Code Resource Allocation

Feature Guide

Code Resource Allocation

Code Resource Allocation

Version
V1.0

Date

Author

2016/05/12

Cai Yaofang

Reviewer
Ke

Yazhu,

Song

Qiong, Nie Xiaoping

Revision History
Compared with UR14, no change except
software version.

2016 ZTE Corporation. All rights reserved.

ZTE CONFIDENTIAL: This document contains proprietary information of ZTE and is not to be disclosed or used
without the prior written permission of ZTE.
Due to update and improvement of ZTE products and technologies, information in this document is subjected to
change without notice.

ZTE Confidential Proprietary

Code Resource Allocation

TABLE OF CONTENTS
1

Feature Attributes ............................................................................................. 5

2
2.1
2.1.1
2.2
2.3

Overview ............................................................................................................ 5
Feature Introduction ............................................................................................. 5
ZWF21-04-006 Code Resource Allocation ........................................................... 5
License Control .................................................................................................... 7
Correlation with Other Features ........................................................................... 8

3
3.1
3.1.1
3.1.2
3.2
3.2.1
3.2.2
3.3
3.3.1
3.3.2
3.4
3.4.1
3.4.2

Technical Descriptions ..................................................................................... 8

Channelization Code Allocation for Uplink Physical Channels ............................. 8
Channelization Code Allocation for the Uplink PRACH ........................................ 8
Channelization Code Allocation for the Uplink DPCH ........................................... 9
Scrambling Code Allocation for Uplink Physical Channels ................................. 10
Scrambling Code Allocation for the Uplink PRACH ............................................ 10
Scrambling Code Allocation for the Uplink DPCH .............................................. 14
Channelization Code Allocation for Downlink Physical Channels ....................... 17
Channelization Code Allocation for Downlink Common Physical Channels ........ 17
Channelization Code Allocation for the Downlink DPCH .................................... 18
Scrambling Code Allocation for Downlink Physical Channels ............................. 20
Scrambling Code Allocation for Downlink Common Physical Channels ............. 22
Scrambling Code Allocation for the Downlink DPCH .......................................... 22

4
4.1
4.2

Parameters and Configurations ..................................................................... 22

Parameters Related to Scrambling Code Allocation for PRACH ........................ 22
Parameters Related to Channelization Code Allocation for Downlink Physical
Channels ........................................................................................................... 25

5
5.1
5.1.1
5.1.2
5.1.3
5.2

Related Counters and Alarms ........................................................................ 27

Related Counters ............................................................................................... 27
Available Ratio of Code Resource ..................................................................... 27
Number of Code Node Used and Freed ............................................................. 27
Distribution of Code Node Occupied .................................................................. 29
Related Alarms .................................................................................................. 33

6
6.1
6.2
6.3
6.4
6.5

Engineering Guide .......................................................................................... 34

Application Scenario .......................................................................................... 34
Feature Activation Procedure ............................................................................. 34
Feature Validation Procedure ............................................................................ 36
Feature Deactivation Procedure......................................................................... 37
Network Impact .................................................................................................. 37

ZTE Confidential Proprietary

Code Resource Allocation

Abbreviation .................................................................................................... 38

Reference Document....................................................................................... 38

ZTE Confidential Proprietary

Code Resource Allocation

FIGURES
Figure 2-1 Spreading and Scrambling ................................................................................. 6
Figure 2-2 OVSF Code Tree ............................................................................................... 7
Figure 3-1 Example of PRACH Configuration in a Cell.......................................................13
Figure 3-2 Downlink CC Allocation of the DPCH ................................................................19
Figure 6-1 Parameter Configuration Interface1...............................................................34
Figure 6-2 Parameter Configuration Interface2...............................................................35
Figure 6-3 Parameter Configuration Interface3...............................................................35
Figure 6-4 Parameter Configuration Interface4...............................................................36

TABLES
Table 6-1 Feature Validation Procedure.............................................................................36
Table 6-2 RNC parameter list 1 .........................................................................................37

ZTE Confidential Proprietary

Code Resource Allocation

Feature Attributes
RNC Version: [ZXWR RNC V3.15.10.20/ZXUR 9000 V4.15.10.20]
Node B Version: [ZXSDR V4.15.10]
Attribute: [Mandatory]
Related Network Element:
NE Name

Related or Not

UE

Node B

RNC

iTC

MSC

MGW

SGSN

GGSN

HLR

Special Requirement

: Involved, -: Not involved.

Overview

2.1

Feature Introduction

2.1.1

ZWF21-04-006 Code Resource Allocation

As a spread spectrum communication system based on the CDMA technology,
Wideband Code Division Multiple Access (WCDMA) differentiates user equipment (UEs)
by using scrambling codes (SCs) in the uplink direction, and spreads the spectrum by
using the channelization codes (CCs) of the Orthogonal Variable Spreading Factor
(OVSF). In the downlink direction, WCDMA differentiates cells by using the primary
scrambling codes (PSCs), and spreads the spectrum by using CCs of the OVSF. A

ZTE Confidential Proprietary

Code Resource Allocation

downlink CC is also used to differentiate downlink channels in a cell. Figure 2-1 shows
the spreading and scrambling process of WCDMA.

Figure 2-1

Spreading and Scrambling

Channelisation
Code

Scrambling
Code

Spreading

Scrambling

Data

The ZTE RAN system supports code resource management as follows:

Downlink SC
A downlink SC is used to differentiate signals from different cells. There are totally
512 primary scrambling codes (PSCs). Downlink PSCs of adjacent cells must be
different and set as static during network planning.

Uplink SC
An uplink SC is used to differentiate signals from different UEs. An SC of PRACH is
generated according to the PSC of the cell. An SC of DPCCH and DPDCH can be
selected from 2

24

long SCs and 2

24

short SCs to ensure that each SC of UE is

different.

Downlink CC
A downlink CC is used to differentiate downlink channels of a cell. Each downlink
channel of a cell uses a different CC from one OVSF tree, see Figure 2-2. Different
Spread Factors (SFs) support different rates. A smaller SF means higher rate. The
codes of the same SF in the OVSF code tree are mutually orthogonal, and the
codes with different SFs in different code tree branches are also mutually
orthogonal, but the codes with different SFs in the same code tree branches are not
mutually orthogonal. Downlink channels must be mutually orthogonal. Once a code
is assigned, the lower-layer low-rate code nodes and upper-layer high-speed code
nodes in the corresponding code tree can no longer be assigned, that is, they are
blocked.
Due to these features, the downlink CCs become limited resources. Improper

ZTE Confidential Proprietary

Code Resource Allocation

allocation of CCs reduces system capacity. The ZTE RAN system with the DRBC
feature can dynamically adjust the SF allocated to UE in accordance with real-time
traffic. It prevents code resources from being occupied excessively by UE. During
CC allocation, the system minimizes the block rate and maximizes the utilization of
the code tree.

Figure 2-2

OVSF Code Tree

c4,1 = (1,1,1,1)
c2,1 = (1,1)
c4,2 = (1,1,-1,-1)
c1,1 = (1)
c4,3 = (1,-1,1,-1)
c2,2 = (1,-1)
c4,4 = (1,-1,-1,1)
SF = 1

