You are on page 1of 24

RNC Capacity Engineering Guide

Document number: Document issue: Document status: Date: UMT/IRC/INF/022089 03.06 Standard 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 AlcatelLucent. 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

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

RNC Capacity Engineering Guide


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

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

RNC Capacity Engineering Guide

CONTENTS
1. INTRODUCTION............................................................................................................................5 1.1. 1.2. 1.3. 2. OBJECT ....................................................................................................................................5 SCOPE OF THIS DOCUMENT .......................................................................................................5 AUDIENCE FOR THIS DOCUMENT ................................................................................................5

RELATED DOCUMENTS ..............................................................................................................6 2.1. 2.2. APPLICABLE DOCUMENTS ..........................................................................................................6 REFERENCE DOCUMENTS ..........................................................................................................6

3.

9370 RNC CAPACITY PROBLEMATIC........................................................................................7 3.1. 3.2. OVERVIEW OF 9370 RNC ARCHITECTURE .............................................................................7 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. 4. RNC CAPACITY REPRESENTATION ...........................................................................................17

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. 6. RNC CAPACITY ESTIMATIONS ................................................................................................23 ABBREVIATIONS AND DEFINITIONS.......................................................................................24 6.1. 6.2. ABBREVIATIONS ......................................................................................................................24
DEFINITIONS ...........................................................................................................................24

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

RNC Capacity Engineering Guide

1.
1.1.

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

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

RNC Capacity Engineering Guide

2.
2.1.

RELATED DOCUMENTS
APPLICABLE DOCUMENTS
[A1] [A2] [A3] [A4] UMT/PLM/INF/4862 UMT/SYS/DD/8005 NN 20500-024 UMT/COM/INF/23886 UMTS RNC Capacity Roadmap RNC Overload UMTS RNC and POC Alarms Changes to Alcatel-Lucent UMTS RNC Portfolio Evolution in UA05.1 and UA06

2.2.

REFERENCE DOCUMENTS
[R1] [R2] [R3] [R4] [R5] [R6] UMT/IRC/APP/13736 UMT/IRC/APP/0166 UMT/IRC/APP/0164 UMT/IRC/APP/0050 UMT/IRC/DD/0011 UMT/IRC/APP/023122 RNC Product Engineering Information Iu Transport Engineering Guide IuB Transport Engineering Guide IuR transport Engineering Guide UTRAN Parameter Users Guide UMTS 7670 RSP/ESE Product Engineering Information

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

RNC Capacity Engineering Guide

3.
3.1.

9370 RNC CAPACITY PROBLEMATIC


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 o 16pOC3STM1 PQC boards 16pOC3STM1 MS3 boards.

from UA05.1.2 two types of Packet Server boards are available: o o Packet Server: PS-FP (that may also be called PS1 in the following of the document) Dual Core Packet Server: DCPS.

from UA06.0 two types of CP boards are available: o o CP3 boards 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, )

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

RNC Capacity Engineering Guide


- 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 N<=8, P=2 for N>8 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 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 card/Pmc CP CP PSFP PSFP PSFP PSFP PSFP PSFP OC3 OC3 PSFP PSFP PSFP PSFP PSFP PSFP 0 1 PMC ID within PSFP 2 3 4 5

PMC-M PMC-M RAB RAB RAB RAB

TMU TMU TMU TMU TMU TMU

RAB RAB NI NI RAB RAB

RAB RAB RAB RAB RAB RAB

PC PC PC PC PC PC

RAB RAB OMU OMU RAB RAB

RAB RAB RAB RAB RAB RAB

TMU TMU TMU TMU TMU TMU

RAB RAB RAB RAB RAB RAB

RAB RAB RAB RAB RAB RAB

PC PC PC PC PC PC

RAB RAB TMU TMU RAB RAB

Figure 1: Case full ATM with 12 PS boards - Allocation of PMC on the different PS-FP or DCPS

slot 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

