Sie sind auf Seite 1von 116

Nokia Networks

WCDMA RAN, Rel. WCDMA


17, Operating Documentation,
Pre-release, Issue 01

Managing WCDMA RAN


Capacity
DN0972569
Issue 06
Approval Date 2016-04-27

 
 
Managing WCDMA RAN 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 © 2016 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: 06
Managing WCDMA RAN Capacity

Table of Contents
This document has 116 pages
   
Summary of changes..................................................................... 9
   
1 Introduction to capacity management.......................................... 10
1.1 Purpose and scope of the document........................................... 10
1.2 3G RAN capacity management model.........................................12
1.3 Capacity management process....................................................15
   
2 Access network capacity and stability..........................................17
2.1 Generic access network capacity management aspects............. 17
2.1.1 Voice capacity.............................................................................. 17
2.1.1.1 Voice capacity - user plane.......................................................... 17
2.1.1.2 Voice capacity - control plane...................................................... 18
2.1.2 Data capacity............................................................................... 20
2.1.2.1 Data capacity - user plane........................................................... 21
2.1.2.2 Data capacity - control plane........................................................21
2.1.3 User capacity............................................................................... 21
2.2 Access network capacity monitoring............................................ 22
2.3 Access network stability monitoring............................................. 22
   
3 Radio interface capacity...............................................................26
3.1 Downlink power............................................................................26
3.2 Uplink interference....................................................................... 28
3.3 Common channel capacity...........................................................30
3.4 Channelization code tree............................................................. 32
   
4 Multiradio Flexi BTS WCDMA capacity........................................ 35
4.1 BTS baseband capacity monitoring............................................. 41
4.1.1 BTS level......................................................................................41
4.1.2 LCG level..................................................................................... 42
4.1.3 WCEL level.................................................................................. 44
4.1.4 Reactive monitoring..................................................................... 45
4.1.5 Analyzes, overload, and upgrades...............................................45
4.2 BTS control plane capacity.......................................................... 47
4.3 BTS user plane capacity.............................................................. 49
4.3.1 BTS level......................................................................................51
4.3.2 LCG level..................................................................................... 53
4.3.3 Scheduler level.............................................................................54
4.3.4 WCEL level.................................................................................. 55
4.3.5 Reactive monitoring..................................................................... 56
4.3.6 Analyzes, overload, and upgrades...............................................57
   
5 RNC capacity............................................................................... 61
5.1 RNC control plane capacity..........................................................61

Issue: 06 DN0972569 3
Managing WCDMA RAN Capacity

5.1.1 RNC control plane index.............................................................. 61
5.2 RNC user plane capacity............................................................. 62
5.2.1 Voice capacity.............................................................................. 62
5.2.2 Data capacity............................................................................... 64
5.2.3 RNC user plane fill factor............................................................. 65
5.2.4 RRC connected subscribers........................................................ 66
5.3 RNC connectivity..........................................................................67
5.3.1 Carriers and sites......................................................................... 67
5.4 IPA-RNC.......................................................................................68
5.4.1 cRNC DSP capacity for calls........................................................69
5.4.2 IPA-RNC unit loads...................................................................... 70
5.4.2.1 ICSU.............................................................................................71
5.4.2.2 RSMU...........................................................................................72
5.4.2.3 OMU............................................................................................. 73
5.4.2.4 OMS............................................................................................. 74
5.4.2.5 DMCU.......................................................................................... 74
5.4.2.5.1 DMPG.......................................................................................... 75
5.4.2.5.2 DSP.............................................................................................. 76
5.4.2.6 SFU.............................................................................................. 77
5.4.2.7 MXU............................................................................................. 77
5.4.2.8 SWU............................................................................................. 77
5.4.2.9 NPS1............................................................................................77
5.4.2.10 NPGE........................................................................................... 79
5.5 mcRNC.........................................................................................80
5.5.1 mcRNC DSP capacity for calls.....................................................83
5.5.2 mcRNC units................................................................................ 84
5.5.2.1 CFPU........................................................................................... 84
5.5.2.2 CSPU........................................................................................... 85
5.5.2.3 EIPU............................................................................................. 86
5.5.2.4 USPU........................................................................................... 87
5.6 RNC capacity usage forecasting..................................................88
5.6.1 Calculation of the controller fill ratio (CFR).................................. 89
5.6.2 Estimation of the date when internal resources might become
limiting - quick estimation............................................................. 89
5.6.3 Estimation of the date when the internal resources might become
limiting - standard trend follow-up................................................ 89
5.6.4 KPIs relevant for controller capacity upgrade planning................90
   
6 IP transport interface capacity......................................................92
6.1 Ethernet interface.........................................................................93
6.2 IP-based route..............................................................................95
6.2.1 IP-based route: IFC enabled........................................................ 96
6.2.2 IP-based route: IFC disabled....................................................... 98
6.2.3 IP-based route: CAC-controlled traffic........................................100
   
7 ATM transport interface capacity................................................104
7.1 ATM interface............................................................................. 107

4 DN0972569 Issue: 06
Managing WCDMA RAN Capacity

7.2 ATM virtual path......................................................................... 108


7.3 ATM virtual channel.................................................................... 110
7.3.1 ATM virtual channel - CBR......................................................... 110
7.3.2 ATM virtual channel - UBR/UBR+.............................................. 112
7.4 VCC bundle................................................................................ 115

Issue: 06 DN0972569 5
Managing WCDMA RAN Capacity

List of Figures
Figure 1 The principle of proactive capacity management............................... 10
Figure 2 The principle of reactive capacity management................................. 11
Figure 3 3G RAN capacity model..................................................................... 14
Figure 4 Simplified Capacity Management Process......................................... 16
Figure 5 Access network capacity and stability................................................ 17
Figure 6 Radio interface................................................................................... 26
Figure 7 Common channels mapped to one SCCPCH.................................... 30
Figure 8 Common channels mapped to two SCCPCHs................................... 31
Figure 9 BTS capacity...................................................................................... 35
Figure 10 No BTS baseband pooling in use....................................................... 36
Figure 11 BTS baseband pooling in use.............................................................36
Figure 12 Non-overlapping baseband resources................................................40
Figure 13 Overlapping baseband capacity and static resources reservation..... 40
Figure 14 RNC capacity......................................................................................61
Figure 15 RNC2600 architecture........................................................................ 69
Figure 16 DMCU HW Architecture......................................................................75
Figure 17 mcRNC architecture........................................................................... 81
Figure 18 mcRNC unit architecture.................................................................... 82
Figure 19 mcRNC HW and SW components......................................................83
Figure 20 IP interface capacity bottlenecks........................................................ 92
Figure 21 IP transport interface.......................................................................... 93
Figure 22 Ethernet interface monitoring............................................................. 93
Figure 23 IP resource overbooking.....................................................................94
Figure 24 IP route monitoring: IFC enabled........................................................96
Figure 25 IP route monitoring - traffic limited by feature RAN1110: HSPA
Congestion Control.............................................................................98
Figure 26 Example for IP CAC monitoring for an IP-based route where IFC is
also enabled..................................................................................... 101
Figure 27 IP CAC: committed traffic blocking................................................... 101
Figure 28 ATM interface capacity bottlenecks.................................................. 104
Figure 29 Monitoring principle of ATM bottlenecks........................................... 106
Figure 30 ATM transport interface: identified monitoring cases........................107
Figure 31 VCC bundle - UBR + VCCs bandwidth.............................................115

6 DN0972569 Issue: 06
Managing WCDMA RAN Capacity

List of Tables
Table 1 Template of the monitored capacity item............................................ 14
Table 2 Network voice capacity - user plane...................................................17
Table 3 Network voice capacity - control plane............................................... 18
Table 4 Access network stability..................................................................... 22
Table 5 Transmitted total carrier power........................................................... 26
Table 6 Received total wideband power..........................................................28
Table 7 Common channel capacity................................................................. 31
Table 8 Channelization code tree....................................................................32
Table 9 FSMC/D/E and FSMF logical configurations...................................... 36
Table 10 FSMC/D/E BTS baseband configurations.......................................... 37
Table 11 FSMF BTS baseband configurations..................................................37
Table 12 FSMF baseband capacity...................................................................41
Table 13 FSMC/D/E baseband capacity........................................................... 41
Table 14 BTS-level issues.................................................................................41
Table 15 LCG-level issues................................................................................ 42
Table 16 WCEL-level issues............................................................................. 44
Table 17 Reactive monitoring............................................................................45
Table 18 Analyzes, overload, and upgrades..................................................... 45
Table 19 BTS control plane capacity.................................................................47
Table 20 FSMC/D/E and FSMF throughput capacity........................................ 50
Table 21 FSMC/D/E and FSMF user capacity.................................................. 50
Table 22 BTS-level issues.................................................................................51
Table 23 LCG-level issues................................................................................ 53
Table 24 Scheduler-level issues........................................................................54
Table 25 WCEL-level issues............................................................................. 55
Table 26 Reactive monitoring ...........................................................................56
Table 27 Analyzes, overload, and upgrades..................................................... 57
Table 28 RNC control plane load index.............................................................61
Table 29 Voice capacity.....................................................................................62
Table 30 Data capacity......................................................................................64
Table 31 RNC user plane fill factor....................................................................65
Table 32 Number of RNC connected subscribers............................................. 66
Table 33 IPA-RNC and mcRNC connectivity.....................................................67
Table 34 DMCU fill factor.................................................................................. 69
Table 35 Supported unit types in IPA-RNC....................................................... 70
Table 36 RNC ICSU capacity............................................................................ 71
Table 37 RNC RSMU capacity.......................................................................... 72
Table 38 RNC OMU capacity............................................................................ 73

Issue: 06 DN0972569 7
Managing WCDMA RAN Capacity