SF = 2

SF = 4

Uplink CC
Uplink CC is used to differentiate uplink channels of a UE. Each UE can use all CCs
of a code tree in its uplink channels. The ZTE RAN system with the DRBC feature
can dynamically adjust the shortest SF available to a UE, preventing CE resources
of a Node B from depletion.

2.2

License Control
Table 2-1

License Control List

Feature ID

ZWF21-04-006

ZTE Confidential Proprietary

Feature Name
Code
Allocation

Resource

License

Configured

Sales

Control Item

NE

Unit

N/A

N/A

N/A

Code Resource Allocation

2.3

Correlation with Other Features

1.

Dependency

None
2.

Mutual exclusion

None
3. Affected Features
None

Technical Descriptions
Code resource allocation contains channel code allocation and scrambling code
allocation. And code allocation depends on the type of the physical channels. This
feature guide only describes code allocation for the PRACH, DPCH and downlink
common physical channels such as P-CPICH, P-CCPCH, S-CCPCH, PICH, AICH, and
S-CPICH. For code allocation about HSDPA and HSUPA, refer to the ZTE UMTS
HSDPA Introduction Feature Guide and the ZTE UMTS HSUPA Introduction Feature
Guide.
The following are the details about code allocation for the above mentioned physical
channels.

3.1

Channelization Code Allocation for Uplink Physical

Channels

3.1.1

Channelization Code Allocation for the Uplink PRACH

Channelization code allocation for the PRACH depends on the preamble signatures.

ZTE Confidential Proprietary

Code Resource Allocation

There are 16 preamble signatures s, 0 s 15, every one of which points to one of the
16 nodes in the code tree that corresponds to the channelization codes of length 16. The
sub-tree below the specified node is used for spreading the message part.
The spread spectrum code used by the control part of the PRACH message is Cc = Cch,
256, m,

where, m = 16 s + 15.

The spread spectrum code used by the data part of the PRACH message is Cd = Cch,SF,m,
where SF is the spreading factor used for the data part ranging from 32 to 256 and m =
SFs/16.
Because the size of a message carried on the RACH is fixed, the SF for a 20 ms TTI is
larger than that for a 10 ms TTI and therefore provides a higher spreading gain. A 20 ms
TTI is suitable for UEs on the coverage border because of higher spreading gain. But for
the UEs that are far away from the base station, power consumption may be high.
For a ZTE RNC, the minimum allowed SF for RACH 20 ms TTI is 64, which channel bit
rate is 60 kbps. The minimum allowed SF for RACH 10 ms TTI is 32, which channel bit
rate is 120 kbps. A UE selects an appropriate SF in accordance with the size of the
PRACH message part and the PRACH system information list broadcasted in
SIB5/SIB5bis which contains the available SF, TTI list and puncturing limit (fixed at
100%).

3.1.2

Channelization Code Allocation for the Uplink DPCH

In the uplink direction, scrambling codes are used to differentiate UEs, and therefore,
each UE in the uplink direction can separately use all channelization codes in a code tree.
The UE dynamically selects the SF and CCs in accordance with the spreading factor
(that is the minimum allowed value) configured at the network side and the data to be
transmitted in each TTI. A ZTE RNC supports only one DPDCH in the uplink.
The uplink DPCH CCs are allocated based on the following rules:

The DPCCH uses the Cch,256,0 code for spreading the spectrum.

If there is only one DPDCH, the CC used by the DPDCH is Cch,SF,k, where, SF refers
to spreading factor and k= SF/4.

ZTE Confidential Proprietary

Code Resource Allocation

3.2

Scrambling Code Allocation for Uplink Physical

Channels

3.2.1

Scrambling Code Allocation for the Uplink PRACH

The scrambling code for the PRACH consists of a scrambling code for the PRACH
preamble part and a scrambling code for the PRACH message part.

3.2.1.1

Scrambling Code Allocation for the PRACH Preamble Part

The PRACH preamble part consisting of a preamble scrambling code and a preamble
signature is defined as follows:
Cpre,n,s(k) = Sr-pre,n(k) Csig,s(k)

j ( k)
e 4 2

, k = 0, 1, 2, 3, , 4095; where:

k denotes the k:th chip and k=0 corresponds to the chip transmitted first in time.

Cpre,n,s(k) denotes a PRACH preamble code for random access.

Sr-pre,n(k) denotes a preamble scrambling code.

Csig,s(k) denotes a preamble signature.

j ( k)
4 2

will reduce the peak to average ratio through limiting the phase shift of

consecuctive chips by 90 degrees.

The PRACH preamble part is illustrated as follows:

ZTE Confidential Proprietary

10

Code Resource Allocation

Figure 3-1

3.2.1.1.1

PRACH Preamble Code

Preamble Signatures
The preamble signature corresponding to a signature s consists of 256 repetitions of a
length 16 signature Ps(n), n=015. This is defined as follows:
Csig,s(k) = Ps(k modulo 16), k = 0, 1, , 4095.
Where, s refers to the index of the signature denoting one of 16 types of Ps(n) and s = 0,
1, , 15, that is, there are 16 PRACH preamble signatures at most for each PRACH.
The preamble signatures for each PRACH are configured by the parameter
UPrach.signature and broadcasted in SIB5 or SIB5bis (for Band IV).
Any PRACH with an individual scrambling code may employ the complete or a subset of
signatures.
If different PRACHs have separate SCs, and each PRACH has its own valid signatures
(16 at most) without considering overlapping with other PRACHs.
If two or more PRACHs adopt the same preamble SC, they are differentiated from each
other through different groups of signatures.

3.2.1.1.2

Preamble Scrambling Codes

The scrambling code for the PRACH preamble part is constructed from the long
scrambling sequences. There are totally 8192 PRACH preamble scrambling codes. The
n:th preamble scrambling code, n = 0, 1, , 8191, is defined as:
Sr-pre,n(k) = clong,1,n(k), k = 0, 1, , 4095;

ZTE Confidential Proprietary

11

Code Resource Allocation

where n denotes the scrambling sequence number, and k denotes the k:th chip, it means
that the n:th preamble scrambling code is obtained from the first 4096 chips of the n:th
long scrambling sequences.
The n is defined as:
n = 16m + i;
where m denotes the downlink primary scrambling code and m = 0, 1, 2, , 511; i
denotes the preamble scrambling code number and i = 0, 1, 2, , 15 which is configured
through the parameter UPrach.PreamScraCode and broadcasted in SIB5 or SIB5bis (for
Band IV).
According to the definition above mentioned, there are 16 preamble scrambling codes at
most for a cell.

3.2.1.1.3

PRACH Preamble Configuration in Scenarios

One or multiple PRACHs can be configured in a cell. The various PRACHs are
distinguished either by different preamble scrambling codes, or by a common scrambling
code but distinct (non-overlapping) partitions of available signatures and available
sub-channels.
Because an Acquisition Indicator (AI) carried on the AICH corresponds to a signature s
on the PRACH, the PRACHs with a same preamble scrambling code correspond to an
AICH. A ZTE RNC supports one PRACH for R99 in this version.
The

