Вы находитесь на странице: 1из 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

IPRAN Network High Level Design for Project VTR


RAN12
for VTR RNC RM1301, RM1302, AN201, BB801

Issue

3.0

Date

2013-08-05

Huawei Technologies Co. Ltd

2013-11-1

1 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Huawei Technologies Co., Ltd. provides VTR with comprehensive technical support and service. For any assistan
please contact our local office or company headquarters.

Huawei Technologies Co., Ltd.


Address:

Huawei Industrial Base


Bantian, Longgang
Shenzhen 518129
Peoples Republic of China

Website:

http://www.huawei.com

Email:

support@huawei.com

Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.


No part of this document may be reproduced or transmitted in any from or by any means without prior written
consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions


And other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Contents

Contents
1 Introduction..................................................................................................................................15
1.1 Objectives....................................................................................................................................................... 15
1.2 Scopes ............................................................................................................................................................ 15
1.3 Dependencies ................................................................................................................................................. 16
1.4 Assumptions ................................................................................................................................................... 16

2 Network Naming and Numbering Design ............................................................................ 17


2.1 Naming Principle and Design......................................................................................................................... 17
2.2 Numbering Principle and Design ................................................................................................................... 18
2.2.1 Network Parameter Numbering ............................................................................................................ 18
2.2.2 IP address schemes................................................................................................................................ 18

3 UMTS Network Structure .........................................................................................................19


3.1 Target Network............................................................................................................................................... 19

4 RAN Network Design Requirement .......................................................................................21


4.1 Capacity Requirement of Target Network...................................................................................................... 21

5 Principles and Information of RAN O&M Design .............................................................. 22


5.1 O&M Network Topology ............................................................................................................................... 22
5.2 O&M Networking Principle and Design........................................................................................................ 22
5.2.1 O&M IP Planning Design ..................................................................................................................... 22
5.2.2 NodeB OM Channel Design ................................................................................................................. 25
5.2.3 Networking Design Between RAN and M2000.................................................................................... 28
5.2.4 NodeB Software Management Design.................................................................................................. 28
5.3 O&M Security Management Principle and Design........................................................................................ 30

2013-11-1

3 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

5.3.1 RAN OM TCP/UDP Port Design.......................................................................................................... 30


5.4 NE Time Synchronization Principle and Design............................................................................................ 31
5.4.1 NodeB Time Synchronization Design................................................................................................... 31
5.4.2 RNC Time Synchronization Design...................................................................................................... 31
5.4.3 M2000 Time Synchronization Design .................................................................................................. 32

6 RAN System Clock Synchronization Design ........................................................................33


6.1 RNC System Clock Source Design ................................................................................................................ 33
6.2 NodeB System Clock Source Design............................................................................................................. 33

7 RAN Resource Distributed Design .........................................................................................35


7.1 RAN Hardware Resource Layout Principle ................................................................................................... 35
7.1.1 RNC SPU Board Layout Design........................................................................................................... 36
7.1.2 RNC DPU Board Layout Design .......................................................................................................... 37
7.1.3 RNC Transmission Interface Boards Layout Design ............................................................................ 38
7.1.4 RNC Other Types of Boards Layout Design......................................................................................... 39
7.1.5 Boards Distribution Layout................................................................................................................... 40
7.2 Transmission Resource Distribution Design .................................................................................................. 45
7.3 NodeBs Distribution in SPUs Design ............................................................................................................ 45
7.4 IU and Iur Signaling links Distribution in SPUs Design................................................................................ 47

8 RAN Transmission Interface Capability Design..................................................................50


8.1 Iu CS Transmission Interface Capability Design ........................................................................................... 50
8.1.1 Total Iu CS User Plane Throughput Estimation .................................................................................... 50
8.1.2 Total Iu CS Control Plane Throughput Estimation ............................................................................... 51
8.1.3 Total Number of Ports for Iu CS Transmission on RNC Calculation.................................................... 52
8.2 Iu PS Transmission Interface Capability Design............................................................................................ 52
8.2.1 Total Iu PS User Plane Throughput Estimation .................................................................................... 53
8.2.2 Total Iu PS Control Plane Throughput Estimation................................................................................ 53
8.2.3 Total Number of Ports for Iu PS Transmission on RNC Calculation .................................................... 54
8.3 Iub Transmission Interface Capability Design ............................................................................................... 55
8.3.1 Traffic Mapping on IP Strategy Design................................................................................................. 55
8.3.2 Total Iub User Plane Throughput for Iub IP Transmission Estimation ................................................. 56
8.3.3 Total Iub Control Plane Throughput for Iub IP Transmission Estimation............................................. 57
8.3.4 Total Number of Ports for Iub IP Transmission on RNC Calculation ................................................... 57
8.4 Iub Transmission Configuration Design for Typical NodeB .......................................................................... 58

2013-11-1

4 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

8.4.1 Configuration Recommendation for NCP............................................................................................. 58


8.4.2 Configuration Recommendation for CCP ............................................................................................. 58
8.4.3 Configuration Recommendation for IPPATH ....................................................................................... 59
8.5 Iur Transmission Interface Capability Design................................................................................................ 60
8.5.1 Total Iur User Plane Throughput Estimation......................................................................................... 60
8.5.2 Total Iur Control Plane Throughput Estimation.................................................................................... 61
8.5.3 Total Number of Ports for Iur Transmission on RNC Calculation ........................................................ 61

9 RAN Transmission Interface Reliability Design..................................................................62


9.1 Iub Transmission Interface Networking Reliability Design ........................................................................... 62
9.1.1 Iub Networking Topology ..................................................................................................................... 62
9.1.2 Iub Interface Boards Redundancy Design............................................................................................. 63
9.1.3 Iub Transmission Ports Redundancy in RNC Design ........................................................................... 63
9.1.4 Iub Transmission Fault Detection Design ............................................................................................. 63
9.1.5 Iub Transmission QoS Difference Design............................................................................................. 64
9.1.6 Iub Transmission Layer Address Allocation Design ............................................................................. 67
9.2 Iu CS Transmission Interface Networking Reliability Design ....................................................................... 69
9.2.1 Iu CS Networking Topology ................................................................................................................. 69
9.2.2 Iu CS Interface Boards Redundancy Design......................................................................................... 69
9.2.3 Iu CS Transmission Ports Redundancy in RNC Design........................................................................ 70
9.2.4 Iu CS Transmission Fault Detection Design ......................................................................................... 70
9.2.5 Iu CS Transmission QoS Difference Design......................................................................................... 70
9.3 Iu PS Transmission Interface Networking Reliability Design........................................................................ 71
9.3.1 Iu PS Networking Topology.................................................................................................................. 71
9.3.2 Iu PS Interface Boards Redundancy Design ......................................................................................... 72
9.3.3 Iu PS Transmission Ports Redundancy in RNC Design ........................................................................ 72
9.3.4 Iu PS Transmission Fault Detection Design.......................................................................................... 73
9.3.5 Iu PS Transmission QoS Difference Design ......................................................................................... 73
9.4 Iur Transmission Interface Networking Availability Design .......................................................................... 75
9.4.1 Iur Networking Topology...................................................................................................................... 75
9.4.2 Iur Interface Boards Redundancy Design ............................................................................................. 75
9.4.3 Iur Transmission Ports Redundancy in RNC Design ............................................................................ 75
9.4.4 Iur Transmission Fault Detection Design.............................................................................................. 76
9.4.5 Iur Transmission QoS Difference Design ............................................................................................. 76

2013-11-1

5 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

10 RAN Interconnection Negotiation Design ..........................................................................77


10.1 Negotiation Design for RNC........................................................................................................................ 77
10.1.1 Parameters of SS7 Design................................................................................................................... 77
10.2 Iu CS Interconnection Negotiation Design................................................................................................... 78
10.2.1 Topology of Iu CS Interconnection..................................................................................................... 78
10.2.2 Iu CS Transmission Physical Layer Negotiation Design .................................................................... 79
10.2.3 Signaling Links Negotiation Design of Iu CS Signaling Plane........................................................... 80
10.2.4 IP PATH Negotiation Design of Iu CS User Plane.............................................................................. 83
10.2.5 Iu CS RANAP Negotiation Design ..................................................................................................... 85
10.2.6 Iu CS IUUP Negotiation Design ......................................................................................................... 85
10.3 Iu PS Interconnection Negotiation Design ................................................................................................... 86
10.3.1 Topology of Iu PS Interconnection ..................................................................................................... 86
10.3.2 Iu PS Transmission Physical Layer Negotiation Design..................................................................... 87
10.3.3 Signaling Links Negotiation Design of Iu PS Signaling Plane ........................................................... 88
10.3.4 IP PATH Negotiation Design of Iu PS User Plane .............................................................................. 92
10.3.5 Iu PS RANAP Negotiation Design ..................................................................................................... 93
10.4 Iub Interconnection Negotiation Parameters Recommendation Design....................................................... 94
10.4.1 Topology of Iub Interconnection......................................................................................................... 94
10.4.2 Negotiation Parameters of Transmission Physical Layer Design and Recommendation.................... 95
10.4.3 Negotiation Parameters of Transmission Signaling Link Design and Recommendation.................... 97
10.4.4 Negotiation Parameters of IP PATH Design........................................................................................ 99
10.4.5 Negotiation Parameters of NBAP Design ......................................................................................... 100
10.5 Iur Interconnection Negotiation Design ..................................................................................................... 100
10.5.1 Topology of Iur Interconnection ....................................................................................................... 100
10.5.2 Iur Transmission Physical Layer Negotiation Design....................................................................... 101
10.5.3 Signaling Links Negotiation Design of Iur Signaling Plane ............................................................. 102
10.5.4 IP PATH Negotiation Design of Iur User Plane ................................................................................ 106
10.5.5 Iur RNSAP Negotiation Design ........................................................................................................ 108

11 RAN Common Features Design ...........................................................................................109


11.1 Huawei RNS Iur Interoperability Strategy Design ..................................................................................... 109
11.1.2 Iur Interoperability Strategy Design for CS Traffic only................................................................... 110
11.1.3 Iur Interoperability Strategy Design for R99 PS Traffic only ........................................................... 110
11.1.4 Iur Interoperability Strategy Design for HSDPA PS and CS Traffic Combination ........................... 110

2013-11-1

6 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

12 Acronyms and Abbreviations............................................................................................... 111

2013-11-1

7 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Figure 7-7 Iub interface links in the IP networking............................................................................................. 45


Figure 7-8 Signaling plane links of the IuCS/IuPS interface in the IP networking ............................................. 47
Figure 8-1 IP transport networking...................................................................................................................... 55
Figure 9-1 Iub networking................................................................................................................................... 62
Figure 9-2 Iu CS networking............................................................................................................................... 69
Figure 9-3 Redundancy mode of Iu CS GOUc ports........................................................................................... 70
Figure 9-4 Iu PS networking ............................................................................................................................... 71
Figure 9-5 Iur networking ................................................................................................................................... 75
Figure 10-1 Protocol stack for the IP-based Iu CS interface ............................................................................... 78
Figure 10-2 Logical networking on the Iu CS interface ...................................................................................... 78
Figure 10-3 Protocol stack for the IP-based Iu PS interface................................................................................ 86
Figure 10-4 Logical networking on the Iu PS interface....................................................................................... 87
Figure 10-5 Iub interface protocol stack.............................................................................................................. 94
Figure 10-6 Iub interface topology (Control Plane) ............................................................................................ 94
Figure 10-7 Iub interface topology (User Plane)................................................................................................. 95
Figure 10-8 Iub interface bear type ..................................................................................................................... 95
Figure 10-9 Logical networking on the Iur interface (1) ................................................................................... 101
Figure 10-10 Logical networking on the Iur interface (2) ................................................................................. 101
Figure 11-1 Serving and Drift RNS................................................................................................................... 109

