RADIO NETWORK CONTROLLER · PDF fileRADIO NETWORK CONTROLLER DIMENSIONING The need for high speed, high bandwidth data drives the evolution of wireless networks from

RADIO NETWORKCONTROLLER

DIMENSIONINGThe need for high speed, high bandwidth data drives theevolution of wireless networks from 2G to 3G. The radio networkcontroller is one of the key network elements in the 3G wirelessnetwork as it handles both circuit switched and packet switcheddata and also the associated signaling in both domains. Thereforethe dimensioning of this network element, in terms of controlprocessors, network processors and addressing the terminatinglink capacities is crucial from the operator’s point of view.

This white paper describes an approach for the dimensioning ofthe radio network controller in the 3G wireless network. It alsoexplains the RNC architecture and configurations throughexamples.

WHITE PAPER

SRIVATSA K N

Page: Table of Contents

Table of Contents

Radio Network Controller Dimensioning

INTRODUCTION ............................................................................................................................................................ 3ARCHITECTURE ............................................................................................................................................................. 3THE DIMENSIONING APPROACH .............................................................................................................................. 4

INPUTS FROM TRAFFIC MODEL .................................................................................................................. 5CALL ATTEMPTS ................................................................................................................................. 5DATA RATES ....................................................................................................................................... 5SIGNALLING ASPECTS ...................................................................................................................... 6

BHCA COMPUTATIONS ................................................................................................................................. 6CONTROL PLANE ............................................................................................................................... 6USER PLANE ...................................................................................................................................... 7

USER PLANE REQUIREMENTS ...................................................................................................................... 7CONTROL PLANE REQUIREMENTS .............................................................................................................. 8

MESSAGE COMPLEXITY ANALYSIS METHOD – A SUMMARY ................................................. 8CONTROL PLANE REQUIREMENTS – A SAMPLE OUTPUT ......................................................... 9

LINK CAPACITIES COMPUTATION................................................................................................................ 9SAMPLE RNC CONFIGURATION ............................................................................................................................. 10

INPUTS .......................................................................................................................................................... 10TRAFFIC MODEL ............................................................................................................................. 10USER TRAFFIC CHARACTERISTICS ............................................................................................... 11

OUTPUTS ........................................................................................................................................................ 11CONTROL PLANE CONFIGURATION ............................................................................................ 11DATA PLANE CONFIGURATION ................................................................................................... 12OUTPUT – RNC SPECIFICATIONS ............................................................................................... 12

CONCLUSION .......................................................................................................................................................... 14ACRONYMSACRONYMSACRONYMSACRONYMSACRONYMS ................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ 1414141414REFERENCESREFERENCESREFERENCESREFERENCESREFERENCES ................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ 1515151515ABOUT THE AUTHOR ................................................................................................................................................. 15ABOUT WIPRO TECHNOLOGIES ............................................................................................................................... 16WIPRO IN TELECOM ................................................................................................................................................. 16

© Wipro Technologies Page:


03 of 16

INTRODUCTIONThere are various models which have the ability to predict the traffic requirements in a 3G network. But given a traffic model,the next step is to dimension the network according to the parameters of the traffic model. In this paper, an approach ispresented for the dimensioning of the RNC.

The dimensioning of RNC can be viewed from 3 different aspects:• User plane requirements – what is the required bandwidth for supporting both CS and PS traffic• Control plane capacities – what are the required control processor capacities for handling both CS and PS signaling

across all interfaces• Link capacities – what are the link capacity requirements across all interfaces

Given these aspects, this paper discusses approaches dealing with:• Computation of user plane capacities required across all the interfaces in terms of network processor requirements• Computation of control plane capacities across all the interfaces in terms of control processor requirements• Computation of link capacities required across all the interfaces

This information will be useful for designing the RNC in terms of determining the number of control/network processorsrequired and the corresponding link capacities required at each interface based on the estimated subscriber traffic in that area.Another usage could be that of validating an existing design of the RNC with the dimensions given by the approach. Thisinformation can also be used for existing RNCs to check if the current dimensions of the RNC are inline with the traffic offeredon a per RNC basis. While scaling up to meet increased bandwidth requirements, the new required RNC configuration can bedetermined.

