Dimensioning WCDMA RAN_ McRNC

DN0983585 Issue 02C

Nokia Siemens Networks Confidential

1 (39)

WCDMA RAN, Rel.RU40, Operating Documentation

Dimensioning WCDMA RAN: Multicontroller RNC

DN0983585 Issue 02C Approval date: 2013-09-03

Confidential

2 (39) Nokia Siemens Networks Confidential

DN0983585 Issue 02C

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given as is and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright Nokia Siemens Networks 2013. All rights reserved.


DN0983585 Issue 02C


3 (39)

Table of contents

Summary of changes ............................................................................ 4 List of figures and tables .......................................................................... 5

1 Overview ............................................................................... 6 1.1 mcRNC hardware ................................................................... 6 1.2 mcRNC functional architecture .............................................. 7 1.3 mcRNC capacity limits ......................................................... 10 1.4 Interfaces in mcRNC ............................................................ 12

2 Dimensioning process....................................................... 14 2.1 Dimensioning based on RNC throughput limitations ........... 15 2.1.1 User Plane dimensioning ..................................................... 15 2.1.2 Calculating RNC user plane fill rate based on traffic mix

rule ....................................................................................... 17 2.1.3 Control plane dimensioning ................................................. 18 2.2 RNC dimensioning based on BTS connectivity limits .......... 20 2.3 Physical interface connectivity ............................................. 21 2.3.1 Physical interface capacity ................................................... 21 2.3.2 Configuration and network architecture restrictions ............. 22 2.4 Smartphone impact on mcRNC capacity ............................. 23

3 RNC SW license keys ........................................................ 25 3.1 AMR Erlangs license ............................................................ 25 3.2 PS throughput capacity license ............................................ 26 3.3 Number of unlocked carriers ................................................ 27

4 BTS load distribution factor (uneven load factor) .......... 28 4.1 Background .......................................................................... 28 4.2 BTS load distribution factor definition .................................. 28 4.3 Rule example ....................................................................... 31

5 RNC dimensioning example ............................................. 33

6 Annexes .............................................................................. 37 6.1 Annex 1 Counters and KPIs used for mcRNC

dimensioning ........................................................................ 37 6.2 Annex 2 NSN default Traffic Profiles ................................ 38


DN0983585 Issue 02C

Summary of changes

This document comprises 39 pages.

Changes between Issues 02B (2013-05-03, RU40) and 02C (2013-09-03, RU40)

Updated values in the following tables:

- Table 1 mcRNC capacity and performance limits mcRNC2.0 HW

- Table 2 mcRNC capacity and performance limits - mcRNC3.0 HW

- Table 3 mcRNC physical interfaces (BCN-A)

- Table 6 Voice and data service call mix

- Table 8 Smartphone traffic profile

Added Table 4 mcRNC physical interfaces (BCN-B)

Updated Figure 6 RRC state changes

Updated formula for Calculating RNC user plane fill rate based on traffic mix rule in chapter 2: Dimensioning process

Added new paragraphs and modified formula for checking control plane utilization in subchapter 2.1.3 Control plane dimensioning

Added chapter 6: Annexes

Changes between Issues 02A (2013-02-26, RU40) and 02B (2013-05-03, RU40)

Updated values in the following tables:



- Table 14 Calculated number of mcRNCs/modules from Control Plane point of view

Changes between Issues 02 (2012-12-05, RU40) and 02A (2013-02-26, RU40) Updated values in the following tables:



Updated formula for RNC Control Plane check in chapter 5: RNC dimensioning example


DN0983585 Issue 02C


5 (39)

List of figures and tables

Figure 1 mcRNC HW module architecture .................................................................................................. 7 Figure 2 The block diagram of the mcRNC HW module ............................................................................. 8 Figure 3 Capacity steps in mcRNC ........................................................................................................... 10 Figure 4 Overview of mcRNC dimensioning process ................................................................................ 15 Figure 5 Dimensioning RNC - throughput limitation check ....................................................................... 16 Figure 6 RRC state changes ..................................................................................................................... 19 Figure 7 AMR capacity license principle ................................................................................................... 26 Figure 8 PS Throughput License principle ................................................................................................ 27 Figure 9 Even load calculation .................................................................................................................. 29 Figure 10 Uneven load calculation ............................................................................................................ 30 Figure 11 BTS load distribution factor ....................................................................................................... 30 Table 1 mcRNC capacity and performance limits mcRNC2.0 HW ........................................................ 11 Table 2 mcRNC capacity and performance limits - mcRNC3.0 HW ......................................................... 12 Table 3 mcRNC physical interfaces (BCN-A)............................................................................................ 13 Table 4 mcRNC physical interfaces (BCN-B)............................................................................................ 13 Table 5 Frame Protocol bit rates ............................................................................................................... 17 Table 6 Voice and data service call mix .................................................................................................... 19 Table 7 Minimum interface requirements for mcRNC using 1 Gigabit Ethernet and 10 Gigabit Ethernet 22 Table 8 Smartphone traffic profile ............................................................................................................. 24 Table 9 Example: BTS BH distribution ...................................................................................................... 31 Table 10 Example: Calculated BH traffic at the RNC level ....................................................................... 32 Table 11 Standard traffic model ................................................................................................................ 33 Table 12 Network traffic summation .......................................................................................................... 34 Table 13 Calculated number of mcRNCs/modules from throughput point of view ................................... 35 Table 14 Calculated number of mcRNCs/modules from Control Plane point of view ............................... 36 Table 15 Calculated number of mcRNCs/modules from carrier/BTS connectivity point of view .............. 36 Table 16 KPIs and counters to be used for mcRNC dimensioning ........................................................... 38 Table 17 Basic UE Traffic Profile .............................................................................................................. 38 Table 18 Smartphone UE Traffic Profile .................................................................................................... 39 Table 19 Laptop UE Traffic Profile ............................................................................................................ 39


