Dimpcu

GERAN PS domain
Network Engineering

PCU dimensioning
BR10.0
Version 1.0 IUS
September 2008

GERAN, PS domain, Planning Guideline
PCU dimensioning
The information in this document is subject to change without notice and describes only the product
defined in the introduction of this documentation. This documentation is the company internal
document and thus not intended to be handed out to customers, and no part of it may be used,
reproduced, modified or transmitted in any form or means without the prior written permission of
Nokia Siemens Networks. The documentation has been prepared to be used by professional and
properly trained personnel, and the reader assumes full responsibility when using it. Nokia Siemens
Networks welcomes reader comments as part of the process of continuous development and
improvement of the documentation.
The information or statements given in this documentation concerning the suitability, capacity, or
performance of the mentioned hardware or software products are given "as is" and all liability arising
in connection with such hardware or software products shall be defined conclusively and finally in a
separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens
Networks has made all reasonable efforts to ensure that the instructions contained in the document
are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed
necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.
Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT
WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR
ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL
OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT,
REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA, THAT MAY
ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.
This documentation and the product it describes are considered protected by copyrights and other
intellectual property rights according to the applicable laws.
The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of
Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective owners, and
they are mentioned for identification purposes only.
Copyright Nokia Siemens Networks 2008. All rights reserved

2
PCU dimensioning
This document consists of a total of 52 pages.
Table of Contents
0 General information.........................................................................................5
0.1 Motivation for this guideline.............................................................................5
0.2 Scope of the document ...................................................................................5
1 (E)GPRS in BR implementation of NSN GERAN ...........................................7
1.1 PCU HW realization ........................................................................................8
1.2 PCU load control algorithm...........................................................................10
1.2.1 Function of load balancing ............................................................................10
1.2.2 Calculation steps performed by load balancing ............................................11
1.2.3 Configuration rules related to load balancing................................................14
1.2.4 Relationship to database parameters ...........................................................17
1.3 PCU redundancy concept .............................................................................21
2 PCU dimensioning approach ........................................................................22
2.1 Abis dimensioning for PS resources .............................................................23
2.2 Relationship to database parameters ...........................................................28
3 PCU planning approach................................................................................31
3.1 Impact of PS channels release strategy .......................................................31
3.2 Impact of initial coding schemes selection strategy......................................34
3.3 Impact of MS allocation strategy...................................................................37
3.4 Impact of TBF release strategy.....................................................................38
3.5 Summary of additional PCU planning aspects..............................................39
4 BR10 improvements on PS traffic handling ..................................................40
4.1 Modified PCU load balancing........................................................................40
4.2 Enhancement of PCU capacity .....................................................................41
4.2.1 Interdependencies between BR10.0 PCU improvements: impact on planning43
4.3 Improvement of DL resources allocation method (IDRA) .............................44
5 PCU optimization based on PM counters .....................................................47
Abbreviations................................................................................................................52

3
PCU dimensioning
List of Figures and Tables
Figure 1-1: Network entities supporting the GPRS technology..................................... 7
Figure 2-1: average number of PDTs per site (N
PDT,BTSE
) for small and medium cell
configuration in terms of PDCH.................................................................... 26
PDT,BTSE
) for medium and high cell
configuration in terms of PDCH.................................................................... 27
Figure 2-3: Abis pool and subpool concept ................................................................. 30
Figure 3-1: overview on PCU and TDPC/AP activities during PS channel allocation. 32
Figure 3-2: PS channel allocation and release (an example for default settings of
TEMPCH/TEMPDT timers and burst traffic in the network) ...................... 34
Figure 3-3: an example of horizontal allocation: 2 users, each one occupy 3 PDCHs,
Abis resources must be granted to 6 PDCHs .............................................. 37
Figure 3-4: an example of vertical allocation: 4 users multiplexed in 1 PDCH, the
remaining 5 PDCHs unused (can be e.g. preempted to extend CS capacity),
Abis resources must be granted to 1 PDCH only ........................................ 38
Figure 4-1: TDPC/AP algorithm with Enhancements of PCU capacity enabled........ 43
Figure 4-2: IDRA principles.......................................................................................... 44
Figure 4-3: reconfiguration of allocated resources by means of IDRA........................ 45

Table 1-1: overview on HW realization of PCU............................................................. 9
Table 1-2: mapping of planning parameters related to load balancing algorithm into DB
attributes....................................................................................................... 19
Table 2-1: the number of PDT per PDCH depending on (M)CS................................. 24
Table 3-1: summary of PCU planning aspects............................................................ 39

List of Planning Rules
Rule 1-1: Configuration of the parameters related to the load balancing.................... 14
Rule 2-1: Dimensioning vs. planning........................................................................... 28
Rule 2-2: Setting up Abis pool and subpool (ASSLAPD attribute) .............................. 29
Rule 3-1: TEMPCH/TEMPPDT timers......................................................................... 33
Rule 3-2: Relation between TEMPCH and TEMPDT.................................................. 34
Rule 3-3: Regression analysis..................................................................................... 35

4
PCU dimensioning
0 General information
The chapter provides general information about purpose and scope of the guideline.
0.1 Motivation for this guideline
The document provides details about architecture of (E)GPRS in GERAN. In addition
to description of the relevant Network Entities (NEs) and HW which is used to realize
particular NE, the other aspects having impact on the amount and load of PCU are
covered here as well. These are e.g. PCU load distribution algorithm, impact of
assignment of radio channels on system behaviour and data base settings affecting
several procedures relevant for PS traffic handling.
Provisioning of such information becomes crucial for PCU dimensioning in mature
(E)GPRS networks where planner has to deal not only with growing PS throughput
requirements but also with a variety of applications described by different QoS
characteristics and traffic demands. Occurrence of some extra-ordinary applications
which not always can be easily assigned to one of well known traffic patterns may lead
to improper planning assumption which lead to wrong bandwidth reservation within
entities and interfaces. Next, such inaccuracy can cause unexpected load behaviour
and in combination with unfavorable data base settings even PCU congestion and the
whole network quality deterioration in consequence. This effect can be alleviated or
even avoided when additional aspects are taken into consideration during planning
and dimensioning process of GERAN. Analysis and description of these additional
aspects making PCU dimensioning more accurate is what the document has been
worked out for.
0.2 Scope of the document
The document is composed of five main parts (chapters):
Chapter 1 provides system specification for PCU dimensioning (e.g. system
limitation based on HW and SW releases, load balancing, impact of radio network
configuration and data base setting on load balancing behaviour)
Chapter 2 provides information about PCU dimensioning approach depending on
different implementation of (E)GPRS and Abis allocation strategy as well as other
aspects related to dimensioning going beyond calculation procedure.
Chapter 3 provides overview on additional planning aspects that must be taken
into account during field implementation for different application types, e.g. impact
of empty channel timers settings, channel allocation strategy, channel release
strategy are explained as well as the most important data base parameters are
indicated.
Chapter 4 provides short overview on BR10 improvements to the way in which PS
traffic is handled as the features introduced in BR10 are expected to bring
significant advantages in many challenging scenarios (for which current featureset
is or soon will be no longer sufficient).
5
PCU dimensioning
Chapter 5 reports some PM counters which are helpful to verify performance of
PS traffic in GERAN as well as dimensioning results. Together with basic counter
information it is also explained what would be typical countermeasures to
particular problems observed during performance measurements analyses, e.g.
an example for PDT and/or PCU reconfiguration based on measured load
distribution could be given.

Please note that the document is focusing on PCU dimensioning therefore Abis topics
are also covered. The document does not provide any guidelines being relevant to the
remaining interfaces and nodes responsible for handling of PS traffic like e.g. Um, Gb
or SGSN. These network elements are only mentioned where required to ensure the
document clarity and consistency.
6
PCU dimensioning
1 (E)GPRS in BR implementation of NSN
GERAN
The standard GSM network does not provide sufficient functionality to realize a packet
switched (PS) data services. In order to enable PS services some additional
components have to be added to Radio Access Network (RAN) as well as to Core
Network (CN).
Functional unit responsible for handling of PS services in GERAN is called Packet
Control Unit (PCU). In BR implementation of NSN RAN PCUs are installed in BSC as
one of its boards, so activation of the PS services does not imply introduction of any
additional interfaces within RAN (e.g. between BSC and PCU). The PCU controls
inter-working between Radio Network (RN) and CN nodes and thus it must ensure
data flow between Abis and Gb interfaces. RN sites contain Channel Coding Units
(CCUs) which finally form data blocks generated by PCU to make these blocks ready
to send on Um interface towards Mobile Station (MS). In the CN the functionality of the
PS traffic switching centre is realized by Serving GPRS Support Node (SGSN). The
following figure provides overview about the GERAN elements responsible for
handling of PS traffic:

CCU
CCU
P
C
U
B TS B S C
S GS N
A-bis G
b
Figure 1-1: Network entities supporting the GPRS technology

The main tasks of PCUs can be summarized as follows:
channel access control functions on radio and Abis interfaces (evaluation of the
required amount of channels, requesting TDPC/AP for allocation of PDCH or PDT)
for both newly incoming PS calls and when additional resources are requested for
already established PS calls;
LLC layer PDU segmentation into RLC blocks for downlink transmission / RLC
layer PDU re-assembly into LLC blocks for uplink transmission (e.g. for DL: SGSN
sends to the right PCU data sub-divided in a certain number of LLC frames by
means of Gb interface; the LLC frames have a variable length; therefore before
data is sent on Um interface which has a limited capacity, the LLC frames are
segmented by PCU in a certain number of RLC/MAC blocks which have a well
defined length according to the used coding scheme; then RLC/MAC blocks are
sent to the right cells by means of PCU frames on Abis interface);
management of the protocol stack of the Gb interface;
PDCH scheduling functions for UL and DL transfer;
PDCH RLC ARQ functions, including buffering and re-transmission of RLC blocks;
7
PCU dimensioning
Radio Channel management functions, e.g. congestion control, broadcast control
information;

At BTS site packet functionalities are supported by CCUs; the main functions of CCUs
can be summarized as follows:
first of all, a BTS after receiving RLC/MAC block from the PCU forms (so-called)
Radio Block which is then sent over Um interface towards MS; forming of Radio
Blocks is usually called channel coding and consists in execution of the following
procedures on the received RLC/MAC block: block coding, convolution coding,
puncturing and interleaving;
radio channel measurements functions including received quality level, received
signal level and information related to timing advance;
continuous TA update;
incremental redundancy UL/DL;

1.1 PCU HW realization
HW realization of PCU varies with evolution of the BSC. It determines the BSC
capacity for PS traffic.

High Capacity BSC step I (BSC/72)
BSC / 72 was introduced in BR6.0. The PCU functionality is realized within BSC / 72
by means of PPXU boards. Up to 6 PPXUs can be deployed within BSC / 72 and each
one supports up to 256 PDTs. Load balancing is used to assign cells among PCU and
to control PCU load also in the event of PCU outage (i.e. for redundancy purposes):
initially cells carrying PS traffic are dynamically distributed among all available PPXUs;
when any PPXU breaks down, the related PS cells are automatically redistributed
among the remaining PPXUs if any capacity is available. Therefore when a failure of a
PPXU occurs, then the max BSC/120 capacity expressed in terms of managed PDTs
is reduced to 1280 (i.e. 5 256).
Each PCU is able to handle 4 Mbit/s data flow towards the Gb interface. This amount
of PS data traffic corresponds to a flow obtained by 64 time slots (64 kbit/s each one)
on a PCM line. These figures determine the maximum number of Frame Relay links
(FRLs) that can be configured for each PCU. Hence for each PCU at most 63 FRLs
can be created (max allowable capacity of a single FRL is 31 timeslots of 64 kbit/s).
High Capacity BSC supports all GPRS / EDGE Coding Schemes (as well as both
standard and concatenated PCU frames).

High Capacity BSC step II (BSC / 120)
BSC / 120 was introduced in BR7.0. The only difference between realization of PCU
functionality within BSC / 120 and BSC / 72 is capacity enhancements in number of
PPXUs managed by a BSC which is doubled from 6 in case of BSC / 72 to 12 in case
of BSC / 120 (11 when a failure of one PPXU occurs). The remaining aspects like
8
PCU dimensioning
number of PDTs handled by a single PCU or redundancy scheme are maintained. It
simply results in a twofold increase of the capacity figures per BSC.