card/Pmc CP CP PSFP PSFP PSFP PSFP PSFP PSFP OC3 OC3 PSFP PSFP PSFP PSFP 4GIGE 4GIGE

PMC ID within PSFP 2 3

PMC-M PMC-M RAB RAB RAB RAB

TMU TMU TMU TMU TMU TMU

RAB RAB NI NI RAB RAB

RAB RAB RAB RAB RAB RAB

PC PC PC PC PC PC

RAB RAB OMU OMU RAB RAB

RAB RAB RAB RAB

TMU TMU TMU TMU

RAB RAB RAB RAB

RAB RAB RAB RAB

PC PC PC PC

RAB RAB TMU TMU

Figure 2: Case mix ATM/IP with 10 PS boards- Allocation of PMC on the different PS-FP or DCPS

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

RNC Capacity Engineering Guide


PMC ID within PSFP 2 3

slot 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

card/Pmc CP CP PSFP PSFP PSFP PSFP PSFP PSFP PSFP PSFP PSFP PSFP PSFP PSFP 4GIGE 4GIGE

PMC-M PMC-M RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB

TMU TMU TMU TMU TMU TMU TMU TMU TMU TMU TMU TMU

RAB RAB NI NI RAB RAB RAB RAB RAB RAB RAB RAB

RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB

PC PC PC PC PC PC PC PC PC PC PC PC

RAB RAB OMU OMU RAB RAB RAB RAB RAB RAB TMU TMU

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 o o o o 9370 RNC with 4 PSFP, 9370 RNC with 6 PSFP, 9370 RNC with 8 PSFP, 9370 RNC with 10 PSFP, 9370 RNC with 12 PSFP.

for RNC equipped with DCPS: o o o o o 9370 RNC with 4 DCPS, 9370 RNC with 6 DCPS, 9370 RNC with 8 DCPS, 9370 RNC with 10 DCPS, 9370 RNC with 12 DCPS.

No mixed configuration using PSFP and DCPS is supported.

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

RNC Capacity Engineering Guide


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
Modules w 4 PSFP ATM Fabric CP3 16pOC3/STM1 4pGiGE PS-FP Modules w 4 DCPS ATM Fabric CP(CP3 or CP4) 16pOC3/STM1 4pGiGE DCPS 2 2 2 0 4 MIX 2 2 2 2 4 IP 2 2 0 2 4 ATM 2 2 2 0 6 w 6 DCPS MIX 2 2 2 2 6 IP 2 2 0 2 6 ATM 2 2 2 0 8 2 2 2 0 4 MIX 2 2 2 2 4 IP 2 2 0 2 4 ATM 2 2 2 0 6 w 6 PSFP MIX 2 2 2 2 6 IP 2 2 0 2 6 ATM 2 2 2 0 8 9370 RNC w 8 PSFP MIX 2 2 2 2 8 9370 RNC w 8 DCPS MIX 2 2 2 2 8 IP 2 2 0 2 8 w 10 DCPS ATM 2 2 2 0 10 MIX 2 2 2 2 10 IP 2 2 0 2 10 w 12 DCPS ATM 2 2 2 0 12 MIX N/A N/A N/A N/A N/A IP 2 2 0 2 12 IP 2 2 0 2 8 w 10 PSFP ATM 2 2 2 0 10 MIX 2 2 2 2 10 IP 2 2 0 2 10 w 12 PSFP ATM 2 2 2 0 12 MIX N/A N/A N/A N/A N/A IP 2 2 0 2 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 2 2 2 4 10 4 w 6 PSFP or DCPS 2 2 2 6 18 6 W 8 PSFP or DCPS 2 2 2 8 26 8 w 10 PSFP or DCPS 2 2 2 10 32 12 w 12 PSFP or DCPS 2 2 2 12 40 14

PMC-M PMC-OMU PMC-NI PMC-PC PMC-RAB PMC-TMU

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

RNC Capacity Engineering Guide


PMC-id and number 2 3