Table 39 RNC DMPG capacity..........................................................................75
Table 40 RNC DSP load....................................................................................76
Table 41 RNC MXU capacity.............................................................................77
Table 42 RNC NPS1 capacity........................................................................... 78
Table 43 RNC NPGE capacity.......................................................................... 79
Table 44 mcRNC DSP capacity........................................................................ 84
Table 45 CFPU load.......................................................................................... 84
Table 46 CSPU load..........................................................................................85
Table 47 EIPU load........................................................................................... 86
Table 48 USPU load..........................................................................................87
Table 49 Common KPIs for capacity licenses................................................... 90
Table 50 KPIs for cRNC.................................................................................... 90
Table 51 KPIs for mcRNC................................................................................. 90
Table 52 Ethernet bandwidth capacity.............................................................. 94
Table 53 IP route bandwidth: IFC enabled........................................................ 96
Table 54 IP route bandwidth: IFC disabled....................................................... 98
Table 55 Committed bandwidth.......................................................................102
Table 56 Utilization of ATM interface............................................................... 108
Table 57 Utilization of ATM virtual path........................................................... 108
Table 58 Utilization of ATM virtual channel (CBR)...........................................110
Table 59 Utilization of ATM virtual channel (UBR/UBR+)................................ 112
Table 60 Utilization of ATM VCC bundle..........................................................115

8 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Summary of changes

Summary of changes
Changes between document issues are cumulative. Therefore, the latest document
issue contains all changes made to previous issues.

Changes between issues 05A (2015-09-29, WCDMA 16) and 06 (2016-04-27,


WCDMA 17)
Table 27 Analyzes, overload, and upgrades has been updated. Added RAN3259: 2 ms
TTI non-FDPCH users increase feature in upgrade section.
Changes between issues 05 (2015-08-03, WCDMA 16) and 05A (2015-09-29,
WCDMA 16)
Chapter 4 Multiradio Flexi BTS WCDMA capacity has been updated. Notes are added
under HSPA and HSUPA/R99 CE in Commissioning of BTS resources.
Changes between issues 04C (2015-05-15, RU50) and 05 (2015-08-03, WCDMA 16)
Flexi Direct contents have been removed.
Chapter 4.3 BTS user plane capacity has been updated.
• changed the number of HSUPA users in Table 21: FSMC/D/E and FSMF user
capacity
• added RAN1913: High Speed Cell_FACH  feature in

Chapter 6.2.2 IP-based route: IFC disabled has been updated.
• removed counter M5000C179
• added counter M5000C453

Chapter 5.5.2 mcRNC units has been updated.
Updated tables:
• Table 45: CFPU load
• Table 46: CSPU load
• Table 47: EIPU load
• Table 48: USPU load

Issue: 06 DN0972569 9
   

Introduction to capacity management Managing WCDMA RAN Capacity

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
Traffic
Capacityutilization
Trendline
Traffic

100%
Utilization

Time
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.

10 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Introduction to capacity management

Figure 2 The principle of reactive capacity management

Traffic
Capacityutilization
ReactiveKPI/Counter

ReactivKP/Counter
Traffic

100%

Time
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 Note: 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.

Issue: 06 DN0972569 11
   

Introduction to capacity management Managing WCDMA RAN Capacity

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:
1. Profile basic UE and smart UE produce CS voice and data load to the network,
whereas wireless DSL only produces data.
2. Profile smart UE is seen as the main control plane loader, whereas group wireless
DSL is seen as the main user plane loader.

g Note: 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:

12 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Introduction to capacity management

1. voice Capacity, that is monitored on BTS and RNC levels
• 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

Issue: 06 DN0972569 13
   

Introduction to capacity management Managing WCDMA RAN Capacity

– session success rates

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

AccessNetworkCapacity

Airinterface WBTS FlexiDirect RNC Interface

Connectivity Userplane Controlplane

Mnitoredcapacityitem 1

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

g
1. Monitored
Note: There are different KPI IDs in use for WCDMA RAN (RNC_xxxxy).
capacity item

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).

14 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Introduction to capacity management

Table 1 Template of the monitored capacity item (Cont.)
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):
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.

Issue: 06 DN0972569 15
   

Introduction to capacity management Managing WCDMA RAN Capacity

Figure 4 Simplified Capacity Management Process

SelectedcountersandKPIdataforeachmonitored
capacityitem

Trendanalysisanddrillingdownintocounter
andKPIdata

Thedatewhenthethresholdofeachmonitored
capacityitemisreachedforthefirsttime

Capacityexpansion,optimization,orreconfiguration

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.

16 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Access network capacity and stability

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

AccessNetworkCapacity AccessNetworkStability

Voice Data User Call Call Call


Capacity Capacity Capacity Attempts Accessibility Retainability

2.1 Generic access network capacity management


aspects
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

Issue: 06 DN0972569 17
   

Access network capacity and stability Managing WCDMA RAN Capacity

Table 2 Network voice capacity - user plane (Cont.)
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
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 31: RNC user plane fill factor.

6. Upgrade See Table 31: 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

18 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Access network capacity and stability

Table 3 Network voice capacity - control plane (Cont.)
RNC_1773a AMR Licensed 40% (together - The AMR simultaneous call distribution in the
Capacity with Licensed Capacity. It shows the percentage of
simultaneous RNC_1774a) AMR call distribution, between 80 and 90% of the
call distribution licensed capacity (occurrences compared to the
ratio 80-90% total amount of distribution load occurrences).
Licensed
AMR Capacity
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).

3. Reactive Counter/KPI Name, unit Description


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 31: RNC user plane fill factor.

Issue: 06 DN0972569 19
   

Access network capacity and stability Managing WCDMA RAN Capacity

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).
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

20 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Access network capacity and stability

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.

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: 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.

Issue: 06 DN0972569 21
   

Access network capacity and stability Managing WCDMA RAN Capacity

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  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  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. Access
Monitore network
d stability
capacity
The
item
following
Access
Network
stability
KPIs
should
always be
monitored
along with
the
selected
capacity
KPIs.

2. Counter/K Name, Target Red flag Description


Proactive PI unit
monitorin
g

- - - - - -

3. Counter/K Name, Description


Reactive PI unit
monitorin
g

Service RNC_229 RAB The number of


or a attempts RAB setup
session voice attempts
attempts requested for
CS
conversational

22 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Access network capacity and stability

Table 4 Access network stability (Cont.)

calls with RAB
QoS parameter
‘source
descriptor’ =
Speech

RNC_617 RAB The number of


a attempts RAB setup
streamin attempts
g requested for
streaming calls.

RNC_616 RAB The number of


a attempts RAB setup
PS attempts
interactiv requested for
e and PS interactive
backgro or background
und calls. This
counter update
is depending on
the profile
setting in the
registry.

RNC_930 Packet Packet session


b session setup attempts
attempts over the
reporting
period.

RNC_545 HS- HS-FACH


6a FACH session
session attempts
attempts

Service RNC_565 Voice AMR call setup


or f call success ratio
session setup [%] over the
accessibil success reporting
ity ratio period.
(CSSR)
[%]

RNC_576 Packet Packet service


e service setup success
setup ratio [%] over
success the reporting
ratio period.
(CSSR)
[%]

Issue: 06 DN0972569 23
   

Access network capacity and stability Managing WCDMA RAN Capacity

Table 4 Access network stability (Cont.)

RNC_916 Packet Packet session


b session setup success
setup ratio [%] over
success the reporting
ratio period.
(SSSR)
[%]

RNC_545 Switche The success


9a d to ratio of
enhance transitions from
d HS- CELL_DCH or
FACH CELL_PCH to
success Enhanced HS-
ratio [%] FACH.

Service RNC_231 RAB RAB success


or d success ratio of AMR
session ratio, voice [%] over
retainabili voice the reporting
ty (CSR) period. Covers
the RAB active
phase of a call.

RNC_736 RAB RAB success


b success ratio for NRT
ratio, services [%]
NRT from user
services perspective
over the
reporting
period. Covers
the RAB active
phase of a call.

RNC_922 Packet The packet


b session session
success success ratio
ratio for streaming,
interactive and
background
services.

RNC_547 Switches The success


6a from ratio of
enhance transitions from
d HS- enhanced HS-
FACH FACH to
success CELL_DCH or
ratio [%] CELL_PCH.

4. In cases
Analysis of
degraded

24 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Access network capacity and stability

Table 4 Access network stability (Cont.)

accessibil
ity or
retainabili
ty, 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. In case of
Overload overload,
the
success
rate
rapidly
decrease
s.

6. The
Upgrade possible
upgrade
need is
related to
the
monitored
capacity
case.

Issue: 06 DN0972569 25
   

Radio interface capacity Managing WCDMA RAN 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

Radiointerface

Downlink Uplink Common Channelization


power interference channels codetree

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.

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


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
to power value depends on the
share DL [%]
PRACHDelayRange WCEL parameter settings.

3. Reactive Counter/KPI Name, unit Description


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
Share DL [%] PRACHDelayRange WCEL parameter settings.

RNC_964a RRC setup FR due to
RRC setup failure ratio caused by Admission Control.
AC [%]

26 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Radio interface 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
perspective. The active time refers to the scheduled TTIs, that is,
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.
[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
[#] 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.

Issue: 06 DN0972569 27
   

Radio interface capacity Managing WCDMA RAN Capacity

Table 5 Transmitted total carrier power (Cont.)
4. RB releases and downgrades
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.

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


monitoring flag

RNC_5203b Share of time when the received total
Percentage of RTWP in wideband power is in classes 13-16. The KPI
10% -
marginal area [%] is based on the M1000C320-41 counters.
The total uplink power (RTWP) measurement

28 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Radio interface capacity

Table 6 Received total wideband power (Cont.)
report samples the power values that are
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.

RNC_972a AMR service reject rate UL The number of voice call requests that have been rejected on


[%] the UL.

RNC_974a CS data service reject rate The number of video call requests that have been rejected on


UL [%] the UL.

RNC_976a PS data service reject rate The number of PS data call requests that have been rejected


UL [%] on the UL.

RNC_661d HSDPA access failure rate HSDPA access failure rate because of the associated UL


due to UL DCH [%] DCH.

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.

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 -

Issue: 06 DN0972569 29
   

Radio interface capacity Managing WCDMA RAN Capacity

3.3 Common channel capacity


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.).

30 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Radio interface capacity

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.

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


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
[%] 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 [%]
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 [%]
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 [%]
corresponding transport channel maximum bit rate to
get the load ratio).