DN0983585 Issue 02C

1 Overview The Multicontroller RNC (mcRNC) is a realization of the UTRAN 3G Radio Network Controller (RNC) on hardware comprising many multi-core processors along with the necessary memory, storage, switching, and networking equipment in a rack mount box configuration. The functionality of the RNC is achieved by the software running typically on two or more such modules, which are also known as Box Controller Nodes (BCNs).

The software complies with the 3GPP specified protocols for interacting with other Network Elements.

A general description of the RNC and its functions is available in Multicontroller RNC Product Description.

1.1 mcRNC hardware

The mcRNC consists of several mcRNC HW modules (BCNs), and each BCN contains a motherboard with a management processor and eight separate add-on cards, containing multi-core processors that are connected to the motherboard through PCI-e connectors. With these features, the same hardware can be used for processing of the user, control, transport and management plane functions.

The single physical switch is divided into two logical switches one for external network communication and the other for internal network communication. Each processor in the add-on card is connected to the external switch and the internal switch.

The functional blocks of one hardware node are shown in Figure 1 mcRNC HW module architecture.


DN0983585 Issue 02C


7 (39)

Figure 1 mcRNC HW module architecture

1.2 mcRNC functional architecture

The box-based mcRNC concept is an attempt to create a telecom product with disruptive hardware and software architecture that clearly outperforms traditional chassis-blade product architectures in terms of cost per MB of data.

As the mcRNC has only one type of processing hardware, in theory, it allows for a large degree of freedom in designing functional software architecture. The logical functions can be freely allocated inside the physical units.

Figure 2: The block diagram of the mcRNC HW module shows the general functional architecture. At high level, the network element consists of the following parts:

Network interface functions

Switching functions

Control plane processing

User plane processing

Carrier connectivity functions

O&M functions


DN0983585 Issue 02C

The functions are distributed in entities of hardware and software. The main processing units/entities of the mcRNC are listed below:

Centralized Functions Processing Unit (CFPU)

Cell-Specific Processing Unit (CSPU)

UE-Specific Processing Unit (USPU)

External Interface Processing Unit (EIPU)

Ethernet switches

Figure 2 The block diagram of the mcRNC HW module


DN0983585 Issue 02C


9 (39)

USPU

This processing unit implements all UE-specific control and user plane processing. Furthermore, all dedicated control plane and user plane resources for a single UE are allocated from the same USPU unit. Therefore, USPU units are completely independent of each other and different USPUs might not have mutual communication at all. It makes implementation of SN+ redundancy functionalities, such as moving UE-specific processing from one processor to another simpler.

USPU consists of the following two functional units:

USCP UE Specific functions and services in the control plane

USUP - UE Specific functions and services in the user plane. This includes the dedicated and shared channel services, since they are relevant for a UE.

CSPU

This processing unit implements all cell-specific control and user plane processing. Furthermore, all control and user plane resources for a single BTS are allocated from the same CSPU unit. Therefore, CSPU units are completely independent of each other and different CSPUs might not have mutual communication at all. The unit uses N + M (M >= 1) redundancy. Allocation of BTSs under control of specific CSPUs is controlled by the Operation and Management Unit (OMU). The same functionality in the OMU also allows for graceful reallocation of BTSs one by one, from one CSPU to another. This feature provides seamless shutdown and replacement of one mcRNC hardware unit.

The CSPU consists of the following two functional units:

CSCP Cell Specific functions and services in Control Plane

CSUP Cell Specific functions and services in User Plane

CFPU

The Centralized Functions Processing Unit (CFPU) consists of the OMU and Centralized Functions Control Plane (CFCP). The OMU performs the basic system maintenance functions such as hardware configuration, alarm system, configuration of signaling transport and centralized recovery functions. It also contains cellular-network-related functions such as radio network configuration management, radio network recovery and RNW database. All the functions that require 2N type of redundancy are located in the CFPU, as it is only 2N (hot standby) redundant processing unit. Additionally, all the location-services-related functions requiring 2N redundancy or centralized processing, like accounting of simultaneous ongoing location-related-procedures in the whole network element, are located in the CFPU. The OMU terminates an external Ethernet interface. Management connections and connections to OMS go through this interface.

EIPU

The External Interface Processing Unit (EIPU) hosts the networking and transport stacks needed for processing both signaling and user plane data. It also handles the load balancing and distribution to other units. It consists of two functional units - the Signaling Transport Plane (SITP) and External Interface Transport Plane (EITP).


DN0983585 Issue 02C

1.3 mcRNC capacity limits

mcRNC capacity steps are defined based on the number of BCNs that one Network Element consists of, for example step 1 uses two controller modules, step 3 uses four controller modules and step 5 uses six controller modules.

The first two mcRNC configurations, containing 2 and 6 HW modules (BCNs) are introduced with RU30 System Program release. Those configurations consist of the first version of processor in add-in cards (BCNOC-A) and the first BCN type (BCN-A)

In RU40 System Program release, the following new HW is introduced:

new in add-in cards (BMPP2-B)

new BCN type (BCN-B)

These new add-in cards provide more processing power, which reflects in an increase in RNC capacity. The BCN-B provides a bigger amount of 10GbE interfaces at the front panel.

With the new add-in cards and the new BCN type, two capacity steps are supported: s1 and s3. For all mcRNC capacity steps supported in RU40 System Program Release (with the official naming) please refer to Figure 3 Capacity steps in mcRNC.

Figure 3 Capacity steps in mcRNC

