dimensioning wcdma ran - rnc (crnc and mcrnc)

WCDMA RAN, Rel. RU50, Operating Documentation

Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)

DNXXXXXXX Issue 01 Approval Date 2014-XX-XX

Disclaimer Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)

2 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.

Issue 01

DNXXXXXXX

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 Solutions and 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 Solutions and 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 Solutions and 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 Solutions and Networks and the customer. However, Nokia Solutions and 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 Solutions and Networks will, if deemed necessary Nokia Solutions and Networks, explain issues which may not be covered by the document. Nokia Solutions and Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL NOKIA SOLUTIONS AND 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. NSN is a trademark of Nokia Solutions and Networks. Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their respective

owners, and they are mentioned for identification purposes only. Copyright Nokia Solutions and Networks 2014. All rights reserved.

Nokia Solutions and Networks are continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for power use and proper disposal of our products and their components.

If you should have questions regarding our Environmental Policy or any of the environmental services

we offer, please contact us at Nokia Solutions and Networks for additional information.


Issue 01

DNXXXXXXX

Copyright 2014 Nokia Solutions and Networks. All rights reserved.

3/38

Table of Contents

This document has 38 pages.

Summary of changes ............................................................................................................. 6

1 Introduction ..................................................................................................... 7

2 Dimensioning process ..................................................................................... 8

2.1 cRNC and mcRNC common dimensioning aspects ......................................... 9

2.1.1 User plane limitation check ............................................................................. 9

2.1.2 Control plane dimensioning ........................................................................... 12

2.1.3 BTS/cell connectivity check ........................................................................... 14

2.2 cRNC specific dimensioning aspects ............................................................. 14

2.2.1 Physical interface dimensioning .................................................................... 14

2.2.1.1 Maximum throughput limitation check ........................................................... 15

2.2.1.2 Control plane limitation check........................................................................ 16

2.2.1.3 Static connectivity limitation check ................................................................ 16

2.3 mcRNC specific dimensioning aspects .......................................................... 17

2.3.1 Physical interface dimensioning .................................................................... 17

2.4 Smartphone impact on RNC capacity ............................................................ 20

3 RNC SW license keys ................................................................................... 22

3.1 AMR erlangs license ..................................................................................... 22

3.2 PS throughput capacity license ..................................................................... 23

3.3 Number of unlocked carriers ......................................................................... 24

4 BTS load distribution factor (uneven load factor) ........................................... 25

4.1 Background ................................................................................................... 25

4.2 BTS load distribution factor definition ............................................................ 25

4.3 Rule example ................................................................................................ 28

5 RNC dimensioning example .......................................................................... 30

6 Annexes ........................................................................................................ 35

6.1 Annex 1 Counters and KPIs used for mcRNC dimensioning ...................... 35

6.2 Annex 2 NSN default traffic profiles ............................................................ 36



Issue 01

DNXXXXXXX

List of Figures

Figure 1 Overview of RNC dimensioning process ......................................................... 8

Figure 2 User plane limitation check ........................................................................... 10

Figure 3 RRC state changes ....................................................................................... 13

Figure 4 Physical interface dimensioning process ....................................................... 15

Figure 5 AMR capacity license principle ...................................................................... 23

Figure 6 PS throughput license principle ..................................................................... 24

Figure 7 Even load calculation .................................................................................... 26

Figure 8 Uneven load calculation ................................................................................ 27

Figure 9 BTS load distribution factor ........................................................................... 27


Issue 01

DNXXXXXXX


5/38

List of Tables

Table 1 Frame protocol bit rates ................................................................................ 11

Table 2 Voice and data service call mix ..................................................................... 12

Table 3 Performance limitations for NPS1 and NPGE in various scenarios................ 16

Table 4 Minimum interface requirements for mcRNC ................................................. 19

Table 5 Smartphone traffic profile .............................................................................. 20

Table 6 Example: BTS BH distribution ....................................................................... 28

Table 7 Example: calculated BH traffic at the RNC level ............................................ 29

Table 8 Standard traffic model ................................................................................... 30

Table 9 Network traffic summation ............................................................................. 31

Table 10 Calculated number of mcRNCs/modules from throughput point of view ........ 32

Table 11 Calculated number of mcRNCs/modules from control plane point of view ..... 33

Table 12 Calculated number of mcRNCs/modules from carrier/BTS connectivity point of view............................................................................................................... 34

Table 13 KPIs and counters to be used for mcRNC dimensioning ............................... 35

Table 14 Basic UE traffic profile ................................................................................... 36

Table 15 Smartphone UE traffic profile ........................................................................ 37

Table 16 Laptop UE traffic profile ................................................................................. 37

