iub interface capacity assessment v0.6

Copyright 2006 AIRCOM International - All rights reserved. No part of this work, which is protected by copyright, may be reproduced in any form or by any means - graphic, electronic or mechanical, including photocopying, recording, taping or storage in an information retrieval system – without the written permission of the copyright owner.

Deliverable

OJSC “VimpelCom” (BeeLine™) CS-EP-VIM-002-DOC-009- Iub Interface Capacity Assessment Author: Artemi Glazkov Date: 13 October 2008 Ref: CS-EP-VIM-002-DOC-009 Version: 0.6 Status: Issued Sec. Class: Commercial in Confidence

Commercial in Confidence

Author: Artemi Glazkov OJSC “VimpelCom” (BeeLine™) of 25 Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence

Document Control

Revision History

Revision Number

Date Name Revision

0.1 22/07/2008 A. Glazkov First draft

0.2 23/09/2008 A. Glazkov Second draft:

• Section 5.2.1 is corrected

• Section 6.2 is corrected

0.3 10/10/2008 A. Glazkov Comments from Vimpelcom

0.4 12/10/2008 A. Glazkov Forth draft.

0.5 13/10/2008 A. Glazkov Corrected by VC

0.6 13/10/2008 A. Glazkov Issued

Reviewers

Reviewer Date Feedback


Author: Artemi Glazkov OJSC “VimpelCom” (BeeLine™) of 25 Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence

Document Acceptance Signature Block

This document accepted by VimpelCom in full without amendments and exclusions

Signatory Organisation Role Signature Date Georgy Tolchinskiy

VimpelCom Senior Expert, Network Planning Division

Artemi Glazkov

Aircom International

Senior Consultant, Project Manager


Author: Artemi Glazkov OJSC “VimpelCom” (BeeLine™) Page 2 of 25 Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence

Contents Document Control ...................................................................................................................... 2

Revision History...................................................................................................................... 2

Reviewers ............................................................................................................................... 2

Document Acceptance Signature Block ............................................................................. 3

Contents ..................................................................................................................................... 2

List of Tables .............................................................................................................................. 3

List of Figures ............................................................................................................................. 3

References ................................................................................................................................. 4

1 Purpose of this document ................................................................................................... 5

2 Overview ............................................................................................................................. 5

3 Audience ............................................................................................................................. 5

4 Terminology ........................................................................................................................ 6

5 Iub Interface Capacity Assessment Overview .................................................................... 9

5.1 Interfaces in UMTS RAN area ................................................................................... 9

5.2 Assessment Process.................................................................................................. 9

5.2.1 NodeB Traffic Model ............................................................................................ 10

5.2.2 Service Activity Factor .......................................................................................... 11

5.2.3 Iub Overheads ...................................................................................................... 12

5.2.4 Required Number of Physical Links ..................................................................... 12

5.2.5 NodeB Planned/Installed Physical Links .............................................................. 12

6 Protocol Stacks and Interface Overheads ........................................................................ 12

6.1 Release 99 ATM Overeheads .................................................................................. 12

6.2 HSDPA ATM Overeheads ....................................................................................... 14

6.3 Iub Signalling Overehead ......................................................................................... 15

6.4 ATM Overbooking Overhead ................................................................................... 15

7 NodeB Iub Throughput Calculation .................................................................................. 15

7.1 Calculation Assumptions .......................................................................................... 16

7.2 R99 CS Voice Service.............................................................................................. 16

7.3 R99 NRT128 PS Service ......................................................................................... 17

7.4 Combined R99 Throughput ...................................................................................... 17

7.5 HSDPA Service ........................................................................................................ 18

7.6 Accounting for ATM Overbooking ............................................................................ 18

8 Required Number of E1 links ............................................................................................ 18

8.1 HSDPA impact on Iub requirements ........................................................................ 18

9 Regional Plan E1 Link Requirements Assessment .......................................................... 20

9.1 Required Number of E1 Links .................................................................................. 20

10 Conclusion ................................................................................................................... 21

APPENDIX ............................................................................................................................... 22

A.1 Calculating R99 CS Voice Service Throughput using ASSET .................................... 22