2013-11-1

9 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Table 7-9 NodeB distribution on the SPU subsystem.......................................................................................... 47


Table 7-10 Configuration rules for signaling links .............................................................................................. 48
Table 7-11 Signaling link allocation .................................................................................................................... 48
Table 7-12 Signaling link allocation.................................................................................................................... 48
Table 8-1 Throughput of the Iu CS interface on the user plane RM1301 ............................................................ 50
Table 8-2 Throughput of the Iu CS interface on the user plane RM1302 ............................................................ 50
Table 8-3 Throughput of the Iu CS interface on the user plane AN201............................................................... 51
Table 8-4 Throughput of the Iu CS interface on the user plane BB801............................................................... 51
Table 8-5 Throughput of the Iu CS interface on the control plane for RM1301.................................................. 51
Table 8-6 Throughput of the Iu CS interface on the control plane for RM1302.................................................. 51
Table 8-7 Throughput of the Iu CS interface on the control plane for AN201 .................................................... 51
Table 8-8 Throughput of the Iu CS interface on the control plane for BB801..................................................... 51
Table 8-9 Number of active GOUc ports for RM1301 ........................................................................................ 52
Table 8-10 Number of active GOUc ports for RM1302 ...................................................................................... 52
Table 8-11 Number of active GOUc ports for AN201 ......................................................................................... 52
Table 8-12 Number of active GOUc ports for BB801 ......................................................................................... 52
Table 8-13 Throughput of the Iu PS interface on the user plane for RM1301..................................................... 53
Table 8-14 Throughput of the Iu PS interface on the user plane for RM1302..................................................... 53
Table 8-15 Throughput of the Iu PS interface on the user plane for AN201 ....................................................... 53
Table 8-16 Throughput of the Iu PS interface on the user plane for BB801........................................................ 53
Table 8-17 Throughput of the Iu PS interface on the control plane for RM1301 ................................................ 53
Table 8-18 Throughput of the Iu PS interface on the control plane for RM1302 ................................................ 53
Table 8-19 Throughput of the Iu PS interface on the control plane for AN201................................................... 54
Table 8-20 Throughput of the Iu PS interface on the control plane for BB801 ................................................... 54
Table 8-21 Number of active GOUc ports for RM1301 ...................................................................................... 54
Table 8-22 Number of active GOUc ports for RM1302 ...................................................................................... 54

2013-11-1

11 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Table 8-23 Number of active GOUc ports for AN201......................................................................................... 54


Table 8-24 Number of active GOUc ports for BB801 ......................................................................................... 54
Table 8-25 General rules for user plane transmission mapping ........................................................................... 56
Table 8-26 Throughput of the Iub interface on the user plane in IP transmission for RM1301........................... 56
Table 8-27 Throughput of the Iub interface on the user plane in IP transmission for RM1302........................... 56
Table 8-28 Throughput of the Iub interface on the user plane in IP transmission for AN201 ............................. 56
Table 8-29 Throughput of the Iub interface on the user plane in IP transmission for BB801.............................. 56
Table 8-30 Throughput of the Iub interface on the control plane in IP transmission for RM1301 ...................... 57
Table 8-31 Throughput of the Iub interface on the control plane in IP transmission for RM1302 ...................... 57
Table 8-32 Throughput of the Iub interface on the control plane in IP transmission for AN201......................... 57
Table 8-33 Throughput of the Iub interface on the control plane in IP transmission for BB801 ......................... 57
Table 8-34 Number of active GOUc ports for RM1301 ...................................................................................... 57
Table 8-35 Number of active GOUc ports for RM1302 ...................................................................................... 58
Table 8-36 Number of active GOUc ports for AN201......................................................................................... 58
Table 8-37 Number of active GOUc ports for BB801 ......................................................................................... 58
Table 8-38 NCP configuration ............................................................................................................................. 58
Table 8-39 CCP configuration ............................................................................................................................. 59
Table 8-40 IPPATH configuration ....................................................................................................................... 59
Table 8-41 Configuration recommendation for IPPATH ..................................................................................... 60
Table 8-42 Throughput of the Iur interface on the user plane for RM1301......................................................... 60
Table 8-43 Throughput of the Iur interface on the user plane for RM1302......................................................... 60
Table 8-44 Throughput of the Iur interface on the user plane for AN201............................................................ 60
Table 8-45 Throughput of the Iur interface on the user plane for BB801............................................................ 61
Table 8-46 Throughput of the Iur interface on the control plane for RM1301 .................................................... 61
Table 8-47 Throughput of the Iur interface on the control plane for RM1302 .................................................... 61
Table 8-48 Throughput of the Iur interface on the control plane for AN201....................................................... 61

2013-11-1

12 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Table 10-17 FE port data to be negotiated ........................................................................................................... 96


Table 10-18 GE port data to be negotiated .......................................................................................................... 96
Table 10-19 SCTP data to be negotiated.............................................................................................................. 97
Table 10-20 NCP and CCP data to be negotiated ................................................................................................ 98
Table 10-21 IP path data to be negotiated............................................................................................................ 99
Table 10-22 NBAP data to be negotiated........................................................................................................... 100
Table 10-23 Physical layer data of the Iur interface to be negotiated ................................................................ 102
Table 10-24 IP layer data of the Iur interface to be negotiated .......................................................................... 103
Table 10-25 SCTP layer data of the Iur interface to be negotiated .................................................................... 103
Table 10-26 M3UA layer data of the Iur interface to be negotiated .................................................................. 105
Table 10-27 SCCP layer data of the Iur interface to be negotiated.................................................................... 106
Table 10-28 IP path data of the Iur interface to be negotiated ........................................................................... 107
Table 10-29 IP route data of the Iur interface to be negotiated.......................................................................... 107

2013-11-1

14 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

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

Meeting the network scale requirement.

Being of good security, high reliability, and reasonable resource allocation.

Supporting convenient capacity expansion.

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

1.3 Dependencies
Table 1-1 Dependencies
Issue No.
1

Item

Description

Network scale

The design follows target network scale and


target number of subscribers from VTR.

2
3

Site distribution

The design follows site lists and


distribution from VTR.

Boundary maps

UTRAN boundary maps and UTRAN


network planning for RF coverage.

Transmission network

The design follows transmission


network information from VTR.

1.4 Assumptions
This HLD is based on the following general assumptions:

2013-11-1

BOQ is correct.

Traffic model is correct.

Target network scale is correct.

Target number of subscribers is correct.

The capacity of NodeBs and RNCs and the distribution information are correct.

Subscriber distribution is correct.

Transmission network information is correct.

16 , 113

IPRAN Network High Level Design for Project VTRRAN12

2
2.1

Security Level: Internal

Network Naming and


Numbering Design

Naming Principle and 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 is used.

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.

RNC BAM Naming


z

Use the following naming rules recommended by Huawei: BAM_Slot_RNC Name

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

IPRAN Network High Level Design for Project VTRRAN12


z

Security Level: Internal

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.

For Example: URM2001

Cell Naming
z

Use the existing cell naming rule: Name of the NodeB + Sector number.

For Example: URM20011, URM20012, URM20013

2.2

Numbering Principle and Design


2.2.1 Network Parameter Numbering
Some numbering is shared in different interfaces, for example ANI, SCTP link, N7DPC and so on.
This numbering should be planned in different interfaces in advance.
Table 2-1 shows the recommended numbering planning among Iub, IuCS and IuPS interface.
Table 2-1 Numbering planning
Item
ANI
SCTP
N7DPC
M3DE
M3LKS
M3LNK_SIGLNKID

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

2.2.2 IP address schemes


It is an important step in network design to plan the IP addresses appropriately. For large scale network,
IP addresses must be planned and implemented unanimously. How IP addresses are planned will impact
on the efficiency of route protocol algorithm of the network, and its performance, scalability,
management, as well as its further development.

2013-11-1

18 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

The principle for IP addresses planning


z

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.

UMTS Network Structure

3.1 Target Network


In VTR 3G networks, 4 RNCs will be constructed: RNC_RM1301, RNC_RM1302, RNC_AFT_01 and
RNC_BB801.
The IuCS, IUPS , Iur and Iub interface all use IP transmission.
Figure 3-1 Target VTR network

2013-11-1

19 , 113

IPRAN Network High Level Design for Project VTRRAN12

IDEN

ISUP
BICC

NodeBs

Security Level: Internal

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

RAN Network Design


Requirement

4.1 Capacity Requirement of Target Network


Target Network Scale
The entire target VTR network will contain 4 RNCs and VTR NodeB. For details, see Table 4-1.
Table 4-1 Distribution of NodeBs
RNC_RM1301 RNC_RM1302 RNC_AFT_01 RNC_BB801
The Num Of Node B

396

297

15

264

Interface Connection Requirement


Table 4-2 Interface Information
Interface Information

Product

Version

Iu-CS

GE port, Board Backup (Share with IuR)

Iu-PS

GE port, Board Backup

Iub

GE port, Board Backup

Iur

GE port, Board Backup (share with IuCS)

Information

Table 4-3 Product Version Information


Version Information

2013-11-1

RNC

RAN12 or latest stable version.

Node B

RAN12 or latest stable version.

21 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Principles and Information


of RAN O&M Design

5.1 O&M Network Topology


M2000 will manage and maintain NodeB directly through IP network bypassing the RNC.
Figure 5-1 shows the entire O&M network.
Figure 5-1 Topology of O&M network

5.2 O&M Networking Principle and Design


5.2.1 O&M IP Planning Design
RNC BAM IP Address Design
Among BAM IP addresses, external fixed IP addresses and external virtual IP addresses need to be
planned according to onsite situations. In addition, the VTR needs to check whether the subnet number of

2013-11-1

22 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

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

Table 5-1 Example for BAM IP addresses


IP Address
Internal fixed IP address

External fixed IP address

Planning Principle
The preset IP addresses of the internal Ethernet adapters are:

Active BAM: 80.168.3.50 (255.0.0.0)

Standby BAM: 80.168.3.60 (255.0.0.0)

The preset IP addresses of the external Ethernet adapters are:

Active BAM: 172.121.139.201 (255.255.255.0)

Standby BAM: 172.121.139.202 (255.255.255.0)

The settings can be reconfigured on site based on the actual networking


topology.
Internal virtual IP address

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).

External virtual IP address

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

Standby BAM: 192.168.3.60 (255.255.255.0)

23 , 113

IPRAN Network High Level Design for Project VTRRAN12

IP Address

Security Level: Internal

Planning Principle
The IP address cannot be changed.

Commissioning IP address

The preset commissioning IP addresses are:

Active BAM: 192.168.6.50 (255.255.255.0)

Standby BAM: 192.168.6.60 (255.255.255.0)

The IP address cannot be changed.

Figure 5-3 External network of BAM connection figure

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

NodeB OM IP Address Design