Summary of changes Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)


Issue 01

DNXXXXXXX

Summary of changes

Changes between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues.

Issue 01 (2014-XX-XX, RU50)

This is the first issue of this document.

Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) Introduction

Issue 01

DNXXXXXXX


7/38

1 Introduction This document describes the dimensioning methodologies for classic RNC (cRNC) and Multicontroller RNC (mcRNC). For simplicity, both the abovementioned WCDMA radio network controllers (RNCs) will be generally called RNC in this document.

Dimensioning process Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)


Issue 01

DNXXXXXXX

2 Dimensioning process RNC dimensioning is a process that determines the minimum RNC configuration required to satisfy the customer traffic demand with a required grade of service (GoS) level. It can be visualized using a simple workflow chart, as shown in Figure 1 Overview of RNC dimensioning process. Some dimensioning steps are common for both types of RNCs and some are specific only for only one of them. Therefore, this chapter is divided into two parts: RNC common dimensioning aspects and RNC-specific dimensioning aspects.

Figure 1 Overview of RNC dimensioning process

RNC dimensioning requires the preliminary dimensioning of the base transceiver stations (BTSs), Uu, Iub, Iur, and Iu interfaces to be done aside from RNC dimensioning itself. Uu dimensioning and calculation of the required number of BTSs is described in detail in Dimensioning WCDMA RAN: Air Interface. Transport interface dimensioning (Iub, Iur, IuCS, and IuPS) is described in detail in Dimensioning WCDMA RAN: Transport Interfaces. The

Kyera.YlaganSticky Note There seems to be too much space

Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) Dimensioning process

Issue 01

DNXXXXXXX


9/38

number of subscribers and the subscriber traffic profile (both user and control Plane) must also be known.

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

calculation of aggregated user plane traffic demand and verification against RNC capacity limitations for packet-switched (PS) data throughput and adaptive multi-rate (AMR) capacity (in erlangs) according to the traffic mix rule

calculation of the control plane load in terms of busy hour call attempts (BHCA), state transitions, and other signaling events and verification against the RNC limits

verification of the number of BTSs and cells to be connected against the RNC limits

calculation of 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 (for more details, see chapter 3 RNC SW license keys). The RNC limits are defined by the specific hardware and software configuration and can be checked in RNC Product Description documents.

2.1 cRNC and mcRNC common dimensioning aspects

2.1.1 User plane limitation check

Figure 2 User plane limitation check 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 and their traffic profile, with a distinction between voice, circuit-switched (CS), PS, and high-speed packet access (HSPA) traffic.

Kyera.YlaganHighlightSuggestion:mention what "this" pertains to.

Kyera.YlaganHighlight For more information on, see...

Kyera.YlaganHighlight configurations

Kyera.YlaganHighlightSuggestion: If possible, do not start sentence with a figure, table or number.



Issue 01

DNXXXXXXX

Figure 2 User plane limitation check

Based on the subscriber traffic profile, values for the offered traffic at the RNC level can be calculated. During the calculation, follow these principles:

1. Calculate the user traffic from the BTSs as 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 frame protocol (FP) bit rates (see Table 1 Frame protocol bit rates) with 100% activity (in PS non-real time (NRT) data, a smaller activity factor can be used).

Note that:

AMR traffic is treated independently from other load as far as the Iub throughput limitation is concerned.

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

FactorActivityNRTrateiBearer

kbpsiBearerTrafficNRTSiteiBeareronIntensityNRT

