Dimensioning WCDMA RAN_ McRNC
-
Upload
chastity-miller -
Category
Documents
-
view
466 -
download
81
description
Transcript of Dimensioning WCDMA RAN_ McRNC
-
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
1 (39)
WCDMA RAN, Rel.RU40, Operating Documentation
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C Approval date: 2013-09-03
Confidential
-
2 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.
The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given as is and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.
Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.
This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.
The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.
Copyright Nokia Siemens Networks 2013. All rights reserved.
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
3 (39)
Table of contents
Summary of changes ............................................................................ 4 List of figures and tables .......................................................................... 5
1 Overview ............................................................................... 6 1.1 mcRNC hardware ................................................................... 6 1.2 mcRNC functional architecture .............................................. 7 1.3 mcRNC capacity limits ......................................................... 10 1.4 Interfaces in mcRNC ............................................................ 12
2 Dimensioning process....................................................... 14 2.1 Dimensioning based on RNC throughput limitations ........... 15 2.1.1 User Plane dimensioning ..................................................... 15 2.1.2 Calculating RNC user plane fill rate based on traffic mix
rule ....................................................................................... 17 2.1.3 Control plane dimensioning ................................................. 18 2.2 RNC dimensioning based on BTS connectivity limits .......... 20 2.3 Physical interface connectivity ............................................. 21 2.3.1 Physical interface capacity ................................................... 21 2.3.2 Configuration and network architecture restrictions ............. 22 2.4 Smartphone impact on mcRNC capacity ............................. 23
3 RNC SW license keys ........................................................ 25 3.1 AMR Erlangs license ............................................................ 25 3.2 PS throughput capacity license ............................................ 26 3.3 Number of unlocked carriers ................................................ 27
4 BTS load distribution factor (uneven load factor) .......... 28 4.1 Background .......................................................................... 28 4.2 BTS load distribution factor definition .................................. 28 4.3 Rule example ....................................................................... 31
5 RNC dimensioning example ............................................. 33
6 Annexes .............................................................................. 37 6.1 Annex 1 Counters and KPIs used for mcRNC
dimensioning ........................................................................ 37 6.2 Annex 2 NSN default Traffic Profiles ................................ 38
-
4 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
Summary of changes
This document comprises 39 pages.
Changes between Issues 02B (2013-05-03, RU40) and 02C (2013-09-03, RU40)
Updated values in the following tables:
- Table 1 mcRNC capacity and performance limits mcRNC2.0 HW
- Table 2 mcRNC capacity and performance limits - mcRNC3.0 HW
- Table 3 mcRNC physical interfaces (BCN-A)
- Table 6 Voice and data service call mix
- Table 8 Smartphone traffic profile
Added Table 4 mcRNC physical interfaces (BCN-B)
Updated Figure 6 RRC state changes
Updated formula for Calculating RNC user plane fill rate based on traffic mix rule in chapter 2: Dimensioning process
Added new paragraphs and modified formula for checking control plane utilization in subchapter 2.1.3 Control plane dimensioning
Added chapter 6: Annexes
Changes between Issues 02A (2013-02-26, RU40) and 02B (2013-05-03, RU40)
Updated values in the following tables:
- Table 1 mcRNC capacity and performance limits mcRNC2.0 HW
- Table 2 mcRNC capacity and performance limits - mcRNC3.0 HW
- Table 14 Calculated number of mcRNCs/modules from Control Plane point of view
Changes between Issues 02 (2012-12-05, RU40) and 02A (2013-02-26, RU40) Updated values in the following tables:
- Table 1 mcRNC capacity and performance limits mcRNC2.0 HW
- Table 2 mcRNC capacity and performance limits - mcRNC3.0 HW
Updated formula for RNC Control Plane check in chapter 5: RNC dimensioning example
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
5 (39)
List of figures and tables
Figure 1 mcRNC HW module architecture .................................................................................................. 7 Figure 2 The block diagram of the mcRNC HW module ............................................................................. 8 Figure 3 Capacity steps in mcRNC ........................................................................................................... 10 Figure 4 Overview of mcRNC dimensioning process ................................................................................ 15 Figure 5 Dimensioning RNC - throughput limitation check ....................................................................... 16 Figure 6 RRC state changes ..................................................................................................................... 19 Figure 7 AMR capacity license principle ................................................................................................... 26 Figure 8 PS Throughput License principle ................................................................................................ 27 Figure 9 Even load calculation .................................................................................................................. 29 Figure 10 Uneven load calculation ............................................................................................................ 30 Figure 11 BTS load distribution factor ....................................................................................................... 30 Table 1 mcRNC capacity and performance limits mcRNC2.0 HW ........................................................ 11 Table 2 mcRNC capacity and performance limits - mcRNC3.0 HW ......................................................... 12 Table 3 mcRNC physical interfaces (BCN-A)............................................................................................ 13 Table 4 mcRNC physical interfaces (BCN-B)............................................................................................ 13 Table 5 Frame Protocol bit rates ............................................................................................................... 17 Table 6 Voice and data service call mix .................................................................................................... 19 Table 7 Minimum interface requirements for mcRNC using 1 Gigabit Ethernet and 10 Gigabit Ethernet 22 Table 8 Smartphone traffic profile ............................................................................................................. 24 Table 9 Example: BTS BH distribution ...................................................................................................... 31 Table 10 Example: Calculated BH traffic at the RNC level ....................................................................... 32 Table 11 Standard traffic model ................................................................................................................ 33 Table 12 Network traffic summation .......................................................................................................... 34 Table 13 Calculated number of mcRNCs/modules from throughput point of view ................................... 35 Table 14 Calculated number of mcRNCs/modules from Control Plane point of view ............................... 36 Table 15 Calculated number of mcRNCs/modules from carrier/BTS connectivity point of view .............. 36 Table 16 KPIs and counters to be used for mcRNC dimensioning ........................................................... 38 Table 17 Basic UE Traffic Profile .............................................................................................................. 38 Table 18 Smartphone UE Traffic Profile .................................................................................................... 39 Table 19 Laptop UE Traffic Profile ............................................................................................................ 39
-
6 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
1 Overview The Multicontroller RNC (mcRNC) is a realization of the UTRAN 3G Radio Network Controller (RNC) on hardware comprising many multi-core processors along with the necessary memory, storage, switching, and networking equipment in a rack mount box configuration. The functionality of the RNC is achieved by the software running typically on two or more such modules, which are also known as Box Controller Nodes (BCNs).
The software complies with the 3GPP specified protocols for interacting with other Network Elements.
A general description of the RNC and its functions is available in Multicontroller RNC Product Description.
1.1 mcRNC hardware
The mcRNC consists of several mcRNC HW modules (BCNs), and each BCN contains a motherboard with a management processor and eight separate add-on cards, containing multi-core processors that are connected to the motherboard through PCI-e connectors. With these features, the same hardware can be used for processing of the user, control, transport and management plane functions.
The single physical switch is divided into two logical switches one for external network communication and the other for internal network communication. Each processor in the add-on card is connected to the external switch and the internal switch.
The functional blocks of one hardware node are shown in Figure 1 mcRNC HW module architecture.
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
7 (39)
Figure 1 mcRNC HW module architecture
1.2 mcRNC functional architecture
The box-based mcRNC concept is an attempt to create a telecom product with disruptive hardware and software architecture that clearly outperforms traditional chassis-blade product architectures in terms of cost per MB of data.
As the mcRNC has only one type of processing hardware, in theory, it allows for a large degree of freedom in designing functional software architecture. The logical functions can be freely allocated inside the physical units.
Figure 2: The block diagram of the mcRNC HW module shows the general functional architecture. At high level, the network element consists of the following parts:
Network interface functions
Switching functions
Control plane processing
User plane processing
Carrier connectivity functions
O&M functions
-
8 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
The functions are distributed in entities of hardware and software. The main processing units/entities of the mcRNC are listed below:
Centralized Functions Processing Unit (CFPU)
Cell-Specific Processing Unit (CSPU)
UE-Specific Processing Unit (USPU)
External Interface Processing Unit (EIPU)
Ethernet switches
Figure 2 The block diagram of the mcRNC HW module
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
9 (39)
USPU
This processing unit implements all UE-specific control and user plane processing. Furthermore, all dedicated control plane and user plane resources for a single UE are allocated from the same USPU unit. Therefore, USPU units are completely independent of each other and different USPUs might not have mutual communication at all. It makes implementation of SN+ redundancy functionalities, such as moving UE-specific processing from one processor to another simpler.
USPU consists of the following two functional units:
USCP UE Specific functions and services in the control plane
USUP - UE Specific functions and services in the user plane. This includes the dedicated and shared channel services, since they are relevant for a UE.
CSPU
This processing unit implements all cell-specific control and user plane processing. Furthermore, all control and user plane resources for a single BTS are allocated from the same CSPU unit. Therefore, CSPU units are completely independent of each other and different CSPUs might not have mutual communication at all. The unit uses N + M (M >= 1) redundancy. Allocation of BTSs under control of specific CSPUs is controlled by the Operation and Management Unit (OMU). The same functionality in the OMU also allows for graceful reallocation of BTSs one by one, from one CSPU to another. This feature provides seamless shutdown and replacement of one mcRNC hardware unit.
The CSPU consists of the following two functional units:
CSCP Cell Specific functions and services in Control Plane
CSUP Cell Specific functions and services in User Plane
CFPU
The Centralized Functions Processing Unit (CFPU) consists of the OMU and Centralized Functions Control Plane (CFCP). The OMU performs the basic system maintenance functions such as hardware configuration, alarm system, configuration of signaling transport and centralized recovery functions. It also contains cellular-network-related functions such as radio network configuration management, radio network recovery and RNW database. All the functions that require 2N type of redundancy are located in the CFPU, as it is only 2N (hot standby) redundant processing unit. Additionally, all the location-services-related functions requiring 2N redundancy or centralized processing, like accounting of simultaneous ongoing location-related-procedures in the whole network element, are located in the CFPU. The OMU terminates an external Ethernet interface. Management connections and connections to OMS go through this interface.
EIPU
The External Interface Processing Unit (EIPU) hosts the networking and transport stacks needed for processing both signaling and user plane data. It also handles the load balancing and distribution to other units. It consists of two functional units - the Signaling Transport Plane (SITP) and External Interface Transport Plane (EITP).
-
10 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
1.3 mcRNC capacity limits
mcRNC capacity steps are defined based on the number of BCNs that one Network Element consists of, for example step 1 uses two controller modules, step 3 uses four controller modules and step 5 uses six controller modules.
The first two mcRNC configurations, containing 2 and 6 HW modules (BCNs) are introduced with RU30 System Program release. Those configurations consist of the first version of processor in add-in cards (BCNOC-A) and the first BCN type (BCN-A)
In RU40 System Program release, the following new HW is introduced:
new in add-in cards (BMPP2-B)
new BCN type (BCN-B)
These new add-in cards provide more processing power, which reflects in an increase in RNC capacity. The BCN-B provides a bigger amount of 10GbE interfaces at the front panel.
With the new add-in cards and the new BCN type, two capacity steps are supported: s1 and s3. For all mcRNC capacity steps supported in RU40 System Program Release (with the official naming) please refer to Figure 3 Capacity steps in mcRNC.
Figure 3 Capacity steps in mcRNC
mcRNC capacity and performance limits for all configurations are provided in Table 1.
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
11 (39)
mcRNC capacity step S1-A1 S5-A1
CS BHCA 340 000 1 380 000
PS BHCA 485 000 1 940 000
PS Session BHCA 970 000 3 880 000
Smartphone BHCA 327 000 1 310 000
Smartphone Iub DL/UL throughput [Mbps] 150/60 700/290
max Iub DL/UL throughput [Mbps] 910 / 380 3660 /1530
AMR/CS voice over HSPA capacity [Erlangs]
8500 34500
BTS connectivity 470 1020
Carrier connectivity 1410 3110
RRC connected state UEs 195 000 780 000
Maximum number of Cell_DCH users 10 500 42 000
IuPS HSDPA net bit rate [Mbit/s] 819 3294
IuPS HSUPA net bit rate [Mbit/s] 204 984
Table 1 mcRNC capacity and performance limits mcRNC2.0 HW
-
12 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
mcRNC capacity step S1-B2 S3-B2
CS BHCA 760 000 2 140 000
PS BHCA 1 400 000 3 500 000
PS Session BHCA 2 800 000 7 000 000
Smartphone BHCA 1 170 000 2 940 000
Smartphone Iub DL/UL throughput [Mbps] 450/190 1250/530
max Iub DL/UL throughput [Mbps] 1850 / 790 5260/2260
AMR/CS voice over HSPA capacity [Erlangs]
19000 53500
BTS connectivity 520 1320
Carrier connectivity 2600 6600
RRC connected state UEs 352 000 1 000 000
Maximum number of Cell_DCH users 26400 66000
IuPS HSDPA net bit rate [Mbit/s] 1665 4734
IuPS HSUPA net bit rate [Mbit/s] 500 1420
Table 2 mcRNC capacity and performance limits - mcRNC3.0 HW
_______________________________________________________________________
NOTE
Maximum Iub throughputs are given on Frame Protocol layer. IuPS net bit rates are given on top of GTP-U layer.
_______________________________________________________________________
1.4 Interfaces in mcRNC
The mcRNC provides a set of physical Ethernet / Gigabit Ethernet interfaces to execute physical-layer and transport-layer functions, such as policing, statistics, OAM, buffer management and scheduling. Any interface (except OAM) can be configured to be used as an Iu, Iub or Iur interface with one restriction of four 10 Gbps Ethernet interfaces per HW module reserved for interconnections between HW modules. In addition to LAN interfaces and debugging, management interfaces are provided. The number and types of interfaces for each mcRNC module are presented in the following tables:
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
13 (39)
Interface type
Gigabit Ethernet
10 Gbps Ethernet
Ethernet
Usage Network connections and element management
Inter-module connections
Operating and Maintenance
Standard IEEE 802.3-2005 IEEE 802.3-2005 IEEE 802.3
Physical layer 1000Base-SX/LX/T 10G Direct Attach 10Base-T/100Base-TX/1000Base-T
Number of interfaces BCN-A
16+2(O&M) 6 0-2
Number of interfaces BCN-B
10+2(O&M) 9 0-2
Table 3 mcRNC physical interfaces (BCN-A)
Interface type Gigabit Ethernet
1 and 10 Gbps Ethernet
Ethernet
Usage Network connections and element management
Inter-module connections
Operating and Maintenance
Standard IEEE 802.3-2005 IEEE 802.3-2005 IEEE 802.3
Physical layer 1000Base-SX/LX/T 10G Direct Attach 10Base-T/100Base-TX/1000Base-T
Number of interfaces
10+2(O&M) 9 0-2
Table 4 mcRNC physical interfaces (BCN-B)
-
14 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
2 Dimensioning process
The RNC dimensioning requires preliminary dimensioning of BTSs, Uu, Iub, Iur, and Iu interfaces. The Uu dimensioning and calculation of the required number of BTSs is described in detail in Dimensioning WCDMA RAN: Air Interface.
After having this done, further steps of the RNC dimensioning process can be applied:
1) Calculation of aggregated user plane traffic demand and verification against RNC capacity limitations for PS data throughput on Iub (Mbps) and AMR capacity (Erlangs) according to the Traffic Mix Rule
2) Calculation of the control plane load in terms of Busy Hour Call Attempts and verifying against the RNC limits
3) Verification of the number of BTSs and cells to be connected against the RNC limits
4) Calculation the number of required physical interfaces and verification against the RNC limits
The hardware limits are essential for the RNC dimensioning process. Some of the hardware limits can be additionally limited by software licenses (see chapter RNC SW license keys). The RNC limits are defined by the specific hardware and software configurations.
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
15 (39)
Figure 4 Overview of mcRNC dimensioning process
2.1 Dimensioning based on RNC throughput limitations
2.1.1 User Plane dimensioning
Figure 5 describes the generic method for calculating the total number of RNCs in the network from the user plane traffic perspective. This method gives an overall understanding of the number of RNCs required in relation to subscribers, with a distinction between the voice, CS, PS and HSPA traffic. The UL dimensioning includes DCH and HSUPA.
-
16 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
Figure 5 Dimensioning RNC - throughput limitation check
Based on traffic, the values for the offered traffic on the Iub can be calculated. When calculating, adhere to the following steps:
1. Calculate the user traffic from the BTSs for the expected number of users of each service type: AMR, CS data, PS data and HSPA traffic. Furthermore, define the expected data rates of CS/PS data and HSPA traffic. The data rates used are the FP bit rates (see Table 5 Frame Protocol bit rates) with 100% activity (in PS NRT Data, smaller Activity Factor can be used).
Note that:
AMR traffic is treated independently from other load, as far as the Iub throughput limit is concerned;
PS NRT Data amount is summed over sites per traffic type:
FactorActivityNRTrateiBearer
kbpsiBearerTrafficNRTSiteiBeareronIntensityNRT
____
)(________
The number of simultaneous connections at RNC in CS and PS data can be calculated by ErlangB with small blocking (0.1% commonly used).
Calculate the HSDPA traffic using the following equation:
teUsersPerSiSites UserPerTrafficHSDPAOverheadFPTrafficHSDPA ___)_1(_
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
17 (39)
Service (TTI) FP bit rate
AMR 12.2 16400
CS 64 (20 ms) 66100
PS 64 (20 ms) 69200
PS 128 (20 ms) 136400
PS 256 (10 ms) 272800
PS 384 (10 ms) 407200
Table 5 Frame Protocol bit rates
As the HSDPA air interface data rates may be changed with 2 ms period, and FP overheads change roughly 3-19% as well, it is recommended to use 11% overhead over the payload rates for HSDPA to include the RLC and FP overheads.
2. Include the SHO overhead for R99 PS data, CS data, and HSUPA. Unless otherwise specified, SHO overhead of 40% is used in the dimensioning phase.
3. Select the mcRNC Capacity Step and then calculate the RNC load according to the rules described in chapter 2.1 Dimensioning based on RNC throughput limitations. If it is difficult to select the optimal capacity step, run calculations for all steps and select the most optimal one (see chapter 5 RNC dimensioning example).
4. Verify the uplink traffic amounts, including the HSUPA traffic according to RNC capacities. For Rel99, in UL direction, 30% of DL traffic is supported and is dimensioned similarly (on Iub interface, with SHO included). With HSUPA, the 30% share is calculated without SHO and thus, the total amount of traffic is greater than with Rel99 (Iub_UL_limit = Iub_DL_limit*0.3*1.4). See chapter 1.3 mcRNC capacity limits for calculated UL limits and chapter 2.1.2 Calculating RNC user plane fill rate based on traffic mix for more details.
The final output should be the number and configuration of RNCs for the planned area.
2.1.2 Calculating RNC user plane fill rate based on traffic mix rule
If the complete traffic demand from the BTSs is known, the traffic mix rule can be applied. In the mixed traffic, the sum of relative loads of the three traffic types (AMR, CS and PS) over the Iub interface has to be less than or equal to 1. Relative load means dividing the offered traffic by the maximum allowed traffic value.
-
18 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
Therefore, if the result of the following formula is higher than 1, the number of needed RNCs has to be increased.
1)(max
)(
)(max
)(
)(max
)(
MbpsthroughputIub
MbpsdataCS
MbpsthroughputIub
MbpsdataPS
ErlAMR
ErlAMR
Note that:
1. The RNC Iub throughput (Mbps) is the traffic in the downlink (DL) direction defined in
the FP level. It includes 40% of SHO. It is defined with Laptop UE Traffic Profile.
2. 30% of DL traffic is supported in uplink UL direction (UL Iub = 0.3* DL Iu_throughput x fp overheads x SHO)
3. The mcRNC maximum PS throughput can be dynamically divided into the UL and DL proportions (maximum Iu-PS net throughput is greater than 77% for DL traffic and 50% for UL traffic). Therefore, if the expected UL traffic is higher than 30% of the downlink, the values of summed PS traffic DL + UL on Iub can be used in the traffic mix rule instead of the DL only.
4. For the size of the Iur capacity, see Dimensioning Iur chapter in Dimensioning WCDMA RAN: Access Network (Transport) document.
5. The packet data throughput (Mbit/s) is considered for non-real-time traffic.
2.1.3 Control plane dimensioning
Besides mcRNC user plane capacity, control plane capacity check should also be performed to verify whether the selected RNC is able to handle all related control plane functions.
The RNC control plane load strongly depends on the number of subscribers and the related traffic profile. In mcRNC, the control plane capacity is expressed by the maximum CS BHCA and PS BHCA capacity (see chapter 1.3 mcRNC capacity limits).
To check the control plane utilization, the following formula should be used:
1_max_
___
_max_
___
BHCAPS
hourbusyBHCAPS
BHCACS
hourbusyBHCACS
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
19 (39)
The maximum CS BHCA and PS BHCA limits are given with the following reference Traffic Profile:
Property Value
Proportion of handovers 40%
CS Mean Holding Time 90 s
hard handovers 0.1 per call
soft handovers 6 per call
CS traffic per user 25 mErl
PS traffic per user 2 kbps
NAS BHCA per user 3.8
PS RAB MHT 185 s
Soft handovers per PS RAB 0,78
Cell updates per PS RAB 2.9
Table 6 Voice and data service call mix
The PS BHCA also depends on how many RRC state changes are made during one call. Values given in chapter 1.3 mcRNC capacity limits are based on traffic profile with the following state changes as average per call:
Figure 6 RRC state changes
The figure above shows the following state changes:
1. Idle to Cell_DCH
2. Cell_DCH to Cell_PCH
3. Cell_PCH to Cell_DCH
4. Cell_DCH to Cell_PCH
5. Cell_PCH to Cell_FACH
-
20 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
6. Cell_FACH to Cell_Idle
If the expected control plane traffic model is different that the NSN default or it is needed to take into account the PS traffic model more precisely (for example the amount of state transitions per call), then instead of using the above rule, it is recommended to use the modified one:
Where:
PS_session_BHCA Occurs when the packet scheduler attempts to allocate a transport channel for the NRT RAB, and there are no dedicated/shared channels that are already allocated for the RAB. In other words, it is the sum of following state transitions during Busy Hour:
Idle to Cell_DCH
Cell_PCH to Cell_DCH
Cell PCH to Cell_FACH
CS_Proportion = CS_BHCA / (CS_BHCA + PS_session_BHCA)
PS_Proportion = PS_session_BHCA / (CS_BHCA + PS_session_BHCA)
max_PS_Session_ BHCA maximum RNC PS session attempts limit, calculated for each RNC type as: 2x max_PS_BHCA
2.2 RNC dimensioning based on BTS connectivity limits
The dimensioning process for carriers and WBTSs is based on the following principles:
Get the amount of sites and carriers. This is normally available from radio network planning.
Retrieve the relevant limit from the RNC capacity tables.
Define the filling ratio for the limit.
Calculate the number of RNCs based on the following equations:
1_maxmax
___
BHCAPS sessionion * PS proportCS BHCA + ion * CS proport
BHCAsessionPSBHCACS
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
21 (39)
ratioFillCarrieritCarrierRNC
carriersofNumberCarrierRNCNeeded
__lim__
__)(_
ratioFillBTSitBTSRNC
BTSsofNumberBTSRNCNeeded
__lim__
__)(_
2.3 Physical interface connectivity
The mcRNC provides Ethernet switching functionality both for the internal communication between the various processing units (USPUs, CSPUs, CFPUs, and EIPUs), and for flexible connection of the external network interfaces to the processing units. The internal communication and external network switching parts are kept totally separated, and each processing unit has its own 10 Gbps Ethernet interfaces for both of these parts. The full line rate switching capacity supported by the product ensures fast and bottleneck-free communication both for the internal and external communication.
The switches of different modules are interconnected via 10 Gbps Ethernet links. Full meshed topology is used to provide a highly resilient and reliable communication also between modules.
For the number and type of physical interfaces that are supported by different configurations of each mcRNC capacity step, see chapter 1.4 Interfaces in mcRNC
To calculate the required number of physical interfaces, which need to be configured for external connectivity, the following perspectives must be considered:
Interface dimensioning perspective (in terms of maximum throughput, processing capacity, and so on)
Configuration and architecture limitation considerations (for example, protection and load sharing principles)
Both of these approaches are described in following subchapters, and both must be considered during the interface number calculation.
2.3.1 Physical interface capacity
Physical interface dimensioning can be limited by one of the following:
Maximum throughput capacity
Static connectivity limitations
Maximum call processing capacity
Maximum throughput capacity
The throughput of interfaces can be limited by physical port bitrates.
To calculate the number of physical interfaces, it is enough to take the maximum overall throughput in one direction (either ingress or egress) and divide it by port bitrate.
-
22 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
Static connectivity limitations
For IP/Ethernet connectivity, the limitation is the number of VLANs and BFD sessions. Normally, one VLAN and BFD session is used per BTS. In case the VLAN traffic differentiation feature is used, five VLANs per BTS are needed.
In mcRNC, the number of BFD sessions supported is always equal to the BTS connectivity limits for each mcRNC capacity step, and the maximum number of VLANs is 4096 for all the capacity steps.
2.3.2 Configuration and network architecture restrictions
Besides the capacity limitations, which need to be checked during physical interface dimensioning, there are also some restrictions coming out from the internal mcRNC configuration and IP network architecture, which need to be considered:
Recommended IP transport site solution limitations
Recommended solution consists of a pair of Cisco 7600/Juniper EX series routers connected to the mcRNC. With a pair of site routers, the mcRNC needs to be connected to both of them.
Load sharing
In mcRNC, the load is shared among all HW modules. To provide fair load distribution and to avoid potential backplane capacity limitations, each HW module must be connected to the external network.
Link and internal unit protection
For link and unit protection purposes it is recommended that each EIPU unit is connected to each site router with at least one 1 Gbps Ethernet connections. If 10 Gbps Ethernet interfaces are going to be used, then each EIPU needs to be connected to one router.
Considering all these restrictions, the minimum network connectivity requirements can be summarized in the following table:
mcRNC capacity step:
Management interfaces
External connectivity- 1Gbps Eth
External connectivity- 10Gbps Eth
mcRNC S1-A1 2 8 -
mcRNC S5-A1 2 24 -
mcRNC S1-B2 2 8 4
mcRNC S3-B2 2 16 8
Table 7 Minimum interface requirements for mcRNC using 1 Gigabit Ethernet and 10 Gigabit Ethernet
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
23 (39)
2.4 Smartphone impact on mcRNC capacity
Introduction
The difference of the smartphone traffic profile comes mainly from the fact that besides higher usage of traditional PS services (for example, web-browsing), a lot of signaling traffic is generated by always on applications (such as instant messaging, weather widgets, push mail, location services, and so on).
For a good user experience, each always on application has to keep the IP connection active for a long time. This is achieved by sending keep alive messages (heartbeats) periodically. As a result, each always on application, on top of the user plane data, has to send and receive small packets very frequently. Depending on the application and network configuration/parameterization, each heartbeat triggers some signalling events, which have to be processed in the RNC (state transition from Cell_PCH to Cell_FACH/Cell_DCH or even the whole PS call attempt procedure). The resulting Smartphone Traffic Profile is characterized by a very high control plane load compared to low PS throughput.
Smartphone traffic impact on mcRNC dimensioning
Because of high control plane resource consumption caused by smartphones, a maximum PS throughput in the mcRNC cannot be achieved with this kind of traffic. To have an indication on the achievable throughput with smartphone traffic profile, separate capacity limits are defined for Smartphone Iub PS throughput as well as Smartphone BHCA (see chapter 1.3 mcRNC capacity limits).
Smartphone BHCA contains both, CS and PS BHCA with 30%/70% split. The whole Smartphone Traffic Profile is presented in the table below:
-
24 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
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 2
Table 8 Smartphone traffic profile
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
25 (39)
3 RNC SW license keys
High-capacity mcRNCs enables capacity licensing. Capacity upgrades are possible only with an upgrade of an SW license. No HW changes are required for the capacity upgrade when the capacity fits the limits of the HW capability.
Capacity can be freely SW configured for:
Data (PS throughput)
Voice (AMR Erlangs)
Number of unlocked cells
This way the RNC becomes a flexible product for both small and big operators. Operators may first buy only a limited operating SW (OSW) capacity, but for the maximum HW needed to cover installation and commissioning the operators pays only once.
To use any of the licensed features, the license must be installed in the mcRNC. For capacity-type features, the capacity limit must be defined.
3.1 AMR Erlangs license
The AMR Erlangs license provides the maximum number of simultaneous AMR RABs. The RNC counts the number of simultaneous AMR RABs periodically. When the amount is greater than the licensed capacity, the RNC does not admit new AMR RABs as long as the amount decreases below the licensed limit. In practice, some overcapacity is allowed and hysteresis is used between starting and stopping the AMR limitation. Pre-emption is used - higher priority AMR RABs may pre-empt lower priority AMR RABs when the licensed capacity is exceeded.
-
26 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
Figure 7 AMR capacity license principle
3.2 PS throughput capacity license
The PS throughput license provides the maximum RNC downlink PS throughput in Mbit/s. The RNC counts the PS throughput received on each Iu-PS interface periodically. The PS throughput on Iub is factored in by adding the FP header overhead factor (11%) to the measured GTP throughput. Iu-CS traffic, Iur traffic, or soft handover overhead do not count as the PS data throughput.
When the throughput is higher than the licensed capacity, the RNC starts to limit the downlink PS throughput on each Iu-PS interface. The throughput is limited in small steps, considering the TCP behavior on packet dropping. When the throughput is limited, packet dropping cannot be avoided. When the RNC-level PS throughput decreases, the throughput limitation is first decreased and eventually stopped. In practice, some overcapacity is allowed and hysteresis is used between starting, decreasing, and stopping of the throughput limiting.
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
27 (39)
Figure 8 PS Throughput License principle
3.3 Number of unlocked carriers
The number of carriers capacity license provides the O&M with a limit for the maximum number of unlocked cells to be connected to the RNC element. The OMU is involved in this licensing process.
-
28 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
4 BTS load distribution factor (uneven load factor)
4.1 Background
In real-life networks, daily traffic in certain BTSs is distributed differently over time. In BTSs placed in urban areas, traffic is at its highest during working hours, which is between 07:00 and 17:00. While in BTSs placed in rural areas, traffic is at its highest in the afternoons or in the evenings.
In many cases, BTSs with different traffic profiles and traffic distribution in space and time work under one RNC. Therefore, BTS load distribution needs to be considered during the RNC and Iub dimensioning process to decrease the number of RNCs needed in the network.
.
4.2 BTS load distribution factor definition
Even load calculation
Currently, in the RNC and interfaces dimensioning process, a traffic profile is defined per user and per BTS area in busy hours, but it is not defined when these busy hours (BH) happen in each BTS. It is assumed that BH in all BTSs happens at the same time, so the worst case is considered. At the RNC level, traffic demand is calculated simply by summing up BH traffic over all BTSs.
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
29 (39)
Figure 9 Even load calculation
Uneven load calculation
In real-life networks, high traffic in BTSs happens only for 2-3 hours per day, and is distributed unevenly in time across the network. As a result, at the RNC level, the traffic is quite evenly spread out for most of the day, but it is much lower than indicated by the even load calculation method.
-
30 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
Figure 10 Uneven load calculation
The difference between the RNC traffic demand calculated by even load calculations and uneven load calculations is called the BTS load distribution factor (LDF).
Figure 11 BTS load distribution factor
To calculate the BTS load distribution factor (LDF), comply with the following principles:
Identify the busiest hour (BH) for each cell and the volume of data carried in that hour and work out each BTS personal BH throughput.
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
31 (39)
Sum up these to give an equivalent throughput value (see section Even load calculation).
Identify the traffic in each BTS in every hour of the day.
Sum up these for every hour and choose the highest result to give an aggregated BH throughput value (see section Uneven load calculation).
To calculate the BTS load distribution factor, divide an equivalent throughput value by the aggregated BH throughput.
LDF calculation makes it possible to estimate how the RNC load, calculated by the tools, can be decreased according to traffic distribution over time. The following throughput parameters are decreased:
AMR calls [Erl]
CS data [Mbps]
PS data [Mbps]
4.3 Rule example In theory, for 300 BTSs connected to one RNC, each with 5 Mbps traffic demand in busy hours, most of the tools assume that BTS busy hours happen at the same time in all the BTSs. Therefore, the needed RNC data throughput would be:
300 BTS * 5 Mbps per BTS = 1500 Mbps
Because of the geographical distribution, BTSs under one RNC have their busy hours at different times of the day. Therefore, the needed RNC level throughput seems to be much lower. To simplify the example, there are five BTS areas, depending on traffic distribution in time:
BTS Area
No. of BTSs
BTS busy hour load at :
9 pm [Mbps]
12 pm [Mbps]
6 pm [Mbps]
Area 1 40 1.5 5 1
Area 2 70 0.5 5 3
Area 3 120 0.5 1 5
Area 4 50 5 2.5 1.5
Area 5 20 3 5 0.5
Table 9 Example: BTS BH distribution
-
32 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
After adding up the traffic per each area, the traffic demand at the RNC level at defined hours is as follows:
BTS Area
No. of BTSs
Area busy hour load at :
9 pm [Mbps]
12 pm [Mbps]
6 pm [Mbps]
Area 1 40 60 200 40
Area 2 70 35 350 210
Area 3 120 60 120 600
Area 4 50 250 125 75
Area 5 20 60 100 10
RNC level 300 465 895 935
Table 10 Example: Calculated BH traffic at the RNC level
Considering BTS BH distribution in time, the maximum load at the RNC level is 935 Mbps and it is at 18:00. With this data, it is possible to calculate the BTS load distribution factor (LDF):
LDF = 1500 Mbps / 935 Mbps = 1.6
Once you have calculated the LDF, it is possible to decrease the needed RNC throughputs that are calculated by the tools by dividing them by 1.6. The values received reflect the required throughput with respect to traffic distribution over time.
In real-life networks, traffic at the RNC level is quite even between 10:00 and 01:00, that is for ~15 hours.
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
33 (39)
5 RNC dimensioning example
Throughput limitation check
Note that the purpose of this example is only to describe the dimensioning method. The actual RNC capacity figures and formulas must be verified from the mcRNC product description. The assumption is that based on the Radio Network Plan, there are 4000 BTSs, 1000 subscribers per BTS and the SHO is 30%. The number of subscribers per BTS is an average value in the network during the Busy Hour. The traffic mix and HSPA mean rates per subscriber assumed in the example are presented in the table below.
Traffic type BHCA Traffic per subs
AMR 0.95 25 mErl
CS data 0.05 3.2 mErl
PS Rel99 0.1 480 bps
HSDPA 0.2 950 bps
Table 11 Standard traffic model
Total AMR load can be calculated as follows:
AMR Load = 4000 BTSs * 1000 subscribers * 0.025 Erl= 100 000 Erl
CS data Erlangs are summed in the same manner:
CS data load = 4000 BTSs * 1000 subscribers * 0.0032 Erl= 12 800 Erl
The number of simultaneous connections at the RNC can be calculated by ErlangB with small blocking:
ErlB (12800, 0.1) = 12 984 channels
Adding 30% SHO results in 16 880 channels
The load for RNC throughput is calculated with the overhead down to FP layer (see Table 5 for the Frame Protocol bit rates):
CS data load = 16 880 * 66.1 kbps = 1116 Mbps
-
34 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
PS Rel99 data traffic is summed over sites per traffic type. In the example, the mean PS Rel99 traffic split from standard traffic model is used:
NRT64 25%
NRT128 20%
NRT384 55%
According to this split, and adding 80% of the NRT activity factor, traffic intensities are calculated as follows:
bearerskbps
kbpsNRT 9375
%8064
%25480400064
bearerskbps
kbpsNRT 3750
%80128
%204804000128
bearerskbps
kbpsNRT 3438
%80384
%554804000384
Simultaneous bearers with 0.1% blocking probability and 30% SHO:
NRT64: ErlB(9375, 0.1%) * 1.3= 9541 * 1.3 = 12547 bearers
NRT128: ErlB(3750, 0.1%) * 1.3= 3870 * 1.3 = 5031 bearers
NRT384: ErlB(3438, 0.1%) * 1.3= 3554 * 1.3 = 4621 bearers
The RNC throughput load is calculated by multiplying the number of bearers by FP bit rate for each traffic type (see Table 5 Frame Protocol bit rates):
NRT64: 12547 * 69.5 kbps = 872 Mbps
NRT128: 5031 * 136.7 kbps = 688 Mbps
NRT384: 4621 * 408 kbps = 1885 Mbps
HSDPA load:
MbpsloadHSDPAji
4218950.011.110004000
Calculated throughputs are summarized in the following table:
Traffic type BHCA Traffic per subs
Traffic per BTS
Network traffic
AMR 0.95 25 mErl 25 Erl 100000 Erl
CS data 0.05 3.2 mErl 3.2 Erl 1116 Mbps
PS Rel99 0.1 480 bps 0.480 Mbps 3445 Mbps
HSDPA 0.2 950 bps 0.950 Mbps 4218 Mbps
Total PS traffic 0.3 1430 bps 1.430 Mbps 7663 Mbps
Table 12 Network traffic summation
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
35 (39)
The UL share of the PS traffic in the standard traffic model is less than 30 %, so the UL traffic does not need to be considered separately in the RNC dimensioning.
The next step is to put the calculated traffic demands into a Traffic Mix Rule and calculate how many mcRNCs are needed to fulfill the throughput requirement. To select the optimal result, this step has to be replied for each capacity step. The RNC load can be calculated with an 85% filling ratio:
mcRNC S1-A1:
19.25%85910
7663
%85910
1116
%858500
100000
Mbps
Mbps
Mbps
Mbps
Erl
Erl
Results for all the capacity steps and optimization profiles are presented in the following table:
mcRNC type Number of mcRNCs Number of modules
mcRNC S1-A1 26 52
mcRNC S5-A1 7 42
mcRNC S1-B2 12 24
mcRNC S3-B2 5 20
Table 13 Calculated number of mcRNCs/modules from throughput point of view
The received results show that for mcRNC S7-B2 capacity step, the number of modules is the lowest, however, the appropriate capacity step can be chosen also based on, for example, the geographical traffic distribution in the network.
The number of RNCs needed in the network can be decreased also by applying BTS load distribution factor described in chapter 4 BTS load distribution factor (uneven load factor), when the traffic demands are given at BTS level.
RNC control plane check
For the 4 000 000 subscribers with given BHCAs described in Table 11, the total CS BHCA and PS BHCA in Busy Hour can be calculated:
CS_BHCA = 4 000 000 * (0.95+0.05) = 4 000 000;
PS_BHCA = 4 000 000 * 0.3 = 1 200 000;
For Control Plane calculation, also 85% fill ratio can be used:
mcRNC S1-A1:
75.16%85485000
1200000
%85340000
4000000
-
36 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
Results for all the capacity steps and optimization profiles are presented in the following table:
mcRNC type Number of mcRNCs Number of modules
mcRNC S1-A1 17 34
mcRNC S5-A1 5 30
mcRNC S1-B2 8 16
mcRNC S3-B2 3 12
Table 14 Calculated number of mcRNCs/modules from Control Plane point of view
It can be concluded, that with this traffic profile, the Control Plane will not be a first limiting factor.
Carrier / BTS connectivity check
For 4000 BTSs with three carriers assigned to one BTS, 12000 carriers are needed. The number of mcRNCs with 85% filling ratio is calculated using the following equation:
mcRNC/s1:
01.10%851410
12000)(_
CarrierRNCNeeded
01.10%85470
4000)(_
BTSRNCNeeded
The results for all the capacity steps and optimization profiles are presented in the following table:
mcRNC 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
Table 15 Calculated number of mcRNCs/modules from carrier/BTS connectivity point of view
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
37 (39)
6 Annexes
6.1 Annex 1 Counters and KPIs used for mcRNC dimensioning
To obtain network dimensioning parameters from live network, following KPIs, counters and formulas can be used
Parameter name KPI/ counter formula
User Plane
AMR [Erl] = RNC_280b
PS Data [Mbps] =(HSDPA_Net_Load[Mbps] + PS_Rel99NRTLoad)*1,11
CS Data [Mbps] = M1002C69 * 66,1 / (SHO_overhead * 1000* DURATION)
SHO_overhead =RNC_192b/100+1
HSDPA_Net_Load[Mbps] =M5000C126 / (1000 * 1,05* DURATION)
PS_Rel99NRTLoad =((M802C8/1000) - HSDPA_Net_Load[Mbps])* SHO_Overhead
Control Plane
CS_BHCA = M1001C66+ M1001C67+ M1001C68+ M1001C653+ M1001C655+ M1001C657)
PS_BHCA = M1001C70+ M1001C71+ M1001C72+ M1001C651+ M1001C817+ M1001C826
PS_Session_BHCA RNC_930b
State transitions
DCH-FACH =M1006C45 / DURATION - "HS-DSCH-FACH"
FACH-DCH =M1006C46 / DURATION - "FACH-HS-DSCH"
HS-DCH-FACH =M1006C154 / DURATION
FACH-HS-DSCH '=M1006C127 / DURATION
FACH-PCH =(M1006C181) / DURATION
-
38 (39) Nokia Siemens Networks Confidential
DN0983585 Issue 02C
Parameter name KPI/ counter formula
PCH-FACH =M1006C171/DURATION
DCH-PCH =M1006C114 / DURATION
PCH-DCH =M1006C175/DURATION
BTS / Cell connectivity
Cell Number RNC_2172a
BTS Number RNC_2171a
Table 16 KPIs and counters to be used for mcRNC dimensioning
6.2 Annex 2 NSN default Traffic Profiles
The user traffic profile defines the UE behavior in a customer network. Because users behave differently from each other, it is not possible to define one, common traffic profile for all of them. That is why Nokia Siemens Networks defined three reference UE traffic profiles for three typical UE types:
Basic UE
Smartphone UE
Laptop UE
The traffic profiles for each type of UE are presented in the tables below.
Property Value
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
NAS BHCA per user 3.8
PS RAB MHT 80
SHO per PS RAB 2
Table 17 Basic UE Traffic Profile
-
Dimensioning WCDMA RAN: Multicontroller RNC
DN0983585 Issue 02C
Nokia Siemens Networks Confidential
39 (39)
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 2
Table 18 Smartphone 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 -
PS traffic per user 21.3 kbps
NAS BHCA per user 3.8
PS RAB MHT 1000 s
SHO per PS RAB 5.3
Table 19 Laptop UE Traffic Profile
Each operator then can define its Operator Profile based on share of different UE types. Nokia Siemens Networks defined three reference Operator Profiles with different UE types share (Basic UE/ Smartphone UE / Laptop UE):
Voice centric operator: 79%/20%/1%
Middle-field operator: 20%/79%/1%
Data centric operator: 10%/10%/80%