UMT_IRC_INF_022089 RNC Capacity Engineering Guide UA07[1].1 Internal V03.06
-
Upload
bouziane-beldjilali -
Category
Documents
-
view
38 -
download
1
Transcript of UMT_IRC_INF_022089 RNC Capacity Engineering Guide UA07[1].1 Internal V03.06
-
RNC Capacity Engineering Guide
Document number: UMT/IRC/INF/022089 Document issue: 03.06 Document status: Standard Date: 17/03/2011
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
INTERNAL DOCUMENT
Copyright 2007 Alcatel-Lucent, All Rights Reserved
Printed in France
UNCONTROLLED COPY: The master of this document is stored on an electronic database and is write
protected; it may be altered only by authorized persons. While copies may be printed, it is not recommended.
Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be regarded
as uncontrolled copies.
ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of Alcatel-
Lucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information
contained herein confidential, shall disclose the information only to its employees with a need to know, and shall
protect the information from disclosure and dissemination to third parties. Except as expressly authorized in
writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you have
received this document in error, please notify the sender and destroy it immediately.
without notice. Nortel Networks assumes no responsibility for errors that might appear in t.All other brand and
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 2/24
PUBLICATION HISTORY
01/FEB/2007
Issue 00.01 / EN, Draft
Document Creation
02/APR/2007
Issue 00.02 / EN, Draft
Document update after first review
18/APR/2007
Issue 00.03 / EN, Draft
Candidate release for UA05.0 Cur
20/APR/2007
Issue 01.00 / EN, Preliminary
Document release for UA05.0 Cur after review
17/JUL/2007
Issue 01.01 / EN, Standard
Update after new comments, release for UA05.0 ChR
3/SEPT/2007
Issue 01.02 / EN, Preliminary
Updates for UA05.1 DR4
06/NOV/2007
Issue 01.03 / EN, Standard
Updates for UA05.1 DR5
20/MAR/2008
Issue 01.04 / EN, Draft
Release of the document to be reviewed for UA05.1.2 DR4
01/APR/2008
Issue 01.05 / EN, Preliminary
Document release for UA05.1.2 DR4
20/MAI/2008
Issue 02.01 / EN, Draft
Document update for UA06.0 release
05/JUN/2008
Issue 02.02 / EN, Preliminary
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 3/24
Document update after review. UA06 Preliminary release.
05/JUN/2009
Issue 02.03 / EN, Standard
Document release for UA06 DR5
18/JAN/2010
Issue 03.01 / EN, Draft
Document release for UA07.1
26/JAN/2010
Issue 03.02 / EN, Preliminary
Modifications see review minutes
Document release for UA07.1 DR4
1/FEB/2010
Issue 03.03 / EN, Preliminary
Add chapter on RNC capacity representation
Correction for PMC-PC engineering limit
Document release for UA07.1 DR4
1/JUNE/2010
Issue 03.04 / EN, Preliminary
Adding UA7.1.2 content
17/MARCH/2011
Issue 03.06 / EN, Standard
Adding UA7.1.3 content
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 4/24
CONTENTS
1. INTRODUCTION............................................................................................................................5
1.1. OBJECT....................................................................................................................................5
1.2. SCOPE OF THIS DOCUMENT .......................................................................................................5
1.3. AUDIENCE FOR THIS DOCUMENT ................................................................................................5
2. RELATED DOCUMENTS ..............................................................................................................6
2.1. APPLICABLE DOCUMENTS ..........................................................................................................6
2.2. REFERENCE DOCUMENTS..........................................................................................................6
3. 9370 RNC CAPACITY PROBLEMATIC........................................................................................7
3.1. OVERVIEW OF 9370 RNC ARCHITECTURE.............................................................................7
3.2. DIFFERENT CAPACITY ASPECTS ..............................................................................................12
3.2.1 RNC capacity In Connectivity........................................................................................12 3.2.2 RNC Coverage capacity................................................................................................14 3.2.3 RNC Traffic Capacity ....................................................................................................14
3.3. COMMITTED CAPACITY LEVELS ..........................................................................................16
3.4. RNC CAPACITY REPRESENTATION ...........................................................................................17
4. OPERATIONAL VIEW ON RNC CAPACITY ..............................................................................19
4.1. GENERAL CONSIDERATIONS AND RECOMMENDATIONS ......................................................19
4.1.1 General View.................................................................................................................19 4.1.2 Counters management specificity .................................................................................20 4.1.3 PMC-TMU specific concern ..........................................................................................21
4.2. POSSIBLE ACTIONS FOR CAPACITY ENHANCEMENTS ................................................22
5. RNC CAPACITY ESTIMATIONS ................................................................................................23
6. ABBREVIATIONS AND DEFINITIONS.......................................................................................24
6.1. ABBREVIATIONS ......................................................................................................................24
6.2. DEFINITIONS ...........................................................................................................................24
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 5/24
1. INTRODUCTION
1.1. OBJECT
The object of this document is to provide some guidelines regarding RNC capacity. It
presents capacity problematic with Alcatel-Lucent 9370 RNC from an Engineering
point of view.
1.2. SCOPE OF THIS DOCUMENT
This document is applicable to 9370 RNC for release UA07.1 (applicable for both
UA7.1.1 and UA7.1.3).
1.3. AUDIENCE FOR THIS DOCUMENT
It is destined to regional engineering teams and other teams involved, in Pre-Sales or
Post-Sales context, in RNC capacity exercises from an operational point of view.
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 6/24
2. RELATED DOCUMENTS
2.1. APPLICABLE DOCUMENTS
[A1] UMT/PLM/INF/4862 UMTS RNC Capacity Roadmap
[A2] UMT/SYS/DD/8005 RNC Overload
[A3] NN 20500-024 UMTS RNC and POC Alarms
[A4] UMT/COM/INF/23886 Changes to Alcatel-Lucent UMTS RNC Portfolio
Evolution in UA05.1 and UA06
2.2. REFERENCE DOCUMENTS
[R1] UMT/IRC/APP/13736 RNC Product Engineering Information
[R2] UMT/IRC/APP/0166 Iu Transport Engineering Guide
[R3] UMT/IRC/APP/0164 IuB Transport Engineering Guide
[R4] UMT/IRC/APP/0050 IuR transport Engineering Guide
[R5] UMT/IRC/DD/0011 UTRAN Parameter Users Guide
[R6] UMT/IRC/APP/023122 UMTS 7670 RSP/ESE Product Engineering
Information
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 7/24
3. 9370 RNC CAPACITY PROBLEMATIC
3.1. OVERVIEW OF 9370 RNC ARCHITECTURE
9370 RNC architecture is presented in document [R1]. This current chapter gives a short overview of
the RNC architecture related to capacity aspects. For a more complete view of the product, document
[R1] should be used.
The main modules of 9370 RNC are the following ones:
- Fabric modules (internal RNC switching modules for internal exchanges of messages)
managed in 1+1 mode (full duplication of traffic on the fabric)
- 16pOC3/STM1 boards (Interfaces boards providing ATM access to IuB, IuCS, IuPS, IuR,
IuPC, IuBC, ) Managed in 1:1 mode (operational/hot stand-by)
- CP boards (Control Process boards managing RNC platform, manages also associated
disks) Managed in 1:1 mode (operational/hot stand-by)
- PS boards (Packet Server processing boards managing calls and traffic for the RNC)
Managed in N+P mode
- 4pGiGE boards (Interfaces boards providing direct IP interface to the RNC). These boards
are optional.
It has to be noticed that:
- from UA05.0 two types of 16pOC3STM1 boards are available (may be optional in case of full
IP RNC):
o 16pOC3STM1 PQC boards
o 16pOC3STM1 MS3 boards.
- from UA05.1.2 two types of Packet Server boards are available:
o Packet Server: PS-FP (that may also be called PS1 in the following of the document)
o Dual Core Packet Server: DCPS.
- from UA06.0 two types of CP boards are available:
o CP3 boards
o CP4 boards
- From UA6.0 4pGiGE boards are introduced (may be optional in case of full ATM
configuration)
Each Packet Server board contains 6 PMC (PCI Mezzanine Card). (For DCPS it may be considered
also that each of them contains 6 logical PMC). A dedicated role is applied to each PMC. The
following different PMC main roles are roughly the following:
- PMC-M (1:1): Master PMC managing PMC organization and supervision inside the RNC,
- PMC-NI (1:1): managing SS7 stacks (layers MTP3 & SCCP)
- PMC-OMU (1:1): managing OAM relations between RNC and OMC (CM, FM, PM, )
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 8/24
- PMC-PC (N+1 - up to 12): Protocol Converter (Segmentation & reassembly) between
IP/AAL2 and IP/AAL5; load sharing for ATM configuration
- PMC-RAB (N+1 up to 40): Bearer processing, radio protocol handling (RLC, MAC, ),
Macro diversity,
- PMC-TMU (N+P: P=1 for N8 up to 14): Call and cell processing, RANAP,
RNSAP, NBAP, RRM
The allocation of the PMC roles on the PS-FP (or DCPS) is presented in the following figures, this
depend of the RNC interface configuration:
slot card/Pmc 0 1 2 3 4 5
0 CP
1 CP
2 PSFP PMC-M TMU RAB RAB PC RAB
3 PSFP PMC-M TMU RAB RAB PC RAB
4 PSFP RAB TMU NI RAB PC OMU
5 PSFP RAB TMU NI RAB PC OMU
6 PSFP RAB TMU RAB RAB PC RAB
7 PSFP RAB TMU RAB RAB PC RAB
8 OC3
9 OC3
10 PSFP RAB TMU RAB RAB PC RAB
11 PSFP RAB TMU RAB RAB PC RAB
12 PSFP RAB TMU RAB RAB PC TMU
13 PSFP RAB TMU RAB RAB PC TMU
14 PSFP RAB TMU RAB RAB PC RAB
15 PSFP RAB TMU RAB RAB PC RAB
PMC ID within PSFP
Figure 1: Case full ATM with 12 PS boards - Allocation of PMC on the different PS-FP or DCPS
slot card/Pmc 0 1 2 3 4 5
0 CP
1 CP
2 PSFP PMC-M TMU RAB RAB PC RAB
3 PSFP PMC-M TMU RAB RAB PC RAB
4 PSFP RAB TMU NI RAB PC OMU
5 PSFP RAB TMU NI RAB PC OMU
6 PSFP RAB TMU RAB RAB PC RAB
7 PSFP RAB TMU RAB RAB PC RAB
8 OC3
9 OC3
10 PSFP RAB TMU RAB RAB PC RAB
11 PSFP RAB TMU RAB RAB PC RAB
12 PSFP RAB TMU RAB RAB PC TMU
13 PSFP RAB TMU RAB RAB PC TMU
14 4GIGE
15 4GIGE
PMC ID within PSFP
Figure 2: Case mix ATM/IP with 10 PS boards- Allocation of PMC on the different PS-FP or DCPS
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 9/24
slot card/Pmc 0 1 2 3 4 5
0 CP
1 CP
2 PSFP PMC-M TMU RAB RAB PC RAB
3 PSFP PMC-M TMU RAB RAB PC RAB
4 PSFP RAB TMU NI RAB PC OMU
5 PSFP RAB TMU NI RAB PC OMU
6 PSFP RAB TMU RAB RAB PC RAB
7 PSFP RAB TMU RAB RAB PC RAB
8 PSFP RAB TMU RAB RAB PC RAB
9 PSFP RAB TMU RAB RAB PC RAB
10 PSFP RAB TMU RAB RAB PC RAB
11 PSFP RAB TMU RAB RAB PC RAB
12 PSFP RAB TMU RAB RAB PC TMU
13 PSFP RAB TMU RAB RAB PC TMU
14 4GIGE
15 4GIGE
PMC ID within PSFP
Figure 3: Case full IP with 12 PS boards - Allocation of PMC on the different PS-FP or DCPS
The role of the different PMC can not be modified. The allocation of these roles is static depending on
the PS-FP (or DCPS) slot number and PMC id. The above figure presents the implementation of these
PMC roles for a 12 or 10 PS-FP (or DCPS) market model. For smaller market models, the
implementation remains the same for the PS-FP (or DCPS) present in the rack according to their slot
number (Reminder: PS boards are set in the rack from the lower slot value up to the lower slot values.
Thus for lower market models only the first slots of PSFP are full).
Different 9370 RNC supported market models exist according to the number of Packet Server present
in the shelf. The different supported market models in UA07.1 are:
- for RNC equipped with PS-FP:
o 9370 RNC with 4 PSFP,
o 9370 RNC with 6 PSFP,
o 9370 RNC with 8 PSFP,
o 9370 RNC with 10 PSFP,
o 9370 RNC with 12 PSFP.
- for RNC equipped with DCPS:
o 9370 RNC with 4 DCPS,
o 9370 RNC with 6 DCPS,
o 9370 RNC with 8 DCPS,
o 9370 RNC with 10 DCPS,
o 9370 RNC with 12 DCPS.
No mixed configuration using PSFP and DCPS is supported.
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 10/24
The following table summarizes the different modules of these market models (the number of PS-FP
or DCPS boards is the only difference between the market models).
9370 RNC Market Models
9370 RNC
w 4 PSFP w 6 PSFP w 8 PSFP w 10 PSFP w 12 PSFP
Modules
ATM MIX IP ATM MIX IP ATM MIX IP ATM MIX IP ATM MIX IP
Fabric 2 2 2 2 2 2 2 2 2 2 2 2 2 N/A 2
CP3 2 2 2 2 2 2 2 2 2 2 2 2 2 N/A 2
16pOC3/STM1 2 2 0 2 2 0 2 2 0 2 2 0 2 N/A 0
4pGiGE 0 2 2 0 2 2 0 2 2 0 2 2 0 N/A 2
PS-FP 4 4 4 6 6 6 8 8 8 10 10 10 12 N/A 12
9370 RNC
w 4 DCPS w 6 DCPS w 8 DCPS w 10 DCPS w 12 DCPS
Modules
ATM MIX IP ATM MIX IP ATM MIX IP ATM MIX IP ATM MIX IP
Fabric 2 2 2 2 2 2 2 2 2 2 2 2 2 N/A 2
CP(CP3 or CP4) 2 2 2 2 2 2 2 2 2 2 2 2 2 N/A 2
16pOC3/STM1 2 2 0 2 2 0 2 2 0 2 2 0 2 N/A 0
4pGiGE 0 2 2 0 2 2 0 2 2 0 2 2 0 N/A 2
DCPS 4 4 4 6 6 6 8 8 8 10 10 10 12 N/A 12
Table 1: Number of modules per market model
The number of different PMC types per market model is the following:
9370 RNC Market Models
PMC Types w 4 PSFP or
DCPS
w 6 PSFP or
DCPS
W 8 PSFP or
DCPS
w 10 PSFP or
DCPS
w 12 PSFP or
DCPS
PMC-M 2 2 2 2 2
PMC-OMU 2 2 2 2 2
PMC-NI 2 2 2 2 2
PMC-PC 4 6 8 10 12
PMC-RAB 10 18 26 32 40
PMC-TMU 4 6 8 12 14
Table 2: Number of PMC of each type per market model
Since UA7.1.3 with the introduction of the FRS 106904 TMU RAB rebalancing it is possible to modify
the PMC mapping for the market models with 10 DCPS and CP4 only. This feature allows changing
PMC-RAB in slot 10 and 11 PMC id 5 by PMC-TMU. Then since UA7.1.3 both following configuration
are possible for slot 10 and 11:
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 11/24
PMC-id and number
Slot Card 0 1 2 3 4 5
0 CP4
1 CP4
2 DCPS PMC-M TMU RAB RAB PC RAB
3 DCPS PMC-M TMU RAB RAB PC RAB
4 DCPS RAB TMU NI RAB PC OMU
5 DCPS RAB TMU NI RAB PC OMU
6 DCPS RAB TMU RAB RAB PC RAB
7 DCPS RAB TMU RAB RAB PC RAB
8 16p OC3
9 16p OC3
10 DCPS RAB TMU RAB RAB PC RAB
11 DCPS RAB TMU RAB RAB PC RAB
12 DCPS RAB TMU RAB RAB PC TMU
13 DCPS RAB TMU RAB RAB PC TMU
14 4pGigE
15 4pGigE
Or
PMC-id and number
Slot Card 0 1 2 3 4 5
0 CP4
1 CP4
2 DCPS PMC-M TMU RAB RAB PC RAB
3 DCPS PMC-M TMU RAB RAB PC RAB
4 DCPS RAB TMU NI RAB PC OMU
5 DCPS RAB TMU NI RAB PC OMU
6 DCPS RAB TMU RAB RAB PC RAB
7 DCPS RAB TMU RAB RAB PC RAB
8 16p OC3
9 16p OC3
10 DCPS RAB TMU RAB RAB PC TMU
11 DCPS RAB TMU RAB RAB PC TMU
12 DCPS RAB TMU RAB RAB PC TMU
13 DCPS RAB TMU RAB RAB PC TMU
14 4pGigE
15 4pGigE
In that last case the RNC runs with 30 PMC-RAB and 14 TMUs
Estimated TMU capacity gain is between 12% and 18%. At feature introduction this gain must be
assessed.
With the different possible board types, the following hardware baselines are supported:
- CP3 + (optionally) 16pOC3STM1 PQC + PSFP + (optionally) 4pGiGE
- CP3 + (optionally) 16pOC3STM1 MS3 + PSFP + (optionally) 4pGiGE
- CP3 + (optionally) 16pOC3STM1 PQC + DCPS + (optionally) 4pGiGE
- CP3 + (optionally) 16pOC3STM1 MS3 + DCPS + (optionally) 4pGiGE
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 12/24
- CP4 + (optionally) 16pOC3STM1 MS3 + DCPS + (optionally) 4pGiGE
It is important to note that inside a same RNC:
- no mixity is possible between 16pOC3STM1 PQC and 16pOC3STM1 MS3 boards,
- no mixity is possible between PSFP and DCPS boards,
- no mixity is possible between CP3 and CP4 boards.
- In UA7.1 16pOC3STM1 become optional, in case of full IP RNC
- At least one type of board between 16pOC3STM1 and 4pGiGE must be present in the RNC.
3.2. DIFFERENT CAPACITY ASPECTS
From a capacity perspective, three different aspects have to be considered for the RNC:
- Connectivity
- Coverage
- Traffic
3.2.1 RNC CAPACITY IN CONNECTIVITY
ATM CONNECTIVITY
The ATM external connectivity of the RNC is provided by the 16pOC3/STM1 boards. They are
managed in a 1:1 mode (Operational/Stand By). Thus two 16 ports OC3/STM1 are available for the
access to the interfaces whatever the market model is.
Two generations of 16pOC3/STM1 boards are available:
- the 16pOC3/STM1 PQC board,
- the 16pOC3/STM1 MS3 board (optional board that may be introduced from UA05 release).
Both types of boards offer 16 OC3/STM1 ports. Nevertheless, the 16pOC3/STM1 MS3 offers a higher
capacity in term of number of ATM PVC supported:
- 16pOC3/STM1 PQC: 16000 PVC
- 16pOC3/STM1 MS3: 45000 PVC (16000 max per port).
It has to be mentioned that, according to the configuration needed for the interfaces, some Hairpins,
may be needed impacting the number of ports really available for the external connections:
Such hairpins are needed in case of VPT shaping: some external hairpins have to be put on external
ports of the 16pOC3/STM1 board.
Prior to UA06, hairpins were also needed for sPVC (Soft PVC) management. From UA06.0 there is no
more need for such hairpins. For RNC on which these hairpins were used in the previous releases, it
is then possible now to remove them and thus free some external ports if needed.
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 13/24
(For more details about hairpin usage, please refer to documents [R2], [R3] and [R4]).
The connectivity offered by the 16pOC3STM1 boards are, SDH or Sonet, STM1 or OC3, Clear
Channel VC4 level. For all other needs, the use of a Transport Node will be necessary. To work with
Alcatel-Lucent 9370 RNC, two types of Transport Nodes are recommended: Alcatel Lucent 7670 ESE
and 7670 RSP products. The ALU 7670 ESE product offers E1/T1 connectivity, optical STM1/OC3
VC4 level and VC12 level, IMA support, etc The ALU 7670 RSP product provides also a wide range
of possible connectivity: optical SONET/SDH at OC3/STM1, OC12/STM4 and OC48/STM16 speeds,
DS3, STM1 electrical, Gigabit Ethernet (IP/MPLS only),
For more information about 7670 ESE and 7670 RSP products and associated dimensioning please
refer to document [R6].
In term of Iu DL traffic the 16pOC3/STM1 PQC has a maximum capacity of 310 Mbps (at applicative
level). This constraint does not exist with the 16pOC3/STM1 MS3 board that supports up to 2.5 Gbps
IP forwarding (Note that interface physical layer can support up to 16 x 155 Mb/s = 2480 Mb/s). Thus
for RNC that would need an ATM Iu DL bandwidth capacity higher than 310 Mbps (this could be the
case depending on the call profile for market models using DCPS boards), the 16pOC3/STM1 MS3
boards should be used.
PMC-PC can support up to 810 AAL2 paths each.
IP CONNECTIVITY
From UA06.0 it is possible to have direct IP access on Iu-PS and IuB from the RNC (optional
configuration). These IP access are managed by the 4pGiGE boards. Two of these boards have to be
set in the RNC shelf in case where direct IP accesses are used.
In UA07.1, IP access is possible on all interfaces:
In case of Iu-Flex configuration some Iu-PS interfaces may be based on ATM and some others on IP.
Nevertheless for a given Iu-PS interface the Control Plane and the User Plane have to be based on
the same type of interface (ATM or IP).
Hybrid IuB may be configured on a NodeB basis: on a given RNC, some NodeB may be connected
through a pure ATM IuB interface and some others with an hybrid IuB configuration. The principle of
hybrid IuB is to have a mixed ATM and IP interface between the RNC and the concerned NodeB. IP is
then only used for the HSxPA interactive/background user plane traffic. The rest of the traffic is
exchanged through ATM.
In UA07.1, three types of configurations are supported pure ATM configurations, configuration with a
mixed of ATM and IP interfaces and pure IP configuration. For configuration using a mixed of ATM
and IP interfaces, the two 16pOC3STM1 boards and the two 4pGiGE boards need to be present in the
shelf. The 4pGiGE boards have to be set in the shelf in slots 14 and 15, at the place of two PS boards.
This means that for mixed ATM and IP RNC, the maximum supported market model is with 10
PSFP or DCPS boards.
The two 4pGiGE boards are managed in load sharing mode. Each one of the board provide 4 Giga
Ethernet external ports (there is thus of total of 8 Giga Ethernet ports available per RNC). Each port
has a capacity of 1Gbps but the total throughput supported by a board is 2.5 Gbps.
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 14/24
For redundancy aspects, it is recommended to define some active and redundant paths through the
two 4pGiGE boards. The active and redundant paths of a given link should be defined on the two
different 4pGiGE boards in order to support the loss of one of them.
To be able to support the loss of one board without any capacity impact, it is recommended that the
total IP traffic exchanged across the RNC (so over the two 4pGiGE boards) do not exceed 2.5 Gbps.
Remark: in UA07.1, this value should not be a limitation for the RNC since the processing capacity of
the PS boards should limit the traffic before the external interface boards. For example, for Mobile
Premium Office profile Iu Application bandwidth is 675Mbps for a 12 DCPS RNC in UA7.1. For more
details, refer to [A1]
3.2.2 RNC COVERAGE CAPACITY
Under the term coverage is here considered the maximum numbers of NodeB and cells that a RNC
can support. These values are dependent on the market model and on the hardware baselines. For
more details, refer to [A1]
The corresponding figures are presented in the table below.
9370 RNC Market Models with CP3 boards
w 4 PSFP or
DCPS
w 6 PSFP or
DCPS
W 8 PSFP or
DCPS
w 10 PSFP or
DCPS
w 12 PSFP or
DCPS
Max NodeB 360 600 800 1200 1200
Max Cells 360 600 800 1200 1200
9370 RNC Market Models with CP4 boards
w 4 DCPS w 6 DCPS W 8 DCPS w 10 DCPS w 12 DCPS
Max NodeB 600 1000 1400 2000 2400
Max Cells 600 1000 1400 2000 2400
Table 3: Coverage capacity for the different RNC market model
It has to be noticed that from UA06.0 the committed maximum number of supported NodeB is equal
(According to Capacity Roadmap [A1]) to the maximum number of supported cells. This means that
the RNC NodeB/cell capacity is limited by the first NodeB or Cell which reaches its limit.
3.2.3 RNC TRAFFIC CAPACITY
BORDER LIMITS
In term of traffic capacity, the RNC product has some border limits that cannot be exceeded.
In term of number of internal dimensioning figures, the maximum numbers of contexts are the
following for a 9370 RNC with 12 PSFP:
o Max number of CS RRC contexts: 6048
o Max number of DCH (CS+PS) RRC contexts: 8640
o Max number of FACH RRC contexts: 7020
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 15/24
o Max number of CELL_PCH RRC Contexts: 7020
o Max number of total CELL_PCH and URA_PCH RRC contexts: 32040.
For a market model using 12 DCPS, the following maximum numbers of contexts are:
o Max number of CS RRC contexts: 14520
o Max number of DCH (CS + PS) RRC contexts: 17280
o Max number of FACH RRC contexts: 14040
o Max number of CELL_PCH RRC Contexts: 14040
o Max number of total CELL_PCH and URA_PCH RRC contexts: 64080
For configurations with lower number of PSFP or DCPS boards, the number of contexts available can
be got from the above values proportionally to the number of active PMC-TMUs.
It has to be noticed that these border limits are maximum values, but most of the time (with an
operational usage of the RNC) some other bottlenecks will prevent reaching these limits as explain in
the following chapter (nevertheless, the screening 6 of the counter #631
VS.RadioBearerEstablishmentUnsuccess allows to detect if some Radio Bearer Establishment are
rejected due to lack of internal RNC contexts).
It should also be noted that the context limits are maximum instantaneous values; the maximum
number of contexts that might be expected to be consumed, on average, with random traffic, is
noticeably less due to the fluctuations in random traffic.
TRAFFIC LIMITATIONS
In term of traffic for a given type of Packet Server (PS1 or DCPS), the limiting factor will be the CPU
load and internal resources consumption generated on the different PMC boards that manage the
traffic processing. As presented in chapter 3.1, the number of PMC resources depends on the market
model used. Thus to increase the RNC capacity in term of traffic it is necessary to increase the market
model used (if the current RNC is not already having 12 Packet Server boards), or to move from a
market model using PS-FP boards to a market model using DCPS boards.
In UA07 the expected capacity ratio between a market model using DCPS boards is 3 time higher
than the capacity of the same market model with PS-FP boards running in UA05.0/UA05.1 for a same
call profile. For more details, refer to RNC capacity RoadMap [A1].
The load generated on the different PMC will vary depending on the characteristics of the call profile of
the end-users. Aggressive call profiles will generate higher loads on the PMC boards and thus will
impact the RNC capacity. The RNC capacity may be limited by the Control Plane processing or the
User Plane processing (or both of them), depending on the load generated by the processing of the
procedures corresponding to the call profile.
When approaching maximum processing capacity of the RNC boards, an overload control mechanism
will be activated to prevent entering in exceptional faulty conditions due to lack of resources. See
document [A2] for the description of the overload mechanism.
As a summary, the RNC capacity in term of traffic is based on the processing capacity of the PS-FP or
DCPS boards. This capacity depends on the call profile characteristics.
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 16/24
3.3. COMMITTED CAPACITY LEVELS
For the different UTRAN releases, some commitments are taken by Alcatel-Lucent in term of RNC
capacity. As seen previously, the RNC capacity is directly dependent of the call profile to consider.
Thus, for the RNC capacity commitments, different call profiles are defined. The behavior and capacity
of the RNC with these call profiles are validated during load tests in R&D Lab to ensure the
commitments are respected.
The detailed description of the reference call profiles considered for the RNC capacity commitments
are presented in document [A1]. This document is the reference for the committed capacity levels of
the RNC. Very precise conditions in term of volume of traffic, used services and associated signaling
are considered. The associated RNC capacity results are available in this document [A1]. Please refer
to it for the corresponding values.
It is important to have in mind that the different figures presented in this document are reached for
different independent call profiles. These figures can not be got simultaneously (for instance for a
9370 RNC with 12 PSFP, 3900 Erlang can not be got with 176 Mbps on Iu interface). They can not be
considered as commitments for any conditions of usage as they are associated to precise hypothesis
in term of signaling and services. Moreover these figures are got in a context where the features Full
Event Trigger and Iub Silent Mode are enabled, and thus are valid only in this context.
All the previous figures are got in conditions where an engineering margin is kept on the RNC. This
engineering margin corresponds is specify for each CPU type see table below.
Table 4: CPU Engineering Limit per Release
This does not mean that above this CPU load value the RNC will enter in overload, but it corresponds
to a margin taken to ensure the RNC will be able to handle some variations of traffic while keeping a
good Quality Of Service (QOS) for the end users.
All dimensioning exercises made by Alcatel-Lucent people for Pre-Sales of Post-Sales needs should
consider this engineering limit.
The Engineering Limit is the maximum resource utilization caused by conforming traffic at which
reasonable performance can be achieved. Conforming traffic means traffic that meets a particular set
of assumptions. Reasonable performance means a quality of service defined by ALU RNC Design.
The assumptions include that the traffic is assumed equivalent to a stationary random process, which
means the underlying statistics of the traffic, including mean and variance, do not significantly change
over the course of the OBS interval. The level of reasonable performance assumed includes rejection
of up to 1% of (repeated) RRC Connection Requests due to overload, and the frequent suspension of
call trace. For customers that demand more stringent operation, Engineering is advised to debate the
Engineering Limit and RNC Capacity.
CPU Type UA06 UA7.0 UA7.1
PMC-RAB (DSCP) 80% 80% 80%
PMC-PC (DSCP) 70% 70% 80%
PMC-TMU (DSCP) 70% 70% 80%All others DSCP CPU
and all PSFP CPU 70% 70% 70%
Release
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 17/24
3.4. RNC CAPACITY REPRESENTATION
It becomes common to try to draw the RNC capacity to allow comparison against reference RNC
capacity or to compare various RNC of the same network.
The representation is a two dimensions graph with Erlang and Data Bandwidth for each axis.
Figure 4: RNC Capacity representation
The graph above represents the RNC Capacity for various Alcatel-Lucent Call Profiles. The various
capacities cannot be aligned on one nice line between Voice only (Max Erlangs) and Office Premium
(Max Data Throughput) see [A1]. This shows that capacity is strongly dependant on the call profile.
For example, even if Data only and Office premium are data they do not have the same type of
signaling profile, so final capacity is not the same.
A study on a real network was done, and provides this kind of results:
Figure 4: Network RNC Capacity analysis
Capa RNC Data Bw/Erlangs
0
2000
4000
6000
8000
10000
12000
0 100 200 300 400 500 600 700
Data Bw
Erlangs
All Voice
All Data
Mixed
Mixed HSDPA
Office Premium
Video Streaming
Service Mixed Profile 6
Service Mixed Profile 5
Service Mixed Profile 7
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 18/24
This means that some work need to be performed to understand why the capacity of the RNCs in the
circle are below the average of this network.
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 19/24
4. OPERATIONAL VIEW ON RNC CAPACITY
4.1. GENERAL CONSIDERATIONS AND RECOMMENDATIONS
4.1.1 GENERAL VIEW
As presented in the previous chapters, the RNC capacity is directly linked to the call profile of the end
users covered by this RNC. By this way, the capacity of RNC in term of end users covered may be
different inside a same network according to the behavior of the users (mobility), to the services
offered, to the network characteristics (LAC/RAC boundaries, covered area, number of NodeB and
cells, etc ).
To maintain a good QOS for each RNC, it is important to analyze regularly the traffic capacity offered
locally by these RNC.
To have a view on the capacity margin of an operational RNC, a monitoring of the different RNC
boards loads involved in traffic processing should be done. From UA05.0 a counter allows to monitor
the different PMC loads: this counter is the counter:
#20202 VS.ApCpuUtilizationAvg
This counter is available for each PMC id of each PS-FP or DCPS slot. Thus, with the mapping table
presented in chapter 3.1, it is possible to see the load for each type of PMC. This counter should be
observed at the lowest granularity, maximum hour granularity. As explained previously, the RNC may
either be Control Plane limited or User Plane limited. Thus all types of PMC should be studied
because it will not be always the same type of PMC that will be the limiting factor.
When working at low level of CPU, there is no risk of traffic limitation due to the maximum capacity of
the concerned RNC. When the CPU load on the PMC becomes significant, specific attention should
be set on this capacity subject. A rough value to consider for the CPU load of the different types of
PMC is described in section 3.3. (This value is a relatively rough target since, depending on the traffic
variations; RNCs may reach congestion situations with different average CPU load), this value is
usually the engineering limit.
To ensure that none of the PMC reaches its engineering limit a counter is defined: #20201
ApCpuUtilizationHistogram. The sum of the indicators from index 3 to 8 should remain below 900 for a
quarter hour observation.
So as explained above, the general rough recommendation is to monitor the different boards by PMC
type, and to have for the most loaded PMC type, an average load of the limit provided in section 3.3.
Associated to this global recommendation, it is recommended to correlate the CPU load observed on
the most loaded PMC type, with the counters:
#0404 NT_Rrc_Connection_Reject (screening 6),
#0810 NT_Unhandled_paging_request_CS (screening 4).
#0811 NT_Unhandled_paging_request_PS (screening 4).
These counters indicate the number of RRC connection requests and paging requests rejected due to
overload conditions. Some acceptable levels of ratio of RRC connection requests and paging request
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 20/24
rejected should be targeted (according to customer objective in term of QOS). If these targets are not
respected, actions should be taken to decrease the load on the RNC boards (see some proposals in
next chapter).
From UA05 some other counters should also be observed to have a view on other rejections
performed:
#1521: NT_Ovin_CnAccLa_Discard (screening 0, 1 and 2)
Number of Downlink or uplink messages discarded at CN Access La on PMC-RAB.
#1522: NT_Ovin_Ni_Discard
Number of Core Network messages received in PMC-NI (screening 0 and 1) with amount of
discarded messages (screening 2 and 3)
#1523: NT_Ovin_Rab_Rrc_Conn_Req_Discard
Total RRC connection messages dropped due to panic overload
It has to be noticed also that alarms are generated by the RNC if the Overload level critical is
reached. These alarms should be clearly observed. Their references are: 7070 2007 and 7070 2008
(Inode SW part) and also ANO_OVERLOAD_THRESHOLD (CNode SW part). For more detail on
these alarms see document [A3].
In addition to the observation of the load of the PMC boards, it will be also necessary to observe
carefully the IU throughput managed by the RNC. This will be mandatory in the cases where the
16pOC3/STM1 are PQC one. If the border limits of these boards (310 Mbps for the 16pOC3/STM1
PQC boards) are approached, some actions should be taken to upgrade accordingly the HW of the
RNC (replacement of 16pOC3/STM1 PQC boards by 16pOC3/STM1 MS3 boards).
Note: such situations should be anticipated by previous analyses of the expected traffic on the RNC
before entering into these situations.
4.1.2 COUNTERS MANAGEMENT SPECIFICITY
Another operational evolution is introduced in UA06.0: it concerns the introduction of a mechanism to
limit the number of active observation counters. This mechanism as been introduced, due to the large
number of cells to be supported, to the large number of new additional counters introduced at each
release and due to the limited memory available on the boards. The following principle is applied: the
maximum number of possible active counter instances depends on the type of CP boards (different
thresholds are defined for the configurations using CP3 boards and for the configurations using CP4
boards). To manage the active counters, a counter list is introduced in UA06 for the RNC. This one
specifies the counters to be activated for a given RNC. The number of these counters should respect
the maximum number of possible active counters. Else, in case, where the number of requested
counters is higher than the threshold applicable to the current RNC HW configuration, the RNC will
automatically limit the number of active counters based on a priority level that is associated to each
counter.
For configurations with CP3 boards (max 1200 cells), the maximum number of supported counters is:
4.75 millions. For configurations with CP4 boards (max 2400 cells), the maximum number of
supported counters is 9.5 millions. In case where 80% of the number of active counters is reached a
warning is raised: ANO_PF_GPO_LIMIT_80_PC_REACHED. When the number of active counters
reaches the maximum limit, a minor alarm is raised and the counters having the lowest priority are
filtered (this alarm is:
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 21/24
ANO_PF_GPO_LIMIT_100_PC_REACHED_AND_LOW_PRIORITY_COUNTERS_DISABLED). It is
thus recommended to observe if the warning at 80% is raised, and if there is a risk of reaching the
limit, it is recommended to modify the RNC counter List (suppress some non mandatory counters in it)
to be sure to remain under the maximum limit and then control the RNC active counters.
4.1.3 PMC-TMU SPECIFIC CONCERN
Moreover, it has to be noticed that some CPU load differences inside a same type of PMC type may
exists between the different PMC. This is specially the case for the PMC-TMU on which the different
NodeB are allocated.
By default, the allocation of NodeB on the PMC-TMU is made statically after the definition of the
NodeB (or after build) according to the less loaded Iub in term of ports and also according to NodeB
type. Thus from a real time activity perspective, we may have unfortunately some most loaded NodeB
collocated on the same TMU during the Busy Hour. Thus the CPU load between the different PMC-
TMU could be not perfectly balanced.
From UA06.0 it is possible to modify this distribution: NodeB are indeed set into Service Groups.
There are as many Service Groups possible as the number of active TMU. The RNC distributes the
different Service Groups on the different active TMU. In case of specific events like PS board restart or
maintenance activity on one of the PS boards, the RNC redistributes the Service Groups dynamically
on the active TMU.
From UA06.0 it is possible to specify the Service Group in which will be set a NodeB (parameter
ServiceGroupId). By the same way it is possible to know on which NodeBs a given Service Group
has been positioned. It is not possible to predict on which TMU a ServiceGroup will be mapped, it is a
dynamic process that can evolutes due to TMU restart. But it is possible at a specific time to know the
association TMU-ServiceGroup, so to perform some post-processing. (see below)
So, with a monitoring of the CPU load of the different TMU, it is possible to modify the affectation of
some of the NodeB in order to get some PMC-TMU boards that would be well balanced. The facility
allows also, for instance, to set the NodeB that cover the same important area on different TMU. This
may be interesting for redundancy question in order to have, in case of one TMU loss, one NodeB
located on another TMU still covering the concerned area.
A specific study on Orange network can be viewed at: https://wcdma-ll.app.alcatel-
lucent.com/livelink/livelink.exe?func=ll&objId=54533496&objAction=browse&sort=name&viewType=1
Since UA7.1.3 the feature FRS 106904 TMU load balancing improvement review completely the load
balancing mechanism. A dynamic table is permanently up to date ranking all the TMU including the
passive one by their capability of handling a new incoming call. At each incoming call the local TMU
will decide if the local TMU is the best candidate to handle the call or will redistribute it to the best
TMU.
When upgrading a RNC full ATM to a RNC ATM + IP, if the market model was having 12 PS-FP, it will
now be needed to suppress 2 PS-FP. A capacity analysis should be performed to ensure that no
impact on the traffic will occur in that case. Else, it has to be studied (in case where the RNC was not
equipped with DCPS) if a configuration using DCPS boards may be used. In the case where the RNC
was already full of DCPS and where an impact is expected, a part of the traffic should be redirected to
another RNC (NodeB reparenting) or a new RNC deployed.
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 22/24
4.2. POSSIBLE ACTIONS FOR CAPACITY ENHANCEMENTS
The intent of this chapter is not to propose an exhaustive list of the actions that may improve the RNC
capacity, but to provide some proposals to help enhancing the RNC capacity. This list is to be
completed based on returns on experience received.
Thus, the following possible actions may be considered:
- Enabling of features that improves RNC capacity like Iub Silent Mode, Full Event Trigger (The
engineering recommendation is to have them enabled by default).
- Decrease some event frequencies like Measurement Reports if it is compatible with QOS aspects,
- Modify AO timers to limit some release and establishment of Data calls,
- Limit the usage of call trace feature
- Study if some reorganization of LAC and RAC boundaries may help in decreasing RNC loads
- Addition of new Packet Server boards inside the RNC if it is possible to work with a bigger Market
model.
- Migration from a RNC market model using PS-FP boards to a market model using DCPS boards if
the RNC is not already equipped with DCPS.
- If the RNC is equipped with 16pOC3STM1 PQC boards, it has to be verified that these boards are
not reaching their limitation (310 Mbps Iu DL traffic). Else they should be replaced by 16pOC3STM1
MS3 boards.
- Reparenting of some NodeB to less loaded RNC
- Addition of new RNC on the network
-
In addition to these actions, from UA05.0, operators have the possibility to enable the feature called
Automatic Access/Class Barring on service outrage. This one allows offering a re-enforced
protection for the elements of the system (not only RNC but also Core Network elements). The
principle is, in case where either the CN is in overload, either an IU failure is detected or either the
RNC is in overload, to automatically generate some Access class barring or Cell barring orders. This
has the interest to block at the UE level some new incoming requests on a system that is not ready to
accept them. For more information about this feature, associated mechanism and parameters please
refer to documents [A2] and [R5].
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 23/24
5. RNC CAPACITY ESTIMATIONS
For Pre-sales or Post-sales activities, the estimation of the RNC capacity is often necessary. For this
activity, a dedicated tool: RCT: RNC Capacity Tool is developed and maintained for each release. This
one allows performing some RNC Capacity estimations based on a call profile characteristics. This
tool is developed by R&D team in parallel with RNC product evolutions.
This tool is for an internal usage; Pre-Sales teams and Engineering teams are able to use it for
network capacity analysis. Some services about network capacity may be provided to customers with
the help of this tool.
-
RNC Capacity Engineering Guide
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 24/24
6. ABBREVIATIONS AND DEFINITIONS
6.1. ABBREVIATIONS
NPO Network Performance Optimizer
OMU Operation and Maintenance Unit
PMC PCI Mezzanine Card
PMC-M PMC Master
PMC-NI PMC Network Interface
PMC-OMU PMC Operation and Maintenance Unit
PMC-PC PMC Protocol Converter
PMC-RAB PMC Radio Access Bearer
PMC-TMU PMC Traffic Management Unit
QOS Quality of Service
RNC Radio Network Controller
TMU Traffic Management Unit
6.2. DEFINITIONS
END OF DOCUMENT