____

)(________

The number of simultaneous connections at the RNC in CS and PS data can be calculated using erlang B with small blocking (0.1% is commonly used).

2. Include the soft handover (SHO) overhead for R99 PS data, CS data, and high-speed uplink packet access (HSUPA). Unless otherwise specified, a SHO overhead of 40% is used in the dimensioning phase.

3. HSPA dimensioning high-speed downlink packet access (HSDPA) load can be calculated with the equation below:

teUsersPerSiSites UserPerTrafficHSDPAOverheadFPTrafficHSDPA ___)_1(_The HSDPA air interface data rates can be changed with a 2-ms period and FP overheads change roughly between 3-19% as well. Therefore, it is

Kyera.YlaganHighlightwith a small

Kyera.YlaganHighlight an

Kyera.YlaganHighlightusing


Issue 01

DNXXXXXXX


11/38

recommended to use 11% overhead over the payload rates for HSDPA to include the radio link control (RLC) and FP overheads.

4. Verify the uplink traffic amounts, including the HSUPA traffic, according to RNC capacities. For R99, in the UL direction, 30% of DL traffic is supported and is dimensioned similarly (on the 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 R99 (Iub_UL_limit = Iub_DL_limit x 0.3

x 1.4).

5. Select the RNC capacity step and calculate the RNC load according to the rule described in the Calculating RNC user plane fill rate based on traffic mix rule section. If it is too difficult to select the optimal capacity step, run calculations for all steps and select the most optimal one (see chapter 5 RNC dimensioning example).

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

Table 1 Frame protocol bit rates

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

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 mixed traffic, the sum of the relative loads of the three traffic types (AMR, CS, and PS) over the Iub-interface must be less than or equal to 1. Relative load means dividing the offered traffic by the maximum allowed traffic value. Therefore, if the result of the following formula is higher than 1, the number of needed RNCs must be increased.

1)(max

)(

)(max

)(

)(max

)(

MbpsthroughputIub

MbpsdataCS

MbpsthroughputIub

MbpsdataPS

ErlAMR

ErlAMR

Kyera.YlaganHighlightthe DL

Kyera.YlaganHighlightthus,

Kyera.YlaganHighlightDid you mean "greater than R99"?

Kyera.YlaganHighlightthe traffic

Kyera.YlaganHighlightA relative load



Issue 01

DNXXXXXXX

Note that:

1. RNC Iub throughput (in Mbps) is the traffic in the downlink (DL) direction defined in the FP level and it includes 40% of SHO. It is defined with the Laptop UE traffic profile.

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

3. RNC 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 DL, the values of the summed PS traffic (DL + UL) on Iub can be used in the traffic mix rule instead of DL only.

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

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

2.1.2 Control plane dimensioning

Aside from the user plane capacity, control plane capacity check must also be done to verify whether the selected RNC can handle all related control plane functions.

The RNC Control plane load strongly depends on the number of subscribers and the related traffic profile. In the RNC, the control plane capacity is expressed by the maximum CS BHCA and PS BHCA capacity (see RNC Product Descriptions for more details).

To check the control plane usage, use the following formula:

1_max_

_

_max_

_

BHCAPS

BHCAPS

BHCACS

BHCACS

The maximum CS BHCA and PS BHCA limits are given with the reference traffic profile in Table 2 Voice and data service call mix:

Table 2 Voice and data service call mix

Property Value

Proportion of handovers 40%

CS mean holding time 90 s

hard handovers 0.1 per call

soft handovers 6 per call

Kyera.YlaganHighlightthe DL traffic

Kyera.YlaganHighlightof using the DL only.

Kyera.YlaganHighlightLink this text if possible


Issue 01

DNXXXXXXX


13/38

Property Value

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

The PS BHCA also depends on how many radio resource controller (RRC) state changes are made during one call. The values given in RNC Product Descriptions are based on a traffic profile with the following state changes as average per call:

Figure 3 RRC state changes

Figure 3 RRC state changes shows the following states:

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

6. Cell_FACH to Idle

If the expected control plane traffic model is different from the NSN default or it is needed to consider 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:

1

_max

__

max

_

BHCAPS session

BHCAsessionPS

CS BHCA

BHCACS



Issue 01

DNXXXXXXX

Where:

PS_session_BHCA occurs when the packet scheduler attempts to allocate transport channel for the NRT radio access bearer (RAB) and there are no dedicated/shared channels that are already allocated for the RAB. In other words, it is the sum of the following state transitions during busy hour:

Idle to Cell_DCH

Cell_PCH to Cell_DCH

Cell_PCH to Cell_FACH

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

2.1.3 BTS/cell connectivity check

The dimensioning process for cells 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:

ratioFillCarrieritCarrierRNC

carriersofNumberCarrierRNCNeeded

__lim__

__)(_

ratioFillBTSitBTSRNC

BTSsofNumberBTSRNCNeeded

__lim__

__)(_

2.2 cRNC specific dimensioning aspects

2.2.1 Physical interface dimensioning

For the number and type of interfaces that are supported by different configurations of each RNC, see RNC Product Descriptions. The interfaces

can be configured flexibly according to the operators requests and capacity needs.

Both synchronous transport module 1 (STM-1) and Gigabit Ethernet (GE) interfaces can be present in the same RNC. The physical interface dimensioning process is described in Figure 4 Physical interface dimensioning process:

Kyera.YlaganHighlight For more information on the...

Kyera.YlaganHighlight Use italics for variables represented by letters and normal typeface for operators (x, ,+, and ).

Kyera.YlaganHighlight Use italics for variables represented by letters and normal typeface for operators (x, ,+, and ).


Issue 01

DNXXXXXXX


15/38

Figure 4 Physical interface dimensioning process

2.2.1.1 Maximum throughput limitation check

Regarding the user plane, the maximum throughput coming from all logical interfaces terminated on one physical interface card must be checked against the card limitation. This maximum can be defined either per port or per whole card. The idea is to check whether unidirectional bandwidth (BW) per port does not exceed the maximum port rate and that symmetrical traffic per card does not exceed the maximum card bit rate.

NPGE

Each GE port in NPGE(P) supports 1000 Mbps throughput symmetrically at the Ethernet level. With two GE ports, NPGE(P) supports the maximum of 1.65 Gbit/s symmetrical because of switching fabric (SFU) port rate limitation.

The small packet size decreases achievable throughput. For example, in an Iu-CS AMR call, 75 bytes at the IP level decreases to 39 bytes at the application level.

The NPGE packet forwarding capacity is 2.6 Mpps total in both directions, including signaling. In the Iu-CS interface, one NPGE can support about 32 000 erlangs of traffic with the NSN traffic mix because of the CS-call small packet size.

NPS1

The maximum throughput of NPS1(P) is 1200 Mbit/s symmetrical traffic at the ATM level. This means that the maximum bandwidth of eight STM-1 interfaces is fully used. The maximum throughput with ATM adaptation layer type 2 (AAL2) traffic is 1000 Mbit/s. If the asynchronous transfer mode (ATM) policing is used, AAL2 switching capacity throughput decreases to 890 Mbit/s.

Kyera.YlaganHighlight



Kyera.YlaganHighlight put a space after "Iur BW,"

Kyera.YlaganHighlightinterfaces that are terminated

Kyera.YlaganHighlightDid you mean "maximum throughput"?

Kyera.YlaganHighlightthe switching fabric

Kyera.YlaganHighlight...forwarding's total capacity is 2.6 Mbps in both directions.



Issue 01

DNXXXXXXX

2.2.1.2 Control plane limitation check

Call processing also affects the load of an NPS1(P)/NPGE(P) unit. This can be presented in terms of BHCA capacity per unit (similar to whole RNC). The BHCA capacity per NPS1 and NPGE is defined according to the following typical configurations:

Iu-CS and Iu-PS on the same unit

Iub dedicated unit

Iub, Iu-CS, and Iu-PS on the same unit

Table 3 Performance limitations for NPS1 and NPGE in various scenarios

NPS1(P) CS BHCA

NPS1(P) PS BHCA

NPS1(P) PS session attempts

NPGE(P) CS BHCA

NPGE(P) PS BHCA

NPGE(P) PS session attempts

Iu-CS/Iu-PS

1 280 000 618 600 1 237 2000 1 280 000 850 590 1 701 180

Iub 751 640 512 330 1 024 660 626 370 512 160 1 024 320

Iub/Iu-CS/Iu-PS

691 480 410 370 820 740 583 960 386 950 773 900

These values are given with the NSN traffic mix.

Control plane dimensioning rules for physical interface cards are identical to RNC-level control plane dimensioning, as described in chapter 2.1.2 Control plane dimensioning.

2.2.1.3 Static connectivity limitation check

Aside from user and control plane capacity check, some static connectivity limitations must also be verified against card limitations. These limitations are different for each transport technology and are explained in the following sections.

IP

For IP/Ethernet connectivity, the limitation is the number of virtual local area networks (VLANs), IP-based routes, and Bidirectional Forwarding Direction (BFD) sessions.

The following list shows the number of IP objects supported in NPGE(P):

static route: 3000

IP-based route: 1024

Kyera.YlaganHighlightthe RNC-level

Kyera.YlaganHighlightDid you mean "Detection"?


Issue 01

DNXXXXXXX


17/38

VLAN: 600

BFD session: 600

Normally, one VLAN and BFD session is used per BTS. Therefore, NPGE capacity is 600 BTS. Static routes do not limit BTS values, because only one route is used per BTS.

ATM

For ATM connectivity, the limitation is the number of UP virtual channel (VCs) and virtual paths (VPs).

The following list shows the number of ATM objects supported per NPS1:

User plane: 3800

One NPS1(P) can support 2000 VCs for other purposes at the same time, that is, signaling links, semi-permanent VCs, and so on. The total number per RNC is 31 800 for all types of VCs, 14 000 for UP VCs (AAL2 paths).

AAL2 path per VP: 512

VPs: 1744

Shaped VPs: 768

VC bundles: 1440

The maximum number of BTSs connected to one NPS1 depends on the number of user plane VCs configured to the BTS. When using an average of three user plane VCs per BTS, up to 3800/3 = 1267 BTSs per NPS unit can be connected.

If shaped VPs and/or VC bundles are used, depending on the configured amount of bundles and shaped VPs per BTS, such configurations can affect the maximum possible BTS number per NPS1.

2.3 mcRNC specific dimensioning aspects

2.3.1 Physical interface dimensioning

The mcRNC provides Ethernet switching functionality for both the internal communication between the various processing units (USPUs, CSPUs, CFPUs, and EIPUs) as well as 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.

Kyera.YlaganHighlight channels

Kyera.YlaganHighlightthat are supported

Kyera.YlaganHighlightVCs and 14 000 for...

Kyera.YlaganHighlightthat are connected

Kyera.YlaganHighlightthe flexible connection

Kyera.YlaganHighlightcapacity that is supported

Kyera.YlaganHighlightfor both



Issue 01

DNXXXXXXX

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

For the number and type of physical interfaces that are supported by different configurations of each mcRNC capacity step, see the mcRNC Product Description document.

To calculate the required number and type of physical interfaces that must 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 those approaches are described in the following subchapters and both must be considered during the interface number calculation.

Physical interface capacity

Physical interface dimensioning can be limited by:

the maximum throughput capacity

static connectivity limitations

the maximum call processing capacity

Maximum throughput capacity

The throughput of interfaces can be limited by physical port bit rates.

At the moment, only 1 Gbps Ethernet ports can be used for external connectivity, therefore, to calculate the number of 1 Gbps Ethernet interfaces it is enough to take the maximum overall throughput in one direction (either ingress or egress) and divide it by 1 Gbps. For protection purposes, the obtained number of ports must be doubled to provide the appropriate level of link protection.

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. If 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 capacity steps.

Configuration and network architecture restrictions

Aside from the capacity limitations, which must be checked during physical interface dimensioning, there are also some restrictions coming from the

Kyera.YlaganHighlightFor more information on the number...

Kyera.YlaganHighlightCurrently,

Kyera.YlaganHighlightinterfaces,

Kyera.YlaganHighlightsessions that are supported


Issue 01

DNXXXXXXX


19/38

internal mcRNC configuration and IP network architecture, which must be considered:

1. Recommended IP transport site solution limitations

The recommended solution consists of a pair of Cisco 7600 series routers connected to the mcRNC. With a pair of site routers, the mcRNC must be connected to both of them.

2. 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 comprising an EIPU unit must be connected to the external network.

3. 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 1 Gbps Ethernet connections.

Considering all these restrictions, the minimum network connectivity requirements can be summarized in Table 4 Minimum interface requirements for mcRNC.

Table 4 Minimum interface requirements for mcRNC

Minimum Number of Ethernet ports required (without RAN2696)

S1-A1 S5-A1 S1-B2 S3-B2

Shared EIPUs 8 x 1 GbE 24 x 1 GbE 8 x 1 GbE 16 x 1 GbE

Separate Iu and Iub/Dedicated EIPUs

Iu Interfaces 4 x 1 GbE 8 x 1 GbE 4 x 1 GbE 8 x 1 GbE

Iub interface 4 x 1 GbE 16 x 1 GbE 4 x 1 GbE 8 x 1 GbE

Minimum Number of Ethernet ports required (with RAN2696)

- - S1-B2 S3-B2

Shared EIPUs - - 4 x 10 GbE 8 x 10 GbE

Separate Iu and Iub/Dedicated EIPUs

Iu Interfaces - - 2 x 10 GbE 4 x 10 GbE

Iub interface - - 8 x 1 GbE 16 x 1 GbE

Kyera.YlaganHighlightSuggestion: that must be considered.

Kyera.YlaganHighlight if the order of the listed items is not relevant, use a bullet list

Kyera.YlaganSticky Noterouters that are

Kyera.YlaganSticky NoteTo provide a fair load distribution



Issue 01

DNXXXXXXX

2.4 Smartphone impact on RNC capacity

Introduction

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

For a good user experience, each always on application must 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, must send and receive small packets very frequently. Depending on the application and network configuration/parameterization, each heartbeat triggers some signaling events, which must be processed in the RNC (state transition from Cell_PCH to Cell_FACH/Cell_DCH or even whole PS call attempt procedure). The resulting smartphone traffic profile is characterized by a very high control plane load compared to a 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. In order to have an indication on the achievable capacity with the smartphone traffic profile, a separate capacity limit is defined for smartphone BHCA.

Smartphone BHCA contains both CS and PS BHCA with a 30%/70% split. The whole smartphone traffic profile is presented in Table 5 Smartphone traffic profile:

Table 5 Smartphone traffic profile

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

Kyera.YlaganHighlight To

Kyera.YlaganHighlight30%-70%

Kyera.YlaganHighlightremove the bullet

Kyera.YlaganHighlightremove the bullet


Issue 01

DNXXXXXXX


21/38

Property Value


PS RAB MHT 239 s

SHO per PS RAB

Kyera.YlaganSticky Note -

RNC SW license keys Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)


Issue 01

DNXXXXXXX

3 RNC SW license keys High capacity mcRNC enables capacity licensing. Capacity upgrades are possible only with an upgrade of an SW license. No HW changes are required in 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 can first buy only a limited operating SW (OSW) capacity, but maximum HW to cover installation and commissioning costs only once.

To use any of the licensed features, the license must be installed in the mcRNC. For capacity-type features, the capacity 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 can pre-empt lower priority AMR RABs when the licensed capacity is exceeded.

Kyera.YlaganHighlightA high

Kyera.YlaganHighlightthe maximum HW

Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) RNC SW license keys