eBSC
eBSC was introduced in BR9.0. The PCU functionality is realized within eBSC by
means of UPM boards. Up to 10 UPM boards can be deployed within eBSC and each
one supports up to 850 PDTs. Load balancing is used to assign cells among UPM
boards (i.e. PCU) and to control their load also in the event of outage (i.e. for
redundancy purposes): initially cells carrying PS traffic are dynamically distributed
among all available UPM boards; when any UPM breaks down, the related PS cells
are automatically redistributed among the remaining boards if any capacity is
available. Therefore when a failure of a UPM occurs, then the max eBSC capacity
expressed in terms of managed PDTs is reduced to 7650 (i.e. 9 850).
Each PCU is able to handle 13.6 Mbit/s data flow towards the Gb interface. Although
possible eBSC capacity for PS traffic increased significantly (from 48 Mbit/s in case of
BSC/120 to 136 Mbit/s) the possible number of FRLs per eBSC is identical compared
with BSC/120 (i.e. 756 FRLs per eBSC; max allowable capacity of a single FRL is 31
timeslots of 64 kbit/s).

The overview about HW realization of PCUs in different BSCs is given in the table
below:
parameter

BSC / 72 BSC / 120 eBSC
PCUs
maximum number of
PCUs per BSC
6 12 10
PCU realization 1 PCU 1 PPXU 1 PCU 1 PPXU 1 PCU 1 UPM
redundancy load balancing load balancing load balancing
PDTs
max number of PDTs
per PCU (N
PDT,PCU
)
256 256 850
maximum number of
PDTs per BSC
1536
= 6 256
3072
= 12 256
8500
= 10 850
throughput based on PDTs
maximum throughput
per PCU
4 Mbit/s
= 256 16 kbit/s
4 Mbit/s
= 256 16 kbit/s
13.6 Mbit/s
= 850 16 kbit/s
maximum throughput
per BSC in Mbit/s
24
= 6 4
48
= 12 4
136
= 10 13.6
FRLs
maximum number of
FRLs per BSC
378

756

756
cells with PS traffic (PTPPKFs)
maximum number of
GPRS cells per BSC
250 400 1000
Table 1-1: overview on HW realization of PCU
Note:
9
PCU dimensioning
From BR9.0 on it is possible to choose between dedicated and centralized NS
layer (due to introduction of the Central NS layer). When Central NS layer is enabled a
separate PCU board (PPXU or UPM) is required to handle NS layer tasks for the
whole BSC. This PPXU-NS / UPM-NS is not counted in the table above because it
does not process PDTs. Introduction of PPXU-NS / UPM-NS has different
consequences in case of fully equipped (in terms of PCUs) BSC/120 and eBSC: in
BSC/120 the number of PCU boards processing PDTs is decremented to insert
PPXU-NS whereas eBSC is flexible enough to keep the number of PCU boards
processing PDTs unchanged because additional, eleventh UPM can be inserted.

1.2 PCU load control algorithm
A PCU is responsible for management of incoming (E)GPRS requests which are only
related to its own set of cells. Basically a user never needs to assign cells to a PCU
manually. This distribution is always
1
done fully automatically by means of load
balancing algorithm executed by PTPPKF Load Distributor (PLD) process
implemented in the TDPC / AP-M processor.
1.2.1 Function of load balancing
Load balancing performs GPRS cells distribution (during system init) or re-distribution
(due to occurrence of the remaining events reported below) among existing PCUs
having NSVCs created when PCU is realized by means of either PPXU boards or
UPM boards.
The following events trigger load balancing algorithm:
system init,
any PCU having NSVCs created becomes unavailable (i.e. it fails or is locked),
physical connection between a PCU and the SGSN becomes completely
unavailable (i.e. the last NSVC from the PCU towards an SGSN becomes
unavailable); it happens when:
PCM line containing the last available FRL goes down or is locked,
the last FRL or the last NSVC is locked,
faulty/locked PCU comes back in service,
physical connection between a PCU and the SGSN comes back in service,
newly created PCU comes in service for the first time (to come in service means
to have at least one NSVC towards an SGSN already created),
a GPRS cell (PTPPKF) deletion (if the most loaded PCU has a weight at least 10
% greater than the average load after the PTPPKF deletion).
In principle load balancing algorithm starts whenever the transmission path between
an SGSN and a GPRS cell is modified. Note that when a PCU becomes unavailable
(due to either fault/lock PCU or connection outage) only the GPRS cells managed by

1
Up to BR9 it was indeed done fully automatically, from BR10 on also manual assignment is possible (please
refer to chapter 4.1 for more information).
10
PCU dimensioning
the PCU are subject to redistribution. If no further load redistribution is triggered during
the PCU unavailability, then the GPRS cells assigned to this PCU before the outage
will be simply put back on it.
The following events do not trigger load balancing algorithm:
a GPRS cell creation (a GPRS cell when created is simply assigned to the least
loaded PCU),
a PCU creation as long as the newly created PCU does not come in service,
a PCU overload indication since PCU overload management does not cause any
modification of the transmission path between the SGSN and the GPRS cells
managed by the PCU.

1.2.2 Calculation steps performed by load balancing
Distribution / re-distribution of GPRS cells between PCUs is done based on the
following information:
number of PCUs configured in the BSC,
number of GPRS cells (PTPPKFs) configured in the BSC,
total number of radio channels configured for PS services for each GPRS cell,
total number of timeslots reserved for each PCU on the Gb interface,
Routing Area of the each GPRS cell (meaningful especially during system init).
Obviously only active cells and PCUs which came in service will be taken into
consideration by load balancing algorithm.
Decision about cell assignment is done by the algorithm on the basis of PCU average
load (PCUw_target) calculated as follows:

PCUband
) i ( PTPw
PCUband(n) t(n) PCUw_targe Equation 1
where:
PTPw(i) number of radio channels configured for PS services for i-th
cell assigned to the PCU i.e. sum of packet control channels,
reserved and shared PDCHs
PCUband(n) number of 64 kbit/s timeslots (GTS) on PCMG/PCMA reserved
for all FRLs associated to a n-th PCU

Note:
When IP SNS is in use instead of the FR one, then PCUband(n) is defined as the
number of 16 kbit/s timeslots on Abis (PDT) assigned to the particular PCU.

The algorithm tries to distribute the PS cells among the available PCUs so that all the
PCUs have PCU_weight as near as possible to PCUw_target.
11
PCU dimensioning
PCU_weight denotes the sum of all PTPw on that PCU:
( )
i
i PTPw weight(n) _ PCU
Equation 2

Therefore additional calculations are executed as shown below. Firstly for each and
every PCU being installed and in service a Delta between the current PCU weight
(PCU_weight(n)) and the PCU average load (PCUw_target) is calculated as follows:
) n ( et arg t _ PCUw ) n ( weight _ PCU ) n ( Delta Equation 3
where: n = 0N
N number of PCUs in service per BSC

Then in the next step two PCUs are selected from the pool to act as:
PCU destination (PCU_d) which is the PCU with the minimum Delta (see Equation
3)
PCU source (PCU_s) which is the PCU with the greatest (positive) Delta (see
Equation 3)

From PCU_s, starting from the smallest Routing Area present on the PCU to the
greatest one, the algorithm selects the first cell with maximum weight (PTP_target)
where:
10 ntage DeltaPerce
with
) s ( Delta PTPw
>
Equation 4

Please note that DeltaPercentage(s) is defined as:
) s ( et arg t _ PCUw
100 ) s ( Delta
) s ( ntage DeltaPerce

Equation 5

If PTP_target exists, it will be moved from PCU_s to PCU_d what means that PCU
assigned for PTP_target as well as PCU_weight and PCU_delta for both PCU_s and
PCU_d will be updated and the whole procedure repeated. The algorithm aims at
achieving the following target:
10 ntage DeltaPerce < Equation 6

Please be aware it is not always possible to reach the target defined by Equation 6.
For instance let us consider the following example:
12
PCU dimensioning
3 PCUs in service, one of them has 2 timeslots on Gb interface created and the
remaining two ones have 1 timeslot each;
6 GPRS cells enabled: four of them with 100 data channels created and the
remaining two with 50 data channel created.
The following steps are performed by load balancing in such case:
loading inputs from database
PCUband(0) = 2, PCUband(1) = 1, PCUband(2) = 1
PTPw(0) = PTPw(1) = PTPw(2) = PTPw(3) = 100, PTPw(4) = PTPw(5) = 50
cf. Equation 1
PCUw_target(0) = 250
PCUw_target(1) = PCUw_target(2) = 125
The optimum assignment is as follows (cf. Equation 2):
PCU_weight(0) = 250
PCU_weight(1) = 150
PCU_weight(2) = 100
What results in the following possible (also other options are equally good)
distribution of PTTPKF between PCUs:
PCU(0) -> PTPPKF(0), PTPPKF(1), PTPPKF(4)
PCU(1) -> PTPPKF(2), PTPPKF(5)
PCU(2) -> PTPPKF(3);
cf. Equation 3
Delta(0) = 0
Delta(1) = 25
Delta(2) = -25
balancing procedure (cf. Equation 4 Equation 6)
PCU(1) is selected to act as PCU_s and PCU(2) is selected to act as PCU_d
none of cells originally assigned to PCU(1) can be marked as PTP_target and
moved to PCU(2) (otherwise the condition defined by Equation 4 would not be
fulfilled)
DeltaPercentage(1) = 20% (i.e. target defined by Equation 6 is not fulfilled)
although the target is not fulfilled the load balancing algorithm has performed
an optimal distribution.

Moreover, also the Routing Areas are taking into account during cell distribution by
trying to assign an entire RA on a single PCU where possible. Restriction of RA
considerations during execution of cell (re-)distribution is fully justified since even
though the algorithm tries to assign all cells from a RA to a single PCU (to e.g. reduce
PS paging, improve performance of cell reselection, ) the constraint related to equal
load of PCUs (as defined by Equation 1) has higher priority and thus information about
RA is neglected if it would collide with the balancing of the PCU loads.
13
PCU dimensioning
1.2.3 Configuration rules related to load balancing
During network design process it is necessary to rely on the distribution of cells among
existing PCUs which is carried automatically by load balancing algorithm (as
described in the chapter above). It is assumed that load balancing leads to
homogenous distribution of cells among PCUs, i.e. distribution which is proportional to
bandwidth available per PCU. This assumption has certain consequences for network
performance and dimensioning:
it is expected that all equipped PCUs share similar load (on their Frame Relay
timeslots), at least it is unexpected that some PCUs have very low load while the
other one(s) is even overloaded,
it is expected that Gb traffic is distributed (almost
2
) evenly among equipped PCUs,
this assumption is basis for Gb interface dimensioning (it is important especially in
case of Gb over FR).
As already mentioned, obtaining an optimal solution (i.e. DeltaPercentage 10%)
requires significant computational effort. Nevertheless the accuracy and reliability of
the assignment also depends on the input parameters the algorithm is provided with.
In order to maximize the probability that cell distribution among available PCUs will be
as even as predicted and thus load of PCUs and on Gb interface will be balanced it is
necessary to configure the number of PDCHs per cell accordingly to the actual
amount of PS traffic produced in the cell (rather than e.g. to assume the same
amount of PDCHs per each cell regardless of the PS traffic volume within the cell).

Rule 1-1: Configuration of the parameters related to the load balancing
Number of PDCHs per cell: must reflect the actual PS traffic per cell (i.e. should
be obtained from radio planning)
Number of timeslots on Gb interface per PCU: equal distribution is recommended
(if each PCU has the same amount of timeslots on Gb then all PCUs have an
equal load to share).
The remaining parameters: are obtained from DB.

The examples below show advantages of the configuration given by Rule 1-1.
Let us assume there are 7 GPRS cells enabled. One of them (PTPPKF0) is located in
the area where (E)GPRS traffic is commonly used (e.g. center of city, business area)
while in the remaining ones (E)GPRS traffic is small (e.g. 5 times smaller than in the
business area). Furthermore 2 PCUs are installed in the BSC to handle PS traffic
produced by these 7 cells. Below please see the calculation steps executed by the
load balancing algorithm depending on configuration of the parameters related to the
algorithm.
Case 1. Configuration of the PDCHs per cell independent from PS traffic handled by
cells
PTPw(0) = PTPw(1) = PTPw(2) = PTPw(3) = PTPw(4) = PTPw(5) = PTPw(6) = 5

2
It is clear that fully homogenous distribution happens rarely. Therefore certain spare capacity (safety margin)
is considered during Gb interface dimensioning to ensure sufficient bandwidth on Frame Relay links (the uneven
distribution might be critical in case of Gb over FR).
14
PCU dimensioning
PCUband(0) = PCUband(1) = 5 (equal distribution of load on Gb interface assumed)
Since both PCUs are expected to share the same load their targets are (cf. Equation
1): PCUw_target(0) = PCUw_target(1) = 5 (5 + 5 + 5 + 5 + 5 + 5 + 5) / (5 + 5) = 17.5

Step1:
PTPPKF0 (the most loaded one) is assigned to PCU0, the remaining cells are
assigned to PCU1
Calculation steps:
cf. Equation 2
PCU_weight(0) = 5
PCU_weight(1) = 30
cf. Equation 3
Delta(0) = -12.5 => PCU_d
Delta(1) = 12.5 => PCU_s
cf. Equation 4 and Equation 5
any of cells currently assigned to PCU(1) can be marked as PTP_target
because each of them has the same weight which is less than or equal to
Delta (i.e. PTPw = 5 Delta(s) = 13.5) and at the same time:
DeltaPercentage = 12.5 100 / 17.5 = 71% (i.e. more than 10%)
Decision: one of cells originally assigned to PCU_s (PCU1) will be randomly
moved to PCU_d (PCU0), e.g. PTPPKF(1).
The target has not been fulfilled yet but more favorable (i.e. leading to smaller
value of DeltaPercentage) distribution is still possible. Thus all PCU weights
and deltas are recalculated and the whole procedure is repeated.
Step2:
PTPPKF0 (the most loaded one) and PTPPKF1 are assigned to PCU0, the remaining
5 cells are still assigned to PCU1
Calculation steps:
cf. Equation 2
PCU_weight(0) = 10
PCU_weight(1) = 25
cf. Equation 3
Delta(0) = -7.5 => PCU_d
Delta(1) = 7.5 => PCU_s
any of cells currently assigned to PCU(1) can be marked as PTP_target
because each of them has the same weight which is less than or equal to
Delta (i.e. PTPw = 5 Delta(s) = 7.5) and at the same time:
15
PCU dimensioning
Decision: one of cells originally assigned to PCU_s (PCU1) will be randomly
moved to PCU_d (PCU0), e.g. PTPPKF(2).
The target has not been fulfilled yet but more favorable (i.e. leading to smaller
value of DeltaPercentage) distribution is still possible. Thus all PCU weights
and deltas are recalculated and the whole procedure is repeated.
Step3:
PTPPKF0 (the most loaded one), PTPPKF1 and PTTPKF2 are assigned to PCU0, the
remaining 4 cells are still assigned to PCU1
Calculation steps:
cf. Equation 2
PCU_weight(0) = 15
PCU_weight(1) = 20
cf. Equation 3
Delta(0) = -2.5 => PCU_d
Delta(1) = 2.5 => PCU_s
none of cells currently assigned to PCU(1) can be marked as PTP_target
because each of them has the same weight which is now greater than Delta
(i.e. PTPw = 5 > Delta(s) = 2.5) and at the same time:
Decision: the system is balanced, no more steps is needed.
The target is not fulfilled but the lower value of DeltaPercentage is not
possible and thus the assignment achieved in Step3 is maintained.
Note:
None of distribution is optimal, because PTPPKF0 will never be
recognized by the algorithm as the one producing significantly more load
than the others. It means that the PCU, which PTPPKF0 is assigned to,
will always carry more traffic than the second PCU. This can next lead to
uneven traffic distribution also within Gb interface and in the worst case
to temporary indication of PCU overload and quality degradation on Gb
interface.

Case 2. Configuration of the PDCHs per cell reflecting the actual PS traffic handled
by cells
PTPw(0) = 5, PTPw(1) = PTPw(2) = PTPw(3) = PTPw(4) = PTPw(5) = PTPw(6) = 1
PCUband(0) = PCUband(1) = 5 (equal distribution of load on Gb interface assumed)
Since both PCUs are expected to share the same load their targets are (cf. Equation
1): PCUw_target(0) = PCUw_target(1) = 5 (5 + 1 + 1 + 1 + 1 + 1 + 1) / (5 + 5) = 5.5

Step1:
16
PCU dimensioning
PTPPKF0 (the most loaded one) is assigned to PCU0, the remaining cells are
assigned to PCU1
Calculation steps:
cf. Equation 2
PCU_weight(0) = 5
PCU_weight(1) = 6
cf. Equation 3
Delta(0) = -0.5 => PCU_d
Delta(1) = 0.5 => PCU_s
none of cells currently assigned to PCU(1) needs to be marked as PTP_target
because each of them has the same weight which is greater than Delta (i.e.
PTPw = 1 > Delta(s) = 0.5) and at the same time:
DeltaPercentage = 0.5 100 / 5.5 = 9% (i.e. less than 10%)
Decision: the system is balanced, no more steps is needed.
The target has been fulfilled and thus the assignment is maintained.

The examples above (Case 2) show clearly that the algorithm can only interpret
properly the weight of cells (and make homogenous distribution of cells) when the
number of PDCHs per cell really reflects the actual PS traffic in the cell. Otherwise
(Case 1) distribution is done fully randomly and even though from algorithm point of
view cells are distributed in optimum way, the difference in PCU load may be really
considerable.

Obviously it is difficult to derive from offer tools an expected PS traffic volume per cell
basis. However this is not a problem since for offer dimensioning homogenous traffic
distribution can be (and shall be) assumed.
For real network the PS traffic volume per cell can be evaluated by means of PM
counters. Measured values can be then inputs for the optimization of the number of
PDCHs per cell which can have an impact even on end-to-end network performance.
It means that high performance of cellular networks carrying PS traffic can be only
ensured when requirements related to dimensioning as well as configuration and
optimization are met at the same time.
1.2.4 Relationship to database parameters
The table below gives an overview about mapping of parameters relevant for load
balancing algorithm into database objects and attributes.
relevant input DB parameter
(object)
short description
#configured PCUs PCU The PCU functional object
represents the Packet Control Unit.
17
PCU dimensioning
relevant input DB parameter short description
(object)
The creation of PCU object implies
autocreation of HMOs modeling BSC
board responsible for handling of
PCU functionality.
#configured GPRS cells PTPPKF The PTPPKF functional object
enables (and represents) the Point
To Point PacKet transFer in the cell.
In order to enable PTPPKF in a cell,
its parent instances BTS (cell) and
BTSM (site) must be created first.
#configured channels for
PS services:
packet control
channels;
reserved packet
traffic channels;
dynamic (shared)
packet traffic
channels;
GDCH (CHAN)

GMANPRESPRM
EMANPRESPRM
GMANPRESCOM
EMANPRESCOM
(PTPPKF)

GPDPDTCHA
(PTPPKF)
The GDCH (GPRS Dedicated
CHannel) attribute enables creation
of packet control channels (when set
either to PBCCH or to PCCCH) or
dynamic packet traffic channels
(when set to NULL). The number of
CHAN configured as PBCCH or
PCCCH determines the number of
packet control channels.
The set of parameters
GMANPRESxxx / EMANPRESxxx is
used to define maximum number of
PDCHs reserved for GPRS and
EDGE, respectively. The suffixes
PRM and COM are used to
distinguish between primary (PRM)
and complementary (COM) areas.
Such distinction is only related to
extended cells where PRM and COM
areas are mapped into far and near
areas, respectively. For standard
and dual-band standard cells the
attributes with suffix COM are
irrelevant.
The GPDPDTCHA (GPRS
percentage of dynamic PDTCH
available) determines the percentage
of these traffic channels (GDCH set
to NULL) that can be used for both
CS traffic and PS traffic.
#timeslots reserved on Gb

GTS (FRL)

The GPRS timeslot (GTS) defines
the bandwidth expressed in terms of
timeslots reserved for the FRL either
18
PCU dimensioning
relevant input DB parameter short description
(object)

PCUID (FRL)

on PCMG or on PCMA (depending
on setting of GLK).
The PCU identifier (PCUID)
indicates the PCU, which the FRL is
related to.
Routing Area

RACODE
(PTPPKF)

RACOL
(PTPPKF)
Routing Area numbering (RACODE)
is not unique within the whole
network, but it is unique within the
Location Area. Therefore two
identifiers are necessary to define
unambiguously the RA.
The Routing Area Code (RACODE)
identifies RA the cell belongs to
inside the given Location Area.
The Routing Area Colour (RACOL) is
a way to distinguish different RA on
air interface.
Table 1-2: mapping of planning parameters related to load balancing algorithm
into DB attributes

The examples below show how to evaluate the number of configured GPRS channels
on radio interface and on Gb interface.

Example 1: radio interface
Let us consider a cell with 3 TRXs, MAINBCCH (non-combined) configuration and 1
channel for SDCCH. If PS services are supported by all TRXs, the total number of
timeslots available for CS and PS traffic is 22.
Assuming the following settings of parameters reported in Table 1-2:
GDCH = PBCCH (for 1 CHAN object, i.e. 1 packet control channel activated)
GMANSPRESPRM = 1,
GPDPDTCHA = 50 (i.e. 50%),
the maximum number (NMAX) of GPRS channels shared with CS services is
calculated as follows:
( ) [ ] 100 / GPDPDTCHA MANSPRES GDCH NCHAN
NMAX
+
Equation 7
where:
NCHAN total number of channels available in cell per CS and PS services,
GDCH total number of packet control channels per cell (sum of GDCH
configured as PBCCH and PCCCH)
19
PCU dimensioning
MANSPRES total number of reserved packet traffic channels per cell (sum of
GMANSPRESPRM, EMANSPRESPRM, GMANSPRESCOM and
EMANSPRESCOM)
GPDPDTCHA percentage of CHANs that can be shared between TCHs and PDCHs
(the calculated value is rounded down)

Applying the values assumed in the Example1 the maximum number of dynamic
packet traffic channels is of:
NMAX = [22 (1+1)] * 50 / 100 = 10
Therefore in this cell we will have:
1 packet control channel (single PBCCH defined by means of GDCH),
1 reserved traffic control channel (defined by means of GMANSPRESPRM),
10 shared CS / PS traffic channels (computed by means of Equation 7),
10 = 22 (1 + 1 + 10) traffic channels dedicated for CS only.

The parameter PTPw() which is considered in Equation 1 in this case is equal to 12
(sum of 1 packet control channel, 1 reserved packet traffic channel and 10 shared
packet traffic channels).

Example 2. Gb interface
Let us consider a PCU having 2 Frame Relay links created. They are configured as
follows (only the relevant attributes are reported below):
FRL:0, PCUID=PCU:0, GLK = PCMG:0,
GTS = 1&2&3&4&5&6&7&8&9&10&11&12&13&14&15&16&17&18,
FRL:1, PCUID=PCU:0, GLK = PCMG:1,
GTS = 1&2&3&4&5&6&7&8&9&10&11&12&13&14&15&16&17&18,
So the number of the timeslots reserved per PCU on Gb interface can be evaluated by
means of the following formula:
( )
1 N
0 i
i : FRL GTS () GTS _ PCU Equation 8
where:
GTS(FRL:i) number of GPRS timeslots (GTS) created on Gb interface per i-th FRL,
N number of FRLs per PCU (note that indices usually start from 0, if
counted from 1 then the upper limit of the sum shall be N rather than
N 1)

Applying the values assumed in the Example 2 the number of timeslots reserved per
PCU on Gb interface:
PCUband() = 18 + 18 = 36
The value computed by means of Equation 8 is then directly used in Equation 1.
20
PCU dimensioning
1.3 PCU redundancy concept
PCU modules which are installed in High Capacity BSC platform (BSC/72, BSC/120,
eBSC) use load balancing to assign cells among PCUs and to control PCU load also
in the event of PCU outage (i.e. for redundancy purposes): during normal operation
state, all installed modules serve the incoming traffic which is distributed between
them in such a way to achieve (as far as possible) equal load. In the event of
breakdown of any HW module the system aims in redistribution of the traffic originally
handled by the faulty module among the remaining working modules. This is only
possible if working modules have enough spare capacity (in normal operation
conditions) to take over traffic supposed to be handled by the failed module.
Therefore to fully exploit load balancing advantages it is necessary to take its
attributes into account during dimensioning and planning of the system. In particular it
means that the modules should not be planned to the upper bound because in case
of outage no traffic can be taken over by the remaining modules. Another technique
which is commonly used during capacity planning of HW modules working with load
balancing is over-provisioning. Please refer to chapter 2 for further information.

21
PCU dimensioning
2 PCU dimensioning approach
The number of PCUs is determined by the number of PDTs required on Abis interface.
The minimum number of active PCUs can be expressed by means of the following
formula:
1
1
1
PCU , PDT
BSC , PDT
BSC , PCU
N
N
N Equation 9
where:
N
PDT,BSC
the number of Packet Data Terminals to be handled by the particular
BSC
N
PDT,PCU
the number of Packet Data Terminals that can be handled by the single
PCU (depends on PCU realization, see Table 1-1 for details)

The way in which the number of PDTs per BSC is computed mainly depends on
allocation strategy of Abis resources: basically two cases are possible i.e. static or
dynamic strategy. Please refer to chapter 2.1 for explanations how to proceed in each
case.
In the formula above N
PCU,BSC
denotes the number of active PCUs, i.e. those which
must be installed in the BSC to process PS traffic transmitted by PDTs during normal
working condition. Besides, it is necessary to reserve some additional HW modules for
the purpose of:
- redundancy,
- NS layer configuration.
In High Capacity BSC platform the PCU is realized by means of PPXU or UPM
boards. PS load is shared among all installed boards what guarantees that no traffic
is lost during outage of a board only if the remaining boards have enough free
resources (i.e. are not fully loaded) to take over the traffic originally assigned to the
PCU that becomes faulty. Therefore, for more conservative planning where high
reliability of network is expected, 1 more PCU (in comparison with dimensioning result
achieved with Equation 9) is installed to ensure that even during outage of a single
board the remaining ones will have enough space to take over the traffic. Obviously,
installation of an extra PCU increases network cost, besides it can be only taken into
consideration if there is enough space for another PCU available in the BSC.
In other cases, e.g. mainly when cost attractive offer is expected (even running the
risk of loosing some traffic in case of PCU outage), the actual number of PCUs
(according to Equation 9) may be installed.
Hence over-provisioning can be and in fact is quite often used to improve network
reliability. For more conservative approach even certain PCU utilization rate can be
assumed (e.g. 70% 80%) to efficiently cope with unexpected traffic peaks.
Please refer to the remark next to Table 1-1 for summary about impact of NS layer
configuration on the number of PCU boards installed.
22
PCU dimensioning

2.1 Abis dimensioning for PS resources

As abovementioned, the way in which the number of PDTs per BSC (N
PDT,BSC
) is
computed depends on Abis allocation strategy:
static allocation of Abis (standard PCU frames in use):
BSC , PDCH BSC , PDT
N N Equation 10
where:
N
PDCH,BSC
the total number of PDCHs (dedicated and shared) created in
BSC area
Standard PCU frames were the only option on early stage of GPRS networks
development (i.e. before BR7.0). However, also nowadays they can be in use
(instead of concatenated frames, see below for details) in networks where there
is no interest in having of higher CSs (i.e. CS3 and CS4) as well as MCSs (due
to e.g. small PS traffic). In such scenarios usage of standard PCU frames allows
to save Abis resources because when CS3/CS4 and MCSs are all disabled then
1:1 relation between channels carrying PS traffic on Um-IF and on Abis still
exists and Equation 10 can be used.

static allocation of Abis, BR7.0 and later SW releases (concatenated PCU
frames in use):
Introduction of higher GPRS CSs and EDGE entails usage of concatenated
PCU frames rather than standard ones as a single Abis sub-channel is not
sufficient to transmit the amount of PS traffic delivered by a single PDCH
carrying high (M)CS. In maximum 5 PDTs is required to support the MCS-8 /
MCS-9. In order to assign several (i.e. up to 5) PDTs to a single PDCH the
standard PCU frame must be replaced with concatenated PCU frames. The
concatenated PCU frames allow to map the content of the single PDU, which
can not be transmitted over a single PDT because of the PDT gross capacity
limitation (320 bits sent every 20 ms), to appropriate amount of PDTs. The table
below gives an overview about how many PDTs is required per PDCH
depending on the (M)CS:
N
PDT,PDCH
coding
scheme
technology size of RLC/MAC
block = user bits +
spare bits + header
net / gross
PDCH data
rate [kbps] BR6.0 BR7.0
CS-1 GPRS 160 + 0 + 24 8.0 / 9.2 1 1
CS-2 GPRS 240 + 7 + 24 12.0 / 13.6 1 2
CS-3 GPRS 288 + 3 + 24 14.4 / 15.8 2
CS-4 GPRS 400 + 7 + 24 20.0 / 21.6 2
MCS-1 EDGE 176 + 2 + 31 08.8 / 10.5 1
MCS-2 EDGE 224 + 2 + 31 11.2 / 12.9 2
MCS-3 EDGE 296 + 2 + 31 14.8 / 16.5 2
MCS-4 EDGE 352 + 2 + 31 17.6 / 19.3 2
MCS-5 EDGE 448 + 2 + 37 22.4 / 24.4
not
applicable
2
23
PCU dimensioning
N
PDT,PDCH
coding
scheme
technology size of RLC/MAC net / gross
block = user bits + PDCH data
spare bits + header rate [kbps] BR6.0 BR7.0
MCS-6 EDGE 592 + 2 + 37 29.6 / 31.6 3
MCS-7 EDGE 2*448 + 2*2 + 46 44.8 / 47.3 4
MCS-8 EDGE 2*544 + 2*2 + 46 54.4 / 56.9 5
MCS-9 EDGE 2*592 + 2*2 + 46 59.2 / 61.7 5
Table 2-1: the number of PDT per PDCH depending on (M)CS

Please note that concatenated PCU frames require 2 PDTs even for CS-2
(unless CS-3/CS-4 are disabled) although data throughput rate is less than 16
kbps. It is caused by the fact that PCU frames basically do not only carry the
content of the RLC/MAC blocks (i.e. user data and RLC/MAC header incl. 3 bits
spent for USF pre-coding) but also inband signaling and contribution of signaling
is quite considerable.
In comparison to the standard PCU frames, the concatenated ones contain even
more signalling information (e.g. sub-frame counter which allows the receiving
side PCU in UL or BTS in DL to reassemble the sub-frames to achieve the
original complete RLC/MAC block) which is always mapped into the header of
the 1st frame. Therefore the amount of payload bits that can be transmitted by
1st concatenated frame (216 user bits
3
) is less than the amount of payload
which is transmitted by a standard PCU frame (271 user bits) and in particular it
is insufficient to carry CS-2 (even though user perceivable throughput rate does
not exceed 16 kbit/s).

Hence the number of PDTs that would be required, to guarantee that each and
every created PDCH will always have enough Abis resources can be computed
by means of the formula below:
BSC , PDCHedge BSC , PDCHgprs BSC , PDT
N 5 N 2 N +
Equation 11
where:
N
PDCHgprs,BSC
the total number of PDCHs carrying GPRS traffic created in
BSC area (corresponds to the PDCHs created in cells where
EDGE is not enabled, i.e. EEDGE = FALSE),
N
PDCHedge,BSC
the total number of PDCHs carrying EDGE traffic created in
BSC area
e.g. let us assume that BSC supports e.g. 20 rural sites with 3 cells and 2
PDCHs per cell (only GPRS CSs are in use) and e.g. 25 urban sites with 3 cells
and 4 PDCH per cell (and EDGE MCS enabled). Then, the number of PDTs,
would be of: 2 (20 3 2) + 5 (25 3 4) = 1740.
Please note that this is upper limit which is in practice never created due to non-
optimum Abis bandwidth consumption. For more pragmatic approach please
see below.

24
PCU dimensioning
dynamic allocation of Abis (FAAS, from BR7.0 on):
Static allocation of Abis resources is highly inefficient because in this mode 2 or
5 Abis sub-slots (for the cases without and with EDGE activated, respectively)
must be permanently reserved for each radio channel created. Usage of a
particular coding scheme is controlled by algorithm called Link Adaptation that
chooses automatically the best coding scheme depending on the prevailing
radio conditions. Therefore users who are in different radio conditions will
operate with different coding schemes and as a consequence not every user
may have coding scheme high enough to occupy max number of Abis
resources. Hence to avoid waste of Abis resources a dynamic allocation
strategy is introduced where the system assigns dynamically the number of Abis
sub-slots which is appropriate to a particular call. In such case a common pool
of resources is reserved per site (BTSE) and these resources are shared
between CS and PS calls initiated in any of cells housed and managed by the
BTSE.
For this reason, in case of flexible Abis allocation strategy (FAAS), an analytical
approach to evaluate N
PDT,BSC
is not sufficient either and stochastic
considerations need to be done instead. As a result, depending on how big is
acceptable Abis blocking rate and what are the average propagation conditions,
in average less than 5 Abis sub-slots per PDCH can be reserved.
In order to evaluate the amount of resources that must be reserved on Abis for
PS traffic two aspects must be combined: (1) the number of PDTs assigned to a
PDCH depends on probability of (M)CS usage, (2) all cells housed in a given
site (BTSE) dynamically share common pool of Abis resources reserved for that
site and thus statistical multiplexing of traffic produced by these cells is
observed and brings benefits in terms of bandwidth savings. For dimensioning
purposes an assumption is taken that both PS call arrival rate as well as service
time are described by exponential distribution. The modeling based on such
assumptions simplifies considerably calculation procedure nevertheless still
gives results which fit quite well to the reality. Application of probability theory
allows to find iteratively factor K that denotes the number of PDTs needed per
site (N
PDT,BTSE
) and is expressed by:

FAAS
N
1 i
i
B K B P
BTSE , cell
,
_
Equation 12
where:
BB
FAAS
blocking rate on Abis interface: due to lack of resources in Abis pool
the resources spent to handle ongoing calls are downgraded as a first
measure and finally an incoming calls are rejected if downgrade does
not solve the problem
BB

i
variable denoting sum of PDTs required by all PDCH created in the i-th
cell of the given site (BTSE), see below for further considerations

3
Note that the remaining concatenated PCU frames transmit 272 user bits.
25
PCU dimensioning
K factor denoting the number of PDT per site (N
PDT,BTSE
), outcome of the
Equation 12, it is incremented iteratively unless the inequality is
satisfied
N
cell,BTSE
Number of cells per site (BTSE)
P(x) probability for the event x

The B
i
variable is obviously defined as sum of contribution (in terms of the number of
PDT required per given PDCH when particular (M)CS is in use) of each PDCH created
in the whole site. The number of PDTs needed for particular PDCH is chosen based
on calculation of probabilities that particular PDCH needs k Abis sub-slots (k = 1, 2, 3,
4, 5). Due to calculation complexity these probabilities can be only computed using
numerical algorithm being part of dimensioning process. A detailed description of the
algorithm is out of scope for this document.
Below please find the results produced based on the following assumptions:
typical frequency re-use, average PDCH throughput of ~35 kbps
optimum (i.e. not necessarily default, for details please refer to chapter 3)
settings of TEMPCH/TEMPDT timers

0
5
10
15
20
25
30
35
40
45
50
55
1+1+1 2+2+2 3+3+3 4+4+4 5+5+5 6+6+6
PDCH/cell configuration
a
v
e
r
a
g
e

P
D
T

p
e
r

s
i
t
e
5 kbps/cell
10 kbit/cell
15 kbit/cell
20 kbit/cell
25 kbit/cell
33 kbit/cell
40 kbit/cell
45 kbit/cell
60 kbit/cell
PDT,BTSE
) for small and medium
cell configuration in terms of PDCH

