Sie sind auf Seite 1von 223

UMTS RNC Product Engineering Information

Document number: UMT/IRC/APP/13737

Document issue: 06.01/EN


Document status: Preliminary
Date: 07/25/2011

External document

Copyright 2011 Alcatel-Lucent, All Rights Reserved

Printed in France

UNCONTROLLED COPY: The master of this document is stored on an electronic database and is write
protected; it may be altered only by authorized persons. While copies may be printed, it is not recommended.
Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be regarded
as uncontrolled copies.

ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of Alcatel-
Lucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information
contained herein confidential, shall disclose the information only to its employees with a need to know, and shall
protect the information from disclosure and dissemination to third parties. Except as expressly authorized in
writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you have
received this document in error, please notify the sender and destroy it immediately.

without notice. Nortel Networks assumes no responsibility for errors that might appear in t.All other brand and
product names are trademarks or regist

ered trademarks of their respective holders.


UMTS RNC Product Engineering Information

PUBLICATION HISTORY
March 2010
Issue 05.04 / EN, Preliminary Version for UA07.1 DR4

Error in nb of cell max page 172


Add SFP specification page 66

March 2010
Issue 05.05 / EN, Preliminary Version for UA07.1 DR4
Correction Nbr Max of AAL2 path

June 2010
Issue 05.06/EN, Standard Version for UA07.1 DR5

Market Model evolution on Full IP configuration

Introduction of 16pOC3 (PQC and MS3) evolution from UA7.1

Introduction of GiGe evolution from UA7.1

Improvement for RNC Sparing Model and Redundancy

August 2010
Issue 05.07/EN Standard version update for
UA07.1.2TMU RAB Balancing evolution

December 2010
Issue 05.08/EN Standard version update for UA07.1.2 DR5

Update regarding dedicated cards for slots 14,15 8,9 & 1,2

Update and Re pagination for IuB Interface

Update for Iu BC Interface sharing

July 2011
Issue 06.01/EN preliminary version update for UA08.1 DR4

New document related to release UA06, UA07 and UA08

Update regarding PMC organization on the releases

Update and improvement regarding RNC IP System Architecture


Update and improvement regarding RNC Radio Interface

Update for all the new UA08.1 features

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 2/223


UMTS RNC Product Engineering Information

CONTENTS

1. INTRODUCTION ..........................................................................................................................12
1.1. OBJECT ..................................................................................................................................12
1.2. SCOPE OF THIS DOCUMENT .....................................................................................................12
1.3. AUDIENCE FOR THIS DOCUMENT ..............................................................................................16
1.4. ABOUT THIS DOCUMENT ........................................................................................................17

2. RELATED DOCUMENTS ............................................................................................................19


2.1. STANDARDS .......................................................................................................................19
2.1.1 3GPP .............................................................................................................................19
2.1.2 ITU-T .............................................................................................................................20
2.1.3 ANSI ..............................................................................................................................21
2.1.4 ATM-Forum ...................................................................................................................21
2.1.5 IETF RFC ......................................................................................................................22
2.1.6 BellCordia ......................................................................................................................22
2.1.7 STATE OF COMPLIANCY ............................................................................................23
2.2. PROCESS ............................................................................................................................24
2.2.1 EXTERNAL ...................................................................................................................24
2.3. PLM ......................................................................................................................................25
2.3.1 EXTERNAL ...................................................................................................................25
2.4. LCM/NPI ...............................................................................................................................25
2.4.1 EXTERNAL ...................................................................................................................25
2.5. TECHNICAL PUBLICATIONS ......................................................................................................27
2.5.1 EXTERNAL ...................................................................................................................27
2.6. TECHNICAL PUBLICATIONS OPERATIONS ..............................................................................28
2.6.1 EXTERNAL ...................................................................................................................28
2.7. R&D ......................................................................................................................................29
2.7.1 EXTERNAL ...................................................................................................................29
2.8. ENGINEERING ....................................................................................................................30
2.8.1 EXTERNAL ...................................................................................................................30
2.9. RADIO NETWORK CONTROLLER 9370 RNC .............................................................................31
2.9.1 EXTERNAL ...................................................................................................................31
2.10. I&C ........................................................................................................................................33
2.10.1 EXTERNAL ...................................................................................................................33
2.11. SOL-COM ..............................................................................................................................34
2.11.1 EXTERNAL ...................................................................................................................34

3. ABBREVIATIONS AND DEFINITIONS .......................................................................................35


3.1. ABBREVIATIONS ......................................................................................................................35
3.2. DEFINITIONS ...........................................................................................................................38

4. RNC OVERVIEW .........................................................................................................................39


4.1. UMTS NETWORK OVERVIEW ............................................................................................39
4.2. UTRAN ARCHITECTURE OVERVIEW .....................................................................................40
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 3/223


UMTS RNC Product Engineering Information

4.3. UTRAN BACKHAULING OVERVIEW ..................................................................................42


4.4. RNC AND INTERFACES OVERVIEW ......................................................................................44
4.5. UTRAN SHARING ................................................................................................................46

5. RNC DESCRIPTION ....................................................................................................................48


5.1. RNC OVERALL HARDWARE DESCRIPTION .....................................................................48
5.1.1 RNC NETWORK ELEMENT AND NoDES ...................................................................48
5.1.2 RNC SITE SPECIFICATION .........................................................................................50
5.1.3 RNC POWER SUPPLY AND CONSUMPTION ............................................................50
5.1.4 RNC COOLING SYSTEM .............................................................................................50
5.2. RNC MODULES ...................................................................................................................51
5.2.1 MODULES AND PEC APPLICABILITY ........................................................................51
5.2.2 SUPPORTED CONFIGURATION.................................................................................54
5.2.3 MODULES DEPLOYMENT ...........................................................................................60
5.2.4 MODULES DESCRIPTION ...........................................................................................63
5.2.5 MODULES PHYSICAL CHARACTERITICS .................................................................63
5.2.5.1 RNC Modules Optical Connectors ............................................................................63
5.2.5.2 16pOC3/STM1 and 16pOC3/STM1 MS3 ..................................................................65
5.2.6 MODULES RELIABILITY ..............................................................................................66
5.3. RNC SOFTWARE.................................................................................................................67
5.3.1 RNC SOFTWARE PACKAGES ....................................................................................67
5.3.2 RNC SOFTWARE SIZE ................................................................................................68
5.3.3 RNC SOFTWARE NAMES ...........................................................................................68
5.3.4 RNC MSS based Applications packages ......................................................................69
5.3.5 RNC MSS based FEATURES.......................................................................................70
5.4. RNC BOARDS ARCHITECTURE ..............................................................................................72
5.4.1 CP .................................................................................................................................72
5.4.2 16p OC3/STM1 .............................................................................................................74
5.4.3 Packet Server ................................................................................................................79
5.4.4 Packet Server pmc roles dESCRIPTION ......................................................................81
5.4.5 PMC Role Assignment from ua08.1 release and with Flex TMU/RAB Assignment
feature (109904) ...........................................................................................................................88
5.4.6 4P GIGE BOARDS ........................................................................................................92
5.4.7 LOCALMEDIA Role .......................................................................................................93
5.5. RNC SYSTEM ARCHITECTURE .........................................................................................93
5.5.1 RNC Overall Architecture ..............................................................................................93
5.5.2 RNC ATM TO IP Transport Evolution ...........................................................................95
5.5.3 RNC 9370 ATM TO IP MIGRATION .............................................................................98
5.5.4 RNC IP System Architecture .........................................................................................99
5.5.4.1 Local Media interface ................................................................................................99
5.5.4.2 Virtual ROUTER CONFIGURATIONS ....................................................................100
5.5.4.3 OAM Traffic Virtual Router and Local Media ...........................................................105
5.5.4.4 RNC IP addresses allocation summary...................................................................109
5.5.4.5 UMTS Operational Flows Virtual Router and local media for the RNC paths .........110
5.5.4.6 RNC INTERNAL EXCHANGES Virtual Router .......................................................117
5.5.4.7 LOCATION SERVICES Virtual Router and Local Media ........................................118
5.5.4.8 CELL BROADCAST SERVICES Virtual Router and Local Media ..........................119
5.5.5 RNC SS7 System Architecture ...................................................................................119
5.5.5.1 RNC SS7 STACK STANDARDS .............................................................................119
5.5.5.2 RNC SS7 Dual Stack ...............................................................................................121
5.5.5.3 RNC SS7 Stack Internal Architecture ......................................................................121
5.5.5.4 RNC SS7 Stack Supported Architecture .................................................................122
5.5.5.5 RNC SS7 Load-Sharing Mechanisms .....................................................................125
5.5.6 RNC QAAL2 System Architecture ..............................................................................125
5.6. RNC IP TRANSPORT FEATURES ............................................................................................126
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 4/223


UMTS RNC Product Engineering Information

5.6.1 Ip utran path diversity support on 9370 RNC ..............................................................126


5.6.2 sctp multi homing on 9370 rnc ....................................................................................128
5.6.3 ip utran bidirectional forwarding detection (Bfd)..........................................................129
5.6.4 lag support on 9370 rnc ..............................................................................................131
5.6.4.1 KEY BENEFIT .........................................................................................................132
5.6.4.2 LOAD BALANCING ON RNC ..................................................................................132
5.6.4.3 LAG CAPACITY and THROUGHPUT .....................................................................133
5.6.4.4 CONFIGURE LAG ON RNC WITH PDR PRESENT ..............................................133
5.6.4.5 LAG GROUP RESILIENCY .....................................................................................134
5.7. RNC FUNCTIONS ..............................................................................................................136
5.7.1 RNC Reliability ............................................................................................................136
5.7.2 RNC Upgrade targets ..................................................................................................136
5.7.3 Redundancy definition .................................................................................................138
5.7.4 RNC Sparing Model ....................................................................................................138
5.7.4.1 PMC-M Sparing .......................................................................................................138
5.7.4.2 PC and PATH SPARING .........................................................................................140
5.7.4.3 RAB and CELL LOGICAL GROUP SPARING ........................................................143
5.7.4.4 TMU Sparing for cell c-plane ...................................................................................144
5.7.4.5 NI and pdc sparing for ss7 stack .............................................................................145
5.7.4.6 OC3 Sparing ............................................................................................................146
5.7.4.7 CP sparing ...............................................................................................................146
5.7.5 ip utran carrier grade and sparing model ....................................................................147
5.7.5.1 protected ip routes on 4pge card for ip transport sparing .....................................148
5.7.5.2 ni and pdc sparing for c-plane traffic on iu/iur .........................................................149
5.7.5.3 PC sparing for u-plane traffic on iub ........................................................................150
5.7.6 RNC Modules redundancy summary ..........................................................................152
5.7.7 RNC Overload .............................................................................................................152
5.7.8 other RNC Sparing Functions .....................................................................................152
5.7.8.1 APS USAGE ............................................................................................................152
5.7.8.2 Y-Splitter ..................................................................................................................153
5.7.9 RNC NTP ....................................................................................................................157
5.7.10 RNC Synchronization ..................................................................................................157
5.7.11 RNC OAM Security and configuration management ..................................................159
5.7.11.1 IPSEC for WMS and RNC OAM Interface ...............................................................159
5.7.11.2 Radius Authentication for RNC ...............................................................................159
5.7.12 SERVICE GROUP PROVISIONING ...........................................................................160
5.7.13 HITLESS CAPACITY INCREASE ...............................................................................162
5.8. RNC INTERFACES ............................................................................................................164
5.8.1 RNC Radio Interface ...................................................................................................164
5.8.2 RNC PHYSICAL INTERFACES ..................................................................................165
5.8.3 Iub Interface ................................................................................................................167
5.8.4 IuCS Interface .............................................................................................................176
5.8.5 IuPS Interface..............................................................................................................181
5.8.6 Iu-FLEX CONTEXT .....................................................................................................190
5.8.7 IuR Interface ................................................................................................................190
5.8.8 IuPC Interface .............................................................................................................197
5.8.9 IuBC Interface .............................................................................................................200
5.8.10 OAM Interface .............................................................................................................202
5.8.11 CROSS-Interface dependencies .................................................................................203
5.9. RNC CAPACITY AND DIMENSIONING .............................................................................205
5.9.1 RNC CAPACITY..........................................................................................................205
5.9.1.1 RNC SS7 Entities Capacity Limits ...........................................................................205
5.9.1.2 RNC AAL2 entities capacities Limits .......................................................................206
5.9.2 16POC3/STM1 CAPACITY limits................................................................................207
5.9.3 4pGigE BOARDS CAPACITY limits ............................................................................209
5.9.4 Iub Interface Capacity Limits .......................................................................................210
5.9.5 IuCS Interface Capacity Limits ....................................................................................213
5.9.6 IuR Interface Capacity Limits ......................................................................................213
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 5/223


UMTS RNC Product Engineering Information

5.9.7 IuPS Interface Capacity Limits ....................................................................................214


5.9.8 IuPC Interface Capacity Limits ....................................................................................214
5.9.9 IuBC Interface Capacity Limits ....................................................................................214
5.9.10 Number of Neighboring GSM or CDMa1X CELLS .....................................................215
5.9.11 Applicable Rules for RNC in UTRAN Sharing Environment .......................................215
5.9.12 RNC counter volume control .......................................................................................217
5.9.13 RNC Counter Evolution in UA08.1 release .................................................................219
5.10. RNC LCM ...........................................................................................................................220
5.10.1 RNC REGULATORY COMPLIANCES .......................................................................220
5.10.2 RNC UPGRADE Paths ...............................................................................................220
5.10.3 RNC HARDWARE MIGRATIONS...............................................................................220
5.10.4 RNC ORDERING ........................................................................................................221
5.10.5 RNC Commissioning and Integration ..........................................................................221
5.10.6 RNC OPERABILITY ....................................................................................................222
5.10.7 RNC SCALABILITY .....................................................................................................222
5.11. RNC INTER-WORKING .......................................................................................................222
5.12. RNC ENGINEERING RULES .............................................................................................222
5.12.1 Hardware Deployment ................................................................................................222
5.12.2 RNC ScaLaBility ..........................................................................................................222
5.12.3 AvailAbility ...................................................................................................................222

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 6/223


UMTS RNC Product Engineering Information

FIGURES

Figure 4.1-1: UTRAN within UMTS Networks ................................................................................................... 39


Figure 4.1-2: UMTS Networks Stratum ................................................................................................................ 40
Figure 4.2-1: UTRAN Network Architecture Overview ....................................................................................... 41
Figure 4.2-2: Iu-Flex Architecture logical view .................................................................................................... 42
Figure 4.2-3: Network architecture overview for full IP configuration ................................................................ 42
Figure 4.3-1: UTRAN Backhauling Overview ..................................................................................................... 43
Figure 4.4-1: UTRAN Interfaces Planes Overview .............................................................................................. 45
Figure 4.5-1: UTRAN Interfaces Planes Overview .............................................................................................. 46
Figure 5.1-1: Alcatel-Lucent RNC Overview ....................................................................................................... 49
Figure 5.4-1: RNC Overall Hardware Architecture .............................................................................................. 72
Figure 5.4-2: 16pOC3/STM1 PQC Board Internal Architecture .......................................................................... 75
Figure 5.4-3: 16pOC3/STM1 PQC Optical Ports Management ............................................................................ 76
Figure 5.4-4: 16pOC3/STM1 MS3 board internal architecture ............................................................................ 77
Figure 5.4-5: 16pOC3/STM1 MS3 board optical ports management ................................................................... 78
Figure 5.4-6: PSFP Board Internal Architecture ................................................................................................... 79
Figure 5.4-7: DCPS Block Diagram ..................................................................................................................... 80
Figure 5.4-8: eDCPS Block Diagram .................................................................................................................... 81
Figure 5.4-9: PSFP PMCs roles deployment into RNC ........................................................................................ 85
Figure 5.4-10: PMCs role deployment with 10 PS boards (hybrid ATM/IP) ...................................................... 86
Figure 5.4-11: DCPS PMCs role deployment with feature TMU RAB Balancing (CP4 & 10 DCPS) ............... 87
Figure 5.4-12: DCPS PMCs role deployment with 12 PSs and full IP context .................................................. 87
Figure 5.4-13: 9370 RNC Flex TMU RAB role assignment strategy table .......................................................... 89
Figure 5.4-14: Role Assignment for 16 TMU / 10 DCPS and 20 TMU / 12 DCPS ............................................. 90
Figure 5.4-15: Possible UA08.1 RNC 9370 Configurations ................................................................................. 91
Figure 5.5-1: RNC Overall System Architecture .................................................................................................. 94
Figure 5.5-2: Release Summary of ATM and IP Transport Introduction.............................................................. 95
Figure 5.5-3: All ATM Transport for RNC up to UA6.0 ...................................................................................... 95
Figure 5.5-4: Hybrid IuB and IuPS introduction on UA6.0 .................................................................................. 96
Figure 5.5-5: UA07 Mix and Match ATM & IP any interface.............................................................................. 97
Figure 5.5-6: All IP UTRAN for all interfaces ..................................................................................................... 97
Figure 5.5-7: Segmented VR for each interface .................................................................................................. 103
Figure 5.5-8: Consolidated VR approach ............................................................................................................ 104
Figure 5.5-9: Segmented by UP VR and CP VR all interfaces ........................................................................ 104
Figure 5.5-10: Segmented VRs by UP and CP all interfaces .................................................................. 105
Figure 5.5-11: RNC In Band OAM Connectivity ............................................................................................... 107
Figure 5.5-12: RNC In Band OAM ATM Connectivity ..................................................................................... 108
Figure 5.5-13: RNC OAM inBand/outofBand over IP ....................................................................................... 108
Figure 5.5-14: RNC ATM Out of Band OAM Connectivity .............................................................................. 109
Figure 5.5-15: Example of a RNC using different SS7 protocol stacks .............................................................. 121
Figure 5.5-16: RNC supported SS7 Topologies ............................................................................................... 124
Figure 5.7-1: RNC reliability diagram ................................................................................................................ 136
Figure 5.7-2: AAL-2 Path Binding ..................................................................................................................... 140
Figure 5.7-3: Path Sparing on PC ....................................................................................................................... 141
Figure 5.7-4: PC Swact ....................................................................................................................................... 142
Figure 5.7-5: ATM Card Swact .......................................................................................................................... 143
Figure 5.7-6: RAB and Path Sparing .................................................................................................................. 144
Figure 5.7-7: SS7 Stack Distribution .................................................................................................................. 145
Figure 5.7-8: Sparing Model for SS7 Stack ........................................................................................................ 146
Figure 5.7-9: Protected Static IP routes .............................................................................................................. 148
Figure 5.7-10: IP IuPS C-Plane Path Redundancy between the RNC and a Core Network................................ 150
Figure 5.7-11: PC NAT Functionality for N:1 Sparing ....................................................................................... 151
Figure 5.7-12: RNC modules redundancy summary ........................................................................................... 152
Figure 5.7-13 Y-Splitter ...................................................................................................................................... 154
Figure 5.7-14: RNC Connectivity Reliability levels ........................................................................................... 155
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 7/223


UMTS RNC Product Engineering Information

Figure 5.7-15: RNC synchronization sources ..................................................................................................... 157


Figure 5.7-16: RNC with collocated POC synchronization sources ................................................................... 158
Figure 5.8-1: Alcatel-Lucent RNC full ATM Iub protocol stacks implementation ............................................ 172
Figure 5.8-2: Alcatel-Lucent RNC hybrid Iub protocol stacks implementation ................................................. 173
Figure 5.8-3: Alcatel-Lucent RNC full IP Iub protocol stacks implementation .................................................. 174
Figure 5.8-4: Alcatel-Lucent RNC IuCS protocol stack implementation ........................................................... 176
Figure 5.8-5: Alcatel-Lucent RNC IuCS protocol stack implementation for IP ................................................. 177
Figure 5.8-6: Alcatel-Lucent RNC IuPS protocol stack implementation ATM based case ............................. 182
Figure 5.8-7: Alcatel-Lucent RNC IuPS protocol stack implementation IP based case .................................. 183
Figure 5.8-8: Alcatel-Lucent RNC IuR ATM protocol stack implementation .................................................... 191
Figure 5.8-9: Alcatel-Lucent RNC IuR protocol stack implementation for IP .................................................. 194
Figure 5.8-10: Alcatel-Lucent RNC IuPC protocol stack implementation ......................................................... 197
Figure 5.8-11: Alcatel-Lucent RNC IuBC protocol stack implementation ......................................................... 200
Figure 5.8-12: Overview of OAM organization within UTRAN ........................................................................ 203

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 8/223


UMTS RNC Product Engineering Information

TABLES

Table 1.4-1: Meaning of <Nature> ....................................................................................................................... 18


Table 5.2-1 RNC Modules Applicability .............................................................................................................. 52
Table 5.2-2: RNC OC3 Modules Applicability..................................................................................................... 53
Table 5.2-3: RNC RoHS Compliant Modules....................................................................................................... 54
Table 5.2-4: RNC modules Cardtype .................................................................................................................... 63
Table 5.2-5: RNC modules MTBF........................................................................................................................ 67
Table 5.3-1: RNC Software Packages Applicability ............................................................................................. 67
Table 5.3-2: RNC Application Packages .............................................................................................................. 69
Table 5.3-3: RNC Modules supported FeatureList ............................................................................................... 71
Table 5.5-1: RNC Local Media Interface address assignments .......................................................................... 109
Table 5.5-2: SS7 stack matrix ............................................................................................................................. 120
Table 5.8-1: RNC Physical interfaces usage by UMTS interfaces ...................................................................... 166
Table 5.8-2: RNC UMTS Interfaces Physical Layer Sharing ............................................................................. 167

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 9/223


UMTS RNC Product Engineering Information

RULES

Rule 5.1-1: RNC SDH/SONET Type description ................................................................................................. 49


Rule 5.2-1: RNC Market Models Naming Convention ......................................................................................... 55
Rule 5.2-2: RNC 9370 supported Market Models ................................................................................................ 56
Rule 5.2-3: RNC HW baseline .............................................................................................................................. 59
Rule 5.2-4: RNC Hardware Capability parameter value ....................................................................................... 59
Rule 5.2-5: RNC Hardware mixity rules ............................................................................................................... 59
Rule 5.2-6: RNC Hardware Slots rules ................................................................................................................. 59
Rule 5.2-7: RNC Hardware compatibility matrix ................................................................................................. 60
Rule 5.2-8: Modules deployment within RNC ...................................................................................................... 62
Rule 5.2-9: Mixed configuration with 16pOC3STM1 boards ............................................................................... 66
Rule 5.3-1: RNC Integrated-Node Foundation Loads Naming Convention ......................................................... 68
Rule 5.5-1: Virtual Router configuration ............................................................................................................ 103
Rule 5.5-2: SS7 Point Code Format .................................................................................................................... 122
Rule 5.7-1: RNC Y-Splitter Usage ................................................................................................................... 155
Rule 5.7-2: RNC Minimal Interface Redundancy requirements ......................................................................... 156
Rule 5.7-3: RNC Synchronization in case of full IP configuration ..................................................................... 158
Rule 5.7-4: RNC Service Group Provisioning .................................................................................................. 161
Rule 5.7-5: RNC Number of NodeB per Service Group .................................................................................. 162
Rule 5.7-6: RNC remote Fdd Cells balancing ..................................................................................................... 162
Rule 5.8-1: RNC Carriers support ....................................................................................................................... 164
Rule 5.8-2: RNC SDH/SONET optical interfaces support ................................................................................. 166
Rule 5.8-3: Alcatel-Lucent IuPS list of rules overview ...................................................................................... 183
Rule 5.8-4: Alcatel-Lucent IuR list of rules overview ........................................................................................ 191
Rule 5.8-5: Alcatel-Lucent IuPC list of rules overview ...................................................................................... 198
Rule 5.8-6: Alcatel-Lucent IuBC list of rules overview...................................................................................... 201
Rule 5.8-7: NodeB OAM Management at RNC level ......................................................................................... 202
Rule 5.8-8: RNC AAL2 based interfaces dependency ........................................................................................ 203
Rule 5.8-9: RNC Iub Control Plane dependency ................................................................................................ 204

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 10/223


UMTS RNC Product Engineering Information

GUIDELINES

Guideline 5.12-1: RNC available shelf usage ..................................................................................................... 222


Guideline 5.12-3: RNC Synchronization Sources ............................................................................................... 223

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 11/223


UMTS RNC Product Engineering Information

1. INTRODUCTION
WARNING: Some product oriented studies will be made to enrich engineering
effectiveness of the RNC and then be integrated into this document. For any
addition and comments please refer to your Alcatel-Lucent representative.

1.1. OBJECT
This document aims at:

+ Providing reader with a list of pointers to reference documents on some of


RNC specific aspects where Engineering inputs, margins and actions are limited or
which are a good source to understand RNC historical background.

+ Consolidating some information from miscellaneous sources and across


several releases if needed to provide with a good vision on RNC context and/or
requirements.

+ Being a repository of Engineering Guidelines for UMTS Radio Network


Controller in relation with platform, system as well as some functional aspects in order
to help in taking best of its capabilities within customer contexts, to ease avoidance of
quite impacting re-engineering and to capture best practices.

Important Note: This document mainly focuses on topics in relation with RNC
platform itself as well as options offered on its side from an integration perspective into
a Network Architecture; please refer to TEG for more information on a given interface
from a both ends and detailed perspective. As a matter of fact features related with
Cell Selection/Re-selection, Call Management, Power Management and associated
algorithms are not to be covered here; please refer to UPUG for those. HSDPA and
HSUPA related items are covered into dedicated HSxPA Engineering Guide
[Ext_Eng_006].

Please note that as range of applicable engineering rules is quite large, the content of
this document is subject to changes without notifications.

1.2. SCOPE OF THIS DOCUMENT


Targeted release of this version is UA8.1/OAM08.1. Warnings are highlighted when
other releases are mentioned.

This document covers also the release UA6.x and UA7.x

For all the older releases, please refer to


Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 12/223


UMTS RNC Product Engineering Information

UMT/IRC/APP/13737 v5_08 DR5 Standard


UMTS Reference Load line-ups:

UTRAN release UA06.0 UA07.0 UA07.1 UA08.1

OAM release OAM6.0 OAM7.0 OAM7.1 OAM08.1

RNC PCR release PCR 8.2 PCR 8.2 PCR 8.2 PCR 8.2

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 13/223


UMTS RNC Product Engineering Information

The following features are present in this document (Specific UA08.1 features are in
Yellow Cells):

RNC Platform

PM ID Feature Title Release


34215 CP4 Introduction UA06.0
92036 CP4 / 16pOC3 PQC Compatibility UA06.0.3.2

RNC Availability

PM ID Feature Title Release


29777 UA06.0 RNC Availability UA06.0
36243 UA07 UTRAN Network Elements dependabilities UA07.0
34560 IP carrier Grade evolution UA07.1
36243,1 UA7.1 UTRAN Network Elements dependabilities UA07.1

RNC Capacity

PM ID Feature Title Release


29869 9370 RNC x2 dimensioning UA06.0
33912 Increased number of Neighboring RNCs UA06.0
75546.1 RNC capacity improvement (*2.5) UA07.0
75746,2 RNC capacity improvement (*3) UA07.1
106904 TMU RAB Balancing UA07.1.2
83985 9370 RNC Capacity increase with eDCPS UA08.1
109443 eDCPS introduction UA08.1
109904 Flexible TMU-RAB Assignment UA08.1

UTRAN Architecture

PM ID Feature Title Release


34105 UTRAN sharing developments UA06.0
33365 Hybrid IuB support on RNC UA06.0
33363 RNC support for IuPS transport over IP UA06.0
36244 UA07 Compatibility with External Nodes UA07.0
82732 Iu PS UP IP @subnet reduction to size /26 UA07.0
28528 MOCN UA07.1
33328 IuR over IP / Ethernet UA07.1
34478 Iu-CS over IP / Ethernet UA07.1
36244,1 UA7.1 Compatibility with External Nodes UA07.1
78492 Globalization of 34220 RNC support dual stack SS7 UA07.1
78494 Globalization of 34237 Rate Controller UA07.1
79364 Bidirectional Forwarding Detection Introduction in 9370 RNC UA08.1
82733 Iu PS UP IP @subnet reduction to size /28 (16 IP@) UA08.1
89717 IP Plan update for IP UTRAN UA08.1
110760 IP UTRAN Path Diversity support on RNC UA08.1
110761 SCTP Multi Homing support UA08.1
114393 LAG Support on 9370 RNC UA08.1
117498 RNC Interfaces Enhancement for Movilnet Rollout UA08.1

HSPA/HSPA+ Services

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 14/223


UMTS RNC Product Engineering Information

PM ID Feature Title Release


34386 64-QAM for HSDPA UA07.0
34388 L2 Improvements support: flexible RLC and MAC-ehs UA07.0

RNC Operability

PM ID Feature Title Release


34436 RNC counter volume control UA06.0
34443 UA07 RNC Counter Evolutions UA07.0
34648 Counter Capacity Improvement, Counter Volume Control UA07.0
81118 UA07 RNC Log Enhancements UA07.0
UA enabler for Additional information in UTRAN Service View and
74599 UA07.1
Equipment Monitor (34613)
81563 Internal RNC tools for IP based UMTS protocols debugging UA07.1
81564 Embedded RNC IP spying tool on 4pGigE card external ports UA07.1
116252 RNC UA08.1 Counters evolutions UA08.1

RNC Security

PM ID Feature Title Release

RNC QoS

PM ID Feature Title Release


34202 Bandwidth pools on RNC UA06.0

RNC Interworking

PM ID Feature Title Release


28018 3GPP compiant IuB UA06.0
33361 UA06 upgrade paths UA06.0
82934 UA Backward Compatibility and Upgrade Path UA07.1
118402 WMS Software Upgrade Path to OAM08.1 UA08.1

UTRAN Backhauling

PM ID Feature Title Release

UTRAN Coverage

PM ID Feature Title Release

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 15/223


UMTS RNC Product Engineering Information

Warning: 7670 Transport Node description

A dedicated PEI document is available for the description of the 7670 ESE and 7670
RSP transport nodes, thus, these ones are not described in this RNC PEI. This node
is used principally for ATM network.

(See document reference [EXT_ENG_008]).

Warning: 7750 Service router description

A dedicated PEI document is available for the description of the 7750 SR (Service
Router), thus, this one is not described in this RNC PEI. This node is used principally
for IP network.

See document reference [EXT_ENG_011]

Following ALU new naming strategy, W-CDMA RNC products are now called
9370 RNC. This name now replaces previous RNC1500 denomination but
corresponds to the same product. In the following of the document, only the
9370 RNC denomination will be used (except in the former reference document
titles or feature titles).

1.3. AUDIENCE FOR THIS DOCUMENT


This document is intended primarily for Network Designers and Application Engineers
involved into Engineering activities, as well as RNC Life Cycle within Customers. It
can also be used by Integration and Support team as a capture of the RNC Platform
supported scope.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 16/223


UMTS RNC Product Engineering Information

1.4. ABOUT THIS DOCUMENT


Within this document, following conventions are used:
As far as RAN Model Objects and Parameters are concerned:

- The parameter names are written in bold italic.

- The objects names are written in bold.


- The parameters properties are presented as follows:

Parameter Object
Range & Unit
User Granularity
Class
Value

Warning: All Objects/Parameters information are extracted from OAM RAN Model.

The product associated rules are presented as follows. Those aim at describing
what is supported or not:

Rule: <Domain> <Name> (<Nature>)

The Engineering Guidelines are presented as follows. These are


recommendations to get the best of the product and/or network within supported
space:

Engineering Guidelines: <Domain> <Name> (<Nature>)

The rule is always written in bold


Justification and/or examples are always written in italic

The restrictions are presented as the following. Typically when the behaviour is
not as predicted, is not as described into standards

Restriction: <Domain> <Name> (<Nature>)

The Customer Inputs for Network Design which points to high level information
required to implement associated:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 17/223


UMTS RNC Product Engineering Information

Network Design: <Domain> <Name> (<Nature>)

And where:

<Domain>: Identifies which Node, Network Element, Interface it is


applicable (e.g. RNC, IuPS)

<Name>: Gives a title to the rule

<Nature>: Indicates the root cause for it

<Nature> <Nature> Meaning

(Short Name) (Long Name)

HC Hard Coded Either Hardware or Software is responsible for this.

M Mandatory No control but must be followed for the system to


operate properly into a supported environment.

S Standard Required by Standard

D Design Mainly for restriction and if related with Design

T Test Mainly for restriction and if related with Tests

R Recommended No control and not mandatory but recommended


(Optional) for:

- Design: To follow good Network Design


basis and principles.

- Availability: To ensure Network robustness.

- Performances: To provide with an


optimized usage of resources.

- Security: To secure network against


potential attacks.

Operations: To offer better operational


effectiveness for site or network extension,
upgrade, reconfiguration

Table 1.4-1: Meaning of <Nature>

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 18/223


UMTS RNC Product Engineering Information

2. RELATED DOCUMENTS
Reminder: This document does not aim at covering all topics where RNC is involved;
as such references provided below are only the ones related with its scope.

2.1. STANDARDS

2.1.1 3GPP
All 3GPP specifications are available at:

http://www.3gpp.org

Tag Reference Title

[Ext_3GPP_001] TR 21.905 Vocabulary for 3GPP Specifications

[Ext_3GPP_002] TS 21.101 TS and TR for a UTRAN-based 3GPP system

[Ext_3GPP_003] TS 23.002 Network Architecture

[Ext_3GPP_004] TS 23.003 Numbering, Addressing and Identification

[Ext_3GPP_005] TS 23.101 General UMTS Architecture

[Ext_3GPP_006] TS 23.107 QoS concept and Architecture

[Ext_3GPP_007] TS 23.110 UMTS Access Stratum Services and Functions

[Ext_3GPP_008] TS 23.121 Architectural requirements for Release 1999

[Ext_3GPP_009] TS 23.221 Architectural requirements for Release 5

[Ext_3GPP_010] TS 25.401 UTRAN Overall Description

[Ext_3GPP_011] TS 25.402 Synchronization in UTRAN (Stage 2)

[Ext_3GPP_012] TR 23.930 Iu Principles

[Ext_3GPP_013] TS 25.410 UTRAN Iu Interface General Aspects and Principles

[Ext_3GPP_014] TS 25.420 UTRAN Iur Interface General Aspects and Principles

[Ext_3GPP_015] TS 25.430 UTRAN Iub Interface General Aspects and Principles

[Ext_3GPP_016] TS 25.442 UTRAN implementation-specific O&M Transport

[Ext_3GPP_017] TS 25.450 UTRAN Iupc Interface General Aspects and Principles

[Ext_3GPP_018] TS 25.460 UTRAN Iuant Interface General Aspects and Principles

[Ext_3GPP_019] TS 23.041 Technical realization of Cell Broadcast Services (CBS)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 19/223


UMTS RNC Product Engineering Information

2.1.2 ITU-T

Tag Reference Title

[Ext_ITU_001] E.191 B-ISDN Numbering & Addressing