Issue 01

DNXXXXXXX


23/38

Figure 5 AMR capacity license principle

3.2 PS throughput capacity license

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. 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. Throughput is limited in small steps, taking into account TCP behavior on packet dropping. When throughput is limited, packet dropping cannot be avoided. When the RNC level PS throughput decreases, the throughput limitation is decreased first and eventually stopped. In practice, some overcapacity is allowed and hysteresis is used between starting, decreasing, and stopping the throughput limiting.

Kyera.YlaganHighlightthat is received

RNC SW license keys Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)


Issue 01

DNXXXXXXX

Figure 6 PS throughput license principle

3.3 Number of unlocked carriers

The number of carrier capacity licenses 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.

Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) BTS load distribution factor (uneven load factor)

Issue 01

DNXXXXXXX


25/38

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, the highest amount of traffic happens during working hours, that is, between 7 AM and 5 PM, while in BTSs placed in rural areas, the highest amount of traffic happens 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 must be considered during the RNC dimensioning process to decrease the number of RNCs needed in the network and also to prepare cost-efficient offers for the customers.

LDF must be used only when the traffic model is defined on the BTS level. If the traffic model is already defined on the RNC level, it already includes the impact of LDF.

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 the BH in all BTSs happen at the same time, so the worst case is considered. At the RNC level, traffic demand is calculated simply by summing BH traffic over all BTSs.

