UMT_IRC_INF_022089 RNC Capacity Engineering Guide UA07[1].1 Internal V03.06

RNC Capacity Engineering Guide

Document number: UMT/IRC/INF/022089 Document issue: 03.06 Document status: Standard Date: 17/03/2011

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

INTERNAL DOCUMENT

Copyright 2007 Alcatel-Lucent, All Rights Reserved

Printed in France

UNCONTROLLED COPY: The master of this document is stored on an electronic database and is write

protected; it may be altered only by authorized persons. While copies may be printed, it is not recommended.

Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be regarded

as uncontrolled copies.

ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of Alcatel-

Lucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information

contained herein confidential, shall disclose the information only to its employees with a need to know, and shall

protect the information from disclosure and dissemination to third parties. Except as expressly authorized in

writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you have

received this document in error, please notify the sender and destroy it immediately.

without notice. Nortel Networks assumes no responsibility for errors that might appear in t.All other brand and



UMT/IRC/INF/022089 03.06/ EN Standard 4/7/2011 Page 2/24

PUBLICATION HISTORY

01/FEB/2007

Issue 00.01 / EN, Draft

Document Creation

02/APR/2007


Document update after first review

18/APR/2007


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


Updates for UA05.1 DR4

06/NOV/2007


Updates for UA05.1 DR5

20/MAR/2008


Release of the document to be reviewed for UA05.1.2 DR4

01/APR/2008


Document release for UA05.1.2 DR4

20/MAI/2008


Document update for UA06.0 release

05/JUN/2008





Document update after review. UA06 Preliminary release.

05/JUN/2009


Document release for UA06 DR5

18/JAN/2010


Document release for UA07.1

26/JAN/2010


Modifications see review minutes

Document release for UA07.1 DR4

1/FEB/2010


Add chapter on RNC capacity representation

Correction for PMC-PC engineering limit

Document release for UA07.1 DR4

1/JUNE/2010


Adding UA7.1.2 content

17/MARCH/2011


Adding UA7.1.3 content




CONTENTS

1. INTRODUCTION............................................................................................................................5

1.1. OBJECT....................................................................................................................................5

1.2. SCOPE OF THIS DOCUMENT .......................................................................................................5

1.3. AUDIENCE FOR THIS DOCUMENT ................................................................................................5

2. RELATED DOCUMENTS ..............................................................................................................6

2.1. APPLICABLE DOCUMENTS ..........................................................................................................6

2.2. REFERENCE DOCUMENTS..........................................................................................................6

3. 9370 RNC CAPACITY PROBLEMATIC........................................................................................7

3.1. OVERVIEW OF 9370 RNC ARCHITECTURE.............................................................................7

3.2. DIFFERENT CAPACITY ASPECTS ..............................................................................................12

3.2.1 RNC capacity In Connectivity........................................................................................12 3.2.2 RNC Coverage capacity................................................................................................14 3.2.3 RNC Traffic Capacity ....................................................................................................14

3.3. COMMITTED CAPACITY LEVELS ..........................................................................................16

3.4. RNC CAPACITY REPRESENTATION ...........................................................................................17

4. OPERATIONAL VIEW ON RNC CAPACITY ..............................................................................19

4.1. GENERAL CONSIDERATIONS AND RECOMMENDATIONS ......................................................19

4.1.1 General View.................................................................................................................19 4.1.2 Counters management specificity .................................................................................20 4.1.3 PMC-TMU specific concern ..........................................................................................21

4.2. POSSIBLE ACTIONS FOR CAPACITY ENHANCEMENTS ................................................22

5. RNC CAPACITY ESTIMATIONS ................................................................................................23

6. ABBREVIATIONS AND DEFINITIONS.......................................................................................24

6.1. ABBREVIATIONS ......................................................................................................................24

6.2. DEFINITIONS ...........................................................................................................................24




1. INTRODUCTION

1.1. OBJECT

The object of this document is to provide some guidelines regarding RNC capacity. It

presents capacity problematic with Alcatel-Lucent 9370 RNC from an Engineering

point of view.

1.2. SCOPE OF THIS DOCUMENT

This document is applicable to 9370 RNC for release UA07.1 (applicable for both

UA7.1.1 and UA7.1.3).

1.3. AUDIENCE FOR THIS DOCUMENT

It is destined to regional engineering teams and other teams involved, in Pre-Sales or