A.2 Calculating R99 NRT128 Service Throughput using ASSET ...................................... 23

A.3 Calculating SHO using ASSET .................................................................................... 23



List of Tables

Table 6-1 Calculated overheads for different traffic types and their service rates .................. 13

Table 8-1 Average HSDPA Throughput vs. Number of E1 Links ............................................ 19

List of Figures Figure 5-1 General architecture of the 3G network ................................................................... 9

Figure 5-2 Iub Capacity Assessment Process Flowchart ........................................................ 10

Figure 5-3 Illustration of the NRT service activity .................................................................... 11

Figure 5-4 Illustration of Activity Factor Calculation ................................................................. 12

Figure 6-1 Protocol stack for R99 Circuit Switched service .................................................... 13

Figure 6-2 Protocol stack for R99 Packet Switched service ................................................... 13

Figure 6-3 Protocol stack for HSDPA service ......................................................................... 14

Figure 7-1 Iub Throughput calculation .................................................................................... 16

Figure 9-1 Estimated Number of E1 Links per Planning Region ............................................. 20

Figure 9-2 Estimated Number of E1 Links per Population Centre ........................................... 21



References [1] CS-EP-VIM-002-DOC-005- Roll-out Plan Guidelines, version 1.4

[2] HSDPA/HSUPA for UMTS, High Speed Radio Access for Mobile Communications by Harri Holma and Antti Toskala, John Wiley and Sons [3] CS-EP-VIM-002-DOC-009- Iub Interface Capacity Assessment v0.1-Site Data.xls



1 Purpose of this document

This document describes a methodology of assessment of the ATM based Iub interface required capacity and subsequently a number of E1 links required to support predicted NodeB traffic.

2 Overview

Regional Plan Assessment activity was carried out by Aircom Radio Network Planning Management Team based on information provided by the VimpelCom Radio Network Engineering.

The key information element used during the assessment was the existing VimpelCom GSM network traffic. This information allowed creation of traffic density maps, which are used as an input for Monter-Carlo simulations [1]. Based on results of the simulations it was possible to make conclusions about behaviour of a loaded UMTS network. Information about predicted NodeB throughput was available as one of the Regional Plan Assessment outputs.

This document presents a simulation based approach to assessment of the ATM based Iub interface requirements. The document provides formulae for calculating overheads to be applied to take into account signalling introduced by different protocols on different layers.

The analysis will indicate which NodeB or a part of the network is the most likely element to experience Iub interface overload due to a lack of physical links (E1 links)

3 Audience

This document is intended to be used by:

• Aircom Radio Network Planning (RNP) Management Team, as a guide to the process of roll-out planning

• VimpelCom Radio Network Engineering, for information on the procedure carried out by Aircom RNP Management Team



4 Terminology

Term Description 3GPP 3rd Generation Partnership Project (ETSI, TTC/ARIB, P1T1,

etc.) A2SU AAL2 Switching Unit

AAL# ATM Adaptation Layer type #

AMR Adaptive Multirate (speech codec)

ATM Asynchronous Transfer Mode

AXC ATM Cross-connect

AXU ATM Cross-connect Unit

BCH Broadcast Channel

BH Busy Hour

BS Base Station

CBR Constant Bit Rate

CCH Common Channel

CDVT Cell Delay Variation Tolerance

CES Circuit Emulation Service

CN Core Network

CPCS Common Part Convergence Sub-layer

CPICH Common pilot channel

CPS Common Part Sub-layer

CPS-PH CPS Packet Header

CPS-PP CPS Packet Payload

CQI Channel quality indicator

CS Circuit Switched

DCH Dedicated Channel

DCN Data Communication Network

Dl Downlink

DMCU Data and Macro Diversity Unit

DRNC Drift RNC

DSCH Downlink Shared Channel

EDGE Enhanced Data rates for GSM Evolution

FACH Forward Access Channel

FP Frame Protocol (a.k.a. User Plane protocol)

FR Full Rate

GFR Guaranteed Frame Rate

GTPU GTP Unit

GTP-U User plane part of the GPRS Tunneling Protocol

HSDPA High speed downlink packet access

