ZTE UMTS Code Resource Allocation Feature Guide - V8 5 - 201312 - 548008

Code Resource Allocation
Feature Guide
WCDMA RAN
Code Resource Allocation Feature Guide

Version Date Author Reviewer Revision History
1. Updated 3.2.2.6 DPCH/F-DPCH

Re-Assign of HSDPA cell.
2. Added dynamic allocation of E-AGCH
and E-RGCH/E-HICH code in.3.3.2.3
CC Allocation of Downlink E-AGCH
and 3.3.2.4 CC Allocation of Downlink
E-RGCH/E-HICH respectively.
3. Added 3.3.2.5
E-AGCH/E-RGCH/E-HICH number
adjustment triggered by
E-AGCH/E-RGCH/E-HICH CC
V7.0 2012-3-26 Hu Xingxing Liu LiPing
congestion
4. Updated the fairness of R99 DCH and

HSDPA in 3.2.2.3 CC Allocation of
Downlink HS-PDSCH.
5. Deleted ZTE Node B does not support

HS-PDSCH CC allocation currently.
6. Updated Fairness of R99 DCH and

HSDPA.
1. Updated 3.2.2.9 Fairness of R99 DCH

and HSDPA.
2. Added notes for Parameters of

Cai
MaxEagchNum and numofEagch.
V8.0 2012-12-1 Yaofang/Xia Cui Lili
Zhiyuan
3. Updated the parameter name for
Fairness of R99 DCH and HSDPA.
4. Added the counter of C311775712:
Number of downgraded R99 service
caused by HSDPA of Higher Code
ZTE Confidential Proprietary 1

Priority.
5. Updated RCP to CMP.
6. Added 3.2.2.10 HS-SCCH and
HS-PDSCH CCs Multiplexing in M-RRU
Sector-based Scheduling.
7. Added a parameter on Node B for CC
Allocation of HS-PDSCH by Node B.
1. Added Feature ID.

Cai
2. Added 3.6 Code Sharing between
V8.5 2013-11-23 Yaofang/Xia Cui Lili
Cells, 3.5 Fast Dynamic Code
Zhiyuan
Allocation.
2013 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.

TABLE OF CONTENTS
1 Feature Attributes ............................................................................................. 6
2 Overview ............................................................................................................ 6
2.1 ZWF21-04-006 Code Resource Allocation ........................................................... 9
2.1.1 R99 Code Resource Allocation ............................................................................ 9
2.1.2 HSDPA Code Resource Allocation ...................................................................... 9
2.1.3 HSUPA Code Resource Allocation .................................................................... 10
2.1.4 Uplink Enhanced CELL_FACH Code Resource Allocation ................................. 11
2.2 ZWF23-04-020 Fast Dynamic Code Allocation .................................................. 11
2.3 ZWF23-04-021 Code Sharing between Cells ..................................................... 11
3 Technical Descriptions ................................................................................... 12

3.1 R99 Code Resource Allocation .......................................................................... 12
3.1.1 SC Allocation of Uplink Physical Channel .......................................................... 12
3.1.2 SC Allocation of Downlink Physical Channel ...................................................... 18
3.1.3 Uplink CC .......................................................................................................... 19
3.1.4 Downlink CC Management ................................................................................ 21
3.2 HSDPA Code Resource Allocation .................................................................... 24
3.2.1 SC Allocation ..................................................................................................... 24
3.2.2 CC Allocation ..................................................................................................... 24
3.3 Code Resource Allocation of HSUPA................................................................. 36
3.3.1 SC Allocation ..................................................................................................... 36
3.3.2 CC Allocation ..................................................................................................... 36
3.4 Code Resource Allocation of Uplink Enhanced CELL_FACH ............................. 48
3.4.1 SC Allocation ..................................................................................................... 48
3.4.2 CC Allocation ..................................................................................................... 49
3.5 Fast Dynamic Code Allocation ........................................................................... 50
3.6 Code Sharing between Cells .............................................................................. 51
4 Parameters and Configurations ..................................................................... 52

4.1 Parameters Related to R99 Code Resource Allocation ...................................... 52
4.1.1 Parameter List ................................................................................................... 52
4.1.2 Parameter Configurations .................................................................................. 52
4.2 Parameters Related to HSDPA Code Resource Allocation ................................ 55
4.2.1 Parameter List ................................................................................................... 55
4.3 Parameters Related to HSUPA Code Resource Allocation ................................ 63
4.3.1 Parameter List ................................................................................................... 63

4.4 Parameters Related to Uplink Enhanced CELL_FACH Code Resource

Allocation ........................................................................................................... 69
4.4.1 Parameter List ................................................................................................... 69
4.5 Parameters Related to Fast Dynamic Code Allocation ....................................... 71
4.5.1 Parameter List ................................................................................................... 71
4.6 Parameters Related to Code Sharing between Cells ......................................... 72
4.6.1 Parameter List ................................................................................................... 72
5 Counter List ..................................................................................................... 73
6 Glossary ........................................................................................................... 80

FIGURES
Figure 2-1 Spreading and Scrambling ................................................................................. 7

Figure 2-2 Allocation of Downlink CCs ................................................................................ 8
Figure 3-1 Configuration Example of Cell PRACH .............................................................14
Figure 3-2 Spreading of Uplink DPCCH and Uplink DPDCH ..............................................21
Figure 3-3 Downlink CC Allocation of DPCH ......................................................................23
Figure 3-4 Mechanism of Increasing the Number of HS-PDSCHs......................................27
Figure 3-5 Mechanism of Decreasing the Number of HS-PDSCHs ....................................28
Figure 3-6 Flowchart of the methods for E-AGCHs allocation ............................................39
Figure 3-7 Flowchart of the methods for E-RGCH/E-HICHs allocation ...............................44

1 Feature Attributes
System version: [RNC V3.12.10/V4.12.10, OMMR V12.12.41, Node B V4.12.10, OMMB
V12.12.40]
Attribute: [Mandatory + Optional]
Involved NEs:
UE Node B RNC MSCS MGW SGSN GGSN HLR
- - - - -
Note:
-: Not involved.
: Involved.
Dependency: [None]
Mutual exclusion: [None]
Note: [None]
2 Overview
As a spread spectrum communication system based on CDMA technology, Wideband
Code Division Multiple Access (WCDMA) differentiates User Equipment (UE) by using
Scrambling Codes (SC) in the uplink direction, and spreads the spectrum by using
Channelization Codes (CC) of the Orthogonal Variable Spreading Factor (OVSF). In the
downlink direction, WCDMA differentiates cells by using Primary Scrambling Codes
(PSC), and spreads the spectrum by using CCs of the OVSF. WCDMA is used to
differentiate downlink channels in the same cell. Figure 2-1 shows the spreading and
scrambling process of WCDMA.

Figure 2-1 Spreading and Scrambling
Channelisation Scrambling
Code Code
Data
Spreading Scrambling
In the downlink direction, WCDMA contains a total of 8,192 SCs divided into 512 groups,
each of which contains one PSC and 15 secondary scrambling codes (SSC). Each cell is
assigned a unique PSC and corresponding SSC group. PSCs are used for the downlink
common channel to differentiate various cells.
In the downlink direction, WCDMA spreads the spectrum for channels by using the CCs
of the OVSF, and separates various downlink channels by using the orthogonality of
different CCs. The OVSF codes can be indicated through a code tree. A code in the code
tree can be expressed as Cch,SF,k, where, SF refers to the spreading factor, and k refers
to the code number (the number ranges from 0 to SF-1). The codes of the same SF in
the OVSF code tree are mutually orthogonal, the codes with different SFs in different
code tree branches are also mutually orthogonal, and the codes with different SFs in the
same code tree are not mutually orthogonal. But downlink channels are required to be
mutually orthogonal. Once a code is assigned, its 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 a
limited resource. Any irrational allocation of CCs reduces system capacity. Therefore, the
allocation and management of downlink CCs is crucial to the WCDMA system.
24 24
WCDMA has a total of 2 long SCs and 2 short SCs available in the uplink direction.
There are enough SC resources in uplink. When allocating SC resources, each UE shall
be assigned a different SC. When the spectrum is spread for the dedicated channel in
the uplink direction, each UE can use all CCs in a CC tree without sharing CCs with other
UEs. 3gpp expressly stipulates the rules for allocating the SCs and CCs in the uplink
common channel.

Figure 2-2 Allocation of Downlink CCs
Cch,4,0 =(1,1,1,1)
Cch,2,0 = (1,1)
Cch,4,1 = (1,1,-1,-1)
Cch,1,0 = (1)
Cch,4,2 = (1,-1,1,-1)
Cch,2,1 = (1,-1)
Cch,4,3 = (1,-1,-1,1)
SF = 1 SF = 2 SF = 4
Code resource management covers the following aspects:
R99-related code resource management, including:
SC and CC allocation of uplink physical channel, including Physical Random

Access Channel (PRACH), and uplink Dedicated Physical Channel (DPCH)
SC and CC allocation of downlink physical channel, including downlink common

physical channel and downlink DPCH
HSDPA related code resource management includes SC and CC allocation of

HS-DPCCH in the uplink direction, F-DPCH, HS-SCCH and HS-PDSCH in the downlink
direction, and CC allocation of downlink DPCH in the HSDPA-capable cell. The CC
allocation of HS-PDSCH includes the static and dynamic allocation.
HSUPA related code resource management includes SC and CC allocation of uplink

E-DPCCH/E-DPDCH, and downlink E-AGCH/E-RGCH/E-HICH.HSPA+ related code
resource management includes CC allocation of enhanced F-DPCH, and the impact on
F-DPCH defined by the R6 protocol.

2.1 ZWF21-04-006 Code Resource Allocation
2.1.1 R99 Code Resource Allocation
Code resource control is to allocate the downlink CCs to cells dynamically according to
certain rules with a view of maximizing the utilization of code resources and increasing
system capacity.
The OVSF codes are used for spreading the downlink spectrum. The mutually
orthogonal downlink spread spectrum codes are allocated to different channels. The
OVSF is expanded through a binary tree. The codes at the same layer are mutually
orthogonal, so are the codes in different layers without direct inheritance relation. If a
code is used, the lower-layer codes and the codes at the same branch from this code to
the code tree root are not available. Therefore, the downlink code resources of each cell
are limited and should be fully utilized.
The downlink CCs are allocated to a cell according to its level. The downlink CCs of the
common channel are first allocated when the cell is established. The downlink CCs of the
dedicated channel are dynamically allocated when the channel is established.
The code resources should be utilized to the utmost. During the service setup, the RNC
calculates the SF according to the service rate, and allocates the corresponding CCs.
After the service is released, the CCs should also be released so as to allocate them to
other UEs. For each cell, the RNC maintains a CC table. The CC table records the status
of each code, for example, idle, allocated or shielded. When code resources are
allocated, it is required to prevent the idle code resource block caused by the allocation
of codes from being shielded.
2.1.2 HSDPA Code Resource Allocation
When HSDPA and R99 use the same carrier frequency, the HSDPA service throughput
of each cell is affected by the number of the HS-PDSCHs, which is the number of the
codes with the SF 16 allocated to a HS-PDSCH. ZTE RNC supports dynamic or static
allocation of the HS-PDSCHs. The dynamic allocation can flexibly and quickly reflect the
change in system load.

ZTE RNC supports the dynamic allocation of the CCs of the downlink HS-PDSCHs and
physical HS-SCCHs, which includes the following:
Supports the manually configuring of the number of HS-PDSCH/HS-SCCH CCs in

OMCR
Supports the reallocation of HS-PDSCCH/HS-SCCH CCs (increase or decrease

the number of these channels)
According to the data throughput of the HSDPA services and flow demand of the R99
services, the HS-PDSCH resources are dynamically adjusted and the CCs of the
downlink HS-PDSCHs are dynamically allocated. The number of HS-PDSCH CCs is
re-estimated in two ways:
1. Fast prediction and adjustment mode;
2. Allocating HS-PDSCHs and total power dynamically according to the congestion

status, and re-allocating CCs.
The dynamic allocation of codes of the HSDPA also includes the dynamic adjustment of
code resource between the HSDPA and R99 service.
For an M-RRU cell including several sectors, HS-SCCH and HS-PDSCH CCs can be
multiplexed among different sectors through Node B scheduling policy. For the details
about the M-RRU, refer to ZTE UMTS Coverage Enhancement Feature Guide.
2.1.3 HSUPA Code Resource Allocation
The HSUPA introduces three types of downlink physical channels (E-AGCH, E-RGCH,
and E-HICH). The SF of E-AGCH is 256, and the SF of E-RGCH/E-HICH is 128. The
E-RGCH and E-HICH can use the same CC. They are differentiated through the
signature sequences. The E-AGCH and E-RGCH/E-HICH use the same scrambling
code.
The HSUPA code resources of the E-AGCH and E-RGCH/E-HICH can be configured on
this principle: One E-RGCH/E-HICH channel can be shared by a maximum of 20 HSUPA
UEs, and one E-AGCH can be shared by a maximum of 16 to 25 HSUPA UEs.

