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
Alcatel·Lucent 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 Alcatel·Lucent written authorization

UMT/IRC/INF/022089

03.06/ EN

Standard

4/7/2011

Page 2/24

01 / EN.2 content 17/MARCH/2011 Issue 03.1. Preliminary Adding UA7. Standard Adding UA7.03 / EN.06 / EN. Preliminary Add chapter on RNC capacity representation Correction for PMC-PC engineering limit Document release for UA07.03 / EN. Draft Document release for UA07. UA06 Preliminary release.1 DR4 1/FEB/2010 Issue 03. Preliminary Modifications see review minutes Document release for UA07.02 / EN.04 / EN.3 content Passing on or copying of this document. Standard Document release for UA06 DR5 18/JAN/2010 Issue 03.RNC Capacity Engineering Guide Document update after review. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03.1. 05/JUN/2009 Issue 02.1 26/JAN/2010 Issue 03.1 DR4 1/JUNE/2010 Issue 03.06/ EN Standard 4/7/2011 Page 3/24 .

............3 PMC-TMU specific concern .........................................19 4..................................1 General View............................................2.. APPLICABLE DOCUMENTS ........ RNC CAPACITY REPRESENTATION .............................................................................6 2............2.................. GENERAL CONSIDERATIONS AND RECOMMENDATIONS ......... REFERENCE DOCUMENTS ...............................1..........................................................................1....................................................19 4...........................................................................................5 1............... DEFINITIONS ......... RNC CAPACITY ESTIMATIONS ................................................................................................2...................2 RNC Coverage capacity.........7 3...................5 RELATED DOCUMENTS ................... OBJECT .............5 1...........................12 3.2 Counters management specificity ................................................................................14 3.1........................................3 RNC Traffic Capacity ................................................................................................................23 6.............1................................................06/ EN Standard 4/7/2011 Page 4/24 ..................................... POSSIBLE ACTIONS FOR CAPACITY ENHANCEMENTS .......16 3..... 4.............. OVERVIEW OF 9370 RNC ARCHITECTURE .....................4..1................1 RNC capacity In Connectivity.........................24 6.......................................22 5.. DIFFERENT CAPACITY ASPECTS ............2............................................................ COMMITTED CAPACITY LEVELS ....................................................................1.............6 2.24 Passing on or copying of this document...............................................17 OPERATIONAL VIEW ON RNC CAPACITY ....12 3.....................1..........................................................................................................RNC Capacity Engineering Guide CONTENTS 1........................................................................ 2..........................1...................................................................................................................14 3...............................................2......2............ SCOPE OF THIS DOCUMENT ........................................................................................... 3.......................................................................................21 4...2...................................3.......7 3..........................2.......................................................... AUDIENCE FOR THIS DOCUMENT ......................... use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03..................6 9370 RNC CAPACITY PROBLEMATIC.................................. ABBREVIATIONS AND DEFINITIONS....................20 4.....................................................5 1.....................................................24 6..... ABBREVIATIONS .................................................................................... INTRODUCTION.3.........................19 4.......

use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. INTRODUCTION 1.1.2.1 and UA7.3. It presents capacity problematic with Alcatel-Lucent 9370 RNC from an Engineering point of view. OBJECT The object of this document is to provide some guidelines regarding RNC capacity.06/ EN Standard 4/7/2011 Page 5/24 . 1.1.1. SCOPE OF THIS DOCUMENT This document is applicable to 9370 RNC for release UA07. in RNC capacity exercises from an operational point of view. in Pre-Sales or Post-Sales context.RNC Capacity Engineering Guide 1.1 (applicable for both UA7.3). Passing on or copying of this document. AUDIENCE FOR THIS DOCUMENT It is destined to regional engineering teams and other teams involved. 1.