Post-Sales context, in RNC capacity exercises from an operational point of view.




2. RELATED DOCUMENTS

2.1. APPLICABLE DOCUMENTS

[A1] UMT/PLM/INF/4862 UMTS RNC Capacity Roadmap

[A2] UMT/SYS/DD/8005 RNC Overload

[A3] NN 20500-024 UMTS RNC and POC Alarms

[A4] UMT/COM/INF/23886 Changes to Alcatel-Lucent UMTS RNC Portfolio

Evolution in UA05.1 and UA06

2.2. REFERENCE DOCUMENTS

[R1] UMT/IRC/APP/13736 RNC Product Engineering Information

[R2] UMT/IRC/APP/0166 Iu Transport Engineering Guide

[R3] UMT/IRC/APP/0164 IuB Transport Engineering Guide

[R4] UMT/IRC/APP/0050 IuR transport Engineering Guide

[R5] UMT/IRC/DD/0011 UTRAN Parameter Users Guide

[R6] UMT/IRC/APP/023122 UMTS 7670 RSP/ESE Product Engineering

Information




3. 9370 RNC CAPACITY PROBLEMATIC

3.1. OVERVIEW OF 9370 RNC ARCHITECTURE

9370 RNC architecture is presented in document [R1]. This current chapter gives a short overview of

the RNC architecture related to capacity aspects. For a more complete view of the product, document

[R1] should be used.

The main modules of 9370 RNC are the following ones:

- Fabric modules (internal RNC switching modules for internal exchanges of messages)

managed in 1+1 mode (full duplication of traffic on the fabric)

- 16pOC3/STM1 boards (Interfaces boards providing ATM access to IuB, IuCS, IuPS, IuR,

IuPC, IuBC, ) Managed in 1:1 mode (operational/hot stand-by)

- CP boards (Control Process boards managing RNC platform, manages also associated

disks) Managed in 1:1 mode (operational/hot stand-by)

- PS boards (Packet Server processing boards managing calls and traffic for the RNC)

Managed in N+P mode

- 4pGiGE boards (Interfaces boards providing direct IP interface to the RNC). These boards

are optional.

It has to be noticed that:

- from UA05.0 two types of 16pOC3STM1 boards are available (may be optional in case of full

IP RNC):

o 16pOC3STM1 PQC boards

o 16pOC3STM1 MS3 boards.

- from UA05.1.2 two types of Packet Server boards are available:

o Packet Server: PS-FP (that may also be called PS1 in the following of the document)

o Dual Core Packet Server: DCPS.

- from UA06.0 two types of CP boards are available:

o CP3 boards

o CP4 boards

- From UA6.0 4pGiGE boards are introduced (may be optional in case of full ATM

configuration)

Each Packet Server board contains 6 PMC (PCI Mezzanine Card). (For DCPS it may be considered

also that each of them contains 6 logical PMC). A dedicated role is applied to each PMC. The

following different PMC main roles are roughly the following:

- PMC-M (1:1): Master PMC managing PMC organization and supervision inside the RNC,

- PMC-NI (1:1): managing SS7 stacks (layers MTP3 & SCCP)

- PMC-OMU (1:1): managing OAM relations between RNC and OMC (CM, FM, PM, )




- PMC-PC (N+1 - up to 12): Protocol Converter (Segmentation & reassembly) between

IP/AAL2 and IP/AAL5; load sharing for ATM configuration

- PMC-RAB (N+1 up to 40): Bearer processing, radio protocol handling (RLC, MAC, ),

Macro diversity,

- PMC-TMU (N+P: P=1 for N8 up to 14): Call and cell processing, RANAP,

RNSAP, NBAP, RRM

The allocation of the PMC roles on the PS-FP (or DCPS) is presented in the following figures, this

depend of the RNC interface configuration:

slot card/Pmc 0 1 2 3 4 5

0 CP

1 CP

2 PSFP PMC-M TMU RAB RAB PC RAB


4 PSFP RAB TMU NI RAB PC OMU


6 PSFP RAB TMU RAB RAB PC RAB


8 OC3

9 OC3



12 PSFP RAB TMU RAB RAB PC TMU




PMC ID within PSFP

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


0 CP

1 CP







8 OC3

9 OC3





14 4GIGE

15 4GIGE

PMC ID within PSFP

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





0 CP

1 CP













14 4GIGE