Issue: 06 DN0972569 31
   

Radio interface capacity Managing WCDMA RAN Capacity

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 [%]
the corresponding transport channel maximum bit rate
to get the load ratio).

3. Reactive Counter/KPI Name, unit Description


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.

32 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Radio interface capacity

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.

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


monitoring flag

RNC_113a Average code tree The average code tree


70% 80
occupancy [%] occupancy.

RNC_519b Min code tree occupancy The minimum code tree


- -
[%] occupancy.

RNC_520b Max code tree occupancy The maximum code tree


80% 90
[%] occupancy.

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,
where the code tree situation of
a cell is measured.

3. Reactive Counter/KPI Name, unit Description


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 [#]

M1000C153 RB DOWNGRADE BY The number of RB downgrades by pre-emption


PREEMPTION DUE TO because of spreading code congestion.
SPREADING CODE
CONGESTION [#]

Issue: 06 DN0972569 33
   

Radio interface capacity Managing WCDMA RAN Capacity

Table 8 Channelization code tree (Cont.)
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.

34 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Multiradio Flexi BTS WCDMA capacity

4 Multiradio Flexi BTS WCDMA capacity


Figure 9: BTS capacity shows the bottlenecks in the BTS capacity which are the
baseband, control plane, and user plane.

Figure 9 BTS capacity

BTS capacity

Baseband Control plane User plane

NBAP Throughput
R99 CEs SUs Users
message load

To monitor the Flexi BTS capacity issues in Figure 9: BTS capacity, it is important to
know the following:
• used configurations
– logical configurations, for example, whether there is one or multiple local cell
groups in use
– baseband configurations, for example, whether there are one or two system
modules in use

• commissioning of available resources
– reservation order of resources that are commissioned
– relationship to licensed resources

• licensing of available resources

g Note: For more details on BTS configurations including HW FSMB System Module,
see the RU30 baseband dimensioning guidelines.

Used configurations
The following are the visibility in capacity monitoring:
• The different logical configuration levels, that is, the BTS -> LCG -> WCEL are used
in the capacity monitoring cases.
• From capacity point of view, the one LCG (Figure 10: No BTS baseband pooling in
use) vs. multi-LCG (Figure 11: BTS baseband pooling in use) is important.

Issue: 06 DN0972569 35
   

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN Capacity

Figure 10 No BTS baseband pooling in use
No baseband
pooling, that is, all
Cell 3 cells in one
Cell 2 LCG
Cell 4
Cell 5
Cell 1 Example: M5008 counters are reported in a BTS level,
Cell 6 and M5006 counters on a LCG level. The whole
Rel99 CE license and HSxPA processing set
Cell 12 Cell 7 capacities commissioned is available for this
Cell 8 single LCG, which consumes the whole BTS capacity.
Cell 11 LCG 1
Cell 10 Cell 9

Figure 11 BTS baseband pooling in use

Baseband
pools

Cell 7
Cell 9 Cell 10
Cell 8 Cell 12
LCG 4 Example: M5008 counters are reported in
Cell 11 a BTS level, while M5006 counters on a LCG level.
LCG 3
Check the commissioning configuration
to find out the share of Rel99 CE and HSxPA
processing set licenses available per LCGs,
and the total licensed capacity of the whole BTS.
Cell 1
Cell 3
Cell 4 Cell 2
LCG 1
Cell 6
Cell 5
LCG 2

Used logical configurations

Table 9 FSMC/D/E and FSMF logical configurations

FSMC/D/E (rel2) and FSMF (rel3) logical configurations

Logical entity BTS level LCG level Cell level

Logical cell group max 4 - -

Cell 1 FSM: max 12 -


• FSMC: 3
• FSMD: 6
• FSME: 9
• FSMF: 6
• FSMF +
1*FBBA: 12
• FSMF +
2*FBBA: 18

Two FSM *):
• FSMC+FSMD: 9

36 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Multiradio Flexi BTS WCDMA capacity

Table 9 FSMC/D/E and FSMF logical configurations (Cont.)

FSMC/D/E (rel2) and FSMF (rel3) logical configurations

Logical entity BTS level LCG level Cell level

• FSMD+FSMD:
12
• FSME+FSMD:
15
• FSME+ FSME:
18

*) Only the most common FSM combinations given here.
Used baseband configurations

Table 10 FSMC/D/E BTS baseband configurations

FSMC/D/E (rel2) BTS baseband configurations *

Baseband per BTS per LCG per SM


entity

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


(SM) LCGs
two SM/BTS: sharing is based
on cells mapped to SMs

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 2 max 4


scheduler(s) LCG number

Table 11 FSMF BTS baseband configurations

FSMF (rel3) BTS baseband configurations *

Baseband per BTS per LCG per SM


entity

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


(SM) LCGs

Issue: 06 DN0972569 37
   

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN Capacity

Table 11 FSMF BTS baseband configurations (Cont.)

FSMF (rel3) BTS baseband configurations *

Baseband per BTS per LCG per SM


entity

two SM/BTS: sharing is based
on cells mapped to SMs
Fixed/sector BB pooling: 1
Flexible BB pooling: Shared
between LCGs based on
parameter
accessBBCapacity.

HSDPA based on max 2 max 8


scheduler(s) LCG number

HSUPA based on max 1 max 4


scheduler(s) LCG number

g Note: The number of activated HSDPA schedulers depends onTcell configuration; see
Dimensioning WCDMA RAN: Flexi BTS Baseband.

Commissioning of BTS resources


The visibilty in capacity monitoring: The commissioned resources, that is the users and
throughput are monitored.
The HW resources to be allocated are commissioned in the following order:
1. HSDPA

38 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Multiradio Flexi BTS WCDMA capacity

2. CCCH
3. HSUPA/R99 CE

HSDPA

g Note: The HS-FACH users are counted as part of the HSDPA users from the HSDPA
resource utilization point of view.

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
The parameter limits 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.

CCCH
In FSMF, additional CCCH resources (not included into FSM price) does not consume
Rel99 CE license but CCCH PS licenses.
HSUPA/R99 CE

g Note: The HS-RACH baseband resource consumption is accounted in the HSUPA
processing set capacity license.

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 12: Non-
overlapping baseband resources)
– Overlapping resources between HSPUA and R99 (see Figure 13: 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: 06 DN0972569 39
   

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN Capacity

Figure 12 Non-overlapping baseband resources

Licensenon-overlappingcase

OneHSUPA BTSProcessingSet
(equivalentof48R99CE)isalways
availableforR99usersandHSUPA users*
SystemModule

*Note:48CEineach
LCGisalwaysdynamic
HSUPA HSDPA (evenwithoutlicense
R99CElicenses processingsets commissioned overlapping).
throughput

Basebandresources Free(unlicensed)baseband
availableforR99users resources-notavailablefor
R99usersandHSDPA
datausers

Figure 13 Overlapping baseband capacity and static resources reservation

OneHSUPA BTSProcessingSet
Overlappingscenario (equivalentof48R99CE)isalways
availableforR99usersandHSUPA users*

SystemModule

HSDPA
R99CElicenses HSUPA BTS commissioned
processingsets throughput

Rel99users
Rel99users Basebandresources
HSUPA users availableforR99users only!

HSUPA BTS Overlappingbasebandcapacity


48CE
(dynamic) Processingsets canbedynamicallyshared
betweenHSUPA andR99users*

*R99usersalwayshavehigherpriority
ForoverlappingRel99CElicensesandlicensedHSUPA resources,commissioningcanbe
performedinordertoguaranteeresourcesforHSUPA.
From0to48HSUPA resourcestepscanbestaticallycommissionedwith
numOfHsupaResourceStepsRes (LCELGW)parameter.

40 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Multiradio Flexi BTS WCDMA capacity

4.1 BTS baseband capacity monitoring


The available baseband capacity depends on the number of system modules (SM) and
their types.
The Table 12: FSMF baseband capacity and Table 13: FSMC/D/E baseband capacity
indicate the current capacity of the available SMs.

Table 12 FSMF baseband capacity

Baseband capacity - FSMF (rel3)

System module type F

Subunits FSMF (no extension): 5.5 subunit
FSMF + 1xFBBA: 11.5 subunit
FSMF + 2xFBBA: 17.5 subunit

g Note: Subunits on FSM-rel3 and FSM-rel2 have different resource capacity. Therefore,
any concrete SU value is not given for FSMF + FSME configuration.

Table 13 FSMC/D/E baseband capacity

Baseband capacity - FSMC/D/E (rel3)

System module type C D E

Subunits 5 12 19

4.1.1 BTS level

Table 14 BTS-level issues
Monitored Monitored capacity item description
capacity
item
R99 CE The WBTS level monitoring measurement (M5008) measures R99 CE utilization
utilization on the WBTS level. (Available since RU50 EP1)
Subunit The WBTS level monitoring measurement (M5008) measures SU utilization on
utilization the WBTS level.
Proactive Counter/KPI Name, Unit Target Red flag Description
monitoring

Issue: 06 DN0972569 41
   

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN Capacity

Table 14 BTS-level issues (Cont.)
Monitored Monitored capacity item description
capacity
item
R99 CE RNC_5483a Average R99 70% 80% The average R99 CE
utilization - CE utilization usage DL.
DL in DL per BTS
[%]
R99 CE RNC_5484a Average R99 70% 80% The average R99 CE
utilization - CE utilization usage DL.
UL in UL per BTS
[%]
Subunit RNC_5410a Average SUs 70% 80% This KPI shows the
utilization utilization per average BB SUs
BTS [%] *) utilization ratio as a
relation of the
maximum number of
used subunits to the
total SUs in the
baseband.
RNC_5409a Maximum SUs - 100% This KPI shows the
utilization per maximum BB SUs
BTS [%] *) utilization ratio as a
relation of the
maximum number of
used subunits to the
total SUs in the
baseband.

4.1.2 LCG level