Kyera.YlaganHighlightthat are

Kyera.YlaganHighlightinterfaces

BTS load distribution factor (uneven load factor) Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)


Issue 01

DNXXXXXXX

Figure 7 Even load calculation

Uneven load calculation

In real-life networks, high traffic in BTSs happens only for two to three hours per day and it 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.


Issue 01

DNXXXXXXX


27/38

Figure 8 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 9 BTS load distribution factor

To calculate the BTS (LDF), follow these principles:

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

Kyera.YlaganHighlightthat is calculated

BTS load distribution factor (uneven load factor) Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)


Issue 01

DNXXXXXXX

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

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

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

Divide an equivalent throughput value by the aggregated BH throughput value to calculate the BTS load distribution factor.

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

300 BTS x 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 the traffic distribution in time, as shown in Table 6 Example: BTS BH distribution:

Table 6 Example: BTS BH distribution

BTS Area No. of BTSs BTS bushy 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


Kyera.YlaganHighlightBTSs that are connected

Kyera.YlaganHighlight... to one RNC (each BTS having 5 Mbps traffic during busy hours), most of the tools...

Kyera.YlaganHighlight busy

Kyera.YlaganHighlight Use italics for variables represented by letters and normal typeface for operators (x, , +, and ).


Issue 01

DNXXXXXXX