[Ext_ITU_002] I.150 B-ISDN Asynchronous Transfer Mode functional Characteristics

[Ext_ITU_003] I.361 B-ISDN ATM Layer Specification

[Ext_ITU_004] I.363.2 B-ISDN ATM Adaptation Layer specification : Type 2 AAL

[Ext_ITU_005] I.363.5 B-ISDN ATM Adaptation Layer Specification : Type 5 AAL

[Ext_ITU_006] I.371 ATM Traffic control and congestion control in B-ISDN

[Ext_ITU_007] I.761 Inverse Multiplexing for ATM (IMA)

[Ext_ITU_008] I.762 ATM over Fractional Physical Links

[Ext_ITU_009] Q.700 Introduction to CCITT Signaling System No 7

[Ext_ITU_010] Q.701 Functional description of the message transfer part (MTP) of SS7

[Ext_ITU_011] Q.702 Signaling data link

[Ext_ITU_012] Q.703 Signaling link

[Ext_ITU_013] Q.704 Signaling network functions and messages

[Ext_ITU_014] Q.705 Signaling network structure

[Ext_ITU_015] Q.711 Functional description of the signaling connection control part

[Ext_ITU_016] Q.712 Definition and function of signaling connection control part


messages

[Ext_ITU_017] Q.713 Signaling connection control part formats and codes

[Ext_ITU_018] Q.714 Signaling connection control part procedures

[Ext_ITU_019] Q.715 Signaling connection control part user guide

[Ext_ITU_020] Q.2100 B-ISDN signaling ATM adaptation layer (SAAL) - Overview


description

[Ext_ITU_021] Q.2110 B-ISDN ATM adaptation layer - Service specific connection


oriented protocol (SSCOP)

[Ext_ITU_022] Q.2130 B-ISDN signaling ATM adaptation layer - Service specific


coordination function for support of signaling at the user-network
interface (SSCF at UNI)

[Ext_ITU_023] Q.2140 B-ISDN ATM adaptation layer - Service specific coordination


function for signaling at the network node interface (SSCF AT NNI)

[Ext_ITU_024] Q.2144 B-ISDN signaling ATM adaptation layer - Layer management for
the SAAL at the network node interface

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 20/223


UMTS RNC Product Engineering Information

[Ext_ITU_025] Q.2150.1 Signaling Transport Converter on MTP3 and MTP3b

[Ext_ITU_026] Q.2210 Message Transfer Part level 3 functions and messages using the
services of ITU-T recommendation Q.2140

[Ext_ITU_027] Q.2630.1 AAL Type 2 Signaling Protocol Capability Set 1

[Ext_ITU_028] Q.2630.2 AAL Type 2 Signaling Protocol Capability Set 2

[Ext_ITU_029] Q.2751 Extension of Q.751.1 for SAAL Signaling Links

[Ext_ITU_030] G.841 Types and characteristics of SDH network protection architectures

[Ext_ITU_031] G.707 Network Node interface for the Synchronous Digital Hierarchy
(SDH)

[Ext_ITU_032] G. 957 Optical Interfaces for equipments and systems relating to SDH

[Ext_ITU_033] I.630 ATM Protection Switching

2.1.3 ANSI

Tag Reference Title

[Ext_ANSI_001] T1.111 ANSI Telecommunications Signaling Systems No. 7 (SS7)


Functional Description of the Signaling System Message Transfer
Part (MTP)

[Ext_ANSI_002] T1.112 ANSI Telecommunications Signaling System No. 7 (SS7)


Signaling Connection Control Part

[Ext_ANSI_003] T1.637 ANSI Telecommunications B-ISDN ATM Adaptation Layer


Service Specific Connection Oriented Protocol

[Ext_ANSI_004] T1.645 ANSI Telecommunications B-ISDN Signaling ATM Adaptation


Layer Service Specific Coordination Function for Support of
Signaling at the Network Node Interface (SCCF at the NNI)

2.1.4 ATM-FORUM
All ATM Forum specifications are available at:

http://www.atmforum.org/standards/approved.html

Tag Reference Title

[Ext_ATMF_001] af-phy-0064.000 E1 Physical Layer Specification

[Ext_ATMF_003] af-phy-0086.001 Inverse Multiplexing for ATM (IMA) v1.1

[Ext_ATMF_004] af-phy-0130.000 ATM on fractional E1/T1

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 21/223


UMTS RNC Product Engineering Information

[Ext_ATMF_007] af-sig-0061.000 ATM User-Network Interface Specification V4.0

[Ext_ATMF_008] af-pnni-0055.000 Private Network-Network Interface Specification Version 1.0


(PNNI 1.0)

[Ext_ATMF_009] af-ra-0105.000 ATM Forum Addressing User Guide Version 1.0

[Ext_ATMF_010] af-ra-0106.000 ATM Forum Addressing Reference Guide

[Ext_ATMF_011] af-tm-0121.000 Traffic Management 4.1

[Ext_ATMF_012] af-tm-0150.000 Addendum to Traffic Management V4.1 for an Optional


Minimum Desired Cell Rate Indication for UBR

2.1.5 IETF RFC


All IETF specifications are available at: http://www.rfc-editor.org/

Tag Reference Title

[Ext_RFC_001] RFC 791 Internet Protocol

[Ext_RFC_002] RFC 826 Ethernet Address Resolution Protocol

[Ext_RFC_003] RFC 1027 Using ARP to implement transparent subnet gateways (Proxy ARP)

[Ext_RFC_004] RFC 2390 Inverse Address Resolution Protocol

[Ext_RFC_005] RFC 2225 Classical IP and ARP over ATM

[Ext_RFC_006] RFC 2684 Multi-protocol Encapsulation over ATM AAL5

[Ext_RFC_007] RFC 793 Transmission Control Protocol

[Ext_RFC_008] RFC 768 User Datagram Protocol

[Ext_RFC_009] RFC 2453 RIP version 2

[Ext_RFC_010] RFC 2474 Definition of the Differentiated Service Field (DS Field) in the IPv4
and IPv6 Headers

[Ext_RFC_011] RFC 2992 Analysis of an Equal Cost Multi Path Algorithm (ECMP)

2.1.6 BELLCORDIA

Tag Reference Title

[Ext_BEL_001] GR-253 CORE SONET Transport Systems: Common Generic Criteria

[Ext_BEL_002] GR-1929 CORE Reliability and Quality Measurements for Telecommunications

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 22/223


UMTS RNC Product Engineering Information

Systems (RQMS-Wireless)

[Ext_BEL_003] GR-815 CORE Telecordia Technologies: Generic Requirements for Network


Security/Network System (NE/NS) Security

[Ext_BEL_004] GR-63 CORE NEBS Requirements

[Ext_BEL_005] GR-1244 CORE Clocks for the Synchronized Network Common Generic
Criteria

2.1.7 STATE OF COMPLIANCY


Below are only listed documents containing for a given UA release the list of
references of miscellaneous TS SOCs.

Tag Reference Title

[Ext_SOC_001] UMT/SYS/DD/9966 UA06.0 High Level Compliance to 3GPP Specifications

UMT/SYS/DD/29371 UA08 3GPP Standard Compliance

UMT/SYS/DD/33107 3GPP Standard Compliance in UA08.1

Note that UA04.x previous releases of this document are available under the same reference.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 23/223


UMTS RNC Product Engineering Information

2.2. PROCESS

2.2.1 EXTERNAL

Tag Reference Title

[Ext_PRO_001] UMT/NPI/INF/1 UMTS Customer Reference Handbook

[Ext_PRO_007] UMT/DCL/APP/24348 UMTS Overall Documentation Plan for UA06.0/OAM06.0

[Ext_PRO_008] UMT/DCL/APP/25988 UMTS Overall Documentation Plan for UA07.0/OAM07.0

[Ext_PRO_009] UMT/DCL/APP/28704 UMTS Overall Documentation Plan for UA07.1/OAM07.1

[Ext_PRO_010] UMT/DCL/APP/32793 UMTS Overall Documentation Plan for A07.1.3/OAM07.1.3

[Ext_PRO_011] UMT/DCL/APP/34996 UMTS Overall Documentation Plan for UA08.1/OAM08.1

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 24/223


UMTS RNC Product Engineering Information

2.3. PLM

2.3.1 EXTERNAL

Tag Reference Title

[Ext_PLM_003] UMT/RAN/INF/12025 UMTS RNC 1500 Customer Product Description

[Ext_PLM_004] UMT/PLM/INF/4862 UMTS RNC Capacity Roadmap

[Ext_PLM_005] UMT/OAM/INF/5 W-NMS CPO

[Ext_PLM_009] UMT/SYS/DD/15211 GSM/UMTS System Upgrade Paths and Compatibility


Matrix

[Ext_PLM_015] UMT/SYS/INF/22664 UA06 Feature Planning Guide

[Ext_PLM_016] UMT/SYS/INF/25020 UA07 Feature Planning Guide

[Ext_PLM_017] UMT/SYS/DD/27975 UA07.0 Upgrade Paths

[Ext_PLM_018] UMT/SYS/DD/28939 UA07.1 Upgrade Paths

[Ext_PLM_019] UMT/SYS/DD/31950 UA08.1 Upgrade Paths

2.4. LCM/NPI

2.4.1 EXTERNAL
Tag Reference Title

[Ext_LCM_001] UMT/COM/INF/11130 UMTS RNC Packet Server releases 13 & 14 introduction

[Ext_LCM_002] UMT/COM/INF/12213 UMTS RNC - NTHW18BB Packet Server Introduction

[Ext_LCM_003] UMT/COM/INF/12544 UMTS RNC - NTHW18BA Packet Server - Release 09 and


below Retrofit

[Ext_LCM_004] UMT/COM/INF/15659 Manufacturing discontinue of the Network Access Module


(NAM)

[Ext_LCM_005] UMT/COM/INF/13947 PB RNC 1500 Introduction and RNC 1000 Manufacture


Discontinue

[Ext_LCM_006] UMT/COM/INF/16062 PB RNC Hardware Evolution

[Ext_LCM_007] UMT/COM/INF/16063 PB RNC 1500 RoHS compliance

[Ext_LCM_011] UMT/COM/INF/19675 Manufacturing Discontinue Notice for RNC PCM -


Replacement is RNC SDH/SONET and MSS7K POC

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 25/223


UMTS RNC Product Engineering Information

[Ext_LCM_012] UMT/COM/INF/21631 UMTS RNC Portfolio Evolution in UA05 and UA06

[Ext_LCM_013] UMT/COM/INF/23886 Changes to RNC Portfolio evolution in UA5.1 and UA06

[Ext_LCM_014] UMT/COM/INF/33931 Last Software Release for PSFP NTHW18xx

[Ext_LCM_015] UMT/COM/INF/33343 New Order code for DCPS

[Ext_LCM_016] UMT/COM/INF/28123 9370 RNC ATM and IP Interface FP Evolution

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 26/223


UMTS RNC Product Engineering Information

2.5. TECHNICAL PUBLICATIONS

2.5.1 EXTERNAL

Tag Reference Title

[Ext_NTP_001] UMT/DCL/DD/1 or 411-8111-101 About the UMTS Network

[Ext_NTP_002] UMT/DCL/DD/4 or 411-8111-804 UMTS Terminology

[Ext_NTP_004] UMT/DCL/DD/13710 or 411-8111-931 UMTS RNC 1500 Description

[Ext_NTP_006] UMT/DCL/DD/13711 or 411-8111-563 UMTS RNC 1500 Hardware Maintenance


Guide

[Ext_NTP_007] 411-8111-554 RNC 1000 & 1500 Fault Analysis

[Ext_NTP_009] 411-8111-565 RNC 1500 TML Tool

[Ext_NTP_010] UMT/DCL/DD/10 or 411-8111-510 About the Access Network OAM

[Ext_NTP_011] UMT/DCL/DD/12 or 411-8111-512 Access Network OAM Commands

[Ext_NTP_012] NN-20500-030 WICL

[Ext_NTP_013] UMT/DCL/DD/13 or 411-8111-813 Access Network Parameters

[Ext_NTP_014] UMT/DCL/DD/22 or 411-8111-822 Access Network Observation Counters

[Ext_NTP_015] UMT/DCL/DD/8518 or 411-8111-916 About WPS

[Ext_NTP_016] NN-20500-021 9370 RNC Technical Description

[Ext_NTP_017] NN-20500-023 9370 RNC Maintenance Guide

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 27/223


UMTS RNC Product Engineering Information

2.6. TECHNICAL PUBLICATIONS OPERATIONS

2.6.1 EXTERNAL

Tag Reference Title

[Ext_OPE_001] UMT/DCL/DD/8521 or WPS For Access Network - Procedures


411-8111-917

[Ext_OPE_010] UMT/DCL/DD/14324 RNC 1500 Patching Procedure


or 411-8111-232

[Ext_OPE_012] NMS/COM/INF/16674 W-NMS supported characters for UMTS Access Network Element
Naming

[Ext_OPE_024] UMT/OAM/DD/18936 FN RNC 1500 Emergency Recovery through W-NMS

[Ext_OPE_025] 411-8111-539 NodeB Addition NRP

[Ext_OPE_026] 411-8111-540 NodeB Re-parenting NRP

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 28/223


UMTS RNC Product Engineering Information

2.7. R&D

2.7.1 EXTERNAL
Those documents are available under Kiosklive.

Tag Reference Title

[Ext_R&D_001] UMT/SYS/DD/1 UMTS System Overview

[Ext_R&D_002] UMT/SYS/DD/12599 UMTS Qos Solution FN

[Ext_R&D_004] UMT/SYS/DD/89 UMTS Drop&Insert via BTS with Fractional ATM


over single E1

[Ext_R&D_005] UMT/SYS/DD/90 Multiple PCM Iub connection without IMA

[Ext_R&D_006] UMT/SYS/DD/95 PNNI and SPVCs between RNC-AN and RNC-IN

[Ext_R&D_007] UMT/SYS/DD/131 Inverse Multiplexing for ATM use in UMTS

[Ext_R&D_008] UMT/BTS/DD/484 Site LAN Functional Specification

[Ext_R&D_009] UMT/SYS/DD/145 UMTS Radio Access 1900 Mhz Adaptation

[Ext_R&D_011] UMT/SYS/DD/4666 SPVCs on Iu/IuR/Iub interfaces

[Ext_R&D_018] UMT/SYS/DD/8005 RNC Overload

[Ext_R&D_019] UMT/OAM/DD/15080 FN W-NMS Support of IPSec for MSS RNC

[Ext_R&D_020] UMT/OAM/DD/15649 FN W-NMS Support of Radius Authentication to


MSS RNC

[Ext_R&D_021] UMT/SYS/DD/5702 Cell Broadcast Service

[Ext_R&D_022] UMT/SYS/DD/016708 UTRAN Iu-flex Functional Node

[Ext_R&D_023] UMT/SYS/DD/018827 Enhanced DCH System Specification

[Ext_R&D_024] UMT/SYS/DD/023094 UTRAN sharing

[Ext_R&D_025] UMT/SYS/DD/023092 IP in UTRAN FN

[Ext_R&D_026] UMT/RNC/DD/25077 UA07 IP Transport Functional Specification

[Ext_R&D_027] UMT/SYS/APR/032480 UA08.1 RNC Counters Evolution

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 29/223


UMTS RNC Product Engineering Information

2.8. ENGINEERING

2.8.1 EXTERNAL
Tag Reference Title

[Ext_ENG_001] UMT/DCL/DD/20 UTRAN Parameters User Guide

[Ext_ENG_002] UMT/IRC/APP/48 UTRAN Dimensioning Guide

[Ext_ENG_003] UMT/IRC/APP/7149 Iub TEG

[Ext_ENG_004] UMT/IRC/APP/11676 Iu TEG

[Ext_ENG_005] UMT/IRC/APP/12509 Iur TEG

[Ext_ENG_006] UMT/IRC/APP/16664 HSxPA Engineering Guide

[Ext_ENG_007] UMT/OAM/APP/24291 WMS Engineering Guide

[Ext_ENG_008] UMT/IRC/APP/23122 UMTS 7670 RSP/ESE Product Engineering Information

[Ext_ENG_009] UMT/IRC/APP/25783 Addressing TEG External

[Ext_ENG_010] UMT/IRC/APP/16664 HSXPA Parameters User guide UA08.1

[Ext_ENG_011] UMT/IRC/APP/24840 UMTS 77xx for Pseudowire in W-CDMA PEI

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 30/223


UMTS RNC Product Engineering Information

2.9. RADIO NETWORK CONTROLLER 9370 RNC

2.9.1 EXTERNAL
Tag Reference Title

[Ext_MSS_001] ATM_TM-PCR6.1 MSS 7400, 15000, 20000 ATM Traffic Management


Engineering Guidelines for PCR6.1

[Ext_MSS_002] ATM_Net-PCR6.1 MSS 7400, 15000, 20000 ATM Networking Engineering


Guidelines for PCR6.1

[Ext_MSS_003] MSA32-PCR6.1 MSS 7400 MSA32 Engineering Guidelines for PCR6.1

[Ext_MSS_004] NN 10600-120 MSS 15000, 20000 Hardware Description

[Ext_MSS_006] NN 10600-551 MSS 7400, 15000, 20000 FP Configuration Reference

[Ext_MSS_008] NN 10600-060 MSS 7400, 15000, 20000 Components

[Ext_MSS_009] NN 10600-500 MSS 7400, 15000, 20000 Alarms Reference

[Ext_MSS_010] NN 10600-053 MSS 7400, 15000, 20000 Commands Quick Reference

[Ext_MSS_011] NN 10600-550 MSS 7400, 15000, 20000 Common Configuration


Procedures

[Ext_MSS_012] NN 10600-561 MSS 7400, 15000, 20000 Data Management

[Ext_MSS_013] NN 10600-700 MSS 7400, 15000, 20000 ATM Technology Fundamentals

[Ext_MSS_014] NN 10600-702 MSS 7400, 15000, 20000 ATM Routing and Signalling
Fundamentals

[Ext_MSS_015] NN 10600-705 MSS 7400, 15000, 20000 ATM Traffic Management


Fundamentals

[Ext_MSS_016] NN 10600-706 MSS 7400, 15000, 20000 ATM Traffic Shaping and
Policing Fundamentals

[Ext_MSS_017] NN 10600-707 MSS 7400, 15000, 20000 ATM Traffic Queuing and
Scheduling Fundamentals

[Ext_MSS_018] NN 10600-708 MSS 7400, 15000, 20000 ATM CAC and Bandwidth
Management Fundamentals

[Ext_MSS_019] NN 10600-710 MSS 7400, 15000, 20000 ATM Configuration Management

[Ext_MSS_020] NN 10600-715 MSS 7400, 15000, 20000 ATM Fault and Performance
Management

[Ext_MSS_021] NN 10600-730 MSS 7400, 15000, 20000 Operations Inverse Multiplexing


for ATM

[Ext_MSS_022] NN 10600-720 MSS 7400, 15000, 20000 Operations AAL1 Circuit

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 31/223


UMTS RNC Product Engineering Information

Emulation

[Ext_MSS_023] NN 10600-800 MSS 7400, 15000, 20000 IP Technology Fundamentals

[Ext_MSS_024] NN 10600-801 MSS 7400, 15000, 20000 IP Configuration Management

[Ext_MSS_025] NN 10600-125 MSS 15000,20000 Planning Site Requirements

[Ext_MSS_026] NN 10600-005 MSS 7400/15000/2000 Terminology

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 32/223


UMTS RNC Product Engineering Information

2.10. I&C

2.10.1 EXTERNAL

Tag Reference Title

[Ext_I&C_008] 06-9699 UMTS RNC 1500 Site Specification

[Ext_I&C_009] 24-6223 Alcatel-Lucent 9370 RNC Commissioning Method

[Ext_I&C_010] 65-9695 UMTS RNC Control Node Decommissioning & Removal

[Ext_I&C_012] 65-8079 UMTS RNC Y-Splitter Introduction

[Ext_I&C_015] 65-0829 UMTS RNC1500 OC3 SmlrAtm to MS3 PosAtm migration

[Ext_I&C_016] 24-0721 UMTS RNC 1500 Startup to Startup Enhancements


Upgrade

[Ext_I&C_018] 65-6260 Alcatel-Lucent 9370 RNC PSFP1 to DCPS Migration


(applicable to UA05.1.2)

[Ext_I&C_019] 65-6263 Alcatel-Lucent 9370 RNC CP3 to CP4 Migration

[Ext_I&C_020] 65-6250 Alcatel-lucent 9370 RNC PS1 to DCPS Migration with the
same CP board

[Ext_I&C_021] 65-6262 Alcatel-lucent 9370 RNC UA6.x Hardware Upgrade

[Ext_I&C_022] 30-6222 Alcatel-Lucent 9370 RNC UA7.x Integration

[Ext_I&C_023] 65-6249 Alcatel-lucent 9370 RNC PS (PS1 or DCPS) Reduction

[Ext_I&C_024] 65-6248 Alcatel-Lucent 9370 GIGE Introduction & Installation

[Ext_I&C_025] 65-6220 Alcatel-lucent 9370 RNC UA7.x Hardware Upgrade

[Ext_I&C_026] 65-6218 Alcatel-lucent 9370 RNC UA7.1.x ATM/IP to Full IP

[Ext_I&C_027] 65-3008 Alcatel-lucent 9370 RNC UA08.1 DCPS to eDCPS


migration

[Ext_I&C_028] 65-3005 Alcatel-Lucent 9370 RNC UA08.1 Commissioning Method

[Ext_I&C_029] 30-3006 Alcatel-Lucent 9370 RNC UA08.1 Integration Method

[Ext_I&C_030] 65-3007 Alcatel-lucent 9370 RNC UA08.1 Hardware Upgrade

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 33/223


UMTS RNC Product Engineering Information

2.11. SOL-COM

2.11.1 EXTERNAL
The MOPG document must be consult for all the models for provisioning

Tag Reference Title

[Ext_SC_002] UMT/PFO/APP/15467 UMTS RNC 1500 Modeled Offer Provisioning Guide

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 34/223


UMTS RNC Product Engineering Information

3. ABBREVIATIONS AND DEFINITIONS

3.1. ABBREVIATIONS

rd
3GPP 3 Generation Partnership Project

3GPP TR 3GPP Technical Reports

3GPP TS 3GPP Technical Specifications

AAL2 ATM Adaptation Layer Type 2

AAL5 ATM Adaptation Layer Type 5

ABC ATM Bus Controller

ALCAP Access Link Control Application Part

APC ATM Port Controller

APC Adjacent Point Code

APS Automatic Protection Switching

AQM ATM Queue Manager

ARC ATM Resource Component

ARP Address Resolution Protocol

AS Access Stratum

ASIC Application Specific Integrated Circuit

ATM Asynchronous Transfer Mode

A2EA AAL2 End Address

BICN Bearer Independent Core Network

BOOTP Bootstrap Protocol

BRAN Broadband Radio Access Network

CBC Cell Broadcast Centre

CBS Cell Broadcast Services

CPAC Cross Point Access Controller

CDMA Code Division Multiple Access

C-Node Control-Node

CP Control Processor

CPO Customer Product Overview

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 35/223


UMTS RNC Product Engineering Information

CPSO CP SwitchOver

DES Data Encryption Standard

DHCP Dynamic Host Configuration Protocol

DSCP Differentiated Services Code Point

ECMP Equal Cost Multi-Path

EP Equipment Protection

ESP Encapsulating Security Payload

FCRC Frame Core Resource Component

FDD Frequency Division Duplex

FP Function Processor

FPG Feature Planning Guide

FPGA Field Programmable Gate Array

FRU Field Repair Unit

GQM Generic Queue Manager

I&C Installation & Commissioning

IETF Internet Engineering Task Force

IKE Internet Key Exchange

IMA Inverse Multiplexing for ATM

I-Node Interface-Node (RNC 1000) or Integrated-Node (9370 RNC)

IP Internet Protocol

ITU-T International Telecommunication Union - Telecom

LCM Life Cycle Management

MS-DOC Modular Structure DOCument

MSS Multi-Service Switch (a.k.a Passport)

MTBF Mean Time Between Failures

NAS Non Access Stratum

NEBS Network Equipment Building System

NMS Network Management System

NNI Network to Network Interface


rd
MS3 Multi-Service 3 generation Function Processor

NTP Nortel Technical Publication

NTP Network Time Protocol

OAM Operations Administration and Maintenance

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 36/223


UMTS RNC Product Engineering Information

OC-3 Optical Carrier level 3

OMU Operation and Maintenance Unit

OSPF Open Shortest Path First

PCM Pulse Code Modulation

PDC Processor Daughter Card

PEC Product Engineering Code

PHB Per Hop Behavior

PMC PCI Mezzanine Card

PLM Product Line Management

PNNI Private NNI

POC Point Of Concentration

PQC Passport Queue Controller

RIP Routing Information Protocol

QoS Quality of Service

QRD Queue Relay Device

RFC Request For Comments

RNC Radio Network Controller

RNL Radio Network Layer

SAS Stand-Alone SMLC

SFP Small Form-factor Pluggable

SMLC Serving Mobile Location Center

SUNI Saturn User Dual Network Interface

STM-1 Synchronous Transport Module 1

TEG Transport Engineering Guide

TDD Time Division Duplex

TMU Traffic Management Unit

TNL Transport Network Layer

UMTS Universal Mobile Telecommunications System

UNI User to Network Interface

USRAN UMTS Satellite Radio Access Network

UTRAN UMTS Terrestrial Radio Access Network

WICL Wireless Internet Command Language

WNE Wireless Network Engineering

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 37/223


UMTS RNC Product Engineering Information

3.2. DEFINITIONS
NEBS (Network Equipment Building System): Telcordia standards for power cabling,
grounding, and environmental safety, power and operation interfaces for
telecommunications equipment. The NEBS frame is used to house
telecommunications equipment.

RNC Upgrade: In term of software upgrade, two different types of RNC upgrade exist:
with MIB change or without MIB change. In case where the software releases are
compatible in term of MIB structure and content, the upgrade consist in downloading
and activating the new software. In case where the MIB is impacted by the new
software release (in term of structure or value), a build MIB action is necessary
during the upgrade procedure.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 38/223


UMTS RNC Product Engineering Information

4. RNC OVERVIEW

Warning: This section is UA release independent and for information ONLY.

4.1. UMTS NETWORK OVERVIEW


UMTS Network Architecture is split into 2 parts:

UTRAN which is the Access Network and may use either W-CDMA (FDD) or
TD/CDMA (TDD) radio technologies

Core Network (CN) which may be connected to different types of Access


Networks (UTRAN, USRAN, BRAN)

The Access Network roughly consists of all the entities which manage the functions
and resources specific to the Access technique used. As such the Core Network is
responsible for handling the Call Control, User Services, Location Management, etc
which are up to some extend quite independent from the technology used in the
Access Network.

The reference points between the Access Network and the Core Network is termed
the Iu as illustrated below.

CN

Iu

UTRAN

Uu

UE

UTRAN UMTS Terrestrial Radio Access Network


CN Core Network
UE User Equipment

Figure 4.1-1: UTRAN within UMTS Networks

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 39/223


UMTS RNC Product Engineering Information

Following this split logic; specifications also provide a model in which Mobile-Network
functional interactions are divided between two areas known as:

The NAS (Non Access Stratum) layer which handles functions such as Call
Control, Mobility Management, Session Management, Supplementary
Servicesthat are transparent as much as possible to the UTRAN

The AS (Access Stratum) layer which acts as a bearer of the NAS functions
and is completely dependent from the radio technology.

This is illustrated into the diagram below:

Non-Access Stratum

Radio Radio Iu Iu
proto- proto- proto proto
cols cols cols cols

Access Stratum
UE UTRAN CN
Radio Iu
(Uu)

Figure 4.1-2: UMTS Networks Stratum

4.2. UTRAN ARCHITECTURE OVERVIEW


The UTRAN is composed of several Radio Network Subsystems (RNS). An RNS
covers a certain geographical area and is equivalent to the GSM BSS.

Each RNS is composed of several entities:

One Radio Network Controller (RNC), that manages several NodeBs.

One or more NodeBs which is the logical node for radio


transmission/reception in one or more cells to/from the UE

Optionally one SAS that manages location services

Those entities are interconnected with each other and to the outside world through
interfaces:

As previously mentioned, RNS is connected to Core Network though Iu

The different RNS can be interconnected through the Iur interface of each
RNC to form a network (optional)

A NodeB is connected to the RNC through the Iub interface


Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 40/223


UMTS RNC Product Engineering Information

The RNC is connected to the SAS via the IuPC interface (optional)
Optionally, the RNC is connected to a CBC (Cell Broadcast Center) through
IuBC interface for Cell Broadcast Services.

Then all those entities and interfaces are managed by the operator thanks to the OAM
network.

Figure 4.2-1: UTRAN Network Architecture Overview

From UA5.0 release with the introduction of Iu-Flex facility, several Core Networks
may be connected to the RNC for load balancing and redundancy purpose (Iu-Flex
configuration may be used for CS domain only, PS domain only or both of them). An
example of a typical configuration is presented below:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 41/223


UMTS RNC Product Engineering Information

Figure 4.2-2: Iu-Flex Architecture logical view

From release UA07.1 with full IP introduction all nodes are connected through IP backbone.

9370 9353 WMS(DHCP Server),


SiteLAN
RNC

Uu IuB IuB Iu
(CS & PS)

All-IP
UE IuR 5140
Node B
(iBTS) BMC
IP
IP backbone Cisco 76xx
backhaul GGSN
7500
SGSN
SiteLAN

IuR
Uu IuB 5060
Iu
WCS
(CS & PS) 7549 MG
All-IP IuB
UE Node B 9370
(iBTS) RNC

Symmetricom TP5000
Input Clock Source - 1588 Grand Master
(T1/E1, GPS)

Figure 4.2-3: Network architecture overview for full IP configuration

4.3. UTRAN BACKHAULING OVERVIEW


Inside the UTRAN and between the UTRAN and the Core Network, interfaces can be
conveyed over direct physical connection or over virtual networks using any suitable
transport network. Furthermore as part of those transport networks, many different
Layer 1 technologies available can be met depending on many different factors such
as geographical, interconnectivity, etc constraints.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 42/223


UMTS RNC Product Engineering Information

As a matter of fact UTRAN requires different backhauling solutions. Several products


exist in Alcatel-Lucent portfolio. The 7670 RSP and 7670 ESE products, that have a
wide range of available boards and physical interfaces, allow answering to the need,
principally for ATM connectivity. ALU 7670 Transport Node is described in a dedicated
PEI document (see document [Ext_ENG_008]).and [Ext_ENG_011])

From UA06 for IUPS/IUB and from UA07.1 for all interfaces, IP connectivity requires
the introduction of IP routers. Several products exist in Alcatel-Lucent portfolio. The
7750/7710 products are the one that have been selected for the E2E system tests.

Those can be used as edge, core or concentration network elements within the
backhauling solution.

The following figure presents an overview of the UTRAN backhauling; backhauling


solutions are indicated here as Transport Nodes and could be Alcatel-Lucent 7670 or
7750 solutions.

Figure 4.3-1: UTRAN Backhauling Overview

Alcatel Lucent RNC offers ATM connectivity towards external interfaces, and from
UA06.0, IP direct connections are also possible for IuPS interface and, in a hybrid
ATM and IP configuration, for IuB interface (see paragraph 5.8 for more detailed
information).
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 43/223


UMTS RNC Product Engineering Information

4.4. RNC AND INTERFACES OVERVIEW


The RNC is the central element within the UTRAN and is responsible for most of
UTRAN functions through controlling and managing the Access Network. Those
functions cover for example Transfer of User Data, Overall system access control
(Admission Control, Congestion Control), Ciphering / Deciphering, Mobility, Radio
Resource Management, RAN information Management, etc.

Please refer to 3GPP specifications, WNE UPUG and HPUG for a list and description
of UTRAN functions.

Depending on the context and UTRAN architecture, while performing its UTRAN
functions, the RNC may be:

The Controlling RNC, which refers to the RNC the base station is parented
to. Thus RNC manages all radio and logical resources associated with it.

The Serving RNC, which refers for one specific mobile as the RNC handling
the Iu interface for this mobile if Iur is used.

The Drift RNC, which refers for one specific mobile as the RNC controlling the
NodeB used by this mobile if Iur is used.

Also its interfaces are all implemented following the protocol model depicted below
and based on layers and plane independent of each other.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 44/223


UMTS RNC Product Engineering Information

Radio Control Plane User Plane


Network
Layer Application Data
Protocol Stream(s)

Transport Transport Network Transport Network Transport Network


Network User Plane Control Plane User Plane
Layer
ALCAP(s)

Signalling Signalling Data


Bearer(s) Bearer(s) Bearer(s)

Physical Layer

Figure 4.4-1: UTRAN Interfaces Planes Overview

So UTRAN is horizontally layered into a Radio Network Layer and a Transport


Network Layer. All UTRAN related issues are visible only in the Radio Network Layer,
and the Transport Network Layer represents standard transport technology that is
selected to be used for UTRAN. As a consequence a 3GPP compliant implementation
is seen as one supporting the RNL specified for that interface and as a minimum for
interoperability being able to act as endpoints for the TNL according to the
specifications for that interface.

So for each UTRAN interface (Iu, Iur, Iub, Iupc, Iubc) the related transport network
layer protocol and functionality is specified. The transport network layer provides
services for user plane transport, signaling transport and transport of implementation
specific O&M.

Furthermore UMTS specific UTRAN Architecture logical nodes and interfaces


between them are defined as part of the Radio Network Layer, but Transport Network
Architecture is not specified by 3GPP and is left as an operator issue. At the TNL
layer, UMTS Network Elements may also act as a switch/router.

From a vertical perspective, interfaces are relying on some or all of the following
planes:

Control Plane that includes Application Protocol(s) and Signalling Bearer(s)


for transporting them

User Plane that includes Data Stream(s) made of one or more frame
protocol(s) and Data Bearer(s) for those Data Stream(s)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 45/223


UMTS RNC Product Engineering Information

Transport Network Control Plane which is completely in the Transport


Network Layer. It includes protocol(s) (e.g. ALCAP) needed to manage the
Data

OAM plane for transport of implementation specific O&M

4.5. UTRAN SHARING


Alcatel-Lucent RNC 9370 supports the UTRAN sharing feature.

The principle of this feature is to allow operators to share some UTRAN network
elements in order to minimize investments in some location.

In an UTRAN sharing configuration, at least one RNC is shared between different


operators. The NodeB managed by such RNC may either belong to one specific
operator or be shared between them. In Alcatel-Lucent solution, the radio frequencies
are not shared between the operators. Thus each cell belongs to one unique operator
and to one unique network. The RNC is simultaneously connected to the core
networks of the different operators. The OMC connected to a shared RNC has also to
be shared by the operators. The different calls are redirected into the correct Core and
UTRAN network thanks to the PLMN of the different cells that are dedicated to one
network.

The following figure presents an example of a logical network architecture for a shared
RNC into a Shared UTRAN configuration (the presence of shared NodeB is optional.)