HW Hard Ware

IFU Interface Unit

IMA Inverse Multiplexing for ATM

IP Internet Protocol

ISDN Integrated Services Digital Network



IWF Inter-Working Function

IWU Inter Working Unit

L1 Layer 1

LOS Line Of Sight

MAC Medium Access Control

MSC Mobile Services Switching Centre

MTU Maximum Transmission Unit (a.k.a. Media Transmission Unit)

NBAP Node B Application Part

NBAP-C Node B Application Part Common

NBAP-D Node B Application Part Dedicated

NRT Non-real time

OH Overhead

PCCPCH Primary common control physical channel

PCH Paging Channel

PCR Peak Cell Rate

PDCP Packet Data Converge Protocol

PDU Protocol Data Unit

PHY Physical layer

PS Packet Switched

P-SCH Primary Synchronisation channel

PSTN Public Switched Telephone Network

PVC Pre-defined Virtual Connection

QoS Quality of Service

RAB Radio Access Bearer

RACH Random Access Channel

RAN Radio Access Network

RANAP Radio Access Network Application Part

RF Radio Frequency

RLC Radio Link Control

RNC Radio Network Controller

RNP Aircom Radio Network Planning

RNSAP Radio Network System Application Part

RRM Radio Resource Management

RT Real time

SAAL Signalling ATM Adaptation Layer

SAAL-NNI Signalling ATM Adaptation Layer for Network to Network Interface

SAAL-UNI Signalling ATM Adaptation Layer for User to Network Interface

SAR Segmentation and Reassembly

SCCPCH Secondary common control physical channel

SDU Service Data Unit

SGSN Serving GPRS Support Node

SHO Soft Handover

SHO Soft Hand Over

SINR Signal-to-noise ratio where noise includes both thermal noise and interference



SRNC Serving RNC

SRTS Synchronous Residual Time Stamp

SSADT Service Specific Assured Data Transfer

S-SCH Secondary Synchronisation channel

SSCS Service Specific Convergence Sublayer

SSSAR Service Specific Segmentation and Reassembly

SSTED Service Specific Transmission Error Detection

STF Start Field

TB Transport Block

UBR Unspecified Bit Rate

UDP User Datagram Protocol

UE User Equipment

UEP Unequal Error Protection

UL Uplink

UMTS Universal Mobile Telecommunications System

USCH Uplink Shared Channel (existence is FFS in 3GPP)

UTRAN UMTS Terrestrial Radio Access Network

VBR Variable Bit Rate

VCC Virtual Channel Connection

VCI Virtual Channel Identifier

VPC Virtual Path Connection

VPI Virtual Path Identifier

WAF Wideband Antenna Filter

WAM Wideband Application Manager

WCDMA Wideband CDMA, Code division multiple access

WSM Wideband Summing and Multiplexing

WSP Wideband Signal Processor

WTR Wideband Transmitter and Receiver



5 Iub Interface Capacity Assessment Overview

5.1 Interfaces in UMTS RAN area

There are several different interfaces used to connect various network elements in UMTS RAN.

RAN -Radio Access Network

Packet Switching

RNC

RNC

Iu -CS IWU/ATM

MSC

SGSNGGSN

A

Internet

PSTN

Iu -PS

Iu -CS

Iu -PS

IWU/ATM

BSBS

BS

BS

BS

BS

BS

A

Circuit Switching

BS

BS

BS

BS

Iur

Iub

Iub

Figure 5-1 General architecture of the 3G network

Iub is the interface between BTSs and RNC. RNC terminates Iub traffic coming from the BS direction, divides traffic, signalling and overheads correctly for Iur, Iu-CS and Iu-PS directions.

Iu-CS is the interface between RNC and IWU/MSC; MSC is a core network element for the circuit switched services i.e. MSC is in the PSTN/ISDN domain. All voice traffic and CS data from BS are transferred to MSC/IWU via RNC.

Iu-PS is the interface between RNC and SGSN; SGSN is a core network element for the packet switched data. All PSD traffic from BTS is terminated in SGSN.