mcRNC capacity and performance limits for all configurations are provided in Table 1.


DN0983585 Issue 02C


11 (39)

mcRNC capacity step S1-A1 S5-A1

CS BHCA 340 000 1 380 000

PS BHCA 485 000 1 940 000

PS Session BHCA 970 000 3 880 000

Smartphone BHCA 327 000 1 310 000

Smartphone Iub DL/UL throughput [Mbps] 150/60 700/290

max Iub DL/UL throughput [Mbps] 910 / 380 3660 /1530

AMR/CS voice over HSPA capacity [Erlangs]

8500 34500

BTS connectivity 470 1020

Carrier connectivity 1410 3110

RRC connected state UEs 195 000 780 000

Maximum number of Cell_DCH users 10 500 42 000

IuPS HSDPA net bit rate [Mbit/s] 819 3294

IuPS HSUPA net bit rate [Mbit/s] 204 984

Table 1 mcRNC capacity and performance limits mcRNC2.0 HW


DN0983585 Issue 02C

mcRNC capacity step S1-B2 S3-B2

CS BHCA 760 000 2 140 000

PS BHCA 1 400 000 3 500 000

PS Session BHCA 2 800 000 7 000 000

Smartphone BHCA 1 170 000 2 940 000

Smartphone Iub DL/UL throughput [Mbps] 450/190 1250/530

max Iub DL/UL throughput [Mbps] 1850 / 790 5260/2260

AMR/CS voice over HSPA capacity [Erlangs]

19000 53500

BTS connectivity 520 1320

Carrier connectivity 2600 6600

RRC connected state UEs 352 000 1 000 000

Maximum number of Cell_DCH users 26400 66000

IuPS HSDPA net bit rate [Mbit/s] 1665 4734

IuPS HSUPA net bit rate [Mbit/s] 500 1420

Table 2 mcRNC capacity and performance limits - mcRNC3.0 HW

_______________________________________________________________________

NOTE

Maximum Iub throughputs are given on Frame Protocol layer. IuPS net bit rates are given on top of GTP-U layer.

_______________________________________________________________________

1.4 Interfaces in mcRNC

The mcRNC provides a set of physical Ethernet / Gigabit Ethernet interfaces to execute physical-layer and transport-layer functions, such as policing, statistics, OAM, buffer management and scheduling. Any interface (except OAM) can be configured to be used as an Iu, Iub or Iur interface with one restriction of four 10 Gbps Ethernet interfaces per HW module reserved for interconnections between HW modules. In addition to LAN interfaces and debugging, management interfaces are provided. The number and types of interfaces for each mcRNC module are presented in the following tables:


DN0983585 Issue 02C


13 (39)

Interface type

Gigabit Ethernet

10 Gbps Ethernet

Ethernet

Usage Network connections and element management

Inter-module connections

Operating and Maintenance

Standard IEEE 802.3-2005 IEEE 802.3-2005 IEEE 802.3

Physical layer 1000Base-SX/LX/T 10G Direct Attach 10Base-T/100Base-TX/1000Base-T

Number of interfaces BCN-A

16+2(O&M) 6 0-2

Number of interfaces BCN-B

10+2(O&M) 9 0-2

Table 3 mcRNC physical interfaces (BCN-A)

Interface type Gigabit Ethernet

1 and 10 Gbps Ethernet

Ethernet

Usage Network connections and element management

Inter-module connections

Operating and Maintenance

Standard IEEE 802.3-2005 IEEE 802.3-2005 IEEE 802.3

Physical layer 1000Base-SX/LX/T 10G Direct Attach 10Base-T/100Base-TX/1000Base-T

Number of interfaces

10+2(O&M) 9 0-2

Table 4 mcRNC physical interfaces (BCN-B)


DN0983585 Issue 02C

2 Dimensioning process

The RNC dimensioning requires preliminary dimensioning of BTSs, Uu, Iub, Iur, and Iu interfaces. The Uu dimensioning and calculation of the required number of BTSs is described in detail in Dimensioning WCDMA RAN: Air Interface.

After having this done, further steps of the RNC dimensioning process can be applied:

1) Calculation of aggregated user plane traffic demand and verification against RNC capacity limitations for PS data throughput on Iub (Mbps) and AMR capacity (Erlangs) according to the Traffic Mix Rule

2) Calculation of the control plane load in terms of Busy Hour Call Attempts and verifying against the RNC limits

3) Verification of the number of BTSs and cells to be connected against the RNC limits

4) Calculation the number of required physical interfaces and verification against the RNC limits

The hardware limits are essential for the RNC dimensioning process. Some of the hardware limits can be additionally limited by software licenses (see chapter RNC SW license keys). The RNC limits are defined by the specific hardware and software configurations.


DN0983585 Issue 02C


15 (39)

Figure 4 Overview of mcRNC dimensioning process

2.1 Dimensioning based on RNC throughput limitations

2.1.1 User Plane dimensioning

Figure 5 describes the generic method for calculating the total number of RNCs in the network from the user plane traffic perspective. This method gives an overall understanding of the number of RNCs required in relation to subscribers, with a distinction between the voice, CS, PS and HSPA traffic. The UL dimensioning includes DCH and HSUPA.


DN0983585 Issue 02C

Figure 5 Dimensioning RNC - throughput limitation check

Based on traffic, the values for the offered traffic on the Iub can be calculated. When calculating, adhere to the following steps:

1. Calculate the user traffic from the BTSs for the expected number of users of each service type: AMR, CS data, PS data and HSPA traffic. Furthermore, define the expected data rates of CS/PS data and HSPA traffic. The data rates used are the FP bit rates (see Table 5 Frame Protocol bit rates) with 100% activity (in PS NRT Data, smaller Activity Factor can be used).