26
PCU dimensioning
20
25
30
35
40
45
50
55
60
65
70
75
80
85
4+4+4 5+5+5 6+6+6 7+7+7 8+8+8 9+9+9 10+10+10 11+11+11 12+12+12
PDCH/cell configuration
a
v
e
r
a
g
e

P
D
T

p
e
r

s
i
t
e
15 kbit/cell
25 kbit/cell
40 kbit/cell
45 kbit/cell
60 kbit/cell
75 kbit/cell
100 kbit/cell
PDT,BTSE
) for medium and high cell
configuration in terms of PDCH

Please note that:
the results are sensitive to PS traffic per cell: for other traffic volumes than
those displayed in the graphs above the presented results can be extrapolated
the results are sensitive to average PDCH throughput: for values greater than
35 kbps less Abis resources are needed and vice versa
the results depend on many different factors therefore they should be treated
like evaluation which is subject to verification and optimization in real network
(please also refer to chapter Error! Reference source not found. for
indication which counters can be used to verify dimensioning results in the
real network)

Obviously, the last step is summing up contribution of each site (i.e. each Abis pool)
and calculation of the number of PDT needed per BSC:
BSC , BTSE
N
1 i
BTSE , PDT BSC , PDT
N N Equation 13
where:
N
PDT,BTSE
the number of PDTs per site; should be taken from Figure 2-1 or Figure
2-2 depending on cell configuration
N
BTSE,BSC
the number of sites with PS traffic per BSC