The NodeB is maintained by the M2000 or the maintenance terminal (including LMT) through the
remote OM channel.
The recommended remote NodeB maintenance channel is over the IP link. IP data streams are
terminated on the Iub interface board. Through IP routing, O&M packages are routed to the main
control board of the NodeB for processing.
Figure 5-4 NodeB ETHIP & OMIP

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.

5.2.2 NodeB OM Channel Design


OMCH Policy
It is recommended that the NodeB is directly routed to the M2000 for maintenance without passing
through the RNC. This can separate service channels from maintenance channels, thus enhancing
network security and QoS.

2013-11-1

25 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Figure 5-5 NodeB OMCH policy

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

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 Function and Parameter Configuration


The Dynamic Host Configuration Protocol (DHCP) transfers configuration information to hosts in a
network. Based on the BOOTP, the DHCP adds the function of dynamically obtaining IP addresses.
The members defined in the DHCP are as follows:
z

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

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

5.2.3 Networking Design Between RAN and M2000


The M2000 is connected to the RAN through the Router. The M2000 performs O&M on the RNC and
NodeB through the Router.
Figure 5-8 RAN and M2000

5.2.4 NodeB Software Management Design


The NodeB software management including mainly: file transfer and NE upgrade.
File transfer:

2013-11-1

28 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

5.3 O&M Security Management Principle and Design


This section describes O&M security management and design, it include the ports which should be
enable on the firewall and BAM anti-virus recommendation. O&M design can guarantee the RAN
security.

5.3.1 RAN OM TCP/UDP Port Design


Table 5-3 lists the ports used for services of RNC. It needs to enable the ports on the firewall according
to VTR requirements.
Table 5-3 TCP/UDP ports of RNC
Port Number TCP & UDP

Client & Serve Port Description

21

TCP

Server

FTP

20

TCP

Server

FTP

1234

UDP

Client

SNTP client

3389

TCP

Server

Remote Windows desktop


(maintaining the OMU through
MSTSC)

6000

TCP

Server

MML maintenance port

6001

TCP

Server

Alarm console

6006

TCP

Server

LMT maintenance port

6007

TCP

Server

MML debugging console

6088

TCP

Server

Huawei-defined protocol
(remote upgrade tool)

6099

TCP

Server

Data synchronization with the M2000

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

Port Number TCP & UDP

Client & Serve Port Description

21

TCP

Server

FTP

6000

TCP

Server

MML maintenance port

30 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

6001

TCP

Server

Alarm console

6006

TCP

Server

LMT maintenance port

6007

TCP

Server

MML debugging console

5.4 NE Time Synchronization Principle and Design


This section describes policy design for time synchronization of the RNC and the NodeB.

5.4.1 NodeB Time Synchronization Design


The NodeB can be set to SNTP client only. The RNC, M2000, or the server provided by VTR can be set
as the time synchronization server of the NodeB. The NodeB time synchronization server recommended
by Huawei is the M2000. Table 5-5 lists time synchronization parameters.
Table 5-5 Recommended NodeB time synchronization parameters
Time Synchronization Parameter

Recommended Value

Time synchronization server

M2000

Address of the time clock synchronization server

IP address of the M2000 server

Time synchronization period

6 hours

Number of the port used by the time synchroniza 123


server
Figure 5-11 Logical line of NodeB time synchronization

5.4.2 RNC Time Synchronization Design


It can set the M2000 or the time synchronization server provided by VTR as the RNC time
synchronization server. The RNC time synchronization server recommended by Huawei is directly
connected to the NTP Server. If not possible, the M2000 can be configured as the server. Table 5-6 lists
time synchronization parameters. In addition, it can also configure up to 16 time synchronization servers
on the RNC.

2013-11-1

31 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Table 5-6 Recommended RNC time synchronization parameters


Time Synchronization Parameter

Recommended Value

Time synchronization server

NTP Server

Address of the time synchronization server

IP address of the NTP Server

Time synchronization period

60 minutes

Number of the port used by the time synchroniza 123


server

5.4.3 M2000 Time Synchronization Design


The M2000 time synchronization server is directly connected to the NTP Server provided by the
customer. If not possible, the M2000 can be configured as the server. Table 5-67 lists time
synchronization parameters.
Table 5-7 Recommended M2000 time synchronization parameters
Time Synchronization Parameter

Recommended Value

Time synchronization server

Customer NTP Server

Address of the time synchronization server

IP address of the NTP Server

Time synchronization period

60 minutes

Number of the port used by the time synchroniza 123


server

Figure 5-12 Logical line of RNC time synchronization

NTP
Server

2013-11-1

Router

RNC
Time Synchronization

32 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

RAN System Clock


Synchronization Design

This chapter describes the system clock source design of the RNC and NodeB and flow directions of
relevant system clocks.

6.1 RNC System Clock Source Design


Considering situations of VTR target network, based on IP Network and the deployment by using GE
interfaces, it is not necessary provide a clock source for the RNC. This is due the fact that the IP
Network can guarantee the data sending, therefore, if some package is lost, it can be sent again.

6.2 NodeB System Clock Source Design


The Iub interface uses the IP transport. Therefore, it is recommended to set the NodeB to extract clock
signals from the IPCLK1000 nearest to the connected NodeB. The NodeB requires that the time
precision should be +/-0.05 ppm. For all current RNCs, one IPClock will be installed as they will
provide the clock signal to the North, South, Central and Santiago regions. At the same time, these
IPClocks will have a backup IPClock running in a different location in Santiago that will provide a
backup signal in case one of the other four equipments malfunctions. This type of backup will be
describes as N+1 type.Figure 6-1 shows the recommended NodeB system clock source.

2013-11-1

33 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Figure 6-1 System clock stream of the NodeB

2013-11-1

34 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

RAN Resource Distributed


Design

This chapter describes optimization design for RNC capabilities, involving board configuration, the port
controller, NodeB allocation, and signaling links allocation.

7.1 RAN Hardware Resource Layout Principle


The V200R011 RNC supports the following boards: OMUa, SCUa, SPUa, CSUa, GCUa, GCGa, DPUb,
AEUa, AOUa, UOIa, PEUa, FG2a, GOUa, PFCU, MDMC, and WOPB. The PFCU is configured in the
fan box. The MDMC and WOPB boards are configured in the power distribution box. Other boards are
configured in the subrack of the RNC.
The RSS and RBS each contain 28 slots. In the RSS, slots 20 to 23 are used to house two OMUa boards
and other slots are used to house other boards on a one-to-one basis. The board structure is the same in
the RSS and RBS. That is, the backplane is configured in the center of the subrack and the front and rear
boards are installed on both sides of the backplane respectively, as shown in Figure 7-1.

2013-11-1

35 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Figure 7-1 General board structure in a subrack

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.

7.1.1 RNC SPU Board Layout Design


The SPUa performs the signaling processing function. Before configuring SPUa board, plan the slot
number in advance.

Slot Constraints of the SPUa Board


Slot constraints of the SPUa board in the V200R012 RSS and RBS are as follows:
z

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Table 7-1 Configuration rules for the SPUa board


SN

Configuration Rule for the SPUa Board

Configure the SPUa board in slots 0 to 5 and 8-11.

Configure the SPUa board in the active/standby mode.

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


main control SPUa board

Support 100 Node B, 300 Cells and 67,500 BHCA.


Each SPU subsystem support 25 Node B, 75 Cells and 168,75
BHCA

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.

7.1.2 RNC DPU Board Layout Design


The DPUb board processes and distributes service data flows on the user plane. Before configuring a
DPUb board, plan the slot number in advance.

Slot Constraints of the DPUb Board


Slot constraints of the DPU in the V200R011 RSS and RBS are as follows:
z

The DPU is configured in slots 8 to 11 and 14 to19 in the RSS.

The DPU is configured in slots 8 to 19 in the RSS.

One DPUb board can support 150 cells.


The maximum configuration in RSS Subrack support 4 DPUb boards meanwhile RBS Subrack
support 6 DPUb boards.
Table 7-3 DPUb board Processing Capability
Board

Capability

DPUb board

Supporting 96 Mbit/s (DL+UL) data streams;


Supporting 1,500 Erlang CS voice services;
Supporting 750 Erlang CS data services;
Supporting 150 cells

2013-11-1

37 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

7.1.3 RNC Transmission Interface Boards Layout Design


The V200R011RNC supports the following interface boards: AEUa, AOUa, UOIa, PEUa, FG2a, and
GOUa. Before board configuration, plan the slots of all interface boards.
Because the RNC RM1301/RM1302/AN201/BB801 uses the GOUc boards only, this section describes
the configuration principles and optimization design of this board only.

Slot Constraints of Interface Boards


Slot constraints of interface boards in the V200R011 RSS and RSS are as follows:
z

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.

Configuring the Iu/Iur Interface Board


The star connection is used in data switching between subracks of the RNC. The RSS serves as the main
subrack and the RBS serves as the extension subrack. The SCUa board of the RBS is connected to the
SCUa board of the RSS through the Ethernet cable, and the GE switching between subracks is
implemented through the RSS, as shown in the following figure.
Figure 7-2 Internal data switching of the RNC

2013-11-1

38 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

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.

Configuring the Iub Interface Board


Table 7-4 Configuration rules for interface boards
SN

Configuration Rule for Interface Board

Configure interface boards in the active/standby mode.

Distribute Iub interface boards on each subrack evenly.

Table 7-5 GOUc board Processing Capability


Interface
IUB

IUR

IU-CS

IU-PS

Capability
Voice Service in the CS Domain

18000 Erlang

Data Service in the CS Domain

18000 Erlang

Maximum Payload Throughput (UL+DL)

2600 Mbit/s

Voice Service in the CS Domain

18000 Erlang

Data Service in the CS Domain

18000 Erlang

Maximum Payload Throughput (UL+DL)

2600 Mbit/s

Voice Service in the CS Domain

18000 Erlang

Data Service in the CS Domain

9000 Erlang

Maximum Payload Throughput (UL+DL)

3200 Mbit/s

7.1.4 RNC Other Types of Boards Layout Design


Other boards used by the VTR RNCs include the OMUa board, SCUa board, and GCUa board. The slot
numbers of these boards are fixed. Insert them properly.

Slot Constraints of the OMUa Board


The OMUa board is the BAM of the RNC. In the RNC operating system, the OMUa board serves as a
bridge for the communication between the O&M terminal and other boards of the RNC.
The RNC can be configured with one or two OMUa boards. The OMUa board is constantly configured
in slots 20 and 21, or slots 22 and 23 in the RSS. The OMUa board is two times thicker than other
boards. Therefore, each OMUa board occupies two slots.

2013-11-1

39 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

In terms of reliability, it is required to configure a pair of active and standby OMUa boards for one
RNC.

Slot Constraints of the SCUa Board


The SCUa board implements internal switching of the RNC. The SCUa board in the RSS implements
central switching function. The SCUa board in the RBS implements level-2 switching. This implements
internal two-level MAC switching of the RNC and full interconnection among various modules of the
RNC.
Two SCUa boards are constantly configured in slots 6 and 7 in each RSS and RBS.

Slot Constraints of the GCUa Board


Two GCUa boards must be configured in slots 12 and 13 in the RSS.

7.1.5 Boards Distribution Layout


Figure 7-3 shows the board configuration of the RNC_RM1301 according to the preceding design rules
for board configuration.

2013-11-1

40 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Figure 7-3 Board configuration for the RNC_RM1301

Figure 7-4 Board configuration for the RNC_RM1302