15 4GIGE

PMC ID within PSFP

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

The role of the different PMC can not be modified. The allocation of these roles is static depending on

the PS-FP (or DCPS) slot number and PMC id. The above figure presents the implementation of these

PMC roles for a 12 or 10 PS-FP (or DCPS) market model. For smaller market models, the

implementation remains the same for the PS-FP (or DCPS) present in the rack according to their slot

number (Reminder: PS boards are set in the rack from the lower slot value up to the lower slot values.

Thus for lower market models only the first slots of PSFP are full).

Different 9370 RNC supported market models exist according to the number of Packet Server present

in the shelf. The different supported market models in UA07.1 are:

- for RNC equipped with PS-FP:

o 9370 RNC with 4 PSFP,




o 9370 RNC with 12 PSFP.

- for RNC equipped with DCPS:

o 9370 RNC with 4 DCPS,




o 9370 RNC with 12 DCPS.

No mixed configuration using PSFP and DCPS is supported.




The following table summarizes the different modules of these market models (the number of PS-FP

or DCPS boards is the only difference between the market models).

9370 RNC Market Models

9370 RNC

w 4 PSFP w 6 PSFP w 8 PSFP w 10 PSFP w 12 PSFP

Modules

ATM MIX IP ATM MIX IP ATM MIX IP ATM MIX IP ATM MIX IP

Fabric 2 2 2 2 2 2 2 2 2 2 2 2 2 N/A 2

CP3 2 2 2 2 2 2 2 2 2 2 2 2 2 N/A 2

16pOC3/STM1 2 2 0 2 2 0 2 2 0 2 2 0 2 N/A 0

4pGiGE 0 2 2 0 2 2 0 2 2 0 2 2 0 N/A 2

PS-FP 4 4 4 6 6 6 8 8 8 10 10 10 12 N/A 12

9370 RNC

w 4 DCPS w 6 DCPS w 8 DCPS w 10 DCPS w 12 DCPS

Modules

ATM MIX IP ATM MIX IP ATM MIX IP ATM MIX IP ATM MIX IP

Fabric 2 2 2 2 2 2 2 2 2 2 2 2 2 N/A 2

CP(CP3 or CP4) 2 2 2 2 2 2 2 2 2 2 2 2 2 N/A 2

16pOC3/STM1 2 2 0 2 2 0 2 2 0 2 2 0 2 N/A 0

4pGiGE 0 2 2 0 2 2 0 2 2 0 2 2 0 N/A 2

DCPS 4 4 4 6 6 6 8 8 8 10 10 10 12 N/A 12

Table 1: Number of modules per market model

The number of different PMC types per market model is the following:

9370 RNC Market Models

PMC Types w 4 PSFP or

DCPS

w 6 PSFP or

DCPS

W 8 PSFP or

DCPS

w 10 PSFP or

DCPS

w 12 PSFP or

DCPS

PMC-M 2 2 2 2 2

PMC-OMU 2 2 2 2 2

PMC-NI 2 2 2 2 2

PMC-PC 4 6 8 10 12

PMC-RAB 10 18 26 32 40

PMC-TMU 4 6 8 12 14

Table 2: Number of PMC of each type per market model

Since UA7.1.3 with the introduction of the FRS 106904 TMU RAB rebalancing it is possible to modify

the PMC mapping for the market models with 10 DCPS and CP4 only. This feature allows changing

PMC-RAB in slot 10 and 11 PMC id 5 by PMC-TMU. Then since UA7.1.3 both following configuration

are possible for slot 10 and 11:




PMC-id and number

Slot Card 0 1 2 3 4 5

0 CP4

1 CP4

2 DCPS PMC-M TMU RAB RAB PC RAB


4 DCPS RAB TMU NI RAB PC OMU


6 DCPS RAB TMU RAB RAB PC RAB


8 16p OC3

9 16p OC3



12 DCPS RAB TMU RAB RAB PC TMU


14 4pGigE

15 4pGigE

Or

PMC-id and number

Slot Card 0 1 2 3 4 5

0 CP4

1 CP4







8 16p OC3

9 16p OC3





14 4pGigE

15 4pGigE

In that last case the RNC runs with 30 PMC-RAB and 14 TMUs

Estimated TMU capacity gain is between 12% and 18%. At feature introduction this gain must be

assessed.

With the different possible board types, the following hardware baselines are supported:

- CP3 + (optionally) 16pOC3STM1 PQC + PSFP + (optionally) 4pGiGE

- CP3 + (optionally) 16pOC3STM1 MS3 + PSFP + (optionally) 4pGiGE

- CP3 + (optionally) 16pOC3STM1 PQC + DCPS + (optionally) 4pGiGE

- CP3 + (optionally) 16pOC3STM1 MS3 + DCPS + (optionally) 4pGiGE




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




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




For redundancy aspects, it is recommended to define some active and redundant paths through the

two 4pGiGE boards. The active and redundant paths of a given link should be defined on the two

different 4pGiGE boards in order to support the loss of one of them.

To be able to support the loss of one board without any capacity impact, it is recommended that the

total IP traffic exchanged across the RNC (so over the two 4pGiGE boards) do not exceed 2.5 Gbps.

Remark: in UA07.1, this value should not be a limitation for the RNC since the processing capacity of

the PS boards should limit the traffic before the external interface boards. For example, for Mobile

Premium Office profile Iu Application bandwidth is 675Mbps for a 12 DCPS RNC in UA7.1. For more

details, refer to [A1]

3.2.2 RNC COVERAGE CAPACITY

Under the term coverage is here considered the maximum numbers of NodeB and cells that a RNC

can support. These values are dependent on the market model and on the hardware baselines. For

more details, refer to [A1]

The corresponding figures are presented in the table below.

9370 RNC Market Models with CP3 boards

w 4 PSFP or

DCPS

w 6 PSFP or

DCPS

W 8 PSFP or

DCPS

w 10 PSFP or

DCPS

w 12 PSFP or

DCPS

Max NodeB 360 600 800 1200 1200

Max Cells 360 600 800 1200 1200

9370 RNC Market Models with CP4 boards

w 4 DCPS w 6 DCPS W 8 DCPS w 10 DCPS w 12 DCPS

Max NodeB 600 1000 1400 2000 2400

Max Cells 600 1000 1400 2000 2400

Table 3: Coverage capacity for the different RNC market model

It has to be noticed that from UA06.0 the committed maximum number of supported NodeB is equal

(According to Capacity Roadmap [A1]) to the maximum number of supported cells. This means that

the RNC NodeB/cell capacity is limited by the first NodeB or Cell which reaches its limit.

3.2.3 RNC TRAFFIC CAPACITY

BORDER LIMITS

In term of traffic capacity, the RNC product has some border limits that cannot be exceeded.

In term of number of internal dimensioning figures, the maximum numbers of contexts are the

following for a 9370 RNC with 12 PSFP:

o Max number of CS RRC contexts: 6048

o Max number of DCH (CS+PS) RRC contexts: 8640

o Max number of FACH RRC contexts: 7020




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.




3.3. COMMITTED CAPACITY LEVELS

For the different UTRAN releases, some commitments are taken by Alcatel-Lucent in term of RNC

capacity. As seen previously, the RNC capacity is directly dependent of the call profile to consider.

Thus, for the RNC capacity commitments, different call profiles are defined. The behavior and capacity

of the RNC with these call profiles are validated during load tests in R&D Lab to ensure the

commitments are respected.

The detailed description of the reference call profiles considered for the RNC capacity commitments

are presented in document [A1]. This document is the reference for the committed capacity levels of

the RNC. Very precise conditions in term of volume of traffic, used services and associated signaling

are considered. The associated RNC capacity results are available in this document [A1]. Please refer

to it for the corresponding values.

It is important to have in mind that the different figures presented in this document are reached for

different independent call profiles. These figures can not be got simultaneously (for instance for a

9370 RNC with 12 PSFP, 3900 Erlang can not be got with 176 Mbps on Iu interface). They can not be

considered as commitments for any conditions of usage as they are associated to precise hypothesis

in term of signaling and services. Moreover these figures are got in a context where the features Full

Event Trigger and Iub Silent Mode are enabled, and thus are valid only in this context.

All the previous figures are got in conditions where an engineering margin is kept on the RNC. This

engineering margin corresponds is specify for each CPU type see table below.

Table 4: CPU Engineering Limit per Release

This does not mean that above this CPU load value the RNC will enter in overload, but it corresponds

to a margin taken to ensure the RNC will be able to handle some variations of traffic while keeping a

good Quality Of Service (QOS) for the end users.