27
PCU dimensioning
The Equation 9 clearly shows that dimensioning of PDTs is crucial for PCU dimensioning
process. However, note that how many PDTs is eventually served per a PCU depends not
only on dimensioning result obtained from Equation 9 but also on the outcome of the cell
distribution among PCUs which is done by load balancing algorithm. For instance, if we have
1000 PDTs to handle and 5 PCUs installed including the over-provisioned one, it does not
necessarily mean that each PCU will serve 200 PDTs although homogenous distribution is
anticipated because the actual number of PDTs per PCU is determined by cell assignment.
But obviously as described in chapter 1.2.3 the closer relation of the number of PDCHs
configured per cell to the actual amount of PS traffic produced in the cell, the higher
probability that the cell distribution will be indeed homogenous.

Rule 2-1: Dimensioning vs. planning
The abovementioned methods allow to evaluate the number of PDTs and in
consequence the number of PCUs based on minimal set of inputs. Such
approach is usually chosen to make budgetary offers mainly during network
acquisition.
For implementation phase also additional information should be available and
thus needs to be taken into account, e.g. typical applications and services
supposed to run in the network, load of HW elements already installed, DB
settings, etc. Based on that additional planning activities are made to include
those additional inputs and dimensioning results may be subject to refinement.
The additional aspects that need to be included during planning process are
described in chapter 3.

2.2 Relationship to database parameters
After introduction of flexible allocation of Abis resources more parameters are involved
in mapping between radio and Abis resources than in case of static allocation. This is
due to (1) lack of fixed relationship between PDCHs and PDTs as well as (2) more
sophisticated redundancy and fault recovery mechanisms on Abis. Both features
namely dynamic allocation of Abis resources as well as load sharing and fault
recovery of LAPD links are reflected in Abis pool and Abis subpool concept. From
definition Abis pool denotes set of Abis subslots (represented by SUBTSLB attribute)
that can be shared by all cells in given BTSE for CS and PS calls, while Abis subpool
denotes subset of resources belonging to the given Abis pool which is supervised by
the single LAPD link (represented by LPDLM object). These definitions constitute the
following concept:
- each site has certain amount of Abis resources reserved to handle CS and PS
calls produced in any cell belonging to the given site (Abis pool)
- it is possible to create 1 or more LAPD links to supervise the resources bunched
together in a single Abis pool; the benefit of having more than 1 LAPD link per
Abis pool (i.e. the benefit of having more than one Abis subpool) is better
tolerance against LAPD link faults (due to e.g. PCM breakdown): when LPDLM
supervising certain Abis subpool becomes unavailable then all Abis resources
28
PCU dimensioning
being under supervision of that LPDLM becomes unavailable too as BSC
excludes them from the Abis pool; in such case, when another Abis subpool is
created (i.e. when another LPDLM is available to supervise other part of given
Abis pool), the traffic can be taken over by the second Abis subpool unless no
resources are free in the second Abis subpool; when faulty LPDLM comes back to
service the Abis resources supervised by the LAPD links come back to the service
too;
Abis pool can comprise one or more than one Abis subpools, in the latter these
subpools can be distributed over different PCMB lines to minimize the impact of PCM
line outage on availability of an Abis pool. Abis pool and subpool are indicated
implicitly by means of ASSLAPD attribute of SUBTSLB object. Each Abis sub-slot
(represented by SUBTSLB objects) has its ASSLAPD attribute which indicates
explicitly associated LAPD channel and subordinate site (by indication of their
instances numbers). In this way the relation between Abis sub-slot and BTSE is also
defined.

Rule 2-2: Setting up Abis pool and subpool (ASSLAPD attribute)
CREATE SUBTSLB: NAME=PCMB:x/TSLB:y/SUBTSLB:z,
ASSLAPD = BTSM:n/LPDLM:m
All SUBTSLBs (regardless of the PCMB instance number they are created on)
that contain the same BTSM no. in the ASSLAPD path make up the Abis pool of
the BTSM.
All SUBTSLBs that contain the same BTSM no. and the same LPDLM no. in the
ASSLAPD path, make up one Abis subpool for the BTSM, i.e. these SUBTSLBs
are that part of Abis resources reserved for the BTSM which are created on the
same PCMB and whose availability is supervised with the help of the same
LPDLM.

Note that BTSM, PCMB, LPDLM and SUBTSLB objects must be created before Abis
pool and subpool is set up.
The figure below explains the concept by showing different allocation possibilities:

29
PCU dimensioning
BTSM1
PCMB1
Abis pool
(composed of 6 sub-TSL)
related LAPD
This configuration has:
- Abis pool with 6 sub-TSL
- 1 LAPD link and 1 subpool (pools and subpools areas correspond each other)
- Note: PCMB1 is related to BTSM1
From DB perspective:
- CREATE SUBTSLB1: NAME=PCMB1/TSLB:1/SUBTSLB:1, ASSLAPD=BTSM:1/LPDLM:1
-
LPDLM1
BTSM1
PCMB1
LPDLM1
PCMB2
LPDLM2
Abis pool
(composed of 6 sub-TSL split among 2 E1 for redundancy)
- Abis pool split into 2 subpool
- particular subpools created in different E1
- Note: PCMB1 and PCMB2 are related to BTSM1
-
-
BTSM1
PCMB1
Abis pool
(composed of 6 sub-TSL)
related LAPD
- 1 LAPD link and 1 subpool (pools and subpools areas correspond each other)
- Note: PCMB1 is related to BTSM1
-
LPDLM1
BTSM1
PCMB1
LPDLM1
PCMB2
LPDLM2
Abis pool
(composed of 6 sub-TSL split among 2 E1 for redundancy)
- Abis pool split into 2 subpool
- particular subpools created in different E1
- Note: PCMB1 and PCMB2 are related to BTSM1
-
-
Figure 2-3: Abis pool and subpool concept

30
PCU dimensioning
3 PCU planning approach
Dimensioning rules given in chapter 2 allow to evaluate the amount of Abis resources
(and in consequence the number of PCU modules). However whether the results
obtained from dimensioning are achievable or not in the field depends very much on
other aspects that can be hardly incorporated into dimensioning phase and thus must
be taken into consideration during implementation planning. These additional aspects
include careful evaluation at least of:
- radio/Abis channels release strategy,
- initial coding schemes determination strategy,
- MS allocation strategy,
- TBF release strategy.
Besides, the evaluation of the abovementioned aspects must be done in the context of
predominant application which is expected to run in the given network. Due to huge
variety of commercially available PS applications it is not easy either to anticipate the
most commonly used one in advance or to make detailed analyses (e.g. by means of
simulations) of system behaviour for each possible one. Therefore certain
simplifications must be taken during network planning which is actually in case of PS
domain an iterative process with some optimization activities aiming at achievement
better and better accuracy in each step rather than a compact procedure with
straightforward analytical formulae. Hence, at least two extreme applications must be
defined which further considerations will be led for:
- an http-like applications (which can be considered as a typical one) with typical
data volume per transaction of several hundreds bytes up to single hundreds of
kilobytes, time between packets of single hundreds of milliseconds and TBF
serving time of several seconds; such applications will be hereafter throughout the
document referred to as a regular traffic
- a chat-like applications (which can be considered as a demanding one) with
average data volume per transaction of several bytes up to a single hundreds of
bytes, time between packets of several seconds and TBF serving time of some
hundreds of milliseconds; such applications will be hereafter throughout the
document referred to as a bursty traffic
Impact of these both applications types on planning aspects mentioned above will be
then evaluated in the next paragraphs.
3.1 Impact of PS channels release strategy
In order to satisfy incoming PS call requests it is necessary to grant resources on
radio and Abis interfaces (also on Gb interface, however Gb interface is purely
dedicated for PS traffic while radio/Abis resources are shared between CS and PS
calls). The existing channel allocation algorithm aims at an allocation that would allow
to maximize the (average) throughput and to minimize the amount of resources used
(in average) for PS data traffic. Tasks related to channel assignment are split between
PCU and TDPC/AP:
31
PCU dimensioning
- PCU receives the request for PS resources, calculates the number of PDCHs,
looks for resources and either serves the request by itself (when already
established resources are not fully loaded then incoming TBF can be multiplexed)
or sends TDPC/AP request for additional resources;
- TDPC/AP is involved when PCU can not handle the incoming request by means of
already established resources. In such case TDPC/AP needs to check whether
any other resources that can be used for PS traffic are available and if so they are
used. The last resort is an attempt to either downgrade the running transmission
or to release any resources which are still kept open but are no longer in use. If
these activities are not successful either, then the request needs to be rejected
which leads to increase of TBF blocking rate. It goes without saying that execution
of all these steps puts also additional effort onto TDPC/AP which is related to e.g.
queuing of the requests which resources are searched for.
The split of responsibilities between PCU and TDPC/AP is shown in the figure below.

D
k
j
f
g
h
j
f
h
g
j
f
d
s
k
D
a
f
h
g
h
d
s
g
calculate the required
number of PDCH/PDT
MS/SGSN request
are new
PDCHs needed?
are new
PDTs needed?
are additional
resources available?
is downgrade/release
of any resources
possible?
reject the request
channel assignment
yes
yes
no
no
no
no
yes
yes
PCU
algorithm
TDPC
algorithm
number of PDCH/PDT
number of PDCH/PDT
MS/SGSN request MS/SGSN request
are new
PDCHs needed?
are new
PDCHs needed?
are new
PDTs needed?
are new
PDTs needed?
are additional
are additional
of any resources
possible?
reject the request reject the request
channel assignment
yes
yes
no
no
no
no
yes
yes
PCU
algorithm
TDPC
algorithm
Figure 3-1: overview on PCU and TDPC/AP activities during PS channel
allocation

The concept of packet channels management described above aims at limited
involvement of TDPC/AP into PS channel allocation. Such approach allows to
minimize impact of PS traffic on TDPC/AP load. This is necessary as TDPC/AP is
32
PCU dimensioning
unavoidably involved in processing of each CS call and thus TDPC/AP involvement in
each PS call would result in degradation of CS capacity of the whole BSC. Thus
TDPC/AP capacity can be saved thanks to keeping already established PS resources
(PDCH, PDT) for some time after transmission of payload is completed in order to re-
use these resources by newly incoming PS requests coming from the same cell
without any further involvement from TDPC/AP. The time for which the resources are
kept is user defined and controlled by means of adjustable timers.
This approach has obviously pros and cons. On one hand, TDPC/AP is not involved in
processing of each and every PS call (what is the case for CS traffic) and thus the
impact of PS traffic on TDPC/AP load is (almost) negligible. On the other hand, the
resources may be kept unused for some time and they will not be available for other
requests coming from other cells. Therefore setting of times for which PS resources
are kept is a trade-off between consumption of TDPC/AP load and TBF blocking rates.

Rule 3-1: TEMPCH/TEMPPDT timers
Timers which allow to keep PS resources for some time after completion of
payload transfer to minimize TDPC/AP load are configurable by means of
database parameters related to CPCU object TEMPCH and TEMPPDT for radio
and Abis interfaces, respectively.

TEMPCH attribute allows to define the delay time for the release of an allocated
PDCH if there are no TBF activities. The timer is started on the stop of the last TBF
and keeps the allocated TCH activated to serve possible new TBFs. The purpose of
this timer is to avoid continuous channel allocation requests from the PCU to the
TDPC/AP. Until the timer lasts, the established PDCH is still regarded as allocated
one and can immediately take over a new TBF coming from the same cell even if it is
not used for the transfer of payload at the moment.
TEMPDT attribute allows to define the delay time for the release of an allocated
PDT(s) if the related PDCH does not require this PDT anymore (e.g. due to a
downgrade of the used coding scheme, note that 1 PDT per PDCH
4
is kept also after
expiration of TEMPDT as long as TEMPCH lasts cf. partial Abis release vs.
complete Abis release in Figure 3-2). TEMPDT is equivalent parameter to TEMPCH
so its meaning and role for Abis resources are analogical to those of TEMPCH for
radio interface.
Default values of TEMPCH and TEMPDT are 30s and 15s, respectively. These
defaults fit much better to the scenario when predominant application running in the
network is of regular traffic type for which probability of occurrence consecutive
packets within 30s is relatively high. On the other hand, for applications that produce
bursty traffic, the default setting of the TEMPCH/TEMPDT timers is unfavourable. The
Figure 3-2 depicts the effect which is observed is such a case (i.e. default settings of
TEMPCH/TEMPDT timers and bursty traffic in the network). Please note, that
resources (both on radio and Abis interfaces) are physically occupied only for a small
fraction of second while they are blocked for requests coming from different cells for
30s. This is highly inefficient and it leads to the situation that statistics show
33
PCU dimensioning
considerable TBF blocking rate and very small amount of transmitted data at the same
time.