Note that:

AMR traffic is treated independently from other load, as far as the Iub throughput limit is concerned;

PS NRT Data amount is summed over sites per traffic type:

FactorActivityNRTrateiBearer

kbpsiBearerTrafficNRTSiteiBeareronIntensityNRT

____

)(________

The number of simultaneous connections at RNC in CS and PS data can be calculated by ErlangB with small blocking (0.1% commonly used).

Calculate the HSDPA traffic using the following equation:

teUsersPerSiSites UserPerTrafficHSDPAOverheadFPTrafficHSDPA ___)_1(_


DN0983585 Issue 02C


17 (39)

Service (TTI) FP bit rate

AMR 12.2 16400

CS 64 (20 ms) 66100

PS 64 (20 ms) 69200

PS 128 (20 ms) 136400

PS 256 (10 ms) 272800

PS 384 (10 ms) 407200

Table 5 Frame Protocol bit rates

As the HSDPA air interface data rates may be changed with 2 ms period, and FP overheads change roughly 3-19% as well, it is recommended to use 11% overhead over the payload rates for HSDPA to include the RLC and FP overheads.

2. Include the SHO overhead for R99 PS data, CS data, and HSUPA. Unless otherwise specified, SHO overhead of 40% is used in the dimensioning phase.

3. Select the mcRNC Capacity Step and then calculate the RNC load according to the rules described in chapter 2.1 Dimensioning based on RNC throughput limitations. If it is difficult to select the optimal capacity step, run calculations for all steps and select the most optimal one (see chapter 5 RNC dimensioning example).

4. Verify the uplink traffic amounts, including the HSUPA traffic according to RNC capacities. For Rel99, in UL direction, 30% of DL traffic is supported and is dimensioned similarly (on Iub interface, with SHO included). With HSUPA, the 30% share is calculated without SHO and thus, the total amount of traffic is greater than with Rel99 (Iub_UL_limit = Iub_DL_limit*0.3*1.4). See chapter 1.3 mcRNC capacity limits for calculated UL limits and chapter 2.1.2 Calculating RNC user plane fill rate based on traffic mix for more details.

The final output should be the number and configuration of RNCs for the planned area.

2.1.2 Calculating RNC user plane fill rate based on traffic mix rule

If the complete traffic demand from the BTSs is known, the traffic mix rule can be applied. In the mixed traffic, the sum of relative loads of the three traffic types (AMR, CS and PS) over the Iub interface has to be less than or equal to 1. Relative load means dividing the offered traffic by the maximum allowed traffic value.


DN0983585 Issue 02C

Therefore, if the result of the following formula is higher than 1, the number of needed RNCs has to be increased.

1)(max

)(

)(max

)(

)(max

)(

MbpsthroughputIub

MbpsdataCS

MbpsthroughputIub

MbpsdataPS

ErlAMR

ErlAMR

Note that:

1. The RNC Iub throughput (Mbps) is the traffic in the downlink (DL) direction defined in

the FP level. It includes 40% of SHO. It is defined with Laptop UE Traffic Profile.

2. 30% of DL traffic is supported in uplink UL direction (UL Iub = 0.3* DL Iu_throughput x fp overheads x SHO)

3. The mcRNC maximum PS throughput can be dynamically divided into the UL and DL proportions (maximum Iu-PS net throughput is greater than 77% for DL traffic and 50% for UL traffic). Therefore, if the expected UL traffic is higher than 30% of the downlink, the values of summed PS traffic DL + UL on Iub can be used in the traffic mix rule instead of the DL only.

4. For the size of the Iur capacity, see Dimensioning Iur chapter in Dimensioning WCDMA RAN: Access Network (Transport) document.

5. The packet data throughput (Mbit/s) is considered for non-real-time traffic.

2.1.3 Control plane dimensioning

Besides mcRNC user plane capacity, control plane capacity check should also be performed to verify whether the selected RNC is able to handle all related control plane functions.

The RNC control plane load strongly depends on the number of subscribers and the related traffic profile. In mcRNC, the control plane capacity is expressed by the maximum CS BHCA and PS BHCA capacity (see chapter 1.3 mcRNC capacity limits).

To check the control plane utilization, the following formula should be used:

1_max_

___

_max_

___

BHCAPS

hourbusyBHCAPS

BHCACS

hourbusyBHCACS


DN0983585 Issue 02C


19 (39)

The maximum CS BHCA and PS BHCA limits are given with the following reference Traffic Profile:

Property Value

Proportion of handovers 40%

CS Mean Holding Time 90 s

hard handovers 0.1 per call

soft handovers 6 per call

CS traffic per user 25 mErl

PS traffic per user 2 kbps

NAS BHCA per user 3.8

PS RAB MHT 185 s

Soft handovers per PS RAB 0,78

Cell updates per PS RAB 2.9

Table 6 Voice and data service call mix

The PS BHCA also depends on how many RRC state changes are made during one call. Values given in chapter 1.3 mcRNC capacity limits are based on traffic profile with the following state changes as average per call:

Figure 6 RRC state changes

The figure above shows the following state changes:

1. Idle to Cell_DCH

2. Cell_DCH to Cell_PCH

3. Cell_PCH to Cell_DCH

4. Cell_DCH to Cell_PCH

5. Cell_PCH to Cell_FACH


DN0983585 Issue 02C

6. Cell_FACH to Cell_Idle

If the expected control plane traffic model is different that the NSN default or it is needed to take into account the PS traffic model more precisely (for example the amount of state transitions per call), then instead of using the above rule, it is recommended to use the modified one:

Where:

PS_session_BHCA Occurs when the packet scheduler attempts to allocate a transport channel for the NRT RAB, and there are no dedicated/shared channels that are already allocated for the RAB. In other words, it is the sum of following state transitions during Busy Hour:

Idle to Cell_DCH

Cell_PCH to Cell_DCH

Cell PCH to Cell_FACH

CS_Proportion = CS_BHCA / (CS_BHCA + PS_session_BHCA)

PS_Proportion = PS_session_BHCA / (CS_BHCA + PS_session_BHCA)

max_PS_Session_ BHCA maximum RNC PS session attempts limit, calculated for each RNC type as: 2x max_PS_BHCA

2.2 RNC dimensioning based on BTS connectivity limits

The dimensioning process for carriers and WBTSs is based on the following principles:

Get the amount of sites and carriers. This is normally available from radio network planning.

Retrieve the relevant limit from the RNC capacity tables.

Define the filling ratio for the limit.

Calculate the number of RNCs based on the following equations:

1_maxmax

___

BHCAPS sessionion * PS proportCS BHCA + ion * CS proport

BHCAsessionPSBHCACS


DN0983585 Issue 02C


21 (39)

ratioFillCarrieritCarrierRNC

carriersofNumberCarrierRNCNeeded

__lim__

__)(_

ratioFillBTSitBTSRNC

BTSsofNumberBTSRNCNeeded

__lim__

__)(_

2.3 Physical interface connectivity

The mcRNC provides Ethernet switching functionality both for the internal communication between the various processing units (USPUs, CSPUs, CFPUs, and EIPUs), and for flexible connection of the external network interfaces to the processing units. The internal communication and external network switching parts are kept totally separated, and each processing unit has its own 10 Gbps Ethernet interfaces for both of these parts. The full line rate switching capacity supported by the product ensures fast and bottleneck-free communication both for the internal and external communication.

The switches of different modules are interconnected via 10 Gbps Ethernet links. Full meshed topology is used to provide a highly resilient and reliable communication also between modules.

For the number and type of physical interfaces that are supported by different configurations of each mcRNC capacity step, see chapter 1.4 Interfaces in mcRNC

To calculate the required number of physical interfaces, which need to be configured for external connectivity, the following perspectives must be considered:

Interface dimensioning perspective (in terms of maximum throughput, processing capacity, and so on)

Configuration and architecture limitation considerations (for example, protection and load sharing principles)

Both of these approaches are described in following subchapters, and both must be considered during the interface number calculation.

2.3.1 Physical interface capacity

Physical interface dimensioning can be limited by one of the following:

Maximum throughput capacity

Static connectivity limitations

Maximum call processing capacity

Maximum throughput capacity

The throughput of interfaces can be limited by physical port bitrates.

To calculate the number of physical interfaces, it is enough to take the maximum overall throughput in one direction (either ingress or egress) and divide it by port bitrate.


DN0983585 Issue 02C

Static connectivity limitations

For IP/Ethernet connectivity, the limitation is the number of VLANs and BFD sessions. Normally, one VLAN and BFD session is used per BTS. In case the VLAN traffic differentiation feature is used, five VLANs per BTS are needed.

In mcRNC, the number of BFD sessions supported is always equal to the BTS connectivity limits for each mcRNC capacity step, and the maximum number of VLANs is 4096 for all the capacity steps.

2.3.2 Configuration and network architecture restrictions

Besides the capacity limitations, which need to be checked during physical interface dimensioning, there are also some restrictions coming out from the internal mcRNC configuration and IP network architecture, which need to be considered:

Recommended IP transport site solution limitations

Recommended solution consists of a pair of Cisco 7600/Juniper EX series routers connected to the mcRNC. With a pair of site routers, the mcRNC needs to be connected to both of them.

Load sharing

In mcRNC, the load is shared among all HW modules. To provide fair load distribution and to avoid potential backplane capacity limitations, each HW module must be connected to the external network.

Link and internal unit protection

For link and unit protection purposes it is recommended that each EIPU unit is connected to each site router with at least one 1 Gbps Ethernet connections. If 10 Gbps Ethernet interfaces are going to be used, then each EIPU needs to be connected to one router.

Considering all these restrictions, the minimum network connectivity requirements can be summarized in the following table:

mcRNC capacity step:

Management interfaces

External connectivity- 1Gbps Eth

External connectivity- 10Gbps Eth

mcRNC S1-A1 2 8 -

mcRNC S5-A1 2 24 -

mcRNC S1-B2 2 8 4

mcRNC S3-B2 2 16 8

Table 7 Minimum interface requirements for mcRNC using 1 Gigabit Ethernet and 10 Gigabit Ethernet


DN0983585 Issue 02C


23 (39)

2.4 Smartphone impact on mcRNC capacity

Introduction

The difference of the smartphone traffic profile comes mainly from the fact that besides higher usage of traditional PS services (for example, web-browsing), a lot of signaling traffic is generated by always on applications (such as instant messaging, weather widgets, push mail, location services, and so on).

For a good user experience, each always on application has to keep the IP connection active for a long time. This is achieved by sending keep alive messages (heartbeats) periodically. As a result, each always on application, on top of the user plane data, has to send and receive small packets very frequently. Depending on the application and network configuration/parameterization, each heartbeat triggers some signalling events, which have to be processed in the RNC (state transition from Cell_PCH to Cell_FACH/Cell_DCH or even the whole PS call attempt procedure). The resulting Smartphone Traffic Profile is characterized by a very high control plane load compared to low PS throughput.

Smartphone traffic impact on mcRNC dimensioning

Because of high control plane resource consumption caused by smartphones, a maximum PS throughput in the mcRNC cannot be achieved with this kind of traffic. To have an indication on the achievable throughput with smartphone traffic profile, separate capacity limits are defined for Smartphone Iub PS throughput as well as Smartphone BHCA (see chapter 1.3 mcRNC capacity limits).

Smartphone BHCA contains both, CS and PS BHCA with 30%/70% split. The whole Smartphone Traffic Profile is presented in the table below:


DN0983585 Issue 02C

Property Value

CS BHCA per subscriber 1

PS BHCA per subscriber 2.3



hard handovers 0.1 per CS call

soft handovers 6 per CS call


PS traffic per user 2,34 kbps


PS RAB MHT 239 s

SHO per PS RAB 2

Table 8 Smartphone traffic profile


DN0983585 Issue 02C


25 (39)

3 RNC SW license keys

High-capacity mcRNCs enables capacity licensing. Capacity upgrades are possible only with an upgrade of an SW license. No HW changes are required for the capacity upgrade when the capacity fits the limits of the HW capability.

Capacity can be freely SW configured for:

Data (PS throughput)

Voice (AMR Erlangs)

Number of unlocked cells

This way the RNC becomes a flexible product for both small and big operators. Operators may first buy only a limited operating SW (OSW) capacity, but for the maximum HW needed to cover installation and commissioning the operators pays only once.

To use any of the licensed features, the license must be installed in the mcRNC. For capacity-type features, the capacity limit must be defined.

3.1 AMR Erlangs license

The AMR Erlangs license provides the maximum number of simultaneous AMR RABs. The RNC counts the number of simultaneous AMR RABs periodically. When the amount is greater than the licensed capacity, the RNC does not admit new AMR RABs as long as the amount decreases below the licensed limit. In practice, some overcapacity is allowed and hysteresis is used between starting and stopping the AMR limitation. Pre-emption is used - higher priority AMR RABs may pre-empt lower priority AMR RABs when the licensed capacity is exceeded.


DN0983585 Issue 02C

Figure 7 AMR capacity license principle

3.2 PS throughput capacity license

The PS throughput license provides the maximum RNC downlink PS throughput in Mbit/s. The RNC counts the PS throughput received on each Iu-PS interface periodically. The PS throughput on Iub is factored in by adding the FP header overhead factor (11%) to the measured GTP throughput. Iu-CS traffic, Iur traffic, or soft handover overhead do not count as the PS data throughput.

When the throughput is higher than the licensed capacity, the RNC starts to limit the downlink PS throughput on each Iu-PS interface. The throughput is limited in small steps, considering the TCP behavior on packet dropping. When the throughput is limited, packet dropping cannot be avoided. When the RNC-level PS throughput decreases, the throughput limitation is first decreased and eventually stopped. In practice, some overcapacity is allowed and hysteresis is used between starting, decreasing, and stopping of the throughput limiting.


DN0983585 Issue 02C


27 (39)

Figure 8 PS Throughput License principle

3.3 Number of unlocked carriers

The number of carriers capacity license provides the O&M with a limit for the maximum number of unlocked cells to be connected to the RNC element. The OMU is involved in this licensing process.


DN0983585 Issue 02C

4 BTS load distribution factor (uneven load factor)

4.1 Background

In real-life networks, daily traffic in certain BTSs is distributed differently over time. In BTSs placed in urban areas, traffic is at its highest during working hours, which is between 07:00 and 17:00. While in BTSs placed in rural areas, traffic is at its highest in the afternoons or in the evenings.

In many cases, BTSs with different traffic profiles and traffic distribution in space and time work under one RNC. Therefore, BTS load distribution needs to be considered during the RNC and Iub dimensioning process to decrease the number of RNCs needed in the network.

.

4.2 BTS load distribution factor definition

Even load calculation

Currently, in the RNC and interfaces dimensioning process, a traffic profile is defined per user and per BTS area in busy hours, but it is not defined when these busy hours (BH) happen in each BTS. It is assumed that BH in all BTSs happens at the same time, so the worst case is considered. At the RNC level, traffic demand is calculated simply by summing up BH traffic over all BTSs.


DN0983585 Issue 02C


29 (39)

Figure 9 Even load calculation

Uneven load calculation

In real-life networks, high traffic in BTSs happens only for 2-3 hours per day, and is distributed unevenly in time across the network. As a result, at the RNC level, the traffic is quite evenly spread out for most of the day, but it is much lower than indicated by the even load calculation method.


DN0983585 Issue 02C

Figure 10 Uneven load calculation

The difference between the RNC traffic demand calculated by even load calculations and uneven load calculations is called the BTS load distribution factor (LDF).

Figure 11 BTS load distribution factor

To calculate the BTS load distribution factor (LDF), comply with the following principles:

Identify the busiest hour (BH) for each cell and the volume of data carried in that hour and work out each BTS personal BH throughput.


DN0983585 Issue 02C


31 (39)

Sum up these to give an equivalent throughput value (see section Even load calculation).

Identify the traffic in each BTS in every hour of the day.

Sum up these for every hour and choose the highest result to give an aggregated BH throughput value (see section Uneven load calculation).

To calculate the BTS load distribution factor, divide an equivalent throughput value by the aggregated BH throughput.

LDF calculation makes it possible to estimate how the RNC load, calculated by the tools, can be decreased according to traffic distribution over time. The following throughput parameters are decreased:

AMR calls [Erl]

CS data [Mbps]

PS data [Mbps]

4.3 Rule example In theory, for 300 BTSs connected to one RNC, each with 5 Mbps traffic demand in busy hours, most of the tools assume that BTS busy hours happen at the same time in all the BTSs. Therefore, the needed RNC data throughput would be:

300 BTS * 5 Mbps per BTS = 1500 Mbps

Because of the geographical distribution, BTSs under one RNC have their busy hours at different times of the day. Therefore, the needed RNC level throughput seems to be much lower. To simplify the example, there are five BTS areas, depending on traffic distribution in time:

BTS Area

No. of BTSs

BTS busy hour load at :

9 pm [Mbps]

12 pm [Mbps]

6 pm [Mbps]

Area 1 40 1.5 5 1

Area 2 70 0.5 5 3

Area 3 120 0.5 1 5

Area 4 50 5 2.5 1.5

Area 5 20 3 5 0.5

Table 9 Example: BTS BH distribution


DN0983585 Issue 02C

After adding up the traffic per each area, the traffic demand at the RNC level at defined hours is as follows:

BTS Area

No. of BTSs

Area busy hour load at :

9 pm [Mbps]

12 pm [Mbps]

6 pm [Mbps]

Area 1 40 60 200 40

Area 2 70 35 350 210

Area 3 120 60 120 600

Area 4 50 250 125 75

Area 5 20 60 100 10

RNC level 300 465 895 935

Table 10 Example: Calculated BH traffic at the RNC level

Considering BTS BH distribution in time, the maximum load at the RNC level is 935 Mbps and it is at 18:00. With this data, it is possible to calculate the BTS load distribution factor (LDF):

LDF = 1500 Mbps / 935 Mbps = 1.6

Once you have calculated the LDF, it is possible to decrease the needed RNC throughputs that are calculated by the tools by dividing them by 1.6. The values received reflect the required throughput with respect to traffic distribution over time.

In real-life networks, traffic at the RNC level is quite even between 10:00 and 01:00, that is for ~15 hours.


DN0983585 Issue 02C


33 (39)

5 RNC dimensioning example

Throughput limitation check

Note that the purpose of this example is only to describe the dimensioning method. The actual RNC capacity figures and formulas must be verified from the mcRNC product description. The assumption is that based on the Radio Network Plan, there are 4000 BTSs, 1000 subscribers per BTS and the SHO is 30%. The number of subscribers per BTS is an average value in the network during the Busy Hour. The traffic mix and HSPA mean rates per subscriber assumed in the example are presented in the table below.

Traffic type BHCA Traffic per subs

AMR 0.95 25 mErl

CS data 0.05 3.2 mErl

PS Rel99 0.1 480 bps

HSDPA 0.2 950 bps

Table 11 Standard traffic model

Total AMR load can be calculated as follows:

AMR Load = 4000 BTSs * 1000 subscribers * 0.025 Erl= 100 000 Erl

CS data Erlangs are summed in the same manner:

CS data load = 4000 BTSs * 1000 subscribers * 0.0032 Erl= 12 800 Erl

The number of simultaneous connections at the RNC can be calculated by ErlangB with small blocking:

ErlB (12800, 0.1) = 12 984 channels

Adding 30% SHO results in 16 880 channels

The load for RNC throughput is calculated with the overhead down to FP layer (see Table 5 for the Frame Protocol bit rates):

CS data load = 16 880 * 66.1 kbps = 1116 Mbps


DN0983585 Issue 02C

PS Rel99 data traffic is summed over sites per traffic type. In the example, the mean PS Rel99 traffic split from standard traffic model is used:

NRT64 25%

NRT128 20%

NRT384 55%

According to this split, and adding 80% of the NRT activity factor, traffic intensities are calculated as follows:

bearerskbps

kbpsNRT 9375

%8064

%25480400064

bearerskbps

kbpsNRT 3750

%80128

%204804000128

bearerskbps

kbpsNRT 3438

%80384

%554804000384

Simultaneous bearers with 0.1% blocking probability and 30% SHO:

NRT64: ErlB(9375, 0.1%) * 1.3= 9541 * 1.3 = 12547 bearers

NRT128: ErlB(3750, 0.1%) * 1.3= 3870 * 1.3 = 5031 bearers

NRT384: ErlB(3438, 0.1%) * 1.3= 3554 * 1.3 = 4621 bearers

The RNC throughput load is calculated by multiplying the number of bearers by FP bit rate for each traffic type (see Table 5 Frame Protocol bit rates):

NRT64: 12547 * 69.5 kbps = 872 Mbps

NRT128: 5031 * 136.7 kbps = 688 Mbps

NRT384: 4621 * 408 kbps = 1885 Mbps

HSDPA load:

MbpsloadHSDPAji

4218950.011.110004000

Calculated throughputs are summarized in the following table:

Traffic type BHCA Traffic per subs

Traffic per BTS

Network traffic

AMR 0.95 25 mErl 25 Erl 100000 Erl

CS data 0.05 3.2 mErl 3.2 Erl 1116 Mbps

PS Rel99 0.1 480 bps 0.480 Mbps 3445 Mbps

HSDPA 0.2 950 bps 0.950 Mbps 4218 Mbps

Total PS traffic 0.3 1430 bps 1.430 Mbps 7663 Mbps

Table 12 Network traffic summation


DN0983585 Issue 02C


35 (39)

The UL share of the PS traffic in the standard traffic model is less than 30 %, so the UL traffic does not need to be considered separately in the RNC dimensioning.

The next step is to put the calculated traffic demands into a Traffic Mix Rule and calculate how many mcRNCs are needed to fulfill the throughput requirement. To select the optimal result, this step has to be replied for each capacity step. The RNC load can be calculated with an 85% filling ratio:

mcRNC S1-A1:

19.25%85910

7663

%85910

1116

%858500

100000

Mbps

Mbps

Mbps

Mbps

Erl

Erl

Results for all the capacity steps and optimization profiles are presented in the following table:

mcRNC type Number of mcRNCs Number of modules

mcRNC S1-A1 26 52

mcRNC S5-A1 7 42

mcRNC S1-B2 12 24

mcRNC S3-B2 5 20

Table 13 Calculated number of mcRNCs/modules from throughput point of view

The received results show that for mcRNC S7-B2 capacity step, the number of modules is the lowest, however, the appropriate capacity step can be chosen also based on, for example, the geographical traffic distribution in the network.

The number of RNCs needed in the network can be decreased also by applying BTS load distribution factor described in chapter 4 BTS load distribution factor (uneven load factor), when the traffic demands are given at BTS level.

RNC control plane check

For the 4 000 000 subscribers with given BHCAs described in Table 11, the total CS BHCA and PS BHCA in Busy Hour can be calculated:

CS_BHCA = 4 000 000 * (0.95+0.05) = 4 000 000;

PS_BHCA = 4 000 000 * 0.3 = 1 200 000;

For Control Plane calculation, also 85% fill ratio can be used:

mcRNC S1-A1:

75.16%85485000

1200000

%85340000

4000000


DN0983585 Issue 02C

Results for all the capacity steps and optimization profiles are presented in the following table:


mcRNC S1-A1 17 34

mcRNC S5-A1 5 30

mcRNC S1-B2 8 16

mcRNC S3-B2 3 12

Table 14 Calculated number of mcRNCs/modules from Control Plane point of view

It can be concluded, that with this traffic profile, the Control Plane will not be a first limiting factor.

Carrier / BTS connectivity check

For 4000 BTSs with three carriers assigned to one BTS, 12000 carriers are needed. The number of mcRNCs with 85% filling ratio is calculated using the following equation:

mcRNC/s1:

01.10%851410

12000)(_

CarrierRNCNeeded

01.10%85470

4000)(_

BTSRNCNeeded

The results for all the capacity steps and optimization profiles are presented in the following table:


mcRNC S1-A1 11 22

mcRNC S5-A1 5 30

mcRNC S1-B2 10 20

mcRNC S3-B2 4 16

Table 15 Calculated number of mcRNCs/modules from carrier/BTS connectivity point of view


DN0983585 Issue 02C


37 (39)

6 Annexes

6.1 Annex 1 Counters and KPIs used for mcRNC dimensioning

To obtain network dimensioning parameters from live network, following KPIs, counters and formulas can be used

Parameter name KPI/ counter formula

User Plane

AMR [Erl] = RNC_280b

PS Data [Mbps] =(HSDPA_Net_Load[Mbps] + PS_Rel99NRTLoad)*1,11

CS Data [Mbps] = M1002C69 * 66,1 / (SHO_overhead * 1000* DURATION)

SHO_overhead =RNC_192b/100+1

HSDPA_Net_Load[Mbps] =M5000C126 / (1000 * 1,05* DURATION)

PS_Rel99NRTLoad =((M802C8/1000) - HSDPA_Net_Load[Mbps])* SHO_Overhead

Control Plane

CS_BHCA = M1001C66+ M1001C67+ M1001C68+ M1001C653+ M1001C655+ M1001C657)