E-DPCCH and E-DPDCH are introduced in the uplink for HSUPA. The CC of E-DPCCH
is fixed. The CC of E-DPDCH(s) is allocated on UE side according to the number of
DPDCH and the number of E-DPDCHs used. E-DPCCH/E-DPDCH uses the same SC
as the uplink DPCCH.
There are two methods to modify the number of E-AGCHs and E-RGCH/E-HICHs. One
is a static configuration and the other is a dynamical adjustment according to the number
of dedicated HSUPA UEs in real time. The latter is a new introduced feature.
2.1.4 Uplink Enhanced CELL_FACH Code Resource Allocation
The RNC allocates the code resources for the PRACH, AICH, F-DPCH, E-AGCH and
E-RGCH/E-HICH in uplink enhanced CELL_FACH when the cell is established. There
are only one PRACH, one AICH and one E-AGCH for the uplink enhanced CELL_FACH.
The RNC can configure at most 32 sets of resources, and configure F-DCH/
E-RGCH/E-HICH information for every resource.
2.2 ZWF23-04-020 Fast Dynamic Code Allocation
RNC dynamic allocation method is applied in HS-PDSCH code allocation for ZTE Node
B. Relative to HSDPA 2ms TTI scheduling, the signaling delay between RNC and Node
B is so long that R99 must be reserved to enough free codes while RNC is configuring
HS-PDSCH code. For the fast HSDPA scheduling, these free codes probably cause a
waste of SF16 code resources. So, the solution of Node B free code allocation is
introduced.
2.3 ZWF23-04-021 Code Sharing between Cells
Generally, the operator purchases the HSDPA code license of each cell according to the
number of codes. For example, 5 codes, 10 codes, or 15 codes as a set, the code is
SF=16 HS-DSCH channelized code. If the number of codes is different, the peak bit rate
is also different. Therefore, the operator may purchase the HSDPA code license
according to the development of the data service instead of buying the entire 15-code
license, so that the operation cost can be significantly reduced.

If the operator purchases the HSDPA license of each cell by 5 or 10 codes, because the
transient loads of the cells in a base station are different, the data requirement of one cell
may be very high and exceeds the peak bit rate of 5 or 10 codes, while the data
requirement of other cells is very low and the 5 or 10 codes cannot be fully used.
With this feature, the HSDPA code license can be shared among different cells. In the
above scenario, the light-load cell may lend its code license to the heavy-load cells. As a
result, the transient available HSDPA codes of a single cell exceed the number of codes
authorized to it, but will not exceed the threshold of 15 HS-DSCH channelized codes per
cell. The total number of HS-DSCH channelized codes used by all cells does not exceed
the total number of codes license authorized to all cells.
3 Technical Descriptions
3.1 R99 Code Resource Allocation
3.1.1 SC Allocation of Uplink Physical Channel
3.1.1.1 SC Allocation of PRACH
Preamble of PRACH
A PRACH preamble is generated by a preamble SC and a signature:

j ( k)
4 2
Cpre,n,s(k) = Sr-pre,n(k) Csig,s(k) e , k = 0, 1, 2, 3, , 4,095;
Preamble SC of PRACH
A PRACH preamble SC is generated by the long SC sequence:
Sr-pre,n(i) = clong,1,n(i), i = 0, 1, , 4,095; n =0, 1,2,, 8,191;
There are a total of 8,192 preamble SCs in the whole system. The SC and
preamble of the PRACH message part use the same SC sequence number n, and
th
the SC in message part starts with the 4,096 chip in the SC sequence.

All 8,192 SCs are divided into 512 groups, each of which contains 16 SCs. The
relation between the SC sequence number and PSC sequence number of the
related cell is as follows: n = 16m+k, m = 0, 1, , 511; k = 0, 1, , 15. In the 16
available SCs, the PreamScraCode is used to configure the SC in the OMCR by
the RNC.
Signature of PRACH preamble
The preamble signature is constituted by the 16-bit Ps(n)( n=015) code for 256
times:
Csig,s(i) = Ps(i modulo 16), i = 0, 1, , 4095.
There are 16 types of PS(i) , and s refers to the index of the signature.
There are 16 PRACH preamble SCs and 16 PRACH preamble signatures in each
cell. Multiple PRACHs can be set in a cell, and they can be configured with different
PRACH preamble SCs and preamble signatures.
The RNC has different PRACHs configured in the following two modes:
Different PRACHs have separate SCs, and each PRACH has its own valid
signatures (16 at most; configured through Signature in the OMCR) without
considering overlapping with other PRACHs. One PRACH corresponds to one
AICH. PRACH0 and PRACH1 in the following figure are physical channels that
have their own specific SCs. Each physical channel uses all signatures and
sub-channel numbers, and preamble signatures allocated for each ASC are
not overlapped. But preamble signatures between ASCs of different PRACHs
can be overlapped.
Two or more PRACHs adopt the same preamble SC, but they are
differentiated from each other by using different groups of signatures. The
access possibility of any signature is the same. When configuring PRACHs
with identical SCs, ensure that the signatures allocated for two physical
channels are not overlapped. Two or more PRACHs correspond to one AICH.
In the following figure, PRACH2 and PRACH3 adopt identical SCs, but the
preamble signatures allocated to each of them are not overlapped.

Each PRACH allocates a varied number of preamble signatures for different ASCs.
The smaller the ASC is, the more preamble signatures are allocated to it, and the
lower the probability of conflict with preambles of other UEs during the access
process.
The following figure illustrates the above two cases respectively.
Figure 3-1 Configuration Example of Cell PRACH
RACH RACH 0 RACH 1 RACH 2 RACH 3

(max 16 per cell)
Coding Coding Coding Coding
PRACH
(max 16 per cell) PRACH 0 PRACH 1 PRACH 2 PRACH 3
Preamble Preamble Preamble Preamble
Preamble scrambling code scrambling scrambling scrambling scrambling
(max 16 per cell) code 0 code 1 code 2 code 2
PRACH partitions ASC 0 ASC 1 ASC 2 ASC 0 ASC 1 ASC 2 ASC 3 ASC 0 ASC 1 ASC 2 Partition not available Partition not availableASC 0 ASC 1
(one partition per ASC, on PRACH 2 on PRACH 3
max. 8 per PRACH)
11 11 11 11
available
subchannels
(max 12)
0 0 0 0
0 15 0 15 0 9 10 15
available preamble signatures (max 16)
SC of the PRACH message part
There are a total of 8,192 SCs in the PRACH message part. The relation between
each SC and its corresponding SC sequence is as follows:
Sr-msg,n(i) = Clong,n(i + 4096), i = 0, 1, , 38,399
th
As indicated in the above expression, the SCs of 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.1.1.2 SC Allocation of DPCH
Uplink SC allocation of normal calls
A DPCCH or DPDCH can be scrambled by long or short SCs. The SC has 38,400
chips in length. The relation between the SC length and long/short SC sequence is
as follows:

Sdpch,n(i) = Clong,n(i), i = 0, 1, , 38,399
Sdpch,n(i) = Cshort,n(i), i = 0, 1, , 38,399
24
The number of SCs available in the uplink direction in WCDMA is 2 . The No. 0 to
24
No. 8,191 SCs are allocated to the PRACHs, and the remaining (2 -8,192) SCs
can all be used for the uplink DPCHs. Considering that the versions earlier than R4
of 3GPP support the PCPCHs in the uplink direction and the SC sequence numbers
used by PCPCHs range from 8,192 to 40,959, the range of uplink SCs available to
24
DPCHs is 40,960 to 2 -1.When the cells managed by several RNCs are adjacent, it
is possible that identical uplink SCs are allocated to different UEs at the edge of
adjacent cells, thus causing great interference between each other. To avoid such a
problem, a non-overlapped SC segment is allocated to adjacent RNCs, and each
RNC can only allocate uplink SCs to UEs within its own SC segment allocated (The
SC allocation of each RNC can be planned by operators, and the RNC SC
segments that are not mutually adjacent can be reused). In addition, long and short
SCs exist in the uplink direction, and the number of them is the same (40,960 ~
24
2 -1). So long as the SC segments are determined, the SC segments available to
RNCs include both long and short SCs with the same value range by default. If
Node B supports multi-UE detection, short SCs are allocated; if Node B does not
support multi-UE detection, long SCs are allocated. ZTE Node B does not support
multi-UE detection currently.
ZTE RNC allocates an ID to a UE accessing the system in a Control plane public

Main Processor (CMP) in the RNC system. This ID is unique in the CMP range, and
the IDs of different CMPs can be identical. Based on such a feature, the SCs can be
subdivided to segments and allocated to CMPs, which means uplink SCs can be
managed (including allocation and release) according to CMPs.
The allocation schemes are as follows:
i. Determine the number of SCs allocated to each CMP according to the CMP
capacity, and configure these two parameters: RcpScrStartId and
RcpScrEndId in the OMCR.
ii. The CMP can map the ID of a UE on the current CMP into the SC number in
the following way: In order to improve the intra-frequency hard handover

success rate, RNC allocates two SCs to each user. The SC before hard
handover and the SC after hard handover is different. If the Sequence
Numbers (SN) of SCs allocated for the uplink DPCH are denoted by DPCH
Scramble codenum1 and 2, the SNs are as follows.
DPCH Scramble codenum1 = Starting No. of CMP Scrambling Code + ID*2,
DPCH Scramble codenum2 = Starting No. of CMP Scrambling Code + ID*2+1.
RNC allocates DPCH Scramble codenum1 to the UE for the first time, and
allocates the other to the new radio link in the intra-frequency frequency hard
handover to avoid the SCs conflict that will cause the call drop. This scheme
necessitates no dedicated management of uplink SCs. Moreover, it is easy to
use and highly efficient.
Uplink SC allocation for 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, thus causing the uplink interference between two UEs.
Therefore, upon the completion of SRNC relocation, the new SRNC must
re-allocate the uplink SC within its own managed SC segment to the relocated UE
based on the uplink SC allocation policy of normal calls. The allocation method is
the same as that of Uplink SC allocation of normal calls.
Uplink SC allocation in the case of handover from other systems to WCDMA
For a UE handed over from another system to the 3G system, the type of the
allocated SC (Long and short) is still judged on the principle in Part 1. If the SC type
is determined, the RNC needs to allocate the UE to be handed over to 3G
according to the specification mode IE cell in the HANDEOVER TO UTRAN
COMMAND message.
If the specification mode is Complete Specification, the RNC allocates the uplink
SCs to the UE by using the uplink SC allocation scheme for normal calls.
If the specification mode is Preconfiguration, the pre-configured SC number

allocated by the RNC to the UE can only stay within the Integer(0..8191) range, and
this number can only be temporarily when the UE is initially handed over to the 3G

network, as stipulated in the protocol. For the 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 that can be allocated to UEs handed over from other systems to 3G is 16, and
these 16 SCs are all related to downlink PSCs: Scramble code =16*m+k,
k=0,1,.15; m refers to PSC number. During the planning of cell PSCs, it has been
considered that the Identical PSCs must be geographically far from each other to
prevent the adjacent RNCs to allocate the identical uplink SC numbers to the UEs in
adjacent cells.
2. The uplink SCs of PRACH in each cell are the same as the above descriptions, and
long SCs are allocated.
i. When the RNC decides to allocate a long SC to the UE handed over from
other systems to 3G, it must allocate an SC that is not allocated to the PRACH
among the 16 uplink 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 (6 at most) under its jurisdiction. If it fails to find an idle long SC,
the RNC may return a no SC for allocation result (In this case, parameters
may be configured in the Complete specification mode).
ii. When the RNC decides to allocate a short SC to a UE handed over from other
systems to 3G, the short SCs may be exhausted by a large number of UEs
handed over to the same cell at a time. The reason is that each cell has only
16 short SCs in spite of no use of short SCs by a PRACH. If short SCs of a cell
are used up, the RNC can still allocate a short SC from idle uplink short SCs of
adjacent cells under its jurisdiction. If no idle short SC is available even in
adjacent cells, parameters can be configured in the Complete specification
mode.
3. After a UE is successfully handed over to the 3G network, an SC is re-allocated to

the UE by adopting the uplink SC allocation scheme for normal calls.

3.1.2 SC Allocation of Downlink Physical Channel
There are 24,576 downlink SCs in total, numbered from 0 to 24,575 in turn. The 24,576
SCs can be divided into the following three parts.
k=0, 1, 2, till 8,191 correspond to 8,192 common SCs, and are used for a common
mode.
k+8192, k=0,1,2,8191: They refer to 8,192 substitute SCs, also known as left
substitute SCs, used in compressed mode when n<SF/2. The letter n refers to the
SN of downlink CCs used in non-compressed mode.
k+16384, k=0,1,2,8191: They refer to 8,192 substitute SCs, also known as right
substitute SCs, used in compressed mode when n>=SF/2. The letter n refers to
the SN of downlink CCs used in non-compressed mode.
Substitute SCs can be used in compressed mode to scramble compressed frames,

which are instructed by high-level signaling to use substitute SCs or ordinary SCs.
The first 8,192 ordinary SCs are divided into 512 groups, each of which contains one
primary SC and 15 secondary SCs following the primary SC.
SN of primary SCs: n=16*I i=0,,511
SN of secondary SCs: 16*i + k k=1,,15
The 512 primary SCs are divided into 64 groups, each of which contains 8 primary SCs.
For the No. K primary SC of Group J, the relation between SC numbers and SNs is
expressed as follows:
8*J*16 + K*16 J=0,,63 K=0,,7
A downlink primary SC is allocated for each cell during network planning, and secondary
SC group is determined after the primary SC is allocated. In downlink direction, primary
SCs are used to differentiate cells and CCs to differentiate channels. It is recommended
that the allocation of primary SCs, already completed during network planning, should
ensure minimum mutual correlated between each cell and its adjacent cells.
The downlink SCs are allocated on the following principles:

The P-CCPCH, P-CPICH, PICH, AICH, S-CCPCH (carrying a PCH) and MICH
must be scrambled by using primary SCs in a cell.
A cell may have 0, 1 or more S-CPICHs, which can transmit in the whole or part of a cell.
The S-CPICH can be scrambled by using primary or secondary SCs. At present, ZTE
only supports the S-CPICH to be scrambled by primary SCs.
If using the P-CPICH or S-CPICH as the phase reference, other downlink physical
links must use the SC of the reference P-CPICH or S-CPICH for scrambling.
3.1.2.1 SC Allocation of Downlink Common Physical Channels
Downlink common physical channels include the P-CCPCH, P-CPICH, PICH, AICH and
S-CCPCH that carries a PCH. They are all scrambled by using downlink primary SCs.
If carrying no PCH, S-CCPCH uses the same scrambling code as its phase reference
channel (P-CPICH or S-CPICH). At present, ZTE only supports it to be scrambled by
primary SCs.
3.1.2.2 SC Allocation of Downlink DPCH
The downlink DPCH can be scrambled by using the same SC of the P-CPICH or
S-CPICH that acts as its phase reference. At present, ZTE allows only the P-CPICH to
be used as a phase reference channel of the downlink DPCH.
3.1.3 Uplink CC
3.1.3.1 CC Allocation of Uplink PRACH
There are 16 uplink preamble signatures s (0 s 15) in total, which are repeatedly
constituted by sixteen 16-bit code sequences in the code tree with the SF=16 for 256
times. The spread spectrum code used by the control part of the PRACH:
cc = Cch,256,m;
Where, m = 16 s + 15.

The spread spectrum code used by the data part of PRACH:
cd = Cch,SF,m
Where, SF refers to Spreading Factor of the data part. The value of SF ranges from 32 to
256; m = SF s/16. The minimum SF is invariably configured as 64. The UE adaptively
selects the SF according to the size of the PRACH message part, the minimum SF and
the puncturing limit (which is invariably configured as 100%).
3.1.3.2 CC Allocation of Uplink DPCH
In the uplink direction, SCs are used to differentiate UEs, and therefore, each UE in the
uplink direction can separately use all CCs in a code tree. The UE dynamically selects
the SF and CCs according to the AvailableSF configured at the network side and the
data to be transmitted by each TTI. If multiple CCs are used, the UE should ensure the
orthogonality between CCs.
The uplink DPCH CCs are allocated based on the following principles:
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.
If there are multiple DPDCHs, and the SF of all DPDCHs is 4, the CC used by
DPDCHn is Cch,4,k ,
Where,
k = 1 if n {1, 2},
3 if n {3, 4},
2 if n {5, 6}
It can be seen that DPDCH1 and DPDCH2, DPDCH3 and DPDCH4 and DPDCH5
and DPDCH6 respectively use identical CC because DPDCHs with odd and even
numbers are respectively mapped into the real and imaginary parts of uplink DPCH,
as shown in Figure 3-2. Therefore, uplink DPDCHs can use the same CC in pairs.

Figure 3-2 Spreading of Uplink DPCCH and Uplink DPDCH
cd,1 d
DPDCH1
cd,3 d

DPDCH3 I
cd,5 d
DPDCH5
I+jQ
Sdpch
cd,2 d
DPDCH2
cd,4 d
DPDCH4

Q
cd,6 d
DPDCH6
j
cc c
DPCCH
3.1.4 Downlink CC Management
3.1.4.1 CC Allocation of Downlink Common Physical Channels
RNC allocates the CC resources for downlink common physical channels when the cell
is established in the order of P-CPICH, P-CCPCH, S-CCPCH, PICH, AICH, and
S-CPICH. The CC allocation of downlink common physical channels is as follows:
The protocol makes the following stipulations:
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:

The S-CPICH uses a downlink CC with the SF 256, and ZTE RNC decides to
allocate the channel code for S-CPICH based on the capability of cell supporting
the S-CPICH. If the cell supports the S-CPICH, ZTE RNC allocates the downlink
CC with the smallest SN to the S-CPICH among all allocable CCs with the required
SF. Otherwise, ZTE RNC does not allocation channel code to the S-CPICH.
The AICH uses a downlink CC with the SF 256, and ZTE RNC allocates the
downlink CC for every AICH in the OMCR. 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.
The PICH uses a downlink CC with the SF 256, and ZTE RNC allocates the
downlink CC for every PICH in the OMCR. The method involves the ZTE RNC
allocating the downlink CC with the smallest SN to the PICH among all allocable
CCs with the required SF.
For the S-CCPCH: According to TS 25.211, the SFs of downlink CCs have a
one-to-one correspondence with timeslot formats (when the S-CCPCH only carry
PCH or only FACH of MCCH, the timeslot format is 4,otherwise,it is 8) of the
S-CCPCH. Therefore, once the timeslot format of S-CCPCH is determined, the SF
is also determined. ZTE RNC allocates the downlink CC with the smallest SN to the
S-CCPCH among all allocable CCs with the required SF.
3.1.4.2 Downlink CC Allocation of 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 to CC allocation is to
enhance the code resource utilization. Specifically speaking, when a CC is allocated, the
number of other CCs with a low SF in the same code tree that should be blocked must be
as few as possible so that these CCs can be assigned to other UEs. As shown in Figure
3-3, suppose C64,1 is already allocated: it will block CCs with low SFs such as C32,0, C16,0,
and C8,0 in the same code tree, as shown in Figure 3-3(a). Now you have several
schemes available to allocate another CC with SF 64. The allocation scheme in Figure
3-3(b) does not block any CC with low SFs. The allocation scheme shown in Figure 3-3(c)
blocks a high-speed CC with SF 32, while the allocation scheme shown in Figure 3-3(d)
blocks two CCs with SFs of 32 and 16 respectively. Apparently, Figure 3-3(b)