Network operator A Network operator B

Shared OMC

Core Network A Core Network B

Private RNC into Shared RNC for Private RNC into


network A networks A and B network B

Shared NodeB for network A and B

Private NodeB into Cell Private NodeB into


Cell
network A network B network B
network A

Figure 4.5-1: UTRAN Interfaces Planes Overview

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 46/223


UMTS RNC Product Engineering Information

The features activated on the shared RNC (RNC level features) will be applied to all
the NodeB managed by this RNC and so for the different operators. All upgrade and
maintenance activities will have to be coordinated between the different operators. For
a shared RNC the majority of the resources will be common to the different operators
(no dedicated HW, no dedicated capacity, no dedicated number of NodeB, cells,
etc). Thus the RNC resource usage will have to be coordinated between the
operators. Nevertheless, concerning Iub resources, some Iub bandwidth may be
reserved per operator (through the help of bandwidth pools).

For the different engineering rules applicable to the RNC product in a shared UTRAN
environment, please refer to corresponding chapter of this document: chapter 5.9.11.

For additional description about UTRAN sharing feature, please refer to document
[Ext_R&D_024].

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 47/223


UMTS RNC Product Engineering Information

5. RNC DESCRIPTION

5.1. RNC OVERALL HARDWARE DESCRIPTION

5.1.1 RNC NETWORK ELEMENT AND NODES


9370 RNC

Following parameters make it possible to indicate/determine the RNC family and RNC
potential HW variants:
Concerning the HW variants possible from UA06.0, this one is specified through the
parameter hardwareCapability of the object RncIn. This one will be described in
chapter 5.2.2.

From UA06 release the parameter mode (object RncIn) is no more available.

Now two types of RNC are supported

o SDH/SONET RNC with OC-3/STM-1 Clear-Channel.

SDH equivalent to 16 ports STM1

SONET equivalent to 16 ports OC3

o Gigabit Ethernet Interfaces

Important Reminder :

RNC-PCM configurations are no more supported.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 48/223


UMTS RNC Product Engineering Information

9370 RNC consists in one single node based on MSS15K (a.k.a PP15K) platform.
The 9370 RNC uses standard I/O interface, FPs for all its traffics interfaces. These
may be OC-3/STM-1 ATM or Gigabit Ethernet interfaces. In the ATM case, clear
channel interfaces are used.
For providing some other types of connectivity an additional Transport Node has to be
used. Such a Transport Node may be based on Alcatel-Lucent platform (7670 RSP,
7670 ESE) and Service Router ALU 7750 for IP. These last ones are proposed for
new deployments.

Figure 5.1-1: Alcatel-Lucent RNC Overview

Rule: RNC RNC SDH/SONET Type (M)

A RNC SDH/SONET Type is made up of exactly:


+ One I-Node platform (MSS 15 K based)

In case one single RNC is set within the cabinet, it must be inserted into the lower part
of it for stability reasons.
Note that two RNC may be inserted into the cabinet (in lower and upper part of the
cabinet). They are in that case working completely independantly from one another
(like two different physically isolated RNC).

Rule 5.1-1: RNC SDH/SONET Type description

For more information on RNC packagings please refer to Solutions Commercialization


[Ext_SC_002]) document.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 49/223


UMTS RNC Product Engineering Information

5.1.2 RNC SITE SPECIFICATION


For RNC site specification information in order to perform site engineering such as:
+ Office Layout and Footprint

+ Physical dimensions

+ Weight
+ Environmental characteristics

Please refer to CPO ([Ext_PLM_002] and [Ext_PLM_003]), NTP ([Ext_NTP_016] and


I&C [Ext_I&C_008]) documents.

Warning: From a customer perspective, reference is I&C Site Specifications


document.

5.1.3 RNC POWER SUPPLY AND CONSUMPTION


RNC is -48V DC or -60V DC powered as the nominal input voltage value. As a matter
of fact a specific cabinet including the rectifier, the storage and the distribution
functions have to be foreseen.

The acceptable variations in the input voltage are as follows:

Range from -72 VDC to -40 VDC for 9370 RNC

For more information on Power Management and typical/maximum power


consumption please refer to CPO [Ext_PLM_003]), NTP ([Ext_NTP_016] and I&C
[Ext_I&C_008]) documents.

Warning: From a customer perspective, reference is I&C Site Specifications


document.

5.1.4 RNC COOLING SYSTEM


