Professional Documents
Culture Documents
Issue
3.0
Date
2013-08-05
2013-11-1
1 , 113
Huawei Technologies Co., Ltd. provides VTR with comprehensive technical support and service. For any assistan
please contact our local office or company headquarters.
Website:
http://www.huawei.com
Email:
support@huawei.com
Notice
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Update History
Version
2013-11-1
Description
Issue date
Prepared by
Approved by
1.0
2013-06-12
Liang Xiulai
VTR
2.0
2013-07-17
Liang Xiulai
VTR
3.0
2013-08-05
Liang Xiulai
VTR
2 , 113
Contents
Contents
1 Introduction..................................................................................................................................15
1.1 Objectives....................................................................................................................................................... 15
1.2 Scopes ............................................................................................................................................................ 15
1.3 Dependencies ................................................................................................................................................. 16
1.4 Assumptions ................................................................................................................................................... 16
2013-11-1
3 , 113
2013-11-1
4 , 113
2013-11-1
5 , 113
2013-11-1
6 , 113
2013-11-1
7 , 113
Figures
Figure 3-1 Target VTR network .......................................................................................................................... 19
Figure 5-1 Topology of O&M network ............................................................................................................... 22
Figure 5-2 Logical locations of BAM IP address ................................................................................................ 23
Figure 5-3 External network of BAM connection figure .................................................................................... 24
Figure 5-4 NodeB ETHIP & OMIP..................................................................................................................... 25
Figure 5-5 NodeB OMCH policy ........................................................................................................................ 26
Figure 5-6 Configuring an OMCH ...................................................................................................................... 27
Figure 5-7 Enabling the DHCP to configure a NodeB OMCH ........................................................................... 28
Figure 5-8 RAN and M2000................................................................................................................................ 28
Figure 5-9 The content of NodeB software management.................................................................................... 29
Figure 5-10 The process of NodeB software management.................................................................................. 29
Figure 5-11 Logical line of NodeB time synchronization ................................................................................... 31
Figure 5-12 Logical line of RNC time synchronization ...................................................................................... 32
Figure 6-1 System clock stream of the NodeB.................................................................................................... 34
Figure 7-1 General board structure in a subrack ................................................................................................. 36
Figure 7-2 Internal data switching of the RNC ................................................................................................... 38
Figure 7-3 Board configuration for the RNC_RM1301 ...................................................................................... 41
Figure 7-4 Board configuration for the RNC_RM1302 ...................................................................................... 41
Figure 7-5 Board configuration for the RNC_AN201......................................................................................... 43
Figure 7-6 Board configuration for the RNC_BB801 ......................................................................................... 44
2013-11-1
8 , 113
2013-11-1
9 , 113
Tables
Table 1-1 Dependencies....................................................................................................................................... 16
Table 2-1 Numbering planning ............................................................................................................................ 18
Table 4-1 Distribution of NodeBs........................................................................................................................ 21
Table 4-2 Interface Information........................................................................................................................... 21
Table 4-3 Product Version Information................................................................................................................ 21
Table 5-1 Example for BAM IP addresses........................................................................................................... 23
Table 5-2 DSCP configuration in the IPPATH..................................................................................................... 26
Table 5-3 TCP/UDP ports of RNC ...................................................................................................................... 30
Table 5-4 TCP/UDP ports of NodeB ................................................................................................................... 30
Table 5-5 Recommended NodeB time synchronization parameters .................................................................... 31
Table 5-6 Recommended RNC time synchronization parameters ....................................................................... 32
Table 5-7 Recommended M2000 time synchronization parameters.................................................................... 32
Table 7-1 Configuration rules for the SPUa board .............................................................................................. 37
Table 7-2 SPUa board Processing Capability ...................................................................................................... 37
Table 7-3 DPUb board Processing Capability ..................................................................................................... 37
Table 7-4 Configuration rules for interface boards.............................................................................................. 39
Table 7-5 GOUc board Processing Capability..................................................................................................... 39
Table 7-6 NodeB distribution on the SPU subsystem.......................................................................................... 46
Table 7-7 NodeB distribution on the SPU subsystem.......................................................................................... 46
Table 7-8 NodeB distribution on the SPU subsystem.......................................................................................... 46
2013-11-1
10 , 113
2013-11-1
11 , 113
2013-11-1
12 , 113
Table 8-49 Throughput of the Iur interface on the control plane for BB801 ....................................................... 61
Table 9-1 User plane DSCP................................................................................................................................. 65
Table 9-2 DSCP allocation for each service ........................................................................................................ 66
Table 9-3 DSCP mapping for signaling and user part.......................................................................................... 71
Table 9-4 Requirements for Iu CS transmission QoS .......................................................................................... 71
Table 9-5 Iu PS DSCP Design ............................................................................................................................. 73
Table 9-6 TRMMAP For IUPS-1......................................................................................................................... 73
Table 9-7 TRMMAP For IUPS-2......................................................................................................................... 73
Table 9-8 Requirements for Iu PS transmission QoS .......................................................................................... 74
Table 9-9 Requirements for Iur transmission QoS............................................................................................... 76
Table 10-1 Parameters to be negotiated in the SS7 network................................................................................ 77
Table 10-2 Physical layer data of the Iu CS interface to be negotiated ............................................................... 79
Table 10-3 IP layer data of the Iu CS interface to be negotiated.......................................................................... 80
Table 10-4 SCTP layer data of the Iu CS interface to be negotiated.................................................................... 80
Table 10-5 M3UA layer data of the Iu CS interface to be negotiated.................................................................. 82
Table 10-6 SCCP layer data of the Iu CS interface to be negotiated ................................................................... 83
Table 10-7 IP path data of the Iu CS interface to be negotiated........................................................................ 84
Table 10-8 IP route data of the Iu CS interface to be negotiated ......................................................................... 84
Table 10-9 IUUP version number ........................................................................................................................ 86
Table 10-10 Physical layer data of the Iu PS interface to be negotiated.............................................................. 87
Table 10-11 IP layer data of the Iu PS interface to be negotiated ........................................................................ 88
Table 10-12 SCTP layer data of the Iu PS interface to be negotiated .................................................................. 89
Table 10-13 M3UA layer data of the Iu PS interface to be negotiated ................................................................ 90
Table 10-14 SCCP layer data of the Iu PS interface to be negotiated.................................................................. 91
Table 10-15 IP path data of the Iu PS interface to be negotiated ......................................................................... 92
Table 10-16 IP route data of the Iu PS interface to be negotiated........................................................................ 92
2013-11-1
13 , 113
2013-11-1
14 , 113
Introduction
1.1 Objectives
This document aims to describe the general network design for the building of the 3G network for VTR.
It also describes the High level design (HLD) principles for this network.
The implementation will happen in one phase, Phase 1. And this HLD refers strictly to this phase
According to the network development in the future, the HLD will be updated.
This phase is defined as commercial launch of voice and data services. The Phase 1 service offering will
support all required terminal types. At Phase 1, all cell sites required shall be operational, all services
available, and VTR will start selling subscriptions to paying customers. All support systems to run the
network, including but not limited to, customer care and subscriber provisioning shall be available.
Based on the network scale and traffic model of VTR, HLD is to reasonably design the UMTS RAN
networking to establish a UMTS network. The UMTS network has the following features:
z
HLD focuses on Huawei RAN network elements (NEs) and other NEs connected to the RAN NEs.
HLD serves as the input of low level design (LLD).
1.2 Scopes
This document involves HLD for the RNC Santiago 1, RNC Santiago 2, RNC Antofagasta and RNC
Chillan.
According to the features of the Huawei UMTS product, HLD covers RAN networking, focusing on
operation and maintenance (O&M), system clock synchronization, RAN resource distributed design,
transmission interface capability, transmission interface networking reliability, interconnection
negotiation, and common features.
2013-11-1
15 , 113
1.3 Dependencies
Table 1-1 Dependencies
Issue No.
1
Item
Description
Network scale
2
3
Site distribution
Boundary maps
Transmission network
1.4 Assumptions
This HLD is based on the following general assumptions:
2013-11-1
BOQ is correct.
The capacity of NodeBs and RNCs and the distribution information are correct.
16 , 113
2
2.1
RNC Naming
RNC_RM1301, it means the first RNC that will be located in Santiago.
RNC_RM1302, it means the second RNC that will be located in Santiago.
RNC_AN201, it means the third RNC that will be located in Antofagasta.
RNC_BB801, it means the fourth RNC that will be located in Chillan.
For example:
BAM_S20_RNC_RM1301, it means BAM on slot 20 of RNC_RM1301.
BAM_S22_RNC_RM1301, it means BAM on slot 22 of RNC_RM1301
2013-11-1
17 , 113
BAM name should be the same with the name of SQL Server installed
NodeB Naming
z
Use the existing NodeB naming rule: First letter which indicates the type of network, region
code where NodeB is located and site code.
Cell Naming
z
Use the existing cell naming rule: Name of the NodeB + Sector number.
2.2
Iub
[0,1800]]
[0,120]
Iu CS
1800
120
0
0
0
0
Iu PS
1810
130
10
10
10
10
Range
0..1999
0..149
0..118
0..118
0..118
0..63
2013-11-1
18 , 113
Uniqueness
The same IP address cannot be used at the same time by two hosts/devices in the same logic IP network.
Although MPLS/VPN technology that supports address overlap is used, it is better to plan different
addresses as much as possible.
z
Continuity
Continuous addresses are easy to aggregation in hierarchy network, this can reduce route table
significantly and improve the efficiencies of route algorithm.
z
Scalable
A certain quantity of addresses should be left at each layer for the consistency needed in address
aggregation when expanding the network.
2013-11-1
19 , 113
IDEN
ISUP
BICC
NodeBs
SG
ISUP
Mc_FE
MAP C/D_FE
MGW
Iub
IuPS
IuCS
NodeBs
IuCS_GE
MSC
IuCS_GE
RNC Santiago 01
Iub
SG
IuPS
IuCS
DNS
Gr_FE
NodeBs
RNC Santiago 02
Iub
IuPS
IuCS
GGSN
Gn_GE
IuPS_GE
Ga_GE
NodeBs
RNC Antofagasta
SGSN
Gz_GE
Iub
SUR
IuPS
IuCS
RNC Chillan
2013-11-1
HLR
PCRF
Charging
Gateway
20 , 113
396
297
15
264
Product
Version
Iu-CS
Iu-PS
Iub
Iur
Information
2013-11-1
RNC
Node B
21 , 113
2013-11-1
22 , 113
the internal network segment of RNC conflicts with the subnet number of the external network segment.
The logical locations of BAM IP address were shown below:
Figure 5-2 Logical locations of BAM IP address
Planning Principle
The preset IP addresses of the internal Ethernet adapters are:
The active BAM is 80.168.3.50 and that of the standby BAM is 80.168.3.60.
The internal virtual IP address can be set to 80.168.3.40. The preset virtual IP
address of the internal network is 80.168.3.40 (255.0.0.0).
If the external fixed IP address of the active BAM is 172.121.139.201 and that
of the standby BAM is 172.121.139.202, the external virtual IP address can be
set to 172.121.139.200.
Backup channel IP addresses The preset backup channel IP addresses of the active and standby BAMs are:
of the active and standby
Active BAM: 192.168.3.50 (255.255.255.0)
BAMs
2013-11-1
23 , 113
IP Address
Planning Principle
The IP address cannot be changed.
Commissioning IP address
2013-11-1
According to following rules to set BAM external fixed IP addresses, BAM external
virtual IP addresses
1)
Active and Standby OMUa has Ethernet adapter 0 and 1 on the panel of the board.
The two adapters are teamed as the external network team for the communication
between the BAM and the OM terminal (the LMT or M2000).This two adapters has
same external fixed IP addresses.
2)
The external fixed IP addresses of the active and standby BAMs has the same
external virtual IP address, and this external virtual IP address is setting based on
VTRs network planning.
3)
The external virtual IP address is set in the same subnet with the external fixed IP
addresses of the active and standby BAMs.
The internal subnet number of the RNC is 80 by default and the debugging subnet
number is 192 by default. If internal subnet 80 and debugging subnet 192 are used in the
VTRs network, the internal network segments of the RNC need to be modified.
24 , 113
It is recommended that the NodeB OMIP and the ETHIP be configured on the same network segment.
In this case, the ARP agent of the FE port must be enabled.
For details, see section 9.1.6 Iub Transmission Layer Address Allocation Design/NodeB Address
Planning.
Based on RNC address planning, the IP addresses for O&M and Service will be on different subnets and
VLANs.
2013-11-1
25 , 113
DSCP Design
The Differentiated Service is a method of providing different services with different transmission
priorities.
The PHB AF4 corresponding to the DSCP of the OMCH ranges from 32 to 39. For details, see the
DSCP configuration for PS and CS services. According to OMCH DSCP, it is recommended to set
OMCH DSCP to 16.
Table 5-2 shows the DSCP configuration in the IPPATH.
Table 5-2 DSCP configuration in the IPPATH
2013-11-1
IPPATH Type
DSCP
PHB
EF PATH
46
EF
AF41 PATH
34
AF41
AF42 PATH
36
AF42
AF43 PATH
38
AF43
AF31 PATH
26
AF31
AF32 PATH
28
AF32
AF33 PATH
30
AF33
AF21 PATH
18
AF21
AF22 PATH
20
AF22
AF23 PATH
22
AF23
AF11 PATH
10
AF11
AF12 PATH
12
AF12
AF13 PATH
14
AF13
BE PATH
BE
26 , 113
OMCH Configuration
Route 1: On the NodeB side, configure a route to the M2000. The next hop is the interface IP address of
the Router in VTR network that will act as Gateway.
Route 2: On the M2000, configure a route to the NodeB OMIP. The next hop is the interface IP address
of the Router in VTR network that will act as Gateway.
In addition, the routes of transmission equipment need to be configured.
Figure 5-6 Configuring an OMCH
DHCP client: indicates the host, such as, the NodeB, that uses the DHCP to obtain
configuration parameters in a network.
DHCP server: indicates the host, such as, the RNC, that returns configuration parameters to
the DHCP client in a network.
The DHCP is used to automatically establish remote NodeB maintenance channels. For example, when
a NodeB downloads incorrect configuration files or maintenance channel parameters are incorrectly
configured, including configuration loss, the NodeB can use the DHCP to automatically obtain OMCH
parameters set for the NodeB by the RNC for re-establishing a maintenance channel.
After receiving the DHCP request packet, the RNC fills the corresponding NodeB IP address to the
response packet according to the NodeB ESN in the request packet. Therefore, to enable the DHCP
normally, a correct NodeB IP address and NodeB ESN should be configured on the RNC side. In this
manner, the NodeB can obtain correct OMCH parameters (such as the NodeB IP address and gateway)
after the DHCP is enabled.
2013-11-1
27 , 113
The NodeB IP address is set through network planning and is unique in the entire network.
Each NodeB has a globally unique NodeB ESN before delivery. It can be obtained from the NodeB
label or by running the MML command: DSP BARCODE.
Figure 5-7 Enabling the DHCP to configure a NodeB OMCH
2013-11-1
28 , 113
NodeB file that includes data (such as configuration file), software, patch and log, etc. is transferred
between M2000 server, M2000 client and NodeB.
NodeB upgrade:
On the M2000, upgrading the NodeB software and patch involves multiple operations. Upgrading the
NodeB software (or patch) involves loading, activating, and synchronizing the software. If the required
software or patch is not installed on the matching NE, you can upload the file from the client to the
M2000 server, and then download the file from the server to the NE.
Figure 5-9 The content of NodeB software management
Software management of the M2000 is based on the FTP. To implement this function, the FTP server
should be set for transferring the files between the M2000 and NEs. The FTP server serves as a transit
server.
According to the OMCH policy, the NodeB is directly routed to the M2000. It is recommended to
configure the OMC (Operation and Maintenance Center) of the M2000 as the file server.
Figure 5-10 The process of NodeB software management
2013-11-1
29 , 113
21
TCP
Server
FTP
20
TCP
Server
FTP
1234
UDP
Client
SNTP client
3389
TCP
Server
6000
TCP
Server
6001
TCP
Server
Alarm console
6006
TCP
Server
6007
TCP
Server
6088
TCP
Server
Huawei-defined protocol
(remote upgrade tool)
6099
TCP
Server
6100
TCP
Server
Alarm box
16002
TCP
Server
The
port
that
actively
performance messages
rep
Table 5-4 lists the ports used for services of NodeB. It needs to enable the ports on the firewall
according to VTR requirements.
Table 5-4 TCP/UDP ports of NodeB
2013-11-1
21
TCP
Server
FTP
6000
TCP
Server
30 , 113
6001
TCP
Server
Alarm console
6006
TCP
Server
6007
TCP
Server
Recommended Value
M2000
6 hours
2013-11-1
31 , 113
Recommended Value
NTP Server
60 minutes
Recommended Value
60 minutes
NTP
Server
2013-11-1
Router
RNC
Time Synchronization
32 , 113
This chapter describes the system clock source design of the RNC and NodeB and flow directions of
relevant system clocks.
2013-11-1
33 , 113
2013-11-1
34 , 113
This chapter describes optimization design for RNC capabilities, involving board configuration, the port
controller, NodeB allocation, and signaling links allocation.
2013-11-1
35 , 113
Two adjacent odd and even slots on one side of the backplane are a pair of active and standby slots. For
example, slots 0 and 1 are a pair of active and standby slots, and slots 2 and 3 are a pair of active and
standby slots. A pair of active/standby boards needs to be configured in a pair of active and standby
slots.
The slots in which the boards of different types can be configured need to meet the board configuration
rules of the RNC. In addition, reasonable resource allocation and scalability also need to be considered.
The following section describes the distribution policy for OMUa, SCUa, SPUa, GCUa, DPUb, AOUa,
and GOUa boards.
The SPUa board can be configured in slots 0 to 5 and 8-11 in the subracks. Two adjacent odd
and even slots are a pair of active and standby slots. For example, slots 0 and 1 are a pair of
active and standby slots, and slots 2 and 3 are a pair of active and standby slots.
Considering future network development, HLD considers network expansion and evolution in advance.
Table 7-1 lists the recommended configuration rules for the SPUa board.
2013-11-1
36 , 113
The maximum configuration in RSS Subrack support 2 pairs (active/standby) boards meanwhile the RBS
Subrack support 3 pairs (active/standby).
Table 7-2 SPUa board Processing Capability
Board
Capability
Processing Capability of the n Support 100 Node B, 300 Cells and 90,000 BHCA. Each SPU
main control SPUa board
subsystem support 25 Node B, 75 Cells and 22500 BHCA.
Capability
DPUb board
2013-11-1
37 , 113
Interface boards are selectively configured in the RSS. The number of interface boards
depends on the requirement. Interface boards can be configured in idle slots (slots 14 to 19,
and slots 24 to 27) in the RSS .The boards in two adjacent odd and event slots can be or not
be a pair of active/standby boards.
Considering future network expansion and evolution, configuration interface boards from slot 27 in
descending order is recommended.
Considering the reliability, configuration interface boards in the active/standby mode is recommended.
2013-11-1
38 , 113
The subracks of the RNC are connected in the star mode. The data between any two RBSs is switched
through the RSS. If the Iu/Iur interface is configured in an RBS only and is not configured in the RSS,
the services on other RBSs are interrupted provided that the RBS or the RSS is faulty.
It is recommended to configure the Iu/Iur interface on the RSS first.
IUR
IU-CS
IU-PS
Capability
Voice Service in the CS Domain
18000 Erlang
18000 Erlang
2600 Mbit/s
18000 Erlang
18000 Erlang
2600 Mbit/s
18000 Erlang
9000 Erlang
3200 Mbit/s
2013-11-1
39 , 113
In terms of reliability, it is required to configure a pair of active and standby OMUa boards for one
RNC.
2013-11-1
40 , 113
2013-11-1
41 , 113
2013-11-1
42 , 113
2013-11-1
43 , 113
2013-11-1
44 , 113
2013-11-1
The control SPU subsystem and physical bearer can be in different subracks.
Each SPU board can be configured with up to 100 NodeBs, except the first SPU which can be
configured with 75 NodeBs.
45 , 113
SPU No.
Number of
NodeBs
SPU
Number of SPU
Number of
Subsystem NNodeBs
Subsystem NNodeBs
0/0
81
0/2
108
0/4
108
The RNC_RM1301 RNC has 8 SPUa board (4 pairs, active/standby). The below table lists the detailed
distribution of NodeBs.
Table 7-7 NodeB distribution on the SPU
SPU No.
Number of
SPU No.
NodeBs
Number of
SPU No.
NodeBs
Number of
SPU No.
NodeBs
Number of
NodeBs
0/2
84
114
84
114
0/4
1/2
1/4
The RNC_BB801 has 4 SPUa board (2 pairs, active/standby). The below table lists the detailed
distribution of NodeBs.
Table 7-8 NodeB distribution on the SPU
2013-11-1
SPU No.
Number of
NodeBs
SPU No.
Number of
NodeBs
0/2
112
0/4
152
46 , 113
The RNC_AN201 has 4 SPUa board (2 pairs, active/standby). The below table lists the detailed
distribution of NodeBs.
Table 7-9 NodeB distribution on the SPU
SPU No.
Number of
NodeBs
SPU No.
Number of
NodeBs
0/2
35
0/4
45
M3UA links belong to the M3UA signaling link set and are numbered from 0 to 63. M3UA links are
carried on SCTP links.
The MSC and SGSN are directly connected to the RNCs. Therefore, M3UA links are terminated on and
connected to the MSC and SGSN.
2013-11-1
47 , 113
Signaling
Route Mask
and
Signaling
Link Mask
Design
The RNC has only one subrack. It is recommended to configure two SCTP links on the
signaling plane between the RNC and the peer signaling
point (MSC, SGSN and NRNC).
The RNC has two or more
subracks.
VTR
has only one signaling route and it is recommended to set the signaling route mask to B0000 and the
signaling link mask to B1111.
IuCS
0/2/1
0/4/0
2
1/2/1
The
RNC_A
3
1/4/0
N201,
0
0/2/2
RNC_R IuPS
M1302
1
0/4/1
and
RNC_B
2
1/2/2
B801
have
3
1/4/1
one
subrack. Therefore, 2 SCTP links are recommended between the RNC and the MSC and SGSN, The
below table lists the configuration results.
Table 7-12 Signaling link allocation
Interface
IuCS
0/4/1
0/4/2
0/2/1
IuPS
2013-11-1
48 , 113
Interface
2013-11-1
0/2/3
49 , 113
This chapter describes how to calculate the throughput of the IuCS/IuPS/Iur/Iub interface and the
number of ports on the interface boards in the all RNC according to the traffic model provided by the
VTR. In addition, this chapter also provides recommended transmission configurations on the control
plane and user plane of each interface according to the calculated interface throughput.
Value
2710
2013-11-1
Item
Value
1683
50 , 113
Value
562
Value
2509
Value
5.20
Table 8-6 Throughput of the Iu CS interface on the control plane for RM1302
Item
Value
3.23
Table 8-7 Throughput of the Iu CS interface on the control plane for AN201
Item
Value
1.01
Table 8-8 Throughput of the Iu CS interface on the control plane for BB801
Item
Value
4.82
Note: IuCS control plane throughput (Mbps)=3%* IuCS user plane throughput (Mbps),
2013-11-1
51 , 113
1
Table 8-10 Number of active GOUc ports for RM1302
GE Active Port Number
IuCS
1
Table 8-11 Number of active GOUc ports for AN201
GE Active Port Number
IuCS
2013-11-1
52 , 113
Value
PS DL Throughput (Mbps)
2479
PS UL Throughput (Mbps)
1062
Table 8-14 Throughput of the Iu PS interface on the user plane for RM1302
Item
Value
PS DL Throughput (Mbps)
999
PS UL Throughput (Mbps)
426
Table 8-15 Throughput of the Iu PS interface on the user plane for AN201
Item
Value
PS DL Throughput (Mbps)
622
PS UL Throughput (Mbps)
267
Table 8-16 Throughput of the Iu PS interface on the user plane for BB801
Item
Value
PS DL Throughput (Mbps)
897
PS UL Throughput (Mbps)
377
Value
24.8
Table 8-18 Throughput of the Iu PS interface on the control plane for RM1302
2013-11-1
Item
Value
10
53 , 113
Table 8-19 Throughput of the Iu PS interface on the control plane for AN201
Item
Value
6.2
Table 8-20 Throughput of the Iu PS interface on the control plane for BB801
Item
Value
2013-11-1
54 , 113
IP transport Networking
IP transport can transmit the services of different QoS in different ways. IP transmission is used for
services of low QoS, such as HSDPA and HSUPA services. Figure 8-1 shows the IP transport
networking.
Figure 8-1 IP transport networking
The VTR RNC is configured with the IP interface board (GOUc). The IP interface board is connected to
the IP transmission network through the GE port.
The NodeB is connected to the IP transmission networks through the corresponding IP interface boards.
The FE networking is used in VTR.
2013-11-1
Perform transmission mapping according to Table 8-25 for user plane data.
55 , 113
Because the NodeB is directly routed to the M2000 for maintenance without passing the RNC,
the Iub interface does not have management plane data.
Value
3714
Table 8-27 Throughput of the Iub interface on the user plane in IP transmission for RM1302
Item
Value
1533
Table 8-28 Throughput of the Iub interface on the user plane in IP transmission for AN201
Item
Value
925
Table 8-29 Throughput of the Iub interface on the user plane in IP transmission for BB801
2013-11-1
Item
Value
1435
56 , 113
Value
371.4
Table 8-31 Throughput of the Iub interface on the control plane in IP transmission for RM1302
Item
Value
153.3
Table 8-32 Throughput of the Iub interface on the control plane in IP transmission for AN201
Item
Value
92.5
Table 8-33 Throughput of the Iub interface on the control plane in IP transmission for BB801
Item
Value
143.5
2013-11-1
57 , 113
NCP
48
The control plane is of the highest priority and is recommended to be carried with high DSCP.
NodeB Control Port (NCP) link between the RNC and a NodeB, which is used to transmit NodeB
Application Part (NBAP) common process messages of Iub interface. There is only one NCP link
between a RNC and a NodeB.
2013-11-1
58 , 113
CCP
48
CCP port is 0.
Communication Control Port (CCP) link between the RNC and a NodeB, which used to
transmit NodeB Application Part (NBAP) dedicated process messages of Iub interface.
There can be multiple CCP links between one RNC and one NodeB.
2013-11-1
Rx (kbps)
DSCP CBS
EBS
Physical Link 0
BW/2
AF41 PATH
Physical Link 0
BW/2
AF42 PATH
Physical Link 0
BW/2
AF43 PATH
Physical Link 0
BW/2
AF31 PATH
26
Physical Link 0
BW/2
AF32 PATH
28
Physical Link 0
BW/2
AF33 PATH
30
Physical Link 0
BW/2
AF21 PATH
18
Physical Link 0
BW/2
AF22 PATH
20
Physical Link 0
BW/2
AF23 PATH
22
Physical Link 0
BW/2
AF11 PATH
10
Physical Link 0
BW/2
59 , 113
AF12 PATH
12
Physical Link 0
BW/2
AF13 PATH
14
Physical Link 0
BW/2
BE PATH
Physical Link 0
BW/2
Bandwidth
IPPATH
100M
Note: The IPPATH configured for IUB is 100M, this is a logical value, and the limitation is just in TX side;
Value
371
Table 8-43 Throughput of the Iur interface on the user plane for RM1302
Item
Value
153
Table 8-44 Throughput of the Iur interface on the user plane for AN201
2013-11-1
Item
Value
9.3
60 , 113
Table 8-45 Throughput of the Iur interface on the user plane for BB801
Item
Value
144
Value
31.1
Table 8-47 Throughput of the Iur interface on the control plane for RM1302
Item
Value
15.3
Table 8-48 Throughput of the Iur interface on the control plane for AN201
Item
Value
Table 8-49 Throughput of the Iur interface on the control plane for BB801
Item
Value
14.4
Note: Iur control plane throughput (Mbps)=10%*Max(IUB DL control plane throughput ,IUB
UL control plane throughput )
2013-11-1
61 , 113
This chapter describes the reliability design of transmission interfaces, including the network topology
of the Iub, IuCS, IuPS and Iur interfaces, redundancy of interface boards and ports, failure detection,
QoS, transmission security design, and address allocation. This can ensure reliable and secure
transmission, detect failures in time, and differentiate priorities to guarantee high-priority services.
The Iub interface uses the IP transmission and supports IP protocol stacks. Active and standby GOUc
boards provide GE port to connect two Routers. RNC provide interface IP and logical IP for
2013-11-1
62 , 113
communication. Through PE, the RNC is connected to the IP transmission network backbone. NodeB
side, FE port is used to support connection.
2013-11-1
63 , 113
The IPPATH PING detection provides a method to check whether user plane links are normal.
The IPPATH PING detection switch is a parameter for configuring an IPPATH.
After the PING detection is enabled, the detection address of the IPPATH is periodically
pinged on the RNC side. An alarm is reported when the detection addresses cannot be pinged
for the specified times, that is, the IPPATH is unreachable. The detection address is usually
the termination address of the IPPATH on the peer side.
z
Transmission Resource mapping table for Iub, that is, the mapping between services and
transmission resources (paths). It may use the default map for Iub ATM or Iub IP.
DSCP values design for the user plane IPPATH, signaling plane SCTPLNK, and the OM in IP
transmission.
The QoS of UMTS is composed of the fields Edge-to-edge QoS links that the service
flow throughout.
VTR 3G Network is the ALL IP network. When the service flow throughout the CN
based IP. Its implemented by IP QoS in fact. The two things exist a mapping.
2013-11-1
64 , 113
Service Type
Example
Conversational
Streaming
Video Play
Interactive
Web
Background
Email, FTP
User
Gold
Silver
Bronze
Note: The service priority decrease from the top to the bottom. For Example: the Conversational has the high
priority, the same as the Gold User.
DSCP Value Design for the User Plane and Signaling Plane in IP Transmission
DSCP: The DiffServ model put forward by IETF works at the IP layer, focusing on converging data
streams and PHBs. The DiffServ model uses the TOS field in the IPV4 header and renames it the DS
field (DSCP). The DS field is defined according to the preset rules. Therefore, by identifying the DS
field, downlink nodes can obtain sufficient information to process the received data packets and
forwards them to the next node correctly. In this way, complex QoS assurance is converted into PHBs
through the DS field.
z
2013-11-1
IPPATH Type
DSCP
EF PATH
46
AF41 PATH
34
AF42 PATH
36
AF43 PATH
38
AF31 PATH
26
AF32 PATH
28
AF33 PATH
30
AF21 PATH
18
AF22 PATH
20
AF23 PATH
22
65 , 113
IPPATH Type
DSCP
AF11 PATH
10
AF12 PATH
12
AF13 PATH
14
BE PATH
Based on Huawei DSCP recommendation for Control Plane, User Plane, IPCLK Link and OM channel the DSCP
allocation for each service is like the following table.
Table 9-2 DSCP allocation for each service
2013-11-1
Service
User
PATH
DSCP
802.1q
CP
SIG (NCP/CCP)
SCTP Link
48
UP
EF PATH
Bronze
AF41 PATH
34
Sliver
AF42 PATH
36
Gold
AF43 PATH
38
Bronze
AF31 PATH
26
Sliver
AF32 PATH
28
Gold
AF33 PATH
30
Bronze
AF21 PATH
18
Sliver
AF22 PATH
20
Gold
AF23 PATH
22
Bronze
AF11 PATH
10
Sliver
AF12 PATH
12
Gold
AF13 PATH
14
All
users
BE PATH
5
46
66 , 113
IPCl
k
IP clock
IPClk Link
10
O&
M
OAM link
CS(16)
Each port can be configured with one primary Ethernet port address (ETHIP) and up to 15
secondary ETHIPs. In the case of boards and ports backup apart, however, the primary and
secondary ETHIPs are configured for the active ports only. Each port in use need to be
configured with at least the primary ETHIP.
IP addresses are determined by users according to actual network planning and belong to
the addresses of class A/B/C. An IP address consists of the network segment and host
segment. The host segment cannot be all 0s or all 1s. When the CIDR is used, the selected
IP address cannot be the invalid address under A/B/C class. In addition, an IP address
cannot start with 0 or 127.
The planned IP address and the internal IP address of the BAM cannot be on the same
network segment or on different network segments in which the inclusion relationship
exists.
DEVIP: The device IP addresses configured on the same interface board cannot be in the
same subnet. In addition, the device IP addresses configured on different interface boards
must be different. The device IP addresses must be different or be on different network
segments from the existing IP address in the RNC. The existing IP addresses include the
local/peer IP address of the PPP link, local/peer IP address of the MLPPP group, IP
address of the Ethernet port, peer address of the IPPATH, and peer address of the SCTP
link.
ETHIP: The IP addresses of different Ethernet ports or the primary and secondary IP
addresses of the same Ethernet port cannot be on the same network segment or on
different network segments in which the inclusion relationship exists. In addition, the IP
addresses of Ethernet ports must be different or be on different network segment as the
existing IP address in the RNC. The existing IP addresses include the local/peer IP address
of the PPP link, local/peer IP address of the MLPPP group, and device IP address.
In IP L3 networking, the mask length of an address on the RNC side depends on the number of required
addresses. In this case, a network segment needs to be further divided. For example, one ETHIP needs
to be on the same network segment as its gateway. If the gateway uses one IP address only, two valid
addresses are needed. In this case, the 30-bit mask can be used. If the gateway uses the VRRP, the
2013-11-1
67 , 113
gateway needs one virtual IP address and two real IP addresses. In this case, the 29-bit mask can be
used.
Based on RNC address planning, the NodeB addresses are numbered in ascending order on the same
network segment according to NodeB numbers. The NodeBs connected to the same region gateway are
continuously numbered form 1 (NodeBIP_Num, for address calculation only).
Example: RNC_RM1301 need connect 396 NodeB with one pair of GE port. Total IP address is
396*3=1188. Therefore, 21 bit mask with 2048 IP address would be proper. The IP addresses of the
NodeBs connected to this GOUc are as follows. Note that the last number of the IP address starts from 1
and some IP addresses are reserved for future use.
NodeB1 ETHIP:10.10.0.1/21
NodeB1 OMIP1:10.10.0.2/21
NodeB2 OMIP2:10.10.0.3/21
2013-11-1
68 , 113
NodeB2 ETHIP:10.10.0.4/21
NodeB1 OMIP1:10.10.0.5/21
NodeB2 OMIP2:10.10.0.6/21
2013-11-1
69 , 113
RNC marked DSCP for Signaling and Bearer from different service priority, meanwhile the CS marked DSCP
for Signaling and Bearer from its ports.
In the following picture we describe the process after the RNC add the DSCP associated to each service
in S5352, the DSCP is mapped into 802.1q value as MPLS exp.
2013-11-1
70 , 113
Link/PATH
DSCP
Service
Signaling
SCTP
48
Signing
User Data
IPPATH
46
Conversational
IPLR
IPTD
IPDV
Conversational
< 0.05%
< 10 ms
< 7 ms
Streaming
< 0.05%
< 10 ms
< 7 ms
Interactive
< 1%
< 10 ms
< 7 ms
Background
< 1%
< 10 ms
< 7 ms
2013-11-1
71 , 113
2013-11-1
72 , 113
Link/PATH
DSCP
Signing
SCTP
48
User Data
QOS IPPATH
Service
48
Signing
46
Conversational
43
Streaming
23
Interactive_ high
22
Interactive_ middle
21
Interactive_ low
Background
2013-11-1
73 , 113
Based on the QoS design, each service is associated with a DSCP that will be associated to and MPLS
exp on Datacom Switch. (IP Backbone).
2013-11-1
IPLR
IPTD
IPDV
Conversational
< 0.05%
< 10 ms
< 7 ms
Streaming
< 0.05%
< 10 ms
< 7 ms
Interactive
< 1%
< 10 ms
< 7 ms
Background
< 1%
< 10 ms
< 7 ms
74 , 113
2013-11-1
75 , 113
For the IPPATH of the Iur interface, turn on the IPPATH connectivity detection switch.
z
2013-11-1
IPLR
IPTD
IPDV
Conversational
< 0.05%
< 10 ms
< 7 ms
Streaming
< 0.05%
< 10 ms
< 7 ms
Interactive
< 1%
< 10 ms
< 7 ms
Background
< 1%
< 10 ms
< 7 ms
76 , 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
10
RAN Interconnection
Negotiation Design
This chapter mainly specifies the parameters to be negotiated at the protocol layers on the Iu CS/Iu
PS/Iub interfaces.
(11/1/2013)
Commercial in Confidence
Consistency of network ID
Page 77 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
The following figure shows the logical interconnection at the protocol layer on the Iu CS interface.
Figure 10-2 Logical networking on the Iu CS interface
(11/1/2013)
Commercial in Confidence
Page 78 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Description
Negotiated
Ethernet port data
Device IP address
of the interface
board
GE
port
(11/1/2013)
Recommended
Value
Negotiation
Principle
None
1,500
Consistency of data
configuration
Maximum
It refers to the maximum
transmission length of the transmission
unit.
unit
Whether to
enable auto
negotiation
If auto negotiation is
Enable
disabled, the transmission
rate over the FE port,
working mode, and whether
enable flow control are
user-defined.
Consistency of data
configuration (If auto
negotiation is disabled, th
configurations on the RN
side should be consistent
with those on the MSC
side.)
Whether to
enable flow
control
Consistency of data
configuration
Commercial in Confidence
Page 79 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Description
Be Negotiated
The
configuration
of this
parameter is determined
the VTR based on the
network
planning.
(2) Data to be negotiated on the SCTP layer: parameters to be negotiated before add the SCTP link
So, according to the protocol, it need configure two IP address on RNC and MSC server respectively.
Table 10-4 SCTP layer data of the Iu CS interface to be negotiated
(11/1/2013)
Parameters to Be
Negotiated
Description
Working mode
Commercial in Confidence
The configuration
of this parameter should be
negotiated.
(Generally, When
RNC serve as
client, it needs to configure its port
No.)
Page 80 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
The configuration
of this parameter should be
negotiated.
Generally,
according to the protocol when the MS
serve as
Server, its port
NO. is 2905
The configuration
of this parameter is determined by the V
based on the network planning.
The configuration
of this parameter is determined by the V
based on the network planning.
MSC Server IP
address One
The configuration
of this parameter is determined by the V
based on the network planning.
MSC Server IP
address Two
The configuration
of this parameter is determined by the V
based on the network planning.
(3) Data to be negotiated on the M3UA layer: parameters to be negotiated before add the M3UA link
set
(11/1/2013)
Commercial in Confidence
Page 81 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Description
Application
Mode
Consistency of data
configuration
(Huawei recommends that th
application mode on both th
RNC
side and the MSC side be se
IPSP)
The application mode at the M3UA layer can be set either to ASP or IPSP. An ASP is a logical entity and
represents certain resources. Each AS contains an ASP set where one ASP entity or more than one ASP
entity can process services. IPSP indicates IP service point. It is an IP-based process. An IPSP is
essentially the same as an ASP, except that it uses M3UA with point-to-point type. Conceptually, an
IPSP does not use the services of a Signaling Gateway node.
The traffic mode at the M3UA layer can be set either to active/standby mode or to load sharing mode.
Active/standby mode specifies that one ASP entity manages all services. Load sharing mode specifies
that two ASPs share all traffic loads.
The recommended value for the routing context at the M3UA layer is 4294967295. This value indicates
that it is not advised to configure the routing context.
(4) Data to be negotiated on the SCCP layer:
(11/1/2013)
Commercial in Confidence
Page 82 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Description
Recommended Negotiation
Value
Principle
Inactive TX timer
This parameter is
configured according
the value of the inact
RX
timer on the
RNC.
Inactive RX timer
The
configuration
of this
parameter
should be negotiated
(The duration
of this timer
should be at
least twice
longer than
that of the
inactive TX
timer on the
MSC.
The value of the local inactive RX timer should be at least twice greater than that of the peer inactive
TX timer. The ITUT- Q.714 protocol has the following descriptions regarding the setting of the timer.
It might be advantageous to make sure that the inactivity receive timer T (iar) is at least twice the
inactivity send timer T (ias). Huawei recommends that the value for the inactive TX timer is set to 90s
and that of the inactive RX timer 720s. These two timers are parameters that affect the overall
configuration of the RNC. The Iu CS interface, Iu PS interface, and Iur interface all require the
configuration of these parameters. Therefore, before configuring these two parameters, it should
consider the configuration of the CN (IuCS).
(11/1/2013)
Commercial in Confidence
Page 83 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Recommended Negotiation
Value
Principle
Local IP address
and subnet mask
of the RNC
None
This parameter
specifies
the service IP addr
on
the RNC side and t
mask of the subnet
where the board
resides.
The configuration
this parameter is
determined by
the VTR
based on the
network planning
Peer IP address
and subnet mask
of the MSC
None
This parameter
specifies
the IP address of th
MSC.
The configuration
this parameter is
determined by
the VTR
based on the
network planning
Recommended
Value
Negotiation
Principle
Destination
None
The configuration o
this parameter is
determined by the
VTR based
on the network
planning.
The configuration o
this parameter is
determined by the
VTR based
on the network
planning.
IP address
Subnet mask
(11/1/2013)
Commercial in Confidence
Page 84 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Next hop
None
The configuration o
this parameter is
determined by the
VTR based
on the network
planning.
The CN protocol version can be R99, R4, R5 or R6. It needs to obtain the proper protocol
version from the MSC.
The CR support type depends on the CN protocol version. Different CN protocol versions
support different CR types. The relation between the two is as follows:
When the CN protocol version is R99, the CR support type can be CR527_SUPPORT or
CR527_NOT_SUPPORT.
When the CN protocol version is R4, the CR support type can be CR528_SUPPORT or
CR528_NOT_SUPPORT.
When the CN protocol version is R5, the CR support type can be CR529_SUPPORT or
CR529_NOT_SUPPORT.
When the CN protocol version is R6, the CR type needs not to be negotiated.
CR support type is related to UE Not Involved Relocation, when the network support UE Not
Involved Relocation, then, CN and RNC should negotiate CR support type.
For
details
on
the
CR
type,
see
the
3GPP
www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_18/Docs/ZIP/index-2.html/ RP-020741.zip
protocol.
(11/1/2013)
Commercial in Confidence
Page 85 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
V2
The following figure shows the actual networking on the Iu PS interface. The SCTP, M3UA, SCCP, and
RANAP layers on the Iu PS interface should be negotiated.
(11/1/2013)
Commercial in Confidence
Page 86 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Description
Recommended
Value
Negotiation
Principle
It consists of the IP
address of the
Ethernet port and
subnet mask.
None
The configuration
of this data is
determined by the
VTR based on the
network planning.
Device IP address of
the interface board
When the Iu PS
interface uses L3
networking, the
interface board
should be configured
with the device IP
address. This address
is determined by the
VTR based on the
network planning.
None
The configuration
of this data is
determined by the
VTR based on the
network planning.
It refers to the
maximum length of
the transmission
unit.
1,500
Consistency of data
configuration
GE
optical
(11/1/2013)
Maximum
transmission
unit
Commercial in Confidence
Page 87 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
port
Whether to
enable auto
negotiation
If auto negotiation is
disabled, the
transmission rate
over the FE port,
working mode, and
whether to enable
flow control are
user-defined.
Enable
Whether to
enable flow
control
ON
Consistency of data
configuration
(If auto negotiation
is disabled, the
configurations on
the RNC side
should be
consistent with
those on the SGSN
side.)
Consistency of data
configuration
Description
Recommended
Value
Negotiation
Principle
IP address of the
gateway between the
RNC and the SGSN
None
The
configuration
of this
parameter is
determined
by the VTR
based on the
network
planning.
(2) Data to be negotiated on the SCTP layer: parameters to be negotiated before add the SCTP link
So, according to the protocol, it need configure two IP address on RNC and SGSN respectively
(11/1/2013)
Commercial in Confidence
Page 88 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Description
Recommended
Value
Negotiation
Principle
Working mode
The configuration
of this parameter
should be
negotiated.
(Huawei
recommends that
the RNC serve as
the client and the
SGSN serve as the
server.)
None
2905
The configuration
of this parameter
should be
negotiated.
(Generally, When
RNC serve as
client, it needs to
configure its port
No.)
The configuration
of this parameter
should be
negotiated.
Generally,
according to the
protocol when the
SGSN serve as
Server, its port
NO. is 2905
(11/1/2013)
RNC IP address
One
None
The configuration
of this parameter
is determined by
the VTR based on
the network
planning.
RNC IP address
Two
None
The configuration
of this parameter
is determined by
the VTR based on
the network
planning.
Commercial in Confidence
Page 89 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
SGSN IP address
One
None
The configuration
of this parameter
is determined by
the VTR based on
the network
planning.
SGSN IP address
Two
None
The configuration
of this parameter
is determined by
the VTR based on
the network
planning.
VLAN ID
None
The configuration
of this parameter
should be
negotiated with
SGSN and the
transmission
equipment
between RNC and
SGSN.
(3) Data to be negotiated on the M3UA layer: parameters to be negotiated before add the M3UA link set
Table 10-13 M3UA layer data of the Iu PS interface to be negotiated
Parameters
to Be
Negotiated
Description
Recommen
ded Value
Negotiation Principle
Application
Mode
M3UA_IPSP
Traffic Mode
Routing
Context
M3UA_LOA
DSHARE_M
OD
4294967295
The application mode at the M3UA layer can be set either to ASP or IPSP. ASP means Application
Server Process. An ASP is a logical entity and represents certain resources. Each AS contains an ASP set
(11/1/2013)
Commercial in Confidence
Page 90 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
where one ASP entity or more than one ASP entity can process services. IPSP indicates IP service point.
It is an IP-based process. An IPSP is essentially the same as an ASP, except that it uses point-to-point
M3UA. Conceptually, an IPSP does not use the services of a Signaling Gateway node.
The traffic mode at the M3UA layer can be set either to active/standby mode or to load sharing mode.
Active/standby mode specifies that one ASP entity manages all services. Load sharing mode specifies
that two ASPs share all traffic loads.
The recommended value for the routing context at the M3UA layer is 4294967295. This value indicates
that it is not advised to configure the routing context.
(4) Data to be negotiated on the SCCP layer
Table 10-14 SCCP layer data of the Iu PS interface to be negotiated
Parameters to Be
Negotiated
Description
Recommended
Value
Negotiation
Principle
Inactive TX timer
90 s
This
parameter is
configured
according to
the value of
the inactive
RX timer on
the SGSN.
Inactive RX timer
720s
The
configuration
of this
parameter
should be
negotiated.
(The value of
this timer
should be at
least twice
greater than
that of the
inactive TX
timer on the
SGSN.)
The value of the local inactive RX timer should be at least twice greater than that of the peer inactive
TX timer. The ITUT- Q.714 protocol has the following descriptions regarding the setting of the timer.
It might be advantageous to make sure that the inactivity receive timer T (iar) is at least twice the
inactivity send timer T(ias). Huawei recommends that the value for the inactive TX timer is set to 90s
and that of the inactive RX timer 720s. These two timers are parameters that affect the overall
configuration of the RNC. The Iu CS interface, Iu PS interface, and Iur interface all require the
configuration of these parameters. Therefore, before configuring these two parameters, it should
consider the configuration of the CN (Iu CS, Iu PS) and that of the neighboring RNC.
(11/1/2013)
Commercial in Confidence
Page 91 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Description
Recommended
Value
Negotiation
Principle
Local IP address
and subnet mask
of the RNC
None
The
configuration of
this parameter
is determined
by the VTR
based on the
network
planning.
Peer IP address
and subnet mask
of the SGSN
None
The
configuration of
this parameter
is determined
by the VTR
based on the
network
planning.
(11/1/2013)
Parameters
to Be
Negotiated
Description
Recommended
Value
Negotiation
Principle
Destination
IP address
None
The
configuration
of this
parameter is
determined
by the VTR
based on the
network
planning.
Commercial in Confidence
Page 92 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Subnet
mask
None
The
configuration
of this
parameter is
determined
by the VTR
based on the
network
planning.
Next hop
None
The
configuration
of this
parameter is
determined
by the VTR
based on the
network
planning.
The CN protocol version can be R99, R4, R5 or R6. It needs to obtain the proper
protocol version from the SGSN.
When the CN protocol version is R99, the CR support type can be CR527_SUPPORT or
CR527_NOT_SUPPORT.
When the CN protocol version is R4, the CR support type can be CR528_SUPPORT or
CR528_NOT_SUPPORT.
When the CN protocol version is R5, the CR support type can be CR529_SUPPORT or
CR529_NOT_SUPPORT.
When the CN protocol version is R6, the CR type needs not to be negotiated.
CR support type is related to UE Not Involved Relocation, when the network support UE Not
Involved Relocation, then, CN and RNC should negotiate CR support type.
(11/1/2013)
Commercial in Confidence
Page 93 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
(11/1/2013)
Commercial in Confidence
Page 94 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
(11/1/2013)
Commercial in Confidence
Page 95 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
No. Name
Description
Whether to
If auto negotiation is enabled,
ENABLE
enable auto negotiation the transmission rate over the FE port,
working mode, and whether to enable flo
control depend on the negotiation results
(2)
1,500 bytes
GE
port
data
to be
negoti
ated
3
The
configuration
of this
parameter on
the NodeB
should be consiste
with that on
the RNC.
Working mode
The
configuration
of this
parameter on
the NodeB
should be consiste
with that on
the RNC.
Whether to
enable flow
control
The
configuration
of this
parameter on
the NodeB
should be consiste
with that on
the RNC.
p
o
r
t
t
o
b
5 e
n
e
g
o
t
i
(11/1/2013)
The
configuration
of this
parameter on
the NodeB
should be consiste
with that on
the RNC.
Transmission
Table
10-18
rate
overGthe FE port
E
4 d
a
t
a
The
configuration
of this
parameter on
the NodeB
should be consiste
with that on
the RNC.
Commercial in Confidence
Page 96 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
ated
No. Name
Description
Recommended Value
Maximum
This parameter specifies the maximu None
transmission unit length of the transmission unit.
(MTU)
The
configur
of this
paramet
the Nod
should b
with tha
the RNC
Whether to
enable auto
negotiation
The
configur
of this
paramet
the Nod
should b
with tha
the RNC
Whether to
enable flow
control
The
configur
of this
paramet
the Nod
should b
with tha
the RNC
(11/1/2013)
Negoti
No. Name
Description
This parameter specifies the work The RNC serves The working
mode of the equipment.
as the server.
mode configur
on the NodeB
should be
consistent with
that
on the RNC.
Working mode
Commercial in Confidence
Recommended Negotiation
Value
Principle
Page 97 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
The configurat
of this data is
determined by
the customer
based on
the network
planning.
The configurat
of this data is
determined by
the customer
based on
the network
planning.
The configurat
of this data is
determined by
the customer
based on
the network
planning.
The configurat
of this parame
is determined b
the configurati
on the NodeB.
(11/1/2013)
No.
Name
Description
Recommended Value
Commercial in Confidence
Negotiation
Principle
Consistency
of data
configuration
Page 98 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
(11/1/2013)
Description
This parameter is
negotiated between
the NodeB and the RNC
The transmit bandwidth
the
RNC side should be sam
to the received bandwidt
on the NodeB side.
None
Peer IP address If IP path check flag is set to
be checked
ENABLED, [peer IP address to be
(optional)
checked] should be negotiated wit
the peer end.
Commercial in Confidence
DISABLED
Page 99 of 113
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Description
Recommended
Value
Negotiation
Principle
The NBAP
protocol
version on the
NodeB should
be consistent
with that on
the RNC side.
(11/1/2013)
Commercial in Confidence
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
The following figure shows the actual networking on the Iur interface. The SCTP, M3UA, SCCP, and
RNSAP layers on the Iur interface should be negotiated.
Figure 10-10 Logical networking on the Iur interface (2)
(11/1/2013)
Commercial in Confidence
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Description
Recommended
Value
Negotiation
Principle
It consists of the IP
address of the
Ethernet port and
subnet mask.
None
The
configuration
of this data is
determined by
the VTR based
on the network
planning.
Device IP address of
the interface board
None
The
configuration
of this data is
determined by
the VTR based
on the network
planning.
Maximum
transmission
unit
It refers to the
maximum length of
the transmission
unit.
1500
Consistency of
data
configuration
Whether to
enable auto
negotiation
If auto negotiation
is disabled, the
transmission rate
over the GE port,
working mode, and
whether to enable
flow control are
user-defined.
Enable
Consistency of
data
configuration
In the Ethernet,
flow control is
required when the
flow control frame
needs to be sent and
handled.
ON
GE
optical
port
Whether to
enable flow
control
(If auto
negotiation is
disabled, the
configurations
on the RNC
side should be
consistent with
those on the
NRNC side.)
Consistency of
data
configuration
(11/1/2013)
Commercial in Confidence
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Description
Recommended
Value
Negotiation
Principle
None
The
configuration
of this
parameter is
determined
by the VTR
based on the
network
planning.
(2) Data to be negotiated at the SCTP layer: parameters to be negotiated before add the SCTP link
Table 10-25 SCTP layer data of the Iur interface to be negotiated
Parameters to
Be Negotiated
Description
Recommended
Value
Negotiation
Principle
Working mode
The
configuration
of this
parameter
should be
negotiated.
(Huawei
recommends
that the RNC
serve as the
client and the
NRNC serve as
the server.)
None
The
configuration
of this
parameter
should be
negotiated.
(Generally,
When RNC
serve as client,
it need to
cofigurate its
port No.)
(11/1/2013)
Commercial in Confidence
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
2905
The
configuration
of this
parameter
should be
negotiated.
Generally,
according to
the protocol
when the
NRNC serve as
Server, its port
NO. is 2905
RNC IP address
One
None
The
configuration
of this
parameter is
determined by
the VTR based
on the network
planning.
NRNC IP
address One
None
The
configuration
of this
parameter is
determined by
the VTR
based on the
network
planning.
VLAN ID
VLAN(Virtual LAN), A
logically independent
network. Several VLANs
can co-exist on a single
physical switch.
None
The
configuration
of this
parameter
should be
negotiated with
NRNC and the
transmission
equipment
between RNC
and NRNC.
(3) Data to be negotiated on the M3UA layer: parameters to be negotiated before add the M3UA link set
(11/1/2013)
Commercial in Confidence
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Description
Recomm
ended
Value
Negotiation Principle
Applicatio
n Mode
M3UA_IP
SP
Traffic
Mode
Routing
Context
M3UA_L
OADSHA
RE_MOD
Consistency of data
configuration
This parameter
specifies the routing
context of the M3UA
entity.
429496729
5
The application mode at the M3UA layer can be set either to ASP or IPSP. ASP means Application
Server Process. An ASP is a logical entity and represents certain resources. Each AS contains an ASP set
where one ASP entity or more than one ASP entity can process services. IPSP indicates IP service point.
It is an IP-based process. An IPSP is essentially the same as an ASP, except that it uses M3UA in a
point-to-point fashion. Conceptually, an IPSP does not use the services of a Signalling Gateway node.
The traffic mode at the M3UA layer can be set either to active/standby mode or to load sharing mode.
Active/standby mode specifies that one ASP entity manages all services. Load sharing mode specifies
that two ASPs share all traffic loads.
The recommended value for the routing context at the M3UA layer is 4294967295. This value indicates
that it is not advised to configure the routing context.
(4) Data to be negotiated on the SCCP layer
(11/1/2013)
Commercial in Confidence
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Description
Recommended
Value
Negotiation
Principle
Inactive TX timer
90s
This
parameter is
configured
according to
the value of
the inactive
RX timer on
the NRNC.
Inactive RX timer
720s
The
configuration
of this
parameter
should be
negotiated.
(The value of
this timer
should be at
least twice
greater than
that of the
inactive TX
timer on the
NRNC.)
The value of the local inactive RX timer should be at least twice greater than that of the peer inactive
TX timer. The ITUT- Q.714 protocol has the following descriptions regarding the setting of the timer.
It might be advantageous to make sure that the inactivity receive timer T(iar) is at least twice the
inactivity send timer T(ias). Huawei recommends that the value for the inactive TX timer is set to 90s
and that of the inactive RX timer 720s. These two timers are parameters that affect the overall
configuration of the RNC. The Iu CS interface, Iu PS interface, and Iur interface all require the
configuration of these parameters. Therefore, before configuring these two parameters, it should
consider the configuration of the CN (Iu CS, Iu PS) and that of the neighboring RNC.
(11/1/2013)
Commercial in Confidence
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Description
Recommended
Value
Negotiation
Principle
Local IP address
and subnet mask
of the RNC
None
The
configuration
of this
parameter is
determined by
the VTR based
on the network
planning.
Peer IP address
and subnet mask
of the NRNC
None
The
configuration
of this
parameter is
determined by
the VTR based
on the network
planning.
(11/1/2013)
Parameters
to Be
Negotiated
Description
Recommended
Value
Negotiation
Principle
Destination
IP address
None
The
configuration
of this
parameter is
determined by
the VTR based
on the network
planning.
Subnet mask
None
The
configuration
of this
parameter is
determined by
the VTR based
on the network
planning.
Commercial in Confidence
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Next hop
None
The
configuration
of this
parameter is
determined by
the VTR based
on the network
planning.
(11/1/2013)
Commercial in Confidence
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
11
This chapter specifies the basic functions of network design. They are Iur interoperability strategy and
2G/3G Interoperability. These two strategies focus on the compatibility between network equipment and
ensure user satisfaction.
For Iur interoperability strategy, Huawei recommends handover on the Iur interface and DSCR strategy
instead of SRNS Relocation. If intra-frequency coverage is applied between neighboring RNCs the soft
handover is adopted on Iur; if inter-frequency coverage is applied between neighboring RNCs the hard
handover is adopted on Iur. For VTR network, only intra-frequency coverage exists between
neighboring RNCs.
DSCR is short for Direct Signaling Connection Re-establish. As for DSCR, the 3GPP TS 23.060
protocol has the following description: The UE shall also perform a RAU procedure immediately on
entering PMM-IDLE state when it has received a RRC Connection Release message with cause
(11/1/2013)
Commercial in Confidence
UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01
Directed Signaling connection re-establishment even if the RA has not changed since the last update.
That is, if the UE meets certain requirements, the SRNC can initiate the RRC connection release
procedure with the cause of DSCR, thus enabling the UE to reselect a proper cell and access the
network.
For the typical handover procedure, see 3GPP TS 25.931 protocols.
(11/1/2013)
Commercial in Confidence
12
AAL2
ALCAP
AMR
ARP
ATM
BAM
BITS
BPS
CCP
CN
Core Network
CRNC
Controlling RNC
CS
Circuit Switched
DHCP
DRNS
Drift RNS
DSCP
EMS
ESN
FE
Fast Ethernet
FP
Frame Protocol
GE
Gigabit Ethernet
GPS
GTP-U
HDB3
HSDPA
HS-DSCH
HSUPA
IP
Internet Protocol
IPDV
(11/1/2013)
Acronyms and
Abbreviations
Commercial in Confidence
IPLR
IPTD
IUUP
LMT
M2000
iManager M2000
MAC
MBMS
MDC
MGW
Media Gateway
MSC
MSP
MTP3
MTU
NBAP
NCP
NodeB
NRI
NRNC
NRT
Non-Real-Time
OMC
OMIP
PDCP
PPP
Point-to-Point Protocol
PPS
PS
Packet Switched
PVC
QoS
Quality of Service
RAN
RANAP
RBS
RLC
RNC
RSS
RTP
RT-VBR
SAAL
SCTP
SDH
SGSN
SHO
Soft HandOver
SNTP
SRNC
Serving RNC
(11/1/2013)
Commercial in Confidence
STM-1
UBR
UDP
UE
User Equipment
UMTS
UNI
User-Network Interface
UTRAN
VCI
VLAN
VPI
VRRP
(11/1/2013)
Commercial in Confidence