6 HLD For RAN v10

The High Level Design for RAN
The High Level Design for RAN

LOT1 Addis Ababa Swap and Build project
HUAWEI TECHNOLOGIES CO., LTD.
ethio telecom TEP
Confidential
[]
Document Admin
This document is subject to The Telecom Expansion Project. All proposed changes will be offered for review
and acceptance to the nominated Quality representative prior to formal release.
The distribution and overall maintenance of this Plan will be co-ordinate by the Project Manager (PM).
External copies will be distributed in accordance with an agreed distribution.
This document is high level design, after site survey completion, the HLD can be modified
List of Related Documents:
Revision History
Version
Revision Date
Summary of Changes
V1.0
10 Dec 2013
draft
V7.0
16 Dec 2013
Updated as ETs suggestion
V8.0
20 Dec 2013
V9.0
21 Dec 2013
V10.0
22 Dec 2013
Updated to 5 BSC and 5 RNC
V10.1
05 Jan 2014
Updated LTE site number and OMC
Author
Approvals
This document requires the following approvals. Signed approval forms are held with the project archive
files. This document requires the following approvals. Signed approval forms are held with the project
archive files.
Name
TEP
Signature
Title
Confidential
Date
TABLE OF CONTENTS
TABLE OF CONTENTS..................................................................................................................................... I
1
Introduction................................................................................................................................................ 1
1.1
Objectives............................................................................................................................................ 1
1.2
Scope of Work..................................................................................................................................... 1
1.3
Inputs................................................................................................................................................... 1
1.4
Dependencies...................................................................................................................................... 2
1.5
Assumptions........................................................................................................................................ 2
Target Network Design............................................................................................................................... 3
2.1
Current Network Analysis..................................................................................................................... 3
2.1.1
2G Sites Distribution in Current Network (AA Region)......................................................................3
2.1.2
3G Sites Distribution in Current Network (AA Region)......................................................................3
2.1.3
Existing BSC/RNC Information......................................................................................................... 3
2.1.4
Existing OMC Information................................................................................................................. 6
2.1.5
Activated Features in Current Network............................................................................................. 6
2.2
Target Network Design........................................................................................................................ 7
2.2.1
2.3
BSC/RNC Homing Relationship....................................................................................................... 8

BSC6910 Product and Capacity.......................................................................................................... 8
2.3.1
BSC6910 Product Information.......................................................................................................... 8
2.3.2
GSM BSC6910 Dimension Design.................................................................................................10
2.3.3
UMTS BSC6910 Dimension Design...............................................................................................16
2.4
LTE Network and Capacity Design.................................................................................................... 26
2.4.1
LTE Sites Distribution in Target Network (AA Region)....................................................................26
2.4.2
Interface capacity design................................................................................................................... 26
2.5
MBTS Homing Allocation Design....................................................................................................... 29
2.5.1
2G BTS Allocation Design.............................................................................................................. 29
2.5.2
3G NodeB Allocation Design.......................................................................................................... 30
Hardware Distribution Design................................................................................................................... 31
3.1
Hardware Distribution Principle.......................................................................................................... 31
3.2
BSC6910 Board Layout..................................................................................................................... 31
3.2.1
BSC6910 GSM Board Layout......................................................................................................... 31
3.2.2
BSC6910 UMTS Board Layout....................................................................................................... 33
3.3
BSC6910 Power Consumption.......................................................................................................... 33
3.4
BSC6910 Boards Overview............................................................................................................... 34
3.4.1
BSC6910 Boards Introduction........................................................................................................ 34
3.4.2
BSC6910 Interface Board Layout................................................................................................... 39
3.5
3.5.1
TEP
eNodeB Hardware Introduction.......................................................................................................... 43

BBU Slot Design............................................................................................................................. 43
Confidential
3.5.2
BBU Boards Overview.................................................................................................................... 44
3.5.3
Board Introduction.......................................................................................................................... 45
3.5.4
BBU and RRU Layout..................................................................................................................... 53
3.6
2G System Signal Flow...................................................................................................................... 55
3.6.1
User Plane Signaling Flow.............................................................................................................. 55
3.6.2
Control Plane Signaling Flow.......................................................................................................... 56
3.7
3G System Signal Flow...................................................................................................................... 58
3.7.1
User Plane Signaling Flow.............................................................................................................. 58
3.7.2
Control Plane Signaling Flow.......................................................................................................... 60
Naming Design......................................................................................................................................... 62
4.1
BSC/RNC Naming............................................................................................................................. 62
4.2
eNodeB Naming Design.................................................................................................................... 63
4.3
Cell Naming Design........................................................................................................................... 64
O&M Network Design............................................................................................................................... 65
5.1
RAN O&M Network Topology............................................................................................................. 65
5.2
M2000 Design.................................................................................................................................... 66
5.2.1
M2000 Software Structure and Interface........................................................................................69
5.2.2
M2000 Dimension........................................................................................................................... 72
5.3
BSC6910 OMU Design...................................................................................................................... 73
5.3.1
OMU Port Design........................................................................................................................... 73
5.3.2
2G O&M Bandwidth Requirements.................................................................................................74
5.3.3
3G O&M Bandwidth Requirements.................................................................................................74
5.3.4
BSC/RNC OMU IP Plan and configuration.....................................................................................75
5.4
LTE O&M Design............................................................................................................................... 78
5.4.1
eNodeB OM IP Address Design..................................................................................................... 78
5.4.2
eNodeB OMCH Design.................................................................................................................. 78
5.4.3
NTP Synchronization Design.......................................................................................................... 79
Interface Interconnection Design.............................................................................................................. 80
6.1
A Interface Design............................................................................................................................. 80
6.1.1
Interconnection Solution Description..............................................................................................80
6.1.2
IP/VLAN/Routing Planning.............................................................................................................. 81
6.1.3
Logical Links................................................................................................................................... 84
6.1.4
Requirements for Interconnection................................................................................................... 84
6.2
Gb Interface Design........................................................................................................................... 85
6.2.1
6.2.2
6.2.3
Logical Links................................................................................................................................... 88
6.2.4
TEP
Confidential
6.3
Abis Interface Design......................................................................................................................... 88
6.3.1
6.3.2
6.3.3
Logical Links................................................................................................................................... 92
6.3.4
6.3.5
Abis Interface Bandwidth Calculation............................................................................................. 93
6.3.6
Abis Port Allocation Design............................................................................................................. 94
6.4
IuCS Interface Design........................................................................................................................ 95
6.4.1
6.4.2
6.4.3
Logical Links................................................................................................................................... 99
6.4.4
Requirements for Interconnection................................................................................................. 100
6.5
IuPS Interface Design...................................................................................................................... 101
6.5.1
Interconnection Solution Description............................................................................................101
6.5.2
IP/VLAN/Routing Planning............................................................................................................ 102
6.5.3
Logical Links................................................................................................................................. 105
6.5.4
6.6
Iur Interface...................................................................................................................................... 107
6.7
Iub Interface Design......................................................................................................................... 108
6.7.1
Interconnection Solution Description............................................................................................108
6.7.2
IP/VLAN/Routing Planning............................................................................................................ 110
6.7.3
Logical Links................................................................................................................................. 111
6.7.4
6.7.5
Iub Transmission Dimension (from NodeB to RNC)......................................................................113
6.7.6
Iub Port Allocation Design............................................................................................................. 114
6.8
LTE Interface Design........................................................................................................................ 115
6.8.1
Port Planning................................................................................................................................ 115
6.8.2
S1/X2 Interface Planning.............................................................................................................. 116
6.8.3
IP Address Planning...................................................................................................................... 116
6.8.4
IP Route Planning......................................................................................................................... 118
6.8.5
VLAN Planning............................................................................................................................. 118
6.8.6
Traffic flow.................................................................................................................................... 120
QoS Design............................................................................................................................................ 121
7.1
Qos overview................................................................................................................................... 121
7.1.1
2G Qos Requirement.................................................................................................................... 121
7.1.2
3G QoS Requirement................................................................................................................... 121
7.1.3
LTE QoS Requirement.................................................................................................................. 122
7.2
TEP
QoS Design..................................................................................................................................... 122

Confidential
7.2.1
2G QoS Design............................................................................................................................ 123
7.2.2
3G QoS Design............................................................................................................................ 124
7.2.3
LTE QoS Design........................................................................................................................... 127
7.2.4
MBTS QoS Design....................................................................................................................... 128
Redundancy Mechanism Design............................................................................................................ 130
8.1
MSC POOL...................................................................................................................................... 130
8.1.1
Introduction................................................................................................................................... 130
8.1.2
MSC POOL Planning.................................................................................................................... 132
8.2
SGSN POOL.................................................................................................................................... 133
8.2.1
Introduction................................................................................................................................... 133
8.2.2
SGSN POOL Planning.................................................................................................................. 135
8.3
Iu-Flex.............................................................................................................................................. 137
8.3.1
Introduction................................................................................................................................... 137
8.3.2
Iu Flex service process................................................................................................................. 140
8.3.3
Load Balancing............................................................................................................................. 141
8.3.4
Load Re-Distribution..................................................................................................................... 142
8.3.5
Iu-Flex Planning............................................................................................................................ 142
8.4
S1-Flex............................................................................................................................................ 143
8.4.1
S1-Flex Overview......................................................................................................................... 143
8.4.2
Networking and Principles............................................................................................................ 144
8.4.3
Basic Configurations..................................................................................................................... 145
8.4.4
Flex at the User Plane.................................................................................................................. 145
8.5
Transmission SON Feature............................................................................................................. 146
8.5.1
Automatic Setup Process............................................................................................................. 146
8.5.2
S1 Interface Automatic Setup....................................................................................................... 146
8.5.3
X2 Interface Automatic Setup....................................................................................................... 147
8.6
Faults Detection Mechanism............................................................................................................ 147
8.6.1
BFD.............................................................................................................................................. 148
8.6.2
ARP Detection.............................................................................................................................. 150
8.6.3
Binding Relationship Between SBFD/ARP and IP Route.............................................................151
8.6.4
SBFD/ARP Design in VRRP Networking Mode............................................................................151
8.6.5
eNodeB Transmission Detection Mechanism...............................................................................153
8.7
System Reliability............................................................................................................................ 153
8.8
Hardware Reliability......................................................................................................................... 154
8.8.1
Board Redundancy....................................................................................................................... 155
8.8.2
Port Redundancy.......................................................................................................................... 157
8.9
9
TEP
Software Reliability.......................................................................................................................... 158

Feature Deployment............................................................................................................................... 159
Confidential
9.1
2G Feature Categorization............................................................................................................... 159
9.2
3G Feature Categorization............................................................................................................... 160
9.3
LTE Feature Categorization............................................................................................................. 162
10 Clock Synchronization Design................................................................................................................ 166

10.1
Overview.......................................................................................................................................... 166
10.2
IEEE 1588 V2 Clock Synchronization.............................................................................................. 168
10.2.1
IPClock Server Capacity and Bandwidth......................................................................................170
11 Time Synchronization Design................................................................................................................. 176

11.1
Time Synchronization Introduction................................................................................................... 176
11.2
Time Synchronization Resource...................................................................................................... 176
12 Acronyms and Abbreviations.................................................................................................................. 177
Introduction
1.1 Objectives
According to the network equipment list, traffic model and the requirement of customer, the ethio
telecom Technical Solution Document is to design an excellent network, which meets the requirement of
network dimension, with high security & availability, reasonable resource distribution, and convenient to
maintenance and expand in future.
1.2 Scope of Work

This design is a High Level Design document for the AA area in Addis Ababa, Ethiopia.
The Technical Solution takes into account the security for the whole RAN network, which should
consider convenient to expand & maintenance in future based on existing network.
The report covers the design of BSS network design for BSC/RNC/MBTS, which does not include
SGSN, core network design such as MSC, MGW, HLR, and the RF network design.
This design does not include the BSC6910 design such as heat and cooling solution, materials and etc.
This topic will be covered in the BSC6910 Product Documentation.
1.3 Inputs
The following sources of information have been used for this HLD
NSN network modernization project HLD proposal V0.5
A&Gb&Abis Interface IP Transmission Solution Recommended for Commercial

Networks
Technical Clarification of the GSM Network Design Service (GSM only Applicable to the
SRAN8.0 & GBSS15.0 & BSC6910)

TEP
Confidential
IuCS&IuPS&Iub Interface IP Transmission Solution Recommended for Commercial
Networks
Technical Clarification of UMTS RAN15.0 NetWork Design Service(Based on BSC6910)
-20130420-A-2.7
LTE eRAN6 0 Network Design Guide
SRAN8.0 Abis&Iub&S1 IP Insecure Transmission Solutions Recommended for

Commercial Networks V1.1_20130808
Note: All the documents listed above can be found in acceptance documents.
1.4 Dependencies
Issue
No.
Item
Default value
1
2
3
4
5
6
7
Traffic model
Network scale
Transmission
network
IP Plan
Site List
All Numbering
and Naming
Description
The default values of RAN network elements are Huaweis
empirical values. It has been tested by Huawei and can
guarantee the performance of network.
The design follows traffic model from ethio telecom network.
The design follows target network scale from ethio telecom
network.
The design follows transmission network information from ethio
telecom network.
The design for Addresses will need to follow ethio telecoms
actual IP Plan
This design will follow the list provided by ethio telecom of
MBTSs that need to connect to the new Huawei RAN Network.
This will follow ethio telecoms Naming and Numbering Plan.
1.5 Assumptions
This Document is based on the following general assumptions:
Traffic model and traffic forecast is confirmed.
Target network scale is confirmed.
Target number of subscribers is confirmed.
The capacity and distribution information of BTSs are confirmed.
Subscriber distribution is confirmed.
Radio coverage information is confirmed.
Transmission network information is confirmed.
Dimensioning has already been completed and used as input in terms of number of
TRXs required per sector for example.
Dimensioning is based on Active cards being able to carry full load.
TEP
Confidential
Huawei to send information on revised LAC plans based on RF planning details.

These need to take into account densities, coverage distance.
Total Throughput requirements on the Transmission network as result of the design

needs to be discussed separately with transmission teams.
TEP
Confidential
2.1 Current Network Analysis

2.1.1
2G Sites Distribution in Current Network (AA Region)
2.1.2
3G Sites Distribution in Current Network (AA Region)
2.1.3
Existing BSC/RNC Information
Existing BSC information
Current RF capacity:
TEP
Confidential
Target Network Design
Items
Value
Average
Value per
BSC
Total BTS
Total TRX
Total Subs
CS Erl per sub per BH
BHCA per Sub per BH
311
13413
3,400,000
0.025
6
19
789
200000
N/A
N/A
Total
BHCA
Subs
PS Active
Subs
Abis
(Mbps)
A
(Mbps)
Gb
(Mbps)
1476705
1476705
1476706
1476706
1476706
1476706
1476706
1476706
1476706
1476706
1476706
1476706
1476706
1476706
1476706
1476706
1476706
246117
246117
246117
246117
246117
246117
246118
246118
246118
246118
246118
246118
246118
246118
246118
246118
246118
123059
123059
123059
123059
123059
123059
123059
123059
123059
123059
123059
123059
123059
123059
123059
123059
123059
175.2
175.2
175.2
175.2
175.2
175.2
175.2
175.2
175.2
175.2
175.2
175.2
175.2
175.2
175.2
175.2
175.2
134
134
134
134
134
134
134
134
134
134
134
134
134
134
134
134
134
17.17
17.17
17.17
17.17
17.17
17.17
17.17
17.17
17.17
17.17
17.17
17.17
17.17
17.17
17.17
17.17
17.17
25,104,000
4,184,000
2,092,003
2,978
2,278
292
TRX Qty
6000
12456
2856
21312
Subs
1250600
2726826
650012
4627438
Current available capacity for BSC:

BSC No.
TRX
Qty
BTS
Qty
NSN_BSC01
NSN_BSC02
NSN_BSC03
NSN_BSC04
NSN_BSC05
ZTE_BSC01
ZTE_BSC02
ZTE_BSC03
ZTE_BSC04
ZTE_BSC05
ZTE_BSC06
ZTE_BSC07
ZTE_BSC08
ZTE_BSC09
ZTE_BSC10
ZTE_BSC11
ZTE_BSC12
1024
1025
1025
1025
1025
1025
1025
1025
1025
1025
1025
1025
1025
1025
1025
1025
1025
16
16
17
17
17
19
19
19
19
19
19
19
19
19
19
19
19
Total
17424
311
Traffic
(Erl)
6152
6153
6153
6153
6153
6153
6153
6153
6153
6153
6153
6153
6153
6153
6153
6153
6153
104,60
0
Future 2G Capacity in Target Network:

Site Configuration
G666+D444
G666+D666
G666+D888
Total
BSC No.
AA_BSC0
1
AA_BSC0
2
TEP
Site Qty
200
346
68
614
TRX
Qty
BTS
Qty
A Traffic
(Erl)
Total
BHCA
Subs
4212
125
22696
5356202.9
907831
4344
126
23540
5555499
941610
Confidential
PS
Active
Subs
453915.
5
470805
Abis
(Mbps)
A
(Mbps
)
Gb
(Mbps
)
719.82
553
63.33
742.38
570
65.68
AA_BSC0
3
AA_BSC0
4
AA_BSC0
5
TOTAL
4182
122
22616
5337446.8
904652
452326
714.7
549
63.1
4278
118
23491
5543923.2
939648
469824
731.1
568
65.54
4296
123
23342
5508812.3
933697
466848.
5
734.18
564
65.13
2131
2
614
115686
27301884.
2
462743
8
2313719
3642.1
8
2804
322.7
8
Existing RNC information
Current RF capacity:
Total NodeB Qty
Total Cell Qty
Total CE Qty
BHCA per Sub per BH
244
888
53548
14
Current available capacity for RNC:

RNC No.
Cell
Qty
NodeB
Qty
CS
Vioce(Erl)
CS
Data(Erl
)
BHCA
ZTE_RNC0
1
870
244
7500
120
4200000
Total
Subs
300,00
0
Iub
(Mbps)
IuPS
(Mbps)
(Mbps)
12688
522
9203.9
1349.94
Future 3G Capacity in Target Network:

Site
Configuration
U222
U333
U444
Total
RNC No.
Cell
Qty
NodeB
Qty
CS
Vioce(Erl)
AA_RNC01
AA_RNC02
AA_RNC03
AA_RNC04
AA_RNC05
TOTAL
1257
1377
1329
1353
1392
6708
140
145
143
141
153
722
7039.2
7711.2
7442.4
7576.8
7795.2
37564.8
Site Qty
Cell Qty
Subs
79
494
149
722
474
4446
1788
6708
106176
995904
400512
1502592
CS
Data(Erl
)
7.04
7.71
7.44
7.58
7.8
37.56
Total
BHCA
4063026.2
4450904.6
4295753.3
4373329
4499389.4
21682403
Subs
281568
308448
297696
303072
311808
1502592
Iub
(Mbps)
7833
8580
8281
8431
8674
41799
IuCS
(Mbps
)
323
353
341
347
357
1721
Existing OMC Information
Existing OMC dimension analysis as below:
2G TRX Qty
TEP
13413
Confidential
IuR
IuPS
(Mbps)
(Mbps)
5686
6229
6012
6121
6297
30345
834
914
882
898
924
4452
Note: The actual BSC/RNC information in existing network needs a detailed site survey and shall be
adjusted during LLD.
2.1.4
IuR
IuCS
(Mbps)
3G Cell Qty
888
NE Type
Unit
Equivalent NE
Number Mapping
UMTS
GSM
1 Cell
1 TRX
1/35
1/75
Total Capacity of OMC
204
Future OMC Capacity in Target Network:
Report Period
NE Type
NE Version
Unit
30/60 Minutes
WRAN
GBSS
eRAN
RAN 15.0
GBSS 15.0
eRAN6.0
1 Cell
1 TRX
1 Cell
NE Type
Network Scale
GSM
UMTS
LTE
Total Capacity of OMC
21312 TRXs
6708 UMTS Cells
987 LTE Cells
Equivalent NE Number Mapping

Measure KPI
Measure Full
Counter Set
Counter Set
1/50
1/35
1/125
1/75
1/60
1/42
Equivalent NEswith 100% Full

Counter Measurement
285
192
24
501
Note: The actual OMC information in existing network needs a detailed site survey and shall be adjusted
during LLD.
2.1.5
Activated Features in Current Network
2G Activated Feature List
Please refer to the attachment <2G Feature List_20131217> for the details.
2G Feature
List_20131217.xlsx
3G Activated Feature List
Please refer to the attachment <3G Feature List_20131217> for the details.
3G Feature
List_20131217.xlsx
Note: The actual activated features information in existing network need a detailed network analysis and
shall be adjusted during LLD.
TEP
Confidential
2.2 Target Network Design

Proposed GSM/UMTS/LTE radio network solution for AA region (including swap and new build site):
Target Network Topology for AA region
2.2.1
BSC/RNC Homing Relationship
BSC/RNC to CS/PS Core
2.3 BSC6910 Product and Capacity

2.3.1
BSC6910 Product Information
Target Product Version:

Product Version Information
TEP
Confidential
NE Type
Version Information
BSC
BSC6910V100R015C0SPHXXX
BTS
BTS3900V100R008C00SPCXXX
The BSC6910 uses the Huawei N68E-22 cabinet. The design complies with the IEC60297 and IEEE
standards. The cabinet configured with the MPS subrack is called Main Processing Rack (MPR) and the
cabinet not configured with the MPS subrack is called Extended Processing Rack (EPR).
Figure 2-1 Front view (left) and rear view (right) of the BSC6910 cabinet
1 Subracks
2 Air defense subrack
The BSC6910 subracks are classified into the MPS and EPS, as described in Table 2-1.
Table 2-1 Classification of the BSC6910 subracks
TEP
Subrack
Quantity
MPS
The MPS performs centralized

switching and provides service paths for
other subracks. It also provides the service
processing interface, O&M interface, and
system clock interface.
EPS
The EPS performs the functions of user

plane processing and signaling control.
Confidential
Function
2.3.2
GSM BSC6910 Dimension Design
2.3.2.1 Dimension principle

Huawei will obey the following BSC dimension principle within Addis Ababa project.
Traffic volume
ethio telecom request the traffic volume for each BSC must not be more than 50,000 Erl in image
network. So Huawei respected this requirement and took it as dimension input. Each BSC traffic volume
should between 20,000 Erl and 50,000 Erl.
Transmission resource availability

All the BTS throughput will converge to BSC. If the single node throughput of BSC is too high, it will
impact on the metro transmission resource. Considering the 10G SDH capacity and fiber resource
availability, huawei will distribute the throughput into several BSC.
Worada division
ET provide 28 woradas polygon for Addis Ababa project planning. The sites in the same worada should
be connected to the identical BSC as much as possible.
To figure out the number of BSC, Huawei will find a standard reference BSC model which comply the above design
principle. Then the number of BSC can be calculated as below:
Number of BSC = Total Capacity/Capacity of standard reference BSC

2.3.2.2 BSC Model Dimension
To find out BSC standard reference model, Huawei assume the reference BSC model as below:
Reference BSC Model Assumption
Parameter
TRX Qty
Total Traffic Forecast(AA Region)

21312(Note)
Value of Ref.BSC
75% * Value of Ref.BSC
5800
4350
BTS Qty
614
170
127
Note: The statistic of total traffic forecast listed above based on RF planning results of AA Region
2G Traffic Model Assumption of the Reference BSC as below:
CS
Average voice traffic per subscriber@BH(Erlang)
TEP
Value
0.025
Average Call Duration(s)
45
Average MOCs/Sub/BH(Times)
0.7
Average MTCs/Sub/BH(Times)
1.3
Average MO-SMSs/Sub/BH(Times)
0.2
Average MT-SMSs/Sub/BH(Times)
0.3
Location update/Sub/BH(Times)
1.5
Percent of Mobile originated calls(%)
35
Percent of Mobile terminated calls(%)
65
Average IMSI Attach/Sub/BH(Times)
0.15
Average IMSI Detach/Sub/BH(Times)
0.15
Average intra-BSC HOs/Sub/BH(Times)
2.2
Average inter-BSC HOs/Sub/BH(Times)
0.2
Paging Retransfer Ratio(%)
35
MR Report/Sub/BH(Times)
180
Confidential
A Erl/Um Erl(%)
80
Average BHCA/Sub/BH(Times)
5.9
PS
Average traffic in BH/sub(kbps)
Value
0.1
GPRS Active Sub Factor
0.5
Static PDCH per Cell
Dynamic PDCH per Cell
Gb Circuit Utilization Ratio(%)
70
Dynamic PDCH Active Ratio(%)
50
PS Paging/Sub/BH(Times)
1.25
GoS
Grade of Service(Gos)on Um interface(%)
Value
2
Grade of Service(Gos)on A interface(%)
0.1
Reference BSC Dimension Calculation Formulas & Output

1)
Reference BSC Dimension Calculation Formulas
TCH per cell = ( 8* TRX per cell BCCH Number of SDCCH(HR) Static PDCH per Cell ) * ( 1+ HR
Ratio)
Erlang per cell = erlangB_traffic (TCH per cell, Gos in Um interface )
Erlang requirement of A = Erlang per cell * 3 * BTS QTY * A Erl :Um Erl
The CIC volume is calculated by the below formula:
Sub Qty = Erlang requirement of A / Average voice traffic per subscriber BH
CIC requirement of network = erlangB_Device (Erlang requirement of A , Gos in A interface)
Notes:
erlangB_traffic and erlangB_Device are erlangB formulas that is widely used in call center
scheduling. The formula can be used to calculate any one of the following three factors if you know or predict
the other two:
(1) Busy Hour Traffic (BHT): the number of hours of call traffic during the busiest hour of operation;
(2) Blocking: the percentage of calls that are blocked because not enough lines are available;
(3) Lines: the number of lines in a trunk group;
Gb Throughput requirement of network = GPRS Active Sub * Average traffic in BH per sub / Gb Circuit
Utilization Ratio
PDCH requirement of network = ( Static PDCH per Cell + Dynamic PDCH per Cell * Dynamic PDCH
Active ratio) * BTS QTY * 3
Abis IP throughput(Mbps) = TRX quantity when using IP * 7 * Abis-CIC IP bandwidth(kbps) / 1024 / 2
A IP Throughput[control plane] = A-CIC QTY * SS7 link throughput per CIC
A IP Throughput[user plane] = A-CIC QTY * (TRAU frame + frame head of A interface when using IP) *
50 * CSVAD / 1024
A IP throughput(Mbps)=A IP Throughput[control plane]+A IP Throughput[user plane]
2)
Reference BSC Dimension Calculation Output
Based on the above inputs and formulas, we can figure out the output of Abis/A/Gb Throughput, CS
Erlang, BHCA, etc.for reference BSC.
Network Output(CS)
Name
TEP
Value
Confidential
TRX QTY
Sub Qty
TDM STM-1QTY(E1)
IP STM-1 QTY(E1)
BTS QTY
Cell QTY
A TRAFFIC(Erlang)
A-CIC QTY
max IWF number
CS BHCA
Abis IP throughput(Mbps)
A IP Throughput[user plane](kbps)
A IP Throughput[control plane]( kbps )
A IP throughput(Mbps)
WBAMR
Network Output(PS)
Name
Static PDCH QTY
Dynamic PDCH QTY
Configured PDCH QTY
Active PDCH QTY
Gb 64Kbps Link QTY
Gb throughput(Mbps)
5800
1405610
0
0
170
1020
35140.25
34484
43500.0
8293099
991.21
747603.0
31035.6.2
761.0
0.0
Value
2040
3060
5100
3570
1961
98.05
Reference BSC Board Configuration

BSC boards hardware specification for the board quantity calculation as below:
Capacity of EGPUa:
CP/UP board
BSC6910(EGPUa) for GSM
TRX/ BTS/CELL
1000/600/600
PDCH
3000
Erlang capacity
6250
BHCA
2200K
Capacity of GOUc:
A &Gb&Abis interface
GOUc
VoiceErl
10050
CIC
23040
UL+DL(Mbps)
2000
TRX
2048
Abis interface configuration principle and limitation:

The configuration quantity is determined on the requirement of the number of ports and number of
TRXs.
Abis interface calculation formula:
Number of Abis interface boards = 2* MAX( Requirement of TRX / TRX capacity of interface board,
Requirement of port number / port number of interface board)
Gb interface configuration principle and limitation:
The configuration quantity is determined on the requirement of the number of ports and throughput.
TEP
Confidential
Gb interface calculation formula:Number of interface boards = 2 * ROUNDUP ( MAX ( Requirement of

port number / Port number Per board, Throughput requirement of Gb / Throughput Per board ) , 0 )
A interface configuration principle and limitation:
The configuration quantity is determined on the requirement of the number of ports and number of CICs.
Number of interface boards = 2 * ROUNDUP (CIC requirement of Interface / CIC number Per board , 0 )
Based on the above board capcity and the formular we can figure out the quantity for each type board.
EGPUa for CP = roundup(7643/2200,0) + 1 = 5
EGPUa for UP = roundup(5800/1000,0) +1 = 7
Interface for A =2* roundup34484/23040,0=4
Interface for Abis = 2*roundup (5800/2048,0) = 6
Interface for Gb = 2*roundup (98.05 /2000,0) = 2
The BSC boards configuration is show as below
Table 2-1 Reference BSC Boards Configuration
Board name
Qty
OMU
2
SCU
4
EGPUa
12
GOUc
12
GCU
2
OMU Operation & maintenance unit

1+1 for each BSC
SCU switch control unit
1+1 for each subrack
EGPUa: General processing unit for CP and UP
N+1 for CP and UP
GOUc: General optical unit for A/Abis/Gb interface
1+1 for each interface
GCU: General clock Unit
1+1 for each BSC
Based on the reference BSC calculation, we will estimate the number of BSC for Addis Ababa network.
Number of BSC = max(roundup (Total TRX of Addis Ababa/TRX capacity of reference BSC*75%,0),
roundup (Total BTS of Addis Ababa/BTS Qty of reference BSC*75%,0))
= max(roundup (21312/4350,0),roundup (623/127,0))
=5
2.3.2.3
Final BSC Dimension
BSC No.
TRX
Qty
BTS
Qty
A
Traffic
(Erl)
Total
BHCA
Subs
PS Active
Subs
Ref. BSC
5800
170
35140
8,293,099
1405610
702805
4212
125
22696
5356203
907831
453916
72.62
%
73.53
%
64.59
%
64.59%
64.59%
64.59%
4344
126
23540
5555499
941610
470805
74.90
%
74.12
%
66.99
%
66.99%
66.99%
66.99%
4182
122
22616
5337447
904652
72.10
%
71.76
%
64.36
%
64.36%
4278
118
23491
73.76
%
69.41
%
4296
123
AA_BSC0
1
Capacity
Utilization
AA_BSC0
2
Capacity
Utilization
AA_BSC0
3
Capacity
Utilization
AA_BSC0
4
Capacity
Utilization
AA_BSC0
5
TEP
Abis
(Mbps
)
991.2
1
719.8
2
72.62
%
742.3
8
74.90
%
A
(Mbps
)
Gb
(Mbps
)
761
98.05
553
63.33
72.67
%
64.59
%
570
65.68
74.90
%
66.99
%
452326
714.7
549
63.1
64.36%
64.36%
72.10
%
72.14
%
64.35
%
5543923
939648
469824
731.1
568
65.54
66.85
%
66.85%
66.85%
66.85%
74.64
%
66.84
%
23342
5508812
933697
466849
73.76
%
734.1
8
564
65.13
Confidential
Capacity
Utilization
74.07
%
72.35
%
TOTAL
21312
614
66.43
%
11568
6
66.43%
66.43%
66.43%
27,301,884
4627438
2313719
74.07
%
3642.
2
74.11
%
2804
66.43
%
322.7
8
BSC Board Dimension Output:

Interface
Type
SUBRAC
K
SUBRAC
K
GCU
RMP
GCUP
OMU
SAU
SCU
A
GB
ABIS
Board
Type
Board Number
AA_BSC AA_BSC
3
4
AA_BSC
1
AA_BSC
2
AA_BSC
5
GMPS
GEPS
GCUa
EGPUa
EGPUa
EOMUa
ESAUa
SCUb
GOUc
GOUc
GOUc
1
2
2
10
2
1
4
4
2
6
1
2
2
10
2
1
4
4
2
6
1
2
2
10
2
1
4
4
2
6
1
2
2
10
2
1
4
4
2
6
1
2
2
10
2
1
4
4
2
6
2G Sites Distribution in Target Network:
According to new network planning and optimization, we can get the target network configuration and
capacity.
GSM radio network configuration and capacity:
GSM Network Planning Capacity Result in AA region
TEP
Confidential
BSC No.
Site Config
G666+D44
4
AA_BSC G666+D66
1
6
G666+D88
8
G666+D44
4
AA_BSC G666+D66
2
6
G666+D88
8
G666+D44
4
AA_BSC G666+D66
3
6
G666+D88
8
G666+D44
4
AA_BSC G666+D66
4
6
G666+D88
8
G666+D44
4
AA_BSC G666+D66
5
6
G666+D88
8
Total
2.3.3
Site Qty
TRX Qty
Subs
65
1950
406445
43
1548
338883
17
714
162503
46
1380
287638
66
2376
520146
14
588
133826
38
1140
237614
81
2916
638361
126
28677
26
780
162578
61
2196
480741
31
1302
296329
25
750
156325
95
3420
748695
126
28677
614
21312
4627438
UMTS BSC6910 Dimension Design
2.3.3.1 Dimension principle

Huawei will obey the following RNC dimension principle within Addis Ababa project.
Data throughput
The data service throughput is not even in real network. Sometimes the burst throughput will exceed the
design target. Considering the combine voice/data service traffic model and network safety, Huawei suggests
the throughput for each RNC should be between 20Gbps and 45G bps.
Transmission resource availability

All the NodeBs throughput will converge to RNC. If the single node throughput of RNC is too high, it will
impact on the metro transmission resource. Considering the 10G SDH capacity and fiber resource
availability, huawei will distribute the throughput into several RNC.
Worada division
ET provide 28 woradas polygon for Addis Ababa project planning. The sites in the same worada should
be connected to the identical RNC as much as possible.
To figure out the number of RNC, Huawei will find a standard reference RNC model which comply the
above design principle. Then the number of RNC can be calculated as below:
TEP
Confidential
1)
Number of RNC = Total Capacity/Capacity of standard reference RNC

Notes:
The number of cells configured for one RNC must not exceed 75% of the product specification. The number
of NodeBs configured for one RNC must not exceed 75% of the product specification.
2.3.3.2 RNC Model Dimension
To find out RNC standard reference model, Huawei assume the reference RNC model as below:
Reference RNC Model Assumption
Parameter
Sub
Total Traffic Forecast(AA Region)

1502592 (Note)
Value of Ref.RNC
75% * Value of Ref.RNC
NodeB Qty
722
420,000
315,000
205
153
Cell Qty
6708
1900
1425
Note: The statistic of total traffic forecast listed above based on RF planning results of AA Region
3G Traffic Model Assumption for the Reference RNC as below:
User plane traffic parameter
CS voice penetration ratio [%]
100.00%
CS data (Video Phone 64k) penetration ratio [%]

Voice Traffic per CS voice sub in BH [Erlang]
CS data traffic per CS data (Video Phone 64k) sub in BH [Erlang]
CS voice call duration [sec]
CS data (Video Phone 64k) call duration [sec]
PS (Including R99 and HSPA) Penetration Ratio [%]
PS throughput (Including R99 and HSPA, UL+DL) per active PS
sub in BH [kbps]
1.00%
0.025
0.0025
45
45
100.00%
Other related parameters
IuCS signaling throughput ratio [%]

IuPS signaling throughput ratio [%]
Iub CS signaling throughput ratio per site [%]
Iub PS signaling throughput ratio per site [%]
Iub OAM throughput per site [kbps]
Traffic throughput ratio between Iur and Iub [%]
Iur signaling throughput ratio [%]
Control plane traffic parameter
CS voice call per CS voice sub per BH [times]

Proportion of soft Handover for CS voice call (not including softer
Handover) [%]
Handover times per CS voice call (Inter/Intra RNC soft&softer
handover) [times/call]
Ratio of soft HO / soft&softer HO for CS voice call [%]
CS Data call per CS data sub per BH [times]
Proportion of soft handover for CS data call (not including softer
hanover) [%]
Handover times per CS data call (Inter/Intra RNC soft&softer
handover) [times/call]
Ratio of soft handover/ soft&softer handover for CS data call [%]
Smart phone Penetration Ratio (% of Total Subscribers)
TEP
Value
Confidential
33.53kbps
Value
1.00%
1.00%
10.00%
10.00%
64.0kbps
10.00%
10.00%
Value
2
30.00%
4
80.00%
0.15
30.00%
6
80.00%
63.30%
(Smart phone) PS call per PS sub per BH

Data Dongle Penetration Ratio (% of Total Subscribers)
(Data Dongle)PS call per PS sub per BH
PS call duration [sec]
PS call per PS sub per BH [times]
Proportion of soft handover for PS call (not including softer
handover) [%]
Handover times per PS call (Inter/Intra RNC soft&softer handover)
[times/call]
Ratio of soft handover / soft&softer handover for PS call [%]
BHCA per sub per BH [times](including CS voice/CS data/PS
service)
Number of SMS/BH/SUB(MO) [times]
Number of SMS/BH/SUB(MT) [times]
Proportion of UL PS(Including R99 and HSPA) throughput [%]
Proportion of DL PS(Including R99 and HSPA) throughput [%]
R99 share of DL PS throughput per sub [%]
HSDPA share of DL PS throughput per sub [%]
R99 share of UL PS throughput per sub [%]
HSUPA share of UL PS throughput per sub [%]
15
36.70%
8
55.5
12.43
30.00%
2.64
80.00%
14.43
0.2
0.3
30.00%
70.00%
10.00%
90.00%
50.00%
50.00%
Note:
Regarding to the BHCA per Subscriber, please follow the calculation formula as below:
BHCA per subscriber =CS Voice call per sub per BH * CS Voice penetration ratio + CS Data
call per sub per BH * CS Data penetration ratio + PS call per sub per BH * PS penetration
ratio=2*100%+0.15*1%+12.43*100%=14.43
Total BHCA=Total subscriber * BHCA per subscriber=420,000 * 14.43= 6060600
Reference RNC Dimension Calculation Formulas & Output

1)
Reference RNC Dimension Calculation Formulas

Iub Interface Dimension Formulas
Iub DL payload throughput for CS voice
=Subscribers * CS voice penetration ratio * Voice Traffic per sub per BH * 12.2 * (1 +
Proportion of SHO for CS call)*CS voice active factor
Iub UL payload throughput for CS voice
=Subscribers * CS voice penetration ratio * Voice Traffic per sub per BH * 12.2 * (1 +
Proportion of SHO for CS call)*CS voice active factor
Iub DL payload throughput for CS data
=Subscribers * CS data penetration ratio * CS data traffic per sub per BH * 64 * (1 +

Proportion of SHO for CS call)
Iub UL payload throughput for CS data
=Subscribers * CS data penetration ratio * CS data traffic per sub per BH * 64 * (1 +

Proportion of SHO for CS call)
TEP
Confidential
Iub DL payload throughput for PS R99
=Subscribers * PS penetration ratio * Total PS throughput per user per BH * Proportion of

DL PS throughput * R99 share of DL PS throughput per sub * (1+ Proportion of SHO for PS
call)
Iub DL payload throughput for PS HSDPA

DL PS throughput * HSDPA share of DL PS throughput per sub
Iub UL payload througput for PS R99

UL PS throughput * R99 share of UL PS throughput per sub * (1+ Proportion of SHO for PS
call)
Iub UL payload througput for PS HSUPA

UL PS throughput * HSUPA share of UL PS throughput per sub* (1+ Proportion of SHO for
PS call)
Iub MBMS throughput
=Number of cell * MBMS penetration ratio * MBMS Iub throughput per cell
Iub DL user plane payload throughput
=Iub DL payload throughput for CS voice + Iub DL payload throughput for CS data + Iub DL
payload throughput for PS R99 + Iub DL payload throughput for PS HSDPA + Iub MBMS
throughput
Iub UL user plane payload throughput
=Iub UL payload throughput for CS voice + Iub UL payload throughput for CS data + Iub UL
payload througput for PS R99 + Iub UL payload througput for PS HSUPA
Iub user plane payload throughput
=MAX (Iub DL user plane payload throughput, Iub UL user plane payload throughput)
Iub CS control plane throughput
=Max (Iub DL payload throughput for CS voice + Iub DL payload throughput for CS data, Iub
UL payload throughput for CS voice + Iub UL payload throughput for CS data) * Iub CS
signaling throughput ratio
Iub PS control plane throughput
=Max (Iub DL payload throughput for PS R99 + Iub DL payload throughput for PS HSDPA,
Iub UL payload throughput for PS R99 + Iub UL payload throughput for PS HSUAP) * Iub
PS signaling throughput ratio
Iub control plane throughput
=Iub CS signaling throughput + Iub PS signaling throughput
Iub OAM throughput
=Iub OAM throughput per site * NodeB Number
IuCS Interface Dimension Formulas
IuCS CS voice(Erl)
=Subscribers*CS voice penetration ratio*Voice Traffic per CS voice sub in BH
IuCS CS data(Erl)
=Subscribers * CS data(Video Phone 64k) penetration ratio * CS data(Video Phone 64k)
TEP
Confidential
traffic per sub per BH
IuCS CS voice DL payload throughput (Mbps)
=(IuCS CS voice(Erl)* 12.2) / 1000
IuCS CS voice UL payload throughput (Mbps)
=(IuCS CS voice(Erl) * 12.2) / 1000
IuCS CS data DL payload throughput (Mbps)
=(IuCS CS data(Erl) * 64) / 1000
IuCS CS data UL payload throughput (Mbps)
=(IuCS CS data(Erl) * 64) / 1000
IuCS control plane throughput
=Max (IuCS CS voice DL payload throughput + IuCS CS data DL payload throughput ,

IuCS CS voice UL payload throughput + IuCS CS data UL payload throughput ) * IuCS
signaling throughput ratio
IuPS Interface Dimension Formulas
PS DL PO throughput (Mbps)
=Subscribers * PS Penetration Ratio * Total PS throughput per user per BH * Proportion of

DL PS throughput / 1000000
PS UL PO throughput (Mbps)
= Subscribers * PS Penetration Ratio * Total PS throughput per user per BH * Proportion of

UL PS throughput / 1000000
IuPS DL data plane payload throughput

(Mbps)
= PS DL PO throughput + IuPS MBMS payload throughput / 1000
IuPS UL data plane payload throughput

(Mbps)
= PS UL PO throughput
IuPS control plane throughput (Mbps)
= Max (IuPS DL data plane payload throughput , IuPS UL data plane payload throughput ) *
IuPS signaling throughput ratio
Iur Interface Dimension Formulas
Iur DL payload throughput (Mbps)
= (Iub DL payload throughput for CS voice + Iub DL payload throughput for CS data + Iub
DL payload throughput for PS R99 + Iub DL payload throughput for PS HSDPA + Iub
MBMS throughput) * Traffic throughput ratio between Iur and Iub
Iur UL payload throughput (Mbps)
= (Iub UL payload throughput for CS voice + Iub UL payload throughput for CS data + Iub
UL payload throughput for PS R99 + Iub UL payload throughput for PS HSUPA) * Traffic
throughput ratio between Iur and Iub
Iur control plane throughput (Mbps)
= Max(Iur DL payload throughput, Iur UL payload throughput) * Iur signaling throughput
TEP
Confidential
ratio
2)
Capacity Calculation Output
Based on input and formula, we will figure out the output of each interface throughputCS
ErlangBHCANodeB/Cell for reference RNC.
IuCS Table
Parameters
IuCS CS voice (Erl)
IuCS CS data (Erl)
IuCS CS voice DL payload throughput (Mbps)
IuCS CS voice UL payload throughput (Mbps)
IuCS CS data DL payload throughput (Mbps)
IuCS CS data UL payload throughput (Mbps)
IuCS control plane throughput
IuPS Table
Parameters
IuPS DL data plane payload throughput (Mbps)
IuPS UL data plane payload throughput (Mbps)
IuPS control plane throughput (Mbps)
Iur Table
Parameters
Iur DL payload throughput (Mbps)
Iur UL payload throughput (Mbps)
Iur control plane throughput (Mbps)
Value
10500.
0
10.5
128.1
128.1
0.68
0.68
1.288
Value
6893.21
2954.233
8
68.9321
Value
720.81
394.89
72.081
Iub Table
Parameters
Iub CS voice (Erl)
Iub CS data (Erl)
Iub DL payload throughput for CS voice (Mbps)
Iub UL payload throughput for CS voice (Mbps)
Iub DL payload throughput for CS data (Mbps)
Iub UL payload throughput for CS data (Mbps)
Iub DL payload throughput for PS R99 (Mbps)
Iub DL payload throughput for PS HSDPA (Mbps)
Iub UL payload througput for PS R99 (Mbps)
Iub UL payload througput for PS HSUPA (Mbps)
Iub MBMS throughput (Mbps)
Iub CS signaling throughput (Mbps)
Iub PS signaling throughput (Mbps)
Iub OAM throughput (Mbps)
TEP
Confidential
Value
13650.
0
13.65
100.8
100.8
0.89
0.89
898.8
6207.6
1923.6
1923.6
0.0
10.17
710.65
19.2
Reference RNC Board Configuration

RNC boards hardware specification for the board quantity calculation as below:
Capacity of EGPUa
CP/UP board
BSC6910(EGPUa) FOR UMTS
Active Users capacity per CP/UP board
35000/21000
Online Users capacity per CP board
70000
Erlang capacity per UP board
10050
Nodebs per CP/ Cells per UP
700/1400
Throughput per UP board(Mbps) (including UL/DL

throughput)
2000
Capacity of EXOUa
IUB
Interface
board
EXOUa
IUB
Voice
Erl
75000
IU
Interfac
e Board
IUCS
Voice(Erl)
EXOUa
75000
VPEr
l
75000
UL(Mbps)
DL(Mbps)
UL+DL(Mbps)
8,000
8,000
10,000
VP(Erl)
IUPS
UL(Mbps)
DL(Mbps)
UL+DL(Mbps)
37500
9,500
9,500
10,000
CID/UDP
NodeB
1000000
1500
IUPS On-line
users
500000
Boards = Capacity Requirements/Capacity per board

CP boards = max (CP boards for BHCA , CP boards for Active users , CP boards for Online users, CP
boards for NodeB )+1
CP boards for BHCA = Total Subscribers /( Subsystem numbers per CP board * Supported subscriber
number per CP )
CP boards for Active users = Active Users/Active Users capacity per CP board.
CP boards for Online users = Online Users/Online Users capacity per CP board.
CP boards for NodeB= Total Nodeb/Nodeb capacity per CP board.
Number of EGPUa for CP = 9
UP boards = max (UP boards for Iub Erlang, UP boards for Iub PS throughput, UP boards for Active
users , UP boards for Cells )+1
UP boards for Iub Erlang = IuB CS Traffic (Erlang)/Erlang capacity per UP board
UP boards for Iub PS throughput = (IuB DL PS Throughput + IuB UL PS Throughput ) /PS Throughput
per UP board
UP boards for Active users = Active Users/Active Users capacity per CP board.
UP boards for Cells = Total Cells/Cells capacity per CP board.
Number of EGPUa for UP = 14
3. IuB Interface boards = 2*max (IuB int boards for Erlang + IuB int boards for Throughput , for IuB
Active Users , for Nodebs)
IuB int boards for Erlang = IuB CS Traffic (Erlang)/Erlang capacity per IuB int board
TEP
Confidential
IuB int boards for Throughput = (IuB PS DL throughput /DL throughput capacity per IuB int board + IuB
PS UL throughput /UL throughput capacity per IuB int board ) + (IuB Signaling Throughput + OAM
Throughput )/ DL throughput capacity per IuB int board
IuB Int boards for Active users = IuB Active Users/IuB Active Users capacity per IuB Int board.
IuB Int boards for Nodebs = Total Nodebs/Nodeb capacity per IuB Int board.
Number of EXOUa = 6
4. IuCS/Iur Interface boards = 2*[ MAX( Number of IuCS interface board_Traffic, Number of IuCS
interface board_BandwidthNumber of IuCS Interface Board_Active users)+ MAX(Number of Iur interface
board_Traffic, Number of Iur interface board_bandwidth Number of Iur Interface Board_Active users)]
Number of EXOUa = 6
5. IuPS Interface boards = 2*Max(IuPS Int boards for traffic ,IuPS Int boards for throughput , IuPS Int
boards for PS online Users)
IuPS Int boards for throughput = Iu DL PS throughput/DL PS throughput per Iu int board + Iu UL PS
throughput/UL PS throughput per Iu int board + ( IuPS signaling throughput+ OAM throughput)/DL PS
throughput per Iu int board
IuPS Int boards for PS online Users = PS online users/ online users capacity per IuPS int board
IuPS Int boards for traffic = MAX(IuPS DL Transmission Traffic / Iu PS DL specification , IuPS UL
Transmission Traffic / Iu PS UL specification, (IuPS DL Transmission Traffic + IuPS UL Transmission
Traffic ) / Iu PS DL+UL specification )
Number of EXOUa = 4
The RNC configuration is shown as below
Reference RNC Configuration
Board name
OMU
SCU
Qty
2
4
EGPUa
23
EXOUa
16
GCU
2
OMU Operation & maintenance unit

1+1 for each RNC
SCU switch control unit
1+1 for each subrack
EGPUa: General processing unit for CP and UP
N+1 for CP and UP
GCU: General clock Unit
1+1 for each RNC
EXOUa 10GE optical interface Board for IuB/IuCS/IuPS/IuR 1+1 for each interface
Based on the above reference RNC calculation, we will estimate the number of RNC for Addis Ababa
network.
Number of RNC
= max( roundup (Total subs of Addis Ababa/subs of reference RNC,0), roundup (Total NodeB of Addis
Ababa/NodeB Qty of reference RNC,0), roundup (Total cell of Addis Ababa/Cell Qty of reference RNC,0))
=5
2.3.3.3
RNC No.
Ref. RNC
AA_RNC0
1
Capacity
Utilization
AA_RNC0
TEP
Final RNC Dimension
Cell
Qty
190
0
125
7
66.1
6%
137
Nod
eB
Qty
CS
Vioce(
Erl)
CS
Data(Erl)
Total
BHCA
Subs
Iub
(Mbps
)
IuCS
(Mbps
)
IuPS
(Mbps
)
IuR
(Mbps
)
205
10500
10.5
6060600
420000
11684
481
8482
1244
140
7039.2
7.04
4063026.2
281568
7833
323
5686
834
67.04%
67.05%
67.04%
67.04%
7711.2
7.71
4450904.6
308448
67.04
%
8580
67.15
%
353
67.04
%
6229
67.04
%
914
68.2
9%
145
Confidential
2
Capacity
Utilization
AA_RNC0
3
Capacity
Utilization
AA_RNC0
4
Capacity
Utilization
AA_RNC0
5
Capacity
Utilization
TOTAL
7
72.4
7%
132
9
69.9
5%
135
3
71.2
1%
139
2
73.2
6%
670
8
70.7
3%
73.44%
73.43%
73.44%
73.44%
73.43
%
73.39
%
73.44
%
73.47
%
143
7442.4
7.44
4295753.3
297696
8281
341
6012
882
69.7
6%
70.88%
70.86%
70.88%
70.88%
70.87
%
70.89
%
70.88
%
70.90
%
141
7576.8
7.58
4373329
303072
8431
347
6121
898
68.7
8%
72.16%
72.19%
72.16%
72.16%
72.16
%
72.14
%
72.16
%
72.19
%
153
7795.2
7.8
4499389.4
311808
8674
357
6297
924
74.6
3%
74.24%
74.29%
74.24%
74.24%
74.24
%
74.22
%
74.24
%
74.28
%
722
37564.
8
37.56
21682403
150259
2
41799
1721
30345
4452
RNC Board Dimension Output:

Interface
Type
Board
Type
SUBRACK
SCU
GCU
OMU
GPU
SAU
Iub_IP
IuPS_IP
IuCSIur_IP
SUBRACK
SCUb
GCUa
EOMUa
EGPUa
ESAUa
EXOUa
EXOUa
EXOUa
AA_RNC
1
2
4
2
2
23
1
6
4
6
Board Number
AA_RNC
AA_RNC
AA_RNC2
3
4
2
2
2
4
4
4
2
2
2
2
2
2
23
23
23
1
1
1
6
6
6
4
4
4
6
6
6
3G Sites Distribution in Target Network:
TEP
Confidential
AA_RNC5
2
4
2
2
23
1
6
4
6
According to new network planning and optimization, we can get the target network configuration and
capacity.
UMTS radio network configuration and capacity
UMTS Network Planning Capacity Result in AA region
RNC No.
AA_RNC
1
AA_RNC
2
AA_RNC
3
AA_RNC
4
AA_RNC
5
Site
Config
U222
U333
U444
U333
U444
U222
U333
U444
U222
U333
U444
U222
U333
U444
Site Qty
Cell Qty
Subs
54
33
53
121
24
2
125
16
19
75
47
4
140
9
722
324
297
636
1089
288
12
1125
192
114
675
564
24
1260
108
6708
72576
66528
142464
243936
64512
2688
252000
43008
25536
151200
126336
5376
282240
24192
1502592
Total
TEP
Confidential
LTE Network and Capacity Design
2.4
2.4.1
LTE Sites Distribution in Target Network (AA Region)
Note Huawei will only ensure the eRAN and EPC(not including HSS of LTE) ready for use, Ethio
Telecom shall provide HSS system before LTE commercial launch.
2.4.2
Interface capacity design
3 interfaces should be considered here: S1-C, S1-U, X2. eNodeB interface topology:
TEP
Confidential
Traffic Model & Service Model
Huawei recommends that the signaling plane traffic is 1% to 3% of the user plane traffic according to
its emulation and experience values.
Huawei recommends that the X2 traffic is 1% to 3% of the S1 traffic according to emulation and
experience values.
UL:DL=1:4
Service Model
UL
Traffic
Parameters
Voip
Video Phone
Video
conference
Real Time
Gaming
Streaming
Media
IMS
Signalling
Web
Browsing
File Transfer
Email
P2P file
sharing
DL
BL
ER
Bearer
ratekbps
)
PPP Session
Time(s)
80
70
PPP
Session
Duty
Ratio
0.4
1
1%
1%
26.9
62.528
80
70
PPP
Sessio
n Duty
Ratio
0
1
62.528
1800
1%
125.056
1800
1%
31.264
1800
0.2
1%
125.056
1800
1%
31.264
1200
0.05
1%
250.112
1200
1%
15.632
0.2
1%
15.632
1%
62.528
1800
0.05
1%
250.112
1800
1%
140.688
140.688
600
50
1
0.5
1%
1%
750.336
750.336
600
15
1
0
1%
1%
48.85
1200
1%
97.7
1200
1%
Bearer
ratekbps
PPP
Session
Time(s)
26.9
62.528
BL
ER
1%
1%
Traffic Model
Dense Urban
User
Behavior
Urban
Suburban
Rural Area
Traffic
penetratio
n Ratio
BHS
A
Traffic
penetratio
n Ratio
BHS
A
Traffic
penetratio
n Ratio
BHS
A
Traffic
penetratio
n Ratio
BHS
A
Voip
100.00%
1.4
100.00%
1.3
50.00%
50.00%
0.9
Video Phone
Video
conference
Real Time
Gaming
Streaming
Media
IMS Signalling
20.00%
0.2
20.00%
0.16
10.00%
0.1
5.00%
0.05
20.00%
0.2
15.00%
0.15
10.00%
0.1
5.00%
0.05
30.00%
0.2
20.00%
0.2
10.00%
0.1
5.00%
0.1
15.00%
0.2
15.00%
0.15
5.00%
0.1
5.00%
0.1
40.00%
30.00%
25.00%
20.00%
Web Browsing
100.00%
0.6
100.00%
0.4
40.00%
0.3
30.00%
0.2
File Transfer
20.00%
0.3
20.00%
0.2
20.00%
0.2
10.00%
0.2
Email
P2P file
10.00%
20.00%
0.4
0.2
10.00%
20.00%
0.3
0.15
10.00%
20.00%
0.2
0.1
5.00%
0.1
0.1
TEP
Confidential
5.00%
sharing
User Distribution
Urban
Dense Urban
50%
Suburban
Rural Area
0%
0%
50%
The number of subscribers per eNodeB

number
Capacity Evaluation Results
Domain
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Input
Parameter
Output Result
Output Result
Output Result
Output Result
TEP
600
Default
Value
Parameter
Value
Number of Users/eNB
600
Source of Throughput/User
600
User
Defined
Throughput/User_UL(Mbps)
0.1
0.1
Throughput/User_DL(Mbps)
0.15
0.15
Packet Size(Bytes)
700
700
X2 to S1 Ratio(%)
2.0
2.0
Enable VLAN
YES
YES
Enable IPSEC
NO
YES
Duplex Type
Full-Duplex
Full-Duplex
GTPU Head(Bytes)
12
12
UDP Head(Bytes)
IP Head(Bytes)
20
20
IPSEC Head(Bytes)
70
VLAN Head(Bytes)
MAC Head(Bytes)
18
18
Peak Average Ratio
1.25
1.25
Control to User Ratio(%)
2.0
2.0
OM Throughput(Kbps)
512.0
512.0
IP CLK Throughput(Kbps)
S1-C Interface Peak Throughput(Mbps)
S1-U Interface Peak Throughput(Mbps)
S1 Interface Peak Throughput(Mbps)
X2 Interface Peak Throughput(Mbps)
12.0
2.4494
122.4675
124.9169
2.4983
12.0
Confidential
Traffic Model
Output Result
Total Throughput Required(Mbps)
127.9269
2.5 MBTS Homing Allocation Design

2.5.1
2G BTS Allocation Design
BTS homing and TRX homing are designed according to the network planning design . To balance the
processing capabilities of various BSC modules and improve anti-impact and anti-risk capabilities, allocate
BTSs among modules properly to implement load balancing. That is, distribute BTSs in a continuous manner
between BSCs but distribute BTSs in a discontinuous manner within a BSC and between boards in large
sites.
Design principles:
The number of TRXs needs to meet the designed specifications of GMPS and GEPS
subracks.
The number of TRXs needs to meet the required board processing specification.
The traffic carried by each module and BHCA do not exceed 60% of the designed
specification.
Certain redundant ports and capacity need to be reserved for each Abis interface
board for subsequent small-scale adjustment and expansion.
Plan the BTSs connected to the BSC continuously in the coverage area (unless
transmission conditions do not permit). Avoid discontinuous BTS distribution in different BSCs; otherwise
inter-MSC handovers increase.
signaling traffic.
Allocate the BTSs in the same LAC to the same subrack to reduce inter-module
Allocate the VIP sites (hot-spot areas with heavy traffic) in an area to different Abis
interface boards in a subrack in a discontinuous manner. Overlapping coverage exists between adjacent
cells. Therefore, this allocation mode can minimize the impacts due to out-of-service of partial VIP sites in
the same area.
For an office that is constructed by phase, there may be many site re-homing
requirements. Therefore, during initial site allocation, allocate the sites that have such a re-homing
requirement to several Abis interface boards in a module to reduce the workload during re-homing.
Output of the design
LLD output (LLD based on the LLD template)
BTS name
XXX
2.5.2
BTS configuration
Module No
Board No
S2/2/2
Port No
X
3G NodeB Allocation Design

NodeB deployment in RNC subracks and EGPU slots:
From version RAN 14.1 BSC6910 supports dynamic cell deployment. The service processing
subsystem is automatically allocated by the system when the base station is configured.
NodeB deployment in RNC interface boards:
According to the principle of each subsystem allocate cells balance, the system automatically calculates
the allocation, human intervention is not possible, but pay attention to open the base station dynamic
deployment switch (MML command SET UCELLAUTOHOMING).
For super base station, its not needed that consider the problem of the deployment, because the RNC
each system specifications are greater than the NodeB ability in BSC6910 RAN15.0.
TEP
NodeB and RNC configuration matching principle:

Confidential
Its necessary that the overall capacity of the RNC and the deployed configuration of each NodeB
maximum capacity is match. This capacity is measured by the number of users that supported by the RNC
and NodeB certain traffic model.
The user number supported by the RNC hardware configuration = SUM (the user number supported by
the NodeB hardware configuration)
Output of the design
LLD output (LLD based on the LLD template)
NodeB name NodeB configuration
XXX
SPU
Subsystem
No
Board No
S2/2/2
Port No
Hardware Distribution Design
3.1 Hardware Distribution Principle

Purpose of board layout design:
performance.
Decrease the number of messages forwarded between subracks to improve the BSC
Balance the load between subracks to improve the anti-attack capability.
Reserve certain port redundancy to facilitate site adjustment and expansion.
Deploy logical boards of the same type in a centralized manner to reduce

interleaving with boards of different types.
Deploy electrical interface boards on one side and optical interface boards on the
other side to facilitate cable connection.
Use different boards to provide 2G and 3G services to reduce the impact of software
upgrade and board adjustment on services.
Allocate slots properly to maximize the board processing capability (the switching
capability of the slots on the backplane differs).
Reduce inter-subrack signaling transfer. Ensure that the processing capabilities of

the Abis interface board, A interface board, and embedded packet control unit (PCU) in the same subrack
match each other.
Recommended Layout Configuration
Assign EOMUa switch boards to slot 10 to 13. SCUb boards are assigned to slot 20
and 21, and EGPUa boards for resource management are assigned to slot 8 and 9.
Assign GCUa/GCGa boards to slot 14 and 15.
EGPUa/ESAUa boards can be inserted in other idle slots other than the fixed slots.
The following assignment is recommended:
TEP
Assign ESAUa boards to slot 0 and 1.

Confidential
Preferred slots for EGPUa boards are slot 2 to 7 in MPS subrack; slot 0 to 13 in
EPS subrack.
The following assignment is recommended for GOUc/EXOUa boards:

EXOUa boards can only be assigned to slot 16 to 19 and slot 22 to 25.
Preferred slots for GOUc boards are slot 16 to 19 and slot 22 to 25. When these
slots are inadequate, they can be assigned to slot 26 to 27.
3.2 BSC6910 Board Layout

3.2.1
BSC6910 GSM Board Layout
The following layout is prepared based on NEP tool output (Use the NEP Tool to automatically generate
the board layout figure):
TEP
Confidential
3.2.2
BSC6910 UMTS Board Layout
The following layout is prepared based on NEP tool output (Use the NEP Tool to automatically generate
the board layout figure):
TEP
Confidential
3.3 BSC6910 Power Consumption

BSC6910 GSM Power Consumption = 3844.4W
BSC6910 UMTS Power Consumption = 6155.7W
TEP
Confidential
3.4 BSC6910 Boards Overview

3.4.1
BSC6910 Boards Introduction

BSC Board Introduction
BSC Board
type
Hardware version
Software version
GCUa
General Clock Unit

REV:a
BSC6910V100R015
EGPUa
Evolved General
Processing Unit REV:a
BSC6910V100R015
EOMUa
Evolved Operation and

Maintenance Unit REV:a
BSC6910V100R015
ESAUa
TEP
Evolved Service Aware

Unit REV:a
BSC6910V100R015
Confidential
Board Capacity
Extracts timing signals from the
external synchronization timing
port and from the
synchronization line signals,
processes the timing signals,
and provides the timing signals
and reference clock for the
entire system
Clock precision level: Grade
three
When the EGPUa board is
used to process services on
the GSM BSC control plane
and user plane, it supports:
1000 TRXs
600 cells
600 BTSs
6250 Erlang
3000 PDCHs
2,200,000 busy hour call
attempts (BHCAs), including
PS traffic
A maximum of 150,000 alarms
can be recorded.
Time when the standby OMU
data is synchronized with the
active OMU data1 Second.
Duration of the synchronization
between the active OMU files
and standby OMU filesFive
minutes. The time required for
the synchronization varies
according to the size and
quantity of the files to be
synchronized.
Duration of the switchover
between the active and
standby OMUs:The switchover
finishes in four minutes.
Duration of the OMU restart
caused by an OMU fault. This
duration lasts for about three
minutes.
An ESAUa board collects and
preprocesses the data reported
by NEs. The ESAUa board
then uploads the preprocessed
data to the M2000 and
eCoordinator. The Nastar
collects and analyzes the data
reported by the ESAUa board
on the M2000 side.
SCUb
GE Switching network
and Control Unit REV:b
BSC6910V100R015
GOUc
4-port packet over GE

Optical interface Unit
REV:c
BSC6910V100R015
RNC Board Introduction
RNC Board
type
GCUa
TEP
The ESAUa board performs the