2013-11-1

41 , 113

IPRAN Network High Level Design for Project VTRRAN12

2013-11-1

Security Level: Internal

42 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Figure 7-5 Board configuration for the RNC_AN201

2013-11-1

43 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Figure 7-6 Board configuration for the RNC_BB801

2013-11-1

44 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

7.2 Transmission Resource Distribution Design


Port Controller
A port controller is the control SPU subsystem of a port. The ports can be classified into seven types:
Ethernet port, PPP link, MLPPP link, UNI link, IMA link, fractional ATM (FRAATM) port, and
unchannelized (NCOPT) electrical port.
The path of a port can be available and can provide transmission resources for upper-layer services only
after a port controller is specified for the port.
Therefore, a port controller must be specified for each port to be used.

7.3 NodeBs Distribution in SPUs Design


When adding a NodeB to an RNC, a control SPU subsystem is specified to the NodeB. Figure7-7 shows
the Iub interface links in the IP networking.
Figure 7-7 Iub interface links in the IP networking

Configuration Constraints of the Control SPU Subsystem


Specifying a control SPU subsystem for a NodeB is subject to the following constraints:

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

NodeB Distribution the SPU Subsystem


For NodeB distribution we should consider some points:
It is recommended to try to balance the traffic load of the NodeBs through the subsystems of the SPU.
Each SPU has four subsystems. The best policy to deploy these NodeBs is aggregate them in similar
groups. It means put the same number of high traffic NodeBs in different subsystems from the same
SPU.
This NodeB allocation was done according to the numbers of NodeBs. However, according to the
subscribers and traffic increasing, a new network analysis can be provided and also a resource
optimization service.
The RNC_RM1302 RNC has 6 SPUa board (3 pairs, active/standby). The below table lists the detailed
distribution of NodeBs.
Table 7-6 NodeB distribution on the SPU

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

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

7.4 IU and Iur Signaling links Distribution in SPUs Design


Figure 7-8 shows signaling plane links of the IuCS/IuPS interface in the IP networking.
Figure 7-8 Signaling plane links of the IuCS/IuPS interface in the IP networking

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.

Quantity Design of Signaling Links


The recommended number of SCTP links ranges from 2 to 16. Select a proper number of SCTP links
according to the traffic calculated on the Iu signaling plane. To facilitate mask configuration, it is
recommended to configure the number of SCTP links as the exponential of 2, that is, 2/4/8/16. If the
number of SCTP links is set to an odd number, such as 3, the traffic of one SCTP link is two times the
traffic of other SCTP links no matter how the masks are configured.
According to the interconnection experience of Huawei commercial network, it is recommended to
configure signaling links according to the rules described as below:

2013-11-1

47 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Table 7-10 Configuration rules for signaling links


Configuration Rules for Signaling Links

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.

It is recommended to configure four SCTP links on the


signaling plane between the RNC and the peer signaling
point (MSC or SGSN).
It is recommended to configure two SCTP links on the
signaling plane between the RNC and the NRNC.

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.

Design Result of Signaling Links


The RNC_RM1302 has two subracks. Therefore, 4 SCTP links are recommended between the RNC and the MSC
and SGSN, and two SCTP links between the RNC and each NRNC. The below table lists the configuration results.
Note: For SPU Subsystem No, consider X/Y/Z where X is the Subrack Number, Y the Slot Number where the
SPUa board is allocated and Z as the SPU susbsystem number where the Signaling Link is allocated
Table 7-11 Signaling link allocation
Interface

Signaling Link No.

SPU Subsystem No.

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

Signaling Link No.

SPU Subsystem No.

IuCS

0/4/1

0/4/2

0/2/1

IuPS

2013-11-1

48 , 113

IPRAN Network High Level Design for Project VTRRAN12

Interface

2013-11-1

Security Level: Internal

Signaling Link No.

SPU Subsystem No.

0/2/3

49 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

RAN Transmission Interface


Capability Design

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.

8.1 Iu CS Transmission Interface Capability Design


The throughput of the Iu CS interface is calculated based on the traffic model provided by VTR, the
number of NodeBs configured in each RNC, and the number of subscribers supported by the each RNC.

8.1.1 Total Iu CS User Plane Throughput Estimation


The throughput of the Iu CS interface on the user plane consists of CS voice and CS data. The below
table lists the calculated interface throughput.
Table 8-1 Throughput of the Iu CS interface on the user plane RM1301
Item

Value

IuCS CS voice (Erl)

2710

Table 8-2 Throughput of the Iu CS interface on the user plane RM1302

2013-11-1

Item

Value

IuCS CS voice (Erl)

1683

50 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Table 8-3 Throughput of the Iu CS interface on the user plane AN201


Item

Value

IuCS CS voice (Erl)

562

Table 8-4 Throughput of the Iu CS interface on the user plane BB801


Item

Value

IuCS CS voice (Erl)

2509

8.1.2 Total Iu CS Control Plane Throughput Estimation


The below tables list the calculation results.
Table 8-5 Throughput of the Iu CS interface on the control plane for RM1301
Item

Value

IuCS control plane throughput (Mbps)

5.20

Table 8-6 Throughput of the Iu CS interface on the control plane for RM1302
Item

Value

IuCS control plane throughput (Mbps)

3.23

Table 8-7 Throughput of the Iu CS interface on the control plane for AN201
Item

Value

IuCS control plane throughput (Mbps)

1.01

Table 8-8 Throughput of the Iu CS interface on the control plane for BB801
Item

Value

IuCS control plane throughput (Mbps)

4.82

Note: IuCS control plane throughput (Mbps)=3%* IuCS user plane throughput (Mbps),

2013-11-1

51 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

8.1.3 Total Number of Ports for Iu CS Transmission on RNC


Calculation
All RNC IP transmission uses the GOUc board. The GOUc board provides 4 GE optical interfaces, and
the rate is 1 Gbps.
Based on the IuCS user plane throughput, IuCS control plane throughput, the number of the GOUc ports
required by the IuCS interface is calculated.
The below table lists the active number of GOUc ports required by the IuCS interface.
Table 8-9 Number of active GOUc ports for RM1301
GE Active Port Number
IuCS

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

Table 8-12 Number of active GOUc ports for BB801


GE Active Port Number
IuCS

8.2 Iu PS Transmission Interface Capability Design


The throughput of the Iu PS interface is calculated according to the traffic model of the VTR, the
number of NodeBs configured in the RNCs, and the number of subscribers supported by the RNCs.

2013-11-1

52 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

8.2.1 Total Iu PS User Plane Throughput Estimation


Table 8-13 Throughput of the Iu PS interface on the user plane for RM1301
Item

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

8.2.2 Total Iu PS Control Plane Throughput Estimation


The below table lists the calculation results.
Table 8-17 Throughput of the Iu PS interface on the control plane for RM1301
Item

Value

IuPS control plane throughput (Mbps)

24.8

Table 8-18 Throughput of the Iu PS interface on the control plane for RM1302

2013-11-1

Item

Value

IuPS control plane throughput (Mbps)

10

53 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Table 8-19 Throughput of the Iu PS interface on the control plane for AN201
Item

Value

IuPS control plane throughput (Mbps)

6.2

Table 8-20 Throughput of the Iu PS interface on the control plane for BB801
Item

Value

IuPS control plane throughput (Mbps)

Note:IuPS control plane throughput (Mbps)=1%*IuPS user plane throughput (Mbps)

8.2.3 Total Number of Ports for Iu PS Transmission on RNC


Calculation
All RNC IP transmission uses the GOUc board. The GOUc board provides two GE optical interfaces
with the rate 1 Gbps.
Based on the IuPS user plane throughput and IuPS control plane throughput, the number of the GOUc
ports required by the Iu PS interface is calculated.
The below table lists the number of active GOUc ports required by the Iu PS interface.
Table 8-21 Number of active GOUc ports for RM1301
GE Active Port Number
IuPS

Table 8-22 Number of active GOUc ports for RM1302


GE Active Port Number
IuPS

Table 8-23 Number of active GOUc ports for AN201


GE Active Port Number
IuPS

Table 8-24 Number of active GOUc ports for BB801


GE Active Port Number
IuPS

2013-11-1

54 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

8.3 Iub Transmission Interface Capability Design


This section describes how to calculate the traffic and throughput of the Iub interface and how to
calculate the required IP ports.

8.3.1 Traffic Mapping on IP Strategy Design


IP transport networking of the Iub interface indicates that the protocol (IP) stack networking is used
between the RNC and the NodeB.
With the development of data services, especially the introduction of the HSDPA/HSUPA, the Iub
interface has larger and larger requirements for transmission bandwidth. Introducing the IP transmission
technology can save the cost.

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.

Service Mapping and Transmission Resource Allocation Principle


For transmission resource allocation in IP transport of the Iub interface, it is recommended to:

2013-11-1

Use IP transmission for control plane data.

Perform transmission mapping according to Table 8-25 for user plane data.

55 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Table 8-25 General rules for user plane transmission mapping


Transmission Bearer Service Type
Type
IP transmission PS interactive services, PS background services, HSDPA conversational
services, HSDPA streaming services, HSDPA interactive services, HSDP
background services, HSUPA conversational services, HSUPA streaming
services, HSUPA interactive services, and HSUPA background services
z

Use IP transmission for management plane data.

Because the NodeB is directly routed to the M2000 for maintenance without passing the RNC,
the Iub interface does not have management plane data.

8.3.2 Total Iub User Plane Throughput for Iub IP Transmission


Estimation
Based on the service mapping design in the IP transport, the throughput of the Iub interface on the user
plane consists of Iub CS voice, Iub CS data, Iub PS R99, Iub PS HSDPA and Iub PS HSUPA.

The below table lists the calculation results.


Table 8-26 Throughput of the Iub interface on the user plane in IP transmission for RM1301
Item

Value

Iub Throughput (Mbps)

3714

Table 8-27 Throughput of the Iub interface on the user plane in IP transmission for RM1302
Item

Value

Iub Throughput (Mbps)

1533

Table 8-28 Throughput of the Iub interface on the user plane in IP transmission for AN201
Item

Value

Iub Throughput (Mbps)

925

Table 8-29 Throughput of the Iub interface on the user plane in IP transmission for BB801

2013-11-1

Item

Value

Iub Throughput (Mbps)

1435

56 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

8.3.3 Total Iub Control Plane Throughput for Iub IP


Transmission Estimation
The throughput of the Iub interface on the control plane consists of Iub CS signaling throughput and Iu
PS signaling throughput.
The below table is the calculation results.
Table 8-30 Throughput of the Iub interface on the control plane in IP transmission for RM1301
Item

Value

Total Iub control plane throughput (Mbps)

371.4

Table 8-31 Throughput of the Iub interface on the control plane in IP transmission for RM1302
Item

Value

Total Iub control plane throughput (Mbps)

153.3

Table 8-32 Throughput of the Iub interface on the control plane in IP transmission for AN201
Item

Value

Total Iub control plane throughput (Mbps)

92.5

Table 8-33 Throughput of the Iub interface on the control plane in IP transmission for BB801
Item

Value

Total Iub control plane throughput (Mbps)

143.5

Note: Iub control plane throughput=10%* Iub user plane throughput

8.3.4 Total Number of Ports for Iub IP Transmission on RNC