Iur is the interface between two or more RNCs. Iur interface is needed if UE transmits and receives the same signal via two different BTS, which belong, to two different RNCs and for signalling between the individual RNCs (e.g. for Handover).

This document is concerned with capacity of the Iub interface.

5.2 Assessment Process

Dimensioning of the Iub interface during a network planning sage or assessment of its capacity in the already planned network is a complex task. Accuracy of the result very much depend upon accuracy of initial assumptions, knowledge of the network customer behaviour and knowledge of vendor specific particularities. In many cases this information remains inaccurate till the very late stage of the network planning or even until the network is launched life.

However, using the best available at the moment assumptions and the previous experience Aircom RNP attempts providing a comparative analysis on the VimpelCom network as per RO2008 plan, which could be



used for future development. The analysis will indicate which NodeB or a part of the network is the most likely element to experience Iub interface overload due to a lack of physical links (E1 links).

The process of assessment could be broadly described by the diagram below:

Figure 5-2 Iub Capacity Assessment Process Flowchart

The following subsections provide a short overview of the above diagram.

5.2.1 NodeB Traffic Model

Details of a traffic model and user profile utilised during the Regional Plan Assessment stage could be found in [1]. They were used, in conjunction with information about the existing GSM network traffic, to create UMTS terminal density maps. The maps were used as the main input for analysis based on Monte-Carlo simulations. For every of the analyses NodeBs per-service simulated throughput was produced.

The adopted traffic model consists of three services:

• Release 99 Circuit Switch Voice service (R99 CS Voice)

• Release 99 Non-real Time Packet Switch 128 kbps service (R99 NRT128)

• HSDPA Packet Switch service

HSUPA service is not modelled at the moment. However, it is expected that DL traffic will impact Iub interface considerably more comparing to the UL traffic due to asymmetrical nature of PS traffic.



5.2.2 Service Activity Factor

It is necessary to define Bearer Activity Factors for R99 bearers as well as for bearers utilised by HSDPA service.

Bearer Activity factors (AF) affect 3 elements in the simulation:

• They scale interference in the UL and DL, i.e. they appear in the denominators of the UL and DL Eb/No formulae.

• They scale the throughputs on the cells, i.e. when the activity factor isα , a bearer with a user rate of

12.000 kbps will provide an average throughput of 12.000α kbps.

• They scale resource consumption for PS services, i.e. when the activity factor is α , a bearer requiring

1 resource (when active) will consume an average of α resources.

These activity factors are not necessarily all the same:

• When scaling interference, we need an activity factor that accounts for retransmissions.

• When scaling throughputs (user bit rate), we need an activity factor that does not include retransmissions.

• When scaling resource consumption, we need an activity factor that account for retransmissions, and resource inefficiency due to release timeout.

Figure 5-3 and Figure 5-4 illustrate how different types of activity are modelled in the planning tool and the approach which separates the three different activities.

Packet

Retransmitted Packet

Release Timeout

Figure 5-3 Illustration of the NRT service activity



Figure 5-4 Illustration of Activity Factor Calculation

The activity factor for voice services is assumed to be 65% [1].

The activity model assumes that a volume of data (e.g. a number of webpage or a number of video clips) an average user transfers through the HSDPA service is constant disregarding the rate the data could be transferred to the user. It is assumed that the minimum user bit rate utilised to transfer data through HSDPA is 384kbps (according VC requirements) and corresponding activity factor will be close to 100%.

For bearers with higher rates the activity factor is calculated as follows:

RateiBearerUser

OHBearerSigAFi

_*384=

Equation 1

Where:

AFi – bearer i activity factor

BearerUserRatei – bearer i user bit rate

BearerSig_OH – bearer signalling overhead. A bearer has to provide a rate slightly higher than the required user throughput to allow some signalling overhead. This overhead is assumed to be at least 10% (1.10).

So we assume BearerSig_OH = 1.1.

5.2.3 Iub Overheads

A number of additional protocol layers are used to convey the user information through the Iub interface. Each layer will add additional bits to the original payload. These overheads depend on the traffic type (CS, PS), technology used to carry the traffic (R99 or HSDPA) and amount of transferred data.

5.2.4 Required Number of Physical Links

