Vous êtes sur la page 1sur 25

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) Page 2 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




Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 3 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

Commercial in Confidence
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

Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 3 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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

Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 4 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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


Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 5 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 6 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 7 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 8 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 9 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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
SGSN
GGSN
A
Internet
PSTN
Iu -
PS
Iu -CS
Iu -PS
IWU/ATM
BS
BS
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
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 10 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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.
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 11 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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


Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 12 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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:
Ratei BearerUser
OH BearerSig
AFi
_ * 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, IuCS (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:
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 13 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence

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
G
n
I
u
I
ub
U
u
GGSN
3G-
SGSN
RNC
Node B
UE
G
i
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).
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 14 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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).
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 15 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
Assuming target BLER = 10%,

% 45 45 . 1
) 1 . 0 1 (
30 . 1
_ _ =>

= HSDPA OH ATM
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:
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 16 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence

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]:
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 17 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence

( ) ( ) kbps kbps VAF kbps
CsVoive ATM Tavg ATM in rate voice Average
86 . 13 % 35 5 . 4 % 65 9 . 18
_ _
= + =
= =

Equation 3

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

kbps N CsVoice ATM Tavg N
CsVoice total ATM Tavg users N for ATM in rate voice Average
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:
% 30 30 . 1 _ _ 128 => = OH ATM NRT
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 . 1 265 . 1 ( ) 128 _ (
) _ _ 128 _ _ Re _ ( ) 128 _ (
128 _ _ _ _ _ _ 128
= =
= =
= =
NRT Tprim NRT Tprim
OH ATM NRT OH Buf t PS NRT Tprim
NRT Total ATM Tavg users N for ATM in rate vNRT Average

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 . 1 4 . 1 ) 128 _ _ _ _ _ _ (
_ _ ) 128 _ _ _ _ _ _ ( 99 _ _ _
+ =
= + =
= + =
NRT Total ATM Tavg CsVoive Total ATM Tavg
NRT Total ATM Tavg CsVoive Total ATM Tavg
OH Iub OH SHO NRT Total ATM Tavg CsVoive Total ATM Tavg R Total Iub Tavg

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%)
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 18 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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 . 1 1 . 1 _ _ _ _ _ _ _
_ _ _ _ _ _ _ _
=
= = =
= =
HSDPA Total Tavg
HSDPA Total Tavg HSDPA OH ATM OH Iub HSDPA Total Tavg
OH Iub HSDPA OH ATM HSDPA Total Tavg HSDPA Total Iub Tavg


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 _ _ _
_ _
+ =
=
+
=
=
+
=
HSDPA Total Iub Tavg R Total Iub Tavg
HSDPA Total Iub Tavg R Total Iub Tavg
OH g Overbookin
HSDPA Total Iub Tavg R Total Iub Tavg
Total Iub Tavg

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 # Total Iub Tavg ROUNDUP quired E =
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.
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 19 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
#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.
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 20 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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.
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 21 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence

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.
Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 22 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
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
ChEprim
Voice Ttotal Voice Tprim * _ _ =

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 . 0 2 . 12 _ = N Voice Tprim
Equation 12
The above equation does not include the silence period because it is not accounted in Assets voice bearer
model utilised in this project.
Hence, from Equation 11 and Equation 12, the number of primary voice terminals N:

) 65 . 0 2 . 12 /( ) * _ ( =
ChEtotal
ChEprim
Voice Ttotal N

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

kbps
ChEtotal
ChEprim
Voice Ttotal
ChEtotal
ChEprim
Voice Ttotal
N N CsVoice ATM Tavg N
CsVoive Total ATM Tavg users N for ATM in rate voice Average
749 . 1 ) * _ (
)) 65 . 0 2 . 12 /( ) 35 . 0 5 . 4 ( 55 . 1 ( ) * _ (
35 . 0 5 . 4 65 . 0 55 . 1 2 . 12 _ _
_ _ _ _ _ _
=
= + =
= + = =
= =

Equation 14

Commercial in Confidence
Author: Artemi Glazkov OJSC VimpelCom (BeeLine) Page 23 of 25
Date: 13 October 2008 CS-EP-VIM-002-DOC-009 Commercial in Confidence
A.2 Calculating R99 NRT128 Service Throughput using ASSET
An equation similar to Equation 9 can be written:

ChEtotal
ChEprim
NRT Ttotal NRT Tprim * 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 . 1 265 . 1 ( ) * 128 _ (
128 _ _ _ _ _ _ 128
= =
= =
ChEtotal
ChEprim
NRT Ttotal
ChEtotal
ChEprim
NRT Ttotal
NRT Total ATM Tavg users N for ATM in rate vNRT Average

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
ChEsoft
OH SHO + =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.