Nokia Managing Wcdma Ran and Flexi Direct Capacity

Nokia Networks
WCDMA RAN, Rel. RU40,

Operating Documentation,
Issue 06, Documentation
Change Delivery 1 WCDMA
RAN, Rel. RU40, Operating
Documentation, Issue 09
Managing WCDMA RAN and

Flexi Direct Capacity
DN0972569
Issue 03I
Approval Date 2014-09-19

Managing WCDMA RAN and Flexi Direct Capacity
The information in this document applies solely to the hardware/software product (“Product”) specified
herein, and only as specified herein.
This document is intended for use by Nokia Solutions and Networks' customers (“You”) only, and it may not
be used except for the purposes defined in the agreement between You and Nokia Solutions and Networks
(“Agreement”) under which this document is distributed. No part of this document may be used, copied,
reproduced, modified or transmitted in any form or means without the prior written permission of Nokia
Solutions and Networks. If you have not entered into an Agreement applicable to the Product, or if that
Agreement has expired or has been terminated, You may not use this document in any manner and You
are obliged to return it to Nokia Solutions and Networks and destroy or delete any copies thereof.
The document has been prepared to be used by professional and properly trained personnel, and You
assume full responsibility when using it. Nokia Solutions and Networks welcome Your comments as part of
the process of continuous development and improvement of the documentation.
This document and its contents are provided as a convenience to You. Any information or statements
concerning the suitability, capacity, fitness for purpose or performance of the Product are given solely on
an “as is” and “as available” basis in this document, and Nokia Solutions and Networks reserves the right
to change any such information and statements without notice. Nokia Solutions and Networks has made all
reasonable efforts to ensure that the content of this document is adequate and free of material errors and
omissions, and Nokia Solutions and Networks will correct errors that You identify in this document. But,
Nokia Solutions and Networks' total liability for any errors in the document is strictly limited to the correction
of such error(s). Nokia Solutions and Networks does not warrant that the use of the software in the Product
will be uninterrupted or error-free.
NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY OF AVAILABILITY, ACCURACY, RELIABILITY, TITLE, NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, IS MADE IN RELATION TO THE
CONTENT OF THIS DOCUMENT. IN NO EVENT WILL NOKIA SOLUTIONS AND NETWORKS BE
LIABLE 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, EVEN IN THE CASE OF
ERRORS IN OR OMISSIONS FROM THIS DOCUMENT OR ITS CONTENT.
This document is Nokia Solutions and Networks’ proprietary and confidential information, which may not be
distributed or disclosed to any third parties without the prior written consent of Nokia Solutions and
Networks.
Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document
may be trademarks of their respective owners, and they are mentioned for identification purposes only.
Copyright © 2015 Nokia Solutions and Networks. All rights reserved.
f Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources of danger.
Only trained and qualified personnel may install, operate, maintain or otherwise handle this
product and only after having carefully read the safety information applicable to this product.
The safety information is provided in the Safety Information section in the “Legal, Safety and
Environmental Information” part of this document or documentation set.
Nokia Solutions and Networks is continually striving to reduce the adverse environmental effects of its
products and services. We would like to encourage you as our customers and users to join us in working
towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations
for power use and proper disposal of our products and their components.
If you should have questions regarding our Environmental Policy or any of the environmental services we
offer, please contact us at Nokia Solutions and Networks for any additional information.
2 DN0972569 Issue: 03I
Table of Contents
This document has 127 pages

Summary of changes..................................................................... 9

1 Introduction to capacity management...........................................11
1.1 Purpose and scope of the document............................................11
1.2 3G RAN capacity management model.........................................13
1.3 Capacity management process....................................................16

2 Access network capacity and stability..........................................18
2.1 Generic access network capacity management aspects............. 18
2.1.1 Voice capacity.............................................................................. 18
2.1.1.1 Voice capacity - user plane.......................................................... 18
2.1.1.2 Voice capacity - control plane...................................................... 19
2.1.2 Data capacity............................................................................... 20
2.1.2.1 Data capacity - user plane........................................................... 22
2.1.2.2 Data capacity - control plane........................................................22
2.1.3 User capacity............................................................................... 22
2.2 Access network capacity monitoring............................................ 23
2.3 Access network stability monitoring............................................. 23

3 Radio interface capacity...............................................................25
3.1 Downlink power............................................................................25
3.2 Uplink interference....................................................................... 27
3.3 Common channel capacity...........................................................29
3.4 Channelization code tree............................................................. 31

4 Multiradio Flexi BTS WCDMA capacity........................................ 34
4.1 BTS baseband capacity............................................................... 40
4.1.1 Baseband capacity configuration and processing principles........40
4.1.2 Baseband capacity monitoring..................................................... 44
4.2 BTS control plane capacity.......................................................... 50
4.3 BTS user plane capacity.............................................................. 53

5 RNC capacity............................................................................... 61
5.1 RNC control plane capacity..........................................................61
5.1.1 RNC control plane index.............................................................. 61
5.2 RNC user plane capacity............................................................. 62
5.2.1 Voice capacity.............................................................................. 63
5.2.2 Data capacity............................................................................... 64
5.2.3 RNC user plane fill factor............................................................. 66
5.2.4 RRC connected subscribers........................................................ 68
5.3 RNC connectivity..........................................................................69
5.3.1 Carriers and sites......................................................................... 69
5.4 IPA-RNC.......................................................................................70
Issue: 03I DN0972569 3
5.4.1 cRNC DSP capacity for calls........................................................72
5.4.2 IPA-RNC unit loads...................................................................... 73
5.4.2.1 ICSU.............................................................................................74
5.4.2.2 RSMU...........................................................................................75
5.4.2.3 OMU............................................................................................. 76
5.4.2.4 OMS............................................................................................. 77
5.4.2.5 DMCU.......................................................................................... 77
5.4.2.5.1 DMPG.......................................................................................... 78
5.4.2.5.2 DSP.............................................................................................. 79
5.4.2.6 GTPU........................................................................................... 80
5.4.2.7 SFU.............................................................................................. 80
5.4.2.8 A2SU............................................................................................80
5.4.2.9 MXU............................................................................................. 81
5.4.2.10 SWU............................................................................................. 82
5.4.2.11 NIS1............................................................................................. 82
5.4.2.12 NIP1............................................................................................. 83
5.4.2.13 NPS1............................................................................................83
5.4.2.14 NPGE........................................................................................... 85
5.5 mcRNC.........................................................................................86
5.5.1 mcRNC DSP capacity for calls.....................................................89
5.5.2 mcRNC units................................................................................ 90
5.5.2.1 CFPU........................................................................................... 90
5.5.2.2 CSPU........................................................................................... 91
5.5.2.3 EIPU............................................................................................. 92
5.5.2.4 USPU........................................................................................... 93
5.6 Flexi Direct RNC capacity............................................................ 94
5.6.1 Flexi Direct RNC processing load................................................ 95
5.7 RNC capacity usage forecasting..................................................98
5.7.1 Calculation of the controller fill ratio (CFR).................................. 99
5.7.2 Estimation of the date when internal resources might become
limiting - quick estimation............................................................. 99
5.7.3 Estimation of the date when the internal resources might become
limiting - standard trend follow-up................................................ 99
5.7.4 KPIs relevant for controller capacity upgrade planning..............100

6 IP transport interface capacity....................................................102
6.1 Ethernet interface.......................................................................103
6.2 IP-based route............................................................................105
6.2.1 IP-based route: IFC enabled...................................................... 106
6.2.2 IP-based route: IFC disabled..................................................... 108
6.2.3 IP-based route: CAC-controlled traffic........................................ 111

7 ATM transport interface capacity................................................ 115
7.1 ATM interface............................................................................. 119
7.2 ATM virtual path......................................................................... 120
7.3 ATM virtual channel....................................................................121
7.3.1 ATM virtual channel - CBR......................................................... 121
4 DN0972569 Issue: 03I
7.3.2 ATM virtual channel - UBR/UBR+.............................................. 123

7.4 VCC bundle................................................................................126
Issue: 03I DN0972569 5
List of Figures
Figure 1 The principle of proactive capacity management............................... 11
Figure 2 The principle of reactive capacity management................................. 12
Figure 3 3G RAN capacity model..................................................................... 15
Figure 4 Simplified Capacity Management Process......................................... 17
Figure 5 Access network capacity and stability................................................ 18
Figure 6 Radio interface................................................................................... 25
Figure 7 Common channels mapped to one SCCPCH.................................... 29
Figure 8 Common channels mapped to two SCCPCHs................................... 30
Figure 9 FSMC/D/E and FSMF capacity.......................................................... 39
Figure 10 Non-overlapping baseband resources................................................42
Figure 11 Overlapping baseband capacity and static resources reservation..... 42
Figure 12 No BTS baseband pooling in use....................................................... 45
Figure 13 BTS baseband pooling in use.............................................................45
Figure 14 RNC capacity......................................................................................61
Figure 15 RNC2600 architecture........................................................................ 71
Figure 16 RNC196/450 architecture................................................................... 72
Figure 17 DMCU HW Architecture......................................................................78
Figure 18 mcRNC architecture........................................................................... 87
Figure 19 mcRNC unit architecture.................................................................... 88
Figure 20 mcRNC HW and SW components......................................................89
Figure 21 Flexi Direct functional architecture..................................................... 96
Figure 22 Flexi Direct BTS functional interfacing................................................97
Figure 23 IP interface capacity bottlenecks...................................................... 102
Figure 24 IP transport interface........................................................................ 103
Figure 25 Ethernet interface monitoring........................................................... 103
Figure 26 IP resource overbooking...................................................................104
Figure 27 IP route monitoring: IFC enabled......................................................106
Figure 28 IP route monitoring - traffic limited by feature RAN1110: HSPA
Congestion Control...........................................................................109
Figure 29 Example for IP CAC monitoring for an IP-based route where IFC is
also enabled......................................................................................111
Figure 30 IP CAC: committed traffic blocking................................................... 112
Figure 31 ATM interface capacity bottlenecks.................................................. 115
Figure 32 Monitoring principle of ATM bottlenecks........................................... 118
Figure 33 ATM transport interface: identified monitoring cases........................ 119
Figure 34 VCC bundle - UBR + VCCs bandwidth.............................................126
6 DN0972569 Issue: 03I
List of Tables
Table 1 Template of the monitored capacity item............................................ 15
Table 2 Network voice capacity - user plane...................................................18
Table 3 Network voice capacity - control plane............................................... 19
Table 4 Access network stability..................................................................... 23
Table 5 Transmitted total carrier power........................................................... 25
Table 6 Received total wideband power..........................................................27
Table 7 Common channel capacity................................................................. 30
Table 8 Channelization code tree....................................................................31
Table 9 FSMC/D/E and FSMF logical configurations...................................... 34
Table 10 FSMC/D/E BTS baseband configurations.......................................... 35
Table 11 FSMF BTS baseband configurations..................................................36
Table 12 FSMF baseband capacity...................................................................36
Table 13 FSMC/D/E baseband capacity........................................................... 37
Table 14 FSMC/D/E and FSMF throughput capacity........................................ 37
Table 15 FSMC/D/E and FSMF user capacity.................................................. 37
Table 16 FSMC/D/E or FSMF capacity licensing.............................................. 38
Table 17 R99 channel element pool-based license...........................................40
Table 18 HSxPA processing sets...................................................................... 40
Table 19 Baseband capacity monitoring........................................................... 46
Table 20 BTS control plane capacity.................................................................51
Table 21 BTS user plane capacity.....................................................................54
Table 22 RNC control plane load index.............................................................61
Table 23 Voice capacity.....................................................................................63
Table 24 Data capacity......................................................................................64
Table 25 RNC user plane fill factor....................................................................66
Table 26 Number of RNC connected subscribers............................................. 68
Table 27 IPA-RNC and mcRNC connectivity.....................................................69
Table 28 DMCU fill factor.................................................................................. 72
Table 29 Supported unit types in IPA-RNC....................................................... 73
Table 30 RNC ICSU capacity............................................................................ 74
Table 31 RNC RSMU capacity.......................................................................... 76
Table 32 RNC OMU capacity............................................................................ 76
Table 33 RNC DMPG capacity..........................................................................78
Table 34 RNC DSP load....................................................................................79
Table 35 RNC GTPU capacity...........................................................................80
Table 36 RNC A2SP capacity........................................................................... 81
Table 37 RNC MXU capacity.............................................................................82
Table 38 RNC NIS1 capacity.............................................................................82
Issue: 03I DN0972569 7
Table 39 RNC NIP1 capacity.............................................................................83
Table 40 RNC NPS1 capacity........................................................................... 84
Table 41 RNC NPGE capacity.......................................................................... 85
Table 42 mcRNC DSP capacity........................................................................ 90
Table 43 CFPU load.......................................................................................... 90
Table 44 CSPU load..........................................................................................91
Table 45 EIPU load........................................................................................... 92
Table 46 USPU load..........................................................................................93
Table 47 Flexi Direct RNC processing load.......................................................97
Table 48 Common KPIs for capacity licenses................................................. 100
Table 49 KPIs for cRNC.................................................................................. 100
Table 50 KPIs for mcRNC............................................................................... 100
Table 51 Ethernet bandwidth capacity............................................................ 104
Table 52 IP route bandwidth: IFC enabled...................................................... 106
Table 53 IP route bandwidth: IFC disabled..................................................... 109
Table 54 Committed bandwidth....................................................................... 112
Table 55 Utilization of ATM interface............................................................... 119
Table 56 Utilization of ATM virtual path........................................................... 120
Table 57 Utilization of ATM virtual channel (CBR).......................................... 121
Table 58 Utilization of ATM virtual channel (UBR/UBR+)................................123
Table 59 Utilization of ATM VCC bundle......................................................... 126
8 DN0972569 Issue: 03I

Managing WCDMA RAN and Flexi Direct Capacity Summary of changes
Summary of changes
Changes between document issues are cumulative. Therefore, the latest document
issue contains all the changes made to previous issues.
Changes between issues 03H (2014-06-19, RU40) and 03I (2014-09-

19, RU40)
Chapter 4 Multiradio Flexi BTS WCDMA capacity
• Added note before Table 19: Baseband capacity monitoring
• Added section BTS cell level baseband capacity during mass events
• Updated Table 16: FSMC/D/E or FSMF capacity licensing
• Updated Table 18: HSxPA processing sets
• Updated BTS control plane capacity
– Added note before Table 20: BTS control plane capacity
• Updated Figure 11: Overlapping baseband capacity and static resources reservation
Chapter 5 RNC capacity
• Updated Table 23: Voice capacity
• Updated Table 26: Number of RNC connected subscribers
• Updated Table 46: USPU load
Changes between issues 03G (2014-04-21, RU40) and 03H (2014-06-

19, RU40)
Chapter 4 Multiradio Flexi BTS WCDMA capacity
• Updated Table 9: FSMC/D/E and FSMF logical configurations
• Updated Table 11: FSMF BTS baseband configurations
• Updated Table 12: FSMF baseband capacity
• Updated Figure 11: Overlapping baseband capacity and static resources reservation
• Updated Radio Link Capacity attempts target
• Updated Analyses for Radio link setup load in WBTS
• Updated RNC_2258a, RNC2264a, RNC_2268a, RNC2269a, RNC_2270a,
RNC_2274a, RNC_2275a, RNC_2276a descriptions in Table 19: Baseband capacity
monitoring
Chapter 5 RNC capacity
• Updated KPIs relevant for controller capacity upgrade planning, RNC_5499a CPU
load of EITP in EIPU.
Changes between issues 03F (2014-03-14, RU40) and 03G (2014-04-

21, RU40)
Chapter ICSU has been updated.
• Removed M1006C206 counter
Issue: 03I DN0972569 9

Summary of changes Managing WCDMA RAN and Flexi Direct Capacity
• Modified Table 35 Analysis
10 DN0972569 Issue: 03I

Managing WCDMA RAN and Flexi Direct Capacity Introduction to capacity management
1 Introduction to capacity management
1.1 Purpose and scope of the document

The purpose of the document is to introduce the measurement-based capacity
management, which uses counters and Key Performance Indicators (KPIs) KPIs defined
in Radio Access Network (RAN). In practice, this means monitoring the RAN capacity
usage, showing the evolution in time, and indicating early enough when to upgrade the
RAN capacity. The network dimensioning is out of the scope of this document. The
network is dimensioned and planned earlier (with the use of available traffic parameters).
In the measurement-based capacity management, there is no continuous dimensioning
of the network or its parts (if the traffic parameters change or the traffic demand
increases). For details on dimensioning, see Dimensioning WCDMA RAN: Access
Network (RNC), Dimensioning WCDMA RAN: Access Network (Transport Interfaces),
Dimensioning WCDMA RAN: Air Interface, Dimensioning WCDMA RAN: Flexi BTS
Baseband, Dimensioning WCDMA RAN: Traffic Modeling, and Dimensioning WCDMA
RAN: Ultra BTS Baseband in the UltraSite WCDMA Base Station, Operating
Documentation Issue 01 documentation set.
There are two approaches of the measurement-based capacity management:
1. Figure 1: The principle of proactive capacity management shows the aims for
planned or long-term upgrade of the capacity.
Figure 1 The principle of proactive capacity management
In proactive capacity management, the user is able to monitor the usage (utilization)
of the resource directly, and based on the trend, is able to start the upgrade in time.
There is no need to monitor the traffic itself.
2. Figure 2: The principle of reactive capacity management shows that reactive
management concentrates on the current state of RAN, aiming for short-term
bottleneck removal and tuning of the capacity.
Issue: 03I DN0972569 11

Introduction to capacity management Managing WCDMA RAN and Flexi Direct Capacity
Figure 2 The principle of reactive capacity management
In reactive capacity management, the user does not monitor the usage of the
resource directly, and cannot predict with a trend line when the resource is
exhausted. Instead, another type of KPI or counter is used. This KPI/counter
represents the blocking or the QoS degradation in the network. Blocking or
degradation of service starts when the underlying capacity reaches 100% of
utilization.
Therefore, for monitoring needs, there are both proactive and reactive KPIs. The
latter directly or indirectly indicates the QoS problems and blocking of the RAN. With
the help of these KPIs, potential capacity problems are removed. Each capacity KPI
is followed at the network, city, RNC, BTS, cluster of cells, or levels depending on the
need.
g For the full counter and KPI description with formulas, see:
Product Information -> Reference Information -> counter descriptions in NOLS, and
Product Information -> Reference Information -> KPI descriptions in NOLS.
Document’s scope details:
• At first, it concentrates on proactive approach. If there are no proactive means to
monitor, the reactive means should be used.
• It presents the product architecture and monitoring capabilities for the user and
control plane capacity only if it is necessary for understanding the nature of the
monitored capacity item.
• It does not specify any capacity values or product configurations under a specific
load. For this kind of information, see the dimensioning guidelines and product
descriptions.
• It refers to RAN capacity features. A capacity feature is a feature that allows more
end-user services in the RAN without additional hardware needs.
• The O&M capacity management is not described in this document.
• The given use cases covers only a “single owner” RAN, for example, MORAN and
Inter Circle Roaming cases are excluded.
12 DN0972569 Issue: 03I

1.2 3G RAN capacity management model

This document models the 3G RAN Capacity Management as two different but related
hierarchical structures:
• Traffic Model, which consists of relevant call types (profiles) and subscriber types
(profiles).
• Capacity Model, which consists of radio interface, WBTS, RNC, and transport
interfaces.
A key difference between 3G RAN and other cellular networks is that in 3G RAN,
subsystems and interface resource management functionalities interact closely. As an
example, the access transmission blocking on the Iub interface influences directly the
end-to-end quality of service. With the working QoS parameterization, the admission
control (AC) and the packet scheduler (PS) are allowed to degrade (instead of blocking)
the end-user services.
Traffic Model
The document breaks down the RAN Traffic Model to the needed level of presented call
and subscriber types. The current 3G RAN Traffic model covers the following:
1. Relevant call types or profiles- based on the following two main RAN services:
• CS voice
• data (including VoIP)
Data and voice should be followed separately, because there are separate resource
pools for voice and data in some parts of the system.
2. Relevant subscriber types or profile:
• basic UE ( plain UE or M2M UE)
• smart UE (smartphone or tablet)
• wireless DSL (notebook, laptop, or desktop)
There are two main differences between the three profiles:
• Profile basic UE and smart UE produce CS voice and data load to the network,
whereas wireless DSL only produces data.
• Profile smart UE is seen as the main control plane loader, whereas group wireless
DSL is seen as the main user plane loader.
g The UEs in the wireless DSL profile may also produce significant control plane load.
Therefore, depending on the penetration shares between the three different UE groups,
the voice or data capacity needs may differ significantly.
Capacity Model
The document breaks down the RAN Capacity Model to a level where possible capacity
bottlenecks or monitored capacity is presented. The current 3G RAN capacity model
covers the following:
1. voice Capacity, that is monitored on BTS and RNC levels
Issue: 03I DN0972569 13

• control plane- CS service/call attempts (equivalent to CS RAB setup attempt)
• user plane- CS Erlang
2. data capacity, that is monitored on BTS and RNC levels
• control plane:
– PS service attempts (equivalent to PS RAB setup attempt)
– PS session attempts (when a PS user is moved to CELL-DCH state because
of a capacity request)
– HS-FACH session attempt (when a PS user is moved to enhanced CELL-
FASH state because of a capacity request)
• User Plane: PS data throughput
3. user capacity, that is monitored on BTS and RNC levels
• RRC connected mode users in the RNC
• HSDPA users in RNC or BTS/WCELL
• HSUPA users in RNC or BTS/WCELL
4. radio interface capacity
• radio resource utilization- affects network level setup success rates
• resource manager- channelization codes
• admission control:
– transmission power levels
– received power levels
– common channel capacity- common channel load
5. transport interface capacity
• L2 user plane transport capacity
• L2 control plane transport capacity
6. network element capacity
• L3 control plane processing capacity
• L2 user plane processing capacity
• L2 control lane processing capacity
• L1 interface capacity
• connectivity
Stability monitoring is also followed as a part of the capacity model.
• service/call accessibility
– service setup success rates
– session setup success rates
• service/call retainability
– service success rates
– session success rates
14 DN0972569 Issue: 03I

The stability is monitored both on Access Network and the network element levels.
As all the listed capacity items impact the system capacity, the user is required to
monitor all the capacity items presented in the document at the same time.
Figure 3: 3G RAN capacity model shows a part of the monitored capacity item structure.
In this example, the top level is broken down to the WBTS level and the WBTS
subcategories (the lowest category is the WBTS control plane).
Figure 3 3G RAN capacity model
It is recommended that the user monitors the traffic as well. By correlating the traffic
volume measurements with the reactive capacity counters, it is possible to notice that the
reason for quality degradation is the increasing load in the system. The most important
parameters of the traffic are Voice minutes and Erlangs, Data Volume, and control plane
event frequencies, which the user should collect from the whole access network. The
control plane events include BHCA, RRC state transitions, and NAS BHCA.
This document uses the template shown in Table 1: Template of the monitored capacity
item. Each monitored capacity item includes the means of proactive or reactive
monitoring of the resource, the analysis of the capacity item (using counters and KPIs),
the response of the item to the overload condition, and the means to upgrade the
capacity.
Table 1 Template of the monitored capacity item
1. Monitored
capacity item g There are different KPI IDs in use for WCDMA RAN (RNC_xxxxy) and Flexi Direct (IHSPA_xxxxy)
It describes the part of the system, which the increasing traffic might overload if not properly planned and
dimensioned, or the traffic growth is exhausting the network capacity. The item covers possible
architectural units (saleable units) and avoids details at a lower level (if possible).
2. Proactive It describes what the user has to predict (the capacity item utilization, which enables capacity upgrades
monitoring before hitting the overload state).
Proactive monitoring includes the existing counters and KPIs related to the capacity item. The monitored
items should have the following threshold values mentioned (if they are known):
Issue: 03I DN0972569 15

Table 1 Template of the monitored capacity item (Cont.)
Target: recommended capacity/counter-based KPI values for avoiding QoS degradation in the RAN
system. In case of the RNC, this pertains to the nominal capacity. After reaching this level, the system
does not necessarily drop services, but the QoS parameter values, such as the bit rate, might be lower
than expected. The user should plan capacity upgrades so that they are implemented before the target
level is reached.
Red Flag: This attribute contains a capacity/counter value indicating severe QoS degradation or service
blocking or call setup time degradation. Please note that RNC only uses the target and not the red flag.
3. Reactive It describes that a particular element, part of an element, or interface has become congested or
monitoring overloaded.
The document gives no recommended threshold values for avoiding service blocking or QoS degradation
because the counter/KPI value is not proportional to the capacity item, therefore, they cannot be used for
trending. However, the network planners usually have recommended values for these counters/KPIs,
which vary between the networks.
4. Analysis It describes how to interpret the monitored counter values, suggesting which sub items need to be
monitored, or which other actions need to be performed if the upgrade cannot be done directly based on
the monitored counters.
5. Overload It describes the system’s response to an overload condition when the traffic consumes the capacity up to
100%.
6. Upgrade It describes the ways in which the capacity upgrade is performed. The document mentions recommended
actions for removing capacity limitation/overload (like adding sales units, capacity features). The
document might mention how to optimize the capacity with parameters, but it is not the main purpose of
this document.
1.3 Capacity management process

Figure 4: Simplified Capacity Management Process shows the capacity management
process that includes the monitored capacity items, collecting data, and analyzing trends
of the counters. Based on the thresholds (after drilling down to a suitable level), the
capacity is expanded, reconfigured, or optimized.
16 DN0972569 Issue: 03I

Figure 4 Simplified Capacity Management Process
The user is able to select counters and KPIs according to the aggregation level of the
KPI. The most important dimension is time. The user is able to collect counter values by
hour, day, and week (a maximum of daily values over one week). The time dimension is
further refined; for example, a selected hour is the maximum hourly value for the day, or
the hourly value for a user-defined busy hour specified separately for each day of the
week. For trend calculations, the weekly cycle in the capacity utilization patterns is a
useful tool. The second important dimension is the space, or the topology of the network.
When drilling down to the capacity bottleneck, both the capacity utilization trend over
time dimension (such as the weekly time series), and the location of bottleneck in space
(such as the RNC, BTS, or cell) should be analyzed.
Issue: 03I DN0972569 17

Access network capacity and stability Managing WCDMA RAN and Flexi Direct Capacity
2 Access network capacity and stability

The purpose of this chapter is to provide information about the Traffic Model parts.
In addition, there are given few stability type of KPIs that are needed in all types of
Capacity monitoring.
Figure 5 Access network capacity and stability
Access Network Capacity Access Network Stability
Voice Data User Call Call Call

Capacity Capacity Capacity Attempts Accessibility Retainability
2.1 Generic access network capacity management

aspects
When combining the earlier presented Traffic and Capacity Models, the following
management aspects are used; voice capacity, data capacity and user capacity.
2.1.1 Voice capacity

Required voice capacity is affected by activity of handheld UEs, here either plain UEs or
smart phones (M2M might also produce CS voice but is ignored here). There is no
difference in expected capacity needs between Plain UEs and smart phones.
However, there is a clear difference in required voice capacity between “basic” or pre-
paid voice subscriptions. Usually, a pre-paid subscription needs as much as half of the
capacity needed by a “basic” one. The difference is expected on the user plane, that is,
the number of call attempts are expected to be the same, but the duration usually drops
to half when pre-paid subscriptions are compared to “basic” subscriptions.
Thus, the share of pre-paid subscriptions should be taken into account when the voice
capacity needs are estimated. This means that the more pre-paid voice subscribers in
the network, the less voice user plane capacity is required (compared to network with
only “basic” voice subscribers).
2.1.1.1 Voice capacity - user plane
Table 2 Network voice capacity - user plane
1. Monitored Network voice capacity - user plane
capacity item
Only hard voice capacity is taken into account, that is, voice Erlang capacity is not under any license. The
Erlang can be proactively monitored.
2. Proactive Counter/KPI Name, unit Target Red flag Description

monitoring
18 DN0972569 Issue: 03I