29/38

After adding up the traffic per area, the traffic demand at the RNC level at defined hours as shown in Table 7 Example: calculated BH traffic at the RNC level:

Table 7 Example: calculated BH traffic at the RNC level

BTS Area No. of BTSs BTS bushy 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

Considering the BTS BH distribution in time, the maximum load at the RNC level is 695 Mbps and it is at 6 PM. With this data, the BTS load distribution factor (LDF) can be calculated:

LDF = 1500 Mbps/935 Mbps = 1.6

Once the LDF is calculated, the needed RNC throughputs that are calculated by the tools can be decreased 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 AM-1 AM, that is, for ~15 hours.

Kyera.YlaganHighlight busy

Kyera.YlaganHighlight 18:00

Kyera.YlaganHighlight Use italics for variables represented by letters and normal typeface for operators (x, , +, and ).

Kyera.YlaganHighlightthat are received


Kyera.YlaganHighlight Write times of day using the 24-hour clock, with a colon separating hours from minutes and, when necessary, minutes from seconds.

Kyera.YlaganHighlight Write times of day using the 24-hour clock, with a colon separating hours from minutes and, when necessary, minutes from seconds.

RNC dimensioning example Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)


Issue 01

DNXXXXXXX

5 RNC dimensioning example Throughput limitation check