PDCH
Abis/PDT
Time
Abis/PDT
assignment
PDCH
deactivation
User data
transm.
TDPC
load
TBF request
from MS (UL)
or SGSN (DL)
2
0
0
m
s
small object to be transmitted
(bursty traffic-like application)
delayed TBF rel.
default: 1500ms
TEMPDT
default: 15s
TEMPCH
default: 30s
Partial Abis /
PDT release
Complete Abis /
PDT release
PDCH activation
+ assignment
TBF
release
Abis/PDT remain assigned to PDCH and
can thus be used for a new TBF in same
cell but appear blocked for other cells
PDCH still active but idle
PDCH
Abis/PDT
Time
Abis/PDT
assignment
PDCH
deactivation
User data
transm.
TDPC
load
TBF request
from MS (UL)
or SGSN (DL)
2
0
0
m
s
small object to be transmitted
(bursty traffic-like application)
delayed TBF rel.
default: 1500ms
TEMPDT
default: 15s
TEMPCH
default: 30s
Partial Abis /
PDT release
Complete Abis /
PDT release
PDCH activation
+ assignment
TBF
release
Abis/PDT remain assigned to PDCH and
can thus be used for a new TBF in same
cell but appear blocked for other cells
PDCH still active but idle

Figure 3-2: PS channel allocation and release (an example for default settings of
TEMPCH/TEMPDT timers and burst traffic in the network)

Field experiences show that, when bursty traffic is predominating, a careful
reduction of TEMPCH/TEMPDT timers to smaller values can improve the situation.
Please note that any modification of TEMPCH/TEMPDT timers must be done stepwise
with constant control of TDPC/AP load in order to avoid BSC overload.

Rule 3-2: Relation between TEMPCH and TEMPDT
It does not make any sense to keep Abis resources longer than radio ones so it
must be always ensured that TEMPCH > TEMPDT

3.2 Impact of initial coding schemes selection strategy
User can define, per PS cell basis, initial coding schemes for GPRS and EGPRS.
Setting of these parameters affects both the number of PDCHs the system is trying to
assign as well as the number of PDTs to be initially reserved per PDCH.

4
Actually 1 or 2 PDT per PDCH can be kept after expiration of TEMPDT depending on setting of BIT23 of
MNTBMASK (up to BR10) or setting of DB attribute of BSC object called EPDTRELI (from BR10 on).
34
PCU dimensioning
The impact of initial coding scheme on the number of PDCH is related to the way in
which PCU decides about how many radio resources are needed for incoming PS call.
Different methods are used by PCU to evaluate the number of PDCHs in BR releases
earlier than BR8.0 and from BR8.0 on.
Before BR8.0 the number of PDCHs is computed by means of the following formula:
( )