following functions for the
Nastar:
Filters and aggregates raw
data reported by NEs
according to the rule for Nastar
thematic tasks.
Sends data preprocessing
results to the Nastar through
the M2000 for the Nastar to
perform thematic service
analysis.
Number of GSM TRXs
Bandwidth Required (kbit/s)
Number of TRXs < 360
64
360 Number of TRXs 960
708
Number of TRXs > 960
1856
It implements BSC6910 MAC
switching and provides
interconnections between all
modules in a BSC6910.
Provides the maintenance
management function
Supports active/standby
switchovers
Enables inter-subrack
connections
Provides a total switching
capacity of 240 Gbit/s
Distributes clock signals and
RFN signals for the system
Abis TRX: 2048
A CS voice service: 23,040
Erlang
Gb Maximum payload
throughput (at the physical
layer): 2000 Mbit/s
Hardware version
General Clock Unit

REV:a
Software version
Board Capacity
BSC6910V100R015
Extracts timing signals from the

external synchronization timing
port and from the
synchronization line signals,
processes the timing signals,
and provides the timing signals
and reference clock for the
entire systemClock precision
level: Grade three
Confidential
EGPUa
Evolved General
Processing Unit REV:a
BSC6910V100R015
EOMUa
Evolved Operation and

Maintenance Unit REV:a
BSC6910V100R015
ESAUa
TEP
Evolved Service Aware

Unit REV:a
BSC6910V100R015
Confidential
If the EGPUa board is used to

process services on the UMTS
RNC control plane and user
plane, it supports:
2000 Mbit/s traffic (based on
the 64 kbit/s uplink and 384
kbit/s downlink for a single
user)
10,050 Erlang (CS voice
services)
5025 Erlang (CS data services)
1400 cells
700 NodeBs
35,000 online MSs (occupying
DCHs, HSDPAs, or FACHs for
control-plane services)
21,000 online MSs (occupying
DCHs, HSDPAs, or FACHs for
user-plane services)
1,668,000 BHCAs (based on
Huawei Smartphone traffic
model)
A maximum of 150,000 alarms
can be recorded.
Time when the standby OMU
data is synchronized with the
active OMU data1 Second.
Duration of the synchronization
between the active OMU files
and standby OMU filesFive
minutes. The time required for
the synchronization varies
according to the size and
quantity of the files to be
synchronized.
Duration of the switchover
between the active and
standby OMUs:The switchover
finishes in four minutes.
Duration of the OMU restart
caused by an OMU fault. This
duration lasts for about three
minutes.
An ESAUa board collects and
preprocesses the data reported
by NEs. The ESAUa board
then uploads the preprocessed
data to the M2000 and
eCoordinator. The Nastar
collects and analyzes the data
reported by the ESAUa board
on the M2000 side.
The ESAUa board performs the
following functions for the
Nastar:
Filters and aggregates raw
data reported by NEs
according to the rule for Nastar
thematic tasks.
Sends data preprocessing

results to the Nastar through
the M2000 for the Nastar to
perform thematic service
analysis.
Number of GSM TRXs
Bandwidth Required (kbit/s)
Number of TRXs < 360
64
360 Number of TRXs 960
708
Number of TRXs > 960
1856
SCUb
EXOUa
TEP
GE Switching network
and Control Unit REV:b
Evolved 2 10GE Port

Optical Interface Unit
REV:a
BSC6910V100R015
BSC6910V100R015
Confidential
It implements BSC6910 MAC

switching and provides
interconnections between all
modules in a BSC6910.
Provides the maintenance
management function
Supports active/standby
switchovers
Enables inter-subrack
connections
Provides a total switching
capacity of 240 Gbit/s
Distributes clock signals and
RFN signals for the system
Iub
Number of NodeBs:1500
CS Voice Service:75,000
Erlang
CS Data Service:75,000 Erlang
Maximum payload throughput
(uplink):8000 Mbit/s
NOTE:
When the maximum payload
throughput is reached in the
uplink, the downlink payload
throughput is 0 Mbit/s.
(downlink):8000 Mbit/s
NOTE:
downlink, the uplink payload
(both uplink and
downlink):10000 Mbit/s
Iu-CS
CS Voice Service:75,000
Erlang
CS Data Service:37,500 Erlang
Iu-PS
(uplink):9500 Mbit/s
NOTE:

uplink, the downlink payload
(downlink):9500 Mbit/s
NOTE:
downlink, the uplink payload
(both uplink and
downlink):10000 Mbit/s
TEID(Tunnel Endpoint ID)
1000000
3.4.2
BSC6910 Interface Board Layout

Interface
A
Abis over IP
(Ethernet)
Gb
O&M in BSC
Type
Board
IP over GE, Optical
GOUc
4GE, Optical
IP over GE, Optical
GOUc
4GE, Optical
IP over GE, Optical
GOUc
4GE, Optical
IP over FE, Electrical
GOUc Device Panel
TEP
Confidential
EOMUa
Interface of the Board
4FE,Electrical
Port
RX
TX
Function
Optical port, used to transmit
and receive optical signals. TX
refers to the transmitting optical
port, and RX refers to the
receiving optical port.
Item
Abis
A
Gb
TRX
CS voice service
(at the physical layer)
Interface
Type
Specification
2048
23,040 Erlang
2000Mbit/s
Board
Interface of the Board
IuCS/Iur
IP over GE, Optical
EXOUa
210GE, Optical
Iub over IP (Ethernet)
IP over GE, Optical
EXOUa
210GE, Optical
IuPS
IP over GE, Optical
EXOUa
210GE, Optical
IP over FE, Electrical
EOMUa
O&M in RNC
EXOUa Device Panel
TEP
Connector Type
LC/PC
Confidential
4FE, Electrical
Port
RX
TX
Iub
Function
Both TX and RX are optical
ports. TX transmits optical signals
and RX receives optical signals.
Item
Specification (with SCUb configured)
Number of User Datagram Protocols
1,000,000
Number of NodeBs
1500
CS Voice Service
75,000 Erlang
CS Data Service
75,000 Erlang
Maximum payload throughput (uplink)
8000 Mbit/s
Note:When the maximum payload
throughput is reached in the uplink, the
downlink payload throughput is 0 Mbit/s.
Maximum payload throughput (downlink)
TEP
Connector Type
LC/PC
Confidential
8000 Mbit/s
Maximum payload throughput (both uplink

and downlink)
10000 Mbit/s
Maximum uplink payload throughput

(uplink:downlink = 1:4)
2000 Mbit/s
Maximum downlink payload throughput

8000 Mbit/s
Maximum uplink+downlink payload

throughput (uplink:downlink = 1:4)
10000 Mbit/s
CS Voice Service
CS Data Service
75,000 Erlang
37,500 Erlang
Maximum payload throughput (uplink)
9500 Mbit/s
Maximum payload throughput (downlink)
9500 Mbit/s
Maximum payload throughput (both uplink

and downlink)
10000 Mbit/s
Maximum uplink payload throughput

2000 Mbit/s
Maximum downlink payload throughput

8000 Mbit/s
Maximum uplink+downlink payload

throughput (uplink:downlink = 1:4)
10000 Mbit/s
TEID(Tunnel Endpoint ID)
1000000
Iu-CS
Iu-PS
3.5 eNodeB Hardware Introduction

3.5.1
BBU Slot Design
eNodeB recommended slot configuration rule
TEP
Confidential
Table 1.1.1.I.1.1.1.1 Board configuration principles

Boa
rd
Mandato
ry/Optional
Maxim
um
Quantity
LMPT/
UMPT
FAN
Mandatory
Mandatory
UPEU
Mandatory
UEIU
LBBP
Optional
Mandatory
1
6
UTRP
Optional
USCU
Optional
Slot
Slot 6 or
slot 7
Slot 16
Slot 18 or
slot19
Slot 18
Slot 0, slot
1, slot 2,
slot 3, slot 4
or slot 5
Slot 4 or
slot 5
Slot 0, slot
1, slot 4 or
slot 5
Configuration Principle
Slot 7 is preferentially used for

one LMPT or UMPT.
This board can be configured
only in slot 16
Slot 19 is preferentially used for a
single UPEU.
The following slots for configuring
an LBBP are arranged in descending
order of priority: slot 3 > slot 1 > slot 2
> slot 0 > slot 4 > slot 5.
a UTPR are arranged in descending
order of priority: slot 4 > slot 6.
a USCU with one satellite card are
arranged in descending order of
priority: slot 5 > slot 4 > slot 1 > slot 0.
The following slot combinations
for configuring a USCU with two
satellite cards are arranged in
descending order of priority: slots 5
and 4 > slots 1 and 0.
The UCIU, UTRP, and USCU are configured in descending order of priority.
Target BBU Slot Design as below:
FAN
TEP
Reserved for GU
Reserved for GU
LBBPd2
Reserved for GU
Confidential
Reserved for GU
UMPTb1
UPEU
UPEU
3.5.2
BBU Boards Overview

MBTS Board type
UMPT
WBBP
WBBP
LBBP
UBRI
3.5.3
Hardwar
e version
REV:b1
REV:f1
REV:f3
REV:d2
REV: b
Software version
Board Capacity
BTS3900V100R008
Supported Mode:GSM singlemode/UMTS single-mode/LTE FDD

only/LTE TDD only/Co-MPT
multimode including any mode
Transmission Mode:FE/GE over
electrical ports or optical ports
Port Quantity1*FE/GE electrical
ports and 1*FE/GE optical ports
Maximum Number of Supported
Carriers: 72
Maximum RRC_CONNECTED UEs:
10800
BTS3900V100R008
Number of Cells:6
Number of UL CEs:192
Number of DL CEs256
Number of HSDPA Codes6*15
Number of HSDPA UEs144
Number of HSUPA UEs144
BTS3900V100R008
Number of Cells: 6
Number of UL CEs: 256
Number of DL CEs384
Number of HSDPA Codes6*15
Number of HSDPA UEs256
Number of HSUPA UEs256
BTS3900V100R008
Number of Cells3
Maximum RRC_Connected Users
per Cell Bandwidth
1.4 MHz504
3 MHz1080
5 MHz1800
10 MHz3600
15 MHz3600
20 MHz3600
Antenna Configuration Support
3x20 MHz 1T1R
3x20 MHz 1T2R
3x20 MHz 2T2R
3x20 MHz 4T4R
BTS3900V100R008
Quantity of CPRI Ports6

CPRI Port Rate (Gbit/s)1.25, 2.5,
4.9, 6.144, or 9.8
Support Topology TypeStar,
chain, and ring topologies
Board Introduction
UMPT
The UMPT, which is the universal main processing and transmission unit of BBU3900, provides
functions such as signaling processing and resource management for other boards.
TEP
Confidential
The UMPT boards UMPTa2, UMPTa6, and UMPTb1 are available on the LTE network. The board type is
marked in the lower left corner of each board.
A UMPT has the following ports:
One FE/GE optical port and one FE/GE electrical port: used to transmit service data
and signaling over the Ethernet
Four E1/T1 ports: used to input and output E1/T1 signals
One GPS port: used to forward RF signals received from the antenna to a satellite
One USB port: used to upgrade eNodeB software
card
A UMPT has the following indicators for different working modes:
R0: indicates GSM or CDMA.
R1: indicates UMTS, TD-SCDMA, or WiMAX.
R2: indicates LTE.
In addition, indicators L01 and L23 on the panel help users determine whether the E1/T1 links work
properly. L01 indicates the status of link 0 and link 1 and L23 indicates that of link 2 and link 3.
Figure 1.1.1.I.1.1.1, Figure 1.1.1.I.1.1.2, and Figure 1.1.1.I.1.1.3 show the UMPTa2, UMPTa6, and
UMPTb1 panels respectively.
Figure 1.1.1.I.1.1.1 UMPTa2 panel
Figure 1.1.1.I.1.1.2 UMPTa6 panel
Figure 1.1.1.I.1.1.3 UMPTb1 panel
LBBP
The LTE baseband processing unit (LBBP) of BBU3900 provides baseband processing of the uplink and
downlink data. The interface between the LBBP and the radio frequency module is the CPRI interface. The
LBBPs can be inserted into slots 0 to 5. A maximum of three LBBPs are supported. Slot 3 is recommended
for only one LBBP, slots 2 and 3 for two LBBPs, and slots 1 to 3 for three LBBPs.
The LBBPd is divided into LBBPd1 and LBBPd2 with different processing capabilities.
Figure 1.1.1.I.1.1.1 and Figure 1.1.1.I.1.1.2 show the LBBPc and LBBPd panels respectively.
Figure 1.1.1.I.1.1.1 LBBPc panel
TEP
Confidential
Figure 1.1.1.I.1.1.2 LBBPd panel
Table 1.1.1.I.1.1.2.1 lists the specifications of the LBBP for use in the FDD LTE scenario.
Table 1.1.1.I.1.1.2.1 LBBP specifications
Board
LBBPc
LBBPd1
LBBPd2
Support
Cells
3
Supported Cell
Bandwidth
1.4 MHz/3 MHz/5
MHz/10 MHz/15
MHz/20 MHz
1.4 MHz/3 MHz/5
MHz/10 MHz/15
MHz/20 MHz
1.4 MHz/3 MHz/5
MHz/10 MHz/15
MHz/20 MHz
Supported
Antenna
Configuration
Maximum Throughput
3 x 10 MHz 4T4R
3 x 20 MHz 2T2R
1 x 20 MHz 4T4R
3 x 20 MHz 2T2R
3 x 20 MHz 2T2R
3 x 20 MHz 4T4R
DL: 300 Mbit/s
UL: 100 Mbit/s
DL: 450 Mbit/s
UL: 225 Mbit/s
DL: 600 Mbit/s
UL: 225 Mbit/s
UPEU
The universal power and environment interface unit (UPEU) falls into four types, UPEUa, UPEUb,
UPEUc, and UPEUd. Their functions are as follows:
The UPEUa, UPEUc, and UPEUd boards convert 48 V DC input power into +12 V
The UPEUb converts +24 V DC input power into +12 V DC.
DC.
Each UPEU provides two ports for RS485 signals and eight ports for Boolean
signals. Boolean signals are input through dry contacts or open collectors (OCs).
Each UPEU supports hot backup. If you remove the active UPEU from the two
UPEU boards that properly work in active/standby mode, the standby UPEU immediately starts supplying
power with the eNodeB free from any impact.
Table 1.1.1.I.1.1.1.1 describes the UPEU specifications.
Table 1.1.1.I.1.1.1.1 UPEU specifications
Board
UPEUa
UPEUc
UPEUd
TEP
Output Power
One UPEUa has an output
power of 300 W.
One UPEUc has an output
power of 360 W and two have a
total output power of 650 W.
One UPEUd has an output
power of 650 W.
Confidential
Backup Function
1+1 backup
1+1 backup
1+1 backup
The UPEUa and UPEUd boards have silk-screens 48 V and +24 V on panels
indicating their board types respectively. UPEUa, UPEUc, and UPEUd are distinguished
by the labels UPEUc and UPEUd on the UPEUc and UPEUd panels respectively.
If two UPEUc boards are installed for 1+1 backup, both boards are functioning. Output
power provided by two boards is described in the table. If two UPEUa boards are installed
for 1+1 backup, only one of them is functioning. Output power provided by two UPEUa
boards is not described in the table.
RRU3936
RRU3936 Introduction
This section describes the exterior and dimensions of an RRU.
Also the ports on the RRU panels: an RRU has a bottom panel, cabling cavity panel, and indicator panel
RRU exterior
Figure below shows RRU dimensions.

RRU dimensions
TEP
Confidential
Ports on the RRU panels
RRU3936 modules are remote radio units and can work in different modes with different configurations
and the software-defined radio (SDR) technique.
Supported Modes and Frequency Bands.The following table lists the modes and frequency bands
supported by an RRU3936.
Type
RRU393
6
Frequency
Band (MHz)
Receive
Frequency
Band (MHz)
Transmit
Frequency
Band (MHz)
Carrier Working
Frequency
bandwidth
900 EGSM
880 to 915
925 to 960
35MHz
900 PGSM
890 to 915
935 to 960
25MHz
1800
1710 to 1785
1805 to 1880
75MHz
Output power for the RRU3936 (GL MSR, 1800 MHz)
TEP
Confidential
Mode
GSM, UMTS, and
GU
GSM, UMTS, LTE,
GU, and GL
Mode
GSM
+ LTE
Total
Number
of GSM
Carriers
Total
Number
of LTE
Carriers
Output
Power
per
GSM
Carrier
(W)
Output
Power
per LTE
Carrier
(W)
Bandwidth
of LTE Carrier
(MHz)
40
40
1.4,3,5,10,15,20
20
40
1.4,3,5,10,15,20
30
20
1.4,3,5,10,15,20
20
20
1.4,3,5,10,15,20
12
20
1.4,3,5,10,15,20
10
20
1.4,3,5,10,15
10
10
1.4,3,5,10,15
10
1.4,3,5,10,15
RRU3268
RRU3268 Introduction
This section describes the exterior and dimensions of an RRU.
Also the ports on the RRU panels: an RRU has a bottom panel, cabling cavity panel, and indicator panel
RRU exterior:
TEP
Confidential
RRU dimensions:
Ports on the RRU panels:
RRU3268 Technical Specification

An RRU3268, which is a remote radio unit for LTE, supports two carriers.
The following table lists the modes and frequency bands supported by an RRU3268.
Receive
Transmit
Carrier Working
Frequency
Type
Mode
Frequency
Frequency
Frequency
Band (MHz)
Band (MHz)
Band (MHz)
bandwidth
RRU326
LTE
2600 (band 7)
2500 to 2570
2620 to 2690
70MHz
TEP
Confidential
700 (band 28)
800
Band A: 703 to
743
Band B: 718 to
748
791 to 821
Band A: 758 to
798
Band B: 773 to
803
832 to 862
40MHz
30MHz
30MHz
RF Specfication:
Type
RRU326
8
Transmit
and
Receive
Channel
s
2T2R
Capacity
Receiver Sensitivity (dBm)

1T1R
Two carriers. The bandwidth per carrier is 5,

10, 15, or 20 MHz.
In band 7 of the 2600 MHz frequency

band, the total bandwidth between the
maximum frequency and the minimum
frequency of two carriers on the
RRU3268 cannot exceed 50 MHz.
In band 28 of the 700 MHz frequency

band, the total bandwidth between the
maximum frequency and the minimum
frequency of two carriers on the
RRU3268 cannot exceed 25 MHz.
In the 800 MHz frequency band, the

total bandwidth between the maximum
frequency and the minimum frequency of
two carriers on the RRU3268 cannot
exceed 30 MHz.
2600
MHz:
-106.5
700
MHz:
-106.0
800MHz:
-106.4
1T2R
2600
MHz:
-109.3
700
MHz:
-108.8
800MH
z: -109.2
Mode
Total Number of Carriers
Output Power per Carrier (W)
LTE
1 (MIMO)
2x40
2 (MIMO)
2x20
2 (MIMO)
carrier 1: 2 x 13
carrier 2: 2 x 27
carrier 1: 2 x 10
carrier 2: 2 x 30
carrier 1: 2 x 8
carrier 2: 2 x 32
carrier 1: 2 x 16
carrier 2: 2 x 24
carrier 1: 2 x 17
carrier 2: 2 x 23
2 (MIMO)
2 (MIMO)
2 (MIMO)
2 (MIMO)
TEP
Confidential
3.5.4
BBU and RRU Layout
3.5.4.1
Installation Scenarios
For indoor sites: 1BBU+2DCDU-12B+12RRU
For outdoor sites: 1TMC11H+12RRU
3.5.4.2
CPRI cable Connection
Maximum Configuration: G666+D888+U444+L111

Hardware Configuration: DBS3900+3*G9.RRU3929+6*G18.RRU3936+3*RRU3826
Option 1:
Option 2(Huawei recommended):
TEP
Confidential
Note:
1. The speed of CPRI cable is 2.5Gbps and the actual CPRI cable connection need to be adjusted
during detailed site survey and LLD.
2. The cost behind the option 1 and option 2 is the same.
3. The single faulty in the Option 1 will cause both 2G and 3G out of service at the same time. So the
reliability of Option 2 is much higher than Option1. Huawei recommended the Option 2.
3.6 2G System Signal Flow

3.6.1
User Plane Signaling Flow
3.6.1.1 GSM CS Signaling Flow

After a CS call is established in the GSM network, the MS and the network communicate with each other
through the CS signaling flow. The method of processing the GSM CS signaling flow varies according to the
transmission mode adopted on the Abis and A interfaces and the configuration mode of the BSC6910
subracks.
The figure below shows the CS signaling flow in Abis over IP and A over IP transmission mode.
TEP
Confidential
GSM CS signaling flow
As shown in the figure above, the CS signaling flow on the uplink is as follows:
1.
2.
The uplink CS signalings are sent from the BTS to the Abis interface board in the MPS/EPS.
The Abis interface board encapsulates the CS signalings in PTRAU frames, which are then
transmitted to the EGPUa board through the SCUb board.
3.
The EGPUa board converts PTRAU frames into RTP frames, reorders RTP frames, and eliminates
jitter.
4.
The SCUb board transmits CS signalings from the EGPUa board to the A interface board, and then
the A interface board transmits the signalings to the MGW.
The downlink flow is the reverse of the uplink flow.
3.6.1.2 GSM PS Signaling Flow
After a PS connection is established in the GSM network, the MS and the network communicate with
each other through the PS signaling flow. The GSM PS signaling flow varies according to the transmission
mode adopted on the Abis interface.
The figure shows the PS signaling flow in Abis over IP transmission mode.
GSM PS signaling flow
As shown in figure above, the PS signaling flow on the uplink is as follows:

1.
The packet data is sent from the BTS to the Abis interface board in the MPS/EPS.
2.
The SCUb board transmits the packet data to the EGPUa board.
3.
The EGPUa board converts the frame format and then transmits the data to the Gb interface board
through the SCUb board.
4.
The Gb interface board processes the packet data according to the IP protocol and then transmits it
to the SGSN over the Gb interface.
TEP
Confidential
3.6.2
Control Plane Signaling Flow
3.6.2.1 Signaling Flow on the A Interface

The signaling flow on the A interface refers to the signaling messages transmitted between the BSC6910
and the MGW/MSC Server(MSS).
The figure shows the signaling flow on the A interface in A over IP mode.
Signaling flow on the A interface in A over IP mode
As shown in the figure above, the uplink signaling flow on the A interface is as follows:
1.
In the MPS/EPS, the EGPUa board processes the signaling according to the BSSAP, SCCP, SCTP,
and M3UA protocols. Then, the signaling is transmitted to the A interface board through the SCUb board.
2.
The A interface board processes the signaling according to the IP protocol. Then, the signaling is
transmitted through the MGW to the MSS server.
3.6.2.2 Signaling Flow on the Abis Interface
The signaling flow on the Abis interface refers to the signaling messages transmitted between the
BSC6910 and the base station. The signaling flow varies according to the transmission mode adopted on the
Abis interface.
The figure shows the signaling flow on the Abis interface in Abis over IP mode.
Signaling flow on the Abis interface in Abis over IP mode
As shown in the figure above, the uplink signaling flow on the Abis interface is as follows:
1.
The signaling from the BTS is transmitted to the Abis interface board in the MPS/EPS over the
Abis interface.
2.
The Abis interface board processes the signaling according to the MAC, IP, and UDP protocols.
Then, the signaling is transmitted to the signaling processing board through the SCUb board.
TEP
Confidential
3.6.2.3 Signaling Flow on the Gb Interface

The signaling flow on the Gb interface refers to the signaling messages transmitted between the
BSC6910 and the SGSN.
The figure shows the signaling flow on the Gb interface.
Signaling flow on the Gb interface
As shown in the figure above, the uplink signaling flow on the Gb interface is as follows:
1.
In the MPS/EPS, the signaling processing board processes the signaling according to the NS and
BSSGP protocols. Then, the signaling is transmitted to the Gb interface board through the SCUb board.
2.
The Gb interface board processes the signaling according to the IP protocol. Then, the signaling is
transmitted to the SGSN over the Gb interface.
3.7 3G System Signal Flow

3.7.1
User Plane Signaling Flow
3.7.1.1 Intra-BSC6910 Data Flow Between Iub and Iu-CS/Iu-PS

If the BSC6910 that receives the data from the Iub interface sends the data directly to the MSC/SGSN
over the Iu-CS/Iu-PS interface, the data flow is called an intra-BSC6910 data flow between Iub and Iu-CS/IuPS. Following figure shows the intra-BSC6910 data flow between Iub and Iu-CS/Iu-PS.
TEP
Confidential
Intra-BSC6910 data flow between Iub and Iu-CS/Iu-PS
NOTE:
All the communications between the boards are switched by the SCUb boards.
The signal flow on the uplink is as follows:

1.
The NodeB processes the data and then sends it to the Iub interface board of BSC6910 over the Iub
interface.
2.
The Iub interface board processes the data and sends it to the EGPUa board in the same subrack.
See signal flow 1 in the figure
If the EGPUa board that processes the data and the Iub interface board that receives the data are
located in different subracks, the data is switched by the MPS. The MPS then sends the data to the target
EGPUa board. See signal flow 2 in the figure
3.
The EGPUa board processes the data according to the FP, MDC, MAC, RLC, and Iu UP or
PDCP/GTP-U protocols, separates the CS/PS user-plane data from other data, and then sends the data to
the Iu-CS/Iu-PS interface board.
4.
The Iu-CS/Iu-PS interface board processes the data and then sends it to the MSC/SGSN.
3.7.1.2 Inter-BSC6910 Data Flow Between Iub and Iu-CS/Iu-PS
If the BSC6910 that receives the data from the Iub interface sends the data to the MSC/SGSN through
another BSC6910, the data flow is called an inter-BSC6910 data flow between Iub and Iu-CS/Iu-PS.
Following figure shows the data flow between BSC6910-1 and BSC6910-2.
TEP
Confidential
Inter-BSC6910 data flow between Iub and Iu-CS/Iu-PS
NOTE:
The signal flow on the uplink is as follows:

1.
The NodeB processes the data and then sends it to the Iub interface board of BSC6910-1 over the
Iub interface.
2.
The Iub interface board and EGPUa board of BSC6910-1 process the data and then send it to the
Iur interface board of BSC6910-1.
3.
The Iur interface board of BSC6910-1 processes the data and then sends it to the Iur interface board
of BSC6910-2 over the Iur interface between BSC6910-1 and BSC6910-2.
4.
The Iur interface board of BSC6910-2 processes the data and then sends it to the EGUPa board.
5.
The EGUPa board processes the data, separates the CS/PS user-plane data from other data, and
then sends the data to the Iu-CS/Iu-PS interface board.
6.
The Iu-CS/Iu-PS interface board processes the data and then sends it to the MSC/SGSN.
3.7.2
Control Plane Signaling Flow
3.7.2.1 Signaling Flow on the Iub Interface

The signaling flow on the Iub interface refers to the control-plane messages transmitted between the
BSC6910 and the NodeB.
Following figure shows the signaling flow on the Iub interface.
TEP
Confidential
Signaling flow on the Iub interface
NOTE:
The signaling flow on the uplink is as follows:

1.
The NodeB transmits the control-plane messages to the Iub interface board of the BSC6910 over the
Iub interface.
2.
The Iub interface board processes the messages and then sends them to the EGPUa board where
the messages are terminated. See signal flow 1 in the figure
If the EGPUa board that processes the messages and the Iub interface board that receives the
messages are located in different subracks, the messages travel to the MPS for switching. The MPS then
sends the messages to the target EGPUa board. See signal flow 2 in the figure.
3.7.2.2 Signaling Flow on the Iu/Iur Interface
The signaling flow on the Iu interface refers to the control-plane messages transmitted between the
BSC6910 and the MSC/SGSN, and the signaling flow on the Iur interface refers to the control-plane
messages transmitted between one BSC6910 and another BSC6910.
Following figure shows the signaling flow on the Iu/Iur interface. See signal flows 1, 2, and 3.
Signaling flow on the Iu/Iur interface
NOTE:
TEP
Confidential
The signaling flow on the downlink is as follows:

1.
The MSC or SGSN sends the control-plane messages to the Iu interface board of the BSC6910 over
the Iu interface, or another BSC6910 sends the control-plane messages to the Iur interface board of the local
BSC6910 over the Iur interface.
2.
The Iu/Iur interface board processes the messages and then sends them to the EGPUa board in the
same subrack for processing. See signal flow 1 in the figure.
If the EGPUa board in the same subrack as the Iu/Iur interface board cannot process the messages, the
messages are switched by the MPS to the EGPUa board in another subrack. See signal flow 2 in the figure.
After being processed by the Iu/Iur interface board, the messages are directly switched by the MPS to
the EGPUa board in another subrack. See signal flow 3 in the figure.
The uplink flow is the reverse of the downlink flow.
Naming Design
Huawei recommended the NE name was consist of letter and number, and NE name cannot contain
special characters such as @, #, !, %, ^, &, *, .[], /\, and . In addition, the names must be unique in the
entire network irrespective of whether the original naming rule or the naming rule recommended by Huawei.
( Note: All the sites naming will be finalized after detailed site survey and LLD by ethio telecom)
4.1
BSC/RNC Naming
Huawei recommended the NE name was consistent of letter and number, and NE name cannot contain
special characters such as @, #, , %, ^, &, *, [], and . In addition, the names must be unique in the entire
network irrespective of whether the original naming rule or the naming rule recommended by Huawei is used.
The new naming combination that will be used as <ABC><D><H><xx>
A & B &C represents the short name of geographical location where BSC/RNC installed
TEP
Confidential
C represents the Node Type value range=R or B; R for RNC and B for BSC
Hrepresents the code for Huawei equipment
XXis a two digits number that indicates the numerical sequence for nodes in this area, value range from 0
to 99.
Table 1.1.1.1.1.1.1.1 BSC Naming
BSC Name
AAZBH01
SRRH02
Explanation
1st Huawei BSC in
Addis Ababa region
2nd Huawei RNC in
SR region
BSC EOMUa Naming.

For BSC6910, each EOMUa card will occupy 2 slots. The active and standby EOMUa will be installed in
slot10~13.
The following naming rules recommended by Huawei: EOMUa_Slot No._ BSC
Name
Table 1.1.1.1.1.1.1.2 EOMUa Naming
OMUa
SR/Slot
0/10
0/12
BAM Name
EOMUa_S10_ AAZBH01
EOMUa_S12_ AAZBH01
EOMUa name should be the same with the name of SQL Server installed
BTS Naming
Generally, the number of BTSs is large. Therefore, to simplify the BTS names. Name BTSs as follows:
<A><B>
A stands for the name of area where the BTS is located, or the name of the property company that
manages the area where the BTS is located.
B stands for the BTS ID. For example, BTS2 located in Parkview named Parkview2.
4.2 eNodeB Naming Design

Preferably an eNodeB name should reflect the geographical location or area of the eNodeB. Therefore,
the recommended eNodeB naming rule is: eNodeB geographical area + site type + '_' + serial number.
Examples as below:
TEP
Confidential
If the eNodeB geographical area name can be abbreviated, the abbreviated name is recommended. For
example, Shanghai Jinqiao is abbreviated as JQ.
If all the eNodeBs of a delivery project are of the same type, there is no need to specify the site type.
If there is only one eNodeB in the area, there is no need to specify the serial number. If there are
multiple eNodeBs, it is recommended that the serial number begin from 1.
Discuss with the customer about the information that the customer wants to contain in the eNodeB
name. Huawei eNodeB supports a maximum of 64 characters. The character string cannot be all blank or
contain any of the following characters: ? : , & * / \ | '' ;= + two or more blanks, or two or more percent signs
(%).
The eNodeB naming rule must reflect the information that the customer wants to represent and should
ensure unique names in the entire network.
The EPCs of Nokia-Siemens and Alcatel-Lucent do not support the underline in the eNodeB name.
Keep this rule in mind if Huawei eNodeBs need to connect to Nokia-Siemens or Alcatel-Lucent EPCs. If this
rule is violated, the S1 interface will be faulty. Huawei EPC has no such rule.
4.3 Cell Naming Design