1. APPLICABLE DOCUMENTS 2. [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.06/ EN Standard 4/7/2011 Page 6/24 .2.1 and UA06 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 Passing on or copying of this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03.RNC Capacity Engineering Guide 2. RELATED DOCUMENTS 2.

PM. - PMC-NI (1:1): managing SS7 stacks (layers MTP3 & SCCP) - PMC-OMU (1:1): managing OAM relations between RNC and OMC (CM.1. OVERVIEW OF 9370 RNC ARCHITECTURE 9370 RNC architecture is presented in document [R1]. from UA05. (For DCPS it may be considered also that each of them contains 6 “logical” PMC). …) – Managed in 1:1 mode (operational/hot stand-by) . IuPS.from UA05. IuBC. It has to be noticed that: .CP boards (Control Process boards managing RNC platform. FM.06/ EN Standard 4/7/2011 Page 7/24 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. from UA06.From UA6. 9370 RNC CAPACITY PROBLEMATIC 3. The main modules of 9370 RNC are the following ones: . These boards are optional. …) Passing on or copying of this document. A dedicated role is applied to each PMC. For a more complete view of the product.0 two types of CP boards are available: o CP3 boards o CP4 boards .0 4pGiGE boards are introduced (may be optional in case of full ATM configuration) Each Packet Server board contains 6 PMC (PCI Mezzanine Card).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.16pOC3/STM1 boards (Interfaces boards providing ATM access to IuB. IuR.1. manages also associated disks) – Managed in 1:1 mode (operational/hot stand-by) . This current chapter gives a short overview of the RNC architecture related to capacity aspects.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. IuPC.PS boards (“Packet Server” processing boards managing calls and traffic for the RNC) – Managed in N+P mode . document [R1] should be used.RNC Capacity Engineering Guide 3. The following different PMC main roles are roughly the following: - PMC-M (1:1): Master PMC managing PMC organization and supervision inside the RNC. IuCS.4pGiGE boards (Interfaces boards providing direct IP interface to the RNC).Fabric modules (internal RNC switching modules for internal exchanges of messages) – managed in 1+1 mode (full duplication of traffic on the fabric) .

MAC.PMC-TMU (N+P: P=1 for N<=8. RRM… The allocation of the PMC roles on the PS-FP (or DCPS) is presented in the following figures. radio protocol handling (RLC. Macro diversity. 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 PMC ID within PSFP 2 3 0 1 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 TMU TMU TMU TMU TMU TMU RAB RAB RAB RAB RAB RAB 4 5 RAB RAB RAB RAB RAB RAB PC PC PC PC PC PC RAB RAB OMU OMU 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 . load sharing for ATM configuration . … .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 0 1 PMC-M PMC-M RAB RAB RAB RAB TMU TMU TMU TMU TMU TMU RAB RAB NI NI RAB RAB RAB RAB RAB RAB TMU TMU TMU TMU RAB RAB RAB RAB 4 5 RAB RAB RAB RAB RAB RAB PC PC PC PC PC PC RAB RAB OMU OMU RAB RAB RAB RAB RAB RAB PC PC PC PC RAB RAB TMU TMU Figure 2: Case mix ATM/IP with 10 PS boards.RNC Capacity Engineering Guide . …).06/ EN Standard 4/7/2011 Page 8/24 .up to 12): Protocol Converter (Segmentation & reassembly) between IP/AAL2 and IP/AAL5. NBAP. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. RNSAP. P=2 for N>8 – up to 14): Call and cell processing.Allocation of PMC on the different PS-FP or DCPS Passing on or copying of this document. RANAP.PMC-PC (N+1 .PMC-RAB (N+1 – up to 40): Bearer processing.

o 9370 RNC with 12 DCPS. Thus for lower market models only the first slots of PSFP are full). o 9370 RNC with 6 DCPS. The different supported market models in UA07. o 9370 RNC with 8 DCPS. 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.Allocation of PMC on the different PS-FP or DCPS The role of the different PMC can not be modified.RNC Capacity Engineering Guide 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 0 1 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 PMC ID within PSFP 2 3 RAB RAB NI NI RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB RAB 4 5 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 . The above figure presents the implementation of these PMC roles for a 12 or 10 PS-FP (or DCPS) market model. Passing on or copying of this document. Different 9370 RNC supported market models exist according to the number of Packet Server present in the shelf. for RNC equipped with DCPS: o 9370 RNC with 4 DCPS. For smaller market models. No mixed configuration using PSFP and DCPS is supported.06/ EN Standard 4/7/2011 Page 9/24 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. o 9370 RNC with 6 PSFP. o 9370 RNC with 10 PSFP. o 9370 RNC with 10 DCPS. o 9370 RNC with 8 PSFP. o 9370 RNC with 12 PSFP.1 are: - - for RNC equipped with PS-FP: o 9370 RNC with 4 PSFP. The allocation of these roles is static depending on the PS-FP (or DCPS) slot number and PMC id.