Slot Card 0 0 CP4 1 CP4 2 DCPS PMC-M 3 DCPS PMC-M 4 DCPS RAB 5 DCPS RAB 6 DCPS RAB 7 DCPS RAB 8 16p OC3 9 16p OC3 10 DCPS RAB 11 DCPS RAB 12 DCPS RAB 13 DCPS RAB 14 4pGigE 15 4pGigE Or

TMU TMU TMU TMU TMU TMU

RAB RAB NI NI RAB RAB

RAB RAB RAB RAB RAB RAB

PC PC PC PC PC PC

RAB RAB OMU OMU RAB RAB

TMU TMU TMU TMU

RAB RAB RAB RAB

RAB RAB RAB RAB

PC PC PC PC

RAB RAB TMU TMU

Slot Card 0 1 0 CP4 1 CP4 2 DCPS PMC-M TMU RAB RAB 3 DCPS PMC-M TMU RAB RAB 4 DCPS RAB TMU NI RAB 5 DCPS RAB TMU NI RAB 6 DCPS RAB TMU RAB RAB 7 DCPS RAB TMU RAB RAB 8 16p OC3 9 16p OC3 10 DCPS RAB TMU RAB RAB 11 DCPS RAB TMU RAB RAB 12 DCPS RAB TMU RAB RAB 13 DCPS RAB TMU RAB RAB 14 4pGigE 15 4pGigE In that last case the RNC runs with 30 PMC-RAB and 14 TMUs

PMC-id and number 2 3

PC PC PC PC PC PC

RAB RAB OMU OMU RAB RAB

PC PC PC PC

TMU TMU TMU TMU

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

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

RNC Capacity Engineering Guide


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

RNC Capacity Engineering Guide


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

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

RNC Capacity Engineering Guide


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 Max NodeB Max Cells 360 360 w 6 PSFP or DCPS 600 600 W 8 PSFP or DCPS 800 800 w 10 PSFP or DCPS 1200 1200 w 12 PSFP or DCPS 1200 1200

9370 RNC Market Models with CP4 boards w 4 DCPS Max NodeB Max Cells 600 600 w 6 DCPS 1000 1000 W 8 DCPS 1400 1400 w 10 DCPS 2000 2000 w 12 DCPS 2400 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
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

RNC Capacity Engineering Guide


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.

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

RNC Capacity Engineering Guide

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.
CPU Type PMC-RAB (DSCP) PMC-PC (DSCP) PMC-TMU (DSCP) All others DSCP CPU and all PSFP CPU UA06 80% 70% 70% 70% Release UA7.0 UA7.1 80% 80% 70% 80% 70% 80% 70% 70%

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.

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

RNC Capacity Engineering Guide

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

Capa RNC Data Bw/Erlangs


12000 10000 8000 Erlangs 6000 4000 2000 0 0 100 200 300 400 500 600 700 Data Bw All Voice All Data Mixed Mixed HSDPA Office Premium Video Streaming Service Mixed Profile 6 Service Mixed Profile 5 Service Mixed Profile 7

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

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

RNC Capacity Engineering Guide


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.

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

RNC Capacity Engineering Guide

4.
4.1.

OPERATIONAL VIEW ON RNC CAPACITY


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

RNC Capacity Engineering Guide


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

RNC Capacity Engineering Guide


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

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

RNC Capacity Engineering Guide

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

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

RNC Capacity Engineering Guide

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.

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

RNC Capacity Engineering Guide

6.
6.1.

ABBREVIATIONS AND DEFINITIONS


ABBREVIATIONS
NPO OMU PMC PMC-M PMC-NI PMC-OMU PMC-PC PMC-RAB PMC-TMU QOS RNC TMU Network Performance Optimizer Operation and Maintenance Unit PCI Mezzanine Card PMC Master PMC Network Interface PMC Operation and Maintenance Unit PMC Protocol Converter PMC Radio Access Bearer PMC Traffic Management Unit Quality of Service Radio Network Controller Traffic Management Unit

6.2.

DEFINITIONS

END OF DOCUMENT

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

You might also like