For purposes of this activity it is assumed that all NodeBs are connected to RNCs through E1 type links.

5.2.5 NodeB Planned/Installed Physical Links

Based upon information provided by VimpelCom it is assumed that two E1 links are install on every NodeB.

6 Protocol Stacks and Interface Overheads

6.1 Release 99 ATM Overeheads

Each layer in protocol stack will add additional bits to the original payload and depending on the layer, different overheads are used. In Iu interface there can be distinguished two different types of traffic, Iu–CS (Iu-Circuit Switched data and speech) for connections towards IWU/MSC and Iu-PS (Iu-Packet Switched) for SGSN.

Protocol stacks for Circuit Switched and Packet Switched Domain are shown below:



AAL2

PHY

ATM

PHY

ATM

AAL2

FP

PHY

AAL2

PHY

ATM

Link Layer

PHY

AAL2

PHY

ATM

WCDMA L1

FP

WCDMA L1

E.g., Vocoder

PHY

PSTN/ N-ISDN

A I u I ub U u

IWU

RNC

Node B

UE

E

I u -CS UP I u -CS UP

E.g., Vocoder

Link Layer

Α/µ− law PCM, UDI, etc.

Α/µ− law PCM, UDI, etc.

MSC

RLC-U

MAC

RLC-U

MAC

Figure 6-1 Protocol stack for R99 Circuit Switched service

IP

AAL5

PHY

UDP

LLC/SNAP

GTP-U

ATM

PHY

ATM

AAL2

FP

PDCP

UDP

IP

Link

Layer

PHY

GTP

IP

AAL5

PHY

UDP

LLC/SNAP

GTP-U

ATM

UDP

IP

Link

Layer

PHY

GTP

AAL2

PHY

ATM

WCDMA

L1

FP

WCDMA

L1

PDCP

E.g.,IPv4, IPv6

PHY

E.g.,IPv4, IPv6

GnIuIubUu

GGSN

3G-SGSN

RNC

Node B

UEGi

RLC-U

MAC

RLC-U

MAC

Figure 6-2 Protocol stack for R99 Packet Switched service

The overheads for Iub transmission are composed of the following parts:

• Frame Protocol Layer header (FPL)

• AAL2 segmentation header (variable length PDU, up to 45 Oct.)

• ATM cell header

FPL and AAL2 OH are transport channel specific, therefore for each service bitrate the OH should be calculated separately. All transport channels of the same VPC are then handled together and the ATM-Cell OH should then be added to the total traffic sum.

Table 6-1 below shows the calculated bit rates below ATM (i.e. on the Physical transmission medium) after the various overheads have been considered for various UMTS services.

overhead.xls

Table 6-1 Calculated overheads for different traffic types and their service rates

Note that this does not include Soft Handover (SHO) factor, which should be accounted for in the total overhead calculations.

ATM over PDH/SDH System is capable to handle different traffic types and service rates simultaneously. One subscriber can have a several connections at the same time (for example: 1 CS voice call + 1 CS data call + 2 PS calls).



Each traffic type and service rate requires a different size of ATM overhead percentage when they are transferred via each interface. Therefore transmission capacity calculations have to be performed separately for each service before summing to get a right result.

PSD traffic needs extra transmission capacity because of the re-transmission and buffering. This OH for R99 is fixed to be 26.5% at the moment.

Transmission capacity for PSD is not always symmetrical in both uplink and downlink direction. Therefore for transmission capacity calculation the worst case is taken into account, which is DL.

All traffic types should be converted to be kbps /service rate or physical channels /service rate before starting to calculate the transmission capacities.

SHO (Soft Handover) factor is Iub interface parameter. Conventionally this value includes also the Softer Handover factor. If Softer Handover factor is known, it must be excluded from SHO percentage for Iub calculation as Softer handovers do not affect it.

A conventionally assumed value of 40% SHO could be used in calculation.

6.2 HSDPA ATM Overeheads

A protocol stack for HSDPA Domain is shown below:

Figure 6-3 Protocol stack for HSDPA service

