Professional Documents
Culture Documents
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
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
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
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
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
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
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.
1.3.
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
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
3.
3.1.
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
PC PC PC PC PC PC
PC PC PC PC PC PC
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
PC PC PC PC PC PC
PC PC PC PC
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
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.
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
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
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
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
PC PC PC PC PC PC
PC PC PC PC
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
PC PC PC PC PC PC
PC PC PC PC
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
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.
From a capacity perspective, three different aspects have to be considered for the RNC: Connectivity Coverage Traffic
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
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
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
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.
UMT/IRC/INF/022089
03.06/ EN
Standard
4/7/2011
Page 14/24
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
3.3.
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
3.4.
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.
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:
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
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
4.
4.1.
#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
#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.
UMT/IRC/INF/022089
03.06/ EN
Standard
4/7/2011
Page 20/24
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
4.2.
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
5.
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
6.
6.1.
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