Table 15 LCG-level issues
Monitored Monitored capacity item description
capacity
item
R99 CE The WBTS R99 resource (M5006) measurement measures R99 CE utilization on
utilization the LCG level.
SU utilization The WBTS R99 HW resource (M5006) measurement measures SU utilization on
LCG level.
Proactive Counter/KPI Name, Target Red Description
monitoring unit flag
R99 CE RNC_2256a UL CE 3% 5% The UL CE R99 Utilization
utilization - R99 Distribution Rate - (80 - <90)%,
UL utilization provides information about the
distributio percentage of measured events, for
n rate - uplink traffic, which indicate that
(80 - <90) channel elements (CE) usage ratio
[%] was between 80 and 90% of existing
resources.

42 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Multiradio Flexi BTS WCDMA capacity

Table 15 LCG-level issues (Cont.)
Monitored Monitored capacity item description
capacity
item
RNC_2257a UL CE 1% 2% The UL CE R99 Utilization
R99 Distribution Rate - (90 - <100)%,
utilization provides information about the
distributio percentage of measured events, for
n rate - uplink traffic, which indicate that
(90 - channel elements (CE) usage ratio
<100) [%] was between 90 and 100% of
existing resources.
RNC_2258a UL CE 0% 1% The UL CE R99 Utilization
R99 Distribution Rate - (100 or more)%,
utilization provides information about the
distributio percentage of measured events, for
n rate - uplink traffic, which indicate that
(100% or channel elements (CE) usage ratio
more) per was between 100% or more of
LCG [%] existing resources.
R99 CE RNC_2262a DL CE 3% 5% The DL CE R99 Utilization
utilization - R99 Distribution Rate - (80 - <90)%,
DL utilization provides information about the
distributio percentage of measured events, for
n rate - Uplink traffic, which indicate that
(80 - <90) Channel Elements usage ratio was
[%] between 80 and 90% of existing
resources.
RNC_2263a DL CE 1% 2% The DL CE R99 Utilization
R99 Distribution Rate - (90 - <100)%,
utilization provides information about the
distributio percentage of measured events, for
n rate - uplink traffic, which indicate that
(90 - channel elements (CE) usage ratio
<100) [%] was between 90 and 100% of
existing resources.
RNC_2264a DL CE 0% 1% The DL CE R99 Utilization
R99 Distribution Rate - (100 or more)%,
utilization provides information about the
distributio percentage of measured events, for
n rate - uplink traffic, which indicate that
(100% or channel elements (CE) usage ratio
more) per was between 100% or more of
LCG [%] existing resources.
SU utilization RNC_5511a Average 70% 80% The average SUs utilization per
SUs LCG.
utilization
per LCG
[%]

Issue: 06 DN0972569 43
   

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN Capacity

Table 15 LCG-level issues (Cont.)
Monitored Monitored capacity item description
capacity
item

RNC_5512a Maximum - 100% The maximum SUs utilization per


SUs LCG.
utilization
per LCG
[%]
RNC_5513a Average 70% 80% The average HSUPA SUs utilization
HSUPA per LCG.
SUs
utilization
per LCG
[%]
RNC_5514a Maximum - 100% The maximum HSUPA SUs
HSUPA utilization per LCG.
SUs
utilization
per LCG
[%]

4.1.3 WCEL level

Table 16 WCEL-level issues
Monitored Monitored capacity item description
capacity
item
HSUPA HW - The cell resource (M1000) measurement measures different HSUPA HW
limited limitations on the WCEL level.
durations
HSxPA setup The traffic (M1002) measurement measures different HSxPA failure reasons on
failures the WCEL level.
Proactive Counter/KPI Name, unit Target Red Description
monitoring flag
HSUPA HW - M1000C269 BTS HSUPA 180s - This counter indicates the
limited HW limited amount of time the BTS local cell
durations duration [s] group HW pool (where this cell
belongs to) is in the HSUPA HW
limited state during the
measurement period. In this
state, the RNC sets up the E-
DCH but the BTS HW shortage
may cause the throughput to be
lower than expected.

44 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Multiradio Flexi BTS WCDMA capacity

4.1.4 Reactive monitoring


Reactive monitoring

Table 17 Reactive monitoring
Reactive Counter/KPI Name, unit Description
monitoring
HSUPA HW - M1000C270 BTS HSUPA This counter indicates the amount of time
limited durations HW no capacity the BTS local cell group HW pool (where
duration [s] this cell belongs to) is in the HSUPA HW
limited state during the measurement
period. In this state, the RNC does not set
up the E-DCH.
HSxPA setup RNC_957d E-DCH Not The percentage of occurrences when E-
failures - due to Selected due to DCH uplink transport channel cannot be
resource shortage BTS HW [%] selected in this cell for interactive,
background, and streaming class
connections because BTS has reported
to have no capacity available for E-DCH.
HSxPA setup RNC_673d HSDPA Access The HSDPA access failure rate due to
failures – due to failure rate due BTS originated reason.
BTS internal to BTS [%]
reasons
RNC_1726a Streaming The HSDPA setup failure ratio due to BTS
HSDPA Setup failures, for streaming traffic class.
failure rate due
to BTS [%]
RNC_956d E-DCH Setup The percentage of E-DCH setup failures
FR due to BTS due to BTS for interactive, background
[%] and streaming class connections.

g Note: All reactive monitoring is related to WCEL-level issues.

4.1.5 Analyzes, overload, and upgrades

Table 18 Analyzes, overload, and upgrades
Analyzes BTS level/One LCG (Baseband pooling not in use):

1. R99 CE utilization
Follow the total CE utilization in the uplink and downlink using the
following KPIs:
• UL: RNC_5484a
• DL: RNC_5483a

2. Subunit utilization
Follow the average/maximum SU utilization using the following
KPIs:

Issue: 06 DN0972569 45
   

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN Capacity

Table 18 Analyzes, overload, and upgrades (Cont.)
• Average: RNC_5410a
• Maximum: RNC_5409a

More than one LCG (Baseband pooling in use):

1. R99 utilization
Follow the total CE utilization in the uplink and downlink using the
following KPIs:
• UL: RNC_2256a, RNC_2257a, RNC_2258a
• DL: RNC_2262a, RNC_2263a, RNC_2264a

2. Subunit utilization
Follow the average/maximum SU utilization using the following
KPIs:
• Average: RNC_5511a
• Maximum: RNC_5512a

g Note: The sampling interval (5 seconds) used in the
utilization KPIs might not capture the sharp load peaks.

HSUPA Baseband shortage


The counter M1000C270 gives the duration of HSUPA baseband
capacity shortage during a measurement period.
HSDPA and HSUPA setup failures (cell level)
• Use the RNC_957d to check if HSUPA BB capacity or HSUPA
Processing Set capacity has exceeded the capacity limit.
• Use the KPIs RNC_673d and RNC_1726a to check whether there
are problems in setting of the HSDPA connections between BTS
and RNC. Please note that a possible problem is not necessarily
related to Baseband capacity issues.
• Use the RNC_956d to check whether there are problems in setting
of the HSUPA connections between BTS and RNC. Please note
that a possible problem is not necessarily related to Baseband
capacity issues.

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. Overload
instructions are found in BTS user plane capacity.

Upgrade Possible upgrade actions: R99 CE upgrade need

1. Increase the R99 CE and/or HSDPA/HSUPA processing set
licenses if it is allowed by the installed HW.
2. Expand the capacity by installing an extension system module
and/or an extension card in the Flexi BTS.
3. In the case of no license and HW limitations, follow the steps found
in BTS user plane capacity.

46 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Multiradio Flexi BTS WCDMA 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
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 Note: The signaling capacity of 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 measured field experience from smart
phone dominant environment as explained in the analyses part of
Table 19: BTS control plane capacity.

Table 19 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.

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


monitoring flag