For easy management and memory of cell names, it is recommended that the cell names be planned on
the basis of eNodeB names. The recommended cell naming rule is: eNodeB name + '_' + Cell + serial
number. Examples as below:
Determine where the serial number begins from 1. If multiple frequencies are used by the customer
network, the serial number can be planned by the following rule:
First frequency: serial number 1 to 5; second frequency: serial number 6 to 10.
Discuss with the customer about the information that the customer wants to contain in the cell name.
Huawei eNodeB supports a maximum of 99 characters in a cell name. The character string cannot be all
blank or contain any of the following characters: ',', ';', '=', '"', ''', '<', '>', '!', '?', '\', two or more blanks, two or
more %.
The cell naming rule must reflect the information that the customer wants to represent and should
ensure unique names in the entire network.
TEP
Confidential
O&M Network Design
5.1 RAN O&M Network Topology
In the OM system, the M2000 provides Element Management System (EMS) functions. Through
the flexible northbound interface, the M2000 is connected to the Network Management System
(NMS).For the southbound interface, it will connect to BSC/RNC and Single RAN BTS.
M2000 ATAE cluster system Introduction
The M2000 provides various OM solutions for telecom operators to meet the requirements of
network deployment, network monitoring, network adjustment, and service management. Ethio telecom
selects Huawei ATAE cluster M2000 system to deploy as the NMS system.
The M2000 ATAE cluster system is composed of one ATAE cluster systems that are located in core
switch room.
TEP
Confidential
5.2 M2000 Design

The M2000 server supports multiple hardware platforms. This section describes the ATAE cluster
system.
The ATAE provides a complete service platform solution, including dense service processing
boards, storage devices, USM, and network devices.
The ATAE uses the modularization technology to separate resources, such as computing,
input/output (I/O) ports, and storage, from each other, and to separate management and services,
thereby ensuring the high availability of the system. The ATAE system integrates multiple techniques
concerning with the server, storage, network switching and connection, and heterogeneous intelligent
management. The high performance enables the ATAE system to meet the future requirement for
service development. The ATAE supports the existing devices and meanwhile is highly extensible. It is
ideal for extending the applications.
The ATAE functions as a telecommunications server of high availability, high reliability, and high
performance, and provides an open, standard, and universal service processing platform. The ATAE is
intended for the following applications: server applications, powerful processing capability, and powerful
backboard switching capability.
The hardware of the ATAE cluster system comprises the cabinet, ATAE subracks, boards, and disk
arrays, as shown in figure below:
Specifications of the DC cabinet of the ATAE
TEP
Confidential
Item
Cabinet type
Dimensions
Weight
Load bearing of the floor of
the equipment room
Voltage
Current
Number of power supply
channels
Voltage range
Value
N68E-22 cabinet
2,200 mm (height) x 600 mm (width) x 800 mm
(depth)
392.3 kg (full configuration)
> 818 g/m2
48 V to 60 V DC
63 A to 110 A
3+3
72 V to 36V DC
An ATAE subrack consists of components with different functions. Boards in the subrack
communicate with one another through the backplane to function as an independent work unit.
Appearance of the ATAE subrack shown as below:
TEP
Confidential
5.2.1
M2000 Software Structure and Interface
Huawei NMS solution: iManager M2000 supports the centralized O&M of CS, PS core, BSS,
UTRAN and GERAN system, through OM network. Huawei has centralized OMC solution for
GSM&UMTS based on unified platform regarding of network construction, management, network
planning, performance evaluation and trouble shooting, etc.
As shown in following figure, the M2000 software is classified into the following types:
M2000 server software
M2000 client software
NE mediation software
NE mediation software varies according to the NE version. Through the adaptation of the NE
mediation software, the M2000 connects to the NE of the corresponding version.
TEP
Confidential
To interconnect with external systems and software, the M2000 provides the following interfaces:
CORBA interface
The CORBA interface is based on CORBA interface specifications and is in compliance with 3GPP
R6 specifications. Through the CORBA interface, the NMS manages M2000 alarms, sets performance
measurement tasks, queries M2000 configuration data, and queries and delivers configuration
parameters in batches.
CORBA security interface
Through the CORBA security interface, the NMS manages M2000 users and user rights, such as
creating users and maintaining user information.
File interface
The M2000 saves alarm data, performance data, configuration data, inventory data, and LTE
tracing data as files. Through the file interface, the NMS obtains and processes these files.
The NMS can use the configuration file interface to obtain configuration data from the M2000. In
addition, after the CME is installed, the configuration file interface can be used to integrate the data
planning tools of telecom operators into the M2000. In that way,data planning, modification, and
activation are automatically performed through the configuration file interface. The configuration file
interface is applicable to OM scenarios, such as site creation, site relocation, network parameter
optimization, and the optimization of neighboring cell relationships.
Alarm streaming interface
The M2000 forwards NE alarms to the NMS in the form of character stream in real time.The NMS
can actively obtain the list of active alarms from the M2000.
TEP
SNMP interface
Confidential
Through the SNMP alarm interface, the M2000 forwards alarms to the NMS for handling in real
time. The SNMP interface supports the SNMPv1, SNMPv2, and SNMPv3 protocols.
XML interface
Complying with the TMF MTOSI 2.0 series standards, the XML NBI enables the M2000 to provide
unified alarm, performance, inventory, service provisioning, diagnostic test, and protection group
management on transport and IP equipment for OSSs.
MML transparent transmission interface
The MML transparent transmission interface serves as a proxy for transferring MML commands
between the NMS and NEs. With this interface, the NMS can operate and maintain the related NEs
using MML commands.
Syslog interface
The M2000 forwards operating system logs, M2000 logs, and NE logs using the Syslogprotocol.
LDAP user management interface
This interface complies with LDAP. Through this interface, the security management system
provided by a third party can create, modify, delete, and query Huawei OSS systems accounts.
LDAP user authentication interface
This interface supports the account authentication based on LDAP as well as remote authentication
of user names and passwords.
RADIUS user authentication interface
This interface supports the account authentication based on RADIUS as well as remote
authentication of user names and passwords.
Northbound line test interface
The line test system connects to the NEs managed by the M2000 server through the northbound
interfaces for line test. In this way, the line test system works with the NEs to automatically handle and
manage subscriber complaints, conduct test, and rectifyfaults.
TL1 northbound interface
The TL1 northbound interface of the M2000 is used to interconnect the EMS with the OSS. By
using the TL1 northbound interface, the OSS or NMS can provide services and perform OM operations
for integrated access devices (IADs), multimedia terminals, voice subscribers, basic rate access (BRA)
subscribers, primary rate adaptation (PRA) subscribers, and multimedia subscribers. In addition, the
OSS or NMS manages NGN resources and services of the SHLR, AGCF and SoftX3000 by using the
TL1 northbound interface. NEs report notification messages to the OSS or NMS by using the TL1
northbound interface of the M2000.
Radio access networks (RANs) are divided into three layers: NE layer (NEL), element
management layer (EML), and network management layer (NML). Accordingly, SingleRAN
configuration management has three layers: NE configuration, subnet configuration management, and
network configuration management.
NE configuration
TEP
Confidential
Huawei provides various clients that support man-machine language (MML) interfaces, including
the web-based LMT (Web LMT) and MML command-line interface integrated with the M2000. Such
clients allow you to run MML scripts to fine-tune NE configuration parameters. You can also modify NE
configuration parameters on the Configuration Management Express (CME) through the southbound
interface.
Subnet configuration management

Huawei provides the CME, a professional configuration solution used to perform EMS-layer
configuration management. The CME helps you centrally manage a SingleRAN network. The CME
provides scenario-based templates and foolproof wizards, which allow you to efficiently migrate base
stations, adjust networks, and check for consistency between parameter settings. The CME is
recommended for configuration operations rather than Web LMT.
Network configuration management

NMS-layer configuration management is a configuration solution for the entire network. The
northbound interface allows EMSs from different vendors to be connected to the telecom operator's
NMS. Huawei CME is connected to the NMS through the northbound interface. The telecom operator
usually has a comprehensive evaluation system in the NMS for parameter planning. After the planning
system determines the parameters to be optimized, you can send the modified parameter information to
the CME through the northbound interface. The CME then modifies the parameters for NEs. This
greatly improves end-to-end O&M efficiency and reduces the operating expense (OPEX).
Following shows the configuration management structure.
Considering different departments and network management for the radio and CN, we suggest provide
separated NMS for radio and CN: one set of NMS for GSM/UMTS and LTE in the future; another NMS
for all CN equipments (MSS, MGW, SGSN, GGSN, HLR, STP, etc)
TEP
Confidential
5.2.2
M2000 Dimension
Huawei choose M2000 ATAE cluster system as network management system, the system will be
located in 1 ATAE Cabinet.
M2000 capacity defined by the Equivalent NEs numbers, the mapping and calculation please refer
to the following tables:
Report Period
30/60 Minutes
15 Minutes
NE Type
NE Version
Unit
WRAN
GBSS
eRAN
WRAN
GBSS
eRAN
RAN 15.0
GBSS 15.0
eRAN6.0
RAN 15.0
GBSS 15.0
eRAN6.0
1 Cell
1 TRX
1 Cell
1 Cell
1 TRX
1 Cell
Equivalent NE Number Mapping

Measure KPI
Measure Full
Counter Set
Counter Set
1/50
1/35
1/125
1/75
1/60
1/42
1/30
1/21
1/75
1/45
1/36
1/25.2
For GSM/UMTS/LTE network elements in AA region, the required NMS configuration is as following
figure:
Number of equivalent NEs Dimension in M2000
Equivalent NEswith 100%
NE Type
Network Scale
Full Counter Measurement
GSM
21312 TRXs
285
UMTS
6708 UMTS Cells
192
LTE
987 LTE Cells
24
Total
501
Huawei suggest that M2000 capacity configured as 800 Equivalent NEs and this NMS system can
manage all GSM/UMTS and LTE radio network in the future by expanding the software configuration.
5.3 BSC6910 OMU Design

5.3.1
OMU Port Design
The two Ethernet adapters ETH0 and the ETH1 on the OMU board for the external network are
connected to the OM terminal through the networking equipment. The networking equipment refers to the
HUB, the LAN switch, or router.
TEP
Confidential
Figure 1.1.1.1.1.1.1 The networking diagram of the OMU
Figure 1.1.1.1.1.1.2 The OMU external network connection
5.3.2
2G O&M Bandwidth Requirements
The O&M bandwidth requirement is dependent on the number of BTSs as follows.

BTS Quantity
100
200
400
600
800
TEP
Confidential
OM Bandwidth
Requirement(kbit/s)
448
640
1024
1216
1536
1000
5.3.3
1792
3G O&M Bandwidth Requirements
The O&M bandwidth requirement is dependent on the number of NodeBs as follows.

NodeB Quantity &
CELL Quantity
NodeB=100&Cell=300
NodeB=200&Cell=600
NodeB=400&Cell=1200
NodeB=600&Cell=1800
5.3.4
OM Bandwidth
Requirement
4544kbit/s
5120kbit/s
6272kbit/s
7124kbit/s
BSC/RNC OMU IP Plan and configuration
IP addresses of the BAM consists of the fixed IP addresses of internal and external networks, virtual IP
addresses of internal and external networks, and commissioning IP addresses. If the BSC is configured with
two OMUa boards, that is, the BSC is configured with the active and standby BAMs; the BAM IP addresses
also include the backup channel IP addresses of the active and standby BAMs.
Table 1.1.1.I.1.1.1.1 IP addresses of the BAM
IP Address
Description
Internal fixed IP address
IP address of the internal network team
External fixed IP address
IP address of the external network team

IP address used for the communication between the BAM
Internal virtual IP address
and the host

IP address used for the communication between the
External virtual IP address

Backup
channel
BAM, LMTs, and M2000

IP
addresses of the active and

standby BAMs
IP addresses used for the communication between the

active and standby BAM
IP address used for local OM operations on the BAM
Commissioning IP address
This is not a common scenario. In this scenario, the

commissioning is commonly performed through the portable
computer connected to the BAM using an Ethernet cable.
Before delivery, these IP addresses should be planned and set for each BAM: the internal fixed IP
address, internal virtual IP address, external fixed IP address, and commissioning IP address, and also
backup channel IP addresses of the BAMs (if two OMUa board are configured). Usually, there is no need to
modify the default internal network IP addresses. Therefore we can consider that the Virtual, Active BAM IP
and Standby BAM IP addresses should be planned.
TEP
Confidential
The external virtual IP address is set on site. The preset external fixed IP address may be reconfigured
based on the field requirements.
Table 1.1.1.I.1.1.1.2 IP addresses planning principle of the BAM
IP Address
Planning Principle
Internal fixed IP
The preset IP addresses of the internal Ethernet adapters are:
address
Active BAM: 80.168.3.50 (255.0.0.0)

Standby BAM: 80.168.3.60 (255.0.0.0)
Ensure that this IP address is in the same network segment as that of the
external Ethernet ports on the SCUa board.
External fixed IP
The preset IP addresses of the external Ethernet adapters are:
address
Active BAM: 172.121.139.201 (255.255.255.0)

Standby BAM: 172.121.139.202 (255.255.255.0)
The settings should be reconfigured on site based on the actual networking
topology.
Internal virtual IP
address
The internal virtual IP address is set in the same subnet with the internal
fixed IP addresses of the active and standby BAMs. This subnet is named the
BAM internal network segment. In addition, the internal virtual IP address cannot
be identical with other IP addresses in the subnet. The preset virtual IP address
of the internal network is 80.168.3.40 (255.0.0.0).
External virtual IP
address
The external virtual IP address is set in the same subnet with the external
fixed IP addresses of the active and standby BAMs. This subnet is named the
BAM external network segment. In addition, the external virtual IP address
cannot be identical with other IP addresses in the subnet. The external virtual IP
address can be set to 172.121.139.200.
Backup channel IP
addresses of the
The preset backup channel IP addresses of the active and standby BAMs
are:
active and standby
Active BAM: 192.168.3.50 (255.255.255.0)
BAMs
Standby BAM: 192.168.3.60 (255.255.255.0)

The IP address cannot be changed.
Debugging IP address
The preset debugging IP addresses are:

Active BAM: 192.168.6.50 (255.255.255.0)
Standby BAM: 192.168.6.60 (255.255.255.0)
And the final configuration for each OMU per BSC will be designed in LLD according to the actual
situation.OSS Connectivity Details as below:
TEP
Confidential
Figure 1.1.1.1.1.1.3 Network Element for OSS Interface
Figure 1
M2000
The iManager M2000 Mobile Element Management System manages Huawei mobile network elements
(NEs) in a centralized manner.
PRS
PRS is an integrated solution to the performance management for mobile networks and provides a basic
platform for multiple users to monitor and analyze network performance. this system is applicable to GSM,
CDMA, UMTS, WiMAX, and LTE networks.
LTE O&M Design
5.4
This section describes the design and configuration of eNodeB operation and maintenance. This
includes the eNodeB OM IP design, OMCH design, OM security design, and time synchronization design.
5.4.1
eNodeB OM IP Address Design
Scenario: The OMCH of the eNodeB is connected to the Ethernet port with IPSec disabled.
It is recommended that the OM IP address of the eNodeB and the Ethernet interface IP address (whose
port type is ETH or ETHTRK) use the same IP address.
TEP
Confidential
If the OM IP address is a logical IP address, you can directly run the ADD OMCH command; the ADD
DEVIP command is not needed.
5.4.2
eNodeB OMCH Design
The eNodeB OMCH design includes the DSCP of the OMCH, DHCP.
DSCP of the OMCH
Huawei recommend to set high priority for the OMCH. The DSCP value range is 0 to 63. The
recommended DSCP value for the OMCH is 46 (for MML commands) and 18 (for FTP services). The
following is a command for setting these values:
SET DIFPRI: PRIRULE=DSCP, OMHIGHPRI=46, OMLOWPRI=18;
5.4.3
NTP Synchronization Design
5.4.3.1
NTP Overview
The Network Time Protocol (NTP) is an application layer protocol for time synchronization between the
distributed time server and the clients. It provides time synchronization for the network devices so that the
devices can provide multiple applications based on synchronous time.
The NTP is based on user datagram protocol; the available port numbers are 123 to 5999 and 6100 to
65534; the default value is 123. It is recommended that the NTP time synchronization period be set two 360
minutes.
5.4.3.2
NTP Server Selection Policies
The selection of the NTP server is determined by the actual situation.

The order of preference is
GPS
Private NTP server
The M2000 Server
We will use the M2000 as the NTP server for eNodeB time synchronization..
5.4.3.3
NNTP Server Configurations
For the configurations on the M2000, see the M2000 manual.

The commands for configuring the NTP on the eNodeB are as follows:
1.
SET TIMESRC: TIMESRC=NTP; //Sets the NTP server as the clock source.
2.
SET TZ: ZONET=GMT+0800, DST=NO;
3.
ADD NTPC: MODE=IPV4, IP="10.10.10.1", PORT=123, SYNCCYCLE=60, AUTHMODE=PLAIN;
1.
2.
In the M2000 HA system, each of the active and standby M2000s has an IP address. Run the following
commands to set both M2000s to NTP server and specify the active one:
ADD NTPC: MODE=IPV4, IP=''10.10.10.2'', PORT=123, SYNCCYCLE=60, AUTHMODE=PLAIN;
SET MASTERNTPS: MODE=IPV4, IP="10.10.10.1";
TEP
Confidential
Interface Interconnection Design
6.1 A Interface Design

6.1.1
Interconnection Solution Description
For A interface, the GOUc boards will be used as the interface board and the following solution will be
deployed: Transmission pool of active/standby interface boards with manual active/standby LAG.
The BSC connects to RT1 and RT2 routers through the manual active/standby LAG
on the active and standby interface boards. Data is transmitted and received through the active port. The
logical IP addresses on multiple pairs of active/standby interface boards form an IP pool.
VRRP is configured between the routers as the next hop of the BSC. VRRP
heartbeats are transmitted over the trunk between RT1 and RT2.
The signaling plane and the user plane share a physical port, while the bearer
network isolates the signaling plane and user plane of the A/IuCS interface with different VPNs. Accordingly,
different VLANs and interface IPs should be made available on the BSC side (for the signaling interface, a
separate interface IP address is configured: IP111 and VLAN; for the user plane, a separate IP address is
configured: IP131 and VLAN; for the signaling plane of the standby board, a separate interface IP address is
configured: IP121 and VLAN; and for the user plane, a separate interface IP address is configured: IP141
and VLAN.)
TEP
Confidential
6.1.2
IP/VLAN/Routing Planning
6.1.2.1 Physical ports
For the BSC interface boards and the Ethernet ports of RT1 and RT2, enable the
auto-negotiation mechanism.
Ports related to the VRRP on RT1 and RT2, including ports connecting the BSC and
the trunk ports between the routers, must be configured as Layer 2 ports. Besides, given that traffic may be
forwarded between RT1 and RT2 and the VRRP heartbeat link must be reliable, the trunk bandwidth must be
greater than 50% of the total BSC traffic, and at least two GE ports should be aggregated.
BSC ports in even slots must be connected to high-priority routers to increase the
consistency between the active paths of the BSC and routers.
6.1.2.2 IP addresses and VLAN
For details about the configuration of the IP addresses and VLAN, see .
The BSC port IP address (IP111), RT1 VLANIF IP address (IP112), RT2 VLANIF IP address (IP113), and
VRRP virtual IP address (IP110) must be on the same network segment. That is, at least four IP addresses
are required, using a 29-bit mask. For good scalability, logical IP addresses (DEV IP) are used for the service
IP addresses of the BSC.
The VLAN is divided based on the signaling plane and service plane, and different VLANs correspond to
different VRRP groups in the router.
Table2-22 IP address and VLAN Planning
Equipment
BSC
IP
IP111
IP11
4
IP13
1
IP15
0
IP17
0
IP12
1
IP12
4
IP14
1
IP16
0
IP18
0
RT1
TEP
IP11
2
IP Address Description
The IP address of the sub-interface on the
signaling plane of the first pair of active/standby
interface boards
The IP address of the standby port on the
first pair of active/standby interface boards
(used for ARP detection only)
user plane of the first pair of active/standby
interface boards
The logical IP address of the signaling
plane of the first pair of active/standby interface
boards
The logical IP address of the user plane of
the first pair of active/standby interface boards
signaling plane of the second pair of
active/standby interface boards
The IP address of the standby port on the
second pair of active/standby interface boards
(used for ARP detection only)
user plane of the second pair of active/standby
interface boards
plane of the second pair of active/standby
interface boards
The logical IP address of the user plane of
the second pair of active/standby interface
boards
The signaling plane VRRP physical IP
address connected to the active port on the first
pair of active/standby interface boards
Confidential
Network
Segment
VLAN
Mask
Length
Network
segment 11
VLAN1
1
29
Network
segment 11
VALN11
29
Network
segment 13
VLAN1
3
29
Network
segment 15
N/A
32
Network
segment 17
Network
segment 12
N/A
32
VLAN1
2
29
Network
segment 12
VALN1
2
29
Network
segment 14
VLAN1
4
29
Network
segment 16
N/A
32
Network
segment 18
N/A
32
Network
segment 11
VLAN1
1
29
Equipment
IP
IP13
2
IP12
2
IP14
2
IP11
0
IP13
0
IP12
0
IP14
0
RT2
IP11
3
IP13
3
IP12
3
IP14
3
MSC
Server
MGW
IP31
1
IP32
1
IP31
2
IP32
2
IP33
1
IP34
1
The user plane VRRP physical IP address
connected to the active port on the first pair of
address connected to the active port on the
connected to the active port on the second pair
of active/standby interface boards
The signaling plane VRRP virtual IP
The user plane VRRP virtual IP address
The user plane VRRP virtual IP address
Signaling plane IP address 1
User plane IP address 1
Network
Segment
VLAN
Mask
Length
Network
segment 13
VLAN1
3
29
Network
segment 12
VLAN1
2
29
Network
segment 14
VLAN1
4
29
Network
segment 11
VLAN1
1
29
Network
segment 13
VLAN1
3
29
Network
segment 12
VLAN1
2
29
Network
segment 14
VLAN1
4
29
Network
segment 11
VLAN1
1
29
Network
segment 13
VLAN1
3
29
Network
segment 12
VLAN1
2
29
Network
segment 14
VLAN1
4
29
Network
segment 31
Network
segment 32
Network
segment 31
Network
segment 32
Network
segment 33
Network
segment 34
N/A
32
N/A
32
N/A
32
N/A
32
N/A
32
N/A
32
Note 1: To simplify routing configuration of the peer equipment so that the local pool can be expanded
without modifying peer routing configuration, it is recommended that the IP addresses in a single pool be on
the same IP address segment.
The Layer 2 ports that connect RT1 and RT2 to the BSC are configured in the
trunk mode, allowing VLAN11, VLAN12, VLAN13, and VLAN14 to pass through.
The VLAN information is tagged on the BSC based on the next hop. As the BSC
exchanges packets with the three IP addresses RT1_VRRP_Physical IP/RT2_VRRP_Physical
TEP
Confidential
IP/VRRP_Virtual IP (e.g:IP110/IP112/IP113), the same VLANID (e.g:VLANID11) should be configured for all
the three next hops. Other VLAN configurations are similar.
6.1.2.3 Routes
Table 1.1.1.I.1.1.1.1 Static route configuration
Equipment
RT1
Destination IP Address
IP150
IP170
IP160
IP180
IP150
IP170
IP160
IP180
RT2
Next Hop
Priority
IP111
IP131
IP121
IP141
IP111
IP131
IP121
IP141
Default
Default
Default
Default
Default
Default
Default
Default
Table 1.1.1.I.1.1.1.2 Static route configuration (based on the source IP address)

Equipment
BSC
Source
IP
Next Hop
IP150
IP170
IP160
IP180
Standby Next Hop
IP110
IP130
IP120
IP140
It is recommended that a dynamic routing protocol (such as OSPF and ISIS) be

configured for the intermediate network.
6.1.3
Logical Links
SCTP and M3UA configuration:
M3UA links should be evenly distributed among different subracks, EGPUa

boards and subsystems.(SCTP links Qty should equal to 2n and more than half of the EGPUa boards Qty)
On the BSC side, the SCTP dual-homing must cross boards, so that cross-board
active/standby SCTP link protection can be provided for the signaling plane.
It is recommended that the BSC serve as the client, and the core network serve
as the server. The SCTP and M3UA configurations can be distinguished by the IP address or the port
number on the client side. As identical port numbers are used on the server side, SCTP and MU3A
configurations are distinguished by the IP address. Parallel paths are recommended for the SCTP link.
SCTP link configuration:

Type
SCTP Link
RNC IP
Address 1
RNC IP
Address 2
M3LNK1
M3LNK2
M3LNK3
M3LNK4
SCTP link1
SCTP link2
SCTP link3
SCTP link4
IP150
IP160
IP150
IP160
IP160
IP150
IP160
IP150
RNC Port
No.
Port 1
Port 2
Port 3
Port 4
Peer IP
Address 1
Peer IP
Address 2
IP311
IP321
IP312
IP322
IP321
IP311
IP322
IP312
Peer Port
No.
Port 5
Port 5
Port 5
Port 5
Note 1: If the server supports configuration of another port number, choose the other port number (port
4).
TEP
Service IP address configuration
Confidential

Configurations on the BSC side: Add an IP pool, and put the service IP addresses
of IP170 and IP180 in this IP pool. When adding an adjacent node, associate the MSC server/MGW with this
IP pool.
6.1.4
Requirements for Interconnection
Requirements for Routers on the BSC side
The IP addresses in the IP pool on the BSC should be interconnected with the IP
addresses of the peer nodes of the A interface.
RT1 and RT2 must support VRRP.
RT1 and RT2 must support Layer 2 ports and VLAN interfaces.
RT1 and RT2 must update the entries in their ARP tables after receiving the free
ARP session from the BSC.
BSC ports in even slots must be connected to the VRRP router with higher priority
for better consistency between the active paths of the BSC and the routers. In addition, Technical Service
Department (TSD) engineers must ensure that the active router is mounted in an even slot after each
upgrade or reset. (If the active router is in an odd slot, initiate manual switchover.)
It is recommended that the trunk bandwidth between RT1 and RT2 exceed 50% of
the total BSC data traffic and that at least two GE ports be aggregated over the trunk.
Layer 2 ports connecting RT1/RT2 to the BSC must be configured in the trunk mode.
Requirements for core network devices
Peer user plane IP addresses and signaling plane IP addresses must be in even
numbers, so that they can be divided into two groups.
SCTP dual-homing configuration is required for the signaling plane.
Requirements for the intermediate transmission network
The intermediate network must be able to differentiate between priorities.
The QoS requirements of services for the intermediate network are as follows:
One-Way Delay
(ms)
A interface
Maximu
m value
15
Target
value
10
Jitter (ms)
Maximum
value
7
Target
value
Packet Loss Rate

Maximum
value
1E-3
Target value
1E-4
1 The maximum value column indicates the basic commercial requirements for deploying radio services.
6.2 Gb Interface Design

6.2.1
For Gb interface, one pair of the GOUc board will be used as the interface board and the following
solution will be deployed:
Active and standby VRRP routers + the active and standby boards of the BSC with manual
active/standby LAG..
TEP
Confidential

The BSC connects to RT1 and RT2 routers through the manual active/standby LAG
on the active and standby interface boards. Data is transmitted and received through the active port.
Virtual Router Redundancy Protocol (VRRP) is configured between the two routers
as the next hop of the BSC. VRRP heartbeat is transmitted on the Trunk between RT1 and RT2.
6.2.2
6.2.2.1
L3 networking is implemented between BSC and SGSN.
Physical Ports
It is recommended that the following Ethernet ports are configured in autonegotiation mode: Ethernet ports on the interface boards and Ethernet ports on RT1/RT2.
Ports related to VRRP1 on RT1 and RT2, including ports on the BSC as well as the
Trunk between the routers, must be configured in L2 mode. Because the service traffic may be forwarded
between RT1 and RT2 and the reliability of the VRRP heartbeat links must be ensured, the Trunk bandwidth
must be larger than 50% of the data traffic on the BSC and at least two GE interfaces are aggregated.
BSC ports in even slots must be connected to the VRRP high-priority routers to
enhance the consistency between the active paths of the BSC and routers.
Ports on the BSC do not support L2 switching. Therefore, the STP protocol is not
required on the peer device.(STP Disable)
6.2.2.2
IP Addresses and VLAN
For details about the configuration of the IP address and VLAN, see the IP
configuration table, as shown in the table .
TEP
Confidential

The following IP addresses are on the same network segment: port IP address
(IP111) of BSC, VLANIF IP addresses (IP110) of RT1, VLANIF IP addresses (IP112) of RT2, VRRP virtual IP
address (IP119). At least four IP addresses are required, using 29-bit masks. To facilitate expansion, BSC
service IP addresses use logical IP addresses (device IP addresses).
Table 1.1.1.I.1.1.1.3 IP address and VLAN configuration

Device IP Address
BSC
RT1
IP address over the active port
IP113
IP address used during APR detection

over the standby port
IP150
Service IP address (logical IP address)
IP110
IP112
IP119
SGSN
Network Segment
IP111
IP119
RT2
VLANIF IP address connected to the

BSC
VRRP virtual IP address provided to the
BSC
VLANIF IP address connected to the
BSC
VRRP virtual IP address provided to the
BSC
IP350
SGSN service IP address
Network segment
11
Network segment
11
Network segment
15
Network segment
11
Network segment
11
Network segment
11
Network segment
11
Network segment
35
VLAN
Mask
Length
VLAN11
29
VLAN11
29
N/A
32
VLAN11
29
VLAN11
29
VLAN11
29
VLAN11
29
N/A
32
The BSC configures VLAN IDs according to the next hop. The BSC interchanges
packets with IP addresses IP110, IP112, and IP119. Therefore, three next hops must be configured with the
same VLANID 11.
L2 ports for RT1 and RT2 connected to the BSC are in Trunk mode and allow
VLAN11 to pass through. The BSC configures VLAN IDs according to the next hop. The BSC interchanges
packets with IP addresses IP110, IP112, and IP119. Therefore, three next hops must be configured with the
same VLANID 11.
ADD VLANID: SRN=X, SN=X, IPADDR="110", VLANID=11;

6.2.2.3
Routes
Configuration of static routes

Device
BSC
RT1
RT2
Next Hop
IP350
IP150
IP150
Priority
IP119
IP111
IP111
Default
Default
Default
Its advised to configure dynamic route protocols between RT1, RT2, and the
intermediate network, such as OSPF and ISIS. It is recommended that routers are configured with route
policies to ensure that data to IP150 is transited on the active router RT1.
6.2.3
Logical Links
NSVL configuration
Table 1.1.1.I.1.1.1.4 NSVL configuration
TEP
Device
NSVL
BSC
NSVL 1
IP Address
IP150
Confidential
UDP Port No
Port 1
Weight
100 (Note 1)
SGSN
NSVL 1
IP350
Port 2
100 (Note 1)
Note 1: Weight in the preceding table does not refer to percentage. Values of Weight range from 1 to
255. Generally, Weight is retained at the default value 100 (equivalent for all NSVLs). Weight needs to be
modified only when the intermediate path bandwidths are different or there are multiple SGSNs at the peer
end. Note that modifying Weight affects load sharing affects.
6.2.4
Requirement for Routers on the BSC Side
RT1 and RT2 support VRRP.
RT1 and RT2 support L2 ports and VLAN interfaces.

RT1 and RT2 must update ARP table items after receiving free ARP packets from
the BSC.
enhance the consistency between the active paths of the BSC and routers. In addition, TSD engineers must
ensure that the active router is installed in an even slot after each upgrade or reset. (If the active router is
installed in an odd slot, manually switch over the routers.)
The bandwidth of the Trunk between RT1 and RT2 must be larger than 50% of the
data traffic of the BSC and at least two GE interfaces are aggregated.
If there are other routers (when RT1/RT2 is extended into a L3 network), route
policies or active and standby planes must be configured on the routers to ensure that the data transmitted to
IP150 is transmitted to the active router RT1 first.
L2 ports for RT1/RT2 connecting to the BSC must be configured in Trunk mode.
Requirement for Core Network Devices

None
Requirements for Intermediate Transmission Network
The intermediate network must be able to differentiate priorities.
QoS requirements for the services on the intermediate network are as follows:
Gb
interface
One-Way Delay
(ms)
15
Jitter (ms)
8
Packet Loss Rate

5E-4
6.3 Abis Interface Design

6.3.1
The Abis interface in an internal interface. The BTS that are provided by different manufacturers cannot
interwork through the Abis interface.
The protocols and standards that the Abis interface complies with are as follows:
Basic principles of the Abis interface: 3GPP 48.052
Physical layer: 3GPP 48.054
Data link layer: 3GPP 48.056
Layer 3 signaling procedure: 3GPP 48.058
O&M message transfer mechanism: 3GPP 52.021
BSC code converter/rate adaptation in-band control protocol: 3GPP 48.060
IP transmission mode
Basic principle: UDP/IP bears the CS and PS service, signaling, and O&M messages.
Implementation method:
TEP
Confidential
Packet interfaces boards are added to the BTS and the BSC. On the Abis interface, the PS and service
service/signaling messages are transmitted in IP over FE/GE mode.
Each BTS is configured with an independent logical IP address. Each CS service channel, RSL, OML,
and ESL is allocated with a UDP port number. For the PS service, each TRX is allocated with a UDP port
number.
On the BSC side, a fixed UDP port number is used, and the UDP port number on the BTS side is used
to distinguish CS and PS signaling/O&M messages.
Abis over IP interface protocol
Abis Transmission topology as below:
For Abis interface, one pair of the GOUc board will be used as the interface board and the following
solution will be deployed: single IP address Pool of active/standby boards + manual active/standby LAGs.
TEP
Confidential
The BSC connects to RT1 and RT2 routers through the manual active/standby LAG on the
active and standby interface boards. Data is transmitted and received through the active port.VRRP IP
addresses are configured between the dual routers, which function as the next hops of the BSC. Heartbeat
messages are transmitted over the trunk between CE1 and CE2.
Logical IP address of the active/standby interface board of the BSC comprises an Single IP pool.
The BTS is connected to the Ethernet network through a single Ethernet port.
The BSC uses layer-3 networking.

6.3.2
6.3.2.1
Physical Ports
It is recommended that the following Ethernet ports are configured in autonegotiation mode: Ethernet ports on the interface boards and Ethernet ports on RT1/RT2.
Ports related to VRRP1 on RT1 and RT2, including ports on the BSC as well as the
must be larger than 50% of the data traffic on the BSC and at least two GE interfaces are aggregated.
enhance the consistency between the active paths of the BSC and routers.
Ports on the BSC do not support L2 switching. Therefore, the STP protocol is not
6.3.2.2
The service IP addresses of the BSC/BTS use logical IP addresses in the L3 networking.
L2 ports on RT 1 and RT 2 for connecting to the BSC must be configured in Access mode. In this way,
the VLAN does not need to be tagged for the BSC.
TEP
Confidential
Table 1.1.1.I.1.1.1.5 Configuration of IP addresses and VLANs
6.3.2.3
Routes
Device
Destination IP
Next Hop
Priority
BSC
IP151
IP19
Default
BTS
IP200
IP119
Default
CE1
IP200
IP11
Default
CE2
IP200
IP11
Default
It is advised to configure OSPF and ISIS for the IP bearer network and introduce static route and direct
route to RT1 and RT2. Configure routing strategy so that RT1 has higher priority reaching IP200 so that data
to IP200 passes through RT1.
6.3.3
Logical Links
G/U /L Co-TX
New IP addresses to be created on MBTS:
Logical IP: Dev IP10/13/16/19/22
sub-IF IP: IP11/14/17/20/23
2G&3G&4G Single OAM IP: IP10, M2000 IP: IP30
(OAM IP will also use as IPCLK Client IP, IPCLK Server IP: IP80 )
NodeB Service IP: IP13, RNC IP: IP40

TEP
Confidential
GSM Service : IP16, BSC IP: IP50;

LTE S1/X2 Control Plane IP: IP19, MME/SGW Control Plane IP: IP60
LTE S1/X2 User Plane IP: IP22, MME/SGW User Plane IP: IP70
BTS Routing Table:
6.3.4
The single IP address in IPPOOL should be interconnected with all the BTS allocated in this interface board.
RT 1 and RT 2 support the VRRP.

RT 1 and RT 2 support L2 ports and VLAN interfaces.
RT 1 and RT 2 must update the ARP table items after receiving the free ARP session.
BSC ports in even slots must be connected to routers with high-priority VRRPs to enhance the consistency
between the active paths of the BSC and routers. The GTS personnel must ensure that boards installed in
even-numbered slots are active boards after an upgrade or reset is complete. If a board installed in an oddnumbered slot is an active board, switch over the board to the standby state.
It is recommended that the TRUNK bandwidth between RT 1 and RT 2 exceed 50% of the total BSC data
traffic and at least two GE interfaces are aggregated.
Suggest the peer device is configured with the STP disabled
L2 ports on RT 1 and RT 2 for connecting to the BSC must be configured in Access mode.
If BFD session is configured on the active port of manual active/standby LAG, it requires that the BFD
session on RT1 and RT2 must be configured to dynamic mode which means the parameter
DISCRIMINATOR is not configured.
6.3.5
Abis Interface Bandwidth Calculation
Bandwidth calculation for each BTS as below:

TEP
Confidential
Dimensioning Parameters Used

Parameter Type
Parameter Name
Common Parameters
Site Configuration
Transmission Bandwidth Usage Ratio
Whether to support IP MUX
No. IP MUX Packets
Active PDCH Qty
PS Core Mode
PS Activity Factor
HR Ratio
FR Code Mode
HR Code Mode
Um Interface GoS
PS Parameters
CS Parameters
Peak of Traffic
CS Activated Factor
Whether to support BTS Local Switch
BTS Local Switch Ratio
Average Call Duration (second)
Parameter
Value
Sx/x/x
85%
Yes
2
6
MCS-9
1
0%
FR
HR
2%
Network
Traffic
0.5
No
0%
45
The Abis bandwidth calculation results of typical site configuration are below:
Site
Configuration
G2/2/2
G4/4/4
G6/6/6
G8/8/8
G4/4/4+D4/4/4
G4/4/4+D6/6/6
G4/4/4+D8/8/8
G6/6/6+D8/8/8
G6/6/6+D12/12/1
2
G8/8/8+D12/12/1
2
6.3.6
Bandwidth(Mbps
)
1.00
1.83
2.72
3.56
3.67
4.56
5.39
6.28
7.94
8.78
Abis Port Allocation Design
Port allocation principal:
Subrack-based Abis port planning by LAC
To minimize the inter-subrack signaling traffic caused due to inter-cell handover and paging forwarding,
plan the BTSs in the same LAC to the same BM subrack as possible as you can.
Discontinuous BTS distribution in a subrack (optional)
The BTSs in a subrack can be distributed between boards in a discontinuous manner. Overlapping
coverage exists between adjacent cells. Based on discontinuous BTS distribution, adjacent BTSs are
distributed to different Abis interface boards. When a board is faulty, the BTS under it is out of service but the
overlapping coverage of the peripheral cells can still ensure services to a certain degree. This can minimize
the impacts of board faults.
TEP
Confidential
The BTS must be evenly distributed to different interface boards based on the station module to ensure
load balance among boards.
Batch site establishment
For certain projects, sites need to be established in batches due to transmission providing capabilities,
engineering implementation capabilities and customer requirements. Based on special requirements, the site
distribution strategy can be adjusted. For the best results, abide by the principle of subrack-based Abis port
planning by LAC.
Site Name
BTS1
TRX Quantity
10
BSC Name
xxx
Subrack/Slot/P
ort
0/20/0
6.4 IuCS Interface Design

6.4.1
For IuCS interface, the EXOUa boards will be used as the interface board and the following solution will
be deployed: Transmission pool of active/standby interface boards with manual active/standby LAG.
TEP
Confidential
The RNC connects to RT1 and RT2 routers through the manual active/standby LAG
VRRP is configured between the routers as the next hop of the RNC. VRRP
network isolates the signaling plane and user plane of the IuCS interface with different VPNs. Accordingly,
different VLANs and interface IPs should be made available on the RNC side (for the signaling interface, a
and VLAN.)
TEP
Confidential
6.4.2
6.4.2.1 Physical ports

For the RNC interface boards and the Ethernet ports of RT1 and RT2, enable the
auto-negotiation mechanism.
Ports related to the VRRP on RT1 and RT2, including ports connecting the RNC and
the trunk ports between the routers, must be configured as Layer 2 ports. Besides, given that traffic may be
greater than 50% of the total RNC traffic, and at least two GE ports should be aggregated.
RNC ports in even slots must be connected to high-priority routers to increase the
consistency between the active paths of the RNC and routers.

6.4.2.2 IP addresses and VLAN
For details about the configuration of the IP addresses and VLAN, see .
The RNC port IP address (IP111), RT1 VLANIF IP address (IP112), RT2 VLANIF IP address (IP113),
and VRRP virtual IP address (IP110) must be on the same network segment. That is, at least four IP
addresses are required, using a 29-bit mask. For good scalability, logical IP addresses (DEV IP) are used for
the service IP addresses of the RNC.
The VLAN is divided based on the signaling plane and service plane, and different VLANs correspond to
different VRRP groups in the router.
Table2-22 IP address and VLAN Planning
Equ
ipment
RN
C
I
P111
I
P114
I
P131
I
P150
I
P170
I
P121
I
P124
I
P141
TEP
P
The IP address of the sub-interface
on the signaling plane of the first pair of
The IP address of the standby port
on the first pair of active/standby
interface boards (used for ARP detection
only)
on the user plane of the first pair of
The logical IP address of the
signaling plane of the first pair of
The logical IP address of the user
plane of the first pair of active/standby
interface boards
on the signaling plane of the second pair
The IP address of the standby port
on the second pair of active/standby
interface boards (used for ARP detection
only)
on the user plane of the second pair of
Confidential
Network
Segment
VLA
N
Network
segment 11
N11
Network
segment 11
N11
Network
segment 13
N13
Ma
sk
Length
VLA
29
VAL
29
VLA
29
Network
segment 15
N/A
32
Network
segment 17
N/A
32
VLA
29
VAL
29
VLA
29
Network
segment 12
N12
Network
segment 12
N12
Network
segment 14
N14
Equ
ipment
I
P160
I
P180
RT1
I
P112
I
P132
I
P122
I
P142
I
P110
I
P130
I
P120
I
P140
RT2
I
P113
I
P133
I
P123
I
P143
TEP
P
The logical IP address of the
signaling plane of the second pair of
plane of the second pair of
The signaling plane VRRP physical
IP address connected to the active port
interface boards
The user plane VRRP physical IP
address connected to the active port on
the first pair of active/standby interface
boards
interface boards
the second pair of active/standby
interface boards
boards
The user plane VRRP virtual IP
boards
interface boards
interface boards
interface boards
boards
interface boards
interface boards
Confidential
Network
Segment
VLA
N
Ma
sk
Length
Network
segment 16
N/A
32
Network
segment 18
N/A
32
VLA
29
VLA
29
VLA
29
VLA
29
VLA
29
VLA
29
VLA
29
VLA
29
VLA
29
VLA
29
VLA
29
VLA
29
Network
segment 11
N11
Network
segment 13
N13
Network
segment 12
N12
Network
segment 14
N14
Network
segment 11
N11
Network
segment 13
N13
Network
segment 12
N12
Network
segment 14
N14
Network
segment 11
N11
Network
segment 13
N13
Network
segment 12
N12
Network
segment 14
N14
Equ
ipment
MS
C Server
MG
W
P
I
P311
I
P321
I
P312
I
P322
I
P331
I
P341

Network
Segment
Network
segment 31
Network
segment 32
Network
segment 31
Network
segment 32
Network
segment 33
Network
segment 34
VLA
N
Ma
sk
Length
N/A
32
N/A
32
N/A
32
N/A
32
N/A
32
N/A
32
without modifying peer routing configuration, it is recommended that the IP addresses in a single pool be on
the same IP address segment.
The Layer 2 ports that connect RT1 and RT2 to the RNC are configured in the
trunk mode, allowing VLAN11, VLAN12, VLAN13, and VLAN14 to pass through.
The VLAN information is tagged on the RNC based on the next hop. As the RNC
exchanges packets with the three IP addresses RT1_VRRP_Physical IP/RT2_VRRP_Physical
IP/VRRP_Virtual IP (e.g:IP110/IP112/IP113), the same VLANID (e.g:VLANID11) should be configured for all
the three next hops. Other VLAN configurations are similar.
6.4.2.3 Routes
Static route configuration
Equipment
RT1
IP150
IP170
IP160
IP180
RT2
IP150
IP170
IP160
IP180
Static route configuration (based on the source IP address)
Equipment
RNC
Source
IP
IP150
IP170
IP160
IP180
Next Hop
Next Hop
Priority
IP111
IP131
IP121
IP141
IP111
IP131
IP121
IP141
Default
Default
Default
Default
Default
Default
Default
Default
Standby Next Hop
IP110
IP130
IP120
IP140
It is recommended that a dynamic routing protocol (such as OSPF and ISIS) be

6.4.3
Logical Links

TEP
Confidential

On the RNC side, the SCTP dual-homing must cross boards, so that cross-board
It is recommended that the RNC serve as the client and the core network serve
configurations are distinguished by the IP address. Parallel paths are recommended for the SCTP link.
SCTP link configuration:

Type
SCTP Link
RNC IP
Address 1
RNC IP
Address 2
RNC Port
No.
Peer IP
Address 1
Peer IP
Address 2
Peer Port
No.
M3LNK1
SCTP link1
IP150
IP160 Port 1
IP311
IP321
Port 5
M3LNK2
SCTP link2
IP160
IP150 Port 2
IP321
IP311
Port 5
M3LNK3
SCTP link3
IP150
IP160 Port 3
IP312
IP322
Port 5
M3LNK4
SCTP link4
IP160
IP150 Port 4
IP322
IP312
Port 5
Note :If the server supports configuration of another port number, choose the other port number (port 4).
Configurations on the RNC side: Add an IP pool, and put the service IP
addresses of IP170 and IP180 in this IP pool. When adding an adjacent node, associate the MSC
server/MGW with this IP pool.
6.4.4
Requirements for Routers on the RNC side
The IP addresses in the IP pool on the RNC should be interconnected with the IP
addresses of the peer nodes of the A interface.
ARP session from the RNC.
RNC ports in even slots must be connected to the VRRP router with higher priority
for better consistency between the active paths of the RNC and the routers. In addition, Technical Service
Department (TSD) engineers must ensure that the active router is mounted in an even slot after each
upgrade or reset. (If the active router is in an odd slot, initiate manual switchover.)
the total RNC data traffic and that at least two GE ports be aggregated over the trunk.
Layer 2 ports connecting RT1/RT2 to the RNC must be configured in the trunk mode.
SCTP dual-homing configuration is required for the signaling plane.
Requirements for the intermediate transmission network
TEP
Confidential
IuCS
interface
One-Way Delay (ms)
Jitter (ms)
Maximu
m value
15
Maximum
value
7
Target
value
10
Packet Loss Rate

Target
value
Maximum
value
1E-3
Target value
1E-4
1 The maximum value column indicates the basic commercial requirements for deploying radio services.
6.5 IuPS Interface Design

6.5.1
For IuPS interface, two pairs of the EXOUa boards will be used as the interface board and the following
solution will be deployed: Transmission pool of active/standby interface boards with manual active/standby
LAG.
The RNC connects to RT1 and RT2 routers through the manual active/standby LAG
VRRP is configured between the routers as the next hop of the RNC. VRRP
TEP
The RNC and the SGSN are connected at Layer 3.
Confidential
network isolates the signaling plane and user plane of the Iu-PS interface with different VPNs. Accordingly,
different VLANs and interface IPs should be made available on the RNC side (for the signaling interface, a
and VLAN.)
6.5.2
6.5.2.1
Physical ports
For the RNC interface boards and the Ethernet ports of RT1 and RT2, auto-
negotiation is recommended.
Ports related to the VRRP on RT1 and RT2, including ports connecting the RNC and
the trunk between the routers, must be configured as Layer 2 ports. Besides, given that traffic may be
greater than 50% of the total RNC traffic, and at least two GE ports should be aggregated.
for better consistency between the active paths of the RNC and the routers.
6.5.2.2
IP addresses and VLAN
For details about the configuration of IP addresses and VLAN, see Table
1.1.1.I.1.1.1.6.
The RNC port IP address (IP111), RT1 VLANIF IP address (IP112), RT2 VLANIF
IP address (IP113), and VRRP virtual IP address (IP110) must be on the same network segment. That is, at
least four IP addresses are required, using a 29-bit mask. For good scalability, logical IP addresses (DEV IP)
are used for the service IP addresses of the RNC.
The VLAN is divided based on the signaling plane and service plane, and
different VLANs correspond to different VRRP groups in the router.
Table 1.1.1.I.1.1.1.6 IP address and VLAN configurations

Equip
ment
RNC
IP
Address
IP111
IP114
IP131
TEP
Network Segment
VLAN
The IP address of the sub-interface on

the signaling plane of the first pair of
The IP address of the standby port on
the first pair of active/standby
interface boards (used for ARP
detection only)
the user plane of the first pair of
Network segment
11
VLAN11
29
Network segment
11
VALN11
29
Network segment
13
VLAN13
29
Confidential
Mask
Length
Equip
ment
IP
Address
IP150
IP170
IP121
IP124
IP141
IP160
IP180
RT1
IP112
IP132
IP122
IP142
IP110
IP130
IP120
IP140
TEP
Network Segment
VLAN

interface boards
interface boards
the signaling plane of the second pair
The IP address of the standby port on
interface boards (used for ARP
detection only)
the user plane of the second pair of
address connected to the active port
interface boards
interface boards
interface boards
interface boards
interface boards
interface boards
interface boards
interface boards
Network segment
15
N/A
32
Network segment
17
N/A
32
Network segment
12
VLAN12
29
Network segment
12
VALN12
29
Network segment
14
VLAN14
29
Network segment
16
N/A
32
Network segment
18
N/A
32
Network segment
11
VLAN11
29
Network segment
13
VLAN13
29
Network segment
12
VLAN12
29
Network segment
14
VLAN14
29
Network segment
11
VLAN11
29
Network segment
13
VLAN13
29
Network segment
12
VLAN12
29
Network segment
14
VLAN14
29
Confidential
Mask
Length
Equip
ment
RT2
IP
Address
Network Segment
VLAN
Network segment
11
VLAN11
29
Network segment
13
VLAN13
29
Network segment
12
VLAN12
29
Network segment
14
VLAN14
29
IP311

interface boards
interface boards
interface boards
interface boards
N/A
32
IP321
N/A
32
IP331
N/A
32
IP341
Network segment
31
Network segment
32
Network segment
33
Network segment
34
N/A
32
IP113
IP133
IP123
IP143
SGSN
Mask
Length
without modifying peer routing configuration, it is recommended that the IP addresses in a single pool be
located in the same IP address segment.
The Layer 2 ports that connect RT1 and RT2 to the RNC are configured in the trunk
mode, allowing VLAN11, VLAN12, VLAN13, and VLAN14 to pass through.

The VLAN information is tagged for the RNC based on the next hop. As the RNC
exchanges packets with the three IP addresses (IP110/IP112/IP113), the same VLANID11 should be
configured for all the three next hops. Other VLAN configurations are similar.
6.5.2.3
Routes
Table 1.1.1.I.1.1.1.7 Static route configuration.

Equipment
RT1
RT2
TEP
IP150
IP170
IP160
IP180
IP150
IP170
IP160
IP180
Confidential
Next Hop
IP111
IP131
IP121
IP141
IP111
IP131
IP121
IP141
Priority
Default
Default
Default
Default
Default
Default
Default
Default
Table 1.1.1.I.1.1.1.8 Static route configuration (based on the source IP address)

Equipment
Source IP
RNC
IP150
IP170
IP160
IP180
Next Hop
Standby Next Hop
IP110
IP130
IP120
IP140
-It is recommended that a dynamic routing protocol (such as OSPF and ISIS) be

6.5.3
Logical Links

On the RNC side, the SCTP dual-homing must cross boards, so that cross-board
It is recommended that the RNC serve as the client, and the core network serve
configurations are distinguished by the IP address.
Parallel paths are recommended for the SCTP link.
Table 1.1.1.I.1.1.1.9 SCTP link configuration

Type
SCTP Lin
k
RNC IP
Address
1
RNC IP
Address 2
RNC
Port
No.
Peer IP
address 1
Peer IP
address 2
Peer Port
No.
M3LNK
1
M3LNK
2
SCTP link
1
SCTP
Link2
IP150
IP160
Port 1
IP311
IP321
Port 2
IP160
IP150
Port 3
IP321
IP311
Port 2
Note:
If the server supports configuration of another port number, choose the other port number (port 4).
Configurations on the RNC side:Add an IP pool, put the service IP addresses

(IP170 and IP180) in the IP pool, and associate the SGSN to this IP pool when adding an adjacent node.
6.5.4
Requirements for the access router on the RNC side
The IP addresses in the IP pool on the RNC should be available for the IP addresses
of the peer nodes of the Iu-PS interface.
ARP session from the RNC.

TEP
Confidential
for better consistency between the active paths of the RNC and the routers. In addition, TSD engineers must
ensure that the active router is mounted in an even slot after each upgrade or reset. (If the active router is in
an odd slot, initiate manual switchover.)
the total RNC data traffic and that at least two GE ports be aggregated over the trunk.
Layer 2 ports connecting RT1/RT2 to the RNC must be configured in the trunk mode.
SCTP dual-homing configuration is recommended for the signaling plane.
Requirements for the intermediate network
Iu-PS
interface
1.
One-Way Delay (ms)
Jitter (ms)
Maximum
value
15
Maximum
value
7
Target
value
10
Packet Loss Rate

Target
value
Maximum
value
1E-3
Target value
1E-6
The maximum value column indicates the basic commercial requirements for deploying radio services.
6.6 Iur Interface

The Iur interface design is the same with IuCS interface, and it will share the same EXOUa boards with
IuCS interface.
The port allocation design on EXOUa board for IuCS and Iur interfaces as below:
TEP
Confidential
The suggested M3UA/SCTP links Qty=2*Subrack Qty/RNC
6.7 Iub Interface Design

6.7.1
The Iub interface connects the RNC and the NodeB. When the Iub over IP protocol stack is used, the
data in the control and user planes of the Iub interface is transported over IP. And the figure below shows the
Iub over IP protocol stack.
TEP
Confidential
Iub over IP protocol stack
Control plane
The application protocol for the control plane of the Iub interface is the NodeB Application Part (NBAP).
NBAP is responsible for the transport of control plane messages between the NodeB and the CRNC at the
radio network layer.
When Iub over IP is used, NBAP is carried on the Stream Control Transmission Protocol (SCTP) link.
Signaling messages carried on SCTP links are NCP and CCP signaling messages.
User plane
The application protocols for the user plane of the Iub interface are a series of frame protocols: DCH FP,
RACH FP, FACH FP, PCH FP, HS-DSCH FP, and E-DCH FP. These protocols are responsible for the
transport of data and control frames between the NodeB and the CRNC. These frames contain Uu interface
user data and user-related control data.
For the BSC6910, when Iub over IP is used, the user plane data on the Iub interface is carried by the
transmission resource pool.
For the BSC6910, the data link layer of Iub over IP supports IP over FE/GE/10GE.
For the NodeB3900, the data link layer of Iub over IP supports IP over E1/T1 and IP over
FE/GE/10GE.
Iub Transmission topology as below:
TEP
Confidential
For Iub interface, one pair of the EXOUa board will be used as the interface board and the following
solution will be deployed: single IP address Pool of active/standby boards + manual active/standby LAGs.
The RNC connects to RT1 and RT2 routers through the manual active/standby LAG on the
active and standby interface boards. Data is transmitted and received through the active port.VRRP IP
addresses are configured between the dual routers, which function as the next hops of the RNC. Heartbeat
messages are transmitted over the trunk between CE1 and CE2.
Logical IP address of the active/standby interface board of the RNC comprises an Single IP pool.
The NodeB is connected to the Ethernet network through a single Ethernet port.
The RNC uses layer-3 networking.

6.7.2
6.7.2.1
Physical Ports
It is recommended that the following Ethernet ports are configured in auto-
negotiation mode: Ethernet ports on the interface boards and Ethernet ports on RT1/RT2.
Ports related to VRRP1 on RT1 and RT2, including ports on the RNC as well as the
TEP
Confidential
must be larger than 50% of the data traffic on the RNC and at least two GE interfaces are aggregated.
RNC ports in even slots must be connected to the VRRP high-priority routers to
enhance the consistency between the active paths of the RNC and routers.
Ports on the RNC do not support L2 switching. Therefore, the STP protocol is not

6.7.2.2
The service IP addresses of the RNC/NodeB use logical IP addresses in the L3 networking.
L2 ports on RT 1 and RT 2 for connecting to the RNC must be configured in Access mode. In this way,
the VLAN does not need to be tagged for the RNC.
Table 1.1.1.I.1.1.1.10 Configuration of IP addresses and VLANs
6.7.2.3
Routes
Device
Destination IP
RNC
NodeB
CE1
CE2
IP151
IP200
IP200
IP200
TEP
Next Hop
IP19
IP119
IP11
IP11
Confidential
Priority
Default
Default
Default
Default
It is advised to configure OSPF and ISIS for the IP bearer network and introduce static route and direct
route to RT1 and RT2. Configure routing strategy so that RT1 has higher priority reaching IP200 so that data
to IP200 passes through RT1.
6.7.3
Logical Links
G/U /L Co-TX
New IP addresses to be created on MBTS:
sub-IF IP: IP11/14/17/20/23
2G&3G&4G Single OAM IP: IP10, M2000 IP: IP30

NodeB Routing Table:
TEP
Confidential
6.7.4

The single IP address in IPPOOL should be interconnected with all the NodeB
allocated in this interface board.
RT 1 and RT 2 support the VRRP.

RT 1 and RT 2 support L2 ports and VLAN interfaces.
RT 1 and RT 2 must update the ARP table items after receiving the free ARP session.
RNC ports in even slots must be connected to routers with high-priority VRRPs to enhance the consistency
between the active paths of the RNC and routers. The GTS personnel must ensure that boards installed in
even-numbered slots are active boards after an upgrade or reset is complete. If a board installed in an oddnumbered slot is an active board, switch over the board to the standby state.
It is recommended that the TRUNK bandwidth between RT 1 and RT 2 exceed 50% of the total RNC data
traffic and at least two GE interfaces are aggregated.
Suggest the peer device is configured with the STP disabled
L2 ports on RT 1 and RT 2 for connecting to the RNC must be configured in Access mode.
If BFD session is configured on the active port of manual active/standby LAG, it requires that the BFD
session on RT1 and RT2 must be configured to dynamic mode which means the parameter
DISCRIMINATOR is not configured.
6.7.5
Iub Transmission Dimension (from NodeB to RNC)
Traffic Model
Based on ethio telecoms requirement, the below traffic model should be considered:
Table 6-2 UMTS Traffic Model
Traffic Usage in GB/Month/User
traffic per user per month in GB
Dongle
10
HSPA+
Smart Phone
1
Voice
SP
0.025 erl
% of daily traffic at busy hour is 10% and down link ratio 70%
Active users is assumed to be 70%
This traffic per user includes normal traffic, signaling traffic and additional soft handover traffic,
SP voice excludes additional soft handover traffic.
The voice unit is erlang, so it should be converted erl to kbps, then calculate the total supported
throughput, the calculation is show as below:
VolumePerU ser @ BusyHour ErlangPerU ser @ BH 3600 ActivityFactor Ri
AMR12.2, Activity Factor: 0.67
Video Phone, CS 64, Activity Factor: 1
PS services, Activity Factor: 0.9
Ri: Bearer or Services bit rate, for example: AMR12.2 is 12.2kbps, CS64 is 64kbps
So,
VolumeperUser @ BusyHour = 0.025*3600*0.67*12.2=735.6Kbits, convert it to kpbs:
735.6/3600=0.21kpbs
In order to calculate the load of one connection of different service, Huawei should convert the above
traffic mode to below format:
Table 6-3 UMTS Traffic Model Calculation
TEP
Confidential
Assumptions:
BH traffic ratio: 10%(kbps)
Load heavy User
10GB/Month
0.55M
70%
Type
User Allowance
Subscribers
User Actived Rate
Assumptions:
BH traffic ratio: 10%(kbps)
Average User Average throughput@BH(kbps)
77.67
Handset
1GB/Month
0.95M
70%
7.77+0.21(Voice)
33.53
Throughput rate@BH/user = (Monthly allowance BH traffic ratio)/(30 days 3600s)
The traffic model is 33.53kbps per user, which including normal traffic , signaling traffic and soft
handover, so Huawei can calculate the Iub bandwidth based this traffic model and subscribers
supported per cell.Then, the average bandwidth (DL: 70% total bandwidth) for the typical
configuration are calculated as below:
U222: 224 Subs*70%*6 cells*33.53 *70%/1024= 21.6 Mbps
U333: 224 subs*70%*9 cells*33.53 *70%/1024= 32.3 Mbps
U444: 224 Subs*70%*12 cells*33.53 *70% /1024= 43.1 Mbps
Compare with the peak rate, and take 20% redundancy into consideration, the following peak
bandwidth will be used.
Different configuration Iub transmission Dimension Result
Configuratio
Average
Peak
n
Bandwidth(Mbps)
Bandwidth(Mbps)
U222
21.6
50
U333
32.3
75
U444
43.1
100
6.7.6
Iub Port Allocation Design
Port allocation principal:
Subrack-based Iub port planning by LAC
To minimize the inter-subrack signaling traffic caused due to inter-cell handover and paging forwarding,
plan the NodeBs in the same LAC to the same BM subrack as possible as you can.
Discontinuous NodeB distribution in a subrack (optional)
The NodeBs in a subrack can be distributed between boards in a discontinuous manner. Overlapping
coverage exists between adjacent cells. Based on discontinuous NodeB distribution, adjacent NodeBs are
distributed to different Iub interface boards. When a board is faulty, the NodeB under it is out of service but
the overlapping coverage of the peripheral cells can still ensure services to a certain degree. This can
minimize the impacts of board faults.
The NodeB must be evenly distributed to different interface boards based on the station module to
ensure load balance among boards.
Batch site establishment
For certain projects, sites need to be established in batches due to transmission providing capabilities,
engineering implementation capabilities and customer requirements. Based on special requirements, the site
distribution strategy can be adjusted. For the best results, abide by the principle of subrack-based Iub port
planning by LAC.
TEP
Confidential
Site Name
NodeB1
Cell Quantity
10
RNC Name
xxx
Subrack/Slot/P
ort
0/20/0
6.8 LTE Interface Design

6.8.1
Port Planning
UMPT provides electrical ports and optical ports, depending on the type of ports supported by
transmission equipment.
6.8.1.1
Electrical Ports
An electrical port is referred to as Ethernet port. There are three types: 10 Mbit/s (obsolete), 100 Mbit/s,
and gigabit/s. The type of ports used depends on the customer's transmission network planning, switch type,
and transmission bandwidth planning.
The FE/GE electrical ports use RJ45 connector and have a maximum transmission distance. If the
eNodeB uses the FE/GE network cables to connect to the LAN switch, xDSL, microwave equipment, or
routers, the maximum transmission distance of the network cables needs to be considered.
LTE requires high transmission bandwidth (300 Mbit/s for demo sites and at least 100 Mbit/s for
commercial sites). The gigabit network ports are recommended, considering the LTE bandwidth requirement
and future capacity expansion. Alternatively, two 100 Mbit/s FE ports can be bundled and Ethernet link
aggregation can be used to support load sharing and bandwidth expansion.
Auto-negotiation mode must be used for gigabit full-duplex electrical ports.
6.8.1.2
Optical Ports
In light of LTE's demand for high bandwidth and the evolution trend of the transmission network, fiber
access will become the mainstream access for LTE. At present, most companies' L3 switches support both
electrical ports and optical ports; fiber access to the eNodeB is common.
The UMPT of Huawei eNodeB provides FE/GE optical interfaces that support both single-mode and
multimode optical cables. The maximum transmission distance of the multimode FE optical interface is 2 km
and that of the single-mode FE optical interface is 15 km, 40 km, or 80 km, depending on the optical modules
and cable standard. The maximum transmission distance of the multimode GE optical interface is 550 m and
that of the single-mode GE optical interface is 15 km, 40 km, or 80 km.
The optical interface can work in designated rate and duplex mode, or in auto-negotiation. Designated
rate and duplex mode is recommended.
The duplex mode and auto-negotiation mechanism of the eNodeB are described as follows:
If the settings of the two optical ports are inconsistent, the auto-negotiation port is down. Therefore, the
settings must be consistent. The two ports must be both auto-negotiation and both full-duplex.
If the settings of the two electrical ports are inconsistent, for example, one auto-negotiation and the other
gigabit full-duplex, the auto-negotiation port changes to the gigabit full-duplex mode. A restraint on the
electrical ports is that auto-negotiation must be selected for gigabit electrical ports.
The default attribute of the ports of the LTE products is auto-negotiation. This is also the recommended
setting for the transmission network, though the transmission network does not necessarily use the
recommended auto-negotiation. Considering the accidents caused by auto-negotiation failure at the
preliminary UMTS stage, we recommend that you ensure consistency with the peer transmission equipment
by specifying the duplex mode and rate for the ports of both the eNodeB and the peer transmission
TEP
Confidential
equipment. If gigabit optical ports are used, specify gigabit full-duplex for both ports and avoid autonegotiation. If gigabit electrical ports are used, you have to specify auto-negotiation.
6.8.2
S1/X2 Interface Planning
1. X2 According to 3GPP, X2 interface is used for handover between eNodeBs. For the eNodeBs
under the same L3 router, X2 forwarding can be done within the same router
2. For eNodeBs under different Routers, X2 forwarding through routers
3. Its recommended that all X2 traffic is configured to one logical port.
4. S1-Flex enabled from a single eNodeB to MME/SGW Pool
6.8.3
IP Address Planning
6.8.3.1
IP Address Planning Policies and Principles
For the sake of saving physical resources, use one physical port only.
Considering the high bandwidth required by LTE and future expansion, gigabit optical ports or gigabit
electrical ports are recommended.
For non-IPSec networking, for the sake of saving address resource, route planning, and future maintenance,
the recommended configuration is three IP addresses for each eNodeB, one for S1/X2-CP, one for S1/X2-UP
and one for OM/clock. If the address resource is insufficient, one eNodeB uses only one IP address.
Take into account VLAN planning when considering IP address planning.
To configure an interface IP addresses for the OMCH, run both the ADD DEVIP and ADD OMCH
commands, where the ADD OMCH command uses the address specified by the ADD DEVIP
command.
To configure a logical IP address for an OMCH, run the ADD OMCH command only. This
command does not use the address specified by the ADD DEVIP command.
6.8.3.2
eNodeB IP Planning details
LOCALIP:192.168.0.49;(default)
S1/X2-CP share 1 IP
S1/X2-UP share 1 IP
O&M/CLOCK share 1 IP
Regarding to the IP & Route & VLAN Solution for MBTS with G/U/L Co-transmission, please refer to
following configuration:
New IP addresses to be created:
TEP
Confidential
sub-IF IP: IP11/14/17/20/23
2G&3G&4G OAM IP: IP10, M2000 IP: IP30
According the available address range and network rollout, we plan the IP address for each eNodeB as
below:
6.8.4
IP Route Planning
6.8.4.1
Route Configuration
Routes are configured for IP layer 3 networking. There are three types of route configurations:
mask.
Host address: The destination address is a specific address and the mask is a 32-bit
Network segment route: The destination address is a network segment. This

configuration requires little workload and is recommended.
TEP
Confidential
6.8.5
VLAN Planning
The nodes of a local area network are divided into logical network segments (virtual local area networks
(VLANs)). That is, a physical LAN is logically divided into multiple broadcast domains (IEEE802.1Q). The
broadcast traffic in a VLAN is not forwarded to other VLANs, preventing broadcast storm.
VLAN also provides security. Different VLANs cannot access each other at layer 2; VLAN tags indicate
priorities at layer 2.
6.8.5.1
VLAN Priorities
The value range of the VLAN priority is 0 (lowest priority) to 7 (highest priority). VLAN tags can be
configured on the eNodeB or the intermediary equipment, preferentially the eNodeB.
The following table lists the mapping between the differentiated service code points (DSCPs) and the
VLAN priorities.
PHB
EF
EF
EF
AF4
AF3
AF2
AF1
BE
DSCP Value Range

56~63
48~55
40~47
32~39
24~31
16~23
8~15
0~7
VLAN Priority
7
6
5
4
3
2
1
0
The abbreviations are explained as follows:

PHB: pre-hop behavior
EF: expedited forwarding
AF: assured forwarding
BE: best effort
CoS: Class of Service, a concept in the transmission equipment. In CoS, packets are scheduled to
queues of different priorities to ensure that packets with different priorities obtain different QoS treatment,
including delay and bandwidth.
You need to discuss with the transmission network engineers about the mapping from VLAN priorities to
the COS and the VLAN allocations, including the VLAN attribute of the ports (such as access ports, trunk
ports, or hybrid ports), and allocated VLANs.
6.8.5.2
VLAN Configuration
To configure the VLAN, perform the following steps:

Step 1: Set DSCP values for all services. (This step is optional and required based on onsite
requirements.)
1.
Run the following command to set DSCP values for signaling, OM service, and clock service:
SET DIFPRI:PRIRULE=DSCP,SIGPRI=46,OMHIGHPRI=46,OMLOWPRI=14,IPCLKPRI=46;
TEP
Confidential
2.
Run the following command to set DSCP values for services at the user plane.
The DSCP value of the service whose QCI is 1 is used as an example in the command.
ADD UDTPARAGRP:UDTPARAGRPID=0,PRIRULE=DSCP,PRI=46, ADD
UDT:UDTNO=1,UDTPARAGRPID=0;
Step 2: Run the following command to set the VLAN information for the next hop:
ADD VLANMAP: NEXTHOPIP="10.10.10.10", MASK="255.255.255.252", VLANMODE=SINGLEVLAN
VLANID=100,SETPRIO=DISABLE;
The commands in Step 3, instead of the command in Step 2, are used to set the VLAN priority for the
next-hop service.
Step 3: Run the following commands to configure the mapping between DSCP values and VLAN
priorities (optional and required based on onsite requirements):
SET DSCPMAP: DSCP=46, VLANPRIO=5;
----End
6.8.6
Traffic flow
S1 Traffic flow
X2 Traffic flow
TEP
Confidential
QoS Design
7.1 Qos overview

The quality of service (QoS) of an IP network refers to the capability of the network. The IP network that
traverses multiple bottom network technologies (multi-link protocol, frame relay, asynchronous transfer
mode, Ethernet, synchronous digital hierarchy, and multiprotocol label switching) provides services of preset
and expected QoS in terms of packet loss rate, delay, jitter, and bandwidth.
QoS requirements of all interfaces of IP transmission as below:
7.1.1
2G Qos Requirement
Delay (ms)
Abis IP
Suggestion
Value
Jitter (ms)
Max
Value
< 15 ms
Suggestion
Value
< 40 ms
< 8 ms
Delay (ms)
A/Gb IP
Packet Loss Rate (%)
Max
Value
Sugge
stion Value
Ma
x Value
< 15 ms
< 0.05%
< 0.1%
Jitter (ms)
< 15 ms
< 8 ms
Packet Loss Rate (%)

< 0.05%
Input Clock Precision Requirement

IPCLK
BTS/NodeB
7.1.2
< 0.016 ppm

< 0.05 ppm
3G QoS Requirement
QoS of the Iub interface for the transmission network

QoS of the Iub
Interface for the
Transmission
Network
IPTD (ms)
Recommen
ded value
Maximum
value
IPDV (ms)
Recommended
value
IPLR
Maximum
value
Recommended
value
Maximum
value
RT service
< 10
< 40
<2
< 15
< 0.01%
< 0.1%
NRT service
< 10
< 40
<2
< 15
< 0.01%
< 0.1%
QoS of the Iu-CS/Iu-PS/Iur Interface for the Transmission Network
The Iu-CS, Iu-PS, and Iur Interfaces have the same QoS requirements for the transmission network, as
listed in the following table.
QoS of the IuCS/Iu-PS/Iur
Interface for the
Transmission
Network
Iu-CS
Iu-PS
Iur
Notes:
TEP
IPTD (ms)
Recommend Maximum
ed value
value
< 10
< 10
< 10
IPDV (ms)
Recommended
value
< 15
< 15
< 15
Confidential
<7
<7
<7
IPLR
Maximum
value
<7
<7
<7
Recommended
value
Maximum
value
< 0.01%
< 0.0001%
< 0.01%
< 0.1%
< 0.1%
< 0.1%
RT services include conversational services and streaming services. NRT services include interactive
services and background services.
IPLR is short for IP packet loss rate, IPTD for IP packet time delay, and IPDV for IP packet delay
variation..
The maximum value indicates that basic commercial requirement of radio service deployment can be
met.
It is recommended that the delay of end-to-end RT services and end-to-end NRT services (including on
the Iub, Iur, and Iu-CS interfaces) be shorter than 40 ms and 60 ms respectively to ensure the service quality.
7.1.3
LTE QoS Requirement
S1/X2 QoS requirements of services on the intermediate Ethernet network
QoS Design
7.2
QoS design principles:

In the IP layer-3 network, different DSCP values are set for different services to ensure the QoS in IP
transmission.
Basic principles:
The priority of signaling is the highest.
The priority of the voice service is lower than that of signaling.
The priority of the real-time data service is lower than that of the voice service.
service.
The priority of the non-real-time data service is lower than that of the real-time data
The IP networks of different operators are different. If the number of DSCP values provided by an
operator is smaller than the number of DSCP values recommended by Huawei, DSCP convergence can be
implemented. For example, use the same DSCP for the voice service and the real-time data service.
7.2.1
2G QoS Design
In the IPRAN or MPLS Core, the QoS classification will keep the same as the classification from
MBTS/MBSC. Router or CX600 will trust upstream default and follow the classification in the service side.
The mobile service classification map is showed below:
7.2.1.1
QoS Design on Abis Interface
QoS Design on Huawei BSC:
TEP
Confidential
7.2.1.2
QoS Design on A/Gb Interface
7.2.1.3
VLAN Priority
VLAN priority will mapping from DSCP value, the rules as below
Note 1:
It is recommended select "SINGLEVLAN" in ADD VLANMAP.

Note 2:
It is recommended configure "Set VLAN Priority" as "DISABLE" in ADD VLANMAP, and map VLAN
Priority from DSCP by SET DSCPMAP.
7.2.2
3G QoS Design
In the IPRAN or MPLS Core, the QoS classification will keep the same as the classification from
MNodeB/MRNC. Router or CX600 will trust upstream default and follow the classification in the service side.
The mobile service classification map is showed below:
7.2.2.1
QoS Design on Iub Interface
Iub QoS Design on Huawei RNC:

System
UMTS
UMTS
TEP
Interface
Iub
Iub
Service Type
PHB
DSCP
NCP & CCP

Common channel service active
Confidential
EF
48
46
UMTS
UMTS
UMTS
UMTS
UMTS
UMTS
UMTS
UMTS
UMTS
UMTS
UMTS
UMTS
UMTS
UMTS
UMTS
UMTS
UMTS
UMTS
Iub
Iub
Iub
Iub
Iub
Iub
Iub
Iub
Iub
Iub
Iub
Iub
Iub
Iub
Iub
Iub
Iub
Iub
UMTS
Iub
UMTS
UMTS
UMTS
Iub
Iub
Iub
UMTS
UMTS
UMTS
Iub
Iub
Iub
UMTS
UMTS
UMTS
UMTS
Iub
Iub
Iub
Iub
7.2.2.2
IUPS
IUPS
TEP
46
46
46
46
46
46
46
34
34
34
34
34
34
34
34
34
34
18
EF
EF
EF
EF
EF
EF
EF
AF41
AF41
AF41
AF41
AF41
AF41
AF41
AF41
AF41
AF41
AF21
18
AF21
18
AF21
AF21
AF11
18
10
10
AF11
AF11
AF11
10
10
10
AF11
AF11
AF11
AF11
10
10
10
QoS Design on IuCS/IuPS/IuR Interface
Interface
IUCS
IUCS
IUCS
IUCS
IUPS
IUPS
IUPS
IUPS
IUPS
IUPS
IMS signaling (IMS SRB)

Signaling (SRB)
HSDPA signaling (SRB)
HSDPA IMS signaling (IMS SRB)
HSUPA signaling (SRB)
HSUPA IMS signaling (IMS SRB)
AMR speech service
HSDPA speech service
HSUPA speech service
R99 CS session service
R99 PS session service
HSDPA session service
HSUPA session service
R99 CS stream service
R99 PS stream service
HSDPA stream service
HSUPA stream service
R99 PS high-priority interactive service
R99 PS medium-priority interactive
service
R99 PS low-priority interactive
service
R99 PS background service
HSDPA high-priority interactive service
HSDPA medium-priority interactive
service
HSDPA low-priority interactive service
HSUPA high-priority interactive service
HSUPA medium-priority interactive
service
HSUPA low-priority interactive service
HSDPA background service
HSUPA background service
Service Type
CS RANAP signaling
AMR voice primary path
R99 CS conversational primary path
R99 CS streaming primary path
PS RANAP signaling
IMS SRB primary path
R99 PS conversational primary path
R99 PS streaming primary path
R99 PS high PRI interactive primary path
R99 PS middle PRI interactive primary
path
R99 PS low PRI interactive primary path
R99 PS background primary path
Confidential
PHB
EF
AF41
AF41
EF
AF41
AF41
AF21
DSCP
48
46
34
34
48
46
34
34
18
AF21
18
AF21
AF21
18
18
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
IUR
7.2.2.3
RNSAP signaling
Common channel primary PATH
IMS SRB primary PATH (IMS SRB)
SRB primary PATH (SRB)
HSDPA Signal primary PATH (SRB)
HSDPA IMS Signal primary PATH (IMS
SRB)
HSUPA Signal primary PATH (SRB)
HSUPA IMS Signal primary PATH (IMS
SRB)
AMR voice primary PATH
HSDPA Voice primary PATH
HSUPA Voice primary PATH
R99 CS conversational primary PATH
R99 PS conversational primary PATH
HSDPA conversational primary PATH
HSUPA conversational primary PATH
R99 CS streaming primary PATH
R99 PS streaming primary PATH
HSDPA streaming primary PATH
HSUPA streaming primary PATH
R99 PS high PRI interactive primary PATH
R99 PS middle PRI interactive primary
PATH
R99 PS low PRI interactive primary PATH
R99 PS background primary PATH
HSDPA high PRI interactive primary PATH
HSDPA middle PRI interactive primary
PATH
HSDPA low PRI interactive primary PATH
HSUPA high PRI interactive primary PATH
HSUPA middle PRI interactive primary
PATH
HSUPA low PRI interactive primary PATH
HSDPA background primary PATH
HSUPA background primary PATH
EF
EF
EF
EF
48
46
46
46
46
EF
46
EF
46
EF
46
EF
AF41
AF41
AF41
AF41
AF41
AF41
AF41
AF41
AF41
AF41
AF21
46
34
34
34
34
34
34
34
34
34
34
18
AF21
18
AF21
AF21
AF11
18
18
10
AF11
10
AF11
AF11
10
10
AF11
10
AF11
AF11
AF11
10
10
10
VLAN Priority
VLAN priority will mapping from DSCP value, the rules as below
TEP
Note 1:
Confidential
It is recommended select "SINGLEVLAN" in ADD VLANMAP.
Note 2:
It is recommended configure "Set VLAN Priority" as "DISABLE" in ADD VLANMAP, and map VLAN
Priority from DSCP by SET DSCPMAP.
7.2.3
LTE QoS Design
7.2.3.1
Design Principal of LTE QoS
Radio network layer: The eNodeB maps high-priority services to high-priority logical channels to ensure
that the high-priority services are scheduled in high priority. This function is processed internally by the
eNodeB. You do not need to configure this function.
Transport network layer: The service priorities are mapped to the DiffServ PHBs at the IP layer and are
marked with different DSCPs. The PHBs are then mapped to VLAN priorities. This function can be
configured flexibly by the operator and includes the following:
Mapping from the control plane, user plane, and OMCH to DSCPs.
Mapping from the user plane to the QCIs. QCIs are extensible.
Mapping from the DSCPs to the VLAN priorities.
LTE QoS requirement of transmission network (including QCI 1~QCI 9):
7.2.3.2
Detail Design of LTE QoS
Mapping from the Control Plane, User Plane, and OMCH to DSCP.The following table lists the QoS
configurations recommended by Huawei.
TEP
Confidential
Service Type
DSCP
(Hexadec
imal)
Nine
servic
e
types
DSCP
(Duodeci
mal)
MML Command for

Setting DSCP
Values
Data Type
VLAN
Priority
QCI1
QCI2
QCI3
QCI4
QCI5
QCI6
QCI7
QCI8
QCI9
SCTP
OM
MML
FTP
IP
1588
Clock
V2
Ping packets
Ping response
packets
0x2E
0x1A
0x1A
0x1A
0x2E
0x12
0x12
0x12
0
0x30
0x2E
0x12
0x2E
46
34
34
34
46
18
18
18
0
48
46
18
46
ADD UDTPARAGRP
ADD UDTPARAGRP
ADD UDTPARAGRP
ADD UDTPARAGRP
ADD UDTPARAGRP
ADD UDTPARAGRP
ADD UDTPARAGRP
ADD UDTPARAGRP
ADD UDTPARAGRP
SET DIFPRI
SET DIFPRI
SET DIFPRI
SET DIFPRI
User data
User data
User data
User data
User data
User data
User data
User data
User data
SIG
OM_H
OM_L
User data
5
3
3
3
5
2
2
2
0
6
5
2
0
0
0
0
User data
User data
5
0
0
ARP
No DSCP value
PING
The DSCP of the
response packets is
the same as the
DSCP of the ping
packets. The DSCP
value of the ping
packets from the
transmission devices
or EPC is 0.
Configuration not
required
Other
It is recommended that the DSCP value for OM FTP packets be different from that of packets at the user
plane. Otherwise, packets at the user plane are assigned to the dedicated OM FTP queue (queue 7) during
queue scheduling on the eNodeB side. Note that the two reverse pressure algorithms, one for OM FTP
queue and another for other queues, are enabled by default in eRAN6.0. The former algorithm was disabled
by default in versions earlier than eRAN6.0 and the latter has been enabled by default since eRAN2.1.
CMPV2 packets, NTP packets, and handshake packets through the OMCH are OM_H packets.
7.2.4
MBTS QoS Design

System
GSM
eGBTS
UMTS
NodeB
TEP
Service Type
ABIS CP
OM High(Note 1)
OM Low(Note 1)
PTP
USERDATA1(Note 2)
USERDATA2
USERDATA3
BFD
NCP&CCP
OM High
OM Low
Confidential
Recommend
DSCP
48
46
18
46
46
34
26
56
48
46
18
MML Command
SET DIFPRI
SET DIFPRI
SET DIFPRI
SET DIFPRI
ADD IPPATH(Note 3)
ADD IPPATH
ADD IPPATH
ADD BFDSESSION
SET DIFPRI
SET DIFPRI
SET DIFPRI
LTE eNodeB
PTP
USERDATA1(Note 2)
USERDATA2
USERDATA3
USERDATA4
BFD
QCI1
QCI2
QCI3
QCI4
QCI5
QCI6
QCI7
QCI8
QCI9
SCTP
OM High
OM Low
PTP
BFD
46
46
34
18
10
56
46
34
34
34
46
18
18
18
0
48
46
18
46
56
SET DIFPRI
ADD IPPATH(Note 3)
ADD IPPATH
ADD IPPATH
ADD IPPATH
ADD BFDSESSION
MOD UDTPARAGRP
MOD UDTPARAGRP
MOD UDTPARAGRP
MOD UDTPARAGRP
MOD UDTPARAGRP
MOD UDTPARAGRP
MOD UDTPARAGRP
MOD UDTPARAGRP
MOD UDTPARAGRP
SET DIFPRI
SET DIFPRI
SET DIFPRI
SET DIFPRI
ADD BFDSESSION
Note 1
The OM High service includes packets of MML commands, HTTP/HTTPs, SNTP and so on. The
OM Low service is FTP packets.When the DSCP of OM Low is 18, the QCI6 and QCI7 will be put in
OM FTP queue due to the same DSCP value with OM Low. So it is need to enable the "OM FTP Traffic
Control Switch" to performe backpressure for QCI6 and QCI7, the MML command is SET
RSCGRPALG: SN=7, SBT=BASE_BOARD, PT=ETH, RSCGRPID=0, OMTCSW=ENABLE;
Note 2
The DSCP value in ADD IPPMSESSION should be same with the DSCP of user plane.
Note 3
In Link mode, use ADD IPPATH to configure the DSCP of user plane
Redundancy Mechanism Design
8.1 MSC POOL

8.1.1
Introduction
An MSC pool consists of a group of MSCs handling the traffic generated from one MSC pool area. A
BSC belonging to an MSC pool area is connected to each MSC in the MSC pool. With resource and load
sharing, the traffic is evenly distributed to all the MSCs in an MSC pool, reducing inter-MSC handovers and
implementing MSC node redundancy.
TEP
Confidential
Network topology of an MSC pool
The MSC Pool feature complies with the 3GPP TS 23.236 V6.3.0 protocol. This feature has the following
advantages:
All the MSCs in an MSC pool implement load balancing and resource sharing, increasing network
capacity and reducing equipment investment.
If an MSC in an MSC pool is faulty or if an MSC is added to or removed from an MSC pool, the
existing network architecture does not need to be adjusted. This helps implement MSC node redundancy
and improve network reliability.
Logically, all the MSCs in one MSC pool are regarded as one MSC. Therefore, inter-MSC handovers
and the signaling between the MSCs and the Home Location Registers (HLRs) decrease, and the entire
network performance is improved.
With the MSC Pool feature, one BSC is connected to multiple MSCs in the MSC pool. During the call
setup procedure, if a call is not dedicated to a specific MSC, the BSC sends the Connect Request message
to all the MSCs to evenly distribute traffic among the MSCs in the MSC pool.
The BSC initiates the load balancing procedure based on the following MS identifiers:
Temporary mobile subscriber identity (TMSI)

TMSI containing NRI
If MSCSTATUEof the MSC corresponding to the NRI is NORMAL(Normal), the BSC sends the MSC a
Complete Layer 3 Information message.
If the MSC corresponding to the NRI is unavailable, the BSC randomly selects an available MSC whose
MSCSTATUE is NORMAL(Normal) according to the load balancing algorithm and sends the MSC a
Complete Layer 3 Information message.
TMSI containing NULL_NRI
The BSC randomly selects an available MSC whose MSCSTATUE is NORMAL(Normal) according to
the load balancing algorithm and sends the MSC a Complete Layer 3 Information message.
TEP
Confidential
International mobile subscriber identity (IMSI) or international mobile equipment identity (IMEI)
The BSC randomly selects an available MSC whose MSCSTATUE is NORMAL(Normal) according to
the load balancing algorithm and sends the MSC a Complete Layer 3 Information message.
MSC selection during the call setup procedure
After the MSC Pool feature is enabled on the BSC, the TMSI allocation function must be enabled on the
MSC and the TMSI that the MSC allocates to the MS must contain the NRI.
NOTE:
If MSCSTATUE of an MSC can be NORMAL(Normal), OFFLOAD(Offload), or

UNAVAIL(Unavailable).
If MSCSTATUE of an MSC is NORMAL(Normal), the MSC properly processes services for newly
connected MSs and existing MSs.
If MSCSTATUE of an MSC is OFFLOAD(Offload), the MSC properly processes services for existing
MSs and rejects access requests from new MSs.
If MSCSTATUE of an MSC is UNAVAIL(Unavailable), the MSC does not process services for
existing MSs and rejects access requests from new MSs.
The MSC has two operational states: available and unavailable.
If the MSC is in the available state, both the MSC and the communication between the BSC and
the MSC are normal.
If the MSC is in the unavailable state, the MSC or the communication between the BSC and the
MSC is abnormal.
8.1.2
MSC POOL Planning
Negotiation parameter Planning:

Support MSCPOOL
Yes
Length of NRI in TMSI
6
MSC
NRI to MSC mapping
MSC Capacity(K
Users)
TEP
Confidential
MSC
2
MSC
3
1800
1800
3600
NULL-NRI
11
IP address Planning:
signal plane
BSC
BSC
Loca
l IP
Address1
Loca
l IP
Address2
Local
SCTP Port
No.
MSC
MSC
1
Rem
ote IP
Address1
Rem
ote IP
Address2
Remote
UDP Port No.
MSC
2
MSC
3
user plane
No IPPATH needed, user plane working as an IP POOL
8.2 SGSN POOL

8.2.1
Introduction
The SGSN Pool feature (also known as Gb Flex) enables multiple serving GPRS support nodes
(SGSNs) to form an SGSN pool for resource sharing and load balancing. A BSC in an SGSN pool area is
connected to all SGSNs in the SGSN pool. Traffic load is evenly distributed to all SGSNs in the SGSN pool,
reducing the number of inter-SGSN handovers and implementing SGSN node redundancy.
As shown in the figure, an SGSN pool consists of multiple SGSNs. The SGSNs provide redundancy for
each other and connect to all BSCs in the SGSN pool area. When a mobile station (MS) requests access to
the network, the BSC serving the MS routes the access request to a specific SGSN. When an SGSN is
faulty, MSs served by this SGSN are switched to other SGSNs in the pool. This eliminates the single point of
failure and enhances the reliability of the PS domain of the core network (CN).
TEP
Confidential
Network topology of an SGSN pool
As defined in 3GPP TS 23.236 V6.3.0, the SGSN pool feature has the following advantages:
Reduces configuration workload. The overall capacity of the wireless network can be expanded by
load sharing across the SGSNs in a pool, removing the need for network replanning.
Enhances service reliability with SGSN node redundancy. With SGSN Pool, the services carried by
an SGSN in an SGSN pool are taken over by other SGSNs in the pool if the SGSN is faulty. Without SGSN
Pool, service interruptions occur when an SGSN becomes unavailable.
Improves packet switched (PS) service quality and user experience. Each SGSN in an SGSN pool
serves all the routing areas (RAs) in the SGSN pool area. Therefore, an MS does not need to perform an
inter-SGSN RA update as long as it is within the SGSN pool area.
Reduces investments in SGSNs and cuts down the overall capital expenditure (CAPEX). The SGSN
Pool feature implements load sharing across all the SGSNs in a pool. When the number of MSs in an SGSN
coverage area during busy hours exceeds the capacity of the SGSN, the excess load is distributed to other
SGSNs in the pool. This means that SGSN capacity expansion or deployment of additional SGSN is not
required as long as the overall capacity of the SGSN pool is sufficient to serve all the MSs in the SGSN pool
area.
An SGSN pool is a group of SGSNs serving MSs in one SGSN pool area. A BSC in an SGSN pool area
is connected to all SGSNs in the SGSN pool. As shown in the following figure, SGSNs 1, 2, and 3 form
SGSN pool 1, and all RAs served by BSCs 1, 2, and 5 form SGSN pool area 1. SGSNs 4, 5, and 6 form
SGSN pool 2, and all RAs served by BSCs 2, 3, and 6 form SGSN pool area 2.
TEP
Confidential
Structure of SGSN Pool
An SGSN pool area consists of multiple RAs. All the RAs served by one BSC belong to the same SGSN
pool area. Above figure shows a typical SGSN pool configuration, in which RA 21 and RA 22 belong to both
SGSN pool area 1 and SGSN pool area 2. All the SGSNs in an SGSN pool are available to process the PS
services of the MSs in all the RAs of the SGSN pool area. One or more SGSNs in an SGSN pool may also
connect to BSCs outside the SGSN pool area. As shown in this figure, SGSN 6 in SGSN pool 2 connects to
BSC 4, which is outside the SGSN pool area 2, and provides services to MSs in RA 41 and RA 42 as well as
to RA 21, RA 22, RA 31, RA 32, RA 61, and RA62.
The SGSNPOOLALLOW parameter is used to enable or disable the SGSN pool feature. If the SGSN
pool feature is enabled on the BSC side, the packet temporary mobile subscriber identity (P-TMSI)
reallocation function must be enabled on the SGSN side.
SGSN Pool Procedure
The SGSN pool procedure varies, depending on the MS status.
Scenario A: If SGSN 1 is being offloaded and an MS registered to SGSN 1 initiates a PS service
request, the SGSN pool procedure is as follows:
Before the call is set up, SGSN 1 allocates P-TMSI 1 to the MS. In P-TMSI 1, the NRI value
is NULL_NRI and the routing area identity (RAI) value is Non-broadcast RAI.
The MS initiates an RA update upon receiving the Non-broadcast RAI from SGSN 1.
The BSC obtains the NULL_NRI from TLLI 1 and routes the service request of the MS to an
available SGSN based on the load balancing algorithm.
The SGSN allocates P-TMSI 2 to the MS.
Scenario B: If an MS has not been sending or receiving anything for a prolonged period of time, the
SGSN pool procedure is as follows:
TEP
Confidential
The MS initiates a periodic RA update with TLLI 1. The BSC routes the LLC frame of the MS
to SGSN 1.
SGSN 1 allocates P-TMSI 2 to the MS. In P-TMSI 2, the NRI value is NULL_NRI and the
RAI value is Non-broadcast RAI.
Upon receiving the Non-broadcast RAI, the MS initiates an RA update, replacing TLLI 1 with
TLLI 2.
Since SGSN 1 is being offloaded and the NRI value in TLLI 2 is NULL_NRI, the BSC
distributes the MS to another SGSN that is functioning properly. The P-TMSI reallocation for the MS is
complete.
Scenario C: If an MS has been powered off for a long time, it initiates an RA update when powered on
again. In this case, the SGSN pool procedure is as follows:
If SGSN 1 is still being offloaded, the MS is reallocated a P-TMSI in the same procedure as
when an MS has not been sending or receiving anything for a prolonged period of time.
If SGSN 1 is no longer being offloaded, it continues to serve the MS without allocating a new
P-TMSI to the MS.
After offloading is complete in the SGSN pool, need to set SGSNSTATUS of SGSN 1 to ALLOW(Allow).
Otherwise, new MSs cannot register with SGSN 1.
8.2.2
SGSN POOL Planning
Non-Overlapping Deployment
In non-overlapping deployment, the same SGSN belongs to only one SGSN pool, and the same BSC is
served by only one SGSN pool.
As shown in the figure below, SGSN pool 1 serves BSCs 1 through 4, and SGSN pool 2 serves BSCs 5
through 7. SGSNs in different SGSN pools can use the same NRI. Within an SGSN pool, however, each
SGSN must have a unique NRI, and the length of the NRI is the same for all SGSNs in the same SGSN pool
area. An SGSN can derive the IP addresses of the other SGSNs based on their NRIs and distinguish
between intra-SGSN and inter-SGSN service requests based on the NRI and RAI combination.
TEP
Confidential
Non-overlapping deployment
Negotiation parameter Planning:

SGSN_POOL_ALLO
W
Length of NRI in PTMSI
Yes
6
SGS
NRI to SGSN mapping
N1
SGSN Capacity(K
Users)
NULL-NRI
SGS
N2
SGS
N3
1800
1800
3600
11
NSVL and PTPBVC Planning:

Gb Interface
BSC
BSC
NSV
L Local
IP
Loca
l UDP
Port No.
Subnetw
ork Configure
Mode
NSV
L Remote
IP
Remot
e UDP Port
No.
Cell
PTPBVC
SGS
N
NSE
ID
BVC
I=1
SGS
N1
NSE
1
Static
BVC
I=2
SGS
N2
NSE
2
Static
BVC
I=3
SGS
N3
NSE
3
Static
Note:
When add PTP BSSGP virtual connection (PTP BVC) for a cell, please keep the same BVC Index for all
different SGSN Node.
TEP
Confidential
8.3 Iu-Flex
8.3.1
Introduction
Iu Flex is an extended function of RAN. The 3GPP TS 23.236 defines Iu Flex as follows: "Intra-domain
Connection of Radio Access Network (RAN) Nodes to Multiple Core Network Nodes."
The Iu Flex (WRFD-021302 Iu Flex) brings in the concept of "pool area". A pool area contains one or
more MSC/SGSN service areas. In a pool area, the UE roams freely without changing the serving CN node.
The Iu Flex enables a RAN node to route information to different CN nodes, implementing the load balance
among MSCs or SGSNs.
Iu Flex is introduced in 3GPP R5. With Iu Flex, one RAN node can be connected to several CN nodes
and these CN nodes can form a pool area. The UEs in the same pool area do not need to change the
serving CN node.
The introduction of Iu Flex avoids the imbalance of resource usage among different CN nodes in
different traffic peak hours and achieves the load balancing among several CN nodes in the WCDMA
network.
In a traditional network structure, a RAN node only needs to know whether the destination is the CS
domain or the PS domain before sending information. It does not need to discriminate specific CN nodes
because a RAN node is connected to only one CN node.
With Iu Flex, however, one RNC can connect to several MSCs/SGSNs physically, where CS nodes and
PS nodes form different pool areas. Therefore, a RAN node can send information to different CN nodes in
the CS or PS domain and achieve load balancing among several CN nodes in the pool area.
The pool area is described as follows:
A pool area is a collection of one or more MSC or SGSN serving areas. One or more CN nodes can
provide services in parallel and these CN nodes share the traffic in the pool area.
Pool areas may overlap. RAN nodes belong to all the overlapping pool areas.
The CS pool area is independent of the PS pool area.
If a UE roams in a certain pool area, it does not need to change the serving CN node.
The Iu Flex feature enhances network reliability, achieves load balancing, and reduces UE roaming
signaling.
A RAN node service area contains all the cells controlled by the RAN node. A pool area is a collection of
one or more RAN node service areas. It is served, in parallel, by one or more CN nodes that share the traffic
of this area.
A UE is served by one dedicated CN node in a pool area as long as the UE is under the radio coverage
of the pool area. Pool areas can overlap each other. If several overlapping pool areas cover a same RAN
node service area, the RAN node service area belongs to these pool areas. The pool areas of the CS
domain and those of the PS domain are configured independently with the granularity of RAN node service
areas.
In a pool area, the UE roams freely without changing the serving CN node. The RAN node service area
can belong to the same pool area or several pool areas.
TEP
Confidential
Pool area configuration example
CS pool area 1: includes RAN node areas 1, 2, 5, 6, and MSC servers 1, 2, and 3, which provide
service for the RAN node areas.
CS pool area 2: includes RAN node areas 2, 3, 6, 7, and MSC servers 4, 5, and 6, which provide
service for the RAN node areas.
PS pool area 1: includes RAN node areas 1 and 5, and SGSNs 1 and 2, which provide service for
the RAN node areas.
PS pool area 2: includes RAN node areas 2, 3, 6, 7, and SGSN 3, 4, and 5, which provide service for
the RAN node areas.
8.3.1.1 NRI
The Network Resource Identifier (NRI) identifies the CN node that serves a pool area. The NRI has a
flexible length from 0 bit to 10 bits. 0 bit means no Iu flex. The NRI lengths are the same for all the CN nodes
in one pool area.
In areas where pool areas overlap, the NRI identifies the CN node that serves these overlapping pool
areas. For overlapping pool areas, the NRI lengths must be configured the same for all the nodes serving
specific pool areas.
The CN nodes in the CS domain and those in the PS domain are addressed separately, so the NRIs of
the CS and PS domains are independent of each other.
The NRI is a part of the Temporary Mobile Station Identity (TMSI) for the CS domain, or of the Packet
TMSI (P-TMSI) for the PS domain. The TMSI or P-TMSI is assigned to the UE by the serving CN node. The
TMSI or P-TMSI allocation mechanism of the CN node generates TMSIs or P-TMSIs with NRIs determined
by certain bits.
TEP
Confidential
The association between the NRIs and the CN nodes in the CN pool area is configured on the RAN
nodes.
In the WCDMA system, the UE provides an intra domain NAS node selector (IDNNS) in the access
stratum (AS) part of the Initial Direct Transfer message to the RAN node. The IDNNS contains a routing
parameter with a fixed length of 10 bits. This routing parameter contains the NRI information. In addition, the
IDNNS contains the identity that indicates the source of the routing parameters. The identity can be TMSI/PTMSI, international mobile subscriber identity (IMSI), international mobile equipment identity (IMEI), and so
on. The RAN node masks the significant bits out of the routing parameter part of the IDNNS to determine the
NRI that is used to identify the relevant CN node. The most significant bit of the NRI corresponds to the most
significant bit of the routing parameter in the IDNNS. A routing parameter containing the identity of IMSI is in
range of 0 to 999 (calculated by (IMSI div 10) mod 1000) and is called IMSIROUTE in this document. The
association between IMSIROUTE and the CN nodes in the CN pool area is configured on the RNC.
8.3.1.2 NullNRI
NullNRI is a special value of the NRI, which indicates that the CN node identified by the NRI is to be
offloaded. On receiving a message carrying NullNRI, the RNC starts the IDNNS function to select an
appropriate CN node. NullNRI can be unique in a Public Land Mobile Network (PLMN) or set separately in
the CS domain and PS domain.
8.3.1.3 Non-broadcast LAI/RAI
Non-broadcast Location Area Identity (LAI) or Routing Area Identity (RAI) is different from the normal
LAI/RAI in the network. It is used in the scenario that the CN node is to be offloaded.
The UE will immediately initiate Location Update or Route Area Update after receiving the Nonbroadcast LAI/RAI.
8.3.1.4 NNSF
The NNSF performs the selection of a CN node and the processing of the IMSI Paging Message in both
the CS and PS domain.
In the RAN node, the NNSF selects a specific CN node (MSC server or SGSN) and routes the initial
NAS signaling message to the selected CN node.
If a CN node address configured for the NRI can be derived from the initial NAS signaling message, the
NNSF routes the message to the CN node. If no CN node address is configured for the derived NRI or no
NRI can be derived (for example, the UE indicates an identity that contains no NRI), or the configured CN
node cannot be reached, the NNSF selects an available CN node based on load balancing and routes the
message to the selected CN node.
The procedure for NNSF is as follows:
1.
CN Node allocates route information to the UE.

If CN supports the Iu Flex, the CN indicate the NRI in the TMSI or P-TMSI when allocating the TMSI or
P-TMSI to the UE.
2.
UE indicates the route information and sends it to the RNC in the Initial Direct Transfer message.
3.
RNC selects the CN Node based on the routing information in the Initial Direct Transfer message.
8.3.2
Iu Flex service process
The Iu Flex service process is as follows (taking the PS domain as an example).
TEP
Confidential
Iu Flex service process
1.
2.
The MS accesses the network through the RAN1, and provides the IDNNS to the RAN1.
The RAN1 obtains the corresponding SGSN based on the IDNNS, and then connects the MS to the
SGSN1.
3.
The SGSN1 sends its NRI to the MS when the MS access is completed.
4.
The MS moves to the area served by the RAN2.
5.
When the MS requests to access the network though the RAN2, the MS provides the IDNNS to the
RAN2, containing the SGSN1 NRI.
6.
The RAN2 finds the SGSN1 that serves the MS originally, and then connects the MS to the SGSN1
that serves the MS at the first time of network access.
When a UE is moving within a Pool area, the UE can be continuously served by a certain CN node.
Therefore, the location update process between the SGSNs is avoided, and the network load is reduced.
8.3.3
Load Balancing
Load Balancing (WRFD-021306 Iu Flex Load Distribution Management) describes how the NNSF
balances the load between the available CN nodes.
The RNC selects a CN node from the available CN nodes based on the load balancing principle. Load
balancing occurs in one of the following situations:
There is no CN node configured for the NRI or IMSIROUTE indicated by the UE.
The CN node corresponding to an NRI or IMSIROUTE cannot be reached.

TEP
Confidential
The CN node corresponding to an NRI or IMSIROUTE is inhibited.
No NRI or IMSIROUTE can be derived.
The value of the NRI is NullNRI.

Based on the load balancing principle, the RNC records the capability of each CN node which is
configured to the NORMAL state and is not in overloaded, and then selects a CN node based on
randomization function for the UE.
Assume that the RNC is connected to three MSCs in NORMAL state (identified as MSC A, B, and C)
and their available capabilities are 10, 20, and 10, respectively. Among the UEs accessing in load balancing
condition, 25% of UEs are routed to MSC A, 50% of UEs are routed to MSC B, and 25% of UEs are routed to
MSC C, according to the rules of load balancing. Other UEs are routed to the specific CN nodes identified by
the NRI.
NOTE:
If a CN node whose available capacity is 0 is identified by a valid NRI and the route parameters of a UE
include the NRI, the UE will still be routed to the CN node.
The capability of the CN node is acquired in the following way:
Static capability
The static capability of the CN node is specified by the AvailCap of the ADD UCNNODE command in the
RNC.
8.3.4
Load Re-Distribution
There are situations where a network operator needs to remove load from one CN node (for example, to
perform scheduled maintenance, upgrade or load re-distribution to avoid overload), with minimal impact on
end users, or additional load on other entities, or both.
Load Re-Distribution helps to re-distribute UEs to other CN nodes. There are two ways to implement
load re-distribution:
Load re-distribution based on NullNRI
Load re-distribution based on blocking CN node

8.3.5
Iu-Flex Planning
Negotiation parameter Planning

For CS Domain:
CS_NRI_CFGMODE
SUPP_IUFLEX
CS NRI Length
6
CNI
NRI to CN Node
Mapping
D=1
CS Domain Node
Capacity(K Users)
CS NULL-NRI
CNI
D=2
1800
1800
3600
10
For PS Domain:
TEP
PS_NRI_CFGMODE
SUPP_IUFLEX
PS NRI Length
6
Confidential
CNI
D=3
CNI
D=1
NRI to CN Node
Mapping
PS Domain Node
Capacity(K Users)
PS NULL-NRI
CNI
CNI
D=2
D=3
1000
1000
2000
Remote
IP
Address1
Remote
IP
Address2
11
signal plane
RNC
Local IP
Address1
RNC
Local IP
Address2
Local SCTP
Port No.
MSC/SGSN
MSC/SGSN1
MSC/SGSN2
MSC/SGSN3
Remote
UDP Port
No.
user plane
No IPPATH needed, user plane working as an IP POOL
8.4 S1-Flex
8.4.1
S1-Flex Overview
S1-Flex means that an eNodeB sets up S1-MME connections with multiple MMEs of an operator. These
MMEs form an MME pool. When a UE accesses an eNodeB, the eNodeB selects an MME for the UE and
sets up a dedicated S1 interface.
The functions of S1-Flex are as follows:
If a UE moves within an MME pool area, the serving MME is not changed, lowering the signaling overhead.
The MME pool provides load balancing, increasing the sharing gain.
The network is easy to manage. For example, the network topology is easy to adjust, minimizing the impact
on existing services. It is easy to add or delete MMEs.
The MMEs of an MME pool are mutually redundant, improving network reliability. Each eNodeB is connected
to multiple MMEs. This requires that the eNodeB can route the signaling messages from the UE to the
correct MME. Therefore, S1-Flex includes the following technologies:
Selecting an MME pool
Selecting an MME within an MME pool
MME load re-balancing
MME overload processing

8.4.2
Networking and Principles
S1-Flex affects the eNodeB networking and configurations.

TEP
Confidential
Networking
In normal networking, each eNodeB is connected to an MME. With S1-Flex, the eNodeB networking is
changed in that an eNodeB is connected to multiple MMEs.
Figure 2
The preceding figure is an eNodeB networking diagram with enabled S1-Flex. There are two concepts
that need to be elaborated:
MME pool area and MME pool
An MME pool area consists of one or multiple tracking areas (TAs).
An MME pool consists of one or multiple MMEs that serve the same MME pool area.
For example, if a UE moves within MME POOL 1 shown in the preceding figure, the serving MME is not
changed.
In order for each MME in an MME pool to serve the same MME pool area, each MME in the MME pool
must be connected to all the eNodeBs in the MME pool area; each eNodeB must be connected to all the
MMEs in the MME pool area.
In this scenario, the eNodeB may provide only one network cable but is logically connected to multiple
MMEs.
Principles
How does an eNodeB select an MME pool?
Each eNodeB may be in multiple MME pool areas and is connected to all the MMEs in each MML pool.
The eNodeB selects an MME pool for the UE based on the network topology so that if the UE moves later,
the probability of changing the serving MME is minimal. The eNodeB obtains the network topology through
the X2 interface. The principle is that the eNodeB selects the MME pool that is connected to the most
eNodeBs.
How does an eNodeB select an MME?
The eNodeB selects an MME from an MME pool based on load sharing, effectively utilizing the
processing capability of the EPC. Different MMEs have different processing capabilities. The MME informs
the eNodeB of this capability at the time of S1 interface setup. The eNodeB selects an MME based on the
relative capacity of an MME and the number of dedicated connections that this MME has with the eNodeBs.
The probability of selecting an MME has a positive correlation with the relative capacity of the MME and a
negative correlation with the number of S1 interfaces that this MME has with the eNodeBs.
An eNodeB sets up an S1-MME connection with all the MMEs in the MME pool and maintains the
relative capacity information of each MME. The eNodeB counts in real time the number of S1 interfaces that
the eNodeB has with the MMEs. If an MME is overloaded and its relative capacity is 0, this MME is not
placed at the candidate MME list and is not selected.
8.4.3
Basic Configurations
S1-Flex requires that each eNodeB is connected to multiple MMEs and that the eNodeB can route the
UE signaling messages to the correct MME. That is, the eNodeB needs to set up an S1-MME connection
with each MME to route the signaling messages to the correct MME. Therefore, the following configurations
are required by the S1-Flex:
TEP
Confidential
1.
License. An eNodeB needs the license to enable S1-Flex. Run DSP LICENSE to
display the license configurations. If the value of the Allocated parameter is 1 for S1-Flex, S1-Flex can be
enabled on the eNodeB; if the value of the Allocated parameter is 0, S1-Flex cannot be enabled on the
eNodeB.
2.
Parameters to be negotiated with the multiple MMEs, including the following: MCC,
MNC, TAC, SCTP port number, IP address, MME version number (R8 or R9).
3.
SCTP links between an eNodeB and each of the multiple MMEs. The following
examples add multiple SCTP links:
ADD SCTPLNK: SCTPNO=0, SN=7, LOCIP="10.10.10.10", LOCPORT=2910, PEERIP="11.11.11.11",
PEERPORT=2910, AUTOSWITCH=ENABLE;
ADD SCTPLNK: SCTPNO=1, SN=7, LOCIP="10.10.10.10", LOCPORT=2910, PEERIP="11.11.10.10",
PEERPORT=2910, AUTOSWITCH=ENABLE;
4.
IP routes between the eNodeB and the multiple MMEs if the multiple MMEs are not
in the same network segment.
5.
S1 interfaces. The following examples add S1 interfaces and map the SCTP links
that an operator has to the operator.
ADD S1INTERFACE: S1InterfaceId=0, S1SctpLinkId=0, CnOperatorId=0;
ADD S1INTERFACE: S1InterfaceId=1, S1SctpLinkId=1, CnOperatorId=0;
After finishing the basic configurations of S1-Flex, run DSP S1INTERFACE to display the SCTP links of
the operator. If the SCTP links are normal, S1-Flex has been configured.
At present, the eNodeB supports a maximum of 16 connected MMEs.
8.4.4
Flex at the User Plane
A more popular scenario is that an eNodeB is connected to multiple S-GWs. In contrast to S1-Flex, the
eNodeB is connected to the S-GWs of multiple EPCs. This scenario is described as follows:
To connect an eNodeB with multiple S-GWs, configure multiple IP paths for the eNodeB. The MME
notifies the eNodeB of the S-GW address over the INITIAL UE CONTEXT SETUP message when the UE
initiates a service. If the IP path to the S-GW is configured on the eNodeB, the eNodeB can set up a userplane link to the S-GW.
Two logical IP addresses can be configured on each S-GW because the S-GW has two CPUs, each of
which has a logical IP address.
The two logical IP addresses provide load sharing. Two IP paths are recommended.
The MME notifies the eNodeB of the unified gateway (UGW) address. The EPC determines which IP
path to use. You need to configure two IP paths on the eNodeB.
Therefore, Flex at the user plane can be used for one S-GW that has two CPUs.
8.5 Transmission SON Feature

The transmission SON feature indicates the automatic setup function of S1 and X2 interfaces. The
automatic setup function enables an eNodeB to set links such as SCTP links, IP paths, and IPSec
information. Manual operation is not required. In terms of protocol layer, the automatic setup is divided into
automatic setup at the control plane and automatic setup at the user plane. In terms of transport network, it is
divided into automatic setup in secure scenarios and that in non-secure scenarios.
8.5.1
Automatic Setup Process
The following describes the automatic setup process of S1 and X2 interfaces, including configuration of
SCTP links, IP paths, and IPSec information:
1. After being powered on, the eNodeB performs self-check and automatic negotiation. Based on automatic
negotiation, it can obtain the information such as the duplex mode and peer device IP address.
2. The eNodeB obtains the OMCH configuration through DHCP packets and sets up the OMCH with an NMS
(such as the M2000).
TEP
Confidential
3. The eNodeB downloads the software and configuration information, including the information about the S1
interface, through the OMCH. Based on the information, the S1 interface between the eNodeB and
MME/SGW is automatically set up.
4. The eNodeB obtains the information about the X2 interface through the S1 interface or OMCH. Based on the
information, the X2 interface is automatically set up.
8.5.2
S1 Interface Automatic Setup
The S1 interface automatic setup is implemented in a non-secure scenario according to the design.
Automatic Setup in a Non-Secure Scenario
The process of S1 interface automatic setup in a non-secure scenario is similar to Automatic Setup
Process .In the process, an OMCH is first set up between the eNodeB and the M2000. Then, the eNodeB
obtains configuration files and reads data about the signaling plane and the user plane to set up links.
Data about the signaling plane that the eNodeB needs to read is the configuration data for parameters
SCTPHOST and SCTPPEER. The eNodeB starts SCTP link automatic setup using the first local signaling IP
address configured in the SCTPHOST and the first signaling IP address configured in the SCTPPEER. The
eNodeB establishes a dual-homed SCTP link if the second local signaling IP address is available in
SCTPHOST and the second signaling IP address is available in SCTPPEER.
Compared with the automatic setup at control plane, the automatic setup at user plane supports manual
and automatic configuration of SGW objects.
1. Manual configuration of SGW objects: Users need to configure SGW information by running the ADD
USERPLANEHOST and ADD USERPLANEPEER commands. That is, after the DHCP process, the eNodeB
obtains the service IP addresses in the MOs USERPLANEHOST and USERPLANEPEER. Then, an IP path
is automatically generated.
2. Automatic configuration of SGW objects: Users do not need to manually configure SGW information.
Only USERPLANEHOST needs to be configured. When the first UE of the eNodeB initiates a service
access, the MME delivers the Initial Context Setup Request, which contains the SGW IP address, to the
eNodeB. Then, the eNodeB establishes an IP path towards the SGW based on the service IP address in
USERPLANEHOST and the obtained SGW IP address
8.5.3
X2 Interface Automatic Setup
Similar to the S1 interface, the X2 interface automatic setup involves X2-C interface automatic setup at
the control plane and X2-U interface automatic setup at the user plane respectively. The X2 interface
automatic setup varies according to the configuration method of theX2eNodeB object, as described in the
following:
1.
If X2eNodeB is manually configured, the X2 interface is set up by configuring

parameters SCTPPEER and USERPLANEPEER. In this scenario, users need to manually add multiple
X2eNodeB objects for multiple X2 interfaces.
2.
If X2eNodeB is not configured, the X2 interface is set up by configuring the

GlobalProcSwitch.X2SonLinkSetupType parameter. There are two setup modes, X2 over S1 and X2 over
M2000.
In both modes, GlobalProcSwitch.X2SonLinkSetupSwitch must be set to ON.
X2 Interface Automatic Setup (SCTPPEER and USERPLANEPEER Not Configured)
X2 over S1
In X2 over S1mode, the MME collects the configuration information about neighboring eNodeBs. This
mode applies to eNodeBs, regardless of which telecom operator they belong to and which NMS they are
managed by. The mode is recommended. The process is described as follows:
The source eNodeB uses ANR to collect or users manually configure information about neighboring cells,
including the global eNodeB ID of a neighboring cell. Intra-RAT neighbor relationships can be manually
configured by configuring MOs UTRANINTRAFREQNCELL and EUTRANINTERFREQNCELL.
1.
After an S1-based handover is triggered, the source eNodeB reports the global ID of
the destination eNodeB and the source eNodeB X2 information to the MME.
TEP
Confidential
2.
The MME forwards the information sent by the source eNodeB to the destination
eNodeB. After the destination eNodeB receives the information, it sends the IP address of its X2 interface to
the MME. The MME sends the X2 IP address of the destination eNodeB to the source eNodeB.
8.6 Faults Detection Mechanism

The Ethernet fault detection mechanisms, including physical detection, ETH OAM, BFD, ARP, and IP
PM, apply to different layers in the Ethernet protocol stack. These mechanisms aim at improving network
reliability.
Following figure shows the fault detection mechanisms supported by different protocol layers.
8.6.1
BFD
The network equipment requires that communication faults between adjacent systems are detected
rapidly. If a fault occurs, a temporary channel can be quickly established, or the data can be switched over to
other links. BFD is a means to quickly detect link faults.
BFD is a type of high-speed independent Hello protocol. It is used to detect the transmission accuracy of
Ethernet, Multiprotocol Label Switching (MPLS), IP Security Protocol (IPsec) tunnels, and common routing
encapsulation. In addition, it can detect faults and trigger fault isolation within tens of milliseconds to
minimize service losses.
When a fault is detected, active and standby ports are switched over or IP rerouting is triggered by BFD.
This avoids packet losses and call drops, improving the reliability of the BSC.
BFD can detect faults quickly without adding a large amount of extra load, and BFD messages can be
used as heartbeat messages in BFD mode. If the system transmits several BFD messages over a link but
does not receive any response messages, the link is faulty.
BFD is a handshake protocol. BFD messages are periodically transmitted based on the negotiation
result to detect the link connectivity. If the system does not receive any BFD messages from the peer end for
a long time, the link is disconnected. The figure below shows the BFD message exchange when the link is
disconnected.
TEP
Confidential
After a BFD session is set up, the system periodically transmits BFD control messages in asynchronous
BFD mode. If the peer end receives BFD control messages within the detection time, the BFD session is in
the UP state. Otherwise, the BFD session is in the DOWN state.
BFD is classified into single-hop BFD (SBFD) and multi-hop BFD (MBFD). The BSC supports BFD on
the A, Abis, Gb interfaces and SBFD will be deployed on these interfaces.
8.6.1.1 SBFD
SBFD applies only to the direct connection where both ends are on the same network segment. It has
the following characteristics:
SBFD must be started at both ends simultaneously. The detection duration at the two ends must be
similar.
The port status is associated with the detection status. If a fault is detected, port switchover is
triggered and the routes whose next hop is the detected address are deleted. Then, the upper-layer services
select other available routes.
Independent port detection is supported.

Currently, the BSC will only use SBFD on the active port and in asynchronous mode.
If an SBFD session is shut down during SBFD, the BSC automatically disables the routes whose nexthop IP address is the peer IP address of the failed SBFD session. If SBFD is configured to be applicable only
TEP
Confidential
to the active port and WHETHERAFFECTSWAP is set to YES, an SBFD link fault triggers a port switchover.
Otherwise, an SBFD link fault does not trigger a port switchover, but the availability of the related routes is
affected.
SBFD requires that both the BSC and its peer devices support BFD.
8.6.2
ARP Detection
The working principle of ARP detection is similar to that of SBFD detection. ARP detection uses the ARP
mechanism, where, after sending an ARP request to the peer end, the local end determines link connectivity
according to the ARP response from the peer end
The BSC periodically sends an ARP request to the network. The destination IP address of the request is
the peer IP address to be detected. The BSC determines the link connectivity based on whether it receives
an ARP response from the destination. If the BSC receives this ARP response, the link is normal. If the BSC
does not receive an ARP response from the destination for certain consecutive periods, the link is faulty.
ARP detection applies only to a direct connection where the IP addresses of both ends are on the same
network segment. ARP detection can be used only when the peer equipment does not support BFD.
NOTE:
ARP messages are broadcast messages. If the BSC and Layer 3 devices are directly connected,
broadcast storms will not occur. If the BSC and the Layer 3 devices are not directly connected, broadcast
storms are likely to occur.
The characteristics of ARP detection are as follows:
ARP detection does not depend on peer equipment. A single end can start the ARP detection.
The port status is associated with the detection status. If a fault is detected, port switchover is
triggered and the routes whose next hop is the detected address are deleted. Then, the upper-layer services
select other available routes.
Independent port detection is supported. When boards work in active/standby mode, ARP detection
can be performed only on the active port or on the active and standby ports simultaneously.
The IP addresses of the active and standby ports cannot be in the same network segment. The
BSC6910 does not support ports working in active/standby mode.
The differences between ARP detection and BFD are as follows:
ARP detection takes longer to detect a fault than BFD.
BFD detection requires support from both ends of the link to detect faults whereas ARP detection
does not.
When the ARP detection result shows that a link is faulty, the corresponding routes are triggered to
be unavailable. When this occurs, a port switchover can also be triggered by data configuration. This function
is similar to that provided by SBFD.
ARP detection and SBFD are used to:
Detect the connectivity of the link between the BSC and the gateway when routers are configured.
Detect the connectivity of the link between the BSC and the peer equipment when the BSC and the
peer equipment are directly connected. Generally, the peer equipment is core network (CN) equipment.
8.6.3
Binding Relationship Between SBFD/ARP and IP Route
When SBFD or ARP detection is performed, each SBFD or ARP detection task must be bound with an
IP route.
For each pair of source and destination IP addresses, only one SBFD or ARP detection task can be
started. Also, the source IP address must be the port IP address, and the destination IP address must be on
the same network segment as the source IP address.
TEP
Confidential
If detection is started on an independent port or an active port, the route whose next hop is the
destination IP address is automatically selected as the detected route.
SBFD or ARP detection started on the active port is classified into key detection and common detection.
If key detection detects a fault on the active port and does not detect a fault on the standby port, a port
switchover is triggered. Common detection does not trigger a switchover.
If a fault is detected on the independent port, the route bound with this detection is faulty.
If a fault is detected on the active port:
When a port switchover is not triggered, the route bound with this detection is automatically
disabled, and will not be selected as a detected route.
When a port switchover is triggered, the route is switched over to the standby port.
8.6.4
SBFD/ARP Design in VRRP Networking Mode
In Virtual Router Redundancy Protocol (VRRP) networking mode, a master router is selected from
routers according to specified criteria. The master router forwards data packets and uses its virtual MAC
address as the SBFD/ARP source address for the host to respond. Other routers function as backup routers.
The master router communicates with backup routers by periodically sending VRRP multicast packets so
that the backup routers learn the status of the master router in real time. In most cases, backup routers do
not forward the data packets that are meant for the virtual MAC address. If the master router is faulty and the
backup router does not receive VRRP messages at a specified interval, the backup router takes over the
services handled by the master router. In this manner, the continuity and reliability of communications are
ensured.
VRRP networking mode
The virtual IP address in a VRRP networking mode does not support BFD detection. As shown in the
figure above, the BSC uses VRRP IP2 (virtual IP address) as the next-hop IP address for communication.
Please note that VRRP IP2 cannot be used as the source or destination IP address for SBFD detection
because routers are configured.
In this case, only key ARP detection can be used to detect the connectivity of the link between IP1 and
VRRP IP2. In addition, common SBFD detection can be used to detect the connectivity of the communication
link, with IP1 (port IP address) used as the source IP address and IP3 or IP4 (port IP address of the router)
used as the destination IP address. At the same time, the router starts to detect the BSC. Therefore, the
router can perform a VRRP switchover once a link is faulty. In addition, the BSC detects whether VRRP IP2
is faulty and determines whether to switch over the port that is connected to the router.
In summary, the rules below should be followed and the preferred detection scheme also attached:
TEP
Confidential
1, Two SBFD will be configured for the active port on BSC, and the next hop IP address on
RT1/RT2(IP112/IP113) should be used as destination IP addresses for detecting. And the SBFD is
configured to affect port switchover (WHETHERAFFECTSWAP is set to YES), which means that SBFD link
fault will trigger a port switchover.
2, ARP detection will be configured for the ports on standby board and the destination IP address for
detection should be the VRRP virtual IP address (IP110), also, its necessary to have an IP address on the
ports of standby board when ARP detection is deployed(add the IP address on standby port by MML
command: STR IPCHK;)
3, By default, BFD detection on the BSC lasts 300 ms (100 ms x 3).
4, The default ARP detection duration must be changed into 30s (10s x 3 times = 30 seconds). Quick
detection is not required on the standby port.
Preferred Fault Checking Scheme
Suggested Fault detection mechanism to achieve the fault recovery less than 1s:
1Dual SBFD detection will be enabled on the active port//SBFD1 to RT1(IP112) and SBFD2 to
RT2(IP113)
2ARP detection will be enabled on standby port//ARP to VRRP Virtual IP110, IP addresses must be
configured by MML command: STR IPCHK
8.6.5
eNodeB Transmission Detection Mechanism
Transmission
Fault
Detection
Mechanism
Usage
Strengths and
Weaknesses
GTPU
detection
GTP-U monitors
S1 and X2 links at
the user plane in
the application
layer through
control packets.
Strength: IP path
fault detection
and problem
location
TEP
Confidential
Requirement
Recommended
Scenarios
None
Recommended
8.7 System Reliability

The BSC6910 system reliability is ensured by the following features:
High-reliability architecture design

Port trunking technology is employed on the active and standby switching boards. The ports in a port
trunking group work in load sharing mode. When a link between the SCUb boards in different subracks is
faulty, the system transfers the services carried on the faulty link to other links and isolates the faulty link. In
addition, the SCUb boards in different subracks are cross-connected, preventing a port failure on the SCUb
board in one subrack from affecting the SCUb boards in another subrack. This improves the reliability of
intra-controller communication.
Dual clock planes are used in the clock transmission between the GCUa/GCGa board and the SCUb
board. Therefore, a single failure does not affect the normal operation of the system clock.
Resource pool design

The system implements load sharing on the control plane and on the user plane by employing a full
resource pool design. This effectively prevents suspension of service in case of overload, improving resource
utilization and system reliability.
Active/standby switchover
All BSC6910 hardware supports active/standby switchover. Quick switchover between active and
standby parts improves system reliability. In addition, quick fault detection and recovery minimizes the impact
of faults on services.
Flow control
The system performs flow control based on the central processing unit (CPU) and memory usage.
Therefore, the BSC6910 can continue working by regulating the items pertaining to performance monitoring,
resource auditing, and resource scheduling in the case of CPU overload and resource insufficiency. In this
way, the system reliability is enhanced.
8.8 Hardware Reliability

The BSC6910 hardware reliability is ensured by the following features:
The system uses the multi-level cascaded and distributed cluster control mode. Several CPUs form a cluster
processing system. The communication channels between CPUs are based on the redundancy design or
anti-suspension/breakdown design.
The system uses the redundancy design, as described in Table 2-4, to support the hot swap of boards and
backup of boards and ports. Therefore, the system has a strong fault tolerance capability.
An isolation mechanism is used. When entity A fails to accomplish a task, entity B that has functions identical
to entity A takes over the task. Meanwhile, entity A is isolated until it is restored.
When a board with a single function is faulty, you can restart the board.
All boards support dual-BIOS. BIOS is short for basic input/output system. Faults in one BIOS do not affect
the startup or operation of the boards.
The system uses the nonvolatile memory to store important data.
With advanced integrated circuits, the system features high integration, sophisticated technology, and high
reliability.
All the parts of the system have high quality and pass the aging test. The hardware assembly process is
strictly controlled. These methods ensure high stability and reliability for long-term operation.
Board redundancy mode:
TEP
Board
Redundancy Mode
EGPUa
Board resource pool
Confidential
Board
EXOUa
Board redundancy + board resource pool + 10 Gbit/s GE

port redundancy or load sharing
EOMUa
Board redundancy
ESAUa
Independently configured
GOUc
8.8.1
Redundancy Mode
Board redundancy + board resource pool + GE port

redundancy or load sharing
GCUa/GCGa
Board redundancy
SCUb
Board redundancy + port trunking on GE ports
Board Redundancy
8.8.1.1 Backup of EXOUa/GOUc Boards

Two EXOUa/GOUc boards work in board backup mode, one EXOUa/GOUc board is active and the
other is standby. The standby board synchronizes data with the active board in real time.
Automatic Switchover
The active and standby EXOUa/GOUc boards can be switched over only when either of the following
conditions is met:
The active EXOUa/GOUc board is reset, but the standby EXOUa/GOUc board works properly.
The active EXOUa/GOUc board is faulty, but the standby EXOUa/GOUc board works properly.
Switchover Process
When the active and standby EXOUa/GOUc boards are switched over, the active EXOUa/GOUc board
becomes standby after being reset, and the standby EXOUa/GOUc board becomes active.
Impact of Switchovers on the System
The impact of switchovers on ongoing services will not affected due to the strategy of active/standby
Ethernet port trunking mode on the active and standby boards
8.8.1.2 Backup of SCUb Boards
Two SCUb boards are installed in adjacent active and standby slots in a BSC6910 subrack, the two
boards work in 1+1 backup mode.
SCUb boards are configured to work in active/standby mode, either of the two boards can be active
when they start up. Generally, the SCUb boards perform maintenance, management, and GE/10GE
switching in the local subrack. And the active SCUb board processes the maintenance and management
data, and the GE/10GE switching data is processed by both active and standby SCUb boards.
The active and standby SCUb boards can be switched over only when one of the following conditions is
fulfilled:
The active SCUb board is reset, and the standby SCUb board works properly.
The active SCUb board is faulty, and the standby SCUb board works properly.
The clock source of the active SCUb board is faulty, and that of the standby SCUb board works
properly.
Impact of Switchover on the System
When the active and standby SCUb boards are switched over, services are not affected.
TEP
Confidential
8.8.1.3 Backup of EOMUa Boards

Two EOMUa boards are installed in adjacent active and standby slots in the BSC6910 MPS, the two
boards work in 1+1 backup mode.
The active and standby EOMUa boards are automatically switched over only when one of the following
conditions is fulfilled:
The standby EOMUa board cannot detect the heartbeat information about the active EOMUa board
for five consecutive minutes.
The active EOMUa board cannot detect the virtual IP address for three consecutive minutes, but the
standby EOMUa board works properly.
Both the active and standby EOMUa boards work properly for one period, and no switchover occurs
during the period.
Impact of Switchover on the System
A switchover between the active and standby EOMUa boards temporarily interrupts the OM network, but
does not affect the services of the BSC6910. The OM network automatically recovers after the switchover.
8.8.1.4
Resource Pool and Warm Backup of EGPUa Boards
The EGPUa board provides the following logical functions: RMP for resource management, UCUP for
UMTS service processing, and GCUP for GSM service processing. The redundancy mode of the EGPUa
board varies depending on its logical type.
i.
Backup of RMP-Type EGPUa Boards

In the BSC6910, a pair of RMP-type EGPUa boards are configured in adjacent slots of the MPS to work
in 1+1 backup mode.
The active and standby EGPUa boards can be switched over only when either of the following
conditions is met:
The active EGPUa board is reset, but the standby EGPUa board works properly.
The active EGPUa board is faulty, but the standby EGPUa board works properly.
A switchover between the active and standby EGPUa boards does not affect ongoing services.
ii.
Resource Pool of EGPUa Boards Whose Logical Type is GCUP

The EGPUa boards whose logical type is GCUP work in resource pool mode, all the EGPUa boards
process services. Among these services, control plane (CP) services are backed up by standby subsystems
on these boards, whereas user plane (UP) services are not backed up. When a CP subsystem or board is
faulty, CP services can be restored based on backup data, and UP services must be reestablished.
An automatic switchover is triggered only when one of the following conditions is met:
The active EGPUa board is reset, but the EGPUa board where the standby CP subsystem is located
works properly.
The active EGPUa board is faulty, but the EGPUa board where the standby CP subsystem is located
works properly.
The active CP subsystem is reset, but the EGPUa board where the standby CP subsystem is located
works properly.
TEP
Confidential
The active CP subsystem is faulty, but the EGPUa board where the standby CP subsystem is
located works properly.
If a GCP subsystem is faulty, the resulting switchover does not affect established services or new
services.
If an EGPUa(GCUP) board is faulty, the GUP subsystem does not work in backup mode. This affects
all established services and services that are being established but has no impact on new services.
During the switchover, some standby CPU subsystems are switched over to the active state. As a
result, the usage of these CPUs significantly fluctuates for 10 to 20 minutes and service load balancing is
performed. After the switchover, the CPU usage becomes stable.
8.8.2
Port Redundancy
8.8.2.1 Ethernet Port Trunking

Ethernet port trunking for all interface boards will work in active/standby mode.
In active/standby mode, ports in a trunk group work in active/standby mode. If the active port is faulty,
data flows are automatically switched over to the standby port. Therefore, the total capacity of the trunk
group is not affected.
Use the MML command: ADD ETHTRK and ADD ETHTRKLNK to establish a trunk group. The trunk
group uses one IP address for external communication.
If a GE/FE/10GE link in a trunk group is faulty, data flows carried on the link are automatically switched
to other GE/FE/10GE links. All data flows carried by a trunk group use one IP address. Therefore, faulty links
in the group are invisible and they do not affect ongoing services.
8.8.2.2 Impact of Port Faults on the System
When a port in a trunk group is faulty, ongoing services are not affected.
8.9 Software Reliability

The BSC6910 software reliability is ensured by the following features:
Scheduled check on crucial resources

The software check mechanism checks various software resources in the system. If resources are out of
service because of software faults, this mechanism can release abnormal resources and generate related
logs and alarms.
Task monitoring
When the software is running, internal software faults and some hardware faults can be monitored
through the monitoring process. The monitoring process monitors the task running status and reports errors
to the O&M system.
Data check
The software integrity check and digital signature technique are used to prevent the software from being
tampered with during the transmission and storage.
The software performs scheduled or event-driven data consistency checks, restores data selectively or
preferably, and generates logs and alarms.
TEP
Confidential
Data backup
Both the data in the OMU database and the data of other boards can be backed up to ensure data
reliability and consistency.
Operation log storage

The system automatically records historical operations into logs. The operation logs help in locating and
rectifying the faults caused by misoperations.
TEP
Confidential
9.1
Feature Deployment
2G Feature Categorization
The proposed 2G feature divide into 3 categories, the category definition as below:
A: Basic Feature (must have)
B: Optional Feature (good to have)
C: Special Feature (limited to have)
Feature Type
CS Service
PS Service
CS Service
CS Service
Network
Performance
Network
Performance
Network
Performance
Network
Performance
Network
Performance
Network
Performance
Network
Performance
Power Saving
Power Saving
Power Saving
Power Saving
Power Saving
Power Saving
Topology and
Transmission
Topology and
Transmission
Topology and
Transmission
Topology and
Transmission
Topology and
Transmission
Topology and
Transmission
O&M Experience
O&M Experience
TEP
Functionalities
AMR
EDGE MCS1-9
Enhanced Full Rate
HR
Vendor
response
A
A
B
A
TrFO
B
Co-BCCH cell
C
AMR FR/HR Dynamic Adjustment
A
PDCH Dynamic Adjustment
A
PS Power Control
A
Discontinuous Transmission (DTX)-Downlink
A
Discontinuous Transmission (DTX)-Uplink
TRX Power Amplifier Intelligent Shutdown
Active Backup Power Control
Power Optimization Based on Channel Type
PSU Smart Control
Dynamic Cell Power Off
TRX Working Voltage Adjustment
A
B
B
C
C
B
C
Synchronous Ethernet
B
Abis over IP
A
Abis IP over E1/T1
C
Abis MUX
B
Abis IPHC
B
GBFD-150201 A over IP Based on Dynamic Load Balancing
A
Support BTS Automatic Configuration and Planning(one on
OSS)
Suoport BTS Automatic Capacity Planning(one on OSS)O
Confidential
C
C
O&M Experience
Security
Security
O&M Experience
O&M Experience
PS Service
Value-added Service
Value-added Service
Topology and
Transmission
Topology and
Transmission
Topology and
Transmission
9.2
Support BTS Automatic Neighbor Cell Planning and

Optimization(one on OSS)
A5/1 Ciphering Algorithm
Extended UL TBF
Location Base Services
Cell Broadcast
C
A
B
C
C
B
C
A
A flex
Gb flex
Gb over IP
A5/3 Ciphering Algorithm

2G/3G Neighboring Cell Automatic Optimization
Radio Measurement Data Interface for Navigation
3G Feature Categorization
Feature Type
HSPA Service
HSPA Service
HSPA Service
HSPA Service
HSPA Service
HSPA Service
Topology and
Transmission
Topology and
Transmission
Topology and
Transmission
Topology and
Transmission
Topology and
Transmission
Topology and
Transmission
Topology and
Transmission
Topology and
Transmission
Topology and
Transmission
Network
Performance
Network
Performance
TEP
Functionalities
HSDPA 7,2 Mbps
HSDPA 10,2 Mbps
HSDPA 14,4 Mbps
HSDPA 21 Mbps (64QAM)
HSDPA 42,2 (64QAM+DualCarrier)
HSUPA 2ms TTi & 5.76Mbps
Vendor
response
A
A
A
A
B
B
IuPS over IP
IuCS over IP
Iu Flex
Iu Flex Load Distribution Management
Iub over IP (Hybrid)
Dual Iub
Iub over IP (full IP)
Synchronous Ethernet
PDCP Header Compression (RoHC)
AMR-WB (Adaptive Multi Rate Wide Band)

AMR/WB-AMR Speech Rates Control
Confidential
C
C
Network
Performance
HSPA Service
HSPA Service
HSPA Service
HSPA Service
HSPA Service
HSPA Service
HSPA Service
HSPA Service
HSPA Service
HSPA Service
Network
Performance
HSPA Service
HSPA Service
HSPA Service
HSPA Service
HSPA Service
HSPA Service
Network
Performance
Network
Performance
Mobility
Mobility
Mobility
Mobility
Mobility
Mobility
TFO/TrFO
HSUPA Introduction Package
HSUPA UE Category 1 to 7
HSUPA HARQ and Fast UL Scheduling in Node B
HSUPA Admission Control
HSUPA Power Control
HSUPA Mobility Management
HSUPA DCCC
HSUPA Transport Resource Management
Interactive and Background Traffic Class on HSUPA
B
A
B
A
A
A
A
A
A
A
HSUPA Adaptive Transmission
Dynamic CE Resource Management

HSUPA Iub Flow Control in Case of Iub Congestion
HSUPA FDE
Adaptive Configuration of Traffic Channel Power offset
for HSUPA
Anti-Interference Scheduling for HSUPA
Dual-Threshold Scheduling with HSUPA Interference
Cancellation
HSPA+ Downlink 42Mbps per User
A
B
C
Downlink 64QAM
Potential User Control

Load Based GSM and UMTS Handover Enhancement
Based on Iur-g
NACC Procedure Optimization Based on Iur-g
GSM and UMTS Load Balancing Based on Iur-g
GSM and UMTS Traffic Steering Based on Iur-g
Inter-RAT Handover Based on Coverage
Inter-RAT Handover Based on DL QoS
B
B
B
B
C
C
C
C
A
B
LTE Feature Categorization
9.3

Feature Type
Functionalities
Radio Management
Logical Channel Management
Radio Management
Transport Channel Management
Radio Management
Physical Channel Management
Radio Management
Integrity Protection
Radio Management
DL Asynchronous HARQ
Radio Management
UL Synchronous HARQ
Radio Management
RRC Connection Management
Radio Management
Radio Bearer Management
TEP
Confidential
Vendor
response
A
A
A
A
A
A
A
A
Radio Management
Broadcast of system information
Radio Management
Random Access Procedure
Radio Management
Paging
Radio Management
Cell Access Radius up to 15km
Radio Management
Admission Control
Radio Management
Congestion Control
Radio Management
Basic Scheduling
Radio Management
Uplink Power Control
Radio Management
Dynamic Downlink Power Allocation
Radio Management
DRX
Mobility
Mobility Management
Mobility
Coverage Based Intra-frequency Handover
Mobility
Coverage Based Inter-frequency Handover
Mobility
Cell Selection and Re-selection
Radio Management
Radio Management
Radio Management
Static Inter-Cell Interference Coordination

Downlink Static Inter-Cell Interference Coordination
Uplink Static Inter-Cell Interference Coordination
Radio Management
Antenna Configuration
Radio Management
UL 2-Antenna Receive Diversity
Reliability
Reliability
Reliability
Main Processing and Transport Unit Cold Backup
A
A
A
B
C
C
A
A
A
A
A
A
A
A
C
C
C
B
B
B
C
Reliability
Cell Re-build Between Baseband Processing Units
Reliability
SCTP Multi-homing
Reliability
Intra-baseband Card Resource Pool(user level/cell level)
Basic Service
Support of UE Category 1
Basic Service
Emergency Call
O&M Experience
Local Maintenance of the LMT
O&M Experience
Centralized Management
O&M Experience
Security Socket Layer
O&M Experience
Software Version Upgrade Management
O&M Experience
Hot Patch Management
O&M Experience
Fault Management
O&M Experience
Configuration Management
O&M Experience
Performance Management
A
A
A
A
A
A
A
A
A
A
O&M Experience
Real-time Monitoring of System Running Information
O&M Experience
Security Management
O&M Experience
Optimized eNodeB Commissioning Solution
O&M Experience
Environment Monitoring
O&M Experience
Inventory Management
O&M Experience
Network
Performance
Network
Performance
Network
Performance
License Management
A
A
A
A
A
DL 2x2 MIMO
UL 64QAM
UL Interference Rejection Combining
TEP
Confidential
Network
Performance
Network
Performance
Network
Performance
Service QoS
Dynamic Inter-Cell Interference Coordination
Downlink Dynamic Inter-Cell Interference

Coordination
Uplink Dynamic Inter-Cell Interference Coordination
Service QoS
Enhanced Scheduling
CQI Adjustment
Dynamic Scheduling
B
B
B
Service QoS
Robust Header Compression (ROHC)
Service QoS
B
C
C
C
Mobility
Active Queue Management(AQM)

Enhanced Admission Control
Radio/transport resource pre-emption
LoCation Services(LCS)
PS Inter-RAT Mobility between E-UTRAN and
UTRAN
PS Inter-RAT Mobility between E-UTRAN and
GERAN
Intra-LTE Load Balancing
Mobility
Inter-RAT Load Sharing to UTRAN
Mobility
Mobility
SON
Inter-RAT Load Sharing to GERAN

Service based inter-RAT handover to UTRAN
Service based inter-RAT handover to GERAN
CS Fallback to UTRAN
CS Fallback to GERAN
Remote Electrical Tilt Control
Adaptive Power Consumption
RF Channel Intelligent Shutdown
Power Consumption Monitoring
Automatic Neighbour Relation (ANR)
Inter-RAT ANR
Self-configuration
C
C
C
C
C
C
B
C
B
B
C
B
SON
Mobility Robust Optimization (MRO)
SON
PCI Collision Detection & Self-Optimization
SON
Sleeping Cell Detection
SON
Antenna Fault Detection

Encryption: AES
IPSEC
Enhanced Transport QoS Management
Transport Resource Overload Control
IP Performance Monitoring
Transport Dynamic Flow Control
Different Transport Paths based on QoS Grade
B
C
C
C
B
B
C
C
S1 flex Introduction
Service QoS
Service QoS
Service QoS
Service QoS
Mobility
Mobility
Mobility
Mobility
Mobility
Site Solution
Site Solution
Site Solution
Site Solution
SON
SON
Secuity
Secuity
Transmission QoS
Transmission QoS
Transmission QoS
Transmission QoS
Transmission QoS
Topology and
Transmission
C
C
C
Note:
1)
TEP
For more details of feature description and activation guidance, please refer to LLD.
Confidential
2)
Recommended Feature please refer to the column comments from ET Value is Y,P and
Y(with Condition) in the file attached as below:
RAN Featue
Table_20131213 with ET Comments.xlsx
10
Clock Synchronization Design
10.1 Overview
The requirement for clock synchronization on different base stations of different standards can be met
through various methods, such as physical clocks (such as the building integrated timing supply system
(BITS) clock, WAN clock, and synchronous Ethernet clock) and recovery clocks (such as the Communication
Engineering Standard Adaptive Clock Recovery (CES ACR)/Data Clock Recovery (DCR), and 1588v2 clock).
1588v2 is defined as a time synchronization protocol. 1588v2 ensures high-precision time
synchronization between devices, and now is also used in clock synchronization between devices.
This is the network's requirement for clock synchronization. Network clock synchronization consists of
time synchronization and frequency synchronization.
Frequency Synchronization
Frequency synchronization, namely, clock synchronization, refers to strict relationship between signals
based on a constant frequency offset or phase offset, in which signals are sent or received at an average
rate in an epoch. In this manner, all devices in the communications network operate at the same rate. That
is, the difference of phases between signals is a constant value.
Time Synchronization
TEP
Confidential
Time synchronization, namely, phase synchronization, refers to consistency of both frequencies and
phases between signals. That is, the phase offset between signals is always 0.
For different wireless communications systems, the synchronization requirements are different.
Wireless
Communications Systems
Clock Frequency
Accuracy Clock
Phase Synchronization
Requirement
GSM
0.05ppm
NA
WCDMA
0.05ppm
NA
TD-SCDMA
0.05ppm
3us
CDMA2000
0.05ppm
3us
WiMax FDD
0.05ppm
NA
WiMax TDD
0.05ppm
1us
LTE-FDD
0.05ppm
NA
The clock system and the clock source are not required when the BSC provides only the Ethernet ports
(FE/GE), so in this chapter we only need to design BTS Clock synchronization solution.
And for SingleRAN BTS, it requires frequency synchronization.
The basic requirements for frequency synchronization in SingleRAN are as follows:
The precision of the reference clock must be less than 0.05 ppm.
In co-transmission through backplane interconnection scenarios with a separate-MPT base station, the main
control board of the primary mode obtains clock signals form a shared port and then transfers the signals to
other main control boards through the backplane (including the inter-BBU UCIU). Other main control boards
use the peer mode clock as the reference clock. The secondary mode cannot directly obtain IEEE 2588v2
clock signals.
In this project, Huawei will deploy Clock over IP(1588V2 unicast) for all regions. The table below shows
the difference and QoS requirement of these two solutions.
TEP
Confidential
Table 1.1.1.I.1.2.1.1 Decision tree for the base station synchronization clock selection
Synchr
onization
Solution
1588V2
unicast
Advantage
Disadvantage
There is no
requirement on the bearer
network.
The HUB base
station scenario is
supported.
The cost is high and the

CLK server must be configured.
Much service bandwidth
is occupied. The service
bandwidth for each NodeB is 16.5
kbit/s by default, and the
maximum bandwidth for each
NodeB is 66 kbit/s.
Application Scenario
Recommended
solution (default).
This solution is used
when line clocks and
BITS clocks do not exist
near the NodeB.
The planning of the

configuration is relatively
complex.
The clock quality is
vulnerable to the delay, jitter, and
packet loss of the network.
Ethernet
synchroniz
ation
This solution
does not occupy service
bandwidth.
Neighboring devices must

support the Ethernet
synchronization.
The planning of
the configuration is
simple.
Backup solution.
This solution is used
when neighbor devices of
the NodeB support the
Ethernet synchronization
and the clock error rate is
less than 0.05 ppm.
This solution is
not vulnerable to the
effect of delay, jitter, and
packet loss on the
intermediate network.
The HUB base
station scenario is
supported.
Notes:
On the base station side, it is recommended that IEEE 1588v2 packets be carried on logical IP
addresses.
It is commended that two IP clock servers be configured as the active and standby reference clocks for
the base station to enhance equipment reliability.
If an Ethernet reference clock is used, it is recommended that Synchronization Status Message (SSM)
field be used.
Requirements on the QoS of the bearer network for implementing IP-based clock synchronization
TEP
Technology
Counter
Counter Value
IEEE 1588 V2
Delay
Jitter
60 ms
< 20 ms
Packet loss
rate
< 1%
Confidential
Remarks
/
A sharp jitter results in a large
frequency offset between the
eNodeB and the reference clock.
If the frequency precision exceeds
0.05 ppm, the clock is unlocked.
If the packet loss rate is high,
the loss of clock packets carrying
timestamps results in a large
frequency offset.
Technology
Synchronous
Ethernet
Counter
Frequency
precision of
input clocks
Counter Value
Better than 16
ppb
Remarks
If the packet loss rate is high,
the loss of negotiation packets
and keepalive packets results in
clock link interruption.
The data bearer network has
no QoS requirement for the
synchronous Ethernet. According
to the G8262 protocol, the
precision of the input clock
frequency should be better than
4.6 ppm.
This does not meet eNodeB
frequency precision requirements.
10.2 IEEE 1588 V2 Clock Synchronization

The IEEE1588 V2 clock synchronization is one of the IP-based clock synchronization solutions. It
applies to the Ethernet transport network and is described in the feature GBFD-118620 Clock over IP support
1588v2. Huawei GSM BSS complies with the IEEE 1588 V2 standards. It can work with the clock server that
complies with the IEEE 1588 V2 standards to provide high-accuracy synchronization clock signals for IPbased BTSs.
IEEE1588 V2 is a precise clock synchronization protocol. It is also called the Precision Time Protocol
(PTP). IEEE1588 V2 messages are transmitted between the master and slave devices to calculate the time
and frequency offsets. In this way, the time and frequency of the master and slave devices are synchronized.
Huawei BTSs support only frequency synchronization when using IEEE1588 V2.
The IEEE1588 V2 frequency synchronization does not require a TC or BC, shown as below:
The IEEE1588 V2 clock synchronization networking requires a clock server and a clock client. The BTS
serves as the clock client. Upon obtaining the reference clock from another device (such as the GPS or
BITS), the clock server sends an IP packet with a time stamp to the BTS. When the BTS receives the time
stamp, it eliminates the delay using an adaptive method to obtain the reference clock that meets the clock
accuracy requirements.
To use the IEEE1588 V2 solution on the GBTS, set the ClkType parameter to IP_TIME(IP Clock), and
the CLKPRTTYP parameter to PTP(PTP Protocol).
TEP
Confidential
Typical IEEE1588 V2 clock synchronization networking
The IEEE1588 V2 solution supports two types of clock synchronization networking: unicast and
multicast.
Huawei suggest IPCLK Server working as unicast in Layer 3 from IPCLK server to MBTS.
In unicast networking, the clock server sets up a clock link to each MBTS for transmitting IP packets
containing clock synchronization information, as shown in figure below:
Unicast networking in the IEEE1588 V2 solution
10.2.1
IPClock Server Capacity and Bandwidth
Hardware of the IPCLK3000

IPCLK3000 is composed of a clock board QW33PCKS, a power module, fans, and an embedded
TEP
Confidential
satellite card.
The IPCLK3000 is 1U case-shaped equipment that complies with the IEC60297 standard. Appearance
of IPCLK3000 is shown in figures below.
Appearance of IPCLK3000 (DC power)
Power Input Ports
Electrical Specification:
Service Ports
IPCLK3000 provides four service ports, supporting PTP and synchronous Ethernet services. Each
service port can connect a maximum of 512 clients.
Table 3-3 describes the service ports on the IPCLK3000.
Note: IPCLK3000 does not support 100M optical modules and it is advisable not to forcibly configure
100M optical modules.
Clock Signal Input Ports
The IPCLK3000 supports the following types of clock sources:
Building integrated timing supply system (BITS) clock
External 8 kHz clock, which is a standard 8 kHz clock provided by an external device
TEP
Confidential
Global Positioning System (GPS) /Global Navigation Satellite System (GLONASS) clock
External 1PPS (1 pulse per second)+TOD clock
The BITS clock is further categorized into the following types:
2xE1 inputs (2.048 Mbit/s or 2.048 MHz balanced signal inputs)
2xE1 inputs (2.048 Mbit/s or 2.048 MHz unbalanced signal inputs)
2xT1 inputs (1.544 Mbit/s or 1.544 MHz balanced signal inputs)
2x10 MHz inputs
Through software configuration, multiple types of clock signals can be imported to the input ports on the
IPCLK3000. Table below describes the types of clock signals that can be imported to each port. At a time,
only one type of clock signal can be imported to a port.
The IPCLK3000 supports built-in rubidium (RB) clocks and oven controlled crystal oscillator (OCXOs).
When a GPS source is traced, clock accuracy complies with ITU-T G.811 and time accuracy is less than 100
ns. Even when the external reference source is lost, the built-in rubidium clock of IPCLK3000 can have a
frequency holding precision of 1x10-11/day and a time holding precision of 1 s/day.
As an IP clock server, the IPCLK3000 sends IP clock packets to a base station so that the base station
can parse the clock packets and recover the clock from the packets. IPCLK3000s can recover clocks from IP
clock packets only if intermediate networks transporting the packets have a jitter less than 20 ms and a
packet loss rate less than 1%.
The IPCLK3000 can send IP clock packets to a maximum of 2048 home APs at the same time at the
following frequency:
For the IEEE 1588v2 protocol, you can set the packet sending frequency to 1/16, 1/8, 1/4, 1/2, 1, 2, 4, 8, 16,
32, 64, 128, or 256 packets per second. In unicast mode, the packet transmission interval can be up to 128
packets per second. In multicast mode, the packet transmission interval can be up to 256 packets per
second. Under default configurations (16 packets per second), keep the bandwidth for sending the IP clock
packets at 12kbit/s for each base station. Ensure that the bandwidth does not exceed 190kbit/s in a poor
network environment.
The IP clock time packets bandwidth calculation shown as the table below:
TEP
Confidential
Clock Performance Specifications

Table 2-1 describes the clock performance specifications for the IPCLK3000.
O&M
The O&M system of the IPCLK3000 uses a customized man-machine interface based on the ManMachine Language (MML) and Graphical User Interface (GUI).
Figure below shows the O&M system of the IPCLK3000.
TEP
Confidential
The O&M system of the IPCLK3000 provides the following two consoles:
LMT
The LMT is applicable to local and remote maintenance. It is used to maintain a single IPCLK3000 from
aspects such as software upgrade, data loading, alarm data collection, and equipment maintenance.
M2000
The M2000 is applicable to remote maintenance. It is used to maintain multiple IPCLK3000s on the
network level from aspects such as software upgrade, data loading, alarm data collection, and equipment
maintenance.
NOTE
Local maintenance refers to the O&M process during which the maintenance personnel log in to the
IPCLK3000 by directly connecting an LMT to the local Ethernet port on the IPCLK3000.
Remote maintenance refers to the O&M process where the maintenance personnel in an equipment
room or at a network maintenance center configure IP routes on the LMT or M2000 to log in to the
IPCLK3000 remotely.
Planning data of IPClock3000
The onsite planning data for the IPCLK3000 includes network IP addresses and clock sources.
O&M
1+1 IPCLK Server
IPCLK3000 Server Active

IPCLK3000 Server
Standby
Clock source Planning:

Items
TEP
IP
address
IP
address
for LMT
PC
Servi
ce IP
address
(FE/GE1)
Servi
ce IP
address
(FE/GE2)
Servi
ce IP
address
(FE/GE3)
Servi
ce IP
address
(FE/GE4)
Value
Description
Confidential
GPS, BITS, or 8 kHz/1PPS clock.

If the clock source is set to the BITS or 8
kHz/1PPS
clock, you should also set each port for signal
input of
each clock source.
Clock switching mode
Free, Manual, Auto

If the mode is set to Manual, you should also
set the
number of the port from which the clock is
extracted.
GPS parameters
Working mode of the satellite card

Mask angle
Feeder delay
Clock source type
11
Time Synchronization Design
11.1 Time Synchronization Introduction

The NTP time synchronization network determines the reference time for the network and uses the
reference time to specify how device nodes communicate with each other. The characteristics of The Time
Synchronization are as follows:
The time synchronization of a mobile network is implemented through the NTP/SNTP protocols.
Time synchronization means making the time deviation between the telecommunications
equipments and the Coordinated Universal Time (UTC) time as small as possible (eg.100ms).
The time synchronization network is in the customer/server mode. It uses hierarchical time
servers to ensure the time synchronization of the entire network. Usually, the time synchronization sources
come from the standard time sources.
TEP
Confidential
In the RAN Network, time synchronization ensures the time synchronization of the network elements
(NEs) and the M2000. M2000 needs to record the time when a fault alarm or event alarm is generated to
analyze the event and the performance.
The M2000 server uses Solaris 10 and supports the NTP features based on NTPV3 protocol versions.
By setting the parameters in the file /etc/inet/ntp conf on the Solaris operating system, use to set the M2000
server as an NTP client in the mobile network. Specify an IP address for the NTP server that the M2000
server gains access to, the M2000 server can obtain the time synchronization information from the specified
NTP server. In addition, you can configure the M2000 administration console as an intermediate time server.
The OMU serves as the NTP client to synchronize the time on each NE node and each module of RAN
Network. After the OMU obtains the reference time from the specified NTP server, the OMU BAM delivers
the time to each element to realize time synchronization.
11.2 Time Synchronization Resource

Choose the Internet time synchronization according to the network requirements.
Time Synchronization Resource
M2000/NTP Server
Interface Type
FE/GE
12
TEP
Acronyms and Abbreviations
BITS
CN
DHCP
DSCP
ESN
eNodeB
E-UTRAN
FE
GE
GPS
IP
IPDV
IPLR
IPPM
IPSec
IPTD
LMT
MAC
MGW
MSC
Building Integrated Timing Supply System

Core Network
Dynamic Host Configuration Protocol
Differentiated Service Code Point
Electronic Serial Number
LTE base station
Evolved Universal Terrestrial Radio Access Network
Fast Ethernet
Gigabit Ethernet
Global Positioning System
Internet Protocol
IP Packet Delay Variation
IP Packet Loss Rate
IP Performance Monitor
IP Security
IP Packet Time Delay
Local Maintenance Terminal
Medium Access Control
Media Gateway
Mobile services Switching Canter
PPP
QoS
SCTP
VLAN
VRRP
IMS
EPC
Point-to-Point Protocol
Quality of Service
Signaling Control Transmission Protocol
Virtual Local Area Network
Virtual Route Redundancy Protocol
IP Multimedia System
Evolved Packet Core
Confidential
TEP
Confidential

6 HLD For RAN v10

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

6 HLD For RAN v10

Încărcat de

Drepturi de autor:

Formate disponibile

The High Level Design for RAN

The High Level Design for RAN

HUAWEI TECHNOLOGIES CO., LTD.

ethio telecom TEP

Updated as ETs suggestion

Updated as ETs suggestion

Updated as ETs suggestion

Updated to 5 BSC and 5 RNC

Updated LTE site number and OMC

Target Network Design............................................................................................................................... 3

Current Network Analysis..................................................................................................................... 3

2G Sites Distribution in Current Network (AA Region)......................................................................3

3G Sites Distribution in Current Network (AA Region)......................................................................3

Existing BSC/RNC Information......................................................................................................... 3

Existing OMC Information................................................................................................................. 6

Activated Features in Current Network............................................................................................. 6

Target Network Design........................................................................................................................ 7

BSC/RNC Homing Relationship....................................................................................................... 8

BSC6910 Product Information.......................................................................................................... 8

GSM BSC6910 Dimension Design.................................................................................................10

UMTS BSC6910 Dimension Design...............................................................................................16

LTE Network and Capacity Design.................................................................................................... 26

LTE Sites Distribution in Target Network (AA Region)....................................................................26

Interface capacity design................................................................................................................... 26

MBTS Homing Allocation Design....................................................................................................... 29

2G BTS Allocation Design.............................................................................................................. 29

3G NodeB Allocation Design.......................................................................................................... 30

Hardware Distribution Design................................................................................................................... 31

Hardware Distribution Principle.......................................................................................................... 31

BSC6910 Board Layout..................................................................................................................... 31

BSC6910 GSM Board Layout......................................................................................................... 31

BSC6910 UMTS Board Layout....................................................................................................... 33

BSC6910 Power Consumption.......................................................................................................... 33

BSC6910 Boards Overview............................................................................................................... 34

BSC6910 Boards Introduction........................................................................................................ 34

BSC6910 Interface Board Layout................................................................................................... 39

eNodeB Hardware Introduction.......................................................................................................... 43

BBU Boards Overview.................................................................................................................... 44

BBU and RRU Layout..................................................................................................................... 53

2G System Signal Flow...................................................................................................................... 55

User Plane Signaling Flow.............................................................................................................. 55

Control Plane Signaling Flow.......................................................................................................... 56

3G System Signal Flow...................................................................................................................... 58

User Plane Signaling Flow.............................................................................................................. 58

Control Plane Signaling Flow.......................................................................................................... 60

eNodeB Naming Design.................................................................................................................... 63

Cell Naming Design........................................................................................................................... 64

O&M Network Design............................................................................................................................... 65

RAN O&M Network Topology............................................................................................................. 65

M2000 Software Structure and Interface........................................................................................69

BSC6910 OMU Design...................................................................................................................... 73

OMU Port Design........................................................................................................................... 73

2G O&M Bandwidth Requirements.................................................................................................74

3G O&M Bandwidth Requirements.................................................................................................74

BSC/RNC OMU IP Plan and configuration.....................................................................................75

LTE O&M Design............................................................................................................................... 78

eNodeB OM IP Address Design..................................................................................................... 78

eNodeB OMCH Design.................................................................................................................. 78

NTP Synchronization Design.......................................................................................................... 79

Interface Interconnection Design.............................................................................................................. 80

Interconnection Solution Description..............................................................................................80

Requirements for Interconnection................................................................................................... 84

Interconnection Solution Description..............................................................................................85