demonstrates the highest code table utilization, while Figure 3-3(d) the lowest. The aim
of downlink CC is to look for the optimal allocation scheme based on certain algorithm to
block as few CCs as possible and achieve the highest code table utilization. ZTE RNC
adopts weight-based downlink CC allocation algorithm to effectively improve the 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 first: Their upper-level nodes with a smaller
SF in the same CC code tree branch are blocked.
3. Among these downlink CCs that comply with Principle 2, the downlink CCs with the
following features should be allocated first: 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.
Figure 3-3 Downlink CC Allocation of DPCH
Free
Allocated
SF= 8 0 0
` BLocked
SF=16 ` 0 1 ` 0 1
SF=32 ` 0 1 ` 2 3 ` 0 1 ` 2 3
SF=64 ` ` ` ` ` ` ` `
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
(a) (b)
SF= 8 0 0
SF=16 ` 0 1 ` 0 1
SF=32 ` 0 1 ` 2 3 ` 0 1 ` 2 3
SF=64 ` ` ` ` ` ` ` `
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
(c) (d)

3.2 HSDPA Code Resource Allocation
3.2.1 SC Allocation
3.2.1.1 SC Allocation of Uplink HS-DPCCH
The uplink HS-DPCCH can be scrambled by either long SCs or short SCs, and it uses
the same SCs as the uplink DPCCH of the same UE. If Node B supports multi-UE
detection, short SCs are allocated; if Node B does not support multi-UE detection, long
SCs are allocated. ZTE Node B does not support multi-UE detection currently.
3.2.1.2 SC Allocation of Downlink HS-SCCH and HS-PDSCH
The HS-PDSCH can be scrambled by using either primary SCs or secondary SCs. A
group of HS-PDSCHs and the HS-SCCH that carries the channel scheduling information
of this group of HS-PDSCHs must use the same downlink SC, more specifically, the SCs
used by their phase reference channel (P-CPICH or S-CPICH). At present, ZTE only
supports them to be scrambled by primary SCs.
3.2.1.3 SC Allocation of Downlink F-DPCH
There are two kinds of F-DPCH, the ordinary F-DPCH and the enhanced F-DPCH
(E-FDPCH). The ordinary F-DPCH uses the same SCs as its phase reference channel
(P-CPICH or S-CPICH). At present, ZTE only allows the P-CPICH to act as a phase
reference channel. The SC allocation method of E-FDPCH is the same to the method of
ordinary F-DPCH.
3.2.2 CC Allocation
3.2.2.1 CC Allocation of Uplink HS-DPCCH
In the uplink direction, the CC allocation rule of the HS-DPCCH is related to the number
of DPCCHs, as listed in the following table.

Table 3-1 CC Allocation Rule of HS-DPCCH
Nmax-dpdch Channelization code Cch
1 Cch,256,64
2,4,6 Cch,256,1
3,5 Cch,256,32
Nmax-dpdch refers to the maximum number of DPDCHs that can be supported by TFC
in TFCS. When Nmax-dpdch is an even number, HS-DPCCH is mapped into branch I
(real part); when Nmax-dpdch is an odd number, HS-DPCCH is mapped into branch Q
(imaginary part).
3.2.2.2 CC Allocation of Downlink HS-SCCH
The HS-SCCH adopts the spread spectrum codes with the SF 128 for spreading the
spectrum, and consecutive allocation is not required. ZTE RNC adopts a static method to
configure the number of HS-SCCHs. If only one HS-SCCH is configured, HS-PDSCHs
code multiplexed is not supported because MAC-hs can only schedule one HSDPA
service in each scheduling cycle. If more than one HS-SCCH are configured,
HS-PDSCHs code multiplexed is supported because MAC-hs can schedule more than
one HSDPA service in each scheduling cycle. The details about HS-PDSCHs code
multiplexing and MAC-hs scheduling are described in the ZTE UMTS HSDPA Packet
Schedule Feature Guide. The number of HS-SCCHs is configured by NumofHsscch in
the OMCR.
The number of HS-SCCH CCs is configured in the OMCR, and these CCs are allocated
by the RNC in an ascending order of SNs of allocable downlink CCs in the code tree after
the R99 downlink common physical channels are allocated when the cell is established.
3.2.2.3 CC Allocation of Downlink HS-PDSCH
The HS-PDSCH adopts the CC with the SF 16 for spreading the spectrum. The RNC
allocates CCs in a descending order of their SNs consecutively, particularly, performing
consecutive allocation of CCs starting with Cch,16,15.
ZTE RNC can configure the number of HS-PDSCHs in dynamic mode or in static mode.

Static allocation
To adopt the static configuration mode, you need to collect statistics of average
data throughput within the coverage area of the cell in advance, estimate the
number of HS-PDSCHs required. The static allocation is a special example of the
next dynamic allocation. ZTE RNC carries it out by setting the minimum value
(MinNumofHspdsch) and maximum value (MaxNumofHspdsch) to the same value
in dynamic allocation. If the average data throughput within the coverage area
changes, you need to modify the MinNumofHspdsch and MaxNumofHspdsch in
OMCR.
Dynamic allocation
1. Period-based dynamic adjustment of HS-PDSCH CC
Perform periodic collection of statistics of HS-PDSCH CCs (the OMCR configures

the period of dynamic adjustment through the CodeUptPrd parameter, and
configures the time unit of CodeUptPrd through the CodeUptPrdUnit parameter). If
the number of idle CCs is less than a certain threshold, decrease the number of
HS-PDSCHs; if the number of idle CCs is larger than a certain threshold, increase
the number of HS-PDSCHs.
Specifically speaking, add one HS-PDSCH if Formula 1 is observed.
If Formula 2 is observed:
If hsVsR99CdPriInd is set to Not Supported, delete one HS-PDSCH.
If hsVsR99CdPriInd is set to Supported which means fairness of R99 DCH

and HSDPA should be considered, refer to 3.2.2.9 Fairness of R99 DCH and
HSDPA for the detail.
OcuRateNoHspdsch + OcuRateHspdsch + DpchCodeHy + 32 <= 512 Formula 1
OcuRateNoHspdsch + OcuRateHspdsch + CodeUptHyA > 512

Formula 2

OcuRateHspdsch refers to the number of the SF512 codes blocked by the

HS-PDSCH.
OcuRateNoHspdsch refers to the number of the SF512 codes blocked by the

non-HS-PDSCH channels.
DpchCodeHy refers to the number of the SF512 codes reserved for the
DPCHs.
CodeUptA refers to the threshold, which is expressed by the number of SF 512

codes used to determine whether to decrease the number of HSPDSCHs. In
the formula, 512 refers to the total number of the SF 512 codes in the code
tree, and 32 refers to the number of the SF 512 codes blocked by one
HS-PDSCH which occupies one SF16 code. There exists the following relation:
DpchCodeHy >= CodeUptHyA >= 0.
Note: The parameters above are expressed by the number of SF512 codes
because 512 is the maximum spreading factor in the code tree,
Figure 3-4 and Figure 3-5 respectively show the process of dynamic adjustment of
HS-PDSCH code resources (deltaP refers to the number of the codes with the SF
512, which is converted from the number of the unallocated downlink CCs).
Figure 3-4 Mechanism of Increasing the Number of HS-PDSCHs
OcuRateHspdsch If deltaP>=DpchCodeHy+32,
increase the HS-PDSCH
number
DpchCodeHy
deltaP
Max Code Usage
512
OcuRateNoHspdsch

Figure 3-5 Mechanism of Decreasing the Number of HS-PDSCHs
OcuRateHspdsch
If deltaP<CodeUptHyA,
decrease the HS-PDSCH number
deltaP
CodeUptHyA
Max Code Usage
(512)
OcuRateNoHspdsch
2. Dynamic adjustment triggered by DPCH CC congestion
When the DPCH CCs are congested, one HS-PDSCH is deleted. The number of
the remaining HS-PDSCHs must be greater than or equal to the minimum number
of HS-PDSCHs (MinNumofHspdsch). ZTE RNC forbids the increase in the number
of HS-PDSCHs triggered by the period-based dynamic adjustment of HS-PDSCH
CC within 15s.
3. Dynamic adjustment triggered by HS-PDSCH throughput congestion
If the HSDPA data throughput is restricted, it indicates that the HS-PDSCH CCs of
the current cell are not enough. After a certain number of CCs (DpchCodeHy) are
reserved for the DPCH, it is triggered to add one HS-PDSCH. The increased
number of HS-PDSCH must be smaller than or equal to the maximum number of
HS-PDSCHs (MaxNumofHspdsch). After the HSDPA data throughput congestion
triggers the increase in the number of HS-PDSCHs, the number of HS-PDSCHs
may be decreased because the number of HSDPA UEs is zero. To avoid this
problem, ZTE RNC forbids the decrease in the number of HS-PDSCHs triggered by
the number of HSDPA UEs as zero within 20s.
4. Other contents related to dynamic adjustment of number of HS-PDSCHs
During dynamic adjustment of the number of HS-PDSCHs, ZTE RNC restricts the
number of HS-PDSCHs between the minimum value (MinNumofHspdsch) and

maximum value (MaxNumofHspdsch), which are configured in the OMCR.

According to the sum of maximum bit rate of the current HSDPA services
(HsMBRSum), sum of guarantee bit rate (HsGBRSum), and average data rate
(HspdschBitRate) of a single HS-PDSCH configured in the OMCR, ZTE RNC also
calculates the maximum number of HS-PDSCHs (MaxHspdschNumbyMBR)
required by all the current HSDPA services and the minimum number of
HS-PDSCHs (MinHspdschNumbyGBR) required to ensure the guarantee rate of all
the current HSDPA services. In addition, ZTE RNC selects the largest of three
values,MaxHspdschNum, MinHspdschNumbyMBR and the maximum number(15)
of free SF16 codes in the cell, as the upper limiter for the adjustment of number of
HS-PDSCHs, and selects MinNumofHspdsch or MinHspdschNumbyGBR,
whichever is larger, as the lower limit for the adjustment of number of HS-PDSCHs.
Formula 3 and Formula 4 describe the calculation process of
MaxHspdschNumbyMBR and MinHspdschNumbyGBR respectively.
MaxHspdschNumbyMBR HsMBRSum
(0.5 HspdschBitRate)
Formula 3
MinHspdschNumbyGBR HsGBRSum
(0.5 HspdschBitRate)
Formula 4
When the number of real-time HS-PDSCHs in the cell is smaller than the
NumofHspdsch value configured in the OMCR, ZTE RNC allows increasing the
HS-PDSCH number to NumofHspdsch directly to increase the number of
HS-PDSCHs quickly. When the number of real-time HS-PDSCHs in the cell is
larger than the NumofHspdsch value configured in the OMCR, only one HS-PDSCH
is added at a time.
When the number of HSDPA Radio Bearers (RBs) in the cell is zero, ZTE RNC
allows the number of HS-PDSCHs to be directly decreased to the
MinNumofHspdsch value configured in the OMCR.

3.2.2.4 DPCH CC Allocation in HSDPA-Capable Cell
The CCs used by the HS-PDSCH are consecutively allocated starting from Cch,16,15. The
number of HS-PDSCHs may be adjusted dynamically. To avoid the impact on the
throughput of the HSDPA service due to the conflict between the downlink CCs of DPCH
used by the R99 service and the those of the HS-PDSCHs increased during dynamic
adjustment, ZTE RNC allocates the downlink CC with the smallest SN to the downlink
DPCH among all allocable CCs with the required SF, that is, the CCs used by the
downlink DPCH should be as far from those used by the HS-PDSCH as possible in the
code tree.
3.2.2.5 OCNS Cell Downlink CC Allocation
The following changes to the downlink CC allocation are implanted in order to support
the OCNS function:
ZTE RNC configures the OCNS code by the parameter OCNSCodeNumber, and
configures the OCNS code index by the parameter OCNSCode.
In the cells supporting HSDPA services, SF16 codes will be separated into several
parts by the OCNS code. In this case, the part in which the free SF16 code of the
largest index exists can be used by the HS-PDSCH channels.
If the OCNS codes are changed, ZTE RNC will re-establish the cell.
In order to avoid blocking the SF16 codes in the middle of the code tree, the
settings of OCNS codes in Annex-E5.2 of Specification 34.121 are recommended.
3.2.2.6 DPCH/F-DPCH Re-Assign of HSDPA cell
In order that the DPCH/F-DPCH codes could make the best use of CC and free more
SF16 codes, and also allocate the codes of HSDPA more efficiently, DPCH/F-DPCH
Re-Assign of HSDPA cell performs periodic re-assignment the SF16 blocked by the
DPCH/F-DPCH channels. The parameter CodeReAssPrd controls the period.
DPCH/F-DPCH Re-Assign of HSDPA cell can free the blocked SF16 code and allocate it
to the HS-PDSCH. This function is controlled by CodeReAssInd. If the HS-PDSCH

number needs to be increased and the free SF=512 code number is larger than 64, the
DPCH/F-DPCH code re-assignment is performed.
The steps of re-assignment are as follows:
1. Find the SF16 code which has the biggest code index and is blocked by
DPCH/F-DPCH, then set it as SF16_i.
2. Re-assign all the DPCH/F-DPCH channels which blocked the SF16_i to other free
channels. The code indexes of new free channels are less than the old ones and
the SF is kept.
In the above description, if ZTE RNC works as DRNC for the services whose
channelization code blocks the SF16_i,
If IurCdReAssDrop is On, ZTE RNC sends Radio Link Failure message to

SRNC, and releases the radio link and channelization code of the services.
If IurCdReAssDrop is Off, ZTE RNC does not re-assign the DPCH/F-DPCH

code of the services.
3.2.2.7 CC Allocation of DC-HSDPA cell
HS-DPCCH is only allocated in the primary carrier. HS-SCCH is allocated in both the
primary carrier and the secondary carrier. The protocol describes that the number of
HS-SCCH detected by one UE cannot exceed 6, and the number of HS-SCCH
cannot exceed 4 in each carrier. HS-DPCCH and HS-SCCH CC allocation method
in DC-HSDPA cell is the same as the method in single carrier cell. The dynamic
HS-PDSCH CC allocation methods in DC-HSDPA cell are the same as the
HS-PDSCH CC allocation methods in single carrier cell except that the HS-PDSCH
number of each DC-HSDPA cell will be increased by one if HS-PDSCH throughput
is congested. ZTE RNC also restricts the range of adjustment of each carrier as
followed:
Assumptions:
The MBR sum of the HSDPA services borne in the primary cell: HsMBRSum 1;
The MBR sum of the HSDPA services borne in the secondary cell:

HsMBRSum2; The MBR sum of the HSDPA services borne in both cells:
HsMBRSum_dual.
The GBR sum of the HSDPA services borne in the primary cell: HsGBRSum 1;
The GBR sum of the HSDPA services borne in the secondary cell:
HsGBRSum2; The GBR sum of the HSDPA services borne in both cells:
HsGBRSum_dual.
The maximum and minimum HS-PDSCH number of the primary cell:

MaxNumofHspdsch1 and MinNumofHspdsch1; The maximum and minimum
HS-PDSCH number of the secondary cell: MaxNumofHspdsch2 and
MinNumofHspdsch2.
Restrictions:
Primary cell HS-PDSCH number >=max(HsGBRSum1

/(0.5*HspdschBitRate),MinNumofHspdsch1)
Secondary cell HS-PDSCH number >=max(HsGBRSum 2

/(0.5*HspdschBitRate),MinNumofHspdsch2)
Sum of the primary and secondary HS-PDSCH number >=

HsGBRSum1/(0.5*HspdschBitRate) + HsGBRSum2/(0.5*HspdschBitRate) +
HsGBRSum_dual/(0.5*HspdschBitRate)
Sum of the primary and secondary HS-PDSCH number <= min(HsMBRSum 1

/(0.5*HspdschBitRate + HsMBRSum2/(0.5*HspdschBitRate) + HsMBRSum_dual
/(0.5*HspdschBitRate),MaxNumofHspdsch1+ MaxNumofHspdsch2)
3.2.2.8 F-DPCH CC Allocation
The F-DPCH is introduced to save downlink code resources, that is, multiple UEs share
one F-DPCH in the time-division mode. Compared to the R5 protocol, it is not required to
set up an associated downlink DPCH for the UE only having HSDPA services.
The F-DPCH always adopts the downlink CCs with the SF 256 for spreading the
spectrum. When a new F-DPCH is established, the RNC allocates the CC with the
smallest SN among all the currently unused CCs with the SF 256 to the F-DPCH.

The mechanism for multiple UEs to reuse F-DPCH is as follows:
It can be known from the frame structure of the F-DPCH that, if a UE uses one F-DPCH,
the TPC bits in one timeslot only occupy 256 chips, and the rest bits adopt DTX.
Therefore, the F-DPCH with the same CC can be configured for multiple UEs that are
subjected to time division multiplexing in the same timeslot. A timeslot contains 2,560
chips in total for reuse by a maximum of 10 UEs. The timing relation for multiple UEs to
reuse one F-DPCH wireless frame in relation to PCCPCH wireless frame is determined
by the RNC through parameter configurations: For the lub interface, set the chip offset
parameter, and for the Uu interface, set F-DPCH frame offset (Integer (0..38144 by step
of 256)).
There are two kinds of F-DPCH, the ordinary F-DPCH and the enhanced F-DPCH
(EF-DPCH). The ordinary F-DPCH fixedly uses the second TPC of every slot. The
EF-DPCH can use any TPC of every slot.
When judging whether the F-DPCH can be reused by new UEs, the RNC needs to
calculate F-DPCH,p according to Default DPCH Offset Value and to judge whether the
established F-DPCH has any unoccupied part to TDM the new TPC commands(as to
F-DPCH, the established F-DPCH is reused only when its second TPC of every slot is
free; as to EF-DPCH, the established F-DPCH is reused when it has free TPC); if yes,
the established F-DPCH is reused; if not, a new F-DPCH is established, the CC with the
smallest SN among idle CCs with the SF 256 is allocated to it, and the related F-DPCH,p
is given.
3.2.2.9 Fairness of R99 DCH and HSDPA
ZTE can adjust the priority of HSDPA and R99 services in code resource allocation
according to the code resource currently used by R99 and HSDPA services.
The parameter hsVsR99CdPriInd controls whether to switch on the function. For the
access request of a new incoming user or a handover user or a PCH to DCH user, R99
service is always given the priority in code resource allocation compared with HSDPA
service and it is not controlled by the parameter.

3.2.2.9.1 Threshold for code fairness
Define a threshold for code fairness = max {the lower limit for the adjustment of number
of HS-PDSCHs calculated in 3.2.2.3, min {NumofHspdsch, Maximum Number of
HS-PDSCH}}. And HSDPA service is given the priority in using the code resource in the
range of threshold for code fairness. If the code resource currently used by HSDPA
service exceeds the threshold, the HS-PDSCH code will be decreased if needed in the
period-based dynamic adjustment of HS-PDSCH CC. Otherwise, the code resource
used by R99 will be decreased prior to that used by HSDPA service.
The formula below is used to judge the priority of code resource allocation.
The user number of HSDPA service >0 and code resource currently used by HS-PDSCH
<= the threshold for code fairness. Formula 5
Note:
If HsSharMethod is set to Not Sharing, Maximum Number of HS-PDSCH takes the
value of upper limit for the adjustment of number of HS-PDSCHs calculated in 3.2.2.3
CC Allocation of Downlink HS-PDSCH.
If HsSharMethod is set to Sharing, Maximum Number of HS-PDSCH takes the value of
maximum HS-PDSCH number calculated in 3.6 Code Sharing between Cells
3.2.2.9.2 Code Allocation for Fairness
If hsVsR99CdPriInd is set to Supported, the following judgment is periodically

performed with period-based dynamic adjustment of HS-PDSCH CC in 3.2.2.3 CC
Allocation of Downlink HS-PDSCH.
For HsNBAssInd is set to Not Supported:
If the code resource of threshold for code fairness is used by non HSDPA service, DCH
downgrade of R99 service will be triggered.
If Formula 2 in 3.2.2.3 CC Allocation of Downlink HS-PDSCH and Formula 5 for judging

the priority of code resource allocation are observed, DCH downgrade of R99 service will
be triggered and code resource for HS-PDSCH is not decreased. If there is any failure in

DCH downgrade, delete one HS-PDSCH. If only Formula 2 in 3.2.2.3 CC Allocation of

Downlink HS-PDSCH is observed, delete one HS-PDSCH directly.
For HsNBAssInd is set to Supported: if the code resource currently used by

HS-PDSCH < threshold for code fairness, DCH downgrade of R99 service will be
triggered.
Note:
The principles for selecting services for downgrade are the same as those described in
ZTE UMTS Congestion Control Feature Guide.
Please refer to ZTE UMTS Congestion Control Feature Guide for the congestion
control algorithm for fairness of R99 DCH and HSDPA.
3.2.2.10 HS-SCCH and HS-PDSCH CCs Multiplexing in M-RRU Sector-based

Scheduling
An M-RRU cell includes several sectors. When UEs stay in partial sectors and use
HSDPA service, traditionally downlink HS-SCCH and HS-PDSCH channel codes
allocated to the cell are occupied by all sectors. In order to improve downlink CCs usage
ratio in M-RRU cell, Node B adopts M-RRU sector-based scheduling policy to allocate
HS-SCCH and HS-PDSCH channel codes.
If the value of hsMRRUSchInd is No, M-RRU cell doesnt adopt sector-based

scheduling policy, an HSDPA service in one sector can occupy HS-SCCH and
HS-PDSCH CCs of all sectors in the cell. And the same channel codes cannot be used
by other sectors or users.
If the value of hsMRRUSchInd is Yes, M-RRU cell adopt sector-based scheduling,

HS-SCCH and HS-PDSCH codes can be multiplexed among different sectors in the
M-RRU cell. Node B allocates HS-SCCH and HS-PDSCH channelized codes to UEs so
that they can be used within UEs belonged sector. Node B can also allocate these codes
to the other users in other sectors.
In the situation that the value of hsMRRUSchInd is Yes, if the value of

MRRU456NotComInd is No, M-RRUM sector-based scheduling enables the reusing of

HS-SCCH and HS-PDSCH channelized codes among at most 3 sectors; if the value of
MRRU456NotComInd is Yes, M-RRU sector-based scheduling enables the reusing of
HS-SCCH and HS-PDSCH channelized codes among at most 6 sectors.
Please refer to ZTE UMTS Coverage Enhancement Feature Guide for the M-RRU
introduction.
3.3 Code Resource Allocation of HSUPA
3.3.1 SC Allocation
3.3.1.1 SC Allocation of Uplink E-DPCCH/E-DPDCH
The uplink E-DPCCH/E-DPDCH uses the same SC as the uplink DPCCH.
3.3.1.2 SC Allocation of Downlink E-AGCH/E-HICH/E-RGCH
In a cell, the E-AGCH and E-RGCH/E-HICH allocated to a UE use the same SC as their
phase reference channels (P-CPICH or S-CPICH). At present, ZTE RNC only allows the
P-CPICH to act as the phase reference channel, that is, primary scrambling code of the
cell is used for the downlink E-AGCH and E-RGCH/E-HICH.
3.3.2 CC Allocation
3.3.2.1 CC Allocation of Uplink E-DPCCH
As described in TS 25.213, the E-DPCCH shall be spread with channelization code of

Cch,256,1.
3.3.2.2 CC Allocation of Uplink E-DPDCH
The CCs used by E-DPDCHs are allocated according to the rule listed in Table 3-2
where Nmax-dpdch means the largest number of simultaneously-configured uplink
dedicated channel DPDCHs from all the TFCs in the TFCS as described in TS 25.213.

Table 3-2 Channelization code for E-DPDCH (TS 25.213)
Nmax-dpdch E-DPDCHk Channelization code Ced,k
0 E-DPDCH1 Cch,SF,SF/4 if SF 4
Cch,2,1 if SF = 2
E-DPDCH2 Cch,4,1 if SF = 4
Cch,2,1 if SF = 2
E-DPDCH3 Cch,4,1
E-DPDCH4
1 E-DPDCH1 Cch,SF,SF/2
E-DPDCH2 Cch,4,2 if SF = 4
Cch,2,1 if SF = 2
Note
When more than one E-DPDCH is transmitted, the respective channelization codes used
for E-DPDCH1 and E-DPDCH2 are always the same.
If the number of E-DPDCHs exceeds 2, the UE always sends E-DPDCH3 and E-DPDCH4
concurrently. The UE dynamically selects the SF and CC of the used E-DPDCH
according to the allowed number of E-DPDCHs configured at the network side and the
data to be transmitted by each TTI.
The relation between the number of E-DPDCHs and the SF size in the mentioned table is
as follows:
1. If there is no DPDCH and only one E-DPDCH, the CC of the E-DPDCH1 is:
When SF 4, use the CC of Cch,SF,SF/4;
When SF = 2, use the CC of Cch,2,1.
2. If there are one DPDCH and one E-DPDCHs, Cch,SF,SF/2 is used for E-DPDCH1.
3. If there are two E-DPDCHs:
When Nmax-dpdch = 0, E-DPDCH1 and E-DPDCH2 use the same CC, that is,
Cch,4,1 or Cch,2,1.

When Nmax-dpdch = 1, E-DPDCH1 and E-DPDCH2 use the same CC, that is,
Cch,4,2 or Cch,2,1.
4. If there are four E-DPDCHs, Nmax-dpdch can only be 0:
E-DPDCH1 and E-DPDCH2 use the same CC, that is, Cch,2,1.
E-DPDCH3 and E-DPDCH4 use the same CC, that is, Cch,4,1.
3.3.2.3 CC Allocation of Downlink E-AGCH
The UE needs to monitor the E-AGCH of the serving cell continually to obtain absolute
grant. A number of UEs can be supported by time division on one E-AGCH which is a
common downlink physical channel. The number of UEs supported by each E-AGCH is
limited.
The number of E-AGCHs is related to the number of UEs using HSUPA service and the
service type (burst traffic will consume E-AGCH frequently and the traffic of constant rate
seldom consume E-AGCH).
The initial E-AGCH code resources (specified by the parameter of NumofEagch) are
allocated on the HSUPA-capable cell established. The E-AGCH uses the downlink CCs
with the SF 256 for spreading the spectrum. When an HSUPA-capable cell is to be
established, a certain number (specified by the NumofEagch parameter) of downlink
CCs with the SF 256 are allocated to the E-AGCHs after the downlink common physical
channels of R99 and HSDPA are allocated. The downlink CCs are allocated from the
smallest SN of all the available downlink CCs.
The flowchart of the methods for E-AGCH allocation is described as follows.

Figure 3-6 Flowchart of the methods for E-AGCHs allocation

In the flowchart:
EagchUserNum stands for the sum of the number of scheduled E-DCH users in the
serving cell and ComUserNumEagch. If (ULEFACHSupport = 1: Supported) and
(DediComEAGCHSwi = 1: On), then ComUserNumEagch = min
(CommonEdchNum, UserNumPerEagch), otherwise, ComUserNumEagch = 0.
DediEagchNum stands for the number of dedicated E-AGCHs used currently.
3.3.2.3.1 Adjust the number of E-AGCHs by manual
If the static method is adopted, configure numofEagch equals to MaxEagchNum, and the
number of E-AGCHs is constant. Collect the statistics of average number of HSUPA UEs
and service types in the coverage area of the cell, estimate the number of required
E-AGCHs, and then reconfigure the parameters of NumofEagch and MaxEagchNum in
OMCR. If the average number of HSUPA UEs or service type in the coverage area of the
cell is changed, modify the number of E-AGCHs accordingly in the OMCR.
If an E-AGCH is to be added after the HSUPA-capable cell is established, it should be

next to the downlink physical channels for the cell. If the CC is occupied by an
emergence call, no E-AGCH is added until the call is released. Otherwise, the call is
dropped to release the CC for E-AGCH to use.
If the number of E-AGCHs is modified to be reduced, the CCs of E-AGCHs will be

released immediately from large SN to small SN even there are users on the E-AGCHs.
Note:
When the value of MaxEagchNum or numofEagch is modified,
If the modified value of numofEagch <= the number of E-AGCHs currently used <=
the modified value of MaxEagchNum, there is no need to adjust the code resource
for E-AGCHs.
If the modified value of numofEagch > the number of E-AGCHs currently used,
increase the number of E-AGCHs directly to the modified value of numofEagch. And
non-emergence call will drop. If the CC is occupied by an emergence call, wait until
the emergence call is released and then add the E-AGCH.

If the number of E-AGCHs currently used > the modified value of MaxEagchNum,
decrease the number of E-AGCHs immediately to the modified value of
MaxEagchNum and the call drop may be caused.
3.3.2.3.2 Adjust the number of E-AGCHs dynamically
If the dynamic method is adopted, configure numofEagch<MaxEagchNum and the

number of E-AGCHs will be adjusted ranging from numofEagch to MaxEagchNum
according to the number of HSUPA UEs. The method is as follows:
1. Compute the EagchUserNum in the E-AGCH code resource (which can bear the
dedicated HSUPA users) on the period (HsupaCtrChUptPrd). If UlEFACHSupport is
Supported and DediComEAGCHSwi is On, EagchUserNum is the sum of the
number of dedicated scheduled HSUPA users in the serving cell and
ComUserNumEagch which takes the value of min(CommonEdchNum,
UserNumPerEagch), otherwise, EagchUserNum is the number of dedicated
scheduled HSUPA users in the serving cell.
2. Decide whether to adjust the number of E-AGCH as follows.
If the following conditions are all satisfied, increase one E-AGCH.
The current number of E-AGCHs which can bear the dedicated HSUPA users
(DediEAGCHNum) is less than MaxEagchNum.
The value of EagchUserNum divided by DediEAGCHNum (EagchUserNum

/DediEAGCHNum) is greater than or equal to EagchUpThr.
EagchUserNum of the cell is less than EdchTrafLimit.
The value of DediEAGCHNum multiplying UserNumPerEagch (DediEAGCHNum *

UserNumPerEagch) is less than the sum of EdchTrafLimit and ComUserNumEagch
(EdchTrafLimit + ComUserNumEagch).
If the following conditions are all satisfied, decrease the E-AGCH which has the biggest
code number when there is no HSUPA user on.

The current number of E-AGCHs which can bear the dedicated HSUPA users
(DediEAGCHNum) is greater than NumofEagch.
The value of DediEAGCHNum divided by (DediEAGCHNum-1) is less than or equal

to EagchDnThr.
Note:
In the above description, the increased E-AGCHs can only be used by the
dedicated HSUPA users.
If the code resource to increase the E-AGCH(s) is used or blocked by DPCH, the
DPCH code resource will be reassigned to free the code. The steps of
re-assignment are the same as those described in 3.2.2.8 DPCH/F-DPCH
Re-Assign of HSDPA cell. If the code resource to increase the E-AGCH(s) is used
or blocked by F-DPCH or an emergency call, the re-assignment is not triggered and
no E-AGCH is added.
If the code resource to increase E-AGCH(s) is used or blocked by HS-PDSCH and

hsNBAssInd is Not Supported, and the number of HS-PDSCH is more than the
lower limit for the adjustment of HS-PDSCH number in 3.2.2.3 CC Allocation of
Downlink HS-PDSCH, the cell reduces the number of HS-PDSCHs; If the code
resource to increase E-AGCH(s) is used or blocked by HS-PDSCH and
hsNBAssInd is Supported, and the number of free SF16 is more than the lower
limit for the adjustment of HS-PDSCH number in 3.2.2.3, the cell reduces the
number of HS-PDSCHs; Otherwise, the cell keeps the number of E-AGCHs.
3.3.2.4 CC Allocation of Downlink E-RGCH/E-HICH
The UE needs to continually monitor the E-RGCH in serving and non-serving radio link
set to obtain relative grant and E-HICH to obtain the uplink E-DCH hybrid ARQ
acknowledgement indicator. The E-RGCH and E-HICH are dedicated downlink physical
channels and use the same CC that is differentiated through different signatures (40
signatures in total). Each UE in the E-DCH radio link set should be allocated an E-RGCH
and an E-HICH of different signatures. A maximum of 20 HSUPA UEs can be supported
on one E-RGCH/E-HICH.

The initial E-RGCH/E-HICH code resources (specified by the parameter of

NumofErgHich) are allocated on the HSUPA-capable cell established. The
E-RGCH/E-HICH uses the same downlink CC with the SF 128 for spreading the
spectrum. When an HSUPA-capable cell is to be established, a certain number of
downlink CCs with the SF 128 are allocated to the E-RGCH/E-HICHs after the downlink
common physical channels of R99, HSDPA and E-AGCHs allocated. The downlink CCs
are allocated from the smallest SN of all the available downlink CCs.
The flowchart of the methods for E-RGCH/E-HICHs allocation is described as follows:

Figure 3-7 Flowchart of the methods for E-RGCH/E-HICHs allocation

In the flowchart:
EdchUserNum stands for the total number of dedicated E-DCH users and the
common E-DCH users on the dedicated E-RGCH/E-HICHs
(DediComUserNumErghich) in the cell. DediComUserNumErghich stands for the
number of common E-DCH users on the E-RGCH/E-HICHs for dedicated E-DCH
users. If (ULEFACHSupport = 1: Supported) and (DediComEAGCHSwi = 1: On),
DediComUserNumErghich takes the value of CommonEdchNum, otherwise, it
takes the value of zero.
DediErghichNum stands for the number of E-RGCH/E-HICHs for dedicated E-DCH

users.
3.3.2.4.1 Adjust the number of E-RGCH/E-HICHs by manual
If the static method is adopted, configure NumofErgHich equals to maxERgHichNum and

the number of E-RGCH/E-HICHs is constant. Collect the statistics of average number of
HSUPA UEs in the coverage area of the cell, estimate the number of required
E-RGCH/E-HICHs, and then reconfigure the parameters of NumofErgHich and
maxERgHichNum in OMCR. If the average number of HSUPA UEs in the coverage area
of the cell or in the adjacent cells is changed, modify the number of E-RGCH/E-HICHs
accordingly in the OMCR.
If an E-RGCH/E-HICH is to be added after the HSUPA-capable cell is established, it

should be next to the downlink physical channels for the cell. If the CC is occupied by an
emergence call, no E-RGCH/EHICH is added until the call is released. Otherwise, the call is
dropped to release the CC for E-RGCH/E-HICH to use.
If the number of E-RGCH/E-HICHs is modified to be reduced, the CCs of

E-RGCH/E-HICHs will be released immediately from large SN to small SN even there
are users on the E-RGCH/E-HICHs.
When the value of maxERgHichNum or NumofErgHich is modified, the action is similar

to the Note in 3.3.2.3.1 Adjust the number of E-AGCHs by manual.

3.3.2.4.2 Adjust the number of E-RGCH/E-HICHs dynamically
If the dynamic method is adopted, configure NumofErgHich<maxERgHichNum and the

number of E-RGCH/E-HICHs will be adjusted ranging from NumofErgHich to
maxERgHichNum according to the number of HSUPA UEs.
The method is as follows:
1. Compute the sum of the number of dedicated scheduled HSUPA users

(EdchUserNum) and DediComUserNumErghich in the cell on the period
(HsupaCtrChUptPrd).
2. Decide whether to adjust the number of E-RGCH/E-HICH as follows.
If the following conditions are all satisfied, increase one E-RGCH/E-HICH.
The current number of E-RGCH/E-HICH which can bear the dedicated HSUPA
users (DediErghichNum) is less than maxERgHichNum;
The value that EdchUserNum is divided by DediErghichNum is greater than or

equal to ErgHichUpThr;
The value that DediErghichNum multiplies 20 is less than the sum of EdchTrafLimit
and DediComUserNumErghich.
If the following conditions are all satisfied, reduce the E-RGCH/E-HICH which has the
biggest code number.
The number of E-HICHs which can bear the dedicated HSUPA users
(DediErghichNum) is greater than NumofErgHich.
The value that EdchUserNum is divided by (DediErghichNum-1) is less than or

equal to ergHichDnThr.
Note:
In the above description, the increased E-RGCH/E-HICH can only be used by the
dedicated HSUPA user.

If the code resource of increased E-RGCH/E-HICH is used or blocked by DPCH,

the DPCH code resource is reassigned to free the code. The steps of re-assignment
are the same as those described in 3.2.2.8 DPCH/F-DPCH Re-Assign of HSDPA
cell. If the code resource of increased E-RGCH/E-HICH is used or blocked by
F-DPCH or an emergency call, the re-assignment is not triggered and no
E-RGCH/E-HICH is added.
If the code resource of increased E-RGCH/HICH is used or blocked by HS-PDSCH

and hsNBAssInd is Not Supported, and the number of HS-PDSCH is more than
the lower limit for the adjustment of HS-PDSCH number in 3.2.2.3 CC Allocation of
Downlink HS-PDSCH, the cell reduces the number of HS-PDSCH; If the code
resource of increased E-RGCH/HICH is used or blocked by HS-PDSCH and
hsNBAssInd is Supported, and the number of free SF16 is more than the lower
limit for the adjustment of HS-PDSCH number in 3.2.2.3, the cell reduces the
number of HS-PDSCH; Otherwise,the cell keeps the number of E-RGCH/E-HICH.
3.3.2.5 E-AGCH/E-RGCH/E-HICH number adjustment triggered by

E-AGCH/E-RGCH/E-HICH CC congestion
E-AGCH/E-RGCH/E-HICH CC congestion can cause the cell to adjust the number of

E-AGCH/E-RGCH/E-HICH.
1. HSUPA service is rejected because of the E-AGCH capacity limitation
If ECtrChCongIncSwh is 1 and the current number of E-AGCHs (DediEagchNum) which

can bear the dedicated HSUPA user is less than MaxEagchNum, and (DediEagchNum *
UserNumPerEagch) is less than (EdchTrafLimit + ComUserNumEagch), increases one
E-AGCH. Otherwise, keep the current number of E-AGCHs. ComUserNumEagch is

mentioned in 3.3.2.3 CC Allocation of Downlink E-AGCH. If the CC is occupied by an
emergence call, no E-AGCH is added until the call is released. Otherwise, the call is
dropped to release the CC for E-AGCH to use.
2. HSUPA service is rejected because of the E-RGCH/HICH capacity limitation
If ECtrChCongIncSwh is 1 and the number of E-RGCH/HICHs (DediErghichNum) which

can bear the dedicated HSUPA users is less than MaxErghichNum, and (DediErghichNum
* 20) is less than (EdchTrafLimit + DediComUserNumErghich), increases one E-RGCH/HICH.

Otherwise keep the current number of E-RGCH/E-HICH. DediComUserNumErghich is

mentioned in 3.3.2.4 CC Allocation of Downlink E-RGCH/E-HICH. If the CC is
occupied by an emergence call, no E-RGCH/E-HICH is added until the call is released.
Otherwise, the call is dropped to release the CC for E-RGCH/E-HICH to use.
3.4 Code Resource Allocation of Uplink Enhanced

CELL_FACH
3.4.1 SC Allocation
3.4.1.1 SC Allocation of Uplink PRACH
Uplink Enhanced CELL_FACH (i.e. common E-DCH) uses only the PRACH preamble,
and uses only one PRACH. The method is the same as described in 3.1.1.1 SC
Allocation of PRACH. Distinguish the R99 PRACH and common E-DCH according to the
PrachType in OMCR. PrachType is 0 means the information about the R99 PRACH.
PrachType is 1 means the information about the common E-DCH PRACH.
3.4.1.2 SC Allocation of Uplink DPCH
Every cell configures the number of resources CommonEdchNum in the OMCR. ZTE
RNC allocates the SC for every resource.
Set the primary scrambling code (PrimScraCode) of cell is n (n=0511). For the
resource configuration with index i, the SC of uplink DPCH is 8192+n*32+i.
3.4.1.3 SC Allocation of Downlink
The F-DCH/E-RGCH/E-HICH/E-AGCH use the same SC as the P-CPICH, and the SC of

other downlink physical channels are the same as 3.1/3.2/3.3.

3.4.2 CC Allocation
When an uplink enhanced Cell_FACH-capable cell is established and after the downlink
common physical channels of R99 /HSDPA/HSUPA are allocated, ZTE RNC allocates
the CC of downlink common physical channels for Common E-DCH in the order of
AICH/F-DPCH/E-AGCH/E-RGCH/HICH.
3.4.2.1 CC Allocation of Downlink AICH
There is one and only one AICH in the common E-DCH. If the AICH of common E-DCH
PRACH is used also by the R99 PRACH in the OMCR, then RNC allocates the AICH of
R99 PRACH to the common E-DCH, otherwise ZTE RNC allocates the downlink CC with
the smallest SN to the AICH of common E-DCH among all allocable CCs with the
required SF.
3.4.2.2 CC Allocation of Downlink F-DPCH
Every common E-DCH resource has the F-DPCH information. Ten resource
configurations can use the same F-DPCH channel code and distinguish using the soffset,
then the number of F-DPCH for Common E-DCH is ceil (CommonEDCHNum/10). The
F-DPCH fixedly uses the second TPC of every slot. ZTE RNC allocates the downlink CC
with the smallest SN to the F-DPCH of common E-DCH among all allocable CCs with the
required SF.
For the resource configuration with index i, set the channel code with the smallest SN
and free soffset from the above F-DPCHs as the F-DPCH channel code of resource
configuration i, then set the first free soffset of that F-DPCH as the soffset of resource
configuration i.
3.4.2.3 CC Allocation of Downlink E-AGCH.
Common E-DCH has one and only one E-AGCH. If DediComEAGCHSwi is OFF, ZTE
RNC allocates the downlink CC with the smallest SN to the E-AGCH of common E-DCH
among all allocable CCs with the required SF, otherwise, set the first E-AGCH of HSUPA
to be used by the common E-DCH.

3.4.2.4 CC Allocation of Downlink E-RGCH/HICH
Every common E-DCH resource has the E-RGCH/HICH information. E-RGCH and
E-HICH have the same channel code. Twenty resource configurations can use the same
E-RGCH/HICH channel code and distinguish using the signature sequence. So the
number of E-RGCH/HICH for Common E-DCH is ceil(CommonEDCHNum/20). ZTE
RNC allocates the downlink CC with the smallest SN to the E-RGCH/HICH of common
E-DCH among all allocable CCs with the required SF. For the resource configuration with
index i, set the E-RGCH/HICH with the smallest SN and two free signatures sequence
from the above E-RGCH/HICHs as the E-RGCH/HICH of resource configuration i, then
set the two free signatures sequence to resource configuration i.
3.4.2.5 CC Allocation of Uplink DPCH
The methods of CC allocation of uplink DPCCH, HS-DPCCH, E-DPCCH, E-DPDCH are

the same as described in 3.1/3.2/3.3.
3.5 Fast Dynamic Code Allocation
Dynamic CC allocation of HS-PDSCH by RNC is slow and cannot make use of free SF16
codes. If Node B controls the CC allocation, it can schedule the free and discrete SF16
codes to the HSDPA services. Node B can stop scheduling this code if RNC allocates it
to the DPCH service. In this case, HSDPA services will have good performance. The
parameter HsNBAssInd controls the function.
If HsNBAssInd is Not Supported and the value of enableDynCode on Node B side is

No, RNC controls the allocation of HS-PDSCH in this cell. It is referred in 3.2.2.3 CC
Allocation of Downlink HS-PDSCH.
If HsNBAssInd is Supported and the value of enableDynCode on Node B side is Yes,

Node B can provide HSDPA service by dynamically using the free CCs among the
maximum HS-PDSCH CCs allocated by RNC.
Note:
If HsSharMethod is Not Sharing, the value of maximum HS-PDSCH CCs is

MaxHspdschNum, otherwise the maximum value is calculated according to 3.6 Code

Sharing between Cells
3.6 Code Sharing between Cells
The Co-NodeB Cells HS-PDSCHs Sharing Function shares HS-PDSCH channels

among several cells belonging to the same Node B, which makes good use of the Node
B hardware resources and reduces the CAPEX. ZTE RNC controls this function by
configuring the parameter HsSharMethod.
For the cells supporting both R99 and HSDPA services, the parameter HsShareInd
controls whether to share its HS-PDSCH channels with the other Co-NodeB cells. The
sum of MaxHspdschNum of all Co-NodeB cells, which is set to share the HS-PDSCH
channels, is the total number of HS-PDSCH channels (TotalHspdschNum) shared
among these cells.
ZTE RNC periodically (The period is configured by the parameter HsSharUptPrd) or

when Co-NodeB cells have changed, calculates the maximum HS-PDSCH channel
number for each of the cells sharing their HS-PDSCH channels according to the
following steps:
1. According to Formula 4, calculate the sum of minimum HS-PDSCH number

(MinNumofHspdsch) of each cell from the OMCR and gets HsNum by taking the
sum off the TotalHspdschNum.
2. Allocate the HS-PDSCH number for each cell according to the ratio of the sum of
GBR and NBR of all HSDPA services in each cell. And take the sum of this number
and the minimum HS-PDSCH number for each cell as the temporary maximum
HS-PDSCH number for each cell.
3. For each cell, take the smaller one between the temporary maximum HS-PDSCH
number of the last step and the result of Formula 3 as the maximum HS-PDSCH
number.
4. If there are still some free HS-PDSCH codes after getting the maximum HS-PDSCH
number of each cell in the step (1), (2) and (3), those codes are to be allocated as

follows. Assuming that the number of HS-PDSCH codes, not assigned yet, is A, and
the number of Co-NodeB cells sharing HS-PDSCHs is N. Set B=floor(A/N), C=A
mod N. For the first Cth cells which are the largest in the sum of GBR of all HSDPA
services, the maximum HS-PDSCH number increases B+1. For the others, the
maximum HS-PDSCH number increases B.
4 Parameters and Configurations
4.1 Parameters Related to R99 Code Resource

Allocation
4.1.1 Parameter List
4.1.1.1 SC/CC-Related Parameter Configuration for Uplink Physical Channel

No. Abbreviated Name Parameter Name
1 ModuleSeq Module No.
2 RcpScrStartId Starting No. of CMP Scrambling Code
3 RcpScrEndId Ending No. of CMP Scrambling Code
4 PreamScraCode PRACH Preamble Scrambling Code
5 Signature Available Signature
4.1.1.2 SC/CC-Related Parameter Configuration for Uplink Physical Channel

1 primaryScramblingCode Cell Primary Scrambling Code
4.1.2 Parameter Configurations
4.1.2.1 Module No.
OMC path

GUI: Managed Element->Equipment->Rack->Shelf->Board->Module No.
Parameter configuration
The parameter specifies the CMP module number on which the cell is established.
4.1.2.2 Starting No. of CMP Scrambling Code
OMC path
GUI: Managed Element->Equipment->Module->Starting No. of CMP Scrambling

Code
The parameter indicates the starting SC number of the CMP DPCH (40960 by
default).
It is required to determine the number of SCs to be allocated to each CMP

according to the capability of the CMP. Accordingly, configure two parameters in the
OMCR: Starting No. of CMP Scrambling Code and Ending No. of CMP Scrambling
Code.
4.1.2.3 Ending No. of CMP Scrambling Code
OMC path
GUI: Managed Element->Equipment->Module->Ending No. of CMP Scrambling

Code
The parameter indicates the ending SC number of the CMP DPCH.
It is required to determine the number of SCs to be allocated to each CMP

according to the capability of the CMP. Accordingly, configure two parameters in the
OMCR: Starting No. of CMP Scrambling Code and Ending No. of CMP Scrambling
Code.

4.1.2.4 PRACH Preamble Scrambling Code
OMC path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN

Cell->Channel Configuration->AICH Configuration->PRACH
Configuration->PRACH Preamble Scrambling Code
The parameter indicates the number of the preamble SC used by each PRACH in
the cell (the default is 0, and the maximum is 15).
The parameter value is incremented by 1 every time one PRACH is added.
4.1.2.5 Available Signature
OMC path

Cell->Channel Configuration->AICH Configuration->PRACH
Configuration->Available Signature
The parameter indicates a valid signature used for an accessing PRACH. Bit=1
means the corresponding signature is valid. By default, every bit is equal to 1.
4.1.2.6 Cell Primary Scrambling Code
OMC path

Cell->Cell Primary Scrambling Code
This parameter is the primary SC of the cell. It is used to differentiate cells.

4.2 Parameters Related to HSDPA Code Resource

Allocation
4.2.1.1 Parameter Configuration for HSDPA CC Allocation

1 NumofHspdsch Number Of HS-PDSCH
2 MinNumofHspdsch Minimum Number Of HS-PDSCH
3 MaxNumofHspdsch Maximum Number Of HS-PDSCH
4 NumofHsscch Number Of HS-SCCH
5 DpchCodeHy SF512 Number to Increase HS-PDSCH Number
6 CodeUptHyA SF512 Number to Decrease HS-PDSCH Number
7 HspdschBitRate HS-PDSCH Bit Rate
8 CodeUptPrds Code Update Period(second)
9 codeUptPrdms Code Update Period(millisecond)
10 CodeUptPrdUnit Code Update Period Unit
11 Number of the Codes with SF =128 Ordered for

OCNSCodeNumber
OCNS
12 OCNSCode Code Node Number with SF =128 for OCNS
13 CodeReAssInd DPCH Code Re-Assign Support Indicator
14 CodeReAssPrd DPCH Code Re-Assign Period
15 Switch for DRNC Code Re-Assignment Radio Link

IurCdReAssDrop
Release
16 hsVsR99CdPriInd HSDPA Vs R99 Code Priority Indicator
17 hsMRRUSchInd M-RRU Sector Schedule Indicator
18 MRRU456NotComInd M-RRU 456 not combine Indicator

4.2.2.1 Number of HS-PDSCH
OMC path

Cell->Hspa Configuration In A Cell->Number of HS-PDSCH
When the HS-PDSCH number is smaller than the parameter, the HS-PDSCH
number can be adjusted to the parameter value directly if the criterion to increase
the HS-PDSCH number is satisfied.
If hsVsR99CdPriInd is set to "Supported" and HS-PDSCH number is smaller than or

equal to the threshold for code fairness, HSDPA service is of higher priority to use
the code resource relative to R99 service. Otherwise, R99 service is of higher
priority.
4.2.2.2 Minimum Number of HS-PDSCH
OMC path

Cell->Hspa Configuration In A Cell->Minimum Number of HS-PDSCH
This parameter indicates the minimum number of the HS-PDSCHs configured in the
cell. The parameter value is smaller than or equal to the number of initial
HS-PDSCHs, as well as the maximum number of HS-PDSCHs.
If the parameter is set to a larger value, the allowed minimum number of

HS-PDSCHs in the cell is increased.
By default, the parameter value is 1, which cannot be further decreased.

4.2.2.3 Maximum Number of HS-PDSCH
OMC path

Cell->Hspa Configuration In A Cell->Maximum Number of HS-PDSCH
The parameter indicates the allowed maximum number of HS-PDSCHs in the cell.
If the parameter is set to a smaller value, the allowed maximum number of

HS-PDSCHs in the cell is decreased.
By default, the parameter value is 15, which cannot be further increased.
4.2.2.4 Number of HS-SCCH
OMC path

Cell->Hspa Configuration In A Cell->Number of HS-SCCH
The parameter indicates the number of HS-SCCHs configured in the cell. In a

timeslot, usually, one HS-SCCH indicates the HS-related information of a HSDPA
UE.
If the cell supports both R99 and HSDPA, the parameter is set to 2.
If the cell supports HSDPA only, the parameter is set to 3.
4.2.2.5 SF512 Number to Increase HS-PDSCH Number
OMC path


Cell->Hspa Configuration In A Cell->SF512 Number to Increase HS-PDSCH
Number
The parameter is used to reserve a certain number of code resources for the DPCH.
The HS-PDSCH codes are dynamically adjusted according the restriction of this
parameter.
If the parameter is set to a larger value, more code resources are reserved for the
DPCH.
If the parameter is set to a smaller value, fewer code resources are reserved for the
DPCH.
4.2.2.6 SF512 Number to Decrease HS-PDSCH Number
OMC path

Cell->Hspa Configuration In A Cell->SF512 Number to Decrease HS-PDSCH
Number
The parameter indicates that the expected value is restricted by this parameter
while the number of HS-PDSCHs is decreased. It means the code Hysteresis of the
HS-PDSCHs.
If the parameter is set to a larger value, the minimum DPCH code, which can be
used by the system, will increase.
If the parameter is set to a smaller value, the minimum DPCH code, which can be
used by the system, will decrease.

4.2.2.7 HS-PDSCH Bit Rate
OMC path

Cell->Hspa Configuration In A Cell->HS-PDSCH Bit Rate
The parameter indicates the average data rate of each HS-PDSCH. It is used to
calculate the maximum number of HS-PDSCHs required by the current service and
the minimum number of HS-PDSCHs required by the GBR of the current HS
service.
If the parameter is set to a larger value, the same rate requires fewer HS-PDSCHs.
If the parameter is set to a smaller value, the same rate requires more HS-PDSCHs.
4.2.2.8 Code Update Period(millisecond)
OMC path
GUI: Managed Element ->UMTS Logical Function Configuration->Service

Configuration->Hspa Configuration->Code Update Period(millisecond)
This parameter indicates the judgment period (in the unit of ms) of the adjustment of
the number of HS-PDSCHs triggered by the code occupation ratio. It needs to be
used together with the unit of judgment period. It is used for periodical dynamic
code adjustment.
If the parameter is set to a larger value, the judgment period of HS-PDSCH code
adjustment becomes longer.
If the parameter is set to a smaller value, the judgment period of HS-PDSCH code
adjustment becomes shorter.

4.2.2.9 Code Update Period (second)
OMC path

Configuration->Hspa Configuration->Code Update Period(second)
This parameter indicates the judgment period (in the unit s) of the adjustment of the
number of HS-PDSCHs triggered by the code occupation ratio. It needs to be used
together with the unit of judgment period. It is used for periodical dynamic code
adjustment.
If the parameter is set to a larger value, the judgment period of HS-PDSCH code
adjustment becomes longer.
If the parameter is set to a smaller value, the judgment period of HS-PDSCH code
adjustment becomes shorter.
4.2.2.10 Code Update Period Unit
OMC path

Configuration->Hspa Configuration->Code Update Period Unit
The parameter indicates the unit of judgment period of the adjustment of the number of
HS-PDSCHs triggered by the code occupation ratio. It can be either s or ms.
4.2.2.11 Number of the Codes with SF =128 Ordered for OCNS
OMCR path

Cell->Number of the Codes with SF =128 Ordered for OCNS

This parameter indicates that the reserved total number of SF=128 for OCNS.
If the parameter is set to a larger value, the reserved total number will increase;
If the parameter is set to a smaller value, the reserved total number will decrease.
4.2.2.12 Code Node Number with SF =128 for OCNS
OMCR path

Cell->Code Node Number with SF =128 for OCNS
The parameter indicates that code number of SF=128 for OCNS.
4.2.2.13 DPCH Code Re-Assign Support Indicator
OMCR path

Configuration->Hspa Configuration->DPCH Code Re-Assign Support Indicator
The parameter indicates whether the system supports DPCH code re-assign when
needed.
4.2.2.14 DPCH Code Re-Assign Period
OMCR path

Configuration->Hspa Configuration->DPCH Code Re-Assign Period

The parameter indicates the period of HS-PDSCH re-assignment. For each period,
the system will judge whether to do the DPCH code re-assignment or not.
4.2.2.15 Switch for DRNC Code Re-Assignment Radio Link Release
OMCR path

Cell->Hspa Configuration In A Cell->Switch for DRNC Code Re-Assignment Radio
Link Release
The parameter indicates the actions in the code re-assignment when ZTE RNC
works as DRNC. If the parameter is set to On, ZTE RNC sends Radio Link Failure
message to SRNC, and releases the radio link and channelization code of the
services. If parameter is set to Off, ZTE RNC does not re-assign the
channelization code of the services.
4.2.2.16 HSDPA Vs R99 Code Priority Indicator
OMCR path

Cell->Hspa Configuration In A Cell->HSDPA Vs R99 Code Priority Indicator
This parameter indicates whether to judge the priority of HSDPA and R99 services
in code resource allocation. If this parameter is set to "Supported" and the number
of HS-PDSCH code used is smaller than the threshold for code allocation fairness,
HSDPA service is given high priority to use the code resource compared with R99
service.
4.2.2.17 M-RRU Sector-based Scheduling Indicator
OMCB path

GUI: Manage Network Element-> Radio Parameters ->UMTS->MRRU sector-based

Scheduling Switch
This parameter specifies whether Node B supports M-RRU sector-based scheduling

function.
4.2.2.18 M-RRU 456 Non-combination Indicator
OMCB path
GUI: Manage Network Element-> Radio Parameter ->UMTS-> High-efficiency MRRU

456 switch
This parameter specifies whether Node B supports high-efficiency MRRU 456 function.
4.3 Parameters Related to HSUPA Code Resource

Allocation
4.3.1.1 Parameter Configuration for HSUPA CC Allocation

1 NumofEagch Number Of E-AGCH
2 NumofErgHich Number Of E-RGCH/ E-HICH
3 User Number Threshold to Decrease E-AGCH

EAgchDnThr
Number
4 EAgchUpThr User Number Threshold to Increase E-AGCH Number
5 User Number Threshold to Decrease E-RGCH/HICH

ERgHichDnThr
Number
6 User Number Threshold to Increase E-RGCH/HICH

ERgHichUpThr
Number

7 Maximum E-AGCH Number for Dedicated E-DCH

MaxEAgchNum
Users
8 Maximum E-RGCH/HICH Number for Dedicated

MaxERgHichNum
E-DCH Users
9 Maximal Scheduled E-DCH User Number in

UserNumPerEagch
CELL_DCH state Scheduled Per E-AGCH
10 HsupaCtrChUptPrd HSUPA Control Channel Number Update Period(s)
11 Switch to Increase the HSUPA Control Channel

ECtrChCongIncSwh
Number by Congestion
4.3.2.1 Number of E-AGCH
OMCR path

Cell->Hspa Configuration In A Cell->Number of E-AGCH
This parameter indicates the number of the allocated initial E-AGCHs in the cell.
If the parameter is set to a larger value, more E-AGCHs are allocated to the cell.
If the parameter is set to a smaller value, fewer E-AGCHs are allocated to the cell.
4.3.2.2 Number of E-RGCH/E-HICH
OMCR path

Cell->Hspa Configuration In A Cell->Number of E-RGCH/E-HICH

This parameter indicates the number of the allocated initial E-RGCHs/E-HICHs in

the cell.
If the parameter is set to a larger value, more E-RGCHs/E-HICHs are allocated to

the cell.
If the parameter is set to a smaller value, fewer E-RGCHs/E-HICHs are allocated to

the cell.
4.3.2.3 User Number Threshold to Decrease E-AGCH Number
OMCR path

Cell->Hspa Configuration In A Cell->User Number Threshold to Decrease E-AGCH
Number
This parameter indicates the threshold for decreasing the E-AGCH number. The
E-AGCH number could be decreased, if the result of HSUPA scheduled user
number, which takes the cell as the serving cell divided by the current E-AGCH
number minus 1, is less than or equal to the threshold.
4.3.2.4 User Number Threshold to Increase E-AGCH Number
OMCR path

Cell->Hspa Configuration In A Cell->User Number Threshold to Increase E-AGCH
Number
This parameter indicates the threshold to increase the E-AGCH number. The
E-AGCH number could be increased, if the average number of scheduled users of
each E-AGCH is larger than or equal to the threshold.

4.3.2.5 User Number Threshold to Decrease E-RGCH/HICH Number
OMCR path

Cell->Hspa Configuration In A Cell->User Number Threshold to Decrease
E-RGCH/HICH Number
This parameter indicates the threshold to decrease the E-RGCH/HICH umber. The
E-RGCH/HICH number could be decreased, if the result of total HSUPA user
number divided by the current E-RGCH/HICH number minus 1, is less than or equal
to the threshold.
4.3.2.6 User Number Threshold to Increase E-RGCH/HICH Number
OMCR path

Cell->Hspa Configuration In A Cell->User Number Threshold to Increase
E-RGCH/HICH Number
The number of E-RGCH/HICHs could be increased, if the average number of users

of each E-RGCH/HICH is larger than or equal to the threshold.
4.3.2.7 Maximum E-AGCH Number for Dedicated E-DCH Users
OMCR path

Cell->Hspa Configuration In A Cell->Maximum E-AGCH Number for Dedicated
E-DCH Users
This parameter indicates the cell maximum number of the E-AGCH. Usually, the
parameter could take the value of the license HSUPA user number divided by
UserNumPerEagch. But it could be reduced if there is a lot of DPCH code

congestion.
4.3.2.8 Maximum E-RGCH/HICH Number for Dedicated E-DCH Users
OMCR path

Cell->Hspa Configuration In A Cell->Maximum E-RGCH/HICH Number for
Dedicated E-DCH Users
This parameter indicates the cell maximum number of the E-RGCH/HICH. Usually,
the parameter could take the value of the license HSUPA user number divided by
20. But it could be reduced if there is a lot of DPCH code congestion.
4.3.2.9 Maximal Scheduled E-DCH User Number in CELL_DCH state Scheduled

Per E-AGCH
OMCR path

Cell->Hspa Configuration In A Cell->Maximal Scheduled E-DCH User Number in
CELL_DCH state Scheduled Per E-AGCH
This parameter indicates the Maximal Scheduled E-DCH User Number in

CELL_DCH state that can be scheduled Per E-AGCH. The larger of the value, the
more E-DCH User can be carried on one E-AGCH, but overabundance of E-DCH
User per E-AGCH may lead bad E-DCH QoS. The less of the value, the less
E-DCH User can be carried on one E-AGCH, and the better E-DCH QoS can be
got.
4.3.2.10 Switch to Increase the HSUPA Control Channel Number by Congestion
OMCR path


Cell->Hspa Configuration In A Cell->Switch to Increase the HSUPA Control
Channel Number by Congestion
This parameter indicates whether to increase the E-AGCH or E-RGCH/HICH

number when HSUPA service is rejected because of the E-AGCH or
E-RGCH/HICH capacity limitation.
If this switch is ON, the cell increases one E-AGCH or E-RGCH/E-HICH when
HSUPA service is rejected because of the E-AGCH or E-RGCH/E-HICH capacity
limitation, otherwise, the cell keeps the number of E-AGCH or E-RGCH/E-HICH.
4.3.2.11 HSUPA Control Channel Number Update Period(s)
OMCR path

Configuration->Hspa Configuration->HSUPA Control Channel Number Update
Period
The parameter indicates the period to judge whether to adjust the E-AGCH and
E-RGCH/E-HICH number.
If it is too long, the E-AGCH and E-RGCH/E-HICH number cannot be adjusted in

time. If it is too short, frequent E-AGCH and E-RGCH/E-HICH number adjustment
will take too much system resource such as CPU.

4.4 Parameters Related to Uplink Enhanced

CELL_FACH Code Resource Allocation
4.4.1.1 Parameter Configuration for Uplink Enhanced CELL_FACH CC Allocation

1 CommonEdchNum Common E-DCH Resources Number
2 PrachType Type of PRACH Preamble
3 E-AGCH Multiplexing Switch in Dedicated and

DediComEAGCHSwi
Common E-DCH
4.4.2.1 Common E-DCH Resources Number
OMCR path

Cell->EFACH Configuration->Common E-DCH Resources Number
This parameter indicates the number of common E-DCH resources in uplink

enhanced CELL_FACH state.
The larger this parameter is, more common E-DCH users can transmit data at the
same time, but more system resources will be used.
The smaller this parameter is, less common E-DCH users can transmit data at the
same time, but less system resources will be used.

4.4.2.2 Type of PRACH Preamble
OMCR path

Cell->Channel Configuration->AICH Configuration->PRACH Configuration->Type
of PRACH Preamble
This parameter indicates the related parameters of PRACH are used for R99
PRACH or common E-DCH, and is used to index the information of
Random-access in R99 and Common E-DCH.
4.4.2.3 E-AGCH Multiplexing Switch in Dedicated and Common E-DCH
OMCR path

Cell->Hspa Configuration In A Cell->E-AGCH Multiplexing Switch in Dedicated and
Common E-DCH
This parameter is the E-AGCH multiplexing switch in dedicated E-DCH and

common E-DCH.
When this parameter is set to OFF, UEs in dedicated E-DCH use different channel
codes from those in the common E-DCH.
When this parameter is set to ON, UEs in dedicated E-DCH can use the same
channel code of E-AGCH as those in the common E-DCH, which will save one
channelization code resource of SF256, but the waiting time of E-AGCH information
in Collision resolution of Common E-DCH phase may be longer than the Maximum
period for collision resolution phase, which will make the UE release the resources.

4.5 Parameters Related to Fast Dynamic Code

Allocation

1 HS-PDSCH Code NodeB Assignment Support

HsNBAssInd
Indicator
2 enableDynCode Dynamic code allocation supported
4.5.2.1 HS-PDSCH Code NodeB Assignment Support Indicator
OMCR path

Cell->Hspa Configuration In A Cell->HS-PDSCH Code NodeB Assignment Support
Indicator
The parameter indicates whether the system supports the assignment of

HS-PDSCH code in Node B when needed.
4.5.2.2 Dynamic code allocation supported
OMCB path
GUI: Manage Network Element -> Radio Parameter ->UMTS->UMTS Sector-> Local
Cell-> Dynamic code allocation supported
This parameter specifies whether Node B supports the function of dynamic allocation of
HS-PDSCH codes in local cell.

4.6 Parameters Related to Code Sharing between Cells

1 HsSharMethod Co-NodeB HS-PDSCH Code Sharing Method
2 HsShareInd Co-NodeB HS-PDSCH Code Sharing Indicator
3 HsSharUptPrd Co-NodeB HS-PDSCH Code Sharing Update Period
4.6.2.1 Co-NodeB HS-PDSCH Code Sharing Method
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->Iub Link

Configuration->Co-NodeB HS-PDSCH Code Sharing Method
The parameter indicates whether the Node B office supports HS-PDSCH Code
sharing with the cells in the same Node B.
4.6.2.2 Co-NodeB HS-PDSCH Code Sharing Indicator
OMCR path

Cell->Hspa Configuration In A Cell->Co-NodeB HS-PDSCH Code Sharing Indicator
The parameter indicates whether the cell supports HS-PDSCH Code sharing with
the other cells in the same Node B.

4.6.2.3 Co-NodeB HS-PDSCH Code Sharing Update Period
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->Iub Link

Configuration->Co-NodeB HS-PDSCH Code Sharing Update Period
The parameter indicates that the period of RNC updates the total number of sharing
HS-PDSCH code.
5 Counter List
Counter No. Description
C310424227 Current available ratio of code resource
C310424228 Maximum available ratio of code resource
C310426478 Minimum available ratio of code resource
C310424230 Sum available ratio of code resource
C310424231 Statistics times of code resource
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
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

C310426485 Minimum Number of Code Node Free, SF=16
C310424248 Summation Number of Code Node Free, SF=16

C310424282 Times of 0 Code Node Used,SF=256
C310424283 Times of Code Node Used between 1 to 8, SF=256;




C310434424 Sum of HS-PDSCH code nodes
C310434425 Statistics times of HS-PDSCH code node
C310434426 Current number of HS-PDSCH code nodes used
C310434427 Max number of HS-PDSCH code nodes used
C310436502 Min number of HS-PDSCH code nodes used
C310434429 Sum of HS-SCCH code nodes
C310434430 Current number of HS-SCCH code nodes used
C310434431 Max number of HS-SCCH code nodes used
C310436504 Min number of HS-SCCH code nodes used
C310435946 Current occupation ratio of HSDPA code resource
C310434433 Maximum occupation ratio of HSDPA code resource
C310436506 Minimum occupation ratio of HSDPA code resource
Dpch Code Reassign Number of SF8 due to Periodic Code

C311785723
Re-assignment


C311785724
Re-assignment

C311785725
Re-assignment

C311785726
Re-assignment

C311785727
Re-assignment

C311785728
Re-assignment
Number of UE in F-DPCH Code Reassign due to Periodic Code

C311786820
Re-assignment
Number of DPCH /F-DPCH Code Reassign Failure due to

C311785738
Periodic Code Re-assignment
Number of Releasing SF8 Dpch due to Periodic Code

C311786821
Re-assignment

C311786822
Re-assignment

C311786823
Re-assignment

C311786824
Re-assignment

C311786825
Re-assignment

C311786826
Re-assignment
Number of UE to Release F-DPCH due to Periodic Code

C311786827
Re-assignment
Number of downgraded R99 service caused by HSDPA of Higher

C311775712
Code Priority
6 Glossary
HSDPA: High Speed Downlink Packet Access
HSUPA: High Speed Uplink Packet Access

MBMS: Multimedia Broadcast Multicast Service
HS-DPCCH: High Speed - Dedicated Physical Control Channel
HS-SCCH: High Speed - Synchronization Control Channel
HS-PDSCH: High Speed - Physical Downlink Shared Channel
E-DPCCH: E-DCH Dedicated Physical Control Channel
E-DPDCH: E-DCH Dedicated Physical Data Control Channel
E-AGCH: E-DCH Absolute Grant Channel
E-RGCH: E-DCH Relative Grant Channel
E-HICH: E-DCH HARQ Acknowledgement Indicator Channel
MICH: MBMS Indicator Channel
P-T-P: Point-to-Point
P-T-M: Point-to-Multipoint
ASC: Access Service Class
CMP: Control plane public Main Processor

ZTE UMTS Code Resource Allocation Feature Guide - V8 5 - 201312 - 548008

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ZTE UMTS Code Resource Allocation Feature Guide - V8 5 - 201312 - 548008

Uploaded by

Copyright:

Available Formats

Code Resource Allocation

Code Resource Allocation Feature Guide

1. Updated 3.2.2.6 DPCH/F-DPCH

4. Updated the fairness of R99 DCH and

5. Deleted ZTE Node B does not support

6. Updated Fairness of R99 DCH and

1. Updated 3.2.2.9 Fairness of R99 DCH

2. Added notes for Parameters of

ZTE Confidential Proprietary 1

1. Added Feature ID.

2013 ZTE Corporation. All rights reserved.

ZTE Confidential Proprietary 2

3 Technical Descriptions ................................................................................... 12

4 Parameters and Configurations ..................................................................... 52

ZTE Confidential Proprietary 3

4.4 Parameters Related to Uplink Enhanced CELL_FACH Code Resource

5 Counter List ..................................................................................................... 73

ZTE Confidential Proprietary 4

Figure 2-1 Spreading and Scrambling ................................................................................. 7

ZTE Confidential Proprietary 5

Attribute: [Mandatory + Optional]

Mutual exclusion: [None]

ZTE Confidential Proprietary 6

Figure 2-1 Spreading and Scrambling

ZTE Confidential Proprietary 7

Figure 2-2 Allocation of Downlink CCs

Code resource management covers the following aspects:

R99-related code resource management, including:

SC and CC allocation of uplink physical channel, including Physical Random

SC and CC allocation of downlink physical channel, including downlink common

HSDPA related code resource management includes SC and CC allocation of

HSUPA related code resource management includes SC and CC allocation of uplink

ZTE Confidential Proprietary 8

2.1 ZWF21-04-006 Code Resource Allocation

2.1.1 R99 Code Resource Allocation

2.1.2 HSDPA Code Resource Allocation

ZTE Confidential Proprietary 9

Supports the manually configuring of the number of HS-PDSCH/HS-SCCH CCs in

Supports the reallocation of HS-PDSCCH/HS-SCCH CCs (increase or decrease

1. Fast prediction and adjustment mode;

2. Allocating HS-PDSCHs and total power dynamically according to the congestion

2.1.3 HSUPA Code Resource Allocation

ZTE Confidential Proprietary 10

2.1.4 Uplink Enhanced CELL_FACH Code Resource Allocation

2.2 ZWF23-04-020 Fast Dynamic Code Allocation

2.3 ZWF23-04-021 Code Sharing between Cells

ZTE Confidential Proprietary 11

3.1 R99 Code Resource Allocation

3.1.1 SC Allocation of Uplink Physical Channel

3.1.1.1 SC Allocation of PRACH

A PRACH preamble is generated by a preamble SC and a signature:

A PRACH preamble SC is generated by the long SC sequence:

Sr-pre,n(i) = clong,1,n(i), i = 0, 1, , 4,095; n =0, 1,2,, 8,191;

ZTE Confidential Proprietary 12

Signature of PRACH preamble

Csig,s(i) = Ps(i modulo 16), i = 0, 1, , 4095.

ZTE Confidential Proprietary 13

The following figure illustrates the above two cases respectively.

Figure 3-1 Configuration Example of Cell PRACH

RACH RACH 0 RACH 1 RACH 2 RACH 3

SC of the PRACH message part

Sr-msg,n(i) = Clong,n(i + 4096), i = 0, 1, , 38,399

3.1.1.2 SC Allocation of DPCH

8J16 + K*16 J=0,,63 K=0,,7