The basic functionality of the different protocol layers if HSDPA as well as HSUPA is similar to Release 99. However, a number of changes were introduced to improve performance. A detailed comprehensive description of the introduced changes could be found in [2], chapter 3.

HSDPA improves Iub efficiency compared to R99 packet data since HSDPA uses time shared channels with flow control in Iub. With R99 the Iub bandwidth is typically allocated separately per user. It makes difficult to share available capacity dynamically.

Due to buffering of data in the Node B transmission with high peak data rates at the Uu interface can be supported with HSDPA without requiring a similar higher Iub bandwidth. Short periods of Iub congestion do not necessarily result in unused HSDPA air interface capacity.

HSDPA does not support the soft handover, so the data transmitted to one HSDPA user is only sent once over a single Iub. On the other hand, to support HS mobility, SHO is present for the corresponding signalling plane. However, this is a low rate signalling and it does not impact significantly the overall overhead. It means that an additional OH due to SHO may be applied in Iub capacity calculations.

Furthermore, Iub protocol headers depends on the number of MACd PDU encapsulated in one HS DSCH FP

frame, which is triggered by the Flow Control algorithm. In other words HS OH clearly depends upon the HS payload size.

The overheads may vary from vendor to vendor, but it is the common practice to assume that the total RLC-to-ATM OH for HSDPA is around 30% (1.30).



Assuming target BLER = 10%,