1
1
1
1
MS , MsCl
init CSinit ) M ( max,
MS , peak
N ;
BLER 1 r
r
max N Equation 14
where:
N initial number of PDCHs required to serve incoming PS request
r
peak,MS
peak throughput rate defined per user (the value is defined for each
MS is system and stored in HLR)
r
max,(M)CSinit
maximum throughput rate achievable per initial coding scheme (CS or
MCS, depending on whether GPRS or EGPRS is in use, cf. net PDCH
data rate reported in Table 2-1)
BLER
init
initial Block Error Rate; BLER is defined as the ratio of the number of
radio blocks to be repeated (i.e. not acknowledged blocks) to the
number of totally transmitted radio blocks (i.e. sum of the
acknowledged blocks and the not acknowledged ones).
N
MsCl,MS
the number of channels related to the MS multislot class capability

Please note that the information about the previously used coding scheme and BLER
value of a particular MS are stored for some time which is configurable (cf.
STGTTLLIINF attribute). When this information is no longer available (due to
expiration of STGTTLLIINF) then the system needs to retrieve the initial BLER and
initial coding scheme values from database. For this purpose the following attributes of
PTPPKF object are in use:
- INIBLER to define initial BLER value,
- INICSCH to define initial coding scheme and
- INIMCSDL to define initial DL MCS
5
.

In BR8.0 the method described by means of Equation 14 was modified to choose
initial number of radio resources in more optimal way. The best possible assignment
for given multislot capability is chosen by means of minimum square method (MSM).

Rule 3-3: Regression analysis
The MSM methods, generally known as regression analysis, are basically used to
model numerical data obtained from observations by adjusting the parameter(s)
of a model so as to get an optimal fit of the data.
The best fit is that instance of the model for which the sum of squared

5
In addition to that it is possible to define initial UL MCS by means of IMCSULGMSK and IMCSUL8PSK for
both types of modulations.
35
PCU dimensioning
residuals has its least value, a residual being the difference between an
observed/expected value (y) and the value given by the model (kF, where F
denotes independent variable constituting the model and k denotes a parameter
to be determined).
Mathematicians used the following formula to execute regression analysis:
( )

m
1 i
2
i i
F k y S

In this method PCU checks each possible configuration (according to the MS multislot
capability) and chooses as a result the one which leads to the minimum difference
between peak throughput rates defined per user on DL and UL (cf. r
peak,MS
in Equation
14) and the maximum throughput that can be achieved using certain amount of
PDCH transmitting data with given coding scheme and BLER, i.e. N r
max,(M)CSinit
(1-
BLER) (cf. N, r
max,(M)CSinit
, BLER
init
in Equation 14, respectively).
So the sum of squares to be minimized in this case is given by (cf. Rule 3-3):
( ) ( )
( ) ( )
2
UL
init
UL
CSinit ) M ( max,
UL UL
MS , peak
2
DL
init
DL
CSinit ) M ( max,
DL DL
MS , peak
BLER 1 r N r
BLER 1 r N r S
+
+
Equation 15
The system tries any possible combination of N
DL
and N
UL
and chooses the one which
correspond to the least value of the parameter S.
Current methods of PDCH evaluation are very much dependent of peak throughput
rate defined per user (which can be actually treated as hardcoded parameter because
it is part of user profile stored in the HLR). Therefore the parameter is commonly set to
rather high values to guarantee that user will achieve high throughput rates. However,
regardless of chosen peak throughput rates, the actual throughput rate per user
depend on many other factors e.g. MS allocation strategy (see chapter 3.3) and from
network performance point of view it is much better to have configurable dependency
between peak throughput rate and real traffic volume to be sent (which is strongly
connected to the predominant application: for regular traffic higher peak values are
expected while for bursty traffic smaller values are sufficient). Introduction of
possibility to adjust the relationship between peak throughput and payload to be
transmitted is upcoming and will be available from BR10 on, for more information refer
to chapter 4.3 (IDRA).

Default values of INICSCH and INIMCSDL (CS2 and MCS6, respectively) fit better to
the scenario with regular traffic. In such case higher MS throughput rates are justified
(and this may be also reflected in peak throughput rate defined per user), therefore
system will try to assign more PDCHs on radio and at the same time more PDTs
will be tried to be reserved per each PDCH on Abis interface. Please also note that in
scenario with regular traffic radio and Abis resources are not recommended to be
released immediately after completion of transmission and therefore the extremely
undesired case would be to assign too many resources (in comparison to the amount
36
PCU dimensioning
of data which is to be transmitted) and then to keep these resources unavailable for
other PS calls.
Another undesired effect related to setting of initial coding scheme is connected with
PCU behaviour when it operates close to its capacity limit. In such case, when new PS
call comes and several PDCHs are assigned to this call (to achieve high throughput)
the related amount of PDTs is trying to be allocated on Abis based on current settings
of the initial coding schemes. If PCU capacity is insufficient to allocate the required
amount of PDTs, then the following rules apply: as many as possible PDCHs are
assigned and they all get the same amount of PDTs. It may lead to certain reduction
of the throughput rate when less than requested PDTs are available.
In other words, when initial coding schemes are set to default (high) values also in
cells where bursty traffic dominates the Abis resources are unnecessarily consumed
by bursty traffic applications and in consequence are unavailable for other cells
assigned to the PCU where bursty traffic does not dominate and higher throughput
rate is required. Hence, for bursty traffic, it is more efficient when initial coding
schemes are set to the lowest values to save Abis resources (mainly Abis, as usage of
radio resources can be optimized mainly by tuning peak throughput rates).
Please also note that further benefits are observed after enabling possibility to use
only one downlink timeslot for GPRS Mobility Management (GMM) and Signaling
Management (SM) procedures (e.g. RA update, PDP context activation, attach, ).
Without the feature also those procedures can get several TS what leads to highly
inefficient utilization of resources (PDCH, PDT, PCU, ). The feature can be enabled:
- up to BR10 by means of BIT14 of maintenance bitmask,
- from BR10 on by means of DB attribute of BSC object called ESTSGMMSM.
3.3 Impact of MS allocation strategy
There are two possible MS allocation strategies: horizontal and vertical.
Horizontal strategy aims in achieving the highest possible throughput. In this strategy,
incoming PS calls are distributed among all available PDCHs to maximize the
throughput.

BCCH SDCCH PDCH1 PDCH2 PDCH3 PDCH4 PDCH5 PDCH6
MS1, 3 TS multislot capability MS2, 3 TS multislot capability
MS1, 3 TS multislot capability MS2, 3 TS multislot capability
Figure 3-3: an example of horizontal allocation: 2 users, each one occupy 3
PDCHs, Abis resources must be granted to 6 PDCHs

Vertical strategy tries to multiplex as many users as possible on each PDCH. In this
strategy high throughput rates can be hardly achieved, however the resources are
saved.
MS1
MS2
MS3
MS4
MS1
MS2
MS3
MS4

37
PCU dimensioning
Figure 3-4: an example of vertical allocation: 4 users multiplexed in 1 PDCH, the
remaining 5 PDCHs unused (can be e.g. preempted to extend CS capacity), Abis
resources must be granted to 1 PDCH only

Although the MS allocation strategy is related to the way in which particular MS are
allocated in TRX, it also clearly affects PDT consumption and, in consequence, PCU
usage. Therefore also MS allocation strategy should be also adjusted to the
predominant application. Here the rules are quite straightforward: regular traffic-
based applications require horizontal strategy while vertical strategy is much more
efficient for bursty traffic applications (selection of vertical strategy is crucial in
particular when bursty traffic application dominate in the network where the majority
of users have user peak throughput set to high values, cf. chapter 3.2).
Selection of MS allocation strategy is controllable by means of set of attributes:
GASTRTH / GASTRABISTH and GMANMSAL.
GASTRTH (GPRS allocation strategy thresholds) is an attribute of PTPPKF object
and allows to define the thresholds for the system to switch between horizontal and
vertical GPRS channel allocation.
GASTRABISTH (GPRS allocation strategy Abis thresholds) is an attribute of BTSM
objects and allows to define thresholds for the system to switch between horizontal
and vertical GPRS channel allocation depending on Abis load. Since the number of
Abis resources depends on how many PDCHs are assigned, therefore
GASTRABISTH can be also considered as threshold to stop/restore of PDCH
upgrading due to Abis scarcity.
GMANMSAL (GPRS maximum number of allocated MS) is an attribute of PTPPKF
object and allows to define the maximum number of user that can be multiplexed on
the single PDCH is the cell. Therefore the parameter is crucial when vertical allocation
is chosen. Please note that GMANMSAL attribute is only valid for releases earlier than
BR9.0.
3.4 Impact of TBF release strategy
The Temporary Block Flow (TBF) is the unidirectional physical connection between an
MS and a network. In order to set-up a TBF the proper amount of PDCHs must be
assigned. Therefore similar mechanisms consisting in keeping the existing TBF open
for the certain time even if transmission is suspended for a moment are introduced in
order to save PCU as well as TDPC/AP resources by avoiding repeatedly execution of
PDCH allocation and release whenever data transmission in the open TBF is
suspended (e.g. to fill up transmission buffers). Delaying of TBF release paradoxically
leads to faster transmission of packets (especially the bigger ones which required
several radio blocks) since no time is lost for re-establishment of all involved
resources after every short inactivity of the TBF.
It means that TBF release strategy also should be aligned with predominant
application as delayed release brings benefits mainly for applications producing
regular traffic while for those with bursty traffic it will additionally contribute to the
38
PCU dimensioning
times for which PDCH/PDT are kept without significant improvements. This is because
TEMPCH timer starts when the last TBF running on the PDCH is closed.
Times for which TBF release is delayed are adjustable by means of DB parameters
TIMEDTBFREL and TEXTULTBF for DL and UL TBFs, respectively. Both timers are
attributes of CPCU object. Their default values (i.e. 1.5 s) also fit better to applications
with regular traffic and for bursty traffic applications TBF delay times can be
decreased.
Besides, further benefits are observed after enabling of delayed TBF release for GMM
and SM procedures. The feature can be enabled:
- up to BR10 by means of BIT10 of maintenance bitmask,
- from BR10 on by means of DB attribute of CPCU object called
EDTBFRELGMMSM.

3.5 Summary of additional PCU planning aspects
The chapter briefly describes the planning issues that must be taken into account in
addition to dimensioning results. The chapter includes real project experiences and
allows to understand the impact of parameters related to the most important planning
aspects on system performance.
The table below gives summary on the aspects discussed in chapters above:
application type and main
characteristics:
regular bursty
- average packet length
- time between packets
- 500 1500 bytes
- hundreds of milliseconds
- several bytes
- several seconds
radio/Abis channels
release strategy:
default short release times
initial coding schemes default lower than default
MS allocation strategy horizontal vertical
TBF release strategy delayed DL / extended UL short release times
Table 3-1: summary of PCU planning aspects

Please note that modification of defaults must be always done carefully with constant
control of TDPC/AP as well as PCU real time load in order to avoid loss of BSC
stability and switch to overload state.

39
PCU dimensioning
4 BR10 improvements on PS traffic handling
Current PS traffic management in BSC has certain limitations in terms of flexibility that
restrict PS load control and in consequence may lead to measurable performance
degradation. Therefore set of improvements in the way in which PS traffic is handled
by BSC were prepared to relax those PCU limitations. Besides, further improvements
are related to the method used by PCU to evaluate the number of PDCHs required for
a particular PS request. The existing method is connected with user peak throughput
definition which is up to now application independent. So far the system is not able to
assess how much data is going to be transmitted (in DL) what significantly affects the
amount of assigned PDCHs, because for given user always the same peak
throughput is trying to be ensured regardless of the actual amount of data to be
transmitted which is very undesired effect.
Thus the following features are available from BR10 on:
- Modified PCU load balancing
- PCU capacity enhancements
- Improvement of DL Resource Allocation (IDRA)
The next paragraphs give brief description of the newly introduce functionality, typical
use cases and impact on planning.
4.1 Modified PCU load balancing
Without the feature cells are assigned to the PCUs by means of load balancing
algorithm. As already mentioned this distribution is performed fully automatically, user
is only responsible for provisioning of input parameters, some of them stem from
network configuration the other ones are derived from dimensioning (for details please
refer to Rule 1-1). The accuracy and quality of distribution cells between PCUs (and,
in consequence, PCU load) depend on exactness of inputs and the number of PDCH
per cell is the crucial one. If the created number of PDCH does not reflect the actual
cell load then the algorithm is not able to distinguish between cells with high and small
amount of PS traffic. In such case the amount of configured PDCH is not reliable
indicator of upcoming PS traffic and it leads to random rather than homogenous
distribution of cells among PCU and in consequence differences in PCU load may be
observed (cf. chapter 1.2.3). Besides, even if a cell(s) with high PS traffic is
recognized there are no means to force PCU to take over particular cells (so even
insertion of additional PCU does not necessarily mean that load will be better
balanced).
All of these deficiencies are expected to be overcome by introduction
of simple modifications of the load balancing algorithm (described in chapter 1.2).
In the modified algorithm a cell with PS traffic can be assigned manually to a PCU.
This is possible due to introduction of the new attribute which indicates explicitly the
PTPPKF group identification which shall be assigned only to a single PCU (statically in
legacy configuration, which means that PTPPKF group n is handled by PCU(n); or
40
PCU dimensioning
dynamically in Central NS configuration). The overall principles of load balancing
algorithm are maintained (purpose, triggering events,) which means that still:
- weights of all cells (i.e. those with manual assignment to a PCU defined and those
without) and all PCUs are computed to balance the load,
- modification of a transmission path cell-SGSN or PCU creation are only reasons
for cell re-assignment (cf. chapter 1.2.1),
- PCU overload still does not trigger cell re-assignment (however such
optimization can be done manually with the feature enabled by defining/changing
a PCU which the cell shall be assigned to).
Calculation steps the algorithm does in order to find the best possible assignment are
only slightly modified due to introduction of the feature, namely:
- cell assignment is done in two steps:
- in the first step, only the cells having preferred PCU defined are assigned
- in the second step, all cells unassigned are distributed automatically
- only cells which are not assigned manually to any PCU are subject to re-
distribution unless the PCU that is carrying the group becomes unavailable or the
communication with SGSN cannot be performed,
- some additional information must be included in the algorithm to distinguish
between static and dynamic components of PCU_weight as only dynamic
components are subject to optimization.
This modification of load balancing algorithm is expected to guarantee more ideal load
balancing as user has now possibility to adjust the assignment done automatically by
the system. However the feature does not protect against short-lasting PCU overload
due to sudden changes in traffic patterns or other dynamic modification. And for this
purpose a separate feature is available in BR10 namely Enhancement of PCU
capacity. For more information about Enhancements of PCU capacity please refer to
chapter 4.2.
Manual assignment of cells is controllable by means of PRPTPGID (Preferred Point-
to-Point group ID) attribute of PTPPKF object. Note that the attribute can be set to
NULL: in such case the cell will be dynamically assigned to one of the installed PCU
as well as may be subject to re-assignment on the basis of current PCU load situation
whenever load balancing is triggered for any reason.
4.2 Enhancement of PCU capacity
This feature is complementary to Modified PCU load balancing described above as it
allows to relax the limitation in terms of flexibility of PDT resources usage in the event
of PCU (temporary) congestion. Without the feature when PCU is fully loaded then a
newly incoming PS request can not be served
6
(what leads to performance
degradation due to increase of TBF blocking rate) even though other less loaded
PCU(s) is(are) available in BSC. This is due to lack of mechanism that would allow to

6
The incoming call is rejected even in the situation when ongoing calls are running with high coding schemes
what leads to usage several PDTs per each PDCH but no downgrade is done in such case.
41
PCU dimensioning
use the free resources of a less loaded PCU to take over the excessive traffic of the
congested (heavier loaded) PCU.
With the feature it is possible to overcome this limitation as it is possible to temporary
serve more PDTs than those locally available:
- in case of a PCU congestion it is possible to borrow some PDTs from less loaded
PCU,
- when a PCU occupation is low enough it is possible to lend some PDTs to
another PCU(s) suffering from (temporary) lack of Abis resources.
Enhancements of PCU capacity is a software feature which does not require any new
hardware modules and is applicable to both PPXUv2/TDPC as well as UPM/AP for cBSC
and eBSC platforms, respectively. The feature slightly modifies (TDPC/APs part) of PS
channel allocation algorithm:
- as long as less than 80% of PDT are busy the local resources are always in use
- if threshold of 80% is exceeded the TDPC/AP tries to satisfy incoming requests
with borrowed PDTs (if the PCU had lent some resources to other PCU, they are
regained beforehand any resources are borrowed)
- in the meantime, another newly introduced threshold called stop PDT upgrade for
congestion can be monitored: if it is exceeded then requests for PDT upgrade due
to link adaptation are ignored and additional PDTs are not allocated even if radio
conditions are good enough to do so; please note that this functionality is
configurable (i.e. can be disabled or enabled, in latter case the actual threshold
can be set) by means of DB attribute of CPCU object called
STPPDTUPGRCONG.

The figure below depicts changes in the TDPC/AP algorithm (cf. Figure 3-1) due to
introduction of the feature:

are additional
of any resources
possible, any PDT
already lent?
reject the request reject the request
channel assignment
no
no
yes
yes
TDPC
algorithm
PDT request PDT request
can some resources
be borrowed?
no
yes
42
PCU dimensioning

Figure 4-1: TDPC/AP algorithm with Enhancements of PCU capacity enabled

When decision is made to borrow PDTs from other PCU the best candidate is to be
found. The PCU where some PDTs can be borrowed from must fulfill some pre-requisites
as it must belong to the same CPCU pool and less of 80% of its resources can be in use.
From among PCUs that fulfill these requirements, based on real-time ranking held by
TDPC/AP, the one having at the same time the lowest number of cells statically assigned
(1st decision level) and the highest number of idle PDTs available (2nd decision level) is
chosen.
Thus the feature leads to benefits in terms of greater flexibility in PDT utilization as the
PS call attempt that cannot be handled by the PCU, which it is dedicated to, can be now
served by another PCU where free resources are still available. Therefore PCU blocking
situation is expected less likely to happen.
4.2.1 Interdependencies between BR10.0 PCU improvements: impact on
planning
Both PCU related features introduced in BR10 (i.e. Modified PCU load balancing and
Enhancement of PCU capacity) are expected to be beneficial in different scenarios.
However they were designed together, are mutually complementary and thus the most
common and efficient use case for these features would be to use both of them. These
features can play with some parameters by themselves (e.g. PCU-cell assignment)
provided that they are not restricted by unfavorable setting of relevant attributes (e.g.
Modified PCU load balancing allows to assign each cell manually, while Enhancements
of PCU capacity works more efficient when less cells is assigned manually). So only the
reasonable combination of both BR10 features may bring the expected benefits.
Therefore the following steps should be done in order to improve PCU load situation:
1) To review the relation between the number of PDCHs per cell and the actual PS
traffic produced in the cell. The higher traffic is generated in the cell the more PDCH
it shall have created. Cells with considerable difference in PS traffic must not have
the same amount of PDCH.
Please note that this action should result in more equal PCU load distribution even
without switching on Modified PCU load balancing and Enhancement of PCU capacity
or any additional features!
2) To recognize cells with the highest PS traffic and assigned them manually to chosen
PCUs. The remaining cells should not have any PCUs defined as they can be
distributed automatically in such a way to balance load.
Prerequisite: in each cell the number of PDCH must reflect the actual PS traffic.
3) If enough PCU will not have too many cells assigned manually, Enhancements of
PCU capacity feature will be able to easily find a good candidate for borrowing PDTs
in order to counteract against short lasting traffic peaks within the area managed by
the particular PCU.
Execution of these three steps should improve load control and allow to achieve well
balanced PCU load.
43
PCU dimensioning
4.3 Improvement of DL resources allocation method (IDRA)
Chapter 3.2 explains the way in which the number of radio resources required to transmit
PS data is computed. One of the parameters that are crucial to this calculation is MS
required peak throughput rate (cf. r
peak,MS
in Equation 14 and Equation 15) which is
defined per user, stored in core network and retrieved from there whenever given MS is
going to start transmission. This is a drawback of the algorithm because peak throughput
rate is usually chosen to relatively high values and what is actually the worst this
value does not depend at all on the amount of data to be transmitted. This leads to very
undesired effect as system is not able to distinguish between applications and the same
amount of resources are always tried to be allocated (for given user) regardless of the
actual amount of data.
This disadvantage of the algorithm is improved in BR10.0 by introduction of IDRA
method. IDRA, when enabled, decides what value of peak throughput should be used by
resource allocation algorithm (to be precise: IDRA defines used in
DL
MS , peak
r Equation 15):
either peak throughput rate available in users profile (usually set of high values) or a
symbolic value of 1 bps. The IDRA concept consists in periodical checking the amount of
data to be transmitted. The amount of data is expressed in terms of the number of RLC
octets queued in DL Transmission Buffer (also called LLC queue). Hence:
- if the number of RLC octets is below a configurable threshold (THIDRA) then the
resources required for the TBF are evaluated based on low peak throughput
requirement which aims at allocation of 1 PDCH for the PS call,
- if the number of RLC octets exceeds a configurable threshold (THIDRA) then the
resources required for the TBF are evaluated based on MS peak throughput
parameter which (usually) leads to allocation of several PDCH for the PS call.
The figure below depicts main principles of IDRA:
incoming
PS call
does number of RLC
octets exceed THIDRA?
number of PDCHs based on
MS peak throughput rate
=> n PDCHs possible
IDRA symbolic value
=> 1 PDCH most likely
channel assignment
TSIDRA starts
yes no
incoming
PS call
does number of RLC
=> n PDCHs possible
IDRA symbolic value
=> 1 PDCH most likely
channel assignment
TSIDRA starts
yes no

Figure 4-2: IDRA principles