Radio Link M5004C1 Peak RL 56 RL/s (2 - Peak radio link setup messages that are


setups per FSME) handled per second, where the handled
Capacity -
second [#] setups are those that have not been rejected
Attempts 22 RL/s (1
because of congestion.
FSMD)
70 RL/s
(FSMF +
g Note: Targets are based on dominant
Smartphone profiles.
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]

3. Reactive Counter/KPI Name, unit Description


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 [#]

Issue: 06 DN0972569 47
   

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN Capacity

Table 19 BTS control plane capacity (Cont.)
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 [#]

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. For details on the maximum values of each
BTS variant, see the WBTS product documentation.
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 use 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 Note: 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.

48 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Multiradio Flexi BTS WCDMA capacity

Table 19 BTS control plane capacity (Cont.)
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.
• 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.
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
Table 20: FSMC/D/E and FSMF throughput capacity lists the total throughput capacity of
the BTS, which depends on the number of HSPA schedulers and the number of subunits
in the system module(s).

Issue: 06 DN0972569 49
   

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN Capacity

Table 20 FSMC/D/E and FSMF throughput capacity

Throughput capacity - FSMC/D/E (rel2) and FSMF (rel3)

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

Table 20: FSMC/D/E and FSMF throughput capacity 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.

g Note: For HW rel2, one system module (SM) can have a maximum of two HSDPA
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
The total user 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. The
BTS-specific capacity does not represent the sum of the cells. The REL99 does not have
any connectivity limits at the BTS, hence radio interface or CE capacity limits the number
of REL99 users.

Table 21 FSMC/D/E and FSMF user capacity

User capacity - FSMC/D/E (rel2) and FSMF (rel3)

User type Set by Max capacity Level

HSDPA users HSDPA scheduler 240 users *) HSDPA scheduler

HSUPA users HSUPA scheduler 320 HSUPA scheduler

HSUPA users HSUPA scheduler 128 users Cell

*) 480 per LCG is only possible if there is exactly one LCG x 2 x FSMr2 and cell to FSM
mapping is used (2 schedulers in one LCG).

50 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Multiradio Flexi BTS WCDMA capacity

The maximum number of HSDPA users also depends on the activated features, and the
number/type of HSDPA processing sets. Note that in HW rel2, 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.
For HW rel2, one system module can have a maximum of two schedulers shared by all
LCGs and one scheduler serves a maximum of six 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.
The maximum number of HSUPA users also depends on the activated features, and the
number/type of HSUPA processing sets.
There is a MaxNumberHSDPAUsers parameter, which might also limit some other
numbers on the cell level.

g Note: In RNC, there is a parameter MaxNumberEDCHLCG that needs to be set
according to the HSUPA scheduler limitation 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 a 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 by the BTS
to the cell. 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.

4.3.1 BTS level

Table 22 BTS-level issues
Monitored Monitored capacity item description
capacity
item
HSxPA The WBTS level monitoring (M5008) measurement measures HSxPA throughput
throughput capacity on the WBTS level.
capacity
Number of The WBTS level monitoring (M5008) measurement measures the
HSxPA users number/commissioned number of HSxPA users on the WBTS level.

Issue: 06 DN0972569 51
   

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN Capacity

Table 22 BTS-level issues (Cont.)
Monitored Monitored capacity item description
capacity
item
Proactive Counter/KPI Name, Target Red Description
monitoring unit flag
RNC_5556a Average 70% 80% The average HSDPA throughput
HSDPA utilization ratio per BTS taking
throughpu configured in denominator.
t
utilization
per BTS
HSxPA [%]
throughput
utilization RNC_5558a Average 70% 80% The average HSUPA throughput
HSUPA utilization ratio per BTS taking
throughpu configured in denominator.
t
utilization
per BTS
[%]
RNC_5554a Average 70% 80% The average number of HSDPA
HSDPA users' utilization ratio per BTS taking
user configured in denominator.
number
utilization
per BTS
[%]
RNC_5550a Maximum - 100% The maximum number of HSDPA
HSDPA users’ utilization ratio per BTS taking
user configured in denominator.
number
utilization
per BTS
Number of [%]
HSxPA users RNC_5555a Average 70% 80% The average number of HSUPA
HSUPA users’ utilization ratio per BTS taking
user configured in denominator.
number
utilization
per BTS
[%]
RNC_5551a Maximum - 100% The maximum number of HSUPA
HSUPA users’ utilization ratio per BTS taking
user configured in denominator.
number
utilization
per BTS
[%]

52 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Multiradio Flexi BTS WCDMA capacity

4.3.2 LCG level

Table 23 LCG-level issues
Monitored Monitored capacity item description
capacity
item
HSxPA The LCG level monitoring (M5006) measurement measures HSxPA throughput
throughput capacity on the LCG level.
capacity
Number of The LCG level monitoring (M5006) measurement measures the
HSxPA users number/commissioned number of HSxPA users on the LCG level.
Proactive Counter/KPI Name, Target Red Description
monitoring unit flag
RNC_5521a Average 70% 80% This KPI shows the average HSDPA
HSDPA throughput utilization per LCG.
Throughp
ut
utilization
per LCG
HSxPA [%]
throughput
utilization RNC_5523a Average 70% 80% This KPI shows the average HSUPA
HSUPA throughput utilization per LCG.
Throughp
ut
utilization
per LCG
[%]
RNC_5517a Average 70% 80% This KPI shows the average number
HSUPA of HSUPA users utilization per LCG.
user
number
utilization
per LCG
RNC_2268a HSPA UL 3% 5% The HSPA UL user utilization
user distribution rate - (80 - < 90) %,
utilization provides information about the
distributio percentage of measured events for
Number of n rate - HSPA uplink traffic, which indicate
HSxPA users (80 - <90) that channel elements (CE) usage
per LCG ratio was between 60 and 80% of
[%] the existing resources.
RNC_2269a HSPA UL 1% 2% The HSPA UL user utilization
user distribution rate - (90 - < 100)%
utilization provides information about the
distributio percentage of measured events for
n rate - HSPA uplink traffic, which indicate
(90 - that the channel elements (CE)
<100) per usage ratio was between 80 and
LCG [%] 100% of the existing resources.

Issue: 06 DN0972569 53
   

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN Capacity

Table 23 LCG-level issues (Cont.)
Monitored Monitored capacity item description
capacity
item
RNC_2270a HSPA UL 0% 1% The HSPA UL user utilization
user distribution rate - 100%, provides
utilization information about the percentage of
distributio measured events, for HSPA uplink
n rate - traffic, which indicate that channel
100% per elements (CE) usage ratio was
LCG 100% of existing resources.
RNC_5519a Average 70% 80% This KPI shows the average number
HSDPA of HSUPA users utilization per LCG.
user
number
utilization
per LCG
RNC_2274a HSPA DL 3% 5% The HSPA DL user utilization
user distribution rate - (80 - < 90)%,
utilization provides information about the
distributio percentage of measured events for
n rate - HSPA uplink traffic, which indicate
(80 - <90) that channel elements (CE) usage
per LCG ratio was between 60 and 80% of
[%] the existing resources.
RNC_2275a HSPA DL 1% 2% The HSPA DL user utilization
user distribution rate - (90 - < 100)%
utilization provides information about the
distributio percentage of measured events for
n rate - HSPA uplink traffic, which indicate
(90 - that the channel elements (CE)
<100) per usage ratio was between 80 and
LCG [%] 100% of the existing resources.
RNC_2276a HSPA DL 0% 1% The HSPA DL User utilization
User distribution rate - 100%, provides
Utilization information about the percentage of
Distributio measured events, for HSPA uplink
n Rate - traffic, which indicate that channel
100% per elements (CE) usage ratio was
LCG 100% of existing resources.

4.3.3 Scheduler level

Table 24 Scheduler-level issues
Monitored Monitored capacity item description
capacity
item
HSxPA The Scheduler Level Monitoring (M5011) measurement measures commissioned
throughput HSDPA throughput usage on the scheduler level.
capacity

54 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Multiradio Flexi BTS WCDMA capacity

Table 24 Scheduler-level issues (Cont.)
Monitored Monitored capacity item description
capacity
item
Proactive Counter/KPI Name, Target Red Description
Monitoring unit flag
RNC_5530a Average 70% 80% This KPI shows the average HSUPA
HSUPA throughput utilization per scheduler.
throughpu
t
utilization
per
schedule
HSDPA [%]
Throughput
utilization RNC_5526a Average 70% 80% This KPI shows the average HSUPA
HSDPA throughput utilization per scheduler.
throughpu
t
utilization
per
schedule
[%]
RNC_5524a Average 70% 80% This KPI shows the average HSDPA
HSDPA users utilization per scheduler.
users
utilization
per
scheduler
Number of [%]
HSxPA users RNC_5528a Average 70% 80% This KPI shows the average HSUPA
HSUPA users utilisation per scheduler.
users
utilization
per
scheduler
[%]

4.3.4 WCEL level


WCEL level

Table 25 WCEL-level issues
Monitored Monitored capacity item description
capacity
item
Number of The Cell Resource (M1000) measurement measures HSxPA user numbers on
HSxPA users the WCEL level.
HSxPA setup The Traffic (M1002) measurement measures different HSxPA failure reasons on
failure the WCEL level.

Issue: 06 DN0972569 55
   

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN Capacity

Table 25 WCEL-level issues (Cont.)
Monitored Monitored capacity item description
capacity
item
Cell The L3 Signaling at Iub (M1005) measurement measures different RL congestion
congestion reasons on the WCEL level.
due to BTS
Proactive Counter/KPI Name, Target Red Description
Monitoring unit flag
Number of RNC_645c Average 70% 80% This includes both single and dual
HSxPA users number of cell HSDPA users. The target value
simultane depends on the number of HSDPA
ous users enabled in the cell. Note that
HSDPA the target percentages should be
users per proportional to the maximum
cell [#] supported number of users.
RNC_1686a Maximum - 100% This includes both single and dual
number of cell HSDPA users. The target value
simultane depends on the number of HSDPA
ous users enabled in the cell. Note that
HSDPA the target percentages should be
users per proportional to the maximum
cell [#] supported number of users.
RNC_1036b Average 70% 80% The average number of
number of simultaneous HSUPA users in the
simultane target object.
ous
HSUPA
users per
cell [#]
RNC_1687a Maximum - 100% The maximum number of
number of simultaneous HSUPA users in the
simultane target object.
ous
HSUPA
users per
cell [#]

4.3.5 Reactive monitoring

Table 26 Reactive monitoring
Reactive monitoring Counter/KPI Name, unit Description
RNC_660d DCH selected The congestion because of too many
HSxPA setup failures - due to too Many allocated users - ratio of allocation
due to exceeded HSDPA users requests that are directed to DCH
number of users [%] (because of too many HSDPA users)
over all HSDPA allocations.

56 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Multiradio Flexi BTS WCDMA capacity

Table 26 Reactive monitoring  (Cont.)
Reactive monitoring Counter/KPI Name, unit Description
RNC_968c UL DCH The percentage of unavailable E-
selected due to DCH uplink transport channel for
too many interactive, background, and
HSUPA users streaming class connections
[%] because of maximum amount of E-
DCH users in the cell exceed the
limit defined by
MaxNuberEDCHCell or the number
of EDCH users in local cell group
exceed MaxNumberEDCHLCG.
M1005C179 RL SETUP FAIL The number of radio link setup
FOR FIRST RL failures for the first radio link due to
Cell Congestion due to
DUE TO MISC miscellaneous cause. The first link
BTS– dedicated
CAUSE can be established either in the RRC
device
connection setup or state transition
to CELL_DCH.
RNC_957d E-DCH Not The percentage of times when E-
Selected due to DCH uplink transport channel cannot
HSxPA setup failures - BTS HW [%] be selected in this cell for interactive,
due to resource background, and streaming class
shortage connections because BTS has
reported to have no capacity
available for E-DCH.
HSxPA setup failures RNC_673d HSDPA Access HSDPA access failure rate due to
– due to BTS internal failure rate due BTS originated reason.
reasons to BTS [%]
RNC_1726a Streaming HSDPA Setup Failure Ratio due to
HSDPA Setup BTS failures, for Streaming traffic
failure rate due class.
to BTS [%]
RNC_956d E-DCH Setup The percentage of E-DCH setup
FR due to BTS failures due to BTS for interactive,
[%] background and streaming class
connections.

g Note: All reactive monitoring is related to WCEL-level issues.

4.3.6 Analyzes, overload, and upgrades


Analzyes, overload, and upgrade

Table 27 Analyzes, overload, and upgrades
Analyzes 1. HSxPA throughput utilization - BTS, LCG and Scheduler Levels
The given KPIs show directly the throughput utilization rates for
each measured level.
2. HSxPA users per BTS and Scheduler

Issue: 06 DN0972569 57
   

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN Capacity

Table 27 Analyzes, overload, and upgrades (Cont.)
The given KPIs show directly the user resource utilization rates.
3. HSxPA users per LCG
Follow the total HSxPA user utilization in the uplink and downlink
using the following KPIs:
• UL: RNC_2268a, RNC_2269a, RNC_2270a or RNC_5519a
• DL: RNC_2274a, RNC_2275a, RNC_2276a or RNC_5517a

The sampling interval, five seconds, used in the utilization KPIs
might not capture the sharp load peaks.
4. HSxPA users per cell
Use the maximum number of simultaneous HSDPA/HSUPA users
per cell and the average number of simultaneous HSDPA/HSUPA
users per cell to see when the number of users is approaching the
limit in a cell.
The system updates all M1000 counters only for the primary cell.
The parameters define the maximum values for HSDPA users on
the BTS and cell level, therefore, the user can use the KPIs
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.

g Note: The dual cell HSDPA requires more resources
(approximately two-fold) compared to single cell users. For
the maximum HSUPA user amount per configuration, see the
BTS baseband dimensioning guideline.

5. HSDPA and HSUPA setup failures (cell level)
• Use the KPIs RNC_660d and RNC_968c to check whether new
HSxPA users are not allowed as the allowed user number is
exceeded.

g Note: The exceeded number of users means the cases
when BTS sees that there are more users than allowed
on Cell and/or LCG level based on parameterization.

• Use the RNC_957d to check if HSUPA BB capacity or HSUPA
Processing Set capacity has exceeded the capacity limit.
• Use the KPIs RNC_673d and RNC_1726a to check whether
there are problems in setting of the HSDPA connections
between BTS and RNC. Please note that a possible problem is
not necessarily related to Baseband capacity issues.
• Use the RNC_956d to check whether there are problems in
setting of the HSUPA connections between BTS and RNC.
Please note that a possible problem is not necessarily related to
Baseband capacity issues.

6. BTS congestion (cell level)
Use the RL setup failure counter to determine if there has a
significant number of RL rejections because of congestion in the cell
dedicated device 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 can mean any cause specified in NBAP specification
(TS 25.443). Nokia BTS uses unspecified cause to indicate RL

58 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity Multiradio Flexi BTS WCDMA capacity

Table 27 Analyzes, overload, and upgrades (Cont.)
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.

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 not
accepted anymore to 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.
4. A high signaling rejection rate occurs because of insufficient
channel elements or signaling, or because the base station could
not handle the signaling load. See BTS control plane capacity for
further analysis.

Upgrade HSPA throughput and/or user capacity improvement with


license/HW upgrade
In the case of license or HW upgrade need, follow the steps found in
Baseband capacity monitoring.
HSxPA user capacity improvement without license/HW upgrade

1. Activate the RAN1797: Common Channel Setup feature (see
Activating RAN1797: Common Channel Setup).
2. Activate RAN1201: Fractional DPCH (see Activating RAN1201:
Fractional DPCH), which improves the efficient use of HSDPA radio
resources.

Issue: 06 DN0972569 59
   

Multiradio Flexi BTS WCDMA capacity Managing WCDMA RAN Capacity

Table 27 Analyzes, overload, and upgrades (Cont.)

3. Activate RAN3259: 2 ms TTI non-FDPCH users increase feature
(see Activating RAN3259: 2 ms TTI non-FDPCH users increase),
which improves the user capacity of non-FDPCH users up to 40%
per subunit. This is applicable for both rel2 and rel3.
4. 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.

5. Activate RAN1637: High Speed Cell_FACH DL feature for low
capacity service needs, which saves processing set resources as
there are no additional reservations for DCH setups.

HSxPA throughput capacity improvement without license/HW


upgrade

1. Make sure that there are enough RNC licenses for the cell level
capacity.
2. Make sure that the HSDPA scheduler throughput parameter value is
not lower than the licensed value.
3. Reconfigure the TCELL (if possible) to completely utilize the
available HSDPA schedulers.
4. Add more LCGs if possible.

60 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

5 RNC capacity
This chapter covers IPA-RNC and mcRNC 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 RNCDMCU/


Carriers
Planning Capacity Capacity Capacity USPUFill UnitLoads
andsites
Factor

5.1 RNC control plane capacity


5.1.1 RNC control plane index
Table 28 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.

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


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).

3. Reactive Counter/KPI Name, unit Description


monitoring

- - -

4. Analyses See RNC Capacity Planning Proactive management / Controller Capacity Upgrade Planning

5. Overload See RNC Capacity Planning Proactive management / Controller Capacity Upgrade Planning

Issue: 06 DN0972569 61
   

RNC capacity Managing WCDMA RAN Capacity

Table 28 RNC control plane load index (Cont.)
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.
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.
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.

5.2.1 Voice capacity


Table 29 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.

62 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

Table 29 Voice capacity (Cont.)
2. Proactive Counter/KPI Name, unit Target Red Description
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).

3. Reactive Counter/KPI Name, unit Description


monitoring

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


failures due to which was exceeded for CS voice.
license for CS
Voice [#]
Licensed AMR
capacity 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.

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.

Issue: 06 DN0972569 63
   

RNC capacity Managing WCDMA RAN Capacity

5.2.2 Data capacity

Table 30 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).
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.

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


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).

RNC_5021b Iu-PS peak 90% - Iu-PS peak load in downlink direction


Hard data throughput
capacitz downlink [kbps]

3. Reactive Counter/KPI Name, unit Description


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

64 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

Table 30 Data capacity (Cont.)
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
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 (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.

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 (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 31 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. 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.

g Note: 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 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.

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


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

Issue: 06 DN0972569 65
   

RNC capacity Managing WCDMA RAN Capacity

Table 31 RNC user plane fill factor (Cont.)
stated RNC capacity. The formula
takes into account the measurement of
the soft handover at the Iub.

3. Reactive Counter/KPI Name, unit Description


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.

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 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.

5.2.4 RRC connected subscribers


Table 32 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.

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


monitoring flag

RRC RNC_2173a Maximum See RNC product - The peak number of RRC connected


connected number of descriptions mode users in the RNC (all states) during
mode users RRC the measurement period.
connected
mode users

3. Reactive Counter/KPI Name, unit Description


monitoring

- - -

66 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

Table 32 Number of RNC connected subscribers (Cont.)
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 (RNC2600 Product Description, mcRNC Product Description ). For example, it needs to be
inserted to the KPI formula based on the relevant RNC version.

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.

5.3 RNC connectivity


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 33 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 Note: 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.

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


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: 06 DN0972569 67
   

RNC capacity Managing WCDMA RAN Capacity

Table 33 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 - [#] RNC capacity license. within a given period are not accounted
carriers 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
Connectivity - Number of Iur
there must be load on the configured Iur
RNC interfaces per -
before it appears in the M1004
interfaces RNC
measurement.

3. Reactive Counter/KPI Name, unit Description


monitoring

g
The maximum capacity value of a critical feature has been reached. An
Note: This item is an
application process, which uses the licensed capacity type feature has
alarm.
observed that its capacity usage level has reached the maximum value as
defined by the associated license. As a result, the application process
3295 LICENCE CAPACITY raises this alarm. This alarm is an indication that operator should increase
EXCEEDED 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.

68 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

Figure 15 RNC2600 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 34 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.

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


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.

3. Reactive Counter/KPI Name, unit Description


monitoring
- - -

Issue: 06 DN0972569 69
   

RNC capacity Managing WCDMA RAN Capacity

Table 34 DMCU fill factor (Cont.)
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 Tip: 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 35: Supported unit types in IPA-RNC.

Table 35 Supported unit types in IPA-RNC

Unit Unit name RNC2600 Protection


type Scheme

A2SP AAL2 itching Processor - SN+

DMPG Data and Macro Diversity Group X SN+

ICSU Interface Control and Signaling Unit X N+1

MXU Multiplexer Unit X 2N

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

70 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

Table 35 Supported unit types in IPA-RNC (Cont.)

Unit Unit name RNC2600 Protection


type Scheme

NPS1P Network Processor Interface Unit STM-1 X 2N
Protected

OMU Operation and Maintenance Unit X 2N

RSMU Resource and Switch Management Unit X 2N

SFU Switching Fabric Unit 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 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 36 RNC ICSU capacity
1. Monitored RNC ICSU capacity
capacity item
You can measure the ICSU load with a KPI based on the M592C0 counter. 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.

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


monitoring flag

RNC_5228a Average CPU load of 80% - The RNC ICSU unit load calculated


the most loaded ICSU as the average CPU load of the most
Unit [%] loaded unit.

3. Reactive Counter/KPI Name, unit Description


monitoring
RNC_5206a Windows Access Ratio of total number of rejected WAC gate requests to all
Control (WAC) reject WAC 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

Issue: 06 DN0972569 71
   

RNC capacity Managing WCDMA RAN Capacity

Table 36 RNC ICSU capacity (Cont.)
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: 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 80%. After that, the overload control may
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
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 37 RNC RSMU capacity
1. Monitored RNC RSMU capacity
capacity item

72 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

Table 37 RNC RSMU capacity (Cont.)
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.

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


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.

3. Reactive Counter/KPI Name, unit Description


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 38 RNC OMU capacity
1. Monitored RNC OMU capacity
capacity item
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).

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


monitoring flag

Issue: 06 DN0972569 73
   

RNC capacity Managing WCDMA RAN Capacity

Table 38 RNC OMU capacity (Cont.)
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 [%]

3. Reactive Counter/KPI Name, unit Description


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:

74 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

Figure 16 DMCU HW Architecture
ATMto/fromMXU
ATM

DMPG
DMCU MPC
ATM
mux/demux

CPM PPC Memory

localbus
DMPG DMPG DMPG DMPG

DSP DSP DSP DSP DSP DSP DSP DSP


0 1 2 3 ... ... ... ...

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

PowerPC (PPC) 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 39 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.

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


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.

3. Reactive Counter/KPI Name, unit Description


monitoring
- - -

4. Analysis The KPI represents the maximum of average PPC processor loads on all DMPG units.

5. Overload -

Issue: 06 DN0972569 75
   

RNC capacity Managing WCDMA RAN Capacity

Table 39 RNC DMPG capacity (Cont.)
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 40 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.

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


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

3. Reactive Counter/KPI Name, unit Description


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.

76 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

5.4.2.6 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.7 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.

Table 41 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.

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


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
[%]

3. Reactive Counter/KPI Name, unit Description


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.8 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.9 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

Issue: 06 DN0972569 77
   

RNC capacity Managing WCDMA RAN Capacity

managed by the APP650 network processes. The main traffic management functions
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 42 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).

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


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 [%]

3. Reactive Counter/KPI Name, unit Description


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.

78 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

Table 42 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.10 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 43 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).

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


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: 06 DN0972569 79
   

RNC capacity Managing WCDMA RAN Capacity

Table 43 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
[%]

3. Reactive Counter/KPI Name, unit Description


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 mount configuration. The feature of the
RNC is achieved by the software executing typically on 2 more such modules.

80 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

The variety of functional units in mcRNC is considerably smaller, compared to cRNC.
Figure 17: mcRNC architecture shows the mcRNC architecture.

Figure 17 mcRNC architecture
mcRNC

CFPU EIPU CFPU EIPU

Ethernet
USPU
USPU CSPU
CSPU USPU
USPU CSPU
CSPU

Module1 Module2

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 - Signaling 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 18: mcRNC unit architecture shows the hardware point of view, wherein all the
units are similar, comprising of 8 multicore processors.

Issue: 06 DN0972569 81
   

RNC capacity Managing WCDMA RAN Capacity

Figure 18 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 19: mcRNC HW and SW components.

82 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

Figure 19 mcRNC HW and SW components

RNC
ControlPlaneandO&M RNC
Applications UserPlaneApplications

IPALight
(MiddlewareandAdaptationLayer)
UserPlaneMiddleware
(Middlewareand
AdaptationLayer)
FlexiPlatform
(BasePlatform+OptionalComponents)

SMPLinux SimpleExecutive

Multi-coreandMultiprocessorHardware

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: 06 DN0972569 83
   

RNC capacity Managing WCDMA RAN Capacity

Table 44 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).

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


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.

3. Reactive Counter/KPI Name, unit Description


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), and so on. 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 45 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 Note: CFCP and OMU loads are found in a common KPI.