Calculation
VTR RNC IP transmission uses GOUc boards. GOUc board provides four GE optical ports with the rate
1 Gbps.
Based on the Iub user plane throughput for Iub IP transmission, the number of GOUc ports required is
calculated. The below table lists the minimum number of GOUc ports required.
Table 8-34 Number of active GOUc ports for RM1301
GE Active port number
Iub-GE

2013-11-1

57 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Table 8-35 Number of active GOUc ports for RM1302


GE Active port number
Iub-GE

Table 8-36 Number of active GOUc ports for AN201


GE Active port number
Iub-GE

Table 8-37 Number of active GOUc ports for BB801


GE Active port number
Iub-GE

8.4 Iub Transmission Configuration Design for Typical


NodeB
8.4.1 Configuration Recommendation for NCP
For all IP NodeBs, NCP bears on SCTP link and the bandwidth neednt configure.
Table 8-38 NCP configuration
DSCP
Control plane

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.

8.4.2 Configuration Recommendation for CCP


The CCP is also a control plane and has the same parameter configuration rule as the NCP.

2013-11-1

58 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Table 8-39 CCP configuration


DSCP
Control plane

CCP

48

It is recommended to configure one CCP.

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.

8.4.3 Configuration Recommendation for IPPATH


It is recommended to configure all the types of IPPATH. Table 8-40 lists the recommended IPPATH
parameters.
Table 8-40 IPPATH configuration
IPPATH Type Tx (kbps)
User EF PATH
Plane

2013-11-1

Rx (kbps)

DSCP CBS

EBS

Physical Link BWPhysical Link BW46

Physical Link 0
BW/2

AF41 PATH

Physical Link BWPhysical Link BW34

Physical Link 0
BW/2

AF42 PATH

Physical Link BWPhysical Link BW36

Physical Link 0
BW/2

AF43 PATH

Physical Link BWPhysical Link BW38

Physical Link 0
BW/2

AF31 PATH

Physical Link BWPhysical Link

26

Physical Link 0
BW/2

AF32 PATH

Physical Link BWPhysical Link

28

Physical Link 0
BW/2

AF33 PATH

Physical Link BWPhysical Link

30

Physical Link 0
BW/2

AF21 PATH

Physical Link BWPhysical Link

18

Physical Link 0
BW/2

AF22 PATH

Physical Link BWPhysical Link

20

Physical Link 0
BW/2

AF23 PATH

Physical Link BWPhysical Link

22

Physical Link 0
BW/2

AF11 PATH

Physical Link BWPhysical Link

10

Physical Link 0
BW/2

59 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

AF12 PATH

Physical Link BWPhysical Link

12

Physical Link 0
BW/2

AF13 PATH

Physical Link BWPhysical Link

14

Physical Link 0
BW/2

BE PATH

Physical Link BWPhysical Link

Physical Link 0
BW/2

Table 8-41 Configuration recommendation for IPPATH


Item

Bandwidth

IPPATH

100M

Note: The IPPATH configured for IUB is 100M, this is a logical value, and the limitation is just in TX side;

8.5 Iur Transmission Interface Capability Design


The throughput of the Iur interface is calculated according to the throughput of the Iub interface.
Because the Iur interface has no traffic model, the following Huawei's empirical value is used.

8.5.1 Total Iur User Plane Throughput Estimation


The throughput of the Iur interface is calculated according to the throughput of the Iub interface.,
considering the Iur as the 10% of the Iub throughput The below table lists the throughput of the Iur
interface on the user plane.
Table 8-42 Throughput of the Iur interface on the user plane for RM1301
Item

Value

Iur payload throughput (Mbps)

371

Table 8-43 Throughput of the Iur interface on the user plane for RM1302
Item

Value

Iur payload throughput (Mbps)

153

Table 8-44 Throughput of the Iur interface on the user plane for AN201

2013-11-1

Item

Value

Iur payload throughput (Mbps)

9.3

60 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Table 8-45 Throughput of the Iur interface on the user plane for BB801
Item

Value

Iur payload throughput (Mbps)

144

Note: Iur payload throughput=10%*Iub payload throughput

8.5.2 Total Iur Control Plane Throughput Estimation


The below table lists the calculation results.
Table 8-46 Throughput of the Iur interface on the control plane for RM1301
Item

Value

Iur control plane throughput (Mbps)

31.1

Table 8-47 Throughput of the Iur interface on the control plane for RM1302
Item

Value

Iur control plane throughput (Mbps)

15.3

Table 8-48 Throughput of the Iur interface on the control plane for AN201
Item

Value

Iur control plane throughput (Mbps)

Table 8-49 Throughput of the Iur interface on the control plane for BB801
Item

Value

Iur control plane throughput (Mbps)

14.4

Note: Iur control plane throughput (Mbps)=10%*Max(IUB DL control plane throughput ,IUB
UL control plane throughput )

8.5.3 Total Number of Ports for Iur Transmission on RNC


Calculation
Iur interface shares one GE port with IuCS.

2013-11-1

61 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

RAN Transmission Interface


Reliability Design

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.

9.1 Iub Transmission Interface Networking Reliability


Design
9.1.1 Iub Networking Topology
Figure 9-1 Iub networking

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

communication. Through PE, the RNC is connected to the IP transmission network backbone. NodeB
side, FE port is used to support connection.

9.1.2 Iub Interface Boards Redundancy Design


The RNCs have total one pair of GOUc boards for IP transportation of the Iub interface. One pair of GE
optical ports is used as backup protection.

Board Redundancy Principle


In the case of board backup, one board is active and the other is standby. When the active board is faulty,
switchover occurs and the standby board serves as active board.
The processing capability of one pair of active and standby boards is equivalent to the processing
capability of one active board.
Board backup can improve network reliability. Services can run normally so long as one of the active
and standby boards works properly. In the case of non-redundancy, the failure of a board may interrupt
network services.

Recommended Board Redundancy Mode


It is recommended GOUc boards backup mode for the Iub interface.

9.1.3 Iub Transmission Ports Redundancy in RNC Design


GOUc Port Redundancy Principle
When a pair of GOUc boards work in the backup mode, the corresponding ports of the active and
standby GOUc boards can be also in the backup mode, for example, port 0 of active board and port 0 of
standby board. Board backup and port backup are independent.
When the GE port works in the active/standby mode, one port is active and the other is standby. Only
active GE port receives and sends data. Active and backup ports share one port IP address.

Recommended port Redundancy Mode


It is recommended port backup mode of GOUc board for the Iub interface.

9.1.4 Iub Transmission Fault Detection Design


Analysis on the IPPATH Connectivity Detection Solution
The user plane IPPATH for IP transmission supports PING detection.
z

2013-11-1

Principle of IPPATH connectivity detection

63 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

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

Recommended IPPATH connectivity detection solution


For the IPPATH of the Iub interface, turn on the IPPATH connectivity detection switch.
During configuration, default parameters are usually used.

Analysis on the Gateway of RNC GE Port Connectivity Detection Solution


ARP or BFD detection can be used to detect gateway of RNC GE port connectivity according to RNC
license.

9.1.5 Iub Transmission QoS Difference Design


In terms of wireless network layers, the transmission network layers of the RNC and NodeB first map
service priorities into the DiffServ PHB at the IP layer, mark the service priorities with different DSCPs,
and then map the service priorities into the VLAN priority domain through the PHB. In addition,
operators can flexibly configure the mapping between subscriber service priorities and IP QoS and the
mapping between IP QoS and VLAN priorities according to the requirement.
Therefore, the QoS-related design covers the following three parts:
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.

Mapping between the DSCP and the VLAN priority in IP transmission.

E2E QoS Architecture:


z
z

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.

The Principle of QoS Design:


Each service will be mapped to different DSCP that is described on the first table and each user will
have a different priority allocated in HLR as described in table 2. If a conflict exists between both
tables we follow the basic rule detailed on third step. For Example: At the same time 2 users start
different services. Gold User starts a FTP download and a Bronze user starts a conversation service,
when this situation occurs the high priority will be associated with the service, so in this case the
Bronze User will have a high priority than the Gold User.

2013-11-1

64 , 113

IPRAN Network High Level Design for Project VTRRAN12

Service Type

Example

Conversational

Voice Call, Video Call

Streaming

Video Play

Interactive

Web

Background

Email, FTP

User

Gold
Silver

Security Level: Internal

PRI: R99 HSPA


Signaling Service
Service User

Bronze

*When conflict between and

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

User plane DSCP


Table 9-1 User plane DSCP

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

IPRAN Network High Level Design for Project VTRRAN12

IPPATH Type

DSCP

AF11 PATH

10

AF12 PATH

12

AF13 PATH

14

BE PATH

Security Level: Internal

Signaling plane DSCP


The SCTPLNK DSCP is set to 48.

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

R99 PS conversationalR99 Voice Signaling All


Video Circuit Switched Signaling Voice users
Bearer PTT Bearer (HP & iDEN)/ Data
Conversational / HS CVideo Circuit Switched
BearerHSPA Signaling,HSPA conversational

EF PATH

HSPA Streaming,R99 Streaming

Bronze

AF41 PATH

34

HSPA Streaming,R99 Streaming

Sliver

AF42 PATH

36

HSPA Streaming,R99 Streaming

Gold

AF43 PATH

38

HSPA/R99 high priority interactive service

Bronze

AF31 PATH

26

HSPA/R99 high priority interactive service

Sliver

AF32 PATH

28

HSPA/R99 high priority interactive service

Gold

AF33 PATH

30

HSPA/R99 medium priority interactive service

Bronze

AF21 PATH

18

HSPA/R99 medium priority interactive service

Sliver

AF22 PATH

20

HSPA/R99 medium priority interactive service

Gold

AF23 PATH

22

HSPA/R99 low priority interactive service

Bronze

AF11 PATH

10

HSPA/R99 low priority interactive service

Sliver

AF12 PATH

12

HSPA/R99 low priority interactive service

Gold

AF13 PATH

14

HSPA/R99 background service

All
users

BE PATH

5
46

66 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

IPCl
k

IP clock

IPClk Link

10

O&
M

Operations And Maintenance (OAM) Traffic

OAM link

CS(16)

9.1.6 Iub Transmission Layer Address Allocation Design


General Rules for RNC IP Address Planning
For GOUc boards that support Ethernet ports:
z

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.

The device IP address (DEVIP) is configured according to the backup mode.

Constraints of address planning

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

gateway needs one virtual IP address and two real IP addresses. In this case, the 29-bit mask can be
used.

RNC IP Address Planning


In IP L3 (FE/GE) networking, the ETHIP of each port of the RNC interface board isnt on the same
network segment as the ETHIP of the connected NodeB. In general, the OMIP of the NodeB is
recommended to be on the same network segment as the ETHIP. (ARP proxy should be enabled for the
NodeB) In this case, each NodeB needs at least two IP addresses. According to NodeB quantity, mask
could be decided.
The Iub interface uses one pairs of GOUc boards as backup mode, so, one ETHIP and one DEVIP are
needed.
For example,
GOUc_IubPair_ETHIP 10.10.10.10/30,
GOUc_IubPair_DEVIP 10.10.10.21/30
The specific network segment depends on the planned network segment with VTR.

General Rules for NodeB Address Planning


In IP L3 (FE/GE) networking, the address of a NodeB (ETHIP) must not be on the same network
segment as the RNC interface boards ETHIP and DEVIP.
Each NodeB needs one ETHIP and one OMIP.
The OMIP is recommended to be on the same network segment as the ETHIP when ARP proxy should
be enabled for the NodeB to simplify routing.