All dimensioning exercises made by Alcatel-Lucent people for Pre-Sales of Post-Sales needs should

consider this engineering limit.

The Engineering Limit is the maximum resource utilization caused by conforming traffic at which

reasonable performance can be achieved. Conforming traffic means traffic that meets a particular set

of assumptions. Reasonable performance means a quality of service defined by ALU RNC Design.

The assumptions include that the traffic is assumed equivalent to a stationary random process, which

means the underlying statistics of the traffic, including mean and variance, do not significantly change

over the course of the OBS interval. The level of reasonable performance assumed includes rejection

of up to 1% of (repeated) RRC Connection Requests due to overload, and the frequent suspension of

call trace. For customers that demand more stringent operation, Engineering is advised to debate the

Engineering Limit and RNC Capacity.

CPU Type UA06 UA7.0 UA7.1

PMC-RAB (DSCP) 80% 80% 80%

PMC-PC (DSCP) 70% 70% 80%

PMC-TMU (DSCP) 70% 70% 80%All others DSCP CPU

and all PSFP CPU 70% 70% 70%

Release




3.4. RNC CAPACITY REPRESENTATION

It becomes common to try to draw the RNC capacity to allow comparison against reference RNC

capacity or to compare various RNC of the same network.

The representation is a two dimensions graph with Erlang and Data Bandwidth for each axis.

Figure 4: RNC Capacity representation

The graph above represents the RNC Capacity for various Alcatel-Lucent Call Profiles. The various

capacities cannot be aligned on one nice line between Voice only (Max Erlangs) and Office Premium

(Max Data Throughput) see [A1]. This shows that capacity is strongly dependant on the call profile.

For example, even if Data only and Office premium are data they do not have the same type of

signaling profile, so final capacity is not the same.

A study on a real network was done, and provides this kind of results:

Figure 4: Network RNC Capacity analysis

Capa RNC Data Bw/Erlangs

0

2000

4000

6000

8000

10000

12000

0 100 200 300 400 500 600 700

Data Bw

Erlangs

All Voice

All Data

Mixed

Mixed HSDPA

Office Premium

Video Streaming

Service Mixed Profile 6






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.




4. OPERATIONAL VIEW ON RNC CAPACITY

4.1. GENERAL CONSIDERATIONS AND RECOMMENDATIONS

4.1.1 GENERAL VIEW

As presented in the previous chapters, the RNC capacity is directly linked to the call profile of the end

users covered by this RNC. By this way, the capacity of RNC in term of end users covered may be

different inside a same network according to the behavior of the users (mobility), to the services

offered, to the network characteristics (LAC/RAC boundaries, covered area, number of NodeB and

cells, etc ).

To maintain a good QOS for each RNC, it is important to analyze regularly the traffic capacity offered

locally by these RNC.

To have a view on the capacity margin of an operational RNC, a monitoring of the different RNC

boards loads involved in traffic processing should be done. From UA05.0 a counter allows to monitor

the different PMC loads: this counter is the counter:

#20202 VS.ApCpuUtilizationAvg

This counter is available for each PMC id of each PS-FP or DCPS slot. Thus, with the mapping table

presented in chapter 3.1, it is possible to see the load for each type of PMC. This counter should be

observed at the lowest granularity, maximum hour granularity. As explained previously, the RNC may

either be Control Plane limited or User Plane limited. Thus all types of PMC should be studied

because it will not be always the same type of PMC that will be the limiting factor.

When working at low level of CPU, there is no risk of traffic limitation due to the maximum capacity of

the concerned RNC. When the CPU load on the PMC becomes significant, specific attention should

be set on this capacity subject. A rough value to consider for the CPU load of the different types of

PMC is described in section 3.3. (This value is a relatively rough target since, depending on the traffic

variations; RNCs may reach congestion situations with different average CPU load), this value is

usually the engineering limit.

To ensure that none of the PMC reaches its engineering limit a counter is defined: #20201

ApCpuUtilizationHistogram. The sum of the indicators from index 3 to 8 should remain below 900 for a

quarter hour observation.

So as explained above, the general rough recommendation is to monitor the different boards by PMC

type, and to have for the most loaded PMC type, an average load of the limit provided in section 3.3.

Associated to this global recommendation, it is recommended to correlate the CPU load observed on

the most loaded PMC type, with the counters:

#0404 NT_Rrc_Connection_Reject (screening 6),