06/ EN Standard 4/7/2011 Page 10/24 . This feature allows changing PMC-RAB in slot 10 and 11 PMC id 5 by PMC-TMU. 9370 RNC Market Models Modules 9370 RNC w 4 PSFP w 6 PSFP w 8 PSFP w 10 PSFP w 12 PSFP 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 Modules 9370 RNC w 4 DCPS w 6 DCPS w 8 DCPS w 10 DCPS w 12 DCPS 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. Then since UA7.3 both following configuration are possible for slot 10 and 11: Passing on or copying of this document.1.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).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. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03.

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.RNC Capacity Engineering Guide 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 1 PMC-id and number 2 3 4 5 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 4 5 PC PC PC PC PC PC RAB RAB OMU OMU RAB RAB PC PC PC PC TMU TMU TMU TMU Or PMC-id and number 2 3 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 Estimated TMU capacity gain is between 12% and 18%. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. At feature introduction this gain must be assessed. With the different possible board types.06/ EN Standard 4/7/2011 Page 11/24 .

in case of full IP RNC - At least one type of board between 16pOC3STM1 and 4pGiGE must be present in the RNC. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. Nevertheless. Thus two 16 ports OC3/STM1 are available for the access to the interfaces whatever the market model is. They are managed in a 1:1 mode (Operational/Stand By). hairpins were also needed for sPVC (Soft PVC) management. Prior to UA06. - the 16pOC3/STM1 MS3 board (optional board that may be introduced from UA05 release). From UA06. - no “mixity” is possible between CP3 and CP4 boards. Two generations of 16pOC3/STM1 boards are available: - the 16pOC3/STM1 PQC board.1 RNC CAPACITY IN CONNECTIVITY ATM CONNECTIVITY The ATM external connectivity of the RNC is provided by the 16pOC3/STM1 boards. according to the configuration needed for the interfaces. For RNC on which these hairpins were used in the previous releases. - In UA7.2. - no “mixity” is possible between PSFP and DCPS boards. Passing on or copying of this document.0 there is no more need for such hairpins.2.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. 3. some Hairpins. three different aspects have to be considered for the RNC: - Connectivity - “Coverage” - Traffic 3.1 16pOC3STM1 become optional.06/ EN Standard 4/7/2011 Page 12/24 . 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. 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. DIFFERENT CAPACITY ASPECTS From a capacity perspective. it is then possible now to remove them and thus free some external ports if needed. Both types of boards offer 16 OC3/STM1 ports.

use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. In term of Iu DL traffic the 16pOC3/STM1 PQC has a maximum capacity of 310 Mbps (at applicative level). please refer to documents [R2]. 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). SDH or Sonet. 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.1. Each one of the board provide 4 Giga Ethernet external ports (there is thus of total of 8 Giga Ethernet ports available per RNC). OC12/STM4 and OC48/STM16 speeds. These IP access are managed by the 4pGiGE boards. optical STM1/OC3 VC4 level and VC12 level. the 16pOC3/STM1 MS3 boards should be used.5 Gbps IP forwarding (Note that interface physical layer can support up to 16 x 155 Mb/s = 2480 Mb/s). This constraint does not exist with the 16pOC3/STM1 MS3 board that supports up to 2. This means that for mixed ATM and IP RNC. the use of a Transport Node will be necessary.RNC Capacity Engineering Guide (For more details about hairpin usage. configuration with a mixed of ATM and IP interfaces and pure IP configuration. some NodeB may be connected through a pure ATM IuB interface and some others with an hybrid IuB configuration. the two 16pOC3STM1 boards and the two 4pGiGE boards need to be present in the shelf. For configuration using a mixed of ATM and IP interfaces. PMC-PC can support up to 810 AAL2 paths each. the maximum supported market model is with 10 PSFP or DCPS boards. IP CONNECTIVITY From UA06. Gigabit Ethernet (IP/MPLS only). In UA07. Clear Channel VC4 level. STM1 electrical. Hybrid IuB may be configured on a NodeB basis: on a given RNC. Each port has a capacity of 1Gbps but the total throughput supported by a board is 2. The ALU 7670 ESE product offers E1/T1 connectivity. two types of Transport Nodes are recommended: Alcatel Lucent 7670 ESE and 7670 RSP products. The rest of the traffic is exchanged through ATM.06/ EN Standard 4/7/2011 Page 13/24 . IMA support. The connectivity offered by the 16pOC3STM1 boards are.0 it is possible to have direct IP access on Iu-PS and IuB from the RNC (optional configuration). In UA07.5 Gbps. STM1 or OC3. three types of configurations are supported pure ATM configurations. The principle of hybrid IuB is to have a mixed ATM and IP interface between the RNC and the concerned NodeB. To work with Alcatel-Lucent 9370 RNC. IP is then only used for the HSxPA interactive/background user plane traffic. The two 4pGiGE boards are managed in load sharing mode. etc … The ALU 7670 RSP product provides also a wide range of possible connectivity: optical SONET/SDH at OC3/STM1. 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). at the place of two PS boards. [R3] and [R4]). … For more information about 7670 ESE and 7670 RSP products and associated dimensioning please refer to document [R6].1. The 4pGiGE boards have to be set in the shelf in slots 14 and 15. Passing on or copying of this document. For all other needs. Two of these boards have to be set in the RNC shelf in case where direct IP accesses are used. DS3.