scenario

used

for

PRACH

is

configured

by

the

parameter

UUtranCellFDD.prachCfgScene. The common physical channel ID for a PRACH is

configured by the parameter UPrach.commPhyChanelId. The Type of PRACH Preamble
is configured by the parameter UPrach.prachType, which can be set to Random-access
in R99 or Random-access in Common E-DCH.
If Enhanced Uplink FACH is required, the parameter UUtranCellFDD.prachCfgScene is
set to 1: One PRACH Channel of R99 and One PRACH Channel of Enhanced Uplink
Fach with the Same Preamble Scrambling Codes or 2: One PRACH Channel of R99
and One PRACH Channel of Enhanced Uplink Fach with the Different Preamble

ZTE Confidential Proprietary

12

Code Resource Allocation

Scrambling Codes. If Enhanced Uplink FACH is not required, the parameter

UUtranCellFDD.prachCfgScene is set to 0: One PRACH Channel of R99. For details
about enhanced uplink FACH, refer to the ZTE UMTS Enhanced UL CELL_FACH
Feature Guide.
There are two ways to configure different PRACHs in a cell:

PRACH0 and PRACH1 in the following figure are identified by preamble scrambling
code. Each physical channel uses all signatures and sub-channels, and preamble
signatures allocated for each ASC are not overlapped. But the preamble signatures
between ASCs of PRACHs with different scrambling codes can be overlapped.

PRACH2 and PRACH3 in the following figure adopt a common scrambling code.
The preamble signatures allocated to each PRACH are not overlapped.

Figure 3-1

Example of PRACH Configuration in a Cell

RACH

RACH 0

(max 16 per cell)

PRACH
(max 16 per cell)

Preamble scrambling code

(max 16 per cell)

PRACH partitions

ASC 0

(one partition per ASC,

max. 8 per PRACH)

RACH 2

RACH 1

Coding

Coding

RACH 3

Coding

Coding

PRACH 0

PRACH 1

PRACH 2

PRACH 3

Preamble
scrambling
code 0

Preamble
scrambling
code 1

Preamble
scrambling
code 2

Preamble
scrambling
code 2

ASC 1

ASC 2

11

ASC 0

ASC 1 ASC 2 ASC 3

ASC 0

11

Partition not available Partition not availableASC 0 ASC 1

on PRACH 3
on PRACH 2

ASC 1 ASC 2

11

11

available
subchannels
(max 12)

0
0

15
available preamble signatures (max 16)

0
0

15

0
0

10

In the above two ways, each PRACH allocates a varied number of preamble signatures
for different ASCs. The smaller the ASC is, the higher priority and the more preamble
signatures are allocated to it, and the lower the probability of conflict with preambles of
other UEs is during the access process.
Note:
The physical RACH resources (access slots and preamble signatures) may be divided
into different Access Service Classes (ranging from 0 to 7) to provide different priorities
for RACH usage. The access slot resources are identified by RACH sub-channels. There
are 15 access slots per two radio frames, and each access slot is of length 5120 chips.

ZTE Confidential Proprietary

13

15

Code Resource Allocation

The 15 access slots are distributed over 12 sub-channels, that is, a RACH sub-channel is
a subset of the access slots. On each sub-channel there are five access slots allocated
during eight radio frames spaced 12 access slots. For details, refer to the ZTE UMTS Idle
Mode and Common Channel Behavior Feature Guide.
An ASC consists of a PRACH partition and a persistence value (transmission probability).
A PRACH partition is defined as the complete or a subset of the "Available Signature",
and "Available Sub Channel Number" defined for one PRACH. PRACH partitions
employed for ASC establishment may be overlapping (note that Figure 3-1

Example of

only illustrates cases of non-overlapping PRACH partitions). When sending an RRC

CONNECTION REQUEST message, the RRC determines the ASC; in all other cases
the MAC selects the ASC.

3.2.1.2

Scrambling Code Allocation for the PRACH message part

The scrambling code used for the PRACH message part is 10 ms long and there are
8192 different PRACH scrambling codes defined. The n:th PRACH message part
scrambling code, denoted Sr-msg,n, where n = 0, 1, , 8191, is based on the long
scrambling sequence and is defined as:
Sr-msg,n(i) = Clong,n(i + 4096),

i = 0, 1, , 38399

As indicated in the above expression, the message part scrambling code has a
one-to-one correspondence to the scrambling code used for the preamble part. The SCs
th

of the message part start with the 4,096 chip in the SC sequence, while the first 4,096
chips act as the preamble SCs of PRACH. That is, the preamble SCs and message SCs
of PRACH adopt the same SC sequence number.

3.2.2

Scrambling Code Allocation for the Uplink DPCH

3.2.2.1

Uplink Scrambling Code Allocation in General Cases

A DPCCH or DPDCH can be scrambled by either a long or a short scrambling code. The
scrambling code has 38,400 chips in length. The n:th uplink scrambling code, denoted
Sdpch, n, is defined as:

ZTE Confidential Proprietary

14

Code Resource Allocation

Sdpch,n(i) = Clong,n(i),

i = 0, 1, , 38399, when using long scrambling codes;

Sdpch,n(i) = Cshort,n(i),

i = 0, 1, , 38399, when using short scrambling codes;

There are 2

24

long and 2

24

short uplink scrambling codes. The SCs from No. 0 to No.

24

8,191 are allocated to the PRACHs, and all the remaining (2 -8,192) SCs can be used
for the uplink DPCHs. Because the PCPCHs are supported in the earlier versions of
3GPP and the SC sequence numbers used by PCPCHs range from 8,192 to 40,959, the
24

range of uplink SCs available to DPCHs is from 40,960 to 2 -1. ZTE only supports long
scrambling codes.
The scrambling code allocation schemes for uplink DPCH are as follows: The scrambling
code number is associated with the S-RNTI. Because the length of S-RNTI is 20-bits,
and a scrambling code number is 24-bits, so the most significant 3-bits of a scrambling
code is built from a 3-bit random number. The DPCH scrambling code number is defined
as follows:
DPCH Scramble code number = rand (0~7)*2

21

+ 2*S-RNTI + 40960;

Where rand (07) denotes selecting a random number among 07 (corresponding to

21

3-bit length in binary) and rand (07)*2 denotes 21 bits shifted left for the 3-bit random
24

number. If the DPCH Scramble code number is greater than 2 -1, the result is adjusted
as follows:
24

DPCH Scramble code number = DPCH Scramble code number - 2

+ 40960.

During the intra-frequency hard handover, the new uplink scrambling code for new radio
link after the handover is different from that for the old radio link before the handover. The
purpose is to avoid code conflict and improve the handover success rate. The RNC
allocates a different uplink scrambling code after the handover based on the S-RNTI.
DPCH Scramble codenum1 is allocated when the radio link is established at the call
setup. And DPCH Scramble codenum2 is allocated after the intra-frequency hard
handover. If the intra-frequency hard handover occurs repeatedly, DPCH Scramble
codenum1 and DPCH Scramble codenum2 are used alternately.
The allocation method of DPCH Scramble codenum1 is the same as the method of the
DPCH Scramble code number described above.