#0810 NT_Unhandled_paging_request_CS (screening 4).

#0811 NT_Unhandled_paging_request_PS (screening 4).

These counters indicate the number of RRC connection requests and paging requests rejected due to

overload conditions. Some acceptable levels of ratio of RRC connection requests and paging request




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:




ANO_PF_GPO_LIMIT_100_PC_REACHED_AND_LOW_PRIORITY_COUNTERS_DISABLED). It is

thus recommended to observe if the warning at 80% is raised, and if there is a risk of reaching the

limit, it is recommended to modify the RNC counter List (suppress some non mandatory counters in it)

to be sure to remain under the maximum limit and then control the RNC active counters.

4.1.3 PMC-TMU SPECIFIC CONCERN

Moreover, it has to be noticed that some CPU load differences inside a same type of PMC type may

exists between the different PMC. This is specially the case for the PMC-TMU on which the different

NodeB are allocated.

By default, the allocation of NodeB on the PMC-TMU is made statically after the definition of the

NodeB (or after build) according to the less loaded Iub in term of ports and also according to NodeB

type. Thus from a real time activity perspective, we may have unfortunately some most loaded NodeB

collocated on the same TMU during the Busy Hour. Thus the CPU load between the different PMC-

TMU could be not perfectly balanced.

From UA06.0 it is possible to modify this distribution: NodeB are indeed set into Service Groups.

There are as many Service Groups possible as the number of active TMU. The RNC distributes the

different Service Groups on the different active TMU. In case of specific events like PS board restart or

maintenance activity on one of the PS boards, the RNC redistributes the Service Groups dynamically

on the active TMU.

From UA06.0 it is possible to specify the Service Group in which will be set a NodeB (parameter

ServiceGroupId). By the same way it is possible to know on which NodeBs a given Service Group

has been positioned. It is not possible to predict on which TMU a ServiceGroup will be mapped, it is a

dynamic process that can evolutes due to TMU restart. But it is possible at a specific time to know the

association TMU-ServiceGroup, so to perform some post-processing. (see below)

So, with a monitoring of the CPU load of the different TMU, it is possible to modify the affectation of

some of the NodeB in order to get some PMC-TMU boards that would be well balanced. The facility

allows also, for instance, to set the NodeB that cover the same important area on different TMU. This

may be interesting for redundancy question in order to have, in case of one TMU loss, one NodeB

located on another TMU still covering the concerned area.

A specific study on Orange network can be viewed at: https://wcdma-ll.app.alcatel-

lucent.com/livelink/livelink.exe?func=ll&objId=54533496&objAction=browse&sort=name&viewType=1

Since UA7.1.3 the feature FRS 106904 TMU load balancing improvement review completely the load

balancing mechanism. A dynamic table is permanently up to date ranking all the TMU including the

passive one by their capability of handling a new incoming call. At each incoming call the local TMU

will decide if the local TMU is the best candidate to handle the call or will redistribute it to the best

TMU.

When upgrading a RNC full ATM to a RNC ATM + IP, if the market model was having 12 PS-FP, it will

now be needed to suppress 2 PS-FP. A capacity analysis should be performed to ensure that no

impact on the traffic will occur in that case. Else, it has to be studied (in case where the RNC was not

equipped with DCPS) if a configuration using DCPS boards may be used. In the case where the RNC

was already full of DCPS and where an impact is expected, a part of the traffic should be redirected to

another RNC (NodeB reparenting) or a new RNC deployed.




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




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.




6. ABBREVIATIONS AND DEFINITIONS

6.1. ABBREVIATIONS

NPO Network Performance Optimizer

OMU Operation and Maintenance Unit

PMC PCI Mezzanine Card

PMC-M PMC Master

PMC-NI PMC Network Interface

PMC-OMU PMC Operation and Maintenance Unit

PMC-PC PMC Protocol Converter

PMC-RAB PMC Radio Access Bearer

PMC-TMU PMC Traffic Management Unit

QOS Quality of Service

RNC Radio Network Controller

TMU Traffic Management Unit

6.2. DEFINITIONS

END OF DOCUMENT

UMT_IRC_INF_022089 RNC Capacity Engineering Guide UA07[1].1 Internal V03.06

Documents

Transcript of UMT_IRC_INF_022089 RNC Capacity Engineering Guide UA07[1].1 Internal V03.06