The purpose of this example is only to describe the dimensioning method. The actual RNC capacity figures and formulas must be verified from the RNC Product Descriptions. 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 hours. The traffic mix and HSPA mean rates per subscriber are assumed to be similar to those given in the NSN standard traffic model for dimensioning. Also in the example, the mcRNC is considered as RNC type.

Table 8 Standard traffic model

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

Total AMR load can be calculated as follows:

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

CS data erlangs are summed in the same manner:

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

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

ErlB (12 800, 0.1) = 12 984 channels

Adding 30% SHO results in 16 880 channels.

Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) RNC dimensioning example

Issue 01

DNXXXXXXX


31/38

The load for RNC throughput is calculated with the overhead down to the FP layer (for details, see Table 1 Frame protocol bit rates):

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

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

- NRT64 25%

- NRT128 20%

- NRT384 55%

According to this split, and adding 80% of 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%) x 1.3 = 9541 x 1.3 = 12 547 bearers

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

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

RNC throughput load is calculated by multiplying the number of bearers by FP bit rate for each traffic type (for details, see Table 1 Frame protocol bit rates):

NRT64: 12 547 x 69.5 kbps = 872 Mbps

NRT128: 5031 x 136.7 kbps = 688 Mbps

NRT384: 4621 x 408 kbps = 1885 Mbps

HSDPA load:

MbpsloadHSDPAji

4218950.011.110004000

Calculated throughputs are summarized in Table 9 Network traffic summation:

Table 9 Network traffic summation

Traffic type BHCA Traffic per subs Traffic per BTS Network traffic

AMR 0.95 25 mErl 25 Erl 100 000 Erl

Kyera.YlaganHighlight put a space in between the number and the unit

Kyera.YlaganHighlightThe following are simultaneous bearers...

Kyera.YlaganHighlightThe RNC throughput...

Kyera.YlaganHighlight align left



Issue 01

DNXXXXXXX

Traffic type BHCA Traffic per subs Traffic per BTS Network traffic

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

The UL share of the PS traffic in the standard traffic model is less than 30%, so the UL traffic does not need 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 most optimal result, this step has to be repeated for each capacity. The RNC load can be calculated with 85% filling ratio:

mcRNC S1-A1:

19.25%85910

7663

%85910

1116

%858500

100000

Mbps

Mbps

Mbps

Mbps

Erl

Erl

The results for all the capacity steps are presented in Table 10 Calculated number of mcRNCs/modules from throughput point of view.

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

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

mcRNC S3-B7 2 16

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

The number of RNCs needed in the network can also be decreased by applying BTS load distribution factor described in chapter 4 BTS load distribution factor (uneven load factor).




Kyera.YlaganHighlight If the numbers are in a table and the decimal alignment is necessary, align to the rightand separate all with spaces to indicate the division of thousands

Kyera.YlaganHighlightIf the numbers are in a table and the decimal alignment is necessary, align to the rightand separate all with spaces to indicate the division of thousands



Kyera.YlaganHighlight to be considered

Kyera.YlaganHighlightthat are needed

Kyera.YlaganHighlightthe BTS

Kyera.YlaganHighlightthat is described

Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) RNC dimensioning example

Issue 01

DNXXXXXXX


33/38

RNC Control Plane check

For the 4 000 000 subscribers with given BHCAs described in Table 13 KPIs and counters to be used for mcRNC dimensioning, the total CS BHCA and PS BHCA in busy hour can be calculated:

CS_BHCA = 4 000 000 x (0.95 + 0.05) = 4 000 000

PS_BHCA = 4 000 000 x 0.3 = 1 200 000

For control plane calculation, 85% fill ratio can also be used:

mcRNC S1-A1:

75.16%85485000

1200000

%85340000

4000000

The results for all the capacity steps and optimization profiles are presented in Table 11 Calculated number of mcRNCs/modules from control plane point of view.

Table 11 Calculated number of mcRNCs/modules from control plane point of view


mcRNC S1-A1 17 34

mcRNC S5-A1 5 30

mcRNC S1-B2 8 16

mcRNC S3-B2 3 12

mcRNC S7-B2 2 16

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

Carrier/BTS connectivity check

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

mcRNC/VDB/s1:

69.10%851320

12000)(_

CarrierRNCNeeded

69.10%85440

4000)(_

BTSRNCNeeded

Kyera.YlaganHighlight plane



Issue 01

DNXXXXXXX

The results for all the capacity steps and optimization profiles are presented in Table 12 Calculated number of mcRNCs/modules from carrier/BTS connectivity point of view.

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


mcRNC S1-A1 11 22

mcRNC S5-A1 5 30

mcRNC S1-B2 10 20

mcRNC S3-B2 4 16

mcRNC S7-B2 2 16

Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) Annexes