This means that the RNC NodeB/cell capacity is limited by the first NodeB or Cell which reaches its limit. For more details. it is recommended that the total IP traffic exchanged across the RNC (so over the two 4pGiGE boards) do not exceed 2.2.1. These values are dependent on the market model and on the hardware baselines. the RNC product has some border limits that cannot be exceeded. 3. Remark: in UA07.3 RNC TRAFFIC CAPACITY BORDER LIMITS In term of traffic capacity. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03.2 RNC COVERAGE CAPACITY Under the term coverage is here considered the maximum numbers of NodeB and cells that a RNC can support.1. For more details. 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. refer to [A1] The corresponding figures are presented in the table below. for Mobile Premium Office profile Iu Application bandwidth is 675Mbps for a 12 DCPS RNC in UA7. 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.RNC Capacity Engineering Guide For redundancy aspects. 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. For example. 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.0 the committed maximum number of supported NodeB is equal (According to Capacity Roadmap [A1]) to the maximum number of supported cells. In term of number of internal dimensioning figures.06/ EN Standard 4/7/2011 Page 14/24 .5 Gbps. refer to [A1] 3.2. To be able to support the loss of one board without any capacity impact. it is recommended to define some active and redundant paths through the two 4pGiGE boards.

It should also be noted that the context limits are maximum instantaneous values. with random traffic.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. “Aggressive” call profiles will generate higher loads on the PMC boards and thus will impact the RNC capacity. TRAFFIC LIMITATIONS In term of traffic for a given type of Packet Server (PS1 or DCPS). refer to RNC capacity RoadMap [A1]. on average. For more details. 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. an overload control mechanism will be activated to prevent entering in exceptional faulty conditions due to lack of resources. is noticeably less due to the fluctuations in random traffic.1 for a same call profile. As presented in chapter 3. The load generated on the different PMC will vary depending on the characteristics of the call profile of the end-users.RadioBearerEstablishmentUnsuccess allows to detect if some Radio Bearer Establishment are rejected due to lack of internal RNC contexts). the maximum number of contexts that might be expected to be consumed. the number of contexts available can be got from the above values proportionally to the number of active PMC-TMUs. This capacity depends on the call profile characteristics. the screening 6 of the counter #631 VS. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. 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).0/UA05. As a summary.1. See document [A2] for the description of the overload mechanism. When approaching maximum processing capacity of the RNC boards. or to move from a market model using PS-FP boards to a market model using DCPS boards. 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 number of PMC resources depends on the market model used. For a market model using 12 DCPS. The RNC capacity may be limited by the Control Plane processing or the User Plane processing (or both of them).06/ EN Standard 4/7/2011 Page 15/24 . depending on the load generated by the processing of the procedures corresponding to the call profile. the RNC capacity in term of traffic is based on the processing capacity of the PS-FP or DCPS boards. Passing on or copying of this document. It has to be noticed that these border limits are maximum values. 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. the limiting factor will be the CPU load and internal resources consumption generated on the different PMC boards that manage the traffic processing.