Managing WCDMA RAN and Flexi Direct Capacity Access network capacity and stability
Table 2 Network voice capacity - user plane (Cont.)
RNC_280c Average CS Erlang 70% (a part - CS Erlang = the CS RAB
[Ehr] of the whole holding time.
RNC Fill
Factor
threshold
3. Reactive Counter/KPI Name, unit Description

monitoring
- - -
4. Analysis CS Erlang
CS Erlang must be compared to the available Erlang capacity in RNC. If the threshold is exceeded there
might be overload in the access network regarding the monitored RNC. But as the CS Erlang load is just
a part of the whole total RNC capacity pool, that is, RNC traffic fill factor, you need to consider the whole
RNC traffic fill factor before taking any actions.
5. Overload See Table 25: RNC user plane fill factor.
6. Upgrade See Table 25: RNC user plane fill factor.
2.1.1.2 Voice capacity - control plane
In the RNC2600 and mcRNC HW configuration, the AMR capacity 1 Erl license is
mandatory. If there is no valid AMR capacity 1 Erl license installed in the RNC2600, it
might not establish AMR RABs. The AMR capacity defines the maximum number of
simultaneous AMR radio access bearers. The RNC periodically calculates the number of
simultaneous AMR RABs. There is no averaging applied. If the UE is in a soft handover
state during the AMR RAB is establishment, only SRNC counts it as one AMR RAB.
When you use anchoring, only the anchor RNC calculates AMR RAB.
Table 3 Network voice capacity - control plane
1. Monitored Network voice capacity - control plane
capacity item
The number of simultaneous voice calls are under the RNC level license. The AMR license usage can be
monitored proactively with the license utilization KPIs. The license violations can be reactively monitored
with the M1001C619 and M1001C620 counters.
In addition you can reactively monitor with the setup success KPIs and BHCA.
You can set the 3294 LICENCE CAPACITY WARNING and 3295 LICENCE CAPACITY EXCEEDED
alarms to notify when the AMR capacity is close to the licensed capacity, or if AMR RABs are being
blocked/pre-empted because of exceeding the licensed capacity.
For details, see SW License Key Controlled RNC Capacity.
2. Proactive Counter/KPI Name, unit Target Red Description

monitoring flag
RNC_1773a AMR Licensed 40% (together - The AMR simultaneous call distribution in the

Capacity with Licensed Capacity. It shows the percentage of
Licensed
simultaneous RNC_1774a) AMR call distribution, between 80 and 90% of the
AMR Capacity
call distribution licensed capacity (occurrences compared to the
ratio 80-90% total amount of distribution load occurrences).
Issue: 03I DN0972569 19

Table 3 Network voice capacity - control plane (Cont.)
RNC_1774a AMR Licensed 20% - The AMR simultaneous call distribution in the
Capacity Licensed Capacity. It shows the percentage of
simultaneous AMR call distribution, higher than 90% of licensed
call distribution capacity (occurrences compared to the total
ratio >90% amount of distribution load occurrences).

monitoring
M1001C619 RAB SETUP FAILURES DUE The number of RAB setup failures caused by the AMR

TO LICENCE FOR CS VOICE capacity license which was exceeded for CS voice.
[#]
Licensed
AMR Capacity M1001C620 RAB ACTIVE RELEASES DUE The number of RAB releases because of pre-emption
TO LICENCE PRE-EMPTION caused by the capacity license which was exceeded for
FOR CS VOICE [#] CS voice calls. Also the M1001C144 RAB ACTIVE
RELEASES DUE TO PRE-EMPTION FOR CS VOICE
counter is updated along with this counter.
RNC_229a RAB Attempts Voice [#] Voice BHCA. This measured traffic parameter describes

the traffic demand for voice.
Service
Attempts
RNC_565f Voice Call Setup Success Ratio AMR Call Setup Success Ratio [%] over the reporting
(CSSR) [%] period.
4. Analysis 1-2. AMR licensed capacity simultaneous call distribution ratios
If there are more than 40% of all occurrences in either of the given KPIs, and/or more than 20% in the
RNC_1774a, the AMR capacity license most likely needs to be updated.
3-4. These KPIs monitor reactively how often license-related overload actions need to be taken.
5-6. RAB Attempts Voice/Voice Call Setup Success Ratio (CSSR)
An increase in RAB attempts voice, together with the degradation of voice call setup success ratio,
indicates problems in the network control-plane capacity. In cases of degraded CSSR, the root cause can
be either radio interface (chapter Radio Interface Capacity), BTS (chapters WBTS Capacity (Flexi Rel2.0)
or WBTS Capacity (Flexi Rel1.0/Ultrasite/EUBB)), RNC (chapter RNC Capacity), or transport (chapters IP
Transport Interface Capacity or ATM Transport Interface Capacity).
5. Overload 1-4. When the number of AMR RABs is greater than the licensed capacity, the RNC does not admit new
AMR RABs until the amount decreases below the licensed limit. Overload is allowed and a hysteresis
between starting and stopping the AMR limiting is used. Pre-emption is used, that is, the AMR RABs with
higher priority might pre-empt the low-priority ones when the licensed capacity is exceeded. The RNC will
admit emergency calls even if the amount of AMR RAB is limited because of the AMR capacity 1 Erl
license.
5-6. In case of overload the attempt number rapidly increases and the success rate rapidly decreases.
6. Upgrade In case of upgrade need, more AMR capacity can be licensed or the RNC Fill Factor instructions followed;
see Table 25: RNC user plane fill factor.
2.1.2 Data capacity

The required data capacity is affected by activity of different smart UEs or wireless DSLs
(basic UEs are ignored here).
20 DN0972569 Issue: 03I

There is a clear difference in expected capacity needs between smart UEs and wireless
DSLs for both user and control plane. The difference results from both the penetration
shares between, as well as, from data usage levels and patterns of the different UE
groups.
• The smart UEs are clearly more numerous in the networks and will also remain at
such high level.
• produced data estimates:
– The wireless DSLs produce up to 10 times more data than smart phones.
– The wireless DSLs produce up to 5 times more data than tablets.
• control plane:
– Smart UEs need to save UE battery. Because of this they try to constantly
release allocated services as soon as all related data is received/transmitted just
to request soon again for a new service allocation. This causes a heavy “burden”
of the control plane, therefore the network uses various features to minimize
smart UE signaling.
– The wireless DSLs do not share the need of smart UEs to save the battery and
thus do not try to release the inactive services. However, concerning active
services, there are often other control-plane loading activities to be considered,
for example, keeping alive messages for chat SW.
Unlike in voice capacity, where the service is allocated or not, different states related to
the reserved data services must be considered.
It means that there is a separate data capacity limit for the reserved data service
amounts, that is, in radio network PS radio access bearers (RAB), but also for the
reservation of all the different states for allocated services. There are three different
states possible for the PS UE to use: CELL-DCH, CELL-FACH, and CELL-PCH/URA-
PCH.
The two first-mentioned states make it possible for the UE to send/receive user-related
data. CELL-PCH/URA-PCH state is only used for keeping the location of a UE known
(on a cell/routing area level), and thereby ensuring faster activation of data
sending/receiving via quick moves to CELL-DCH or CELL-FACH states. The reasoning
here is that it is much faster to activate data sending/receiving for the UE if it is in CELL-
PCH/URA-PCH (and has an allocated PS RAB), than when the UE is in idle mode, and
all the service resources (that is, PS RAB resources) need to be allocated. From the UE
perspective, the CELL-PCH/URA-PCH state consumes less energy than CELL-FACH,
and especially than the CELL-DCH, so it is beneficially to keep it in CELL-PCH/URA-
PCH state whenever possible.
The state that is most meaningful from access network data capacity perspective-related
PS service utilization is the CELL-DCH state. In this state the PS UE can fully utilize the
available network data capacity, whereas in CELL-FACH state there are limits set to data
rates and/or amounts. But contemporary UE, especially smart UE, often produce short
and low data volume bursts (that are not related to user data, but for example, service
keep-alive messages) that are meaningful to be handled in CELL-FACH state, and thus
saving the CELL-DCH state capacity for “real” user data.
Issue: 03I DN0972569 21

2.1.2.1 Data capacity - user plane
The data capacity for the user plane is related to all the sent/received UE data in both
CELL-DCH and CELL-FACH states.
The share of wireless UEs should be taken into account when the data capacity needs
are estimated. This means that the more wireless DSL subscribers in the network, the
more extensive the data load will be - compared to a network with only hand-held UEs.
2.1.2.2 Data capacity - control plane
You need to monitor the following in relation to control plane data capacity:
• cases when the packet service-utilizing UE is in any state, that is, PS RAB can be
either active or inactive
• cases when the packet service is considered active:
– CELL-DCH state transmission or reception on dedicated (DCH, E-DCH), or
shared channels (HS-DSCH) - this is called a Packet Session in this document
g Note that the Packet Session here is an RN-specific issue and shouldn't be mixed up
the “packet session” in the PS core that means that there is a PDP context allocated.
– CELL-FACH state data (on either legacy FACH or HS-FACH)
transmission/reception on common channels falls under inactive PS category in
this document.
The share of smart UEs should be taken into account when the data capacity needs are
estimated. This means that the more smart UEs in the network, the more extensive the
control plane load will be.
From network perspective it is beneficial to:
• serve low capacity service needs on CELL-FACH - use the RAN1637: High Speed
CELL_FACH DL and/or the RAN1797: Common Channel Setup features for this
purpose
• prevent frequent PS RAB setups and releases caused by smart UE - use the
RAN2136: Fast Dormancy feature for this purpose
• keep wireless DSLs in CELL-DCH state in cases the UE supports discontinues
transmission - use the RAN1644: Continuous Packet Connectivity (CPC) feature for
this purpose
2.1.3 User capacity

The number of possible users / subscribers in the system varies based on the available
network elements and installed user capacity.
22 DN0972569 Issue: 03I

2.2 Access network capacity monitoring

The access network capacity monitoring information can be found in the monitoring use
cases of the BTS control plane capacity and BTS user plane capacity sections in
Multiradio Flexi BTS WCDMA capacity and in the monitoring use cases of the RNC
control plane capacity and RNC user plane capacity sections in RNC capacity
The Access network capacity monitoring information can be found in the monitoring use
cases of the BTS control plane capacity and BTS user plane capacity Control plane and
User plane sections in the BTS and RNC chapters of this document.
2.3 Access network stability monitoring

Table 4 Access network stability
1. Monitored Access network stability
capacity item
The following Access Network stability KPIs should always be monitored along with the selected capacity
KPIs.

monitoring flag
- - - - -

monitoring
RNC_229a The number of RAB setup attempts requested
RAB attempts voice for CS conversational calls with RAB QoS
IHSPA_229a parameter ‘source descriptor’ = Speech
RNC_617a
The number of RAB setup attempts requested
RAB attempts streaming
for streaming calls.
IHSPA_617a
RNC_616a The number of RAB setup attempts requested
Service or
RAB attempts PS interactive and for PS interactive or background calls. This
session
background counter update is depending on the profile
attempts IHSPA_616a setting in the registry.
RNC_930b
Packet session setup attempts over the
Packet session attempts
reporting period.
IHSPA_930c
RNC_5456a
HS-FACH session attempts HS-FACH session attempts
IHSPA_5456a
Service or RNC_565f
Voice call setup success ratio (CSSR) AMR call setup success ratio [%] over the
session
[%] reporting period.
accessibility
Issue: 03I DN0972569 23

Table 4 Access network stability (Cont.)
IHSPA_565a
RNC_576e
Packet service setup success ratio Packet service setup success ratio [%] over
(CSSR) [%] the reporting period.
IHSPA_5000b
RNC_916b
Packet session setup success ratio Packet session setup success ratio [%] over
(SSSR) [%] the reporting period.
IHSPA_5001c
RNC_5459a The success ratio of transitions from
Switched to enhanced HS-FACH
CELL_DCH or CELL_PCH to Enhanced HS-
success ratio [%]
IHSPA_5459a FACH.
RNC_231d RAB success ratio of AMR voice [%] over the
RAB success ratio, voice (CSR) reporting period. Covers the RAB active
IHSPA_231a phase of a call.
RNC_736b RAB success ratio for NRT services [%] from
RAB success ratio, NRT services user perspective over the reporting period.
Service or IHSPA_736a Covers the RAB active phase of a call.
session
retainability RNC_922b The packet session success ratio for
Packet session success ratio streaming, interactive and background
IHSPA_5007b services.
RNC_5476a The success ratio of transitions from
Switches from enhanced HS-FACH
enhanced HS-FACH to CELL_DCH or
success ratio [%]
IHSPA_5476a CELL_PCH.
4. Analysis In cases of degraded accessibility or retainability, the root cause can either be radio interface (chapter
Radio interface capacity), BTS (chapter Multiradio flexi WBTS capacity), RNC (chapter RNC capacity), or
transport (chapters IP transport interface capacity or ATM transport interface capacity).
5. Overload In case of overload, the success rate rapidly decreases.
6. Upgrade The possible upgrade need is related to the monitored capacity case.
24 DN0972569 Issue: 03I

Managing WCDMA RAN and Flexi Direct Capacity Radio interface capacity
3 Radio interface capacity

Figure 6: Radio interface shows the main bottlenecks in the radio interface which are
downlink power, uplink interference, common channels and the channelization code tree
in the downlink.
Figure 6 Radio interface
3.1 Downlink power

The BTS controls the amount of HSDPA DL transmission power, after the powers for
DCH, HSUPA control channels, and common channels have been set up. The BTS
measures the total power, NonHSDPA power, and HSDPA power.
Table 5 Transmitted total carrier power
1. Monitored Transmitted total carrier power
capacity item
The total transmitted power includes the downlink power allocated to the downlink DPCH, the common
channels, and the E-RGCH, E-AGCH, E-HICH, HS-SCCH, and HS-PDSCH. The BTS reports the
Transmitted Carrier Power in absolute units. The classification depends on the cell size setting
(PRACHDelayRange parameter). A proactive KPI has been defined, based on the M1000C342 -
M1000C353 classification counters.

monitoring flag
RNC_5201a Share of time when the Transmitted Carrier
Marginal transmitted
Power (TxCrPwr) is in classes 7-8. The mapping
carrier power time 20% >50
IHSPA_5201 to power value depends on the
share DL [%]
a PRACHDelayRange WCEL parameter settings.

monitoring
RNC_5202a
Overload Transmitted Share of time when the Transmitted Carrier Power (TxCrPwr) is in
Carrier Power Time classes 9-10. The mapping to power value depends on the
IHSPA_5202 Share DL [%] PRACHDelayRange WCEL parameter settings.
a
RNC_964a
RRC setup FR due to
RRC setup failure ratio caused by Admission Control.
AC [%]
IHSPA_964a
Issue: 03I DN0972569 25

Radio interface capacity Managing WCDMA RAN and Flexi Direct Capacity
Table 5 Transmitted total carrier power (Cont.)
RNC_722d The average active HS-DSCH MAC-d cell throughput from
network perspective, calculated as the HSDPA MAC-d throughput
Active HS-DSCH cell
at BTS, divided by the active HS-DSCH time from the network
throughput
IHSPA_5022 perspective. The active time refers to the scheduled TTIs, that is,
b when sending data.
RNC_1879d The average active HS-DSCH MAC-d throughput from end user
Active HS-DSCH end perspective, calculated as the HSDPA MAC-d throughput at BTS,
user throughput divided by the active HS-DSCH time multiplied by the active users.
IHSPA_1879c [kbps] The active time refers to the scheduled TTIs, that is, when sending
data.
M1000C155 RN RELEASE BY The number of radio bearers released by the dynamic link

DYN LINK OPT DUE optimization for NRT traffic because of RL power congestion.
TO RL POWER
CONGESTION [#]
M1000C166 RB RELEASE DUE The number of radio bearer releases by the enhanced overload

TO ENH OVERLOAD control using the radio link reconfiguration method.
CONTROL USING RL
RECONF [#]
M1000C149 HS-DSCH RELEASE The number of HS-DSCH allocation releases because of downlink

DUE TO DL overload. This counter includes both interactive and background
OVERLOAD [#] class connections. It is updated when the user's HS-DSCH
allocation is released because of the PtxNonHSDPA >=
PtxTargetHSDPA+PtxOffsetHSDPA condition. This counter is
updated only when the HSDPA Static Resource Allocation is used.
M1000C142 RB DOWNGRADE The number of radio bearer downgrades by the enhanced

BY ENH OVERLOAD overload control using the TFC subset method.
CONTROL USING
TFC SUBSET [#]
M1002C602 DL DCH SELECTED This counter is updated when the HS-DSCH cannot be selected

FOR STREAMING as a downlink transport channel because of
DUE TO HSDPA PtxTotal>PtxTargetHSDPA or PtxNC>PtxTargetHSDPA
POWER [#] conditions.
RNC_969b DL DCH selected due The number of times when the HS-DSCH downlink transport

to the HSDPA power channel cannot be selected for an interactive or background class
IHSPA_969a [#] connection because of downlink power limits.
4. Analysis 1. Marginal (Overload) transmitted carrier power time share DL
The primary indication for highly loaded sites is the percentage of time when these sites are in
marginal and overload power classes.
2. RRC setup failure rate due to AC
Admission control might reject setup, cell change, or handover (excluding frozen BTS failure).
Increase of failures indicated by the RRC setup failure rate because of AC, means that the WBTS has
used all available downlink power in order to maintain the connection for the users.
3. The HSDPA throughput
KPIs RNC_722d and RNC_1879a are observed together with the transmitted power KPIs. The
HSDPA contributes a major share here.
4. RB releases and downgrades
26 DN0972569 Issue: 03I

Table 5 Transmitted total carrier power (Cont.)
Counters M1000C155, M1000C166, M1000C149, M1000C142, and M1002C602 react in overload
situation.
Note that the average available power for HSDPA influences the CQI seen by the UE. If the downlink
quality is bad, there is not enough power to serve the users. However, high power for HSDPA does not
necessarily mean high throughput (or low power - low throughput).
5. Overload The system downgrades or releases a dedicated channel of a non-real-time RAB, because of excessive
downlink power.
6. Upgrade With the 40 W LPAs, the maximum HSDPA power increases to 45 dBm (also concerns the average
power). High DL power levels, together with a low throughput, indicate low coverage for UEs. Improve the
coverage by adding sites.
3.2 Uplink interference

The power control allows access to as many users as possible while minimizing the
interference caused by these users. At the same time, the capacity of a WCDMA system
is proportional to the level of interference in the system.
The cell-specific load control in the RNC maintains the estimated received wideband
power value for the resource allocation of the RNC. The estimated received wideband
power value represents the received interference of transferred active bearers, which are
allocated in the RNC (such as DCHs). It does not include the contribution of the bearers,
which have an E-DCH established with the scheduled transmission, as follows:
• If the HSUPA has not been configured in the cell, the estimated received wideband
power value represents the received total wideband power (PrxTotal), measured and
reported by the BTS.
• If the HSUPA has been configured in the cell, the estimated received wideband
power value represents the received total non-E-DCH scheduled transmission
wideband power (PrxNonEDCHST). The PrxTotal is not estimated in the HSUPA cell.
Table 6 Received total wideband power
1. Monitored Received Total Wideband Power
capacity item
The Received Total Wideband Power (RTWP) reflects the total noise level within the UMTS frequency band
of one single cell. This is measured by the BTS.
The RNC limits the uplink noise using the PrxTarget parameter, which defines the maximum allowed
increase in uplink noise in relation to the background noise floor. A high RTWP level indicates an increase in
interference in the cell.

monitoring flag
RNC_5203b
Share of time when the received total
wideband power is in classes 13-16. The KPI
Percentage of RTWP in
10% - is based on the M1000C320-41 counters.
marginal area [%]
IHSPA_5203 The total uplink power (RTWP) measurement
b report samples the power values that are
Issue: 03I DN0972569 27

Table 6 Received total wideband power (Cont.)
within a particular class range. The counter
takes into account the whole received power,
including HSDPA and Common Channels.
M1000C147 RB DOWNGRADE BY PBS The number of RB downgrades by priority-based scheduling

DUE TO INTERFERENCE (PBS) because of interference congestion.
CONGESTION [#]
M1000C159 RB RELEASE BY PBS DUE The number of radio bearers released by priority-based

TO INTERFERENCE scheduling (PBS) because of interference congestion.
CONGESTION [#]
M1000C152 RB DOWNGRADE BY PRE- The number of RB downgrades by pre-emption because of

EMPTION DUE TO interference congestion.
INTERFERENCE
CONGESTION [#]
M1000C164 RB RELEASE BY PRE- The number of radio bearers released by pre-emption because

EMPTION DUE TO of interference congestion.
INTERFERENCE
CONGESTION [#]
RNC_970a
The number of SRB requests that have been rejected on the
SRB reject rate UL [%]
UL.
IHSPA_970a
RNC_972a
AMR service reject rate UL The number of voice call requests that have been rejected on
[%] the UL.
IHSPA_972a
RNC_974a
CS data service reject rate The number of video call requests that have been rejected on
UL [%] the UL.
IHSPA_974a
RNC_976a
PS data service reject rate The number of PS data call requests that have been rejected
UL [%] on the UL.
IHSPA_976a
RNC_661d
HSDPA access failure rate HSDPA access failure rate because of the associated UL
due to UL DCH [%] DCH.
IHSPA_661a
4. Analysis 1. Total interference in UL
The primary indication for a highly loaded BTS.
2. Service rejections
Counters M1000C147, M1000C159, M1000C152, M1000C164 and KPIs RNC_970a, RNC_972a,
RNC_974a, and RNC_976a react in overload situation.
3. HSDPA access FR due to the UL DCH
An increase in the HSDPA access FR due to the UL DCH indicates that there is no room for more UEs to
be connected to that particular cell because of UL power congestion.
There are no predefined thresholds for the frequency of rejections, downgrades, or releases.
28 DN0972569 Issue: 03I

Table 6 Received total wideband power (Cont.)
5. Overload The system downgrades or releases a dedicated channel of a non-real-time RAB (controllable load),
because of excessive uplink congestion situations. When the load is still too high, the power control cannot
mitigate failures because of non-controllable load.
6. Upgrade -
3.3 Common channel capacity

The air interface physical channels map to transport channels in UTRAN:
1. Primary Common Control Physical Channel (PCCPCH), mapped to the BCH
(Broadcast Channel)
2. Secondary Common Control Physical Channel (SCCPCH), mapped to the Paging
Channel (PCH)) or Forward Access Channel (FACH). There can be up to three
SCCPCH channels configured in the cell.
3. Physical Random Access Channel (PRACH), mapped to the Random Access
Channel (RACH).
4. High-Speed Physical Downlink Shared Channel (HS-PDSCH) mapped to FACH.
The channels 1 - 3 are not the subject of the dynamic power control. The transmission
powers of the downlink common physical channels are determined during radio network
planning and their bit rates are not configurable by the user. The system measures the
loads indirectly, by measuring the loads on corresponding transport channels (RACH,
FACH, PCH, and BCH).
Common channel load consists mainly of FACH, RACH, and PCH loads on the SCCPCH
channel(s). RACH and FACH load have separate control plane and user plane load:
RACH-u, RACH-c, FACH-u, and FACH-c. The total load of the common channels is thus,
the sum of these loads.
Figure 7: Common channels mapped to one SCCPCH shows that there can be up to
three SCCPCHs configured in the cell. If only one SCCPH is used in a cell, it will carry
FACH-c (containing DCCH/CCCH/BCCH), FACH-u (containing DTCH), and PCH. FACH
and PCH are multiplexed into the same SCCPH.).
Figure 7 Common channels mapped to one SCCPCH
Figure 8: Common channels mapped to two SCCPCHs shows that if the user configures
two CSSPCHs in a cell, the primary CCPH will always carry PCH only and the second
SCCPH will carry FACH-u and FACH-c.).
Issue: 03I DN0972569 29

Figure 8 Common channels mapped to two SCCPCHs
The system measures the RACH load in the NBAP interface in terms of acknowledged
PRACH preambles. There is no overload control algorithm for RACH, but the RACH load
measurements are used by the RNC for load control, when the downlink channel type
(common or dedicated) is selected.
Table 7 Common channel capacity
1. Monitored Common channel capacity
capacity item
The main proactive KPI for the common channel load is the average SCCPCH channel load, calculated
indirectly from the transport channels, which maps to it. Assuming fixed transmit rates for each transport
channel, the user follow s the load proactively.
Additionally, the user monitors each common transport channel proactively.

monitoring flag
RNC_979a Average SCCPCH channel load - including the PCH in
the measurement period.
SCCPCH
average load - - Average PCCPCH load: if one SCCPCH is used in a
IHSPA_979a [%] cell, it will carry FACH-c (containing
DCCH/CCCH/BCCH), FACH-u (containing DTCH), and
PCH.
RNC_2029b FACH-u load ratio provides information about the
FACH transport channel user plane data load (the
FACH-u load
- - FACH channel throughput is divided by the
ratio [%]
IHSPA_5088a corresponding transport channel maximum bit rate to
get the load ratio).
RNC_2030b FACH-c load ratio provides information about the
FACH transport channel control plane data load (the
FACH-c load
- - FACH channel control data throughput is divided by
ratio [%]
IHSPA_5089a the corresponding transport channel maximum bit rate
to get the load ratio).
RNC_2032a RACH-u load ratio provides information about the
RACH transport channel user plane data load (the
RACH-u load
- - RACH channel user data throughput is divided by the
ratio [%]
IHSPA_5090a corresponding transport channel maximum bit rate to
get the load ratio).
30 DN0972569 Issue: 03I

Table 7 Common channel capacity (Cont.)
RNC_2033a RACH-c load ratio provides information about the
RACH transport channel control plane data load (the
RACH-c load
- - RACH channel control data throughput is divided by
ratio [%]
IHSPA_5091a the corresponding transport channel maximum bit rate
to get the load ratio).

monitoring
- - -
4. Analysis Use RNC_979a to see how loaded the physical channel (SCCPCH) is in this configuration. When two
SCCPCHs are used, this will contain all other transport channels except PCH.
5. Overload If there is only one SCCPCH, the system gives PCH traffic a higher priority compared to the FACH. When
the system notices congestion on this channel, it is likely that the FACH channel will suffer.
6. Upgrade The SCCPCH load (PCH+FACH, or PCH only) is reduced by:
1. Increasing the number of available SCCPCHs (for example, by introducing a second SCCPCH)
2. Evaluating whether there is a high level of signaling generated by the cell, URA, location area, or
routing area updates. If so, consider adjusting the area boundaries or reducing the size of the
location and routing areas.
3. Evaluating whether there is excessive user plane data transfer within the CELL_FACH. If so,
consider reducing the RLC buffer thresholds that trigger the transition to CELL_DCH.
4. Upgrading the Node B configuration with an additional carrier
5. Using the RAN1202: 24 kbps Paging Channel feature if the PCH is loaded.
6. Use the RAN1637: High Speed Cell_FACH DL feature, if the FACH is loaded.
3.4 Channelization code tree

The available codes in the Channelization Code Tree in the BTS becomes a capacity
bottleneck in the downlink direction, especially when HSDPA and HSUPA are enabled in
the cell. There is a fixed number of codes reserved for Common Channels. REL99
services require a certain number of codes, depending on the service bit rate. HSDPA
reserves 5, 10, or 15 codes.
In uplink, the code tree is arranged per each UE; therefore, no capacity bottleneck is
expected.
Table 8 Channelization code tree
1. Monitored Channelization code tree
capacity item
Channelization Code Occupancy provides an indication of the percentage of codes, that the system uses
or blocks. The channelization codes, which the system assigns to both common and dedicated downlink
channels, are included in the KPI. Furthermore, there are also counters used to monitor the maximum
and minimum code occupancy. This is used to detect the cell’s busy and non-busy hours.
Channelization Code Blocking is the percentage of code allocation attempts that block because of code
tree congestion.
Issue: 03I DN0972569 31

Table 8 Channelization code tree (Cont.)
When a user enables HSDPA, the system dynamically adjusts the number of SF16 codes reserved for
HSDPA, depending on the R99 usage of codes. There are counters for monitoring the number of HSDPA
channelization code downgrades because of congestion of the RT or NRT DCH.
The user is able to monitor the impact of code tree congestion reactively using counters related to
HSDPA code and radio bearer downgrades/releases.

monitoring flag
RNC_113a
Average code tree The average code tree
70% 80
occupancy [%] occupancy.
IHSPA_113a
RNC_519b
Min code tree occupancy The minimum code tree
- -
[%] occupancy.
IHSPA_519a
RNC_520b
Max code tree occupancy The maximum code tree
80% 90
[%] occupancy.
IHSPA_520a
RNC_949b Spreading code blocking rate of
a cell over the reporting period.
Spreading code blocking This measurement is based on
5% >5
rate in DL [%] cell resource measurement,
IHSPA_949a where the code tree situation of
a cell is measured.

monitoring
M1000C248-258 DURATION OF HSDPA It is possible to calculate the average number of
xx(5-15) CODES reserved SF16 codes for HSDPA based on the
RESERVATION duration counters for each code (original transmitted xy
(5-15) codes with QPSK or 16QA, M5000).
M1000C266 HSDPA CH CODE The number of HSDPA channelization code

DOWNGRADE DUE TO downgrades because of congestion of RT DCH
RT [#] requests. It is updated when the code downgrade is
started because of a RT-over-HSDPA prioritization.
M1000C267 HSDPA CH CODE The number of HSDPA channelization code

DOWNGRADE DUE TO downgrades because of congestion of NRT DCH
NRT DCH [#] requests. It is updated when the code downgrade is
started because of an NRT DCH-over-HSDPA
prioritization.
M1000C148 RB DOWNGRADE BY The number of RB downgrades by priority-based

PBS DUE TO scheduling (PBS) because of spreading code
SPREADING CODE congestion.
CONGESTION [#]
32 DN0972569 Issue: 03I

Table 8 Channelization code tree (Cont.)
M1000C153 RB DOWNGRADE BY The number of RB downgrades by pre-emption
PREEMPTION DUE TO because of spreading code congestion.
SPREADING CODE
CONGESTION [#]
M1000C165 RB RELEASE BY PRE- The number of radio bearers released by pre-emption

EMPTION DUE TO because of spreading code congestion.
SPREADING CODE
CONGESTION [#]
M1000C160 RB RELEASE BY PBS The number of radio bearers released by priority-

DUE TO SPREADING based scheduling (PBS) because of spreading code
CODE CONGESTION [#] congestion.
4. Analysis 1. Average code tree occupancy
At the average code occupancy of 70%, code blocking starts to affect the QoS at the level of 70%. At
the level of 80%, service blocking can start.
2. Min code tree occupancy
The minimum code occupancy is 3%, when the common channels are active. When HSDPA is
active, but there are no users, the system reserves five codes, bringing the total occupancy to 35%.
3. Max code tree occupancy
The user can use the Maximum code tree occupancy KPI as a triggering point to upgrade (second
carrier). The occupancy ranges from 35% to 100%. When the maximum code occupancy is less than
80%, the code allocation failure rate still remains close to 0% and less than approximately 90% of
maximum code occupancy means that the code allocation failure rate is <1%. Therefore, the user
can use the 85-90% limit.
4. HSDPA channelization code downgrades RT (NRT)
This counter indicates the code tree congestion related to simultaneous REL99 and HSDPA traffic in
the cell. Because of congestion, the system frees the codes allocated to HSDPA, when required by
the RT/NRT DCH allocation. Cells with HSDPA reserve a minimum of five SF16 codes for HSDPA at
the start. If there is HSDPA traffic, and there is no need for R99 codes, the system will try to use up
to fifteen SF16 codes for HSDPA. The RT traffic (normal voice) has the highest priority, so high voice
traffic will be able to keep the number of SF16 codes for HSDPA at the minimum of five codes.
5. Overload With the increase of code occupancy (that is, the R99 traffic increase) the throughput per user
decreases.
6. Upgrade Two basic solutions for avoiding the effect of code congestion are:
1. Reduce the code usage
Reduce the initial R99 bit rate from 128 kbps to 64 kbps or even 16 kbps. Allow R99 NRT to take
codes from HSDPA, for example, allow two SF16 codes to be taken. It is not recommended to
enable the high rate features if there are no 15-code UEs in the network, or if there are other limits
(for example, in the BTS or Iub).
2. Add new codes with new carrier
To obtain more codes, install an additional carrier.
Issue: 03I DN0972569 33

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN and Flexi Direct Capacity
4 Multiradio Flexi BTS WCDMA capacity

In order to monitor Flexi BTS capacity issues, it is important to know the following:
• used configurations:
– logical configurations, for example, whether there are one or multiple local cell
groups in use
– baseband configurations, for example, whether there are one or two system
modules in use
• possible capacity, that is, what is the “hard limit” of the entire capacity in the BTS:
– baseband and control plane capacity, that is, DSP capacity (given in subunits)
– throughput capacity, that is, the number of HSPA schedulers in the BTS
– user capacity, that is, the number of HSPA schedulers in the BTS
• used licenses, that is, what is the current maximum level of available capacity:
– license for R99 traffic, that is, R99 Channel Element license
– license for HSPA traffic, that is, HSxPA Processing Set licenses
– license for additional CCH resources, that is, CCH Processing Set licenses
In addition, a separate license is needed for the user amounts on cell level.
• in the multiple LCG case, for example, multi operator RAN (MORAN) case:
– the split of the - BTS level - R99 Channel Element license between the used
LCGs
– the split of the - BTS level - HSDPA Processing Set license between the used
LCGs
– the split of the - HSUPA scheduler level - HSUPA Processing Set license
between the used LCGs
g RU40 does not bring any changes to FSMB baseband dimensioning rules. For details
on BTS configurations including HW FSMB System Module, see the RU30 baseband
dimensioning guidelines.
Used logical configurations

Table 9: FSMC/D/E and FSMF logical configurations lists that FSMF is split into the
following configurations:
Table 9 FSMC/D/E and FSMF logical configurations
FSMC/D/E and FSMF logical configurations
Logical entity BTS level LCG level Cell level
Logical cell group FSMF / no FBBA: max 2 - -
Other configurations: max 4
34 DN0972569 Issue: 03I

Managing WCDMA RAN and Flexi Direct Capacity Multiradio Flexi BTS WCDMA capacity
Table 9 FSMC/D/E and FSMF logical configurations (Cont.)
FSMC/D/E and FSMF logical configurations
Logical entity BTS level LCG level Cell level
Cell 1 FSM: max 12 -

• FSMC: 3
• FSMD: 6
• FSME: 9
• FSMF: 6
• FSMF + 1*FBBA: 12
• FSMF + 2*FBBA: 18
2 FSM: Only the most common
FSM combinations given here.
Currently FSMF is only available
as stand-alone FSM.
• FSMC+FSMD: 9
• FSMD+FSMD: 12
• FSME+FSMD: 15
• FSME+ FSME: 18
Used baseband configurations

Table 10: FSMC/D/E BTS baseband configurations lists the following issues that need to
be taken into account when following up the capacity of the whole FSMC/D/E BTS.
Table 10 FSMC/D/E BTS baseband configurations
FSMC/D/E BTS baseband configurations *
Baseband per BTS per LCG per SM

entity
System module max 1 one SM/BTS: shared between all -

(SM) LCGs
HSDPA based on SM for FSMC/D/E throughput max 2

scheduler(s) number shared/user number
commissioned between all LCGs
HSUPA based on max 1 max 2

scheduler(s) LCG number
Issue: 03I DN0972569 35

Table 11: FSMF BTS baseband configurations lists the following issues that need to be
taken into account when following up the capacity of the whole FSMF BTS.
Table 11 FSMF BTS baseband configurations
FSMF BTS baseband configurations *
Baseband entity per BTS per LCG per SM
System module max 1 one SM/BTS: shared between all -

(SM) LCGs
Fixed/sector BB pooling: 1
Flexible BB pooling: Shared
between LCGs based on
parameter
accessBBCapacity.
HSDPA based on max 2 max 8

HSUPA based on max 1 max 4

* for more information, see Dimensioning WCDMA RAN: Flexi BTS Baseband.
g The number of activated HSDPA schedulers depends on Tcell configuration; see
Dimensioning WCDMA RAN: Flexi BTS Baseband.
Possible system module capacity

Table 12: FSMF baseband capacity lists the total capacity of the system module(s) which
depend on the system module type(s).
Table 12 FSMF baseband capacity
Baseband capacity - FSMF
System module type F
Subunits FSMF (no extension): 5.5 subunit
FSMF + 1xFBBA: 11.5 subunit
FSMF + 2xFBBA: 17.5 subunit
FSMC/D/E: The total capacity of the system module (s) depends on the system module
type(s):Table 13: FSMC/D/E baseband capacity lists the total capacity of the system
module(s) which depend on the system module type(s).
36 DN0972569 Issue: 03I

Table 13 FSMC/D/E baseband capacity
Baseband capacity - FSMC/D/E
System module type C D E
Subunits 5 12 19
Possible throughput and user capacity: FSMC/D/E and FSMF:

Table 14: FSMC/D/E and FSMF throughput capacity lists the total throughput capacity of
the BTS which depend on the number of HSPA schedulers and the number of subunits
in the system module(s).
Table 14 FSMC/D/E and FSMF throughput capacity
Throughput capacity - FSMC/D/E and FSMF
Throughput Set by Throughput Available steps Max capacity

type step
HSDPA HSDPA 7.2 Mbit/s 35 252 Mbit/s

throughput scheduler
HSUPA HSUPA 5.8 Mbit/s 20 116 Mbit/s

throughput scheduler
The table above shows the maximum throughput capacity of one HSDPA or HSUPA
scheduler. Whether it is possible to reach this depends on the number of available
subunits in the related system module. The subunit capacity is mapped to throughput
capacity (in Mbit/s) in terms of steps. The used throughput steps are also given in the
table. A detailed description about how throughput steps are mapped to the subunits in
system modules is found in Dimensioning WCDMA RAN: Flexi BTS Baseband.
The total used capacity to the BTS depends on the number of HSPA schedulers. In
addition, there are separate limits in the HSUPA scheduler for LCG and Cell levels.
Table 15 FSMC/D/E and FSMF user capacity
User capacity - FSMC/D/E and FSMF
User type Set by Max capacity Level
HSDPA users HSDPA scheduler 240 users HSDPA scheduler
HSUPA users HSUPA scheduler 240 users LCG
Issue: 03I DN0972569 37

Table 15 FSMC/D/E and FSMF user capacity (Cont.)
User capacity - FSMC/D/E and FSMF
User type Set by Max capacity Level
g 480 per LCG is only
possible if there is
exactly one
LCGx2xFSMr2 and cell
to FSM mapping is
used (2 schedulers in
one LCG).
HSUPA users HSUPA scheduler 128 users Cell
Multiple LCG case

Table 16: FSMC/D/E or FSMF capacity licensing lists options for the operator to share
the licensed capacity between configured LCGS during multiple LCG cases.
Table 16 FSMC/D/E or FSMF capacity licensing
FSMC/D/E or FSMF capacity licensing
LCGs R99 CE license HSDPA License Commissioning HSUPA License Commissioning

commissioning
Users Throughput Users Throughput
LCG1 Dedicated or Common share Throughput is proportionally Dedicated share Dedicated share

common share shared at the start-up
assignment. Therefore, after
the start-up is done, each
scheduler has a dedicated
share of total throughput.


38 DN0972569 Issue: 03I

Table 16 FSMC/D/E or FSMF capacity licensing (Cont.)
FSMC/D/E or FSMF capacity licensing
LCGs R99 CE license HSDPA License Commissioning HSUPA License Commissioning

commissioning
Users Throughput Users Throughput

In addition, there are separate CCCH processing licenses in FSMF.
Figure 9 FSMC/D/E and FSMF capacity
Issue: 03I DN0972569 39

4.1 BTS baseband capacity

This section consists of two parts. The first section describes the baseband capacity
configuration and processing principles. The baseband capacity licensing principles are
introduced as well. The second section describes the baseband capacity monitoring with
needed use cases including the available counters/KPIs.
4.1.1 Baseband capacity configuration and processing

principles
The operator is able to allocate the needed baseband capacity from the possible
baseband capacity (see Possible system module capacity and Possible throughput and
user capacity: FSMC/D/E and FSMF in this chapter) via licenses.
There are separate licenses for R99 and HSPA:
Table 17 R99 channel element pool-based license
R99 channel element pool based-license
R99 license type Level CE vs. subunit Maximum licensed

capacity CEs
Channel elements BTS FSMC/D/E: One Depends on used

subunit = 48 R99 CEs system module
type(s)
FSMF: One subunit =
96 R99 CEs
Table 18 HSxPA processing sets
HSxPA processing sets
HSxPA license Level HSxPA Processing set contains

type
Users Throughput
HSDPA1 BTS 32 7.2
HSDPA2 BTS 72 21
HSDPA3 BTS 72 84
HSUPA1 HSUPA 24 5.8

scheduler
40 DN0972569 Issue: 03I

g The licensed number of processing sets will vary based on operator needs. If the
operator uses Generic License key instead of dedicated processing set licenses, then
all the licensed set numbers are set to 99.
g In addition to the HSxPA processing set licenses, the operator also needs to have
separate HSPA user number licenses. These are controlled with RAN level HSPA user
number feature RAN1686: HSPA 72 Users Per Cell.
BTS HW commissioning vs. licensing

The HW resources to allocate are commissioned in the following order:
1. HSDPA
2. CCH
3. HSUPA/R99 CE
1. Even if the HSDPA-reserved HW are allocated first, there are issues to scheduler
parameter settings and over licensing to check that can cause a non-planned
shortage in HSDPA resource utilization.
• HSDPA throughput step parameter: This sets the available user capacity
throughput regardless of what throughput level/step is licensed.
• Over-licensing of HSDPA users: The HSDPA scheduler user capacity is the
actual user limit and not the licensed number.
2. As the HSUPA HW reservation is done at last AND in conjunction with R99 HW
reservation, there are issues related to dynamic and over-licensing to check not to
cause a non-planned shortage in HSUPA resource utilization.
• Dynamic licensing of HSUPA vs. R99 resources
– Non-overlapping resources between HSUPA and R99 (see Figure 10: Non-
overlapping baseband resources)
– Overlapping resources between HSPUA and R99 (see Figure 11:
Overlapping baseband capacity and static resources reservation)
• Over-licensing of HSUPA users: The HSUPA scheduler user capacity is the

actual user limit and not the licensed number.
Issue: 03I DN0972569 41

Figure 10 Non-overlapping baseband resources
License non-overlapping case
One HSUPA BTS Processing Set

(equivalent of 48 R99 CE) is always
available for R99 users and HSUPA users*
System Module Rel.2
*Note: 48 CE in each
LCG is always dynamic
HSDPA (even without license
HSUPA BTS
R99 CE licenses commissioned overlapping).
processing sets
throughput
Free (unlicensed) baseband

resources - not available for
Baseband resources R99 users and HSDPA
available for R99 users data users
Figure 11 Overlapping baseband capacity and static resources reservation
One HSUPA BTS Processing Set

(equivalent of 48 R99 CE) is always
available for R99 users and HSUPA users*
Overlapping scenario
System Module Rel.2
HSDPA
HSUPA BTS
R99 CE licenses commissioned
processing sets
throughput
Rel 99 users Baseband resources

HSUPA users available for R99 users only!
Overlapping baseband capacity

48 CE HSUPA BTS can be dynamically shared
(dynamic) Processing sets between HSUPA and R99 users*
*R99 users always have higher priority
For overlapping Rel99 CE licenses and licensed HSUPA resources, commissioning can be
performed in order to guarantee resources for HSUPA.
NOTE: Up to four HSUPA resource steps can be statically commissioned for HSUPA.
R99 CE management
The channel element (CE) represents the Rel99 processing capability of the DSP
hardware located in the system module of the Flexi BTS. The parameters Access
baseband capacity (accessBbCapacity) and Dedicated baseband
capacity (dedicatedBbCapacity) are used to configure Rel99 CE license allocations
for LCGs. The maximum available Rel99 CEs per LCG and thus per BTS in these
measurements depend on the configuration of these parameters.
42 DN0972569 Issue: 03I

R99 CE processing principles

Each Rel99 RAB type loads the DSP differently; therefore, the number of channel
elements representing each service depends on the allocated UL/DL bit rate. If there is
not enough DSP capacity represented by the channel elements for a new connection,
the BTS blocks the new service. The user is able to control the number of CEs with a
license up to the limit supported by the hardware. The BTS temporarily allows allocation
of capacity beyond the licensed limit, but up to the maximum available HW capacity only.
The channel element bookkeeping rules for common channels and Rel99 services differ.
The DSP is also required for control plane, NAS signaling (location updates, routing area
updates), and SMSs.
Please note that in FSMF, additional CCH resources (not included into FSM price) does
not consume Rel99 CE license but CCCH PS licenses.
HSDPA capacity management and processing principles
There are three options for the HSDPA processing sets depending on the traffic volumes.
If there is no HSDPA processing set available, the HSDPA is not enabled at all.
The number of HSDPA users and the maximum throughput (processing set licenses) are
controlled on the BTS level and is divided between the LCGs according to the
commissioned shares when baseband pooling is used. The parameters used are
shareOfHsdpaUser and mhsdpaSchedList. The licensed number of HSDPA users is
controlled on the BTS level and is divided with shareOfHhsdpaUser between LCGs.
Licensed HSDPA throughput, however, is controlled by a HSDPA scheduler. The
licensed throughput is divided between schedulers proportionally to the throughput
commissioned with mhsdpaSchedList. However, the Tcell configuration of the LCGs
should also be checked to find out the LCG's cell distribution on HSDPA schedulers and
thus, the maximum throughput available for the LCGs.
HSUPA capacity management and processing principles
There is only one type of the HSUPA processing set present. If no HSUPA processing
set is available, the HSUPA is not enabled.
Note that the HSUPA/HSPA service is activated only if HSDPA is enabled on the
BTS/cell level. If baseband pooling is used, the HSUPA licenses are divided between
LCGs according to the commissioned share. The parameter used is
shareOfHsupaLicenses.
The system reserves the capacity for the HSUPA on the basis of need, with specific
sizes of the resource steps. There is no default minimum reservation for the HSUPA.
However, it is possible to define minimum HSUPA resources with the HSUPA BB
decoding capacity and HSUPA BB minimum users commissioning parameters if
needed.
Another important aspect is that the very first HSUPA processing set license is dynamic,
that is, the R99 allocations is made with this license (even without any R99 CE licenses).
The only exception is the minimum reserved HSUPA capacity if any, by commissioning.
Further HSUPA licenses are not dynamic unless they are overlapped with some R99 CE
licenses at any time.
A multi-RAB UE is treated as a single UE on the system level, thus from both the user
count and throughput point of view, its resource consumption method is similar to that of
a single RAB UE. Thus, the HSxPA multi-RAB UE consumes capacity from the available
HSDPA and HSUPA processing set.
References
Issue: 03I DN0972569 43

The CE reservations and dimensioning rules for common channels as well as more
detailed information on LCGs and baseband capacity distributions are explained in
Dimensioning WCDMA RAN: Flexi BTS Baseband.
The resource steps, sizes, and HSxPA processing sets as well as more detailed
information on LCGs and baseband capacity distributions are described in Dimensioning
WCDMA RAN: Flexi BTS Baseband.
See WCDMA RAN License Operation and License Management Principles for more
information related to license setup.
4.1.2 Baseband capacity monitoring

Baseband capacity monitoring cases description
The available baseband capacity is based on a BTS-level or a HSUPA scheduler-level
license, that is, the licenses are based on R99 CEs and HSxPA processing sets and not
the subunits located in the system modules.
Therefore, the monitoring is (primarily) based on following the license utilization rates
and not the consumption of subunits/baseband/DSP HW resources (see Possible
system module capacity). If needed, the DSP HW resource, that is, the subunit utilization
level can be seen. This requires then additional mapping between the monitored license
related utilization rates and what it means in terms of subunit consumption. This is done
via following the mapping instructions given above in the introduction section Possible
system module capacity, Possible throughput capacity, and Possible user capacity. The
operator also needs to consult the Dimensioning WCDMA RAN: Flexi BTS Baseband
document.
The BTS HW capacity is further grouped (pooled), that is, the BTS consists of one to four
pools (local cell groups, LCGs). Thus, there are two different cases for capacity
monitoring:
• One LCG, that is, baseband pooling is not used (see Figure 12: No BTS baseband
pooling in use):
License monitoring is simple, as the BTS licensed capacity = the LCG licensed
capacity.
Monitoring sub case setup: The monitoring is performed on either LCG or BTS
level as the LCG level equals the BTS level.
Monitoring sub case analyze: If LCG resource consumption is high, then the
problem is directly related to the BTS/HSUPA scheduler license shortage or
baseband shortage (in case of all baseband capacity is licensed).
• 2 - 4 LCGs, that is, baseband pooling is used (see Figure 13: BTS baseband pooling
in use):
License monitoring is more complicated, as the licensed baseband capacity is
distributed among the LCGs according to the commissioning setup, common LCG
pool and/or common schedulers.
– The assigned part of the R99 CE license is distributed to the LCGs according to
the commission setup. Unassigned Rel99 CE licenses are in common LCG pool,
and licenses from that pool is by any LCG on need basis. This common share is
controlled on a BTS level.
– The licensed HSDPA throughput is shared between LCGs in case of
commissioning. The maximum value depends on the available HSDPA
processing sets. If commissioning was not done, the throughput is shared
44 DN0972569 Issue: 03I

according to the default allocation rule (see Table System Module Rel.2 HSDPA
throughput steps in section Flexi System Module Rel.2 HSDPA scheduler in
Dimensioning WCDMA RAN: Flexi BTS Baseband).
– HSDPA user shares of used licenses in case of commissioning is shared
between LCGs up to maximum allocation of 100% licensed capacity. If not, the
remaining capacity is put to the shared LCG pool. If commissioning was not
performed for these licenses, then each LCG gets equal share and there is no
common pool of licensed users.
– For HSUPA, there is no common part - commissioning has to be performed so
that values sum up to 100%. If commissioning was not performed, then each
LCG gets equal share.
Monitoring sub case setup:
The monitoring is performed on an LCG level, that is, separately for each baseband
pool or for the whole BTS.
Monitoring sub case analyze:
If the LCG resource consumption is high, then the problem is either based on the
commissioned LCG resource shortage, or full BTS license shortage, or baseband
shortage (in case of all baseband is licensed).
– BTS Level monitoring: If the BTS resource consumption is high, then the
problem is either based on the BTS license shortage or baseband shortage (in
case of all baseband is licensed).
Figure 12 No BTS baseband pooling in use
Figure 13 BTS baseband pooling in use
Issue: 03I DN0972569 45

g There are more WBTS/LCG baseband monitoring counters/KPIs that are available than
the indicated counters/KPIs in Table 19: Baseband capacity monitoring. For a complete
list of available counters, see the Multiradio Flexi BTS WCDMA related performance
monitoring feature RAN2626: Baseband Load Monitoring.
Table 19 Baseband capacity monitoring
1. Monitored Monitored capacity item description
capacity item
Total licensed The “WBTS level monitoring” (M5008) measurement measures HW utilization on the WBTS level.
HW utilization
ratio
R99 CE Baseband pools not in use: The “WBTS level monitoring” measurement (M5008) measures R99 CE
utilization utilization on the WBTS level.
Baseband pools in use: The “WBTS R99 resource” (M5006) measurement measures R99 CE utilization
on the LCG level.
HSxPA Baseband pools not in use: The “WBTS level monitoring” measurement (M5008) measures HSxPA
processing set processing set utilization on the WBTS level.
utilization
Baseband pools in use:
• The “WBTS R99 HW resource” (M5006) measurement measures HSxPA user utilization on LCG
level.
• The “HSPA in WBTS” (M5000) measurement measures HSxPA throughput on a cell level.

monitoring flag
In case baseband pooling is not used
R99 CE RNC_5483a Average used CE 70% 80% The average amount of CE used for R99 users in

utilization - DL for R99 DL [%] DL over the whole measurement period duration,
obtained by sampling with predefined sampling
period, summing all the samples and dividing by the
number of samples of the measurement period.
Note that this is in the WBTS level.
R99 CE RNC_5484a Average used CE 70% 80% The average amount of CE used for R99 users in

utilization - UL for R99 UL [%] UL over the whole measurement period duration,
obtained by sampling with predefined sampling
period, summing all the samples and dividing by the
number of samples for the measurement period.
Note that this is in the WBTS level.
HSxPA RNC_5407a The average HSDPA processing sets utilization

processing set Average HSDPA
ratio. Processing set utilization ratio is based on two
utilization processing sets 70% 80%
IHSPA_5407 conditions: throughput utilization and the number of
utilization ratio [%]
a users.
46 DN0972569 Issue: 03I

Table 19 Baseband capacity monitoring (Cont.)
RNC_5405a The maximum HSDPA processing sets utilization
Maximum HSDPA
100 ratio. Processing set utilization is based on two
processing sets 70%
IHSPA_5405 % conditions: throughput utilization and the number of
utilization ratio [#]
a users.
RNC_5408a The maximum HSUPA processing sets utilization
Average HSUPA
ratio. Processing set utilization is based on two
processing sets 70% 80%
IHSPA_5408 conditions: throughput utilization and the number of
utilization ratio [#]
a users.
RNC_5406a The maximum HSUPA processing sets utilization
Maximum HSUPA
100 ratio. Processing set utilization is based on two
processing sets -
IHSPA_5406 % conditions: throughput utilization and the number of
utilization ratio [%]
a users.
In case baseband pooling is used
RNC_2256a UL CE R99 utilization distribution rate - (80 - < 90)%
provides information about the percentage of
measured events, for uplink traffic, which indicate
that the Channel Elements Usage Ratio was
between 70% and 80% of existing resources.
UL CE R99
utilization Threshold clarification:
3% 5%
distribution rate - Target => when the consumption of CEs in BTS
IHSPA_2431 (80 - < 90)%
a reaches 3% (at least) in the range of 80% - 90% of
the available capacity.
Red flag => when the consumption of CEs in BTS
reaches 5% in the range of 80% - 90% of the
available capacity.
R99 CE
utilization - UL
RNC_2257a UL CE R99 utilization distribution rate - (90 - <
100)% provides information about the percentage of
UL CE R99 measured events for uplink traffic, which indicates
utilization that the Channel Elements Usage Ratio was
1% 2%
distribution rate - between 90% and 100% of existing resources.
IHSPA_2432 (90 - < 100)%
a Threshold clarification: see RNC_2256a
description.
RNC_2258a UL CE R99 - 0% UL CE R99 Utilization Distribution Rate - (100 or

Utilization more)% provides information about the percentage
Distribution Rate - of measured events for Uplink traffic, which indicate
(100 or more) [%] that the Channel Elements Usage Ration was
between 100% or more of existing resources.
RNC_2264a DL CE R99 - 0% DL CE R99 Utilization Distribution Rate - (100 or

utilization more)% provides information about the percentage
R99 CE distribution rate - of measured events for Download traffic, which
utilization - DL (100 or more) [%] indicate that the Channel Elements Usage Ratio
was between 100% or more of the existing
resources.
Issue: 03I DN0972569 47

RNC_2262a DL CE R99 utilization distribution rate - (80 - < 90)%
provides information about the percentage of
DL CE R99 measured events for downlink traffic, which
utilization indicates that the Channel Elements Usage Ratio
3% 5%
distribution rate - was between 80% - 90% of existing resources.
IHSPA_2425 (80 - < 90)%
description.
RNC_2263a DL CE R99 utilization distribution rate - (90 - <
100)% provides information about the percentage of
DL CE R99 measured events, for downlink traffic, which
utilization indicate that the Channel Elements Usage Ratio
1% 2%
distribution rate - was between 80% - 90% of existing resources.
IHSPA_2263 (90 - < 100)%
description.
RNC_2268a HSPA UL user 3% 5% HSPA UL user utilization distribution rate - (80 - <

utilization 90)%, provides information about the percentage of
distribution rate - measured events for HSPA uplink traffic, which
(80 - < 90) [%] indicate that Channel Elements Usage Ratio was
between 60 and 80% of the existing resources.
RNC_2269a HSPA UL user 1% 2% HSPA UL user utilization distribution rate - (90 - <

HSxPA
utilization 100)% provides information about the percentage of
processing set
distribution rate - measured events for HSPA uplink traffic, which
utilization -
(90 - < 100) [%] indicate that the Channel Elements Usage Ratio
HSPA users
was between 80 and 100% of the existing
UL
resources.
RNC_2270a HSPA UL user - 0% HSPA UL user utilization distribution rate - 100%

utilization provides information about the percentage of
distribution Rate - measured events for HSPA uplink traffic, which
100 [%] indicate that the Channel Elements Usage Ratio
was 100% of the existing resources.
RNC_2274a HSPA DL user 3% 5% HSPA DL user utilization distribution rate - (80 -

distribution rate - measured events for HSPA downlink traffic, which
was between 60 and 80% of the existing resources.
RNC_2275a HSPA DL user 1% 2% HSPA DL user utilization distribution rate - (90 -

HSxPA
processing set
utilization -
HSPA users
was between 80 and 100% of the existing
DL
resources.
RNC_2276a HSPA DL user - 0% HSPA DL user utilization distribution rate - 100%

utilization provides information about the percentage of
100 [%] indicate that the Channel Elements Usage Ratio
was 100% of the existing resources.
48 DN0972569 Issue: 03I

HSxPA RNC_5485a HSUPA average 70% 80% Average HSUPA MAC-es throughput [kbit/s].
processing set MAC-es throughput
utilization - [kbit/s]
HSPA
throughput UL
HSxPA RNC_1455b HSDPA MAC-hs 70% 80% Average HSUPA Mac-hs throughput [kbit/s].

processing set throughput [kbit/s]
utilization -
HSPA
throughput DL

monitoring
See the reactive counters in User plane capacity.
4. Analyses Use the RNC_5415a KPI to follow the utilization ratio of the total licensed HW on the BTS level. The HW
is consumed by Rel99, HSDPA, HSUPA, CSoHSPA, common channels, and so on. Note that this KPI
must be analyzed in conjunction with the Rel99 CE and HSxPA processing set utilization counters and
KPIs to determine the specific area of the bottleneck.
Baseband pooling not in use:
1. R99 CE utilization
Follow the total CE utilization, in the uplink and downlink with the following KPIs:
• UL: RNC_2256a, RNC_2257a
• DL: RNC_2262a, RNC_2263a
The sampling interval (5 seconds) used in the utilization KPIs might not capture the sharp load peaks.
Follow the average R99 CE utilization in the uplink and downlink with the following counters:
• UL: M5008C8, RNC_5484a
• DL: M5008C5, RNC_5483a
2. HSxPA processing set utilization
Average and maximum HSDPA processing set utilization (%) is monitored proactively by RNC_5407a
and RNC5405a KPIs, and the same for HSUPA processing set utilization (5) is monitored by
RNC_5408a and RNC_5406a KPIs.
These KPIs measure the number of users, throughput, and the HW utilization (HSUPA) separately
and the bigger average value out of them.
Baseband pooling in use:
1. R99 utilization
Follow the total CE utilization, in the uplink and downlink, with the following KPIs:
• UL: RNC_2256a, RNC_2257a
• DL: RNC_2262a, RNC_2263a
The sampling interval (95 seconds) used in the utilization KPIs might not capture the sharp load
peaks.
2. HSxPA processing set utilization
There are no specific counters/KPIs for HSxPA processing set utilization on the LCG level. Instead,
there are separate counters/KPIs for 2.1) HSxPA throughput and 2.2) HSxPA users utilization.
a) HSxPA throughput utilization
Issue: 03I DN0972569 49

Follow the HSxPA throughput utilization, in the uplink and downlink, with the following KPIs:
• UL: RNC_5485a
• DL: RNC_1455b
The counters/KPIs
• are on a cell level, therefore, they must be separately summed up to LCG level.
• provides a kbit/s and not a percentage (%) value like given for the threshold(s)
– the licensed/commissioned throughput level must be obtained separately
– after that, the percentage (%) value is obtained (measured kbit/s/licensed kbit/s)
b) HSxPA user utilization
Follow the total HSxPA user utilization, in the uplink and downlink, with the following KPIs:
• UL: RNC_2268a, RNC_2269a, RNC_2270a
• DL: RNC_2274a, RNC_2275a, RNC_2276a
The sampling interval (5 seconds) used in the utilization KPIs might not capture the sharp load
peaks.
5. Overload On nearing the 100% utilization level, there could be degradation in quality or rejection of service requests
for the Rel99 and/or HSxPA, depending on which license is reaching the threshold.
R99 CE utilization: See overload instructions for BTS user plane capacity.
HSxPA processing set utilization: See overload instructions for BTS user plane capacity.
6. Upgrade Checking the licensed level of HW resources:
In case there is a need to license more HW resources, KPI RNC_5415a indicates the current percentage
of the already licensed HW resources.
Possible upgrade actions: R99 CE upgrade need
1. Increase the R99 CE licenses if it is allowed by the installed HW.
2. Expand the capacity by installing a second system module in the Flexi BTS.
3. In the case of no license and HW limitations, follow the steps found in BTS user plane capacity.
Possible upgrade actions: HSxPA capacity upgrade need
1. Increase the HSDPA/HSUPA processing set licenses if it is allowed by the installed HW.
2. Expand the capacity by installing a second system module in the Flexi BTS.
3. In the case of no license and HW limitations, follow the steps found in BTS user plane capacity.
4.2 BTS control plane capacity

The control plane at the BTS refers to processing of C-NBAP and D-NBAP messages.
The system uses C-NBAP for the initial radio link (RL) setup signaling between RNC and
BTS common channel measurements. The system uses D-NBAP for signaling of the RL
re-configurations, RL additions, and deletions. The master control unit (MCU) processes
the control plane. In the Flexi BTS, the System Module represents the MCU. The MCUs
50 DN0972569 Issue: 03I

also have other tasks related to O&M, hardware management, and common (radio-
technology-independent) support functions. Therefore, there is a load on the MCU, even
if the user traffic is not processed by the WBTS.
g The signaling capacity of the BTS Control Plane depends heavily on the traffic profile
that is the assumed call mix produced by the different types of subscribers. The given
targets for the use cases below are based on the measured field experience from smart
phone dominant environment as explained in the analyses part of
Table 20: BTS control plane capacity.
Table 20 BTS control plane capacity
1. Monitored Monitored capacity item description.
capacity item
Radio link The signaling load in the WBTS measurement (M5004) measures the radio link capacity on the WBTS
capacity level.
Iub overload The Service Level measurement (M1001) and RRC Signaling measurement (M1006) measures different
protection Iub Overload Protection scenarios on WCELL level.

monitoring flag
Radio Link M5004C1 Peak RL 56 RL/s (2 - Peak radio link setup messages handled per

setups per FSME) second, where the handled setups are those
Capacity -
second [#] that have not been rejected because of
Attempts 22 RL/s (1
congestion.
FSMD)
70 RL/s
(FSMF +
2xFBBA)
Radio Link M5004C3 Average RL 500 ms - Average radio link setup request message

Capacity - setup message queuing time before handled.
Delays queuing time
[ms]

monitoring
Radio Link M5004C0 Number of Number of rejected radio link setup requests because of congestion

Capacity - rejected RL on the MCU (signaling load too high).
BTS rejections setups due to
congestion [#]
Radio Link M1001C4 RRC setup The number of RRC setup failures caused by BTS or Iub overload

Capacity - failures due to control.
RNC BTS reasons
rejections [#]
Issue: 03I DN0972569 51

Table 20 BTS control plane capacity (Cont.)
Common M1006C203 RRC The number of RRC connection rejections because of Iub overload
Channel Connection control.
Service Reject due to
Capacity - Iub overload
RNC control
rejections
4. Analyses 1. Radio link setup load in WBTS
The RL setup message was selected to represent the BTS control plane load. The load is available
with the M5004C1 Peak RL setups per second counter. See the WBTS product documentation for
details on the maximum values of each BTS variant.
Target setting note: In normal high-load operating conditions, the BTS should not have more than 30-
40 peak RL setups per second for the BTS having capacity equivalent to 2FSMEs in use. The given
threshold is 40% above the upper boundary, that is, values of 56 RL/s or higher for peak RL setups
per second indicate increased control plane traffic which can be an indication of capacity limitations at
the user plane.
Similarly, the BTS having capacity equivalent to 1 FSMD in used should not have more than 22 RLs/s
(usual high load condition is between 8-16 RL/s).
Similarly, the BTS having capacity equivalent to FSMF + 2xFBBA in used should not have more than
70 RL/s (usual high load conditions is between 38-50 peak RL/s).
2. RL setup message queuing time
An increase in the RL setup message queuing time indicates that the BTS control plane cannot
process all incoming messages immediately. This is an indication that BTS control plane processor
load is reaching maximum. BTS control plane overload is seen as a high value of rejected RL setups.
The message queuing time adds to the RL setup time, and thus the end-user experience. The
maximum queuing time is 3000 ms, but a value above 500 ms should be observed closely.
3. Rejected RL setups due to congestion
This counter points out the lack of control-plane capacity proactively. The number of rejected RL
setups because of congestion increases sharply when the BTS reaches the signaling capacity limits
and starts to reject new setups.
4. Rejected RRC setups due to BTS reasons
The counter records Radio Link rejections because of Iub overload detected in RNC or rejections by
BTS (M1001C4).
In this case, there is a need to setup a service on the Dedicated or Shared channel. The RNC does
not send anymore RL setup messages to BTS. Therefore, not all RL setup rejections will be recorded
in the primary BTS RL Capacity counter (M5004C0).
g As the M1001C4 includes also BTS related rejections, there will be some overlapping between
the usage of this counter and with M5004C0.
5. Rejected RRC setups due to Iub overload control
The counter records RRC Connection setup rejections because of the Iub overload detected in RNC.
In this case, there is a need to setup a service on the Dedicated or Shared channel. But RNC will
reject the operation in the RRC Connection setup phase. The RNC does not send any RL setup
messages to BTS in this overload condition. This case is transparent to BTS but the user will
experience service degradation.
If BTS C-plane capacity problems are suspected, verify if BTS control plane capacity is really the
bottleneck. In particular, check the air interface, and the BTS CE capacity. Congestion of these
causes overload at the BTS control plane.
5. Overload The BTS and/or RNC should limit the load during overload by rejecting radio link setups. The impact of the
load that limits the network might vary, for example:
• UEs might lose the coverage; after that, retries of the location update with the registration cause might
occur.
52 DN0972569 Issue: 03I

Table 20 BTS control plane capacity (Cont.)
• The number of radio link setups can increase exponentially, because of repeated UE attempts to
connect to the network. Note that the subscriber also might try to connect repeatedly.
• The AMR allocation duration per call might become extremely low (a few seconds) because of the
overload.
Make sure that the user plane and feature licensing does not impose limitations that will be reflected in the
control-plane overload. In addition, optimize the antenna placements to avoid fragmented cell coverage
and black spots.
6. Upgrade Possible upgrade actions:
Control plane capacity improvement without license/HW upgrade
1. Make sure that the C-NBAP bandwidth is sufficient (see KPIs found in IP-based route: IFC enabled
and ATM virtual channel - CBR) and the reporting common measurement reporting period is not
exhausting the C-NBAP.
2. Disable the BTS load-limiting functions in RNC, if there are any active.
3. In case of lack of CE resources causing overload in BTS, check the DCH initial bitrate and TBO and
EPBP parameterization in RNC.
• With TBO (Throughput-Based Optimization) and EPBP (Enhanced Priority-Based Scheduling)
parameterization, the CE resource usage in BTS for DCH bearer could be optimized so that the
DCH bearers do not consume BTS CE resources inefficiently:
– Tuning of TBO settings so that RNC downgrades inefficiently used DCH radio bearers’ bit
rate fast enough.
– Tuning of EBBP settings so that in case of DCH congestion, RNC downgrades existing users
to accommodate for the new entrants.
4. Activate the RAN1797: Common Channel Setup feature (see Activating RAN1797: Common Channel
Setup) that reduces connection setup signaling and the users in Cell_DCH state.
5. Activate the RAN2136: Fast dormancy feature for smart phone dominant networks where signaling
traffic is high.<isn’t it RU40 feature?>
6. Activate RAN1644: Continuous Packet Connectivity feature (see Activating RAN1644: Continuous
packet connectivity).
Control plane capacity improvement with license/HW upgrade
1. Increase the R99 CE/HSxPA processing set licenses if it is allowed by the installed HW.
2. Add new hardware.
4.3 BTS user plane capacity

BTS throughput capacity
The maximum throughput supported by an HSDPA scheduler is 252 Mbps. Note that one
System Module can have a maximum of two schedulers shared by all LCGs, and the
BTS maximum throughput capacity depends on activated features, number and types of
HSDPA processing sets, and the HSDPA scheduler throughput commissioned.
BTS user capacity
Issue: 03I DN0972569 53

The cell connectivity is the number of subscribers connected to the BTS and the cell.
The BTS-specific capacity does not represent the sum of the cells. The REL99 does not
have any connectivity limits at the BTS; radio interface or CE capacity limits the number
of REL99 users.
The maximum number of HSDPA users supported by the scheduler is 240, and this also
depends on the activated features, and the number and type of HSDPA processing sets.
Note that the schedulers are shared across LCGs where the TCELL grouping is done to
configure the cells to the schedulers. The number of local cell groups per BTS is limited
to four. Note that one system module can have a maximum of two schedulers shared by
all LCGs, and one scheduler serves a maximum of cells. So, for a 12-cell configuration,
there are two schedulers, the maximum HSDPA users supported is 480. On the BTS
level, this means that a maximum total capacity of 2 * 480 users if there are two system
modules in use. For more information, see Dimensioning WCDMA RAN: Flexi BTS
Baseband.
There is a limited number of HSUPA users per WBTS, depending on the WBTS
configuration and the HSUPA features that are enabled in the WBTS. There is a
MaxNumberHSDPAUsers parameter, which might also limit some other numbers on the
cell level.
g In RNC, there is a parameter MaxNumberEDCHLCG that needs to be set according to
the HSUPA scheduler limitation in order to avoid unnecessary HSUPA rejections. This
happens if the RNC parameter has a higher value than what is allowed in the BTS
(based on the HSUPA scheduler capacity).
BTS cell level baseband capacity during mass events

In FSMC/D/E, all downlink channels (common and dedicated channels, not the shared
HS-PDSCH channel) of one cell are transmitted through one device. This downlink cell
dedicated device might get congested when high amount of downlink channels are
allocated to a single cell. Congestion might happen during mass events especially when
admission-control-limits-related parameters (for example PrxMaxTargetBTS or
PrxTarget ) for the cell are significantly increased from typical default values. When
congestion happens, new users (downlink channels) are no longer accepted in the cell
by the BTS. In FSMF, this kind of congestion is not applicable due to different HW
architectures.
The capacity of the downlink cell dedicated device in FSMC/D/E depends heavily on the
downlink traffic profile, such as the number of physical channels, spreading factors, and
channel reconfigurations, which means that comprehensive capacity target definition is
very difficult in all possible traffic profile cases. With simplified AMR (voice only traffic
profile) the commonly used target is roughly 80 AMR users per cell.
Table 21 BTS user plane capacity
1. Monitored Monitored capacity item description
capacity
item
HSxPA The WBTS level monitoring (M5008) measurement measures HSxPA throughput capacity on the WBTS
throughput level.
capacity
54 DN0972569 Issue: 03I

Table 21 BTS user plane capacity (Cont.)
HSUPA HW The Cell Resource (M1000) measurement measures different HSUPA HW limitations on the WCELL level.
limited
durations
Cell The L3 Signaling at Iub (M1005) measurement measures different RL congestion reasons on the WCELL
congestion level.
due to BTS
HSxPA The Traffic (M1002) measurement measures different HSxPA failure reasons on the WCELL level.
setup
failures
Number of The WBTS level monitoring (M5008) measurement measures the number/licensed number of HSxPA users
HSxPA on the WBTS level.
users
The Cell Resource (M1000) measurement measures number of HSxPA users on the WCELL level.

monitoring flag
RNC_5401a Average Average HSDPA

HSDPA throughput utilization
throughput 70% 80% ratio per BTS in
IHSPA_5409a utilization ratio reference to maximum
HSxPA [%] licensed throughput.
throughput
utilization RNC_5402a Average Average HSUPA
HSUPA throughput utilization
throughput 70% 80% ratio per BTS in
IHSPA_5402a utilization ratio reference to maximum
[%] licensed throughput.
HSUPA HW M1000C269 BTS HSUPA 36s 180s This counter indicates

- limited HW limited the amount of time in
duration duration [s] which the BTS local
cell HW pool (where
this cell belongs) is in
HSUPA HW-limited
state during the
measurement period.
In this state, the RNC
sets up the E-DCH, but
the BTS HW shortage
might cause the
throughput to be lower
than expected. The
same counter value is
updated for all HSUPA-
enabled cells in the
local cell group.
Issue: 03I DN0972569 55

RNC_5403a Average 70% 80% Average number of
number of HSDPA users
HSDPA users utilization ratio per BTS
utilization ratio in reference to
IHSPA_5403a per BTS [%] maximum licensed
users.
RNC_5398a Maximum number of
Maximum
HSDPA users
number of
utilization ratio per BTS
HSDPA users - 100%
in reference to
IHSPA_5398a utilization ratio
maximum licensed
Number of per BTS [%]
users.
HSxPA
users per
WBTS RNC_5404a Average number of
Average
HSUPA users
number of
HSUPA users 70% 80%
in reference to
maximum licensed
per BTS [%]
users.
RNC_5399a Maximum number of
Maximum
HSUPA users
number of
HSUPA users - 100%
in reference to
maximum licensed
per BTS [%]
users.
Number of RNC_645c Includes both single

HSxPA and dual cell HSDPA
users per users. The target value
WCELL depends on the
number of HSDPA
Average users enabled in the
number of cell.
simultaneous 70% -
IHSPA_645a HSDPA users The target
per cell [#] percentages
should be
g proportional to
the maximum
supported
number of users.
RNC_1686a Maximum
number of Includes both single
simultaneous - 100% and dual cell HSDPA
IHSPA_1036a HSDPA users users.
per cell [#]
RNC_1036b Average
Average number of
number of
simultaneous HSUPA
simultaneous 70% -
users in the target
IHSPA_1036a HSUPA users
object.
per cell [#]
56 DN0972569 Issue: 03I

RNC_1687a Maximum
number of Maximum number of
simultaneous - 100% simultaneous HSUPA
IHSPA_1687a HSUPA users users per cell.
per cell [#]

monitoring
RNC_673d HSDPA
Access failure HSDPA access failure rate because of BTS-
rate due to originated reason.
IHSPA_673b BTS [%]
RNC_1726a Streaming
HSDPA Setup HSDPA setup failure ratio because of BTS failures,
The target
HSxPA failure rate due for streaming traffic class. percentages
IHSPA_1726a to BTS [%]
setup should be
failures - due
to resource RNC_956d g proportional to
the maximum
E-DCH Setup The percentage of the E-DCH setup failures due to
shortage supported
FR due to BTS BTS for interactive, background and streaming
[%] class connections. number of users.
RNc_957d E-DCH Not The percentage of times when E-DCH uplink

Selected due transport channel cannot be selected in this cell for
to BTS HW interactive, background and streaming class
[%] connections, because BTS has reported to have no
capacity available for E-DCH.
RNC_660d DCH selected Congestion because of too many allocated users -

due to too ratio of allocation requests that are directed to DCH
many HSDPA (because of too many HSDPA users) over all
IHSPA_660a users [%] HSDPA allocations.
HSxPA
setup
failures - due RNC_968c Percentage of unavailable E-DCH uplink transport
to exceeded UL DCH channel for interactive, background and streaming
number of selected due class connections because of maximum amount of
users to too many E-DCH users in the cell exceed the limit defined by
IHSPA_968b HSUPA users MaxNuberEDCHCell or the number of E-DCH
[%] users in local cell group exceed
MaxNumberEDCHLCG.
HSUPA HW- M1000C270 BTS HSUPA This counter indicates the amount of time in which

limited HW no the BTS local cell group HW pool (where this cell
durations capacity belongs) is in the HSUPA HW-limited state during
duration [s] the measurement period. In this state, the RNC
Issue: 03I DN0972569 57

does not set up the E-DCH. The same counter
value is updated for all HSUPA-enabled cells in the
local cell group.
Cell M1005C179 This counter The number of radio link setup failures for the first

Congestion indicates the radio link due to miscellaneous cause. The first link
due to BTS- number of RL can be established either in the RRC connection
dedicated SETUP FAIL setup or state transition to CELL_DCH.
device FOR FIRST
RL DUE TO
MISC CAUSE
4. Analyses 1. HSxPA throughput utilization
The given KPIs show directly the HSxPA throughput utilization rates.
2. HSxPA users per BTS
The given KPIs show directly the user resource utilization rates. Note that the Dual Cell HSDPA required
more resources (approximately twofold compared to single cell users.
g These KPIs show low values every time there are more licensed than the available HW.
3. HSDPA users per cell
Use the maximum number of simultaneous HSDPA users per cell and the average number of
simultaneous HSDPA users per cell to see when the maximum number of users is approaching the limit
in a cell. Note that the Dual Cell HSDPA required more resources (approximately twofold) compared to
single cell users.
The number of HSDPA users on the cell level, or on the primary cell, is monitored with a KPI based on
the cell resource measurement (M1000). The system updates all M1000 counters for the primary cell of
the CD-HSDPA connection. The system does not update counters for the secondary cell. Parameters
define the maximum values of counters for HSDPA users on the BTS and cell level, therefore, the user
can use the counters proactively. The user is able to count the Dual Carrier HSDPA users with the
HSDPA in WBTS measurement (M5000). The user is able to see the DC HSDPA user in both cells,
forming a dual cell pair.
4. HSUPA users per cell
Use the maximum number of simultaneous HSUPA users per cell and the average number of
simultaneous HSUPA users per cell to see when the maximum number of users is approaching the limit
in a cell.
g For the maximum HSUPA user amount per configuration, see the
BTS baseband dimensioning guideline.
5. HSDPA and HSUPA setup failures
a) Because of resource shortage
Use the HSDPA and HSUPA setup failures (KPIs RNC_673d, RNC_1726a, RNC_956d and
RNC957d)) because of maximum users or throughput limitations reactively to give an indication of
the capacity problem if the proactive counters are not capturing sharp load peaks. Note that here,
the exceeded number of users means the cases when BTS sees that there are more users than
allowed on BTS and/or LCG level.
b) Because of exceeded number of users
Use the HSDPA and HSUPA setup failures (KPIs RNC_660d and RNC_968c) because of exceeded
number of users reactively, to give an indication of the capacity problem if the proactive counters are
not capturing sharp load peaks. Note that here, the exceeded number of users means the cases
when RNC sees that there are more users than allowed on WCELL level.
6. HSUPA HW-limited durations
58 DN0972569 Issue: 03I

Use the HSUPA HW-limited counters to determine if there has been limitations/lack of HW resources in
processing sets for HSUPA during the measurement period.
• The M1000C269 (BTS HSUPA HW-limited duration) counter indicates that the BTS may need to limit
throughputs of HSUPA UEs. It is therefore an indication that better throughputs could be given to the
UE with additional HW.
• The M1000C270 counter is used as a reactive measure indicating the duration of no HSUPA HW
capacity and thus no more HSUPA UEs are allocated as long as this state consists.
7. BTS congestion
Use the RL setup failure counter to determine if there is a significant number of RL rejections because of
congestion in the cell-dedicated-device realted during the measurement period. Note that this counter
also captures other failure reasons other than cell dedicated device related ones. A miscellaneous cause
that updates the counter for any cause that is specified in NBAP specification (TS 25.443). Nokia BTS
uses unspecified cause to indicate RL rejection of the congestion in the cell dedicated device. Whether
this unspecified counter is the real reason of the M1005C179 counter updates, the root cause can be
analyzed other than counter means.
5. Overload 1. HSDPA user capacity
If the maximum number of HSDPA users has exceeded on the cell or BTS level, the RNC allocates an
R99 connection instead.
2. Mass event handling
During BTS congestion, new users (downlink channels) are no longer accepted in the cell by the BTS.
3. HSUPA user throughput capacity
The lack of processing set resources for HSUPA leads to overload. With more overload, the HSUPA
throughput is affected and eventually new HSUPA users are blocked. At this state the BTS gives the UE
a minimum allocation of ~32kbps with an access to a peak data rate of ~384kbps. A high signaling
rejection rate occurs because of insufficient channel elements for signaling, or because the base station
could not handle the signaling load. See BTS control plane capacity for further analysis.
6. Upgrade Possible upgrade actions:
R99 CE throughput capacity improvement without license/HW upgrade
1. Enable priority-based scheduling to downgrade users in case of congestion.
2. Use R99 resources efficiently by tuning CELL-FACH and CELL_DCH parameters (FACH/DCH inactivity
timers, wait and guard timers, and so on), and by tuning the SHO overhead for the NRT traffic.
R99 CE throughput capacity improvement with license/HW upgrade
1. In the case of license or HW upgrade need, follow the steps found in Baseband capacity monitoring.
Possible upgrade actions:
HSxPA throughput capacity improvement without license/HW upgrade
1. Enable the RAN395: Enhanced Priority Based Scheduling and Overload Control for NRT Traffic feature
to downgrade users in case of congestion.
2. Enable the RAN1013: 16 kbit/s Return Channel DCH Data Rate Support for HSDPA feature. When 16
kbit/s is activated, the throughput-based optimization and flexible upgrade features are be activated for
the HSDPA return channel with the DynUsageHSDPAReturnChannel parameter.
3. Use R99 resources more efficiently by tuning CELL_FACH and CELL_DCH parameters (FACH/DCH
inactivity timers, wait and guard timers, and so on.), and by tuning the SHO overhead for the NRT traffic.
4. Activate the RAN1797: Common Channel Setup feature (see Activating RAN1797: Common Channel
Setup).
5. Activate RAN1201: Fractional DPCH (see Activating RAN1201: Fractional DPCH), which improves the
efficient use of HSDPA radio resources.
Issue: 03I DN0972569 59

6. Activate RAN1644: Continuous Packet Connectivity feature (see Activating RAN1644: Continuous
packet connectivity) and optimize the Cell-DCH timer value.
With this feature, the idle timer in Cell_DCH state is extended. The number of HSPA allocations is
decreased when larger number of polling and web downloads occur when the UE is already in Cell_DCH
state. The key points to be noted are:
• This is beneficial mostly for Control Plane capacity (see BTS control plane capacity/Upgrade
instructions)
• For baseband/HW capacity point of view, this might be a problem if there are lots of laptops in the
network that stays in CELL_DCH state all the time because of this feature and thus, occupying all
the time the needed resources of one user.
• Therefore, the setting of the idle timer in CELL_DCH state needs to be tuned taking both baseband
and control plane capacity into account. Do not use the default timer value (90 seconds) when the
control plane capacity is sufficient even with a shorter value.
7. Activate RU30 feature RAN1637: High Speed Cell_FACH DLfor low capacity service needs, which saves
processing set resources as there are no additional reservations for DCH setups.
8. Activate RAN2879: Mass Event Handler feature to improve the networks' access during the mass event
and to decrease the UL load caused by the sequential service requests.
HSxPA throughput capacity improvement with license/HW upgrade
Possible upgrade actions:
HSxPA user capacity improvement without license/HW upgrade
1. Make sure that there are enough RNC licenses for the cell level capacity.
2. Reconfigure the TCELL (if possible) to completely utilize the available HSDPA schedulers.
3. Add more LCGs if possible.
HSxPA user capacity improvement with license/HW upgrade
60 DN0972569 Issue: 03I

Managing WCDMA RAN and Flexi Direct Capacity RNC capacity
5 RNC capacity
This chapter covers IPA-RNC, mcRNC and Flexi Direct common and specific capacity
issues. The user is able to follow the RNC capacity by monitoring the following capacity
items. Each capacity item should be monitored separately.
Figure 14 RNC capacity
RNC Capacity
Control plane User plane Connectivity Units
Capacity Voice Data User RNC DMCU /

Carriers
Planning Capacity Capacity Capacity USPU Fill Unit Loads
and sites
Factor
5.1 RNC control plane capacity

5.1.1 RNC control plane index
Table 22 RNC control plane load index
1. Monitored RNC control plane load index
capacity item
The following RNC control plane load index KPI is meant to be used as normalization factor or capacity
planning. They are not used on their own.
However, RNC control plane protocol processing concentrates on dedicated units, like ICSU. Hence, the
control plane monitoring is covered by the unit load monitoring.

monitoring flag
RNC control RNC_5234a Controller - - RNC control plane load factor, as a sum

plane load control plane of relevant control plane events for RAN
index load factor services: SRB service setup, Single or
[event/s] Multi RAB service setup, transport
channel setup and maintenance
(including channel type switches, HSPA
serving cell changes).

monitoring
- - -
4. Analyses See RNC Capacity Planning Proactive management / Controller Capacity Upgrade Planning
Issue: 03I DN0972569 61

RNC capacity Managing WCDMA RAN and Flexi Direct Capacity
Table 22 RNC control plane load index (Cont.)
5. Overload See RNC Capacity Planning Proactive management / Controller Capacity Upgrade Planning
6. Upgrade See RNC Capacity Planning Proactive management / Controller Capacity Upgrade Planning
5.2 RNC user plane capacity

There are four main groups in the RNC user plane capacity:
1. Voice capacity
In RNC2600 and mcRNC, HW configuration, the AMR capacity 1, ERL license is
mandatory. If there is no valid AMR capacity 1 Erl license installed in RNC2600, it
might not establish AMR Radio Access Bearers (RABs). The AMR capacity defines
the maximum number of simultaneous AMR radio access bearers. The RNC
periodically calculates the number of simultaneous AMR RABs. There is no
averaging applied. If the UE is in a soft handover state during the AMR RAB
establishment, only SRNC counts it as one AMR RAB. When you use anchoring,
only the anchor RNC calculates AMR RAB.
In Flexi Direct hardware configuration, the total available hardware capacity is free to
be used for CS services. However, there is maximum supported CS capacity
(Erlangs) defined in the product descriptions. This capacity defines the maximum
number of simultaneous AMR RABs. The Flexi Direct RNC periodically calculates the
average and maximum number of simultaneous AMR RABs. If the UE is in a soft
handover state, when the ARM RAB is established, only the serving Flexi Direct RNC
counts it as one AMR RAB. When you use anchoring, only the anchoring Flexi Direct
RNC calculates the AMR RAB.
2. Data capacity
Even if the licensed PS data throughput covers Iub, the system performs the
measurement on the Iu-PS interface. The RNC calculates periodically the amount of
bytes in the GTP packets received on each Iu-PS interface. Samples are averaged
over a longer period, and the resulting throughput is changed to Mbit/s. The PS
throughput on the Iub is factored by adding the FP header overhead factor (11%) to
the measured GTP throughput. The system does not count the Iu-CS traffic, Iur
traffic, or soft handover overhead of the PS data throughput.
In Flexi Direct RNC, the Iu-PS capacity licensing is trust-based, that is the customers
are charged according to the throughput consumption. The maximum target can be
configured by the parameter RNFC-DLPSGTPDataThroughputMax. Throughput
limiting will be applied by Flexi Direct RNC, on reaching this target value. Even if the
PS data throughput covers Iub, the system performs measurement on the Iu-PS
interface. The Flexi Direct RNC periodically calculates the amount of bytes in the
GTP packets received on each Iu-PS interface. Samples are averaged over a longer
period.
3. User plane fill factor
Regarding the user plane capacity of the RNC, the user plane fill factor that sets the
limit. The user plane fill factor covers two aspects: the overall traffic in the RNC, and
the number of ongoing voice calls.
4. RRC connected mode users
The number of users in the RRC-connected states is limited to values that depend
on the RNC capacity step. In practice, other capacity bottlenecks might be limiting
before the maximum number of RRC-connected users is reached.
62 DN0972569 Issue: 03I

5.2.1 Voice capacity

Table 23 Voice capacity
1. Monitored Network voice capacity - IPA-RNC and mcRNC
capacity item
The number of simultaneous voice calls are under the RNC level license. The AMR license usage is
monitored pro actively with the license utilization KPIs. The license violations is reactively monitored with
the M1001C619 and M1001C620 counters.
In addition, you can relatively monitor with the setup success KPIs and BHCA (see Access Network
Stability).
The user sets the 3294 LICENCE CAPACITY WARNING and 3295 LICENCE CAPACITY EXCEEDED
alarms to notify when the AMR capacity is close to the licensed capacity, or if AMR RABs are being
blocked/pre-empted because of exceeding licensed capacity.
For details, see SW License Key Controlled IPA-RNC and mcRNC Capacity.
Network voice capacity - Flexi Direct
CS voice capacity is not licensed in Flexi Direct.
The CS AMR usage can be monitored pro actively with the M802 counters.

monitoring flag
RNC_1773a AMR licensed 40% (together with - The AMR simultaneous call distribution in

capacity RNC_1774a) the licensed capacity. It shows the
simultaneous percentage of AMR call distribution
call between 80 and 90% of the licensed
distribution capacity (occurrences compared to the
ratio 80-90% total amount of distribution load
Licensed AMR occurrences).
capacity
RNC_1774a AMR licensed 20% - The AMR simultaneous call distribution in
capacity the licensed capacity. It shows the
simultaneous percentage of AMR call distribution,
call higher than 90% of licensed capacity
distribution (occurrences compared to the total
ratio >90% amount of distribution load occurrences).
M802C0 AMR_AVERA See Flexi Direct - This is the average number of AMR calls.

Hard AMR GE product description
capacity-Flexi
Direct M802C1 AMR_MAX See Flexi Direct - This is the maximum number of AMR
product description calls.

monitoring
M1001C619 RAB setup The number of RAB setup failures caused by the AMR capacity license,

Licensed AMR failures due to which was exceeded for CS voice.
capacity license for CS
Voice [#]
Issue: 03I DN0972569 63

Table 23 Voice capacity (Cont.)
M1001C620 RAB active The number of RAB releases because of pre-emption caused by the
releases due capacity license which, was exceeded for CS voice calls. Also the
to license pre- M1001C144 RAB active releases because of pre-emption for CS voice
emption for counter is updated along with this counter.
CS voice [#]
4. Analysis Licensed AMR capacity
If there are more than 40% of all occurrences in either of the given KPIs, and/or more than 20% in the
RNC_1774a, the AMR capacity license needs to be updated.
The reactive KPIs monitor how often RNC takes license-related overload actions.
Hard AMR capacity
The maximum and average CS AMR erlangs (M802C0 and M802C1) should be compared against the
defined maximum target in the product descriptions. For example, when the Flexi Direct RNC is serving
only CS services at any point, it should be able to reach the defined maximum Erlangs, with no limitations
imposed by the HW.
5. Overload Licensed AMR capacity
When the number of AMR RABs is greater than the licensed capacity, the RNC does not admit new AMR
RABs until the amount decreases below the licensed limit. Overload is allowed and a hysteresis between
starting and stopping the AMR limiting is used. Pre-emption is used, that is, the AMR RABs with higher
priority might pre-empt the low-priority ones when the licensed capacity has exceeded. The RNC will
admit emergency calls even if the amount of AMR RAB is limited because of the AMR capacity 1 Erl
license.
6. Upgrade IPA-RAN/mcRNC
In case of upgrade need, more AMR capacity can be licensed.
Flexi Direct
Maximum capacity is available without license restrictions.
5.2.2 Data capacity

Table 24 Data capacity
1. Monitored Network data capacity - IPA-RNC and mcRNC
capacity item
There are two different cases to take into account:
• licensed data capacity
• hard data capacity
The RAN monitors:
• throughput utilization levels of interfaces that need a license, that is, Iub
• the load of the Iu-PS interface (for the hard capacity case)
The user is able to monitor the utilization on the Iu-PS licensed capacity pro actively with the RNC_1771a
and RNC_1772a KPIs.
There is a reactive RNC_1770a KPI, which reacts when the throughput exceeds the licensed capacity
(and the rate limitation is active).
64 DN0972569 Issue: 03I

Table 24 Data capacity (Cont.)
The user is able to use the 3294 LICENCE CAPACITY WARNING alarm to notify that Iub PS data
throughput is close to the licensed capacity, and the 3295 LICENCE CAPACITY EXCEEDED alarm to
notify that system drops the PS data packets because of exceeding the licensed capacity.
For details, see SW License Key Controlled RNC Capacity.
Network data capacity - Flexi Direct
Flexi Direct uses the trust-based licensing to control the average PS data throughput supported.
You can monitor the average utilization of the Iu-PS capacity pro actively with the IHSPA_1873a and the
peak utilization by IHSPA_5041b KPIs. There is no licensing applied on Iu-PS throughput utilizations but
the capacity limit is defined by the RNW-parameter RNFC->DLPSGTPDataThroughputMax.

monitoring flag
RNC_1771a Iub-PS licensed 40% (together - Throughput distribution ratio of the Iub-PS

capacity with licensed capacity. It shows the percentage of
throughput RNC_1772a) throughput distribution, between 80 and 90%
distribution ratio of the licensed capacity (occurrences
- 80-90% compared to the total amount of distribution
load occurrences).
Licensed data
capacity
RNC_1772a Iub-PS licensed 20% - Throughput distribution ratio of the Iub-PS
capacity licensed capacity. It shows the percentage of
throughput throughput distribution, higher than 90% of
distribution ratio the licensed capacity (occurrences compared
>90% to the total amount of distribution load
occurrences).
IHSPA_1873a Iu-PS average See Flexi - This is Iu-PS average throughput downlink

throughput Direct product direction.
downlink description
[Kbits/s]
Hard data IHSPA_5041b Iu-PS peak - - This is peak Iu-PS throughput calls in one

capacity throughput Flexi Direct RNC over the reporting period.
[Mbits/s]
RNC_5021b Iu-PS peak 90% - Iu-PS peak load in downlink direction

throughput
downlink [kbps]

monitoring
RNC_1770a Iu-PS The percentage of time when the Iu-PS throughput was over the
throughput over licensed capacity, and as a result, the rate limitation was active.
licensed
capacity [%]
4. Analysis Licensed data capacity
If there are more than 40% of all occurrences in either of the given KPIs and/or more than 20% in the
RNC_1772a, the Iu-PS capacity license, needs to be updated.
Hard data capacity
Issue: 03I DN0972569 65

Table 24 Data capacity (Cont.)
Iu-PS average throughput must be compared to the peak throughput capacity in RNC. If the threshold is
exceeded, there might be an overload in the access network regarding the monitored RNC. The capacity
is dependent on the available interface capacity, that is, used RNC capacity step; for more information,
see the RNC product description (RNC196 Product Description, RNC450 Product Description, RNC2600
Product Description, mcRNC Product Description ).
5. Overload Licensed data capacity
When the throughput is higher than the licensed capacity, the RNC starts to limit the downlink PS
throughput on each Iu-PS interface. The throughput is limited by dropping a small percentage of the GTP
packets. If PS data throughput remains over the licensed capacity, the RNC increases the packet
dropping percentage.
6. Upgrade Licensed data capacity
Upgrade Iub PS throughput license.
Flexi Direct
Maximum capacity is available without license restrictions.
5.2.3 RNC user plane fill factor

The RNC user plane fill factor represents the RNC user plane capacity at a high level.
The RNC user plane fill factor, for simplicity, considers two types of traffic such as CS
voice data, and PS data. The sum of the relative loads of both traffic types has to be less
than or equal to one. The relative load is a result of dividing the measured traffic by the
maximum allowed traffic for each traffic type.
Table 25 RNC user plane fill factor
1. Monitored RNC user plane fill factor
capacity item
The RNC user plane fill factor compares the measured Iu-PS throughput and AMR Erlangs with the
stated RNC capacity. In Flexi Direct, the capacity licensing is not introduced for both CS and PS
capacities. The approach to be followed is a trust-based licensing/pricing. Thus the maximum CS/PS
capacity is limited only by the hardware limitation. Look for the product descriptions and the specific
configurations (peak rate features, BTS capacity licenses, and so on) if any to determine the maximum
capacity in a particular network.
For Flexi Direct RNC, the user plane fill factor can be calculated as follows:
Flexi Direct RNC user plane fill factor = (IuPS throughput/Max IUPS throughput + CS Erl/Max CS
Erl)*100% where
Max IuPS throughput = The maximum IuPS user plane capacity available in the network (to be
determined manually). Max CS Erl = The maximum IuCS user capacity available in the network (to be
determined manually). IuPS throughput = M802C8CS Erl = IHSPA_280a
g The stated RNC capacity is based on the Nokia Solutions and Networks traffic model, which is
specified in the RNC documents (for more information, see RNC196 Product Description,
RNC450 Product Description, RNC2600 Product Description, mcRNC Product Description ). Also,
actual traffic characteristics might differ from the Nokia Solutions and Networks traffic model in
each network, because the Nokia Solutions and Networks traffic model is reflecting an average of
multiple Nokia Solutions and Networks customers’ networks. Therefore, the indicator might not be
precise in all the networks.
66 DN0972569 Issue: 03I

Table 25 RNC user plane fill factor (Cont.)
monitoring flag
Traffic fill factor RNC_5204a RNC user < 70% - The RNC user plane fill factor

plane fill compares the measured Iu-PS
factor [%] throughput and AMR Erlangs with the
stated RNC capacity. The formula
takes into account the measurement of
the soft handover at the Iub.
M802C8 IU_PS_THR See Flexi Direct product - This is the average Iu-PS throughput in

_AVERAGE descriptions downlink direction from the core
network to the Flexi Direct RNC. It
Traffic fill factor includes only user data, not the GTP
- Flexi Direct header.
IHSPA_280a Average CS See Flexi Direct product - This is CS Erlang, meaning the CS

Erlang (Erl) description RAB holding time.

monitoring
M609C3 DSP_SERVICE_FAIL_RES_ALLOC [#] The number of DSP resource allocation

failures.
M609C4 DSP_SERVICE FAIL_RES_MODIFY [#] The number of DSP resource modification

failures.
Packet session RNC_1080b Packet call setup failure rate due to lack Packet call setup failure rate because of lack

setup failures of user plane processing resources [%] of user plane processing resources for
interactive, streaming and background traffic
class.
4. Analyses DSP failures and PS setup failure rate
The user should follow the DSP resource allocation and modification failures together with the pro-active
indicator, since the DSP CPU load might not capture sharp peaks and RNC user plane fill factor might
still hide other capacity bottlenecks, like suboptimal DSP pool configuration.
Flexi Direct RNC user plane fill factor takes into account the user plane capacity of the Flexi Direct RNC.
Note that the Flexi Direct RNC control plane might be limiting. The user plane fill factor might show
values from 40 to 100%, however, the control plane might limit the throughput, depending on the traffic
mix.
5. Overload The RNC overload control should limit the incoming traffic. Therefore, it is recommended to start the
capacity extension planning when the fill factor reaches 70%.
The Flexi Direct RNC overload control should limit the incoming traffic. Therefore, it is recommended to
start the capacity extension planning when the fill factor consistently reaches 100% level.
6. Upgrade The RNC user plane resources are partitioned into pools. Before upgrading, it is recommended to
analyze the pool to see if it is possible to repartition them. See cRNC DSP capacity for calls or mcRNC
DSP capacity for calls.
There is no resource pooling available in Flexi Direct RNC.
Issue: 03I DN0972569 67

5.2.4 RRC connected subscribers

Table 26 Number of RNC connected subscribers
1. Monitored Number of RRC connected subscribers
capacity item
The user is able to monitor the number of subscribers in various RRC-connected states pro
actively with the measurement M802, RNC capacity usage.

monitoring flag
RRC connected RNC_2173a Maximum See RNC - The peak number of RRC

mode users number of RRC product connected mode users in the
connected description RNC (all states) during the
mode users measurement period.
IHSPA_1236a Peak RRC See Flexi Direct - This is the sum of peak RRC

connected product connected mode users divided
mode users per description by the number of active IADAs.
IADA[#]
M802C19 AVE_USERS_C See Flexi Direct - The average number of users in

ELL_DCH [#] product Cell-DCH state in the RNC
description during the measurement period.
RRC connected
mode users -
ELL_FACH [#] product Cell-FACH state in the RNC
Flexi Deirect

ELL_PCH [#] product Cell-PCH state in the RNC
M802C22 AVE_USERS_U See Flexi Direct - The average number of users in

RA_PCH [#] product URA-PCH state in the RNC

monitoring
- - - -
4. Analyses IPA-RNC/mcRNC
If the measured maximum number of RRC connected mode users is greater than 80% of the
available capacity, it might require an upgrade in the RNC. The maximum capacity is provided
in the RNC product description (RNC196 Product Description, RNC450 Product Description,
RNC2600 Product Description, mcRNC Product Description ). For example, it needs to be
inserted to the KPI formula based on the relevant RNC version.
Flexi Direct
In Flexi Direct RNC, the maximum number of users in different RRC-connected mode states is
restricted by the overload control functionality. The current limits are:
• Cell_DCH state: 500 users
• Cell_FACH state: 150 users
68 DN0972569 Issue: 03I

Table 26 Number of RNC connected subscribers (Cont.)
• Cell_PCH/URA_PCH state: 2000 users
5. Overload In case of RRC connected mode users overload, the RNC starts to reject RRC setups and/or
move CELL-PCH users to idle mode.
6. Upgrade IPA-RNC/mcRNC
Split the RNC or select a higher capacity model.
Flexi Direct
If the traffic profile of the network is such that some of the these limits are faced, it is possible to
adjust the limits with PRFILE parameters. If that is needed, please contact Nokia Solutions and
Networks product support.
5.3 RNC connectivity

The carrier (Cell) connectivity and Iur are not licensed in Flexi Direct system. The
system-defined maximum values for both of these are available in product descriptions.
This section only describes the monitoring possibilities. The carrier connectivity license
defines the maximum number of cells that the user can unlock in the RNC.
5.3.1 Carriers and sites

The RNC carrier and site connectivity is not related to traffic. The user is able to define
the connectivity during the integration phase when the user configures the
interconnections between the network elements and customize their parameters. The
counters presented are valid for both IPA-RNC and mcRNC.
Table 27 IPA-RNC and mcRNC connectivity
1. Monitored IPA-RNC and mcRNC connectivity
capacity item
The IPA-RNC and mcRNC keeps track of the number of unlocked cells. If the multi-operator RAN feature
is in use, there can be one PS interface per operator. If the IMSI-based handover is in use, there can be
up to four PLMN IDs per core item.
g Each cell has also a given PLMN ID in order to identify the operator that owns it. Therefore, in a
multi-operator RAN, (MORAN), the PLMN ID identifies the cells that need to be monitored. The
maximum number of different PLMN IDs is four.

monitoring flag
RNC_2171a Number of See the RNC product - The number of WBTSs that have actual

active WBTSs documentation for the measured traffic. The WBTSs that have
Connectivity -
[#] maximum number of no records for service level measurement
sites
sites per RNC. within a given period are not accounted
for in this KPI.
Issue: 03I DN0972569 69

Table 27 IPA-RNC and mcRNC connectivity (Cont.)
RNC_2172a The maximum The number of WCELs that have actual
Number of number of cells per measured traffic. The WCELs that have
active WCELs RNC is defined by the - no records for service level measurement
Connectivity - IHSPA_1235 [#] RNC capacity license. within a given period are not accounted
carriers a for in this KPI.
RNC_183c Cell - - The availability of the WCELs under a

availability controlling RNC (cRNC)
RNC_5216a 32 Sum of M1004 objects (=Iurs). Note that
there must be load on the configured Iur
Connectivity - Number of Iur before it appears in the M1004
RNC interfaces per - measurement.
interfaces RNC
IHSPA_5216 32 IP/Ethernet 20 This is the number of Iur interfaces per
a IP/ATM Flexi Direct BTS.

monitoring
g This item is an alarm. The maximum capacity value of a critical feature has been reached. An
application process, which uses the licensed capacity type feature has
3295 LICENCE CAPACITY observed that its capacity usage level has reached the maximum value as
EXCEEDED defined by the associated license. As a result, the application process
raises this alarm. This alarm is an indication that operator should increase
the available capacity.
4. Analysis -
5. Overload The overload is not directly applicable to the RNC connectivity. Empty networks, without subscribers,
create load that is directly proportional to the size of the network. The number of cells is controlled by a
license. Attempts to increase the number beyond the licensed capacity are rejected in the commissioning
and integration phase.
6. Upgrade Install additional carrier connectivity license capacity in the RNC. The user is able to enhance the system
capacity by adding sites and cells under the RNC (up to the maximum). Install a new RNC or use a
capacity step with better connectivity.
5.4 IPA-RNC
The IPA-RNC feature is distributed among a set of functional units that consist of
hardware and software. Based on the application needs, different tasks can use general
computer units with redundancy. In general, the increase of RNC processing capacity
can be achieved by upgrading computer units with more powerful variants. Figure 15:
RNC2600 architecture shows the internal connections and the external interfaces of
RNC2600 as well as relevant functional units from the communications point of view. The
RNC traffic utilizes ATM (AAL2 virtual channel connections and AAL5 connections) and
Ethernet connections as the figure shows.
70 DN0972569 Issue: 03I

Figure 15 RNC2600 architecture
Figure 16: RNC196/450 architecture shows the RNC196/450 architecture.
Issue: 03I DN0972569 71

Figure 16 RNC196/450 architecture
5.4.1 cRNC DSP capacity for calls

The DSP resources the DMCU in the RNC pool to common channels (CCH) and non-
CCH (HS_DCH). The HS_DCH pool handles both HSPA and R99 DCH traffic. If the
RAN1637; High Speed CELL_FACH DL feature is used, there is an own pool, HS_CCH
for the HS_FACH cell services.
The DMCU Fill Factor covers the number of ongoing calls, assuming the current
resource usage per call.
Table 28 DMCU fill factor
1. Monitored DMCU fill factor
capacity item
The DMCU fill factor measures the utilization of RNC user-plane processing hardware, with no
assumption on traffic model or RNC capacity statement.

monitoring flag
DMCU fill RNC_5416a DMCU fill 95% - User plane resource usage in IPA-RNC

factor factor for (aggregated for all DMCU units). It
calls [%] provides the highest resource usage
value in the granularity period.
72 DN0972569 Issue: 03I

Table 28 DMCU fill factor (Cont.)
monitoring
- - -
4. Analysis You can interpret the KPI value as a call fill factor for the user plane resources: the remaining percentage
is an indicator of how many more calls the RNC can carry, assuming that the current proportions of
different radio bearers remain the same.
When the fill factors exceed the target, start capacity planning. Note that you should follow the other RNC
capacity items as well.
5. Overload The RNC overload control should limit the incoming traffic. Therefore, it is recommended to start the
capacity extension planning when the fill factor reaches 70%.
6. Upgrade The RNC user plane resources are partitioned into pools. Before making an upgrade, it is recommended
to analyze the pools, to see if it is possible to repartition them.
5.4.2 IPA-RNC unit loads

The M592C0 measurement (the average load for a monitored computer unit) measures
the load of Chorus and DMX based unit types of RNC. The load of the OSE-based
computer units (DSP) is measured with M617C1. These measurements are the basis for
the unit load KPIs. The value of the counter is the arithmetical average of samples taken
from the processor load. It is recommended to use the 60-minute period, which has the
maximum processor loads (the busy hour). Combine four consecutive 15-minute periods.
t Monitor the KPI separately for each unit type.
The unit-type-specific KPI includes only the active units. The unit activity depends on the
protection scheme, therefore the unit load KPIs have different variants, depending on the
protection scheme of the unit.
The supported unit types and the protection schemes for each RNC platform are listed in
Table 29: Supported unit types in IPA-RNC.
Table 29 Supported unit types in IPA-RNC
Unit Unit name RNC196/4 RNC2600 Protection

type 50 Scheme
A2SP AAL2 itching Processor X - SN+
DMPG Data and Macro Diversity Group X X SN+
GTPU GPRS Tunneling Protocol Unit X - SN+
ICSU Interface Control and Signalling Unit X X N+1
MXU Multiplexer Unit X X 2N
NIP1 Network Interface Unit PDH X - NP
Issue: 03I DN0972569 73

Table 29 Supported unit types in IPA-RNC (Cont.)
Unit Unit name RNC196/4 RNC2600 Protection

type 50 Scheme
NIS1 Network Interface Unit STM-1 X - NP
NPGE Network Interface Unit Gigabit Ethernet - X NP
NPGEP Network Interface Unit Gigabit Ethernet - X 2N
Protected
NPS1 Network Processor Interface Unit STM-1 - X NP
NPS1P Network Processor Interface Unit STM-1 - X 2N
Protected
OMU Operation and Maintenance Unit X X 2N
RSMU Resource and Switch Management Unit X X 2N
SFU Switching Fabric Unit X X 2N
5.4.2.1 ICSU
The Interface Control and Signaling Unit (ICSU) is a functional unit in the RNC. It
performs signaling transactions towards other network elements and UEs. The protocols
terminated on ICSU are AAL2, RANAP, NBAP, and RNSAP. The ICSU is present in both
RNC196/450 and RNC2600. The system uses a WAC gate (TICKET Service) for
overload control of originating and incoming signaling requests. The ICSU also uses the
buffer limit control (BLC) method to protect the unit from overload. For details on the BLC
and the WAC gate, see RNC Overload Control. The signaling ATM adaptation layer
(SAAL) and Stream Control Transmission Protocol (SCTP) socket interface for NBAP
monitor the RRC message queue length in the ICSU. When the system detects that the
queue length has reached the threshold, it drops part of NBAP requests.
Table 30 RNC ICSU capacity
1. Monitored RNC ICSU capacity
capacity item
You can measure the ICSU load with a KPI, based on the M592C0 counter. The dimensioning target for
ICSU is 70-80% of the CPU performance, depending on the RNC platform. Use 70% for RNC 196/450
and 80% for RNC2600. You can use the reactive KPI, based on the WAC Overload Control (M594) to see
if the system has rejected RRC connection requests because of overload. The reactive M1003C47
counter measures how many paging messages the system has deleted because of the ICSU overload.

monitoring flag
RNC_5228a Average CPU load of 70% for RNC - The RNC ICSU unit load

the most loaded ICSU 196/450, 80% for calculated as the average CPU
Unit [%] RNC2600 load of the most loaded unit.
74 DN0972569 Issue: 03I

Table 30 RNC ICSU capacity (Cont.)
monitoring
RNC_5206a Windows Access Ratio of total number of rejected WAC gate requests to all WAC
Control (WAC) reject gate requests on RNC ICSUs.
ratio [%]
M1003C47 NBR OF DELETED Number of deleted paging messages because of overload in

PAGING MESSAGES the ICSU. The counter is updated when the paging message is
DUE TO ICSU deleted because of overload in the ICSU.
OVERLOAD
4. Analysis 1. ICSU CPU load
The CPU load is caused by subscriber activity, the call setups, that is, BHCA.
2. Number of deleted paging messages due to ICSU overload
The system discards paging messages if there is an overload in the unit responsible for handling the
messages received from the connectionless SCCP relation (ICSU).
3. WAC reject ratio
The WAC reject ratio gives an indication of RRC connection rejects caused by system level
congestion.
g Note that the WAC is a general overload control mechanism, and the reason for the reject
might be on some other unit than ICSU, or even beyond the RNC.
5. Overload Because of the RNC overload control, the CPUs can safely go up to 70% (80%). After that, the overload
control should cause QoS degradation. The ICSU overload is caused by the subscriber or UE activity, the
call setups, that is, BHCA. There are two thresholds for the overload control. In the first phase, only
conversational calls and emergency calls are accepted. If the number of unhandled messages and the
CPU load exceed the pre-defined higher values, only emergency calls are accepted.
6. Upgrade Upgrade RNC if the ICSU CPU loads are close to the targets or reduce the RNC C-plane load by
optimizing the network. You can use the following means to reduce the signaling in the network:
• Reduce SHO area by changing add/drop window and reducing active set size
• Reduce ping-pong (active set addition/deletion) by increasing penalty timers
• Reduce RRC re-attempts
• Selectively remove 2G to 3G neighbor relationships
• Enable Common Channel RRC connection set-up
5.4.2.2 RSMU
The Resource and Switch Management UNIT (RSMU) is required in all RNC
configurations. The RSMU performs UE connection control, according to the request
received from the ICSU. Therefore, the ICSU is the source of most of the load on the
RSMU. The RSMU also performs centralized resource management tasks, such as
switch fabric control, ATM circuit hunting, and DSP resource management tasks. The
RSMU CPU load is directly correlated with the number of leg setups. The legs are
connections inside the RNC (between the internal functions of the RNC). The Leg
Management Program Block (LGMANA) on the RSMU provides the services for
establishing the legs. LGMANA monitors the size of requests it has to serve and the
CPU load. After receiving the CPU load notification and if the number of the requests it
can serve has exceeded certain threshold, LGMANA frees certain low-priority requests
Issue: 03I DN0972569 75

to create buffer space so that higher priority requests can still fit into the buffer. The
second important function in the RSMU is the Layer 2 resource manager (RM3). The
system can establish legs with or without the DSP resources. The system needs the
RM3 functions for managing DSP resources when establishing the leg in the S-RNC.
Table 31 RNC RSMU capacity
1. Monitored RNC RSMU capacity
capacity item
The nominal dimensioning target for RSMU is 70% of the CPU performance. You can monitor the RSMU
CPU load with a 2N redundant unit CPU load formula, which bases on the M592C0 counter. The RSMU
protects itself against overload caused by ICSU, and the ICSU reports the incident in the M1006C205
counter.

monitoring flag
RNC_1871a Average CPU load of 70% - The RNC RSMU unit load, calculated

the active RSMU unit as the average CPU load of the most
[%] loaded unit.

monitoring
M1006C205 RRC CONN REJECT The number of RRC connection rejections because of
DUE TO centralized signaling unit RSMU overload.
CENTRALIZED UNIT
OVERLOAD [#]
4. Analysis 1. RSMU CPU load
The RSMU CPU load level is directly related to leg establishments. The BHCA load and functions
related to RRC state changes are causing leg setups and DSP resource allocations. The target CPU
load (70%) is achieved with no impacts on the traffic.
2. RRC CONN REJECT DUE TO CENTRALIZED UNIT OVERLOAD
This counter on the ICSU is updated when the RNC sends the RRC CONNECTION REJECT
message to the UE, because the RSMU unit is overloaded. In addition, the system updates the
M1006C21 counter (total number of RRC Connection Request Reject messages) along with this
counter. The counter maps to WCEL or the RNC, not directly to the RSMU unit.
5. Overload The overload control mechanism on the RSMU rejects new creations and modifications and allows
deletions of the controlled resources. Because of overload, call setups start to fail, soft handover leg
additions start to fail, until eventually ongoing calls drop when the main branch drops. Additionally,
(concerns PS calls) the impact on the RSMU overload is visible as the UE bitrate upgrade failures.
6. Upgrade You should start the capacity extension planning before the RSMU load reaches 70%.
5.4.2.3 OMU
The Operation and Management Unit (OMU) performs the basic system maintenance
functions such as hardware configuration, alarm system, and centralized recovery
functions. It also contains RAN-related functions, such as radio network management,
radio network recovery, databases, and state management.
Table 32 RNC OMU capacity
1. Monitored RNC OMU capacity
capacity item
76 DN0972569 Issue: 03I

Table 32 RNC OMU capacity (Cont.)
You can monitor the OMU CPU load with the KPI, which is based on M592C0 counter. You can monitor
the volume of TCP/IP traffic in OMU, that is, O&M traffic, with the M563 measurement (TCP/IP Protocol).

monitoring flag
RNC_5207a Average CPU 70% - RNC OMU unit load, calculated as the average CPU

load of the active load of the most loaded unit.
OMU unit [%]

monitoring
- - -
4. Analysis The CPU load of OMU is caused by the O&M network traffic. The CPU is directly correlated with the IP
packets routing rate. Note that the PM data at the end of measurement interval causes peaks in the CPU
usage. These are many alarms related to the OMU overload. For details, see RNC Overload Control.
5. Overload The upper level alarm system monitors the OMU's CPU load and its own message queue length. If the
load reaches the threshold, or the spare OMU unit is in the start-up phase, the system prevents the
execution of the most of the loading MML commands (listing commands). In addition, OMU stops
handling new alarm occurrences until the overload situation is over.
6. Upgrade -
5.4.2.4 OMS
OMS acts as a mediator device between external systems like OSS and managed
network elements. RAN RNW profile under one RNC (and OMS) has impact on nature of
the M-plane O&M traffic going through OMS (for instance, the frequency of PM
measurement period and included measurements). Also the BTS configuration of the cell
number has an impact. See the OMS product documentation for details of monitoring the
OMS capacity.
5.4.2.5 DMCU
The Data and Macro Diversity Combining Unit (DMCU) provides RNC user and control
plane functions including macro diversity combining, outer loop power control, RLC-U
functions, and packet scheduling. Furthermore, the distributed part of the DSP resource
management function has been located in Data and Macro Diversity Processor Group
(DMPG). Data Signaling Processor (DSP) performs signal-processing tasks. The DMCU
has a hierarchical HW structure, consisting of Data and Macro Diversity Processor
Groups (DMPG) and DSPs:
Issue: 03I DN0972569 77

Figure 17 DMCU HW Architecture
DMPGs are independent of each other, and can communicate through an external ATM
switch. DSPs communicate with Power PC (PPC) and CPM (Communications Processor
Module) only. There are variants of the DMCU hardware, where the number of DMPGs,
DSPs, and internal buses with their capacities might vary. In addition, the software
architecture might differ in the DMCU variants. See the RNC product documentation for
the DMCU options. Software is loaded to four DMPGs, on the PPCs and DSPs. The
DMPG functional unit type continues traffic handling in the DMCU even if a single
PowerPC-based computer core block is faulty.
5.4.2.5.1 DMPG
PPC (PowerPC) is a general-purpose processor inside the DMPG. It runs ChorusOS
operating system, IPA2800 platform, and RNC application processes. The PPC capacity
is related to the RNC control plane load. See the DMCU fill factor for DMPG user-plane-
related capacity. The CPM does not have application software, but it handles the low-
level communication functions towards other units in the RNC.
Table 33 RNC DMPG capacity
1. Monitored RNC DMPG (PPC) capacity
capacity item
You can monitor the PPC CPU load with a KPI, which is based on the M592 measurement. There is
preventive overload control on the DMPG, whose task is to reduce blocking probability for more critical
services in overload situations.

monitoring flag
RNC_1981a Average CPU load of 80% - RNC DMPG unit load, calculated as

the most loaded the average CPU load of the most
DMPG (PPC) unit [%] loaded unit.

monitoring
- - -
4. Analysis The KPI represents the maximum of average PPC processor loads on all DMPG units.
78 DN0972569 Issue: 03I

Table 33 RNC DMPG capacity (Cont.)
5. Overload -
6. Upgrade The KPI does not identify the DSP pool, which is most loaded. Therefore, before upgrading, it is
recommended to analyze the individual unit loads to see if the DSP pools can be repartitioned. See also
DSP.
5.4.2.5.2 DSP
The DSP resources the DMCU in the RNC pool to common channels (CCH) and non-
CCH (HC_DCH). The HS-DCH pool handles both HSPA and R99 DCH traffic. If the
RAN1637: High Speed CELL_FACH DL feature is used, there is an own pool, HS_CCH
for HS_FACH cell services.
The DSP processor has a dedicated software depending on the pool it belongs to. With
the introduction of HS CELL_FACH, there are different software images for each of the
CCH, HS_CCH and HS_DCH pools. These roles are permanent at run time, except for
HS_CCH, which can grow up to a configurable limit. Overall, R99 DCH and HSPA DSP
capacity depends on the total number of DSP processors in a given RNC capacity step,
and the number of processors configured for the pool types.
Table 34 RNC DSP load
1. Monitored RNC DSP load
capacity item
The RNC DSP load measures the utilization of RNC user plane processing hardware, with no
assumption on the traffic model or RNC capacity statement.

monitoring flag
RNC_5209a Average CPU load of 80% - The RNC DSP load, calculated as the

the most loaded DSP average CPU load of the most loaded
Unit [%] unit

monitoring
- - -
4. Analysis The DSP CPU load is one of the indications that the system uses for load balancing between the DSPs.
If the loads are high, the DSPs are overloaded. However, if the loads are low, the system might still
experience overload because of other factors such as uneven distribution of the services to DSP pools.
Therefore, you should also check the DSP rejections.
5. Overload If the CPU load is above 80%, the DSP should narrow the current bandwidth. This leads to the slowing
down of the packet sending from the TCP/IP application. If the CPU load is above 90%, the DSP starts to
drop packets. Packet drops are applicable to the whole Mac-d flow, irrespective of the traffic class and
priority.
6. Upgrade The RNC user plane resources are partitioned into pools. Before making an upgrade, it is recommended
to analyze the pools, to see if it is possible to repartition them.
Issue: 03I DN0972569 79

5.4.2.6 GTPU
The GPRS Tunneling Protocol Unit (GTPU) performs user plane functions that are
related to handling of GTP in the Iu-PS interface. The GTPU is optional in the RNC (in
that case NPGE (P) or NPS1(P) does the GTPU-tunneling). From the GTPU capacity
point of view there is no major difference between NRT and RT PS data. However, the
GTPU CPU load depends on the packet frequency. The system cannot achieve high
GTPU throughput with small packet size, because the packet frequency must be high to
reach a given throughput.
Table 35 RNC GTPU capacity
1. Monitored RNC GTPU capacity
capacity item
You can measure the GTPU load pro actively with a KPI, which is based on the M592C0 counter. The
dimensioning target for GTPU is 80% of the CPU performance.

monitoring flag
RNC unit RNC_1872a Average CPU 80% - RNC GTPU unit load,

loads load of the calculated as the average
most loaded CPU load of the most loaded
GTPU unit unit.
[%]

monitoring
- - -
4. Analysis GTPU CPU load
GTPU CPU load is directly correlated with the packet rate per second.
5. Overload The GTPU monitors the system’s message queue and discards packets for the CPU overload. The system
does not drop packet sessions.
6. Upgrade Activate the Dedicated GTPU for Real-time IP Support. If you cannot optimize capacity by reconfiguring
the Iu-PS, upgrade to NPxx units.
5.4.2.7 SFU
The task of the Switching Fabric Unit (SFU) is to switch ATM cells from input ports of the
switching fabric to correct output ports without blocking. The switching capacity of the
unit varies depending on the type of used switching fabric plug-in units. SFU is a non-
blocking unit at the ATM connection level. If input and output capacity is available, the
system can establish a connection through the fabric.
5.4.2.8 A2SU
The task of the AAL2 Switching Unit (A2SU) is to perform switching and multiplexing of
AAL2 CPS packets between external interfaces and signal processing units (DMCU).
The A2SU contains four A2SPs. The Power Quicc processor core part of the A2SP
handles the control plane-related issues, like the AAL2 leg setups related to the 1-CID
80 DN0972569 Issue: 03I

and N-CID channels and a part of the user-plane related issues, like the internal flow
control. The Communications Processor Module (CPM) part handles the user plane
traffic load (related to the 1-CID and N-CID channels). The A2SP bottleneck can be the
CPU load of Power Quicc Core part, the CPU load of the Power Quicc CPM part, or the
AAL2UP connectivity (bandwidth, 1CID count, NCID count).
Table 36 RNC A2SP capacity
1. Monitored RNC A2SP capacity
capacity item
You can measure the A2SP CPU load (Power Quicc processor core part) pro actively with a KPI, which
is based on the M592C0 counter. The dimensioning target for A2SP is 80% of the CPU performance.
The resource allocations rejected because of A2SP capacity can be monitored reactively with the
M800C2 counter. There is an overload control mechanism in the A2SP.

monitoring flag
RNC_5212a Average CPU 80% - RNC A2SP unit load, calculated as the average CPU

load of the most load of the most loaded unit.
loaded A2SP
unit [%]

monitoring
M800C2 RES_INT_CAP The number of transport resource reservations rejected because of
[#] lack of RNC internal capacity. This is the number of resource
reservations which are rejected by CAC since there are no RNC
internal AAL2 processing resources available.
4. Analysis 1. A2SP CPU load
The A2SP CPU load comes from BHCA and from RNC internal transport leg setups, which are
controlled by RSMU.
2. Rejected resource request is because of RNC-internal AAL2 resources
This counter indicates that the A2SP unit terminating the AAL2 VCC has too high load.
If there is not enough capacity in the A2SP unit terminating the AAL2 VCC, the lack of capacity will block
the set-up of new connections.
5. Overload Each A2SP monitors the CPU load and sends a high load notification directly to RSMU. A2SP does not
reject new tasks but the RSMU balances the load between A2SPs according to high load notifications.
The RSMU does not select an overloaded A2SP for a new connection. A2SPs also monitor their own
CPM (Communications Processor Module) load and reject new connection creation tasks during the
CPM overload.
6. Upgrade Correct the situation by moving some highly loaded connections to another A2SP unit.
5.4.2.9 MXU
The MXU multiplexes traffic from tributary units towards the switching fabric and finally to
DSPs in the DMPGs. The ATM Multiplexer also includes part of ATM layer processing
feature, such as policing, statistics, OAM, buffer management, and scheduling. Starting
from RN3.0, VP piping is used and there are no AAL2 legs established in the MXU.
Issue: 03I DN0972569 81

Table 37 RNC MXU capacity
1. Monitored RNC MXU capacity
capacity item
You can measure the MXU load proactively with the KPI. The dimensioning target for MXU is 80% of the
CPU performance. There is an overload control mechanism in the MXU.

monitoring flag
RNC_5213a Average CPU 80% - RNC MXU unit load, calculated as the average

load of the CPU load of the most loaded unit.
active MXU unit
[%]

monitoring
- - -
4. Analysis The MXU load comes from BHCA. The unit is dimensioned so that the CPU load, coming from leg
setups, should stay low compared to the centralized units of the RNC.
5. Overload The MXU CPU load should stay low. If overload occurs, the load is distributed across the MXU cluster.
6. Upgrade -
5.4.2.10 SWU
SWU does the Ethernet switching inside the RNC. It also does the Ethernet switching
between the RNC and an external IP network, for example for O&M purposes. No
capacity bottlenecks have been noticed on this unit.
5.4.2.11 NIS1
Network Interface Unit STM-1 provides STM-1 external interfaces and means to execute
the physical layer and ATM layer feature.
Table 38 RNC NIS1 capacity
1. Monitored RNC NIS1 capacity
capacity item
You can measure the NIS1 CPU load proactively with the KPI. The dimensioning target for NIS1 is 80%
of the CPU performance. There is an overload control mechanism in NIS1.

monitoring flag
RNC_5214a Average CPU 80% - RNC NIS1 unit load, calculated as the average CPU

load of the most load of the most loaded unit.
loaded NIS1
unit [%]

monitoring
- - -
82 DN0972569 Issue: 03I

Table 38 RNC NIS1 capacity (Cont.)
4. Analysis The NIS1 load comes from BHCA. The unit is dimensioned so that CPU load, coming from leg setups,
should stay low compared to the centralized units of the RNC. NIS1-based AAL2 paths are always
handled by A2SU.
5. Overload The CAC program on NIS1 receives the connection creation, modification, and deletion tasks from the
ICSU. The same program block also monitors own unit’s CPU load and informs the RSMU about high
load.
6. Upgrade -
5.4.2.12 NIP1
Network Interface Unit E1 / T1 / JT1 (NIP1) provides the 2Mbit/s and 1.5 Mbit/s PDH
external interfaces and the means to execute the physical layer and the ATM layer
feature.
Table 39 RNC NIP1 capacity
1. Monitored RNC NIP1 capacity
capacity item
You can measure the NIP1 CPU load proactively with the KPI. The dimensioning target for NIP1 is 80%
of the CPU performance. There is an overload control mechanism in NIP1.

monitoring flag
RNC_5215a Average CPU 80% - RNC NIP1 unit load, calculated as the average

load of the most CPU load of the most loaded unit.
loaded NIP1
unit [%]

monitoring
- - -
4. Analysis The NIP1 load comes from BHCA. The unit is dimensioned so that CPU load, coming from leg setups,
should stay low compared to the centralized units of the RNC. NIP1-based AAL2 paths are always
handled by A2SU.
5. Overload The CAC program on NIP1 receives the connection creation, modification, and deletion tasks from
ICSU. The same program block also monitors own unit’s CPU load and informs the RSMU about high
load.
6. Upgrade -
5.4.2.13 NPS1
NPS1 (NPS1P) combines the features of NIS1(NIS1P), A2SU, and GTPU. The unit has
eight STM1 interfaces, which you can use as Iub, Iur and IU interfaces, with ATM or IP
over ATM transport solutions. The main task of the unit is to manage traffic in the RAN
logical interfaces and set up the AAL2 legs and GTP tunnels. The NPS1 traffic is
managed by the APP650 network processes. The main traffic management functions
Issue: 03I DN0972569 83

are: classification of the traffic, AAL2 switching, flow control, policing, queue mapping,
congestion control, scheduling, and Connection Admission Control (CAC). Within a PS
RAB establishment, the system reserves a certain amount of memory for the required
GTP tunnel. Each time the UE’s state changes to CELL_DCH, the system reserves
related memory buffer for the incoming PS data packets. Typically, the system uses
AAL2 channels internally for user plane traffic between NPS1 (P) and DMCU units; GTP
is the protocol towards the Iu-PS. The system routes control plane traffic, on any logical
interface to the ICSU.
Table 40 RNC NPS1 capacity
1. Monitored RNC NPS1 (P) capacity
capacity item
You can measure the NPS1 processor load proactively with the M592 measurement. The dimensioning
target for NPS1 is 80% of the CPU performance. The NSP1 interface utilization (measured
throughput/configured interface bandwidth) can be measured proactively using the M532 measurement
(ATM Interface measurement), separately in ingress and egress direction (traffic towards the SFU, or
from the SFU).You can follow the traffic management impacts, like packed drops caused by policing and
QoS management reactively with the M528 measurement (ATM layer performance).

monitoring flag
RNC_1982a Average CPU 80% - RNC NPS1 unit load, calculated as the average

load of the most CPU load of the most loaded unit.
loaded NPS1
unit [%]
RNC_1127a Average ATM - - Interface utilization is the total number of transmitted

unit interface ingress ATM cells, divided by the configured ingress
utilization bandwidth (ingress direction).
ingress [%]
RNC_1128a Average ATM - - Interface utilization is the total number of transmitted

unit interface ingress ATM cells, divided by the configured ingress
utilization bandwidth (egress direction).
egress [%]

monitoring
RNC_5219a ATM discarded ATM cells dropped because of interface unit internal congestion
cells ingress (ingress direction).
due to
congestion [#]
RNC_5220a ATM discarded ATM cells dropped because of interface unit internal congestion

cells egress due (egress direction).
to congestion
[#]
4. Analysis 1. RNC NPS1 CPU load
The NPS1 load comes from BHCA causing GTP tunnel and AAL2 leg setups.
2. Internal packet processing capacity
You can follow the APP650 network processor capacity proactively by monitoring the ingress and
egress data volumes and correlating them with corresponding ingress and egress packet drop ratios.
84 DN0972569 Issue: 03I

Table 40 RNC NPS1 capacity (Cont.)
This capacity item does not take into account the RAN logical interfaces, like Iub, Iur and IU, which you
need to follow separately.
5. Overload NPS1 might be a bottleneck in live networks if the traffic model in the network differs very much from the
model used in the RNC dimensioning.
6. Upgrade If part of the interface units is loaded, reconfigure the logical interfaces to units that are not loaded. Note
that the interface capacity is higher than the element-level capacity. The element capacity should not be
exceeded when configuring more capacity at the interfaces. If all interface units are loaded and there is
no more capacity available, add a new RNC, or upgrade the RNC to a higher capacity model.
5.4.2.14 NPGE
The NPGE has similar functions as the NPS1, over IP interfaces. The resources on the
NPGE unit are needed for terminating the IP/UDP protocol, statistics, and optionally for
IPSEC.
Table 41 RNC NPGE capacity
1. Monitored RNC NPGE capacity
capacity item
You can measure the NPGE load proactively with the M592C0 counter. The dimensioning target for
NPGE is 80% of the CPU capacity. The CPU load is directly correlated to the internal creation, deletion
and modification caused by UE requests, for example, CS/PS call setup, SHO, channel type switching
and NAS signaling, and so on. The NBAP/RANAP/RANSAP Signaling amount does not affect much to
the CPU load since the signaling links are created statically during the configuration. Also, the CPU load
is not correlated to the user plane throughput because the user plane packet processing is performed by
the APP650 network processor. There are two 1 Gbps Ethernet ports on the NPGE. The port bandwidth
is limited by the operator-configurable RncEthernetBw parameter. The system uses the parameter to
shape the outgoing traffic. You can measure the interface utilization of each Ethernet port against the
configured bandwidth in RX and TX directions. The maximum throughput of NPGE(P) is 1.65 Gbps for
symmetrical traffic at the ATM/AAL5 level. This is limited by the switching fabric (SFU) port rate. You can
measure proactively the internal packet processing of the NPGE, performed by the APP650 network
processor, with the received and transmitted packet drop ratios (to see if the unit has reached its capacity
limit).

monitoring flag
RNC_1983a Average CPU 80% - The maximum load of the NP2GE CPU unit,

load of the most calculated as the average CPU load of the most
loaded NPGE loaded unit.
unit [%]
RNC_5210a NPGE Ethernet 80% - This is the sum of received Ethernet data compared

Port to the maximum value, limited by the
RX_Utilization RncEthernetBw parameter. The formula should be
[%] used separately for each Ethernet port on the NPGE.
RNC_5222a NPGE Ethernet 80% - This is the sum of received Ethernet data compared

Port to the maximum value, limited by the
TX_Utilization RncEthernetBw parameter. The formula should be
[%] used separately for each Ethernet port on NPGE.
Issue: 03I DN0972569 85

Table 41 RNC NPGE capacity (Cont.)
RNC_5223a NPGE - - The formula calculates the sum of received data
RX_Utilization volumes measured from all Ethernet ports of NPGE,
[%] converts the measurements to Kbps, and compares
against the maximum SFU port rate (1650000 kbps).
The measured interface data is converted to the
ATM/AAL5 level.
RNC_5224a NPGE - - The same as above but with TX data.

TX_Utilization
[%]

monitoring
RNC_1644a Ethernet frames Ingress Ethernet frames drop ratio, summed up to unit level.
drop ratio,
ingress [%]
RNC_1645a Ethernet frames Egress Ethernet frames drop ratio, summed up to unit level.

drop ratio,
egress [%]
4. Analysis 1. RNC NPGE CPU load
The NPGE CPU load comes from BHCA or other user activity causing the RAN control plane load.
2. Ethernet port utilization
The Ethernet port utilization comes from user plane data allocated to the Ethernet port.
3. NPGE throughput
The NPGE unit total throughput, which is the sum of the Ethernet ports on the unit, might be limited
by the RNC internal SFU port rate.
4. Internal packet processing capacity
You can follow the APP650 network processor capacity reactively by monitoring the ingress and
egress packet drop ratios.
This capacity item does not take into account the RAN logical interfaces, like Iub, Iur and IU, which you
need to follow separately.
5. Overload The overload, when units are used for Iub interfaces, is caused by BHCA. The unit should tolerate short
bursts of overload, but when there is constant overload, call setups become longer, and call
establishment fails because of call setup timers. Throughput overload can cause packet drops in those
RAN interfaces that are configured on the interface. This might happen when the unit is configured with
the Iu-PS.
6. Upgrade If some of the interface units are loaded, reconfigure the logical interfaces to units that are not loaded. If
all interface units are loaded, split the RNC or select a higher capacity model.
5.5 mcRNC
mcRNC is a realization of the UTRAN 3G Radio Network Controller on a hardware
comprised of many multi-core SoC processors along with necessary memory, storage,
switching, and networking equipment in a rack amount configuration. The feature of the
RNC is achieved by the software executing typically on 2 more such modules.
86 DN0972569 Issue: 03I

The variety of functional units in mcRNC is considerable smaller, compared to cRNC.
Figure 18: mcRNC architecture shows the mcRNC architecture.
Figure 18 mcRNC architecture
mcRNC
CFPU EIPU CFPU EIPU
Ethernet
USPU CSPU USPU CSPU
Module 1 Module 2
The mcRNC consists of 4 functional planes - Control Plane, User Plane, Transport Plane
and Management Plane.
In mcRNC architecture, the services of the Control Plane and User Plane are functionally
divided based on whether they are provided for a specific UE, common entities like BTS
and cells or centralized in the Network Element for architectural reasons. The resulting
functional units are:
CSCP - Cell Specific functions and services in Control Plane
USCP - UE Specific functions and services in Control Plane
CFCP - Centralized Functions and services in Control Plane
CSUP - Cell Specific functions and services in User Plane
USUP - UE Specific functions and services in User Plane. This includes the dedicated
and shared channel services since they are relevant for a UE.
OMU - Operations and Maintenance Unit functions
The Transport Plane is divided based on whether it provides services for the internal
network (also referred to as backplane) or external network (external interfaces).
SITP - Signalling Transport Plane
EITP - External Interface functions in Transport Plane
Finally, Management Plane will need external interface functions, they are handled with
USSR (User Specific SE for RNC O&M).
Figure 19: mcRNC unit architecture shows the hardware point of view, wherein all the
units are similar, comprising of 8 multicore processors.
Issue: 03I DN0972569 87

Figure 19 mcRNC unit architecture
Internal
HW Management
FD
LMP Interfaces
switch
Man.
PCIe
VCMC
1 GigE SAS
Direct interface cross connect
HD
(Element management) Interfaces
Oct 1
Oct 2 10 GigE
Inter_Processor
Communication
10/1 GigE Oct 3
Network
Interfaces
10GE Switch ext.
10GE Switch int.

Oct 4
Oct 5
1 GigE Oct 6
Network
Interfaces
Oct 7
Oct 8
1 GigE
Direct interface
(Element management)
The number of cores of the Octeon multiprocessors vary, depending on the
multiprocessor type. The software is based on Linux or Simple Executive (SE) as shown
in Figure 20: mcRNC HW and SW components.
88 DN0972569 Issue: 03I

Figure 20 mcRNC HW and SW components
RNC
RNC
Control Plane and O&M
User Plane Applications
Applications
IPA Light
(Middleware and Adaptation Layer)
User Plane Middleware
(Middleware and
Adaptation Layer)
Flexi Platform
(Base Platform + Optional Components)
SMP Linux Simple Executive
Multi-core and Multiprocessor Hardware
mcRNC
The Linux-based software can use multiple cores, while the simple executive runs on
single core. User Plane Middleware provides the relevant interfaces and services for the
complete functioning of the User Plane applications in mcRNC.
UMW cores are dedicated core(s) in USPU and in CSPU for UMW processing only. One
USPU and CSPU consist of multiple cores and part of them are used for user plane
processing on top of Simple Executive (SE). From those SE cores for user plane
processing, certain amount of core(s) is/are dedicated for the UMW processing and the
rest of those SE cores are used for RNC User Plane Application processing (like FP,
MAC, RLC and PDCP protocols).
The mcRNC unit loads can be followed by KPIs, based on the M2002 measurement. The
M610 measurement for DSP resource is the average, maximum and minimum usage
percentages.
5.5.1 mcRNC DSP capacity for calls

The DSP capacity of the mcRNC means that the USUP software is running on Simple
Executive on the Octeon multiprocessor core. The USUP implements all UE-specific
protocols: Iu-UP, RTP, RTCP, PDCP, RLC, Mac-d and FP-d. USUP implements the
HSPA services in the mcRNC and hosts the enhanced CELL FACH/RACH services.
The logical DSP resources, needed by the UE can be monitored with the KPI
RNC_5233a, USPU fill factor for calls (user plane). The logical resource model is based
on the traffic mix used by Nokia Solutions and Networks during the development, which
might differ from the actual traffic in the operator network. Therefore, the actual DCP
CPU loads should be measured as well.
Issue: 03I DN0972569 89

Table 42 mcRNC DSP capacity
1. Monitored mcRNC DSP capacity
capacity item
The DSP resources on USPU can be measured with the KPI RNC_5233a, which is based on logical
resource usage (M610).

monitoring flag
RNC_5233a Peak USPU fill factor 95% - User plane fill factor (resource usage)

for calls in RNC. It provides the highest
resource usage value in percentage.

monitoring
- - -
4. Analysis -
5. Overload -
6. Upgrade Upgrade to a higher mcRNC capacity step.
5.5.2 mcRNC units

5.5.2.1 CFPU
The Centralized Functions Processing Unit (CFPU) consists of Operation and
Management Unit (OMU) and Centralized Functions for Control Plane (CFCP). The
OMU performs the basic system maintenance functions such as hardware configuration,
alarm system, configuration of signaling transport and centralized recovery functions. It
also contains cellular network-related functions such as radio network configuration
management, radio network recovery and RNW database.
The CFCP consists of functions that need to or can be run centralized in the RNX, for
example, LCS, SABP handling (Iu-BC interface), centralized information maintenance
(RC3), etc. The CFCP is the node meant to host program blocks where the centralization
does not became a bottleneck.
The USSR in the CFPU terminates the external Ethernet interface needed for
management plane operations. Management connections (ssh) and connection to OMS
goes through this interface.
Table 43 CFPU load
1. Monitored CFPU load
capacity item
You can monitor the processor loads of CFPU with the following KPIs, which represent the loads of the
most loaded nodes.
g CFCP and OMU loads are found in a common KPI.

monitoring flag
90 DN0972569 Issue: 03I

Table 43 CFPU load (Cont.)
RNC_5435a CPU load of < 80% - Average CPU load of the most loaded
Centralized Functions CFPU node in CFPU processing unit.
in CFPU [%] CFPU node process centralized
functions for both Control Plane
((CFCP) and O&M (OMU).
RNC_5436a CPU load of transport < 80% - Average CPU load of the most loaded

functions in CFPU [%] USSR node in CFPU processing unit.
USSR node processes External
Ethernet interface needed for
management plane operations.

monitoring
- - -
4. Analysis -
5. Overload -
5.5.2.2 CSPU
The Cell-Specific Processing Unit (CSPU) implements all cell-specific control and user
plane processing. Further, all control- and user plane resources for a single BTS are
allocated from the same CSPU unit. Therefore, CSPU units can function independently
from one another. The communication between CSCPs in different CSPUs shall be
limited to the exchange of information on its own state rather than to delegate the
processing of the Radio Layer feature.
Table 44 CSPU load
1. Monitored CSPU load
capacity item
You can monitor the processor loads of CSPU with the following KPIs, which represent the loads of the
most loaded nodes.

monitoring flag
RNC_5437a CPU load of CSCP in < 80% - Average CPU load of the most loaded

CSPU [%] CSPU node in CSPU processing unit.
CSPU node processes Cell Specific
functions for Control Plane (CSCP).
RNC_5487a CPU load of CSUP < 80% - Average CPU load of the application

Rel2 HW in CSPU - cores for CSUP nodes in CSPU
Application cores [%] processing unit. CSUP node
processes Cell Specific functions in
User Plane (CSUP).
Issue: 03I DN0972569 91

Table 44 CSPU load (Cont.)
RNC_5488a CPU load of CSUP < 90% - Average CPU load of the UMW (timer,
Rel2 HW in CSPU - ingress, and egress) cores in the most
UMW cores [%] loaded CSUP node in CSPU
processing unit. CSUP node
User Plane (CSUP).
RNC_5493a CPU load of CSUP < 80% - Average CPU load of the application

Rel1 HW - Application cores for CSUP nodes in CSPU
cores [%] processing unit. CSUP node
User Plane (CSUP).
RNC_5494a CPU load of CSUP < 90% - Average CPU load of the UMW (timer,

Rel1 HW in CSPU ingress, and egress) cores in the most
-UMW cores [%] loaded CSUP node in CSPU
processing unit. CSUP node
User Plane (CSUP).

monitoring
- - -
4. Analysis -
5. Overload -
5.5.2.3 EIPU
The External Interface Processing Unit (EIPU) hosts the networking and transport stacks
needed for processing both signaling and user plane date. It also handles the load
balancing and distribution to the other units. It consists of two functional units - the
Signalling Transport Plane (SITP) and External Interface Transport Plane (EITP).
Table 45 EIPU load
1. Monitored EIPU load
capacity item
You can monitor the processor loads of EIPU with the following KPIs, which represents the average load
of the most loaded nodes.

monitoring flag
RNC_5439a CPU load of SITP in < 45% - Average CPU load of the most loaded

EIPU [%] EIPU node in EIPU processing unit.
EIPU node processes Signaling
Transport Plane functions (SITP).
92 DN0972569 Issue: 03I

Table 45 EIPU load (Cont.)
RNC_5440a CPU load of most < 45% - Average CPU load of the most loaded
loaded EITP in EIPU EITP node in EIPU processing unit.
[%] EITP node processes External
Interface Transport Plane functions
(EITP).
RNC_5449a CPU load of EITP in - - Average CPU load of the ETIP nodes

EIPU [%] in EIPU processing unit. EITP node
processes External Interface
Transport Plane functions (EITP).

monitoring
- - -
4. Analysis RNC_5440a: Used in all cases
RNC_5499a: Used in combination with RNC_5440 to check the level of unbalance between EIPUs
5. Overload -
g The target level for RNC_5231a is only 45% because two EIPUs in successive BCNs
are backing up each other so that for active recovery units in EIPU 1, there are standby
recovery units in EIPU 2. If one of these EIPUs fail, the other EIPU activates all the
recovery units and handles the two EIPUs’ loads, reaching in such case a maximum of
90% load.
5.5.2.4 USPU
The UE-Specific Processing Unit (USPU) implements all UE-specific control and user
plane processing. Further, all dedicated control- and user plane resources for a single
UE are allocated from the same USPU unit, as long as the resource management
policies permit. Overload handling and shared channel processing optimization require
some communication between the USPUs but this is minimal and is mostly limited to
control message exchange only. Otherwise, the USPU units are mostly independent of
one another.
USPU processing unit houses USCP and USUP functional units. USCP unit is loaded by
control plane traffic whereas USUP unit is loaded by user plane traffic and also by control
plane traffic due to user plane traffic resource reservations and configurations.
Table 46 USPU load
1. Monitored USPU load
capacity item
You can monitor the processor loads of USPU with the following KPIs, which represents the average load
of the most loaded nodes.

monitoring flag
Issue: 03I DN0972569 93

Table 46 USPU load (Cont.)
RNC_5441a CPU load of USCP in < 80% - Average CPU load of the most loaded
USPU [%] USPU node in USPU processing unit.
USPU node processes UE-Specific
functions for Control Plane (USCP).
RNC_5489b CPU load of USUP < 80% - Average CPU load of the application

Rel2 HW in USPU - cores for USUP nodes in the USUP
Application cores [%] processing unit. The USUP node
processes UE-Specific functions in
User Plane (USUP).
RNC_5490a CPU load of USUP < 90% - Average CPU load of the UMW (timer,

Rel2 HW in USPU - ingress, and egress) cores in the most
UMW cores [%] loaded USUP node in USPU
processing unit. USUP node
User Plane (USUP).
RNC_5495a CPU load of USUP < 80% - Average CPU load of the application

Rel1 HW in USPU - cores for USUP nodes in USPU
Application cores [%] processing unit. USUP node
User Plane (USUP).
RNC_5496a CPU load of USUP < 90% - Average CPU load of the UMW (timer,

Rel1 HW in USPU - ingress, and egress) cores in the most
UMW cores [%] USUP loaded node in USPU
processing unit. USUP node
User Plane (USUP).

monitoring
- - -
4. Analysis -
5. Overload -
5.6 Flexi Direct RNC capacity

You can follow the Flexi Direct RNC capacity by monitoring the Flexi Direct RNC User
Plane Fill Factor at high level. The Flexi Direct RNC processing loads and Flexi Direct
RNC connectivity should be followed separately.
NOTE: Flexi Direct RU30 does not have any capacity upgrade possibilities in terms of
hardware, unit level or licensing. This chapter describes the options to monitor the
probable capacity bottlenecks in Flexi Direct RNC so that the operator could be able to
look for some feature or parameter based optimization options (not part of this document
scope).
94 DN0972569 Issue: 03I

ADA4.0 Product Description reference:
Document name: Flexi Direct RNC
Product description
Number: DN0931395
Location: NOLS
5.6.1 Flexi Direct RNC processing load

RNC feature (Flexi Direct RNC) is integrated with the FlexiBTS in Flexi Direct system.
The FTLB module in the FlexiBTS hardware accommodates the Flexi Direct RNC
software. FTLB is one of the FTM (Flexi Transport Module) variant which is used for Flexi
Direct.
FTLB comes with an Octeon processor, memory and interfacing units, which makes it
possible for the Flexi Direct RNC platform and application software to run on top as
shown in Figure 21: Flexi Direct functional architecture. The functional interfacing is
depicted in Figure 22: Flexi Direct BTS functional interfacing.
Both IP/Ethernet and ATM interfaces are supported for the external interfacing in Flexi
Direct. while there is no hardware or software redundancy supported in Flexi Direct RNC.
The SoC model architecture makes it complex to have a unit level redundancy
realization. In case of processing capacity overflow, the operator shall analyze possible
feature or parameter based optimizations or add a new Flexi Direct BTS for additional
capacity.
The following diagram shows the functional architecture and interfaces of Flexi Direct
and Flexi Direct BTS.
Issue: 03I DN0972569 95

Figure 21 Flexi Direct functional architecture
Flexi Direct RNC HW: CPU
Node
OMU RU
GFCP RU
EITP SE UP SE
Figure 22: Flexi Direct BTS functional interfacing shows the functional architecture and
interfaces of Flexi Direct BTS.
96 DN0972569 Issue: 03I

Figure 22 Flexi Direct BTS functional interfacing
Octeon Westport
Flexi Direct BTS
Transport I/F
IuPS-U
GGSN
IuPS-C
FSP Flexi Direct RNC SGSN
IuCS-U
MGW
Iub’ IuCS-C
FSP
Iur Ethernet RNC MSC
(C-plane +
FSP U-plane) Iur or Flexi Direct
PDH/ATM BTS
ATM WPOI IuPC
SAS
&
Switch
Flexi Direct QoS
Manager
O&M scheduling
shaping
VLAN
FTM OMS NetAct
IP
O&M
FCM
O&M
BTS-SEM
Flexi Direct BTS ToP ToP
The processing load (CPU utilization) in the Flexi Direct RNC is possible to be monitored
at two levels:
1) user plane level
2) control plane level
However, the unit level load monitoring is not possible. It is also to be noted that there is
no possibility to perform a unit level upgrade for any hardware units of Flexi Direct
RNC/Flexi Direct BTS.
Table 47 Flexi Direct RNC processing load
Monitored User plane CPU load
capacity item
The Octeon processor load consumed for user plane processing in Flexi Direct RNC. This is dependent
on the core distribution applied in the ADA product such that there are 5 cores available for user plane.
Note that the core distribution is not operator configurable.
Control Plane CPU load
The Octeon processor load consumed for control plane processing in Flexi Direct RNC. This is
dependent on the core distribution applied in the ADA product such that there are 3 cores available for
control plane. Note that the core distribution is not operator configurable.
Proactive Counter/KPI Name, unit Target Red Description

monitoring flag
IHSPA_5400a FD-RNC user plane 80% - The average CPU load of the

load [%] most loaded core.
Issue: 03I DN0972569 97

Table 47 Flexi Direct RNC processing load (Cont.)
IHSPA_5401a FD-RNC control plane 80% - The average CPU load of the
load [%] most loaded core.
Reactive Counter/KPI Name, unit Description

monitoring
- - -
Analysis The load levels of user and control plane processing resources need to be compared along with other
problems and conditions in the network. For example low average throughput + higher call drops + high
call attempts. Here the control plane could be the bottleneck and the Flexi Direct RNC C-plane
processing level can be verified with IHSPA_5401a.
Overload -
Upgrade Install an additional Flexi Direct BTS network element to increase network level capacity/connectivity.
5.7 RNC capacity usage forecasting

Purpose
For an installed controller product, and using the KPI data collected from the controller,
estimate when internal resources might become limited. This date can be used to plan
optimization or capacity upgrade actions.
g The focus here is on internal controller capacity. For the network transport interface
capacity, see sections IP transport interface capacity and
ATM transport interface capacity.
g Not all internal resources are tracked through a specific KPI, hence this method does
not cover capacity limitations related to these resources.
This section explains how to calculate the Controller Fill Ration (CFR), and presents two
methods that can be used to estimate when the nominal capacity of internal resources
will be reached. The first method is based on the current fill ratio and some assumed
traffic growth. The second method is a trend follow-up over, for example, several weeks.
Used KPIs
There is a set of ‘internal load’ KPIs that need to be followed for each controller product,
and a common ‘offered load’ KPI - the controller SP load index. The details about the
KPIs are given in section.
Assumption
For a given traffic profile, each internal load KPI grows about linearly with the offered
load. This can be written as KPI = a * offered load + b, where the coefficients a
and b are specific for each KPI. Because of this, a KPI value cannot be used as a direct
indicator or of how much more traffic to controller can carry.
98 DN0972569 Issue: 03I

5.7.1 Calculation of the controller fill ratio (CFR)

• Principle: use the observed daily variation of the KPIs as function of the offered load.
The fill ratio is defined by the KPI that would first reach its target level, if the offered
load was increased.
• Collect the hourly data for the relevant KPIs, during a full day (24 hours).
• For each KPI:
– Plot the hourly data as function of the Controller CP load index KPI, and verify
that there is a linear dependency.
– Calculate the linear fit coefficient a and b: KPI = a * index + b.
– Calculate a normalized KPI (nKPI), from the maximum daily value, using its
coefficient b and target load: nKPI = [max(KPI) - b] / [target(KPI) - b].
• The CFR is the maximum over the normalized KPI values, CFR = max(nKPI).
• The CFR can be used to express the remaining traffic capacity as a function of the
current traffic: (100% - CFR) * max offered load.
5.7.2 Estimation of the date when internal resources might

become limiting - quick estimation
• A pre-requisite is to have an estimation of the traffic growth rate (GR, in %/day). We
also use the CFR from Calculation of the controller fill ratio (CFR).
The growth rate is assumed to remain constant until the estimated date.
• If we call ndays the estimated number of days from the date the KPI data was
collected, to the date when internal resources might become limiting, we simply have
ndays = (100% - CFR) / GR.
• In case the number of cells in the radio network is planned to be increased, from
Ncells1 to Ncells2, the CFR calculation must be modified, and the estimated “b”
coefficients should be multiplied by a correction factor: Ncells2 / Ncells1.
• It is important to recognize that there might be a large error in the estimated date.
And that date might change over time, for example, if the traffic profile evolves.
Hence, it is recommended to repeat this assessment periodically, or to use the next
method.
5.7.3 Estimation of the date when the internal resources might

become limiting - standard trend follow-up
• The principle is to follow the evolution of the KPIs over a sufficiently long period of
time, and perform an extrapolation.
• Periodically collect the maximum hourly KPI values per day, for a minimum of 4
weeks.
• For each KPI:
– Plot the KPI values as a function of time. For clarity, weekdays with lower activity
might be left out.
– Extrapolate the trend, and estimate when the KPI-specific target level will be first
reached.
• The estimated date is the earliest of all the KPI-specific dates.
Issue: 03I DN0972569 99

5.7.4 KPIs relevant for controller capacity upgrade planning

• Controller CP load index - common for all controller products. The corresponding KPI
is RNC_5234a.
• Common KPIs for capacity licenses - applicable for cRNC and mcRNC.
Table 48 Common KPIs for capacity licenses
Licence KPI Target
AMR RNC_1773a 40%
AMR RNC_1774a 20%
Data RNC_1771a 40%
Data RNC_1772a 20%
• KPIs for cRNC
Table 49 KPIs for cRNC
Unit KPI Target
ICSU RNC_5228a 80%
RSMU RNC_1871a 70%
NPGE RNC_1983a 80%
DMPG RNC_1981a 80%
DMCU RNC_5416a 70%
DSP RNC_5209a 80%
• KPIs for mcRNC
Table 50 KPIs for mcRNC
Processing
FPNODE type Core type KPI Target
Unit
CFPU CFPU N/A RNC_5435a < 80%
CFPU USSR N/A RNC_5436a < 80%
CSPU CSPU N/A RNC_5437a < 80%
CSPU CSUP Application RNC_5487a [2] < 80%
100 DN0972569 Issue: 03I

Table 50 KPIs for mcRNC (Cont.)
Processing
FPNODE type Core type KPI Target
Unit
CSPU CSUP UMW RNC_5488a [2] < 90%
CSPU CSUP Application RNC_5493a [1] < 80%
CSPU CSUP UMW RNC_5494a [1] < 90%
EIPU EIPU N/A RNC_5439a < 45%
EIPU EITP N/A RNC_5499a < 45%
USPU USPU N/A RNC_5441a < 80%
USPU USUP Application RNC_5489a [2] < 80%
USPU USUP UMW RNC_5490a [2] < 90%
USPU USUP Application RNC_5495a [1] < 80%
USPU USUP UMW RNC_5496a [1] < 90%
[1] for Rel1 HW
[2] for Rel2 HW
g The upgrade actions are expected to be initiated sufficiently ahead of the estimated
date.
Issue: 03I DN0972569 101

IP transport interface capacity Managing WCDMA RAN and Flexi Direct Capacity
6 IP transport interface capacity

Figure 23: IP interface capacity bottlenecks and Figure 24: IP transport interface show
the main bottlenecks in the IP transport interface - the three different bandwidth levels.
• Ethernet bandwidth
• IP-based route bandwidth
• IP-based route committed bandwidth
Figure 23 IP interface capacity bottlenecks
The bottleneck to be monitored is chosen based on the used capacity setting(s):
• if internal flow control (IFC) is set to ON: IP-based route bandwidth is the traffic
limiting factor
• if IFC is set to OFF: Ethernet bandwidth is usually the traffic limiting factor
g If this setting is used, IP-based route traffic and HSDPA part of the IP-based route traffic
can also be limited using the RAN1110: HSDPA Congestion Control feature.
• IFC ON is available only in IPA-RNC and mcRNC
• if IP connection admission control (CAC) is set to ON: there is guaranteed bandwidth
for some traffic
g If the RAN1449: Dual Iub for Flexi WCDMA BTS and/or
RAN1633: Dual Iub for UltraSite WCDMA BTS features are enabled, ATM and IP must
be monitored separately.
102 DN0972569 Issue: 03I

Managing WCDMA RAN and Flexi Direct Capacity IP transport interface capacity
Figure 24 IP transport interface
IP interface
IP Bottlenecks EthernetifBw IPBRBw IPBRCommittedBw
CapacitySettings IFC=OFF IFC=ON CAC=ON
Iu-PStraffic Iubtraffic AllDCHtraffic

Typically
Monitored Iu-CStraffic Iub,Iu-CS,Iur
RadioLayer
Interfaces IFC=InternalFlowControl
Iurtraffic
IPBR=IP BasedRoute
Iubtraffic
6.1 Ethernet interface

The Ethernet Interface monitoring is done to check the utilization level of the Ethernet
interface. The monitoring should be performed when the IFC is disabled for the related
IP-based routes in the Ethernet interface, or if the interface overbooking is used and the
sum of IP-based route bandwidths is higher than the interface capacity.
Figure 25 Ethernet interface monitoring
IFC = OFF for IP Route means that the monitored
interface can fully use the whole Ethernet BW
Capacity available
for all Traffic
Ethernet Interface BW
Ethernet interface traffic
Monitored
Capacity item
All traffic is sharing all the Ethernet BW resources
Issue: 03I DN0972569 103

In this case the nature of the traffic in the monitored interface does not matter, as all
traffic is treated equally.
A logical radio layer interface, for example the Iu-PS interface, might consist of one or
more Ethernet interfaces. Therefore, the logical interfaces can be monitored using IP-
based route monitoring.
Figure 26: IP resource overbooking shows the traffic in Ethernet interface might be
overbooked, that is, the total bandwidth of all related IP-based routes might exceed the
configured bandwidth of the Ethernet interface.
Figure 26 IP resource overbooking
Table 51 Ethernet bandwidth capacity
1. Monitored Ethernet bandwidth capacity
capacity item
Ethernet interface-level monitoring is needed to monitor the use of the interface to avoid congestion on the
interface level. Several IP-based routes for different logical interfaces, such as Iu-CS, and Iur, as well as
Iub, can be sharing the same interface.

monitoring
RNC_5210a NPGE Ethernet port This is the sum of the received
RX_Utilization [%] Ethernet data compared to the
maximum value, limited by the
RncEthernetBw parameter. The
formula to be used separately for
each Ethernet port on the NPGE.
< 80% -
IHSPA_5210a FTLB Ethernet Port This is the sum of the received
RX_Utilization Ethernet data compared to the
maximum, limited by the parameter
ETHERNET_BW. The formula should
be used separately for each
Ethernet port on the FTLB.
RNC_5222a NPGE Ethernet port This is the sum of the transmitted

TX_Utilization [%] < 80% - Ethernet data compared to the
maximum value, limited by the
104 DN0972569 Issue: 03I

Table 51 Ethernet bandwidth capacity (Cont.)
RncEthernetBw parameter. The
formula to be used separately for
each Ethernet port on NPGE.
IHSPA_5222a FTLB Ethernet Port This is the sum of the received

TX_Utilization Ethernet data compared to the
maximum, limited by the parameter
ETHERNET_BW. The formula should
be used separately for each
Ethernet port on the FTLB.

monitoring
RNC_1644a
Ethernet frames drop
Ingress Ethernet frames drop ratio, summed up to unit level.
ratio, ingress [%]
IHSPA_1644a
RNC_1645a
Ethernet frames drop
Egress Ethernet frames drop ratio, summed up to unit level.
ratio, egress [%]
IHSPA_1645a
4. Analysis 1. Ethernet port utilization
The Ethernet port utilization comes from all logical interfaces allocated to the Ethernet port:
• If high values are reached, see point 2 in this table.
• If high values are reached, check if the total traffic of the NPGE is close to the backplane limitation
of 1.65 Gbps (see NPGE).
2. Ethernet frames drop ratio
The possible overload is detected based on dropped frames in the Ethernet port(s) of the interface.
5. Overload The overload is caused by high traffic volumes. The NPGE unit should tolerate short bursts of overload,
but when there is constant overload, throughput overload can cause packet drops in the RAN interfaces
that are configured on the interface.
6. Upgrade If some of the interface units are loaded, reconfigure the logical interfaces to the units that are not loaded.
If all interface units are loaded, split the RNC or select a higher capacity model.
6.2 IP-based route

In the described IP-based route monitoring there is no load sharing over multiple
Ethernet interfaces; the IP-based route for a logical interface based on multiple Ethernet
interfaces exists but it is not described here as a separate monitoring case as there are
no capacity restrictions for such a route configuration.
There are three separate cases for IP-based route monitoring:
1. when the IP-based route bandwidth is the traffic limiting factor (IFC is enabled)
• this case is valid only for Iub interface monitoring
• traffic bandwidth is limited to the configured IP-based route bandwidth
Issue: 03I DN0972569 105

2. when feature RAN1110: HSDPA Congestion Control is the traffic limiting factor (IFC
is disabled)
• this case is valid only for Iub and Iur interface monitoring
• traffic bandwidth is limited to the related Ethernet interface bandwidth
• but the actual traffic limiting factor is the allowed traffic rate given by feature
RAN1110: HSDPA Congestion Control
3. CAC-controlled traffic exists on IP-based route (CAC is enabled)
• this case is valid only for Iub, Iu-CS, and Iur interface monitoring
• traffic bandwidth is limited to the configured IP-based route bandwidth
• an additional bandwidth limit for CAC-controlled traffic is given, that is, committed
bit rate traffic
6.2.1 IP-based route: IFC enabled

Figure 27 IP route monitoring: IFC enabled
IFC = ON means that the monitored interface can

use only the configured BW of used IP Route
Capacity available
IP based route BW
for all Traffic
IP-based route
traffic
Monitored
Capacity item
All traffic is sharing all the IP Route BW resources
Table 52 IP route bandwidth: IFC enabled
1. Monitored IP route bandwidth: IFC enabled
capacity item
This case of IP interface-related capacity monitoring is carried out when the IP-based route bandwidth is
the limiting factor.
g It is recommended that the Iub interface monitoring is carried out based on IP-based route(s).
IP route bandwidth monitoring
In this case, there are no bandwidth limitations set on the IP route (s).

monitoring flag
106 DN0972569 Issue: 03I

Table 52 IP route bandwidth: IFC enabled (Cont.)
Average outgoing traffic utilization rate of
IP-based traffic in controlling RNC for the
Average outgoing IP reporting period for a selected logical
RNC_5449a route traffic utilization < 40% - interface. The outgoing traffic includes all
rate user plane traffic between RNC and
BTS/neighbor RNC/CN (depends on what
is the receiving NE).
Outgoing traffic utilization rate (76% < X <
88%) for IP-based traffic in controlling RNC
Outgoing IP route for the reporting period for a selected
RNC_5450a traffic utilization rate - < 3% < 5% logical interface. The outgoing traffic
(76 - < 88)% includes all user plane traffic between RNC
and BTS/neighbor RNC/CN (depends on
what is the receiving NE).
Outgoing data
traffic load
RNC_5451a Outgoing traffic utilization rate (X > 88%)
for IP-based traffic in controlling RNC for
Outgoing IP route the reporting period for a selected logical
traffic utilization rate - < 1% < 2% interface. The outgoing traffic includes all
(88 - < 100)% user plane traffic between RNC and
RNC_5451a BTS/neighbor RNC/CN (depends on what
is the receiving NE).
Peak outgoing traffic utilization rate for IP-
based traffic in controlling RNC for the
reporting period for a selected logical
Peak outgoing IP route
RNC_5473a < 100% 100% interface. The outgoing traffic includes all
traffic utilization rate]
user plane traffic between RNC and BTS or
neighbor RNC or CN (depending on what
the sending NE is).
Total incoming data volume for IP-based
traffic in controlling RNC for the reporting
period for a selected logical interface. The
Incoming data Incoming IP route
RNC_5029a < 40% - incoming traffic includes all user plane
traffic load traffic volume [Mbit]
traffic between RNC and BTS/neighbor
RNC/CN (depends on what is the sending
NE).

monitoring
- - -
4. Analyses 1. Outgoing traffic load
• Outgoing data average load: The actual threshold for upgrade depends on the peak to average
ratio of the traffic. 40% is given assuming that the peak to average ratio is 2.5.
• Outgoing traffic utilization rates: Can be monitored with specific KPIs (RNC_5450a and
RNC_5451a)
2. Incoming traffic load
Issue: 03I DN0972569 107

Table 52 IP route bandwidth: IFC enabled (Cont.)
Incoming data volume must be divided by measurement period and thereafter be compared to the
IPRB bandwidth to obtain average traffic utilization. This is relevant for the Iub interface of
asymmetric transport, where the UL capacity is clearly lower than the DL capacity, for example, for
example, in asymmetric digital subscriber line (ADSL).
If the average Iub throughput is close to the available transport capacity, it might require an upgrade
of the available bandwidth.
3. Bandwidth utilization
There is no threshold as the IP route bandwidth is not the limiting factor. When the IP route is on a
single Ethernet with monitoring of the data volume KPIs (IHSPA_5084a and IHSPA_5085a) and
comparing the values to Ethernet bandwidth, a threshold can be created.
5. Overload The IP-based route traffic cannot exceed the IP-based route BW when IFC is enabled.
There is a specific KPI (RNC_5473a_ that tells when the BW utilization has been 100%.
If overload is detected, the end-user throughput starts to decrease.
6. Upgrade In the case of overload, the transport capacity and the IP-based route bandwidth should be increased.
In the case of overload the transport capacity should be increased.
6.2.2 IP-based route: IFC disabled

Figure 28: IP route monitoring - traffic limited by feature RAN1110: HSPA Congestion
Control shows that if the IFC is disabled, the traffic in the IP-based route might exceed
the IP-based route parameter value and then the traffic is restricted by:
1. logical interface capacity
2. other traffic in the interface
3. feature RAN1110: HSDPA Congestion Control (for the Iub or Iur interfaces) when it is
active
108 DN0972569 Issue: 03I

Figure 28 IP route monitoring - traffic limited by feature
RAN1110: HSPA Congestion Control
Other IPBRs sharing Ether if
+ HSPA CC restricts the full usage
Traffic load may of Ethernet if for one IPBR
exceed the IPBR BW
All Traffic IFC = OFF for IP Route means that the monitored interface can
in principle fully use the whole Ethernet BW
Capacity available for

IP based route BW
IP-based route
all traffic
traffic
Monitored
Capacity item
All traffic is sharing all the Ethernet BW resources
Table 53 IP route bandwidth: IFC disabled
1. Monitored IP route bandwidth: IFC disabled
capacity item
This case of IP interface-related capacity monitoring is carried out when the Iub transport interface is
monitored and there are no bandwidth limitations set on the Iub IP route(s).

monitoring flag
RNC_5449a Average outgoing traffic utilization rate
for IP-based traffic in controlling RNC
for the reporting period for a selected
Average outgoing IP
logical interface. The outgoing traffic
route traffic utilization < 40% -
includes all user plane traffic between
rate
RNC and BTS/neighbor RNC/CN
IHSPA_5449a (depends on what is the receiving
NE).
Outgoing data
traffic load
RNC_5473a Peak outgoing traffic utilization rate
for IP-based traffic in controlling RNC
for the reporting period for a selected
Peak outgoing IP route logical interface. The outgoing traffic
< 100% 100%
traffic utilization rate includes all user plane traffic between
IHSPA_5473a (depends on what is the receiving
NE).
RNC_5029a Total incoming data volume for IP-
Incoming data Incoming IP route traffic based traffic in controlling RNC for the
< 40% -
traffic load volume [Mbit] reporting period for a selected logical
IHSPA_5085a interface. The incoming traffic
Issue: 03I DN0972569 109

Table 53 IP route bandwidth: IFC disabled (Cont.)
includes all user plane traffic between
(depends on what is the sending NE)

monitoring
M5000C176 HS-DSCH CREDIT Number of HS-DSCH credit reductions because of Iub delay

REDUCTIONS DUE build-up.
TO IUB DELAY [#]
M5000C177 HS-DSCH CREDIT Number of HS-DSCH credit reductions because of severe Iub

REDUCTIONS DUE delay build-up.
TO SEVERE IUB
related to DELAY [#]
HSDPA
congestion
control M5000C178 HS-DSCH CREDIT Number of HS-DSCH credit reductions because of frame loss.
REDUCTIONS DUE
TO FRAME LOSS [#]
M5000C179 HS-DSCH CREDIT Number of HS-DSCH credit reductions because of MAC-HS

REDUCTIONS DUE buffer filling.
TO MAC-HS BUFFER
FILLING [#]
related to M1022C69 DELAY BUILDUP The number off “Congestion Indication control frame - delay

HSUPA INDICATIONS SENT build-up” messages sent to the BTS because of an Iub delay
congestion DUE TO IUB DELAY [#] detected by the Frame protocol.
control
M1022C70 DELAY BUILDUP The number of “Congestion indication control frame - delay
INDICATIONS SENT build-up” messages sent to the BTS because of the RNC HW
DUE TO HW overload congestion control feature.
OVERLOAD [#]
M1022C71 FRAME LOSS The number of “Congestion indication control frame - frame

INDICATIONS SENT loss” messages sent to the BTS because of Iub traffic loss
DUE TO TRAFFIC detected by the Frame protocol.
LOSS [#]

INDICATIONS SENT loss” messages sent to the BTS because of Iub delay detected
DUE TO IUB DELAY [#] by the Frame protocol.

INDICATIONS SENT loss” messages sent to the BTS because of RNC HW
DUE TO HW overload.
OVERLOAD [#]
4. Analyses 1. Used bandwidth
IP route bandwidth is not the limiting factor when the IFC is disabled.
• Outgoing traffic: Average and peak utilization can be monitored.
• Incoming traffic: Incoming data volume must be divided by measurement period and thereafter
be compared to the configured IPRB bandwidth to obtain average traffic utilization.
110 DN0972569 Issue: 03I

Table 53 IP route bandwidth: IFC disabled (Cont.)
– When IFC is disabled and there is no route bandwidth used for IPBR scheduler, counter
M5868C15 IP_EG_BW_CONFIG remains zero. Then utilization KPIs 5449 and 5473 are not
at all relevant, as they do not show any feasible value.
2. Congestion detection:
• for the Iub in downlink: if there is congestion in the Iub transport, the given HDSPA credits are
downgraded and detected by the counters (M5000C176 - M5000C179) listed above in this table.
• for the Iub in uplink: if there is congestion in the Iub transport, there start to be frame losses and
delays. These are detected by the listed counters (M1022C69 - M1022C73).
5. Overload If overload is detected on the Iub interface, the end-user throughput starts to decrease.
There is a specific KPI (RNC_5473a) that tells when the BW utilization has been 100%.
6. Upgrade In the case of overload, the transport capacity should be increased.
6.2.3 IP-based route: CAC-controlled traffic

If the IP-based route committed bandwidth is defined as a non-zero value (IP CAC is
used), the reserved bandwidth of the IP-based route should be monitored to avoid IP
CAC blocking. The Iub downlink IP CAC monitoring is performed in the RNC and the Iub
uplink IP CAC monitoring in the BTS.
When the IP CAC is enabled, then the bandwidth limit of CAC-controlled traffic is set to
be equal to the monitored IP-based route committed bandwidth.
Figure 29 Example for IP CAC monitoring for an IP-based route where IFC is also
enabled
IFC = ON means that the monitored interface can

use only the configured BW of used IP Route
Capacity available for
IP based route BW
NON CAC Traffic

Traffic as a
IP Commited BW
subject for CAC
Monitored
Capacity item
As the CAC is enabled there is committed traffic

i.e. CAC handled traffic have a committed
share of configured IP Route BW resources.
Committed BW includes besides CAC handled traffic

also signaling and DCN traffic
Issue: 03I DN0972569 111

The monitoring principle is to trace the changes of the Committed Bandwidth value. It is
the IP CAC that manages the committed bandwidth. The committed bandwidth includes
the given committed traffic types but also signaling traffic and possible O&M (DCN)
traffic.
Figure 30 IP CAC: committed traffic blocking
Committed BW =Guaranteed Traffic -
Committed SIG BW – Committed DCN BW
New connection
up to this capacity New connection
would fit in requiring this much
capacity would be
blocked
IP Based Route
Committed BW
IP CAC reservation for existing connections
If the user plane traffic towards the BTS is separated onto several virtual local area
networks (VLANs), it is also possible to enable CAC per VLAN. With VLAN
differentiation in use, there can be two separate IP-based routes in the RNC for the
connection towards the BTS.
For DL IP CAC monitoring, the same KPI can be used for all monitored IP-based routes.
For UL IP CAC monitoring, there are separate KPIs based on separate counters for
cases with or without VLAN differentiation.
Capacity Iub control plane (as well as for DCN) traffic is reserved by limiting user plane
connections in IP Connection Admission Control (CAC) with parameter IP-based
committed signalling BW. The formula is (IP-based route committed BW - IP-based
committed signalling BW - IP-based route committed DCN bandwidth).
When assigned to the same PHB queue with CAC-controlled traffic, there is always a
bandwidth for signalling the DCN traffic. This traffic is not limited to the IP-based
committed signalling/DCN BW parameter value. Therefore, it is not necessary to monitor
the signalling traffic similarly as it is in the case when the NBAP signalling is carried in
ATM VCC.
Table 54 Committed bandwidth
1. Monitored Committed bandwidth
capacity item
IP-based route committed bandwidth monitoring is usually done for the Iub, Iu-CS, and Iur interfaces. IP
CAC is not often enabled for Iu-PS, because CAC is performed from the RNC towards the core network
and the other direction is dominating.
The limitation is for the following types of traffic:
• R99 CS Voice
• R99 RT DCH CS: Conversational Class
• R99 RT DCH PS: Streaming Class
• R99 NRT DCH PS: Interactive and Background Class
• HSPA CS Voice (if feature RAN1689: CS Voice Over HSPA is active)
• HSPA RT PS: Streaming Class (if feature RAN1004: Streaming QoS for HSPA is active)
• HSPA NRT (PS): Interactive and Background Class
112 DN0972569 Issue: 03I

Table 54 Committed bandwidth (Cont.)
monitoring flag
IP route RNC_1909b
reservation
Max reserved The maximum value of IP bandwidth usage rate,
rate - DL with
IP-based route < 90% - comparing the maximum value of the reserved IP
or without
bandwidth [%] layer bit rate against the available bandwidth.
VLAN IHSPA_1909a
differentiation
RNC_5383a IP-based Iub
uplink maximum The maximum reservation rate of guaranteed IP
< 90% -
reservation rate transport resources at Flexi BTS per IP interface
IP route IHSPA_5383a at Flexi BTS [%]
reservation
rate - UL
without VLAN RNC_5384a IP-based Iub < 90% - The maximum reservation rate of guaranteed IP
differentiation uplink maximum transport resources at Ultra BTS per IP interface
reservation rate
at Ultrasite BTS
[%]
RNC_5385a IP-based Iub
uplink maximum
The maximum reservation rate of guaranteed IP
reservation rate < 90% -
transport resources at Flexi BTS per VLAN interface.
IP route at Flexi BTS -
IHSPA_5385a
reservation VLAN [%]
rate - UL with
VLAN RNC_5386a IP-based Iub < 90% - The maximum reservation rate of guaranteed IP
differentiation uplink maximum transport resources at Ultra BTS per VLAN interface.
reservation rate
at Ultrasite BTS
- VLAN [%]
IHSPA_1909a Max reserved < 90% - The maximum value of IP bandwidth usage rate,

IP-based route comparing the maximum value of the reserved IP
bandwidth layer bit rate against the available bandwidth.

monitoring
RNC_5005a IP route The transport resource request success ratio [%]. This KPI describes

accessibility for the average success rate of the transport resource reservation
outgoing traffic attempts for IP route based connections every/selected interface
[%] where IP is used.
RNC_5031a IP route The transport resource request success ratio [%]. This KPI describes

accessibility for the average success rate of the transport resource reservation
incoming Iub attempts for IP route based connections every/selected interface
traffic [%] where IP is used.
M804C1 FAIL_RNC_IP_R The number of failed IP transport resource reservations in the RNC

ES_EXT [#] because of external connection admission control.
Issue: 03I DN0972569 113

Table 54 Committed bandwidth (Cont.)
M804C5 FAIL_BTS_IP_R The number of failed IP transport resource reservations in the BTS
ES_EXT_TRAN because of external connection admission control.
S [#]
IHSPA_5086a IP route This is the transport resource request success ratio [%]/ This KPI

accessibility for describes the average success rate of the transport resource
outgoing traffic reservation attempts for IP route-based connections every/ selected
[%] interface where IP is used.
IP route
accessibility
IHSPA_5087a IP route This is the transport resource request success ration [%]. This KPI
accessibility for describes the average success rate of the transport resource
incoming traffic reservation attempts of IP route-based connections every/ selected
[%] interface where IP is used.
IP route M804C1 FAIL_RNC_IP_R This is the number of failed IP transport resource reservations in the

reservation ES_EXT [#] Flexi Direct RNC because of external admission control.
blocking
M804C5 FAIL_BTS_IP_R This is the number of failed IP transport resource reservations in the
ES_EXT_TRAN BTS because of external connection admission control.
S [#]
4. Analysis 1. Maximum reserved capacity for committed traffic
If maximum reserved bandwidth > 90% the probability of blocking because of IP CAC increases.
Thus, the IP-based committed bandwidth needs to be increased.
g NOTE! Threshold value depends on the value of the committed bandwidth parameter. The
higher the bandwidth, the higher the threshold can be.
2. Blocking of committed traffic
• The success ratio of IP route accessibility can be followed up in both uplink and downlink
directions.
• IP route accessibility blocking: there are specific counters for blocking reasons. The M804C1 is
the most relevant of these in the downlink direction and M804C5 is the most relevant in the
uplink direction. These counters means in practice that there is not enough transport capacity
allocated for the related IP route in the Iub, Iu-CS, or Iur interface.
5. Overload If the reservation increases to above the threshold limit, the IP-based CAC blocking probability increases.
6. Upgrade In the case of overload, the IP-based route committed bandwidth should be increased.
• The IP-based route committed bandwidth should be increased.
• Incoming traffic: the IP-based route committed bandwidth (done with parameter
cacCommitedBitRate) should be increased.
• Outgoing traffic: Feature Transport Bearer Tuning can be used to decrease the activity factors used
for calculating CAL allocation.
114 DN0972569 Issue: 03I

Managing WCDMA RAN and Flexi Direct Capacity ATM transport interface capacity
7 ATM transport interface capacity
g This chapter is relevant only for IPA-RNC.
Figure 31: ATM interface capacity bottlenecks shows the main bottlenecks on the ATM
transport interface - the three different interface levels.
• ATM interface
• ATM Virtual Path (VPC)
• ATM Virtual Channel (VCC)
Figure 31 ATM interface capacity bottlenecks
Configuration specifics of given bottlenecks

To find out what to monitor from each bottleneck, the following issues are relevant:
ATM service specifics
ATM transport interface provides traffic for any of the three following different ATM
service types:
• Constant Bit Rate (CBR) traffic
• Unspecified Bit Rate (UBR) traffic
• Unspecified Bit Rate+ (UBR+) traffic
Optional features: RAN1095: UBR+ for Iub User Plane and RAN1192: UBR+ for
Control Plane and Iu/Iur User Plane
The ATM service types are primarily managed by the following parameters:
• Peak Cell Rate (PCR) - limits the maximum total ATM traffic in the VPC/VCC.
• Minimum Defined Cell Rate (MDCR) - additionally for UBR+:
– Guarantees a minimum throughput level for UBR+ traffic in the VPC/VCC.
– The MDCR might be exceeded, that is, the guaranteed traffic load might exceed
100%.
– The difference between UBR and UBR+ management is that for UBR the MDCR
equals zero.
• ATM Connection Admission Control (CAC) is based on these two parameters. The
guaranteed bitrate equals the sum of all CBR PCRs and UBR+ MDCRs.
Issue: 03I DN0972569 115

ATM transport interface capacity Managing WCDMA RAN and Flexi Direct Capacity
The ATM service types can be separately configured for both VPCs and VCCs. However,
a UBR+ VCC can only be mapped to a UBR+ VPC.
ATM configuration specifics
The VPCs and VCCs can be shaped:
Traffic shaping ensures that the egress traffic leaving the network element, for example
RNC, does not exceed the PCR defined for the VPC or VCC. If the connection is
unshaped, the PCR can be exceeded and all surplus ATM cells can be discarded by the
receiving network node.
g In this document, shaping is considered only for CBR VPCs.
The capacity limitations for the bottlenecks are based on:
• ATM interface: the bandwidth of the interface card (STM-1) + configuration limitations
ATM CAC does not accept a VP inside an ATM interface if the sum of all guaranteed
bitrates for VPs exceeds the guaranteed bandwidth of the ATM interface.
• VPC: the used ATM service type(s) + configuration limitations
– For CBR VPs, ATM CAC does not accept a VC inside a VP if the sum of the VC
PCRs (and the MDCRs of all UBR+ VCs) exceeds the VP's PCR.
– For UBR+ VPs, ATM CAC does not accept a VC inside a VP if the sum of
MDCRs exceeds the VP's MDCR.
• VCC: the used ATM service type(s)
User Plane specifics
User Plane (UP) VCCs have the following configuration options related to user (radio
layer) services:
• User services (in this case) mean: RT DCH, NRT DCH, RT HSPA, or NRT HSPA.
• A VCC is shared between all different types of user services. The VCC is configured
to be a CBR, UBR, or UBR+. This type of VCC configuration is primarily used on Iu
interface (no HSPA).
• On Iur: additionally it is possible to dedicate Iur VCCs for up to three different types
of user services (related to the optional feature: RAN1231: HSPA over Iur).
– This AAL2 VCC selection possibility provides the means for traffic differentiation
for user services based on the traffic type (DCH or HSPA) and different AAL2
path types: stringent, bi-level stringent, and tolerant (for more information, see
Table HSPA over Iur AAL2 VCC combinations in WCDMA RAN ATM Transport).
– It is recommended to use a CBR VCC as stringent and stringent&stringent bi-
level paths for real-time traffic to maintain the QoS. Furthermore, it is
recommended to use a UBR+ VCC for stringent bi-level path for NRT-DCH and
Streaming HSPA traffic, and another UBR+ VCC as tolerant path for NRT HSPA
traffic.
• On Iub: additionally it is possible to dedicate Iub User Plane VCCs for up to four
different types of user services (optional feature - RAN759: Path Selection).
116 DN0972569 Issue: 03I

– The Path Selection provides the means for traffic differentiation for user services
based on traffic type (DCH or HSPA) and different AAL2 path types: stringent, bi-
level stringent, and tolerant (for more information, see Table Iub VC combinations
in WCDMA RAN ATM Transport).
– It is recommended to use a UBR+ VCC as bi-level stringent path for NRT-DCH
and Streaming HSPA traffic, and another UBR+ VCC as tolerant path for NRT
HSPA traffic. Further, it is recommended to use a CBR VCC as stringent path for
real-time traffic in order to maintain the QoS.
• Dedicated Iub VCCs are also possible to bundle (optional features: RAN1099:
Dynamic scheduling for HSDPA with Path Selection, RAN1100: Dynamic scheduling
for NRT DCH with Path Selection).
– VCC Bundle is a group of User Plane ATM VCs in the Iub interface for which a
VCCBundlePCR (VCC Bundle Peak Cell Rate) parameter is defined.
This means that unused capacity assigned to one of the bundled VCs can be
used by other VCs of the same bundle at the same time if the total traffic of the
bundled VCs does not exceed the bundle's PCR.
– The VCCBundleEBS (VCC Bundle Excess Bandwidth Share) parameter
defines how excess bandwidth is shared between NRT DCH and HSDPA traffic
in a congestion situation.
The parameter is taken into account only when both HSDPA and NRT DCH are
carried in dedicated VCs in the same VC bundle.
Control plane specifics
For control plane (C-plane) and O&M, the following aspects need to be taken into
account:
• On VCC level there always are separate VCCs for UP, C-plane, and management
plane (M-plane, that is O&M) traffic.
• C-plane or O&M VCCs are not bundled.
Reference: WCDMA RAN ATM Transport.
Monitoring of given bottlenecks

Figure 32: Monitoring principle of ATM bottlenecks shows the actual traffic of the
measured object (for example, VCC, VPC, or ATM interface) and the average traffic over
the measurement period that is measured using the counters. When peak traffic counter
is not available and average traffic values need to be used, measured traffic needs to
have lower threshold values.
Issue: 03I DN0972569 117

Figure 32 Monitoring principle of ATM bottlenecks
ATM Interface: The ATM interface level monitoring is relevant if you have unshaped
VPCs with UBR/UBR+ VCCs inside, and the sum of VCC PCRs exceeds the interface
capacity. Otherwise, the ATM CAC and/or VCC/VPC configuration will prevent overload
possibility.
ATM Virtual Path: The ATM Virtual Path level monitoring is relevant for a shaped CBR
VPC that limits the traffic of the UBR/UBR+ VCCs inside the VPC to the VPC PCR. If
there are CBR VCCs inside a shaped CBR VPC, the VCCs can be monitored on VCC
level to follow up separately their relation to their PCRs.
For Iub, if both CBR and UBR+ VCCs exist inside VPC, the VCCs should be monitored
on VCC level to follow up separately their relation to their PCRs and MDCRs, unless it is
enough to follow up the capacity at VPC level. If there is only one VPC for the Iub
connection, VPC monitoring can be used to monitor the total Iub capacity.
ATM Virtual Channel: The ATM Virtual Channel level monitoring is needed to identify the
amount of traffic per VCC. Depending on the VCC configuration, the different traffic types
like DCH + HSPA stringent, DCH + HSPA stringent bi-level, and HSPA tolerant can be
measured at VCC level.
When separately monitoring Control Plane or Management Plane (O&M), only ATM
Virtual Channel level is relevant.
g If the RAN1449: Dual Iub for Flexi WCDMA BTS and/or
RAN1633: Dual Iub for UltraSite WCDMA BTS features are enabled, ATM and IP must
be monitored separately.
Figure 33: ATM transport interface: identified monitoring cases shows the above
mentioned conclusions. For the listed radio interfaces, the reason is given in the use
case section.
118 DN0972569 Issue: 03I

Figure 33 ATM transport interface: identified monitoring cases
ATMtransportinterface
ATM VirtualPath(VP) VirtualChannel(VC)

Interface
Bottlenecks
Considered UBR+VCCinside ShapedCBR

Configuration UnshapedVP(s) VP(s) CBR UBR/UBR+
7.1 ATM interface

An ATM interface is one of eight STM-1 interfaces in an NPS1/NPS1P (RNC2600) or
NIS1/NIS1P (RNC196/RNC450) unit. The capacity of an STM-1 interface is standardized
to 155 Mbit/s.
Table 55 Utilization of ATM interface
1. Monitored Utilization of ATM interface
capacity item
ATM interface level monitoring is needed to monitor the utilization of the interface to avoid congestion in
the used STM-1 interface.
In this case the ATM services are not separated, that is, the utilization of all the traffic on the ATM interface
is monitored. ATM interface monitoring is typically used for Iu-CS interfaces and for Iu-PS (in case ATM is
used).
g It is also possible to use ATM interface level monitoring for Iub in case it is enough to follow up the
capacity of the whole Iub, that is, no user service separation is needed and the whole ATM interface
is reserved for Iub user plane traffic.

monitoring
RNC_1127a Average ATM unit 80% - Interface utilization is the total
interface utilization number of received ingress ATM
ingress [%] cells, divided by the configured
ingress bandwidth.
RNC_1128a Average ATM unit 80% - Interface utilization is the total

interface utilization number of transmitted egress ATM
egress [%] cells, divided by the configured
ingress bandwidth.

monitoring
4. Analysis 1. Average ingress ATM interface utilization
The data traffic load value gives the utilization rate against the interface capacity. If the utilization rate
is above 80% it might be necessary to move connections to another interface.
Issue: 03I DN0972569 119

Table 55 Utilization of ATM interface (Cont.)
2. Average egress ATM interface utilization
The data traffic load value gives the utilization rate against the interface capacity. If the utilization rate
is above 80% it might be necessary to move connections to another interface.
5. Overload If data traffic load increases above the threshold limits, the user throughput is downgraded in high load
situations.
6. Upgrade For upgrade, move ATM connections from one STM-1 to another.
7.2 ATM virtual path

Table 56 Utilization of ATM virtual path
1. Monitored Utilization of ATM virtual path
capacity item
ATM virtual path monitoring is necessary to monitor the utilization of the interface to avoid congestion on
the VPC level and to see whether guaranteed traffic reservation is sufficient (in a shaped VPC case).
In this case the ATM services are not separated, that is, the utilization of all the traffic on the ATM VPC is
monitored. VPC monitoring is typically used for Iu-CS, Iu-PS (in case ATM is used), Iur, and Iub interfaces.
g For Iu-CS, Iur, and Iub, VPC monitoring is sufficient when it is enough to monitor only the whole
capacity.

monitoring
Shaped or RNC_963a Average ATM VPC - - This KPI shows the outgoing ATM

unshaped egress throughput layer traffic for a single ATM VP
VPC [cps] connection. The load is measured in
RNC egress direction.
RNC_962a Average ATM VPC - - This KPI shows the incoming ATM

ingress throughput layer traffic for a single ATM VP
[cps] connection. The load is measured in
RNC ingress direction.
Unshaped RNC_1061a Average ATM VPC - - This KPI shows the outgoing ATM

VPC egress utilization [%] layer guaranteed traffic load for a
single ATM VP connection. The load
is measured in RNC egress
direction.
RNC_1060b Average ATM VPC - - This KPI shows the incoming ATM

ingress utilization [%] layer guaranteed traffic load for a
single ATM VP connection. The load
is measured in RNC ingress
direction.

monitoring
120 DN0972569 Issue: 03I

Table 56 Utilization of ATM virtual path (Cont.)
4. Analysis 1. Average ATM VPC egress throughput
Compare the measured value to configured PCR (not part of KPI, that is, must be checked from
elsewhere) to obtain a data traffic load value for comparison against the threshold. The comparison
result (=data traffic load for all traffic) is, in that case, the VPC utilization rate against the peak
bandwidth (=PCR). If data traffic load is above the threshold it might be necessary to increase the
PCR.
2. Average ATM VPC ingress throughput
Compare the measured value to configured PCR (not part of KPI, that is, must be checked from
elsewhere) to obtain a data traffic load value for comparison against the threshold. The comparison
result (=data traffic load for all traffic) is in that case the VPC utilization rate against the peak
bandwidth (=PCR). If data traffic load is above the threshold it might be necessary to increase the
PCR.
3. Average egress ATM interface utilization
The data traffic load value gives the utilization rate against the committed bandwidth (= MDCR). If the
utilization rate is above 100% it might be necessary to increase the MDCR.
4. Average ingress ATM interface utilization
The data traffic load value tells the utilization rate against the committed bandwidth (= MDCR). If the
utilization rate is above 100% it might be necessary to increase the MDCR.
situations.
6. Upgrade If overload occurs for all traffic, the PCR should be increased.
If overload occurs for traffic, the MDCR should be increased.
7.3 ATM virtual channel

The ATM VCC use cases are split into CBR VCC and UBR/UBR+ VCC parts.
The use cases for CBR or UBR/UBR+ (without path selection) VCC are for U-plane, CP
and, MP (O&M), but the UBR/UBR+ VCC use cases including path selection are only for
U-plane.
7.3.1 ATM virtual channel - CBR

Table 57 Utilization of ATM virtual channel (CBR)
1. Monitored Utilization of ATM virtual channel
capacity item
ATM Virtual Channel monitoring for CBR VCCs is necessary to monitor the utilization of the connection to
avoid congestion on the VCC level.
In addition to monitoring the traffic carried in the VCC, the AAL2 Connection admission control (CAC)
should be monitored; this means monitoring max AAL2 reservation level and AAL2 connection utilization
(maximum number of AAL2 connections is 248 per VCC). AAL2 CAC is in charge of AAL2 resources.
AAL2 CAC is performed in the WBTS for Iub uplink traffic, and in the RNC for Iub downlink traffic. AAL2
CAC ensures that once an AAL2 connection has been accepted, data can be transported over this
connection within a specified delay boundary and loss ratio.
A CBR VCC is typically used for Iub, Iur, Iu-CS (user and control plane connections).
Iu-CS: All services are RT services in the VCC.
Iur: It depends on the selected configuration which traffic type utilizes one VCC.
Issue: 03I DN0972569 121

Table 57 Utilization of ATM virtual channel (CBR) (Cont.)
If there is AAL2 selection in use (because of RAN1231: HSPA over Iur feature), the monitored CBR VCC
can be used to follow up RT traffic utilization; if not, the monitoring provides the utilization rate of all
services on the Iub VCC.
Iub: It depends on the selected configuration which traffic type utilizes one VCC.
If there is path selection in use, the monitored CBR VCC can be used to follow up RT traffic utilization; if
not, the monitoring provides the utilization rate of all services on the Iub VCC.

monitoring flag
RNC_732b ATM VCC-specific < 40% - This KPI shows the outgoing ATM layer

outgoing traffic load traffic load for a single ATM VC connection.
[%] The load is measured in RNC egress
direction.
RNC_5452a ATM VCC egress < 3% < 5% Outgoing ATM layer traffic utilization rate

utilization rate - (76 - < (76% < X < 88%) for single ATM VC
88)% connection. The load is measured in RNC
Outgoing data egress direction.
traffic load
RNC_5453a ATM VCC egress < 1% < 2% Outgoing ATM layer traffic utilization rate (X
utilization rate - (88 - < > 88%) for single ATM VC connection. The
100)% load is measured in RNC egress direction.
RNC_5477a ATM VCC peak egress < 100% 100% Peak outgoing traffic utilization rate for

load single ATM VC connection. The load is
measured in RNC egress direction.
RNC_960b ATM VCC-specific < 40% - This KPI shows the outgoing ATM layer

incoming traffic load traffic load for a single ATM VC connection.
[%] The load is measured in RNC ingress
direction.
RNC_5454a ATM VCC ingress < 3% < 5% Incoming ATM layer traffic utilization rate

utilization rate - (76 - < (76% < X 88%) for single ATM VC
88)% connection. The load is measured in RNC
Incoming data ingress utilization.
traffic load
RNC_5455a ATM VCC ingress < 1% < 2% Incoming ATM layer traffic utilization rate (X
utilization rate (88 - < > 88%) for single ATM VC connection. The
100)% load is measured in RNC ingress direction.
RNC_5478a ATM VCC peak < 100% 100% Peak incoming traffic utilization rate for

ingress load single ATM VC connection. The load is
measured in RNC ingress direction.
RNC_760a Allocated peak - - The ratio between peak reserved

Connection capacity of ATM VCC bandwidth and total bandwidth of AAL2
utilization [%] path estimated by CAC during
measurement period.
122 DN0972569 Issue: 03I

Table 57 Utilization of ATM virtual channel (CBR) (Cont.)
RNC_1057a Maximum AAL2 < 90% - The ratio between the maximum number of
connection utilization AAL2 path connections and the total
[%] maximum number connections during the
measurement period.

monitoring
Connection RNC_602a AAL2 connection This KPI describes the average success rate of the transport

reservation reservation success resource reservation attempts for AAL2 type connections.
success rate rate [%]
4. Analyses 1. Outgoing data traffic load
Outgoing traffic load and utilization rates: Can be monitored with specific KPIs (RNC_732b,
RNC_5452a and RNC_5453a).
The data traffic load value gives the utilization rate against the peak bandwidth (= PCR). If data traffic
load is above the threshold it might be necessary to increase the PCR.
The threshold for average traffic load for control plane VCCs is 60% for Iub and 20% for Iu.
2. Incoming data traffic load
Incoming traffic utilization rates: Can be monitored with specific KPIs (RNC_960b, RNC_5454a and
RNC_5455a)
The data traffic load value gives the utilization rate against the peak bandwidth (= PCR). If data traffic
load is above the threshold it might be necessary to increase the PCR / bundle PCR.
The threshold for average traffic load for control plane VCCs is 60% for Iub and 20% for Iu.
3. Allocated peak capacity of ATM VCC
If threshold is exceeded, that is, during traffic peaks load is close to 100%, probability AAL2
connection blocks increases. Then, it is necessary to check the AAL2 connection reservation success
KPI (RNC_602a).
4. Maximum AAL2 connection utilization (RNC_1057a)
If threshold is exceeded, a new UP VCC needs to be introduced for the same traffic.
5. AAL2 connection reservation success rate (VCC)
If the rate is below for example 99% (threshold varies based on CBR VCC PCR) there is overload in
the VCC.
5. Overload If data traffic load increases above the threshold limit, the user throughput is downgraded in high load
situations. There are specific KPIs (RNC_5477a and RNC_5478a) that tell when the BW utilization has
been up to 100%.
If allocated peak capacity exceeds the threshold value or maximum AAL2 connection utilization exceeds
the threshold, the probability of blocking because of AAL2 CAC increases.
6. Upgrade If overload occurs, the PCR should be increased.
If more AAL2 connections are necessary, additional VCC needs to be added.
7.3.2 ATM virtual channel - UBR/UBR+

UBR/UBR+ VCC Use Cases differ depending on whether the monitored VCC(s) are in a
bundle or not.
Table 58 Utilization of ATM virtual channel (UBR/UBR+)
1. Monitored Utilization of ATM virtual channel
capacity item
Issue: 03I DN0972569 123

Table 58 Utilization of ATM virtual channel (UBR/UBR+) (Cont.)
ATM virtual channel monitoring for UBR/UBR+ VCCs is needed to monitor the usage of the interface to
avoid congestion on the VCC level, and for UBR+ to see whether guaranteed traffic reservation is
sufficient.
For UBR+, the peak and guaranteed bandwidth differs, that is, it is necessary to monitor two separate
load levels.
A UBR/UBR+VCC (without bundling) is typically used for any radio-layer user or control interface. Also
MP (O&M) typically uses UBR/UBR+ VCC.
Iu-CS: All services are RT services in the VCC.
Iu-PS: The services in UBR+ VCC might be RT (Streaming) DCH/HSPA or NRT DCH/HSPA.
Iur: It depends on the selected configuration which traffic type utilizes one VCC. If there is AAL2 selection
(because of RAN1231: HSPA over Iur feature) in use, the monitored CBR VCC can be used to follow up
RT traffic utilization; if not, the monitoring provides the utilization rate of all services on the Iub VCC.
Iub: It depends on the selected configuration which traffic type utilizes one VCC.
For path selection mapped VCC, there cannot exist a UBR configuration, that is, only UBR+ VCC is
allowed.
If there is path selection in use, the monitored UBR+ VCC can be used to follow up utilization of different
radio services (RT DCH, NRT DCH or HSPA); if not, the monitoring provides the utilization rate of all
services on the Iub VCC.
A UBR+ VCC (with bundling) is only used on Iub interface.
g It might be enough to monitor the whole VCC bundle on VPC level when all bundled VCCs share
the same VPC.
In this case:
• the utilization rate for the whole bundle is assumed to be monitored as described in
VCC bundle.
• the radio services are on own VCCs, so the utilization rates can be monitored separately.

monitoring flag
RNC_732b ATM VCC- - - This KPI shows the outgoing ATM layer traffic load

specific outgoing for a single ATM VC connection. The load is
traffic load [%] measured in RNC egress direction.
RNC_5452a ATM VCC - - Outgoing ATM layer traffic utilization rate (76% < X <

egress utilization 88%) for single ATM VC connection. The load is
rate - (76 - < measured in RNC egress direction.
88)%
Outgoing data
traffic load
RNC_5453a ATM VCC - - Outgoing ATM layer traffic utilization rate (X > 88%)
egress utilization for single ATM VC bundle connection. The load is
rate (88 - < measured in RNC egress direction.
100)%
RNC_5477a ATM VCC peak - - Peak outgoing traffic utilization rate for single ATM

egress load VC connection (% of the MDCR). The load is
measures in RNC egress direction.
124 DN0972569 Issue: 03I

RNC_960b ATM VCC- - - This KPI shows the outgoing ATM layer traffic load
specific for a single ATM VC connection. The load is
incoming traffic measured in RNC ingress direction.
load [%]
RNC_5454a ATM VCC - - Incoming ATM layer traffic utilization rate (76% < X <

ingress 88%) for single ATM VC connection. The load is
utilization rate - measured in RNC ingress direction.
Incoming data (76 - < 88)%
traffic load
RNC_5455a ATM VCC - - Incoming ATM layer traffic utilization rate (X > 88%)
ingress for single ATM VC connection. The load is measured
utilization rate - in RNC ingress direction.
(88 - < 100)%
RNC_5478a ATM VCC peak - - Peak incoming traffic utilization rate for single ATM

ingress load VC connection (% of the MDCR). The load is
measured in RNC ingress direction.
RNC_760a Allocated peak - - The ratio between peak reserved bandwidth and

capacity of ATM total bandwidth of AAL2 path estimated by CAC
VCC [%] during measurement period.
Connection
utilization
RNC_1057a Maximum AAL2 < 90% - The ratio between maximum number of AAL2 path
connection connections and total maximum number connections
utilization [%] during measurement period.

monitoring
Connection RNC_602a AAL2 connection This KPI describes the average success rate of the transport resource

reservation reservation reservation attempts for AAL2 type connections.
success rate success rate [%]
4. Analysis 1. Outgoing data traffic load
Outgoing traffic load and utilization rates: Can be monitored with specific KPIs (RNC_732b,
RNC_5452a and RNC_5453a).
The data traffic load value gives the utilization rate against the peak bandwidth (= MDCR). If data
traffic load is above the threshold it might be necessary to increase the MDCR.
The threshold for average traffic load for control plane VCCs is 60%.
g No threshold recommendation is given for user plane UBR+ VCCs as the planned MDCR
values vary depending on the traffic type carried in the UBR+ VCC and whether the UBR+
VCC is inside the VCC bundle or not.
2. Incoming data traffic load
Incoming traffic utilization rates: Can be monitored with specific KPIs (RNC_960b, RNC_5454a and
RNC_5455a)
The data traffic load value gives the utilization rate against the peak bandwidth (= MDCR). If data
traffic load is above the threshold it might be necessary to increase the PCR / bundle MDCR.
The threshold for average traffic load for control plane VCCs is 60%.
Issue: 03I DN0972569 125

g No threshold recommendation is given for user plane UBR+ VCCs as the planned MDCR
values vary depending on the traffic type carried in the UBR+ VCC and if the UBR+ VCC is
inside the VCC bundle or not.
3. Allocated peak capacity of ATM VCC
If threshold is exceeded, that is, during traffic peaks load is close to 100%, probability AAL2
connection blocks increases. Then, it is necessary to check the AAL2 connection reservation success
KPI (RNC_602a).
4. Maximum AAL2 connection utilization (RNC_1057a)
If threshold is exceeded, a new UP VCC needs to be introduced for the same traffic.
5. AAL2 connection reservation success rate (VCC)
If the rate is below for example 99% (threshold varies based on CBR VCC PCR) there is overload in
the VCC.
5. Overload If data traffic load increases above the threshold limit, the user throughput is downgraded in high load
situations.
If allocated peak capacity increases above the threshold limit, the probability of AAL2 connection
reservation blocks is higher and there might be overload in the VCC.
6. Upgrade If overload occurs for committed traffic, the MDCR should be increased.
If more AAL2 connections are needed, additional VCC needs to be added.
7.4 VCC bundle

Figure 34: VCC bundle - UBR + VCCs bandwidth shows that in a bundle, there can be
both CBR and UBR+ VCC and they share the capacity within the VCC bundle. The traffic
carried in the CBR VCCs are limited by the PCR. The traffic carried in the UBR+ VCCs
can exceed the guaranteed bandwidth (=MDCR). The total traffic within the VCC bundle
consisting of CBR and UBR+ VCCs is limited by the VCCBundlePCR.
Figure 34 VCC bundle - UBR + VCCs bandwidth
Bandwidth %
100%
88%
VC 75%
bundle 50%
25%
g The monitoring of the separate VCCs inside the created VCC bundles are handled in
sections ATM virtual channel - CBR and ATM virtual channel - UBR/UBR+. This section
captures only the bundle level monitoring.
Table 59 Utilization of ATM VCC bundle
1. Monitored Utilization of ATM VCC bundle
capacity item
126 DN0972569 Issue: 03I

Table 59 Utilization of ATM VCC bundle (Cont.)
ATM VCC bundle monitoring is necessary to monitor the utilization of the bundle to avoid congestion on
the VCC bundle level.
ATM VCC bundling is only used on Iub interface.
All the VCCs in the bundle share the same PCR parameter (VCCBundlePCR parameter).

monitoring
RNC_5452a ATM VCC bundle < 3% < 5% Outgoing traffic utilization rate (76%

egress utilization rate - < X < 88%) for ATM VPC bundle.
(76 - < 88)% The load is measured in RNC
egress direction.
Outgoing data
traffic load
RNC_5453a ATM VCC bundle < 1% < 2% Outgoing traffic utilization rate (X >
egress utilization rate - 88%) for ATM VPC bundle. The load
(88 - < 100)$ is measured in RNC egress
direction.

monitoring
4. Analysis Outgoing data traffic load
The data traffic load value gives the utilization rate against the peak bandwidth (=VCCBundlePCR).
• If the target is exceeded, it might be necessary to increase the VCCBundlePCR.
• If the red flag is exceeded, it is necessary to increase the VCCBundlePCR.
situations.
6. Upgrade If overload occurs for all traffic, the VCCBundlePCR should be increased.
Issue: 03I DN0972569 127

Sprache

Willkommen bei Scribd!

Nokia Managing Wcdma Ran and Flexi Direct Capacity

Hochgeladen von

Dokumentinformationen

Beschreibung:

Datum des Uploads

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Beschreibung:

Copyright:

Verfügbare Formate

Nokia Managing Wcdma Ran and Flexi Direct Capacity

Hochgeladen von

Beschreibung:

Copyright:

Verfügbare Formate

Verwandte Titel

Nokia Networks

WCDMA RAN, Rel. RU40,

Managing WCDMA RAN and

f Important Notice on Product Safety

7.3.2 ATM virtual channel - UBR/UBR+.............................................. 123

Changes between issues 03H (2014-06-19, RU40) and 03I (2014-09-

Changes between issues 03G (2014-04-21, RU40) and 03H (2014-06-

Changes between issues 03F (2014-03-14, RU40) and 03G (2014-04-

1 Introduction to capacity management

1.1 Purpose and scope of the document

1.2 3G RAN capacity management model

1.3 Capacity management process

2 Access network capacity and stability

Access Network Capacity Access Network Stability

Voice Data User Call Call Call

2.1 Generic access network capacity management

2.1.1 Voice capacity

2.1.1.1 Voice capacity - user plane

2. Proactive Counter/KPI Name, unit Target Red flag Description

3. Reactive Counter/KPI Name, unit Description

2.1.1.2 Voice capacity - control plane

2. Proactive Counter/KPI Name, unit Target Red Description

RNC_1773a AMR Licensed 40% (together - The AMR simultaneous call distribution in the

3. Reactive Counter/KPI Name, unit Description

M1001C619 RAB SETUP FAILURES DUE The number of RAB setup failures caused by the AMR

RNC_229a RAB Attempts Voice [#] Voice BHCA. This measured traffic parameter describes

2.1.2 Data capacity

2.1.2.1 Data capacity - user plane

2.1.2.2 Data capacity - control plane

2.1.3 User capacity

2.2 Access network capacity monitoring

2.3 Access network stability monitoring

2. Proactive Counter/KPI Name, unit Target Red Description

3. Reactive Counter/KPI Name, unit Description

3 Radio interface capacity

3.1 Downlink power

2. Proactive Counter/KPI Name, unit Target Red Description

3. Reactive Counter/KPI Name, unit Description

M1000C155 RN RELEASE BY The number of radio bearers released by the dynamic link

M1000C166 RB RELEASE DUE The number of radio bearer releases by the enhanced overload

M1000C149 HS-DSCH RELEASE The number of HS-DSCH allocation releases because of downlink

M1000C142 RB DOWNGRADE The number of radio bearer downgrades by the enhanced

M1002C602 DL DCH SELECTED This counter is updated when the HS-DSCH cannot be selected

RNC_969b DL DCH selected due The number of times when the HS-DSCH downlink transport

3.2 Uplink interference

2. Proactive Counter/KPI Name, unit Target Red Description

M1000C147 RB DOWNGRADE BY PBS The number of RB downgrades by priority-based scheduling

M1000C159 RB RELEASE BY PBS DUE The number of radio bearers released by priority-based

M1000C152 RB DOWNGRADE BY PRE- The number of RB downgrades by pre-emption because of

M1000C164 RB RELEASE BY PRE- The number of radio bearers released by pre-emption because

3.3 Common channel capacity

2. Proactive Counter/KPI Name, unit Target Red Description

3. Reactive Counter/KPI Name, unit Description

3.4 Channelization code tree

2. Proactive Counter/KPI Name, unit Target Red Description

3. Reactive Counter/KPI Name, unit Description

M1000C266 HSDPA CH CODE The number of HSDPA channelization code