Code Capacity - Impact of the Code Tree and Non-Orthogonality

The rule set for the code tree is that if a user is, for example, allocated code 8.0, no users
are allowed to occupy any of the codes to the right, since they would not be orthogonal.
A“fat” (480 kbps) user not only occupies Code 8.0 but effectively occupies 16.0 and
16.1, 32.0, 32.1, 32.2, 32.3, and so on down to 256.63. In other words, one “fat” user
occupies 12.5% of all the available code bandwidth. You could theoretically have one
high-bit-rate user on Code 8.0 and 192 “thin” (15 kbps) users on Code 256.65 through
to Code 256.256:
 1 × high-bit-rate user (Code 8)—Occupies 12.5% of the total code bandwidth.
 192 × low-bit-rate users (Code 256)—Occupy all other codes 256.65 through
256.256.
In practice, the code tree can support rather less than the theoretical maximum,
since orthogonality is compromised by other factors (essentially the impact of multipath
delay on the code properties). Users can, however, be moved to left and right of
the code tree, if necessary every 10 ms, delivering very flexible bandwidth on demand.
These are very deterministic codes with a very simple and rigorously predefined structure.
The useful property is the orthogonality, along with the ability to support variable
data rates; the downside is the limited code bandwidth available.
From a hardware point of view, it is easy to move users left and right on the code tree,
since it just involves moving the correlator to sample the spreading code at a faster or
slower rate. On the downlink (Node B to handset), OVSF codes support individual
users; that is, a single RF channel Node B (1 × 5 MHz) can theoretically support 4 highbit-
rate users (960 kbps), 256 × low-bit-rate (15 kbps) users, or any mix in between.
Alternatively, the Node B can support multiple (up to six) coded channels delivered
to a single user—assuming the user’s handset can decorrelate multiple code streams.
Similarly, on the uplink, a handset can potentially deliver up to six simultaneously
encoded code streams, each with a separate OVSF code. In practice, the peak-to-mean
variation introduced by using multiple OVSF codes on the uplink is likely to prevent
their use at least for the next three to five years, until such time as high degrees of
power-efficient linearity are available in the handset PA.
We have said the following about the different code types:
Spreading codes. Run faster than the original input data. The particular class of
code used for spreading is the OVSF code. It has very deterministic rules that
help to preserve orthogonality in the presence of widely varying data rates.

Scrambling codes. Run at the same rate as the spread signal. They scramble but
do not spread; the chip rate remains the same before and after scrambling.
Scrambling codes are used to provide a second level of selectivity over and
above the channel selectivity provided by the OVSF codes. They provide selectivity
between different Node Bs on the downlink and selectivity between different
users on the uplink. Scrambling codes, used in IMT2000DS, are Gold
codes, a particular class of long code. While there is cross-correlation between
long codes, the cross-correlation is uniform and bounded—rather like knowing
that an adjacent RF channel creates a certain level of adjacent and co-channel
interference. The outputs from the code-generating linear feedback register are
generally configured, so that the code will exhibit good randomness to the
extent that the code will appear noiselike but will follow a known rule set
(needed for decorrelation). The codes are often described as Pseudo-Noise (PN)
codes. When they are long, they have good distance properties.
Short codes. Short codes are good for fast correlation—for example, if we want
to lock two codes together. We use short codes to help in code acquisition and
synchronization.
In an IMT2000DS handset, user data is channel-coded, spread, then scrambled on the
Tx side. Incoming data is descrambled then despread. The following section defines the
hardware/software processes required to implement a typical W-CDMAreceiver transmitter
architecture. It is not a full description of the uplink and downlink protocol.