NodeB Address Planning

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

NodeB2 ETHIP:10.10.0.4/21
NodeB1 OMIP1:10.10.0.5/21
NodeB2 OMIP2:10.10.0.6/21

9.2 Iu CS Transmission Interface Networking Reliability


Design
9.2.1 Iu CS Networking Topology
Figure 9-2 Iu CS networking

9.2.2 Iu CS Interface Boards Redundancy Design


The Iu CS interface uses one pair of GOUc boards and one pair of GE ports. One GOUc board is active
and the other one is standby. When the active board is faulty, the services are switched to the standby
board. This improves network reliability.
It is recommended that GOUc boards backup mode for the Iu CS interface.

2013-11-1

69 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

9.2.3 Iu CS Transmission Ports Redundancy in RNC Design


Recommended Port Redundancy Mode for IuCS interface
It is recommended port backup mode of GOUc board for the IuCS interface.
Figure 9-3 Redundancy mode of Iu CS GOUc ports

9.2.4 Iu CS Transmission Fault Detection Design


Recommended IPPATH connectivity detection solution
For the IPPATH of the Iu CS interface, enable the IPPATH connectivity detection switch.

Recommended Gateway of RNC GE Port Connectivity Detection Solution


ARP or BFD detection can be used to detect gateway of RNC GE port connectivity according to RNC
license.

9.2.5 Iu CS Transmission QoS Difference Design

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

Table 9-3 DSCP mapping for signaling and user part


Traffic

Link/PATH

DSCP

Service

Signaling

SCTP

48

Signing

User Data

IPPATH

46

Conversational

Requirements for Transmission QoS


Table 9-4 Requirements for Iu CS transmission QoS
UTRAN traffic class

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

9.3 Iu PS Transmission Interface Networking Reliability


Design
9.3.1 Iu PS Networking Topology
Figure 9-4 Iu PS networking

2013-11-1

71 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

9.3.2 Iu PS Interface Boards Redundancy Design


The Iu PS interface uses one pair of GOUc boards and one pair of GE ports. One GOUc board is active
and the other one is standby. When the active board is faulty, the services are switched to the standby
board. This improves network reliability.
It is recommended that GOUc boards backup mode for the Iu PS interface.

9.3.3 Iu PS Transmission Ports Redundancy in RNC Design


GOUc GE port Backup
When a pair of GOUc boards work in the backup mode, the corresponding ports of the active and
standby GOUc boards can be also in the backup mode, for example port 0 of active board and port 0 of
standby board. Board backup and port backup are independent.
When the GE port works in the active/standby mode, one port is active and the other is standby. Only
active GE port receives and sends data. Active and backup ports share one port IP address.

Recommended Port Redundancy Mode for IuPS interface


It is recommended port backup mode of GOUc board for the IuPS interface.

2013-11-1

72 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

9.3.4 Iu PS Transmission Fault Detection Design


Refer to 9.2.4 Iu CS Transmission Fault Detection Design

9.3.5 Iu PS Transmission QoS Difference Design


Table 9-5 Iu PS DSCP Design
Traffic

Link/PATH

DSCP

Signing

SCTP

48

User Data

QOS IPPATH

Table 9-6 TRMMAP For IUPS-1


DSCP

Service

48

Signing

46

Conversational

43

Streaming

23

Interactive_ high

22

Interactive_ middle

21

Interactive_ low

Background

Table 9-7 TRMMAP For IUPS-2

2013-11-1

73 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

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).

Table 9-8 Requirements for Iu PS transmission QoS

2013-11-1

UTRAN traffic class

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

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

9.4 Iur Transmission Interface Networking Availability


Design
9.4.1 Iur Networking Topology

Figure 9-5 Iur networking


The Iur and Iu CS interfaces share ports and both use IP transmission. The IP network ensures that the
Iur and Iu CS interfaces are routed to correct destination addresses.

9.4.2 Iur Interface Boards Redundancy Design


The Iur interface shares the interface board with the Iu CS interface. Therefore, the Iur interface uses the
same board redundancy mode as the Iu CS interface, that is, one pair of GOUc boards is set to the
backup mode.

9.4.3 Iur Transmission Ports Redundancy in RNC Design


The Iur interface shares GE ports with the Iu CS interface. Therefore, the Iur interface uses the same
port redundancy mode as the Iu CS interface, that is, one pair of GE ports is set to the backup mode.

2013-11-1

75 , 113

IPRAN Network High Level Design for Project VTRRAN12

Security Level: Internal

9.4.4 Iur Transmission Fault Detection Design


z

Recommended IPPATH connectivity detection solution

For the IPPATH of the Iur interface, turn on the IPPATH connectivity detection switch.
z

Recommended Gateway of RNC GE Port Connectivity Detection Solution

In L3 networking, GE ports need to detect gateway connectivity.


BFD detection is recommended to detect gateway of RNC GE port connectivity when RNC license is
supported.

9.4.5 Iur Transmission QoS Difference Design


The QoS design for the network is based on DSCP and User priority already defined in the QoS design
having the singaling DSCP and services already mapped.

Requirements for Transmission QoS


Table 9-9 Requirements for Iur transmission QoS

2013-11-1

UTRAN traffic class

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.

10.1 Negotiation Design for RNC


10.1.1 Parameters of SS7 Design
The parameters to be negotiated in the SS7 network are signaling point code, signaling point code bits,
and network ID.
Table 10-1 Parameters to be negotiated in the SS7 network
Parameters to Description
Be Negotiated
Network ID

Recommend Negotiation Principle


Value

This parameter specifies which typ None


of signaling coding scheme is
adopted in the SS7 network.

Signaling point This parameter is unique in the SS None


network.
code

(11/1/2013)

Commercial in Confidence

Consistency of network ID

(The local network ID should be


consistent with the peer network ID.

The setting of the local signaling po


code depends on that of the peer end

Page 77 of 113

UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01

Signaling point This parameter specifies the numb None


of signaling point code bits.
code bits

Consistency of signaling point code

(The number of the signaling point c


bits at the local end is consistent wit
that at the peer end.)

10.2 Iu CS Interconnection Negotiation Design


10.2.1 Topology of Iu CS Interconnection
Based on the VTR, the Iu interface adopts the IP networking mode. Figure 10-1 shows the protocol
stack for the IP-based Iu CS interface.
Figure 10-1 Protocol stack for the IP-based Iu CS interface

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

10.2.2 Iu CS Transmission Physical Layer Negotiation Design


The interface board on the Iu CS interface is the GOUc, which is the GE optical interface board. When
the GE optical port is used, the parameters of the optical port on the GOUc board should be consistent
with those at the peer end. The related parameters include the maximum transmission unit, whether to
enable auto negotiation, and whether to enable flow control. Based on the VTRs network planning, an
IP address is assigned to each Ethernet port. In addition, the Iu interface uses layer 3 networking, and
thus need to negotiate with the device IP address of the interface board. The following table lists the
data to be negotiated before configure the Iu CS interface.
Table 10-2 Physical layer data of the Iu CS interface to be negotiated
Data to Be

Description

Negotiated
Ethernet port data

Device IP address
of the interface
board

GE
port

(11/1/2013)

Recommended
Value

Negotiation
Principle

It consists of the IP address None


of the Ethernet port and
subnet mask.

The configuration of this


data

When the Iu CS 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.

1,500

Consistency of data
configuration

Maximum
It refers to the maximum
transmission length of the transmission
unit.
unit

is determined by the VTR


based on the network
planning.

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

In the Ethernet, flow control ON


required when the flow
control frame needs to be
sent and handled.

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

10.2.3 Signaling Links Negotiation Design of Iu CS Signaling


Plane
On the signaling plane, the protocol layers to be negotiated are IP, SCTP, M3UA, and SCCP.
(1) Data to be negotiated on the IP layer
Table 10-3 IP layer data of the Iu CS interface to be negotiated
Parameters to

Description

Be Negotiated

Recommende Negotiation Principle


Value

IP address of the gateway When the Iu CS interface None


between the RNC and the uses layer 3 networking, t
MSC Server
IP address of the gateway
between the RNC and the
MSC server should be
configured.

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

This parameter specifies The RNC serve The configuration


as the client.
of this parameter should be
the
negotiated.
working mode of the SC
link.
(Huawei recommends that the RNC
serve as the client
and the MSC serve
as the server.)

Local SCTP port No.

This parameter is used t None


identify the subscribers
with the same IP
address. It is also the
logical transmitter and
receiver of SCTP packet

Commercial in Confidence

Recommende Negotiation Principle


Value

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

Peer SCTP port No.

This parameter is used t 2905


identify the subscribers
with the same IP
address.

The configuration
of this parameter should be
negotiated.

Generally,
according to the protocol when the MS
serve as
Server, its port
NO. is 2905

RNC IP address One

This parameter refers to None


IP address of the Ethern
port or
the device IP address of
board.

The configuration
of this parameter is determined by the V
based on the network planning.

RNC IP address Two

This parameter refers to None


IP address of the Ethern
port or
the device IP address of
board.

The configuration
of this parameter is determined by the V
based on the network planning.

MSC Server IP
address One

This parameter specifies None


the IP address of the MS
server.

The configuration
of this parameter is determined by the V
based on the network planning.

MSC Server IP
address Two

This parameter specifies None


the IP address of the MS
server.

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

Table 10-5 M3UA layer data of the Iu CS interface to be negotiated


Parameters
to Be
Negotiated

Description

Recommended Valu Negotiation Principle

Application
Mode

The application mode M3UA_IPSP


can
be set to ASP or IPSP.

Consistency of data
configuration
(Huawei recommends that th
application mode on both th
RNC
side and the MSC side be se
IPSP)

Traffic Mode This parameter mainly M3UA_LOADSHARE Consistency of data


configuration
consists of active/stand MOD
mode and load sharing
(Huawei recommends that th
mode.
traffic mode on both the RN
side and the
MSC side be set to load
sharing mode.)
Routing
Context

This parameter specifi 4294967295


the routing context of
M3UA entity.

The configuration of this


parameter should be
negotiated.
(Huawei recommends that th
routing context be not
configured on the RNC side
The RNC obtains the value
the routing context of the
M3UA
entity from the MSC side.)

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

Table 10-6 SCCP layer data of the Iu CS interface to be negotiated


Parameters to Be
Negotiated

Description

Recommended Negotiation
Value
Principle

Inactive TX timer

When this timer expires, a


90s
detection message is sent to the
peer end.

This parameter is
configured according
the value of the inact
RX
timer on the
RNC.

Inactive RX timer

If this timer does not receive an 720s


detection message when this tim
expires, the connection is
released.

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).

10.2.4 IP PATH Negotiation Design of Iu CS User Plane


The Iu interface uses layer 3 networking. In this case, an IP path is added and parameters related to IP
route are configured.
(1) IP path data to be negotiated:

(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

Table 10-7 IP path data of the Iu CS interface to be negotiated


Parameters to Be Description
Negotiated

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

(2) IP route data to be negotiated


Table 10-8 IP route data of the Iu CS interface to be negotiated
Parameters to Description
Negotiated

Recommended
Value

Negotiation
Principle

Destination

None

The configuration o
this parameter is
determined by the
VTR based
on the network
planning.

This parameter specifies the subn None


mask.

The configuration o
this parameter is
determined by the
VTR based
on the network
planning.

IP address

Subnet mask

(11/1/2013)

This parameter specifies the IP


address of the MSC.

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

This parameter specifies the IP


address of the Gateway.

None

The configuration o
this parameter is
determined by the
VTR based
on the network
planning.

10.2.5 Iu CS RANAP Negotiation Design


The RANAP layer data to be negotiated are the CN protocol version and the CR type supported by the
CN protocol version.
z

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.

10.2.6 Iu CS IUUP Negotiation Design


The IUUP layer data to be negotiated is the IUUP version number. The IUUP version can be V1 or V2.
The difference between V1 and V2 is that V2 supports the TFO/TRFO function but V1 does not support
it.
The default version number of the IUUP supported by Huawei RNC is V1.

(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

Table 10-9 IUUP version number


IUUP Version Description
Number
V1

Does not support the TFO/TRFO function.


Default version number of the IUUP.

V2

Support the TFO/TRFO function.


The RNC can be set to support V2 through commands.
In this case, a license is required.

10.3 Iu PS Interconnection Negotiation Design


10.3.1 Topology of Iu PS Interconnection
According to the actual network conditions, the Iu PS interface adopts IP-based networking. Figure 10-3
shows the protocol stack for the IP-based Iu PS interface.
Figure 10-3 Protocol stack for the IP-based Iu PS interface

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

Figure 10-4 Logical networking on the Iu PS interface

10.3.2 Iu PS Transmission Physical Layer Negotiation Design


The interface board on the Iu PS interface is the GOUc, which is the GE optical interface board. When
the GE optical port is used, the parameters of the optical port on the GOUc board should be consistent
with those at the peer end. The related parameters include the maximum transmission unit, whether to
enable auto negotiation, and whether to enable flow control. Based on the VTRs network planning, an
IP address is assigned to each Ethernet port. In addition, the Iu interface uses layer 3 networking, and
thus need to negotiate the device IP address of the interface board. The following table lists the data to
be negotiated before configure the Iu PS interface.
Table 10-10 Physical layer data of the Iu PS interface to be negotiated
Data to Be
Negotiated

Description

Recommended
Value

Negotiation
Principle

Ethernet port data

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

In the Ethernet, flow


control is required
when the flow
control frame needs
to be sent and
handled.

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

10.3.3 Signaling Links Negotiation Design of Iu PS Signaling


Plane
On the signaling plane, the protocol layers to be negotiated are the IP, SCTP, M3UA, and SCCP.
(1) Data to be negotiated on the IP layer
Table 10-11 IP layer data of the Iu PS interface to be negotiated
Parameters to Be
Negotiated

Description

Recommended
Value

Negotiation
Principle

IP address of the
gateway between the
RNC and the SGSN

When the Iu PS interface


uses L3 networking, the IP
address of the gateway
between the RNC and the
SGSN should be
configured.

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

Table 10-12 SCTP layer data of the Iu PS interface to be negotiated


Parameters to Be
Negotiated

Description

Recommended
Value

Negotiation
Principle

Working mode

This parameter specifies the


working mode of the SCTP link.

The RNC serves


as the client.

The configuration
of this parameter
should be
negotiated.
(Huawei
recommends that
the RNC serve as
the client and the
SGSN serve as the
server.)

Local SCTP port


No.

Peer SCTP port No.

This parameter is used to


identify the subscribers with the
same IP address. It is also the
logical transmitter and receiver
of SCTP packets.

None

This parameter is used to


identify the subscribers with the
same IP address.

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

This parameter refers to the IP


address of the Ethernet port or
the device IP address of the
board.

None

The configuration
of this parameter
is determined by
the VTR based on
the network
planning.

RNC IP address
Two

This parameter refers to the IP


address of the Ethernet port or
the device IP address of the
board.

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

This parameter specifies the IP


address of the SGSN.

None

The configuration
of this parameter
is determined by
the VTR based on
the network
planning.

SGSN IP address
Two

This parameter specifies the IP


address of the SGSN.

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
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

The application mode can


be set to ASP or to IPSP.

M3UA_IPSP

The configuration of this parameter


should be negotiated.
(Huawei recommends that the
application mode on both the RNC
side and the SGSN side be set to
IPSP.)

Traffic Mode

Routing
Context

The traffic mode can be set


to active/standby mode or
to load sharing mode.

M3UA_LOA
DSHARE_M
OD

Consistency of data configuration

This parameter specifies


the routing context of the
M3UA entity.

4294967295

Consistency of data configuration

(Huawei recommends that the traffic


mode on both the RNC side and the
SGSN side be set to load sharing
mode.)

(Huawei recommends that the


routing context be not configured on
the RNC side.)

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

When this timer expires, a


detection message is sent
to the peer end.

90 s

This
parameter is
configured
according to
the value of
the inactive
RX timer on
the SGSN.

Inactive RX timer

If this timer does not


receive any detection
message when this timer
expires, the connection is
released.

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

10.3.4 IP PATH Negotiation Design of Iu PS User Plane


The Iu interface uses L3 networking. In this case, an IP path is added and parameters related to IP route
are configured.
(1) IP path data to be negotiated
Table 10-15 IP path data of the Iu PS interface to be negotiated
Parameters to
Be Negotiated

Description

Recommended
Value

Negotiation
Principle

Local IP address
and subnet mask
of the RNC

This parameter specifies


the service IP address on
the RNC side and the
mask of the subnet where
the board resides.

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

This parameter specifies


the IP address of the
SGSN.

None

The
configuration of
this parameter
is determined
by the VTR
based on the
network
planning.

(2) IP route data


Table 10-16 IP route data of the Iu PS interface to be negotiated

(11/1/2013)

Parameters
to Be
Negotiated

Description

Recommended
Value

Negotiation
Principle

Destination
IP address

This parameter specifies the IP


address of the SGSN.

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

This parameter specifies the subnet


mask.

None

The
configuration
of this
parameter is
determined
by the VTR
based on the
network
planning.

Next hop

This parameter specifies the IP


address of the Gateway.

None

The
configuration
of this
parameter is
determined
by the VTR
based on the
network
planning.

10.3.5 Iu PS RANAP Negotiation Design


The RANAP layer data to be negotiated are the CN protocol version and the CR type supported by the
CN protocol version.
z

The CN protocol version can be R99, R4, R5 or R6. It needs to obtain the proper
protocol version from the SGSN.

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.

(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

10.4 Iub Interconnection Negotiation Parameters


Recommendation Design
10.4.1 Topology of Iub Interconnection
(1) Iub interface protocol stack (over IP)
Figure 10-5 Iub interface protocol stack

(2) Topology of Iub interconnection


Figure 10-6 Iub interface topology (Control Plane)

(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

Figure 10-7 Iub interface topology (User Plane)

(3) Iub interface bear type


Figure 10-8 Iub interface bear type

10.4.2 Negotiation Parameters of Transmission Physical Layer


Design and Recommendation
According to the different bearing types used on the Iub interface, the NodeB can use the FE electrical
port to connect to the interconnection equipment, and the RNC can use the GE port to connect to the
interconnection equipment. Therefore, the physical layer data to be negotiated consists of the parameters
related to FE electrical port and GE optical port.
(1) FE port data to be negotiated

(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

Table 10-17 FE port data to be negotiated

No. Name

Description

Recommende Negotiation Prin


Value

Maximum transmission This parameter specifies the maximum


unit (MTU)
length of the transmission unit.

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

If auto negotiation is disabled, the


transmission rate over the FE port, worki
mode, and whether to enable flow contro
are user-defined. In addition, ensure that
configured parameters are consistent with
the parameters at the peer end. Otherwise
transmission failure may occur.

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

This parameter is configured only when t None


auto negotiation is disabled.

The
configuration
of this
parameter on
the NodeB
should be consiste
with that on
the RNC.

Whether to
enable flow
control

This parameter is configured only when t None


auto negotiation is disabled. FC is a fram
used in the Ethernet. It specifies whether
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.

This parameter is configured only when t None


auto negotiation is disabled.

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

If auto negotiation is enabled, the


ENABLE
transmission rate over the FE port,
working mode, and whether to enabl
flow control
depend on the negotiation results.
If auto negotiation is disabled, the
transmission rate over the FE port,
working mode, and whether to enabl
flow control are user-defined. In
addition, ensure that the configured
parameters are consistent with the
parameters at the peer end. Otherwis
transmission failure may occur.

Whether to
enable flow
control

This parameter is configured only w None


the
auto negotiation is disabled. FC is a
frame used in the Ethernet. It specifi
whether to enable flow control.

The
configur
of this
paramet
the Nod
should b
with tha
the RNC

10.4.3 Negotiation Parameters of Transmission Signaling Link


Design and Recommendation
(1) SCTP data to be negotiated
Table 10-19 SCTP data to be negotiated

(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.

Local IP address 1 This parameter specifies the local None


of the SCTP link address 1 of the SCTP link.

Local IP address 2 This parameter specifies the local None


of the SCTP link address 2 of the SCTP link.

Peer IP address of This parameter specifies the peer None


the SCTP link
address of the SCTP link.

The configurat
of this data is
determined by
the customer
based on
the network
planning.

Local SCTP port N This parameter specifies the numb None


of the local port used by the SCTP
link

The configurat
of this data is
determined by
the customer
based on
the network
planning.

Peer SCTP port No This parameter specifies the numb None


of the port used by the SCTP link
the peer end.

The configurat
of this parame
is determined b
the configurati
on the NodeB.

(2) NCP and CCP data to be negotiated


Table 10-20 NCP and CCP data to be negotiated

(11/1/2013)

No.

Name

Description

Recommended Value

CCP por This parameter is used to identif 0


No.
CCP link.

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

10.4.4 Negotiation Parameters of IP PATH Design


IP path data to be negotiated
Table 10-21 IP path data to be negotiated
No. Name

(11/1/2013)

Description

Recommended Negotiation Principle


Value

NodeB IP addre This parameter specifies the servic None


of an IP path
IP address on the NodeB side.

The configuration of this


data is
determined by the custom
based on
the network planning.

RNC IP address This parameter specifies the servic None


of an IP path
IP address on the RNC side.

The configuration of this


data is
determined by the custom
based on
the network planning.

IP path service This parameter specifies the servic None


type
type used by the IP path. (Which
service type to use should be
negotiated between the two ends)

The IP path service


type configured on
the NodeB should
be consistent with
that on the RNC.

IP path received This parameter specifies the receiv None


bandwidth
bandwidth of the IP path.

IP path transmit This parameter specifies the transmNone


bandwidth
bandwidth of the IP path.

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.

IP path check fl This parameter specifies whether t DISABLED


(optional)
IP path is tested. If IP path check f
is set to ENABLED, [peer IP addr
to be checked] should be negotiate
with the peer end.

The configuration of this


parameter on the NodeB
should be consistent with
that
on the RNC.

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.

The configuration of this


data is
determined by the custom
based on
the network planning.

FPMUX switch This is to solve the overlarge IP


header in the CS service.

The configuration of this


parameter on the NodeB
should be consistent with
that
on the RNC.

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

DSCP (optional DSCP is short for Differentiated None


Services CodePoint. In the same
network environment, the greater
DSCP is,
the higher the priority is.

The configuration of this


parameter on
the NodeB should be
consistent with that
on the RNC.

10.4.5 Negotiation Parameters of NBAP Design


Table 10-22 NBAP data to be negotiated
No. Name
1

Description

Recommended
Value

NBAP protocol version This parameter specifies the protoco R6


version on the NodeB side.

Negotiation
Principle
The NBAP
protocol
version on the
NodeB should
be consistent
with that on
the RNC side.

10.5 Iur Interconnection Negotiation Design


10.5.1 Topology of Iur Interconnection
According to the actual network conditions, the Iur interface adopts IP-based networking. Figure 10-9
shows the protocol stack for the IP-based Iur interface.

(11/1/2013)

Commercial in Confidence

Page 100 of 113

UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01

Figure 10-9 Logical networking on the Iur interface (1)

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)

10.5.2 Iur Transmission Physical Layer Negotiation Design


The interface board on the Iur interface is the GOUc, which is the GE Optical interface board. When the
GE optical port is used, the parameters of the optical port on the GOUc board should be consistent with
those at the peer end. The related parameters include the maximum transmission unit, whether to enable
auto negotiation, and whether to enable flow control. Based on the VTRs network planning, an IP
address is assigned to each Ethernet port. In addition, the Iur interface uses layer 3 networking, and thus
need to negotiate device IP address of the interface board. Table 10-23 lists the data to be negotiated
before configure the Iur interface.

(11/1/2013)

Commercial in Confidence

Page 101 of 113

UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01

Table 10-23 Physical layer data of the Iur interface to be negotiated


Data to Be
Negotiated

Description

Recommended
Value

Negotiation
Principle

Ethernet port data

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 Iur


interface uses layer
3 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.

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

10.5.3 Signaling Links Negotiation Design of Iur Signaling Plane


On the signaling plane, the protocol layers to be negotiated are IP, SCTP, M3UA, and SCCP.

(11/1/2013)

Commercial in Confidence

Page 102 of 113

UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01

(1) Data to be negotiated on the IP layer


Table 10-24 IP layer data of the Iur interface to be negotiated
Parameters to Be
Negotiated

Description

Recommended
Value

Negotiation
Principle

IP address at the next


hop of the RNC

When the Iur interface


uses layer 3
networking, the IP
address of the
gateway between the
RNC and the
neighboring RNC
should be configured.

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

This parameter specifies


the working mode of the
SCTP link.

The RNC serves


as the client.

The
configuration
of this
parameter
should be
negotiated.
(Huawei
recommends
that the RNC
serve as the
client and the
NRNC serve as
the server.)

Local SCTP port


No.

This parameter is used to


identify the subscribers
with the same IP address.
It is also the logical
transmitter and receiver of
SCTP packets.

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

Page 103 of 113

UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01

Peer SCTP port


No.

This parameter is used to


identify the subscribers
with the same IP address.

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

This parameter refers to


the IP address of the
Ethernet port or the device
IP address of the board.

None

The
configuration
of this
parameter is
determined by
the VTR based
on the network
planning.

NRNC IP
address One

This parameter specifies


the IP address of the
neighboring RNC.

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

Page 104 of 113

UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01

Table 10-26 M3UA layer data of the Iur interface to be negotiated


Paramete
rs to Be
Negotiate
d

Description

Recomm
ended
Value

Negotiation Principle

Applicatio
n Mode

The application mode


can be set to ASP or
to IPSP.

M3UA_IP
SP

The configuration of this


parameter should be
negotiated.
(Huawei recommends that the
application mode on both the
RNC and the NRNC be set to
IPSP.)

Traffic
Mode

Routing
Context

The traffic mode can


be set to
active/standby mode
or to load sharing
mode.

M3UA_L
OADSHA
RE_MOD

Consistency of data
configuration

This parameter
specifies the routing
context of the M3UA
entity.

429496729
5

The configuration of this


parameter should be
negotiated.

(Huawei recommends that the


traffic mode on both the RNC
side and the NRNC side be set
to load sharing mode.)

(Huawei recommends that the


routing context be not
configured on the RNC side.
The RNC obtains the value of
the routing context of the
M3UA entity from the NRNC
side.)

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

Page 105 of 113

UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01

Table 10-27 SCCP layer data of the Iur interface to be negotiated


Parameters to Be
Negotiated

Description

Recommended
Value

Negotiation
Principle

Inactive TX timer

When this timer expires,


a detection message is
sent to the peer end.

90s

This
parameter is
configured
according to
the value of
the inactive
RX timer on
the NRNC.

Inactive RX timer

If this timer does not


receive any detection
message when this timer
expires, the connection is
released.

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.

10.5.4 IP PATH Negotiation Design of Iur User Plane


The Iur interface uses layer 3 networking. In this case, an IP path is added and parameters related to IP
route are configured.
(1) IP path data to be negotiated

(11/1/2013)

Commercial in Confidence

Page 106 of 113

UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01

Table 10-28 IP path data of the Iur interface to be negotiated


Parameters to Be
Negotiated

Description

Recommended
Value

Negotiation
Principle

Local IP address
and subnet mask
of the RNC

This parameter specifies


the service IP address on
the RNC side and the
mask of the subnet
where the board resides.

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

This parameter specifies


the IP address of the
neighboring RNC.

None

The
configuration
of this
parameter is
determined by
the VTR based
on the network
planning.

(2) IP route data to be negotiated


Table 10-29 IP route data of the Iur interface to be negotiated

(11/1/2013)

Parameters
to Be
Negotiated

Description

Recommended
Value

Negotiation
Principle

Destination
IP address

This parameter specifies the


IP address of the neighboring
RNC.

None

The
configuration
of this
parameter is
determined by
the VTR based
on the network
planning.

Subnet mask

This parameter specifies the


subnet mask.

None

The
configuration
of this
parameter is
determined by
the VTR based
on the network
planning.

Commercial in Confidence

Page 107 of 113

UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01

Next hop

This parameter specifies the


IP address of the EMS.

None

The
configuration
of this
parameter is
determined by
the VTR based
on the network
planning.

10.5.5 Iur RNSAP Negotiation Design


The RNSAP layer data to be negotiated is the protocol version supported by the NRNC
The protocol version can be R99, R4, R5 or R6. It needs to obtain the proper protocol version from the
NRNC.

(11/1/2013)

Commercial in Confidence

Page 108 of 113

UMTS RAN High Level Design for VTR RNC_STG_01, RNC_STG_02, RNC_ATF_01,
RNC_CLL_01

11

RAN Common Features


Design

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.

11.1 Huawei RNS Iur Interoperability Strategy Design


Figure 11-1 shows the position of the Iur interface in the network.
Figure 11-1 Serving and Drift RNS

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

Page 109 of 113

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.2 Iur Interoperability Strategy Design for CS Traffic only


The CS service on the live network mainly refers to AMR voice service and video call service. These
two services provide the following features: High real-time requirements Low usage of network
resources Short duration of services
According to the features mentioned above, the CS service adopts soft handover on the Iur interface.

11.1.3 Iur Interoperability Strategy Design for R99 PS Traffic


only
R99 PS service has the feature of low real-time requirements, low usage of network resources, and long
duration of services.
According to the features mentioned above, R99 PS service adopts soft handover on the Iur interface.
After the handover, the DSCR is initiated if one of the following requirements is met:
UE only has a connection with the cells under the DRNC, and congestion alarm occurs to the Iur
transmission resources that carry PS traffic.
All intra-frequency neighboring cells of the best cell are not under SRNC.
The period during which all radio links are connected with DRNC exceeds a certain threshold, for
example 30s.
Through the triggering of the DSCR, the UE selects a cell under the DRNC and re-establishes the
connections. The original connections on the Iur interface are released.

11.1.4 Iur Interoperability Strategy Design for HSDPA PS and


CS Traffic Combination
When a single subscriber uses both the HSDPA service and the CS service, Huawei recommends that
the Iur soft handover is initiated. When the best cell is under the DRNC, the HS-DSCH channel is
converted into the DCH channel. When the voice service in the CS domain is complete (Generally, the
CS service does not last for a long time), the processing of R99 PS service on the Iur interface is the
same as the processing described in 11.1.3 .

(11/1/2013)

Commercial in Confidence

Page 110 of 113

12
AAL2

ATM Adaptation Layer type 2

ALCAP

Access Link Control Application Part

AMR

Adaptive Multi Rate

ARP

Address Resolution Protocol

ATM

Asynchronous Transfer Mode

BAM

Back Administration Module

BITS

Building Integrated Timing Supply System

BPS

Board Protect Switch

CCP

Communication Control Port

CN

Core Network

CRNC

Controlling RNC

CS

Circuit Switched

DHCP

Dynamic Host Configuration Protocol

DRNS

Drift RNS

DSCP

DiffServ Code Point

EMS

Element Management System

ESN

Electronic Serial Number

FE

Fast Ethernet

FP

Frame Protocol

GE

Gigabit Ethernet

GPS

Global positioning system

GTP-U

GPRS Tunneling Protocol User Plane

HDB3

High Density Bipolar 3

HSDPA

High Speed Downlink Packet Access

HS-DSCH

High Speed Downlink Shared Channel

HSUPA

High Speed Uplink Packet Access

IP

Internet Protocol

IPDV

IP Packet Delay Variation

(11/1/2013)

Acronyms and
Abbreviations

Commercial in Confidence

Page 111 of 113

IPLR

IP Packet Loss Rate

IPTD

IP Packet Time Delay

IUUP

Iu Interface User Plane

LMT

Local Maintenance Terminal

M2000

iManager M2000

MAC

Medium Access Control

MBMS

Multimedia Broadcast Multicast Service

MDC

Macro Diversity Convergence

MGW

Media Gateway

MSC

Mobile services Switching Canter

MSP

Multiplex Section Protection

MTP3

Message Transfer Part Level 3

MTU

Maximum Transfer Unit

NBAP

NodeB Application Protocol

NCP

NodeB Control Port

NodeB

WCDMA base station

NRI

Network Resource Identifier

NRNC

Neighboring Radio Network Controller

NRT

Non-Real-Time

OMC

Operation and Maintenance Center

OMIP

IP Address of Operation and Maintenance

PDCP

Packet Data Convergence Protocol

PPP

Point-to-Point Protocol

PPS

Port Protect Switch

PS

Packet Switched

PVC

Permanent Virtual Channel

QoS

Quality of Service

RAN

Radio access network

RANAP

Radio Access Network Application Part

RBS

RNC Business Subrack

RLC

Radio Link Control

RNC

Radio Network Controller

RSS

RNC Switch Subrack

RTP

Real-Time Transport Protocol

RT-VBR

Real Time Variable Bit Rate

SAAL

Signaling ATM Adaptation Layer

SCTP

Stream Control Transmission Protocol

SDH

Synchronous Digital Hierarchy

SGSN

Serving GPRS Support Node

SHO

Soft HandOver

SNTP

Simple Network Time Protocol

SRNC

Serving RNC

(11/1/2013)

Commercial in Confidence

Page 112 of 113

STM-1

SDH Transport Module-1

UBR

Unspecified Bit Rate

UDP

User Datagram Protocol

UE

User Equipment

UMTS

Universal Mobile Telecommunications System

UNI

User-Network Interface

UTRAN

UMTS Terrestrial Radio Access Network

VCI

Virtual Channel Identifier

VLAN

Virtual Local Area Network

VPI

Virtual Path Identifier

VRRP

Virtual Route Redundancy Protocol

(11/1/2013)

Commercial in Confidence

Page 113 of 113