ZTE Confidential Proprietary

15

Code Resource Allocation

The allocation method of DPCH Scramble codenum2 is equal to DPCH Scramble

24

codenum1 + 1. Similarly, if the result of DPCH Scramble codenum2 is greater than 2 -1,
the result is adjusted as follows:
24

DPCH Scramble codenum2 = DPCH Scramble codenum2 - 2 + 40960.

3.2.2.2

Uplink Scrambling Code Allocation after SRNC Relocation

Upon completion of SRNC relocation, the resources of the UE allocated in the previous
SRNC are released, and the uplink SC allocated to this UE may be re-allocated to
another UE, which causes uplink interference between two UEs. Therefore, upon the
completion of SRNC relocation, the new SRNC must re-allocate the uplink SC to the
relocated UE based on the allocated S-RNTI. The allocation method is the same as the
method described in 3.2.2.1 Uplink Scrambling Code Allocation in General Case.

3.2.2.3

Uplink Scrambling Code Allocation in the Case of Handover from Other

Systems to WCDMA
For a UE being handed over from another system to the 3G system, the RNC needs to
allocate an uplink SC for the UE in accordance with the specification mode IE in the
HANDEOVER TO UTRAN COMMAND message. The details are described as follows:

If the specification mode is Complete specification, the RNC allocates the uplink
SC to the UE in accordance with the description in 3.2.2.1 Uplink Scrambling Code
Allocation in General Case.

If the specification mode is Preconfiguration, as specified by 3GPP, the

pre-configured SC number allocated by the RNC to the UE can only stay within the
Integer range (0..8191) , and this number can only be used temporarily when the
UE is initially handed over to the 3G network. For the uplink SC allocated by the
RNC to the UE for temporary use, the following schemes are adopted:
(1)

The SC is allocated by the RNC to the UE for temporary use. Therefore, the
8,192 SCs are divided into 512 groups, each of which has 16 SCs. That is,
the number of SCs in a cell that can be allocated to UEs being handed over
from other systems to 3G is 16, and all these 16 SCs are related to downlink

ZTE Confidential Proprietary

16

Code Resource Allocation

PSCs: uplink Scramble code Number=16*m+k, k=0,1,.15; m refers to PSC

number. During the planning of PSCs for cells, it has been considered that
the identical PSCs must be geographically far from each other to prevent the
adjacent RNCs from allocating the identical uplink SC numbers to the UEs in
adjacent cells.
(2)

The SCs of PRACH in each cell are the same as the above descriptions.
When the RNC decides to allocate a long SC to the UE being handed over
from other systems to 3G, it must allocate an SC that is not allocated to the
PRACH among the 16 SCs configured for this cell. If no SC is available for
allocation, the RNC may find one from idle uplink long SC resources of
adjacent cells under its control. If the RNC fails to find an idle long SC, it may
adopt the method in Complete specification mode.

(3)

After a UE is successfully handed over to the 3G network, an SC is

re-allocated to the UE through the method described in 3.2.2.1 Uplink
Scrambling Code Allocation in General Case.

3.3

Channelization Code Allocation for Downlink

Physical Channels

3.3.1

Channelization Code Allocation for Downlink Common Physical

Channels
The RNC allocates the CC resources for downlink common physical in the order of
P-CPICH, P-CCPCH, S-CCPCH, PICH, AICH, and S-CPICH channels with the code
number from small to large when the cell is established. In accordance with the
specification, CC allocation of downlink common physical channels is as follows:

The downlink CC used by the P-CPICH is constantly Cch,256,0.

The downlink CC used by the P-CCPCH is constantly Cch,256,1.

The CCs used by other downlink common physical channels are allocated as follows:

ZTE Confidential Proprietary

17

Code Resource Allocation

For the S-CCPCH: Set the parameter UUtranCellFDD.sccpchCfgScene to specify

how many S-CCPCHs are configured. In accordance with TS 25.211, the SFs of
downlink CCs have a one-to-one correspondence with timeslot formats of the
S-CCPCH. Therefore, once the timeslot format of S-CCPCH is determined, the SF
is also determined. For the S-CCPCH carrying PCH only or FACH of MCCH only,
the timeslot format is 4 and the SF is 128, otherwise the timeslot format is 8 and the
SF is 64. A ZTE RNC allocates the downlink CC with the smallest SN to the
S-CCPCH among all allocable CCs with the required SF.

A PICH uses a downlink CC with the SF 256, and one PICH is associated with one
S-CCPCH carrying PCH. A ZTE RNC allocates a downlink CC for every PICH. The
method involves the ZTE RNC allocating a downlink CC with the smallest SN to a
PICH among all allocable CCs with the required SF 256.

An AICH uses a downlink CC with the SF 256, and the number of AICHs is related
to the configuration of the scrambling codes for the PRACHs. A ZTE RNC allocates
a downlink CC for every AICH. The method involves the ZTE RNC allocating the
downlink CC with the smallest SN to the AICH among all allocable CCs with the
required SF 256.

An S-CPICH uses a downlink CC with the SF 256. If a cell supports MIMO,

S-CPICH is needed; otherwise S-CPICH is not configured. A ZTE RNC allocates a
downlink CC for every S-CPICH. The method involves the ZTE RNC allocating the
downlink CC with the smallest SN to an S-CPICH among all allocable CCs with the
required SF 256.

After the cell is established, the addition of S-CCPCHs, PICHs or AICHs is through cell
deletion and cell setup, and the deletion of S-CCPCHs, PICHs or AICHs is through a
COMMON TRANSPORT CHANNEL DELETION REQUEST. The addition or the deletion
of S-CPICHs is through cell setup or cell deletion.

3.3.2

Channelization Code Allocation for the Downlink DPCH

Downlink CCs are limited resources. The allocation of a CC will block the CCs of other
SFs in the same code tree, and therefore, the main objective of CC allocation is to
enhance the code resource utilization. Specifically speaking, when a CC is allocated, the

ZTE Confidential Proprietary

18

Code Resource Allocation

number of other CCs with a low SF blocked in the same code tree must be as few as
possible so that these CCs can be assigned to other UEs. A ZTE RNC supports only one
DPCH in the downlink.
As shown in Figure 3-2

Downlink CC Allocation of the DPCH, suppose C64,1 is already

allocated, which blocks CCs with low SFs such as C32,0, C16,0, and C8,0 in the same code
tree, see in Figure 3-2(a).

Figure 3-2

Downlink CC Allocation of the DPCH

Free
SF= 8
SF=16

SF=32

SF=64

Allocated

0
0
1

` 0

` BLocked

` 0

SF=32

SF=64

` 0

4
(c)

(b)

1
1

SF=16

(a)
SF= 8