84 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

Table 45 CFPU load (Cont.)
2. Proactive Counter/KPI Name, unit Target Red Description
monitoring flag

RNC_5435a Maximum over average <80% - The average CPU load of the most


CPU load of loaded CFPU node in CFPU
Centralized Functions processing unit. CFPU node process
in CFPU [%] centralized functions for both Control
Plane ((CFCP) and O&M (OMU).

RNC_5436a Maximum over average <80% - The average CPU load of the most


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

3. Reactive Counter/KPI Name, unit Description


monitoring
- - -

4. Analysis -

5. Overload -

6. Upgrade Upgrade to a higher mcRNC capacity step.

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 46 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.

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


monitoring flag

RNC_5437a Maximum over average < 80% - The average CPU load of the most


CPU load of CSCP in loaded CSPU node in CSPU
CSPU [%] processing unit. CSPU node
processes Cell Specific functions for
Control Plane (CSCP).

Issue: 06 DN0972569 85
   

RNC capacity Managing WCDMA RAN Capacity

Table 46 CSPU load (Cont.)
RNC_5487a Maximum over average < 80% - Average CPU load of the application
CPU load of CSUP in cores for most loaded CSUP node in
CSPU - Application CSPU processing unit. CSUP node
cores [%] processes Cell Specific functions in
User Plane (CSUP).

RNC_5488a Maximum over average < 90% - The everage CPU load of the UMW


CPU load of CSUP in (timer, egress and ingress) cores for
CSPU - UMW cores [%] most loaded CSUP node in CSPU
processing unit. CSUP node
processes Cell Specific functions in
User Plane (CSUP).

3. Reactive Counter/KPI Name, unit Description


monitoring
- - -

4. Analysis -

5. Overload -

6. Upgrade Upgrade to a higher mcRNC capacity step.

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
Signaling Transport Plane (SITP) and External Interface Transport Plane (EITP).

Table 47 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.

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


monitoring flag

RNC_5439a Maximum over average < 45% - The average CPU load of the most


CPU load of SITP in loaded EIPU node in EIPU processing
EIPU [%] unit. EIPU node processes Signaling
Transport Plane functions (STIP).

RNC_5440a Maximum over average < 45 % - The average CPU load of the most


CPU load of EITP in loaded EITP node in EIPU processing
EIPU [%] unit. EITP node processes External
Interface Transport Plane functions
(EITP).
3. Reactive Counter/KPI Name, unit Description
monitoring
- - -

86 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

Table 47 EIPU load (Cont.)
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 -

6. Upgrade Upgrade to a higher mcRNC capacity step.

g Note: 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 48 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.

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


monitoring
RNC_5571a Average over average < 80% - The average CPU load of the USPU
CPU load of USCP in nodes in USPU processing unit.
USPU [%] USPU node processes UE Specific
functions for Control Plane (USCP).

RNC_5572a Average over average < 80% - The average CPU load of the


CPU load of USUP in application cores for USUP nodes in
USPU - Application USPU processing unit. USUP node
cores [%] processes UE Specific functions in
User Plane (USUP).

RNC_5573a Average over Average < 80% - The average CPU load of the UMW


CPU load of USUP in (timer, ingress and egress) cores in
USPU - UMW cores [%] the USUP nodes in USPU processing

Issue: 06 DN0972569 87
   

RNC capacity Managing WCDMA RAN Capacity

Table 48 USPU load (Cont.)
unit. USUP node processes UE
Specific functions in User Plane
(USUP).

3. Reactive Counter/KPI Name, unit Description


monitoring
- - -

4. Analysis -

5. Overload -

6. Upgrade Upgrade to a higher mcRNC capacity step.

5.6 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 Note: 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 Note: 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.

88 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

5.6.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.6.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.6.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: 06 DN0972569 89
   

RNC capacity Managing WCDMA RAN Capacity

5.6.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 49 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 50 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 51 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 < 80%

90 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity RNC capacity

Table 51 KPIs for mcRNC (Cont.)

Processing
FPNODE type Core type KPI Target
Unit

CSPU CSUP UMW RNC_5488a < 90%

EIPU EIPU N/A RNC_5439a < 45%

EIPU EITP N/A RNC_5449a < 45%

USPU USPU N/A RNC_5441a < 80%

USPU USUP Application RNC_5489a < 80%

USPU USUP UMW RNC_5490a < 90%

g Note: The upgrade actions are expected to be initiated sufficiently ahead of the
estimated date.

Issue: 06 DN0972569 91
   

IP transport interface capacity Managing WCDMA RAN Capacity

6 IP transport interface capacity


Figure 20: IP interface capacity bottlenecks and Figure 21: 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 20 IP interface capacity bottlenecks

IP
Route CACguaranteedtraffic CACGuaranteedTraffic
RouteBw

Com
BW -R99CSVoice
-R99RTDCHCS:ConversationalClass
-R99RTDCHPS:StreamingClass
Non-guaranteedtraffic
-R99NRTDCHPS:InteractiveandBackgroundClass
- HSPACSVoice(iffeatureRAN1689isactive)
RncEthernetBw

IP - HSPARTPS:StreamingClass(iffeatureRAN1004isactive)
Route CACguaranteedtraffic NonGuaranteedTraffic(CACsettingisirrelevanthere)
RouteBw

Com - HSPANRTPS:InteractiveandBackgroundClass
BW

Non-guaranteedtraffic

RNC

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 Note: 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 Note: 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.

92 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity IP transport interface capacity

Figure 21 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 22 Ethernet interface monitoring
IFC=OFFforIPRoutemeansthatthemonitored
interfacecanfullyutilizethewholeEthernetBW
EthernetInterfaceBW

Ethernetinterfacetraffic

Monitored
Capacityitem

AlltrafficissharingalltheEthernetBWresources

Issue: 06 DN0972569 93
   

IP transport interface capacity Managing WCDMA RAN Capacity

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 23: 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 23 IP resource overbooking
RouteBw
RouteBw
RncEthernetBw

Overbooking
ofIP
resources
RouteBw
RouteBw

Table 52 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.

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


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
< 80% -
RncEthernetBw parameter. The
formula to be used separately for
each Ethernet port on the NPGE.

RNC_5222a NPGE Ethernet port This is the sum of the transmitted


TX_Utilization [%] Ethernet data compared to the
maximum value, limited by the
< 80% -
RncEthernetBw parameter. The
formula to be used separately for
each Ethernet port on NPGE.

3. Reactive Counter/KPI Name, unit Description


monitoring

94 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity IP transport interface capacity

Table 52 Ethernet bandwidth capacity (Cont.)
RNC_1644a Ethernet frames drop
Ingress Ethernet frames drop ratio, summed up to unit level.
ratio, ingress [%]

RNC_1645a Ethernet frames drop
Egress Ethernet frames drop ratio, summed up to unit level.
ratio, egress [%]

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

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

Issue: 06 DN0972569 95
   

IP transport interface capacity Managing WCDMA RAN Capacity

6.2.1 IP-based route: IFC enabled


Figure 24 IP route monitoring: IFC enabled

IFC=ONmeansthatthemonitoredinterfacecan
utilizeonlytheconfiguredBWofusedIPRoute

Capacityavailable
EthernetInterfaceBW

IPbasedrouteBW

forallTraffic
IP-based route
traffic

Monitored
Capacityitem

AlltrafficissharingalltheIPRouteBWresources

Table 53 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 Note: 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).

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


