Iub Interface Capacity Assessment v0.6
-
Upload
tekillajaz -
Category
Documents
-
view
60 -
download
9
Transcript of 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™) 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
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
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:
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:
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
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).
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%,
%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:
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
( ) ( ) 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%)
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.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.
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
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
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
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.