Issue 01

DNXXXXXXX


35/38

6 Annexes 6.1 Annex 1 Counters and KPIs used for mcRNC

dimensioning

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

Table 13 KPIs and counters to be used for mcRNC dimensioning

Parameter name KPI/counter formula

User plane

AMR [Erl] = RNC_280b

PS Data [Mbps] = (HSDPA_Net_Load[Mbps] + PS_Rel99NRTLoad) x 1.11

CS Data [Mbps] = M1002C69 x 66.1/(SHO_overhead x 1000 x DURATION)

SHO_overhead = RNC_192b/100 + 1

HSDPA_Net_Load [Mbps]

= M5000C126/(1000 x 1.05 x DURATION)

PS_Rel99NRTLoad = ((M802C8/1000) HSDPA_Net_Load [Mbps]) x 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

Annexes Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)


Issue 01

DNXXXXXXX

Parameter name KPI/counter formula

HS-DCH-FACH = M1006C154/DURATION

FACH-HS-DSCH = M1006C127/DURATION

FACH-PCH = (M1006C181)/DURATION

PCH-FACH = M1006C171/DURATION

DCH-PCH = M1006C114/DURATION

PCH-DCH = M1006C175/DURATION

BTS/cell connectivity

Cell Number RNC_2172a

BTS Number RNC_2171a

6.2 Annex 2 NSN default traffic profiles

The user traffic profile defines the UE behavior in a customer network. Users behave differently from each other; therefore it is not possible to define one common traffic profile for all of them. That is why NSN defined three reference UE traffic profiles for three typical UE types:

Basic UE

Smartphone UE

Laptop UE

These traffic profiles are presented in Table 14, Table 15, and Table 16.

Table 14 Basic UE traffic profile

Property Value









Kyera.YlaganHighlightcheck if this apostrophe is needed

Kyera.YlaganHighlightUE's/UEs'

Kyera.YlaganHighlighttherefore, one common traffic profile cannot be defined for all of them.

Kyera.YlaganHighlightbasic

Kyera.YlaganHighlights

Kyera.YlaganHighlightl

Kyera.YlaganHighlight Include complete table titles

Kyera.YlaganHighlightremove bulletsconsider combining the two entries in one cell

Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) Annexes

Issue 01

DNXXXXXXX


37/38

Property Value


PS RAB MHT 80

SHO per PS RAB 2

Table 15 Smartphone UE traffic profile

Property Value










PS RAB MHT 239 s

SHO per PS RAB 7

Table 16 Laptop 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 -



Annexes Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)


Issue 01

DNXXXXXXX

Property Value



PS RAB MHT 1000 s

SHO per PS RAB 5.3

Each operator can then define its operator profile based on the ratio of different UE types. NSN has defined three reference operator profiles with different UE type ratios (Basic UE/Smartphone UE/Laptop UE):

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

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

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

Kyera.YlaganHighlightv

Kyera.YlaganHighlightm

Kyera.YlaganHighlight d

Kyera.YlaganHighlight79:20:1or79-20-1

Table of ContentsList of FiguresList of TablesSummary of changes1 Introduction2 Dimensioning process2.1 cRNC and mcRNC common dimensioning aspects2.1.1 User plane limitation checkCalculating RNC user plane fill rate based on traffic mix rule

2.1.2 Control plane dimensioning2.1.3 BTS/cell connectivity check

2.2 cRNC specific dimensioning aspects2.2.1 Physical interface dimensioning2.2.1.1 Maximum throughput limitation check2.2.1.2 Control plane limitation check2.2.1.3 Static connectivity limitation check

2.3 mcRNC specific dimensioning aspects2.3.1 Physical interface dimensioningPhysical interface capacityConfiguration and network architecture restrictions

2.4 Smartphone impact on RNC capacity

3 RNC SW license keys3.1 AMR erlangs license3.2 PS throughput capacity license3.3 Number of unlocked carriers

4 BTS load distribution factor (uneven load factor)4.1 Background4.2 BTS load distribution factor definition4.3 Rule example

5 RNC dimensioning example6 Annexes6.1 Annex 1 Counters and KPIs used for mcRNC dimensioning6.2 Annex 2 NSN default traffic profiles

dimensioning wcdma ran - rnc (crnc and mcrnc)

Documents

copyright nokia solutions

use of nokia solutions

trademark of nokia solutions

necessary nokia solutions

networks customers

rnc crnc

mcrnc issue

mcrnc dnxxxxxxx issue