Passing on or copying of this document. Moreover these figures are got in a context where the features Full Event Trigger and Iub Silent Mode are enabled. The Engineering Limit is the maximum resource utilization caused by conforming traffic at which reasonable performance can be achieved. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. “Reasonable performance” means a quality of service defined by ALU RNC Design.RNC Capacity Engineering Guide 3.0 UA7. some commitments are taken by Alcatel-Lucent in term of RNC capacity. and thus are valid only in this context. It is important to have in mind that the different figures presented in this document are reached for different independent call profiles. The level of reasonable performance assumed includes rejection of up to 1% of (repeated) RRC Connection Requests due to overload. This document is the reference for the committed capacity levels of the RNC. 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.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. The assumptions include that the traffic is assumed equivalent to a stationary random process. These figures can not be got simultaneously (for instance for a 9370 RNC with 12 PSFP. for the RNC capacity commitments. 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. Engineering is advised to debate the Engineering Limit and RNC Capacity. 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. 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.3. All the previous figures are got in conditions where an engineering margin is kept on the RNC. including mean and variance. As seen previously. All dimensioning exercises made by Alcatel-Lucent people for Pre-Sales of Post-Sales needs should consider this engineering limit. different call profiles are defined. The associated RNC capacity results are available in this document [A1]. Thus.06/ EN Standard 4/7/2011 Page 16/24 . Very precise conditions in term of volume of traffic. Please refer to it for the corresponding values. and the frequent suspension of call trace. 3900 Erlang can not be got with 176 Mbps on Iu interface). the RNC capacity is directly dependent of the call profile to consider. do not significantly change over the course of the OBS interval. used services and associated signaling are considered. The detailed description of the reference call profiles considered for the RNC capacity commitments are presented in document [A1]. “Conforming traffic” means traffic that meets a particular set of assumptions. For customers that demand more stringent operation. COMMITTED CAPACITY LEVELS For the different UTRAN releases. which means the underlying statistics of the traffic. This engineering margin corresponds is specify for each CPU type see table below.

06/ EN Standard 4/7/2011 Page 17/24 . Figure 4: RNC Capacity representation Capa RNC Data Bw/Erlangs 12000 All Voice 10000 All Data Mixed Erlangs 8000 Mixed HSDPA 6000 Office Premium Video Streaming 4000 Service Mixed Profile 6 Service Mixed Profile 5 2000 Service Mixed Profile 7 0 0 100 200 300 400 500 600 700 Data Bw The graph above represents the RNC Capacity for various Alcatel-Lucent Call Profiles. 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. so final capacity is not the same. The representation is a two dimensions graph with Erlang and Data Bandwidth for each axis. 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.RNC Capacity Engineering Guide 3. 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. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. even if Data only and Office premium are data they do not have the same type of signaling profile.4. For example.

use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. Passing on or copying of this document.06/ EN Standard 4/7/2011 Page 18/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.

RNCs may reach congestion situations with different average CPU load). with the counters: #0404 NT_Rrc_Connection_Reject (screening 6).RNC Capacity Engineering Guide 4. covered area. To have a view on the capacity margin of an operational RNC. the general rough recommendation is to monitor the different boards by PMC type.0 a counter allows to monitor the different PMC loads: this counter is the counter: #20202 VS. GENERAL CONSIDERATIONS AND RECOMMENDATIONS 4. Some acceptable levels of ratio of RRC connection requests and paging request Passing on or copying of this document. it is important to analyze regularly the traffic capacity offered locally by these RNC. a monitoring of the different RNC boards loads involved in traffic processing should be done.06/ EN Standard 4/7/2011 Page 19/24 . etc …). use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. the RNC capacity is directly linked to the call profile of the end users covered by this RNC. To maintain a good QOS for each RNC. #0810 NT_Unhandled_paging_request_CS (screening 4). it is recommended to correlate the CPU load observed on the most loaded PMC type. depending on the traffic variations. When working at low level of CPU. So as explained above. 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.3. the RNC may either be Control Plane limited or User Plane limited. Thus. with the mapping table presented in chapter 3. number of NodeB and cells. As explained previously. to the services offered. The sum of the indicators from index 3 to 8 should remain below 900 for a quarter hour observation. A rough value to consider for the CPU load of the different types of PMC is described in section 3. maximum hour granularity.ApCpuUtilizationAvg This counter is available for each PMC id of each PS-FP or DCPS slot. an average load of the limit provided in section 3. These counters indicate the number of RRC connection requests and paging requests rejected due to overload conditions. 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). By this way. To ensure that none of the PMC reaches its engineering limit a counter is defined: #20201 ApCpuUtilizationHistogram. it is possible to see the load for each type of PMC. to the network characteristics (LAC/RAC boundaries. #0811 NT_Unhandled_paging_request_PS (screening 4). This counter should be observed at the lowest granularity.3.1. this value is usually the engineering limit. 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. (This value is a relatively rough target since. specific attention should be set on this capacity subject. OPERATIONAL VIEW ON RNC CAPACITY 4. Associated to this global recommendation.1 GENERAL VIEW As presented in the previous chapters.1. From UA05.1. and to have for the most loaded PMC type.

