ZTE UMTS UR15 Code Resource Allocation Feature Guide

Code Resource Allocation
Feature Guide

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
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
Abbreviation .................................................................................................... 38
Reference Document....................................................................................... 38
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
TABLES
Table 6-1 Feature Validation Procedure.............................................................................36
Table 6-2 RNC parameter list 1 .........................................................................................37
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
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
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
Feature Name
Code
Allocation
Resource
License
Configured
Sales
Control Item
NE
Unit
N/A
N/A
N/A
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.
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.
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:
10
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;
11
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
12
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.
13
15
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:
14
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.
15
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
16
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:
17
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
18
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
19
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.
20
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.
21
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
Recom
GUI Name
Parameter Description
Range
Unit
Default menda
tion
22
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.
23
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
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
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:
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
Recom
GUI Name Parameter Description
Range
Unit
Default menda
tion
25
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
are
Configured,
Supporting
MBMS,
26

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
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
27
C310424240
Summation Number of Code Node Free, SF=8
C310424241
C310424242
C310426483
C310424244
C310424245
C310424246
C310426485
C310424248
C310424249
C310424250
C310426487
C310424252
C310424253
C310424254
C310426562
C310424256
C310424257
C310424258
C310426490
C310424260
C310424261
C310424262
C310426564
C310424264
C310424265
C310424266
C310426493
C310424268
C310424269
C310424270
C310426496
28
5.1.3
C310424272
C310424273
C310424274
C310426498
C310424276
C310424277
C310424278
C310426500
C310424280
C310424281
Distribution of Code Node Occupied

Counter No.
Description
C310424282
Times
C310424283
Times of Code Node Used between 1 to 8, SF=256
C310424284
C310424285
C310424286
C310424287
C310424288
C310424289
C310424290
C310424291
C310424292
C310424293
C310424294
C310424295
C310424296
C310424297
C310424298
C310424299
C310424300
of 0 Code Node Used, SF=256
29
C310424301
C310424302
C310424303
C310424304
C310424305
C310424306
C310424307
C310424308
Times of Code Node Used between 201 to 2088,

SF=256
C310424309
C310424310
C310424311
C310424312
C310424313
C310424314
C310424315
Times
C310424316
C310424317
C310424318
C310424319
C310424320
C310424321
C310424322
C310424323
C310424324
C310424325
C310424326
C310424327
C310424328
C310424329
C310424330
C310424331
of 0 Code Node Used,SF=128
30
C310424332
C310424333
C310424334
C310424335
C310424336
C310424337
C310424338
C310424339
C310424340
C310424341
C310424342
C310424343
C310424344
C310424345
C310424346
C310424347
C310424348
Times
C310424349
C310424350
C310424351
C310424352
C310424353
C310424354
C310424355
C310424356
C310424357
C310424358
C310424359
C310424360
C310424361
C310424362
C310424363
of 0 Code Node Used,SF=64
31
C310424364
C310424365
C310424366
C310424367
C310424368
C310424369
C310424370
C310424371
C310424372
C310424373
C310424374
C310424375
C310424376
C310424377
C310424378
C310424379
C310424380
C310424381
Times of 0 Code Node Used,SF=32
C310424382
C310424383
C310424384
C310424385
C310424386
C310424387
C310424388
C310424389
C310424390
C310424391
C310424392
C310424393
C310424394
C310424395
32
5.2
C310424396
C310424397
C310424398
Times of 0 Code Node Used, SF=16
C310424399
C310424400
C310424401
C310424402
C310424403
C310424404
C310424405
C310424406
C310424407
C310424408
C310424409
C310424410
C310424411
C310424412
C310424413
C310424414
C310424415
C310424416
C310424417
C310424418
C310424419
C310424420
C310424421
C310424422
C310424423
Related Alarms
This feature has no related alarm.
33
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
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.
34
Figure 6-2
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
Logical Function Configuration and double-click UTRAN Cell, and set HSPA Support
Method, see Figure 6-4.
35
Figure 6-4
6.3
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.
36
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:
37
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
38
[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
39

ZTE UMTS UR15 Code Resource Allocation Feature Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ZTE UMTS UR15 Code Resource Allocation Feature Guide

Transféré par

Droits d'auteur :

Formats disponibles

Code Resource Allocation

Code Resource Allocation

Code Resource Allocation

Qiong, Nie Xiaoping

2016 ZTE Corporation. All rights reserved.

ZTE Confidential Proprietary

Code Resource Allocation

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

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

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

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

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

ZTE Confidential Proprietary

Code Resource Allocation

ZTE Confidential Proprietary

Code Resource Allocation

ZTE Confidential Proprietary

Code Resource Allocation

: Involved, -: Not involved.

ZWF21-04-006 Code Resource Allocation

ZTE Confidential Proprietary

Code Resource Allocation

Spreading and Scrambling

The ZTE RAN system supports code resource management as follows:

long SCs and 2

short SCs to ensure that each SC of UE is

ZTE Confidential Proprietary

Code Resource Allocation

OVSF Code Tree

License Control List

ZTE Confidential Proprietary

Code Resource Allocation

Correlation with Other Features

Channelization Code Allocation for Uplink Physical

Channelization Code Allocation for the Uplink PRACH

ZTE Confidential Proprietary

Code Resource Allocation

Channelization Code Allocation for the Uplink DPCH

ZTE Confidential Proprietary

Code Resource Allocation

Scrambling Code Allocation for Uplink Physical

Scrambling Code Allocation for the Uplink PRACH

Scrambling Code Allocation for the PRACH Preamble Part

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.

consecuctive chips by 90 degrees.

ZTE Confidential Proprietary

Code Resource Allocation

PRACH Preamble Code

Preamble Scrambling Codes

ZTE Confidential Proprietary

Code Resource Allocation

PRACH Preamble Configuration in Scenarios

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

ZTE Confidential Proprietary

Code Resource Allocation

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

Example of PRACH Configuration in a Cell

(max 16 per cell)

Preamble scrambling code

(one partition per ASC,

ASC 1 ASC 2 ASC 3

Partition not available Partition not availableASC 0 ASC 1