Академический Документы
Профессиональный Документы
Культура Документы
Feature Guide
WCDMA RAN
Code Resource Allocation Feature Guide
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
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.
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
6 Glossary ........................................................................................................... 80
FIGURES
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]
Involved NEs:
UE Node B RNC MSCS MGW SGSN GGSN HLR
- - - - -
Note:
-: Not involved.
: Involved.
Dependency: [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.
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.
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 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.
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:
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:
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.
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.
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.
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.
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
Preamble of PRACH
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
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.
The preamble signature is constituted by the 16-bit Ps(n)( n=015) code for 256
times:
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.
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)
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:
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.
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:
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.
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.
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.
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.
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.
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.
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:
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 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.
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.
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
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.
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%).
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.
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
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 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.
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.
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.1 SC Allocation
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.
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.
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
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.
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).
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.
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
If Formula 2 is observed:
DpchCodeHy refers to the number of the SF512 codes reserved for the
DPCHs.
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).
OcuRateHspdsch If deltaP>=DpchCodeHy+32,
increase the HS-PDSCH
number
DpchCodeHy
deltaP
Max Code Usage
512
OcuRateNoHspdsch
OcuRateHspdsch
If deltaP<CodeUptHyA,
decrease the HS-PDSCH number
deltaP
CodeUptHyA
Max Code Usage
(512)
OcuRateNoHspdsch
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.
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.
During dynamic adjustment of the number of HS-PDSCHs, ZTE RNC restricts the
number of HS-PDSCHs between the minimum value (MinNumofHspdsch) and
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.
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.
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.
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.
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,
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.
Restrictions:
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.
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.
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.
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
If the code resource of threshold for code fairness is used by non HSDPA service, 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.
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.
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.1 SC Allocation
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
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.
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:
2. If there are one DPDCH and one E-DPDCHs, Cch,SF,SF/2 is used for E-DPDCH1.
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.
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.
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.
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.
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.
Note:
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.
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.
The current number of E-AGCHs which can bear the dedicated HSUPA users
(DediEAGCHNum) is less than MaxEagchNum.
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.
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.
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.
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.
The current number of E-RGCH/E-HICH which can bear the dedicated HSUPA
users (DediErghichNum) is less than maxERgHichNum;
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.
Note:
In the above description, the increased E-RGCH/E-HICH can only be used by the
dedicated HSUPA user.
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.
3.4.1 SC Allocation
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.
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.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.
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.
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.
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.
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.
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.
Note:
If HsSharMethod is Not Sharing, the value of maximum HS-PDSCH CCs is
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.
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.
OMC path
Parameter configuration
The parameter specifies the CMP module number on which the cell is established.
OMC path
Parameter configuration
The parameter indicates the starting SC number of the CMP DPCH (40960 by
default).
OMC path
Parameter configuration
OMC path
Parameter configuration
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).
OMC path
Parameter configuration
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.
OMC path
OMC path
Parameter configuration
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.
OMC path
Parameter configuration
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.
OMC path
Parameter configuration
The parameter indicates the allowed maximum number of HS-PDSCHs in the cell.
OMC path
Parameter configuration
If the cell supports both R99 and HSDPA, the parameter is set to 2.
OMC path
Parameter configuration
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.
OMC path
Parameter configuration
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.
OMC path
Parameter configuration
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.
OMC path
Parameter configuration
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.
OMC path
Parameter configuration
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.
OMC path
Parameter configuration
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.
OMCR path
Parameter configuration
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.
OMCR path
Parameter configuration
OMCR path
Parameter configuration
The parameter indicates whether the system supports DPCH code re-assign when
needed.
OMCR path
Parameter configuration
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.
OMCR path
Parameter configuration
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.
OMCR path
Parameter configuration
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.
OMCB path
Parameter configuration
OMCB path
Parameter configuration
This parameter specifies whether Node B supports high-efficiency MRRU 456 function.
OMCR path
Parameter configuration
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.
OMCR path
Parameter configuration
OMCR path
Parameter configuration
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.
OMCR path
Parameter configuration
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.
OMCR path
Parameter configuration
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.
OMCR path
Parameter configuration
OMCR path
Parameter configuration
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.
OMCR path
Parameter configuration
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.
OMCR path
Parameter configuration
OMCR path
Parameter configuration
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.
OMCR path
Parameter configuration
The parameter indicates the period to judge whether to adjust the E-AGCH and
E-RGCH/E-HICH number.
OMCR path
Parameter configuration
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.
OMCR path
Parameter configuration
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.
OMCR path
Parameter configuration
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.
OMCR path
Parameter configuration
OMCB path
GUI: Manage Network Element -> Radio Parameter ->UMTS->UMTS Sector-> Local
Cell-> Dynamic code allocation supported
Parameter configuration
This parameter specifies whether Node B supports the function of dynamic allocation of
HS-PDSCH codes in local cell.
OMCR path
Parameter configuration
The parameter indicates whether the Node B office supports HS-PDSCH Code
sharing with the cells in the same Node B.
OMCR path
Parameter configuration
The parameter indicates whether the cell supports HS-PDSCH Code sharing with
the other cells in the same Node B.
OMCR path
Parameter configuration
The parameter indicates that the period of RNC updates the total number of sharing
HS-PDSCH code.
5 Counter List
Counter No. Description
6 Glossary
HSDPA: High Speed Downlink Packet Access
P-T-P: Point-to-Point
P-T-M: Point-to-Multipoint