WCDMA RAN, Rel. RU50, Operating Documentation Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) DNXXXXXXX Issue 01 Approval Date 2014-XX-XX
Oct 03, 2015
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.
Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)
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
Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)
4 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)
Issue 01
DNXXXXXXX
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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)
6 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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)
8 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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.
Dimensioning process Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)
10 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) Dimensioning process
Issue 01
DNXXXXXXX
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Dimensioning process Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)
12 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) Dimensioning process
Issue 01
DNXXXXXXX
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Dimensioning process Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)
14 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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 ).
Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) Dimensioning process
Issue 01
DNXXXXXXX
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
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.
Dimensioning process Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)
16 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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"?
Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) Dimensioning process
Issue 01
DNXXXXXXX
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Dimensioning process Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)
18 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) Dimensioning process
Issue 01
DNXXXXXXX
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Dimensioning process Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)
20 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Proportion of handovers 40%
CS mean holding time 90 s
hard handovers 0.1 per CS call
soft handovers 6 per CS call
CS traffic per user 25 mErl
PS traffic per user 2.34 kbps
Kyera.YlaganHighlight To
Kyera.YlaganHighlight30%-70%
Kyera.YlaganHighlightremove the bullet
Kyera.YlaganHighlightremove the bullet
Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) Dimensioning process
Issue 01
DNXXXXXXX
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
21/38
Property Value
NAS BHCA per user 3.8
PS RAB MHT 239 s
SHO per PS RAB
Kyera.YlaganSticky Note -
RNC SW license keys Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)
22 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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)
24 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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)
26 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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.
Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) BTS load distribution factor (uneven load factor)
Issue 01
DNXXXXXXX
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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)
28 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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.YlaganHighlightthe traffic
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 ).
Dimensioning WCDMA RAN: RNC (cRNC and mcRNC) BTS load distribution factor (uneven load factor)
Issue 01
DNXXXXXXX
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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.YlaganHighlightthe traffic
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)
30 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
RNC dimensioning example Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)
32 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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 align left
Kyera.YlaganHighlight align left
Kyera.YlaganHighlight align left
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.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.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
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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 type Number of mcRNCs Number of modules
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
RNC dimensioning example Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)
34 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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 type Number of mcRNCs Number of modules
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
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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)
36 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
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
CS BHCA per subscriber 1
PS BHCA per subscriber 0.1
Proportion of handovers 40%
CS mean holding time 90 s
hard handovers 0.1 per CS call
soft handovers 6 per CS call
CS traffic per user 25 mErl
PS traffic per user 0.06 kbps
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
Copyright 2014 Nokia Solutions and Networks. All rights reserved.
37/38
Property Value
NAS BHCA per user 3.8
PS RAB MHT 80
SHO per PS RAB 2
Table 15 Smartphone UE traffic profile
Property Value
CS BHCA per subscriber 1
PS BHCA per subscriber 2.3
Proportion of handovers 40%
CS mean holding time 90 s
hard handovers 0.1 per CS call
soft handovers 6 per CS call
CS traffic per user 25 mErl
PS traffic per user 2.34 kbps
NAS BHCA per user 3.8
PS RAB MHT 239 s
SHO per PS RAB 7
Table 16 Laptop UE traffic profile
Property Value
CS BHCA per subscriber 0
PS BHCA per subscriber 1
Proportion of handovers -
CS mean holding time -
hard handovers -
soft handovers -
CS traffic per user -
Kyera.YlaganHighlightremove bulletsconsider combining the two entries in one cell
Kyera.YlaganHighlightremove bulletsconsider combining the two entries in one cell
Annexes Dimensioning WCDMA RAN: RNC (cRNC and mcRNC)
38 /38 Copyright 2014 Nokia Solutions and Networks. All rights reserved.
Issue 01
DNXXXXXXX
Property Value
PS traffic per user 21.3 kbps
NAS BHCA per user 3.8
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