PS_BHCA = M1001C70+ M1001C71+ M1001C72+ M1001C651+ M1001C817+ M1001C826

PS_Session_BHCA RNC_930b

State transitions

DCH-FACH =M1006C45 / DURATION - "HS-DSCH-FACH"

FACH-DCH =M1006C46 / DURATION - "FACH-HS-DSCH"

HS-DCH-FACH =M1006C154 / DURATION

FACH-HS-DSCH '=M1006C127 / DURATION

FACH-PCH =(M1006C181) / DURATION


DN0983585 Issue 02C

Parameter name KPI/ counter formula

PCH-FACH =M1006C171/DURATION

DCH-PCH =M1006C114 / DURATION

PCH-DCH =M1006C175/DURATION

BTS / Cell connectivity

Cell Number RNC_2172a

BTS Number RNC_2171a

Table 16 KPIs and counters to be used for mcRNC dimensioning

6.2 Annex 2 NSN default Traffic Profiles

The user traffic profile defines the UE behavior in a customer network. Because users behave differently from each other, it is not possible to define one, common traffic profile for all of them. That is why Nokia Siemens Networks defined three reference UE traffic profiles for three typical UE types:

Basic UE

Smartphone UE

Laptop UE

The traffic profiles for each type of UE are presented in the tables below.

Property Value


PS BHCA per subscriber 0,1






PS traffic per user 0,06 kbps


PS RAB MHT 80

SHO per PS RAB 2

Table 17 Basic UE Traffic Profile


DN0983585 Issue 02C


39 (39)

Property Value


PS BHCA per subscriber 2.3






PS traffic per user 2.34 kbps


PS RAB MHT 239 s

SHO per PS RAB 2

Table 18 Smartphone UE Traffic Profile

Property Value


PS BHCA per subscriber 1

Proportion of handovers -

CS Mean Holding Time -

hard handovers -

soft handovers -

CS traffic per user -

PS traffic per user 21.3 kbps


PS RAB MHT 1000 s

SHO per PS RAB 5.3

Table 19 Laptop UE Traffic Profile

Each operator then can define its Operator Profile based on share of different UE types. Nokia Siemens Networks defined three reference Operator Profiles with different UE types share (Basic UE/ Smartphone UE / Laptop UE):

Voice centric operator: 79%/20%/1%

Middle-field operator: 20%/79%/1%

Data centric operator: 10%/10%/80%

Dimensioning WCDMA RAN_ McRNC

Documents

mentioned hardware

c approval date

customer comments

software products

mcrnc hardware

product names

free of material errors

business interruption