to the large number of new additional counters introduced at each release and due to the limited memory available on the boards.06/ EN Standard 4/7/2011 Page 20/24 . These alarms should be clearly observed. in case. From UA05 some other counters should also be observed to have a view on other rejections performed: #1521: NT_Ovin_CnAccLa_Discard (screening 0. To manage the active counters. the RNC will automatically limit the number of active counters based on a priority level that is associated to each counter.1. the maximum number of supported counters is: 4. 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. Note: such situations should be anticipated by previous analyses of the expected traffic on the RNC before entering into these situations. The number of these counters should respect the maximum number of possible active counters.5 millions. For configurations with CP3 boards (max 1200 cells). Else. a minor alarm is raised and the counters having the lowest priority are filtered (this alarm is: Passing on or copying of this document. For more detail on these alarms see document [A3].0: it concerns the introduction of a mechanism to limit the number of active observation counters. This will be mandatory in the cases where the 16pOC3/STM1 are PQC one.75 millions. due to the large number of cells to be supported. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. actions should be taken to decrease the load on the RNC boards (see some proposals in next chapter).RNC Capacity Engineering Guide rejected should be targeted (according to customer objective in term of QOS). For configurations with CP4 boards (max 2400 cells). When the number of active counters reaches the maximum limit. 4. 1 and 2) Number of Downlink or uplink messages discarded at “CN Access La” on PMC-RAB. Their references are: 7070 2007 and 7070 2008 (Inode SW part) and also ANO_OVERLOAD_THRESHOLD (CNode SW part). In case where 80% of the number of active counters is reached a warning is raised: ANO_PF_GPO_LIMIT_80_PC_REACHED. If the border limits of these boards (310 Mbps for the 16pOC3/STM1 PQC boards) are approached. This mechanism as been introduced. some actions should be taken to upgrade accordingly the HW of the RNC (replacement of 16pOC3/STM1 PQC boards by 16pOC3/STM1 MS3 boards). This one specifies the counters to be activated for a given RNC.2 COUNTERS MANAGEMENT SPECIFICITY Another operational evolution is introduced in UA06. where the number of requested counters is higher than the threshold applicable to the current RNC HW configuration. a counter list is introduced in UA06 for the RNC. the maximum number of supported counters is 9. 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). #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. If these targets are not respected.