` 0

1
1

(d)

There are several schemes available to allocate another CC with SF 64:

The allocation scheme shown in Figure 3-2(b) does not block any CC with low SFs.

The allocation scheme shown in Figure 3-2(c) blocks a high-speed CC with SF 32.

The allocation scheme shown in Figure 3-2(d) blocks two CCs with SFs of 32 and
16 respectively.

Apparently, Figure 3-2(b) demonstrates the highest code table utilization, while Figure
3-2(d) demonstrates the lowest. The aim of downlink CC is to look for the optimal

ZTE Confidential Proprietary

19

Code Resource Allocation

allocation scheme based on a certain algorithm to block as few CCs as possible and
achieve the highest code table utilization.
A ZTE RNC adopts the weight-based downlink CC allocation algorithm to effectively
improve code table utilization and improve system capacity. The allocation principles are
as follows:
1.

The values of SFs of downlink CCs allocated for the DPCH meet DPCH
requirements, and downlink CCs are available for allocation.

2.

Among the downlink CCs that comply with Principle 1, the downlink CCs with the
following features should be allocated with the highest priority: Their upper-level
nodes with a smaller SF in the same CC code tree branch have been blocked.

3.

Among these downlink CCs that comply with Principle 2, the downlink CCs with the
following features should be allocated with the highest priority: Among all blocked
upper-level nodes that comply with Principle 2, the SF value is the largest.

4.

Among the downlink CCs that comply with Principle 3, the downlink CC with the
smallest SN should be allocated first.

3.4

Scrambling Code Allocation for Downlink Physical

Channels
There are totally 24,576 downlink SCs, numbered from 0 to 24,575. The 24,576 SCs can
be divided into the following three parts.

k=0, 1, 2, , 8,191 correspond to 8,192 ordinary scrambling codes.

k+8192, k=0, 1, 2, , 8191: They are the left alternative scrambling code
corresponding to scrambling code k, used in compressed mode when n<SF/2,
where n is the channelization code number used for non-compressed frames.

k+16384, k=0, 1, 2, , 8191: They are right alternative scrambling code

corresponding to scrambling code k, used in compressed mode when n>=SF/2,
where n is the channelization code number used for non-compressed frames.

ZTE Confidential Proprietary

20

Code Resource Allocation

The alternative scrambling codes can be used for compressed frames. The usage of
alternative scrambling code for compressed frames is signaled by higher layers for each
physical channel respectively. In the case compressed mode method SF/2 is used, the
RNC allocates the alternative scrambling code.
The 8,192 ordinary scrambling codes are divided into 512 sets each of a primary
scrambling code and 15 secondary scrambling codes. The details are described as
follows:

The primary scrambling codes consist of scrambling codes n=16*m where

m=0511.

The m:th set of secondary scrambling codes consists of scrambling codes 16*m+i,
where i=115.

There is a one-to-one mapping between each primary scrambling code and 15

secondary scrambling codes in a set such that i:th primary scrambling code
corresponds to i:th set of secondary scrambling codes.

A downlink primary scrambling code is allocated for each cell during network planning
and configured by the parameter UUtranCellFDD.primaryScramblingCode. And the set
of a secondary scrambling code group is determined after the primary SC is allocated. In
the downlink direction, the primary SCs are used to differentiate cells and the CCs to
differentiate channels. It is recommended that allocation of the primary SCs, already
completed during network planning, should ensure minimum mutual correlation between
each cell and its adjacent cells.
The downlink SCs are allocated on the following principles:

The primary CCPCH, primary CPICH, PICH, MICH, AICH and S-CCPCH carrying
PCH shall always be transmitted using the primary scrambling code.

A cell may have 0, 1 or more S-CPICHs which can be transmitted in the whole or
part of a cell. An S-CPICH can be scrambled using a primary or secondary SC. At
present, ZTE only supports an S-CPICH being scrambled by a primary SC.

ZTE Confidential Proprietary

21

Code Resource Allocation

If the P-CPICH or S-CPICH is used as the phase reference, the other downlink
physical links shall be scrambled using the scrambling code of the reference
P-CPICH or S-CPICH.

3.4.1

Scrambling Code Allocation for Downlink Common Physical

Channels
Downlink common physical channels include the P-CCPCH, P-CPICH, PICH, AICH and
S-CCPCH carrying PCH. They are all scrambled by using the downlink primary
scrambling code.
The S-CCPCH not carrying PCH uses the same scrambling code as its phase reference
channel (P-CPICH or S-CPICH). At present, ZTE only supports that the P-CPICH is used
as the phase reference, so the S-CCPCH not carrying PCH is also scrambled by the
downlink primary scrambling code.

3.4.2

Scrambling Code Allocation for the Downlink DPCH

The downlink DPCH can be scrambled using the same scrambling code of the P-CPICH
or S-CPICH that acts as its phase reference. At present, a ZTE RNC allows only the
P-CPICH to be used as a phase reference channel of the downlink DPCH, so a downlink
DPCH is scrambled by the downlink primary scrambling code.

Parameters and Configurations

4.1

Parameters Related to Scrambling Code Allocation

for PRACH
Paramet
er Name

ZTE Confidential Proprietary

Recom
GUI Name

Parameter Description

Range

Unit

Default menda
tion

22

Code Resource Allocation

This parameter indicates all

effective signatures when the
PRACH is used. 16 bit
represents 16 signatures; the
UPrach.si Available

bit which equals 1 means the Bitstrin

gnature

corresponding signature is

Signature

g (16)

111111 111111
N/A

valid. Each signature

111111 111111
1111

1111

corresponds one by one to the

channelization code number of
PRACH whose SF is 16.
This parameter indicates the
preamble scrambling code
index that this PRACH can
use. The scrambling code that
UPrach.p
reamScra
Code

PRACH

can be used for PRACH in

Preamble

each cell relates to the DL

0..15,

Scrambling primary scrambling code of the step 1

Code

N/A

cell. In addition, there are at

most sixteen preamble
scrambling codes available.
This parameter can be used to
distinguish the PRACHs.

ZTE Confidential Proprietary

23

Code Resource Allocation

0: One
PRACH
Channe
l of R99
1: One
PRACH
Channe
l of R99
and
One
PRACH
Channe
l of
Enhanc
ed
Uplink
Fach
with the
Same
Preamb
This parameter indicates

le

typical PRACH configuration

Scramb

scenarios. The PRACH

ling

parameter can be set to

Codes

different values to meet these 2: One

scenarios.

PRACH

If the cell does not support

Channe

enhanced uplink CELL_FACH, l of R99

UUtranCe
llFDD.pra
chCfgSce
ne

PRACH

this parameter is set to "0".

and

Otherwise, it is set to "1" or

One

"2". If this parameter is set to

PRACH

"1", the cell can save one

Channe

AICH code resource of SF

l of

Configurati 256, but the R99 and

on Scene

Enhanc N/A

enhanced uplink CELL_FACH ed

services share the same

Uplink

resource of one PRACH. The Fach

UE's success access ratio will with the
be reduced. If this parameter

Differen

is set to 2, the R99 and

enhanced uplink CELL_FACH Preamb

services use different PRACH le

ZTE Confidential Proprietary

resources. The success

Scramb

access ratio can be

ling

guaranteed, but the cell needs Codes

one more AICH code resource 3: Two
of SF 256.

PRACH
Channe

24

Code Resource Allocation

This parameter indicates the

common physical channel ID
UPrach.c
ommPhy
ChanelId

PRACH

of PRACH. Common physical

Common

channel ID is the unique

68..99,

Physical

identifier allocated to one

step 1

N/A

68

68

N/A

Channel ID common physical channel

within a cell. One cell can
contain several PRACH.
0:

This parameter indicates

Rando

whether the configured

resource for PRACH preamble
part is used for the random
UPrach.p
rachType

access of R99 or common

PRACH

E-DCH services. If both R99

Preamble

services and common E-DCH

cell, both types of PRACH
preamble should be
configured.

4.2

ss in
R99

Type of

services are required in the

m-acce

1:
Rando
m-acce
ss in
Commo
n
E-DCH

Parameters Related to Channelization Code

Allocation for Downlink Physical Channels
Paramet
er Name

ZTE Confidential Proprietary

Recom
GUI Name Parameter Description

Range

Unit

Default menda
tion

25

Code Resource Allocation

0: 2
SCCPCHs
are
Configured,
not
Supporting
MBMS, not
Supporting
CBS
1: 2
SCCPCHs
are
Configured,
not
Supporting
MBMS,
Supporting
CBS
2: 1
SCCPCH is
Configured,
not
Supporting
MBMS, not
Supporting
The parameter indicates
typical SCCPCH
configuration scenarios.
The approviate scenario
can be chosen according
UUtranCe
llFDD.scc
pchCfgSc
ene

to whether MBMS or
SCCPCH

CBS should be

Configurati supported and whether

on Scene

1,2 or 3 SCCPCHs are

configured.For each
scenario, the
corresponding load
balance parameters can
be set as different
values.

CBS

0: 2

3: 1
SCCPCH is
Configured,
not
MBMS,
CBS
4: 2
SCCPCHs
are
Configured,
Supporting
MBMS, not

CHs

CHs

are

are

Config Config

Supporting
Supporting

0: 2

SCCP SCCP

N/A

ured,

ured,

not

not

Suppor Suppor
ting

ting

MBMS, MBMS,
not

not

Suppor Suppor
ting

ting

CBS

CBS

Supporting
CBS
5: 2
SCCPCHs

ZTE Confidential Proprietary

are
Configured,
Supporting
MBMS,

26

Code Resource Allocation

This parameter indicates

UUtranCe
llFDD.pri
maryScra
mblingCo
de

Cell
Primary
Scrambling
Code

the primary scrambling

Config

codes that are used to

ured

distinguish cells. There

are a total of 512

accordi
0..511

N/A

ng to

downlink primary

networ

scrambling codes

available in the UTRAN

plannin

system.

g.

Related Counters and Alarms

5.1

Related Counters

5.1.1

Available Ratio of Code Resource

Counter No.

5.1.2

N/A

Description

C310424227

Current available ratio of code resource

C310424228

Maximum available ratio of code resource

C310426478

Statistics times of minimum code resource

C310424230

Minimum available ratio of code resource

C310424231

Sum available ratio of code resource

Number of Code Node Used and Freed

Counter No.

Description

C310424232

Current Number of Code Node Used, SF=4

C310424233

Current Number of Code Node Used, SF=8

C310424234

Maximum Number of Code Node Used, SF=8

C310426480

Minimum Number of Code Node Used, SF=8

C310424236

Summation Number of Code Node Used, SF=8

C310424237

Current Number of Code Node Free, SF=8

C310424238

Maximum Number of Code Node Free, SF=8

C310426560

Minimum Number of Code Node Free, SF=8

ZTE Confidential Proprietary

27

Code Resource Allocation

C310424240

Summation Number of Code Node Free, SF=8

C310424241

Current Number of Code Node Used, SF=16

C310424242

Maximum Number of Code Node Used, SF=16

C310426483

Minimum Number of Code Node Used, SF=16

C310424244

Summation Number of Code Node Used, SF=16

C310424245

Current Number of Code Node Free, SF=16

C310424246

Maximum Number of Code Node Free, SF=16

C310426485

Minimum Number of Code Node Free, SF=16

C310424248

Summation Number of Code Node Free, SF=16

C310424249

Current Number of Code Node Used, SF=32

C310424250

Maximum Number of Code Node Used, SF=32

C310426487

Minimum Number of Code Node Used, SF=32

C310424252

Summation Number of Code Node Used, SF=32

C310424253

Current Number of Code Node Free, SF=32

C310424254

Maximum Number of Code Node Free, SF=32

C310426562

Minimum Number of Code Node Free, SF=32

C310424256

Summation Number of Code Node Free, SF=32

C310424257

Current Number of Code Node Used, SF=64

C310424258

Maximum Number of Code Node Used, SF=64

C310426490

Minimum Number of Code Node Used, SF=64

C310424260

Summation Number of Code Node Used, SF=64

C310424261

Current Number of Code Node Free, SF=64

C310424262

Maximum Number of Code Node Free, SF=64

C310426564

Minimum Number of Code Node Free, SF=64

C310424264

Summation Number of Code Node Free, SF=64

C310424265

Current Number of Code Node Used, SF=128

C310424266

Maximum Number of Code Node Used, SF=128

C310426493

Minimum Number of Code Node Used, SF=128

C310424268

Summation Number of Code Node Used, SF=128

C310424269

Current Number of Code Node Free, SF=128

C310424270

Maximum Number of Code Node Free, SF=128

C310426496

Minimum Number of Code Node Free, SF=128

ZTE Confidential Proprietary

28

Code Resource Allocation

5.1.3

C310424272

Summation Number of Code Node Free, SF=128

C310424273

Current Number of Code Node Used, SF=256

C310424274

Maximum Number of Code Node Used, SF=256

C310426498

Minimum Number of Code Node Used, SF=256

C310424276

Summation Number of Code Node Used, SF=256

C310424277

Current Number of Code Node Free, SF=256

C310424278

Maximum Number of Code Node Free, SF=256

C310426500

Minimum Number of Code Node Free, SF=256

C310424280

Summation Number of Code Node Free, SF=256

C310424281

Current Number of Code Node Used, SF=512

Distribution of Code Node Occupied

Counter No.

Description

C310424282

Times

C310424283

Times of Code Node Used between 1 to 8, SF=256

C310424284

Times of Code Node Used between 9 to 16, SF=256

C310424285

Times of Code Node Used between 17 to 24, SF=256

C310424286

Times of Code Node Used between 25 to 32, SF=256

C310424287

Times of Code Node Used between 33 to 40, SF=256

C310424288

Times of Code Node Used between 41 to 48, SF=256

C310424289

Times of Code Node Used between 49 to 56, SF=256

C310424290

Times of Code Node Used between 57 to 64, SF=256

C310424291

Times of Code Node Used between 65 to 72, SF=256

C310424292

Times of Code Node Used between 73 to 80, SF=256

C310424293

Times of Code Node Used between 81 to 88, SF=256

C310424294

Times of Code Node Used between 89 to 96, SF=256

C310424295

Times of Code Node Used between 97 to 104, SF=256

C310424296

Times of Code Node Used between 105 to 112, SF=256

C310424297

Times of Code Node Used between 113 to 120, SF=256

C310424298

Times of Code Node Used between 121 to 128, SF=256

C310424299

Times of Code Node Used between 129 to 136, SF=256

C310424300

Times of Code Node Used between 137 to 144, SF=256

ZTE Confidential Proprietary

of 0 Code Node Used, SF=256

29

Code Resource Allocation

C310424301

Times of Code Node Used between 145 to 152, SF=256

C310424302

Times of Code Node Used between 153 to 160, SF=256

C310424303

Times of Code Node Used between 161 to 168, SF=256

C310424304

Times of Code Node Used between 169 to 176, SF=256

C310424305

Times of Code Node Used between 177 to 184, SF=256

C310424306

Times of Code Node Used between 185 to 192, SF=256

C310424307

Times of Code Node Used between 193 to 200, SF=256

C310424308

Times of Code Node Used between 201 to 2088,

SF=256

C310424309

Times of Code Node Used between 209 to 216, SF=256

C310424310

Times of Code Node Used between 217 to 224, SF=256

C310424311

Times of Code Node Used between 225 to 232, SF=256

C310424312

Times of Code Node Used between 233 to 240, SF=256

C310424313

Times of Code Node Used between 241 to 248, SF=256

C310424314

Times of Code Node Used between 249 to 256, SF=256

C310424315

Times

C310424316

Times of Code Node Used between 1 to 4, SF=128

C310424317

Times of Code Node Used between 5 to 8, SF=128

C310424318

Times of Code Node Used between 9 to 12, SF=128

C310424319

Times of Code Node Used between 13 to 16, SF=128

C310424320

Times of Code Node Used between 17 to 20, SF=128

C310424321

Times of Code Node Used between 21 to 24, SF=128

C310424322

Times of Code Node Used between 25 to 28, SF=128

C310424323

Times of Code Node Used between 29 to 32, SF=128

C310424324

Times of Code Node Used between 33 to 36, SF=128

C310424325

Times of Code Node Used between 37 to 40, SF=128

C310424326

Times of Code Node Used between 41 to 44, SF=128

C310424327

Times of Code Node Used between 45 to 48, SF=128

C310424328

Times of Code Node Used between 49 to 52, SF=128

C310424329

Times of Code Node Used between 53 to 56, SF=128

C310424330

Times of Code Node Used between 57 to 60, SF=128

C310424331

Times of Code Node Used between 61 to 64, SF=128

ZTE Confidential Proprietary

of 0 Code Node Used,SF=128

30

Code Resource Allocation

C310424332

Times of Code Node Used between 65 to 68, SF=128

C310424333

Times of Code Node Used between 69 to 72, SF=128

C310424334

Times of Code Node Used between 73 to 76, SF=128

C310424335

Times of Code Node Used between 77 to 80, SF=128

C310424336

Times of Code Node Used between 81 to 84, SF=128

C310424337

Times of Code Node Used between 85 to 88, SF=128

C310424338

Times of Code Node Used between 89 to 92, SF=128

C310424339

Times of Code Node Used between 93 to 96, SF=128

C310424340

Times of Code Node Used between 97 to 100, SF=128

C310424341

Times of Code Node Used between 101 to 104, SF=128

C310424342

Times of Code Node Used between 105 to 108, SF=128

C310424343

Times of Code Node Used between 109 to 112, SF=128

C310424344

Times of Code Node Used between 113 to 116, SF=128

C310424345

Times of Code Node Used between 117 to 120, SF=128

C310424346

Times of Code Node Used between 121 to 124, SF=128

C310424347

Times of Code Node Used between 125 to 128, SF=128

C310424348

Times

C310424349

Times of Code Node Used between 1 to 2, SF=64

C310424350

Times of Code Node Used between 3 to 4, SF=64

C310424351

Times of Code Node Used between 5 to 6, SF=64

C310424352

Times of Code Node Used between 7 to 8, SF=64

C310424353

Times of Code Node Used between 9 to 10, SF=64

C310424354

Times of Code Node Used between 11 to 12, SF=64

C310424355

Times of Code Node Used between 13 to 14, SF=64

C310424356

Times of Code Node Used between 15 to 16, SF=64

C310424357

Times of Code Node Used between 17 to 18, SF=64

C310424358

Times of Code Node Used between 19 to 20, SF=64

C310424359

Times of Code Node Used between 21 to 22, SF=64

C310424360

Times of Code Node Used between 23 to 24, SF=64

C310424361

Times of Code Node Used between 25 to 26, SF=64

C310424362

Times of Code Node Used between 27 to 28, SF=64

C310424363

Times of Code Node Used between 29 to 30, SF=64

ZTE Confidential Proprietary

of 0 Code Node Used,SF=64

31

Code Resource Allocation

C310424364

Times of Code Node Used between 31 to 32, SF=64

C310424365

Times of Code Node Used between 33 to 34, SF=64

C310424366

Times of Code Node Used between 35 to 36, SF=64

C310424367

Times of Code Node Used between 37 to 38, SF=64

C310424368

Times of Code Node Used between 39 to 40, SF=64

C310424369

Times of Code Node Used between 41 to 42, SF=64

C310424370

Times of Code Node Used between 43 to 44, SF=64

C310424371

Times of Code Node Used between 45 to 46, SF=64

C310424372

Times of Code Node Used between 47 to 48, SF=64

C310424373

Times of Code Node Used between 49 to 50, SF=64

C310424374

Times of Code Node Used between 51 to 52, SF=64

C310424375

Times of Code Node Used between 53 to 54, SF=64

C310424376

Times of Code Node Used between 55 to 56, SF=64

C310424377

Times of Code Node Used between 57 to 58, SF=64

C310424378

Times of Code Node Used between 59 to 60, SF=64

C310424379

Times of Code Node Used between 61 to 12, SF=64

C310424380

Times of Code Node Used between 63 to 64, SF=64

C310424381

Times of 0 Code Node Used,SF=32

C310424382

Times of Code Node Used between 1 to 2, SF=32

C310424383

Times of Code Node Used between 3 to 4, SF=32

C310424384

Times of Code Node Used between 5 to 6, SF=32

C310424385

Times of Code Node Used between 7 to 8, SF=32

C310424386

Times of Code Node Used between 9 to 10, SF=32

C310424387

Times of Code Node Used between 11 to 12, SF=32

C310424388

Times of Code Node Used between 13 to 14, SF=32

C310424389

Times of Code Node Used between 15 to 16, SF=32

C310424390

Times of Code Node Used between 17 to 18, SF=32

C310424391

Times of Code Node Used between 19 to 20, SF=32

C310424392

Times of Code Node Used between 21 to 22, SF=32

C310424393

Times of Code Node Used between 23 to 24, SF=32

C310424394

Times of Code Node Used between 25 to 26, SF=32

C310424395

Times of Code Node Used between 27 to 28, SF=32

ZTE Confidential Proprietary

32

Code Resource Allocation

5.2

C310424396

Times of Code Node Used between 29 to 30, SF=32

C310424397

Times of Code Node Used between 31 to 32, SF=32

C310424398

Times of 0 Code Node Used, SF=16

C310424399

Times of 1 Code Node Used, SF=16

C310424400

Times of 2 Code Node Used, SF=16

C310424401

Times of 3 Code Node Used, SF=16

C310424402

Times of 4 Code Node Used, SF=16

C310424403

Times of 5 Code Node Used, SF=16

C310424404

Times of 6 Code Node Used, SF=16

C310424405

Times of 7 Code Node Used, SF=16

C310424406

Times of 8 Code Node Used, SF=16

C310424407

Times of 9 Code Node Used, SF=16

C310424408

Times of 10 Code Node Used, SF=16

C310424409

Times of 11 Code Node Used, SF=16

C310424410

Times of 12 Code Node Used, SF=16

C310424411

Times of 13 Code Node Used, SF=16

C310424412

Times of 14 Code Node Used, SF=16

C310424413

Times of 15 Code Node Used, SF=16

C310424414

Times of 16 Code Node Used, SF=16

C310424415

Times of 0 Code Node Used, SF=8

C310424416

Times of 1 Code Node Used, SF=8

C310424417

Times of 2 Code Node Used, SF=8

C310424418

Times of 3 Code Node Used, SF=8

C310424419

Times of 4 Code Node Used, SF=8

C310424420

Times of 5 Code Node Used, SF=8

C310424421

Times of 6 Code Node Used, SF=8

C310424422

Times of 7 Code Node Used, SF=8

C310424423

Times of 8 Code Node Used, SF=8

Related Alarms
This feature has no related alarm.

ZTE Confidential Proprietary

33

Code Resource Allocation

Engineering Guide

6.1

Application Scenario
This feature is a basic function. It is mandatory for a UMTS network.

6.2

Feature Activation Procedure

The purpose of this chapter is just to guide the reader how to find the GUI location of the
parameters which are related to the deployment of this feature. The values indicated by
the captures possibly are not the real value to be configured. Refer to the last column of
the table in chapter 4 for the practical configuration value.
In the configuration resource tree, select Modify Area > Managed Element > UMTS
Logical Function Configuration > Link Configuration, and double-click Iub Link, and
set Co-NodeB HS-PDSCH Code Sharing Method, see Figure 6-1.

Figure 6-1

Parameter Configuration Interface1

In the configuration resource tree, select Modify Area > Managed Element > UMTS
Logical Function Configuration > UTRAN Cell and double-click HSPA Configuration
In A cell, and set Co-NodeB HS-PDSCH Code Sharing Indicator, see Figure 6-2.

ZTE Confidential Proprietary

34

Code Resource Allocation

Figure 6-2

Parameter Configuration Interface2

In the configuration resource tree, select Modify Area > Managed Element > UMTS
Logical Function Configuration > Link Configuration and double-click Iub Link, and
set Co-NodeB HS-PDSCH Code Sharing Update Period, see Figure 6-3.

Figure 6-3

Parameter Configuration Interface3

In the configuration resource tree, select Modify Area > Managed Element > UMTS
Logical Function Configuration and double-click UTRAN Cell, and set HSPA Support
Method, see Figure 6-4.

ZTE Confidential Proprietary

35

Code Resource Allocation

Figure 6-4

6.3

Parameter Configuration Interface4

Feature Validation Procedure

Table 6-1

Feature Validation Procedure

Test Item

Code Sharing between Cells

1.

The WCDMA system is ready.

2.

Cell1 and Cell2 support HSUPA, HSDPA and DCH. They both
belong to NodeB1.

3.

Cell1 and Cell2 have different frequencies. Cell1 and Cell2

adjacent cells are configured with the same coverage.

4.

The maximum number of HS-PDSCH codes of Cell1 is set to 5,

and the maximum number of HS-PDSCH codes of Cell2 is set
to 10.

Prerequisite
5.

Cell1 and Cell2 are set to share the HS-PDSCH codes in

NodeB1.

6.

UE1 camps on Cell1 in Idle mode.

7.

UE1 supports HSPA. The HSDPA category of UE1 is greater

than 8.

8.

UE1 subscribes interactive or background services, MBR=

UL2Mbps/ DL8Mbps.

ZTE Confidential Proprietary

36

Code Resource Allocation

Test Item

Code Sharing between Cells

1.

Use UE1 to activate a PS call in Cell1 and starts FTP

downloading.

Steps

2.

Maintain the service for 90 s and observes the DL data rate of

UE1.

Expected

3.

Deactivate the PDP.

1.

In step2 the data rate of UE1 can reach 5.8 Mbps. Then the
code number used by UE1 is at least 10, and five codes of

Result

6.4

them are borrowed from Cell2.

Feature Deactivation Procedure

Table 6-2

RNC parameter list 1

Managed Object. logic

name
UIubLink.hsSharMethod

UCHspa.hsShareInd

GUI Name

Default

Deactivation

Value

Value

Co-NodeB HS-PDSCH

0: Not

Code Sharing Method

Sharing

Co-NodeB HS-PDSCH

0: Not

Code Sharing Indicator

Sharing

0: Not Sharing

0: Not Sharing

For the above parameters description and configuration, refer to chapter 6.2 Feature
Activation Procedure.

6.5

Network Impact
1.

Equipment Performance Influence

None
2.

Network KPI

Advantages:

ZTE Confidential Proprietary

37

Code Resource Allocation

With a reasonable channelization code allocation algorithm, the channelization code can
be utilized effectively and the codes on the code tree are not blocked unnecessarily, thus
the calling probability is guaranteed.
With a reasonable scrambling code allocation algorithm, the adjacent cells or users do
not adopt the same scrambling code, thus interference and the call drop rate are
decreased.
Disadvantages:
None

Abbreviation
Abbreviation

Full Name

AICH

Acquisition Indicator Channel

ASC

Access Service Class

DPCH

Dedicated Physical Channel

OSVF

Orthogonal Variable Spreading Factor

P-CPICH

Primary Common Pilot Channel

PICH

Paging Indicator Channel

PRACH

Physical Random Access Channel

RACH

Random Access Channel

S-CCPCH

Secondary Common Control Physical Channel

SF

Spreading Factor

S-RNTI

SRNC - Radio Network Temporary Identifier

Reference Document
[1] 3GPP TS 25.213
[2] 3GPP TS 25.211
[3] 3GPP TS 25.922

ZTE Confidential Proprietary

38

Code Resource Allocation

[4] ZTE UMTS Idle Mode and Common Channel Behavior Feature Guide
[5]ZXUR

9000

UMTS(V4.15.10.20)Radio

Network

Controller

Radio

Parameter

Reference
[6]ZXUR 9000 UMTS(V4.15.10.20)Radio Network Controller Ground Parameter
Reference
[7]ZXUR 9000 UMTS(V4.15.10.20)Radio Network Controller Performance Counter
Reference
[8] ZXWR RNC(V3.15.10.20)Radio Network Controller Radio Parameter Reference
[9] ZXWR RNC(V3.15.10.20)Radio Network Controller Ground Parameter Reference
[10] ZXWR RNC(V3.15.10.20)Radio Network Controller Performance Counter Reference

ZTE Confidential Proprietary

39