ARCHITECTUREIn UMTS, RNC is part of the UTRAN (Universal Terrestrial Radio Access Network). A UTRAN consists of a set of radio networksubsystems, which in turn consist of one RNC and multiple Node-Bs. The Node-B connects to the RNC though the Iub interface.One RNC connects to another RNC through the Iur interface, and the RNC is connected to the MSC through the Iu-CS interfaceand to the SGSN through the Iu-PS interface.

Figure 1: High level network architecture of UMTS networks

RNC

Node B Node B

Iub

cell

RNS

RNC

Iu-CS Iu-PS

Uu

Iur



04 of 16

All elements in a 3G network connect through ATM or IP networks, where the throughput, QoS, and link configurations can bemanaged at a granular level. At the physical layer, the elements can be connected through E1/T1 links or SONET/STM links orEthernet links. The Iub, Iu-CS, and Iu-PS interfaces can be either ATM based, IPoATM based or fully IP based.

THE DIMENSIONING APPROACHThis dimensioning approach will be discussed at the following levels:

• Inputs from the traffic model

• The BHCA computations that are done at the user and signalling planes based on the inputs from the traffic model

• Computation of the actual user plane requirements

• Computation of the actual control plane requirements

• Computation of link capacities

A visual representation of this approach is given in Figure 2.

Figure 2: RNC dimensioning approach

Basic Traffic

Model

User Plane

BHCA

computations

User Plane

Requirements

Control Plane

Requirements

Link Capacity

Requirements

Control

Plane

BHCA

RNC Dimensioning

Aspects



05 of 16

Inputs from Traffic Model

This forms the basis of all computations.

The parameters that constitute the traffic model can be broadly classified under call attempts, duration of calls and the datarates associated with the calls. Under these categories, the parameters need to be input are given in the following tables (theseparameters are for a single user).

Call attempts

Table 1: Call attempts

ParameterParameterParameterParameterParameter ExplanationExplanationExplanationExplanationExplanation

Mobile originated/terminated ratio The ratio of mobile originated versus the mobile terminated calls.

Successful MO/MT call ratios The ratio of successful versus unsuccessful call attempts originated/terminatedby the mobile.

Successful mobile call attempts per userper busy hour

This includes both MO and MT calls which were successfully attempted.

Data rates

Table 2: Data rates


Uplink user peak bit rate Depending on the traffic class, this represents the highest bit rate the usermight be transmitting on the uplink

Downlink user peak bit rate Depending on the traffic class, this represents the highest bit rate the usermight be transmitting on the downlink.

Uplink activity factor Percentage of the total call duration the user is engaged in transmitting dataon the uplink

Downlink activity factor Percentage of the total call duration the user is engaged in transmitting data onthe downlink

Session duration (in secs) This is applicable for both CS and PS calls. This gives the total time the useris engaged in holding the call.



06 of 16

Signalling aspects

Table 3: Signalling related parameters


No. of paging per MTCA Ideally, there should only be 1 paging per user per call. But in case the useris not reachable this could be more.

No. of LA/RA updates per call attempt This is directly proportional to the number of call attempts the user makes.

No. of cell/URA updates per user/second This is directly proportional to the user session duration and number of callattempts.

Number of soft HOs per user/second This is directly proportional to the user session duration and number of callattempts.

Number of intra-RNC hard handoversper user/second

This is directly proportional to the user session duration and number of callattempts.

Number of inter-RNC hard handovers/second

This is directly proportional to the user session duration and number of callattempts.

Number of inter-RAT handovers/second This is directly proportional to the user session duration and number of callattempts.

BHCA Computations

Based on the above input parameters the following parameters can be computed:

Control plane