%4545.1)1.01(

30.1__ =>≈

−=HSDPAOHATM

Equation 2

6.3 Iub Signalling Overehead

NCP, CCP and ALCAP signalling consumes Iub interface bandwidth. Iub bandwidth for signaling depends on the actual traffic volume. However, it can be simplified as approximately 10% of Iub traffic throughput for both R99 and HSDPA.

6.4 ATM Overbooking Overhead

All vendors generally recommend using IMA (Inverse Multiplexing for ATM) technology to improve Iub physical link utilisation if more than two E1 links are used. IMA technology provides a scalable and cost-effective solution for customers seeking to expand E1/T1 link. This achieved by allowing overbooking of resource.

At the moment details of transport solutions selected by VimpelCom are not known, but it is assumed that IMA grouping will be implemented on Iub allowing some ATM overbooking.

For purposes of this document 20% overbooking overhead is assumed.

7 NodeB Iub Throughput Calculation

This section provides a detailed overhead calculation for the traffic model selected for purposes of the project (5.2.1). The process of assessment could be broadly described by the diagram below:



Figure 7-1 Iub Throughput calculation

7.1 Calculation Assumptions

VAF=0.65 (65%), R99 Voice Activity Factor;

PS AF = 1 (100%), R99 PS service Activity Factor (for user bit rate 384 kbps or less);

PS_Ret_Buf_OH = 1.26 (26%), retransmission and buffering OH for R99 PS services (section 6.1);

SHO_OH = 1.4 (40%), Soft Handover OH (section 6.1);

ATM_OH_HSDPA =1.45, ATM overhead for HSDPA (Equation 2);

Iub_OH = 1.1 (10%), Iub signalling OH (section 6.3);

Overbooking_OH = 1.2 (20%), ATM overbooking OH (section 6.4).

7.2 R99 CS Voice Service

An average rate for 12.2kbps voice service at ATM can be calculated using Table 6-1:

Active period rate for 12.2 kbps service rate at ATM = 18.9 kbps. This correspond to the total OH for the active period of 55%

Silent period rate at ATM = 4.5 kbps.

Assuming Voice Activity Factor (VAF) of 65% [1]:



( ) ( ) kbpskbpsVAFkbps

CsVoiveATMTavgATMinratevoiceAverage

86.13%355.4%659.18

__

=∗+∗=

==

Equation 3

For N primary (not in SHO) voice user served by a NodeB the above formula can be modified as follows:

kbpsNCsVoiceATMTavgN

CsVoicetotalATMTavgusersNforATMinratevoiceAverage

86.13__

______

∗=∗=

==

Equation 4

7.3 R99 NRT128 PS Service

An average OH at ATM for NRT128kbps PS data service can be calculated using Table 6-1:

%3030.1__128 =>=OHATMNRT

Equation 5

Activity factor for this service is 100% [1], hence, assuming 26.5% re-transmission and buffering OH (section 6.1), the following equation can be produced:

6445.1)128_()3.1265.1()128_(

)__128__Re_()128_(

128______128

∗=∗∗=

=∗∗=

==

NRTTprimNRTTprim

OHATMNRTOHBuftPSNRTTprim

NRTTotalATMTavgusersNforATMinratevNRTAverage

Equation 6

Where:

Tprim_NRT128- primary NRT128 (not in Soft/Softer HO) throughput;

PS_Ret_Buf_OH = 1.26 (26%), retransmission and buffering OH for R99 PS services (section 6.1);

7.4 Combined R99 Throughput

The total R99 Iub throughput including SHO OH and Iub OH can be calculated as follows:

54.1)128______(

1.14.1)128______(

__)128______(99___

∗+=

=∗∗+=

=∗∗+=

NRTTotalATMTavgCsVoiveTotalATMTavg

NRTTotalATMTavgCsVoiveTotalATMTavg

OHIubOHSHONRTTotalATMTavgCsVoiveTotalATMTavgRTotalIubTavg

Equation 7

Where:

Tavg_ATM_Total_CsVoice - as per Equation 14

Tavg_ATM_Total_NRT128 - as per Equation 6

SHO_OH =1.40 (40%)

Iub_OH = 1.1 (10%)



7.5 HSDPA Service

As it was said above HSDPA does not use SHO, thus total HSDPA Iub throughput can be calculated as follows:

6.1__

45.11.1_______

________

∗=

=∗∗=∗∗=

=∗∗=

HSDPATotalTavg

HSDPATotalTavgHSDPAOHATMOHIubHSDPATotalTavg

OHIubHSDPAOHATMHSDPATotalTavgHSDPATotalIubTavg

Equation 8

Where:

Tavg_Total_HSDPA – throughput of all HSDPA users served by a NodeB;

ATM_OH_HSDPA =1.45 - as per Equation 2;

Iub_OH = 1.1 (10%).

7.6 Accounting for ATM Overbooking

ATM overbooking (section 6.4) effectively reduces Iub loading:

83.0)___99___(

2.1

___99___

_

___99_____

∗+=

=+

=

=+

=

HSDPATotalIubTavgRTotalIubTavg

HSDPATotalIubTavgRTotalIubTavg

OHgOverbookin

HSDPATotalIubTavgRTotalIubTavgTotalIubTavg

Equation 9

Where:

Tavg_Iub_Total_R99 – as per Equation 7

Tavg_Iub_Total_HSDPA – as per Equation 8

Overbooking_OH = 1.2 (20%), section 6.4

8 Required Number of E1 links

The required number of E1 links is calculated using the following equation:

]2048/__[Re_1# TotalIubTavgROUNDUPquiredE =

Equation 10

8.1 HSDPA impact on Iub requirements

It is expected that the VimpelCom UMTS network will be primarily dedicated to supporting HSPA services. Formulas presented in the previous section help to estimate average HSDPA user throughput that can be supported by a given number of E1 links.



#E1 Links Supported Average HSDPA User Throughput, Mbps

1 1.536

2 3.072

3 4.608

4 6.2

5 7.68

6 9.216

7 10.752

8 12.288

9 13.824

10 15.36

11 16.896

12 18.432

Table 8-1 Average HSDPA Throughput vs. Number of E1 Links

It has to be remembered that due to buffering in the NodeB and scheduling that allows time-sharing the resources a higher peak rate (over a short period of time) for radio than the average rate on Iub (presented in the table above) can be achieved. For instance there can be Uu interface data rates up to 14.4Mbps over short (2-ms) periods, however, this does not mean the same data rate being used on the Iub interface for that particular user. It can be as low as 1Mbps over Iub.



9 Regional Plan E1 Link Requirements Assessment

Information about NodeB throughput resulting from Monte-Carlo simulations performed for purposes of the Regional Plan Assessment analysis were aggregated in an Excel spreadsheet [3] which accommodates this report. Additional assumptions were made to accommodate simulation results into methodology presented in section 7. These assumption can be found in Appendixes.

The spreadsheet allows filtering for planning region and population centres.

This section outlines main conclusion that can be drawn from the presented data.

9.1 Required Number of E1 Links

The picture below shows a calculated E1 requirement for three planning regions. Additional engineering margined of 10% was assumed:

Figure 9-1 Estimated Number of E1 Links per Planning Region

As it can be seen from the picture above and from [3] only two sites in the South region could potentially require more than two E1 links. The rest of the network has sufficient capacity to be able to support expected traffic.

The picture below shows a breakdown of the E1 requirement per population center.



Figure 9-2 Estimated Number of E1 Links per Population Centre

10 Conclusion

A methodology of assessing ATM based Iub/ E1 capacity requirements based on results of previously performed Regional Plan Assessment is presented in this document.

Analysis of the results indicates that two E1 links in the Iub interface would provide sufficient capacity to support expected throughput.



APPENDIX

A.1 Calculating R99 CS Voice Service Throughput using ASSET

Total throughput for all voice users served by a NodeB is calculated as one of the Monte-Carlo simulation outputs [1]. It is not possible to distinguish directly between throughputs generated by terminals in Soft/Softer HO and other, primary users. However in AIRCOM Asset, it could be estimated using information about utilised channel elements generated by the simulator:

ChEtotal

ChEprimVoiceTtotalVoiceTprim *__ =

Equation 11

Where:

Tprim_Voice- primary voice (not in Soft/Softer HO) throughput;

Ttotal_Voice- total voice throughput from Monte-Carlo simulation;

ChEprim- channel elements utilised by primary CS users from Monte-Carlo simulation;

ChEtotal- channel elements utilised by all CS users from Monte-Carlo simulation.

At the same time Tprim_Voice can be expressed as follows:

65.02.12_ ∗∗= NVoiceTprim

Equation 12

The above equation does not include the silence period because it is not accounted in Asset’s voice bearer model utilised in this project.

Hence, from Equation 11 and Equation 12, the number of primary voice terminals N:

)65.02.12/()*_( ∗=ChEtotal

ChEprimVoiceTtotalN

Equation 13

Taking into account 55% ATM overhead for the active period and the above two equations Equation 4 can be written as:

kbpsChEtotal

ChEprimVoiceTtotal

ChEtotal

ChEprimVoiceTtotal

NNCsVoiceATMTavgN

CsVoiveTotalATMTavgusersNforATMinratevoiceAverage

749.1)*_(

))65.02.12/()35.05.4(55.1()*_(

35.05.465.055.12.12__

______

∗=

=∗∗+∗=

=∗∗+∗∗∗∗=∗=

==

Equation 14



A.2 Calculating R99 NRT128 Service Throughput using ASSET

An equation similar to Equation 9 can be written:

ChEtotal

ChEprimNRTTtotalNRTTprim *128_128_ =

Equation 15

Where:

Tprim_NRT128- primary NRT128 (not in Soft/Softer HO) throughput;

Ttotal_NRT128- total NRT128 throughput from Monte-Carlo simulation;

Activity factor for this service is 100% [1], hence, assuming 26.5% retransmission and buffering OH (section 6.1), the following equation can be produced:

6445.1)*128_()3.1265.1()*128_(

128______128

∗=∗∗=

==

ChEtotal

ChEprimNRTTtotal

ChEtotal

ChEprimNRTTtotal

NRTTotalATMTavgusersNforATMinratevNRTAverage

Equation 16

A.3 Calculating SHO using ASSET

SHO overhead has to be taken into account when R99 throughput is calculated. A conventional value of 40% can be used. However, for purposes of this project SHO overhead is calculated directly from results of the Monter-Carlo simulation. This allows accounting for excessive coverage overlapping that might occur due to nonoptimal site spacing:

ChEtotal

ChEsoftOHSHO +=1_

Equation 17

Where:

ChEsoft- channel elements utilised by CS users in the Soft HO;

ChEtotal- channel elements utilised by all CS users.

SHO OH can be assumed the same for both CS Voice and NRT128 users as there is no difference in their spatial distribution.

iub interface capacity assessment v0.6

Documents