Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Feature Guide
WCDMA RAN
Allocation
Date
Author
Reviewer
Revision History
1.
Updated
DPCH/F-DPCH
3.2.2.6
3.
Added
3.3.2.5
E-AGCH/E-RGCH/E-HICH
adjustment
V7.0
2012-3-26
Hu Xingxing
number
triggered
by
E-AGCH/E-RGCH/E-HICH
Liu LiPing
CC
congestion
4.
5.
6.
1.
2.
Cai
V8.0
2012-12-1
Yaofang/Xia
Zhiyuan
Added
notes
for
Parameters
of
Cui Lili
3.
Updated
the
parameter
name
for
Priority.
5.
6.
and
1.
2.
Added
Cai
V8.5
2013-11-23
Yaofang/Xia
Zhiyuan
Cui Lili
Cells,
3.6
3.5
Code
Fast
Sharing
between
Dynamic
Code
Allocation.
TABLE OF CONTENTS
1
2
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.2
2.3
Overview ............................................................................................................ 6
ZWF21-04-006 Code Resource Allocation ........................................................... 9
R99 Code Resource Allocation ............................................................................ 9
HSDPA Code Resource Allocation ...................................................................... 9
HSUPA Code Resource Allocation .................................................................... 10
Uplink Enhanced CELL_FACH Code Resource Allocation ................................. 11
ZWF23-04-020 Fast Dynamic Code Allocation .................................................. 11
ZWF23-04-021 Code Sharing between Cells ..................................................... 11
3
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.2
3.2.1
3.2.2
3.3
3.3.1
3.3.2
3.4
3.4.1
3.4.2
3.5
3.6
4
4.1
4.1.1
4.1.2
4.2
4.2.1
4.2.2
4.3
4.3.1
4.3.2
4.4
4.4.1
4.4.2
4.5
4.5.1
4.5.2
4.6
4.6.1
4.6.2
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
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]
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
Channelisation
Code
Scrambling
Code
Spreading
Scrambling
Data
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.
WCDMA has a total of 2
24
24
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
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
2.1
2.1.1
2.1.2
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:
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
10
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
2.2
2.3
11
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.
Technical Descriptions
3.1
3.1.1
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
, 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.
12
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.
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.
13
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
RACH
RACH 0
PRACH
(max 16 per cell)
PRACH partitions
ASC 0
RACH 2
RACH 1
Coding
Coding
RACH 3
Coding
Coding
PRACH 0
PRACH 1
PRACH 2
PRACH 3
Preamble
scrambling
code 0
Preamble
scrambling
code 1
Preamble
scrambling
code 2
Preamble
scrambling
code 2
ASC 1
ASC 2
11
ASC 0
ASC 0
11
ASC 1 ASC 2
11
11
available
subchannels
(max 12)
0
0
15
available preamble signatures (max 16)
0
0
15
0
0
10
th
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
14
15
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
Determine the number of SCs allocated to each CMP according to the CMP
capacity,
and
configure
these
two
parameters:
RcpScrStartId
and
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
15
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.
16
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.
17
3.1.2
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.
i=0,,511
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:
18
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
3.1.2.2
3.1.3
Uplink CC
3.1.3.1
19
3.1.3.2
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.
20
Figure 3-2
cd,3
DPDCH1
DPDCH3
cd,5
DPDCH5
I+jQ
cd,2
cd,4
cd,6
cc
Sdpch
DPDCH2
DPDCH4
DPDCH6
DPCCH
3.1.4
Downlink CC Management
3.1.4.1
The CCs used by other downlink common physical channels are allocated as follows:
21
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
22
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
Free
SF= 8
SF=16
SF=32
SF=64
Allocated
0
0
1
` 0
` BLocked
` 0
SF=32
SF=64
` 0
4
(c)
(b)
1
1
SF=16
(a)
SF= 8
` 0
1
1
(d)
23
3.2
3.2.1
SC Allocation
3.2.1.1
3.2.1.2
3.2.1.3
3.2.2
CC Allocation
3.2.2.1
24
Table 3-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
3.2.2.3
25
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.
26
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).
Figure 3-4
OcuRateHspdsch
deltaP
If deltaP>=DpchCodeHy+32,
increase the HS-PDSCH
number
DpchCodeHy
OcuRateNoHspdsch
27
Figure 3-5
OcuRateHspdsch
If deltaP<CodeUptHyA,
decrease the HS-PDSCH number
deltaP
Max Code Usage
(512)
CodeUptHyA
OcuRateNoHspdsch
2.
3.
4.
28
free SF16 codes in the cell, as the upper limiter for the adjustment of number of
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.
29
3.2.2.4
3.2.2.5
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
30
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,
3.2.2.7
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:
31
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:
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
HsGBRSum1/(0.5*HspdschBitRate)
secondary
+
HS-PDSCH
number
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.
32
F-DPCH,p
is given.
3.2.2.9
33
3.2.2.9.1
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
34
3.2.2.10
35
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
3.3.1
SC Allocation
3.3.1.1
3.3.1.2
3.3.2
CC Allocation
3.3.2.1
3.3.2.2
36
E-DPDCHk
E-DPDCH1
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.
3.
When Nmax-dpdch = 0, E-DPDCH1 and E-DPDCH2 use the same CC, that is,
Cch,4,1 or Cch,2,1.
37
When Nmax-dpdch = 1, E-DPDCH1 and E-DPDCH2 use the same CC, that is,
Cch,4,2 or Cch,2,1.
4.
3.3.2.3
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.
38
Figure 3-6
39
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
3.3.2.3.1
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.
40
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
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,
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.
41
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.
3.3.2.4
42
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:
43
Figure 3-7
44
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
3.3.2.4.1
45
3.3.2.4.2
2.
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.
46
3.3.2.5
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.
47
3.4
3.4.1
SC Allocation
3.4.1.1
3.4.1.2
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.
48
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
3.4.2.2
3.4.2.3
49
3.4.2.4
3.4.2.5
3.5
50
3.6
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
51
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.1
4.1.1
Parameter List
4.1.1.1
4.1.1.2
Abbreviated Name
Parameter Name
ModuleSeq
Module No.
RcpScrStartId
RcpScrEndId
PreamScraCode
Signature
Available Signature
Code
Abbreviated Name
primaryScramblingCode
4.1.2
Parameter Configurations
4.1.2.1
Module No.
Parameter Name
Cell Primary Scrambling Code
OMC path
52
Parameter configuration
The parameter specifies the CMP module number on which the cell is established.
4.1.2.2
OMC path
GUI: Managed Element->Equipment->Module->Starting No. of CMP Scrambling
Code
Parameter configuration
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
OMC path
GUI: Managed Element->Equipment->Module->Ending No. of CMP Scrambling
Code
Parameter configuration
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.
53
4.1.2.4
OMC path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Channel Configuration->AICH Configuration->PRACH
Configuration->PRACH Preamble Scrambling Code
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).
The parameter value is incremented by 1 every time one PRACH is added.
4.1.2.5
Available Signature
OMC path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Channel Configuration->AICH Configuration->PRACH
Configuration->Available Signature
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.
4.1.2.6
OMC path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Cell Primary Scrambling Code
This parameter is the primary SC of the cell. It is used to differentiate cells.
54
4.2
4.2.1
Parameter List
4.2.1.1
Abbreviated Name
Parameter Name
NumofHspdsch
Number Of HS-PDSCH
MinNumofHspdsch
MaxNumofHspdsch
NumofHsscch
Number Of HS-SCCH
DpchCodeHy
CodeUptHyA
HspdschBitRate
CodeUptPrds
codeUptPrdms
10
CodeUptPrdUnit
11
OCNSCodeNumber
12
OCNSCode
13
CodeReAssInd
14
CodeReAssPrd
15
IurCdReAssDrop
16
hsVsR99CdPriInd
17
hsMRRUSchInd
18
MRRU456NotComInd
55
4.2.2
Parameter Configurations
4.2.2.1
Number of HS-PDSCH
OMC path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->Number of HS-PDSCH
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.
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
OMC path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->Minimum Number of HS-PDSCH
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.
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.
56
4.2.2.3
OMC path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->Maximum Number of HS-PDSCH
Parameter configuration
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
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->Number of HS-SCCH
Parameter configuration
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
OMC path
57
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.
4.2.2.6
OMC path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->SF512 Number to Decrease HS-PDSCH
Number
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.
58
4.2.2.7
OMC path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->HS-PDSCH Bit Rate
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.
4.2.2.8
OMC path
GUI: Managed Element ->UMTS Logical Function Configuration->Service
Configuration->Hspa Configuration->Code Update Period(millisecond)
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.
59
4.2.2.9
OMC path
GUI: Managed Element ->UMTS Logical Function Configuration->Service
Configuration->Hspa Configuration->Code Update Period(second)
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.
4.2.2.10
OMC path
GUI: Managed Element ->UMTS Logical Function Configuration->Service
Configuration->Hspa Configuration->Code Update Period Unit
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.
4.2.2.11
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Number of the Codes with SF =128 Ordered for OCNS
60
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.
4.2.2.12
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Code Node Number with SF =128 for OCNS
Parameter configuration
The parameter indicates that code number of SF=128 for OCNS.
4.2.2.13
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->Service
Configuration->Hspa Configuration->DPCH Code Re-Assign Support Indicator
Parameter configuration
The parameter indicates whether the system supports DPCH code re-assign when
needed.
4.2.2.14
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->Service
Configuration->Hspa Configuration->DPCH Code Re-Assign Period
Parameter configuration
61
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
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->Switch for DRNC Code Re-Assignment Radio
Link Release
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.
4.2.2.16
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->HSDPA Vs R99 Code Priority Indicator
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.
4.2.2.17
OMCB path
62
Parameter configuration
4.2.2.18
OMCB path
Parameter configuration
This parameter specifies whether Node B supports high-efficiency MRRU 456 function.
4.3
4.3.1
Parameter List
4.3.1.1
Abbreviated Name
Parameter Name
NumofEagch
Number Of E-AGCH
NumofErgHich
4
5
EAgchDnThr
EAgchUpThr
ERgHichDnThr
ERgHichUpThr
63
10
11
MaxEAgchNum
MaxERgHichNum
UserNumPerEagch
HsupaCtrChUptPrd
ECtrChCongIncSwh
4.3.2
Parameter Configurations
4.3.2.1
Number of E-AGCH
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->Number of E-AGCH
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.
4.3.2.2
Number of E-RGCH/E-HICH
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->Number of E-RGCH/E-HICH
Parameter configuration
64
4.3.2.3
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->User Number Threshold to Decrease E-AGCH
Number
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.
4.3.2.4
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->User Number Threshold to Increase E-AGCH
Number
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.
65
4.3.2.5
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->User Number Threshold to Decrease
E-RGCH/HICH Number
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.
4.3.2.6
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->User Number Threshold to Increase
E-RGCH/HICH Number
Parameter configuration
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
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->Maximum E-AGCH Number for Dedicated
E-DCH Users
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
66
congestion.
4.3.2.8
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->Maximum E-RGCH/HICH Number for
Dedicated E-DCH Users
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.
4.3.2.9
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->Maximal Scheduled E-DCH User Number in
CELL_DCH state Scheduled Per E-AGCH
Parameter configuration
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
OMCR path
67
Parameter configuration
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
OMCR path
GUI: Managed Element
Parameter configuration
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.
68
4.4
4.4.1
Parameter List
4.4.1.1
Abbreviated Name
Parameter Name
CommonEdchNum
PrachType
DediComEAGCHSwi
4.4.2
Parameter Configurations
4.4.2.1
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->EFACH Configuration->Common E-DCH Resources Number
Parameter configuration
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.
69
4.4.2.2
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Channel Configuration->AICH Configuration->PRACH Configuration->Type
of PRACH Preamble
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.
4.4.2.3
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->E-AGCH Multiplexing Switch in Dedicated and
Common E-DCH
Parameter configuration
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.
70
4.5
4.5.1
Parameter List
No.
1
Abbreviated Name
HsNBAssInd
enableDynCode
Parameter Name
HS-PDSCH Code NodeB Assignment Support
Indicator
Dynamic code allocation supported
4.5.2
Parameter Configurations
4.5.2.1
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->HS-PDSCH Code NodeB Assignment Support
Indicator
Parameter configuration
The parameter indicates whether the system supports the assignment of
HS-PDSCH code in Node B when needed.
4.5.2.2
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.
71
4.6
4.6.1
Parameter List
No.
Abbreviated Name
Parameter Name
HsSharMethod
HsShareInd
HsSharUptPrd
4.6.2
Parameter Configurations
4.6.2.1
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->Iub Link
Configuration->Co-NodeB HS-PDSCH Code Sharing Method
Parameter configuration
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
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->UTRAN
Cell->Hspa Configuration In A Cell->Co-NodeB HS-PDSCH Code Sharing Indicator
Parameter configuration
The parameter indicates whether the cell supports HS-PDSCH Code sharing with
the other cells in the same Node B.
72
4.6.2.3
OMCR path
GUI: Managed Element ->UMTS Logical Function Configuration->Iub Link
Configuration->Co-NodeB HS-PDSCH Code Sharing Update Period
Parameter configuration
The parameter indicates that the period of RNC updates the total number of sharing
HS-PDSCH code.
Counter List
Counter No.
Description
C310424227
C310424228
C310426478
C310424230
C310424231
C310424232
Current Number of
C310424233
Current Number of
C310424234
C310426480
C310424236
C310424237
C310424238
C310426560
C310424240
C310424241
C310424242
C310426483
C310424244
C310424245
code resource
73
C310424246
C310426485
C310424248
C310424249
C310424250
C310426487
C310424252
C310424253
C310424254
C310426562
C310424256
C310424257
C310424258
C310426490
C310424260
C310424261
C310424262
C310426564
C310424264
C310424265
C310424266
C310426493
C310424268
C310424269
C310424270
C310426496
C310424272
C310424273
C310424274
C310426498
C310424276
C310424277
74
C310424278
C310426500
C310424280
C310424281
C310424282
Times
C310424283
C310424284
C310424285
C310424286
C310424287
C310424288
C310424289
C310424290
C310424291
C310424292
C310424293
C310424294
C310424295
C310424296
C310424297
C310424298
C310424299
C310424300
C310424301
C310424302
C310424303
C310424304
C310424305
C310424306
C310424307
C310424308
C310424309
75
C310424310
C310424311
C310424312
C310424313
C310424314
C310424315
Times
C310424316
C310424317
C310424318
C310424319
C310424320
C310424321
C310424322
C310424323
C310424324
C310424325
C310424326
C310424327
C310424328
C310424329
C310424330
C310424331
C310424332
C310424333
C310424334
C310424335
C310424336
C310424337
C310424338
C310424339
C310424340
C310424341
76
C310424342
C310424343
C310424344
C310424345
C310424346
C310424347
C310424348
Times
C310424349
C310424350
C310424351
C310424352
C310424353
C310424354
C310424355
C310424356
C310424357
C310424358
C310424359
C310424360
C310424361
C310424362
C310424363
C310424364
C310424365
C310424366
C310424367
C310424368
C310424369
C310424370
C310424371
C310424372
C310424373
77
C310424374
C310424375
C310424376
C310424377
C310424378
C310424379
C310424380
C310424381
C310424382
C310424383
C310424384
C310424385
C310424386
C310424387
C310424388
C310424389
C310424390
C310424391
C310424392
C310424393
C310424394
C310424395
C310424396
C310424397
C310424398
C310424399
C310424400
C310424401
C310424402
C310424403
C310424404
C310424405
78
C310424406
C310424407
C310424408
C310424409
C310424410
C310424411
C310424412
C310424413
C310424414
C310424415
C310424416
C310424417
C310424418
C310424419
C310424420
C310424421
C310424422
C310424423
C310434424
C310434425
C310434426
C310434427
C310436502
C310434429
C310434430
C310434431
C310436504
C310435946
C310434433
C310436506
C311785723
79
C311785724
Re-assignment
Dpch Code Reassign Number of SF32 due to Periodic Code
C311785725
Re-assignment
Dpch Code Reassign Number of SF64 due to Periodic Code
C311785726
Re-assignment
Dpch Code Reassign Number of SF128 due to Periodic Code
C311785727
Re-assignment
Dpch Code Reassign Number of SF256 due to Periodic Code
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
C311786821
Re-assignment
Number of Releasing SF16 Dpch due to Periodic Code
C311786822
Re-assignment
Number of Releasing SF32 Dpch due to Periodic Code
C311786823
Re-assignment
Number of Releasing SF64 Dpch due to Periodic Code
C311786824
Re-assignment
Number of Releasing SF128 Dpch due to Periodic Code
C311786825
Re-assignment
Number of Releasing SF256 Dpch due to Periodic Code
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
Glossary
HSDPA:
HSUPA:
80
MBMS:
HS-DPCCH:
HS-SCCH:
HS-PDSCH:
E-DPCCH:
E-DPDCH:
E-AGCH:
E-RGCH:
E-HICH:
MICH:
P-T-P:
Point-to-Point
P-T-M:
Point-to-Multipoint
ASC:
CMP:
81