monitoring flag

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 data
traffic load
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).

96 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity IP transport interface capacity

Table 53 IP route bandwidth: IFC enabled (Cont.)
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).

3. Reactive Counter/KPI Name, unit Description


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
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 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.

Issue: 06 DN0972569 97
   

IP transport interface capacity Managing WCDMA RAN Capacity

6.2.2 IP-based route: IFC disabled


Figure 25: 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

Figure 25 IP route monitoring - traffic limited by feature
RAN1110: HSPA Congestion Control
OtherIPBRssharingEtherif
+HSPACCrestrictsthefullusage
Trafficloadmay
ofEthernetifforoneIPBR
exceedtheIPBRBW

All Traffic IFC=OFFforIPRoutemeansthatthemonitoredinterfacecan


inprinciplefullyusethewholeEthernetBW

Capacityavailablefor
IPbasedrouteBW
EthernetInterfaceBW

IP-based route

alltraffic
traffic

Monitored
Capacityitem

AlltrafficissharingalltheEthernetBWresources

Table 54 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 the
route(s).

2. Proactive Counter/KPI Name, unit Target R


monitoring

RNC_5449a

Outgoing data
Average outgoing IP route traffic utilization rate < 40% -
traffic load

98 DN0972569 Issue: 06
   

Managing WCDMA RAN Capacity IP transport interface capacity