Please note that IDRA algorithm also allows to reconfigure resources originally assigned
to the ongoing TBF. The double check of LLC queue for the ongoing TBF is triggered
periodically and the frequency of evaluation how many bytes are stored in LLC queue is
configurable by means of timer TSIDRA (which starts whenever number of PDCH is
44
PCU dimensioning
based on IDRA symbolic value, see the figure above). When TSIDRA expires then the
number of bytes stored in LLC queue is compared against THIDRA threshold: if the
number of queued bytes exceeds THIDRA then reconfiguration is triggered and number
of resources is re-computed based on MS peak throughput rate (which usually leads to
more than 1 PDCH per request). Note that only the number of octets that are kept in LLC
queue exactly in the event of TSIDRA expiry matters for the algorithm: even if the number
of queued octets exceeds the THIDRA permanently during TSIDRA running, no activities
are performed by the algorithm. These additional aspects are depicted in the figure
below:

ongoing
PS call
channel (re-)assignment
TSIDRA expires
does number of RLC
PDCH reconfiguration based on
=> n PDCHs possible
no reconfiguration executed,
the existing resources are still utilized
yes
yes
no
ongoing
PS call
TSIDRA expires
does number of RLC
=> n PDCHs possible
yes
yes
no
ongoing
PS call
TSIDRA expires
does number of RLC
=> n PDCHs possible
yes
yes
no
ongoing
PS call
TSIDRA expires
does number of RLC
=> n PDCHs possible
yes
yes
no

Figure 4-3: reconfiguration of allocated resources by means of IDRA

Please note that reconfiguration strategy depicted in the figure above is unidirectional, i.e.
IDRA can only switch from a single timeslot to multi timeslot configuration but not on the
other way round.

The feature is expected to bring significant benefits in terms of radio resource allocation.
With the feature, payload aware resource allocation becomes possible what would
improve performance of Abis interfaces too (and in consequence PCU blocking rate
should be also decreased as bursty traffic applications should much more rarely steal
resources needed by regular traffic-based applications).
The feature if enabled (by means of IDRAACT attribute of BSC) is basically controlled by
means of 2 attributes: IDRATH and IDRATSWITCH, both on CPCU basis.
IDRATH (IDRA threshold) allows to define the threshold which the number of octets
stored in the DL transmission buffer is compared with: IDRA symbolic value of 1 bps is
used as MS DL peak throughput rate during evaluation of required radio resources (cf.
chapter 3.2 and Equation 15) unless the threshold is exceeded.
IDRATSWITCH (IDRA Timer Switch) allows to define a time interval for which IDRA is
checking if resource allocation done previously is the optimum on: every IDRATSWITCH
45
PCU dimensioning
seconds, the algorithm re-checks the amount of payload octets stored in DL transmission
buffer and if it exceeds IDRATH (and single timeslot configuration was originally
achieved) then single timeslot configuration is switched to multi timeslot one. State of
LLC queue during lasting of IDRATSWITCH timer is completely meaningless for the
algorithm (i.e. even if IDRATH is exceeded the chosen configuration is retained).

Please note that similar mechanism as the one introduced by IDRA for DL resources is
already in use for UL resources allocation where system checks the amount of UL data
reported by the MS.
46
PCU dimensioning
5 PCU optimization based on PM counters
The existing counters (BR10) allow to make at least the following analyses that may
lead to trigger certain optimization activities:
double-check of PDT dimensioning results based on real network data,
indication of the need for PCU (or Abis pool) reconfiguration (i.e. due to
underestimation or overestimation during dimensioning)
indication of the need for (manual) cell re-distribution among PCUs installed
(i.e. due to non-optimal cell distribution)
indication of unfavorable setting of TEMPCH/TEMPDT timers
indication of the need for installation another PCU boards due to processing
capacity limits.

Double-check of PDT dimensioning results
This can be done by means of the following PM counters:
Abis Pool Distribution (ABISPDIS)
Abis Pool Supervision (ABISPSUP)
The following subcounters would be relevant for the analysis:
ABISPDIS[1]: single Abis subchannel usage rate for CS traffic ---> v
ABISPDIS[2]: single Abis subchannel usage rate for PS traffic ---> p
1
ABISPDIS[3]: concatenated Abis subchannels (2 16 kbps) usage rate ---> p
2
3
4
5
ABISPSUP[3]: mean number of allocated Abis subchannels ---> N

Mean number of PDTs active per j-th BTSM during the granularity period ( )
mean
BTSE , PDT
N
can be computed as:
,
_
+ + + + +

5 4 3 2 1
mean
BTSE , PDT
p 5 p 4 p 3 p 2 p v
v
1 N N Equation 16
Then, Equation 13 must be applied, to compute the total number of PDTs per BSC.
The final step is to compute the number of PCUs per BSC by means of Equation 9.

The following counters/KPIs are helpful to indicate the need for PCU or Abis pool
reconfiguration or the need for manual cell re-distribution among PCUs
installed:
Number of rejected PDCH assignments (UL/DL) per cause (REJPDASS)
47
PCU dimensioning
Number of degraded PDCH seizures (UL/DL) per cell (UNSPDCSE)
Min, max, mean number of used PDTs per PCU (NPDTPCU)
Min, max, mean number of borrowed PDTs per PCU (NPDTBOR)
Min, max, mean number of conferred PDTs per PCU (NPDTCONF)
KPI: Abis mean utilization, Abis peak utilization, PCU mean utilization

Based on different causes of TBF blocking rate (r
b
) or TBF downgrade rate (r
d
) it is
possible to recognize the need either to enlarge Abis pool:
] 6 ... 1 [ NUACATCL
] 10 , 9 , 2 , 1 [ UNSPDCSE
Abis _ raded deg _ TBF
] 15 ... 13 , 3 ... 1 [ REJPDASS
Abis _ blocking _ TBF
Equation 17

or the number of PCU:
] 12 , 11 , 4 , 3 [ UNSPDCSE
PDT _ raded deg _ TBF
] 18 ... 16 , 6 ... 4 [ REJPDASS
PDT _ blocking _ TBF
Equation 18

The number of rejected assignments and degraded seizures are divided by number of
attempted assignments (NUACATCL) to express blocking rates and degradation rates
in terms of percentage of attempts. The table below denotes the actual meaning of
used subcounters:
uplink downlink REJPDASS: Rejected PDCHs due to
1 13 for interactive services
2 14 for streaming services
3 15
lack of Abis subchannel available
for a TBF
for background services
6 18
lack of PDT at PCU available for a
TBF
uplink downlink UNSPDCSE: Degraded PDCHs seizures due to
2 10
lack of Abis subchannels
available for a TBF for background services
4 12
lack of PDT at PCU available for a
TBF
uplink downlink NUACATCL: Number of attempted PDCH assignments for a
TBF...
48
PCU dimensioning
3 6 for background services

Another set of counter allow to verify how often Enhancements of PCU capacity
feature is in use. So based on the amount of PDTs which are borrowed and lent it is
possible to evaluate if there is a need for manual cell re-distribution. Besides, there is
anther counter to observe PCU occupancy rate (i.e. number of used PDT). If different
PCUs have extremely different occupancy rates then it can be also interpreted as the
need for manual cell re-distribution (by means of Modified PCU load balancing). The
relevant measurements are:
NPDTPCU[3*n+1]: minimum number of used PDT by PCU n
NPDTPCU[3*n+2]: maximum number of used PDT by PCU n
NPDTPCU[3*n+3]: mean number of used PDT by PCU n
NPDTBOR[3*n+1]: minimum number of borrowed PDT by PCU n
NPDTBOR[3*n+2]: maximum number of borrowed PDT by PCU n
NPDTBOR[3*n+3]: mean number of borrowed PDT by PCU n
NPDTCONF[3*n+1]: minimum number of conferred (i.e. lent) PDT by PCU n
NPDTCONF[3*n+2]: maximum number of conferred (i.e. lent) PDT by PCU n
NPDTCONF[3*n+3]: mean number of conferred (i.e. lent) PDT by PCU n

NPDTPCU also allows to estimate average utilization of all PCUs installed what can
be used to recommend installation of another PCU (if average utilization is high):
[ ]
PCU , PDT BSC , PCU
n
N N
3 n 3 NPDTPCU
util _ mean _ PCU

Equation 19
where:
N
PCU,BSC
number of PCUs per BSC
N
PDT,PCU
number of PDT per PCU (256 per PPXU, 850 per UPM; certain
required utilization rate per PCU can be also assumed, e.g. 80%)

Please note that Equation 19 allows to compute an average PCU utilization so peaks
may be overlooked. Thus, even though low PCU utilization rates may be interpreted
as a advice to uninstall a PCU board and e.g. move it to another BSC, also peak
values and PCU processor loads (BSCPRCLD[3*n+7], BSCPRCLD[3*n+8],
BSCPRCLD[3*n+9]; where n denotes the PCU number) must be carefully check
before any PCU will be moved to another BSC.

There are also set of measurements that allow to assess whether size of Abis pool is
optimum. If Abis poll is too small then performance of PS traffic is mainly affected
49
PCU dimensioning
because CS takes precedence over PS in case of shortage of Abis pool resources. This
set of measurements can be done based on Abis Pool Supervision (ABISPSUP)
counters. The following subcounters would be relevant for Abis pool related analyses:
ABISPSUP[1]: mean number of defined Abis subchannels
ABISPSUP[2]: mean number of available Abis subchannels
ABISPSUP[3]: mean number of allocated Abis subchannels
ABISPSUP[4]: max number of allocated Abis subchannels
ABISPSUP[5]: all available Abis subchannels allocated time
ABISPSUP[6]: number of successful Abis subchannels seizures
ABISPSUP[7]: number of unsuccessful Abis subchannels seizures attempts

Mean Abis utilization rate can be computed as:
] 1 [ ABISPSUP
] 3 [ ABISPSUP
util _ mean _ Abis Equation 20

Peak Abis utilization rate can be computed as:
] 1 [ ABISPSUP
] 4 [ ABISPSUP
util _ peak _ Abis Equation 21

Abis pool blocking rate (cumulative, i.e. without distinction between TCH and PDT
blocking rates) can be computed as:
] 7 [ ABISPSUP ] 6 [ ABISPSUP
] 7 [ ABISPSUP
blocking _ Abis
+
Equation 22

Percent of time when Abis pool is completely occupied:
3600
] 5 [ ABISPSUP
me blockingTi _ Abis Equation 23

Percentage of Abis subslots being out of service (OOS) can be computed as:
] 1 [ ABISPSUP
] 2 [ ABISPSUP
1 OOS _ Abis Equation 24

The following counters/KPI are helpful to indicate an unfavorable setting of
TEMPCH/TEMPDT timers:
number of activated PDCHs per cell (NALIPDCH)
number of used PDCH per cell (NALLPDCH)
50
PCU dimensioning

When the ratio of activated to used PDCHs is small:
[ ] 3 NALIPDCH
] 6 [ NALLPDCH
factor _ emptyChan Equation 25
where:
NALLPDCH[6]: mean number of used PDCH in DL
NALIPDCH[3]: mean number of activated PDCH

The smaller is the ratio defined by Equation 25, the closer look at TEMPCH settings is
needed. Especially, if small value of empty channel factor coincides with small
throughput rates per PDCH then TEMPCH settings should be reviewed. Throughput
rate per PDCH is based on data throughput per cell in single timeslot per Traffic Class
(MUTLLC) counter and can be computed as:
[ ] 3 NALIPDCH
] 40 ... 31 [ MUTLLC
perPdch _ throughput _ LLC Equation 26
where:
MUTLLC LLC data throughput per cell in single timeslot per Traffic Class
MUTLLC[31]: GPRS streaming
MUTLLC[3234]: GPRS interactive 1..3
MUTLLC[35]: GPRS background
MUTLLC[36]: EDGE streaming
MUTLLC[3739]: EDGE interactive 1..3
MUTLLC[40]: EDGE background

The following counters are helpful to control PCU processing capacity. Consumption
of PCU (PPXU/UPM) processing power mainly depends on the amount of subscribers
that are served and type of traffic (e.g. number of TBFs, number and size of LLC
frames, multiplexing,) which is produced by those users rather than on absolute
throughput rates.
PCU processing capacity can be observed by means of BSC Processor load counters
(BSCPRCLD). In particular, for information about processor load of n-th PCU please
refer to BSCPRCLD[3*n+7], BSCPRCLD[3*n+8], BSCPRCLD[3*n+9].
51
PCU dimensioning
Abbreviations

IDRA Improved DL Resource Allocation method
PCU Packet Control Unit
UPM User Plane Module

52

Dimpcu

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dimpcu

Uploaded by

Copyright:

Available Formats

GERAN PS domain

You might also like