For a description of RNC cooling system please refer to CPO [Ext_PLM_003]) and
NTP ([Ext_NTP_016]

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 50/223


UMTS RNC Product Engineering Information

5.2. RNC MODULES

5.2.1 MODULES AND PEC APPLICABILITY


Below are ONLY presented modules where:

+ Engineering must be aware of their characteristics for their activities


+ Engineering action can have an impact on them

Reminder: Modules are described further into this document

All PEC Codes presented below are the MINIMAL ones for UA07 on customer
networks: :.( Note that there is no evolution compare to UA06).

From UA7.1, there is an evolution on the 16pOC3 PQC, 16pOC3 MS3 and 4pGiGe
Functional Processors. Due to component obsolescence, the PDB3 daughter board
embedded in these modules is being replaced by the PDB4. The only visible change
is a code change. See on the table 5.2-1 below.

From UA08.1, a new enhanced DCPS (eDCPS) board is introduced.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 51/223


UMTS RNC Product Engineering Information

For SDH RNCs:

Modules Available Minimal PEC Code

CP3 (E1 BITS) [MD] NTHW08CA-01

CP3 (E1 BITS) (1) NTHW08CG-01

CP4 (E1 BITS) NTPN08AG

16pOC3/STM1 (MT-RJ) [MD] NTHW21AA-09

16pOC3/STM1 (MT-RJ) [MD] NTHW21AB-01

16pOC3/STM1 (LC) (2) NTHW31AG-01

16pOC3/STM1 (LC) (5) NTHW31BG

16pOC3/STM1 MS3 (LC) (3) NTHW48AG-07

16pOC3/STM1 MS3 (LC) (5) NTHW48BG

4pGiGE NTHW49AG

4pGiGE (5) NTHW49CG

Packet Server [MD] (4) NTHW18BA-10

Packet Server [MD] NTHW18BB-01

Packet Server (1) [MD] NTHW18BF-02

Dual Core Packet Server: DCPS NTHX20CA-02

Enhanced Dual Core Packet Server: eDCPS (6) NTHX30AA

Table 5.2-1 RNC Modules Applicability


(1) RoHS compliant release

(2) Introduced with RoHS.

(3) Introduced in UA05.0

(4) Non DMA capable boards

(5) Introduced in UA07.1

(6) Introduced in UA08.1

For SONET RNCs in DELTA ONLY

Modules Available Minimal PEC Code

CP3 (DS1 BITS) NTHW06EA-02

CP4 (DS1 BITS) NTPN06AG

16pOC3/STM1 (LC Connector) NTHW31AB-01

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 52/223


UMTS RNC Product Engineering Information

Table 5.2-2: RNC OC3 Modules Applicability

All modules listed above are FRU and included into Inventory reports provided by
WMS Inventory Management solution. Please refer to NTPs for more information.

Boards as well as associated information are also available from WMS RNC
Equipment Monitor solution.

For more information on other modules (I-Node Fabric, BITS module) please refer
to CPO, NTP, SolCom MOPG or Product Spec.

Important Note for European Customers: Full set of RoHS associated modules
PEC codes are communicated through LCM channels, here below are only listed PEC
for modules with specific engineering interest. It is also worth reminding here that
RoHS does not imply existing modules retrofit but is only applicable for modules
st
ordered after July the 1 , 2006.

It is important to note the following points:

o 9370 RNC ONLY is RoHS compliant, .

o There is no RoHS version for 16pOC3/STM1 MT-RJ boards.


16pOC3/STM1 LC boards ONLY are RoHS compliant.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 53/223


UMTS RNC Product Engineering Information

Modules Available Minimal PEC Code

CP3 (E1 BITS) NTHW08CG-01

CP3 (DS1 BITS) NTHW06EG-01

CP4 (E1 BITS) NTPN08AG

CP4 (DS1 BITS) NTPN06AG

16pOC3/STM1 (LC) NTHW31AG-01

16pOC3/STM1 (LC) NTHW31BG

16pOC3/STM1 MS3 (LC) NTHW48AG-07

16pOC3/STM1 MS3 (LC) NTHW48BG

4pGiGE NTHW49AG

4pGiGE NTHW49CG

Packet Server NTHW18BF-02

Dual Core Packet Server (DCPS) (1) NTHX20CB

Enhanced DCPS (eDCPS) NTHX30AA

Table 5.2-3: RNC RoHS Compliant Modules

(1) The current DCPS order code, NTHX20CA, is now replaced with NTHX20CB. The
replacement code (NTHX20CB) will be orderable as of January 2011 while the
existing DCPS code (NTHX20CA) will no longer be orderable as of March 31,
2011. Refer to the document [Ext_LCM_015].

Document [Ext_LCM_007] may be consulted for a complete description of ROHS


aspects for the RNC.

5.2.2 SUPPORTED CONFIGURATION


In order to match with RNC scalability requirements as well as scope supported
configurations, different Markets Models have been defined.

Reminder: Modules are described further into this document

Market Models naming conventions are as follows:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 54/223


UMTS RNC Product Engineering Information

Rule: RNC RNC Market Models Naming convention (M)

Two types of Packet Server modules are proposed. The different market models
naming for 9370 RNC are:

For market models using PSFP boards (first generation of the PS boards sometimes
also called PS1):
9370 RNC w/ <xx> PSFP

Where <XX> represents the <#PSFP> over two digits

For market models using DCPS boards (second generation of the PS boards
sometimes also called PS2):

9370 RNC w/ <xx> DCPS

Where <XX> represents the <#DCPS> over two digits

Same for market models using eDCPS boards (third generation of the PS boards also
called PS3

9370 RNC w/ <xx> eDCPS

E.g:

9370 RNC w/ 06 PSFP stands for a RNC with 6 Packet Servers,

9370 RNC w/ 06 DCPS stands for a RNC with 6 Dual Core Packet Servers

Rule 5.2-1: RNC Market Models Naming Convention

The different supported Market models are the following:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 55/223


UMTS RNC Product Engineering Information

Rule: RNC RNC Market Models (M)

These Market Models are supported in UA6.x, UA7.0 except full IP configuration with 12 PS
supported from UA7.1

Market models Full ATM:

9370 RNC w/ XX PSFP or DCPS Market Models

Modules 9370 RNC 9370 RNC 9370 RNC 9370 RNC 9370 RNC
w/04 PSFP w/06 PSFP w/08 PSFP w/10 PSFP w/12 PSFP
or DCPS or DCPS or DCPS or DCPS or DCPS

PSFP or DCPS 4 6 8 10 12

CP 2 2 2 2 2

16pOC3/STM1 2 2 2 2 2

Market models Mixt IP/ATM:

9370 RNC w/ XX PSFP or DCPS Market Models

Modules 9370 RNC 9370 RNC 9370 RNC 9370 RNC 9370 RNC
w/04 PSFP w/06 PSFP w/08 PSFP w/10 PSFP w/12 PSFP
or DCPS or DCPS or DCPS or DCPS or DCPS

PSFP or DCPS 4 6 8 10 N/A

CP 2 2 2 2 N/A

16pOC3/STM1 2 2 2 2 N/A

4pGIGE 2 2 2 2 N/A

This means that RNC 9370 /w 12 PSFP or DCPS in mixt IP/ATM configuration cannot be
supported.
In this case, two 16pOC3STM1 boards and two 4pGiGE boards are needed; the highest
market model supported in this configuration is with 10 PS boards.

Market models Full IP from UA7.1

Important Note: From UA7.1 with Full IP configuration, 12 PS market model is allowed (2 more PS
at the OC3 place)

9370 RNC w/ XX PSFP or DCPS Market Models

Modules 9370 RNC 9370 RNC 9370 RNC 9370 RNC 9370 RNC
w/04 PSFP w/06 PSFP w/08 PSFP w/10 PSFP w/12 PSFP
or DCPS or DCPS or DCPS or DCPS or DCPS

PSFP or DCPS 4 6 8 10 12

CP 2 2 2 2 2

4pGIGE 2 2 2 2 2

Rule 5.2-2: RNC 9370 supported Market Models

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 56/223


UMTS RNC Product Engineering Information

From a provisioning perspective, a parameter called hardwareCapability allows to


distinguish the hardware baselines using PSFP Packet Server from the baselines
using DCPS Packet Server; and also baselines using CP3 or CP4.

Parameter hardwareCapability Object RncIn


User Customer Class N/A Category Standard
Description specifies the Hardware Capability of the RNC
Access Right Read/Write
Range & Unit Enumeration of {all6mPktServSP, allPktServSP2, allPktServSP2FullDim,
allPktServSP3FullDim2}
Value See table below

For the implementation of the different market models, the following baselines will be
supported in UA06, UA07 and UA08.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 57/223


UMTS RNC Product Engineering Information

Rule: RNC RNC Hardware baselines (M)

Following hardware baselines are supported:

9370 RNC supported Hardware baselines

Modules

PS (1) PSFP PSFP DCPS DCPS DCPS eDCPS

CP (2) CP3 CP3 CP3 CP3 CP4 CP4

16pOC3/STM1 (3) 16pOC3STM1 16pOC3STM1 16pOC3STM1 16pOC3STM1 16pOC3STM1 16pOC3STM1


PQC MS3 PQC MS3
PQC or MS3 (6) PQC or MS3 (6)

Corresponding all6mPktServSP all6mPktServSP allPktServSP2 allPktServSP2 allPktServSP2FullDim allPktServSP3FullDim2


hardwareCapability
Value = 0 Value = 0 Value = 1 Value = 1 Value = 2 Value = 4
provisioning
parameter

For information: x1 x1 X3 (UA7.1) X3 (UA7.1) X3 (UA7.1) +33% vs (UA7.1 with


maximum supported DCPS) TBC
level of traffic
capacity compared
to UA05.0/UA05.1
similar market
models (5)

For Information: x1 x1 x1 x1 x2 (for Market model Same as UA7.1 with


maximum supported with 12DCPS) eDCPS
number of cells
compared to
UA05/UA05.1
similar market
models (4)(5)

(1)
PS boards: PSFP boards are corresponding to boards with PEC code NTHW18xx, while DCPS boards
correspond to Dual Core Packet Server with PEC code: NTHX20xx and eDCPS boards (enhanced DCPS) with PEC
Code NTHX30xx.
(2)
CP corresponds here to Core Processor boards CP3 (E1 or DS1), (NTHW08xx or NTHW06xx or CP4 (E1
or DS1), (NTPN08xx or NTPN0xx).
(3)
16pOC3/STM1 corresponds here to either 16pOC3/STM1 PQC boards (NTHW21xx or NTHW31xx PEC
Codes) or to 16pOC3/STM1 MS3 boards (NTHW48xx PEC Code).
(4)
See exact maximum number of supported NodeB and Cells in paragraph 5.9.4.
(5)
For more information about RNC capacity aspects please refer to document [Ext_PLM_004]
(6)
CP4 is compatible with 16p OC-3 PQC after Release 6.0.3.2

Remark: Note that market model naming and the parameter hardwareCapability do not allow differentiating the type of
16pOC3/STM1 card used (MS3 or PQC one). Please make sure that configured model of 16pOC3/STM1 card matches
deployed one. HardwareCapability parameter values are described below on rule 5.2-4 below.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 58/223


UMTS RNC Product Engineering Information

Rule 5.2-3: RNC HW baseline

Rule: RNC HardwareCapability Parameter Values (M)

Value 0 indicates that all PS boards are 6mPktServSP (PSFP) and CP3 board

- Value 1 indicates that all PS boards are PktServCP2 (DCPS with Small MIB) and CP4 board

- Value 2 indicates that PS boards are either PktServCP2 (DCPS) or possibly PktServCP3
(eDCPS) with Big Mib and CP4 board

- Value 3 indicates that PS boards are either PktServCP2 (DCPS) or PktServCP3 (eDCPS)
with Flex Mib (Flex TMU/RAB) and CP4 board
- Value 4 indicates that all PS boards are PktServCP3 (eDCPS) with Flex Mib (Flex
TMU/RAB) and CP4 board. Feature enhanced capacity activated

Rule 5.2-4: RNC Hardware Capability parameter value

Rule: RNC Hardware mixity rules (M)

The following rules are applicable concerning mixity between the different hardware modules:

- mixity between PSFP and DCPS is not supported

- mixity between 16pOC3STM1 PQC and 16pOC3STM1 MS3 is not supported

- mixity between CP3 and CP4 is not supported

- mixity between DCPS and eDCPS is allowed on UA08.1 but without capacity improve.

Rule 5.2-5: RNC Hardware mixity rules

Rule: RNC Hardware slots rules (M)

The following rules are applicable concerning the pair of boards on the RNC shelf:

- Slots 1 and 2 must be filled either with 2 X CP3 boards, either with 2 X CP4 boards

- Slots 8 and 9 (if used) must be filled with the same card type

- Slots 14 and 15 (if used) must be filled with the same card type (PS or GiGE boards)

Rule 5.2-6: RNC Hardware Slots rules

The availability for the PSFP card in the UTRAN release is described in the document
[Ext_LCM_014]

The migration from a configuration using PSFP boards to a configuration using DCPS
boards, is handled by the I&C procedure [Ext_I&C_020].

The migration from a configuration using CP3 boards to a configuration using CP4
boards, is handled by the I&C procedure [Ext_I&C_019].

The migration from a configuration in mix ATM/IP to a configuration full IP is handled


by the I&C procedure [Ext_I&C_026].

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 59/223


UMTS RNC Product Engineering Information

The migration from a configuration using DCPS boards to a configuration using


eDCPS boards is handled by the I&C procedure [Ext_I&C_027]

Rule: RNC Hardware compatibility matrix (M)

The hardware compatibility matrix for a 9370 RNC, not involved in a hardware migration:
16pOC3 16pOC3
CP3 CP4 STM1 STM1 PSFP DCPS GiGE
PQC MS3 eDCPS

CP3 Y N Y Y Y Y N Y

CP4 N Y Y (1) Y Y Y Y Y
16pOC3
Y Y (1) Y N Y Y Y Y
STM1 PQC
16pOC3
Y Y N Y Y Y Y Y
STM1 MS3
PSFP Y N Y Y Y N N Y
DCPS Y Y Y Y N Y Y Y
eDCPS N Y Y Y N Y Y Y
GiGE Y Y Y Y Y Y Y Y

Rule 5.2-7: RNC Hardware compatibility matrix

CAPACITY INCREASE AND HARDWARE COMPATIBILITY ON UA08.1

The capacity increase requirements must be supported on 9370 RNC


configurations with only eDCPS and CP4 cards on release UA08.1. Capacity
increase is not supported on any 9370 RNC configurations that contain DCPS cards
and/or CP3 cards.

The configurations that must support the capacity increase are listed below:
Configuration Restrictions
2x CP4, eDCPS, 2x16p OC3 PQC Maximum Iu DL 310 Mbps Supported with
16pOC3 PQC Based
2x CP4,eDCPS, 2x16p OC3 MS3 Maximum Iu DL 2.5 Gbps with 16pOC3
MS3
2x CP4,eDCPS, 2x 4pGigE
2x CP4, eDCPS, 2x 16p OC3 PQC, 2x 4p GigE Maximum 10 eDCPS supported
Max 310 Mbps Supported on OC3
2x CP4, eDCPS, 2x 16p OC3 MS3, 2x 4p GigE Maximum 10 eDCPS supported

5.2.3 MODULES DEPLOYMENT


Within supported configurations not all modules deployment is allowed both for
practical and/or system reasons (Backplane connectivity, Boot files, Sparing
capabilities).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 60/223


UMTS RNC Product Engineering Information

Rule: RNC Modules Deployment (M)

Depending on selected RNC Market Model, modules must be inserted and deployed
as illustrated and detailed below:

Cases without 4pGiGE boards and with 16pOC3 board (Full ATM)::

Cases with 4pGiGE boards and 16pOC3 Boards (RNC Mix ATM/IP):

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 61/223


UMTS RNC Product Engineering Information

Cases with 4pGiGE boards and without 16pOC3 (RNC full IP) (From UA07.1)

PS board

PS Board

PS Board

PS Board
PS Board

PS Board
CP
1E CP
0 1 2 3 4 5 6 7

PS Board
PS Board

PS Board

PS Board

4pGigE

4pGigE
PS Board

PS Board
0E 8 9 10 11 12 13 14 15

Following rules have to be applied:

- From UA7.0 , Configuration with 7-PS1 is no more supported.

- CP (CP3 or CP4) are into slots 0 and 1

- - if used (optional boards) 16pOC3/STM1 are into slots 8 and 9

- PS Boards (here PSFP or DCPS) are deployed, according to the number


required for the selected market model, into the following slot sequence:

1. Slots from 2 to 7

2. Slots from 10 to 13

3. Slots from 14 to 15 or from 8 to 9 (according to RNC type :


full ATM or full IP)

- if used (optional boards) 4pGiGE are in slot 14 and 15

- Within a given configuration all non used slots must have filler
inserted.

Rule 5.2-8: Modules deployment within RNC

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 62/223


UMTS RNC Product Engineering Information

5.2.4 MODULES DESCRIPTION


Please refer to CPO, NTP, or Product Spec.

Below are summarized cardtype associated with supported modules into RNC
shelves.
Cardtype parameter is available in WIPS under RNC Equipment/Inode/EM/Shelf/Card
object

Modules Available cardtype

CP3 (E1 BITS) CPeE

CP3 (DS1 BITS) CPeD

CP4 (E1 BITS) CPeE

CP4 (DS1 BITS) CPeD

16pOC3/STM1 (MJ-RT) or (LC) 16pOC3SmIrAtm

16pOC3/STM1 MS3 (LC) 16pOC3PosAtm

4pGiGE 4pGe

Packet Server 6mPktServSP

Dual Core Packet Server PktServSP2

Enhanced DCPS PktServSP3

Table 5.2-4: RNC modules Cardtype

5.2.5 MODULES PHYSICAL CHARACTERITICS


For information on modules weight, sizes please refer to CPO, NTP and I&C
documents.

5.2.5.1 RNC MODULES OPTICAL CONNECTORS


Each version of optical module uses a specific wavelength laser to transmit and
receive data over a fiber optic cable. The wavelengths are matched to the type of fiber
cable it accommodates and to the strength of the laser, namely short reach (SR),
intermediate reach (IR), or long reach (LR).

In Single Mode (SM) the types available are IR or LR; in Multi-Mode (MM) the type
available is SR.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 63/223


UMTS RNC Product Engineering Information

RNC context:
Warning: It is important to note that Optical Fibers commonly used within RNC are
SINGLE mode ones (as opposed to Multi-mode).

The 16pOC3/STM1 PQC have fixed connectivity types (IR) while the 16p OC3/STM1
MS3 boards and the 4pGigE boards are offering different solutions for their
connectivity. These boards are using SFP pluggable optical modules for connectivity.
Therefore on a port basis for these boards, Single Mode OR Multi-mode, as well as
the strength of the laser Short, Intermediate OR Long Reach could be used. In the
context of RNC Single Mode Intermediate Reach is usually used. Long Reach (Single
Mode) or Short Reach (Multi-Mode) could be also chosen depending on the need.
When an in-service SFP fails or the inserted SFP does not match what the socket is
configured for in software, alarm 70115480 is generated.

The table below presents the different connectivity characteristics of the different
optical boards. (Important Reminder: RNC RoHS version relies on 16pOC3/STM1
with LC connectors.)

Board Connector Type Mean Mean


Type Transmission Reception
power power

16pOC3/STM1 MT-RJ SM-IR From -15 to -8 From -28 to -


dBm 8 dBm
NTHW21xx

16pOC3/STM1 Duplex LC SM-IR From -15 to -8 From -28 to -


dBm 8 dBm
NTHW31xx

16pOC3/STM1 Duplex LC SFP: With IR With IR


MS3 module: module:
either SR, IR or LR (IR is the
NTHW48xx most common configuration From -15 to -8 From -28 to -
to use) dBm 8 dBm

Associated PEC Codes: With LR With LR


module: module:
NTTP02AD for MM-SR SFP
(ROHS release) From -5 to 0 From -34 to -
dBm 10 dBm
NTTP02TF for SM-IR SFP
(6/6 ROHS release) or
NTTP02CD (5/6 ROHS
release if the 6/6 release is
not yet available)

NTTP02VF for SM-LR SFP


(6/6 ROHS release) or
NTTP02ED (5/6 ROHS
release if the 6/6 release is
not yet available).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 64/223


UMTS RNC Product Engineering Information

Board Connector Type Distance information


Type

4pGigE Duplex LC SFP: With SR module:

NTHW49xx either SR or IR Up to 500m when using 50/125


fiber with a nominal
Associated PEC Codes:
wavelength of 850 nm or
NTTP01RF: 1000Base SX
Up to 220m when using
for MM-SR
62.5/125 fiber with a nominal
(NTTP01RF is the new wavelength of 850 nm
reference for NTTP01AB)
With IR module:
NTTP01TF: 1000Base LX for
Up to 10 km with a nominal
SM-IR
wavelength of 1310 nm
(NTTP01TF is the new
reference for NTTP01CB)
Mean Mean
Transmission Reception
power power

With SR With SR
module: module:

From -9.5 to From -17 to 0


-3 dBm dBm

With IR With IR
module: module:

From -11 to -3 From -19 to


dBm -3 dBm

More information on MSS based modules connectors are provided into MSS NTPs
[Ext_MSS_004], [Ext_MSS_006].

5.2.5.2 16POC3/STM1 AND 16POC3/STM1 MS3


From UA5.0 is introduced a new 16pOC3/STM1 board: 16pOC3STM1 MS3 board.
This one is an optional board depending on the hardware supported baselines (see
paragraph 5.2.2). Nevertheless, no mixed configuration with 16pOC3STM1 PQC
board (16pOC3SmIrAtm) and 16pOC3STM1 MS3 board (16pOC3PosAtm) is
authorized except during replacement procedure (where they are physically both
present but not operational in hot/stand-by mode). The replacement procedure is
described in document [Ext_I&C_15].

From UA7.1 and depending of the availability is introduced a new evolution of 16pOC3
STM1 PQC and 16pOC3 STM1 MS3 board. The only visible change is a code
change; the functionality and capacity of the module are unchanged.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 65/223


UMTS RNC Product Engineering Information

Impacted Order Codes Substitute Order Codes

Code Description Code Description

NTHW31AG 16pOC3/STM1 PQC NTHW31BG 16pOC3/STM1 PQC

NTHW48AG 16pOC3/STM1 MS3 NTHW48BG 16pOC3/STM1 MS3

These 2 version card can work together but mixing of NTHW31xx and NTHW48xx
continues to be not supported.

Rule: RNC 16pOC3STM1 Mixed configuration (M)

Mixed configuration between different type of 16pOC3/STM1 boards:


16pOC3SmlrAtm and 16pOC3PosAtm is not authorized except during replacement
procedures (where they are physically present but not operational at the same time).

Rule 5.2-9: Mixed configuration with 16pOC3STM1 boards

In the case of a replacement of 16pOC3/STM1 PQC boards by the new


16pOC3/STM1 MS3 boards, connectivity aspects have to be prepared head of time
since the connectivity may be different between these two types of boards (if
16pOC3/STM1 PQC boards were old non ROHS ones, they were equipped with
MTRJ connectors while 16pOC3/STM1 MS3 boards are using LC connectors).
Moreover it is also mandatory to take care to the fact that port numbering is different
between the both types of 16pOC3/STM1 modules (see chapter 5.4.2 for a
presentation of this port numbering for the two types of boards).

5.2.6 MODULES RELIABILITY


RNC modules MTBF are captured into the table below:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 66/223


UMTS RNC Product Engineering Information

RNC Modules MTBF (Years)

RNC

CP3 18

CP4 41

16 Port OC3/STM1 13

16 Port OC3/STM1 MS3 15

4pGiGE 23

Packet Server 14

Dual Core Packet Server 14.5

Enhanced DCPS 14.5

Table 5.2-5: RNC modules MTBF

For more details about the MTBF of other RNC modules, please refer to document
[Ext_PLM_003].

5.3. RNC SOFTWARE

5.3.1 RNC SOFTWARE PACKAGES


A RNC is made of one software package:

+ One RNC MSS 15K based software package. RNC 9370 software is built
on top of standard MSS 15K PCR software, BUT is not the standard software.
Relationship between UA and PCR software is as follows:

RNC UA Release PCR Software Basis

UA06.0 PCR8.2

UA07.0 PCR8.2

UA07.1 PCR8.2

UA08.1 PCR8.2

Table 5.3-1: RNC Software Packages Applicability

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 67/223


UMTS RNC Product Engineering Information

5.3.2 RNC SOFTWARE SIZE


Software packages size does matter in order to dimension OAM interfaces to node to
match customer download time expectations:
On the UA7.1x software version

o RNC software downloaded is around 180 Mb.

For more accurate information on RNC SW downloaded Sizes and OAM interfaces
Bandwidth please refer to [Ext_ENG_007]. Observations and Call Traces files are also
covered.

Note: Some of the software on the RNC side is compressed (mainly software
associated with PS PMCs) to enhance download performances and are de-
compressed on the fly when loaded onto PMCs.

5.3.3 RNC SOFTWARE NAMES


RNC miscellaneous packages naming conventions are presented below:

Rule: RNC RNC Load Naming Convention (HC)

RNC software is built based on MSS 15K software and made of 2 parts:

+ Foundation (7 characters):RI <rrr> <LL> eg: RI71244

+ Patch (6 characters): RI <rrr> <LL>YYwwee eg: RI71244104702

Where:

+ RI identifies the platform (R stands for RNC and I for I-Node Integrated into 9370
RNC context)

+ <rrr> stands for UA release (e.g 712 is UA07.1.2)


th
+ <LL> identifies the load number (e.g. 44 is the 44 foundation built)

+ YY is the two last digits of the year (e.g 10 is for 2010)

+ ww identifies the week the load is generated (e.g 47 implies wk47)

+ ee identifies the load edition built on top of a specific foundation

Rule 5.3-1: RNC Integrated-Node Foundation Loads Naming Convention

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 68/223


UMTS RNC Product Engineering Information

5.3.4 RNC MSS BASED APPLICATIONS PACKAGES


Application packages to be downloaded and applied to the RNC nodes are included
into WMS e-delivery XML files.

Node Application Package Comment

RNC apcBase_xxxx

atmNetworking_xxxx

base_xxxx

baseExt_xxxx

cnp_xxxx

cRNCApc_xxxx

fabric_xxx Depends on delivery

genericUtilities_xxx

ip_xxxx

ipsec_xxx For OAM security features

iRNC_xxxx

iRNCApc_xxxx

iRNCCiph_xxxx Optional only if Ciphering is


applicable

networking_xxxx

ss7_xxxx

ss7Apc_xxxx

wanDte_xxxx

wirelessCommon_xxxx

Table 5.3-2: RNC Application Packages

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 69/223


UMTS RNC Product Engineering Information

5.3.5 RNC MSS BASED FEATURES

As far as the RNC is concerned:

Module Feature Mandatory/ Comment


Optional

CP rnc M Encapsulates oamEnet and


externalTiming (For BITS
external synchronization sources
on CP cards) features

ip M

mvr M

atmHpnni M For PNNI on all interfaces using


Hierarchical PNNI

oamRadius O

ipsec O Need also to clarify the Ftp

Packet Server atmMpe M

(applicable to ip M
PS-FP and
rnc M Encapsulates localMedia and
DCPS boards)
Diffserv

iuPcIp M For A-GPS feature

kasumi O Only if Ciphering is applicable

16pOC3/STM1 atmMpe M

(applicable to ip M
16pOC3STM1
rnc M Encapsulates atmCore,
PQC and
iuxIfRnC, localMedia, aps,
16pOC3STM1
atmUni, atmPnni (if PNNI over
MS3 boards)
IuX is used).

atmMpeSpvc M Related to UA6 feature PNNI


Hairpin Removal, in that way :

In UA06 sPVC can be


managed at application level =>
sPVC PNNI hairpin removal is
possible. (Note that it is not
mandatory, hairpins are still
supported in UA06. Nevertheless
in case of capacity increase it
could be needed to do it to free
additional external ports of
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 70/223


UMTS RNC Product Engineering Information

16pOC3STM1 board for addition


of new external lines).

4pGiGE atmMpe M

ip M

rnc M

Table 5.3-3: RNC Modules supported FeatureList

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 71/223


UMTS RNC Product Engineering Information

5.4. RNC BOARDS ARCHITECTURE


As mentioned into previous sections, RNC is based on MSS 15K and into RNC
context four types of boards are used:

o CP

o 16p OC-3/STM-1
o Packet Server

o Optionally 4pGigE

As such RNC system architecture is as follows:

Packet Server

Figure 5.4-1: RNC Overall Hardware Architecture

5.4.1 CP
The Control Processor (CP) board controls the overall RNC shelf. Two types of CP
boards exist: CP3 or CP4. According to the HW baseline of the RNC (see 5.2.2) one
type or the other has to be used for the RNC.

Some of the main functions it provides are:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 72/223


UMTS RNC Product Engineering Information

o External access (10/100 BaseT RJ45 Ethernet, RS232 Serial console, and
E1/DS1 BITS interfaces for synchronization). Please refer to dedicated
section for a description of those.

o Disk storage for Provisioning Data, Software, Operational Files, Logs, Call
Trace files.

o On-Switch OAM for modules inserted and process instantiated.

o Interface Management with the Off-Switch OAM for FMIP, Telnet, FTP,
Fault Reporting, Provisioning, Time Reference.

o Processing of memory intensive, non real time tasks, such as virtual routing,
Routing tables and Database hosting (Static, RIP, OSPF, PNNI)

Into RNC context, CP operates into 1+1 redundant mode as described into section
dedicated to redundancy.

RNC CP File system is relying on SFS (Shadowed file system), that is an entity which
resides on the active CP providing a redundant file system consisting of two hard
disks located on the active and standby CPs.

When an application writes data to the file system, SFS will apply the data to the local
disk on the active CP and then replicate it to the remote disk on the standby CP. The
data on the standby CP is synchronized allowing for a hitless CP switchover. From the
application point of view, it is always reading and writing to one file system regardless
of the actual status of the individual disk.

DIFFERENCES BETWEEN CP3 AND CP4:


The main differences between CP3 and CP4 boards in term of Hardware
characteristics are the following:

- CP4 processor frequency: 1GHz compared to 400 MHz for CP3 processor
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 73/223


UMTS RNC Product Engineering Information

- CP4 owns UltraDMA (ATA-4) that allows a 2x rate increase across ATA bus
compared to CP3

- L2 memory has the same size (1MB), but sped-up from 133MHz (CP3) to 1GHz
(CP4)
- CP4 DDR memory supports DMA bursts at 266MHz (vs. CP3 main memory 133MHz
Synch DRAM)

- CP4 disk allows faster seek time, fast data transfer to/from the disk (CP4: 7200 RPM
disk up from 4200 for CP3)

5.4.2 16P OC3/STM1


The 16pOC3/STM1 Functional Processor (FP) provides the RNC interfaces with
connectivity to the network.

Some of the main functions it provides are:

o OC3/STM1 interfaces. ). Please refer to dedicated section for a


description of those.

o Connectivity for Iub, IuCS, IuPS, IuR, IuPC and IuBC

o ATM UNI and NNI Cells

o ATM Routing and Signalling (UNI, PNNI)

o ATM connections (PVC, SPVC) switching and termination (VCC, VPT)

Warning: 16pOC3/STM1 ONLY supports BASIC VPT.

o ATM Layer termination and handling to upper Layers

o ATM Traffic Management (Service Categories, CAC, Shaping)


o ATM statistics

o ATM OAM functions

o IP Forwarding

16POC3/STM1 PQC ARCHITECTURE

16pOC3/STM1 simplified high level architecture is as follows:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 74/223


UMTS RNC Product Engineering Information

Figure 5.4-2: 16pOC3/STM1 PQC Board Internal Architecture

ASICs roles are the following ones:

o APC is responsible for ATM Traffic Management

o PQC/QRD manages ingress and egress ATM cells framing into MSS
internal format as well as their forwarding

o CPAC manages the interface with the Fabrics

o PDC is responsible for the board supervision and oam functions

As pointed into the previous figure, each APC is responsible for 4 Optical ports, their
repartition is as follows:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 75/223


UMTS RNC Product Engineering Information

Figure 5.4-3: 16pOC3/STM1 PQC Optical Ports Management

16POC3/STM1 MS3 ARCHITECTURE

The architecture of the 16pOC3STM1 MS3 board is presented in the following figure
with the functional role of each component.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 76/223


UMTS RNC Product Engineering Information

Figure 5.4-4: 16pOC3/STM1 MS3 board internal architecture

The different modules are the following:


o PHY: The PMC Sierra developed S/UNI-16x155 device.
o Atlas: The PMC Sierra developed S/UNI-Atlas-3200 device.
o GQM: Generic Queue Manager device.
o RCAF: Reassembly, Classification and Formatting FPGA.
o CBAAS: Congestion Bus/ATM AAL5 Segmenter FPGA.
o RSP2: Route Switch Processor device.
o FWD: Forwarding Engine device.
o Reassembly FPGA: The FPGA which provides ATM to ATM over PMLS interworking.
This device is a pass through mode for a pure ATM application.
o CPAC2: The IBM developed Cross Point Access Controller device.

The following figure presents the organization of optical ports and their numbering.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 77/223


UMTS RNC Product Engineering Information

Figure 5.4-5: 16pOC3/STM1 MS3 board optical ports management

Into RNC context, 16pOC3/STM1 (for both types of board PQC and MS3 boards)
offers both FP and Interfaces redundancy as described into section dedicated to
redundancy.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 78/223


UMTS RNC Product Engineering Information

5.4.3 PACKET SERVER


The Packet Server Functional Processor (FP) has no external interfaces and provides
the RNC with power processing for UMTS specific Layers and Transport Network
Layer management.

Nota: From UA05.1.2, two types of Packet Server boards exist: PSFP and DCPS (see
chapter 5.2.2). The DCPS boards could be used on the RNC shelf only from this
release.

PACKET SERVER (PS1) FUNCTIONAL PROCESSOR BOARDS

PSFP simplified high level architecture is as follows:

Figure 5.4-6: PSFP Board Internal Architecture

It is based on industry standard PCI Mezzanine Cards (PMCs), and each PSFP hosts
six of them.

ASICs roles are the following ones:

o PMC makes Application Processing detailed below


o PQC manages ingress and egress ATM cells framing into MSS internal
format as well as their forwarding

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 79/223


UMTS RNC Product Engineering Information

o CPAC manages the interface with the Fabrics


o PDC is responsible for the board supervision, oam functions and can also
handle some functional level such as part of the SS7 stack (SAAL-NNI
part for PSFP that do not carry PMC-NI).

DUAL CORE PACKET SERVER BOARDS (PS2)

For DCPS boards, the functional block diagram is the following:

Figure 5.4-7: DCPS Block Diagram

This board contains three Dual Core processors MPC8641D.

From a logical point of view, as for previous PSFP board, 6 different PMC like are
considered on this board for the application processing. The organization of the PMC
is identical between PSFP and DCPS board and is presented below.

ENHANCED DUAL CORE PACKET SERVER BOARDS (PS3)

This board is introduced from UA08.1 release and for eDCPS board, the functional
block diagram is the following

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 80/223


UMTS RNC Product Engineering Information

Figure 5.4-8: eDCPS Block Diagram


From a logical point of view, the main difference vs the DCPS board concern the
Grizzly FPGA architecture.

The DCPS/eDCPS mixity is allowed but without capacity increase. The total capacity
increase is reach with full eDCPS configuration.

5.4.4 PACKET SERVER PMC ROLES DESCRIPTION


PMC-M: PMC-Master (2 per RNC) is used for the management of all other PMCs
involved into User Plane processing (PMC-PCs and PMCs-RABs) and so is
responsible as far as the User Plane is concerned for:
Resource Management

Transport Bearer Management

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 81/223


UMTS RNC Product Engineering Information

Configuration Management (e.g AAL2 Paths Binding to PMC-PCs)


Performance Management (e.g Call Traces)

Load Balancing and overload Management of User Plane

Fault Management
It also carries Q2630.1 signalling through Qaal2 Stack Migration from TMU to PMC-M

PMC-PC: PMC-Protocol Converter (1 per PS boards so 12/RNC maximum)


responsible for AAL2 to AAL5 conversion and vice versa:

Each PMC-PC manages a set of AAL2 path used over Iub, IuCS or IuR
interfaces

PMC-RAB: PMC-Radio Access Bearer (up to 40 per RNC) implements the Layers 1
and 2 of Uu interface which includes:

Compression

Ciphering

DHO (Macro Diversity)

RLC/MAC radio protocol

Qos Management

It also terminates the UMTS User plane protocol layers for cells and calls on the Iu, Iur
and Iub interfaces.

PMC-NI: PMC-Network Interface (2 per RNC) is responsible for some of the SS7
Layers and for relaying A-GPS based information when provisioned:

SCCP

MTP3B

TAL/TCP

PMC-OMU: PMC-Operation and Management Unit (2 per RNC) is used for the OAM
interface to WMS for RNC subset it manages and the management of the majority of
Control Plane of the RNC, so its role is equivalent to the PMC-M role on User Plane
side:

Resource Management

Transport Bearer Management

Configuration Management (e.g NodeBs and Cells assignment to TMUs)

Performance Management (e.g Call Traces)

Load Balancing and overload Management of Control Plane

Fault Management
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 82/223


UMTS RNC Product Engineering Information

RNS Logical O&M


Mounting with CP3 for disk partition access

Termination of SABP protocol for Iu-BC.

PMC-TMU: PMC-Traffic Management Unit (Up to 14 per RNC until UA07.1.2 release)
implements Radio Resource Management (Layer 3 of the Uu Interface).

From UA08.1, with Flex TMU/RAB feature enabled, customer may adjust the number
of TMUs according to some recommended values. Please refer to the PMC role
assignments from UA08.1 chapter.

RRC

RRM Strategy

Qos Management

CAC algorithm

It terminates the UMTS Control plane protocol layers for cells and calls on the Iu, Iur
and Iub interfaces such as RANAP, RNSAP, NBAP.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 83/223


UMTS RNC Product Engineering Information

GLOBAL PMC ORGANIZATION UNTIL UA7.1.2

PMCs may play one of the six roles listed below depending on RNC Family. Their
number may also differ:

PMC Role RNC associated numbers (*)

PMC-M 2

PMC-PC Min 4 / Max 12

PMC-RAB Min 10 / Max 40

PMC-NI 2

PMC-OMU 2

PMC-TMU Min 4 / Max 14

(*) Reminder: Any numbers between min and max are not allowed, numbers are
statically related to number of PSFP as illustrated below and number of PSFP allowed
is itself directed by RNC supported configurations.

Furthermore as illustrated below those roles as STATICALLY assigned by the


Software depending on:

the slot of the PSFP the PMC belongs to is inserted

the PMC identifier

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 84/223


UMTS RNC Product Engineering Information

PMC ROLE ASSIGNMENT IN FULL ATM RNC CONTEXT

Processor ID and Number


Slot Card Type 0 1 2 3 4 5
0 CP
1 CP
2 PSFP PMC-M TMU RAB RAB PC RAB
3 PSFP PMC-M TMU RAB RAB PC RAB
4 PSFP RAB TMU NI RAB PC OMU
5 PSFP RAB TMU NIi RAB PC OMU
6 PSFP RAB TMU RAB RAB PC RAB
7 PSFP RAB TMU RAB RAB PC RAB
8 16p OC3/STM1
9 16p OC3/STM1
10 PSFP RAB TMU RAB RAB PC RAB
11 PSFP RAB TMU RAB RAB PC RAB
12 PSFP RAB TMU RAB RAB PC TMU
13 PSFP RAB TMU RAB RAB PC TMU
14 PSFP RAB TMU RAB RAB PC RAB
15 PSFP RAB TMU RAB RAB PC RAB

Figure 5.4-9: PSFP PMCs roles deployment into RNC

PMCs also offer different level and type of redundancy depending on their role as
described into section dedicated to redundancy.
The above figure 5.4-9 shows the PMC implementation for a market model using 12
PS boards. For smaller market models the implementation of the PMC is the same on
the remaining PS boards.
As explained in paragraph 5.2.3, in case of a RNC configuration using both ATM and
IP connectivity, the slots 14 and 15 are then used for 4pGiGE boards. In that case the
maximum market model is with 10 PS boards. Please refer to the figure 5.4-10 below:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 85/223


UMTS RNC Product Engineering Information

PMC ROLE ASSIGNMENT IN HYBRID ATM/IP RNC CONTEXT (10 PS)

Processor ID and Number


Slot Card Type 0 1 2 3 4 5
0 CP
1 CP
2 PSFP/DCPS PMC-M TMU RAB RAB PC RAB
3 PSFP/DCPS PMC-M TMU RAB RAB PC RAB
4 PSFP/DCPS RAB TMU NI RAB PC OMU
5 PSFP/DCPS RAB TMU NI RAB PC OMU
6 PSFP/DCPS RAB TMU RAB RAB PC RAB
7 PSFP/DCPS RAB TMU RAB RAB PC RAB
8 16p OC3/STM1
9 16p OC3/STM1
10 PSFP/DCPS RAB TMU RAB RAB PC RAB
11 PSFP/DCPS RAB TMU RAB RAB PC RAB
12 PSFP/DCPS RAB TMU RAB RAB PC TMU
13 PSFP/DCPS RAB TMU RAB RAB PC TMU
14 GiGE
15 GiGE

Figure 5.4-10: PMCs role deployment with 10 PS boards (hybrid ATM/IP)

Rule: RNC TMU RAB Re-BALANCING (feature applicable from UA07.1.2)

The new feature TMU RAB RE-BALANCING allows the processor role assignments
on the RNC 9370 to be modified. It provides the ability to select a role configuration
that gives two extra TMUs to the 10 DCPS + CP4 market model. The feature activate
numberOfTmus = 14.

Please refer the figure 5.4-11 below:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 86/223


UMTS RNC Product Engineering Information

PMC ROLE ASSIGNMENT IN HYBRID CONTEXT WITH 7.1.2 FEATURES

Processor ID and Number


Slot Card Type 0 1 2 3 4 5
0 CP4
1 CP4
2 DCPS PMC-M TMU RAB RAB PC RAB
3 DCPS PMC-M TMU RAB RAB PC RAB
4 DCPS RAB TMU NI RAB PC OMU
5 DCPS RAB TMU NI RAB PC OMU
6 DCPS RAB TMU RAB RAB PC RAB
7 DCPS RAB TMU RAB RAB PC RAB
8 16p OC3/STM1
9 16p OC3/STM1
10 DCPS RAB TMU RAB RAB PC TMU
11 DCPS RAB TMU RAB RAB PC TMU
12 DCPS RAB TMU RAB RAB PC TMU
13 DCPS RAB TMU RAB RAB PC TMU
14 GiGE
15 GiGE

Figure 5.4-11: DCPS PMCs role deployment with feature TMU RAB Balancing (CP4 & 10 DCPS)

PMC ROLE ASSIGNMENT WITH ALL IP CONTEXT


Processor ID and Number
Slot Card Type 0 1 2 3 4 5
0 CP4
1 CP4
2 DCPS PMC-M TMU RAB RAB PC RAB
3 DCPS PMC-M TMU RAB RAB PC RAB
4 DCPS RAB TMU NI RAB PC OMU
5 DCPS RAB TMU NI RAB PC OMU
6 DCPS RAB TMU RAB RAB PC RAB
7 DCPS RAB TMU RAB RAB PC RAB
8 DCPS RAB TMU RAB RAB PC RAB
9 DCPS RAB TMU RAB RAB PC RAB
10 DCPS RAB TMU RAB RAB PC RAB
11 DCPS RAB TMU RAB RAB PC RAB
12 DCPS RAB TMU RAB RAB PC TMU
13 DCPS RAB TMU RAB RAB PC TMU
14 GiGE
15 GiGE

Figure 5.4-12: DCPS PMCs role deployment with 12 PSs and full IP context
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 87/223


UMTS RNC Product Engineering Information

The above figure shows the PMCs implementation for a market model using 12 PS
boards and Full IP context. This market model is applicable from UA07.1 release.

5.4.5 PMC ROLE ASSIGNMENT FROM UA08.1 RELEASE AND WITH


FLEX TMU/RAB ASSIGNMENT FEATURE (109904)
For 9370 RNC, the flex number of TMUs configure only applies tu full configured RNC
with 10 or 12 DCPS/eDCPS cards and CP4 cards
In UA7.1.2, the feature PM106904 TMU/RAB Rebalancing introduces a CDL
parameter numberOfTMU under the RncIn component which gives the customer
flexibility to assign either 12 TMU (standard) or 14 TMU on a 10 DCPS+CP4 full
dimensioning RNC (Refer to the 2 Figure above)

In UA08.1, the configuration mentioned in the above section is still supported but not
recommended. This configuration is used to migrate from UA7.1.2 configure to UA8.1
configures only. The CDL parameter is used to support more extra configurations.

On UA08.1 release, eDCPS board will provide same capacity as DCPS but enables
the software evolution for increase strongly capacity from UA08.1 release.
This new feature (Flexible TMU/RAB Assignment) provide also framework to allow
eDCPS & DCPS to use more than 14 TMUs as default setting.

10 DCPS flex: 16 ~ 26 TMU ; 28 ~18 RAB


12 DCPS flex: 20 ~ 32 TMU ; 34 ~ 22 RAB

12 eDCPS default: 20 TMU ; 34 RAB ; 12 RAB-PC (PC removal)

For answer the customer requirements, the following dimensions range will be
recommended.

10 DCPS/eDCPS: 16 TMUs

12 DCPS/eDCPS: 20 TMUs

10 DCPS/eDCPS: 18 TMUs

Remind: On the following chapter tables, DCPS stand for either PS2 or PS3
boards, means DCPS or eDCPS.
It is allowed to add eDCPS boards with TMU/RAB Flex configuration already
activated.

The UA08.1 flex MIB supports 144 cells per Service Group, max 29 Service
Group per RNC

The UA08.1 flexible TMU/RAB role assignment to support extra TMU is as


follow.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 88/223


UMTS RNC Product Engineering Information

Processor ID within DCPS card


Slot Card Type 0 1 2 3 4 5
0 CP4
1 CP4
2 DCPS PMC-M TMU RAB RAB PC TMU+6
3 DCPS PMC-M TMU RAB RAB PC TMU+5
4 DCPS TMU+8 TMU NI RAB PC OMU
5 DCPS TMU+7 TMU NI RAB PC OMU
6 DCPS RAB TMU TMU+14 RAB PC TMU+4
7 DCPS RAB TMU TMU+13 RAB PC TMU+3
8 16p
OC3/STM1/DCPS(All IP)
9 16p
OC3/STM1/DCPS(All IP)
10 DCPS RAB TMU TMU+12 RAB PC TMU+2
11 DCPS RAB TMU TMU+11 RAB PC TMU+1
12 DCPS RAB TMU TMU+10 RAB PC TMU
13 DCPS RAB TMU TMU+9 RAB PC TMU
14 DCPS(Pure ATM)/GE RAB TMU TMU++ RAB PC TMU
15 DCPS(Pure ATM)/GE RAB TMU TMU++ RAB PC TMU

Figure 5.4-13: 9370 RNC Flex TMU RAB role assignment strategy table

RNC: UA08.1 Flexible TMU RAB Role Assignment rules (notes about above figure)

For pure ATM configuration, the last two DCPS cards are in slot 14 and slot 15.

For pure IP configuration, last two DCPS cards are in slot 8 and slot 9, the role assignment on these
two cards is exactly the same as slot 14 and 15 shown in this table above.

The notation of TMU+# Means the sequence number used to increase the extra TMUs.

For 10 DCPS configuration, for example, if extra 6 TMU number is configured for 10 DCPS, then
TMU+7 and TMU+8 won't be converted to TMUs, and keep it's default role assignment as RAB;

For 12 DCPS configuration, if total number of TMU is configured greater or equal than 28, then AP at
position "TMU++" is assigned to TMU for the last two cards, otherwise the role is RAB.

The role assignment is a software concept, the hardware for different AP is the same, this role
assignment is just used for example, there is no guarantee that this mapping will continue be the same
in future releases, and it might be changed with other reasons.

According to the above role assignment strategy, as an example, a typical configure of


16 TMU / 10 DCPS and 20 TMU / 12 DCPS (All IP) is as described in the following
figure..

For 10 DCPS configuration there is no DCPS cards in slot 8 and 9.

For all IP 12 DCPS configuration, two DCPS cards are provided in slot 8 and 9. This
table also demonstrates how hitless capacity expansion works, when add 2 DCPS
cards to an existing 10 DCPS cards RNC.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 89/223


UMTS RNC Product Engineering Information

Example of role assignment for 16 TMU / 10 DCPS and 20 TMU / 12 DCPS


Processor ID within DCPS card
Slot Card Type 0 1 2 3 4 5
0 CP4
1 CP4
2 DCPS PMC-M TMU RAB RAB PC RAB
3 DCPS PMC-M TMU RAB RAB PC RAB
4 DCPS RAB TMU NI RAB PC OMU
5 DCPS RAB TMU NI RAB PC OMU
6 DCPS RAB TMU RAB RAB PC TMU
7 DCPS RAB TMU RAB RAB PC TMU
8 Empty/ RAB TMU RAB RAB PC TMU
16pOC3/STM1/
DCPS(All IP,
12 DCPS only)
9 Empty/ RAB TMU RAB RAB PC TMU
16pOC3/STM1/
DCPS(All IP,
12 DCPS only)
10 DCPS RAB TMU RAB RAB PC TMU
11 DCPS RAB TMU RAB RAB PC TMU
12 DCPS RAB TMU RAB RAB PC TMU
13 DCPS RAB TMU RAB RAB PC TMU
14 GE
15 GE

Figure 5.4-14: Role Assignment for 16 TMU / 10 DCPS and 20 TMU / 12 DCPS

In UA08.1, the number of active TMU (aTMU) equals to the number of SG (Service Group).
The number of standby TMU (sTMU) is determined by number of TMU minus number of
aTMU. The minimum required number of sTMU is determined by fault handling model, it
equals to the maximum number of TMU per FP card, which guarantees in a single FP card
failure case, there is enough standby TMU to take over the SG/NodeBs/Cells from the aTMU
on the impacted FP.
In UA08.1, flex MIB is provided to support the new configurations with extra TMU, the
supported configurations and number of TMU/RAB are listed in the following figure 5.4-15

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 90/223


UMTS RNC Product Engineering Information

Config Name Default UA7.1.2 Flex4 Flex6 Flex8 Flex10 Flex12 Flex14
TMU 12 14 16 18 20 22 24 26
SG(aTMU) 10 12 14 16 18 19 21 23
RAB 32 30 28 26 24 22 20 18
10
DCPS TMU/RAB 0.38 0.47 0.57 0.69 0.83 1.00 1.20 1.44
Ratio
SG/RAB 3.20 2.50 0.50 0.62 0.75 0.86 1.05 1.28
Ratio
TMU 14 --- 20 22 24 28 30 32
SG(aTMU) 12 --- 18 20 22 25 27 29
RAB 40 --- 34 32 30 26 24 22
12
DCPS TMU/RAB 0.35 --- 0.59 0.69 0.80 1.08 1.25 1.45
Ratio
SG/RAB 3.33 --- 0.53 0.63 0.73 0.96 1.13 1.32
Ratio
Min sTMU 2 3
Small /
MIB
Big Big Flex

Figure 5.4-15: Possible UA08.1 RNC 9370 Configurations

Note: RNC reset is required during migration, where different MIB is used or AP role
assignment need to change. For example, migrate from 10DCPS Flex4 to 10DCPS Flex6
requires shelf reset, because 2 RAB are converted to TMU.
10 DCPS migrate to 12 DCPS without changing the MIB and AP role assignment will take
advantage of hitless capacity extension (no outage). For example, migrate from 16 TMU / 10
DCPS (Flex4) to 20 TMU / 12 DCPS (Flex4) is hitless.

INTERACTION WITH FEATURE PM83985 - 9370 RNC CAPACITY


EVOLUTION WITH EDCPS

NB: PM83985 is a UA8.1 feature. With this feature, most of the PC load is taken by
eDCPS FPGA, and all PCs are converted to PC-RAB (or RAB-PC); some UPlane
functionalities are also taken by FPGA, this requires to rebalance the CPlane (TMU) and
UPlane (RAB) processor to achieve maximum capacity for the RNC. Flex TMU/RAB
assignment feature provide a framework to allow PM83985 to assign more than 14 TMU.
Flex MIB can be used for both PM83985 default role assignment and flex role
assignment with extra TMU. The implementation to use this framework is to be covered
by this PM83985 eDCPS feature.

NUMBER OF SERVICEGROUP PARAMETER

The MIB parameter numberOfServiceGroups is extended to the new MIB introduced in the
feature.

9370 default TMU/RAB assignment 9370 flex TMU/RAB assignment

NumberOfServiceGroups <= 12 <= 29

ServiceGroupId [0, 11] [0, 28]


Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 91/223


UMTS RNC Product Engineering Information

See also chapter 5.7.12 SERVICE GROUP PROVISIONING

CAPACITY IMPACT

This feature helps to efficiently use the available processor power usage by assigning varies
number of TMU and RAB per RNC, depending on the customers' traffic profile.
It improves RNC capacity in traffic model where CPlane traffic or TMU CPU utilization is a
significant capacity bottle neck.
However, when this feature is enabled, some RAB are converted to TMU, the RNC
capacity benchmarks are significantly impacted. The capacity benchmark target is
reduced with the same ratio of the decreased RAB number, for example, on 12 DCPS
RNC, when RAB number is changed from 40 to 20 with another 20 RAB converted to
TMU, the expected capacity benchmarks for All Voice, MOP and SMP7 etc. capacity
profiles are reduced to 50% of the level without this feature.

5.4.6 4P GIGE BOARDS


4pGiGE boards are optional. They are needed in case where direct IP interfaces are
used for the RNC. In UA06.0, only IuPS interface and a part of IuB for Hybrid IuB
configuration may use direct IP interface.

From UA7.1, 4pGiGE board could be used for Full IP configuration. As indicated by its
name, this board provides 4 ports for Gigabit Ethernet access.

Note that only IPV4 is supported with 4pGIGE boards.

The main characteristics of the 4pGiGE boards are the following:

Support of 1000 BASE-SX (short wavelength) and 1000 BASE-LX (long


wavelength). This wavelength may be chosen on a port basis with the use of
Small Form Pluggable connectors (SFP).
Ethernet II, 802.3 LLC SNAP encapsulation, 802.3z Gigabit MAC, IEEE VLAN
support (802.1Q)

Basic IP characteristics
Full Gigabit Ethernet throughput (One Gbit/s) supported on each port,
but the total aggregated throughput is limited to 2.5 Gbit/s for the four
ports (approximately depending on packet size and service)
Full duplex only

The description of the SFP connectors that equip these boards is presented in chapter
5.2.5.1.

At provisioning time, the type of connector used has to be specified (parameter


OpticalModule type: LX or SX).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 92/223


UMTS RNC Product Engineering Information

WIPS object is RNC Equipment/Inode/EM/Lp x/Eth/Om object

See chapter 5.9.3 for dimensioning rules associated to 4pGiGE boards.

5.4.7 LOCALMEDIA ROLE


It is important to note that most of hosts internal to RNC have one or several IP@
assigned and used those for exchanges to/from other hosts on top of IP, as such
internally all IP packets are carried (i.e. encapsulated/de-capsulated and internally
forwarded through the Fabric) over backplane cells. This is achieved through the
LocalMedia functionality that provides a Frame Hosting and Forwarding on top of
UDP/IP stack to/from backplane datapath.

For example Localmedia is used for exchanges between PMCs or between PMCs and
PDC.

Furthermore some local media are involved in external communication, this means
that they are externally visible and so required external IP@. See next chapter for
details information on Local Media addressing.

5.5. RNC SYSTEM ARCHITECTURE

5.5.1 RNC OVERALL ARCHITECTURE


As presented into the RNC overview, RNC is divided into three mains categories:

o Control Plane
o User Plane

o OAM Plane, which is vendor implementation specific

Furthermore each of two specified by standards planes are divided into two logical
layers:

o The Radio Network Layer, which includes all the UMTS specific interfaces
and associated protocols

o The Transport Network Layer, which includes all the non UMTS specific
interfaces and protocols, used for both UMTS Signaling and Data
transport, as well as Transport Network Layer related Signaling protocols.

Note: This clear distinction between UMTS applications and Transport Network makes
it possible for both to independently evolve.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 93/223


UMTS RNC Product Engineering Information

Thus depending on RNC Family, associated functions are distributed differently


across the RNC miscellaneous modules, which imply mechanisms for those modules
to interact as well as ways to manage them.

As a matter of fact as illustrated below RNC can be split from a system perspective
into four functional blocks:
o UMTS Control Plane associated functions

o UMTS User Plane associated functions

o Transport Network associated functions

o RNC System Management functions (OAM, Load Balancing, Robustness,


Overload Management)

Figure 5.5-1: RNC Overall System Architecture

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 94/223


UMTS RNC Product Engineering Information

5.5.2 RNC ATM TO IP TRANSPORT EVOLUTION


Until release UA6.0, RNC 9370 support ATM based interfaces only (this includes all
releases up to and including UA05.2).
From UA6.0 new IP features support was developed (Hybrid IuB, IuPS in UA6.0) and
now Native IP IuB, IuR and IuCS over IP for UA07 and UA08 feature. This evolution is
illustrated in the following figure.

UA05.2 and earlier UA06 UA07 and UA7.1 releases UA08.1

IuB ATM existing

Hybrid Hybrid IuB

IP IuB over IP

IuR ATM existing

IP IuR over IP

IuCS ATM existing

IP IuCS over IP

IuPS IP/ATM-AAL5 existing

IP IuPS over IP

Figure 5.5-2: Release Summary of ATM and IP Transport Introduction


Up to UA6.0, all RNC interfaces were transported as ATM on Sonet OC3 (North
American Standard Terms) or ATM on SDH STM1 for Global Market. ATM user plane
transport was ATM-AAL2 / Sonet (SDH) for IuB, IuR and IuCS while IuPS used IP /
ATM-AAL5 / Sonet DH). The control plane traffic was a mix of AAL5 (NBAP) and SS7
stacks both also carried on ATM-AAL5 / Sonet (SDH). See Figure below

Figure 5.5-3: All ATM Transport for RNC up to UA6.0

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 95/223


UMTS RNC Product Engineering Information

Release UA6.0 introduces Hybrid IuB and IuPS on IP through GigaEthernet Boards.
For Hybrid IuB, HSPA user plane was routed as UDP/IP/GE while other user plane
traffic (voice and other low bandwidth traffic) remained on ATM AAL2. All Iub control
plane traffic remained on the ATM / Sonet (SDH) transport. Also in UA6.0, in addition
to the ATM transport for IuPS, all user plane and control plane traffic may alternately
be transported over IP/ GE.

Illustration below:

Figure 5.5-4: Hybrid IuB and IuPS introduction on UA6.0

Release UA07 completes the support for IP GE for the IuCS, IuR and IuB (i.e Native
IP IuB) interfaces. Existing ATM, IP and Hybrid Transport mechanisms continue to be
supported at the same time.

IuB: RNC can connect at the same time to a NodeB with ATM only connections,
another NodeB with Hybrid (ATM and IP) connections and another NodeB with Full IP
connections.

IuR: RNC may have some neighboring RNC with ATM IuR connections and others
with IP IuR connections. While a single RNC can support both ATM and IP IuR
connections, all connections between any 2 RNC however must all be either ATM or
IP based.

IuPS: using IuFlex, a RNC can connect to one (or more) SGSN core with ATM
connections and one (or more) other SGSN with IP / GE connections.

IuCS: using IuFlex, a RNC can connect to one (or more) MSC with ATM connections
and other MSC with IP / GE connections.

Illustration below: UA07 Mix and match ATM & IP:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 96/223


UMTS RNC Product Engineering Information

Figure 5.5-5: UA07 Mix and Match ATM & IP any interface

With the introduction of native IP IuB, IuCS, IuR and continued support for IuPS, it is
now possible to deliver a full IP UTRAN RNC. Replacing the two 16P OC3 (STM1) FP
cards with PS boards (DCPS one) will allow the proportional growth in RNC capacity.
That allows having now 12 PS cards.

Find illustration on the figure below:

Figure 5.5-6: All IP UTRAN for all interfaces

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 97/223


UMTS RNC Product Engineering Information

5.5.3 RNC 9370 ATM TO IP MIGRATION


This section lists the prerequisites at RNC level for migration of IuB, IuR, and IuCS
RNC interface from ATM transport to IP transport. These prerequisites are mainly
ensuring that the IP infrastructure is in place to provide IP connectivity between the
RNC and destination node with resiliency and traffic treatment.

RNC must have Gigabit Ethernet cards installed and with basic IP transport
provisioning (GigE Port, VLAN, VR, Routing and QoS)

Protected static route should be defined

RNC must be running at least UA7


The IP backbone must be ready and network routing should be configured

Proper DSCP values in the Transport Map component should be configured before
the deployment of any IP interfaces.
The configuration of the Gige cards and IP forwarding is consistent with the procedure
depicted under the UA06 release for the IuPS and Hybrid IuB migration to IP. Along
the same lines, with the decommissioning of the Gige cards and re-introduction of the
PSFP card, shelf outage is expected to ensure that the RNC internal routing is
functional.

The migration procedure is executed in distinct steps and each step is roughly
associated with an OMC work order. The partitioning under distinct steps ensures that
if for some reason part of the migration is unsuccessful, only that part of the migration
is impacted and can reverted using the fallback procedure. In most cases fallback is
done using the reverse work order automatically generated by WiPS when the work
order to configure the IP service is created. The following presents from high level
perspective the phases of the ATM to IP transport migration.
The migration procedure could be applied with the help of the following document.

[Ext_R&D_026]

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 98/223


UMTS RNC Product Engineering Information

5.5.4 RNC IP SYSTEM ARCHITECTURE


On release UA07.1, full IP architecture has been introduced. All interfaces could be
carried over IP in addition of ATM if still required.
RNC IP Architecture mainly relies on MSS Virtual Router capabilities. MSS Virtual
Routers are a software emulation of what a real physical Router would be.

Those Virtual router are used to perform the interconnection of local media between
themselves for inter-board communication or for external world communication (IuCS,
IuPS, IuR,IuB, IuPC, IuBC and OAM). Furthermore VRs have independent IP routing
tables and IP addressing space, as such they are fully isolated one from each other.
The Internet Assigned Numbers Authority (IANA) has reserved the following three
blocks of the IP address space for private internets:

10.0.0.0 10.255.255.255 (10/8 prefix) A block


172.16.0.0 172.31.255.255 (176.16/12 prefix) B block

192.168.0.0 192.168.255.255 (192.168/16 prefix) C block

ALU RNCs use some private IP@ ranges for internal needs (VR/0 and VR/2), within
the B block.

Generally the 3G backhaul network is a private network that use IP@ addresses from
IANA reserved address space for private networks.

5.5.4.1 LOCAL MEDIA INTERFACE


The localMedia is a RNC IP media functionality which provides a functional interface
to the PMC that are unaware of the virtualRouter. It provides IP forwarding capability
to the PMC on the PSFP/DCPS FP.

The localMedia is centrally located on the CP.

There is one instance of the localMedia within the RNC.

The localMedia supports up to 32 interfaces each identified by an instance in the


range [0, 31]. There is no constraint on the LocalMedia interface instance numbering.

Each localMedia interface is configured against a VR PP. Several localMedia


interfaces may be configured over one VR.

Each LM interface is used to access a particular set of Hosts within RNC. To each
localMedia interface is assigned a trafficType value and as an option an interfaceType
value, which specify the kind of traffic forwarded over the interface and then
determines the destination set of hosts. Please see as an example the table 5.5-1
below on the chapter RNC IP ADRESSES ALLOCATION SUMMARY.
TrafficType:

TrafficType values:

- TrafficType = iubCplane:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 99/223


UMTS RNC Product Engineering Information

The localMedia interface configured with this trafficType is dedicated to the Iub
controlePlane traffic; the associated traffic terminates on the TMU and OMU. This
trafficType is configured only in case of nativeIP Iub, not configured if hybrid Iub.

- TrafficType = uPlane:
The localMedia interface configured with this trafficType is dedicated to the the whole
or part of the utran userPlane traffic (see interfaceType); the associated traffic
terminates either on the PC-NAT or on the RAB.
- TrafficType = ss7CPlane:

The localMedia interface configured with this trafficType is dedicated to the whole or
part of IuCS, IuPS and Iur controlPlane over IP traffic (see interfaceType); the
associated traffic terminates on the PDC.

- TrafficType = oam:

The localMedia interface configured with this trafficType is dedicated to the RNC oam
traffic; the associated traffic terminates on the OMU.

- TrafficType = ls:

The localMedia interface configured with this trafficType is dedicated to the


locationService traffic; the associated traffic terminates on the NI.

- TrafficType = cbs:

The localMedia interface configured with this trafficType is dedicated to the


cellBroadcastService traffic; the associated traffic terminates on the OMU.

- trafficType = rnc:

The localMedia interface configured with this trafficType is dedicated to some internal
traffic between PC-NAT and RAB.

- TrafficType = internalTraffic:

The localMedia interface configured with this trafficType is dedicated to internal traffic
between PDC and NI.

- TrafficType = iubUPinternal:

The localMedia interface configured with this trafficType is dedicated to some internal
traffic between PC-NAT and TMU, application for the purpose of UMTS Proprietary
loopBack.

5.5.4.2 VIRTUAL ROUTER CONFIGURATIONS


Several VR configurations are supported in RNC UA07 and UA08 release. The
following ones are some examples of possible customer configurations.

IP transport is extended to all interfaces and therefore there are a high number of
possible configurations of Virtual Routers, four main configurations are shown in the
following figures:

Segmented VR for each of OAM, IuB, IuCS, IuR, IuPS see Figure 5.5-7

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 100/223


UMTS RNC Product Engineering Information

Consolidated VR approach --> Combined VR for all routes plus one for OAM
see figure 5.5-8

Segmented VR by UP and CP plus one VR for OAM see figure 5.5-9

Segmented VR for each of OAM, Iux User Plane and Iux Control Plane see
figure 5.5-10

The following table gives some indications for the VR number and role for a standard
VR configuration with segmented VRs per interface and per Cplane/Uplane and the
ports number

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 101/223


UMTS RNC Product Engineering Information

Virtual Router Number and role RNC 4pGE port


Processors
VR0 OAM

VR1 IuPS User Plane PMC-RAB Port2/VLAN2

VR2 Internal

VR3 Location Services

VR4 Cell Broadcast

VR5 Iub UP+CP PMC-PCs Port0/VLAN1

PMC-TMUs

VR7 IuPS CP PDCs Port2/VLAN1

VR8 IuCS UP PMC-PCs Port3/VLAN2

VR9 IuCS CP PDCs Port3/VLAN1

VR10 IuR UP PMC-PCs Port1/VLAN2

VR11 IuR CP PDCs Port1/VLAN1

Some other configurations can be supported if requested such as a mix of segmented


VRs per interface and per CPlane/Uplane: for example, a VR IuCS, a VR IuR, a VR
IuB, a VR IuPS-CP and a VR IuPS-UP in order to isolate pure data traffic from voice
and signaling as requested by Customer.

PDR (Protected Default Route) is used in all configurations but only the first next hop
(active route) is shown to simplify the figures.

The use of VLANs is optional but it becomes mandatory as soon as the number of
protocol ports mapped on external ports exceeds 4.

In all configurations, the OAM VR exists mandatory for ItfR.

Usually in IP transport ItfB does not go through the RNC anymore except in a specific
case where the OMC is connected to an ATM backbone and a Node B is full IP. If, in
this specific case, a single IP address is used in Node B for O&M and Telecom flows,
an additional protocol port must be added for ItfB on the VR supporting IuB.

Moreover, two additional VRs may be configured if needed for Iu-BC and Iu-PC.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 102/223


UMTS RNC Product Engineering Information

Rule: RNC Virtual Router configuration (M)

The configuration of the virtual routers in the RNC is ONLY a consequence of the
internal required in term of IP flow. The means that it mandatory to first define the
external IP configuration of the interface. Questions to be answered:

Does the customer want to separate the interface ? (IuB, IuCS, IuR,IuPS)
Does the customer want to separate UserPlane and ControlPlane ?

How is done the separation ? different ports; Differents VLANs;

Rule 5.5-1: Virtual Router configuration

As such following Virtual Routers are implemented into RNC:

(Note that to have a more detailed view on these VR and some additional schemas,
the document [Ext_R&D_025] should be consulted)

Please find below some examples of configurations. On the figures, The IuB control
plane IP address on the OMU is used for the attach message only and is not the OMUs
OAM address.

SEGMENTED VR FOR EACH INTERFACE

Separation of each connection type (IuB, IuR, IuCS and IuPS). This configuration
provides a level of isolation of the connections from each other. This may be of
interest in an installation where one or more connections type share the network with
public domain traffic. The disadvantage concerns the provisioning complexity and also
the increased number of IP addresses for the RNC.

Figure 5.5-7: Segmented VR for each interface

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 103/223


UMTS RNC Product Engineering Information

CONSOLIDATED VR CONFIGURATION

The consolidated VR approach provides the simplest provisioning, does not require VLAN,
and uses a minimal number of IP addresses. It does not however provide any level of
connection isolation like the Segmented VR solution.

Figure 5.5-8: Consolidated VR approach

SINGLE VR SEGMENTATION FOR TRAFFIC INTERFACES

The connection segmentation by User Plane VR and Control Plane VR provides the
opportunity for the Control Plane transport network to be isolated from the User Plane. This
architecture is consistent with previous narrow band network architectures.

Figure 5.5-9: Segmented by UP VR and CP VR all interfaces


Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 104/223


UMTS RNC Product Engineering Information

SEGMENTED VR PER INTERFACE AND PER UPLANE/CPLANE

This example provides the maximum level of VR isolation between the Iux connections as well
as for the given Iux User Plane and Control Plane connections. It is included to illustrate the
level of flexibility possible. It is also noted that the current Node-B does not have the ability to
support separate VR for User Plane and Control Plane.

Figure 5.5-10: Segmented VRs by UP and CP all interfaces

5.5.4.3 OAM TRAFFIC VIRTUAL ROUTER AND LOCAL MEDIA


This Virtual Router aggregates most of UTRAN Network Elements OAM Flows:

RNC OAM Flows

Aggregate NodeB Implementation specific associated OAM

Externally route to/from OMU over PMCs, so in other words allow access from
WMS to those.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 105/223


UMTS RNC Product Engineering Information

In order to achieve RNC specific point a dedicated Localmedia is implemented with


the following IP internal addressing plan associated with it:

Subnet Address 127.255.0.0

Subnet Mask 255.255.255.0

Broadcast Address 127.255.0.255

Localmedia IP 127.255.0.254

Primary OMU internal IP@ 127.255.0.1

Secondary OMU internal IP@ 127.255.0.2

NodeB Oam over IP Traffic:


ALU does not recommend the nodeB oam over IP traffic flow to be routed through the
RNC in an all IP Utran network (irrespective inBand or OutBand solutions are
deployed in the network), since it increases the delay associated with these flows, as
well as unnecessary increasing the RNC packet processing load.

In case where the OMC is reachable through an ATM backbone, the Iub oam over IP
traffic may be routed through the RNC. In this case, the RNC acts as an interworking
node between the IP domain and the ATM domain.

The RNC Oam traffic is forwarded to the OMC euther inBand over ATM (16pOC3FP)
or inBand over IP (4PGE FP) or out of Band (CP card)

NODEB IUB OVER IP & RNC OAM INBAND OVER ATM

The Iub OAM over IP Traffic is routed to the RNC over the IP backbone and then
forwarded by the RNC inBand over ATM (16pOC3 FP) to the OMC

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 106/223


UMTS RNC Product Engineering Information

Figure 5.5-11: RNC In Band OAM Connectivity

IN BAND CONNECTIVITY OVER ATM

For the In-band OAM connectivity accomplish only over ATM links with the 16pOC-
3/STM-1 module, incoming packets from the OMC-R are converted from Ethernet to
ATM by a router, which is connected to the PMC-OMU with a provisioned IP datapath
over ATM.

OMC-B implementation specific OAM&P (and DHCP) messages are routed over a
16pOC-3/STM-1 link to the Node-Bs via IP/AAL5/ATM on the Iub interface.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 107/223


UMTS RNC Product Engineering Information

Figure 5.5-12: RNC In Band OAM ATM Connectivity

RNC OAM INBAND/OUTBAND OVER IP

The Iub OAM over IP traffic is routed to the OMC directly through the IP backbone.

Figure 5.5-13: RNC OAM inBand/outofBand over IP

RNC OAM OUT OF BAND ATM CONNECTION

Out-of-band OAM&P connectivity is accomplished using an Ethernet port on the CP


module and an internal IP datapath. In other words, OAM messaging uses a separate
Ethernet network.

Incoming packets from the OMC-R are received on the CP Ethernet port and routed to
the PMC-OMU using provisioned IP subnet entries in a routing table.

OMC-B OAM&P (and DHCP) messages are received at the CP Ethernet port and
routed over a 16pOC-3/STM-1 link to the Node-Bs via IP/AAL5/ATM on the Iub
interface.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 108/223


UMTS RNC Product Engineering Information

Figure 5.5-14: RNC ATM Out of Band OAM Connectivity

For more details see [Ext_ENG_009]

5.5.4.4 RNC IP ADDRESSES ALLOCATION SUMMARY


For details refer to [Ext_ENG_009]:

Example below of UTRAN / RNC IP Addressing plan in case of consolidated VR.

Table 5.5-1: RNC Local Media Interface address assignments

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 109/223


UMTS RNC Product Engineering Information

5.5.4.5 UMTS OPERATIONAL FLOWS VIRTUAL ROUTER AND


LOCAL MEDIA FOR THE RNC PATHS
For more details see (FN and TEG Addressing)
This Virtual Router provides internal exchanges to/from PMCs and external
exchanges to/from U-SGSN. PMCs associated subnet under Operational Virtual
Router is indeed visible from outside the RNC (but only PMC-RAB should go outside).

The consolidated VR router could manage:

An internal interface for PMCs, this is achieved through a dedicated


localmedia and associated subnet described below.

External interfaces for IuPS over ATM User Plane. Please refer to IuPS
interface description for a description of those externally visible aspects of
Operational Virtual Router

In case of IuPS over IP:

External interfaces for IuPS over IP User Plane.


External interfaces for IuPS over IP Control Plane.

Internal interface for PDC for the ss7 protocol over IP Control Plane
(ss7Cplane) between RNC and SGSN

In case of Hybrid Iub and in case of CONSOLIDATED configuration:

External interfaces for IuB traffic over IP

Internal Interface for PMC-PC for the IuB traffic over IP

Internal Interface for PMC-TMU for the heartbeat messages sent by RNC to
NodeB for the supervision of the IP links.

Thanks to RNC deterministic allocation rules of roles and associated IP@, it is


possible to extract GTP Hosts IP@ since each PMC-RAB can host a GTP Server.

Note that this address description is used in both cases: Iu-PS over ATM as for Iu-PS
over IP User Plane exchanges.

The Table below, RNC PMC-RAB IP@ shows the IP@ assigned by the RNC to the
PMC-RAB according to:
- The subnetID and subnetMask either /25 or /26 configured on the VR PP linked to
the [uPlane trafficType & IuPS interfaceType] LM interface,

- The PMC location into the RNC (PSFP/DCPS slot number, AP).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 110/223


UMTS RNC Product Engineering Information

Remark: case of ATM RNC, the slots 8 and 9 are populated with the 16pOC3/Stm1
FP; case of hybrid RNC, the slots 8 and 9 are populated with the 16pOC3/Stm1 FP
and the slots 14 and 15 are populated with the 4pGE FP; case of IP RNC the slots 14
and 15 are populated with the 4pGE FP.

WARNING: Those rules are subject to changes from one release to the other. As a
matter of fact number and IP@ of GTP Hosts are subject to changes across UA
releases.

IUPS VIRTUAL ROUTER AND LOCAL MEDIA USER PLANE


ALLOCATION

CHANGE OF RNC IUPS USER PLANE ADDRESSES AND SUBNET


REDUCTION

IP transport on Iu-PS has been introduced in UA06 but the Iu-PS addressing plan has
been improved in UA07. In UA06 the GTP host IP addresses are allocated from within
the same subnet as the PMC internal subnet. Thus, this subnet is used for both
internal message exchanges between the PMCs and for GTP external message
exchanges with the SGSN (when the PMCs are playing a PMC-RAB role). This
addressing scheme has several major drawbacks:
The subnet size is /25 (128 hosts) even though a maximum of only 40 GTP hosts
is required which, from an operators perspective, wastes 86 IP addresses (even
though these addresses are often allocated from a private address space as per
RFC 1918, they are normally managed internally within an operators network as
though if they are public addresses and therefore require coordination at the
corporate level in order to allocate and use a specific private IP address);
It exposes the internal PMC subnet to the outside world which is considered to be
a security risk;
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 111/223


UMTS RNC Product Engineering Information

If the operator wishes to change the Iu-PS IP subnet a global RNC reset is
necessary since this subnet is also used for the internal PMC messaging traffic.

UA06 RNC 9370 /25 IUPS LOGICAL DATAPATH

Both internal & external


traffic appear in the
Operational subnet 172.30.34.0/25 same subnet and VR

PMC-
M
RA
B GP
TM 1
172.30.34.126 10.10.10.1
U LocalMedia TT: rnc PP PP GP
N I / F 1 2 2 SP SGSN
I Operational VR/1 GP 1
3 10.10.10.2
P
C 4pG GP
E 4
OM
U
172.30.34.1 172.30.34.72
RNC

Legend:
TT Traffic Type
PP Protocol Port
GP Gigabit
Ethernet Port
SP SGSN Port

Therefore, in UA07, in order to overcome the above limitations the Iu-PS Uplane
traffic will be separated from the internal PMC traffic. This will be done as part of
the software migration to UA7.0. Thereafter, the operator will be given the choice
of continuing to use the existing /25 subnet or take advantage of configuring a new
smaller subnet of size /26 (64 hosts). By opting for a /26 subnet allows some of the
existing addresses to be freed up for other use, although it does have the side
affect of causing the RNC Iu-PS IP addresses to change.

The /25 address allocation scheme uses the PS slot number and the PMC Id within
that slot to determine the IP address that is allocated for the Iu-PS UP IP address
(i.e. x.y.z.0 OR x.y.z.128 + (15 - <SlotId#> )*6 + <PMCid#>).

The /26 address allocation scheme, on the other hand, uses a simplified scheme
by allocating the Iu-PS UP IP addresses on a consecutive basis, with a full RNC
requiring 40 IP addresses.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 112/223


UMTS RNC Product Engineering Information

UA07 RNC 9370 / 26 IUPS LOGICAL DATAPATH

IuPS Uplane subnet 172.30.34.0/26 Internal traffic separated


from external traffic by
TT: uplane using different subnets
RAB and different VRs
LocalMedia IT: iups
I/F 10.10.10.1
172.30.34.1 PP PP
172.30.34.62
172.30.34.40 1 2
IuPS Uplane VR/2

GP
1
Internal subnet 127.4.1.0/25 GP
2 SP SGS
PMC-M GP 10.10.10.21 N
3
RAB 4pGE GP
4
TMU
LocalMedia TT: rnc
NI I /F
127.4.1.126PP
1
PC Legend:
Internal VR/1 TT Traffic Type
IT Interface Type
OMU PP Protocol Port
127.4.1.1 127.4.1.72 GP Gigabit Ethernet
RN C Port
SP SGSN Port

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 113/223


UMTS RNC Product Engineering Information

UA08 RNC 9370 / 28 IUPS LOGICAL DATAPATH

As presented in the following table, the decision to assign the IP addresses to the
PMC PC/ Panda or PMC-RAB is based on the two criteria:

The subnet size being configured under the LocalMedia interface with a trafficType
Uplane and InterfaceType IuPS and also the deployed card type being either PSFP or
DCPS.

1. UA08 software activation: After the UA08 software activation, the subnet is still
configured as /25 or /26. In this configuration the IuPS UP IP addresses are assigned
to the PMC-RAB.

2. Support for PSFP: When the card type is PSFP, the IP addresses are assigned to
the PMC-RAB. A /28 subnet and PSFP card type combination is not allowed; a
semantic check is added to guard against this configuration.

Rule: RNC Migration from /25 or /26 subnet to /28 subnet

When first activating the UA08 software release; by default the external IuPS UPlane
subnet will have a dimension of 128 or 64 to remain compatible with UA07 and earlier
releases.

When the customer wants to take advantage of this feature and reduce the IuPS
Uplane subnet size to a /28 subnet (with 16 IP addresses), they need to:

find the Vr ProtocolPort instance linked to the Localmedia Interface with


trafficType uplane and ifType iups;

modify the Vr ProtocolPort IpPort LogicalIf component by deleting current


LogicalIf component and adding it with:

IP address a.b.c.(x + 14), where x can be 0, 16, 32, 48, 64, 80, 96, 112,
128, 144, 160, 176, 192, 208, 224 and 240;

Network Mask is set to "255.255.255.240;

Activating this provisioning will cause an all AP reset (and thus a total service outage).
This outage is necessary to ensure that all processors on the RNC have a consistent
view of the new IP configuration.

Although outside the scope of this feature, the SGSN configuration should also be
verified to ensure that routing is configured properly based on the new subnet
definition.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 114/223


UMTS RNC Product Engineering Information

Note: For new deployment in UA08, it is assumed that they would used the /28 subnet
dimension.

IUPS UP DATAPATH

As indicated previously, subnet reduction is obtained by inserting the PMC-PC/Panda


as a concentration point in the IuPS Uplane ingress datapath. Instead of sending the
packet directly to each PMC-RAB (as currently done); the packets received from the
SGSN over the IuPS interface are sent to the PMC-PC/Panda hosting the IuPS UP IP
address. The packets are then forwarded to the PMC-RAB on the local card (in none
failure condition) based on the routing information encoded in the TEID field.

In the egress direction, the packets destined for the SGSN are sent directly from PMC-
RAB to the IuPS interface on the Gige card. The Panda FPGA does not inspect
packets in the egress direction.

The following diagram describes from a high level perspective the steps taken to
forward packets received over the IuPS interface to their final destination on the PMC-
RAB, and in the egress direction the steps to send the outgoing packets from the
PMC-RAB to the IuPS interface on the Gige card:

Characteristics for the IuPS interface are described on the chapter 5.8-5

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 115/223


UMTS RNC Product Engineering Information

IUB VIRTUAL ROUTER AND LOCAL MEDIA

For Hybrid IuB, PMC-PC addressing for IuB User Plane traffic over IP is managed as
following:

This Virtual Router is declared only in the case of Hybrid IuB usage and in the case of
a SEGMENTED VR case (see description in beginning of 5.5.2 section).

PMC-PC addressing for IuB User Plane traffic over IP is managed as following:

Subnet Address x2.y2.z2.t2/28 (with the four last


bits equal to 0)

Subnet Mask 255.255.255.240 ( = /28)

Broadcast Address x2.y2.z2.(t2 | 0xF) (with the four


last bits equal to 1)

Localmedia IP x2.y2.z2.T with T having the


last byte equal to 0xE

PMC-TMU assigned IP@ x2.y2.z2.t2 + PC_identifier


where PC_identifier is coded on
four bits.

In addition for the heartbeat exchange between PMC-TMU and NodeB to


supervise the IP Flows the localmedia characteristics are needed for PMC-TMU:

Subnet Address 127.3.1.0/25

Subnet Mask 255.255.255.128 ( = /25)

Broadcast Address 127.3.1.31

Localmedia IP 127.3.1.126

Internal PMC-TMU assigned 127.3.1.0 + TMU_identifier


IP@ where TMU_identifier is coded
on five bits.

For Native IP IuB, on release UA08.1 with the feature flex TMU/RAB, the IuB
Cplane subnet has to be increased to accommodate up to 30 IP addresses for each
new active TMUs (29 IP for active TMU and one for active OMU)
As these are public addresses, which are a scarce resource, we increase the subnet
only if the operator provisioned numberOfTMU to be more than 14.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 116/223


UMTS RNC Product Engineering Information

The algorithm is modified as follows in UA08.1.


LocalMedia reads the "numberOfTMU" attribute under "RncIn" component to
determine the correct subnet:

When RncIn/numberOfTMU is provisioned to default or 14, IubCplane net mask


should be provisioned to 255.255.255.240 as usual

When RncIn/numberOfTMU is great than 14 but less or equal than 31, IubCplane net
mask should be provisioned to 255.255.255.224
Characteristics for IuB interface are described on the chapter 5.8-3

IUCS VIRTUAL ROUTER AND LOCAL MEDIA

One IP@ Subnet /28 is needed for IuCS CPlane to address PDCs : this Subnet may
be shared with IuB and IuR CPlane depending on the VRs configuration.
One IP@ Subnet /28 is needed for IuCS UPlane to address PMC-PCs : this Subnet
may be shared with IuB and IuR UPlane depending on the VRs configuration.

From UA08.1, the feature 117498 handles the possibility to have user plane over ATM
while control plane is handled over IP.

For complete information on IUCS path, please refer to chapter 5.8-4 IuCS Interface

IUR VIRTUAL ROUTER AND LOCAL MEDIA

RNC can support both ATM and IP IuR connections at the same time

Between 2 RNC, the communication must be either ATM or IP.

For complete information on IUR path, please refer to chapter 5.8-7 IuR Interface

5.5.4.6 RNC INTERNAL EXCHANGES VIRTUAL ROUTER


This Internal Virtual Router (VR/2) provides internal exchanges for:

SS7 functionality

OMUs/TMUs communication into RNC context


OMUs/TMUs access to CP File System into the RNC context.

This is achieved through an internal interface for PMCs and other RNC internal
processors, implemented with dedicated localmedia and associated subnet described
below.

Subnet Address 127.2.0.0

Subnet Mask 255.255.0.0 (=/16)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 117/223


UMTS RNC Product Engineering Information

Broadcast Address 127.2.255.255

Localmedia IP 127.2.255.254

5.5.4.7 LOCATION SERVICES VIRTUAL ROUTER AND LOCAL


MEDIA
This Virtual Router provides internal exchanges to/from PMC-NI managing Agps TNL
and external exchanges to/from SAS. PMC-NI internal associated subnet under
Location Virtual Router is NOT visible from outside the RNC, only external IP
addresses assigned with it are visible.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 118/223


UMTS RNC Product Engineering Information

It manages
An internal interface for PMC-NI, this is achieved through a dedicated
localmedia and associated subnet described below.

External interfaces for IuPC. Please refer to IuPC interface description for a
description of those externally visible aspects of Location Services Virtual
Router

Dedicated Localmedia mentioned above is implemented with the following IP internal


addressing plan:

Subnet Address 127.255.1.0

Subnet Mask 255.255.255.252

Broadcast Address 127.225.1.3

Localmedia IP 127.225.1.2

5.5.4.8 CELL BROADCAST SERVICES VIRTUAL ROUTER AND


LOCAL MEDIA
This Virtual Router provides internal exchanges between PMC_OMU managing CBS
services and external CBC.

Dedicated Localmedia mentioned is implemented with the following IP internal


addressing plan:

Subnet Address 127.254.1.0

Subnet Mask 255.255.255.252

Broadcast Address 127.254.1.3

Localmedia IP 127.254.1.2

5.5.5 RNC SS7 SYSTEM ARCHITECTURE

5.5.5.1 RNC SS7 STACK STANDARDS


In term of standards, the RNC supports ITU SS7 standards, but also ANSI SS7
standards (for North American operators).

The following stacks are supported:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 119/223


UMTS RNC Product Engineering Information

ITU-T ANSI

SCCP (Q.711-Q.716) SCCP (T1.112)


Layers with some
differences between the MTP3-B (Q.2210) MTP3-B (T1.111)
different standards
SSCF-NNI (Q.2140) SSCF-NNI (T1.645)

SSCOP (Q.2210) SSCOP (T1.637)


Similar layers in the AAL5 (I.363.5) AAL5 (T1.635)
different standards
ATM (I.361) ATM (T1.627)

Layer with some


differences between the PHYSICAL LAYER PHYSICAL LAYER
(I.432, STM1) (T1.105, OC3c)
different standards

It has to be noticed that the RNC may support at the same time a combination of SS7
interfaces using different standards. The following table provides the SS7 standard
supported by RNC depending on the different interfaces:

ITU ANSI ITU & ANSI

Iur Yes Yes Yes

IuPS Yes Yes No

IuCS Yes No No

Table 5.5-2: SS7 stack matrix

Note that (in UA06.0) IuPS traffic using ANSI SS7 stack is only supported over ATM.

Thus a configuration as the one presented as an example below is possible:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 120/223


UMTS RNC Product Engineering Information

Figure 5.5-15: Example of a RNC using different SS7 protocol stacks

The selection of the SS7 standard type is specified with the attributes protocolVariant
attribute of the Linkset (Ls), Routeset (Rs) and Destination Signaling Point (DestSP)
components. Depending on the SS7 standard some timers need to be adjusted in
component Ls (values for timers localInhibitTestTimer and remoteInhibitTestTimer )
and also eventually in components Mtp3 and Sccp.

5.5.5.2 RNC SS7 DUAL STACK


The feature available from UA6.0 for North America market is now available for global
market in UA07.1.

Therefore the objective of this feature is to:

Secure the delivery of ANSI SS7 variant on IuPS and Iur

Support dual stack SS7 ANSI and ITU on Iur.

See table above for available stack for each interface.

5.5.5.3 RNC SS7 STACK INTERNAL ARCHITECTURE


SS7 stack is used for the transport of most of UMTS Control Plane. Please refer to
interfaces description for more information on this.

This stack is split among the RNC miscellaneous modules as follows:

TMUs manage RANAP, RNSAP and ALCAP

PSFP PMC NIs manage SCCP and MTP3b layers

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 121/223


UMTS RNC Product Engineering Information

PSFP PDCs, the ones associated with PSFP with PMC-NIs excepted,
manage SSCF-NNI and SCCOP layers in a load sharing mode

16pOC3/STM1s manage AAL5/ATM/Physical layers.

5.5.5.4 RNC SS7 STACK SUPPORTED ARCHITECTURE

Rule: RNC SS7 Point Code Format (M)

In the case where the RNC is using one unique SS7 stack type (ITU-T) then the RNC
uses the same Point Code for all interfaces using SS7 (SCCP and ALCAP).

If the RNC uses two different SS7 stacks then the RNC uses two different points
codes one for the ITU-T SS7 stack usage and one for the ANSI SS7 stack usage.

The Point Codes format are limited to


- 14 bits for ITU standard

- 24 bits for ANSI standard

Decimal notation only is supported.

Rule 5.5-2: SS7 Point Code Format

Restriction: RNC SS7 Point Code Values(S)

Point Code 0 (zero) is not supported on RNC.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 122/223


UMTS RNC Product Engineering Information

From a pure SS7 topology perspective, following ones are supported by RNC:
For all actual releases:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 123/223


UMTS RNC Product Engineering Information

Figure 5.5-16: RNC supported SS7 Topologies

It is important to note that into all supported topologies presented above, the RNC acts
as a leaf node for SS7, it is an end point that is the source and sink of SS7 messages.
So RNC cannot act as STP for other SS7 entities.

A RNC can support on the different concerned interfaces one of the above topology or
a variety of them.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 124/223


UMTS RNC Product Engineering Information

5.5.5.5 RNC SS7 LOAD-SHARING MECHANISMS


The load sharing mechanism is made first at Route level using the priority information
then at Link level according the SLS field value.
Please refer to Iu TEG [Ext_Eng_004] for more information on this mechanism.

5.5.6 RNC QAAL2 SYSTEM ARCHITECTURE


For the releases older then UA06.0, refer to the Product Engineering documentation
on livelink:

Please refer to Iu TEG [Ext_Eng_004] for more information on this feature.


Note that the RNC is identified by one and only one A2EA 40 Hex Address.
Embedded E.164 address format is supported.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 125/223


UMTS RNC Product Engineering Information

5.6. RNC IP TRANSPORT FEATURES


Nota: The features described below are deliverable for the UA08.1 release

5.6.1 IP UTRAN PATH DIVERSITY SUPPORT ON 9370 RNC

FEATURE DESCRIPTION

This feature introduces path diversity between the 9370 RNC and the routers in front of the
RNC for the signalling traffic on the IuCS, IuPS and IuR interfaces. The signalling traffic is split
on different paths in order to preserve a part of the signalling traffic during the recovery time of
the failed path in case of adjacent router failure or a failure of a L2 switch and/or link between
the RNC and the adjacent router. The different paths can still be protected by the existing
ICMP detection or BFD mechanism.
With this feature, introduced in UA08.1 release, only the half of the signalling traffic is
impacted on IuCS, IuPS and IuR interfaces in case of adjacent router failure or a L2 switch
and/or link failure between the RNC and the adjacent router. In prior releases, there would be
a 100% signalling outage for the duration of the failure.

VALUE

Increase of resiliency on IuCS/IuPS interfaces for control plane

Only 50% of the signalling traffic is impacted in case of Next Hop Router (NHR) failure (it was
100% in prior releases)

Half of SCTP associations remain available to support the whole CP traffic

GENERAL VIEW

CS
Core
RNC
Gige NH
Card Router

PS
VR PDR Core
IP Network

Gige NH
Card Router RNC

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 126/223


UMTS RNC Product Engineering Information

EGRESS P ATH DIVERSITY

9370 RNC NH1 Routing


Path 1
10.1.1.1
PDC2 Router 20.1.1.1
SCTP A Router
10.1.1.2 EP1 C 3G-MSC
3G-MSC
GigE1
PDC3 ESC 1 WSS7 1
SCTP SCTP M3UA
NI(a) EP2 IP Network EP1

M3UA
PDC6 VR1 WSS7 2
ESC 2
SCTP SCTP
M3UA
EP3 EP2

11.1.1.1 GigE2
PDC7 Router
SCTP D 21.1.1.1
EP4
11.1.1.2 Router Routing
NH2 B Path 2

By configuring more specific routes, the Control traffic can be sent from the RNC over two
distinct Gige interfaces and routing paths.

The diverse paths (with same NHs (Next Hop) as PDR NHs) are protected under the PDR
(Protected Default Route) framework.

INGRESS PATH DIVERSITY

9370 RNC Subnet 1


10.1.1.1
PDC2 Router 20.1.1.1
SCTP A Router
10.1.1.2 EP1 C 3G-MSC
GigE1
PDC3 ESC 1 WSS7 1
SCTP SCTP M3UA
NI(a) EP2 IP Network EP1

M3UA
PDC6 VR1 WSS7 2
ESC 2
SCTP SCTP
M3UA
EP3 EP2

11.1.1.1 GigE2
PDC7 Router
SCTP D 21.1.1.1
EP4
11.1.1.2 Router
SubnetB 2

By partitioning the SCTP end points under two logical subnets, it is possible to route
from the MSC using two independent paths.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 127/223


UMTS RNC Product Engineering Information

Each subnet on the RNC allows for 5 usable IP addresses, where each IP@ can be
associated with a SCTP End Point. (8 SCTP End Points in 10 DCPS RNC
configurations)

For more information about this feature, please refer to your support center.

5.6.2 SCTP MULTI HOMING ON 9370 RNC

OVERVIEW

This feature deliver for UA08.1 release is dependant of the feature IP UTRAN Path
Diversity Support on 9370 RNC described on the precedent chapter.

SCTP (Stream Control Transmission Protocol) is a reliable transmission protocol. SCTP


operates on top of a connectionless packet network service (such as IP) and has been
designed to transport PSTN signalling messages over IP networks.

SCTP is used as control plane layer for all IPUTRAN interfaces (IP-IuB, IP-IuR, IP-IuPS
and IP-IuCS).

When multi-homing is supported on the RNC and Core Network/neighboring RNC, each
association is protected by having two IP address (two paths) to reach the remote SCTP
end point.

In this configuration, multi-homing offers protection against prolong outage in the IP


network.

Under SCTP control, when a transmitted packet is not acknowledge by the remote end
(within T3 timer), the same packet is retransmitted to the same SCTP end point using the
alternate destination IP address (alternate Path).

Choosing the IP addresses of each multi-homed end point on different subnets ensures
that the packets traverse the network over a different routing path.

FEATURE VALUE

Zero loss of signalling traffic in case of IP path failure when this feature is associated with
Path Diversity (in prior releases, there would be a 100% signalling outage for the duration of
the failure or 50% outage with path diversity only).

Rule: RNC SCTP MULTI HOMING

SCTP Multi-homing & Path Diversity --> No SCTP Traffic Outage

--> SCTP retransmit on alternate transmission path minimizes impact

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 128/223


UMTS RNC Product Engineering Information

9370 RNC MSC/SGSN/


RNC
IP@1 IP@3
SCTP IP Network SCTP
Multi Multi
Homing IP@2 IP@4 Homing

Normal Operation SCTP Multi-homing; uses


different Next Hope Router for each path

9370 RNC MSC/SGSN/


RNC
IP@1 IP@3
SCTP IP Network SCTP
Multi Multi
Homing IP@2 IP@4 Homing

During IP Network failure; no SCTP outage,


as SCTP messages are sent on alternate path

IP TRANSPORT FAILURE CONDITION

When a failure occurs in the IP transport network, SCTP automatically retransmits any
packets for which it did not receive an acknowledgement.

The retransmitted packet is sent to the alternate IP address of the same association.

For more knowing about this feature, please refer to your support center.

5.6.3 IP UTRAN BIDIRECTIONAL FORWARDING DETECTION (BFD)

OVERVIEW

This feature deliver on UA08.1 release enhances the RNC 9370 carrier grade capability by
reducing local fault detection times using a standardized technique.

Bidirectional Forwarding Detection (BFD):

Provide for L3 failure detection between RNC and adjacent Router;

Supported on IuB, IuCS, IuPS & IuR CP/UP;

No Capacity Degradation (< 0.005% BW)

Integrated with PDR framework; 1 BFD Session per PDR NH.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 129/223


UMTS RNC Product Engineering Information

FEATURE VALUE

Reduce L3 failure detection time; in sub-second range (recovery < 1 second);

9370 RNC IMPLEMENTATION

Rule: RNC ICMP Heartbeat & BFD

ICMP Heartbeat / BFD can coexist on RNC;

Both can not be active under same VR (same Protected Default Route, 0.0.0.0)

Rule: RNC Interfaces

4pGe Ethernet interfaces (Not supported on ATM interfaces (e.g. IuPS/ATM-


AAL5/Sonet) or other FPs

Rule: RNC Routes

Supported on the static default routes (0.0.0.0 route); not supported on other routing
protocols or over other best match routes; The RNC supports up to 48 BFD sessions
(12 VRs with 4 NHs per PDR).

Rule: RNC ADMINDOWN state

BFD session can be administratively locked per NH (In this state the BFD session is
considered permanently down and the NH monitored by this session is removed from
list of active NHs under the route)

Rule: RNC Connectivity

Protected path can be at the port level or VLAN

LAG is supported

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 130/223


UMTS RNC Product Engineering Information

RNC BFD FIGURE

RNC BFD Session 1

CP
GigE1
IP Network
PDR
VR

GigE2

BFD Session 2

Protected Default Route (PDR)


0000 NH1 metric 10 PDR active path
NH2 metric 20 PDR alternate path

For more knowing on this feature please refer to your support center.

5.6.4 LAG SUPPORT ON 9370 RNC


This feature deliver on UA08.1 release uses the link aggregation feature already
present on the 4pGE FP. The work involved is to ensure the LAG implementation
satisfies the requirements, it can be enabled on a 9370, and it interworks with the
RNC features.

Link aggregation on the RNC 9370 facilitates the aggregation of a set of Ethernet
ports (up to 4 on a single GE FP) allowing a MAC client to treat the set of ports as a
single port. Figure 5.6-1 shows the positioning of LAG sublayer in the CSMA/CD Layer
architecture, and the relationship of that architecture to the Data Link and Physical
Layers of the OSI Reference model. The figure also shows the ability of LAG sublayer
to combine several individual links into a single MAC interface to the MAC client.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 131/223


UMTS RNC Product Engineering Information

Figure 5.6-1: Architectural positioning of LAG sublayer

5.6.4.1 KEY BENEFIT

Additional bandwidth, for cases where a single (1 Gbps) GigE link bandwidth is
insufficient

Additional Link Resiliency for links between the RNC and adjacent router

Supported on Iub, IuCS, IuPS,IuR, IuBC and IuPC. Major gain for Iub and IuPS when
traffic exceeds 1 Gbps data-centric call profiles.

5.6.4.2 LOAD BALANCING ON RNC


LAG balances the utilization of the LAG Links by moving some flows (FlowIds) from the
most utilized LAG Link to the least utilized one.

LAG supports the concept of load balancing without the necessity for buffering or re-
sequencing at the receiving end. LAG transmits all packets under an IP flow on the same
physical link to prevent mis-sequencing at the receiving end.

Load Rebalancing is triggered when:

The LAG Link utilization of at least one LAG link reaches 70% (not configurable)

Difference greater than 15% utilization (not configurable) of one LAG link over another
in the same LAG group.
For example: assume Link0 is 80% utilized and Link1 is 60% utilized. In this case,
link balancing moves some of the FlowIds from Link0 to Link1.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 132/223


UMTS RNC Product Engineering Information

5.6.4.3 LAG CAPACITY AND THROUGHPUT

There are 4 ports on one GigaEthernet board and the maximum bandwidth is 2.5
Gigabits.

Number of Available BW
Ports (Gbps)

1 1

2 2

3 2.5

4 2.5

LAG is an optional feature that can be enabled if one or more GE interfaces


approach the 1 Gbps limit of a link.
The recommendation is to enable LAG if the link utilization is 70% or above.

5.6.4.4 CONFIGURE LAG ON RNC WITH PDR PRESENT

LAG is enabled on a system where PDR is already present. After successful


provisioning of LAG, traffic is routed over the newly created LAG group.

PDR is enabled and traffic carried over both GE cards.


Please find below a basic functional description

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 133/223


UMTS RNC Product Engineering Information

Figure 5.6-2: Functional Description

5.6.4.5 LAG GROUP RESILIENCY

Two configurations could be proposed:

1. Resiliency within a LAG Group Link protection with the LAG group)

LAG offers link protection by revising the traffic flows of the disabled link
to other available links in the LAG group.

In RNC, the impact on traffic trough the LAG group due to a link failure is
less than 500 ms
LACP monitors the state of the link and Marker/Marker response
Protocol redistributes the IP flows to the remaining links.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 134/223


UMTS RNC Product Engineering Information

AC AC 3
2

D L 3 2 1 D 3

1
1
L 3 2 1 2
2
C C 1
3
1
2
3

MAC Client MAC Client

AC Agg. Control
L LACP PDU
D Distributor
MAC Client PDU
C Collector

2. Resiliency between 2 LAG groups (Link protection by switching between


2 LAG groups)

For each LAG group, the minimum number of links that must be active
for the LAG to remain operational is specified by the minActiveLinks
attribute

If the number of active links goes below the value set in the
minActiveLinks attribute, the LAG group becomes disabled, and the flow
is swicthed to a valid LAG located on the second 4pGiGE card

Nota: For more knowing about this feature please refer to your support center

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 135/223


UMTS RNC Product Engineering Information

5.7. RNC FUNCTIONS

5.7.1 RNC RELIABILITY


RNC reliability can be summarized as follows:

LS = Load Shared HS = Hot Standby BP = Backplane PS1 = PSFP Packet Server DCPS = 2nd Packet Server
generation.
Figure 5.7-1: RNC reliability diagram

5.7.2 RNC UPGRADE TARGETS

The UA8.1 targets for scheduled and unscheduled outages are summarized on the
table below:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 136/223


UMTS RNC Product Engineering Information

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 137/223


UMTS RNC Product Engineering Information

5.7.3 REDUNDANCY DEFINITION


Type of redundancy offered depends on implementation, they can be:

Hot Redundancy or Hot Spared. This refers to standby modules receiving


dynamic information from the active ones as well as having already loaded
configuration data. As such in case of failure or switchover standby one can
take over the previously active one without interruption.

Warm Redundancy. This refers to standby modules receiving some of


dynamic information from the active ones as well as having already loaded
configuration data. Nevertheless some applications may need to restart to
take over in case of failure or switchover. As such there is an impact on
service even if limited.

Cold Standby: This implies that configuration data are loaded but that dynamic
information is not received by the standby. This implies service outage in case
of failure or switchover.

Load Sharing: This refers to a context where all modules are active and share
the load, each of them having an extra capacity available reserved. In case of
failure, they can distribute among them the load of the failed module to still
offer the same capacity.

5.7.4 RNC SPARING MODEL


With the 9370 RNC, the PMC-M, NIs and OMU are 1:1 hot spared.

RAB APs are spared in a load sharing mode in the sense that when one AP fails, the
work load on the failed AP is carried over by multiple APs.

For ATM traffic, PC APs are also spared in a load sharing mode.

TMU APs are spared N:M depending on the number of PS modules and for IP traffic
PCs are spared N:1.

More descriptions on sparing activities are given in the following sections.

5.7.4.1 PMC-M SPARING


The PMC-M is not directly involved in user data traffic, neither C-plane nor U-plane,

However it manages and controls RNC applications and resources used by these
applications. The PMC-M is 1:1 hot spared in the sense that the standby PMC-M is
dynamically synchronized with the active PMC-M, and when the active PMC-M fails,
the standby PMC-M takes over immediately the activity without any service impact.
The major components running on PMC-M are resource manager (RMAN), transport
bearer manager (TBM), connection service manger (CSM) and CNAccess. Packet

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 138/223


UMTS RNC Product Engineering Information

Server Journaling framework (PS JFK) is used by some software components on


PMC-M for data synchronization between the active and standby components.

TBM/Rman manages CID allocation, cell logical group on RABs, Cell and UE call IDs,
and manages its own database. All the information in the database is journalled to the
standby using PS JFK except UE call IDs which are journalled through PSE
messages.

For ATM based transport, TBM manages AAL2 data path binding for U-plane traffic on
Iub, Iu and Iur interfaces. Binding here means to connect ATM traffic coming in from
an ATM interface card to a particular AP. TBM path binding involves software running
on the ATM card, i.e. IuxIf, connection service software on the PDC of the PSFP card
with the AP, and TBM software running on PMC-M. After path binding, AAL2 traffic
gets terminated on PCs.

Every path is hot spared by two PCs with the sparing taking over the traffic
immediately should the PC with the active path fails.

Note that the same applies to the ATM card.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 139/223


UMTS RNC Product Engineering Information

PC-1 PC-2 PC-3

LPS1-A LPS2-A LPS3-A

PMCM Path Binding Iub/Aal2If Iucs/Aal2If Iur/Aal2If


(TBM)
ATM Interface Card (Active)

IuxIf
Iub/aal2If

Core
Node B Network Drift RNC

Figure 5.7-2: AAL-2 Path Binding

5.7.4.2 PC AND PATH SPARING


In ATM based transport, the concept of Logical Path Set (LPS) is used for path
sparing on PCs for link redundancy. An LPS is a collection of paths or ATM
connections. Each LPS is spared as a unit. Paths are grouped into interfaces which
are used for Iucs, Iur and Iub.

Each interface is known as an Aal2If. For sparing purposes, paths are grouped into
LPSes, each of which has an active PC and a standby PC. An entire LPS is switched
over at once when the active PC fails. The LPS load rebalancing algorithm ensures
active and standby LPSes are evenly distributed across the system and the active
LPSes on a PC are evenly distributed to the rest of PCs in the pool should the PC fail.
Figure 5.7-3 shows a simplified view of how LPSes are distributed in the pool of 8
PCs. In this diagram, PC1 is serving as an active role for LPS1, LPS9, LPS17, and
LPS25, at the same time its serving as a standby role for LPS5, LPS6, LPS7 and
LPS8. The same applies to other PCs.

As indicated in the following figure, while each LPS or each path is 1:1 spared, PCs
are spared in load sharing mode in the sense that each PC hosts active LPSes. Traffic
on a failed PC is redirected to other PCs.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 140/223


UMTS RNC Product Engineering Information

Modules of engineering deep interest have the following redundancy into RNC
context:

16pOC3/STM1 offers 1+1 Hot redundancy through EP and APS

o Individual port switchover OR board switchover which would imply all


ports switchover as well

Figure 5.7-3: Path Sparing on PC


When a PC failure is detected by the maintenance software, IuxIf and TBM are
notified of the failure and then the traffic from the ATM side is redirected to the
standby paths on another PC. Similarly, when the active ATM card fails, traffic is
switched automatically to the previous standby ATM card thanks to Multiservice
Switch 15000 APS (Automatic Protection Switching) technology.

Figure 5.7.4 PC Swact shows an example of path activity switchover event. PC-1 is
the PC that hosts an active LPS and PC-2 hosts the corresponding standby LPS.
When PC-1 fails,TBM needs to request IuxIF on the ATM cards to bind with PC-2 and
trigger connection service agent on the PSFP PDC to switch the PC activity state for
the LPS affected.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 141/223


UMTS RNC Product Engineering Information

Figure 5.7-4: PC Swact

Figure 5.7.5 ATM Card Swact shows an example of ATM card swact. When ATM
card switches over, TBM/IuxIf is also responsible to re-bind paths with the newly
active ATM card.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 142/223


UMTS RNC Product Engineering Information

Figure 5.7-5: ATM Card Swact

5.7.4.3 RAB AND CELL LOGICAL GROUP SPARING

RABs provide cell U-plane sparing in the concept of a logical group. Each RAB could
contain multiple logical groups and each logical group could have multiple cells. Each
logical group is spared on another RAB which resides on a different PSFP card.
Information between the active logical group and the standby logical group is
journalled through PS JFK.

RABs connect to PCs through AAL5 virtual sockets. . As shown in Figure 5.7.6 RAB
and Path Sparing, for each active logical group, a number of virtual sockets are
created that connect to both the active and standby PC paths. The virtual sockets for
the standby logical group are not created until the switchover happens.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 143/223


UMTS RNC Product Engineering Information

Figure 5.7-6: RAB and Path Sparing


Similar to path sparing on PC, each RAB could contain active and standby logical
groups.

While each logical group is 1:1 spared, RABs are spared in load sharing mode.

Note that UE calls on RAB are not spared. Therefore, while RAB failure has no impact
on cells, calls hosted on the failed RAB are dropped.

5.7.4.4 TMU SPARING FOR CELL C-PLANE


The TMU handles C-plane processing for both cells and calls. While calls are not
spared on TMUs, cells are cold spared on TMU in N:M sparing mode. For every 7 or
less active TMUs, there is one standby TMU assigned. For a 12 PSFP card system
with 14 TMUs, there are maximum two sparing TMUs. All centralized or static MIB
data is delivered to active and standby TMUs. When one active TMU fails, the standby
TMU takes over the activity and recreates the cells based on existing information.
TMUs are cold spared and cell re-creation can not be done fast enough to avoid
impact on the NodeBs. The impacted NodeB detects cell outage and deletes the cells.
The cells on the NodeB are re-created once TMU switchover completes. The related
U-plane cell contexts are cleared on the RABs. All of the calls on those cells are
dropped. Note that an audit between NodeB and newly active TMU happens after
swact to ensure the data consistency between the NodeB and the TMU.

Similar to AAL2 data path binding done by TBM and IuxIF, Iub Access component on
TMU is also responsible for NBAP signaling and ALCAP path binding. Note that unlike
PC path sparing, paths to standby TMUs are created only after the swact.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 144/223


UMTS RNC Product Engineering Information

In UA7 the maximum number of TMU on each DCPS/PSFP card is 2, with flex
TMU/RAB assignment feature in UA08.1, this number can be 3, when any DCPS card
is assigned 3 TMU, 3 standby TMU are required.

5.7.4.5 NI AND PDC SPARING FOR SS7 STACK


Figure 5.7-7 SS7 Stack Distribution shows the distribution of SS7 software
components in RNC. M3UA and SCTP layers are newly introduced in UA06 for IP
UTRAN. SCCP layer is common for ATM and IP transport. As shown in Figure 5.7-7
SS7 Stack Distribution, NI hosts SCCP and MTP3/M3UA layers. The SAAL-NNI or
SCTP layer is hosted by PDCs of the PSFP cards that dont have NIs on them.

o No impact on service, cells or UE calls may experience some packet


loss but not dr

Figure 5.7-7: SS7 Stack Distribution


Figure 5.7.8 Sparing Model for SS7 Stack shows a sparing model for SS7 stack. For
ATM based transport, SCCP and MTP3 are 1:1 hot spared on the active and standby
NIs. Hot sparing here means when NI switchover happens, there is no service impact
on existing calls. PS JFK is used to journal data between the active and the standby.
SAAL-NNI (SSCFNNI and SSCOP) is spared on PDCs of PSFPs which do not host
any NIs. PDCs are spared in load sharing mode for SS7 links, each of which is hot
spared on multiple PDCs using the link set concept. When one PDC is down, the
traffic on those links are carried out on the rest of PDCs.

For IP UTRAN, M3UA is 1:1 hot spared on NIs and the stack is journalled to the
standby side. SCTP is installed on all PDCs except those on PSFPs with NIs. Each of
those PDCs has an external IP address. Therefore, there are 8 or 10 external IP
addresses on a fully configured system as SCTP termination points. Associations on a
given PDC are distinguished by port numbers. Multiple associations are set up to a
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 145/223


UMTS RNC Product Engineering Information

given SS7 point code over different PDCs to achieve the equivalent link redundancy
as ATM transport layer. Each PDC also terminates multiple associations for different
DPC codes. M3UA stack is connected to multiple SCTP associations on different
PDCs and reacts to the loss of an association by redistributing the load to that DPC
over the remaining associations.

Figure 5.7-8: Sparing Model for SS7 Stack

5.7.4.6 OC3 SPARING


Both PQC and MS3 OC3 cards provide carrier grade capability which is the same as
in the previous release. In UA6.0, hairpin removal feature is required for capacity
increase. SPVC agent process is added on both active and standby ATM cards and
passport JFK is used to journal SPVC provisioning information and dynamic
information, e.g. SPVCID, PMCID and their state changes. The functionality of the
existing IuxIf processes on ATM cards is expanded to provide path binding for SPVCs
similarly as what is done for PVCs.

5.7.4.7 CP SPARING
In UA07 Base layer CP sparing functionality remains the same, i.e. hot CP equipment
protection is enabled.

Introduction of CP4:

CP4 sparing is essentially the same as CP3 sparing with the improvement of reliability
and performance. Compared with CP3, the reliability of CP4 is improved through the
following:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 146/223


UMTS RNC Product Engineering Information

New disk vendor with higher reliability numbers in the product specification
Improved hardware reliability via EMEM parity checking

Improved hardware reliability via CRC on data transfers across ATA bus

Improved hardware reliability via the use of ECC on DDR main memory.
Compared with CP3, CP4 also offers better performance:

Disk speed is increased from 4200 RPM to 7200 RPM

Memory space is increased from 256M to 512M for the first UA06 release. The
hardware is capable of 2G.

CP4 is a faster processor with processing speed increased 1.25 to 2.0 times
compare with CP3.

5.7.5 IP UTRAN CARRIER GRADE AND SPARING MODEL


To provide RNC with a similar redundant model as for ATM UTRAN, IP UTRAN uses
the following strategy for IP interface connections to the external nodes:

Static protected IP routes are used for sparing at IP/L3 layer on GE cards to protect

RNC from interface card/link failures and in some circumstances router failures.

On the C-Plane, multiple associations can be used for failure protections:

Protecting from RNC component failures. When one component in RNC fails

the association on the component is lost, another association on a spared component


can be chosen by M3UA protocol so that traffic can continue to flow.

Sparing through associations can be implemented in load sharing mode or 1:1 spared
mode.

Protecting network router failures. Associations with IP addresses on different


subnet can be used to protect RNC from router failures in the IP network
between RNC and Core Network or NodeB.

TBM does path/LG balancing similarly as in ATM UTRAN. However, TBM is not
involved in data path binding since local media is responsible for setting up the data
path. This is also true for PC failure handling.

To support the above mentioned carrier grade strategy, the sparing model for IP
UTRAN has been changed in the following aspects:

GE cards are spared in load sharing mode

New protocol stacks for IP transport are added on NI, TMU and PDC to be spared

C-Plan traffic to core network is protected by multiple associations on PDC which are
spared in load sharing mode and managed by 1:1 hot spared M3Ua on NIs.

NAT functionality is added on the PC APCs

In the following, the changes in the sparing model are examined in details.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 147/223


UMTS RNC Product Engineering Information

5.7.5.1 PROTECTED IP ROUTES ON 4PGE CARD FOR IP


TRANSPORT SPARING
The feature Protected IP Routes for 4pGe Card introduces Protected IP Routes as
a mechanism for sparing at the IP/L3 layer in order to provide carrier grade (<1 sec
switchover time) support for the 4pGe FP in an IP scenario. A protected route is
defined as an IP route with a set of 2 or more next Hops, each of which uses a unique
local IP address that can be used to forward the IP packet. The operational state of
these next Hops or interfaces of the protected routes are monitored, and the
forwarding information is optimally managed to enable route reprogramming within 1
second in the case of an active next Hop/interface failure. For full coverage, i.e. line
protection and card protection, the adjacent router needs to use static routing towards
the GE cards to maintain IP data flow when failures happen.

Figure 5.7.9: Protected Static IP Routes shows the configuration for protected IP
routes between GE cards and the IP network. GE cards are running in load sharing
sparing mode in the sense that both cards carry IP traffic. When one GE card fails, all
traffic is carried by the other GE card. Similarly, if one next Hop Router fails, all IP
traffic goes through the other next Hop router.

Figure 5.7-9: Protected Static IP routes


In summary, the above system configuration provides the following failure protections:

When one GE card fails, the IP traffic on the failed GE card is re-directed to the other
GE card within 1 second. This applies to both ingress and egress paths.
When ports/links on a GE card fail, the IP traffic on those ports/links is redirected to
the other ports/links on another card within 1 second. This applies to both ingress and
egress paths.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 148/223


UMTS RNC Product Engineering Information

If one of the next Hop routers fails and the routers are using static routes, the IP
traffic on the failed next Hop router is re-directed to the other router within 1 second
thanks to L3 heartbeat mechanism. This applies to both ingress and egress paths.

5.7.5.2 NI AND PDC SPARING FOR C-PLANE TRAFFIC ON IU/IUR


Similar to MTP3 for ATM UTRAN, M3UA is 1:1 hot spared on NIs and the stack is
journalled to the standby side. SCTP is installed on all PDCs except those on PSFPs
with NIs. Each of those PDCs has an external IP address. Therefore, there are 8 or 10
external IP addresses on a fully configured system as SCTP termination points.
Associations on a given PDC are distinguished by port numbers. Multiple associations
are set up to a given SS7 point code over different PDCs to achieve the equivalent link
redundancy as ATM transport layer. Each PDC also terminates multiple associations
for different DPC codes. M3UA stack is connected to multiple SCTP associations on
different PDCs and reacts to the loss of an association by redistributing the load to
that DPC over the remaining associations.

Protecting from RNC component failures

As shown in Figure 5.7.8 Sparing Model for SS7 Stack, M3UA on NI does
routing, load balancing and redundancy management and congestion control
for SCTP links. M3UA is hot spared on NI. When the active NI fails, the
standby NI takes over activity in less than a second of time. There is no
impact on existing calls when NI switchover happens.

SCTP associations are provisioned on PDCs of the PSFP cards without NIs.

The SCTP links on PDCs operate in a load sharing sparing mode managed by M3UA
running on the active NI. To protect system from PDC failure, SCTP endpoint IP
addresses need to be provisioned such that associations to the same Core Network
appear on different PDCs.

Protecting network router failures.

Associations with IP addresses on different subnet can be used to protect


RNC from router failures in the IP network between RNC and Core Network.

The RNC is protected from different RNC component failures as well as adjacent
router failure: Figure 5.7.10 IP IuPS C-Plane Path Redundancy between the RNC and
a Core Network. In the case of multiple IP networks between the RNC and the Core
Network, multiple associations can be provisioned with IP addresses on different IP
networks. In this figure only one redundant path is shown. RNC supports multiple path
redundancy by provisioning multiple associations between the RNC and the Core
Network.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 149/223


UMTS RNC Product Engineering Information

Figure 5.7-10: IP IuPS C-Plane Path Redundancy between the RNC and a Core Network

As to the service recovery time requirements, M3UA layer is hot spared and meets the
equivalent service recovery budget as for MTP3 layer. Similarly, SCTP layer is spared
in load sharing mode and meets the equivalent service recovery budget as for
SAALNNI layer.

5.7.5.3 PC SPARING FOR U-PLANE TRAFFIC ON IUB


Unlike PC path sparing in ATM based transport where paths are 1:1 spared and PCs
are running in load sharing mode, Figure 5.7.11 shows a simplified version of N:1 PC

Network Address Translation (NAT) sparing model where N equals to 2. In the figure,
there are 2 active PCs, each of which has an external visible IP address. The single
standby PC has no external IP address. TBM is responsible for assigning IP
addresses to the active PCs as well as the mapping between a range of UDP ports to
UE logical groups on RABs. A U-plane VR is added for this type of traffic and local
media software connects data path from the GE card to the active PCs. Each PC
builds a port forwarder table based on the mapping to send up link traffic it receives to
the proper RABs. For down link traffic, a new type of VSocket needs to be created to
send UDP packets from RAB to NodeB IP/UDP address through the PC where the
RAB receives traffic from. As shown in the figure, when the active PC1-A crashes, the
standby PC is assigned with the external IP address e@-1 and updated by TBM with
the port forwarder table. The traffic is re-routed to PC3-S and the RABs based on the
port forwarder table. Note that the lines between the PCs and the RABs in the figure
represent the mapping relationship. The real connections are through vSockets which
will be created when calls are set up and torn down when the calls are released. The
switchover between the active PC and the standby PC is fast enough not to impact the
existing calls serviced on the RABs.
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 150/223


UMTS RNC Product Engineering Information

Figure 5.7-11: PC NAT Functionality for N:1 Sparing


IP data path failures between the RNC and the connected NodeBs can be detected by
data path heartbeat mechanism within 5 seconds after a certain number of re-tries fail.

Heartbeat UDP packets are sent from TMUs to the NodeBs and returned back to
TMUs through PCs. Once the failure is detected, an alarm is raised on the NodeB and
this triggers the state change of the FddCells on the NodeB. All the calls associated
are released.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 151/223


UMTS RNC Product Engineering Information

5.7.6 RNC MODULES REDUNDANCY SUMMARY

Figure 5.7-12: RNC modules redundancy summary

5.7.7 RNC OVERLOAD


RNC Overload mechanism is described into external document [Ext_R&D_018].
Associated parameters are presented in document [Ext_Eng_001]. It is also possible
to automatically activate some class barring orders in case of RNC Overload
situations. For more information please refer to Automatic Cell/Class barring
description in document [Ext_Eng_001].

5.7.8 OTHER RNC SPARING FUNCTIONS

5.7.8.1 APS USAGE


APS usage on the external ports of the RNC allows to benefit from line redundancy
(between working line and protected line) and port redundancy (between the active
and stand-by boards). APS and EP (Equipment protection between active and stand-
by 16pOC3STM1 boards) provide thus a high level of availability for external
connectivity of the RNC.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 152/223


UMTS RNC Product Engineering Information

For more information about APS principles and associated parameters please refer to
Iub TEG document.

5.7.8.2 Y-SPLITTER
Reminder: Y-Splitter protection feature is available as a standard MSS feature for 16
ports OC3/STM1 ATM/POS FP (NTHW48 and previous NTHW44 MSS board not
proposed in RNC context). Nevertheless its extension to 16 ports OC3/STM1 ATM FP
(both NTHW21 and NTHW31) has been specifically introduced in UA04.2 for the RNC
and is not available for 16p OC3/STM1 ATM FP used within a Network Element
running software other than the RNC one.

Important Warning: Y-Splitter required for this configuration is not productized and as
a matter of fact not orderable from Alcatel-Lucent. They need to be ordered through a
third party vendor.

For information, Y-splitter characteristics overview is:

At the FP ends of the cable (RNC side) small form LC connectors shall be
used. At the single end of the cable (opposite to RNC side) the connectors are
determined by whatever type of optical interface is needed on the far end.

Mixing Single Mode and multimode (MM) at opposite side of a connection is


not supported

If MM is needed at far end

o Total distance of the path has to be less than 100m (328ft)

o An appropriate attenuator has to be used


The Y-splitter must provide an equal split of the optical signal, where each
split signal meets or exceeds physical layer requirement for Intermediate
Reach (IR) under Telcordia GR253. The legs of the cable after the split must
be in equal length.

The position of the coupler on each cable relative to each three ends of the
cable is critical for having effective cable management. The length of each
installed cable, especially between the port on the installed FP and along the
absolute cable path up to the nearest cable management bracket, has to be
planned so that this coupler:

o will not reside under an FP hood or anywhere across the front of the
shelf

o will not reside in a drawer of the fiber management unit

o Resides on the side of the NEBS2000 frame or equivalent mounting


apparatus, or beyond, but not through or on any of the cable
management brackets.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 153/223


UMTS RNC Product Engineering Information

Y-Splitter feature provides Equipment Protection when APS is not supported by the
far-end equipment or to avoid the expense of a second fiber pair from the far end. This
feature makes uses of an external Y-Splitter cable to passively split (on ingress) and
combine (on egress) the optical signals to from two rx/tx fibers on RNC side onto a
single one rx/tx on far-end equipment.

Paired ports protected by APS OR Y-Splitter can be mixed on the same


16pOC3/STM1 board.

This is illustrated into the figure below:

Figure 5.7-13 Y-Splitter

Same constraints as APS apply such as:

Inter-Card protection ONLY is supported (i.e. no intra-cards protection)

Port X of board in slot 2n is Y-Splitter connected with Port X of board in slot


2n+1

BUT unlike APS 1+1:


The selected line is always associated with the Service Active FP for Y-
Protection. Similarly the standby line is always associated with the Service
Standby FP. Also it is important to note that the laser of the port on the
Service Standby FP is switched off in the egress direction to avoid
disturbing the signal from the Service Active FP.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 154/223


UMTS RNC Product Engineering Information

No Line failure is supported. If selected line fails, no line switchover occurs,


only an FP switchover will make the Standby FP to become the Active one
and thus its associated line to become the selected line.

Warning: Since the coupler (splitter) attenuates the signal, optical power budgets will
be impacted by the insertion is a Y-Splitter.

Rule: RNC Y-Splitter Usage (M)

Within the RNC context caution must be taken that Y-Splitter connectors cannot be
used for 16pOC3/STM1 ports involved into:

SPVC/PNNI Hairpins

VPT Shaped Hairpins

Rule 5.7-1: RNC Y-Splitter Usage

It has to be noticed that from UA06, PNNI hairpins are no more needed for the
management of SPVC.

Also it is not recommended to use them:

Connectivity between two 16pOC3/STM1 and MSA32/STM1 (boards located


on an eventual MSS Transport Node set in front of the RNC)

Connectivity between two 16pOC3/STM1 and one 16pOC3/STM1 or


4pOC3/STM1 since those boards support inter-boards APS (boards located
on an eventual MSS Transport Node set in front of the RNC)

So as illustrated below, Y-Splitter offers an intermediate level of redundancy on RNC


connectivity in case APS is not possible.

Figure 5.7-14: RNC Connectivity Reliability levels

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 155/223


UMTS RNC Product Engineering Information

Rule: RNC Radio Connectivity Protection (M)

RNC with no EP and no APS is NOT supported.

Rule 5.7-2: RNC Minimal Interface Redundancy requirements

Warning: RNC reliability figures are provided assuming EP and APS configurations.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 156/223


UMTS RNC Product Engineering Information

5.7.9 RNC NTP


RNC is synchronized in time for alarms, ops files through the Network Time
Protocol. As such it is needed to indicate to RNC with NTP servers it may be
connected to thanks to their IP address.

5.7.10 RNC SYNCHRONIZATION


RNC does not require any external synchronization reference thanks to its internal
clock offering a Stratum 3 ( +/- 4.6 10-6 s) accuracy.

Nevertheless NodeB for the Uu Radio interface needs a Stratum 1 ( +/- 10-11 s)
accuracy, which can come from the RNC. But in this case, RNC needs to itself retrieve
one clock from another source than its internal clock.

In order to get it, RNC has two alternatives:

Externally via dedicated E1/DS1 on BITS module on back of the shelf.

(Each RNC shelf is equipped with an E1 120 ohm balanced BITS/alarm timing
module. If the customer timing source is 75 ohm unbalanced the NTPN81EA
adapter cable is required).

Through Line Synchronization using its external connectivity, itself


synchronized ahead thanks to other sources.

See explanations on the diagram below for the external synchronizations sources

+ For SDH/SONET RNC:

Figure 5.7-15: RNC synchronization sources

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 157/223


UMTS RNC Product Engineering Information

+ For RNC collocated with a MSS7K POC

Figure 5.7-16: RNC with collocated POC synchronization sources

It is possible to define up to 3 sources from primary to tertiary on both the RNC and
POC.

In case primary fails then secondary takes over. Then if primary recovers it takes over
back again.

If none of the sources are available synchronization is taken from the CP internal
clock.

Rule: RNC Synchronization in case of an hybrid ATM and IP configuration (M)

In case of a configuration using interfaces based on ATM and also interfaces based
on IP, Line synchronisation has to be based on ATM links.

Rule: RNC Synchronization in case of full IP configuration (M)

In case of full IP configuration for IuB interface, NodeB will receive directly the
synchronization (External clock, GPS or PTP/1588). So RNC doesnt need any
external clock. Its internal clock offering a Stratum 3 ( +/- 4.6 10-6 s) accuracy ensures
the full functionality of the RNC.

Rule 5.7-3: RNC Synchronization in case of full IP configuration

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 158/223


UMTS RNC Product Engineering Information

5.7.11 RNC OAM SECURITY AND CONFIGURATION MANAGEMENT

5.7.11.1 IPSEC for WMS and RNC OAM Interface


IPSec security associations can be set up to provide confidentiality between the WMS
servers (Main(s) and Performance Servers) and the RNC CP3 and POC CP2 OAM
interfaces. This is not supported on the interface with OMUs associated flows.

Following IPSec key capabilities are supported:

Transport mode

ESP
DES and 3DES for encryption

HMAC-MD5

HMAC-SHA-1

From UA5.0 IKE (Internet Key Exchange) facility is supported between WMS and
RNC.

Network Design: IPSEC-IKE usage (O)

IKE usage is recommended to re-enforce security aspects.

This confidentiality is offered for the following flows:

Ftp

Telnet

FMIP

NTP
Radius

Please refer to [Ext_R&D_019] for further information.

5.7.11.2 Radius Authentication for RNC


RNC implements a Radius client that directs to a centralized Radius sever on the WMS
main server a Radius authentication request, for each authentication request on RNC for
telnet, ftp, FMIP, and local port requests, and for which no local account exists.

For the RNC, a default set of 5 roles (Administrator, Read-Write, Provisioning,


Maintenance and Read-Only) has been defined in this release, within the centralized WMS
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 159/223


UMTS RNC Product Engineering Information

authentication server, and when there is an authentication request received from the RNC,
as part of the Radius response, the appropriate VSA (Vendor Specific Attribute) is sent
back in the Radius response to the RNC, to enable the appropriate authorization for the
specific login.

Please refer to [Ext_R&D_020] for further information

5.7.12 SERVICE GROUP PROVISIONING


The different NodeB managed by a RNC are allocated into logical entities called
Service Groups. A Service Group gathered a set of NodeB and is positioned by the
RNC on a PMC-TMU (Max one Service group per active TMU). Depending on the
occurring events (eventual fault on a PS board, maintenance activities, etc), the
RNC may move a given service group from a given PMC-TMU to another one.

From UA06, the service group to which a given NodeB is allocated can be specified by
the operator (parameter serviceGroupId of NodeB object). It is also possible to know
on which TMU a RNC has set a given service group. Thus with these facilities, it is
now possible to modify the affectation of one NodeB from a given service group to
another one (and thus by consequence from a PMC-TMU to another one). This
possibility may be interesting in order to better balance the load between the PMC-
TMU if needed. It has to be nevertheless noted that the re-affectation of one NodeB
from a Service Group to another one, implies a loss of service on this NodeB.

The number of service group of a RNC is specified by the parameter


numberOfServiceGroups of the RNC object.
Note: the parameter 'serviceGroupId' used over Iub interface is not used, then there is
no need that serviceGroupId specified below matches its equivalent under NodeB

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 160/223


UMTS RNC Product Engineering Information

Rule: RNC Service Group Provisioning (M)

For the parameters serviceGroupId and numberOfServiceGroups the constraints presented in


the following table have to be respected according to the number of PSFP or DCPS in the RNC.
Moreover, the recommended value for the variable numberOfServiceGroups is the Maximum
value of number of service groups

#PSFP or #DCPS in the Maximum value of Possible Range for


RNC numberOfServiceGroups serviceGroupId

4 3 (0..2)

6 5 (0..4)

7 (PSFP case only) 6 (0..5)

8 7 (0..6)

10 10 (0..9)

12 12 (0..11)

12 with Flex TMU/RAB [14, 29] (0, 28)

Rule 5.7-4: RNC Service Group Provisioning

The maximum number of NodeB and cells per service group depends on the HW
configuration of the RNC. The following rules are applicable:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 161/223


UMTS RNC Product Engineering Information

Rule: RNC Number of NodeB per Service Group (M)

The maximum number of NodeB and cells per Service Group are linked to the
hardwareCapability parameter (see section 5.2.2):

hardwareCapability all6mPktServSP allPktServSP2 allPktServSP2FullDim allPktServSP3FullDim2


parameter
(PSFP) (DCPS small (DCPS Big MIB) (DCPS + Flex MIB)
MIB)

Max number of cells 120 120 204 144


per Service Group

Max number of 120 120 200 144


NodeB per Service
Group

Rule 5.7-5: RNC Number of NodeB per Service Group

The goal of this feature is to spread the load (in term of signaling) of all the nodebs
across the active TMUs.

Rule: RNC remote Fdd Cells balancing (M)

For all NodeBs, with umts cell neighbours located on external RNC(s), it is highly recommended,
to balance equally, as far as possible, those nodebs on all the provisioned Service Groups,
according to the number of remote Fdd Cell.

Rule 5.7-6: RNC remote Fdd Cells balancing

5.7.13 HITLESS CAPACITY INCREASE


Now it is possible to increase RNC market model without any service impact. To do
this, after the physical addition of new PSFP or DCPS boards into the RNC shelf
(always with the respect of the number of boards corresponding to supported market
models), it will be necessary to increase the value of the parameter
numberOfServiceGroups in coherence with above table.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 162/223


UMTS RNC Product Engineering Information

It will then be possible to create new NodeB and set them into the new Service
Groups. It will be also then possible to transfer some NodeB from the initial service
groups to the new ones if desired.

For the physical introduction of additional PS boards in the RNC see document
[Ext_I&C_025].

To reduce the number of PS boards in the RNC, the procedure [Ext_I&C_023] has to
be used.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 163/223


UMTS RNC Product Engineering Information

5.8. RNC INTERFACES

5.8.1 RNC RADIO INTERFACE

Rule: RNC Radio Interface Spectrum(M)

RNC supports NodeB working with following carriers/band:

- 2100 Mhz

- 1900 Mhz

- 900 Mhz

- 850 Mhz

- 1700-2100 Mhz.

In dual band configurations, the following combinations are supported:

- 2100 Mhz and 900 Mhz

- 2100 Mhz and 850 Mhz

- 1900 Mhz and 850 Mhz

- 1700-2100 Mhz and 850 Mhz

- 1700-2100 Mhz and 1900 Mhz

In a tri-band configuration, the following combination is supported:

- 1700-2100 MHz, 850 Mhz and 1900 Mhz.

Justification: WMS and UTRAN constraints.

Rule 5.8-1: RNC Carriers support

UA7 Multi-layer Strategy for Tri Frequency deployments includes: Cell


Selection/Reselection in Idle Mode & Connected Mode; iMCRA Multi-Carrier RRC
Connection Allocation; iMCTA Alarm, CAC and Service.

Recommended strategies for Four Frequency deployments are based on Tri


Frequency deployments by adding additional FDD4 carrier with equivalent
topology/strategy as used for FDD2 & FDD3 layers

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 164/223


UMTS RNC Product Engineering Information

Please refer to Engineering TEG or to Network Performance documents


for more information on UTRAN interfaces as well as their detailed
usage and engineering. Intention here is only to give a high level view
of them

5.8.2 RNC PHYSICAL INTERFACES

Alcatel-Lucent RNC provides several external/internal interfaces listed below. Those


are then made available to one or several of the logical interfaces detailed into the
next sections:
+ RS232 (CP cards) as console connection for on-site maintenance purposes.

+ Ethernet (CP cards)

+ STM-1 clear channel (16pOC3/STM1)


+ OC-3 clear channel (16pOC3/STM1)

+ Giga Ethernet (4pGiGE)

In option, additional Transport nodes may provide complementary interfaces:

+ Full or Partial E1

+ IMA

+ STM1 Electrical Channelized

+ STM1 Optical Channelized

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 165/223


UMTS RNC Product Engineering Information

Rule: RNC RNC Physical Interfaces (M)

Alcatel-Lucent SDH/SONET RNC provides OC-3 OR (exclusive) STM-1 interfaces.


In addition, Giga Ethernet interfaces are introduced for some of the logical interfaces.
In UA07.1, all logical interfaces can be supported by 4pGiGE board

Justification: 16 port OC3-STM1 board cannot operate a mix of OC3 and STM1
interfaces

Rule 5.8-2: RNC SDH/SONET optical interfaces support

Reminder: Some other physical interfaces can be provided using Transport Node as
a backhauling solution.

the different physical access may be used for the different logical interfaces as
presented below:

Type Internal/ Iub IuCS IuPS IuR IuPC IuBC OAM


External

Ethernet E or I (1) No No No No No No Yes

OC-3 / STM-1 clear channel E Yes Yes Yes Yes Yes Yes Yes (1)

Giga Ethernet E Yes Yes Yes Yes Yes (2) Yes Yes (1)

Table 5.8-1: RNC Physical interfaces usage by UMTS interfaces

(1) In case of RNC In-Band OAM, OAM Flows are routed internally towards OMUs.

(2) integrated SMLC server is needed in case of a Full IP RNC

Logical Interfaces allowed EXTERNAL physical media sharing in case dedicated


interfaces are not contemplated; this table is for ATM connectivity. For IP, all
logical interface can share the first hope between RNC and first Router (see
virtual router configuration for more details)..

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 166/223


UMTS RNC Product Engineering Information

Iub IuCS IuPS IuR IuPC IuBC OAM

Iub No No No No No No (**)

IuCS No Yes Yes Yes Yes Yes (*)

IuPS No Yes Yes Yes Yes Yes (*)

IuR No Yes Yes Yes Yes Yes (*)

IuPC No Yes Yes Yes Yes Yes (*)

IuBC No Yes Yes Yes Yes Yes (*)

OAM No (**) Yes (*) Yes (*) Yes (*) Yes (*) Yes (*)

Table 5.8-2: RNC UMTS Interfaces Physical Layer Sharing

(*) This is applicable into the OAM In-band Context

(**) Exception made of NodeB/BTS related OAM

5.8.3 IUB INTERFACE

Several configurations are possible on Iub interface toward the NodeB:

- Multi PCM mode,

- IMA mode,

- nE1+ 1 IMA group,


- 2 IMA groups.

These different configurations allow being able to split R99 traffic and HSxPA traffic on
different supports if needed (several configurations are possible for the organization of
R99 DS traffic, R99 NDS traffic, signaling, OAM, HSDPA traffic, HSUPA traffic, HSPA
streaming traffic ). From an RNC perspective, these different IuB topologies are
managed through the help of Iub bandwidth pools.

For ALCAP protocol management between RNC and NodeB a new VCC is introduced
on IuB interface.
Alcatel-Lucent Iub list of rules overview:

Note: Intent below is just to capture the Alcatel-Lucent Iub permitted scope, guidelines
to select the right options as well as properly dimension the interface is under the TEG
scope [Ext_ENG_003].

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 167/223


UMTS RNC Product Engineering Information

Rule: RNC Iub Interface ATM connection requirements (M)

Iub is AT LEAST made of:


+ One ATM VCC connection for OAM Plane

+ One ATM VCC connection for NBAP-d and one for NBAP-c (Control Plane)

+ One ATM VCC connection for ALCAP (Control Plane)


+ One or several ATM VCC connections for User Plane R99, HSDPA and HSUPA
traffics .

Reminder: Please refer to [Ext_ENG_003] for more complete information about


possible VCC configuration and also to [Ext_Eng_006] for HSDPA or HSUPA matters.

Rule: RNC Iub Interface ATM Cells types (M)

Over Iub related ATM cells can be either UNI or NNI. 3GPP recommends UNI.

Rule: RNC Iub Interface ATM connections types (M)

Iub related ATM connections can be:

+ PVC based

+ SPVC based and initiated on RNC side

+ PVP Shaped or Not with VP termination and VCC extraction at RNC level.
Warning: ATM connections types can be mixed for one Iub interface but this is not
recommended exception made of transition phases.

Rule: RNC Iub ATM Service Categories and Traffic Decriptor supports (O)

Following Services Categories and Traffic Descriptors are available for Iub ATM based
connections:
+ UBR, UBR+, rtVBR, nrtVBR and CBR

+ PCR, SCR, MBS, CDVT if applicable to associated Service Category

Rule: RNC Iub Interface ATM Signalling (M)

RNC ATM based Iub Interfaces supports basic, UNI 3.0, UNI 3.1, UNI 4.0 and PNNI
v1.0 interfaces.

Note: MSS (Passport) also supports IISP, AINI, ILMI and Virtual Interfaces but all
those are NOT contemplated and supported into RNC context.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 168/223


UMTS RNC Product Engineering Information

Rule: RNC Iub Interface ATM Adressing (M)

Over Iub RNC supports addresses and prefixes for ATM Forum NSAP formats:

+ E.164

+ Native E.164
+ Data Country Code (DCC)

+ International Code Designator (ICD)

+ MSS (Passport) default NSAP format

Note: As today into RNC context only MSS default adressing is deployed into Alcatel-
Lucent Labs configuration as well as customers configurations as much as Alcatel-
Lucent is aware of.

Rule: RNC Iub Interface AAL2 User Plane Path available Qos (T)

For User Plane AAL2 Paths, RNC supports differentiation of up to 2 (3 if HSDPA or


HSUPA are used) different Qos used for CAC, Path/CID allocation and bandwidth
reservation mechanism.

Following figure presents an overview of Iub AAL2 resources usage in case where all
different types of traffic are present; for more details please refer to Iub TEG.
[Ext_ENG_003]

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 169/223


UMTS RNC Product Engineering Information

Rule: RNC Iub Interface ARP (Address Resolution Protocol) support for IP
over ATM (M)

RNC supports both InvARP and static ARP on Iub for IP over ATM based connections
as per 3GPP statements.

For the management of HSPA traffic over IP in case of Hybrid Iub configuration,
bandwidth pools are also used to allow distributing the different R99 or HSPA traffic over
ATM or IP.

For more information about the management of these bandwidth pools, and for associated
Engineering rules, please refer to Iub TEG [Ext_ENG_003] document.

Following rules are applicable in case of IuB over IP usage (hybrid IuB
configuration)

Rule: RNC IuB over IP traffic segregation (O)

One or several DiffServ Code Points are used for IuB user plane over IP traffic
segregation.

DiffServ allows managing some QoS classes over IP corresponding to a forwarding


treatment (PHB: Per Hop Behavior) though Differentiated Services Code Points (DSCP).

In the context Hybrid IuB, It is recommended to use only traffic classes corresponding to
Assured Forwarding (AF) PHB with values AF1x or Default Forwarding (DF) PHB for HSPA
Interactive Background traffic.

At the RNC side, to manage these priorities some Emission Priority (EP) Queues are used
inside the 4pGiGE boards. AF1x priorities are mapped on EP6 while DF priority is mapped
on EP7 (EP6 and EP7 are the two lowest priorities).

Highest priority values are reserved for future releases where additional types of traffic may
be carried over IP.

For more information please refer to IuB TEG document [Ext_ENG_003] or to


document [Ext_R&D_025].

Note that these information are relative to the IuB traffic flow carried over IP only (HSPA
Interactive Background traffic), the rest of the traffic over IuB shall use the ATM VCC with
associated traffic Class as presented previously in this chapter.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 170/223


UMTS RNC Product Engineering Information

In term of bandwidth management for the case of an hybrid Iub configuration, it is


recommended to use a primary bandwidth pool for the I/B HSPA traffic over IP (associated
to QoS 3) and a shared bandwidth pool for the ATM based traffic (note that in case of
primary bandwidth pool exhaustion, the I/B HSPA traffic will be mapped into this shared
bandwidth pool but with the lowest priority: QoS 3).

See IuB TEG for more information on the subject.

Note that in case of hybrid Iub used in an UTRAN sharing configuration, one IP bandwidth
pool could be used per operator (so up to 4 IP BP in this case) per IuB interface.

IP addressing for hybrid IuB:

For IuB IP flows, IP addresses are affected to PMC-PC boards. As one PMC-PC is a spare
one, the number of IP addresses for IUB flows is equal to the number of PSFP (or DCPS)
boards minus one. In case of Hybrid IuB the maximum supported market model is with 10
PSFP or DCPS. The following table provides the number of IuB IP address per market
model.

From UA07.1, in case of full IP, the maximum supported market model is with 12
PSFP or DCPS

Market model 4 PSFP 6 PSFP 8 PSFP 10 PSFP 12 PSFP


or DCPS or DCPS or DCPS or DCPS or DCPS

Max number of IP address for IuB IP 3 5 7 9 11


User Plane flows (one per active
PMC-PC)

These IP addresses, as the UDP ports, are provided call per call to the NodeB (during
NBAP RL setup exchange).

Concerning Carrier Grade aspect for hybrid IuB, Protected Default Route (PDR)
mechanism may be used. This mechanism defines a static default route with two or
more (up to 4) next hops interfaces used in case of port failure, card failure, etc
impacting the static default route. It is recommended to configure the Protected
Default Route with next hops being on different protocol ports linked to ports of
different GiGE boards.

From UA07.1 release, Alcatel-Lucent RNC supports two different Iub interface
protocol stacks in three possible different IuB configurations:

full ATM IuB,

hybrid IuB using a mixity of ATM and IP or

full IP IuB

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 171/223


UMTS RNC Product Engineering Information

Hybrid IuB configurations are used to split the IuB user plane between ATM and IP transport.
Control plane remains on ATM. For the user plane, Interactive and Background traffic (non
delay sensitive) using HSDPA/HSUPA is transferred over IP while all other user plane traffic is
transferred over ATM (R99 traffic, HSDPA/HSUPA streaming traffic ).
For Hybrid Iub configurations, two 4pGiGE boards are required into the RNC.

1. The full ATM IuB implementation is presented below:

Figure 5.8-1: Alcatel-Lucent RNC full ATM Iub protocol stacks implementation
2. The hybrid IuB implementation is presented below:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 172/223


UMTS RNC Product Engineering Information

Figure 5.8-2: Alcatel-Lucent RNC hybrid Iub protocol stacks implementation

3. The Full IP IuB implementation is presented below:


Radio Network

Control Plane User Plane


Layer

NBAP Iu-B Data Stream(s)

Transport Network Transport Network


User Plane User Plane
Transport Network Layer

SCTP UDP

IP

IP

802.1q 802.1q

Ethernet Ethernet

Physical Layer Physical Layer

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 173/223


UMTS RNC Product Engineering Information

Figure 5.8-3: Alcatel-Lucent RNC full IP Iub protocol stacks implementation

As such Iub planes are split between:

o AAL5 based OAM plane, which is described further in this document


o AAL2 based or mixed AAL2 and IP based User Plane that terminates on the
RNC

o AAL5 based Control Plane that terminates on the RNC.

Control Plane implemented with NBAP protocol managed by Call Processing are
divided into two categories:
o NBAP-c (common) procedures which are applicable for the full BTS. This is
carried over a dedicated VCC, known as VCC NodeB Control Port.

o NBAP-d (dedicated) procedures dedicated to a UE context. This is carried


over a set of dedicated VCC, known as VCC Communication Control Port.

IUB USER PLANE

IUB USER PLANE OVER IP

Figure 5.8-4: Standard User Plane Stack Protocol over IP Transport

The bearer identifiers (UDP port number and IP address) are exchanged between the
RNC and the NodeB at each Radio Link Setup via NBAP signaling messages.

The DSCP is determined by the RNC and provided to the NodeB at each Radio Link
Setup via NBAP signaling messages.

The IP Packet structure is illustrated below:

The UDP layer allows a checksum on the Bearer Identifier in order to avoid sending
wrong RLC blocks (in fact correct PDU but to the wrong user) over the radio interface.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 174/223


UMTS RNC Product Engineering Information

Indeed, an error on a PDU is detected by the DCH / HS-DSCH / E-DCH Frame


Protocol but an error on the UDP port can be detected only at RLC layer in the UE.

Note that, as this UDP checksum is optional in RFC 768 (a checksum field set to 0000
means no checksum), it is not computed in UA07 to reduce the processing load.
The IP layer includes a fragmentation function for HSUPA frames exceeding the
maximum MTU size if needed.

In the IP header, the Type of Service (ToS) field is superseded by the DSCP field.
The Ethernet layer includes:

Ethernet II or IEEE 802.3 (Ethernet frame structure)

IEEE 802.1Q (VLAN tagging): optional

IEEE 802.1p (Ethernet frame priority) is not supported.

IUB CONTROL PLANE

Figure 5.8-5: Standard Control Plane Stack Protocol over IP Transport

SCTP over IP shall be supported as the transport for NBAP signalling bearer on Iub
Interface.

The checksum method specified in RFC 3309 shall be used instead of the method
specified in RFC 2960.

Each signalling bearer between the RNC and NodeB shall correspond to one single
SCTP stream in the UL and one single SCTP stream in the DL direction, both streams
belonging to the same SCTP association.

IP DSCP marking shall be supported. The DSCP may be determined from the
application parameters.

A RNC equipped with the SCTP stack option shall initiate the INIT procedure for
establishing association (new in Rel 7)

Multi-homing is not required.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 175/223


UMTS RNC Product Engineering Information

5.8.4 IUCS INTERFACE


Reminder: A UTRAN can be packet only and thus IuCS interface may not be
configured.

Alcatel-Lucent RNC IuCS interface protocol stack implementation is illustrated below:

Figure 5.8-4: Alcatel-Lucent RNC IuCS protocol stack implementation

Reminder: Physical layer is detailed into previous section above.


As such for ATM IuCS planes are split between:

o AAL2 based User Plane

o AAL5 based Control Plane and Transport Control.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 176/223


UMTS RNC Product Engineering Information

Radio Network
Control Plane User Plane

Layer
RANAP Iu UP Protocol Layer

Transport Network Transport Network


User Plane User Plane
Transport Network Layer

SCCP
RTP / RTCP
M3UA

SCTP UDP

IP

IP

802.1q 802.1q

Ethernet Ethernet

Physical Layer Physical Layer

Figure 5.8-5: Alcatel-Lucent RNC IuCS protocol stack implementation for IP

User Plane and Control Plane can be carried over an IP transport network.

Note: Intent below is just to capture the Alcatel-Lucent IuCS permitted scope,
guidelines to select the right options as well as properly dimension the interface is
under the TEG scope.

Rule: RNC IuCS interface type (M)

For a given Iu-CS interface, user plane and control plane have to be based of the
same type of access: ATM or IP.

(On UA07.1 release, it is not possible to have, for a given IuCS interface, the user
plane over ATM and the control plane over IP, nor the user plane over IP and the
control plane over ATM).

But in case of Iu-Flex configurations, some CN may be connected through ATM and
some others connected through IP.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 177/223


UMTS RNC Product Engineering Information

Rule: RNC IuCS Signalling Entities (M)

IuCS SCCP and ALCAP signalling entities relies on:


-> RouteSet

+ SCCP requires one RouteSet for Control Plane

+ ALCAP requires one RouteSet for Transport Control Plane


Warning: As described into SS7 System description part, SCCP and ALCAP may use
the same RouteSet. This is for example the case if facing a non BICN Voice Core.

-> LinkSet
Each RouteSet is associated with at least one Linkset

-> SignallingLinks

One Linkset relies on at least one SignallingLink

Rule: RNC IuCS Interface ATM connection requirements (M)

IuCS is made of:

+ One ATM VCC connection per SignallingLink

+ At least one ATM VCC connection for User Plane

Rule: RNC IuCS Interface ATM Cells types (M)

Over IuCS related ATM cells can be either UNI or NNI. 3GPP recommends NNI.

Rule: RNC IuCS Interface ATM connections types (M)

IuCS related ATM connections can be:


+ PVC based

+ PVP Shaped or Not with VP termination and VCC extraction at RNC level.

+ SPVC based and initiated on RNC side


Warning: ATM connections types can be mixed for one IuCS interface but this is not
recommended exception made of transition phases.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 178/223


UMTS RNC Product Engineering Information

Rule: RNC IuCS ATM Service Categories and Traffic Decriptors (O)

Following Services Categories and Traffic Descriptors are available for Iub ATM based
connections:

+ UBR, UBR+, rtVBR, nrtVBR and CBR

+ PCR, SCR, MBS, CDVT if applicable to associated Service Category

Rule: RNC IuCS Interface ATM Signalling (M)

RNC ATM based IuCS Interfaces supports basic, UNI 3.0, UNI 3.1, UNI 4.0 and PNNI
v1.0 interfaces.

Rule: RNC IuCS Interface ATM Adressing (M)

Over IuCS RNC supports addresses and prefixes for ATM Forum NSAP formats:

+ E.164

+ Native E.164

+ Data Country Code (DCC)

+ International Code Designator (ICD)

+ MSS (Passport) default NSAP format

Rule: RNC IuCS Interface AAL2 User Plane Path available Qos (T)

For User Plane AAL2 Paths, RNC supports one Qos used for CAC, Path/CID
allocation and bandwidth reservation mechanisms.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 179/223


UMTS RNC Product Engineering Information

Rule: RNC IuCS over IP Control Plane Configuration (T)

SCTP is terminated on PDC; 1 IP address per PDC is required.

An SCTP end point is identified by an IP address and the SCTP port number.

As associations are always initiated by the RNC, the RNC needs to know which IP
address/Port number of the peer M3UA node to send the SCTP INIT message.

The RNC supports client functionality. This enables the RNC to report to the MSC
when it is a newly introduced entity in the network. The M3UA layer requests SCTP
layer to setup an SCTP association with the MSC.

There are several associations between the RNC and each CN node (each
destination point code (DPC)). The M3UA layer then load shares between these
associations, based on the availability and the load of each SCTP association.

Only point-to-point connection between the RNC and MSC is supported (no
connection via SG); hence M3UA only acts as an IPSP. Therefore, there is no need to
support Routing Key management.

Rule: RNC IuCS over IP User Plane Configuration (T)

Each PMC-PC has its own RNC-UP-IP@ for IuCS IP flows and manages several RTP
sessions

A RTP session is identified by a pair of addresses (RNC UP-IP@ / UDP port, CN UP-
IP@ / UDP port).

UDP port number for RTP shall be even and the next port shall be reserved for RTCP.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 180/223


UMTS RNC Product Engineering Information

The transport bearer is identified by the UDP port number and the IP address (source
UDP port number, destination UDP port number, source IP address, destination IP
address).

The source IP address and destination IP address are exchanged via RANAP and use
the NSAP structure.

There may be one or several IP addresses in the RNC and in the CN. The CN sends
downstream packets of a given RAB to the RNC IP address / UDP port (received in
RANAP) associated to that particular RAB. The packet processing function in the RNC
sends upstream packets of a given RAB to the CN IP address / UDP port (received in
RANAP) associated to that particular RAB. The packet processing function in the RNC
shall use the same source IP address / UDP port as is sent to CN in RANAP. A RTP
session is then identified by a pair of transport addresses (RNC IP address / UDP
port, CN IP address / UDP port).

The RNC shall use two consecutive port numbers for the RTP bearer and for the
optional RTCP connection that transport a single Iu UP connection. Two such
consecutive port numbers are termed port number block. The first port number shall
be even and shall be assigned to the RTP protocol. The next port number shall be
assigned to the RTCP protocol.

5.8.5 IUPS INTERFACE


Reminder: A UTRAN can be voice only and thus IuPS interface may not be
configured.
Alcatel-Lucent RNC offers two possibilities for the IuPS interface:

ATM based protocol stack as illustrated below:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 181/223


UMTS RNC Product Engineering Information

Figure 5.8-6: Alcatel-Lucent RNC IuPS protocol stack implementation ATM based case

As such IuPS planes are split between:

o AAL5 based User Plane

o AAL5 based Control Plane.

IP based protocol stack as illustrated below (for this configuration the


presence of two 4pGiGE boards into the RNC shelf is required):

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 182/223


UMTS RNC Product Engineering Information

Figure 5.8-7: Alcatel-Lucent RNC IuPS protocol stack implementation IP based case

Rule 5.8-3: Alcatel-Lucent IuPS list of rules overview

Note: Intent below is just to capture the Alcatel-Lucent IuPS permitted scope,
guidelines to select the right options as well as properly dimension the interface is
under the TEG scope.

Rule: RNC IuPS interface type (M)

For a given Iu-PS interface, user plane and control plane have to be based of the
same type of access: ATM or IP.

(It is not possible to have, for a given IuPS interface, the user plane over ATM and the
control plane over IP, nor the user plane over IP and the control plane over ATM).

But in case of Iu-Flex configurations, some CN may be connected through ATM and
some others connected through IP.

For the different rules presented below, the ones related to ATM
resources are of course not applicable in case of Iu-PS over IP
configuration.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 183/223


UMTS RNC Product Engineering Information

Rule: RNC IuPS GTP version support (S)

As per required into the 3GPP standards, IuPS UP implements GTPv1

CHARACTERISTICS FOR IUPS OVER ATM

Rule: RNC IuPS Signalling Entities (M)

IuPS SCCP signalling entities relies on:

-> RouteSet

+ SCCP requires one RouteSet for Control Plane

-> LinkSet

Each RouteSet is associated with at least one Linkset

-> SignallingLinks

One Linkset relies on at least one SignallingLink

Rule: RNC IuPS Interface ATM connection requirements (M)

IuPS is made of:

+ One ATM VCC connection per SignallingLink

+ At least one ATM VCC connection for User Plane

Rule: RNC IuPS Interface ATM Cells types (M)

Over IuPS related ATM cells can be either UNI or NNI. 3GPP recommends NNI.

Rule: RNC IuPS Interface ATM connections types (M)

IuPS related ATM connections can be:

+ PVC based

+ PVP Shaped or Not with VP termination and VCC extraction at RNC level.

+ SPVC based and initiated on RNC side exception made of User Plane
associated connections (Introduced in UA04.1)

Warning: ATM connections types can be mixed for one IuPS interface but this is not
recomended exception made of transition phases.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 184/223


UMTS RNC Product Engineering Information

Rule: RNC IuPS ATM Service Categories and Traffic Decriptors (O)

Following Services Categories and Traffic Descriptors are available for IuPS ATM
based connections:

+ UBR, UBR+, rtVBR, nrtVBR and CBR

+ PCR, SCR, MBS, CDVT if applicable to associated Service Category

Rule: RNC IuPS Interface ATM Signalling (M)

RNC ATM based IuPS Interfaces supports basic, UNI 3.0, UNI 3.1, UNI 4.0 and PNNI
v1.0 interfaces.

Note: MSS (Passport) also supports IISP, AINI, ILMI and Virtual Interfaces but all
those are NOT contemplated and supported into RNC context.

Rule: RNC IuPS Interface ATM Addressing (M)

Over IuPS RNC supports addresses and prefixes for ATM Forum NSAP formats:

+ E.164

+ Native E.164

+ Data Country Code (DCC)

+ International Code Designator (ICD)

+ MSS (Passport) default NSAP format

Rule: RNC IuPS Interface AAL5 User Plane available Qos (M)

For User Plane AAL5 connections which encapsulates IP (case of ATM based
configuration), RNC supports differentiation of up to 4 different ipCos.

Rule: RNC IuPS Interface IP packets differentiation (M)

RNC marks IP packet using DSCP. Packet differentiation is based on DiffServ PHB.

Rule: RNC IuPS User Plane IP @ requirements(M)

One IP subnet is associated with each set of one to four VCC (one if one ipcos only, 4
if four of them are used)

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 185/223


UMTS RNC Product Engineering Information

Rule: RNC IuPS over ATM User Plane ECMP (M)

IuPS support Flow based and not packet based ECMP

Rule: RNC IuPS IP Routing Protocols (M)

IuPS ONLY supports static default and static dedicated routing. Dynamic routing
protocols such as RIP or OSPF are not supported.

Rule: RNC IuPS Interface ARP support for IP over ATM (M)

RNC supports both InvARP and static ARP on IuPS for IP over ATM based
connections as per 3GPP requirements.

Network Design: RNC IuPS IP@ Needs

ONE IP subnet for Localmedia matching requirements described as part of the


RNC IP System section and ONE IP subnet per set of VCCs mentioned above.

The principle of IuPS over IP organization is presented in the below figure:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 186/223


UMTS RNC Product Engineering Information

CHARACTERISTICS FOR IUPS OVER IP

IuPS over IP specific informations:

(For additional information please refer to document [Ext_R&D_025] or to Iu Transport


Engineering Guide [Ext_ENG_004])

CONTROL PLANE IMPLEMENTATION

M3UA implementation:

The RNC implements M3UA client functionality. M3UA can act either as IPSP (IP
Server Process: point-to-point connection with SGSN) or as ASP (Application Server
Process: connection via a Signaling Gateway).

SCTP level:

For redundancy purpose, it is recommended to setup at least two associations


between a RNC and a SGSN.
Per association, two streams (one in DL + one in UL) will be supported to convey
SCCP messages. In addition, per association, stream 0 shall be used for M3UA
management messages. Thus 2 outbound streams and 2 inbound streams will be
used per association.

Multi-homing on RNC side is not needed (one single IP address per association on
RNC side) but the RNC supports a multi-homed SGSN.

TRAFFIC SEGREGATION OVER IP

Rule: RNC IuPS over IP traffic segregation (M)

Several DiffServ Code Points are used for IuPS over IP traffic segregation.

DiffServ allows managing some QoS classes over IP corresponding to a forwarding


treatment (PHB: Per Hop Behavior) though Differentiated Services Code Points (DSCP).

For IuPS over IP following mapping is recommended:

o for conversational traffic: usage of Expedited Forwarding (EF),

o for streaming traffic: usage of Assured Forwarding 4x (AF4x)

o for interactive traffic: usage of Assured Forwarding 3x, 2x and 1x (AF3x, AF2x, AF1x)
o for background traffic: usage of Default Forwarding (DF)

o for Network Control: usage of CS6 and CS7.


Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 187/223


UMTS RNC Product Engineering Information

(These different levels of priorities are mapped to different Emission Priorities into the
4pGiGE boards).

Additional characteristics for addressing and configuration

Rule: RNC IuPS over IP Multi Path Management (M)

4pGiGE boards do not support ECMP (Equal Cost Multi Path). Thus ECMP is not
supported for IU-PS over IP.
PDR (Protected Default Route) usage is recommended for IP flows using the 4pGiGE
boards.

PDR corresponds to a static default route (destination 0.0.0.0) with two or more (up to
4) outbound IP interfaces (next hops). Next hops are used to protect the default route
in case of port failure; card failure Each next hop uses one unique IP subnet. At a
given time, only one port and interface is selected as active.

Rule: RNC Virtual Router contraint (M)

ECMP and PDR can not be used simultaneously on the same Virtual Router.

This constraint has to be considered for instance in case of Iu-Flex configurations or


during migration from ATM to IP using Iu-Flex facility (In that case for instance ECMP
should be disabled and PDR activated only when all has been migrated on the IP
environment; before only static route over IP should be used).

Control Plan Addressing for Iu-PS over IP


In addition to user plane IP addresses, RNC IP addresses have to be allocated for Iu-
PS control plane in order to establish SCTP associations between RNC and SGSN.

SCTP are terminated on PDC processor on the PSFP (or DCPS). All PSFP except
those supporting the PMC-NI are able to support SCTP associations. The following
table provides the number of IP address, used for IU-PS over IP control plan, per
RNC, depending on the number of PSFP into the RNC. Recall, in UA06.0, in case of
IP interface usage on the RNC, the maximum market models owns 10 PSFP (or
DCPS).

From UA07.1 within Full IP configuration and 12 PS, the IP mapping addresses used
10 IP address max for Iu-PS Control Plane.

Market model 4 PSFP 6 PSFP 8 PSFP 10 PSFP 12 PSFP


or DCPS or DCPS or DCPS or DCPS or DCPS

Max number of IP address for Iu-PS 2 4 6 8 10


Control Plane (one per PDC for
PSFP not supporting PMC-NI)
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 188/223


UMTS RNC Product Engineering Information

SCTP associations are identified by the couples RNC: local Iu-PS Control Plane RNC
IP address and port number, plus remote IP address and port number.

The RNC Iu-PS Control Plane IP addresses have to be provisioned at configuration


time. By the same way SGSN Control Plane IP addresses and SCTP port numbers
have to be provisioned too in order to allow the RNC to establish the SCTP
association between the RNC and the SGSN. Even though up to 8 associations could
be set between a RNC and SGSN (or Signaling Gateway: SG), by default 2
associations will be created between the RNC and a SGSN (or SG).

User Plan Addressing for Iu-PS over IP

Please refer to the chapter 5.5.4.3 and the Change of RNC Iups User Plane
Addresses and Subnet Reduction part.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 189/223


UMTS RNC Product Engineering Information

5.8.6 IU-FLEX CONTEXT


In the context of Iu-Flex usage, IU interface in composed of several IU-PS and IU-CS
interfaces. In this context, the stack implementation and associated rules presented in
the two previous chapters presenting Iu-CS and Iu-PS interfaces are directly
applicable.
Remark:

Iu-CS and Iu_PS interfaces are managed independently. Thus, the number of Iu-CS
interfaces may be different than the number of Iu-PS interfaces.
In the context of Iu-Flex usage, configurations, where some Iu-PS interfaces are ATM
based and some other are IP based, are supported.

5.8.7 IUR INTERFACE


Reminder: IuR interface is optional, so it might not be configured.

IuR shall provide IP transport for the IuR User Plane and control Plane. The RNC can
support both ATM and IP IuR connection at the same time. However, between 2
RNCs, all connections must be either ATM or IP.

5.8.7.1 IUR INTERFACE ON ATM

Alcatel-Lucent RNC IuR interface protocol stack for ATM implementation is illustrated
below:

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 190/223


UMTS RNC Product Engineering Information

Figure 5.8-8: Alcatel-Lucent RNC IuR ATM protocol stack implementation

Physical layer is detailed into previous section above.

As such IuR planes are split between:

o AAL2 based User Plane

o AAL5 based Control Plane and Transport Control Plane

Rule 5.8-4: Alcatel-Lucent IuR list of rules overview

Note: Intent below is just to capture the Alcatel-Lucent IuR on ATM permitted scope,
guidelines to select the right options as well as properly dimension the interface is
under the TEG scope.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 191/223


UMTS RNC Product Engineering Information

Rule: RNC IuR Signalling Entities (M)

IuR SCCP and ALCAP signalling entities relies on:


-> RouteSet

+ SCCP requires one RouteSet for Control Plane

+ ALCAP requires one RouteSet for Transport Control Plane


Warning: As described into SS7 System description part, SCCP and ALCAP may use
the same RouteSet. This is for example the case for an IuR between two Alcatel-
Lucent RNC without any AAL2 Switch between them.
-> LinkSet

Each RouteSet is associated with at least one Linkset

-> SignallingLinks

One Linkset relies on at least one SignallingLink

Rule: RNC IuR Interface ATM connection requirements (M)

IuR is made of:

+ One ATM VCC connection per SignallingLink

+ At least one ATM VCC connection for User Plane

Rule: RNC IuR Interface ATM Cells types (M)

Over IuR related ATM cells can be either UNI or NNI. 3GPP recommends NNI.

Rule: RNC IuR Interface ATM connections types (M)

IuR related ATM connections can be:

+ PVC based

+ PVP Shaped or Not with VP termination and VCC extraction at RNC level.
+ SPVC based and initiated on RNC side

Warning: ATM connections types can be mixed for one IuCS interface but this is not
recommended exception made of transition phases.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 192/223


UMTS RNC Product Engineering Information

Rule: RNC IuR ATM Service Categories and Traffic Decriptors (O)

Following Services Categories and Traffic Descriptors are available for IuR ATM
based connections:

+ UBR, UBR+, rtVBR, nrtVBR and CBR

+ PCR, SCR, MBS, CDVT if applicable to associated Service Category

Rule: RNC IuR Interface ATM Signalling (M)

RNC ATM based IuR Interfaces supports basic, UNI 3.0, UNI 3.1, UNI 4.0 and PNNI
v1.0 interfaces.

Note: MSS (Passport) also supports IISP, AINI, ILMI and Virtual Interfaces but all
those are NOT contemplated and supported into RNC context.

Rule: RNC IuR Interface ATM Adressing (M)

Over IuR RNC supports addresses and prefixes for ATM Forum NSAP formats:

+ E.164

+ Native E.164

+ Data Country Code (DCC)

+ International Code Designator (ICD)

+ MSS (Passport) default NSAP format

Rule: RNC IuR Interface AAL2 User Plane Path available Qos (M)

For User Plane AAL2 Paths, RNC supports differentiation of up to 3 different Qos (0, 1
and 2) used for CAC, Path/CID allocation and bandwidth reservation mechanisms.

Following figure presents an overview of IuR AAL2 resources usage with all
types of traffic present; for more details please refer to IuR TEG.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 193/223


UMTS RNC Product Engineering Information

5.8.7.2 IUR INTERFACE OVER IP

Alcatel-Lucent RNC IuR interface protocol stack for IP implementation is illustrated


below:
Radio Network

Control Plane User Plane


Layer

RNSAP Iu-R Data Stream(s)

Transport Network Transport Network


User Plane User Plane
Transport Network Layer

SCCP

M3UA

SCTP
UDP

IP

IP

802.1q 802.1q

Ethernet Ethernet

Physical Layer Physical Layer

Figure 5.8-9: Alcatel-Lucent RNC IuR protocol stack implementation for IP

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 194/223


UMTS RNC Product Engineering Information

Figure 5.8-10: Synthetic view of IuR

RNCs may be connected to the ATM backbone or to the IP backbone or to both.


However, Control and User plane stacks for each specific Iur interface must be either
IP or ATM, but may not be a hybrid configuration (i.e. no mix and match of ATM
Control and IP User plane or vice versa, for a given Iur interface). Iur logical
architecture is presented in Figure 5.8-10.

At the IP level, DiffServ is used for QoS differentiation.

At the Ethernet level, VLANs can be used to separate different flows (User Plane,
Control Plane) on a single VR associated with a physical Gigabit Ethernet Port.

An Iur link between any pair of RNCs may be either full ATM or full IP but may not be
a hybrid configuration (ie, no ATM connection and IP link at the same time).

With existing feature, HSDPA over IuR and HSUPA over IuR, HSPA mobility is
performed with following restrictions: SRB over E-DCH over IuR is not supported.

In UA08.1, with Enhanced FDPCH feature, SRB over HSDPA will also be supported.

This feature is described in the following document, HSXPA Parameters User Guide
UA08.1 [Ext_ENG_010]

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 195/223


UMTS RNC Product Engineering Information

5.8.7.3 IUR CONTROL PLANE

The IuR Control Plane is transported over IP and terminates the SCTP/IP layers on
the RNC PDC assigned to this task. The SCCP/M3UA layers are terminated on the NI,
NSAP is terminated on the TMU.

The RNC signaling code is modified in UA07 to allow simultaneous ITU and ANSI
versions of the IuR M3UA layer (i.e. one IuR instance can be ITU and another
instance can be ANSI). Actually, the signaling stack is oblivious to interface type so
the code will support simultaneous ITU and ANSI versions of the M3UA layer for any,
of Iu C-plane interfaces (IuCS, IuPS and IuR). The table below shows what customers
are currently requesting for dual stack signaling support and hence what will be
supported by the software.

The IuR Control Plane RNSAP message fields have been revised to reflect IP
transport structures.

5.8.7.4 IUR USER PLANE

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 196/223


UMTS RNC Product Engineering Information

The IuR User Plane (all connection types) is transported over UDP/IP/Gigabit
Ethernet. As UDP/IP are not a reliable transport layers, packet loss, out of order, and
delayed packets are possible.

The IuR User Plane terminates on the RNC within the NAT AP assigned to the
specific connection. As all IuR User Plane traffic from a given remote RNC terminates
in a single NAT AP, the IP address associated with this NAT AP is the single point of
contact IP address used for that RNCs User Plane traffic.

5.8.8 IUPC INTERFACE


Reminder: IuPC interface is optional, so it might not be configured. (IuPC is used for
location services)

Alcatel-Lucent RNC IuPC interface protocol stack implementation is illustrated


++++++below:

Figure 5.8-10: Alcatel-Lucent RNC IuPC protocol stack implementation

Restriction: RNC IuPC implementation (S)

Part of stack implemented for IuPC is Alcatel-Lucent implementation specific as


compared to 3GPP available options.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 197/223


UMTS RNC Product Engineering Information

This section is focused on IuPC perception from an external network perspective,


which is illustrated below:

Rule 5.8-5: Alcatel-Lucent IuPC list of rules overview

Note: Intent below is just to capture the Alcatel-Lucent IuPC permitted scope,
guidelines to select the right options as well as properly dimension the interface is
under the TEG scope (covered into Iu TEG).

Rule: RNC IuPC Interface ATM Cells types (M)

Over IuPC related ATM cells can be either UNI or NNI. 3GPP recommends NNI.

Rule: RNC IuPC Interface ATM connections types (M)

IuPC related ATM connections are PVCs based.

Rule: RNC IuPC ATM Service Categories and Traffic Decriptor support (O)

Following Services Categories and Traffic Descriptors are available for IuPC ATM
based connections:
+ UBR, UBR+, rtVBR, nrtVBR and CBR

+ PCR, SCR, MBS, CDVT if applicable to associated Service Category

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 198/223


UMTS RNC Product Engineering Information

Rule: RNC IuPC Interface IP Routing Protocol (M)

RNC IuPC interface ONLY implements static routing, no dynamic protocols such as
RIP or OSPF are supported.

Rule: RNC IuPC Interface ARP support for IP over ATM (M)

RNC supports both InvARP and static ARP on Iub for IP over ATM based
connections.

Network Design: RNC IuPC IP@ Needs

IuPC requires two IP@

Restriction: RNC IuPC Interface implementation (S)

Note that the Iu-PC interface is not supported over IP in UA07 as the Standalone
AssistedGPS SMLC (SAS) has been integrated in the RNC since UA06. That means
that Iu-PC over ATM is still supported on a mix ATM/IP RNC but integrated SMLC
server is needed in case of a Full IP RNC.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 199/223


UMTS RNC Product Engineering Information

5.8.9 IUBC INTERFACE


Reminder: IuBC interface is optional, so it might not be configured (Iu-BC is used for
Cell broadcast services).

In case of CBS services usage, the CBC (Cell Broadcast Centre), located in the Core
Network, is connected to the RNC through the IuBC interface that uses the same
possible backhauling solutions as Iu interfaces over ATM.

Alcatel-Lucent RNC IuBC interface protocol stack implementation is illustrated below:

Figure 5.8-11: Alcatel-Lucent RNC IuBC protocol stack implementation

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 200/223


UMTS RNC Product Engineering Information

An overview of the IuBC network is presented below:

Rule 5.8-6: Alcatel-Lucent IuBC list of rules overview

Rule: RNC IuBC Interface ATM Cells types (M)

Over IuBC related ATM cells can be either UNI or NNI.

Rule: RNC IuBC Interface ATM connections types (M)

IuBC related ATM connections are PVCs based.

Rule: RNC IuBC Interface ATM paths (M)

For link redundancy purpose, two ATM VCC supporting SABP traffic shall be
provisioned between the RNC and the CBC on separate physical interfaces.

Rule: RNC IuBC ATM Service Category (M)

IuBC ATM connections are based on UBR Service Category.

Rule: RNC IuBC Interface IP Routing (M)

RNC IuBC interface ONLY implements static routing.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 201/223


UMTS RNC Product Engineering Information

Rule: RNC IuBC Interface over IP (M)

Starting release UA07.1.1, the IuBC interface supports both IP over ATM and IP over
Ethernet transport interfaces thanks to feature IuBC native IP support.

5.8.10 OAM INTERFACE

Rule: RNC NodeB Implementation Specific OAM Management (M)

NodeB implementation specific flows are aggregated at the RNC level. Furthermore
the RNC can support several points of aggregation.

Rule 5.8-7: NodeB OAM Management at RNC level

In case DHCP is used, this aggregation point on RNC plays the role of BOOTP Relay.

Network Design: RNC SDH/SONET OAM IP@ Needs

In case of Out-of-Band, two IP@ are needed for OMUs and one for CPs, those
can be or not part of the same IP subnet.

In case of In-Band, two IP@ are needed for OMUs, one for IP over ATM .

Note: OAM interface, in case of Out Of Band configuration is made through CP


Ethernet access; in UA06, OAM interface is not possible through 4pGiGE boards
(if such boards are present in the RNC).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 202/223


UMTS RNC Product Engineering Information

Following figure presents a global view of OAM organization within UTRAN:

Figure 5.8-12: Overview of OAM organization within UTRAN

5.8.11 CROSS-INTERFACE DEPENDENCIES

Rule: RNC AAL2 based interfaces dependency (M)

All AAL2 based interfaces, i.e Iub UP, IuCS UP and IuR UP must ALL either rely only
on spared interfaces (= Atm Interfaces relying on APS protected ports). OR not spared
interfaces.

Justification: Weakness of IuxIf/Aal2if software implemented on 16p board.

Rule 5.8-8: RNC AAL2 based interfaces dependency

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 203/223


UMTS RNC Product Engineering Information

Rule: RNC RNC Iub Control Plane dependency (M)

Into the RNC context, Iub associated control plane is binded with User Plane through
a common software module. As such dependency mentioned above is to be also
extended to the Iub Control Plane for the RNC.

Justification:Signalling bearer is a sub-component of IuxIf, as such it inherits from


IuxIf/Aal2if software weakness implemented on 16p board.

Rule 5.8-9: RNC Iub Control Plane dependency

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 204/223


UMTS RNC Product Engineering Information

5.9. RNC CAPACITY AND DIMENSIONING


RNC capacity and dimensioning is primarily defined by 3 independent dimensions:
o Coverage i.e. NodeBs, Cells, Neighbouring Links

o Connectivity i.e. STM1s, E1s

o Traffic i.e. Erlangs, Mbps

Furthermore those dimensions are influenced by the level of redundancy that


customer may want to bring into their Network Elements as well as their Network
Architecture.

You can find some complementary informations on the RNC capacity Roadmap
document: [Ext_PLM_004]

5.9.1 RNC CAPACITY

5.9.1.1 RNC SS7 ENTITIES CAPACITY LIMITS

Rule: RNC Maximum Number of SS7 Point Codes (M)

RNC can support up to a maximum of 64 SS7 points codes that can be used over
misc interfaces as DPC or STP for SCCP and/or ALCAP.

Rule: RNC Maximum Number of SS7 Signaling Links (M)

RNC can support up to a maximum of 256 SS7 Signaling Links.

Rule: RNC Maximum Number of SS7 STP (M)

RNC can support up to 2 STP per RouteSet.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 205/223


UMTS RNC Product Engineering Information

Rule: RNC Maximum Number of SS7 DPC per STP (M)

RNC can support up to 20 DPCs reachable through a given STP.

Rule: RNC Maximum Number of SS7 Signalling Links per Linkset (S)

One LinkSet can rely on from 1 to 16 Signalling Links.

5.9.1.2 RNC AAL2 ENTITIES CAPACITIES LIMITS

Rule: RNC Maximum of ALCAP DPC for A2EA Alternate Routing (M)

One A2EA address can be reached through a maximun of 10 ALCAP DPCs

Note that from UA06 the maximum number of A2EA addresses possible in the RNC
software is 16383. With such a big value other constraint will be reached before this
limit. The maximum number of AAL2 paths is presented below.

Rule: RNC Maximum Number of AAL2 Paths (M)

The maximum number of AAL2 paths supported per RNC is given by the following
table :

Configuration 4 6 8 10 12
(#PSFP or
#DCPS)

Max #AAL2 3200 4800 6400 8000 9600


paths

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 206/223


UMTS RNC Product Engineering Information

Rule: RNC Number of CID per AAL2 (S)

One AAL2 Path handles 248 CIDs as per required into ITU.

5.9.2 16POC3/STM1 CAPACITY LIMITS

Rule: 16pOC3/STM1 PQC Number of ATM Connections (M)

16pOC3/STM1 PQC board within RNC supports up to 29 696 256 = 29 440 ATM
connections. As a matter of fact value assigned to the sum of Lp/* Eng Arc Ov
ConnectionPoolCapacity and Lp/* Eng Arc Ov protectedConnectionPoolCapacity
MUST not exceed this number.
Also it is important to note that ConnectionPoolCapacity attribute should NOT be set
to 0 as GPS debug tools requires some not protected connections.

Please refer to TEG for Alcatel-Lucent recommended values of those attributes.

The maximum number of supported PVC for the 16pOC3STM1 is 16000 (16000 end
points or relay points).

Within RNC context, 16pOC3/STM1 PQC uses IP so number of ATM connections is


less than the ATM only ones, furthermore 256 ATM connections are reserved for
PQC1 and PQC2 internal needs.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 207/223


UMTS RNC Product Engineering Information

Rule: 16pOC3/STM1 PQC Vpi.vci Space per Port and APC (M)

16pOC3/STM1 PQC does not offer the full vpi.vci space mentioned within ATM
standards.

From a vci perspective, the maximum vci supported value is 16384.

From a vpi perspective, vpi value can go up to 255 for UNI cells and 4095 for NNI cells
but this under some Connections Space reservation constraints presented below and
part of ConnMap defined on 16pOC3/STM1 interfaces:

Sum of VCCs = [Atmif/* ConnMap Ov numVccsForVpiZero] + [Atmif/* ConnMap Ov


numVccsPerNonZeroVpi]*[Atmif/* ConnMap Ov numNonZeroVpisForVccs]

Sum of VPCs = 2*(2^[Atmif/* maxVpiBits] - 1 - Atmif/* ConnMap Ov


numNonZeroVpisForVccs])

Sum of connections = Sum of VCCs + Sum of VPCs

Constraint becomes: Sum of connections of 4 ports an APC < 113 664. Please refer to
16pOC3/STM1 system description for APC and ports associations.

Please refer to TEG for Alcatel-Lucent recommended values of those attributes.

Please refer to TEG for Alcatel-Lucent recommended values for 16pOC3/STM1 board,
APC, and ports parameters settings for ATM connections.

Rule: 16pOC3/STM1 PQC Maximum Iu DL Throughput (M)

The 16pOC3/STM1 PQC board supports a maximum throughput of 310 Mbps for IU
DL traffic at applicative level.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 208/223


UMTS RNC Product Engineering Information

16POC3/STM1 MS3 CAPACITY LIMITS

Rule: 16pOC3/STM1 MS3 Number of ATM Connections (M)

A 16pOC3/STM1 MS3 board within RNC supports up to 46080 ATM connections


(45k). A maximum of 16384 ATM connections are possible per ports (16k).

Rule: 16pOC3/STM1 MS3 Maximum Throughput (M)

The 16pOC3/STM1 MS3 board supports a maximum throughput of 2.5 Gbps at


physical level.

5.9.3 4PGIGE BOARDS CAPACITY LIMITS

Rule: 4pGiGE Maximum Throughput (M)

Each port a of 4pGiGE board may support a traffic (at physical level) of 1Gbps, but the
board supports a maximum traffic of 2.5 Gbps (for the 4 ports).

Rule: 4pGiGE Number of GiGE ports per RNC (M)

4pGiGE boards are managed in Load Sharing boards. The two boards are active and
are providing of total number of 8 ports.
Each port has a maximum capacity of 1 Gbps, but, as one board has a maximum
capacity of 2.5 Gbps and to be able to support the loss of one board with any impact
on capacity, a maximum of 2.5 Gbps is supported for the IP flows crossing the
4pGiGE boards.

Rule: 4pGiGE Redundancy (O)

In order to have a redundancy for the flows crossing the 4pGiGE boards:

- it is recommended to set for each path one main route on one board and a
redundant route on the second board

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 209/223


UMTS RNC Product Engineering Information

5.9.4 IUB INTERFACE CAPACITY LIMITS

Rule: RNC/Iub Maximum Number of NodeB and Cells (M)

For RNC equipped with CP3, RNC can support up to a maximum of 1200 NodeBs and
1200 Cells.

For RNC equipped with CP4, RNC can support up to a maximum of 2400 NodeBs and
2400 Cells.

It has to be noticed that these values are maximum number of supported contexts for
the NodeB and cells, but some other resources shortage (ex: max control Ports, max
AAL2 paths, max sPVC, max VPT, ) may prevent, depending on the used
configurations, reaching these values.

For more information about the limitations linked to other resources see section
Internal resources dimensioning that may lead to NodeB and Cell limitations
below in this chapter.

Rule: RNC Iub Number of NodeB and Cells scalability (M)

Depending on RNC Market Model, maximum number of supported NodeBs and Cells
are the following:

Configurations with PSFP and CP3 boards

#PSFP 4 6 8 10 12
Max #NodeB 360 600 800 1200 1200

Max #cells 360 600 800 1200 1200

Configurations with DCPS and CP3 boards

#DCPS 4 6 8 10 12

Max #NodeB 360 600 800 1200 1200


Max #cells 360 600 800 1200 1200

Configurations with DCPS and CP4 boards in UA07.1 release

#DCPS 4 6 8 10 12

Max #NodeB 600 1000 1400 2000 2400


Max #cells 600 1000 1400 2000 2400

Note: In UA07.1, the number of cells (1 carrier, 1 sector) is the limiting coverage
factor, not Node Bs. The number of Node Bs can at a maximum be equal to number of
sectors. No change on this dimensioning in UA08.1

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 210/223


UMTS RNC Product Engineering Information

Rule: RNC/Iub ATM connections dimensioning limits (M)

Iub provides :
+ One and only one ATM VCC connection for OAM Plane

+ One and only one ATM VCC connection for NBAP-d (First Control Plane one)

+ From one to six ATM VCC connections for NBAP-c


+ One ATM VCC connection for ALCAP protocol management

+ From one and up to sixteen ATM VCC connections for User Plane and that can
be shared between the different available AAL2 Path Qos
The organization of the different ATM VCC may be done without bandwidth pool or
through one or several bandwidth pools. A maximum of 16 ATM bandwidth pool is
supported per Iub Interface.

In case of Hybrid IuB, one IP bandwidth pool is supported per IuB interface except in
the case of Utran sharing where up to 4 (on per operator) IP bandwidth pool may be
supported per IuB interface.

Internal resources dimensioning that may lead to NodeB and Cell limitations

The maximum number of NodeB and cells may be limited to some internal resources
shortage depending on the used configurations:

Maximum Number of Control Ports:

The maximum number of control ports is 600 per Service Group for configurations
with CP4 boards, and 360 per Service Group for configurations with CP3 boards.
Control Ports are mapped to AAL5 VCC on the IuB corresponding to NBAP and
ALCAP VCC.

A picoBTS or macroBTS requires 3 control ports. A oneBTS requires 2 control ports.


An iBTS requires between 3 and 8 control ports (depending on the number of CEM in
the NodeB).

The following table indicates the number of control ports per RNC depending on the
market models.

Market Model with CP3 boards 4 PSFP 6 PSFP 8 PSFP 10 PSFP 12 PSFP
or 4 or 6 or 8 or 10 or 12
DCPS DCPS DCPS DCPS DCPS

Max Number of Service Group 3 5 7 10 12

Max number of control ports 1080 1800 2520 3600 3600

Market Model with CP4 boards 4 DCPS 6 DCPS 8 DCPS 10 DCPS 12 DCPS

Max Number of Service Group 3 5 7 10 12

Max number of control ports 1800 3000 4200 6000 7200

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 211/223


UMTS RNC Product Engineering Information

Maximum Number of AAL2IF paths:

The maximum number of AAL2If paths per RNC is 800 per PSFP or DCPS. AAL2If
paths are used on IuB user plane to carry the different traffic flows by ATM QOS type.
(for instance one AAL2IF path used for DS traffic with QOS0, one for NDS traffic with
QOS1, one for HSxPA NDS traffic with QOS2, )

The following table indicates the number of AAL2 per RNC depending on the market
models.

Market 4 PSFP or 4 6 PSFP or 6 8 PSFP or 10 PSFP or 12 PSFP or


Model DCPS DCPS 8DCPS 10 DCPS 12 DCPS

Max 3200 4800 6400 8000 9600


Number of
AAL2IF
paths

Maximum Number of SPVC:

The maximum number of ATM SPVC that can be supported per RNC is 256. Thus in
case where SPVC are used for NodeB OAM connectivity, a maximum of 256 NodeBs
can be supported per RNC. When higher a number of NodeBs needs to be supported,
SPVC should not be used.

Maximum Number of VPT/VPC:

In case where shaping is used at VP level on the RNC (with usage of VPT hairpins), a
maximum of 512 VPT/VPC is possible per RNC. If more than 512 VPT need to be
used, it is recommended to use an external Transport Node to perform this
functionality (usage of a 7670 TN for instance).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 212/223


UMTS RNC Product Engineering Information

5.9.5 IUCS INTERFACE CAPACITY LIMITS

Rule: RNC/IuCS Maximum Number of IuCS (M)

RNC can support up to 24 IuCS interfaces.

Rule: RNC/IuCS Number of SCCP destination Point Codes (M)

RNC support one and only one SCCP DPC per IuCS interface.

Rule: RNC/IuCS Number of ALCAP destination Point Codes(M)

RNC can support up to 10 ALCAP DPC.

5.9.6 IUR INTERFACE CAPACITY LIMITS

Rule: RNC/IuR Maximum Number of IuR (M)

RNC can support from 0 to 36 IuR interfaces.

This value corresponds to the max number of neighboring RNC supported.

Rule: RNC/IuR Number of SSCP destination Point Codes (M)

RNC supports one and only one SCCP DPC per IuR.

Rule: RNC/IuR Number of ALCAP destination Point Codes (M)

RNC can support up to 10 ALCAP DPC.

Rule: RNC/IuR Number of A2EA (M)

RNC use one single A2EA address as originating A2EA for all IuR interfaces using
ALCAP.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 213/223


UMTS RNC Product Engineering Information

5.9.7 IUPS INTERFACE CAPACITY LIMITS

Rule: RNC/IuPS Maximum Number of IuPS (M)

RNC can support up to 24 IuPS interfaces.

Rule: RNC/IuPS Number of SSCP destination Point Codes (M)

RNC support one and only one SCCP DPC per IuPS interface.

Applicable to IU-PS over ATM only (ECMP is not supported on 4pGiGE for Iu-PS over
IP):

Rule: RNC IuPS User Plane ECMP (M)

IuPS supports up to three Paths for ECMP.

5.9.8 IUPC INTERFACE CAPACITY LIMITS

Rule: RNC Maximum SAS IP@ (M)

IuPC support up to 2 IP@ for SAS server

5.9.9 IUBC INTERFACE CAPACITY LIMITS

Rule: RNC Maximum CBC (M)

Only one CBC is supported face to the RNC.

Rule: RNC Maximum CBC IP@ (M)

IuBC interface supports up to 2 IP@ for a CBC. For redundancy purpose, these two IP
addresses have to be used to establish two redundant paths between CBC and RNC.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 214/223


UMTS RNC Product Engineering Information

Rule: RNC Maximum RNC IP@ on IUBC interface (M)

Only one RNC IP @ is seen externally for the RNC.

A RNC internal redundancy is made with two processors having the same address.

5.9.10 NUMBER OF NEIGHBORING GSM OR CDMA1X CELLS

Rule: RNC Maximum Number of Neighboring GSM or CDMA1x cells (M)

The maximum number of neighboring GSM or CDMA1x cells seen by a RNC is given
by the following table depending on the HW configuration (see section 5.2.2 for the
definition of the hardwareCapability parameter):

hardwareCapability all6mPktServSP allPktServSP2 allPktServSP2FullDim


parameter

Max number of 1800 1800 3600


neighboring GSM
cells or CDMA1x
cells

5.9.11 APPLICABLE RULES FOR RNC IN UTRAN SHARING


ENVIRONMENT

Rule: RNC UTRAN sharing, maximum number of networks (M)

A RNC can be shared between a maximum of four operators (so a RNC can belong to
four different networks).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 215/223


UMTS RNC Product Engineering Information

Rule: RNC UTRAN sharing, maximum dimensioning figures (M)

The maximum number of resources managed by a shared RNC is identical to the


number of resources of a RNC in a non shared environment (same maximum
numbers of supported NodeB, cells, external ports, etc ).

There is no reserved resources per operator and thus they are all shared from an
RNC point of view.

Rule: RNC UTRAN sharing, Iu Flex support (M)

The feature IuFlrx in conjunction with the feature UTRAN Sharing enables RNC to
interface with up to 24 Core Network nodes per domain (CS or PS)

The number of Iu interfaces may be balanced between the different operators or not.

Rule: RNC UTRAN sharing, connectivity (O)

Iu connections for the different operators may be gathered on the same 16pOC3STM1
ports or not.

Rule: RNC UTRAN sharing, shared NodeB case (M)

In case of a shared NodeB, it is possible to reserve some IuB Bandwidth per operator.
This may be done through the help of IuB Bandwidth pools that may be created per
operator. In case where this possibility is not used, the different operators share the
total IuB bandwitdh, there is then no dedicated Iub resource per operator.

In case where the reservation of IuB bandwidth pools per operator is not used, the Iub
bandwidth is shared and thus the Iub flow of one cell of one operator may impact the
Iub flow of the other cells belonging to other operators.
Remark: in the case where IuB bandwidth pools are dedicated per operator, there is
no statistically bandwidth gain on the IuB between the flows of the different
operators.

In case of an hybrid IuB configuration in an UTRAN sharing environment, bandwidth


pools could be declared for IP traffic and for R99 traffic per operator.

(The maximum number of ATM BP per Iub interface is 16 and the maximum number
of IP BP per Iub interface is 4 in case of UTRAN sharing: one per operator).

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 216/223


UMTS RNC Product Engineering Information

Rule: RNC UTRAN sharing, RNC id (M)

A RNC has one unique RNC Id. Thus in a shared environment, this Id has to be
unique for the different network to which belongs the shared RNC.

Rule: RNC UTRAN sharing, RNC SS7 Point Code (M)

Even in a shared environment, a RNC has a unique SS7 Point Code (for RNC using
one single ITU-T SS7 stack; in the case where ANSi and ITU-T SS7 stacks are used,
two Point Codes are declared for the RNC). Thus in a shared environment, the SS7
point codes for the shared RNC need to be coordinated between the different
operators.

Rule: RNC UTRAN sharing, RNC Cell Id (M)

Cell Id have to be unique into a RNC; thus Cell Ids of the shared NodeB have to be
coordinated between the different operators.

Rule: RNC UTRAN sharing, RNC Iu PC (M)

There is one unique IuPC interface possible per RNC. Thus for a shared RNC the
IuPC interface has to be shared between the operators.

Rule: RNC UTRAN sharing, RNC Iu BC (M)

There is one unique IuBC interface possible per RNC. Thus for a shared RNC the
IuBC interface has to be shared between the operators.

Remark: For a shared RNC, the different networks managed by the different operators
are independent. There is no internal logical Iur like into the RNC between these
networks.

5.9.12 RNC COUNTER VOLUME CONTROL

Active RNC counters are managed through a list of counters (parameter


counterIdList).

With the significant amount of defined counters, depending on the number of cells
created on a given RNC, this one may be not able to support all the possible counters
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 217/223


UMTS RNC Product Engineering Information

due to memory limitations. To be able to manage this limitation, a list of counters is


used. This one specifies the active counters on the RNC. This list is a class 3
parameter; it is possible to enable or disable the different counters on line depending
on the need (any modification of the active list of counters will be taken into account at
the next collection period).

A priority is affected to each possible counter (this priority can not be modified).
Depending on the RNC HW baseline, the RNC will be able to support a given
maximum number of active counters. In case where the number of active counters
reaches this maximum limit, the RNC will provide only the active counters with the
highest priority that fits into the maximum limit. In case where the number of active
counters reaches 80% of the limit, a warning alarm is raised (alarm:
ANO_PF_GPO_LIMIT_80_PC_REACHED). In case where the number of active
counters reaches the limit, a minor alarm is raised (alarm:
ANO_PF_GPO_LIMIT_100_PC_REACHED_AND_LOW_PRIORITY_COUNTERS_DI
SABLED) and the counters with the less priority are no more provided (by groups of
counters of the same priority).

The following maximum limits are applicable:

Rule: RNC RNC counter volume control (M)

The maximum number of active counters shall respect the following limits:

For configurations with CP3 boards:

[Nb screenings (counter i) x Nb Configured Instances (counter i)] <=


4.75 millions

For configurations with CP4 boards:

[Nb screenings (counter i) x Nb Configured Instances (counter i)] <=


9.5 millions

Thus, when the number of active counters is approaching the indicated limitation, the
user should verify that the list of active counters is defined appropriately (and adjust it
if necessary) to avoid having the RNC providing not useful counters while some
necessary ones would be filtered.

The counter list should be also adapted depending on the activated features. By the
same way, it should be verified that the counters used in metrics are declared as
active in the RNC counter list.

From UA7.0, a new feature 34648 (RNC Counter Control & Capacity Improvements) is
introduced in V7.0 which allows to support counter provisioning / configuration at
screening level:

CounterScreeningList is added. This list is used to specify which counter-


screenings are collected and reported by RNC.

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 218/223


UMTS RNC Product Engineering Information

FamilyIdList and CounterList are removed, which means the old fashion of counter
provisioning in V6.0 and earlier releases is no longer applicable.

The feature 34648 is activated by default.

A default CounterScreeningList exists and so can be used to build your MIB. The
default list includes all the existing V6.0 and new V7.0 counters.

This feature allows the operator to control counter volume base on counter screening.
It improves counter capacity by allowing counter selection at screening level.
The RNC accepts counter Screening List configuration even if the counter volume
exceeds its capacity. However, its defense mechanism is triggered at counters
activation in order to disable lower priority counters; the same applies at RNC startup
(same as UA6). In V6, the calculation is based on counters, if a counter is configured
all his screenings will be counted. In V7, only the configured screening will be counted.

5.9.13 RNC COUNTER EVOLUTION IN UA08.1 RELEASE


The RNC Counter Evolution feature enhances network monitoring derived from RNC
performance measurement counters based on customer requirements and internal
proposals for the Alcatel-Lucent UTRAN counters solution. It introduces new counters
on the existing RNC base focusing on customer requirements and other
enhancements to improve monitoring and troubleshooting capabilities. Whilst
providing clearly structured counters with description / trigger details required to
interpret the delivered counter results.

The counters introduced by this feature are pegging events that are introduced by
other features, but these features are already in implemented in previous releases, so
there are no dependencies on features still to be introduced.

This feature should not impact any pre-existing features / functionality / call
processing. Following the introduction of this feature new performance counters shall
be available to the customer to further aid network performance analysis. Counters will
be activated be default but can be controlled / de-activated if required.
For knowing more details on this feature please refer to the FSD [Ext_R&D_027]

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 219/223


UMTS RNC Product Engineering Information

5.10. RNC LCM


(LCM means here Life Cycle Management)

5.10.1 RNC REGULATORY COMPLIANCES


For information on:

Environmental constraints

Electromagnetic compatibility
Security requirements

Please refer to CPO, NTP and I&C methods.

5.10.2 RNC UPGRADE PATHS


For the RNC, upgrade paths to UA07.0, UA07.1 and UA08.1release are presented in the table below.
For more details please refer to UA07.0 Upgrade Paths [Ext_PLM_017], UA07.1 Upgrade Paths
[Ext_PLM_018] and UA08.1 Upgrade Paths [Ext_PLM_019].

RNC Software Upgrade Paths


To UA6.0 UA7.0 UA7.1.1 UA7.1.3 UA8.1
From
UA6.0 Supported Supported Supported Supported NS
UA7.0 Supported Supported Supported Supported NS
UA7.1.1 Supported Supported Supported Supported NS
UA7.1.3 Supported Supported Supported Supported Supported
UA8.1 NS NS NS Supported Supported

Upgrades to UA07.0 or UA07.1 release have to be performed in the same hardware


configuration as previous release. Hardware changes (for instance migration from
PSFP configuration to DCPS/eDCPS configuration or migration from CP3
configuration to CP4 configuration) have to be performed into the same software
release.

Migration from UA07.1.3 to UA08.1 is supported.

5.10.3 RNC HARDWARE MIGRATIONS


RNC hardware migrations supported are the following:

- hardware upgrade from a configuration with CP3 boards (and DCPS boards) to a
configuration with CP4 boards (and DCPS boards): see document [Ext_I&C_019]
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 220/223


UMTS RNC Product Engineering Information

- hardware upgrade from a configuration with PSFP boards to a configuration with


DCPS boards: see document [Ext_I&C_020],

- Procedure to decrease the number of PS boards (PSFP or DCPS) into a RNC:


see document [Ext_I&C_023]
- Procedure to insert 4pGiGE boards into the RNC: see document [Ext_I&C_024].

- Procedure to increase the number of PS boards (PSFP or DCPS) into a RNC


(with same CP boards): see document [Ext_I&C_025]
- Procedure to be carried out in order to migrate 9370 RNC ATM/IP in Full IP
configuration : see document [Ext_I&C_026]

Procedure to increase or replace some DCPS boards with eDCPS in a RNC


is described in the document: [Ext_I&C_027]

5.10.4 RNC ORDERING


Please refer to SolCom MOPGs.

5.10.5 RNC COMMISSIONING AND INTEGRATION


For UA07.x Please refer to I&C methods.

9370 RNC UA7.x Commissioning Method [Ext_I&C_009]

9370 RNC UA07.x Integration Method [Ext_I&C_022]

For UA08.1 Please refer to I&C Methods

ALU 9370 RNC UA08.1 Commissioning Method [Ext_I&C_028]

ALU 9370 RNC UA08.1 Integration Method [Ext_I&C_029]

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 221/223


UMTS RNC Product Engineering Information

5.10.6 RNC OPERABILITY


Please refer to Operations NTPs.

5.10.7 RNC SCALABILITY


In term of scalability, in order to increase the capacity of the RNC, the transition from
one market model to a higher one is possible through addition of PSFP (or DCPS)
boards. Transition from any market model to another higher one is possible.

5.11. RNC INTER-WORKING


Please refer to State of Compliance documents as well as Inter-working FRS.

5.12. RNC ENGINEERING RULES

5.12.1 HARDWARE DEPLOYMENT

NODAL DEPLOYMENT

Engineering Guidelines: RNC RNC available shelf usage (R)

One 9370 RNC cabinet is composed with two shelfs. One RNC uses one shelf.
The second shelf may either be empty or used for an additional RNC.

Guideline 5.12-1: RNC available shelf usage

5.12.2 RNC SCALABILITY


When changing from a market model to another one, the parameter
numberOfServiceGroups has to be adapted (see chapters 5.7.12 and 5.7.13).

When changing to a higher market model the addition of service on the new boards
may be done without impact (see chapter 5.7.13). At the opposite when changing to a
lower market model, the service has to be stopped from the boards to be removed.
Moreover due to SS7 links management, it is advised to perform a build to redistribute
the different resources on the boards.

5.12.3 AVAILABILITY

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 222/223


UMTS RNC Product Engineering Information

Engineering Guidelines: RNC Synchronization Sources (R)

In case NodeB synchronization is brought through RNC, it is recommended to


define at the RNC level at least 2 sources (maximum is 3)

Justification: This is to provide redudancy in case of failure

Guideline 5.12-3: RNC Synchronization Sources

END OF DOCUMENT

Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization

UMT/IRC/APP/13737 06.01/EN Preliminary 07/25/2011 Page 223/223