Table 54 IP route bandwidth: IFC disabled (Cont.)
RNC_5473a

Peak outgoing IP route traffic utilization rate < 100%

RNC_5029a

Incoming data
Incoming IP route traffic volume [Mbit] < 40%
traffic load

3. Reactive Counter/KPI Name, unit Description


monitoring

M5000C176 HS-DSCH CREDIT REDUCTIONS DUE TO IUB DELAY Number of HS-


[#] up.

M5000C177 HS-DSCH CREDIT REDUCTIONS DUE TO SEVERE Number of HS-


IUB DELAY [#] delay build-up.

M5000C178 HS-DSCH CREDIT REDUCTIONS DUE TO FRAME Number of HS-


related to LOSS [#]
HSDPA
congestion M5000C453 HS_DSCH_CRDT_RDCT_BUF_CPU_LOAD [#] The number of
control HS-DSCH
credit
reductions due
to shared
memory buffer
overflow or
HSTUP CPU
overload.

related to M1022C69 DELAY BUILDUP INDICATIONS SENT DUE TO IUB The number of


HSUPA DELAY [#] up” messages 
congestion by the Frame p
control
M1022C70 DELAY BUILDUP INDICATIONS SENT DUE TO HW The number of
OVERLOAD [#] up” messages 
congestion con

M1022C71 FRAME LOSS INDICATIONS SENT DUE TO TRAFFIC The number of


LOSS [#] messages sent
the Frame prot

M1022C72 FRAME LOSS INDICATIONS SENT DUE TO IUB The number of


DELAY [#] messages sent
Frame protoco

Issue: 06 DN0972569 99
   

IP transport interface capacity Managing WCDMA RAN Capacity

Table 54 IP route bandwidth: IFC disabled (Cont.)
M1022C73 FRAME LOSS INDICATIONS SENT DUE TO HW The number of “Co
OVERLOAD [#] messages sent to 

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
average traffic utilization.
– When IFC is disabled and there is no route bandwidth used for IPBR scheduler, counter M5868C15 IP_EG
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
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 
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.

100 DN0972569 Issue: 06


   

Managing WCDMA RAN Capacity IP transport interface capacity

Figure 26 Example for IP CAC monitoring for an IP-based route where IFC is also
enabled

IFC=ONmeansthatthemonitoredinterfacecan
useonlytheconfiguredBWofusedIPRoute

Capacityavailablefor
IP basedrouteBW

NONCACTraffic
EthernetInterfaceBW

Trafficasa
IPCommitedBW subjectforCAC

Monitored
Capacityitem

AstheCACisenabledthereiscommittedtraffic
i.e.CAChandledtraffichaveacommitted
shareofconfiguredIPRouteBWresources.

CommittedBWincludesbesidesCAChandledtraffic
alsosignalingandDCNtraffic

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 27 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

IPCACreservationforexistingconnections

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.

Issue: 06 DN0972569 101


   

IP transport interface capacity Managing WCDMA RAN Capacity

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 signaling BW. The formula is (IP-based route committed BW - IP-based
committed signaling BW - IP-based route committed DCN bandwidth).
When assigned to the same PHB queue with CAC-controlled traffic, there is always a
bandwidth for signaling the DCN traffic. This traffic is not limited to the IP-based
committed signaling/DCN BW parameter value. Therefore, it is not necessary to monitor
the signaling traffic similarly as it is in the case when the NBAP signaling is carried in
ATM VCC.

Table 55 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

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


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
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 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
[%]

IP route RNC_5385a IP-based Iub


reservation uplink maximum
The maximum reservation rate of guaranteed IP
rate - UL with reservation rate < 90% -
transport resources at Flexi BTS per VLAN interface.
VLAN at Flexi BTS -
differentiation VLAN [%]

102 DN0972569 Issue: 06


   

Managing WCDMA RAN Capacity IP transport interface capacity

Table 55 Committed bandwidth (Cont.)
RNC_5386a IP-based Iub < 90% - The maximum reservation rate of guaranteed IP
uplink maximum transport resources at Ultra BTS per VLAN interface.
reservation rate
at Ultrasite BTS
- VLAN [%]

3. Reactive Counter/KPI Name, unit Description


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.

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 [#]

IP route M804C5 FAIL_BTS_IP_R This is the number of failed IP transport resource reservations in the


reservation ES_EXT_TRAN BTS because of external connection admission control.
blocking 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: 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.

Issue: 06 DN0972569 103


   

ATM transport interface capacity Managing WCDMA RAN Capacity

7 ATM transport interface capacity


g Note: This chapter is relevant only for IPA-RNC.

Figure 28: 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 28 ATM interface capacity bottlenecks
Virtual AAL2
channel connection

Virtual
ATM path
interface Virtual
path

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.

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.

104 DN0972569 Issue: 06


   

Managing WCDMA RAN Capacity ATM transport interface capacity

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 Note: 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).
– 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).

Issue: 06 DN0972569 105


   

ATM transport interface capacity Managing WCDMA RAN Capacity

– 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.
Monitoring of given bottlenecks
Figure 29: 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.

Figure 29 Monitoring principle of ATM bottlenecks
Measuredaveragetrafficovermeasurementperiod

100%ofCBRPCR
orUBR+MDCR
Note: Incaseof
UBR+VCCtraffic
canbe>100%

Measurementperiod
Reference
: WCDMA RAN ATM Transport.
ATM Interface

106 DN0972569 Issue: 06


   

Managing WCDMA RAN Capacity ATM transport interface capacity

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.
Figure 30 ATM transport interface: identified monitoring cases

ATMtransportinterface

ATM VirtualPath(VP) VirtualChannel(VC)


Interface
Bottlenecks

Considered UBR+VCCinside ShapedCBR


Configuration UnshapedVP(s) CBR UBR/UBR+
VP(s)

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 Note: 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 30: 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.

7.1 ATM interface


An ATM interface is one of eight STM-1 interfaces in an NPS1/NPS1P (RNC2600). The
capacity of an STM-1 interface is standardized to 155 Mbit/s.

Issue: 06 DN0972569 107


   

ATM transport interface capacity Managing WCDMA RAN Capacity

Table 56 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 Note: 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.

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


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.

3. Reactive Counter/KPI Name, unit Description


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.
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 57 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.

108 DN0972569 Issue: 06


   

Managing WCDMA RAN Capacity ATM transport interface capacity

Table 57 Utilization of ATM virtual path (Cont.)

g Note: For Iu-CS, Iur, and Iub, VPC monitoring is sufficient when it is enough to monitor only the
whole capacity.

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


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.

3. Reactive Counter/KPI Name, unit Description


monitoring

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.

5. Overload If data traffic load increases above the threshold limits, the user throughput is downgraded in high load
situations.

Issue: 06 DN0972569 109


   

ATM transport interface capacity Managing WCDMA RAN Capacity

Table 57 Utilization of ATM virtual path (Cont.)
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 58 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.
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.

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


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.
Outgoing data
traffic load
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
egress direction.

110 DN0972569 Issue: 06


   

Managing WCDMA RAN Capacity ATM transport interface capacity

Table 58 Utilization of ATM virtual channel (CBR) (Cont.)
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


capacity of ATM VCC bandwidth and total bandwidth of AAL2
[%] path estimated by CAC during
measurement period.
Connection
utilization
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.

3. Reactive Counter/KPI Name, unit Description


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.

Issue: 06 DN0972569 111


   

ATM transport interface capacity Managing WCDMA RAN Capacity

Table 58 Utilization of ATM virtual channel (CBR) (Cont.)
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 59 Utilization of ATM virtual channel (UBR/UBR+)
1. Monitored Utilization of ATM virtual channel
capacity item
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.

112 DN0972569 Issue: 06


   

Managing WCDMA RAN Capacity ATM transport interface capacity

Table 59 Utilization of ATM virtual channel (UBR/UBR+) (Cont.)

g Note: 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.

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


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.

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


Connection
capacity of ATM total bandwidth of AAL2 path estimated by CAC
utilization
VCC [%] during measurement period.

Issue: 06 DN0972569 113


   

ATM transport interface capacity Managing WCDMA RAN Capacity

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

3. Reactive Counter/KPI Name, unit Description


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 Note: 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%.

g Note: 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.

114 DN0972569 Issue: 06


   

Managing WCDMA RAN Capacity ATM transport interface capacity

7.4 VCC bundle


Figure 31: 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 31 VCC bundle - UBR + VCCs bandwidth
Bandwidth%

100%
88%
VC 75%
bundle 50%
25%

g Note: 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 60 Utilization of ATM VCC bundle
1. Monitored Utilization of ATM VCC bundle
capacity item
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).

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


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.

3. Reactive Counter/KPI Name, unit Description


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.

Issue: 06 DN0972569 115


   

ATM transport interface capacity Managing WCDMA RAN Capacity

Table 60 Utilization of ATM VCC bundle (Cont.)
• If the red flag is exceeded, it is necessary to increase the VCCBundlePCR.

5. Overload If data traffic load increases above the threshold limits, the user throughput is downgraded in high load
situations.

6. Upgrade If overload occurs for all traffic, the VCCBundlePCR should be increased.

116 DN0972569 Issue: 06