we may have unfortunately some most loaded NodeB collocated on the same TMU during the Busy Hour. It is thus recommended to observe if the warning at 80% is raised. It is not possible to predict on which TMU a ServiceGroup will be mapped. (see below) So. for instance. But it is possible at a specific time to know the association TMU-ServiceGroup. a part of the traffic should be redirected to another RNC (NodeB reparenting) or a new RNC deployed. in case of one TMU loss. it has to be studied (in case where the RNC was not equipped with DCPS) if a configuration using DCPS boards may be used.alcatellucent. This may be interesting for redundancy question in order to have. 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.0 it is possible to modify this distribution: NodeB are indeed set into Service Groups. Thus the CPU load between the different PMCTMU could be not perfectly balanced. and if there is a risk of reaching the limit. In the case where the RNC was already full of DCPS and where an impact is expected. it will now be needed to suppress 2 PS-FP. it has to be noticed that some CPU load differences inside a same type of PMC type may exists between the different PMC.exe?func=ll&objId=54533496&objAction=browse&sort=name&viewType=1 Since UA7. 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. so to perform some post-processing.app.1. In case of specific events like PS board restart or maintenance activity on one of the PS boards. The RNC distributes the different Service Groups on the different active TMU. it is a dynamic process that can evolutes due to TMU restart. one NodeB located on another TMU still covering the concerned area. with a monitoring of the CPU load of the different TMU. if the market model was having 12 PS-FP. 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.3 PMC-TMU SPECIFIC CONCERN Moreover.com/livelink/livelink. By default. Passing on or copying of this document. The facility allows also.RNC Capacity Engineering Guide ANO_PF_GPO_LIMIT_100_PC_REACHED_AND_LOW_PRIORITY_COUNTERS_DISABLED). When upgrading a RNC full ATM to a RNC ATM + IP. 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.3 the feature FRS 106904 TMU load balancing improvement review completely the load balancing mechanism. A specific study on Orange network can be viewed at: https://wcdma-ll. By the same way it is possible to know on which NodeBs a given Service Group has been positioned. 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. to set the NodeB that cover the same important area on different TMU. From UA06.1. 4. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. Else.0 it is possible to specify the Service Group in which will be set a NodeB (parameter ServiceGroupId). There are as many Service Groups possible as the number of active TMU.06/ EN Standard 4/7/2011 Page 21/24 . From UA06. A capacity analysis should be performed to ensure that no impact on the traffic will occur in that case. This is specially the case for the PMC-TMU on which the different NodeB are allocated. Thus from a real time activity perspective. the RNC redistributes the Service Groups dynamically on the active TMU.

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.06/ EN Standard 4/7/2011 Page 22/24 . in case where either the CN is in overload.If the RNC is equipped with 16pOC3STM1 PQC boards. This has the interest to block at the UE level some new incoming requests on a system that is not ready to accept them. either an IU failure is detected or either the RNC is in overload. - Decrease some event frequencies like Measurement Reports if it is compatible with QOS aspects. .Addition of new Packet Server boards inside the RNC if it is possible to work with a bigger Market model. “Full Event Trigger”… (The engineering recommendation is to have them enabled by default). operators have the possibility to enable the feature called “Automatic Access/Class Barring on service outrage”. - Reparenting of some NodeB to less loaded RNC - Addition of new RNC on the network - … In addition to these actions. from UA05. - Modify AO timers to limit some release and establishment of Data calls.2. it has to be verified that these boards are not reaching their limitation (310 Mbps Iu DL traffic). The principle is. 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. Else they should be replaced by 16pOC3STM1 MS3 boards. . to automatically generate some Access class barring or Cell barring orders. associated mechanism and parameters please refer to documents [A2] and [R5].Enabling of features that improves RNC capacity like “Iub Silent Mode”. but to provide some proposals to help enhancing the RNC capacity. This one allows offering a re-enforced protection for the elements of the system (not only RNC but also Core Network elements). the following possible actions may be considered: . - Limit the usage of call trace feature - Study if some reorganization of LAC and RAC boundaries may help in decreasing RNC loads .RNC Capacity Engineering Guide 4.0. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. Passing on or copying of this document. This list is to be completed based on returns on experience received. For more information about this feature. Thus.

Some services about network capacity may be provided to customers with the help of this tool. This tool is developed by R&D team in parallel with RNC product evolutions. Passing on or copying of this document. This one allows performing some RNC Capacity estimations based on a call profile characteristics. RNC CAPACITY ESTIMATIONS For Pre-sales or Post-sales activities. a dedicated tool: RCT: RNC Capacity Tool is developed and maintained for each release.RNC Capacity Engineering Guide 5.06/ EN Standard 4/7/2011 Page 23/24 . use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03. For this activity. the estimation of the RNC capacity is often necessary. Pre-Sales teams and Engineering teams are able to use it for network capacity analysis. This tool is for an internal usage.

RNC Capacity Engineering Guide 6.06/ EN Standard 4/7/2011 Page 24/24 . ABBREVIATIONS 6.1. ABBREVIATIONS AND DEFINITIONS 6.2. 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 DEFINITIONS  END OF DOCUMENT  Passing on or copying of this document. use and communication of its contents not permitted without Alcatel·Lucent written authorization UMT/IRC/INF/022089 03.