ParameterParameterParameterParameterParameter Domain (CS/PSDomain (CS/PSDomain (CS/PSDomain (CS/PSDomain (CS/PS

No. of successful CS MTCA per user/hr CS

No. of successful CS MOCA per user/hr CS

No. of successful PS MOCA per user/hr PS

Total number of CS MTCA CS

Total number of CS MOCA CS

Total number of PS MOCA PS

Total number of calls CS+PS

Total no. of Paging CS+PS

Total no. of LA/RA updates CS+PS

Total no. of cell/URA updates for PS CS+PS



07 of 16

Total no. of CS SHOs CS

Total no. of PS SHOs PS

Total SHOs CS+PS

Nbr of intra-RNC hard HOs for CS CS

Nbr of intra-RNC hard HOs for PS PS

Total intra-RNC hard Hos CS+PS

Nbr of inter-RNC hard HOs for CS CS

Nbr of inter-RNC hard HOs for PS PS

Total inter-RNC hard Hos CS+PS

Nbr of inter-RAT HOs for CS CS

ParameterParameterParameterParameterParameter Domain (CS/PSDomain (CS/PSDomain (CS/PSDomain (CS/PSDomain (CS/PS

*Values in italics are the ones directly used in the user/control plane computations

Table 4: BHCA computations for control plane

User plane

For the user plane, only the peak user traffic that will need to be processed is required. The main BHCA parameters that need tobe computed based on the traffic model are given below:

• Total user traffic per session on the uplink/downlink• Total user traffic per person per busy hour• Total traffic (UL/DL) for the entire RNC per BH

User Plane Requirements

The calculation of the user plane bandwidth requirements directly comes from the input Traffic Model. In general, the usertraffic associated with umts can be classified into conversational, streaming, interactive and background.

For each of these traffic classes, there can be a separate traffic model. Ultimately when the user plane capacity needs to becomputed an aggregate of all these separate traffic models needs to be considered.

The steps involved in calculating the user plane requirements are briefly summarized hereafter:

Step 1:Step 1:Step 1:Step 1:Step 1: The basic traffic model inputs are entered. For example, parameters are number of subscribers, % of subscribersengaged in CS, no. of CS/PS mobile originated, call attempts per user/hour etc.

Step 2: Step 2: Step 2: Step 2: Step 2: Based on the input Traffic model parameters in step 1, some parameters related to the user plane requirements arecomputed. For example computed parameters are no. of successful CS/PS mobile originated call attempts per user/hr, no. ofsuccessful CS MTCA per user/hr etc.

Step 3: Step 3: Step 3: Step 3: Step 3: Finally, the required bandwidth on the UL and DL for user plane traffic is computed. This is done for each assumed trafficclass (e.g., CS, PS-64K, PS-128K and PS-256K).



08 of 16

Control Plane Requirements

The approach to computing the control plane requirements is as follows:

• Using the traffic model, determine the number of primary events (see below) occurring during a BH (busy hour)• For each such event, determine the number of messages to be handled at each of the RNC interfaces (Iub, Iur, Uu, Iu)• Estimate the complexity of handling each message using a method which determines the number of fields that need to

be processed in each message and the complexity of these fields. This is done using the Message Analysis Method• The complexity derived from each message is converted to LOC based on a multiplication factor (which is computed

based on some existing implementation of telecom scenarios related to 2G networks)• The total number of LOC executed per scenario is determined by multiplying the LOC obtained in the previous step with

the estimated number of occurrences of that scenario (this is derived from the traffic model)• Finally, the estimated LOC/sec is aggregated on a protocol/interface basis to give the estimated processing requirements

for each control processor. In this case, aggregation is made on NBAP(Iub), RRC(Uu), RNSAP(Iur) and RANAP(Iu)protocol basis.

Message complexity analysis method – a summaryMessage complexity analysis method – a summaryMessage complexity analysis method – a summaryMessage complexity analysis method – a summaryMessage complexity analysis method – a summary

This method primarily involves analysing the complexity of incoming/outgoing messages at each interface based on the fieldspresent in the message and the nature of these fields (basic, compound etc.).

A sample output of this method is given below, where the complexity of the messages URA Update and URA Update Confirmare determined at the Uu interface. Also the number of LOC executed per second as a result of processing these messages is alsogiven.

RRC Messages UCE Number ofMessages

InterfaceUCE

ACE LOC Numberof Occurrences

(per sec)

Total LOCexecuted(per sec)

URA Update 8 1

URA UpdateConfirm

20 1 28 30.24 3156 5334.3361.764

• Unadjusted complexity estimate (UCE) – This is obtained from the message complexity analysis• Interface UCE – This is just a summation of the complexity estimates of the messages passing through that interface• Adjusted complexity estimate (ACE) – This is the result of adjusting the user interface UCE with the adjustments factor

derived from the general system characteristics determined for RNC• LOC – This is the result of converting the ACE to LOC using the multiplicative factor• Number of occurrences – This is obtained from the Traffic Model• Total LOC executed – LOC multiplied by Number of occurrences per second gives the Total LOC executed for that

scenario per second.



09 of 16

Control plane requirements – a sample outputControl plane requirements – a sample outputControl plane requirements – a sample outputControl plane requirements – a sample outputControl plane requirements – a sample output

Based on the above approaches, the following was computed for the signalling plane requirements:

Figure 3: Control plane requirements – sample output

Link Capacities Computation

As a final step, the link capacities at each interface and the corresponding network processor requirements will be computed.This is based on the following inputs:

• Total user traffic as determined in Error! Reference source not found.Error! Reference source not found.Error! Reference source not found.Error! Reference source not found.Error! Reference source not found.• Total signaling traffic will be taken as a percentage of this entire user traffic (for the purposes of this paper, it is taken as

percentage of the traffic, depending on the interface).• The total of the user and signaling traffic would yield the actual traffic estimated at the RNC level• For each interface, the traffic can be split as follows:

- IuB – The entire traffic generated from CS and PS calls and the associated signaling would be taken into accounthere.

- IuCS - The traffic is further split into CS and PS traffic (based on the traffic model). The traffic associated with CS willbe used for determining the capacity at this interface.

- IuPS – Similar to IuCS, the traffic associated with PS will be used.- Iur – Here the entire data traffic (CS+PS) is taken into account and a percentage of this is estimated to flow through

this interface.• Based on the above bandwidth requirements, the link capacities (in terms of number of E1 or OC-3 links) can be derived

2500

100000

Number of Subscribers

150000 200000

NBAP

RRC

RANAP

RNSAP

250000 300000

Pro

cessor

Requirem

ents

(M

Hz)

2000

1500

1000

500

0



10 of 16

For a subscriber base of 300,000 and a given traffic model, the sample output obtained using this method is shown below.

InterfaceInterfaceInterfaceInterfaceInterface IuBIuBIuBIuBIuB IuCSIuCSIuCSIuCSIuCS IuPSIuPSIuPSIuPSIuPS IurIurIurIurIur

Capacity requirements (In Mbps) 4960.368 131.516 4415.488 1736.129

Nbr of E1 links 2480.184 65.758 2207.744 868.0644

Nbr of OC-3 links 32.00237 0.84849 28.48702 11.20083

Table 5: Link capacity requirements – sample output

SAMPLE RNC CONFIGURATIONIn this section, a sample RNC configuration is presented, given a traffic model and the subscriber base to be supported.

Inputs

Traffic Model

Basic InputsBasic InputsBasic InputsBasic InputsBasic Inputs ValueValueValueValueValue

Number of Subscribers 300000

% of subscribers engaged in CS 80%

% of subscribers engaged in PS 20%

% of traffic using 64K class 60%



No. of CS Mobile Terminated Call Attempts per user/hour 2

No. of CS MO Call attempts per user/hr 2

No. of PS Mobile Terminated Call Attempts per user/hour 0

No. of PS MO Call attempts per user/hr 1

Blocking Probability 2%

No. of paging per MTCA 1.5

No. of LA/RA updates per call attempt 1

No. of cell/URA updates per user/second 0.01

Number of soft HOs per user/second 0.001

Number of intra-RNC hard handovers per user/second 0.0001

Number of inter-RNC hard handovers/second 0.0001

Number of inter-RAT handovers/second 0.0001

CS session duration (in secs) 60

PS session duration (in secs) 600



11 of 16

User traffic characteristics

CharacteristicCharacteristicCharacteristicCharacteristicCharacteristic CS (kbps)CS (kbps)CS (kbps)CS (kbps)CS (kbps) PS-64K (kbps)PS-64K (kbps)PS-64K (kbps)PS-64K (kbps)PS-64K (kbps) PS-128K (kbps)PS-128K (kbps)PS-128K (kbps)PS-128K (kbps)PS-128K (kbps) PS-256K (kbps)PS-256K (kbps)PS-256K (kbps)PS-256K (kbps)PS-256K (kbps)

UL peak rate 12.2 64 128 256

DL peak rate 12.2 64 128 256

UL activity factor 50% 20% 20% 20%

DL activity factor 50% 80% 80% 80%

Outputs

Control plane configuration

Sample CPU specifications

Intel Pentium III XeonClock speed: 1000 Mhz

Sample CPU specifications

Intel IXPClock speed: 166 MhzPeak bandwidth: 4 Gbps

Control plane processors Data plane processors

Figure 4: Sample configuration for a subscriber base of 300,000

RRC CPU

RRC CPU

RRC CPU

Total MHz : 2087

NBAP CPU

NBAP CPU

Total MHz: 1123

RANAP CPU

Total MHz: 500

RNSAP CPU

Total MHz: 700

100%

100%

8%

50%

50%

50%

70%

RRC

configuration

NBAP

configuration

RANAP

configuration

RNSAP

configuration

Iub NP

Iub NP

Total Bandwidth:

5 Gbps

IuCS/PS NP

IuCS/PS NPTotal Bandwidth:

4.4 Gbps

Iur NPTotal Bandwidth:

1.8 GBps

100%

25%

100%

10%

50%

Iub configuration

Iub configuration

Iub configuration



12 of 16

Here, the assumption is that the load is evenly spread across all the processors – with an assumed upper threshold of 75%occupancy. Beyond this threshold there may be performance issues in dealing with real time traffic. Therefore, the aboveconfiguration diagram is only intended to provide the number of CPUs required and not give the occupancy of each CPU.

Since the processors used for RRC and RNSAP are relatively underutilized, they can also be used for supporting OAM relatedmodules. Typically these functionalities would include:

• Support of interface towards the OMC-R

• Support of interface towards local terminals

• Supervision and maintenance of all modules within the RNC

• Performance measurement functions

• Maintenance of central disk-backed database (or any other equivalent data storage base)

Data plane configurationData plane configurationData plane configurationData plane configurationData plane configuration

The link capacity requirements at each interface in order to support a user base of 300,000 subscribers are given here.

Figure 5: Sample links configuration for a subscriber base of 300,000

Output – RNC specificationsOutput – RNC specificationsOutput – RNC specificationsOutput – RNC specificationsOutput – RNC specifications

Using the dimensioning technique outlined in this approach note, we have arrived at a typical RNC specification (please referTable 6).

Iub InterfaceNbr of OC-3 links - 32Data Plane bandwidth - 4.2 GbpsControl Plane bandwidth - 0.8 Gbps

Iu InterfaceNbr of OC-3 links - 29Data Plane bandwidth - 4.2 GbpsControl Plane bandwidth - 0.4 Gbps

RNC

Iur InterfaceNbr of OC-3 links - 11Data Plane bandwidth - 1.5 GbpsControl Plane bandwidth - 0.2 Gbps



13 of 16

Number of subscribers 300000

Iub Number of OC-3 links 32

Number of n/w processor cards* 2

Iur Number of OC-3 links 11


Iu Number of OC-3 links 29


NBAP Number of control processor cards* 2

RRC Number of control processor cards* 3

RNSAP Number of control processor cards* 1

RANAP Number of control processor cards* 1

* Network Processor – Intel IXP, Control Processor – Intel Pentium III Xeon

Table 6: Sample RNC specifications

CONCLUSIONIn this white paper, an approach to dimensioning the RNC was discussed. The main aspects dealt with were the computation ofuser plane requirements, control plane requirements and the link capacity requirements. This approach would prove to beuseful from the RNC designer’s perspective when the expected traffic model is known. Also from the operator’s perspective thisinformation can be used while considering the impacts related to scaling up the network to meet increased user demands.

It has to be kept in mind that this is an iterative approach. Initially, based on the number of subscribers that needs to besupported, the model generates a sample RNC configuration. These outputs have to be validated against hardware constraints,budget constraints and the estimated cost-benefit ratio.

Based on the results of this validation, the desired RNC specifications can be used as inputs to the model to derive the subscriberbase that can be supported. These steps can be performed iteratively to generate the most optimum specifications in terms ofcost, benefits and hardware constraints.



14 of 16

CONCLUSIONIn this white paper, an approach to dimensioning the RNC was discussed. The main aspects dealt with were the computation ofuser plane requirements, control plane requirements and the link capacity requirements. This approach would prove to beuseful from the RNC designer’s perspective when the expected traffic model is known. Also from the operator’s perspective thisinformation can be used while considering the impacts related to scaling up the network to meet increased user demands.

It has to be kept in mind that this is an iterative approach. Initially, based on the number of subscribers that needs to besupported, the model generates a sample RNC configuration. These outputs have to be validated against hardware constraints,budget constraints and the estimated cost-benefit ratio.

Based on the results of this validation, the desired RNC specifications can be used as inputs to the model to derive the subscriberbase that can be supported. These steps can be performed iteratively to generate the most optimum specifications in terms ofcost, benefits and hardware constraints.

ACRONYMS

BHCA Busy Hour Call Attempts

Iub Interface between Node-B and RNC

Iur Interface between RNC and RNC

Iu-CS Interface between RNC and Circuit Switched Network

LA Location Area

LOC Lines Of Code

MOCA Mobile Originated Call Attempt

MOTA Mobile Terminated Call Attempt

Iu-PS Interface between RNC and SGSN

NBAP Node B Application Part

RA Routing Area

RANAP RAN Application Part

RNC Radio Network Controller

RNSAP Radio Network Subsystem Application Part

SGSN Serving GPRS Support Node



15 of 16

REFERENCE1. 3GPP Standards and Protocol Documents

ABOUT THE AUTHORSrivatsa is a Project Leader in Wipro Technologies with about 6 years experience in the telecom domain and 4 years in thewireless domain. He has been involved in the specification, design, implementation and testing of various features related toGSM/GPRS base station controller. He holds a bachelor’s degree in Computer Science. His areas of interest include aspectsinvolving migration of existing wireless 2G systems to 3G systems and integration of wireless systems (GPRS/WLAN).



www.wipro.comeMail: [email protected]

For further information visit us at: http://www.wipro.com/telecomandinternetworking

For more whitepapers logon to: http://www.wipro.com/insights

© Copyright 2004. Wipro Technologies. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by any means, electronic, mechanical,photocopying, recording, or otherwise, without express written permission from Wipro Technologies. Specifications subject to change without notice. All other trademarks mentioned herein are theproperty of their respective owners. Specifications subject to change without notice.

16 of 16

ABOUT WIPRO TECHNOLOGIESWipro is a PCMM Level 5 and SEI CMMi Level 5 certified global IT Services company providing comprehensive IT solutions andservices (including systems integration, IS outsourcing, package implementation, software application development andmaintenance) and Research and Development services (hardware and software design, development and implementation) tocorporations all over the world. Wipro’s unique value proposition is further delivered through their pioneering offshoreoutsourcing Model and stringent Quality Processes of SEI and Six Sigma.

WIPRO IN TELECOMWipro Telecom Solutions Division offers comprehensive solutions for telecommunication to confront challenges, and convertevery challenge into an opportunity. With over two decades of telecom experience, Wipro Telecom solutions offers a widerange of solutions in wireless networking, broadband (data, optical and access networking), voice switching, networkmanagement and hardware design.

Wipro also provides several IPs, components and reference solutions in these domains which help our clients in saving costsand providing the time-to-market advantage. We offer complete consulting, architecting, design, implementation andmaintenance services to the telecom equipment manufacturers.

Worldwide HQWipro Technologies,Sarjapur Road,Bangalore-560 035,India.

U.S.A. U.K. FranceWipro Technologies Wipro Technologies Wipro Technologies1300 Crittenden Lane, 137 Euston Road, 91 Rue Du Faubourg,Mountain View, CA 94043. London, NW1 2 AA. Saint Honoré, 75008 Paris.

Germany Japan U.A.E.Wipro Technologies Wipro Technologies Wipro LimitedHorn Campus, # 911A, Landmark Tower, Office No. 124,Kaistrasses 101, 2-1-1 Minatomirai 2-chome, Building 1, First Floor,Kiel 24114. Nishi-ku, Yokohama 220 8109. Dubai Internet City,

P.O. Box 500119, Dubai.