Umt Irc App 007149 v09.01 Iub Teg Ua7.1.2 Preliminary

Iub Transport Engineering Guide
Document number:
Document issue:
Document status:
Date:
Author:
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Philippe DELMAS
External document
Copyright 2007 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..
Iub Transport, engineering guide
PUBLICATION HISTORY
External
Edition
UMTS
Release:
Date
ReasonsForChange
9.1
UA7-1-2
20/09/10
FRS79363 syncE for IP nodeB.
8.3
UA7-1-1
06/07/10
Standard Version
3.4.7: Modification: PDR/only revertive mode supported.
3.2.3.3: Add qos1 qosDt and qosBp values.
8.2
8.1
30/03/10
02/03/10
3.4.9: mod dsd=multiService

3.2.6: OLS
3.2.2.1.5 TM5, Tse2, dscp value change.
3.6.3.4.1: PTP Dscp value change
3.6.3.4.2: QueueSize, PIR, CIR values change
3.6: Add GE MDA
8.0
11/12/09
3.2.3.3 RNC CM Thresh param: upd
01/11/09
21/07/09
OLS added
3.7.7 ICMP HeartBeat: upd failure detection time.
3.6.2.2.2.1: add the qos mapping table for the 16pOC3 MS3 FP
7.2
11/06/09
7.1
26/01/09
3.6.2.1.3: add the qos mapping table for the 16pOC3 PQC FP.
Standard
3.6.2.2.3: upd, 16pOC3 MS3 FP ECMP.
3.6.10.5.1: upd, asym traffic with 1 bwPool.
7-3
UA6
7-0
02/12/08
- 3.7.7: Change, deadInterval reduced to 3 seconds

- 3.12 7670: add
- 3.5: topology update
- 3.6.10 &3.7.10: upd, transport AC
- 3.6.6 aal2Qos: add
- 3.2.10 maxDiffDelay: upd
- 3.6.9 updated
26/08/08
- Preliminary Edition.
- CM: qosDiscardThreshold formula update,
26/06/08
FRS 23479 Advanced QoS Transport Framework,

FRS 28018 Iub Alcap,
FRS 29869 RNC Dimensioning,
FRS 33334 & 33365 Iub Hybrid,
FRS 33334 NodeB Hybrid,
FRS 34105 UtranSharing,
FRS 34202 BwPool,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 3/240
- FRS 34237 RateController,

- FRS 34682 NodeB IMA Defence.
25/09/07
3.7.11: Icn: removed

3.7.3.1.1.4 and 5.1.3.2.2.1 Rnc1000, removed
5.5.2 Icn TD: removed
5.2.1.2 RNC1000 16pOC3 FP attributes: removed
3.7.2.2.1 add mapping: SC, DP to CLP
3.7.9.1.4: #Hspa vcc per Hspa BwPool rule change.
6-1
06/09/07
3.7.9+4.1.8: FRS34012 Iur Hsdpa taken into consideration by

the congestionManagement.
6-0
18/07/07
Add 3.7.9.1.4 1 IMA and 2 bwPool .

Updated with CR:
- upd of 5 with several hspa vci .
10/07/07
3.8.1.1 NodeB CEM upd

Nodeb ima defense update for IMA Hspa.
FRS 33118: nE1 & 1 IMA over iCCM,
FRS 33865,
FRS 34094: Hspa over xPcm
FRS 31830: 2 IMA groups on xCCM,
picoNodeB updates.
22/01/07
MicroNodeB: updates based on tests.
10/01/07
Hsupa, modification: one single dSRB per hsupa-hsdpa

session,
Hsupa: the xCEM card removed,
NodeB & RNC Hspa CAC corrections.
6-2
5-0
5-1
5-0
42-2
4-2
10/11/06
FRS 33767: Iub over protected atm ring,

FRS 26376: Insertion of picoNodeB atm,
FRS 33865: NodeB nE1 & 1 IMA linkGroup.
01/11/06
FRS29840: Hsupa
FRS30782: 16pOC3 MS3 FP
FRS27083: Rnc aal2Cac enhancement,
FRSxxxxx: Introduction of the atm micro NodeB,
FRS27943: NodeB IMA HoldingPriority,
FRS32602: FallBack to DCH, if hsdpa CAC rejection
29/05/06
Change the Passport Release associated to the UA4-2.

Buffer Size setting case of shaped VPC.
3.7.8.1/RNC/aal2CongestionManagement Th1 upd.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 4/240
CONTENTS
1
INTRODUCTION..........................................................................................................................11
OBJECT ..................................................................................................................................11
SCOPE OF THIS DOCUMENT .....................................................................................................11
AUDIENCE FOR THIS DOCUMENT ..............................................................................................11
2
RELATED DOCUMENTS ............................................................................................................12
3
IUB TRANSPORT NETWORK LAYER, DESCRIPTION ............................................................14
3.1
IUB TOPOLOGY .......................................................................................................................16
3.1.1
ATM Backbone:.............................................................................................................17
3.1.2
Atm ring on Iub ..............................................................................................................17
3.1.3
SDH ring........................................................................................................................18
3.1.4
Hybrid Iub ......................................................................................................................19
3.1.5
Native IP Iub..................................................................................................................20
3.2
RNC......................................................................................................................................21
3.2.1
Transport admission Control .........................................................................................21
3.2.2
TransportMap ................................................................................................................34
3.2.3
Congestion Management a.k.a rate Control .................................................................42
3.2.4
NodeB discrimination ....................................................................................................50
3.2.5
Utran Sharing ................................................................................................................51
3.2.6
OLS ...............................................................................................................................52
3.3
RNC ATM .............................................................................................................................53
3.3.1
ASIC ..............................................................................................................................53
3.3.2
FP..................................................................................................................................54
3.3.3
RNC capacity ................................................................................................................71
3.3.4
Transmission .................................................................................................................72
3.3.5
ATM interface Type .......................................................................................................83
3.3.6
atm CAC........................................................................................................................83
3.3.7
OverSubscription...........................................................................................................84
3.3.8
ATM OAM......................................................................................................................84
3.3.9
VPC, VPT ......................................................................................................................92
3.3.10 Traffic Management ......................................................................................................96
3.3.11 PNNI............................................................................................................................101
3.3.12 InverseARP .................................................................................................................104
3.3.13 Aal2 Components:.......................................................................................................107
3.3.14 Aal2 QOS ....................................................................................................................114
3.3.15 aal5 connections .........................................................................................................115
3.3.16 QOS ............................................................................................................................116
3.3.18 Alcap ...........................................................................................................................123
3.4
RNC IP................................................................................................................................126
3.4.1
FP................................................................................................................................126
3.4.2
IP hosts Utran..............................................................................................................136
3.4.3
IP Components............................................................................................................137
3.4.4
IP hosts Utran..............................................................................................................144
3.4.5
UDP port......................................................................................................................145
3.4.6
LocalMedia ..................................................................................................................146
3.4.7
Virtual Router RNC composition .................................................................................148
3.4.8
PDR.............................................................................................................................152
3.4.9
ICMP HeartBeat ..........................................................................................................155
3.4.10 QOS ............................................................................................................................157
3.4.11 Routing: .......................................................................................................................159
3.4.12 SIGTRAN/SCTP..........................................................................................................159
3.4.13 per UMTS Planes ........................................................................................................161
3.5
NODE B ATM (IBTS) ............................................................................................................163
3.5.1
Cards...........................................................................................................................163
3.5.2
PDH Layer:..................................................................................................................165
3.5.3
Synchronisation...........................................................................................................165
1.1
1.2
1.3
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 5/240
3.5.4
ATM Connections:.......................................................................................................166
3.5.5
Atm CAC .....................................................................................................................166
3.5.6
ATM OAM....................................................................................................................167
3.5.7
MultiPCM.....................................................................................................................167
3.5.8
Fractional E1/T1 ..........................................................................................................168
3.5.9
IMA ..............................................................................................................................172
3.5.10 Mix of N * E1 xPCM and p E1 IMA..............................................................................178
3.5.11 QOS ............................................................................................................................179
3.5.12 Traffic Management ....................................................................................................181
3.5.13 Hspa CAC ...................................................................................................................182
3.5.14 Alcap ...........................................................................................................................183
3.5.15 Oam, IP over Atm........................................................................................................183
3.6
NODE B IP & HYBRID (IBTS).................................................................................................184
3.6.1
NodeB Iub connectivity ...............................................................................................184
3.6.2
Ethernet.......................................................................................................................185
3.6.3
IP .................................................................................................................................188
3.6.4
UDP & TCP & SCTP ports: .........................................................................................193
3.6.5
Synchronisation...........................................................................................................194
3.6.6
SIGTRAN/Sctp ............................................................................................................197
3.6.7
DHCP ..........................................................................................................................198
3.8
MICRO NODEB ATM (BTS 1120) ...........................................................................................198
3.8.1
Transmission: ..............................................................................................................198
3.8.2
Atm: .............................................................................................................................199
3.8.3
Aal2 .............................................................................................................................201
3.8.4
SAAL: ..........................................................................................................................202
3.8.5
IP: ................................................................................................................................202
3.8.6
UMTS traffic flows: ......................................................................................................203
3.9
PICO NODEB ATM (BTS 1010) ...............................................................................................204
3.9.1
Transmission: ..............................................................................................................204
3.9.2
Atm: .............................................................................................................................204
3.9.3
Aal2: ............................................................................................................................205
3.9.4
IP: ................................................................................................................................206
3.9.5
UMTS traffic flows: ......................................................................................................206
3.10
7670....................................................................................................................................206
4
UMTS RELEASES.....................................................................................................................209
4.1
RNC....................................................................................................................................209
4.1.1
FP................................................................................................................................209
4.1.2
RNC Types:.................................................................................................................210
4.1.3
RNC capacity: .............................................................................................................210
4.1.4
Iuxif / IubIf / aal2If:.......................................................................................................211
4.1.5
Pathid: .........................................................................................................................211
4.1.6
Aal2 Path assignment to PMC-PC ..............................................................................211
4.1.7
AAL2 Link CAC: ..........................................................................................................211
4.1.8
aal2CongestionManagement ......................................................................................212
4.1.9
Icn VCC .......................................................................................................................212
4.1.10 TMU.............................................................................................................................212
4.1.11 QOS ............................................................................................................................213
4.2
NODEB ATM ........................................................................................................................213
4.2.1
CCM related: ...............................................................................................................213
4.2.2
CEM related: ...............................................................................................................213
4.2.3
MultiPCM:....................................................................................................................214
4.2.4
IMA: .............................................................................................................................214
4.2.5
n E1 xPCM + p E1 IMA: ..............................................................................................215
4.2.6
AAL1 CES ...................................................................................................................215
4.2.7
QOS ............................................................................................................................215
4.2.8
Traffic Management ....................................................................................................216
4.3
NODEB IP ............................................................................................................................217
4.4
MICRO NODEB .....................................................................................................................218
4.5
PICO NODEB ........................................................................................................................218
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 6/240
4.6
PLANE RELATIVE ...................................................................................................................218

4.6.1
UMTS HSUPA Plane: .................................................................................................218
4.6.2
UMTS HSDPA Plane: .................................................................................................218
4.6.3
UMTS OAM Plane:......................................................................................................218
4.6.4
UMTS Control Plane: ..................................................................................................218
4.6.5
UMTS User Plane .......................................................................................................219
4.6.6
Transport Network ControlPlane:................................................................................219
5
TRANSPORT IDENTIFIERS .....................................................................................................219
5.1
ATM VCC............................................................................................................................221
5.1.1
UpGrade from UA5 to UA6 .........................................................................................221
5.1.2
NodeB interface ..........................................................................................................223
5.1.3
RNC Interface..............................................................................................................225
5.1.4
PNNI............................................................................................................................230
5.2
FP ATTRIBUTES ....................................................................................................................231
5.2.1
16pOC3/Stm1 FP Attributes........................................................................................231
5.2.2
16pOC3/Stm1 MS3 (Atm/Pos) FP ..............................................................................235
5.3
IP ........................................................................................................................................235
5.4
AAL2...................................................................................................................................235
5.4.1
IubIf / aal2If..................................................................................................................235
5.4.2
Pathid: .........................................................................................................................236
5.5
IMA .....................................................................................................................................237
5.5.1
NodeB Holding Priority................................................................................................237
5.5.2
IMA LinkGroup ID:.......................................................................................................239
5.5.3
Traffic descriptor .........................................................................................................239
5.6
TRAFFIC DESCRIPTOR ...........................................................................................................239
5.6.1
Aal2 vcc TD .................................................................................................................239
5.6.2
Aal5 vcc TD .................................................................................................................241
5.7
PARAMETERS .......................................................................................................................241
5.7.1
Traffic Descriptor Type................................................................................................241
5.7.2
Parameter Class .........................................................................................................241
6
ABBREVIATIONS......................................................................................................................242
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 7/240
1 INTRODUCTION
1.1
OBJECT
This document intends to describe the Transport layers on the Iub interface.
It also provides:
- Engineering rules inserted in a red square,
- Configuration of UMTS Node Transport interfaces,
- Traffic parameters over Iub interface.
1.2
SCOPE OF THIS DOCUMENT

The document is related to the release: UA7-1-2 GlobalMarket
The variations between the releases are indicated in section 4.
UTRAN Release:
Passport Release:
UA 4-1
UA 5-0
PCR6-1
UA 5-1
PCR7-2
OAM Release:
Oam4.2
Oam5.0
Oam5.0
UA6
UA7-0
PCR8-2
UA7-1
Oam7-0
Oam7-1
This document covers:

- TRANSPORT network layers (Transmission, ATM, aal2, aal5, Alcap, ss7, IP, sigtran ) relative
to the Iub interface,
- UMTS Nodes: NodeB and RNC. OtherVendor equipments are not covered in this document.
- Impact of backhaul on the UTRAN node interfaces.
1.3
AUDIENCE FOR THIS DOCUMENT

The operators, R&D, WPS, VO, Trial, networkDesign.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 8/240
2 RELATED DOCUMENTS
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 9/240
[
[
[
[[
[[
[
[
[
[
[
[
[
[
[
[
[
[[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
1
2
3
456
798
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
]
]
]
]]
]]
]
]
]
]
]
]
]
]
]
]
]
]]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
]
UMT/IRC/APP/7149
UMT/IRC/APP/011674
UMT/IRC/APP/12509
Iub TEG
Iu TEG
Iur TEG
Addressing TEG
3GPP TS 25 430
3GPP TS 25 442
3GPP TS 34 108
3GPP TS 25.410
3GPP TS 25. 412
3GPP TS 25. 414
3GPP TS 29.060
3GPP TS 25 420 v3.5.0
3GPP TS 25.422 v3.6.0
3GPP TS 23.236 v5.4.0
3GPP TS 25.425 v3.6.0
3GPP TS 25.309 Rel6
UTRAN Iub: General Aspects and Principles

UTRAN Implementation Specific O&M Transport
RAB definition
UTRAN IU Interface: general aspects and principles
UTRAN IU Interface: Signaling transport, Rel99
UTRAN IU Interface: Data & Signaling transport
GTP
Iur general aspect and principles
Iur Signalling transport
Intra-domain connection of RAN node to multiple CN node (Release5)
Iur User Plane protocols for common Transport Channel data Streams.
FDD Enhancement Uplink, overall description, stage 2 (Release 6)
G702
G703
G707
G804
G700 to 706
Q711 to Q 714
G832
G783
G841
G775
I361
I610
I363-1
I363-2
I363-5
I732
I761
I762
Q2210
Q2931
Q2630.1
Q2630.2
E191
X213
Q2941.2
Q1970 and 1990
Q.1950
Q.765.5
Q.2150.1
G711
atmf 0055.000
af-phy-0086.000
af-phy-0086.001
af-phy-0130.00
af-ra-0105.000
af-tm-0121.000
af-vtoa-0078.000
af-cs-0173.000
af-vtoa-0113.000
PDH, Digital Hierarchy Bit Rates

PDH, Physical/Electrical Characteristics of Hierarchical Digital interfaces
Network node interface for the SDH
ATM cell mapping into PDH
MTP NarrowBand
SCCP
Transport of SDH element on PDH network
Characteristics of SDH equipments
Types & Characteristics of SDH Network Protection Architectures
LOS and AIS defect detection and clearance criteria
Specification of ATM layer for B-ISDN.
OAM for broadband ISDN
AAL1
AAL2
AAL5
Functional Characteristics of ATM Equipment
IMA
ATM over fractional physical link
MTP3 functions & messages using the services of Q2140
B-ISDN
Aal2 Signaling, capabilitySet1
Aal2 Signaling, capabilitySet2
B-ISDN numbering & addressing
Addresses
GIT
Nb interface info
Specifications of signaling related to Bearer Independent Call Control (BICC)
Application transport mechanism: Bearer Independent Call Control (BICC)
PCM of Voice Frequencies
PNNI version 1.0
IMA v1-0
IMA v1-1.
ATM on fractional E1/T1.
Addressing, userGuide. V1.0
TrafficManagement Specification.
AAL1
Domain based rerouting
Atm Trunking using Aal2 for narrowband Services
RFC 1541
RFC 2225
RFC 1629
RFC1293
RFC826
RFC1485
RFC1483
RFC2991
RFC 3331
RFC 3332
RFC 2960
RFC 3309
DHCP
IP & ARP over ATM
Guideline for OSI NSAP allocation in internet
InverseARP
ARP
IP over ATM
IP over AAL5
ECMP
SS7 MTP2 User Adaptation (M2UA) Layer
SS7 MTP3 User Adaptation (M3UA) Layer
SCTP, Stream Control
Transmission Protocol
ALU confidential
SCTP, Stream Control Transmission Protocol
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 10/240
[
[
[[
[
[
[
[
[
[[
[
[
[[
[[
[[
[
[[
[
[
[
[
[
[
[
[
[
[
[
[
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
R
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
]
]
]]
]
]
]
]
]
]]
]
]
]]
]
]]
]
]]
]
]
]
]
]
]
]
]
]
]
]
]
GR253
GR2878
Synchronous Optical Network (SONET)

ATM HSL
241-5701-705
241-5701-706
241-5701-707
241-5701-708
241-5701-702
NTP ATM TrafficManagement

NTP ATM TrafficShaping and Policing
NTP ATM Queuing and Scheduling
NTP ATM CAC and Bandwidth
NTP Routing and Signaling
UMT/IRC/APP/007147
UMT/IRC/APP/7146
PEI NodeB
PEI RNC
UMT/DCL/DD/0020
UPUG
3GPP TS 23.002
3GPP TS 23.221
3GPP TS 23.205
3GPP TS 29.205
3GPP TS 29.232
3GPP 29.414
3GPP 29.415
3GPP 29.232
R4 Network Architecture
Architectural Requirements
BICN; Stage 2
Application of Q.1900 Series to BICN Architecture; Stage 3
MGC, MG Interface, Stage 3, Release 4
CN Nb Data Transport and Transport Signaling
CN Nb interface User Plane Protocols
TFO package
[ R 150 ]
[ R 151 ]
FRS 25647
FRS 33767
aal2LinkCac evolution
Iub over protected atm ring
[ R 160 ]
[ R 161 ]
UMT_SYS_DD_023235
UMT/Sys/DD/023092
UA6_Bandwidth_Pools_FN
Hybrid Iub FN
3 IUB TRANSPORT NETWORK LAYER,

DESCRIPTION
The Utran Iub uses the services from either: ATM, IP or both ATM and IP.
Since the first UMTS releases, both UMTS userPlane and controlPlane use the services from ATM.
In UA6 has been introduced the hybrid Iub which consists in using the services from IP for the HSPA
Interactive and Background traffic whereas all other UMTS userPlane traffic and controlPlane uses the
services from ATM.
In UA7 is introduced the native IP Iub which consists in using the services from IP for both UMTS
userPlane and controlPlane.
The ALU UA7 Utran supports the three UTRAN Transport options: ATM, native IP and Hybrid Iub.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 11/240
RNL
OAM
OAM appl
appl
NBAP
NBAP
FP
FP
FP
FP
Q2630.2
Q2630.2
TCP
TCP
TNL
Q2150.2
Q2150.2
IP
IP
SSCF-UNI
SSCF-UNI
LLC/SNAP
LLC/SNAP
SSCOP
SSCOP
AAL5
AAL5
UDP
UDP
AAL2
AAL2
ATM
ATM
OAM
umts CP
IP
IP
Ethernet
Ethernet
Transport CP
UP
UP
(R99 & Hspa Str)
(Hspa I/B)
Iub TEG
Figure 3-1, Atm and Hybrid IUB Protocol stack

On the ATM interface, two different atm adaptation layers are implemented [R60, R61]:
- AAL5 format is used for signalings and oam:
- NBAP common & dedicated,
- ALCAP,
- UMTS and ATM OAM flows.
- AAL2 format is used for userPlane:
- User traffic (Voice and Data),
- NonAccessStratum signalings.
The nonAccessStratum signaling encompasses the RRC protocols:
- MM: Mobility Management,
- SM: Session Management,
- CC: Call Control,
- GMM: GPRS Mobility Management...
The SM, MM, GMM and CC non Access Stratum signaling exchanged between the UE and
the Core Network are seen as User data from the Transport network. Such information, are
carried in following channels:
- Common SRB (SignallingRadioBearer): FACH, PCH and RACH
- Dedicated SRB.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 12/240
RNL:
OAM
CP
UP
Synchro
oam
oam
NBAP
NBAP
FP
FP
PTP
PTP
TCP
TCP
SCTP
SCTP
TNL:
UDP
UDP
IP
IP
Ethernet
Ethernet
Iub TEG
Figure 3-2 native IP IUB Protocol stack

On the Native IP Iub, the UMTS userPlane uses the services from UDP; the UMTS controlPlane (NBAP)
uses the services from SCTP, the PTP uses either the services from UDP or from Ethernet
(configuration).
The IubTEG covers the Transport Network layers used by the UTRAN Iub.
3.1
IUB TOPOLOGY
Different topologies apply to the Iub interface according to:
- The RNC type: ATM RNC, Hybrid RNC or IP RNC,
- Backbone type (atm, aal2, sdh, ip, ethernet)
Below are presented some examples of network topologies on the Iub interface:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 13/240
3.1.1
ATM BACKBONE:
Iub
NodeB
E1
E1
NodeB
BTS
TDM E1
BSC
BSC
NodeB
TDM E1
NodeB
IMA
N*E1
7670
7670 ESE
ESE
NodeB
7670
7670 ESE
ESE
N*E1
oc3/stm1
RNC
RNC
N*E1
NodeB
N*E1
NodeB
7670
7670 ESE
ESE
N*oc3/stm1
NodeB
NodeB
NodeB
IMA
N*E1
IMA
N*E1
7670
7670 ESE
ESE
ATM
ATM
Backbone
Backbone
N*E1
NodeB
NodeB
Figure 3-3 Iub topology

The atm backbone that provides connectivity on Iub interface might be either a UMTS/UTRAN dedicated
atm backbone or a third party atm Service Provider Network (ASP).
Within the above topology the POC (Point of Concentration) function is achieved by atmSwitches e.g.
ALU7670 ESE or 7670 RSP.
Morever the atmSwitches are used for transmission links adaption as long as the nodeB is populated with
E1 whereas the RNC is populated with stm1/oc3 cleraChannel accesses.
The 7670 RSP provides a high capacity atm switching for large size atm backbone and all the sdh
hierarchy access rates from stm1/oc3 to stm16/oc48 either clearChannel or channelized nevertheless no
support for pdh link. The 7670 RSP has been specified to fulfil the backbone core services.
The 7670 ESE has been specified to fulfil the backbone edge services, the 7670 supports both pdh and
sdh access up to stm4/oc12, IMA E1/T1.
When the iub downLink traffic is policed within the atm backbone by exercising UPC, it is recommended
to shape the atm connection within an UMTS operator atmSwitch collocated to the RNC in such a way
the UMTS traffic submited to the atm backbone is conformed to the expected throughput.
3.1.2
ATM RING ON IUB

[R151]
The Iub Network is composed of NodeB, atmSwitches, RNC and a SDH channelized ring.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 14/240
Each nodeB is populated with a small capacity atmSwitch supporting pnni .

The Iub topology consists in several atm rings. An atm ring is composed of up to 10 nodeB.
The securisation of the nodeB atm connections is provided by the pnni. Indeed for each NodeB
atmConnection, two different paths are available. In case of failure of the path supporting the NodeB
atmConnections, the PNNI Rerouting feature allows re-establishment of the NodeB atmConnections on
the alternative path.
The 7670RSP provides transmission adaptation between stm1 channelized links and stm1 clearChannel
links available on the RNC 16pOC3/Stm1 FP. Moreover the 7670RSP acts as a point of concentration,
since it aggregates the traffic received from different atm rings through stm1 channelized links, to a lower
number of stm1 clearChannel accesses. Furthermore the 7670RSP is the point of termination of the Pnni
atm connections initiated in the small capacity atmSwitches located in the nodeB, indeed the RNC is not
involved in the PNNI network, all its CPU capacity is then dedicated to UMTS processing.
Src
Pnni sPvc
PVC
nodeB1
nodeB1
atmSwitch
atmSwitch
IMA
E1
Src
E1
Dst
AESA
IMA
ADM
ADM
nodeB2
nodeB2
atmSwitch
atmSwitch
Atm loop
E1
IMA
nodeB3
nodeB3
E1
IMA
Src
atmSwitch
atmSwitch
Stm1
ADM
ADM
vc12
ADM
Stm1
ADM
Vc4
Vc12
7670
7670
RSP
RSP
RNC
RNC
Stm1
Vc4
Pnni sPvc,
alternative path
Figure 3-4 Atm ring topology on Iub
3.1.3
SDH RING
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 15/240
IMA /1
nodeB
nodeB
nodeB
nodeB
nodeB
nodeB
nodeB
nodeB
nodeB
nodeB
IMA /2
N * E1
Stm1
Vc4/Vc12
Sdh
Sdh
CC
CC
Stm1
63 vc12
Stm1
Vc4/Vc12
7670
7670
ESE
ESE
ADM
ADM
Stm1/oc3
Vc4
Stm1/oc3
Vc4/Vc12
ADM
ADM
RNC
RNC
7670
7670
RSP
RSP
RNC
RNC
Stm1/oc3
Vc4
N * E1
ADM
ADM
N * E1
7670
7670
ESE
ESE
Stm1
Vc4/Vc12
Figure 3-5 Sdh ring with IMA on the Iub

The Iub topology is composed of atm switches and sdh add&Drop Multiplexer.
A sdh ring is inserted between the atmSwitches to provide path resiliency.
The E1 granularity is maintained from the nodeB, through the sdh ring and up to the 7670 RSP.
On each atm interface, as an option the E1 are gathered within an IMA group.
The 7670 RSP achieves the Interworking between the channelized sdh links and the clearChannel sdh
links toward the RNC.
3.1.4
HYBRID IUB
The RNC is connected to an atm backhaul and to either IP or Ethernet backhaul.
Only Hspa interactive and background traffic may be transmitted through the RNC IP interface.
On the RNC ATM interface are transmitted: Signaling, oam, R99, Hspa streaming and as an option Hspa
I/B traffic.
On the NodeB side, the ATM traffic is handling either on multiPcm or IMA.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 16/240
R99 traffic,
Signaling,
Oam
Hspa stream.
Hspa I/B (opt)
RNC
RNC
CS
CS core
core
RNC
RNC
OC3
OC3
ATM
ATM
Backbone
Backbone
OC3
OC3
OC3
OC3
ATM
ATM
Backbone
Backbone
SGSN
SGSN
OC3
OC3
NodeB
NodeB
GE
GE GE
GE
SGSN
SGSN
IP
IPBackHaul
BackHaul
Hspa I/B
ATM
ATM
Backbone
Backbone
SGw
SGw
SGSN
SGSN
TEG
Figure 3-6 Hybrid Utran topology

The IP backhaul is composed of IP routers and may also be composed of ethernet switches. For resiliency
reason, the iub backhaul must not be a pure layer 2 network, indeed in such a way to be able to rely on the
PDR RNC robustness mechanism, at least one IP router must be present in the Iub backhaul:
Rule: IubTEG_Topology_
The Iub backhaul must include of at least one IP router
3.1.5
NATIVE IP IUB
Both the Iub controlPlane and userPlane use the services from IP.
On the RNC side the Iub traffic is transmitted over one port from the 4pGE FP.
On the NodeB side the traffic is transmitted over a fastEthernet link or over a gigaEthernet link .
The nativeIP nodeB are reachable from the RNC through either an IP backbone or Ethernet backbone. In
case of ethernet backbone on the Iub, at least one IP router is present in the backbone to satisfy PDR.
Beside the RNC is able to support hybrid and atm nodeB if populated with 16 pOC3 FP together with the
4pGE FP:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 17/240
SGSN
SGSN
NodeB
NodeB
MGC
MGC
MGw
MGw
ATM
ATMBackbone
Backbone
NodeB
NodeB
MGw
MGw
utran over ATM
OC3
OC3
RNC
RNC
OC3
OC3
NodeB
NodeB
cc
RNC
RNC
NodeB
NodeB
GE
GE GE
GE
SGSN
SGSN
utran over IP
MGC
MGC
MGw
MGw
router
router router
router
NodeB
NodeB
IP/Ethernet
IP/EthernetBackBone
BackBone
NodeB
NodeB
MGw
MGw
Iub
IuCS, Iur & IuPS
RNC
RNC
TEG
Figure 3-7,Utran over atm or IP
3.2
RNC
This section is related to the RNC transport features applying to both the RNC atm and ip interfaces (atm
RNC, hybrid RNC and ip RNC).
The atm RNC is populated with two 16pOC3/Stm1 FP. The RNC provides atm accesses to all the utran
interfaces.
The hybrid RNC is populated with both the 16pOC3/Stm1 FP and the 4pGE FP. The hybrid RNC
provides:
- ATM interface for the Iub R99 UP, CP, oam, Streaming over hs-dsch, Streaming over e-dch
and as an option hspa traffic I/B flows and
- IP interface for the Iub hspa I/B traffic flows as an option,
- ATM interface for the IuCS, Iur and as an option IuPS interfaces,
- IP interface for the IuPS interface as an option.
The IP RNC is populated with two 4pGE FP. The RNC provides IP interfaces to all the utran interfaces.
3.2.1
TRANSPORT ADMISSION CONTROL

Ref: [R160]
The transport admissionControl is invoked at call establishment time. It consists in checking that the
bandwidth required for the call is available on the nodeB interface.
Moreover on the atm interface, the transport admissionControl achieves a load balancing over the
different available aal2 paths under the aal2If.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 18/240
3.2.1.1 EQUIVALENT BIT RATE

The configured equivalentBitRate (EBR) is an estimation of the bandwidth consumed by a rab at RNL
layer.
One EBR value is configured per:
- Rab,
- Direction (UL/DL)
- utran interface (with exception of the IuPS),
- THP as an option.
When configuring the EBR, the Transport overhead must not be taken into consideration. On
admissionControl invokation, the RNC adds a transport overhead ratio value to the EBR corresponding to
the type of transport. The transport overhead ratio applied by the RNC is hardcoded and depends on the
transport type:
- ATM: 21% overhead is added to the EBR.
- IP: 15% overhead is added to the EBR.
Rule: Iub_RNC_AC_1
The configured EBR must not take into account the transport overhead.
When configuring the admissionControl a maxBitRate (MBR) and a rbSetQos values are also assigned
per RAB/direction/interface. The RbSetQos values is an imput parameter for the transportMap
(see3.2.2).
The configured EBR value is taken into consideration by the admissionControl during radioBearer
establishment phase when selecting a bwPool.
admissionControl
- Iux: iubif, iurif or iucsif
Iux + RAB (+THP option)
Identification of the ulRbSetConf and the dlRbSetConf within

the radioAccessService table.
Per direction (UL and DL) and

Per interface (Iub, Iur and Iucs):
cacTransportInfoList (i) Iux FpEquivalentBitRate (EBR)
cacTransportInfoList (i) Iux FpMaxBitRate
(MBR)
cacTransportInfoList (i) Iux TransportQosId
(rbSetQos)
TransportMap
admCtrl, bwPool selection
TEG
Figure 3-8 admissionControl, EBR configuration
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 19/240
DlRbSetConf:
cacTransportInfoList[MAX_NB_REF_AMR_BIT_RATE=8]
cacTransportInfoList(i ). iubFpEquivalentBitRate
cacTransportInfoList(i ). iubFpMaxBitRate
[0..16777216], Step 1, Unit bit/s

[0..16777216], Step 1, Unit bit/s
cacTransportInfoList(i ).
iurFpEquivalentBitRate
iurFpMaxBitRate
[0..16777216], Step 1, Unit bit/s

[0..16777216], Step 1, Unit bit/s
iuFpEquivalentBitRate
iuFpMaxBitRate
[0..16777216], Step 1, Unit bit/s

[0..16777216], Step 1, Unit bit/s
iubIurTransportQosId
iuTransportQosId
cacTransportInfoInstanceCharacteristic
Integer [0..3]
[0..3] step 1
enum {AMR_12_2, AMR_10_2, AMR_7_95, AMR_7_4,
AMR_6_7, AMR_5_9, AMR_5_15, AMR_4_75,
interactive THP=0, interactive THP=1,
interactive THP=2, interactive unspecifiedTHP,
backGround, SRB_ON_HS_DSCH, SRB_ON_DCH, UnSpecified }
UlRbSetConf:
cacTransportInfoList[MAX_NB_REF_AMR_BIT_RATE=8]
cacTransportInfoList(i ). iubFpEquivalentBitRate
cacTransportInfoList(i ). iubFpMaxBitRate
[0..16777216], Step 1, Unit bit/s

[0..16777216], Step 1, Unit bit/s
iurFpEquivalentBitRate
iurFpMaxBitRate
[0..16777216], Step 1, Unit bit/s

[0..16777216], Step 1, Unit bit/s
iuFpEquivalentBitRate
iuFpMaxBitRate
[0..16777216], Step 1, Unit bit/s

[0..16777216], Step 1, Unit bit/s
iubIurTransportQosId
iuTransportQosId
cacTransportInfoInstanceCharacteristic
Integer [0..3]
[0..3] step 1
enum {AMR_12_2, AMR_10_2, AMR_7_95, AMR_7_4,
AMR_6_7, AMR_5_9, AMR_5_15, AMR_4_75,
interactive THP=0, interactive THP=1,
interactive THP=2, interactive unspecifiedTHP,
backGround, SRB_ON_HS_DSCH, SRB_ON_DCH, UnSpecified }
FACH (Nodeb.FDDCell.SCCPCH.FACH)
cacTransportInfo.
dlCacTransportInfo.fpEquivalentBitRate
cacTransportInfo.
dlCacTransportInfo.fpMaxBitRate
cacTransportInfo.
ulCacTransportInfo.fpEquivalentBitRate
cacTransportInfo.
ulCacTransportInfo.fpMaxBitRate
PCH (Nodeb.FDDCell.SCCPCH.PCH)
cacTransportInfo.
cacTransportInfo.
cacTransportInfo.
cacTransportInfo.
RACH (Nodeb.FDDCell.RACH)
cacTransportInfo.
cacTransportInfo.
cacTransportInfo.
cacTransportInfo.
[0..16777216],
[0..16777216],
[0..16777216],
[0..16777216],
Step 1, Unit bit/s

Step 1, Unit bit/s
Step 1, Unit bit/s
Step 1, Unit bit/s
[0..16777216],
[0..16777216],
[0..16777216],
[0..16777216],
Step 1, Unit bit/s

Step 1, Unit bit/s
Step 1, Unit bit/s
Step 1, Unit bit/s
[0..16777216],
[0..16777216],
[0..16777216],
[0..16777216],
Step 1, Unit bit/s

Step 1, Unit bit/s
Step 1, Unit bit/s
Step 1, Unit bit/s
Table 3-1, equivalentBitRate and maxBitRate

Rule: Iub_RNC_AC_2
Either one set of EBR values is configured for the interactive trafficClass or three set of EBR
values are configured for the Interactive trafficClass, one set of EBR values per THP.
On both the Iub and the Iur interfaces, the EBR for the streaming trafficClass over Hsdpa or Hsupa, is
derived from the received Ranap GBR and from the HsdpaTransportEbrCorrectiveFactor /
EdchTransportEbrCorrectiveFactoparameter values configured against the streaming trafficClass:
Hsdpa streaming EBR = f (GBR * HsdpaTransportEbrCorrectiveFactor).
Edch streaming EBR = f (GBR * edchTransportEbrCorrectiveFactor).
Parameter: RNC/radioAccessService//HspaTransportEbrCorrectiveFactor range: [0, 200%].
If HspaTransportEbrCorrectiveFactor = 0%, then EBR=0 the admissionControl doesnt apply to the
stream.
Remark: The EBR is configured for the R99 Streaming.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 20/240
The Operator ensures the consistency of the configured EBR value based on his desired allocation
strategy.
3.2.1.2 INTERFACE BANDWIDTH

On the atm interface, the admissionControl calculates the aal2path bandwidth for each direction based on
the configured UL and DL vcc trafficDescriptor and the genericCAC algorithm:
- Cbr vcc, ECRgcac = PCR c/s
- Vbr vcc, ECRgcac = 2*PCR*SCR/(PCR+SCR) c/s
- Ubr+ vcc, ECRgcac = MDCR c/s,
- Ubr vcc, ECRgcac = 0.
On the ip interface, the admissionControl calculates the ipFlow bandwidth based on the configured UL
and DL ipFlow peak and committed rates and the generic CAC algorithm:
ERgcac = 2*CR*SR/(PR+SR) kb/s
- Cacm:
The bandwidth granulary that the admissionControl takes into consideration for the regulation is
configured through the cacm parameter.
The cacm parameter is configured against an aal2if and an ipIf component, and applies to all the
bwPools under the aal2If and the ipIf components.
aal2If i
cacm
ipIf i
cacm
BwPool/x
BwPool/y
qosnBwReservation
qos 0
path
path
qos 1
path
path
qos 2
path
path
qos 3
path
path
iubIf 1
SignalingBearer
userPlane
aal2LinkToaal2if: aal2If i
ipLinkToIpif: ipIf i
BwPool/y
qosnBwReservation
qos 3
path
path
qosnBwReservation
IP Flow, qos3
congestionManagement i
transportMap j
congestionManagement n
transportMap m
congestionManagement x
transportMap y
TEG
Figure 3-9, admissionControl attributes

Cacm parameter value range: [aal2If, ipIf, qos, aal2path].
- On the atm interface, the admissionControl supported granularities are: bwPool, aal2Qos and
aal2Path.
- On the ip interface, the admissionControl supported granularities are: ipIf, qos (equivalent to ipFlow
as long as one qos per ipFlow).
Rule: IubTEG_RNC_AC_3
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 21/240
It is recommended to regulate the traffic at bwPool level:

- Cacm= aal2if, for the atm interface,
- Cacm= ipIf, for the ip interface.
Remark:
- Cacm=Qos is reserved for specific contexts. When a fraction of bandwidth configured
against a specific qos stream has not to be shared with other qos streams, the
admissionControl is set with cacm=qos and qosnbwReservation= x %.
- It is not recommended to set cacm=aal2path on the Iub interface. This value as an option may
be requested on the IuCS when interworking with otherVendor coreNetwork nodes.
- Cacm = aal2If: The availableBandwidth taken into consideration by the admissionControl is the
calculated total bandwidth per bwPool and per direction,
E.g.: 2 bwPools under one aal2If then:
bwPool1 UL availableBandwidth = vcc / bwPool1 UL ECRgcac,
bwPool1 DL availableBandwidth = vcc / bwPool1 DL ECRgcac,
bwPool2 UL availableBandwidth = vcc / bwPool2 UL ECRgcac,
bwPool2 DL availableBandwidth = vcc / bwPool2 DL ECRgcac.

Remark: If one single bwPool under the aal2If, then cacm=aal2If availableBandwidth has same
definition as in previous releases.
- Cacm = Path: The availableBandwidth taken into consideration by the admissionControl is the
bandwidth per aal2Path and per direction,
aal2Path UL availableBandwidth = vcc UL ECRgcac,
aal2Path DL availableBandwidth = vcc DL ECRgcac.
- Cacm = Qos: The availableBandwidth taken into consideration by the admissionControl is the
calculated total bandwidth per bwPool, per qos and per direction.
The cacm qos value applies to both the atm and the ip interfaces.
- Cacm = ipIf: The availableBandwidth taken into consideration by the admissionControl is the
calculated total bandwidth per bwPool and per direction,
E.g.: 1 bwPools under one ipIf then:
bwPool UL availableBandwidth = ipFlow / bwPool UL ER,
bwPool DL availableBandwidth = ipFlow / wPool DL ER.
- qosnBwReservation:
The qosnBwReservation parameters are either configured against the bwPool component or against
the aal2If then apply to all the bwPool under the aal2If.
The qosnBwReservation parameter value is taken into consideration by the admissionControl on both
downLink and upLink.
When setting the qosnBwReservation with a non zero value and cacm=qos, the admissionControl
takes into consideration an additional bandwidth portion available for all the qos within a bwPool. The
common for all qos bandwidth portion is taken into consideration by the admissionControl on qos i
call establishment when the qos i availableBandwith is exausted.
The qosnBwReservation is applicable only if cacm=qos.
In case of atm interface, the availableBandwidth is the sum of the bandwidth of all the vcc for one
aal2Qos within a bwPool, assuming one bwPool under an aal2If then:
Per qos available bandwidth:
bwPool UL qos i availableBw = qosiBwReservation * bwPool qos i vcc UL ECRgcac,

ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 22/240
bwPool DL qos i availableBw = qosiBwReservation *bwPool qos i vcc DL ECRgcac.

Common for all qos available bandwidth:
bwPool UL common qos availableBw = qosi (100%-qosiBwReservation) * bwPool qos i

vcc UL ECRgcac, with i = [0, 1, 2, 3].
bwPool DL common qos availableBw = qosi (100%-qosiBwReservation) * bwPool qos i

vcc DL ECRgcac, with i = [0, 1, 2, 3].
aal2If i
bwPool x
Available bw =3200 c/s
Cacm = qos
qos0BwReservation=60%
BwPool/x
qos 0
Path, ul/dl ECRgcac=1000 c/s
qos0 = 600 c/s

qos1 = 600 c/s
qos2 = 600 c/s
qos3 = 200 c/s
qosx = 1200 c/s
qos 1
bwPool y
qos 2
qos 3
BwPool/y
qos 3
qos3 = 2000 c/s
Figure 3-10, cacm=qos for atm Rnc
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 23/240
BwPool/x
qos 0 Path, ul/dl ECRgcac=1000 c/s
qos 1
qos 2
qos1 = 600 c/s

qos2 = 600 c/s
qos3 = 200 c/s
qosx = 1200 c/s

ipIf i
Cacm = qos
BwPool/y
qos 3
ipFlow, ul/dl ERgcac=10000 kb/s
TEG
bwPool y
Available bw =10000 B/s
qos 3
qos0 = 600 c/s
bwPool x
aal2If i
Cacm = qos
qos3 = 10000 kb/s
Figure 3-11, cacm=qos for hybrid Rnc

In case of ip interface, the availableBandwidth is the sum of the bandwidth of all the ipFlows within a
bwPool:
Per qos available bandwidth:
bwPool UL qos i availableBw = qosnBwReservation * qos i ipFlow UL ECRgcac,
bwPool DL qos i availableBw = qosnBwReservation * qos i ipFlow DL ECRgcac.
Common for all qos available bandwidth:
bwPool UL common qos availableBw = qosi (100%-qosnBwReservation) * qos i ipFlow

UL ECRgcac, with i = [0, 1, 2, 3].
bwPool DL common qos availableBw = qosi (100%-qosnBwReservation) * qos i ipFlow

DL ECRgcac, with i = [0, 1, 2, 3].
In such a way qosnBwReservation > 0% is effective then:
- a non nul bandwidth must be assigned to the qosn ipFlow or aal2 Path.
Remark: Case of atm interface, a non nul bandwidth must be assigned to the qos3 vcc, therefore the ubr
serviceCategory must not be assigned to the qos3 vcc, preferred ubr+ (MDCR), nrtVbr...
3.2.1.3 ALGORITHM
At each radioBearer establishment, per direction, the admissionControl is invoked to determine the
preferred bwPool and to assign the resources.
The bwPool is selected by the admissionControl according to the algorithm:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 24/240
admCtrl, bwPool selection

INPUT: iubIf (ipIf or aal2If), PLMN-Id, RbType, TC, THP, ARP-PL, RbSetQos, EBR.
bwPool identification:
i
Within ipIf and aal2If, identification of all the bwPools set with:
OutPut:
plmnId = received plmnId and with plmnId =0.
selected bwPools
Bw check:
- If cacm = aal2If / ipIf, check that bwPool ul/dl AR > ul/dl EBR,
ii
- If cacm = qos, check that bwPool qosi ul/dl AR > ul/dl EBR.
- TM identification: Identification of the TM linked to the selected bwPools.
- bwPool selection: select a bwPool :
Linked to TM with TSE matching the input (TC, THP, ARP-PL, rbSetQos, rbType (optional)).
iii
If optional rbType = HS-dsch:
- MorePref: ulDlPref = dlPref and ulDlPref

- LessPref is given to noPref and ulPref
If optional rbType = E-dch:
- MorePref: ulDlPref = ulPref and ulDlPref,

- LessPref: ulDlPref = noPref and dlPref
MorePreferred bwPool: the one with more available bw.

Resource assignment from the bestBwPool and update the bwPool (qos) AR:
=> aal2If: Cid/path assignment, ipIf: PMC-PC IP@ and UDP port
iv
TEG
Figure 3-12, admissionControl, bwPool selection
When selecting the bwPool, the admissionControl takes into consideration:
The PLMN Id configured against the bwPool (utranSharing case),
The cacm option,
The ulDlPreference configured against the TSE within the transportMap (asymmetrical
traffic handling case),
The available bandwidth.
Remark: the admissionControl doesnt take into account the Preference attribute within the
transportMap.
BwPool selection ulDlPreference involvement (case of asymmetrical traffic handling):
The admissionControl takes into consideration the optional received rbType EI and the
ulDlPreference attribute within the transportMap:
If rbType = HS-Dsch:
The tse set with dlPref and ulDlPref are more preferred,
The tse set with noPref and ulPref are LessPreferred,
If rbType = E-Dch:
The tse set with ulPref and ulDlPref are more preferred,
The tse set with noPref and dlPref are LessPreferred,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 25/240
rBType = hsDpa
First choice
Second choice
rBType = hsUpa
First choice
Second choice
ulDlPreference:
Comment:
dlPref
ulDlPref
If no dlPref configured.
dlPref & ulDlPref
If both dlPref and ulDlPref configured.

Traffic spreading between the bwPools according to the available DL bw.
ulPref
If not enough bw within the first choice bwPool.
ulPref & noPreference

If both ulPref and noPreference configured.
HsDpa distributed amongst the 2 bwP according to the available DL bw.
ulDlPreference:
Comment:
ulPref
ulDlPref
If no ulPref configured.
ulPref & ulDlPref
If both ulPref and ulDlPref configured.

Traffic spreading between the bwPools according to the available UL bw.
dlPref
dlPref & noPreference

If both dlPref and noPreference configured.
HsUpa distributed amongst the 2 bwP according to the available UL bw.
Figure 3-13 ulDlPreference involvement in bwPool selection

BwPool selection, availableBw/EBR involvement:
If two or more BwPools have same preference according to the previous rule then:
The bwPool with most DL bandwidth is selected in case of rbType = HS-Dsch,
The bwPool with most UL bandwidth is selected in case of rbType = E-Dch,
The bwPool with most available bandwidth is selected in case of rbType=dch (or no
rbType):
if DL EBR > UL EBR, chose BwPool with more available BW in DL,
if UL EBR > DL EBR,, chose BwPool with more available BW in UL.
If the radioBearer is accepted, the bwPool available bandwidth is reduced by the equivalentBitRate. Else
the call is rejected, the available bandwidth remains unchanged.
3.2.1.4 TRAFFICMEASUREMENT
NT_UL_Watermark_EBR_Aal2If
- Type: cumulative,
- Granularity: qos,
- Definition:
Watermark of allocated uplink EBR during the CAC (reported by TRM) expressed in percentage
of the total bandwidth pool capacity.
The purpose is to look for a trend. For example if the High watermark is consistently very high,
obs period after the period, it means that this one BW pool gets selected very often.
NT_UL_WaterMark_EBR_IpIf
- Type: cumulative,
- Granularity: qos,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 26/240
Definition:
NT_DL_Watermark_EBR_Aal2If
- Type: cumulative,
- Granularity: qos,
- Definition:
NT_DL_WaterMark_EBR_IpIf
- Type: cumulative,
- Granularity: qos,
- Definition:
3.2.1.5 APPLICATION CASES

The objective of this section is give some examples of traffic handling according to the setting
of the RNC admissionControl. Focus is given to the asymmetrical traffic handling.
3.2.1.5.1 1 IMA GROUP, 1 BWPOOL AND ASYMETRICAL TRAFFIC HANDLING

The nodeB is populated with one IMA group. On the RNC side one single bwPool is associated
to the NodeB IMA group. The Hsdpa and Hsupa flow are transported over different paths within
the backbone, e.g.: the hsdpa traffic is transported over adsl link whereas the R99 and Hsupa
traffic transported over sdsl lines.
Configuration:
The hs-dsch and e-dch iubFpEquivalentBitRate must be configured with non nul values.
Within a sharedForAllTrafficTypes bwPool, the qos3 vcc trafficDescriptor vcc are set in such a
way only downlink bandwidth is reserved for some qos3 vcc whereas only uplink bandwidth is
reserved for some others qos3 vcc. The qos3 vcc with downlink reserved bandwidth are going
to be selected by the admissionControl for hs-dsch legs whereas the qos3 vcc with uplink
reserved bandwidth are going to be selected for e-dch legs.
For the example is considered:
- Backbone bandwidth:
o A bandwidth equivalent to 2 E1 is provided by the sdsl leg. The
atmSwitches within the backbone switch the R99, hsupa, signaling and oam
traffic over the sdsl leg.
o A bandwidth equivalent to 3 E1 is provided by the adsl leg. The
atmSwitches within the backbone switch the hsdpa traffic over the adsl leg.
- NodeB bandwidth:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 27/240
The nodeB is populated with an IMA group composed of 5 E1.

Atm vcc:
- 3 hsdpa qos3 vcc:
o On the RNC side, is reserved a DL bandwidth equivalent to 95%*E1 and
no UL bandwidth to each Hsdpa vcc.
o On the nodeB side, different HoldingPriority values assigned to each
Hsdpa vcc.
- 1 hsupa qos3 vcc and 1 qos2 vcc:
o On the RNC side, is reserved an UL bandwidth equivalent to 95%*E1
and no DL bandwidth to the Hsupa vcc. The Hsupa is coupled with one
qos2 vcc for which is reserved a DL bandwidth equivalent to 95%*E1
and no UL bandwidth.
o On the nodeB side, the same HoldingPriority value is assigned to both
the Hsupa vcc and the qos2 vcc.
- 1 qos0 and 1 qos2 vcc:
o On the RNC side, is reserved a UL/DL bandwidth equivalent to 95%*E1
to the set of qos0 and qos2 vcc.
o On the nodeB side, the same HoldingPriority is assigned to both the qos0
vcc and the qos2 vcc.
- And signaling and oam vcc.
RNC CAC and CM: Cacm=qos and qos3bwReservation=100%
Test configuration values:
RNC provisioning
Vcc
#
Radio
Type
QoS
BW
ATM SC
Reserv
DCH
rtVBR
DCH
nrtVBR
HSUPA
DCH
100%
nrtVBR
nrtVBR
RNC ATM tx
PCR
SCR
4490
900
4490 1999
1
4490 4063
MBS/ ECR per

MDCR
VCC
20
1499
30
2766
30
4266
Backhaul
RNC ATM rx
ECR per
HP
4266
4267
PCR
SCR
4490
900
MBS / ECR per

ECR
MDCR
VCC
per HP
20
1499
4490 1999
30
2766
4490 4062
40
4265
4266
4266
xDSL
SDSL
SDSL
SDSL
SDSL
NodeB
HP
1
2
HSDPA
100%
UBR+
4490
4266
4266
4266
ADSL
HSDPA
100%
UBR+
4490
4266
4266
4266
ADSL
HSDPA
100%
UBR+
4490
4266
4266
4266
ADSL
Qos
PCR
UBR1
8980
UBR
8980
UBR+3
8980
UBR
8980
SCR
227
UBR+3 13470 227

UBR+3 13470 227
UBR+3 13470 227
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 28/240
admissionControl: Hs-dsch & E-dch IubFp EquivalentBitRate > 0

aal2If i
Cacm=qos
TransportMap x
interfaceType: Iub,
preference: sharedForAllTrafficTypes
BwPool/x
qosxbwReserv = 0%
qos3bwReserv = 100%
tse i: I/B, rbSetQos2, => qos3

tse j:
DL qosx ECR = 4266
qos x
path
UL qosx ECR = 4266
qos 3
3 hsDpa path
1 hsUpa path
UBR+, rx&tx tdt=9, rxTD= 0-0-0-0-0, txTD= 4490-0-4063-0

nrtVbr, rx&tx tdt=9, rxTD= 4490-0-4062-40, txTD= 1-0-1-1-0
sdsl qos0 vcc, qos 2 vcc, HsUpa qos3 vcc

BwPool/x
atm
atm
atm
atm
adsl
IMA 5 E1
RNC
RNC
NodeB
NodeB
(Option: qos1 vcc)
Stm1
HsDpa qos3 vcc
TEG
Figure 3-14 1 IMA, 1 bwPool and asymmetrical traffic
Remarks:
- As long as one single bwPool handling the qos3 traffic, it is not necessary to set the
transportMap/Tse/ulDlPref parameter.
- 95% of each nodeB E1 is reserved for the userPlane traffic. 5% of each nodeB E1 remains
available for the controlPlane.
- Hsupa serviceCategory set either with ubr+ or nrtVbr.
Both ubr+ and nrtVbr allow reserving bw for the Hsupa vcc at the admissionControl and
congestionManagement level.
- The nrtvbr / TDT= 6 not accept 0 /0 /0, reason why set with 1/1/1.
Expected behaviour:
hsDpa traffic:
The hs-dsch traffic is assigned to a qos3 vcc within the sharedForAllTrafficTypes
bwPool x.
Within the bwPool x, a qos3 vcc with the most available downLink bandwidth is
selected.
The hs-dsch leg is accepted if the bwPool x available bandwidth is higher than the hsdsch overhead*iubFpEquivalentBitRate.
hsUpa traffic:
The e-dch traffic is assigned to a qos3 vcc within the sharedForAllTrafficTypes
bwPool x.
Within the bwPool x, a qos3 vcc with the most available upLink bandwidth is
selected.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 29/240
The e-dch leg is accepted if the bwPool x available bandwidth is higher than the e-dch
overhead*iubFpEquivalentBitRate.
3.2.1.5.2 1 IMA + 1 E1, 2 BWPOOLS, ASYMMETRICAL TRAFFIC

The nodeB is populated with one IMA group and 1 E1.
On the RNC side one bwPool is associated to the NodeB IMA group and a second bwPool is
associated to the NodeB E1. The Hsdpa and Hsupa flow are transported over different paths
within the backbone, e.g.: the hsdpa traffic is transported over adsl link whereas the R99 and
Hsupa traffic transported over leased lines.
admissionControl: Hs-dsch & E-dch IubFpEquivalentBitRate > 0

aal2If i
cacm=aal2if
TransportMap x
BwPool x
qos 3
4 hsDpa path
BwPool y
qos 3
1 path
qos 2
1 path
qos 1
1 path
qos 0
1 path
preference: primaryForTrafficType
tse i: I/B, rbSetQos2, , ulDlPref = dlPref => qos3
UBR+, rx&tx tdt=9, rxTD= 4490-0-4490-0, txTD= 4490-0-4490-0
TransportMap y
UBR, rx&tx tdt=1

nrtVbr, rx&tx tdt=6
rtVbr, rx&tx tdt=6
cbr, rx&tx tdt=1
leasedLines
tse: Conv, rbSetQos0, => qos0
tse: Str, rbSetQos1&2, => qos1
tse: I/B, rbSetQos1, => qos2
tse: I/B, rbSetQos2, , ulDlPref = ulDlPref => qos3
qos0, 1, 2 , 3 vcc
BwPool y
aal2If i
4 qos3 vcc
BwPool x
Stm1
IMA 4 E1
ADSL
ADSL
Eth
RNC
RNC
NodeB
NodeB
E1
1 qos3 vcc
1 qos2 vcc
1 qos1 vcc
1 qos0 vcc
qos 3 vcc
TEG
Figure 3-15, 1 IMA + 1 E1, 2 bwPools, asymmetrical traffic
Expected behaviour:
HsDpa traffic:
The traffic hs-dsch is spead over the qos3 vcc from the primaryForTrafficType
bwPool x AND the sharedForAllTrafficTypes bwPool y, according to the available
downLink bandwidth.
The hs-dsch leg is accepted if the selected bwPool available bandwidth is higher than
the hs-dsch overhead*iubFpEquivalentBitRate.
HsUpa traffic:
The traffic e-dch is assigned first to a qos3 vcc within the sharedForAllTrafficType
bwPool y.
The bwPool y is composed of the bw from qos1 and qos2 vcc.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 30/240
In case of bandwidth exhaustion within the bwPool y, the e-dch traffic is assigned as a
second choice to the primaryForTrafficType bwPool x.
The e-dch leg is accepted if the bwPool x available bandwidth is higher than the e-dch
overhead*iubFpEquivalentBitRate.
3.2.2
TRANSPORTMAP
The TransportMap realizes Classification for atm and ip interfaces and moreover Marking for the ip
interface:
- Classification:
- Up to 4 umts streams are supported called: qos0, qos1, qos2 and qos3,
- The classification is achieved based on the Umts qos information: trafficClass, RbSetQos,
ARP-PL, THP,
The congestionManagement applies per qos stream.
- Marking:
- A DSCP value is assigned per umts stream identified by the umts qos information:
trafficClass, RbSetQos, ARP-PL, THP.
The transportMap is the way to configure the umts to Transport qos mapping table on the RNC Iub, Iur
and IuCS over ip interfaces. The transportMap doesnt apply on the RNC IuPS interface.
Several transportMap tables may be configured within the RNC.
Rule: IubTEG_RNC-TMap_1
The RNC may be configured with up to 64 transportMap components.
A transportMap is linked either to an ipIf bwPool, an aal2if bwPool or an aal2If (as long as no bwPool
configured under the aal2if, case of IucsIf or IurIf). One TransportMap may be shared between several
instances of ipIf bwPool, aal2If bwPool and aal2If, may also be shared between different utran interfaces.
Remark: No transportMap linked to ipFlow, aal2Path or iuPS components.
Rule: IubTEG_RNC-TMap_2
Each BwPool (or Aal2If if no BwPool declared) must be linked to exactly one TransportMap.
A transportMap is configured with the following parameters:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 31/240
RNCIN
TransportMap i
interfaceType:
Iub, Iur, IuCS, ( not iuPS)
preference:
sharedForAllTrafficTypes, or
primaryForTrafficType(only Iub case).
transportServiceEntry 1:
[TC, RbSetQos, ARP PL, Thp] => qos i
ulDlPreference.
transportServiceEntry n:
[TC, RbSetQos, ARP PL, Thp] => qos i
ulDlPreference.
TEG
Figure 3-16, transportMap parameters
- InterfaceType:
Values: [Iub, iuCs, Iur, (not iuPS)]
One transportMap may be configured with different interfaceType values, in other
words a transportMap may be allocated to different Utran interfaces.
- Preference:
Values: [sharedForAllTrafficTypes, primaryForTrafficType]
The setting of the Preference parameter determines the nature of the bwPool the
transportMap is connected to.
The Preference parameter is not taken into consideration by the admissionControl
when selecting a bwPool.
The sharedForAllTrafficTypes preference can be assigned only to an atm bwPool.
The primaryForTrafficType preference can be assigned to both atm bwPool and IP
bwPool.
Rule: IubTEG_RNC_TMap_3
The interfaceType and Preference are mandatory parameters within the transportMap.
Rule: IubTEG_RNC_ TMap _4
The primaryForTrafficType Preference value is available only on the Iub interface.
- Transport serviceEntry:
- Inputs: TC, rbSetQos, ARP-PL, THP.
Each input may be set with a specific value or with the ignore value when the input
parameter doesnt apply to the UMTS flow.
- Output:
qos i: with i in the range [0, 1, 2, 3], one associated transport qos value
involved in both the atm and ip interfaces,
The DSCP value is not taken into consideration on the ATM interface.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 32/240
INPUT values
TC
rbSetQos
ARP-PL
THP
OUTPUT Values
UlDlPreference
DSCP
Qos i

- On the atm interface from an atm or hybrid RNC, four qosi values (qos0, qos1, qos2
and qos3) are supported on the primaryForTrafficType and sharedForAllTrafficTypes
bwPool.
- On the ip interface from a nativeIP RNC, four qosi values (qos0, qos1, qos2 and qos3)
are supported on the sharedForAllTrafficTypes bwPool.
- On the hybrid RNC ip interface, only the qos3 value is supported on the ip
primaryForTrafficType bwPool.
- ulDlPreference:
Values: [noPreference, preferredForUl, preferredForDl, preferredForUlAndDl],
This parameter should be set for the UMTS traffic requesting different qos treatments
on uplink and downlink directions, e.g. hs-dsch/e-eDch. This parameter should be
ignored for the UMTS traffic requiring same qos treatment on both uplink and
downlink direction.
The received RNL radioBearerType value is compared to the tse ulDlPreference
attribute by the admissionControl when selecting a bwPool (see 3.2.1.3).
The ulDlPreference is supported only on the Iub, for both the atm and the ip interfaces.
Remark: one or several transportServiceEntry instances are configured under one transportMap
instance.
Rule: IuTEG_RNC_TMap _7
A specific set of transportServiceEntry input values (TC, THP, ARP, RbSetQos) must be
unique under one transportMap instance.
Nevertheless a specific set of transportServiceEntry input values may be replicated into
different transportMap instances with different output values.
The transport admissionControl algorithm takes into consideration the UMTS traffic qos requirements
and the transportMap/transportServiceEntry and ulDlPreference for the selection of the transport bearer;
a transport bearer being either a qox vcc within aal2 bwPool or an ipFlow within an ip bwPool.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 33/240
RNCIN
RNCIN
IubIf
TransportMap 1
aal2If i
interfaceType: Iub/IuCS, Iur

BwPool/x
Preference: sharedForAllTrafficTypes
qos/i Paths
qos/j, Paths
TransportMap 2
interfaceType: Iub
BwPool/y
Preference: primaryForTrafficType
Qos/k, Paths
IucsIf
Congestionmanagement i
aal2If i
qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z
Qos/i, path/m
qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z
Congestionmanagement j
IurIf
aal2If i
Qos/i, paths
Qos/j, paths
TEG
Figure 3-17, transportMap example
3.2.2.1 TRANSPORTMAP TABLES:

Several transportMap tables are suggested to cover the different contexts: atm, ip or hybrid RNC, atm or
ip interfaces:
TM/#
Description
ATM, sharedForAllTrafficType withOut hspa streaming, UA5 backward compatibility
ATM & IP, primaryForTrafficType, 1 qos, UA5 backward compatibility
ATM, sharedForAllTrafficType with hspa streaming
ATM, primaryForTrafficType, 4 qos
IP, sharedForAllTrafficType with hspa streaming
3.2.2.1.1 - TRANSPORTMAP/1:
ApplicationContext:
- UA5 backward compatibility
- InterfaceType: Iub, IuCS and Iur,
- Hspa streaming: with hspa NOT streaming supported,
- Preference: SharedForAllTrafficTypes,
- Transport: atm, enhancedQos not activated.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 34/240
Transport MAP /1
Comments:
IuCS, Iur, Iub
Tse
TC
1 Common
2 signaling
R99
"
"
IuCS
R99
"
"
Iub, Iur
R99
ARP
ignore
ignore
ignore
3 conversational
4 conversational
5 conversational
ignore
ignore
ignore
6 streaming
7 streaming
8 streaming
9 streaming
ignore
ignore
2
0
1
ignore
ignore
ignore
12 streaming
13 streaming
14 streaming
15 interactive
ignore
ignore
ignore
0
16 interactive
17 interactive
10 streaming
11 streaming
"
"
Iub, Iur
Hspa
"
"
Iub, Iur
R99
"
"
18 interactive
19 interactive
20 interactive
"
"
"
"
"
"
Iub, Iur
Hspa
21 interactive
22 interactive
23 interactive
24 interactive
25 interactive
26 interactive
"
"
27 interactive
28 interactive
29 interactive
"
"
"
R99
30 interactive
31 interactive
32 interactive
33 background
Hspa
34 background
35 background
36 background
"
"
"
Iub, Iur R99
"
"
Iub, Iur
37 background
38 background
"
"
THP
ignore
ignore
rbsetQos
0
0
0
qos
0
0
0
0
1
noPreference
EF
noPreference
EF
noPreference
EF
noPreference
EF
nopreference
EF
nopreference
EF
AF41
nopreference
noPreference
AF42
noPreference
AF43
noPreference
AF41
noPreference
AF42
noPreference
AF43
AF31
noPreference
noPreference
noPreference
AF21
noPreference
AF32
noPreference
AF22
noPreference
AF22
noPreference
AF33
noPreference
AF22
noPreference
AF22
AF11
noPreference
noPreference
AF11
noPreference
AF11
noPreference
AF12
noPreference
AF12
noPreference
AF12
noPreference
AF13
noPreference
AF13
noPreference
AF13
AF23
noPreference
noPreference
EF
AF21
2
1
uldlpreference
noPreference
2
0
0
DSCP
EF
2
ignore
ignore
2
0
1
ignore
ignore
ignore
ignore
AF23
noPreference
AF23
DE
noPreference
noPreference
DE
noPreference
DE
noPreference
Table 3-2, ATM sharedForAllTrafficTypes withOut hspa Streaming
ApplicationContext:
- UA5 backward compatibility,
- InterfaceType: Iub,
- Preference: PrimaryForTrafficType,
- Transport: ip or atm with only qos3 vcc.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 35/240
Transport MAP /2
Tse
TC
ARP
1 interactive
2 interactive
3 interactive
4 interactive
5 interactive
6 interactive
7 interactive
8 interactive
9 interactive
THP
rbsetQos
qos
DSCP
0
AF11
1
2
0
2
preferredForUlAndDl
AF12
2
preferredForUlAndDl
AF13
ignore
ignore
12 background
ignore
preferredForUlAndDl
preferredForUlAndDl
10 background
11 background
preferredForUlAndDl
preferredForUlAndDl
1
0
uldlpreference
preferredForUlAndDl
preferredForUlAndDl
preferredForUlAndDl
preferredForUlAndDl
DE
preferredForUlAndDl
preferredForUlAndDl
Table 3-3, IP or ATM primaryForTrafficType, 1 qos
ApplicationContext:
- InterfaceType: Iub, IuCS and Iur,
- Hspa streaming: hspa streaming supported,
- Transport: atm, enhancedQos activated.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 36/240
Transport MAP /3
Comments:
IuCS, Iur, Iub
Tse
TC
1 Common
2 signaling
R99
"
"
IuCS
R99
"
"
Iub, Iur
R99
ARP
ignore
ignore
ignore
3 conversational
4 conversational
5 conversational
ignore
ignore
ignore
6 streaming
7 streaming
8 streaming
9 streaming
ignore
ignore
2
0
1
ignore
ignore
ignore
12 streaming
13 streaming
14 streaming
15 interactive
ignore
ignore
ignore
0
16 interactive
17 interactive
10 streaming
11 streaming
"
"
Iub, Iur
Hspa
"
"
Iub, Iur
R99
"
"
18 interactive
19 interactive
20 interactive
"
"
"
"
"
"
Iub, Iur
Hspa
21 interactive
22 interactive
23 interactive
24 interactive
25 interactive
26 interactive
"
"
27 interactive
28 interactive
29 interactive
"
"
"
R99
30 interactive
31 interactive
32 interactive
33 background
Hspa
34 background
35 background
36 background
"
"
"
Iub, Iur R99
"
"
Iub, Iur
37 background
38 background
"
"
THP
ignore
ignore
qos
0
0
0
noPreference
EF
noPreference
EF
noPreference
EF
nopreference
EF
nopreference
EF
AF41
nopreference
noPreference
AF42
noPreference
AF43
noPreference
AF41
noPreference
AF42
noPreference
AF43
AF31
noPreference
noPreference
noPreference
AF32
noPreference
AF22
noPreference
AF22
noPreference
AF33
noPreference
AF22
noPreference
AF22
AF11
noPreference
noPreference
AF11
noPreference
AF11
noPreference
AF12
noPreference
AF12
noPreference
AF12
noPreference
AF13
noPreference
AF13
noPreference
AF13
AF23
noPreference
noPreference
2
0
1
2
ignore
0
1
noPreference
EF
noPreference
EF
AF21
2
0
uldlpreference
noPreference
AF21
DSCP
EF
2
1
rbsetQos
0
0
ignore
2
0
1
ignore
ignore
ignore
ignore
AF23
noPreference
AF23
DE
noPreference
noPreference
DE
noPreference
DE
noPreference
Table 3-4, ATM sharedForAllTrafficTypes with hspa Streaming
ApplicationContext:
- InterfaceType: Iub,
- Preference: PrimaryForTrafficType,
- Transport: atm, four qosx vcc.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 37/240
Transport MAP /4
Tse
TC
ARP
1 interactive
2 interactive
3 interactive
4 interactive
5 interactive
6 interactive
7 interactive
8 interactive
9 interactive
THP
rbsetQos
qos
DSCP
0
1
AF11
preferredForUlAndDl
AF12
2
1
preferredForUlAndDl
2
AF13
preferredForUlAndDl
preferredForUlAndDl
ignore
preferredForUlAndDl
10 background
11 background
ignore
12 background
ignore
preferredForUlAndDl
preferredForUlAndDl
0
2
preferredForUlAndDl
preferredForUlAndDl
0
1
uldlpreference
preferredForUlAndDl
DE
preferredForUlAndDl
preferredForUlAndDl
Table 3-5, ATM primaryForTrafficType, 3 qos
ApplicationContext:
- InterfaceType: Iur & IuCS & Iub (nativeIP),
- Transport: IP.
- UA6.0 enhanced QoS activated
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 38/240
Transport MAP /5
Comments:
IuCS, Iur, Iub
Tse
TC
1 Common
2 signaling
R99
"
"
IuCS
R99
"
"
Iub, Iur
R99
Hspa
"
"
Iub, Iur
R99
"
"
"
"
"
"
"
Hspa
"
"
"
ignore
6 streaming
7 streaming
8 streaming
9 streaming
ignore
ignore
2
0
1
ignore
ignore
ignore
12 streaming
13 streaming
14 streaming
15 interactive
ignore
ignore
ignore
0
16 interactive
17 interactive
21 interactive
22 interactive
23 interactive
24 interactive
R99
Hspa
34 background
35 background
36 background
"
"
"
ignore
30 interactive
31 interactive
32 interactive
33 background
"
"
27 interactive
28 interactive
29 interactive
"
Iub, Iur
ignore
25 interactive
26 interactive
"
"
Iub, Iur R99
"
18 interactive
19 interactive
20 interactive
"
Iub, Iur
ignore
3 conversational
4 conversational
5 conversational
10 streaming
11 streaming
"
"
Iub, Iur
ARP
ignore
ignore
37 background
38 background
THP
ignore
ignore
rbsetQos
0
0
0
qos
0
0
0
1
noPreference
EF
noPreference
EF
noPreference
EF
noPreference
EF
nopreference
EF
nopreference
EF
AF41
nopreference
noPreference
AF42
noPreference
AF43
noPreference
AF41
noPreference
AF42
noPreference
AF43
AF31
noPreference
noPreference
AF21
noPreference
AF21
noPreference
AF32
noPreference
AF22
noPreference
AF22
noPreference
AF33
noPreference
AF22
noPreference
AF22
AF11
noPreference
noPreference
AF11
noPreference
AF11
noPreference
AF12
noPreference
AF12
noPreference
AF12
noPreference
AF13
noPreference
AF13
noPreference
AF13
AF23
noPreference
noPreference
CS6
2
1
uldlpreference
noPreference
2
0
0
DSCP
EF
2
ignore
ignore
2
0
1
ignore
ignore
ignore
ignore
AF23
noPreference
AF23
DE
noPreference
noPreference
DE
noPreference
DE
noPreference
Table 6 IP sharedForAllTrafficTypes with hspa Streaming
3.2.3
CONGESTION MANAGEMENT A.K.A RATE CONTROL

Reference: [R160]
The congestionManagement mechanism consists in either discarding or delaying excess traffic for a given
qos stream or for the whole bwPool.
The congestionManagement regulation applies at bwPool level.
The congestionManagement mechanism applies on the Iub interface against local user traffic and the
hsdpa traffic received from the Iur interface (case of RNC acting as a drift RNC).
The congestionManagement mechanism doesnt apply on the Iub interface against the R99 traffic
received from the Iur interface.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 39/240
The RNC congestionManagement is supported on the Iub interface and the Iur interface [R3] downlink
traffic. It applies to both atm and ip interfaces.
The RNC Iub congestionManagement encompasses two regulation mechanisms:
- The qosDiscard algorithm,
- The backPressure algorithm.
Rule: IubTEG_ RNC_CM_1
It is recommended to activate both together qosDiscard and BackPressure on the Iub (atm and
ip legs).
The RNC measures for each qos stream, the real time traffic and applies to it thresholds which are based
on the configured per qos bandwidth and configured per qos parameters:
- qosDt(n), for the qosDiscard thresholds, with n=[0, 1, 2, 3],
- qosBP(n), for the backPressure thresholds, with n=[0, 1, 2, 3].
Remarks:
- qosDt(0) and qosBp(0) are set to zero therefore no regulation applies to the qos0 traffic.
- The feature 3Gpp25902 has no interaction with the congestionManagement.
3.2.3.1 CONGESTIONMANAGEMENT TABLE

The congestionManagement parameters involved in the qosDiscard and backPressure thresholds setting,
are configured through the RncIn/CongestionManagement tables.
A congestionManagement table is linked one or several bwPools, atm or ip bwPool or both atm and ip
bwPools.
Rule: IubTEG_RNC_CM_2
The RNC supports up to 64 congestionManagement tables.
In such a way the congestionManagement regulation is applied to the bwPool traffic:

- The aal2If/BwPool (or aal2If if no configured bwPool) must be linked to a congestionManagement
table.
- The ipIf/bwPool is linked to a CongestionManagement table.
Remark: The ipIf component can not be linked to a congestionManagement table.
Each ipFlow must be linked to an appropriated congestionManagement instance through the
ipIf/bwPool component.
Each aal2Path must be linked to an appropriated congestionManagement table either through the
aal2If or aal2If/bwPool component it belongs to.
Within a congestionManagement table is configured:
- The Activation attribute indicates which algorithm to apply to the bwpool, either:
- disable,
- qosDiscard only, or
- qosDiscard + backPressure.
- The per qos stream parameters involved in the qosDiscard thresholds,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 40/240
The per qos stream parameters involved in the backPressure thresholds.
RNCIN
RNCIN
aal2If i
CongestionManagement i
BwPool/x
Activation: [qosDiscard only, qosDiscard+backPressure]
path/i
path/j
2
BwPool/y
CongestionManagement j
path/k
path/l

ipIf i
3
BwPool/u
CongestionManagement k
ipFlow/i
ipFlow/l
TEG
Figure 3-18, congestionManagement links
3.2.3.2 UA6 BEHAVIOR VERSUS UA5 EQUIVALENT BEHAVIOR

The congestionManagement algorithm provides two different behaviours according to the setting of the
RncIn/enhancedQos parameter:
- If enhancedQos=disable, the congestionManagement provides the UA5 equivalent behaviour:
Emulation of the UA5 behavior, with some variations:
- New formula for Txoff,
- New formulas for qosDiscard and qosBackPressure thresholds,
- The congestionFlag is inserted in the Xoff signal, always set to false .
Remarks:
- Supports up to 3 qos streams, No support of Hspa streaming,
- GBR and minBr not supported.
The RncIn enhancedQos parameter must be set to disable, when the congestionManagement
UA5 equivalent behavior is preferred.
-
If enhancedQos=enable, the congestionManagement provides the UA6 behaviour:

- Support up to 4 qos streams,
- Support of Hspa streaming,
- The CM algorithm is enhanced with:
- The Xon signal,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 41/240
The congestionFlag set either to yes or no is inserted within the Xoff

signal,
The GBR for streaming,
The minBrForHspa and minBrForR99 for interactive and backGround,
TC
THP
minBrForR99
minBrForHsdpa
Interactive
16 kb/s
16 kb/s
Interactive
8 kb/s
8 kb/s
Interactive
8 kb/s
8 kb/s
backGround
na
Table 3-7, suggested minBr vaues

The qosnBwReservation is taken into consideration by the congestionManagement,
The RncIn enhancedQos parameter must be set to enable, when the congestionManagement
UA6 behavior is preferred.
The RncIn enhancedQos parameter must be set to enable when the congestionManagement has
to take into consideration the GBR for streaming and minBrForHspa and minBrForR99 for
interactive/Background
3.2.3.3 QOSDT AND QOSBP PARAMETERS

Up to 4 qos are supported then up to 4 qosDiscard thresholds and 4 qosBackPressure thresholds are set
then one qosDt parameter is set per qos and one qosBP parameter is set per qos.
Rule: IubTEG_RNC-Atm_CM _7
qosDt(0) qosDt(1) qosDt(2) qosDt(3)

A qosBP(n)=0 means that the backPressure doesnt apply for the qos n.
1/ Context of IP interface and Atm interface without trafficShaping at VP level activated:
- Atm interface without basicVPT trafficShaping means:
- The trafficShaping at VP level is not activated neither in the RNC nor in the POC,
- The remote POC is populated with a FP supporting standardVPT, the remote POC acts as
a VC switch (not VP switch) and the trafficShaping at VP level is activated in the remote
POC on the atm interfaces toward the NodeB.
- IP interface: Actually as long as no shaping neither on the RNC nor on the IP backbone and
DifferentiatedServices IP backbone, the RNC CM can be set with high perQos regulation
threshold values.
When IP interface or atm interface without trafficShaping at VP level, the following
congestionManagement qosDiscard and qosBackPressure parameter values apply:
Rule: IubTEG_RNC_CM _8
qosDt 0 0 1 200 2 350 3 500

qosBPt 0 0 1 50 2 95 3 95
Remark: The thresholds for the qos1 stream are set with low values to avoid traffic starvation
over le qos2 and qos3 streams.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 42/240
2/ Context of Atm interface with trafficShaping at VP level activated:

It encompasses 3 Iub configurations:
o 1/ the trafficShaping at VP level is activated in the RNC 16pOC3/Stm1 FP Iub
interfaces, or
o 2/ the remote POC is populated with a FP supporting basicVPT and the trafficShaping
at VP level is activated in the remote POC on the atm interfaces toward the NodeB, or
o 3/ the remote POC is populated with a FP supporting standardVPT, the remote POC
acts as a VP switch (not VC switch) and the trafficShaping at VP level is activated in
the remote POC on the atm interfaces toward the NodeB.
When Atm interface with trafficShaping at VP level, the following congestionManagement
qosDiscard and qosBackPressure parameter values apply:
Rule: IubTEG_RNC_CM _9
qosDt 0 0 1 150 2 300 3 500

qosBPt 0 0 1 66 2 33 3 35
Up to 4 qos streams are supported, one qosDt parameter and one qosBP parameter are configured per qos
stream.
For each qos stream, the RNC calculates the qosDiscard thresholds and qosBackPressure thresholds based
on the bandwidth configured against the bwPool and the qosDt and qosBP parameters.
qosDt(0) qosDt(1) qosDt(2) qosDt(3)
A qosBP(n)=0 means that the backPressure doesnt apply for the qos n.
The CM parameter values specified for ATM without VPT shaping are also suggested for an IP bwPool
(since no shaping is performed by RNC or by IP backbone).
Remark: Actually as long as no shaping neither on the RNC nor on the IP backbone and
DifferentiatedServices IP backbone the RNC CM can be set with high perQos regulation threshold
values.
CM parameter values configured against an IP bwPool:
- qosDt 0 0 1 0 2 350 3 500
- qosBPt 0 0 1 0 2 95 3 95
3.2.3.4 COUNTERS:
All kinds of congestionManagement counters measure the traffic over 10 ms period.
The counter unit is either cell/10ms for the atm interface or bytes/10ms for the ip interface.
Based on the perQos stream real time measured traffic over the previous 10 ms periods, the RNC
estimates per qos stream the expected traffic over the next 10 ms period.
For that the RNC set the Qne (estimated) counters:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 43/240
Qne Counter
definition
Q0e
Half of the qos 0 trafficVolume over the previous 20 ms period.
Q1e
Quarter of the qos1 trafficVolume over the previous 40 ms uncongested period.
Q2e
Q3e
Table 3-8, qosn estimated counters
The per cumulative qos stream counters: Qxxx, in extenso: Q0, Q01, Q012 and Q0123.
Four per cumulative qos stream counters Qxxx provide the traffic over a 10 ms period for qos0,
qos0+qos1, qos0+qos1+qos2, qos0+qos1+qos2+qos3:
Qxxx Counters
definition
Q0
Half of the qos 0 trafficVolume over the previous 20 ms period.
Q01
Q0+ Q1
(qos0 + qos1 traffic)
Q012
Q01 + Q2
(qos0 + qos1+ qos2 traffic)
Q0123
Q012 + Q3
(qos0 + qos1 + qos2 + qos3 traffic)
Table 3-9, Qxxx per cumulative qos counters
Qxxx Counter decrement:

Whatever UA5 equivalent behaviour or UA6 behaviour the Qxxx counters are decremented each 10
ms by the 10msdecrqosn parameter value down to 0.
Per default,
- 10msdecrqosn = dth0 as long as the qosnBwReservation=100% in the context of UA6 behaviour.
- 10msdecrqosn = bwnavail since the qosnBwReservation < 100% in the context of UA6 behavior.
3.2.3.5 THRESHOLDS
The qosDiscard and qosBackPressure threshold values calculated by the RNC depend on the bandwidth
configured per qos against a bwPool, the configured qosDt and qosBP parameters and the setting of the
qosnBwReservation parameters.
Remark: The qosnBwReservation parameters are also involved in the Transport admissionControl.
The qosnBwReservation parameters are involved in the congestionManagement thresholds determination
if:
- the enhancedQos = enabled,
- cacm=qos, and
- qosnBwReservation > 0%.
The qosnbwReservation is taken into consideration by the congestionManagement if:
- The RncIn enhancedQos = enable,
- The cacMethod = Qos under Aal2If or IpIf level
3.2.3.5.1 CASE OF QOSNBWRESERVATION= 0%:

The qosnBwReservation parameter values dont influence the thresholds determination.
QosDiscardThresholds, UA6 and UA5 equivalent behaviours:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 44/240
One discard threshold is set per qos stream. The discard threshold value depends on the
bandwidth assigned to the bwPool on the RNC side and on the configured qosDt parameters
within the congestionManagement table.
On the atm interface, the bandwidth is assigned to the atm bwPool through the vcc
trafficDescriptors.
On the ip interface, the bandwidth is assigned to the bwPool through the peak and commited
rates configured against the ipFlow.
qosDiscardThresholds
dth0 = Th0 = bwPool vcc ECRgcac /100
= bwPool ipFlow ERgcac /100
for the atm interface

for the ip interface
dth1 = Th0 + (qosDt1/100 1) * (Th0 Q0e)

dth2 = Th0 + (qosDt2/100 1) * [Th0 (Q0e+Q1e)]
dth3 = Th0 + (qosDt3/100 1) * [Th0 (Q0e+Q1e+Q2e)]
Table 3-10, qosDiscardThresholds
-
The ECR is the result of the GCAC algorithm.
Th0 = bwPool [qos0 vcc ECRgcac + qos1 vcc ECRgcac + qos2 vcc ECRgcac + qos3 vcc
ECRgcac] /100 for the atm interface,
Th0 = bwPool [qos0 ipFlow ERgcac + qos1 ipFlow ERgcac + qos2 ipFlow ERgcac + qos3
ipFlow ERgcac] /100 for the ip interface,
The dthn thresholds are recalculated each 50 ms .
The Th0 threshold is updated when there is a change in transport status (bandwidth
reduction, restoration, addition).
QosBackPressureThresholds, UA6 and UA5 equivalent behaviours:

One backPressure threshold is set per qos. The backPressure value depends on the per qos
discard threshold and on the configured per qos qosBPt parameter:
bpThn = dthn * qosBPtn/100
Table 3-11, qos backPressure thresholds

-
The BP thresholds are recalculated each 50 ms.

When qosBPTn = 0, no backpressure mechanism is applicable.
3.2.3.5.2 CASE OF QOSNBWRESERVATION > 0%:

Since the cacm=qos, the enhancedQos=enable and qosnBwReservation > 0%, the
congestionManagement takes into consideration the qosnBwReservation in congestionManagement
threshold determination and then in the real time traffic regulation.
Per bwPool and per qos, based on the qosnBwReservation values, the RNC splits the configured
bandwidth in two portions:
- A bandwidth portion exclusively dedicated to one qos n stream,
- A bandwidth portion shared between all the different qos streams.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 45/240
Atm Bw available and Atm bw exclusively reserved per qos

Bw0avail
= Th0 - n [qosnBwReser * vcc ECRqosn /100], with n 0
Bw0exclus = qos0BwReser * vcc ECRqos0 /100

Bw1avail

Bw2avail

Bw3avail
Table 3-12, bwxavail & bwxexclus on atm interface

IP Bw available and IP bw exclusively reserved per qos
Bw0avail
= Th0 - n [qosnBwReser * ipFlow ERqosn /100], with n 0
Bw0exclus = qos0BwReser * ipFlow ERqos0 /100

Bw1avail

Bw2avail

Bw3avail
Table 3-13, bwxavail & bwxexclus on ip interface
Per period of 10 ms, an estimation of the per qos stream traffic using the Bwnavail portion is given by
the relation:
Traffic qos n shared
Trafficqosnshared = Qne bwnexclus
With:
- n = [0, 1, 2, 3],
- If TrafficQosnShared is negative, it is forced to Zero, then Trafficqosnshared 0.
The qos discard threshold definition is impacted by the qosnBwReservation through the
Trafficqosnshared and the bwnavail:
dth0 = bw0avail
dth1 = bw1avail + (qosDt1/100 -1) * [ bw1avail trafficqos0shared ]
dth2 = bw2avail + (qosDt2/100 -1) * [ bw2avail ( trafficqos0shared + trafficqos1shared ) ]
dth3 = bw3avail + (qosDt3/100 -1) * [ bw3avail ( trafficqos0shared + trafficqos1shared + trafficqos2shared ) ]
Table 3-14, discard threshold when qosnBwReservation < 100%
The qosBP threshold formulas are not impacted by the qosnBwReservation nevertheless the qosBP
threshold values are impacted by the qosnBwReservation.
bpThn = dthn * qosBPtn/100
Table 3-15, qos backPressure thresholds
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 46/240
3.2.4
NODEB DISCRIMINATION
Different kinds of nodeB may be connected to the RNC: iBTS, micro_picoBTS, oneBTS.
Beside these nodeB may offer either atm, ip or both interfaces.
The RNC must be configured with the type of the nodeB it is connected to.
Since both parameters are set per nodeB, different types of nodeB may be connected to the RNC.
Within the RNC-CN model two parameters must be set for specifying the nodeB type:
- The RNC/NodeB/ nodeBType parameter value: [iBTS, micro/picoBTS, oneBTS].
- The RNC/NodeB/ nodeBCapability [nativeIP nodeB, Hybrid NodeB, atm NodeB].
RNC
ULRbSetConf
- Qaal2 Cac
DLRbSetConf
- Qaal2 Cac
NodeB
- ConnectionMode,
- saalUniParams
(common for CP, CCP and Alcap)
- IubIfID,
Linked to RNC-IN model/ Root/IubIf
- nodeBCapability,
- alcapCelValidityTimer,
- nodeBType.
CtrlPort (up to 8)
Linked to RNC-IN IubIf/Sig507)
- CtrlPort Id,
- CtrlPortType:
- 0: CP, 1: CCP, 2: SCP, 3: alcap
TEG
Figure 3-19, RNC-CN Model
Rule: IubTEG_RNC_nodeB discrimination_1
The nodeBType parameter must be set according to the type of nodeB either: iBTS,
micro/picoBTS or oneBTS.
The RNC supports a mix of the three nodeBType values.
Rule: IubTEG_RNC_ nodeB discrimination _2
The RNC/NodeB/ nodeBCapability last bit must be set to:
- 3 if nativeIP NodeB,
- 1 if Hybrid NodeB,
- 0 if atm NodeB.
The RNC supports a mix of the three nodeBCapability.
Rule: IubTEG_RNC_ nodeB discrimination _3
The RNC/NodeB/ nodeBCapability can be set to 3 (IP Native NodeB) as long as the parameter
RNC/NodeB/isIubOnNativeIpAllowed = True.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 47/240
3.2.5
UTRAN SHARING
The objective of the UTRAN sharing feature is to allow the UTRAN network to be shared between
several UMTS operators:
Rule: IubTEG_RNC_utranSharing_1
The UTRAN is shared between up to 4 operators.
The RNC equipment is then composed of as many logical RNC as amount of Plmn sharing the utran.
The RNC is partly or completely shared between the Plmn.
The set of allowed radioBearers is the same for all the Plmn.
The transportMap configured in the RNC applies to all the Plmn.
The admissionControl equivalentBitRate values configured in the RNC applies to all the Plmn.
Iub interface impact:

- Both RNC and NodeB may be shared between all the Plmn,
- A shared RNC may have Iub interfaces with both shared and not shared NodeB,
- The utranSharing applies to both the atm and the ip interfaces.
- The Iub cp and ccp vcc are shared between all the Plmn sharing the Utran,
-
The Iub userPlane Transport resources are either shared between all the PLMN sharing the
utran or dedicated per PLMN sharing the utran (see 3.3.13.3):
The IubTransport userPlane resources (aal2 Path, ipFlow) dedicated to a PLMN are
assigned to a PLMN dedicated bwPool. One or several PLMN dedicated bwPool may
be configured per nodeB. A PLMN dedicated bwPool is configured with the PLMN
Identifier.
The IubTransport userPlane resources (aal2 Path, ipFlow) shared between several
PLMN are assigned to a PLMN Common bwPool. One or several shared bwPool may
be configured per nodeB. A shared bwPool is configured with a PLMN Identifier=0.
See 3.3.13.3.
Both the PLMN specific bwPools and the PLMN Common bwPools may coexist on
an Iub interface.
At least one PLMN Common bwPool must be configured on the Iub interfaces supporting MOCN cells.
Remark: The MOCN feature allows the sharing of the radio resources between several
PLMN. This feature is not covered in the TEG.
- Transport Identifiers:
The RNC equipment is composed of one logical RNC per PLMN sharing the RNC equipment.
One logical RNC is identified by its global RNC Id:
Global RNC Id = PLMN Id + RNC Id = MCC + MNC + RNC Id
One RNC Id is configured in the RNC equipment; it is common to all the logical RNC.
The RNC Id numbering plan of all the Plmn sharing the utran operators must be coordinated.
Case of Iub over atm, the RNC is identified by one A2EA:
The A2EA numbering plan must be coordinated between all the Plmn sharing the utran.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 48/240
Example of utran network with utranSharing activated:
Operator A, own MNC
UE
UE
On the Iub, the Transport

resources are common to
both operators unless
PLMN bwPools are
configured per PLMN.
MGw1
MGw2
MGC1
Operator A:
CP & UP vcc
MGw10
Mc
Operator B:
UE
UE
Mc
NRI = 1
Nc
MGw1
CP & UP vcc
MGC2
NRI = 2
UE
UE
UE
UE
Iub
atm
atm
Shared
resources
RNC
RNC
UE
UE
NODE B
B
NODE
MGw10
Iu Plmn 1
Iu Plmn2
dedicated
resources
ATM
ATM
NRI = 1
SGSN 2
NRI = 2
MSC
NRI = 1
MSC
NRI = 2
SGSN 1
NRI = 1
SGSN 1
NRI = 2
Iur
atm
atm
Shared RNC
RNC
Shared
Plmn2, RNC
RNC
Plmn2,
UE
UE
Plmn1, RNC
RNC
Plmn1,
SGSN 1
Operator B, own MNC
3.2.6
OLS
The OLS Differentiation feature intends to provide per UMTS User service differentiation for the Hsdpa
interactive & background traffic according to the OLS value (gold, silver, bronze) assigned to the UE.
The feature is activated as an option:
Object: : OlsDiff
Within the RNC, the feature relies on the congestionManagement for achieving the expected regulation.
The congestionManagement mechanism is enhanced to satisfy the feature requirement.
The perOLS measurement granularity has been introduced within the qos3 stream only.
Therefore the OLS differentiation applies only to the hspa I/B as long as the hspa I/B is mapped to the
qos3 stream:
Rule: IubTEG_RNC_OLS_1
The OLS Differentiation is supported on:
- sharedForAllTrafficTypes bwPool,
- primaryForTrafficType bwPool, if hspa I/B is mapped to only qos3 stream.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 49/240
The OLS Differentiation feature is supported as long as the hspa Streaming is disable , therefore as long
as enhancedQos is disable:
Rule: IubTEG_RNC_OLS_2
If OLS Differentiation is activated, the enhancedQos=disable.
The RNC is configured with a weigth for each OLS value, which determines the distribution of the qos3
available bandwidth over the three perOLS trafficAggregates:
Parameter: OlsDiff, defaultValues: goldWeigth=100, silverWeigth=40, bronzeWeigth=10.
Remark:
- If the Gold user traffic is not enough to fill the Iub, the expectation is that the Bronze and Silver users
are allowed to get more bandwidth than their budgets.
3.3
RNC ATM
This section is related to the RNC transport features applying to the RNC atm interfaces (atm RNC and
hybrid RNC).
The RNC is populated with two 16pOC3/Stm1 FP and provides atm accesses on all the UTRAN
interfaces or the RNC is populated with two 16pOC3/Stm1 FP and two 4pGE FP and provides atm
accesses to Iub, IuCS, Iur and as an option to the IuPS interfaces.
3.3.1
ASIC
The different Passport FP, are based either on APC or AQM trafficManagement ASIC. The type of ASIC
determines the FP trafficManagement behavior.
3.3.1.1 APC ASIC:

AtmConnection Vpi-Vci range:
- Vpi range: [0-255] on UNI interface, [0-4095] on NNI interface.
- Vci range: [32, 16 383].
TrafficManagement characteristics:
- EmissionPriority values (EP0 to EP7),
- Basic VPT,
- SingleRate trafficShaping (also called Linear Shaping),
- Traffic shaping only on Emission Priorities 0.
3.3.1.2 AQM ASIC:

AtmConnection Vpi-Vci range:
- Vpi range: [0-255] on UNI interface, [0-4095] on NNI interface.
- Vci range: [32, 65 535]
TrafficManagement characteristics:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 50/240
3.3.2
8 EmissionPriority values (EP0 to EP7),

Standard and basic VPT,
SingleRate and dualRate trafficShaping (also called linear and inverse UPC)
Traffic shaping on 2 shaping Emission Priorities,
UPC.
FP
3.3.2.1 16POC3/STM1 PQC FP

The RNC is populated with a pair of 16pOC3/STM1 FP.
Iub, Iu, Iur transmission links are connected to the 16pOC3/STM1 FP.
3.3.2.1.1 TRANSMISSION CHARACTERISTICS:
one FP manages sixteen STM1/OC3 links,
interCard APS:
1+1 inter-card line APS. APS configured for lines physically connected to different cards, also
called dual-FP APS.
Rule: IubTEG_16pOC3/Stm1 FP_1
When configuring dual-FP line APS on the 16-port OC-3 ATM FP, configure a pair of ports
on two adjacent FPs and the pair shares the same port number.
The Line switching time in the case of a fault (SF/SD on the line) is within 50 ms.
The APS is compliant either with [R80] or [R33 annexe B]
When setting the 16pOC3/Stm1 FP, the reference recommendation is specified thanks to the
attribute: ATTRIBUTE Laps protocol.
-
The value standard indicates that 1+1 linear APS is used, as described in the
recommendation [R80] and [R33 7]
The value g841AnnexB indicates that optimized 1+1 bidirectional switching is used, as
described in the standard [R33 Annex B].
Rule: IubTEG_16pOC3/Stm1 FP_2

When the 16pOC3/Stm1 FP is configured in such a way to behave according to [R33
annexe B] then:
- ATTRIBUTE Laps mode must be set bidirectional,
- ATTRIBUTE Laps Revertive must be set noRevertive,
- ATTRIBUTE Laps holdOffTime (hoTime) must be set with O.
The APS is configured through laps component in PP15k.
3.3.2.1.2 FP ATM ATTRIBUTES:

The 16pOC3 FP card is based on APC TrafficManagement ASIC. Therefore the 16pOC3 FP ATM
characteristics are those from the APC.
The 16pOC3/Stm1 FP attributes are in charge of the management of the FP, APC and port resources.
They provide the ability to distribute the FP and APC resources to each port, according to the port needs.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 51/240
The FP and APC resources are consumed by the amount of atmConnections and by the atmConnection
Identifier ranges.
Three kinds of the 16pOC3/Stm1 FP attributes:
- AtmIf ConnMap Ov
- Lp Eng Arc Ov and Lp Eng Arc Apc Ov
- AtmIf CA.
Remark: The AtmIf ConnMap Ov attributes apply only to APC based FP, dont apply to AQM based FP.
3.3.2.1.2.1
ATMIF CONNMAP OV ATTRIBUTES:
The objective of AtmIf ConnMap attributes is the reservation of Vci range for vcc. The Vci reservation is
done for vcc identified with Vpi = 0 on one hand and for vcc identified with a nonZero Vpi on other hand.
The AtmIf ConnMap attributes are set per port.
AtmIf ConnMap ov Attribute list:
- ATTRIBUTE AtmIf ConnMap Ov numVccForVpiZero (nZVcc):
Reservation of the Vci range for vcc identified with a Vpi = 0.
The Vci range = [0 (nZVcc-1)].
The value assigned to this attribute must take into account the Vci values: 0 to 31 reserved by
ITU.
The allowed values are power of 2.
The attribute range is (0 16384)
- ATTRIBUTE AtmIf ConnMap Ov numNonZeroVpisForVcc (nVpis):
Setting of the supported contiguous Vpi values for vcc.
The attribute range is [0, 255] for UNI atmInterface, and [0, 4095] for NNI atmInterface.
- ATTRIBUTE AtmIf ConnMap Ov firstNonZeroVpiForVcc (firstVpi):
Setting of the first nonZero Vpi value used for vcc.
If nVpi = 0 then this attribute is ignored.
The attribute range is [1, 255] for UNI atmInterface, and [1, 4095] for NNI atmInterface.
-
ATTRIBUTE AtmIf ConnMap Ov numVccPerNonZeroVpi (nVcc):

Reservation of the Vci range for vcc identified with the nonZero Vpi values.
The Vci range = [0 (nVcc-1)].
The value assigned to this attribute must take into account the Vci values: 0 to 31 reserved by
ITU.
The allowed values are power of 2.
The attribute range is (0 16384)
The vcc space delimited by [firstVpi, firstVpi+nVpi] is consumed by endPoint vcc, vcc
configured under VPT, and switched vcc.
The ConnMap parameter values may be illustrated as following:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 52/240
VCI
65535
16384
2048
nZVcc
511
nVcc
255
32
Vpi0 VCC Space
1024
Programmable VCC space,

Vci reservation for
independant VCCs and the
VCCs under VPTs.
1
3
4
firstVpi
18 19 20
firstVpi+nVpi
255 UNI
VPI
4096 NNI
ATTRIBUTE AtmIf ConnMap Ov numVccsForVpiZero (nZVccs) = 512

ATTRIBUTE AtmIf ConnMap Ov firstNonZeroVpiForVccs (firstVpi) = 3
ATTRIBUTE AtmIf ConnMap Ov numNonZeroVpisForVccs (nVpis) = 16
ATTRIBUTE AtmIf ConnMap Ov numVccsPerNonZeroVpi (nVccs) = 256
Figure 3-20 ConnMap table example
The ConnMap Attribute values consumed APC Memory resources called VCRAM.
The APC has a fixed capacity of 111 K resources, with K=1024, resulting in APC Capacity = 113 664
resources.
The following formula indicates the cost of the configured ConnMap Attribute values on APC Memory,
and prevents against APC Memory overload:
Rule: IubTEG_16pOC3/Stm1 FP Attribute_01
For UNI atmInterfaces:
port 0, 3 [nZVcc + nVpi * nVcc ] < 113 664

For NNI atmInterfaces:
port 0, 3 [ nZVcc + nVpi * nVcc ] < 113 664
Remark:
The above formulas do abstraction of the relay point vpc space, since not used in the RNC.
The complete formulas taken into consideration the relay point vpc space:
- UNI case: port 0, 3 [nZVcc + 2* (255 nVpi) + nVpi * nVcc ] < 113 664
- NNI case: port 0, 3 [ nZVcc + 2* (4095 nVpi) + nVpi * nVcc ] < 113 664.
In such a way to optimize the APC Memory usage,
When specifying the Vpi.Vci addressing scheme:
Choice the lowest Vci values (32, ),
Avoid gap between the chosen Vci values,
Avoid gap between the chosen Vpi values,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 53/240
3.3.2.1.2.2
LP ENG ARC OV & LP ENG ARC APC OV ATTRIBUTES:
The Lp Eng Arc ov and Lp Eng Arc Apc ov attributes provide the ability to set the FP and APC capacity
in terms of amount of atmConnections.
Lp Eng Arc ov Attribute list:
- Lp Eng Arc Ov connectionPoolCapacity (connCap)
The attribute specifies the maximum number of unspared (no APS) connectionResources.
UMTS RNC context: since all 16pOC3/Stm1 FP ports are configured with Laps, unprotected
connectionResources are used only for test purpose.
-
Lp Eng Arc Ov protectedConnectionPoolCapacity (protConnCap)

The attribute specifies the maximum number of spared connectionResources.
UMTS RNC context: since all 16pOC3/Stm1 FP ports are configured with Laps, UTRAN
AtmConnections consume connectionResources from protConnCap.
In the UMTS RNC context, the 16pOC3/STM1 FP handles both ATM and IP traffic (IPRts>0).
In this context of application, the FP capacity is:
RNC 16pOC3/Stm1 FP Capacity:
connCap + protConnCap < 29440
-
Lp Eng Arc Apc Ov connectionPoolCapacity (connCap)

The attribute specifies per APC the maximum number connectionResources.
The attribute value must satisfy the rule:
APC 0, , 3 Lp Eng Arc Apc Ov connCap < connCap + protConnCap

The FP and APC connectionResources are consumed by CA attribute values.
3.3.2.1.2.3
ATMIF CA ATTRIBUTES:
The AtmIf CA attributes provide the ability to set the port capacity in terms of amount of
atmConnections.
Moreover atmIf CA attributes are used for setting the port atmInterfaceType.
The AtmIf CA attributes are set per port.
AtmIf CA Attribute list:
- ATTRIBUTE AtmIf CA maxVcc (vcc)
Setting of the maximum amount of vc Connections that can be configured on a port.
It encompasses both independent vcc and vcc configured under a VPT.
Vcc range: [0, , 16384]
Associated Rule:
maxVcc < [nZVcc + (nVpis * nVcc) 1 ]

ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 54/240
ATTRIBUTE AtmIf CA maxVpcs (vpcs)

Setting of the maximum amount of VP Connections that can be configured on a port.
ApplicationContexts:
- VP Switching for VPs identified with a Vpi value outside of [firstVpi, firstVpi+nVpi]
range,
- UMTS RNC: VPC port of the 2ports hairpin solution for VP trafficShaping.
Vpcs range: [0, 4096]
Associated Rule:
maxVpcs < [ 255 - nVpis ], case of the UNI interface,

maxVpcs < [ 4095 - nVpis ], case of the NNI interface.
-
ATTRIBUTE AtmIf CA maxVpts (vpts)

Setting of the maximum amount of VP endPoints that can be configured on a port.
- UMTS RNC: VPT port of the 2ports hairpin solution for VP trafficShaping.
Vpts range: [0, 4096]
Associated Rule:
Up to 512 VPTs per FP,

Up to 256 VPTs per port,
maxVpts < ConnMap nVpi
The following CA Attributes concerns Vci ranges for dynamically established atmConnections: SVC,
PNNI sPVCs. The CA autoSelected Vci ranges are subsets of connMap ranges.
-
ATTRIBUTE AtmIf CA minAutoSelectedVciForVpiZero (minVciVpiZero)

Setting of the minimum Vci value of the autoSelected range for Vpi=0.
minVciVpiZero range: [0, 65 535].
- UMTS RNC: PNNI sPVCs.
ATTRIBUTE AtmIf CA maxAutoSelectedVciForVpiZero (maxVciVpiZero)
Setting of the maximum Vci value of the autoSelected range for Vpi=0.
maxVciVpiZero range: [0, 65 535].
Associated Rule:
The VCI range delimitated by minVciVpiZero and maxVciVpiZero must be a subset
of connMap nZVcc:
maxVciVpiZero =< connMap nZVcc
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 55/240
ATTRIBUTE AtmIf CA minAutoSelectedVciForNonZeroVpi (minVciNonZeroVpi)

Setting of the minimum Vci value of the autoSelected range for nonZeroVpi.
minVciNonZeroVpi range: [5, 65 535].
ATTRIBUTE AtmIf CA maxAutoSelectedVciForNonZeroVpi (maxVciNonZeroVpi)
Setting of the maximum Vci value of the autoSelected range for nonZeroVpi.
maxVciVpiZero range: [0, 65 535].
Associated Rule:
The VCI range delimitated by minVciNonZeroVpi and maxVciNonZeroVpi must be
a subset of connMap nVcc:
maxVciNonZeroVpi =< connMap nVcc
The CA Attribute values consumed FP resources. Therefore check the APC connectionResource
UsageRate:
For each APC:
port 0, 3 (maxVcc + maxVpcs + (maxVpts * 2) + 1) < Apc ConnCap

It is assumed that the formula 4 is satisfied,
Remark:
-
The formula 10 is valid for basicVPT, and not valid for standardVPT (StandardVPT is not
available on 16pOC3/Stm1 FP).
ATTRIBUTE AtmIf CA maxVpiBits

Setting of the atmInterfaceType: UNI or NNI,
maxVpi = 8 for UNI, maxVpi = 12 for NNI,
Remark:
The CA attributes: minAutoSelectedVpi and maxAutoSelectedVpi are not introduced in the TEG
since not used in the RNC.
The VPC space delimited by [minAutoSelectedVpi,
maxAutoSelectedVpi] is consumed by dynamic established VP Connections: SVP, PNNI
sPVP.
3.3.2.1.3 QOS:
-
serviceCategories:
- Supported: Cbr, rtVbr, nrtVbr, Ubr, Ubr with Mdcr,
- Not supported: ABR.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 56/240
16pOC3 PQC FP Scheduler:

The 16pOC3/STM1 PQC FP supports 4 classQueues (Vr Dsd Phb TrafficClass = sc4q) and 5 EP:
EP0, EP2, EP3, EP4 and EP7.
The MBG is configured against the EP2, EP3, EP4 and EP7 whereas no MBG configured against the
EP0.
The MBG has precedence over the EP0.
For each EP, the guaranteed bandwidth = MBG * link bw, in other word the guaranteed
bandwidth does not take into consideration the AbsolutePriorities: EP0 and EP1.
The scheduler first allocates minimum bandwidth guaranteed to each EP and then allocates the
remaining available bandwidth to the different EP according to a strict priority.
This type of scheduling is referred to as Priority Guaranteed Queuing (PGQ).
Qos mapping table:

The qos mapping table provides:
The mapping of UMTS qos information to ATM qos information (SC) and
The mapping of UMTS qos information to IP qos information to ATM qos information to
cover case of IP over atm interfaces: Iub oam and IuPS UP.
The set of available DSCP values on a VR is determined by the choice of the Vr
DifferentiatedServicesDomain (dsd) component instance:
DSD instance
multiService
CSx, EF, AFxy, DE
DSCP
classSelector
CSx
assuredForwarding
AFxy, CS6, DE
packetVoice
CS7, CS6, CS5, CS1, EF, AF1y, DE
wirelessUmts
Custom
CS7, CS6, CS1, EF, AF3y, AF2y, DE

CS6, DE
Notes: x is in the range [0 to 7] for the CS DSCP, [1 to 4] for the AF DSCP, and y in the
range [1 to 3]. The CS0 is equivalent to Default DSCP then removed from the text.
Rule: IubTEG_16pOC3/Stm1 PQC_Qos_01
It is suggested to set the DSD = multiService.
The following table provides the Transport qos information mapping suggested for the 16pOC3 PQC
FP:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 57/240
UMTS
UP
CP
TrafficClass
Conversational
Signaling
Streaming
ARP
1, 2, 3
na
0
1
2
0
1
UP
Interactive
Background
2
0
1
2
0,1,2
THP
na
1
2
1
2
1
2
3
na
DSCP
trafficClass
sc4q
EP
MBG%
ipCos
SC
CS7
CS6
EF
critical
network
premium
77
cbr
platinium
18
rtVbr
nrtVbr
ubr
AF41
AF42
AF43
AF31
AF21
AF32
AF22
AF33
AF23
AF11
AF12
AF13
DE
gold
silver
gold
silver
gold
silver
bronze
bronze
bronze
Standard
Table 16 Qos mapping table for the 16pOC3 PQC FP

DSCP
dropPrecedence
EF, AFx1, CS6, CS7
Low
AFx2
Medium
AFx3, DE
High
with x = (1, 2, 3, 4)
Table 17 discard policy for the 16pOC3 PQC FP
3.3.2.2 16POC3/STM1 MS3 FP

The FP supports 16 ATM over SONET/SDH links or 16 POS links.
The 16pOC3 MS3FP card is based on GQM TrafficManagement ASIC, its behaviour in terms of qos and
trafficmanagement depends on the GQM.
The 16pOC3/Stm1 ATM/POS FP is also known as 16pOC3/Stm1 MS3 FP, while MS3 is the new architecture
name for the FP.
Swap of the 16pOC3 PQC FP with the 16pOC3 MS3 FP:
Before replacing the 16pOC3/Stm1 PQC FP by the 16pOC3/Stm1 MS3 FP,
- QOS parameter mapping: The IpCos parameter has been migrated to DiffServ parameter before
introduction of the new FP .
3.3.2.2.1 TRANSMISSION CHARACTERISTICS:

-
16 ports OC3 / Stm1 not channelized,

All the 16 ports are configured to support either SONET or SDH frames (Component: Lp/n
Sonet/n or Lp/n Sdh/n). The mix of oc3 and stm1 links on one card is not supported.
Plugable optics: long, intermediate and short reach single mode optics
APS/MSP: 1+1 interCard APS, with options: Unidirectional/Bidirectional, revertive or not
revertive, equivalent to the 16pOC3/Stm1 FP APC based. The APS SD BER threshold is
configurable.
Equipment Protection (EP): the EP switching is triggered by a card removal, card hardware failure,
software failure (causing a card crash) or card manually reset.
OAM Signals: LOS, LOF, LOP, AIS, MS-RDI, FEBE, P-RDI, BIP, Header Error Check Sequence,
Clock: the clockingSource attribute does not support the value Line.
3.3.2.2.2 ATM CHARACTERISTICS:

-
atmInterface type: UNI, NNI,

Vpi range: [0, 255] for UNI, [0, 4095] for NNI,
Vci range for user traffic: [32, 65535],
The Vpi and Vci ranges are more limited by the conmap parameters,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 58/240
The FP resources:
Rule: IubTEG_16pOC3/Stm1 MS3_01
- Up to 45000 atmConnections per FP,
- Up to 32000 perVc queues,
- Since only perVc queues are used in the context of the UMTS, set the Lp/Eng/Arc
component to 32000.
- Up to 16000 atmConnections per port.
Remark:
- If more than 32000 atmConnections are configured, then there are not enough perVc queues,
either the atmConnections are assigned to common queues or to a mix of common and perVc
queues.
AtmConnection types: Pvc, Pvp, Svc, Svp, sPvc, and sPvp,

Vpt:
- BasicVpt. StandardVpt not supported. As a result the Vpd/vptType attribute must be set to
basic.
- The vpt CAC is optional.
- FP VPT capacity:
Up to 512 basicVPT per FP, up to 256 basicVPT per port .
AtmSignaling: Pnni and Hpnni v1.0, Uni 3.0/3.1/4.0,

EFCI: supported. Fixed threshold 35%.
Not Supported: CES.
3.3.2.2.2.1
TRAFFICMANAGEMENT:
The trafficManagement features are provided by the GQM:

- Policing:
dual rate GCRA, discarding, tagging,
- TrafficShaping:
o SingleRate and dualRate trafficShaping,
o The ShapeFairQueueing may apply to up 4 EP, with EP in the range [0, 7],
o Unshaped atmConnections are permitted on a shaped EP
o Basic VPT shaping supported .
up to 512 VPT per FP, up to 256 VPT per port,
The minimum shaping rate is 100 cells/s
3.3.2.2.2.2
AAL5:
EPD, PPD, LPD and W-RED supported,

(Only EPD supported in the 16pOC3/Stm1 APC based FP)
3.3.2.2.2.3
OAM:
According to I610,
PM and CC not supported,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 59/240
3.3.2.2.3 IP CHARACTERISTICS:
The FP IP forwarding capacity: 2,5 Gb/s .
FP characteristics:
The FP supports:
- Static routing,
- MPE,
- inverseARP,
- LocalMedia.
- ECMP ,
The FP does not support:
- DHCP relayAgent,.
QOS:
The IPCos parameter is removed and replaced by the DSCP parameter.
As a result the DSCP is mapped directly to a SC. The removal of IpCos parameter must be
done before introducing the 16pOC3/Stm1 POS/Atm FP in the RNC.
VR/n
|--------DiffServ/I
|--------IP
|
(new)
ECMP:
The FP supports flow based ECMP with up to 3 nextHops.
To activate the IP route traffic loadSharing amongst several paths:
- At least 2 nextHops and up to 3 nextHops are configured under the IP route,
- The ecmpMode parameter is set to perFlowEnh.
ecmpMode = perFlowEnh when ECMP is required.
The AtmMpe Pnni sPvc Src/Dest carrierGrade.
3.3.2.2.4 QOS
The 16pOC3 MS3 FP supports the serviceCategories: Cbr, rtVbr, nrtVbr, Ubr, Ubr with Mdcr known as
UBR+.
It doesnt suppot ABR.
FP Scheduler:
The 16pOC3 MS3 FP provides a two tier scheduler:
- Connection Scheduler (same mechanism as for the AQM based FP):
- WFQ:
- The connection queue weight is either proportional to ECR (default), PCR or
SCR, or
- The connection queue weight is explicitly configured; weight range [1, 4095],
- SFQ:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 60/240
- The shaping rate is either the PCR or both PCR and SCR,
- ClassScheduler:
EP (EmissionPriority) range: [0, 7],
Up to 4 classQueues can be simultaneously configured
AbsolutePriority for EP0 and EP1,
WFQ based on the MBG for the EP2 to EP7,
Since the absolute EP (EP0 and EP1) have been served, the 16pOC3 MS3 FP divides the
total residual bandwidth among the EP proportional to the MBG configured against each
EP. This is referred to as Weighted Fair Queuing (WFQ) where the MBG represents the
weight for the EP.
As a consequence the MBG has a major impact on the QOS.
Each serviceCategory is mapped to one EP:
Rule: IubTEG_16pOC3/Stm1 MS3_QOS_01
Mapping between ServiceCategory and EmissionPriority:
Two different SC can not me mapped to one EP. Unless they are both shaped.
EP CBR EP rtVBR EP nrtVbr EP UBR
MBG:
The MBG parameter configured against nonAbsolute EP is taken into consideration by the
ClassScheduler.
The MBG is set through the command: ATTRIBUTE AtmIf Ep minimumBandwidthGuarantee
(minBw).
The parameter is set with either with:
- a MBG value in the range [0, 100%] or
- The value Priority.
The mix of priority and MBG provisioning is not supported on the 16pOC3/Stm1 MS3 FP.
What is supported is either specifying the priority option for all EPs, or the explicit
configuration of the MBG value for all used EP used on one atmInterface.
Rule: IubTEG_16pOC3/Stm1 MS3_ QOS_02
On one16pOC3/Stm1 MS3 FP atm interface:
- if a MBG value is configured against an EP, then a MBG value must be
configured against each nonAbsolute EP (EP2 to EP7),
- Else, the minimumBandwidthGuarantee is set with Priority value for each
nonAbsolute EP.
A mix of explicit MBG values and Priority is not allowed on atm interface.
The explicit configured MBG values must satisfy the following rules:
When each nonAbsolute EP is configured with an explicit MBG value,
On one atm interface, the MBG values must be chosen in such a way to satisfy:
EP2 to EP7 MBG = 100%

MBG EP2 > MBG EP3 > MBG EP4 > MBG EP5 > MBG EP6 > MBG EP7.
Expected QOS behavior according to the explicit configured MBG value or with Priority:
1/ Case of the MBG = explicit configured MBG value in the range [0, 100]:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 61/240
The MBG configured against the non absolute EPi (EP2 to EP7), specifies the proportion of
the bandwidth assigned to the EPi after absolute priority EP have been served.
E.g. guaranteedBw for EP3:
GuaranteedBw for EP3 = [linkRate (EP0+EP1) traffic] * MBGEP3 / (MBGEP2
+ MBGEP4 + MBGEP7),
The MBG does not protect low priority traffics against traffic Starvation resulting from the two
absolute Priorities:
On GQM based FP, the MBG assigned against an EP has no precedence over
absolute EmissionPriority (EP0, EP1).
Remark:
- If real time traffic (eg: CBR or rtVbr) is mapped to EP2, then the MBG assigned to EP7 add
potential Delay and Jitter on the real time traffic.
- An EP class queue is able to transmit beyond its guaranteed bandwidth, if the bandwidth is
available.
- If the two absolute EP (EP0 and EP1), dont consume any bandwidth, whatever the MBG
configured against the nonAbsolute EP, the non absolute EP may transmit up to the linkRate.
Based on:
- The previous releases recommendation indicating to set an MBG=2% against the EP7,
- The QOS Information mapping table specified in the previous release,
- The default weigh assigned by the Passport to the EP for case of MBG = Priority,
The following MBG values are suggested as default values:
Cbr
rtVbr
nrtVbr
Ubr
EP2
EP3
EP4
EP7
2/ Case of MBG = Priority:

A value of priority means the EP is scheduled according to a strict priority scheme without
providing any additional bandwidth guarantee to the EP.
The system assigns a weigh to each non absolute EP, in such a way to expect a Priority
Guaranteed Queuing behavior. The weigh assigned to the non absolute EP, depends on how
many EP are used.
The weigh assigned to the non absolute EP, depends on how many EP are used:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 62/240
# Used
non absolute
EP
Weight assigned to the non absolute EP

1 EP
1
2
100
99
90
77
18
st
2d EP
4th EP
3d EP
100
100
100
100
Discard mechanism:
Four discardPriority thresholds are set on a connection queue, Default values:
DP0
Threshold
100%
DP1
90%
DP2
75%
DP3
35%
The discard thresholds apply to the common and the perVc queues.
The four DP thresholds are not configurable.
The mapping of (SC+CLP) to DP (DiscardPriority) is hardcoded:
DP
Cbr
Clp0
DP1
Clp1
DP3
rtVbr
DP1
DP3
nrtVbr
DP2
DP3
Ubr
DP3
DP3
WiseDiscard:
Within each 4 CC (congestionControl level), are set the EPD, PPD, and EFCI thresholds:
The CC, EPD, PPD and EFCI thresholds are hardcoded with the following
values:
perVc Queue
Thresholds
CCO
DP
100%
PPD
99%
EPD
90%
CC1
90%
89%
80%
CC2
75%
74%
65%
CC3
35%
34%
25%
EFCI
35%
CLP:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 63/240
Context of IP over atm interface:

The atm Cell CLP value is determined by the ATM service category (SC) and the Drop
Precedence of the IP packet that reached the VR that has the DSD provisioned on.
The IP packet dropPrecedence is in the range: [ low (1), medium (2) or high (3)].
The IP Packet dropPrecedence is set by the PMC-RAB.
Here below the CLP value according to the SC and DP:
serviceCategory
Cbr
Cbr
Cbr
rtVbr
rtVbr
rtVbr
nrtVbr
nrtVbr
nrtVbr
Ubr
Ubr
Ubr
dropPrecedence
1
2
3
1
2
3
1
2
3
1
2
3
=>
Tx CLP
0
0
1
0
0
1
0
0
1
1
1
1
Conclusion:
- The ubr atmConnection cells are always tagged,
- The cbr and vbr atmConnection are tagged only for dropPrecedence 3.
QOS mapping:
The qos mapping table provides:
- The mapping of UMTS qos information to ATM qos information (SC) and
- The mapping of UMTS qos information to IP qos information to ATM qos information
to cover case of IP over atm interfaces: Iub oam and IuPS UP.
Case of IP over ATM flow qos mapping:
The set of available DSCP values for the user IP packets is determined by the choice of
the Vr DifferentiatedServicesDomain (dsd) component instance:
DSD instance
multiService
DSCP
CSx, EF, AFxy, DE
classSelector
CSx
AssuredForwarding
AFxy, CS6, DE
packetVoice
wirelessUmts
Custom
CS6, DE
Notes: x is in the range [0 to 7] for the CS DSCP, [1 to 4] for the AF DSCP, and y
in the range [1 to 3]. The CS0 is equivalent to Default DSCP then removed from the
text.
It is suggested to set the DSD = multiService.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 64/240
The following table provides the Transport qos information mapping suggested for the 16pOC3 MS3
FP:
UMTS
TrafficClass
ARP
THP
DSCP
trafficClass
sc4q
EP
MBG%
77
ipCos
SC
cbr
critical
Conversational
Signaling
UP
CP
Streaming
CS6
EF
1, 2, 3
na
0
1
2
Interactive
Background
AF42
AF43
AF31
AF21
AF32
AF22
AF33
AF23
AF11
AF12
AF13
DE
1
2
1
2
1
2
UP
AF41
na
2
0
1
2
0,1,2
network
premium
3
na
platinium
gold
silver
gold
silver
gold
silver
bronze
bronze
bronze
Standard
17
rtVbr
nrtVbr
ubr
Table 18 Qos mapping table for the 16pOC3 MS3 FP
DSCP
dropPrecedence
EF, AFx1, CS6
Low
AFx2
Medium
AFx3, DE
High
with x = (1, 2, 3, 4)
Table 19 discard policy for the 16pOC3 MS3 FP
3.3.2.2.5 TRAFFICMEASUREMENT
All the Sonet and SDH spooled statistics from the Passport are supported,
All the Atm interface and Vpt spooled statistics from the Passport are supported.
3.3.2.2.6 HARDWARE:
-
The FP is based on GQM ASIC,

Carrier Grade: Hitless Software Migration (HSM),
Y-Splitter is supported,
Atm-Spy supported,
GQM:
Provides both perSC common queue and perVc queues,
The conmap parameters are no more configured, the FP supports a dynamic management of
the atmConnection identifier resources.
3.3.2.3 PSFP OR DCPS FP:

The RNC is populated either with PSFP or DCPS FP.
The mixity of PSFP and DCPS is not supported.
The PSFP/DCPS FP handles the userPlane traffic and the controlPlane traffic (NBAP, RANAP, RNSAP,
ALCAP, SCCP, MTP3, SAAL-NNI and SCTP).
A PSFP/DCPS FP is composed of 6 PMC cards and one PDC.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 65/240
A PMC-Role is assigned to each PMC. Six different PMC roles are specified: PMC-PC, PMC-RAB,
PMC-M, PMC-NI, PMC-TMU and PMC-OMU.
The PMC Role is driven by the the PMC position in the PSFP and the PSFP position in the shelf:
- The PMC-M are hosted by the DCPS FP cards in the first and the second slots,
- The PMC-OMU are hosted by the third and forth PSFP cards,
- The PMC-NI are hosted by the third and forth PSFP cards,
- There is one PMC-PC per PSFP card,
- There is one or two PMC-TMU per PSFP card. There are 14 PMC-TMU on a RNC composed of
12 DCPS FP and 12 PMC-TMU on a RNC composed of 10 PSFP. The PMC-TMU is in position 1
on each PSFP card. The PSFP cards with two PMC-TMU are located in slot 10 and 11 and the
second PMC-TMU is in PMC position 5,
- The PMC-RAB role is assigned to all the remaining PMC,
Beside:
- The active and standby CP are in slot 0 and 1 respectively
- The active and standby 16p/OC3 FP are located in slot 8 and 9 respectively.
- The active and standby 4pGE FP are located in slot 14 and 15 respectively.
3.3.2.3.1 THE PDC AND PMC-ROLE DESCRIPTION:

-
PDC:
Each PDC provides a management functions for that one DCPS FP card only.
Moreover the PDC is in charge of handling the SaalNNI and the Sctp.
The SaalNNI and Sctp traffic is distributed over all the PDC with exception of those running
PMC-NI.
Each PDC is configured with one external IP@ which is used as the RNC CP IP@ on the
IuPS interface.
PMC-OMU:
The OAM functionality is implemented on 2 PMC-OMU components located on different
PSFP cards.
The PMC-OMU handles also the CBS traffic (IuBC).
The sparing scheme is 1+1. The PMC-OMU switch produces no interruption of service except
in case of double fault scenarios.
PMC-M:
The PMC-M hosts the CID management and the Alcap for Iub Iur and IuCS interfaces.
The RNC is populated with two PMC-M components, working in 1+1 redundancy scheme.
Two PMC-M components reside on different PSFP cards.
The PMC-M switch produces no interruption of existing calls except in case of double fault
scenarios. New calls cannot be initiated for approximately 5 seconds.
PMC-NI:
The MTP3b and SCCP protocols are implemented on two PMC-NI components located on
different DCPS FP cards.
Moreover the PMC-NI handles the locationServices traffic (IuPC).
The RNC is populated with two PMC-NI components, working in 1+1 redundancy scheme.
The sparing scheme is 1+1. The PMC-NI switch produces no interruption of existing calls or
service except in double fault scenarios.
The PMC-NI is PSFP cards 2 and 3.
PMC-TMU:
The PMC-TMU is in charge of processing:
- The UMTS protocols: RANAP, RNSAP, and NBAP,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 66/240
- The UMTS heartBeat on the Iub,

- The SCTP protocol on the Iub.
Moreover PMC-TMU supports RRM, RRC, and aal2Link CAC.
Up to 14 PMC-TMU components in the ATM RNC and IP RNC, up to 12 PMC-TMU in the
Hybrid RNC are spread over all the DCPS FP.
The sparing scheme is N+1 if 7 or fewer PSFP and otherwise N+2 spared.
If a PMC-TMU fails, the control planes for the NodeB and cells managed by that TMU are
automatically taken over by one of the spare PMC-TMU within 30 seconds but individual
Radio Links are lost. Individual calls are managed by all the PMC-TMU in load sharing mode.
If a PMC-TMU fails the calls on that PMC-TMU are lost.
PMC-RAB:
The UMTS user plane is handled in up to 40 PMC-RABs within an ATM and IP RNC, in up
to 32 PMC-RABs within a Hybrid RNC spread over all the PSFP in load sharing mode.
Cell common channel user plane functionality is spared so if one PMC-RAB fails its cell
common channel user plane load is taken over by up to 5 other PMC-RAB on other DCPS FP
cards with no loss of common channel service.
Individual call user planes are managed by all the PMC-RAB in load sharing mode.
If a PMC-RAB fails the calls on that PMC-RAB are lost.
Each PMC-RAB is configured with one external IP address used as the RNC IuPS UP IP@.
PMC-PC:
Up to 12 PMC-PC within an ATM RNC and up to 10 PMC-PC within an Hybrid RNC
PMC-PC sparing scheme: N+1.
RNC ATM Interface, PMC-PC function:
The PMC-PC is the aal2 Path point of termination.
The PMC-PC achieves the aal2 to UDP conversion.
The Aal2 paths and the PMC-PC functionality is spared so if one PMC-PC fails its
paths and load is spread over up to 5 other PMC-PC located on other DCPS FP cards
without interruption of cell common channels or calls in progress.
3.3.2.3.2 RNC PSFP/DCPS FP COMPOSITION:

Case of atm RNC:
Since 2 RNC slots are consumed by the interface card, the RNC hardware composition
becomes:
- Up to 12 PSFP,
- Up to 12 PMC-PC,
- Up to 14 PMC-TMU,
- Up to 10 PDC-saalNNI,
- Up to 40 PMC-RAB.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 67/240
RNC
2
0&1
10
8&9
11
12
13
14
15
DCPS
DCPS 66 DCPS
DCPS 77 DCPS
DCPS 88 DCPS
DCPS 99 DCPS
DCPS 10
10 DCPS
DCPS 11
11
Pdc
Pdc
saalNni
saalNni
Pdc
Pdc
saalNni
saalNni
Pdc
Pdc
saalNni
saalNni
Pdc
Pdc
saalNni
saalNni
Pdc
Pdc
saalNni
saalNni
Pdc
Pdc
saalNni
saalNni
Pdc
Pdc
saalNni
saalNni
Pdc
Pdc
saalNni
saalNni
Pdc
Pdc
saalNni
saalNni
Pdc
Pdc
saalNni
saalNni
Pdc
Pdc
saalNni
saalNni
Pdc
Pdc
saalNni
saalNni
RAB
RAB
RAB
RAB
OMU
OMU
OMU
OMU
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
TMU
TMU
TMU
TMU
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
PMC-M
PMC-M PMC-M
PMC-M
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
NI
NI
NI
NI
RAB
RAB
RAB
RAB
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
16pOC3 FP
16pOC3 FP
CP3
CP3
DCPS
DCPS 00 DCPS
DCPS 11 DCPS
DCPS 22 DCPS
DCPS 33 DCPS
DCPS 44 DCPS
DCPS 55
PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT
PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT
TEG
Figure 3-21, ATM RNC DCPS FP composition
3.3.3
RNC CAPACITY
The RNC capacity depends on the type and amount of component it is populated with and parameter
setting.
Parameter:
The setting of the RncIn/hardwareCapability component determines the RNC capacity:
Rule: IubTEG_RNC-Capacity_1
- Set hardwareCapability = allPktServSP2FullDim when the RNC is populated with DCPS, CP4
and 16pOC3 MS3 FP and as an option gigaEth cards.
- Set hardwareCapability = allPktServSP2 when the RNC is populated with DCPS or PSFP, CP3
and 16pOC3 MS3 FP or classical 16pOC3 FP cards.
- Set hardwareCapability = all6mPktServ when the RNC is populated with PSFP, CP3 and
16pOC3 MS3 FP or classical 16pOC3 FP cards.
Avoid:
- hardwareCapability= allPktServSP2FullDim when RNC is populated with CP3.
- hardwareCapability= allPktServSP2 or all6mPktServ when RNC is populated with
CP4.
Capacity:
- When the RNC is populated with: DCPS, CP4, and MS3 and the hardwareCapability parameter =
allPktServSP2FullDim:
UA5-1-2
UA6, hardwareCapability parameter= allPktServSP2FullDim
12 PSFP
4 DCPS
6 DCPS
8 DCPS
10 DCPS
12 DCPS
# nodeB
200
600
1000
1400
2000
2400
# cells
1200
612
1020
1428
2040
2448
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 68/240
- When the RNC is populated with: DCPS, CP3 or CP4 and the hardwareCapability parameter =
allPktServSP2:
UA6, hardwareCapability parameter allPktServSP2.
UA5-1-2
12 PSFP
4 DCPS
6 DCPS
8 DCPS
10 DCPS
12 DCPS
# nodeB
200
360
600
720
800
1200
# cells
1200
360
600
720
800
1200
- When the RNC is populated with: PSFP, CP3 and the hardwareCapability parameter = all6mPktServ:
UA6, hardwareCapability parameter all6mPktServ.
UA5-1-2
3.3.4
12 PSFP
4 PSFP
6 PSFP
8 PSFP
10 PSFP
12 PSFP
# nodeB
200
360
600
720
800
1200
# cells
1200
360
600
720
800
1200
TRANSMISSION
3.3.4.1 PDH:
Different kinds of PDH links are specified either at ITU or at ANSI.
- ITU PDH links:
- E1, 2048 kbit/s,
- E2, 8448 kbit/s, multiplex of 4 E1,
- E3, 34368 kbit/s, multiplex of 4 E2,
- E4, 139264 kbit/s, multiplex of 4 E3, or
- E5, 564992 kbit/s, multiplex of 4 E4.
- ANSI PDH links :
- T1, 1544 kbit/s,
- T2, 6312 kbit/s, multiplex of 4 T1,
- T3, 44736 kbit/s, multiplex of 7 T2,
- T4, 274176 kbit/s, multiplex of 6 T3.
3.3.4.1.1 T1 LINK:
T1 frame is 193 bits length. The frame repetition rate is 125s.
Therefore the T1 throughput is 1,544 Mb/s = 3622 cellules per second.
The T1 frame is split in:
- 1 bit, first bit of the frame, called F bit, dedicated to synchronisation, it is set to 1 for odd frame,
and to 0 for even frame, followed by
- 24 timeSlots, 64 kb/s throughput each when configured with ATM.
Remarks:
MSA32 FP doesnt manage T1 links.
3.3.4.1.1.1
ATM ON T1:
ATM cells are mapped into bits 2 to 193 (i.e. time slots 1 to 24 described) of the 1544 kbits/s frame with
the byte structure of the cell aligned with the byte structure of the frame:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 69/240
193 bits/125 sec

Header
F
F
F
F
F
F
Header
Header
ATM cell mapping field: 24 octets (TS1 ~ TS24)
Provides F3 OAM functions:

Detection of loss of frame alignment
Performance monitoring (CRC-6)
Transmission of FERF and LOC
Performance reporting
ATM
cell
Header
53 octets
T1302260-93
Since T1 payload is 192 bits each 125 s, throughput available for ATM is 1,536 Mb/s,
Rule: IubTEG_T1_1
T1 ATM throughput is 1,536 Mb/s = 3622 Cells/s.
The first bit of a frame is designated an F-bit, and is used for:
- Performance monitoring, CRC6,
- Transmission OAM Signals
- Detection of loss of frame alignment.
For more information refer to [R47 & 48].
3.3.4.1.1.2
CRC:
On T1 is configured as an option CRC.

CRC6 is specified for T1 Signal.
A T1 multiframe is composed of 24 T1 frames.
Within the 24 F bits of a T1 multiframe, 6 bits are reserved for CRC.
3.3.4.1.2 T3 LINK:
T3 link is resulting from the multiplexing of seven T2 tributaries.
T3 throughput is 44 736 kbits/s = 7 * 6312 kb/s + second stage multiplexing Overhead.
There are two formats for T3, T3 signal may be either Channelized or unchannelized:
- Channelized means that T3 signal results from the two stages multiplexing:
T3 = 7 * T2 and T2 = 4 * T1.
A Channelized T3 is the result of the multiplexing of 28 DS1 links.
A Channelized T3 is composed of 7 * 4 * 24 = 672 timeSlots.
- Unchannelized means that T3 payload is filled with bulk data, either cell direct mapping or PLCP
based.
Only Channelized T3 is defined in this section, since unchannelized are not used in UMTS
network.
Throughput
7 * T2
T3
T3 overhead
7 * 6312 = 44 184 kb/s
44 736 kb/s
552 kb/s
7 * 789 = 5523 bits
4760 bits (note)
56 bits
# Bits
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 70/240
7 * 96 = timeSlots
# Timeslot
672 timeSlots
2 timeSlots
Note:
T3 is defined as 44 736 kb/s throughput, and 4760 bits multiframe size, therefore 1,174 T3
frames are transmitted each 125 s.
Detail: 44,736*125 = 5592 bits are transmitted; 5592 bits / 4760 bits = 1,174 T3 multiframes
are transmitted.
T3 multiframe is composed of 4760 bits:
- 4704 bits payload,
- 56 bits overhead.
T3 user throughput in cells/s is calculated on following way:
[44 736 kbit/s / (53 * 8)] * 4704 / 4760 = 104 268 cells/s
Rule: IubTEG_T3_1
T3 ATM throughput is 104 268 Cells/s.
T3 multiframe is composed of 7 frames 680 bits length, called M-sub-frames.
One M-sub-frame is divided into 8 blocks of 85 bits. One block is composed of one overhead bit,
following by 84 bits payload. Indeed 7*8=56 bits overhead within a T3 frame.
X1
X2
P1
P2
M1
M2
M3
F1
F1
F1
F1
F1
F1
F1
C11
C21
C31
C41
C51
C61
C71
F2
F2
F2
F2
F2
F2
F2
C12
C22
C32
C42
C52
C62
C72
F3
F3
F3
F3
F3
F3
F3
C13
C23
C33
C43
C53
C63
C73
F4
F4
F4
F4
F4
F4
F4
Figure 3-22 T3 multiframe structure

Overhead bits functions:
X-bits (X1, X2):
X1 and X2 are used to indicate received errored multiframes to the remote-end
(remote alarm indication RAI or yellow signal);
X1 = X2 = 1 during error free condition,
X1 = X2 = 0 if Loss of Signal (LOS), Out of Frame (OOF), Alarm

Indication Signal (AIS) or Slips are detected in the incoming signal.
P-bits (P1, P2):

P1 and P2 are used for performance monitoring; these bits carry parity information
calculated over the 4704 payload bits in the preceding multiframe:
-
P1 = P2 = 1 if the digital sum of all payload bits is one, and
P1 = P2 = 0 if the digital sum of all payload bits is zero.
The P-bits are calculated and may be modified at each section of a facility;
therefore, the P-bits provide SECTION performance information NOT end-to-end
performance information.
Multiframe alignment signal (M1, M2, M3) :
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 71/240
The multiframe alignment signal 010 (M1 = 0, M2 = 1, M3 = 0) is used to locate all

seven M-subframes, within the multiframe.
M-subframe alignment signal (F1, F2, F3, F4):
The M-subframe alignment signal 1001 (F1 = 1, F2 = 0, F3 = 0, F4 = 1) is used to

identify the overhead bit positions.
C-bits (C11, C12, C13, C21, ... Cij, ... C73):
Either used for bit Parity, or bit stuffing.
3.3.4.1.2.1
-
OAM:
Alarm Indication Signal (AIS):
AIS signal consists in setting information bits with 1010... sequence, starting with a binary one (1)
after each M-bit, F-bit, X-bit, P-bit, and C-bit. The C-bits are set to binary zero (C1 = 0, C2 = 0, C3 =
0).
The X-bits are set to binary one (X1 = 1, X2 = 1).
Idle Signal (Idle):
Idle Signal consists in setting information bits are set to a 1100... sequence, starting with a binary one
(1) after each M-bit, F-bit, X-bit, and C-bit. The C-bits are set to binary zero (C1 = 0, C2 = 0, C3 =
0), in the third M-subframe (C31, C32, C33); the remaining C-Bits (three C-bits in M-subframes 1,
2, 4, 5, 6, and 7) may be individually set to one or zero, and may vary with time. The X-bits are set to
binary one (X1 = 1, X2 = 1).
3.3.4.2 SDH/SONET:
Reference: [R50, 51, 40, 110].
SONET is recommended by ANSI, whereas SDH is recommended by ITU.
Difference between SDH and SONET:
- Frame field terminology,
- Minor differences in the application of certain overhead bytes, level of detail beyond the scope of
this document.
3.3.4.2.1 THROUGHPUT
Two levels of SDH/SONET signals are used within UMTS network.
These levels and associated throughputs are presented in the following table:
SDH Level
SONET Level
Throughput
Throughput
User in Mb/s
Throughput
User in Cells/s
STM1
ClearChannel
STS3 = OC3
Concatenated
155,52 Mb/s
149,76 Mb/s
353 207
STM4
STS12 = OC12
622,08 Mb/s
1 412 828
Notation:
- STM-n stands for SynchronousTransfertModule level n. It identifies the level of SDH signal.
- STS-n stands for SynchronousTransfertSignal level n. Electrical specification for signal
generation level.
- OC-n stands for OpticalCarrier level n: Optical specification for signal generation level.
3.3.4.2.2 TRANSMISSION OAM

Severe problems in signal transmission are notified by means of Maintenance Signals and Status
Signals.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 72/240
Maintenance signals are resulting from problem detected on the incoming SDH/SONET signal.
At Transmission layer are defined four levels of OAM Flows. These OAM flows carry Maintenance
and Status signals related to different SDH/SONET sections:
- Regenerator Section OAM flow:
Carries Maintenance and Status signals related to SDH RegeneratorSection / SONET

Section.
Multiplex Section OAM flow:
Carries Maintenance and Status signals related to SDH MultiplexSection / SONET Line.
LowOrder Section OAM flow:
Carries Maintenance and Status signals related to SDH lowOrder PathSection / SONET
Path.
HighOrder Section OAM flow:
Carries Maintenance and Status signals related to SDH highOrder PathSection / SONET
Path.
The mechanisms to provide OAM functions and to generate Transmission OAM flows depend on the
transport mechanism of the transmission system as well as on the supervision functions contained
within the physical layer termination functions of equipments. Three types of transmission can be
provided in ATM networks:
- SDH-based transmission systems;
-
PDH-based transmission systems.
Cell-based transmission systems;
Rule: TEG_SDH_OAM_1
On ALU nodes, the OAM Flow Type of Transmission implemented is SDH/PDH based. Not Cell based.
The following transmission status event may be detected:
- LOS (Loss Of Signal): disconnection, idle signal, unequipped signal [R53, R110].
An LOS defect is detected when an all-zeros pattern on the incoming SDH/SONET
signal lasts 100 s or longer. If an all-zeros pattern lasts 2.3 s or less, an LOS defect is
not detected.
The 16-port OC-3 function processor does not monitor signal level for loss.
-
LOF (Loss Of Frame):

An SEF (Severely Errored Framing) condition is detected when the incoming signal has
a minimum of four consecutive errored RSOH A1-A2 framing patterns.
A LOF defect is triggered when an SEF condition persists for 3 ms.
The following Maintenance signals may be generated on different kinds of transmission OAM levels:
- AIS (Alarm Indication Signal):
AIS signal notifies the adjacent downstream node that a failure has occurred upstream.
AIS may be generated at MultiplexSection, LowOrder and HighOrder PathSection level.
The SDH MS-AIS is renamed L-AIS in SONET.
AIS triggers: LOS, LOF condition within 125 s on the incoming link.
The MS-AIS is generated in a STM-N / OC-N that contains a valid MultiplexSection
overhead, the K2 byte indicating MS-AIS and a all-ones pattern in the payload:
K2 byte
Bits 6, 7, 8
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 73/240
111
MS-AIS
The HO & LO P-AIS are coded with as all one in the container and Path pointers.
-
RDI (Remote Defect Indication):

RDI signal notifies the adjacent upstream node that a failure has occurred upstream.
RDI may be generated at MultiplexSection, LowOrder and HighOrder PathSection level.
The SDH MS-RDI is renamed L-RDI in SONET.
RDI triggers:
- LOS, LOF condition within 125 s,
Reception of AIS signal.
Remark: FERF is the old name for RDI.

The MS-RDI is coded within K2 byte:
K2 byte
Bits 6, 7, 8
110
MS-RDI
The HO and LO RDI are coded in one bit of the HO / LO container overhead.
Examples of AIS and RDI generation on UMTS interface composed of SDH nodes:
POH
MSOH
P-RDI
K1
K2
0000 0000 0000

POH
P-AIS
0 000
UMTS
UMTS
UMTS
UMTS
LOS Condition
AIS
ATM
ATM
ATM
ATM
crossConnect
Line 1
TX
TX
RX
RX
W
RX
RX
W
RX
RX
TX
TX
RX
RX
RX
RX
Selected Line
TX
TX
RX
RX
TX
TX
TX
TX
RX
RX
RX
RX
TX
TX
PTE
PTE
RSTE
RSTE
MSTE
MSTE
TX
TX
RX
RX
W
TX
TX
PTE
PTE
TX
TX
Regenerator
Line 0
MultiPlex Section 1
RX
RX
TX
TX
TX
TX
RX
RX
RX
RX
TX
TX
MultiPlex Section 2
Figure 3-23 AIS/RDI Generation
3.3.4.2.3 APS
Reference: [R50 & R51 & R110],
Each Iub ATM SDH line is duplicated on the RNC, referred as 1+1 port redundancy, to ensure that the
network will continue operation when a single SDH line is defective. The duplicated SDH line is either
located:
- In the same card case of MSA32E1/Oc3, it is referred as intraCard APS or
-
In a twin card case of 16pOC3 FP, it is referred as interCard APS.

ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 74/240
One line is configured as the Working line, whereas the associated line is configured as the Protected
Line. See MML Attributes:
ATTRIBUTE Aps workingLine (working)
ATTRIBUTE Aps protectionLine (protection)
Both the Working and the Protected lines carry the same payload in the transmit direction, but only the
Working line is used for received payload.
At the node startup, workingLine is selected for receiving user payload data.
Nodes permanently monitor quality of the received signal. Based on these measurements, either node
keeps the working line selected or decides to select protectionLine for receiving user payload data; this
operation is referred as APS Switch.
The Line switching time in case of a fault (SF/SD on the line) is within 50 ms
RNC
RNC
UMTS
UMTS
Node
Node
ActiveCard
16pOC3
16pOC3
WorkingLine
Rx
Rx
Tx
Tx
STM1
STM1
Rx
Rx
Tx
Tx
Same Signal
Rx
Rx
Tx
Tx
Rx
Rx
Tx
Tx
STM1
SDH Network
RNC Traffic
Traffic generator
generator
RNC
16pOC3
16pOC3
Protected Line
Tx
Tx
Rx
Rx
Tx
Tx
Rx
Rx
16pOC3
16pOC3
STM1
Tx
Tx
Rx
Rx
Tx
Tx
Rx
Rx
16pOC3
16pOC3
Duplication of the egress stream
Decision of the ingress stream to take into consideration

Figure 3-24 APS mechanism
Rule: TEG_SDH_APS-1
It is recommended to activate APS on all 16pOC3 FP ports.
Moreover it is recommended to configured them as
- WorkingLine, Stm1 links on the 16pOC3/Stm1 FP located on RNC-IN Slot 8,
- ProtectedLine, Stm1 links on the 16pOC3/Stm1 FP located on RNC-IN Slot 9.
Abnormal Case:
In some cases, operators may decide temporarily not to connect the second fiber on some interfaces.
In such a context:
- IuxIf constraint: If LAPS component is configured on one port supporting AAL2 Vcc, LAPS
must be configured on all RNC 16pOC3 FP ports supporting AAL2 Vcc, even if the second
fiber not connected, in order to ensure a proper behavior of the equipment.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 75/240
No constraint on other application: AtmMpe,

Moreover to minimize outage duration, for conformity with R&D platform RNC configuration
and to facilitate introduction of future features (eg: Y-Splitter)
Its recommended to configure LAPS on each RNC 16pOC3/Stm1 FP port.
Rule: TEG_SDH_APS-3
It is recommended to configure the LAPS component between each port of the pair of
16pOC3/Stm1 FP even so the protected fiber is not connected to the RNC 16pOC3/Stm1
FP.
Remark:
If LAPS component is configured whereas the protected fiber is not connected, one port is in LOS
condition and then alarms appear on the Management platform for the non connected fiber; to
remove these useless alarms either lock the non populated port (lock Lp/9 Sdh/i) or activate the
"alarm filtering" (W-NMS).
3.3.4.2.3.1 APS OPTIONS (CONFIGURABLE)
Unidirectional/bidirectional mode:
Unidirectional mode: APS switching occurs only in the node which detects misbehavior,
when APS is configured in unidirectional mode. There is no APS switching in the remote
node.
Indeed on node which detects traffic disturbance, selected line is switched from the working
line to the protected line, whereas on adjacent node selected line remains the working line.
Even in unidirectional APS, K1 byte is still used to inform the remote SDH node of the local
action. Moreover, K2 byte/Bit5 is set to 0 to reflect unidirectional mode.
Bidirectional mode: APS switching occurs in the node which detect misbehavior on one
hand, and then in the remote node on the other hand, when APS is configured in
bidirectional mode. Node which detects misbehavior on a link invokes APS and informs
remote node by means of SDH MSOH K1 bytes on the protected line that this link is
experiencing a defect. K1 byte is set with the channel number, 0 or 1 in case of redundancy
1+1, and the nature of the defect which occurs on this link e.g.: SF, SD
Indeed on both adjacent nodes, selected line is switch from working line to protected line.
The K2 byte is transmitted too on the protected line.
Remark:
According to SONET recommendation, each node extremity of a SONET link has to
be configured with the same mode unidirectional or bidirectional. If nodes are
configured on different way, each node will apply unidirectional mode.
See MML Attribute: ATTRIBUTE Aps mode
Unidirectional is the default mode on RNC.
Revertive mode:
After APS switching has been invoked, APS feature allows, since misbehavior has been
corrected, to come back to the initial configuration, if Revertive option is enabled. Such
information is exchanged between SDH nodes by means of K1 bytes set with:
WaitToRestore: the protection line is active and the working line has recovered from a
Signal Fail or Signal Degrade. After the period defined by attribute waitToRestorePeriod the
working line will automatically revert to being the received active line and the request will
change to noRequest.
ReverseRequest: This request is only applicable when the provisioned mode is bidirectional.
DoNotRevert: the protection line is active, and Revertive option is not activated. the
working line has recovered from a signalFail or signalDegrade; or a forcedSwitch or
manualSwitch request has been cleared.
NoRequest: the working line is active and no other requests are in effect.
APS option rules:

ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 76/240
Rule: TEG_SDH_APS-4
It is recommended to set APS in bidirectional mode, on ALU RNC and MGw and SGSN nodes, with
exception of the following cases where APS has to be configured in unidirectional mode:
VPT 2 ports.
ALU UMTS node to an otherVendor Node which doesnt provide APS.
Remark:
Bidirectional APS setting allows identifying with any doubt the working fiber.
Unidirectional APS setting is slightly more robust because it can tolerate a failure on the
working fiber transmit side and failure on the protected fiber receive side.
Parameters:
ATTRIBUTE Aps revertive
When this attribute is yes, the Aps reverts the received active line from protection back to
working when a working line request is cleared, after the provisioned waitToRestorePeriod has
expired.
ATTRIBUTE Aps waitToRestorePeriod (wtrPeriod)
This attribute specifies the time during which the protection line will remain the received
active line after the working line recovers from the fault that caused the switch.
3.3.4.2.3.2
APS TRIGGERS
APS invocation is triggered on two different criteria: SF (SignalFail) or SD (SignalDegrade):

- SF criteria, is based on following indicators/Conditions:
-
LOS (LossOfSignal) condition, it results from reception during at least 100 s, of

SDH frame filed with only 0.
Example: This event occurs on link failure.
LOF (LossOfFrame) condition, it results from reception of 4 consecutive errored
frames.
Example: Bad timing, faulty A1, A2 bytes

Reception of MS-AIS.
Reception of MS-RDI (TBC).
SF BER (BlockErrorRate) threshold is reached.

BER threshold is fixed to 10-3.
BER is calculated on the multiplex section overhead. BER counts discrepancy
between received BIP-24N (Bit Interleaved Parity) B2 byte within the SDH
MultiplexSection overhead, and Even parity code calculated on the received SDH
frame.
SF must be detected within 0.08 seconds.
Example: extremely bad fiber, or attenuation problems.
SD criteria, is based on one indicator:

SD BER (BlockErrorRate) threshold is reached. SD BER threshold is in the range 10-3 to
10-10.
BER is calculated on the multiplex section overhead. BER counts discrepancy between
received BIP-24N (Bit Interleaved Parity) B2 byte within the SDH MultiplexSection
overhead, and Even parity code calculated on the received SDH frame.
See MML Attribute:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 77/240
ATTRIBUTE Aps signalDegradeRatio (sdRatio)

This attribute specifies the minimum (BER) for which a Signal Degrade failure is
declared. Its value is the exponent of the BER, with possible values of -5 through -9
inclusive, which correspond to a BER range of 10e-5 through 10e-9.
The switch initiation time for a Signal Degrade varies depending on the observed BER:
BER - Switch Initiation Time
10e-3 - 10 milliseconds
10e-4 - 100 milliseconds
10e-5 - 1 second
10e-6 - 10 seconds
10e-7 - 100 seconds
10e-8 - 16 minutes 40 seconds
10e-9 - 2 hours 46 minutes 40 seconds
The clearing threshold for a Signal Degrade is one-tenth the signalDegradeRatio; for
example, if the provisioned signalDegradeRatio is -5, the corresponding clearing
threshold will be 10e-6. The clearing time varies depending on the clearing threshold
(not the observed BER), and can be determined from the above table.
Remark:
Since the SD BER is higher (eg: 10-5 10-9), it is necessary to monitor more data to
measure the error ratio, if more data are monitored then measurement period is higher.
Eg:
- BER = 10-5 :
100 000 SDH frames 12,5 seconds
=> 8 000 SDH frames 1 second
- BER = 10-9 :
1 000 000 000 SDH frames 125 000 seconds
=> 80 000 000 SDH frames 2 hours, 46 minutes, 40 sec.
Moreover in case of bidirectional mode, a SDH node is notified by means of K1 and K2 bytes
that APS has been invoked in the remote node, APS is then invoked on the local node.
See MML Attributes for APS monitoring:
ATTRIBUTE Aps nearEndRequest (neReq)
ATTRIBUTE Aps timeUntilRestore
This attribute indicates the amount of time until the received active line is automatically
switched back from the protection line to the working line.
On following figures are represented failure conditions which triggered APS in UMTS node:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 78/240
POH
LOS Condition
No Path OAM signal
MSOH
K1
UMTS
UMTS
0000
K2
0000
0000
0 110
MS-RDI
UMTS
UMTS
ATM
ATM
ATM
ATM
Regenerator
Regenerator
TX
TX
RX
RX
Line 1
TX
TX
RX
RX
Selected Line
TX
TX
RX
RX
W
RX
RX
TX
TX
PTE
PTE
RX
RX
TX
TX
RSTE
RSTE
RX
RX
TX
TX
PTE
PTE
RSTE
RSTE
Selected Line
Line 0
TX
TX
P
RX
RX
RX
RX
TX
TX
RX
RX
TX
TX
TX
TX
RX
RX
TX
TX
RX
RX
RX
RX
MultiPlex Section
TX
TX
APS Invokation
POH
No Path OAM signal
MSOH
K1
1101
K2
0001
0000
0000
SF HP Work
Prot
Idle
Figure 3-25 APS switch on LOS Condition

Remark:
APS is configured on the 16pOC3 FP, if one line is in LOS condition:
- No P-RDI is returned to the farEnd (If P-RDI would be returned the farEnd would discard the
traffic),
- The MS-RDI is returned to the farEnd.
2
POH
No Path OAM signal
MSOH
K1
MSOH
K2
0000 0000
K1
0000
0000
0 110
MS-RDI
K2
0000
0000
0 111
MS-AIS
UMTS
UMTS
UMTS
UMTS
LOS Condition
AIS
ATM
ATM
ATM
ATM
Regenerator
TX
TX
RX
RX
TX
TX
Regenerator
Line 1
RX
RX
Selected Line
TX
TX
RX
RX
W
RX
RX
TX
TX
PTE
PTE
RX
RX
TX
TX
RSTE
RSTE
RX
RX
TX
TX
PTE
PTE
RSTE
RSTE
Selected Line
Line 0
TX
TX
P
RX
RX
RX
RX
TX
TX
RX
RX
TX
TX
TX
TX
RX
RX
TX
TX
RX
RX
MultiPlex Section
RX
RX
TX
TX
APS Invokation
2
MSOH
K1
1101
K2
0001
0000
0000
SF HP Work
Figure 3-26 APS switch on MS-AIS reception
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 79/240
Remark:
ATM switches and UMTS Nodes take appropriate action on reception of Transmission OAM signals, or
under Transmission defect conditions:
- APS invocation,
- F4, F5 OAM message generation.
3.3.5
ATM INTERFACE TYPE

ATM implemented on RNC is compliant with [R52].
Two types of ATM interfaces are specified: UNI and NNI. On the UNI interface, the vpi field is 8 bits
length, whereas on NNI interface the vpi field is 12 bits length.
On the Iub interface, the nodeB and the RNC are configured with atm Interface type UNI according to
3Gpp.
3.3.6
ATM CAC
The atm CAC (connection AdmissionControl) is an algorithm invoked at AtmConnection setup:
- In provisioning phase for the pvc,
- In establishment phase for a svc.
The atm CAC verifies that the bandwidth required for the new atmConnection is below than bandwidth
available on the physical link.
Per atmConnection, based on the trafficDescriptor values, the atm CAC calculates the ECR
(EquivalentCellRate). The atm CAC considers the ECR value as the bandwidth required for an
atmConnection.
Two atm CAC algorithms are implemented in the RNC: ACAC (Actual CAC) and GCAC (Generic
CAC).
- ACAC (Actual CAC):
The ACAC is a proprietary CAC algorithm. It is a hop-by-hop reservation scheme performed on the
egress and ingress directions regardless of the connection type: pvc, pvp, svc, svp, sPvc and sPvp.
For each atmConnection and per direction, an ECR is calculated according to the ACAC algorithm.
For calculating the ECR, the ACAC takes into consideration:
- trafficDescriptor parameters: pcr, cdvt, scr and mbs,
- ServiceCategory (SC),
- CellLossRate (CLR).
- Buffer size,
- LinkRate,
The ACAC checks that the sum of ECR for all the atmConnections configured over a link is lower
than link available bandwidth. If not, then some atmConnections are rejected.
-
GCAC (Generic CAC):

The GCAC algorithm is used by pnni and the Transport admissionControl (previously called aal2
link CAC), (3.2.1).
The GCAC algorithm is invoked in the Pnni sPvc originating node when setting up the sPvc
connections.
The GCAC is based on simplified formula: ECRGCAC = 2 * PCR * SCR / (PCR + SCR).
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 80/240
3.3.7
OVERSUBSCRIPTION
The atm oversubscription is configured through the bandwidth pool component.
The port bandwidth is allocated to one bandwidth pool component or distributed over several bandwidth
pool components. One to five bandwidth pools are available per port.
Each bandwidth pool is linked to one or several atm serviceCategories.
Rule: IubTEG_atm-RNC_OvS_01
It is recommended to assign all the port bandwidth to one single bandwidth pool component and link
this bandwidth pool component to all the service categories.
Passport
E1/T1
BwPoll-1
100%
All SC
Figure 3-27 OverSubscription
An oversubscription factor is configured against each bandwidth pool:

- oversubscription factor = 100%: no oversubscription.
- oversubscription factor > 100%: oversubscription.
The RNC permits over-subscription for each bandwidth pool at 64 times the port capacity.
The port oversubscription is taken into consideration by the ACAC (3.3.6).
The Overbooking factor value results from a statistical study of the umts traffic.
3.3.8
ATM OAM
Reference: [R49].
The Transport OAM Signal objective is to detect and isolate equipment failure within the Transport path.
Transport OAM information is handle at Transmission level, and at atm level.
The atm OAM Information is bidirectional; it is carried once the atmConnection is established.
The atm OAM PDU are directly encapsulated within and atm cell payload, without aal (atm
AdaptationLayer).
3.3.8.1 ATM NODE, OAM TYPE

Within an atm network, are considered from an OAM point of view, different types of node:
- Vpc/vcc endPoint node: atm node where atm-user SDU are inserted in atm cell payload.
- Vpc/vcc connectionPoint node: atm node where only atm Connection switching occurs, no
atm-user SDU insertion.
- Vpc/vcc segmentPoint node: atm node which initiates and terminates Segment OAM
flows.
The node oam type is defined by means of configuration:
- EndToEnd F4 OAM vcc is automatically created when vpt is configured or vpc NEP,
- EndToEnd F5 OAM trafficFlow is automatically created when vcc is configured.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 81/240
Segment end point may be provisioned by means of following MML:

ATTRIBUTE AtmIf oamSegmentBoundary (sb)
ATTRIBUTE AtmIf Vpc Nrp oamSegmentBoundary (sb)
ATTRIBUTE AtmIf Vcc Nrp oamSegmentBoundary (sb)
Atm Connection OAM function type may be displayed by means of following MML:
ATTRIBUTE AtmIf Vpc connectionPointType (cpt)
ATTRIBUTE AtmIf Vcc connectionPointType (cpt)
ATTRIBUTE AtmIf Vpt connectionPointType (cpt)
ATTRIBUTE AtmIf Vpt Vcc connectionPointType (cpt)
This attribute reflects the role of the connection component at this interface.
- Cpt = connectionEndPoint indicates that user cells, endToEnd OAM cells, and segment
OAM cells are processed by the connection component.
- Cpt = segmentEndPoint indicates that user cells and endToEnd OAM cells are relayed by
the connection component, while segment OAM cells are processed by the connection
component.
- Cpt = connectingPoint indicates that user cells, end-to-end OAM cells, and segment OAM
cells are relayed by the connection component.
- Cpt = unknown indicates that the connection component is inactive.
3.3.8.2 ATM OAM FLOWS

The atm OAM flows are called either F4 or F5 OAM flows according they are related to vp or vc
Connection.
For both the F4 and F5 atm OAM flows may be specified an EndToEnd OAM flow and a Segment
oriented OAM flow:
- EndToEnd OAM flow:
The endToEnd OAM flow is transmitted between two adjacent ATM connection EndPoint
nodes. An atm Connection endpoint node is the node where the atm-User PDU is
encapsulated within the atm cell payload.
- Segment OAM flow:
The segment OAM flow is transmitted between two nodes at extremity of an OAM
boundary. OAM boundaries are configured (see [R49]).
NodeB
NodeB OAM Boundary
VCC
RNC
RNC
ATM
ATM
switch
switch
ATM
ATM
switch
switch
VCC / VPC
Segment OAM flow

EndToEnd OAM flow
Parameters:
ATTRIBUTE AtmIf oamSegmentBoundary (sb)
ATTRIBUTE AtmIf Vpc Nrp oamSegmentBoundary (sb)
These attributes specify whether the interface/AtmConnection is on an OAM segment boundary.
The atm OAM Information objective is Fault detection, Fault Location and Performance monitoring:
- Fault Management:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 82/240
- Alarm surveillance:
- AIS (AlarmIndicationSignal), F5 : VC-AIS or F4 : VP-AIS,
- RDI (RemoteDefectIndication), F5: VC-RDI, F4: VP-RDI,
- Connectivity verification:
- LoopBack,
- ContinuityCheck, Not supported by the 16pOC3/Stm1 FP.
Performance Management:
Not supported by the 16pOC3/Stm1 FP. Not covered in this document
The endToEnd and Segment F4 OAM flows are carried in dedicated vcc:
- Vpi: any allowed VPI values,
- Vci=3, for segment OAM flow,
- Vci=4, for endToEnd OAM flow,
The endToEnd and Segment F5 OAM flows are not carried in dedicated vcc, but transmitted together
with atm-user traffic in vcc.
Within a vcc, the OAM traffic is distinguished from user traffic by means of payloadType field (atm
header PT field):
- PTI = 100 for Segment F5 OAM traffic,
- PTI = 101 for endToEnd F5 OAM traffic,
- PTI = 000 for ATM-User traffic,
The F4/F5 OAM traffic is carried within atm cells, coded as following:
Cell Header
OAM Type
Function
Type
Function Specific Field
Reserved
CRC-10
5 bytes
4 bits
4 bits
45 bytes
6 bits
10 bits
Figure 3-28 ATM OAM Cell Format
The table below indicates the OAM Cell Field values used within the umts networks:
OAM Type
0001
Function Type
Fault Management
0000
AIS
0001
RDI
0100
ContinuityCheck
1000
LoopBack
When LoopBack is activated, loopBack information is inserted in the OAM Cell Function specific field:
LoopBack Correlation
LoopBack indication ID
indication
Tag
1 bytes
4 bytes
16 bytes
Source ID
Unused
16 bytes
8 bytes
Where:
-
LoopBack indication: The source loopBack point fills this field with value: 0000 0001.
The destination loopBack point returns the value: 0000 0000.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 83/240
Correlation Tag: Identifier of the loopBack invocation checked in loopBack source point
on reception of loopBack answer.
LoopBack Location ID: Identification of the node where loopback has to occur.
Source ID: Coded as an option, identification of the loopBack source point.
3.3.8.3 ATM OAM SIGNALS

AIS:
The AIS (AlarmIndicationSignal) notifies the downstream endPoint node about a failure that
has occurred between endPoint nodes.
The AIS is sent downstream to all affected active atmConnections from the atmConnection
connection point (atm cross connect or switch), which detects the atmConnection failure.
F4/F5 AIS OAM Cells triggers:
- SDH/PDH condition indicating physical link failure E.g. LOS.
- Reception of SDH MS-AIS, PDH AIS,
- Loss of Continuity at ATM layer detected by LoopBack or ContinuityCheck
when activated.
- LCD,
- IMA LinkGroup failure, when RNC IMA releases vcc, ATM layer generates AIS
OAM notification in both directions. RNC vcc NEP notifies application of vcc
failure, and application takes appropriate action.
- Moreover VC-AIS may be triggered by VP-AIS.
The AIS is sent at a frequency of 1 cell/s usually. AIS cells generation stops since failure
detection is removed.
The AIS generation feature is systematically activated when configuring a static
AtmConnection.
The AIS generation becomes an option when configuring dynamic AtmConnection PNNI
sPVC. This option is available at the source and destination of the PNNI sPVC through
attributes:
Atmif Vcc Dst aisGeneration,
Atmif Vcc Src aisGeneration.
Rule: IubTEG_atm-RNC_OAM-1
It is highly recommended to activate aisGeneration attribute on source and destination of
sPvc dedicated to UserPlane and OAM traffic.
It is not recommended to activate aisGeneration attribute on source and destination of
sPvc dedicated to Iub CP and CCP traffic, since RNC-CN doesnt manage AIS signal.
The reason for activating aisGeneration attribute on source and destination of sPVCs dedicated
to UserPlane and OAM traffic, is that if a VCC part of an IMA group goes down, IuxIf/Path
associated to this VCC is informed about VCC failure and then doesnt allow calls on this Path.
When activating aisGeneration on source and Destination of a sPVC, failure of the sPVC, is a
trigger for aisGeneration on Permanent AtmConnections, the sPVC is switched on at the
source and destination:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 84/240
PVC
F5 AIS
PNNI sPVC
ATM
Switch
PNNI sPVC
PNNI
AtmIf
AtmIf
AtmIf
AtmIf
sPVC CdPyNb,
AisGeneration
activated
PVC
ATM
Switch
F5 AIS
sPVC CgPyNb,
AisGeneration
activated
Upon receiving an F4/F5 AIS OAM cell, VPC/VCC endPoint node returns a F4/F5 RDI to
alert upstream intermediate and endPoint nodes that a failure has been detected downstream.
RDI:
The RDI is used to return an indication to the upstream vp/vc endPoint node that the received
end has detected an incoming section defect or is receiving AIS.
The RDI is an upstream signal, whereas the AIS is a downstream signal.
The F4/F5 endToEnd RDI is generated by a vp/vc endPoint node, whereas the F4/F5 Segment
RDI is generated by the segment endPoint node or a vp/vc endPoint node.
The F4/F5 RDI signal is sent with a periodicity of 1 second as long as the defect persists.
After 3 second without reception of a F4/F5 RDI, the atm connection is brought back into
service.
F4/F5 RDI OAM Cells triggers:
- SDH/PDH condition indicating physical link failure E.g. LOS in Segment
boundary node or VPC/VCC EndPoint node.
- Reception of SDH MS-AIS, PDH AIS in a Segment boundary node or VPC/VCC
EndPoint node.
- Reception of F4/F5 AIS EndToEnd in a VPC/VCC EndPoint node,
- Reception of F4/F5 AIS Segment in a Segment boundary node,
RDI frequency generation is usually 1 cell/s. RDI generation stops when failure detection is
removed.
Remark:
AIS generation attribute available when configuring dynamic AtmConnection PNNI sPVC,
allows activating/deactivating both AIS and RDI signals.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 85/240
LOS Condition
UMTS
UMTS
UMTS
UMTS
ATM
ATM
ATM
ATM
ATM
ATM
F4/F5-AIS
P-AIS
TX
TX
RX
RX
PTE
PTE
TX
TX
RX
RX
MSTE
MSTE
RX
RX
TX
TX
TX
TX
RX
RX
PTE
PTE
RX
RX
TX
TX
PTE
PTE
RX
RX
TX
TX
MS-RDI
Ete F4/F5-RDI
Ete F4/F5-RDI
VPC/VCC
EndPoint node
Ete F4/F5-RDI
VPC/VCC
ConnectionPoint node
VPC/VCC
EndPoint node
Figure 3-29 F4/F5 RDI generation on Reception of F4/F5 AIS
LOS Condition
UMTS
UMTS
UMTS
UMTS
ATM
ATM
ATM
ATM
ATM
ATM
MS-AIS
TX
TX
RX
RX
PTE
PTE
RX
RX
PTE
PTE
RX
RX
TX
TX
Ete F4/F5-RDI
VPC/VCC
EndPoint node
TX
TX
TX
TX
RX
RX
RSTE
RSTE
RX
RX
TX
TX
Ete F4/F5-RDI
PTE
PTE
RX
RX
TX
TX
Ete F4/F5-RDI
VPC/VCC
VPC/VCC
EndPoint node
Figure 3-30 F4/F5 RDI generation on Reception of MS-AIS
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 86/240
LOS Condition
UMTS
UMTS
UMTS
UMTS
ATM
ATM
ATM
ATM
TX
TX
RX
RX
PTE
PTE
ATM
ATM
TX
TX
RX
RX
PTE
PTE
RX
RX
TX
TX
TX
TX
RX
RX
RSTE
RSTE
RX
RX
TX
TX
PTE
PTE
RX
RX
TX
TX
Path-RDI
Ete F4/F5-RDI
VPC/VCC
EndPoint node
Ete F4/F5-RDI
VPC/VCC
VPC/VCC
EndPoint node
Figure 3-31 RDI generation on LOS Condition
LoopBack:
This feature consists in inserting a pattern in an atmConnection and indicates to the remote
node that this pattern has to be returned.
The loopback initiator node checks that the received pattern is the expected one and decides to
keep the atmConnection active or to disable it.
The purpose of loopBack is to:
- Prevent from mis-configuration of vpc/vcc translation in a connectionPoint node
and verify the atmConnection continuity.
Therefore atm LoopBacks should be enabled during I&C and disabled once I&C operations are
terminated.
-
Detect failure within an atm Network where nodes dont handle atm OAM
signals: AIS, RDI.
- LoopBack configuration options:

The LoopBack signal is configured either at vc level (F5 OAM) or at vp level (F4 OAM).
The LoopBack is configured either on a predefined OAM segment, or between vpc/vcc
endpoints. The loopBack is then named either Segment OAM loopBack or endToEnd
LoopBack.
The endPoint or connectionPoint inserts a bit pattern 0000 0001 in one OAM flow (F4/F5,
Segment/endToEnd), and expects within a timeout, the bit pattern 0000 0000 returned by the
destinated node.
Such an operation is performed without having to take the ATM Connection out of service.
- LoopBack mechanism:
The loopback pattern is inserted every 30 seconds by the connection end-points,
A loopback is considered successful when the loopback pattern is returned by the
remote end-point within 5 seconds,
It takes 15 to 45 seconds to detect a connection failure (3 consecutive loopback
failures),
After a failure is detected, loopback cells are inserted every second.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 87/240
- RNC LoopBack limitations:

16OC3/STM1 FP:
ATM LoopBack may be activated on a limited number of atmConnections. Assume
that up to 50 loopBacks may be activated per 16pOC3/STM1 FP.
- LoopBack recommendations:
The amount of Iub vcc may be very large then instead of activating systematically loopBack; it
is preferable to ascertain that F4/F5 OAM AIS/RDI Signals are activated within each node of
the atm Backbone.
If F4/F5 OAM AIS/RDI Signals are not available in otherVendor nodes, then for security
reason, we can decide to activate loopBack on some RNC Iub atmConnections.
On Iub interface, ascertains that F4/F5 OAM AIS/RDI Signals are activated in each
node of the ATM backbone.
If F4/F5 OAM AIS/RDI Signals is not available on otherVendor nodes within the
ATM backbone, then loopBack must be activated on some RNC Iub
atmConnections.
On 16pOC3/STM1 FP, up to 50 loopBacks may be activated simultaneously.
Remark:
When activating loopBack in the RNC, it is assumed that intermediate equipments are
transparent for this signal and the far end support loopBack (ALU NodeB and
coreNetwork nodes support loopBack).
Moreover without LocationID value inserted in the loopBack signal, it is not
guaranteed that the far end node which answers is the expected one.
LoopBack parameters:
ATTRIBUTE AtmIf endToEndLoopback (eeLbk)
ATTRIBUTE AtmIf segLinkSideLoopback (segLkLbk)
ATTRIBUTE AtmIf Vpc Vpd endToEndLoopback (eeLbk)
ATTRIBUTE AtmIf Vpc Vpd segLinkSideLoopback (segLkLbk)
ATTRIBUTE AtmIf Vcc Vcd endToEndLoopback (eeLbk)
ATTRIBUTE AtmIf Vcc Vcd segLinkSideLoopback (segLkLbk)
ContinuityCheck:
Continuity check mechanism consists in sending periodically cell, from endPoint node, at some
predetermined interval (every second) so that connectingPoints and the remote endPoint can
distinguish between a connection that is idle and one that has failed.
The continuity check can detect failure that AIS cannot, such as an erroneous VP cross-connect
change (VPI translated to incorrect value).
The ContinuityCheck is not supported by the 16pOC3/Stm1 FP.
3.3.8.4 SOC
16pOC3/STM1 FP:
Partly compliant withI.610:
- Supported:
Fault management:
- Alarm Indication Signal (AIS), Remote Defect Indication (RDI),
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 88/240
- LoopBack.
Not Supported:
- PerformanceManagement,
- FaultManagement: ContinuityCheck.
3.3.9
VPC, VPT
The AtmForum defines the notion of a VP endPoint. A VP endPoint is the node which is responsible for
the grouping of several vcc within a vpc. This function is implemented in the RNC through the VPT
component (VirtualPathTermination).
The reason of grouping several Vcc within one VPC, by means of VPT, is to apply a common treatment
to the set of Vcc, e.g.: TrafficManagement, OAM.
3.3.9.1 VPC
The target of this section is to summarize contexts where VPCs are required.
NodeB E1/T1s can be connected directly to ASP network or connected to a POC before reaching the
ASP.
- When the NodeB is connected directly to the ASP network, without POC, in a multiPCM
configuration, it is recommended to use one VPC for each E1/T1 link that connects NodeB to
the ASP. The ASP provides the E1/T1 access port as well as the VPC across the network.
There are per nodeB as many VPC configured in the ASP as amount of E1/T1 per nodeB.
However, the OAM VCC must still be configured separately; explanation is given in
trafficShaping section.
1 E1/T1
VC UP DS
NodeB
x
VC UP NDS
VC CP
VC CCP
VP x , rtVBR
VC OAM
VC OAM
VP y, rtVBR
VC OAM
VC OAM
VC UP DS
NodeB
z
VP x1
VP y1
VP z1
VCC OAM x
VCC OAM y
VCC OAM z
1 E1/T1
VC UP NDS
VC CP
VC CCP
VP z , rtVBR
VC OAM
VC OAM
16pOC3/STM1 FP
NodeB
1 E1/T1
VC UP NDS
VC CP
VC CCP
ATM Backbone
VC UP DS
RNC-SDH
RNC-SDH
Figure 3-32 VPC setting when NodeB connected directly to ASP

When NodeB, IMA configuration, is connected directly to ASP network, without POC, it is
recommended to use one VPC per IMA linkGroup that connects NodeB to ASP. There are per
nodeB as many VPC configured in the ASP as amount of IMA linkGroups per nodeB.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 89/240
When connecting NodeBs to ASP through remote concentrators (POCs), it is recommended to

set one VPC per POC, to take advantage of statistical multiplexing, to allow bandwidth sharing
between user plane Vcc. POCs multiplex all VCC (UP and CP) arriving from NodeBs, with
exception of OAM VCC, on one or more Vpc. The OAM Vcc should still be configured
explicitly; explanation is given in trafficShaping section.
Figure 3-33 VPC setting when NodeB connected to ASP through POC
Rule: IubTEG_atm-RNC_VP-01
- If ASP and POC inserted on Iub interface, on RNC side set one VP per POC.
- If NodeB MultiPCM configuration connected to ASP without POC, on RNC side set one
VP per NodeB E1/T1 link.
- If NodeB IMA configuration connected to ASP without POC, on RNC side set one VP
per NodeB IMA linkGroup.
Remark:
If VPI of all nodeB Vcc is set to 0, the ATM network cannot treat this as VPC. VPI 0 is reserved for VCC
connections, as defined by ITU-T and ATM Forum.
VPC ServiceCategory:
It is recommended to configure Iub VPC with rtVBR serviceCategory.
Setting VP serviceCategory with rtVBR instead of CBR provides the VP ATM connection
with a longer bufferSize e.g.: Passport CBR default bufferSize is 96 cells, whereas rtVBR
default bufferSize is 480 cells.
Within ASP, CBR serviceCategory might be reserved for traffic more vulnerable to delay:
GSM, ATM CES
VPC ServiceCategory is set to rtVBR
VP TrafficDescriptor parameter:
Setting of VPC TrafficDescriptor Throughput parameters (PCR, SCR), depends on Iub
configuration:
- Case of NodeBs connected directly to ASP:
A VPC initiated in the ASP and terminated in the RNC, if no bandwidth constraint
between ASP and RNC, then
o VPC PCR could be set at NodeB(s)*E1_bandwidth, and
o SCR of PVP could be set at NodeB(s)*E1_bandwidth*E1_UsageRate.
With UsageRate = 80%
Remark:
If on RNC, trafficShaping at VP level is activated, only PCR is taken into account since
16pOC3 FP provides singleRate shaping (linearShaping).
-
Case of NodeBs connected to a POC:

A VPC initiated in the POC and terminated in the RNC, if no bandwidth constraint
between POC and RNC, then VPC PCR and SCR may be defined by cumulative traffic
from NodeBs.
o VPC PCR could be set at #NodeB(s)*E1_bandwidth, and
o VPC SCR could be set at #NodeB(s)*E1_bandwidth*E1_UsageRate.
With UsageRate = 80%
Remark:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 90/240
If on RNC, trafficShaping at VP level is activated, only PCR is taken into account since
16pOC3 FP provides singleRate shaping (linearShaping).
-
Case of private ATM backbone inserted between nodeBs and RNC:

The ATM backbone provides transmission bandwidth to RNC, lower than sum of nodeB
bandwidth, then within ATM backbone:
The VPC PCR is set with ATM Backbone available link bandwidth. In the example below,
VPC PCR may be set with E1 bandwidth on RNC side and ATM switch side
E1/T1
NodeB
NodeB
E1/T1
NodeB
ATM Switch
E1/T1
ATM Switch
E1/T1
STM1/OC3
RNC
TrafficRegulation mechanisms:
When an ASP is included on the Iub interface and provides policed access, it is recommended
to group the Vcc into a single Vp and to invoke TrafficShaping at VP level either on POC and
RNC side.
When an ASP is included on the Iub interface and provides policed access, it is recommended
to activate the TrafficShaping at Vp level, on the RNC side or on the POC side (if present).
Moreover when activating trafficShaping at VP level on one port of the 16pOC3/Stm1 FP, the size of the
assigned perVc queue need to be configured with an appropriate value see Erreur ! Source du renvoi
introuvable..
3.3.9.2 VPT
Within Passport two kinds of VPTs are available:
- basicVPT and
- StandardVPT.
BasicVPT is available on APC based card, e.g.: 16pOC3 FP and AQM based cards, e.g.: 4pOC3 FP,
whereas StandardVPT is available only on AQM based cards.
When configuring basicVPT on a port, activation of trafficShaping is not allowed. For activating
trafficShaping at VP level, a second port and a hairpin is required; VPT is configured on one port, traffic
is diverted to a second port where trafficShaping is activated. It is called the two port solution.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 91/240
BackPlane
Rx
APC
C la s s
S c h e d u le r:
EP & M BG
C o n n e c t i o n S c h e d u le r :
W FQ O r SFQ
T r a n s m it
P e rV C & c o m m o n Q u e u e s
EP0
P er V C Q u e u e s :
VCC 1 Q ueue
W e ig h t 1
Port1
VCC 2 Q ueue
W e ig h t 2
L in k C la s s
Q ueue
fo r E P 0
V P C Q u eu e
W e ig h t 3
Tx
VPT
Co m m on Q ueues:
E P 1 to E P 7 Q u e u e s
Per VC Q ueues :
VCC 71 Q ueue
W e ig h t 1
L in k C la s s
Q ueue
fo r E P 7
VCC 72 Q ueue
W e ig h t 1
EmissionPriority/MostUrgent
E P 0 Q u eu es
C om m o n Q ueues:
EP2
CBR
EP3
rtVBR
EP4 nrtVBR
EP7
UBR
VCC 73 Q ueue
W e ig h t 1
Rx
APC
C la s s
S c h e d u le r :
EP & M BG
C o n n e c tio n S c h e d u le r :
W FQ O r SFQ
T ra n s m it
P erV C & co m m o n Q u e u e s
CBR
E P 0 Q ueues
Port2
Per VC Q ueues :
VCC 1
Q ueue
W e ig h t 1
VCC 2
Q ueue
W e ig h t 2
L i n k C la s s
Q ueue
fo r E P 0
VPC
Tx
C o m m o n Q u eu es:
Q ueue
W e ig h t 3
E P 1 to E P 7 Q u e u e s
Per V C Q ueues :
VCC 71 Q ueue
W e ig h t 1
L i n k C la s s
Q ueue
fo r E P 7
VCC 72 Q ueue
W e ig h t 1
C om m o n Q u eu es:
rtVBR
nrtVBR
EP0
EP2
EP3
EP4
EP7
VCC 73 Q ueue
W e ig h t 1
Figure 3-34 APC, two ports solution
Remark:
On APC based card, TrafficShaping is allowed only on AtmConnection configured with a
serviceCategory mapped to emissionPriority 0.
On AQM based card, a one port solution allows to activate trafficShaping at VP level.
Configuration of a basicVPT consists in:
Identifying the VPC by means of a VPi, VPi range [0, 4095],
Grouping Vcc within the VPC,
Configuring kind of OAM loopBack, segment or endToEnd.
If trafficShaping is required, it is activated on a second port.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 92/240
AtmIf n1
VPT vpi
VPd
- SegmentLoopBack on, off, sameAsInterface
- EndToEndLoopBack on, off, sameAsInterface
AtmIf n2
VPC vpi
VPd
TM
TrafficShaping disabled, sameAsCa
Configuration of a standardVPT consists in:
Identifying the VPC by means of a VPi, VPi range [0, 4095],
Grouping Vcc within the VPC,
Configuring kind of OAM loopBack, segment or endToEnd.
Activation of the trafficShaping,
AtmIf n1
VPT vpi
VPd
- SegmentLoopBack on, off, sameAsInterface
- EndToEndLoopBack on, off, sameAsInterface
TM
- TrafficShaping disabled, sameAsCa
- ServiceCategory,
- Tx TrafficDescriptor Type & Parameters,
- Rx TrafficDescriptor Type & Parameters,
3.3.10 TRAFFIC MANAGEMENT

At ATM level, bandwidth per ATM Connection is managed by means of TrafficDescriptor parameters.
TrafficDescriptor parameters may be involved in traffic regulation, when its activated.
Regulation of traffic on Egress side is achieved by trafficShaping whereas regulation of traffic on
Ingress side is achieved by means of Policing.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 93/240
3.3.10.1
TRAFFICDESCRIPTOR PARAMETER PRESENTATION
Pictures below indicate relationship between PCR, SCR and MBS.

Let us called , the ATM Cells transmission duration. depends on the physical link throughput:
- = 220 s for an E1,
= 2,83 s for an STM1,
For a VBR service category, traffic is considered bursty, and then cells are sent within a burst, bursts are
sent periodically.
Such traffic is described at ATM level by means of 2 throughput parameters: PCR and SCR and size of
the burst MBS:
Context:
TrafficSource: continuous
DualRateShaping:
PCR = linkRate
CDVT = 0
SCR = 1/8 LR
MBS = 3
=> BT = 2*(Ts-T)
ATM-User traffic: Traffic is continuous
1 23456
Shaped traffic
TAT
TAT
Period2
Period3
Period4
Period5
Period6
T= 1/PCR
Ts= 1/SCR
BT
Ts= 1/SCR
BT
Ts= 1/SCR
BT
Ts= 1/SCR
BT
Figure 3-35 PCR, SCR, MBS representation
TAT stands for theorical arrival time, one TAT being defined for each throughput PCR and SCR, they
determine date at which cell is candidate for transmission.
When the ATM-User provides a continuous flow of traffic, it is observed that MBS cells are sent at
PCR while the following cells are sent at SCR.
.
3.3.10.2
TRAFFICDESCRIPTOR SETTING
On IUB interface ATM bearers carry RAB UMTS bearers, therefore ATM VCC trafficDescriptor
parameters have to be set according to RAB definition.
RAB and associated parameters are defined in [R62]:
Per RAB, 3Gpp recommendation indicates amount of blocks of information transmitted per
period of time. The period is called a TTI. Blocks and TTI refer to RLC/MAC layers.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 94/240
On Iub interface, RLC/MAC information is encapsulated in DCHFP for TRB and SRB
dedicated, and then in AAL2 frames.
DCHFP and AAL2 overheads are indicated in [R225]
RRC
PDCP
RRC
PDCP
RLC
RLC
MAC
MAC
Physical
Physical
AAL2
ATM
Physical
UE
NodeB
Uu
Iub
RNC
RAB definition is used to set ATM trafficDescriptor. A direct relation may be

established between RAB parameters and ATM trafficDescriptor parameters.
In explanation below, considers that a RAB block fills totally an ATM Cell payload.
This is an approximation in case of speech call (# 92%).
Below example of RAB 64 kb/s:
- 4 blocks of information may be sent each TTI = 20 ms,
Context:
MBS = 4
Tm = 20 ms
=> SCR = MBS/ Tm = 200 c/s
=> Ts = 5 ms
PCR = 2 * SCR
=> T = 2,5 ms
Example: RAB 64
E1:
STM1:
= 2 20 s
= 2 ,8 s
R A B 6 4 , B lo c k s
1 2 3 4
1 2 3 4
t
T T I = 20 m s
ATM
TD
TA T
T AT
P e riod 2
P eriod 3
P erio d4
T = 1 /P C R
T s = 1/ SC R
BT
T s = 1 /S C R
BT
T s = 1 /S C R
BT
T s = 1/ S C R
BT
Tm = M B S / SC R
T T I = 20 m s
therefore since one block filled an ATM cell, MBS is set equal to 4, and Tm = 20 ms = MBS/SCR:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 95/240
Figure 3-36 RAB / TrafficDescriptor relationship
This example may be generalized to both userPlane Vcc:

DelaySensitive UP VCC:
DS UP VCC carries traffic:
- TRB for UMTS serviceClass: Conversational,
- DedicatedSRB relative to all TRB (DS and NDS),
- CommonSRB.
TRB for UMTS ServiceClass: Conversational and Streaming are handled by means of
following RABs, the most restricting RAB transportFormat is shown in this table, see
[R62] for a complete RAB definition, moreover is considered that a RAB block fills totally
an ATM Cell payload:
RAB
Direction
Speech /
12,2 kb/s 12,2 kb/s
DL
CS Data /
14,4 kb/s 14,4 kb/s
DL
CSD 57, 6
DL
UL
UL
TTI
BlockSize
#MaxBlocks
/TTI
Consecutive
ATM cells
Ms
Bits
Bytes
For highest TF
20
244
31
20
244
31
40
576
72
40
576
72
40
576
72
UL
40
576
72
4
Table 3-20 List of RAB for DelaySensitive traffic
Non DelaySensitive UP VCC:

On nonDelaySensitive UP VCC is carried user traffic for UMTS ServiceClass:
Interactive and Background. Following RABs handle this traffic, the most restricting
RAB transportFormat is shown in this table, see [R62] for complete RAB definition,
moreover is considered that a RAB block fills totally an ATM Cell payload:
UMTS
ServiceClass
RAB
Direction
TTI
I
n
t
e
r
Ms
64kb/s / 64 kb/s
DL
20
BlockSize
Bits
336
Bytes
42
#MaxBlocks
/TTI
Consecutive
ATM cells
For highest TF
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 96/240
UL
64kb/s / 128 kb/s
DL
UL
64kb/s / 384 kb/s
DL
UL
20
336
42
20
336
42
20
336
42
10
336
42
12
12
20
336
42
Table 3-21 List of RAB for nonDelaySensitive traffic
RAB definition provides then, amount of consecutiveCellsForSingleCall sent each TTI. This value can
be considered as the MBS for a single call.
Moreover to establish MBS value, maximum amount of simultaneous calls handled by a node has to be
taken into account.
According to the chosen methodology, either simultaneous call is considered as an input for setting
MBS value, or amount of simultaneous calls is calculated based on a customer trafficModel, by means
of a dimensioning exercise.
Remark:
Determination of ControlPlane VCC trafficDescriptor is the result of a dimensioning
study.
Remark:
In RNC, only Egress trafficDescriptor is provisioned per VCC or per VPC, Ingress
trafficDescriptor is set with same as Egress. On this way provisioned
TrafficDescriptor applies for both directions.
3.3.10.3
TRAFFICSHAPING
The trafficShaping regulates the egress traffic according to trafficDescriptor parameter values.
The RNC 16 ports OC3/STM1 FP supports the linear shaping on EP0 at vc and vp level.
The linear shaper regulates egress traffic according to PCR
There is no recommendation for activating the trafficShaping at vc level within the RNC. Beside the
trafficShaping at vp level may be required on RNC side, when policing activated at vp level within the
atm backbone.
The activation of the trafficShaping at vp level within the RNC requires configuration of 2 ports, one for
the vpt the second for the vpc where the trafficShaping applies (see 3.3.9)
Rule: IubTEG_ATM-TM_1
Without specific operator requirement, it is not recommended to activate
TrafficShaping or Policing function, in order to avoid cell delay and cell discard.
Rule: IubTEG_ATM-TM_2
When a policed ATM backbone is inserted on the UMTS interface, It is recommended
to activate TrafficShaping at VP level.
According to the Iub topology, the VPC results either from the grouping of all Vcc
from a NodeB with exception of the OAM VCC, or from the grouping from all Vcc
from nodeBs behind the POC, with exception of NodeB OAM Vcc.
Reason why Isolating NodeB OAM VCC from a NodeB or POC VPC:
When activating TrafficShaping at VP level on RNC, two 16pOC FP ports are involved.
On the first port NodeB Vcc dedicated Queues are scheduled, resulting in a common queue, VPT is
configured. The common queue feeds the loop at OC3/STM1 linkRate.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 97/240
On the second port, the VPC dedicated queue is fed at STM1/OC3 linkRate. The VPC queue is
scheduled at ShapingRate.
The VPC Queue ingress throughput is higher than the egress throughput.
Therefore a high volume of OAM cells may be inserted between delay sensitive cells in the second port
VPC queue, which generates delay on delay sensitive cells.
3.3.11 PNNI
The PNNI recommendations encompass network Topology and Protocols notions.
Reason for PNNI, on atm interfaces, is to simplify the network configuration and to improve the network
reliability and availability.
The PNNI allows shorter outage times, and transparent recovery from network outage, by means of
dynamic rerouting mechanisms.
Therefore, a better GOS behavior is expected when configuring PNNI.
3.3.11.1
PNNI TOPOLOGY:
The PNNI network may be configured either as a flat network or hierarchical network.
In a flat network topology, the routing information are flooded within the complete network as a
consequence the routing table is identical in all the atm nodes within the network.
Applying hierarchy in a PNNI network consists in grouping the nodes in different sub networks called
peerGroup, e.g.: all Iub ATM switches behind a RNC may be grouped into one peer group, ATM
switches connected to another RNC may be grouped in another peerGroup.
ATM addressing plane has to reflect the topology choice.
In the example above, all nodes belonging to the same peerGroup have the same prefix level88 (88 bits),
whereas prefix level 104 distinguishes nodes within a peerGroup (16 bits).
3.3.11.2
-
PNNI PROTOCOLS:
PNNI RoutingProtocol: Distribution of Topology information within the network. Thanks to this
protocol, node routing tables are updated with information related to reachability, QOS, resource
availability
Topology information are exchanged between each node of the network by means of Hello protocol
messages. These messages are carried in the RCC (RoutingControlChannel) VCC=0/18.
PNNI Signaling Protocol: allows establishment of ATM connections. This protocol is based on BISDN [R47 & 90] with some additional functionalities: sourceRouting, crankBack
PNNI Signaling Protocol messages are carried in the SignalingChannel VCC=0/5.
PNNI SignallingProtocol PNNI RoutingProtocol
SSCF-UNI Q2130
SSCOP Q2110
SAAL UNI
CPCS (AAL5 used)

AAL5
ATM
Physique
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 98/240
3.3.11.3
PNNI CHANNELS:
The sPvc is one kind of atm connection established by means of the PNNI signalingProtocol.
The sPvc is configured only in the node where the connection originates.
When configuring a sPvc, the following information is specified:
- AESA of the ATM port in the destination node,
- Called VCC.
CallingParty Node:
Calling vcc: 3/33
Called vcc= 2/32
CalledAddress = AESA_1
Vcc 3/33
ATM
ATM switch
switch
Or
Or
RNC
RNC
CalledParty
CalledParty
CalledParty Node:
vcc= 2/32
Address = AESA_1
ATM
ATM switch
switch
intermediate
intermediate
sPVC
ATM
ATM switch
switch
Or
Or
RNC
RNC
CalledParty
CalledParty
Vcc 2/32
Figure 3-37 sPVC example
Since the sPvc is configured in the originating node, the sPvc is automatically set in each intermediate
node until the destination node. When establishing a sPvc, an intermediate Passport node runs the ACAC
to verify that the sPvc required bandwidth is acceptable.
In the originating Passport node the GCAC is run.
On each intermediate interface, if the node which sends the Pnni Setup message has a higher nodeId than
the node which receives it, then:
- The local interface vpi.vci is selected by the node which sends the setup message; the
vpi.vci value is chosen in the range specified by the minAutoSelectedVciForVpiZero and
maxAutoSelectedVciForVpiZero attribute.
If no more available vci for VPI=0, then a vci is chosen for the next vpi value; the vci
value is then chosen in the range delimited by: minAutoSelectedVciForNonZeroVpi and
maxAutoSelectedVciForNonZeroVPI attribute.
Else, the vpi.vci value is determined by the node which receives the pnni setup message.
The NodeId attribute is configured under the attribute: atmRouting Pnni ConfiguredNode.
3.3.11.4
PNNI REROUTING:
The rerouting mechanism provides route recovery across a PNNI routing domain.
On Link or Node failure within the PNNI network, the Node where is initiated the sPvc decides to re
established the connection on another path.
The rerouting is referred as Hard Rerouting in [R91], and Connection recovery in NTP.
It is the responsibility of the sPvc calling endpoint to attempt to re-establish the connection.
The rerouting is not performed on routes set through different PNNI routing domains. When a failure
occurs outside of the rerouting domain, no rerouting operation can be performed.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 99/240
Within a PNNI peerGroup, the Node which detects Link or Node failure sends a Release message to both
sPvc originating node and sPvc destination node. The original connection segment is released before the
establishment of the rerouting connection segment.
On the reception of the release message, in conversation phase, if connection recovery has been
activated for the call, see MML: AtmIf PNNI Ebr ConnectionRecovery, the atmSwitch where the sPvc
originates, determines an alternative path for re-establishing the sPvc.
The sPvc originating node blocks the release message and attempts to establish an alternative connection
segment to the destination node.
The sPvc destination node also blocks the release message of the call and waits for the sPvc originating
node to establish the alternative connection segment.
If a route exists, a new establishment procedure is initiated on a new path (SETUP and CONNECT
messages), the connection is restored over the new route. Otherwise, the connection is cleared back to its
end points through normal call clearing procedures.
To be able to reroute the connection, the rerouting node must find a route that meets or exceeds the
applicable QOS characteristics of the ATM service category requested for the original route.
Rerouting triggers:
- Reception of PNNI messages:
RELEASE or RELEASE COMPLETE with re-Routing cause EI,
SAAL Failure,
Restart or Status messages, with incompatible state.

The Hello protocol runs as long as the link is operational. It can therefore act as a link
failure detector when other mechanisms fail.
The Hello protocol monitor the status of the SVCC used as a PNNI routing control
channel between the two LGNs to increase robustness.
Failure of the SVCC indicated from lower levels (ATM, PHY, and Signaling) is treated as
a Link down Event. Procedures to re-establish the SVCC are followed.
Expiry of timer T310 or T303
Following table provides duration for re-routing a set of sPVC connections, according to type of Passport
equipment failure (card, shelf):
Recover 10,000 Connections
13 sec
FP reset 45,000 Connections
2 min
Shelf reset 200,000 Connections

35 min
Figure 3-38 SPVC Recovery Time for PCR 2.2
If unsuccessful, it will then retry at an interval specified by a configurable timer. The failure detection
time is dependent on the type of failures (for example, link, VC, Function Processors, and so forth).
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 100/240
LOS Condition
UMTS
UMTS
1/ RELEASE
2/ SETUP
PNNI
PNNI
ATM
ATM
UMTS
UMTS
1/ RELEASE
PNNI
PNNI
PNNI
PNNI
PNNI
PNNI
ATM
ATM
ATM
ATM
ATM
ATM
2/ SETUP
PNNI
PNNI
ATM
ATM
TX
TX
RX
RX
TX
TX
RX
RX
TX
TX
RX
RX
TX
TX
RX
RX
RX
RX
TX
TX
RX
RX
TX
TX
RX
RX
TX
TX
RX
RX
TX
TX
2/ SETUP
2/ SETUP
PNNI
PNNI
ATM
ATM
TX
TX
RX
RX
TX
TX
RX
RX
RX
RX
TX
TX
RX
RX
TX
TX
Figure 3-39PNNI re-Routing operation
See MML:
ATTRIBUTE AtmIf Vcc Src retryCount
This attribute indicates the number of failed attempts to set up the soft PVP or soft PVC since
the last time the connection failed.
Values Decimal (0..4294967295)
ATTRIBUTE ARtg Pnni failedRoutingAttempts
This attribute counts all calls routed through PNNI which failed. The counter wraps to zero
when it exceeds the maximum value.
ATTRIBUTE AtmIf Uni softPvpAndPvcRetryPeriod
ATTRIBUTE AtmIf Uni softPvpAndPvcHoldOffTime
3.3.11.6
PNNI HAIRPIN REMOVAL
Since pnni is activated on the utran interfaces, the pnni hairpin(s) is used as an option.
The reason for removing the pnni hairpin is to make free some RNC stm1/oc3 links and moreover make
free some classical 16pOC3/Stm1 FP atmConnections.
On the classical 16pOC3/Stm1 FP, it becomes mandatory to remove the pnni hairpin when:
- More than 800 nodeB are present on the RNC:
For the nodeB identified with aal2If = [801-1200], it is planned to configure the associated
atmConnections on the port 808 (5). This operation can be done after re-assigning pnni
hirpin ports resources to the port 808.
- Due to IuFlex feature, several MGw and several SGSN are present requiring more
atmConnections than currently allowed on the ports reserved for the Iu interface,
- The neighbor RNC require more atmConnection than than currently allowed on the ports
reserved for the Iur interface.
3.3.12 INVERSEARP
Reference: ARP [R68 & 66]
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 101/240
Context of the Iub oam ip over atm flow.

The ARP (AddressResolutionProtocol) is used to infer the target layer2 address (e.g.: Ethernet) from the
target Layer3 address (e.g.: IP). The ARP is implemented neither in NodeB nor in Passport.
InverseARP is used to infer the target Layer3 address (e.g.: IP) from the target Layer2 address (e.g.:
ATM). InverseARP is implemented in NodeB and Passport.
InverseARP is a protocol defined in [R83 & R84]. InverseARP provides a method for dynamically
discovering the IP address configured at the remote end of the VCC (e.g. Passport VR PP IP@).
InverseARP uses services of AAL5. On the Iub interface, InverseARP traffic is carried in the OAM Vcc:
IP
ARP
LLC/SNAP
AAL5
ATM
Layer1
An IP node sends InvARP Request to the remote IP node, and expects to receive InvARP Reply with
remote Host IP address included. Then the ARP table is updated with the mapping between VCC and
Host IP address.
Within Passport based nodes, ARP table is updated periodically, according to the setting of MML.
Remark:
In the context of IP over ATM network, ARP is not invoked, only InverseARP is invoked.
Therefore this section treats only InverseARP.
DHCP Request
DHCP Request
Ack
NodeB IP@
InvARP
Request
InvARP Reply
NodeB IP@
InvARP
Request
InvARP Reply
NodeB IP@
NodeB
NodeB
RNC-IN
RNC-IN
VCC OAM
NodeB
NodeB ARP
ARP Table:
Table:
ATM@
ATM@
Empty
Empty ifif PVC
PVC
VpiVci
VpiVci
OAM
OAM Vpi.Vci
Vpi.Vci
IP
IP
RNC
RNC IP@
IP@
RNC-IN
RNC-IN ARP
ARP Table:
Table:
@Age
@Age
xxx
xxx
ATM@
ATM@
Empty
Emptyifif PVC
PVC
VpiVci
VpiVci
OAM
OAM Vpi.Vci
Vpi.Vci
IP
IP
NodeB
NodeB IP@
IP@
@Age
@Age
xxx
xxx
Figure 3-40 InverseARP
When inverse ARP is absent in the remote node or not supported by the ATM interface, the IP address
configured at the remote end of the VCC must be provisioned locally using Passport feature called
StaticArp.
Remarks:
- InverseARP is the Passport default configuration.
- InverseARP is invoked within an IP subnet.
- On one Virtual Router, some ProtocolPorts may be configured with staticARP, whereas other
ProtocolPorts are configured with InverseARP.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 102/240
Mapping information from staticARP overwrites mapping information from InverseARP.

Do not configure StaticARP at one end of a connection and configure InverseARP at the other end
of the connection.
Rule: IubTEG_ARP_1
Within UMTS nodes, on IP over ATM interfaces, it is recommended to activate InverseARP with exception
of Interface terminating on otherVendor nodes not supporting InverseARP.
On nodeB by default is activated dynamic ARP.

On RNC-IN, choice of Dynamic or Static InverseARP, impacts the PassPort ATM MPE component
configuration.
When configuring an ATM MPE component, type of encapsulation must be specified:
Encapsulation type values:
- IpVcEncapsulation: is set when only IP packets are inserted in ATM cells. No InverseARP packet
may be inserted. Therefore with such an encapsulation mechanism InverseARP can not be
configured, only StaticARP applies.
- LlcEncapsulation: is set when IP packets, InverseARP packets, and other kinds of packets are
inserted in ATM cells. Then an LLC and SNAP overhead is added to the encapsulated packet.
Within SNAP overhead two bytes are filled with the EthernetType to reflect the type of inserted
packet:
- EthernetType = 0x0800 for IP packet,
- EthernetType = 0x0806 for InverseARP packet.
Rule: IubTEG_ARP_2
When configuring ATM MPE,
EncapsulationType must be set with value LLC Encapsulation value.
Remark:
If StaticArp is configured for all nexthop Ip@ used on the PP, EncapsulationType=
IpVcEncapsulation may be configured.
Moreover on RNC-IN, when VPT is configured, DynamicARP works correctly only if ATTRIBUTE
AtmIf faultHoldOffTime is set to 0 on port where is configured the VPT.
Rule: IubTEG_ARP_3
If VPT activated, Set ATTRIBUTE AtmIf faultHoldOffTime = 0 on RNC port where is
configured VPT.
Passport MML for dynamic InverseARP:
COMPONENT Vr Ip Arp DynHostEntry (DynHost)
ATTRIBUTE AtmMpe encapType (etype)
Passport MML for static InverseARP:
COMPONENT Vr Ip Arp HostEntry (Host)
This component defines a static host entry in the ARP table.
ATTRIBUTE Vr Ip Arp Host permanentVirtualCircuitNumber (pvcNo)
This attribute specifies the number of the PVC for the static host entry.
ATTRIBUTE Vr Ip Arp autoRefreshTimeout
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 103/240
This attribute defines the timeout value, in minutes, which is assigned to updated ARP entries,
or newly created ARP entries.
The range for the timeout is 1 minute to 1440 minutes (24 hours). Default 5.
ATTRIBUTE Vr Pp IpPort arpNoLearn
When this attribute is set with Disable, the ARP table is automatically updated with
InverArpResponse.
3.3.13 AAL2 COMPONENTS:

3.3.13.1
IUBIF:
Each nodeB is identified in the RNC by an aal2If instance. Under the IubIf are configured subComponent
srelated to the nodeB controlPlane and the nodeB userPlane either atm based (aal2If) or ip based (ipIf).
Rule: IubTEG_atm-RNC aal2-1
On Iub interface, there is a one to one relation between aal2If and IubIf.
The aal2if instances linked to the IubIf instances cannot be assigned to any other aal2 interfaces: IucsIf,
IurIf or IubIf.
Up to 2400 iubIf are currently reserved to identify up to 2400 nodeB.
3.3.13.2
AAL2IF
All the aal2 Paths configured between the RNC and an adjacent aal2 point node are configured under an
aal2If instance.
The ipIf component instance must be unique within the RNC.
The ipIf component instance range: [1, 5000] is reserved for the Iub interface
The adjacent aal2 Point is either a NodeB or an aal2Switch.
Remark: The RNC supports aal2Switch over the iub interface under some condition, see 3.3.18 .
Therefore an aal2If instance is assigned to each nodeB, within an aal2If instance are grouped all paths
serving the NodeB.
The bwPool is an optional component of the aal2If.
3.3.13.3
BANDWIDTHPOOL:
Furthermore the RNC introduced in the previous release the notion of bandwidthPool defined as a group
of aal2Paths amongst all the paths terminating on one specific nodeB. Then a bandwidthPool is a subset
of an aal2if.
The bwPool is optional under an aal2If component.
The bandwidthPool concept has been specified within the RNC to distinguish the nodeB aal2Paths
configured over different NodeB Transport media, e.g.:
- The NodeB paths configured over two different IMA linkGroups are grouped under two different
bwPools,
- The NodeB paths configured over different E1 (mode xPcm) are grouped under different bwPools,
- The NodeB paths configured over an IMA linkGroups and the NodeB paths configured over E1
(mix of xPcm and IMA mode) are isolated into different bwPools.
Moreover the aal2 paths configured over a nodeB IMA linkGroup may be distributed over different
bandwidthPools.
The composition of a bandwidthPool with a set of Path is done by configuration.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 104/240
The bandwidthPool concept has been extended to takes into consideration:

- The nodeB ip interface: see 3.2.3, on the RNC side, the bandwidth reserved for a nodeB ip
interface and the bandwidth reserved for a nodeB atm interface are isolated into different
bandwidthPools.
- The utranSharing: The traffic from the different PLMN sharing the utran may be as an option
isolated into different bandwidthPool.
- Asymmetrical traffic.
- Up to 16 bandwidthPools per aal2If,
- Each bandwidthPool may be populated with up to 16 aal2 paths.
- Within an aal2If the pathIds must be unique whatever they belong to same or different bwPools.
Remark: Even if the aal2If supports up to 16 bandwidthPool, 8 bandwidthPools are enough to cover case
of NodeB configured with 8 E1 in xPcm mode.
The bandwidthPool granularity is taken into consideration by the congestionManagement mechanism for
regulating the downlink traffic.
Rule: IubTEG_RNC aal2 Component_3
Each bwPool must be associated to a congestionManagement instance.
Definition:
- TrafficType: RNC classification of the umts traffic based on the: trafficClass and the RbSetQos
information.
Different types of bandwidthPool:
- primaryForTrafficType bandwidthPool:
The primaryForTrafficType bandwidthPool is supported only on the Iub interface and may be
specified for both the atm and the ip interfaces.
A limited range of UMTS trafficTypes is assigned to such a bandwidthPool: only the Hspa I/B
traffic can be handled over a primaryForTrafficType bwPool.
Within an ATM primaryForTrafficType bwPool, up to 3 qos streams: qos1, qos2 and qos3 may
be configured. The CM/backPressure applies to each 3 qos streams.

- The primaryForTrafficType is available only on the iub interface (interfaceType=Iub).
- Only for HSPA interactive and background traffic may be handle on the
primaryForTrafficType bandwidthPool whatever atm or ip interface.
- Up to 3 qos streams (qos1, qos2 and qos3) within an atm primaryForTrafficType
bwPool.
-
sharedForAllTrafficTypes bandwidthPool:
A sharedForAllTrafficTypes bandwidthPool may be specified only on the atm interfaces.
A wide range of UMTS trafficTypes selects such a bandwidthPool.
Within a sharedForAllTrafficTypes bwPool, the CM/backPressure applies to all the qos
streams with exception of the qos0 stream.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 105/240

- The R99 and Hspa streaming traffic is handle only on the atm
sharedForAllTrafficTypes bandwidth pool.
- As an option the Hspa I/B traffic is handled on the sharedForAllTrafficTypes bandwidth
pool.
-
PLMN common bandwidthPool versus PLMN specific bandwidthPool:

In the context of utranSharing, a bandwidthPool may be either shared by all the PLMN sharing
the utran or dedicated to one PLMN.
Each bwPool is linked to one transportMap, see 3.2.2. Within the transportMap is specified the bwPool
properties:
- TransportMap/Preference specifies the bwPool type either sharedForAllTrafficTypes or
primaryForTrafficType,
- Transportmap/transportServiceEntry specifies the trafficTypes assigned to the bandwidthPool.
Each bwPool must be associated to a transportMap instance with the appropriated
interfaceType.
Exemple of one atm sharedForAllTrafficTypes bwPool and one atm primaryForTrafficType bwPool
associated to one nodeB:
RNCIN
RNCIN / IubIf
aal2If i
TransportMap i
interfaceType: Iub
BwPool/x
transportServiceEntries:
[TC=conv, RbSetQos=0, ]
=> qos0
[TC=stream, RbSetQos=1+2, ]
=> qos1
[TC=interact, RbSetQos=1, ]
=> qos2
[TC=backGround, RbSetQos=1, ] => qos2

[TC=interactive, RbSetQos=2, ]
=> qos3
qos0
path
qos1
path
qos2
path
qos3
path
TransportMap j
interfaceType: Iub
BwPool/y
[TC=interactive, RbSetQos=2, ] => qos3
qos3
path
TEG
Figure 3-41, NodeB with two atm bwPools
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 106/240
Exemple of one atm sharedForAllTrafficTypes bwPool and one ip primaryForTrafficType bwPool

RNCIN
RNCIN / IubIf
aal2If i
TransportMap i
interfaceType: Iub
BwPool/x
qos0
path
qos1
path
qos2
path
qos3
path
=> qos0
=> qos1
=> qos2

=> qos3

TransportMap j
ipIf i
interfaceType: Iub
BwPool/y
ipFlow/i
qos 3

TEG
Figure 3-42, NodeB with one atm bwPools and one ip bwPool
According to the iub topology, different bwPool strategies may be chosen:
Topology
bwPool/Preference
Transport
Comments
N * sharedForTrafficTypes
Atm
One sharedForTrafficType bwPool per xPcm E1.
1 * primaryForTrafficType
Atm
One primaryForTrafficType bwPool associated to the nodeB IMA link.
1 * sharedForTrafficTypes
Atm
One sharedForTrafficType bwPool associated to the nodeB atm link.
Ip
Atm
One sharedForTrafficType bwPool associated to one nodeB IMA link.
Atm
One primaryForTrafficType bwPool associated to one nodeB IMA link.
Atm
One sharedForTrafficType bwPool associated to the nodeB IMA link.
N*E1+IMA
Hybrid Iub
One primaryForTrafficType bwPool associated to the nodeB Ethernet link.
2 IMA
1 IMA
UtranSharing:
Per definition a PLMN Common bwPool is a bwPool shared by all the PLMN sharing the Utran
whereas a PLMN specific bwPool is a bwPool dedicated to one PLMN sharing the Utran.
A PLMN Common bwPool and a PLMN specific bwPool may be either primaryForTrafficType or
sharedForAllTrafficTypes bwPool.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 107/240
On the iub interface may be configured a mix of PLMN Common bwPool and a PLMN specific
bwPool.
Per PLMN sharing the utran, may be configured one or several bwPool for atm, ip or mixed of atm and
ip interfaces.
For the case of PLMN specific bwPool, the bwPool component must be configured with the
corresponding PLMNId.
For the case of PLMN common bwPool, the bwPool component must be configured with the
PLMNId set to Zero.
Case of RNC configured with both PLMN common bwPool and PLMN specific bwPool for a
specific nodeB, the RNC selects first the resources from the PLMN specific bwPool, if exhausted
selects the resources from the PLMN common bwPool.
qos0 Paths
qos1 Paths
qos2 Paths
qos3 Paths
PLMN A specific bwPool bwPool1
atmSwitch
PLMN B specific bwPool bwPool2
qos0 Paths
qos1 Paths
qos2 Paths
qos3 Paths
PLMN common bwPool bwPool3
RNC
NodeB
qos0 Paths
qos1 Paths
qos2 Paths
qos3 Paths
IMA 3 E1
IP router
FE
IubIf i
aal2If i
ipIf i
TEG
Figure 3-43, bwpool in the utranSharing 2 PLMN context, exemple
Asymmetrical traffic:
To handle separately hsdpa and Hsupa flows, two different bandwidthPools must be specified linked to
two different transportMaps:
- The hsdpa is handle by a primaryForTrafficType bwPool linked to a transportMap including a
transportServiceEntry set with ulDlPreference: dlPref,
- The hsupa is handle by a SharedForTrafficTypes bwPool linked to a transportMap including a
transportServiceEntry set with ulDlPreference: ulDlPref.
The asymmetrical traffic handling applies:
- Only to the hspa I/B traffic,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 108/240
Only to on the Iub interface,

On both the atm and the ip interfaces.
Case of hybrid Iub:

- hsupa handles by the sharedForTrafficTypes bwpool over atm interface,
- hsdpa handles by the primaryForTrafficType bwpool over ip interface,
Case of nE1+IMA Iub:
- hsupa handles by the sharedForTrafficTypes bwpool over E1 link,
- hsdpa handles by the primaryForTrafficType bwpool over IMA link.
Case of 2 IMA Iub:
- hsupa handles by the sharedForTrafficTypes bwpool,
- hsdpa handles by the primaryForTrafficType bwpool.
RNCIN
RNCIN / IubIf
aal2If i
TransportMap i
interfaceType: Iub
BwPool/x
qosx
path
tse:
qos3
path
tse: [TC=interactive, RbSetQos=2, ulDlPreference = ulDlPref ] => qos3

tse: [TC=backGround, RbSetQos=2, ulDlPreference = ulDlPref] => qos3
TransportMap j
interfaceType: Iub
BwPool/y
qosx
path
path
tse: [TC=interactive, RbSetQos=2, ulDlPreference = dlPref] => qosx

tse: [TC=backGround, RbSetQos=2, ulDlPreference = dlPref] => qosx
TEG
Figure 3-44 Asymmetrical bwPools case of nE1+IMA
Robustness:
The robustness mechanism applies to the asymmetrical traffic: Hsdpa or Hsupa, identified by the
received radioBearerType UMTS EI
Assuming the configuration indicated in theFigure 3-44 Asymmetrical bwPools case of nE1+IMA:
In normal condition, the admissionControl assigns the hsdpa traffic to the bwPool/y.
In case of bwPool/y bandwidth exhaustion, the admissionControl assigns the hsdpa traffic
to the bwPool/x.
On call establishment, the admissionControl identifies the different TransportMap(s) including tse
satisfying the call qos characteristics.
If several TransportMaps are identified, the ulDlPreference parameter is taken into consideration for
determing the most preferred TM:
- A tse with ulDlPreference = ulPref or dlPref is more preferred than a tse with
ulDlPreference=ulDlPref.
- A tse with ulDlPreference = ulDlPref is more preferred than a tse with
ulDlPreference=noPref.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 109/240
If not enough available bandwidth in the bwPool linked to the most preferred transportMap, the
admissionControl assigns the call to the bwPool linked to the less preferred transportMap.
3.3.13.4
AAL2 PATHS
The RNC supports up to 810 aal2 paths per configured PSFP or DCPS.
UA6
4 PSFP/DCPS
6 PSFP/DCPS
7 PSFP/DCPS
8 PSFP/DCPS
10 PSFP/DCPS
12 PSFP/DCPS
Max # aal2 paths
3240
4860
5670
6480
8100
9720
Table 3-22, #aal2 connections
The pathId is coded on 2 bytes in the range [0, 65535].

Rule: IubTEG_atm-RNC aal2Path-1
The RNC supports up to 9720 paths, identified by a pathId in the range [0, 65535].
The pathIds must be unique within an aal2If, even if the PathIds belongs to different
bandwidthPool
Under one aal2If component, the paths are either configured against the aal2If or against a bwPool; a
mix of path under aal2If and path bwPool is not allowed.
3.3.13.4.1 AAL2 PATH ASSIGNMENT TO PMC-PC

At RNC start up phase, the already configured Paths are assigned to the different PMC-PC. An algorithm
within the RNC is in charge of distributing the configured Iub, Iur and IuCS aal2 Paths on the different
PMC-PC in such a way the PMC-PC are equally loaded.
The PMC-PC estimated load being equal to the sum of the path ECRgcac.
On the Iub interface all Paths under a particular aal2If, are assigned to one single PMC-PC, whatever
their aal2 Path Qos.
All aal2 Paths under a particular aal2If are assigned to one single PMC-PC, whatever the aal2
Path Qos. Indeed one PMC-PC handles all the Paths from one NodeB.
The load of a Path is estimated by means of its ECRgcac: ECRgcac = 2*SCR*PCR / (SCR+PCR).
The load of a PMC-PC is estimated by summing ECR from each Path configured on it.
3.3.13.4.2 AAL2 CID SELECTION

The loadBalancingMethod parameter configured against an UTRAN aal2 interface determines the CID
seizure policy over the aal2 interface:
- The loadBalancingMethod = Link: the CID is seized on the less loaded active Path within an aal2If.
- The loadBalancingMethod = PC: the CID is seized on a Path assigned to the less loaded PMC-PC.
On Iub interface, the loadBalancingMethod must be set to Link.
Remark:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 110/240
On call establishment a CID is seized on the less loaded active Path. If several Paths are equally
loaded, a CID is seized on the Path with the most idle CID.
- The loadBalancingMethod is set to PC on IuCS and Iur interface.
CID selection within the selected Path:
The RNC provides two different algorithms for electing a CID within a chosen path, either is
chosen the first free CID or the least recently used CID. The cidSelectMethod parameter value
determines the algorithm:
- cidSelectMethod = RoundRobin
The RNC selects a CID on roundRobin fashion.
- cidSelectMethod = standardQ2630
- On the IuCS, the RNC selects the available aal2 channel with the lowest
CID value,
- On the Iur, the RNC which is the path owner selects the available aal2
channel with the lowest CID value (from 8 to upwards) whereas the RNC
which is Not the path owner selects the available aal2 channel with the
highest CID value (from 255 to downwards).
- cidSelectMethod = proprietaryConfig
RoundRobin algorithm applies to the Iub interface and standardQ2630
algorithm applies to Iu and Iur interfaces.
On the Iub interface, keep the default cidSelectMethod = roundRobin.
Abnormal cases:
If the PC-CAC rejects the call, no other CID selection is done, since all the paths within an Iub aal2If
are assigned to the same PMC-PC.
3.3.14 AAL2 QOS

The mapping between the different kinds of path (qos0, qos1, qos2 and qos3 paths) and the ITU
codePoint is configured within the RNC.
ALU suggests a mapping as an example that may be modified by the network operator.
The mapping is configured in the RNC thanks to the parameter: qosxtoQ2630QosCodePoint, with x in the
range [0,3].
Based on the ITU codePoint definition:
1 Stringent class
2 Tolerant class

128 to 255 Reserved for network specific assignment

The following ITU code points are suggested for the UA6 realease:
- WithOut hspaStreaming:
qos0toQ2630QosCodepoint = 1
With hspaStreaming:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 111/240

3.3.15 AAL5 CONNECTIONS

The amount of aal5 connections supported by the RNC populated with CP4 depends on the amount of
PSFP/DCPS within the RNC:
4 PSFP/DCPS
6 PSFP/DCPS
8 PSFP/DCPS
10 PSFP/DCPS
12 PSFP/DCPS
Service groups
10
12
Max # aal5 vcc
1800
3000
4200
6000
7200
UA6
Table 3-23, #aal5 connections
This capacity is shared between the 3 utran interfaces.

Based on the amount of aal5 required per type of nodeB, is determined amount of supported nodeB:
The oneNodeB requires 3 ControlPorts
The picoBTS and microBTS requires 3 ControlPorts
The NodeB requires between 3 and 8 ControlPorts.
3.3.15.1
AAL5 CONNECTION ASSIGNMENT TO PMC-TMU
This section describes the RNC algorithm in charge of assigning the NodeB controlPort aal5 connection
to the PMC-TMU.
Each NodeB is assigned to the PMC-TMU through the serviceGroup parameter:
- A serviceGroup values is configured per nodeB,
- The RNC associates each serviceGroup value to an active TMU.
There are as many serviceGroup values as amount of active PMC-TMU (N+P). Each serviceGroup is
identified by the serviceGroupId in the range: [0, (max #active TMU 1)]
UA6, max # serviceGroup according to # TMU
# DCPS or PSFP
# active TMU
# spare TMU
# serviceGroup
serviceGroup Id
[ 0, 2 ]
[ 0, 4 ]
[ 0, 5 ]
[ 0, 6 ]
10
12
10
[ 0, 9 ]
12
14
12
[ 0, 11 ]
Table 3-24, serviceGroup
The nodeB distribution over the different PMC-TMU depends on the serviceGroup value configuration.
The maximum amount of nodeB per serviceGroup depends on the RNC capacity configuration (3.3.3):
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 112/240
all6mPktServSP
allPktServSP2
allPktServSP2FullDim
120
120
200
Max # nodeB per serviceGroup
Table 3-25, max #NodeB per serviceGroup
3.3.16 QOS
3.3.16.1
UMTS QOS INFORMATION
The Umts qos information taken into consideration by the RNC are:
- The TC (trafficClass): Conversational, Streaming, Interactive and Background,
- The ARP (AllocationPriorityPriority):
The ARP specifies the relative importance compared to other UMTS bearers for allocation
and retention of the UMTS bearers.
The ARP attribute is a subscription attribute which is not negotiated from the mobile
terminal.
In situations where resources are scarce, the relevant network elements can use the ARP to
prioritize bearers with a high ARP value over bearers with a low ARP value when
performing admission control.
ARP range value: [1, 2, 3]
- The THP (TrafficHandlingPriority):
The THP specifies the relative importance for handling of all the SDU belonging to the radio
access bearer compared to the SDU of other bearers.
The THP applies only to the interactive trafficClass umts flows.
Within the interactive trafficClass, there is a definite need to differentiate between bearer
qualities. This is handled by using the THP attribute, to allow the RAN to schedule traffic
accordingly.
THP range value: [1, 2, 3], with THP=1 being the highest priority while THP= 3 being the
lowest priority.
Moreover the ALU RNC introduces one more qos information taken into consideration in the qos
mapping table:
- RbSetQos:
Traffic class
IUB interface
RbSetQos
R99
Conv
+cSRB+dSRB
R99 Streaming
R99 I/B
Hspa I/B+Streaming
Conversational
Common
Signaling
Streaming
Interactive
Background
Streaming
Interactive
Background
Since the Transport qos information are correctly mapped between each others, the final objective is to
mapped each different UMTS flows to a specific DSCP value in such a way each umts flow received the
expected qos treatment and is correctly marked.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 113/240
The UMTS qos information is mapped to the Transport Qos information through the configurable
TransportMap RNC component.
3.3.16.2
SERVICECATEGORY
The RNC supports the serviceCategories: cbr, rtVbr, nrtVbr, ubr and ubr+.
To each serviceCategory is assigned a trafficDescriptorType value which determines which
trafficDescriptor parameters must be set against the vcc:
SC
tdt
Tx tdp1
Rx tdp1
Tx tdp2
Rx tdp2
Tx tdp3
Rx tdp3
pcr
pcr
Vbr
pcr
pcr
scr
scr
mbs
mbs
Ubr
Ubr+
pcr
pcr
mdcr
mdcr
Cbr
A MDCR (Minimum Desired Cell Rate) may be configured against an ubr vcc, in such case the ubr
serviceCategory is said ubr+.
The MDCR is the bandwidth reserved by the ACAC for the ubr+ atmConnection, ECRacac = MDCR.
Moreover the MDCR is also taken into consideration by the aal2 CAC: ECRgcac = MDCR.
Rule: IubTEG_atm-RNC_QOS_1
When tdt=9 is associated to the ubr serviceCategory, a MDCR must be configured against the vcc.
Remark:
- The MDCR is configured through the tdp3.
- The PCR must be non-zero and must be greater than or equal to MDCR..
The cbr sc is either associated to the tdt=3 or tdt=1. In the second case no bandwidth is configured against
the cbr vcc.
The vcc trafficDescriptor may be set asymmetrical.
3.3.16.3
QUEUE
Within the RNC, one queue is assigned either per atmConnection (perVcQueuing) or per serviceCategory
(Common Queuing).
The perVC queuing is recommended.
The queues assigned to the atmConnections with same serviceCategory, have identical characterisctics
(Size, thresholds ).
The perVc queue size depends on the serviceCategory configured against the atmConnection:
- CBR atmConnections are assigned to short size highest priority queues,
- VBR atmConnections are assigned to larger size lower priority queues,
- UBR atmConnections are assigned to large size lowest priority queues.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 114/240
The buffer size is configurable, nevertheless within the context of UMTS network the default values are
used with exception of the shaped vpc queue case.
If trafficShaping at vp level is activated, the default queue size calculated by the RNC 16pOC3/Stm1
PQC FP is too short, the vpc queue size should be increase:
On the 16pOC3/Stm1 PQC FP port configured with shaped rtVbr Vpc, set:
atmIf Ca rtVbr TxQueueLimit = 4000 cells
The Vpc being configured with:
atmIf Vpc Vpd Tm txQueueLimit (txQlim) = sameAsCa
Example of MML commands for CBR serviceCategory buffer size setting:

ATTRIBUTE AtmIf CA Cbr txQueueLimit (txql)
This attribute specifies the default maximum queue length for the emission queues used to buffer the
traffic of the CBR service category. It is used as the basis for setting both:
- the queue length and
- the discard thresholds
The discard thresholds are set at approximately 35, 75 and 90 percent of the scaled queue limit for traffic
at discard priority 3 (DP=3), DP=2 and DP=1 respectively.
When this attribute is set to autoConfigure, an appropriate value is selected based on the card type. It is
set to 96 for the following Passport ATM cards (DS1, E1, DS3, E3, and OC-3).
For ATM IP FPs, the per-VC queue limit may be overridden for a permanent connection by specifying a
value in the Vcd Tm or Vpd Tm txQueueLimit attribute. The operational value of the maximum length of a
queue (common or per-VC) is indicated by the Vcc Tm, Vpc Tm, or Vp Tm txQueueThresholds attribute.
Default autoConfigure
ATTRIBUTE AtmIf Vcc Vcd Tm txQueueLimit (txQlim)

This attribute specifies an override to the default transmit queue limit for this connection.
A value of sameAsCa means that the default per-VC transmit queue limit, as defined by the CA service
category, is used for this connection Default sameAsCa
Per Card and per serviceCategory, a summary of the default buffer size values:
16pOC3/Stm1 FP:
xpOC3 FP
serviceCategory
CBR
rtVBR
nrtVBR
UBR
BufferSize
maximum effective
96
480
10240
10240
86
432
7680
7680
ratio
90%
90%
75%
75%
Figure 3-45 16pOC3 FP buffer size
Notes:
-
BufferSize/Maximum is the size of the buffer, configured in ATTRIBUTE AtmIf CA Cbr

txQueueLimit (txql).
The Ratio is the buffer threshold at which Clp0 cells are discarded.
The effective BufferSize is the buffer occupancy at which incoming cells, whatever their CLP
value, are discarded.
BufferSize/Effective = Ratio * BufferSize/Maximum
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 115/240
When setting trafficDescriptor, the effective BufferSize is used by the CAC for processing ECR.
Example of the 16pOC3/Stm1 PQC queueing system:
The 16pOC3/Stm1 FP queue system is composed of two types of queue:
- the perVc queues, one queue is allocated to each atmConnection and
- the classQueue, one classQueue is allocated to each EP.
APC
Class
Scheduler:
EP & M BG
Transm it
PerVC & comm on Q ueues
Connection Scheduler:
SFQ
EP0 Q ueue
Per VC Queues :
Com mon
Queues:
LinkClass
Queue
for EP0
n1 cells
ATM Connection 1 Queue

W eight 1
n2 cells

W eight 2
n3 cells

W eight 3
AT M IP FP QOS M apping
SC
EP
(5 EP, from EP0 to EP7)
FROM
PQC
CLP, SC and CC
Cell discard
Or Comm on Queue:
EP0
cells
EP1
Connection Scheduler:
W FQ
CBR
EP2
I = [2, 3, 7]
rtVBR
EP3
EP i Queue
Per VC Queues :
Com mon
Queues:
To Link
Egress
nrtVBR
ATM Connection i1 Queue
W eight 1
EP4
EP5
LinkClass
Queue
for EP i

W eight 1
EP6
W eight 1
UBR
EP7
Or Comm on Queue:
AP C M apping Table,
SC m apped to EP configurable
Figure 3-46 Buffers within APC based card
3.3.16.4
CLR
The CLR (Cell Loss Ratio) is defined as the number of lost cells divided by the total number of
transmitted cells per ATM Connection.
The CLR is specified per ServiceCategory at pvc provisioning. It is involved in ECR calculation done by
the ACAC.
A small CLR value (for example 10-10) configured against a serviceCategory, results in reserving more
bandwidth to the atmConnections configured with this serviceCategory, in other word results in a larger
ECR.
If CLR=0, means that no bandwidth is reserved per atmConnection.
No CLR is configured against the UBR serviceCategory, since no bandwidth is reserved for the UBR
atmConnections.
3.3.16.5
SCHEDULING
This section describes the RNC 16pOC3/Stm1 PQC FP two stages scheduler.
The scheduler first stage serves the perVc queue and fills the classQueues.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 116/240
The scheduler second stage serves the classQueue.

Configuration:
- QOS mapping table in configured:
o Per port, each SC is mapped to one EP,
o A classQueue is allocated to each EP.
- ATM Connections are configured with SC and TD,
o A SC is configured against each atmConnection
o A perVC queue is allocated to each atmConnection,
When traffic is running:
- Connection Scheduler (WFQ or SFQ):
o The perVc queues are served by the connectionScheduler (firstStage scheduler). The
connectionScheduler is based on the WFQ or SFQ (if trafficShaping activated).
o The amount of cells extracted per perVC queue depends on PerVC Weight (WFQ), or
Frequency of pulling per VC queue depends on shaping Rate (SFQ, T=1/PCR)
o The classQueues are filled by the connectionScheduler.
- Class Scheduler:
o Each linkClass (5 for APC, and 8 for AQM) queue is served according to its priority.
APC
Class
Class Scheduler
Scheduler Connection
Connection Scheduler
Scheduler
WFQ
WFQ or
or SFQ
SFQ
QOS Mapping, APC case:
EP 0 linkClass Queue
1/ SC:
EP 0 perVC Queues
EP, (5 EP (O, 2, 3, 4, 7)
n1 cells
Weight 1
n2 cells
2/ CLP, SC and CC:

cellDiscard

Weight 2
n3 cells
From PQC

Weight 3
APC Mapping Table,

P0
To Link
Egress
EP1
CBR
EP2
EP 7 perVC Queues
EP 7 linkClass Queue
rtVBR
EP3
n1 cells
Weight 1
n2 cells

Weight 2
n3 cells
(EP & MBG)

Weight 3
nrtVBR
EP4
EP5
EP6
UBR
EP7
Figure 3-47 Passport APC Scheduling
Remark:
The perVC weight is per default calculated by the Passport based on the atmConnection trafficDescriptor
or manually set using the MML: ATTRIBUTE AtmIf Vcc Vcd Tm weight.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 117/240
3.3.16.6
DISCARD POLICY
The 16pOC3/STM1 PQC card is based on the APC asic. This section describes the discard policy for the
APC.
According to AtmConnection serviceCategory, the CLP field value and the buffer load, the received cell
is either stored or discarded.
The APC perVC buffers are implemented with 2 hardcoded thresholds, called CongestionControl levels,
involved in the discard policy. The CC level thresholds are set per serviceCategory:
90%
CLP0 discard
CC0
CC1
CBR
38%
CLP1 discard
CC2
CC3
90%
rtVBR
CLP0 discard
CC0
CLP0 discard
CC0
CC1
nrtVBR
38%
CLP1 discard
CC1
CC2
75%
CLP1 Discard
CC2
CC3
32%
CC3
Figure 3-48 CongestionControl levels on APC card.
No discardPriority parameter on the APC based card, the cell CLP values is directly compared to the
buffer occupancy:
Queues:
MappingTable :
ATM Interface :
EmissionPriority
EP0 Queue
Tagged cell
NonTagged cell
Most Urgent
90%
38%
CBR
CLP1
Cell2
CLP0
Cell1
EP0
VCC CBR
EP1
CC0 CC1 CC2
CC3
rtVBR
EP0 queue is in CC2.

Cell1, CLP0, is accepted.
Cell2, CLP1 is rejected.
EP2
EP3
EP4 Queue
Tagged cell
nrtVBR
NonTagged cell
EP4
CLP1
75%
Cell2
CLP0
Cell1
32%
EP5
VCC nrtVBR
EP6
CC0 CC1 CC2
CC3
UBR
EP4 queue is in CC2.

Cell1, CLP0, is accepted.
Cell2, CLP1, is rejected.
EP7
Least Urgent
Figure 3-49 Discard Policy on APC card, based on an example of QOS mapping table.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 118/240
3.3.16.7
CDV, CDVT
The CDV (Cell Delay variation) is the jitter introduced by different network atm queuing stages on the
atm cells:
- Increasing buffer size, or selecting a lower priority serviceCategory, increases the CDV, on the
other hand decreases the cell Loss ratio.
- Decreasing buffer size, or selecting a higher priority serviceCategory, decreases the CDV, on the
other hand increases the cell Loss ratio.
The choice of the atmConnection serviceCategory and buffereSize results from a tradeoff between CDV
and cell Loss.
As long as trafficShaping is desable, the CDV for the highest priority serviceCategory is calculated on the
following way: CDV = BufferSize/EgressLinkThroughput
Due to the CDV introduced by the atm backbone, the atm cells arrive in the downstream node before or
after the TAT (Theorical Arrival Time). The atm cells arriving after the TAT, are conformed on the other
hand the atm cells arriving before the TAT are not conformed. Non conformed cells are rejected by
Policing if activated.
The CDVT (CellDelayVariationTolerance) is a tolerance taken into account by the Policer, which applies
to cells arriving before TAT. Setting the CDVT value allows to reduce amount of rejected cells in a
downstream node where Policing is activated. CDVT unit is second.
According to CDVT value, cells arriving before TAT, in the limit of CDVT, are declared conformed.
CD V T = < ( T
), e g : C D V T= ( T ):
P e rio d 1
TAT
P e r io d 2
TA T
P e r io d 3
TA T
P e rio d 4
TAT
t
T = 1/P C R
CDVT
CD V T > ( T
CDVT
C DV T
) , e g : C D V T = 2 *( T ) :
P e rio d 1
CD V T
TAT
P e r io d 2
T AT
P e r io d 3
TA T
P e rio d 4
TAT
t
T = 1/P C R
CD VT
CD V T
CD V T
CD V T
Figure 3-50 CDVT representation
The CDVT value determines the amount allowed of backToBack cells. The BackToBack cells being the
amount of cells transmitted at linkRate.
Amount of cells transmitted backToBack declared conformed depends on CDVT value:
N = Integer [1 + CDVT / (T )], with:
N: amount of cells transmitted backToBack,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 119/240
T = 1/PCR,
: cell transmission time duration, depends on kind of link.
3.3.18 ALCAP
Within the RNC no parameter is set for activating the Alcap.
Since the NodeB AlcapActivation parameter is set to true, no more version/edition fields included in the
NBAP message then the RNC concludes that the Alcap is the protocol used for the aal2 connection
establishment.
Rule: IubTEG_atm-RNC_Alcap_1
Since alcap is activated on the Iub interface, one single alcap vcc must be configured per nodeB.
The Node B inserts its own A2EA in the NBAP RL Setup Response TLA sent to the RNC. The RNC aal2
address translation table must be configured with the NodeB A2EA and the associated aal2If and PathIds.
R99 traffic over ATM

RNC
Node B
NBAP RL setup/add/reconf request

NO TLA/BindingId IE,
Node B => ATM bearer.
NBAP RL setup/add response

- TLA IE: Node B A2EA in NSAP format
- Binding Id: Node B context reference
ALCAP ERQ
- Destination address:
Node B A2EA in NSAP format
- SUGR parameter:
Binding Id (Node B context reference)
- CEID: aal2 path + CID
ALCAP ECF
TEG
Figure 3-51 Alcap protocol flow
Both the RNC-IN and the RNC-CN models are involved in the Alcap configuration.
The RNC-IN model:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 120/240
Root
IubIf i
Aal2if i
- Cacm
RNC
IubTransport flowCtrl
- activation
- CidSelectMeth
Sig (07)
- Qosparameters
- saalUni
Qaal2Parameters
- orig A2EA,
- LoadBalancingMeth
Nap/ atmConnection
- UmtsInterfaceList (up to 16)

UPlane
- linkTo aal2If
- Qaal2 timers,
- aal2RouteList (up to 128)

Qaal2 endPoints
A2EA (0):
bwPool x
PathId i
- atmConnection
aal2If, cost
- Qos
A2EA (16 383):
- pathOwner
aal2If, cost
Alcap bearer
-saalUni
Nap/ atmConnection
TEG
Figure 3-52, RNC-IN Model
The RNC-CN model:

RNC
ULRbSetConf
- Qaal2 Cac
NodeB
- ConnectionMode,
DLRbSetConf
- Qaal2 Cac
- saalUniParams
(common for CP, CCP and Alcap)
- IubIfID,
Linked to RNC-IN model/ Root/IubIf
- nodeBCapability,
- alcapCelValidityTimer,
- nodeBType.
CtrlPort (up to 8)
Linked to RNC-IN IubIf/Sig507)
- CtrlPort Id,
- CtrlPortType:
- 0: CP, 1: CCP, 2: SCP, 3: alcap
TEG
Figure 3-53, RNC-CN Model
According to the RNC-CN model, the RNC allows configuration of one single alcap
connection per nodeB. Within the RNC one Alcap connection must be assigned to each nodeB
supporting Alcap. The ctrlPortType=3 is assigned to the Alcap connection.
Within the RNC-CN model:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 121/240
The ctrlPortType = 3 must be used for the Alcap connection,

The ctrlPortType = 0 must be used for the CP connection,
The ctrlPortType = 1 must be used for the CCP connection.
On the Iub interface, several SSCOP connections are established per nodeB for the different
SSCOP-Users: nbap-c, nbap-d and Alcap.
The RNC-CN model allows configuration of one single set of SaalUni parameters per nodeB.
It applies to all the nodeB SSCOP connections whatever the SSCOP-User.
On the RNC, one set of saalUni parameters is configured and applies to all the sscop
connections (nbap and alcap sscop connections).
Aal2 Translation Table:
Within the RNC-IN model, the RNC aal2 translation table must be fill with the nodeB A2EA
and the associated aal2If component.
The RNC aal2 translation table must be fill with the nodeB A2EA and the associated
aal2If component.
Only one aal2If instance must be assigned against one qaal2 endPoint A2EA.
The RNC aal2 feature: prefixAddressing is not used on the Iub interface, since the RNC
allows up to one nodeB beyond the aal2Switch.
The alternative routing is not supported.
Alcap Cell Validity Timer
The RNC supports the Alcap Cell Validity Timer. It is configured per nodeB.
On Alcap SSCOP disconnection, the RNC rejects all the new aal2 connection establishment
requests and starts the Alcap Cell Validity timer.
At the expiration of the Alcap Cell Validity timer, the aal2 connections are released.
- If the RNC Alcap Cell Validity Timer is not provisioned (infinite value): the aal2
connections are maintained during the SSCOP disconnection, whatever the SSCOP
disconnection duration.
- If the RNC Alcap Cell Validity Timer is provisioned:
- The aal2 connections are maintained as long as the timer is running,
- At the expiration of the timer, the aal2 connections are released.
- If the RNC Alcap Cell Validity Timer = 0, the aal2 connections are released since the
SSCOP is disconnected.
The Alcap Cell Validity timer must be configured on only one aal2 node (endPoint or
relayPoint), either the nodeB or the RNC or the aal2Switch if present).
Assuming no aal2Switch on the Iub interface:
- When the RNC interworks with the iBTS nodeB then the Alcap Cell Validity timer
must be desactivated in the RNC. The SSCOP disconnection event is under control of
the nodeB.
- When the RNC interworks with the oneBTS nodeB, the Alcap Cell Validity timer
must be activated in the RNC since not available in the nodeB. The RNC controls the
SSCOP disconnection event.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 122/240
The RNC Alcap Cell Validity must be desactivated when Interworking with the iBTS
nodeB.
The RNC Alcap Cell Validity must be activated when Interworking with the oneBTS
nodeB.
Remark: To desactivate the RNC timer, the timer is not provisioned.
Aal2 Switch:
An aal2Switch may be inserted on the Iub interface. Nevertheless the ALU RNC doesnt allow
several NodeB beyond one aal2Switch. Indeed the alcap vcc is configured in the RNC per
nodeB (RNC/NodeB/CtrlPort/controlPortType). The ALU RNC accepts an Iub topology where
each aal2Switch is dedicated to one nodeB.
If the aal2Switching function is required on the Iub interface, each aal2Switch node
must be dedicated to one single nodeB.
3.4
RNC IP
This section is related to the RNC transport features applying to the RNC ip interfaces (ip RNC and
hybrid RNC).
The IP RNC is populated with two 4pGE FP and up to 12 PSFP/DCPS. It provides all utran interfaces
over IP.
The hybrid RNC is populated with two 16pOC3/Stm1 FP, two 4pGE FP and up to 10 PSFP/DCPS.
The hybrid RNC supports simultaneously atm nodeB, hybrid nodeB and ip nodeB.
Remark: The hybrid NodeB atm leg handles all kind of traffic (controlPlane and userPlane) including as
an option the Hsdpa and Hsupa interactive/Background traffic while the IP leg handles only the Hsdpa
and Hsupa interactive/Background userPlane traffic.
The features related to the atm interfaces are described in the section 3.2 RNC ATM.
On the RNC, each nodeB is declared either nativeIP nodeB, hybrid NodeB or ATM nodeB:
Parameters: isIubOnNativeIpAllowed and nodeBCapability (see 3.2.4).
Parameters
isIubOnNativeIpAllowed
nativeIP nodeB
1
Hybrid NodeB
0
Atm nodeB
0
nodeBCapability
3.4.1
FP
3.4.1.1 4PGE FP
The 4 pGE FP provides 4 Ethernet accesses:
- Ethernet port throughput: 1 Gb/s
- FP throughput: 2,5 Gb/s.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 123/240
3.4.1.1.1 PHYSICAL
The 4pGE FP is designed according to the MS3 architecture.
It is composed of the GQM/FQM ASIC, which determines the FP egress qos and TrafficManagement
capabilities.
It provides 4 ethernet ports each offering a transmission 1 giga bit/s in both directions on optical medium.
Each port can be independently configured as SX (1000Base-SX), or LX (1000BASE-LX):
- 1000BASE-LX interface:
The "LX" stands for Long wavelength lasers to transmit data over fiber optic cable.
- 1000BASE-SX interface:
The SX stands for Short wavelength lasers to transmit data over fiber optic cable.
Rule: IubTEG_4pGE FP_1
- The 1000BASE-LX interface supports single-mode optical fibers (SMF) or multimode optical
fibers (MMF).
- The 1000BASE-SX interface supports only multimode optical fiber.
3.4.1.1.2 LAYER2 FRAME:

The 4pGe FP is able to receive and transmit the Ethernet v2 frames.
The 4pGe FP accepts the received IEEE802.3 LLC-SNAP frame, but not capable to transmit the
IEEE802.3 frame.
On reception of an IEEE 802.3 frame, if forwarding is required, the RNC forwards the received IEEE
802.3 frame in the ethernet v2 format.
The minimum ethernet frame size is 64 bytes as specified by the IEEE.
The maximum ethernet frame size is configured (attribute Lp Eth maxFrameSize).
The configured maximum frame size value takes into consideration the ethernet frame fields: destination
and source addresses, the 4 bytes length Q-Tag if present, the protocolType, the payload and the CRC.
The Ethernet frame preamble is not taken into account.
The configured maximum ethernet frame size has been set in such a way to allow an IP packet 1500 bytes
length (default MTU value).
The current configured maximum Ethernet frame size is 1518 bytes.
The current configured maximum Ethernet frame size is 1522 bytes when VLAN field inserted in
the frame.
3.4.1.1.3 AUTONEGOCIATION
The objective of the auto-Negotiation function is to provide the means to exchange information between
two devices that share a link segment and to automatically configure both devices to take maximum
advantage of their abilities.
It is recommended that the link partner activates the auto-negotiation with remote fault encoding
and that auto-negotiation be enabled on the GigE port.
The auto-negotiation can be enabled or disabled for each GigE port (Lp Ethernet autoNegotiation
attribute).
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 124/240
3.4.1.1.4 QOS
FP Scheduler:
The 4pGE FP provides 8 classQueues per port.
The 4pGE FP scheduler applies the absolute PriorityQueuing algorithm to the two highest priority class
queues: EP0 and EP1 and applies the WFQ algorithm the the six lowest priority class queues.
Since the EP0 and EP1 class queues have been served, the scheduler shared the residual bandwidth
between the EP2 to EP7 class queues according to the weight assigned against these queues.
The scheduler terminates transmission of any IP packet from the served queue before visiting another
queue. The empty queues are skipped by the scheduler.
The 4pGE FP must be configured with:
- Tthe mapping between each DSCP value and the classQueue,
- ClassQueue properties,
- The per DSCP discard policy.
IP DSCP mapping to classQueue:
Each DSCP value is mapped to the RNC proprietary parameter trafficClass, which determines
the priority assigned by the scheduler to the behaviourAggregate.
Several DSCP values may be mapped to one single trafficClass value.
The mapping between the DSCP value and the trafficClass value is set through the attribute: Vr
Dsd Phb trafficClass.
Range value: [critical, network, premium, platinum, gold, silver, bronze, standard].
Without customisation, the following default Qos mapping applies:
DSCP
CS7
trafficClass
Critical
CS6
Network
EF, CS5
Premium
CS4, AF4y
Platinum
CS3, AF3y
Gold
CS2, AF2y
Silver
CS1, AF1y
DE
Bronze
Standard
Table 3-26, trafficClass
Furthermore each trafficClass value is mapped to a schedulingClass value through the attribute
Vr Dsd Tc schedulingClass8Queues (sc8q).
This value is used to select one queue over the eight supported by the 4pGE FP port when
transmitting packets.
A higher schedulingClass value is assigned to the more delay sensitive behaviourAggregate.
The (sc8q) schedulingClass range value: [0, 7].
Without customisation, the following default mapping applies:
trafficClass
Critical
schedulingClass (sc8q)
7
Network
Premium
Platinum
Gold
Silver
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 125/240
Bronze
1
Standard
0
Table 3-27, schedulingClass
The 4pGE FP applying the WFQ algorithm to the EP2 to EP7 queues, a weight is assigned to
each EP2 to EP7 through the MBG component which determines queue serving policy of the
scheduler. A higher MBG value is assigned to the higher priority queue.
Without customisation, the following default mapping applies:
EP Queues:
EP0
MBG
Na
EP1
Na
EP2
EP3
50
25
EP4
10
EP5
EP6
EP7
3
Table 3-28, MBG
Taking into consideration the DSCP values specified for the current utran release and the qos mapping
done within the 4pGE FP, the following qos information mapping applies:
Transport Qos information mapping:
DSCP
trafficClass
schedulingClass
EP
MBG%
CS6
EF
critical
network
premium
7
6
5
0
1
2
na
na
50
Queue
Size
100 K
300 K
300 K
platinium
25
300 K
gold
silver
bronze
gold
silver
bronze
gold
silver
bronze
Standard
3
2
1
3
2
1
3
2
1
0
4
5
6
4
5
6
4
5
6
7
10
7
5
7000 K
4200 K
3000K
7000 K
4200 K
3000K
7000 K
4200 K
3000K
2200 K
AF41
AF42
AF43
AF31
AF21
AF11
AF32
AF22
AF12
AF33
AF23
AF13
DE
Discard policy:
A dropPrecedence value is assigned to each DSCP value through the attribute: Vr Dsd Phb
dropPrecedence.
Per classQueue, a queue congestion threshold is associated to each dropPrecedence value.
When receiving an IP packet from the backplane, according to the IP packet dropPrecedence
and the queue occupancy rate the IP packet is either enqueued or discarded:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 126/240
The IP packet is discarded if the queue occupancy rate is higher than the congestion
threshold associated to the IP packet dropPrecedence.
The IP packet is enqueued if the queue occupancy rate is lower than the congestion
threshold associated to the IP packet dropPrecedence.
The dropPrecedence range value: [low, medium, high], while le low value indicates that the
behaviourAggregate is less candidate to discard compared to a high dropPrecedence
behaviourAggregate.
Without customisation, the following default qos mapping applies:
DSCP
CSx, AFx1, EF
dropPrecedence
Low
AFx2
Medium
AFx3, DE
High
table 3-29 Qos mapping: dropPrecedence
It is suggested to apply the RNC default dropPrecedence values:
Transport dropPrecedence suggestion:
DSCP
dropPrecedence
AFx1, CS6
Low
AFx2
Medium
AFx3, DE
High
with x = (1, 2, 3, 4)
Ethernet QOS
P-Tag:
The 3 bits length P-Tag field is ignored on the reception of a valid frame and is set to 0 when
transmitting a Vlan tagged frame.
The P-Tag is ignored by the RNC
3.4.1.1.5 LAN / VLAN

The ethernet Vlan objective:
- Split an ethernet port into several sub virtual ports each identified by a Vlan Identifier and
- Reduces the ethernet broadcast traffic.
The Vlan is an optional ethernet concept. If Vlan configured on the Iub interface, the Vlan configured on
the RNC side terminate on the adjacent IP router, other Vlan may be configured between the nodeB and
their adjacent IP routers.
The Vlan may be configured on the RNC as long as the 4pGE FP is activated.
On the RNC 4pGE FP, one port is set with one of the two modes: Port Mode or Vlan mode.
- The Port Mode applies to a 4pGE FP port when no Vlan component is configured over the port.
The received Vlan untagged and Priority tagged frames are accepted.
The received Vlan tagged frames are discarded.
- The Vlan Mode applies to a 4pGE FP port when one or several VLAN components are configured
over the port.
A VR PP is no more linked to a Lan component but to a specific Vlan component.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 127/240
The IP packets are transmitted within an ethernet frame including the Vlan ID.
Any received ethernet frames are accepted under condition it is tagged with the expected Vlan
Identifier.
The untagged or priority tagged received frames are accepted under condition the port Vlan is
configured, else discarded.
Port mode:
Vlan mode:
EM
EM
LanApplication (La)
LanApplication (La)
Vlan
LinkToProtocolPort
LinkToProtocolPort
TEG
Figure 3-54, port mode versus Vlan mode components

The choice between port mode and Vlan mode is set at the ethernet link level, not at the
FP level.
When Vlan configured over an ethernet port, the entire port operates in Vlan mode.
When operating in Vlan mode, the 4 bytes Q-Tag field is inserted within the ethernet frame,
therefore the MFS (Maximum Frame Size) must be increased (attribute: Lp ethernet MFS). See
3.4.1.1.2.
Within the RNC each Vlan is linked to a different VR protocol Port.
One VLAN is linked to one VR/ProtocolPort.
Dimensioning:
The 4pGE FP supports:
- Up to 400 Vlan per RNC,
- Up to 60 Vlan per VR,
- Up to 12 Vlan per GE port if PDR enable,
- Up to 48 Vlan per RNC if PDR enable.
Beside a RNC VR supports up to 60 protocol ports. As a consequence up to 60 Vlan may be
linked to one RNC VR.
Protocol:
The 4 bytes length Q-Tag field is inserted in any frames transmitted over a Vlan. The Q-Tag is
composed of different fields:
- Q-Tag / Tag Protocol Identifier field:
The RNC set the Q-Tag / Tag Protocol Identifier field with 0x8100 and accepts any received
frame with such a Tag Protocol Identifier value. The frame received with another Tag Protocol
Identifier values are discarded.
The 4pGe FP accept any received tagged frame with Q-Tag / Tag Protocol ID = 0x8100
and discard received frame with other Tag Protocol ID value.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 128/240
- VLAN Identifier field:

The 12 bits length VLAN field is set with a value in the range: [0-4095].
- Vlan ID = 0: the null-VLAN indicates that no VLAN is configured on the Ethernet
port.
- Vlan ID = 1: indicates the port VLAN on the 4pGe FP. The port VLAN is
represented by the LanApplication component when the port is operating in VLAN
mode. In the Vlan mode, the received untagged or priority tagged frame are handle
by the port Vlan if present.
- Vlan ID = 4095: is discarded for IP applications
As long as VLAN is configured on a RNC GE port, the 4pGe FP accepts any tagged
frame with a VLAN ID in the range [2-4094].
Any received tagged frames with an unknown VLAN or a Vlan ID = 4095 are discarded by the
RNC.
3.4.1.1.6 ARP
The 4pGE FP ARP table is dimensioned to support up to 500 entries per port and up to 1000 entries per
FP.
As an example:
- A RNC VR protocol port configured with a /30 subnet size consumes one 4pGE FP ARP table entries,
- A RNC VR protocol port configured with a /24 subnet size consumes 252 4pGE FP ARP table entries.
The 4pGE FP ARP table supports up to 500 entries per port and up to 1000 entries per FP.
3.4.1.1.7 SOC
IP:
IP
Supported
IPv4
IP static routing
Ipv6
ICMP
ECMP (note1)
ARP
IPSec
DHCP relayAgent
Fragmentation (note2)
DifferentiatedServices
PDR (protection Default Route)
Not Supported
OSPF, RIP
Note1: The ECMP used as protection against a 4pGE FP failure causes a too long traffic disruption, >
1s)
Note2: Fragmentation is not actually performed on the 4pGe card since the MTU of the egress IP port
will always be greater than or equal to the incoming IP packet size.
Ethernet:
Ethernet
Supported
Auto negotiation
Not Supported
LAG
MAC Pause frame note1)
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 129/240
Note1: The MAC pause are not generated by the 4pGEFP, nevertheless the 4pGEFP responds to the
received MAC Pause frame by stopping the traffic on that port until that pause condition is removed.
3.4.1.2 PSFP OR DCPS FP:

The RNC is populated either with PSFP or DCPS FP.
The mixity of PSFP and DCPS is not supported.
The PSFP/DCPS FP handles the userPlane traffic and the controlPlane traffic (NBAP, RANAP, RNSAP,
ALCAP, SCCP, MTP3, SAAL-NNI, SCTP and Sigtran).
A PSFP/DCPS FP is composed of 6 PMC cards and one PDC.
A PMC-Role is assigned to each PMC. Six different PMC roles are specified: PMC-PC, PMC-RAB,
PMC-M, PMC-NI, PMC-TMU and PMC-OMU.
The PMC Role is driven by the the PMC position in the PSFP and the PSFP position in the shelf:
- The PMC-M are hosted by the DCPS FP cards in the first and the second slots,
- The PMC-OMU are hosted by the third and forth PSFP cards,
- The PMC-NI are hosted by the third and forth PSFP cards,
- There is one PMC-PC per PSFP card,
- There is one or two PMC-TMU per PSFP card. There are 14 PMC-TMU on a RNC composed of
12 DCPS FP and 12 PMC-TMU on a RNC composed of 10 PSFP. The PMC-TMU is in position 1
on each PSFP card. The PSFP cards with two PMC-TMU are located in slot 10 and 11 and the
second PMC-TMU is in PMC position 5,
- The PMC-RAB role is assigned to all the remaining PMC,
Beside:
- The active and standby CP are in slot 0 and 1 respectively
- The active and standby 16p/OC3 FP are located in slot 8 and 9 respectively.
- The active and standby 4pGE FP are located in slot 14 and 15 respectively.
3.4.1.2.1 THE PDC AND PMC-ROLE DESCRIPTION:

-
PDC:
Each PDC provides a management functions for that one DCPS FP card only.
Moreover the PDC is in charge of handling the SaalNNI and the Sctp.
The SaalNNI and SSTP traffic is distributed over all the PDC with exception of those running
PMC-NI.
Each PDC is configured with one external IP@ which is used as the RNC CP IP@ on the
IuPS interface.
PMC-OMU:
The OAM functionality is implemented on 2 PMC-OMU components located on different
PSFP cards.
The PMC-OMU handles also the CBS traffic (IuBC).
The sparing scheme is 1+1. The PMC-OMU switch produces no interruption of service except
in case of double fault scenarios.
PMC-M:
The PMC-M hosts the CID management and the Alcap for Iub Iur and IuCS interfaces.
The RNC is populated with two PMC-M components, working in 1+1 redundancy scheme.
Two PMC-M components reside on different PSFP cards.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 130/240
The PMC-M switch produces no interruption of existing calls except in case of double fault
scenarios. New calls cannot be initiated for approximately 5 seconds.
PMC-NI:
The M3UA and SCCP protocols are implemented on two PMC-NI components located on
different DCPS FP cards.
Moreover the PMC-NI handles the locationServices traffic (IuPC).
The RNC is populated with two PMC-NI components, working in 1+1 redundancy scheme.
The sparing scheme is 1+1. The PMC-NI switch produces no interruption of existing calls or
service except in double fault scenarios.
The PMC-NI is PSFP cards 2 and 3.
PMC-TMU:
The PMC-TMU is in charge of processing:
- The UMTS protocols: RANAP, RNSAP, and NBAP,
- The UMTS heartBeat on the Iub,
- The SCTP protocol on the Iub.
Moreover PMC-TMU supports RRM, RRC, and aal2Link CAC.
Up to 14 PMC-TMU components in the ATM RNC and IP RNC, up to 12 PMC-TMU in the
Hybrid RNC are spread over all the DCPS FP.
The sparing scheme is N+1 if 7 or fewer PSFP and otherwise N+2 spared.
If a PMC-TMU fails, the control planes for the NodeB and cells managed by that TMU are
automatically taken over by one of the spare PMC-TMU within 30 seconds but individual
Radio Links are lost. Individual calls are managed by all the PMC-TMU in load sharing mode.
If a PMC-TMU fails the calls on that PMC-TMU are lost.
PMC-RAB:
The UMTS user plane is handled in up to 40 PMC-RABs within an ATM and IP RNC, in up
to 32 PMC-RABs within a Hybrid RNC spread over all the PSFP in load sharing mode.
Cell common channel user plane functionality is spared so if one PMC-RAB fails its cell
common channel user plane load is taken over by up to 5 other PMC-RAB on other DCPS FP
cards with no loss of common channel service.
The RTP protocol (IuCS over IP) is implemented within the PMC-RAB.
Individual call user planes are managed by all the PMC-RAB in load sharing mode.
If a PMC-RAB fails the calls on that PMC-RAB are lost.
Each PMC-RAB is configured with one external IP address used as the RNC IuPS UP IP@.
PMC-PC:
Up to 12 PMC-PC within an IP RNC and up to 10 PMC-PC within an Hybrid RNC
PMC-PC sparing scheme: N+1.
RNC Iub UP IP Interface, PMC-PC function:
The PMC-PC is the IP route point of termination.
One and up to 3 external IP@ are assigned to each of the N PMC-PC. No IP@
against the redundant PMC-PC.
The PMC-PC IP@ policyAssignment is: movable.
The PMC-PC IP@ is used as the RNC Iub UP IP@.
3.4.1.2.2 RNC PSFP/DCPS FP COMPOSITION:

Two cases are taken into consideration: native IP RNC and Hybrid RNC.
A Hybrid RNC is populated with both 16pOC3 FP and 4pGE FP interface card whereas the IP RNC is
populated with only the 4pGE FP interface card.
Case of native IP RNC:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 131/240
The native IP RNC is populated with two 4pGE FP and up 12 PSFP/DCPS FP.
Then up to 12 PMC-PC/NAT, 14 PMC-TMU, 10 PDC-SCTP/SaalNNI, 40 PMC-RAB.
The PDC-SCTP handles SCTP.
RNC
0&1
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
DCPS
Pdc
Pdc
SCTP
SCTP
Pdc
Pdc
SCTP
SCTP
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
SCTP
SCTP
Pdc
Pdc
SCTP
SCTP
Pdc
Pdc
SCTP
SCTP
Pdc
Pdc
SCTP
SCTP
Pdc
Pdc
SCTP
SCTP
Pdc
Pdc
SCTP
SCTP
Pdc
Pdc
SCTP
SCTP
Pdc
Pdc
SCTP
SCTP
RAB
RAB
RAB
RAB
OMU
OMU
OMU
OMU
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
TMU
TMU
TMU
TMU
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
PMC-M
PMC-M PMC-M
PMC-M
10
11
12
13
14&15
4pGE FP
4pGE FP
CP3
CP3
DCPS
DCPS
5
0
3
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
NI
NI
NI
NI
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT
PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT
TEG
Figure 3-55 Native IP RNC DCPS FP composition
Case of hybrid RNC:

Since 4 RNC slots are consumed by the interface card, the RNC hardware composition
becomes:
- Up to 10 DCPS FP,
- Up to 10 PMC-PC,
- Up to PMC-TMU,
- Up to 8 PDC-SCTP/SaalNNI, the PDC handles both SCTP and SaalNNI.
- Up to 32 PMC-RAB.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 132/240
RNC
2
0&1
10
8&9
DCPS
DCPS 00 DCPS
DCPS 11 DCPS
DCPS 22 DCPS
DCPS 33 DCPS
DCPS 44 DCPS
DCPS 55
11
12
13
14 & 15
DCPS
DCPS 66 DCPS
DCPS 77 DCPS
DCPS 88 DCPS
DCPS 99
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
Pdc
RAB
RAB
RAB
RAB
OMU
OMU
OMU
OMU
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
TMU
TMU
TMU
TMU
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
NI
NI
NI
NI
RAB
RAB
RAB
RAB
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
PC/NAT
PC/NAT PC/NAT
PC/NAT
PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT
AP:
5
4pGE FP
4pGE FP
PMC-M
PMC-M PMC-M
PMC-M
16pOC3 FP
16pOC3 FP
CP3
CP3
Pdc
Pdc
PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT PC/NAT
PC/NAT
0
3
2
1
4
TEG
Figure 3-56, Hybrid RNC DCPS FP composition
3.4.2
IP HOSTS UTRAN
MGC
MGC
IP
IP RNC
RNC
Iub, Iur, IuCS
CP
CP IP@
IP@
IuPS
PDC
Sctp
PDC
Sctp
PDC
Sctp
PDC
Sctp
PDC
Sctp
PDC
Sctp
PDC
Sctp
PDC
Sctp
CP
IP@
CP
IP@
CP
IP@
CP
IP@
CP
IP@
CP
IP@
CP
IP@
CP
IP@
MGw
MGw
UP
UP IP@
IP@
RNC
RNC
TMU
12:2
RAB
TMU
RAB
TMU
RAB
TMU
RAB
TMU
RAB
TMU
RAB
Iub
CP
IP@
IuPS
UP
IP@
Iub
CP
IP@
IuPS
UP
IP@
Iub
CP
IP@
IuPS
UP
IP@
Iub
CP
IP@
IuPS
Iub
IuPS
UP
IP@
Iub CP
CP IP@
IP@
IuPSUP
UPIP@
IP@
OMU
1:1
OMU1:1
OMU
NI
OMU
NI
NI
NI
Iub
CP
IP@
IubCP
CPIP@
IP@
Iub
LS
IP@
Iub
CP
IP@
LS
LS
IP@
LSIP@
IP@
CP
CP IP@
IP@
UP
UP IP@
IP@
NodeB
NodeB
PC/NAT
N:1
PC/NAT
PC/NAT
PC/NAT
PC/NAT
PC/NAT
UP
IP@
UPIP@
IP@
UP
UP
IP@
UP
UP IP@
IP@
telecom
telecom
IP@
IP@
OMU
1:1
OMU
OMU
OMU
CBS
IP@
CBS
CBS
IP@
CBSIP@
IP@
SGSN
SGSN
CP
CP IP@
IP@
UP
UP IP@
IP@
LS
LS IP@
IP@
Cbs
Cbs IP@
IP@
oam
oam IP@
IP@
TEG
Figure 3-57, Utran IP hosts
-
Iub, Iur and IuCS UP IP traffic terminate on the RNC PC/NAT,

- The IuCS userPlane connection terminates on the RNC within the PMC-PC/NAT
assigned to the specific RTP session. The IuCS UP traffic from a given MSC is
distributed across all the PMC-PC/NAT configured on the RNC for IuCS userPlane
traffic.
- One PMC-PC/NAT is assigned per neighbour RNC to terminate its IP traffic.
Iub CP terminates on the TMU and OMU (for the Attach message).
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 133/240
Iur, IuCS and IuPS CP terminate on the PDC-SCTP and internally forwarded to the PMCNI.
- IuPS UP terminates on the PMC-RAB.
- the RNC9370 handle the received IP packets with Option field included. The RNC reads
and processes the Option field. Nevertheless the handling of the IP packet Option
field dramatically reduces the performance, therefore:
Rule: IuTEG_IP Host_1
It is recommended to avoid setting the Option field within the IP packets exchanged over
the utran.
3.4.3
IP COMPONENTS
Native IP Iub:
On the RNC side, each nodeB is identified on the RNC side by an IubIf instance (see 5.4.1). The nodeB
userPlane over IP interface is identified by an ipIf instance. An ipIf is composed of one or several
bwPool(s). Within each bwPool, 1 and up to 4 qos streams are configured:
iubIf 1
userPlane
ipLink
SignalingBearer
ipIf i
cacm
BwPool/x
linkedTo transportMap
linkedTo CM
PLMN Mcc & Mnc (utranSharing)
qosnBwReservation
Qos0 IP Flow:
DL & UL, CIR & PIR (kb/s)
Qos1 IP Flow:
Qos2 IP Flow:
Qos3 IP Flow:
BwPool/y
Qos3 IP Flow:
TEG
Figure 3-58 nativeIP RNC Components
Hybrid Iub:
On the RNC side, each nodeB is identified on the RNC side by an IubIf instance (see 5.4.1). The nodeB
userPlane over IP interface is identified by an ipIf instance and the nodeB over atm interface is identified
by an aal2if instance (see 3.3.13.1 and 5.4.1):
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 134/240
iubIf 1
SignalingBearer
aal2If i
cacm
userPlane:
BwPool/x
aal2LinkToAal2if: aal2If i
linkedTo TMap
linkedTo CM
PLMN Mcc & Mnc
qosnBwRes
ipLink
ipIf i
cacm
BwPool/y
linkedTo TMap
linkedTo CM
PLMN Mcc & Mnc
qosnBwRes
Qos3 IP Flow:
UL/DL CIR (kb/s)
UL/DL PIR (kb/s)
qos 0
path
path
qos 1
path
path
qos 2
path
path
qos 3
path
path
BwPool/y
qos 3
path
path
TEG
Figure 3-59 hybrid RNC components
3.4.3.1 IPIF:
The IpIf component identifies the peer UMTS node ip interface, e.g.: NodeB ip interface.
On the Iub interface, the IpIf is linked to the IubIf / Uplane identifying the nodeB.
The NodeB IP@ is dynamically assigned to the ipIf component.
The RNC may be connected to up to 2400 nodeB each having its own IP interface.
Rule: IubTEG_RNC IP Components_1
The ipIf component instance must be unique within the RNC.
The ipIf component instance range: [1, 2400] is reserved for the Iub interface
The cacm parameter is configured against each IpIf component and applies to all the bwPools under the
ipIf instance.
3.4.3.2 BANDWIDTHPOOL:
The bandwidthPool concept has been specified within the RNC to distinguish the nodeB aal2Paths
configured over different NodeB Transport media, e.g.:
- The NodeB paths configured over two different IMA linkGroups are grouped under two different
bwPools,
- The NodeB paths configured over different E1 (mode xPcm) are grouped under different bwPools,
- The NodeB paths configured over an IMA linkGroups and the NodeB paths configured over E1
(mix of xPcm and IMA mode) are isolated into different bwPools.
The bandwidthPool concept has been specified for the atm iub, it has been extended to takes into
consideration:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 135/240
The nodeB ip interface:

- On the hybrid RNC side, the bandwidth reserved for a nodeB ip interface and the bandwidth
reserved for a nodeB atm interface are isolated into two different bandwidthPools.
- On the nativeIP RNC, the nodeB ip interface bandwidth is identified by one bwPool on the
RNC side.
The utranSharing: The traffic from the different PLMN sharing the utran may be as an option
isolated into different bandwidthPools.
Asymmetrical traffic.
One or several bwPools is/are configured under an ipIf component:

At least one bwPool must be configured under an ipIf component. The bwPool is a mandatory
component of the ipIf.
Up to 16 bwPools may be configured under an ipIf component.
Each ipIf/bwPool is linked to a transportMap instance and a congestionManagement instance for
regulating the downlink traffic.
Remark: The congestionManagement component can not be linked to the ipIf.
In the context of hybrid Iub, only primaryForTrafficType bandwidthPool may be configured under an ipIf
component.
Definition:
- TrafficType: RNC classification of the umts traffic based on the: trafficClass and the RbSetQos
information.
Different types of bandwidthPool:
- primaryForTrafficType bandwidthPool:
The primaryForTrafficType bandwidthPool is supported only on the Iub interface and may be
specified for both the atm and the ip interfaces.
A limited range of UMTS trafficTypes is assigned to such a bandwidthPool: only the Hspa I/B
traffic can be handled over a primaryForTrafficType bwPool.
Within an IP primaryForTrafficType bwPool, only one qos3 ipFlow is supported. The
CM/backPressure applies to all the qos3 ipFlow streams.
The bwPool associated to the Iub IP interface must be set with preference=
primaryForTrafficType.
- The primaryForTrafficType is available only on the iub interface (interfaceType=Iub).
- Only for HSPA interactive and background traffic may be handle on the primaryForTrafficType
bandwidthPool whatever atm or ip interface.
- The hybrid RNC Iub IP interface must be associated to a primaryForTrafficType bwPool.
- Only one qos3 stream is supported over an IP primaryForTrafficType bwPool.
-
sharedForAllTrafficTypes bandwidthPool:
A sharedForAllTrafficTypes bandwidthPool can be specified for:
- Atm interface on the Hybrid RNC and atm RNC, and
- Ip interface on the ip RNC.
A wide range of UMTS trafficTypes selects such a bandwidthPool.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 136/240
Within a sharedForAllTrafficTypes bwPool, the CM/backPressure applies to all the qos

streams with exception of the qos0 stream.
- The R99 and Hspa streaming traffic is handle only on the sharedForAllTrafficTypes bandwidth
pool.
- As an option the Hspa I/B traffic is handle on the sharedForAllTrafficTypes bandwidth pool.
-
PLMN common bandwidthPool versus PLMN specific bandwidthPool:

In the context of utranSharing, a bandwidthPool may be either shared by all the PLMN sharing
the utran or dedicated to one PLMN.
Each bwPool is linked to one transportMap, see 3.2.2. Within the transportMap is specified the bwPool
properties:
- TransportMap/Preference specifies the bwPool type either sharedForAllTrafficTypes or
primaryForTrafficType,
- Transportmap/transportServiceEntry specifies the trafficTypes assigned to the bandwidthPool.
Each bwPool must be associated to a transportMap instance with the appropriated interfaceType.
Exemple of one atm sharedForAllTrafficTypes bwPool and one ip primaryForTrafficType bwPool
RNCIN
RNCIN / IubIf
aal2If i
TransportMap i
interfaceType: Iub
BwPool/x
=> qos0
=> qos1
=> qos2

=> qos3
qos0
path
qos1
path
qos2
path
qos3
path
TransportMap j
ipIf i
interfaceType: Iub
BwPool/y
ipFlow/i
qos 3
TEG
Figure 3-60, NodeB with one atm bwPools and one ip bwPool (hybrid case)
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 137/240
According to the iub topology, different bwPool strategies may be chosen:
Topology
bwPool/Preference
Transport
Comments
nativeIP
IP
One sharedForTrafficType bwPool associated to the nodeB Ethernet link.
Atm
Ip
N * sharedForTrafficTypes
Atm
One sharedForTrafficType bwPool per xPcm E1.
Atm
One primaryForTrafficType bwPool associated to the nodeB IMA link.
Atm
One sharedForTrafficType bwPool associated to one nodeB IMA link.
Atm
One primaryForTrafficType bwPool associated to one nodeB IMA link.
Atm
One sharedForTrafficType bwPool associated to the nodeB IMA link.
One sharedForTrafficType bwPool associated to the nodeB atm link.
Hybrid Iub
One primaryForTrafficType bwPool associated to the nodeB Ethernet link.
N*E1+IMA
2 IMA
1 IMA
UtranSharing:
Per definition a PLMN Common bwPool is a bwPool shared by all the PLMN sharing the Utran
whereas a PLMN specific bwPool is a bwPool dedicated to one PLMN sharing the Utran.
A PLMN Common bwPool and a PLMN specific bwPool may be either primaryForTrafficType or
sharedForAllTrafficTypes bwPool.
On the iub interface may be configured a mix of PLMN Common bwPool and a PLMN specific
bwPool.
Per PLMN sharing the utran, may be configured one or several bwPool for atm, ip or mixed of atm and
ip interfaces.
For the case of PLMN specific bwPool, the bwPool component must be configured with the
corresponding PLMNId.
For the case of PLMN common bwPool, the bwPool component must be configured with the
PLMNId set to Zero.
Case of RNC configured with both PLMN common bwPool and PLMN specific bwPool for a
specific nodeB, the RNC selects first the resources from the PLMN specific bwPool, if exhausted
selects the resources from the PLMN common bwPool.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 138/240
qos0 Paths
qos1 Paths
qos2 Paths
qos3 Paths
atmSwitch
qos0 Paths
qos1 Paths
qos2 Paths
qos3 Paths
PLMN common bwPool bwPool3
RNC
NodeB
qos0 Paths
qos1 Paths
qos2 Paths
qos3 Paths
IMA 3 E1
IP router
FE
IubIf i
aal2If i
ipIf i
TEG
Figure 3-61, bwpool in the utranSharing 2 PLMN context, exemple of Hybrid Iub
Asymmetrical traffic for Hybrid Iub:

To handle separately hsdpa and Hsupa flows, two different bandwidthPools must be specified linked to
two different transportMaps:
- The hsdpa is handle by a primaryForTrafficType bwPool linked to a transportMap including a
transportServiceEntry set with ulDlPreference: dlPref,
- The hsupa is handle by a SharedForTrafficTypes bwPool linked to a transportMap including a
transportServiceEntry set with ulDlPreference: ulDlPref.
Rule: IubTEG_RNC aal2 Component
The asymmetrical traffic handling applies only to:
- the hspa I/B traffic,
- the Iub interface,
- both the atm and the ip interfaces.
Example:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 139/240
RNCIN
RNCIN / IubIf
aal2If i
TransportMap i
interfaceType: Iub
BwPool/x
qosx
path
tse:
tse: [TC=interactive, RbSetQos=2, ulDlPreference = ulPref ] => qos3
tse: [TC=backGround, RbSetQos=2, ulDlPreference = ulPref] => qos3
qos3
path
TransportMap j
ipIf i
interfaceType: Iub
BwPool/y
tse: [TC=interactive, RbSetQos=2, ulDlPreference = dlPref] => qosx
ipFlow/i
tse: [TC=backGround, RbSetQos=2, ulDlPreference = dlPref] => qosx
qos x
TEG
Figure 3-62 Asymmetrical bwPools
Robustness:
The robustness mechanism applies to the asymmetrical traffic: Hsdpa or Hsupa, identified by the
received radioBearerType UMTS EI
Assuming the configuration indicated in the Figure 3-62 Asymmetrical bwPools:
In normal condition, the admissionControl assigns the hsdpa traffic to the bwPool/y.
In case of bwPool/y bandwidth exhaustion, the admissionControl assigns the hsdpa traffic
to the bwPool/x.
On call establishment, the admissionControl identifies the different TransportMap(s) including tse
satisfying the call qos characteristics.
If several TransportMaps are identified, the ulDlPreference parameter is taken into consideration for
determing the most preferred TM:
- A tse with ulDlPreference = ulPref or dlPref is more preferred than a tse with
ulDlPreference=ulDlPref.
- A tse with ulDlPreference = ulDlPref is more preferred than a tse with
ulDlPreference=noPref.
If not enough available bandwidth in the bwPool linked to the most preferred transportMap, the
admissionControl assigns the call to the bwPool linked to the less preferred transportMap.
3.4.3.3 IPFLOW:
One ipIf/bwPool is populated with one and up to 4 ipFlow components, each configured for different qos
streams.
Case of hybrid RNC, only one qos stream is supported under an ipIf/bwPool; the ipIf/bwPool is populated
with one single qos3 ipFlow.
Each ipFlow component is configured with the expected traffic through the attributes:
- downLinkCommitedRate (kb/s)
- upLinkCommitedRate (kb/s)
- downLinkPeakRate (kb/s)
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 140/240
- upLinkPeakRate (kb/s)
The per ipFlow rates are involved in the downlink congestionManagement mechanism and also in the
downlink and uplink transport IP admissionControl.
iubIf 1
userPlane
ipLink
ipIf i
SignalingBearer
cacm
BwPool/x
linkedTo transportMap
linkedTo CM
PLMN Mcc & Mnc (utranSharing)
qosnBwReservation
qos0 IP Flow:
qos1 IP Flow:
qos2 IP Flow:
qos3 IP Flow:
BwPool/y
qos3 IP Flow:
TEG
Figure 3-63, RNC IP components
3.4.4
IP HOSTS UTRAN
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 141/240
MGw
MGw
IP
IP RNC
RNC
Iub, Iur, IuCS
CP
CP IP@
IP@
IuPS
PDC
Sctp
PDC
Sctp
PDC
Sctp
PDC
Sctp
PDC
Sctp
PDC
Sctp
PDC
Sctp
PDC Sctp
CP
IP@
CP
IP@
CP
IP@
CP
IP@
CP
IP@
CP
IP@
CP
IP@
CP
IP@
UP
UP IP@
IP@
RNC
RNC
TMU
12:2
RAB
TMU
RAB
TMU
RAB
TMU
RAB
TMU
RAB
TMU
RAB
Iub
CP
IP@
IuPS
UP
IP@
Iub
CP
IP@
IuPS
UP
IP@
Iub
CP
IP@
IuPS
UP
IP@
Iub
CP
IP@
IuPS
Iub
IuPS
UP
IP@
Iub CP
CP IP@
IP@
IuPSUP
UPIP@
IP@
OMU
1:1
OMU1:1
OMU
NI
OMU
NI
NI
NI
Iub
CP
IP@
IubCP
CPIP@
IP@
Iub
LS
IP@
Iub
CP
IP@
LS
LS
IP@
LSIP@
IP@
CP
CP IP@
IP@
UP
UP IP@
IP@
NodeB
NodeB
PC/NAT
N:1
PC/NAT
PC/NAT
PC/NAT
PC/NAT
PC/NAT
UP
IP@
UPIP@
IP@
UP
UP
IP@
UP
UP IP@
IP@
telecom
telecom
IP@
IP@
OMU
1:1
OMU
OMU
OMU
CBS
IP@
CBS
CBS
IP@
CBSIP@
IP@
SGSN
SGSN
CP
CP IP@
IP@
UP
UP IP@
IP@
LS
LS IP@
IP@
Cbs
Cbs IP@
IP@
oam
oam IP@
IP@
TEG
Figure 3-64, Utran IP hosts
Iub, Iur and IuCS UP IP traffic terminate on the RNC PC/NAT. One PMC-PC/NAT
handles the whole NodeB IP traffic.
Iub CP terminates on the TMU and OMU (for the Attach_UDP message).
On nodeB side, if no telecom IP@ configured, the telecom traffic terminates on the host
identified by oam IP@.
3.4.5
UDP PORT
A PMC-PC/NAT supports 16 000 UDP ports per PMC-PC/NAT IP@ (16 000 source UDP ports+ 16 000
destination UDP ports per IP@).
A PMC-PC/NAT configured with 3 IP@ (1 IP@ for Iub UP, 1 IP@ for Iur UP and 1 IP@ for
IuCS UP) supports 3*16000 UDP ports.
The RNC supports the UDP Port range: [49152, 65535] for the different applications:
- UserPlane:
One source and one destination UDP ports are assigned per UE connection from the
RNC UDP Port range.
- Prop Attach_UDP_message: (applies only to native IP Iub)
One UDP port from the RNC UDP Port range is allocated to the proprietary
Attach_UDP.
Parameter: iubAttachUdpPortNumber
Rule: IubTEG_RNC-IP_UDP_1
The same UDP port values must be reserved on RNC and nodeB side for the purpose
of the proprietary attach UDP message. (see 3.6.6)
The allocated UDP port is used as source & destination UDP port in the UDP frame
carrying the Proprietary Attach_UDP message sent by the nodeB to the RNC.
Proprietary umts heartBeat: (applies only to the hybrid Iub, not to the IP Iub)
One UDP port from the RNC UDP Port range is configured for the umts prop
heartBeat.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 142/240
3.4.6
LOCALMEDIA
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.
TrafficType:
TrafficType values:
- TrafficType = iubCplane:
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.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 143/240
Rule: IubTEG_localMedia_1
The two LM interfaces: [uPlane trafficType; IuB interfaceType] and IubUplaneInternal
trafficType must be configured over the same VR.
InterfaceType:
InterfaceType values: Iub, IuCS, IuPS, Iur and none.
The interfaceType attribute specifies which utran interface traffic is handle on the LM
interface.
The interfaceType attribute must be configured against the LM interfaces set with uPlane and
ss7Cplane trafficTypes.
The interfaceType attribute is not configured for traffic types other than: uPlane, ss7Cplane.
Remark: The interfaceType value none is not allowed on LM interfaces set with
uPlane and ss7Cplane trafficTypes.
The interfaceType is configured per LM interface with either one single utran interface or a
combination of several utran interfaces:
tT
uPlane
interfaceType:
iub
iuCS
iur
iub+iuCS
iuCS+iur
iub+iur
iub+iuCS+iur
Remark: The IuPS UP and other utran UP traffic flows can not share the same LM
interface since one terminates on the PMC-RAB whereas others terminates on the
PMC-PC/Nat.
tT
interfaceType:
ss7CPlane
iuCS
Iur
IuPS
iuCS+iur
iur+iuPS
iuCS+iuPS
iuCS+iur+iuPS
Remark: The Iub CP and other Utran CP traffic can not share the same LM interface
since one terminates on the PMC-TMU whereas the others terminate on the PDC.
The different [trafficType, interfaceType] combination values must be unique among the
localMedia.
Migration from UA6 to UA7:
The table below indicates the evolution of the LocalMedia interfaces from the UA6 to UA7:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 144/240
UA6
UA7
VR
LM if
LM tT
LM tT
LM iT
Oam
=>
Oam
na
Rnc
=>
uPlane
iuPS
=>
Rnc
na
ss7CP
=>
ss7CP
iuPS
internal
=>
Internal
na
LS
=>
Ls
na
CBS
=>
Cbs
na
iubUP
=>
uPlane
Iub
IubUPint
=>
iubUPInt
na
IubCplane
na
uPlane
Iur, IuCS
Notes:
- The UA6 rnc trafficType has been replaced by:
- The uPlane trafficType with iuPS interfaceType for handling the IuPS external
traffic,
- The rnc trafficType for handling the RNC internal traffic.
- The localMedia interfaces with rnc and internalTraffic trafficType are assigned to the
internal VR PP.
- The UA6 iubUPlane trafficType has been replaced by [uPlane trafficType; Iub
interfaceType].
Furthermore a localMedia interface is linked to a VR protocolPort that has an IpLogicalInterface
configured.
An IP subnet is configured against the VR PP linked to a localMedia interface.
The IP@ from the IP subnet are allocated to the PMC reachable from the localMedia interface according
to one of the 3 IP address assignment policies:
fixed IP@ assignment policy,
Movable IP@ assignment policy,
Configurable IP@ assignment policy,

They are described in the AddressingTEG [R4].
3.4.7
VIRTUAL ROUTER RNC COMPOSITION

Five RNC VR formations are suggested, two of them are iub under interest:
- VR formation1:
- 1 telecom VR handling IP traffic from all utran interfaces: IuPS, IuCS, Iur and Iub
(native + Hybrid).
VR formation2:
- 1 telecom VR dedicated to Iub (native + Hybrid),
- 1 telecom VR handling IP traffic from IuPS, IuCS, Iur.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 145/240
RNC,
RNC, VR
VR Formation
Formation 11
Iux
Iux VR
VR
oam
oam VR
VR 00 LS
cbs VR
VR 44
LS VR
VR 33 cbs
4pGE
Hybrid &
int
int VR
VR 22
4pGE
RNC,
RNC, VR
VR Formation
Formation 22
native IP Iub
Iub
Iub VR
VR
Iu+Iur
Iu+Iur VR
VR
oam
oam VR
VR 00 LS
LS VR
VR 33 cbs
cbs VR
VR 44
4pGE
Hybrid &
int
int VR
VR 22
4pGE
RNC,
RNC, VR
VR Formation
Formation 33
native IP Iub
Iub
Iub VR
VR
Iucs+Iur
Iucs+Iur VR
VR
IuPS
IuPS VR
VR
oam
oam VR
VR 00 LS
cbs VR
VR 44
LS VR
VR 33 cbs
4pGE
Hybrid &
int
int VR
VR 22
4pGE
RNC,
RNC, VR
VR Formation
Formation 44
native IP Iub
Iub
Iub VR
VR
Iur
Iur VR
VR
IuCS
IuCS VR
VR
IuPS
IuPS VR
VR
oam
LS VR
VR 33 cbs
oam VR
VR 00 LS
cbs VR
VR 44
4pGE
Hybrid &
int
int VR
VR 22
4pGE
RNC,
RNC, VR
VR Formation
Formation 55
native IP Iub
Iub
Iub VR
VR
CP+UP
Iur
Iur VR
VR Iur
Iur VR
VR IuCS
IuCS VR
VR IuCS
IuCS VR
VR IuPS
IuPS VR
VR IuPS
IuPS VR
VR
UP
CP
UP
CP
4pGE
UP
oam
oam VR
VR 00 LS
LS VR
VR 33 cbs
cbs VR
VR 44
int
int VR
VR 22
CP
TEG
4pGE
TEG
Figure 3-65, RNC VR Formations
Both the CP and UP Iub traffic are routed through one single VR :
Rule: IubTEG_VR_1
The Iub CP and UP traffic must be routed by one common RNC VR.
Beside 1 VR dedicated to oam, 1 VR dedicated to LS, 1 VR dedicated to CBS and 1 VR dedicated to
RNC internal traffic.
The following figures represent the localMedia interfaces for the different VR formations for native and
hybrid iub:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 146/240
IP
IP RNC
RNC
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
NI
00
NI
NI1
NI1
PDC0
PDC0
PDC1
PDC1
PDC2
PDC2
PDC3
PDC3
PDC9
PDC9
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
PC11
PC11
PC0
PC0
M
00 11
MM
M
TMU0
TMU0
TMU13
TMU13
OMU0
OMU0
TMU0
TMU0
TMU13
OMU1
TMU13 OMU1
PP
PP
PP
PP
PP
Iub+Iu+Iur VR
PP
PP
Int VR
PP
PP
tT: oam
tT: CBS
tT: LS
tT: internal
tT: rnc
iT: IuPS
tT: uPlane
tT: ss7CP
iT: IuPS+IuCS+Iur
iT: Iub+IuCS+Iur
tT: uPlane
tT: IubCplane
tT: IubUplaneInt
localMedia
localMedia
NodeB
NodeB
PP
LS VR CBS VR oam VR
PP
PP
PP
VLAN
VLAN
VLAN
PP
VLAN
RNC
RNC
Iub+Iu+Iur
MGw
MGw
GigE
xx x
GigE
GigE
GigE
x
IP
IP
SGSN
SGSN
TEG
Figure 3-66, VR formation 1
Note: The CBS and LS over IP is currently not supported.
Either each VR PP is linked to different GE ports then either Lan or Vlan are used or several VR PP are
linked to one single GE port then only vlan component can be configured.
Rule: IubTEG_VR_2
As long as several PP are linked to one GE port, one vlan per protocol port must be configured.
The hybrid RNC provides both Atm and IP legs to the nodeB. On the ATM leg are transported R99
userPlane and controlPlane traffic whereas HSPA I/B traffic is transported over the IP leg. As an option,
the same VR is used to forward Iub hspa I/B and other Iux traffic (a.k.a.: UA6 consolidated VR):
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 147/240
IP
IP RNC
RNC
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
Iu
bR
99
CP UP
NI
00
NI
NI1
NI1
Iub
PDC0
PDC0
PDC1
PDC1
PDC2
PDC2
PDC3
PDC3
PDC9
PDC9
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
M
00 11
MM
M
TMU0
TMU0
TMU13
TMU13
OMU0
OMU0
TMU0
TMU0
TMU13
OMU1
TMU13 OMU1
PC11
PC11
PC0
PC0
PP
PP
PP
PP
PP
PP
PP
Iub+Iu+Iur VR
LS VR CBS VR
PP
PP
PP
VLAN
VLANc
VLAN
tT: oam
tT: internal
tT: rnc
iT: IuPS
tT: uPlane
iT: IuPS+IuCS+Iur
tT: ss7CP
iT: Iub+IuCS+Iur
tT: uPlane
tT: LS
tT: CBS
tT: IubUplaneInt
localMedia
localMedia
PP
SGSN
SGSN
PP
Int VR
oam VR
PP
RNC
RNC
VLAN
Iub+Iu+Iur
GigE
xx x
GigE
GigE
GigE
x
MGw
MGw
IP
IP
16pOC3
16pOC3
16pOC3
16pOC3
NodeB
NodeB
ATM
ATM
TEG
Figure 3-67, VR formation1 for Hybrid Iub.
The VR formation 2 is an evolution of the VR formation1 after adding a dedicated Iub VR, the Iub VR handles
Iub both userPlane and controlPlane traffic:
IP
IP RNC
RNC
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
NI
00
NI
NI1
NI1
PDC0
PDC0
PDC1
PDC1
PDC2
PDC2
PDC3
PDC3
PDC9
PDC9
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
M
00 11
MM
M
TMU0
TMU0
TMU13
TMU13
OMU0
OMU0
TMU0
TMU0
TMU13
OMU1
TMU13 OMU1
PC11
PC11
PC0
PC0
PP
PP
Iub VR
PP
PP
PP
Iu+Iur VR
PP
PP
PP
Int VR
PP
PP
tT: oam
tT: CBS
tT: LS
tT: internal
tT: rnc
iT: IuPS
tT: uPlane
tT: ss7CP
iT: IuPS+IuCS+Iur
iT: IuCS+Iur
tT: uPlane
iT: Iub
tT: uPlane
tT: IubCplane
tT: IubUPInt
localMedia
localMedia
NodeB
NodeB
PP
LS VR CBS VR oam VR
PP
PP
PP
PP
VLAN
VLAN
VLAN
VLAN
PP
VLAN
RNC
RNC
Iub+Iu
+Iur
GigE
xx x
GigE
GigE
GigE
x
MGw
MGw
IP
IP
SGSN
SGSN
TEG
Figure 3-68, VR formation 2
Alternative1: One GE link shared by all Utran interfaces.
Alternative2: One GE link dedicated to Iub and one GE link dedicated to IuCS+IuPS+Iur.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 148/240
The hybrid RNC provides both Atm and IP legs to the nodeB. On the ATM leg are transported R99
userPlane and controlPlane traffic whereas HSPA I/B traffic is transported over the IP leg. As an option,
one VR is dedicated to the Iub Hspa I/B forwarding, another VR is in charge of the Iux forwarding
(a.k.a.: UA6 segmented VR):
RNC
RNC
inBand & outBand Oam supported.

Iub OAM, Sig, R99 UP and hspa streaming
are carried over atm.
TMU0
TMU0 RAB
RAB
TMU13
TMU13 RAB
RAB
RAB
RAB
M
M 00
M
M 11
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
OMU0
OMU0
OMU1
OMU1 PC0
PC0 PC9
PC9
nodeB (hybrid)
(hybrid)
nodeB
PP
intVR
Iub
IP
IP
PP
PP
Iub VR
R99 UP
CP
oam
tT: uPlane
iT: Iub
R99 traffic,
Signaling,
Oam
Hspa stream.
Hspa I/B (opt)
tT: iubUPint
Hspa I/B.
tT: rnc
LM
LM
PP
Oam VR
PP
PP
PP
(V)LAN
MPE
MPE
GigE
GigE xx
GigE
GigE xx
16pOC3
16pOC3
16pOC3
16pOC3
ATM
ATM
TEG
Figure 3-69 VR formation2 for hybrid Iub
3.4.8
PDR
Reference: [R161]
The Protected default route (PDR) is a layer3 sparing mechanism applying only to the IP default routes. It
guarantees a traffic disruption less than one second; this time includes the local failure detection and the
traffic diversion.
The PDR feature is supported for IP flows over the 4pGE FP.
Rule: IubTEG_PDR_1
The PDR is available only for IP route with nextHops over the 4pGE FP.
The PDR may be used for protection as long as:
- No routing protocol running on the RNC (Vr Ip Ospf ecmpStatus = disabled),
- The ECMP is deactivated (Vr Ip Static maxEcmpNextHops = 1)
Rule: IubTEG_PDR_2
When PDR is enabled, maxEcmpNextHops must be set to 1, Vr Ip Ospf ecmpStatus must be
disabled.
Only the VR default route (IP@=0.0.0.0, 0.0.0.0) can be used for the Protected Default Route.
Rule: IubTEG_PDR_3
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 149/240
If PDR is used, only the static default route is the protection route.
The VR default route acts as the protection default route since the protected attribute is set to yes (Vr Ip
Static Route protected).
Rule: IubTEG_PDR_4
For enabling the PDR, the RNC attribute Vr Ip Static Route protected must be set to yes against
the default route.
The RNC may be enable on up to 12 VR:
Rule: IubTEG_PDR_5
The RNC supports up to 12 VR with PDR enable.
The VR routing table is configured with the default route only.
Rule: IubTEG_PDR_6
It is not recommended to configure more specific routes when PDR active.
Remark: The ICMP heartbeat which is one trigger for PDR doesnt work on more specific IP route,
therefore PDR doesnt provide protection for more specific IP route when failure on a non adjacent layer2
segment.
The PDR provides protection against default route nextHop failure: On PDR morePreferred NH failure,
the IP traffic is diverted to the PDR lessPreferred NH.
For that several nextHops should be assigned to the default protected route.
RNC Iub VR routingTable:
VR /x
IP
Static
Route = 0.0.0.0, protected=yes
R
R 33
Y
IP@ 3-2
lan
Path 3
GE
PP3
Backhaul
Backhaul
NodeB
NodeB
VR
VR
NextHop = IP@ 2-2 /30,
= metric=1
PP1
IP@ 2-1
IP@ 2-2
lan
lan
lan
= metric=3
lan
Path 2
GE
GE
FP1
FP1
GE
R
R 11
Y
FP2
FP2
GE
SGSN
SGSN
= metric=2
IP@ 1-1
NextHop = IP@ 3-2 /30
R
R 22
Y
NextHop = IP@ 1-2 /30,
PP2
IP@ 3-1
NodeB
NodeB
RNC
RNC
IP@ 1-2
lan
Path 1
GE
TEG
Figure 3-70 PDR with 3 routes and 3 routers
Comments:
Under normal condition:
- VR PP1 metric=1 is the PDR morePreferred route,
- VR PP2 metric=2 and PP3 metric=3 are the PDR lessPreferred route,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 150/240
- The RNC forwards all the IP packets to router 1 through the NH1.
Under Path1 failure:
- The RNC forwards all the IP packets to the router 2 through NH2.
Under Path2 failure:
- The RNC forwards all the IP packets to the router 3 through NH3.
A protected static default route should be configured with several nextHops in such a way to be able to
divert the traffic to a PDR less preferred nextHop in case of failure of the PDR most preferred nextHop.
Whatever amount of nextHop(s) assigned to the protected default route, only one nextHop, the most
preferred, is active for forwarding the IP traffic. On failure of the more preferred nextHop, the IP traffic is
diverted on one of the less preferred nextHop(s).
Rule: IubTEG_PDR_7
Up to 4 nextHops may be assigned to a protected default route.
Each PDR nextHop belongs to different subnets as per the VR PP definition.
To provide maximum traffic protection, the different PDR nextHops should transmit over different paths
when available:
Rule: IubTEG_PDR_8
Each PDR nextHop should be configured over different Ethernet links from different 4pGE FP
and should be connected to different adjacent IP routers.
The duration of the failure detection and PDR IP traffic diversion from the failed nextHop to an active
nextHop is less than 1 second (with exception of the ICMP heartbeat trigger).
Preferred nextHop selection:
The paths configured under the default route can be assigned equal metrics; in this case the
first path that becomes available is selected to carry the traffic. Alternatively, the paths can be
assigned different metric, where the path with the lowest metric will carry traffic in a non
failure scenario.
PDR path recovery behavior, revertive mode:
- If all next hops have the same metric, the path selection under failure condition is nonrevertible. Meaning that when the failed path comes back to service the traffic will not be
reverted back to the original path.
- If different metric is assigned to the next hop, the path selection under failure condition is
revertible. This implies that if the path coming back to service after failure has a lower cost,
the traffic is reverted back to that path.
The WPS tools doesnt support the configuration of multiple PDR nextHops with the same metric,
as a consequence the non-revertive mode can not apply .
Triggers:
- Layer 1 failure (according to IEEE802.3),
LOS,
remote offline failure,
remote link failure,
autoNegotiation error.
- administrative locking of: GE port, VLAN, VR PP, IpPort (near and far End)
- The ICMP HeartBeat is a trigger for PDR, nevertheless this trigger doesnt guarantee a traffic
disruption less than 1 second.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 151/240
PDR/ARP:
In such a way to reduce the outage duration, the RNC may achieve the ARP operation for both
protected and unprotected routes present in the VR routing table before they are involved in the
traffic forwarding, at the RNC setup.
Such a behavior occurs when the RNC attribute Vr Ip preConfigFwdPath is set to enable.
Rule: IubTEG_PDR_9
The preConfigFwdPath attribute must be enabled for both protected and unprotected routes to
resolve ARP prior to route installation.
Ingress traffic handling when PDR:
The RNC VR handles the ingress IP traffic from both the morePreferred and the lessPreferred
path(s) whereas the RNC VR forwards the IP traffic on the PDR morePreferred path.
Two cases are taken into consideration:
1/ the ingress traffic is received on the PDR lessPreferred path whereas the egress
traffic is forwarded on the PDR morePreferred path:
Context: backbone diverting IP traffic on an alternative path.
This solution works.
2/ the ingress traffic is loadshared on PDR lessPreferred path and PDR morePreferred
path:
Without application protocol in charge of packet reordering, this solution presents risk
of mis-ordering.
3.4.9
ICMP HEARTBEAT
Reference: [R161]
As long as no IP routing protocol running on the RNC, the way to detect failure on the interface consists
in activating the ICMP heartbeat.
The ICMP heartbeat checks the continuity of the IP path between two adjacent IP nodes transparently
through the layer2 nodes. It allows the RNC to be aware about a failure occurring on a not-directlyconnected-to-RNC layer 2 interface:
ICMP Heartbeat, fault detection:

ICMP Echo request
RNC
RNC
ICMP Echo reply
Router
GE
GE
GE
GE
Eth
Eth
Bridge
Bridge
TEG
Remark: A robustness mechanism should be implemented in the routers, in such a way the routers are
able to divert the upLink traffic from one failed route to a backup route.
Rule: IubTEG_ICMP_1
The RNC supports the ICMP Heartbeat on the default route (0.0.0.0) only. Not supported on more
specific route.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 152/240
The ICMP Heartbeat is a trigger for RNC PDR:

Rule: IubTEG_ICMP_2
The ICMP heartbeat should be activated in the RNC.
Beside should be activated in the adjacent IP router if supported.
The ICMP HeartBeat is activated on the default IP route through the RNC attribute: VR Ip Static Route
heartbeat.
This attribute is taken into consideration by the RNC once the heartBeat timeout is set (RNC attribute: Vr
Ip Static heartbeatDeadInterval).
The minimum heartBeat deadInterval should be set in such a way to reduce the failure detection time:
Rule: IubTEG_ICMP_3
The ICMP heartbeat deadInterval must be set to 3 seconds.
The ICMP Heartbeat enabled on the default IP route is performed on all the nextHops involved in the
default route traffic forwarding.
ICMP heartBeat algorithm:
The ICMP echoRequest is sent every 1second on the nextHop(s) involved in the protected default
Route. Both the PDR preferred and less preferred routes are being monitored independently at the same
time.
An ICMP echoReply is expected within the 1 second timeout:
- If the ICMP echoReply is received within the 1 second timeout, the heartbeatState of the
nextHop is declared up.
- If no ICMP echoReply has been received within the 1 second timeout, the heartbeat
deadInterval timer is run.
While the heartbeat deadInterval timer is running, ICMP echoRequest is sent each
second and ICMP echoReply is expected within the 1 second timeout.
At the deadInterval timer expiration if no ICMP echoReply has been received then
the heartbeatState of the nextHop is declared down. The nextHop is considered
unreachable. The traffic initially forwarded on the unreacheable nextHop is diverted
to a PDR lessPreferred route (if PDR activated).
Once the heartbeat status is declared down, a single successful ICMP poll/response must be completed
before the heartbeat status of the next hop router is considered up again.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 153/240
RNC NH
IP router
NH up
ICMP EchoRequest
ICMP EchoReply
Periodicity = 1 s
ICMP EchoRequest
ICMP EchoReply
Periodicity = 1 s
1s
deadInterval = 3 s
ICMP EchoRequest
ICMP EchoReply
1s
ICMP EchoRequest
ICMP EchoReply
Failure detection time
ICMP EchoRequest
ICMP EchoReply
1s
NH down
ICMP EchoRequest
ICMP EchoReply
NH up
TEG
Figure 3-71 ICMP heartBeat algo
ICMP HeartBeat failure detection time:
ICMP HeartBeat failure detection time = 1s + deadInterval.
Taking into consideration the deadInterval (range: [3, 60 seconds] then the minimum ICMP
heatBeat failure detection time is 4 seconds.
Miscellaneous:
- TTL: The RNC inserts the ICMP hearbeat within an IP packet set with TTL=64,
- DSCP: The RNC marks the IP packet containing the ICMP hearbeat according to the attribute
value: Vr Dsd phbGeneralSource (phbG).
3.4.10 QOS
Reference: [R160]
The differentiedServices Qos model applies into the UTRAN network.
3.4.10.1
UMTS QOS INFORMATION
The Umts qos information taken into consideration by the RNC are:
- The TC (trafficClass): Conversational, Streaming, Interactive and Background,
- The ARP (AllocationPriorityPriority):
The ARP specifies the relative importance compared to other UMTS bearers for allocation
and retention of the UMTS bearers.
The ARP attribute is a subscription attribute which is not negotiated from the mobile
terminal.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 154/240
In situations where resources are scarce, the relevant network elements can use the ARP to
prioritize bearers with a high ARP value over bearers with a low ARP value when
performing admission control.
ARP range value: [1, 2, 3]
- The THP (TrafficHandlingPriority):
The THP specifies the relative importance for handling of all the SDU belonging to the radio
access bearer compared to the SDU of other bearers.
The THP applies only to the interactive trafficClass umts flows.
Within the interactive trafficClass, there is a definite need to differentiate between bearer
qualities. This is handled by using the THP attribute, to allow the RAN to schedule traffic
accordingly.
THP range value: [1, 2, 3], with THP=1 being the highest priority while THP= 3 being the
lowest priority.
Moreover the ALU RNC introduces one more qos information taken into consideration in the qos
mapping table:
- RbSetQos:
Traffic class
IUB interface
RbSetQos
R99
Conv
+cSRB+dSRB
R99 Streaming
R99 I/B
Hspa I/B+Streaming
Conversational
Common
Signaling
Streaming
Interactive
Background
Streaming
Interactive
Background
Since the Transport qos information are correctly mapped between each others, the final objective is to
mapped each different UMTS flows to a specific DSCP value in such a way each umts flow received the
expected qos treatment and is correctly marked.
The UMTS qos information are mapped to the Transport Qos information through the configurable
TransportMap RNC component.
3.4.10.2
DSCP VALUES
The list of the supported DSCP values is set per VR through DifferentiatedServicesDomain (dsd)
component.
Remark: Whatever IP over atm or IP over Ethernet utran interface, the differentiatedServicesDomain
must be configured at VR level.
DSD instance
multiService
DSCP
CSx, EF, AFxy, DE
classSelector
CSx
assuredForwarding
AFxy, CS6, DE
packetVoice
wirelessUmts

ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 155/240
Custom
CS6, DE
Notes: x is in the range [0 to 7] for the CS DSCP, [1 to 4] for the AF DSCP, and y in the
range [1 to 3]. The CS0 is equivalent to Default DSCP then removed from the text.
Only one differentiatedServicesDomain instance can be set per VR and applies to all the VR ports.
Even if the DSD component is an optional Router component, it must be set in the Umts context:
Rule: IubTEG_Hybrid-RNC_Qos_8
The suggested DSD instance: multiService
Beside the non user IP packet tagging is specified when setting the following attributes:
- Vr Dsd phbRoutingSource (phbR): set with the DSCP value applying to the IP routing
packets. Range value: [EF, AFxy, CSx, DE).
- Vr Dsd phbGeneralSource (phbG): set with the DSCP value applying to the non user and non
routing IP packets, e.g.: applying to the ICMP echo request/reply IP packets. Range value:
[EF, AFxy, CSx, DE).
The qos treatment applying to the IP packets depends on the DSCP and how each DSCP value is mapped
to the FP Qos parameters, see3.4.1.1.4.
3.4.11 ROUTING:
On the RNC, no IP routing protocol is activated, the IP routing tables are manually configured.
Rule: IubTEG_Hybrid-RNC_Routing_1
No Routing protocol is activated, Static routes are used.
3.4.12 SIGTRAN/SCTP
The NBAP uses the services from the SCTP.
SCTP endPoints:
On the RNC Iub side, each TMU is a SCTP endpoint. The RNC Iub is composed of up to 12 SCTP
endpoints (TMU sparing scheme N+P, up to 12+2).
The RNC TMU SCTP endPoint acts as the SCTP client. The NodeB acts as the SCTP server. Therefore
the RNC initiates the SCTP Association.
One RNC TMU supports up to 200 nodeB then up to 200 SCTP Associations (3.3.15.1).
A nodeB is composed of one single SCTP endPoint (3.6.6).
SCTP port:
The RNC computes its own SCTP port per nodeB (on reception of the proprietary Attach_UDP message).
The SCTP port is computed based on the TMU instance allocated to the nodeB and the nodeB identifier
(IubIf). The RNC assigns one single dedicated SCTP ports per nodeB.
SCTP Association & Streams:
One single SCTP Association per NodeB is established whatever nodeBType (iNodeB, oneNodeB,
picoNodeB).
Within the per nodeB SCTP association, one UL stream and one DL stream are assigned per controlPort:
- Case of iBTS: 7 UL/DL streams are reserved (whatever amount of CEM populated)
o Stream 0 assigned to the CP (mandatory),
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 156/240
o Streams 1 to 6 assigned to the CCP.

Case of picoNodeB: 2 UL/DL streams are reserved
o Stream 0 assigned to the CP,
o Stream 1 assigned to the CCP.
Case of oneBts: 1 UL/DL stream is reserved
o Stream 0 assigned to the SCP (one single SCP per oneBts).
SCTP Timers:
It s suggested to apply same SCTP Timers values as those configured on the Iu and Iur interfaces.
The objective of these timer values is that the PDR is invoked before SCTP is aware about an interface
failure.
RNC, Iux SCTP timers and parameters
Recommended values Default values
Rfc values
ackDelay
200 ms
200 ms
heartbeatInterval
3000 ms
3000 ms
30 000 ms
retransmissionTimeOutInitial
1000 ms
3000 ms
3000 ms
retransmissionTimeOutMax
3200 ms
10000 ms
60 000 ms
maxPathRtx
retransmissionTimeOutMin
500 ms
800 ms
Table 30, SCTP Iub timer values
1000 ms
SCTP QOS:
The DSCP is configured per nodeB:
Parameter: RNC/NodeB/ sctpParams / sctpDscp, defaultValue=AF41
SCTP HeartBeat:
The SCTP mechanism on the RNC Iub is identical to the one on the RNC Iu interface [R2].
Proprietary Attach_UDP:
The RNC must be configured with its own UDP port involved in the proprietary Attach_UDP procedure.
Parameter: IubAttachUdpPortNumber. Default: 65534
The RNC UDP port is used destination UDP port within the Attach_UDP message sent by the nodeB.
Remark: The UDP port assigned to the proprietary_Attach_UDP is different from the UDP port
assigned to the UMTS_Prorietary_heartBeat (hybrid Iub).
Rule: IubTEG_IP-RNC_SCTP_1
The same UDP port value must be configured in both:
- The RNC / IubAttachUdpPortNumber parameter and
- The nodeB / AttachUdpPortNumber parameter.
SCTP Association establishment:
The SCTP Association establishment is initiated by the RNC on reception of the proprietary Attach_UDP
message received from the nodeB.
By sending the proprietary Attach_UDP message, the nodeB informs the RNC about its identity (IubIf),
IP@ and its own SCTP port.
On reception of the proprietary Attach_UDP message, the RNC:
Computes its own SCTP port dedicated to the nodeB. The SCTP port remains unchanged as
long as no modification of the iubIf value assigned to the nodeB.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 157/240
Assign a PMC-TMU to the nodeB (the less loaded TMU is selected).

Then the RNC initiates the SCTP Association by sending to the nodeB a SCTP_Init message.
The SCTP INIT message includes: RNC TMU IP@, RNC SCTP port, maxInStream, and
maxOutStream
NodeB
NodeB
RNC
RNC OMU
OMU
RNC
RNC TMU
TMU
ATTACH UDP
NodeB Configuration:
- RNC OMU IP@,
- IubAttach UDP port,
- NodeB own telecom IP@
- nodeB own SCTP port,
- NodeBId = IubIf.
RNC Configuration:
- OMU IP@,
- TMU IP@ (for the Iub CP)
(OMU and TMU in same subnet).
- iubAttach UDP port,
- Iub Sctp param
- IubIf.
IP Packet Header:
- SA = nodeB IP@
- DA = RNC OMU IP@
UDP Header:
AttachTimeInterval.
- Src UDP port,

- Dest UDP port,
ATTACH UDP message payload):
- NodeB SCTP port,
- IubIf.
SCTP INIT
RNC Operational:
- Received nodeB IP@ from SA,
-
- NodeB IP@, NodeB SCTP port,

- RNC TMU IP@, RNC SCTP port,
- maxInStream, and maxOutStream
SCTP ACK
-
- maxInStream, and maxOutStream
CP & CCP over SCTP
TEG
Figure 3-72, Iub SCTP Association establishment
Abnormal cases:
- On TMU Failure, the RNC allocates the standby TMU to the nodeB and re-establishes the
SCTP Association without waiting for a Attach_UDP message from the nodeB.
- If a SCTP association setup fails, the RNC doesnt initiate another SCTP setup to that NodeB,
until a new Attach_UDP message from the NodeB. The RNC expects the NodeB to
continuously send Attah_UDP until a SCTP association is successfully established.
3.4.13 PER UMTS PLANES

3.4.13.1
OAM
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 the particular 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 atm domain.
The result in the two following configurations:
- The Iub Oam over IP traffic is routed to the OMC directly through the IP backbone, or
- 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.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 158/240
RNC oam traffic:

The RNC oam traffic is forwarded to the OMC either inBand over atm (16pOC3FP) or inBand over IP
(4pGE FP) or outBand (CP card).
RNC
RNC
PMC-OMU
PMC-OMU
NodeB 11
NodeB
PMC-OMU
PMC-OMU
oam IP@
LM
LM
FE
PP3
NodeB 33
NodeB
oam IP@
PP2
OAM
OAM VR
VR 00
IP Router
Router
IP
NodeB 22
NodeB
oam IP@
FE
CP
CP
CP
CP
Iub
PP6
PP7
(V)LAN
MPE/1002
OMC
RNC & nodeB

OAM vcc
Iu
AC1
AC1
CP & UP vcc
FE
GigE
GigE xx
GigE
GigE xx
GE
OAM vcc
atmIf
atmIf 815
815
atmIf
atmIf 815
815
ATM
ATM
STM1
TEG
Figure 3-73, nodeB & RNC oam inBand over atm
RNC
RNC
OMC
PMC-OMU
PMC-OMU
RNC oam
nodeB oam
outBand
Backbone
Backbone
PMC-OMU
PMC-OMU
CP
CP
CP
CP
LM
LM
NodeB 11
NodeB
PP3
PP2
oam IP@
OAM
OAM VR
VR 00
FE
NodeB 33
NodeB
IP Router
Router
IP
FE
IP Router
Router
IP
NodeB 22
NodeB
oam IP@
RNC oam
oam IP@
inBand
PP6
PP7
(V)LAN
(V)LAN
MPE/1002
AC1
AC1
GE
Iub
GE
FE
PP8
GigE
GigE yy
GigE
GigE yy
GigE
GigE xx
GigE
GigE xx
Iu
atmIf
atmIf 815
815
atmIf
atmIf 815
815
Figure 3-74, RNC oam inBand/outBand over ip
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 159/240
3.5
NODE B ATM (IBTS)
3.5.1
CARDS
Two kinds of nodeB card: the CEM and the CCM impact the NodeB Transport part.
3.5.1.1 CEM:
The CEM card is the gateway between radio and Iub interface. The amount of CEM cards per nodeB,
determines the call processing capacity of the NodeB.
Different kinds of CEM:
The NodeB may be populated with four kinds of CEM card:
- alphaCEM,
- iCEM64,
- iCEM128,
- xCEM.
All kind of CEM supports Hsupa traffic with exception of the alphaCEM.
Rule: IubTEG_ NodeB-CEM_02
The alphaCEM doesnt support hsupa traffic.
BBU Component:
The different kinds of CEM are populated with different amounts BBU components (BaseBandUnit) in
charge of handling the UMTS traffic:
- The iCEM64 is composed of one BBU,
- The iCEM128 is composed of two BBU.
BBU Role:
Each BBU component within a CEM is loaded with a BBU role; the different BBU roles:
- D-BBU: The BBU dedicated to the release99 traffic (dedicatedServices).
- H-BBU: The BBU dedicated to the hsdpa traffic,
- E-BBU: The BBU dedicated to the hsupa traffic.
The NodeB supports up to four E-BBU roles.
Remark: It is forecasted for UA6 that the NodeB supports up to 6 CEM loaded with E-BBU role.
One BBU component loaded with E-BBU role is able to handle simultaneously up to 15 hsupa legs.
One E-BBU handles up to 15 Hsupa simultaneous sessions.
Since UA5-0, an algorithm is in charge of assigning the different BBU roles to the CEM BBU
components. Therefore the kind of traffic handle by a CEM can not be predicted in configuration phase.
CCP Vcc:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 160/240
Each CEM involved in release99 traffic or a mix of release99 and Hspa traffic is a point of termination of
one aal5 CCP Vcc. The CEM manages also the associated SSCOP connections.
The CEM involved only in hspa traffic dont require terminating one aal5 CCP Vcc.
Since the BBU role assignment to BBU component is devolved to an algorithm, no way to determine
which CEM requiring a ccp vcc and which CEM nor requiring ccp vcc.
As a consequence, it is recommended to configure as many ccp vcc as amount of CEM within the nodeB,
whatever the traffic handle by the CEM.
The ccp vcc configured on the CEM dedicated to hspa is set disable by the nodeB without alarm
generation.
One CCP Vcc is configured per CEM Card,
The CCP Vcc configured on the Iub interface is switched in the CCM to the CEM.
CEM Characteristics:
The iCEM64 is composed of one BBU component.
The iCEM64 handles one kind of traffic amongst three: Release99, hsdpa and hsupa traffics, according to
the BBU role loaded.
The iCEM64 capacity is up to 15 simultaneous hsupa legs.
The iCEM128 is composed of 2 BBU components.
- The iCEM128 handles either:
- Simultaneously two kinds of traffic amongst three: Release99, hsdpa and hsupa
traffics according to the two different BBU roles loaded, or
- One kind of UMTS traffic, if both BBU are loaded with the same BBU role:
Release99 or hsdpa.
- One iCEM128 can not be populated with two E-BBU s.
- The iCEM128 capacity is up to 15 simultaneous hsupa legs.
The xCEM supports up to 1 E-BBU, and up to 64 hsupa legs..
The iCEM128 may be loaded with only one E-BBU role.
Slot 1
Slot 2
D-BBU
iCEM64
H-BBU
NA
E-BBU
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 161/240
iCEM128
Slot 1
Slot 2
D-BBU
D-BBU
D-BBU
H-BBU
H-BBU
D-BBU
H-BBU
H-BBU
D-BBU
E-BBU
E-BBU
D-BBU
E-BBU
E-BBU
E-BBU
H-BBU
H-BBU
E-BBU
Figure 3-75 i CEM BBU roles
3.5.1.2 CCM:
For Card hardware aspects see [R100]
The atm nodeB supports two kinds of xCCM: iCCM and xCCM.
The ip nodeB supports only the xCCM.
The atm & hybrid nodeB populated with xCCM+E1/T1MDA then supports 8 E1, two IMA linkGroups
and two FastEthernet copper accesses.
The xCCM provides a 100Mbps Ethernet port; anyway the ThroughPut is limited to 30 Mbps in DL and
15Mbps in UL.
3.5.2
PDH LAYER:
The NodeB provides both atm and ethernet accesses.
A NodeB may be populated with up to eight E1/T1 links.
The NodeB supports the CRC4. Two modes of configuration:
- A fix configuration: the nodeB is configured with CRC4 activated or not activated, thanks to the
parameter ReceiveCRC = 0 or 1,
- An automatic configuration: the nodeB is configured in such a way that the CRC4 activation is
conditioned by the presence of the CRC4 in the received multiframe. For that the NodeB
E1pcmFrame parameter is set with the value: multiframeAuto, the ReceiveCRC parameter is
ignored.
3.5.3
SYNCHRONISATION
The nodeB is synchronized either from:
- A reference clock given by a stratum 1 clock source, or
- A connected Iub E1.
In the context of synchronization on Iub E1, and CP vcc configured over a single E1 (xPCM) then the E1
where is configured the CP vcc is considered per default as the E1 clock reference.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 162/240
Else the E1 clock reference is fixed by the configuration.

In the context of IMA, the NodeB supports CTC clocking mode. ITC is not supported.
Rule: IubTEG_NodeB-IMA_Synchronisation 01
NodeB supports CTC clocking mode.
3.5.4
ATM CONNECTIONS:
AtmConnection identifier range:
Rule: IubTEG_ NodeB-atm_01
Vpi range: [ 0 to 7]:
- Up to 8 Vpi values can be configured simultaneously.
- The same vpi value may be configured simultaneously on the IMA group and
on multiPcm E1.
Vci range: [ 0 to 255].
AtmConnection type and amount:

Up to 32 vcc may be configured (including aal5, aal2 and aal1), including up to 16 aal2 Vcc).
UserPlane Vcc:
Up to 16 UP vcc may be configured per nodeB.
CCP Vcc:
As many CCP vcc are configured as amount of CEM card in the NodeB.
Up to 6 CCP vcc may be configured per nodeB.
Remark: see exception in 3.5.1.1
CP Vcc:
One CP vcc is configured in the NodeB.
In case of multiPCM configuration, or mix nE1&IMA configuration, if the E1
supporting the CP vcc fails, then all the calls are released.
UMTS OAM Vcc:
One UMTS OAM vcc is configured in the NodeB.
In case of multiPCM configuration, or mix nE1&IMA configuration, if the E1
supporting the OAM vcc fails, then all the nodeB is no more supervised.
EndToEnd F4 OAM Vcc (VCI=4):
F4 OAM vcc is automatically configured in the NodeB with ServiceCategory UBR.
Segment F4 OAM Vcc (VCI=3):
Segment F4 OAM vcc is automatically configured in the NodeB with
ServiceCategory UBR.
3.5.5
ATM CAC
The atm CAC (connection AdmissionControl) is an algorithm invoked during pvc provisioning.
The atm CAC verifies that the bandwidth required for the new atmConnection is below than bandwidth
available on the physical link.
Per atmConnection, based on the trafficDescriptor values, the atm CAC calculates the ECR
(EquivalentCellRate). The atm CAC considers the ECR value as the bandwidth required for an
atmConnection.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 163/240
NodeB atm CAC algorithm:

- ECR = PCR for a CBR atmConnection,
- ECR = SCR for a VBR atmConnection,
- ECR = MCR for a UBR+ atmConnection,
- ECR = 0 for a UBR atmConnection,
Remark:
The CDVT is not managed at NodeB level.
3.5.6
ATM OAM
On the reception of F5 AIS, the nodeB generates an alarm.
The NodeB transmits an atm OAM RDI signal on reception of atm OAM AIS.
Nevertheless the NodeB is not yet able to initiate a RDI on reception of Transmission OAM defect signal
or since aware about LOS condition.
On reception of F4 AIS, the nodeB doesnt generate an alarm.
No counter related F4/F5 signals is available.
The NodeB autonomously configures the EndToEnd F4 OAM vcc (see 4 for release compliancy). This
OAM flow terminates at the vpc endpoint. EndToEnd F4 OAM vcc is identified by vci=4.
The NodeB autonomously configures the Segment F4 OAM vcc (see 4 for release compliancy). This
OAM flow terminates at the OAM boundary. Segment F4 OAM vcc is identified by vci=3.
The F4 OAM vcc is configured with UBR serviceCategory to avoid bandwidth reservation.
The endToEnd F4 OAM vcc is initiated in the nodeB, and terminates in the RNC.
The segment F4 OAM vcc is initiated in the nodeB and terminates within the boundary of the vpc
segment. A vpc segment is under control of Network Administration. The POC may be the boundary of
the vpc segment, therefore node where Segment F4 OAM vcc terminates.
3.5.7
MULTIPCM
The NodeB Iub interface is configured either with IMA linkGroup, xPcm or a mix of IMA and xPcm.
For the E1 not inserted within an IMA linkGroup, configured in xPcm mode, the vcc are distributed on
each E1 link.
The Oam vcc is configured on the pcm 1 per default (in factory).
The others vcc are distributed over the different pcm in such a way to satisfy robustness and load
balancing:
- the CP vcc is configured on a Pcm, different from those supporting oam vcc,
- the CCP vcc are distributed over the different available pcm,
- one up ds vcc and one up nds vcc are configured per pcm.
- If hspa configured over xPcm, then 1 hspa vcc is configured per pcm.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 164/240
Exemple:
- 6 pcm,
- NodeB with 5 CEM,
- 1 Hspa vcc over one shared Pcm together with release99 vcc, the RNC BwPool must be
set in accordance.
- 1 Hspa vcc over one dedicated Pcm in such a way to avoid congestion, the RNC
BwPool must be set in accordance.
The following table provides an exemple of the vcc distribution:
PCM 1
1 oam vcc
PCM 2
1 cp vcc
PCM 3
PCM 4
PCM5
1 ccp vcc
1 ccp vcc
1 ccp vcc
1 ccp vcc
1 ccp vcc
1 up ds vcc
1 up ds vcc
1 up ds vcc
1 up ds vcc
1 up ds vcc
1 up nds vcc
1 up nds vcc
1 up nds vcc
1 up nds vcc
1 up nds vcc
1 hspa vcc
3.5.8
PCM6
1 hspa vcc
FRACTIONAL E1/T1
Fractional E1/T1 [R46 & R93] Transport feature is used for umts Drop&Insert feature.
Drop&Insert is available on single port E1/T1 (combination of Fractional Rate E1/T1 for UMTS and aal1
CES cross connect for GSM IBTS).
NodeB CCM card supports fractional E1/T1.
Rule: IubTEG_D&I_01
Only one link (E1/T1) may be used in a nodeB toward the RNC, if configuring Drop&Insert.
Let us called:
- The droppedNode: node at the end of the chain, where fractional E1/T1 is configured.
- The droppingNode: node which inserts on the link its own SDUs and SDUs received from the
dropped node.
3.5.8.1 CASE OF UMTS/UMTS D&I:

Fractional E1:
One E1 and only one is shared between two NodeBs.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 165/240
Dropped NodeB
Dropping NodeB
E1 n1
E1 n2
NodeB
N2
NodeB
N1
TDM
backbone
UMTS IBTS
1 Fract E1
14 TS
TDM
backbone
UMTS IBTS
1 Fract E1
12 TS
RNCANode
ATM over unchannelise

STM-1
d
RNCINode
e/w MSA 32
with STM-1
Example:
POC splits UMTS traffic for 2 nodeBs on same E1 N1 :
NodeB N1 Iub ATM stream from 12 TS (E1 n1, TS 2-13) is sent over STM1 to RNC-IN,
NodeB N2 ATM stream from 14 TS (E1 n1 TS 17-30) is sent over STM-1

to RNC-IN.
E1 N2 :
NodeB N2 Iub ATM stream from 14 TS (TS 17-30) is switched on E1 n1

and then sent over STM-1 to RNC.
STM-1:
Aggregation traffic from many IBTS including the ones from other MSA (full
or fractional E1).
Rule: IubTEG_D&I_02
- D&I of 2 nodeB max,
- Only one E1 is supported (fractional E1):
- UMTS nodeB requires at least 12 TS on E1 for delay reason,
- At MSA 32E1 port level : AAL1 CES must be used to do TDM cross connect ,
- D/I is not supported with NodeB multiPCM configuration.
- Maximum number of timeslots per nodeB is 18.
- A nodeB traffic flow may not use consecutive TimeSlots.
- Drop&Insert and IMA can not be configured together.
- Connectivities:
o On droppedNode, PCM1 port is configured
o On droppingNode, PCM2 port is configured toward the droppedNode
and PCM1 is configured toward the RNC.
Remarks:
Maximum number of available E1 TS is 30 since TS0 and 16 are reserved [R47].
An Hairpin must be added on MSA32 card because MSA32 port can handle only 1 ATM interface :
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 166/240
RNC-ANode
32 Timeslots
ATM1
Not used
MSA32 card
Node-B 1
Node-B 2
CCM
CCM
ATM1
E1
ATM1
32 Timeslots
Not used
32 Timeslots
Not used ATM2 Not used
E1
32 Timeslots
ATM2
32 Timeslots
Not used ATM2 Not used
ATM / Fractional E1
Timeslot Cross Connect
Cross Connect & ATM Fract E1
Figure 3-76 MSA32 FractionalE1 Hairpin

Fractional T1:
One T1 link is shared between two NodeBs.
Remark: T1 is not managed by MSA FP.
One T1 and only one is shared between two NodeBs.
Dropped NodeB
Dropping NodeB
T1 n1
T1 n2
UMTS
IBTS N2
UMTS
IBTS N1
TDM
backbone
UMTS IBTS
TST1
112
Fract
14 TS
TDM
backbone
OC-3/T1
connector
ATM over unchannelised

OC-3
RNC
UMTS IBTS
12 TS
1 Fract T1
14 TS
Rule: IubTEG_D&I_03
- D&I of 2 nodes B max,
- Only one T1 is supported (fractional T1):
- UMTS node B requires 12 TS on T1 for delay reason,
- D/I is not supported with NodeB multiPCM configuration.
- A nodeB traffic flow may not use consecutive TimeSlots.
- Connectivities:
o On droppedNode, PCM1 port is configured
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 167/240
On droppingNode, PCM2 port is configured toward the droppedNode

and PCM1 is configured toward the RNC.
Remarks:
- F4/F5 AIS dedicated to dropped NodeB Atm connections go through the dropping nodeB.
- The POC based on MSS7k is not involved in T1 D&I, since doesnt provide T1 access.
3.5.8.2 CASE OF UMTS/GSM D&I

Fractional E1:
UMTS
GSM
BTS
NodeB
E1 n1
UMTS IBTS
1 Fract E1
22 TS
1 Fract E1
8 TS
ATM over Unchannelised STM1

RNC-INode
GSM BTS
1 Fract E1
15 TS
TDM backbone
shared between
UMTS & GSM
TDM
backbone
E1 n2
e/w MSA 32
with STM-1
E1 n6
TDM
backbone
GSM
BTS
RNC-ANode
E1 n4
E1 n5
BSC
GSM
UMTS E1 n3
NodeB 1 Fract E1
BTS
15 TS
GSM BTS
2 Fract E1
10 + 8 TS
E1 n7
One E1 link is shared between one GSM BTS and one NodeB:
Example:
MSA32 splits GSM and UMTS traffic from 2 incoming E1
E1 N1:
8 GSM TS (TS 1, 5-11) are mapped onto TS1 and TS5-TS11 of E1 N6.
-
NodeB ATM stream from 22 TS (E1 N1 TS 2-4, 12-15, 17-31) is sent over
STM-1 to RNC.
E1 N2:
- 15 GSM TS (TS 2, 17-30) are switched on E N 4 and then mapped onto
TS1-TS15 of E1 N7.
E1 N3:
- NodeB stream from 15 TS (E1 N3 TS 17-31) is switched on E1 N5 and
then sent over STM-1 to RNC.
E1 N4:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 168/240
10 GSM TS (TS 1, 5-13) are mapped onto TS2 and TS17-TS26 of E1 N6.
8 GSM TS (TS 6-13) are mapped onto TS17-TS25 of E1 N7.
E1 N6&7: Carries GSM Abis from 3 GSM BTS to BSC.

STM-1: Carries Iub aggregation traffic from many IBTS including the ones from other
MSA (full or fractional E1).
Rule: IubTEG_D&I_04
- GSM BTS must be the dropping node, whereas the UMTS NodeB must be the
dropped node.
- Minimum number of TS for UMTS is 12 to insure acceptable delay; therefore in
best case 18 TS are available for GSM.
- D/I is not supported with NodeB multiPCM configuration, or BTS multiPCM.
- The GSM and UMTS TS can be non consecutive.
- Connectivities:
o On droppedNode, PCM1 port is configured,
o On droppingNode, PCM2 port is configured toward the droppedNode and
PCM1 is configured toward the RNC.
Remarks:
- GSM BTS must be the dropping node, in order to not perturb GSM traffic,
- Maximum number of available E1 TS is 30 since TS0 and 16 are reserved [R47].
- Fractional rate E1 access is available on MSA32 FP which populates the MSS7k.
Fractional T1:
One T1 link is shared between one GSM BTS and one NodeB:
Rule: IubTEG_D&I_05
- GSM BTS must be the dropping node, whereas the UMTS NodeB must be the
dropped node.
- Maximum guaranteed configuration 2 dropped nodes: 1 GSM BTS and 1 UMTS
nodeB. The dropping node being a GSM BTS.
- D/I is not supported with NodeB multiPCM configuration, or BTS multiPCM.
- Number of TS for UMTS is 12 to insure acceptable delay; therefore up to 12 TS are
available for GSM.
- The GSM and UMTS TS can be non consecutive.
- Connectivities:
o On droppedNode, PCM1 port is configured,
o On droppingNode, PCM2 port is configured toward the droppedNode and
PCM1 is configured toward the RNC.
Remarks:
- GSM BTS must be the dropping node, in order to not perturb GSM traffic,
- Maximum number of available T1 TS is 24.
- Fractional T1 is not available on 4 ports DS3ch IMA nor on 4 port DS3ch CES.
3.5.9
IMA
The IMA (Inverse Multiplexing Atm) sets together multiple E1/T1 physical links into a single atm high
speed link. This link is called an IMA linkGroup.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 169/240
The IMA is configured between two neighbor atm nodes.

In the originating atm node, the port running IMA receives a single stream of cell traffic from the atm
layer and transparently distributes the individual cells in a round-robin fashion along multiple links within
an IMA linkGroup.
In the destination atm node, the port running IMA re-aggregates the cell stream at the receiving end of the
link group on a cell-by-cell basis, preserving the original cell order and format. See: IMA differential
Delay 3.5.9.4.
IMA linkGroup
IMA linkGroup
NodeB
NodeB
IMA linkGroup
Up to8 E1
IMA linkGroup
IMA linkGroup
NodeB
NodeB
E1
RNC
RNC
POC
POC
POC
POC
IMA linkGroup
NodeB
NodeB
E1
Stm1
On the Iub interface, IMA is candidate for NodeB/POC, POC/POC interfaces.

Compared to xPcm feature, the IMA offers an optimized way of the link bandwidth use.
The xPcm feature consists in distributing vcc through different physical links, whereas IMA consists in
distributing cells from different Vcc through different physical links.
3.5.9.1 SYNCHRONISATION
Two ways of managing clock are suggested:
- CTC (CommonTransmitClock): the same transmitClock applies for all links within the IMA
linkGroup.
- ITC (IndependentTransmitClock): transmitClock is independently derived from one or several
links within an IMA linkGroup.
3.5.9.2 ICP (IMA CONTROL PROTOCOL)

Each RNC card supports ICP compliant to atmForum.
NodeB supports both IMA1.1 and IMA1.0 ATM Forum.
Rule: IubTEG_IMA_02
It is recommended to configure IMA1.1 on nodeB and adjacent atmSwitch.
NodeB Fallback mechanism:

The CCM support the two IMA versions 1.1 and 1.0, nevertheless it doesn't provide the ability
to automatically fallback from IMA version 1.1 to IMA version 1.0 when interworking with
IMA version 1.0 equipment (lack of internal resource).
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 170/240
The iCCM support the two IMA versions 1.1 and 1.0, and provides the ability to fallback from
IMA version 1.1 to IMA version 1.0.
Information convey in ICP cells:
- Logical link Identifier: identification of the physical link within the IMA linkGroup, this value is
negotiated between the two Atm IMA nodes.
- LinkGroup Identifier,
- configuration,
- synchronization,
- status and
- defect information
An IMA linkGroup is managed by means of the ICP (IMA ControlProtocol).
ATM cells being transmitted over a link are distributed into IMA frames containing 128 cells; one ICP
cell is inserted within each frame on a physical link.
IMA Frame 0
ICP
Link 0
127 ICP
128 cells
ICP
IMA Frame 2
127 ICP
128 cells
127
ICP
127
128 cells
127
ICP
127
ATM node
ATM node
IMA Frame 1
Link 1
IMA Frames sent

simultaneously
on each link
IMA
IMA
Figure 3-77 IMA Frame
3.5.9.3 IMA LG BANDWIDTH

The process of IMA framing and control slightly reduces the capacity of individual physical links within
an IMA link group.
The cell capacity of a physical link involved in an IMA linkGroup is calculated with the formula:
Rule: IubTEG_IMA_03
IMA link available throughput:
IDCR = TRLCR * 127/128 * 2048/2049
Where:
- IDCR: IMA Data Cell rate, cell capacity of a physical link
- TRLCR: TimingReferenceLinkCellRate, link cell rate without IMA.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 171/240
Table below provides IDCR for E1 and T1, in the last column is taken into account
MininimumBandwidthGuaranty = 2% reserved for RNC EmissionPriority7 (OAM vcc):
Link type #TimeSlots User throughPut TRLCR
w/o IMA (kb/s)
(Cell/s)
IDCR
(kb/s)
IDCR IDCR-MBG
(cells/s)
(cells/s)
E1
30
1920
4528
1904
4490
4400
T1
24
1536
3622
1523
3591
3519
Figure 3-78 IMA LG bandwidth
For IMA LG Bandwidth Reduction/Restoration mechanisms, see the RNC/IMA and the NodeB/IMA.
3.5.9.4 IMA DIFFERENTIAL DELAY

The AtmForum indicates that:
- The IMA Transmitter shall not introduce differential delay among the constituent links of
more than 2.5 cell times at the physical link rate. Application to E1case: 2,5*220 s = 550 s.
- On the IMA Receiver, the amount of link differential delay tolerated by an IMA
implementation shall be up to at least 25 milliseconds when used over DS1/E1 links.
In the context of the UMTS network, the IMA max differential delay is set in such a way to satisfy the
UMTS network delayBudget.
As long as the E1/T1 composing the IMA Group:
- Used same path (amount of transmission node, transmission link length),
- Used same media (e.g.: cupper line) or different media offering same delay characteristics,
Then closed delay values are expected from the different E1/T1, the IMA max differential delay can be
set with a minimal value:
Rule: IubTEG_IMA_06
The IMA Differential Delay is set to 2 ms as long as same path and same medium used for the
E1/T1 composing the IMA Group.
Since the E1/T1 composing the IMA Group:

- Used different paths (amount of transmission node, transmission link length),
- Used different media (e.g.: cupper line, Wave, Satellite),
Then different delay values are expected from the different E1/T1, the IMA max differential delay must
be set accordingly and moreover set in such a way to satisfy the UMTS expected delayBudget.
UMTS DelayBudget:
The most delay stringent UMTS bearer being the realTime Conversational speech: oneWay
delay in the range [0, 150 ms] or [0, 200 ms] according to the operator gradeOfService
requirement, the realTime Conversational speech is then considered as the reference when
calculating the network expected delay Budget.
Since the network expected delay Budget is calculated then the max differential delay can be
determined.
The max differential delay is set in such a way that when added to the delayBudget, the result is below
the operator oneWay delay objective ([0, 150 ms] or [0, 200 ms]).
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 172/240
Node characteristics:
The nodeB allows configuration of the maxDiffDelay up to 25 ms.
The 7670 is conformed to the atmForum.
The Passport nodes terminating an IMA LG are configured with the maximum tolerated
IMA differentialDelay through the MML:
ATTRIBUTE Lp Ima maxDiffDelay (delay), Range Values: [1..100 ms], Default value:
25 ms.
Remark:
The peer IMA endPoint nodes may be configured with different max differential delay values.
3.5.9.5 NODEB IMA CHARACTERISTICS:

- The multiplexing of atm cell stream is performed on a cell by cell basis across up to 32 physical
links operating at the same link cell rate. Since NodeB offers up to 8 E1/T1, a nodeB IMA
linkGroup is composed of up to 8 E1/T1.
- The nodeB populated with xCCM supports up to two IMA groups. The nodeB populated with
iCCM supports one single IMA group.
- On the nodeB, the IMA linkGroup can cohabite with xPcm.
- Fractional E1/T1 is not allowed when the E1/T1 link is part of an IMA group,
- IMA distributes cells in a round Robin sequence.
- IMA frame 128 cells length.
- On each E1 of an IMA linkGroup, atm cells are mapped into timeslots 1 to 15 and 17 to 31.
- On each T1 of an IMA linkGroup, atm cells are mapped into timeslots 1 to 24.
Rule: IubTEG_NodeB-IMA_01
IMA within CCM is compliant with atmForum V1.0.
IMA within iCCM and xCCM is compliant with atmForum V1.1 (supports also V1.0).
3.5.9.6 IMA DEFENCE:

In the context of link failure within the IMA linkGroup, the nodeB decides to release some vcc.
In the context of link restoration, the nodeB decides to restore some vcc.
The HoldingPriority value assigned to each vcc, determines which vcc are released when the link failure
occurs, moreover determines which vcc are restored when the link recovery occurs.
The HoldingPriority value is set against both the aal2 and aal5 vcc.
The HP is a Class3 parameter.
The HoldingPriority is in the range [0, 16]:
- The vcc set with the highest HP value are first candidate to release in case of link failure.
- The vcc set with the lowest HP value are first candidate to restoration in case of link recovery.
- The vcc set with HoldingPriority = 0 are never released.
Application to the UMTS:
All the aal5 vcc are set with HP=0.
All the aal2 vcc, with exception of the qos3 vcc within a sharedForAllTrafficTypes bwPool, are set with
an holdingPriority in the range [1, 16], then these aal2 vcc are candidate to release in case of link failure.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 173/240
- On link failure, the nodeB releases all the aal2 vcc with the highest holdingPriority
value, whatever the type of aal2 vcc (qos0, qos1, qos2 or qos3 vcc) and whatever
amount of vcc,
- On link restoration, the nodeB restores all the aal2 vcc with the lowest holdingPriority
value, whatever the type of aal2 vcc (qos0, qos1, qos2 or qos3 vcc) and whatever
amount of vcc.
Furthermore since the nodeB has released some vcc, it notifies the RNC about vcc deactivation by means
of the atm oam signals. The RNC is indeed aware about the amount of active aal2 vcc then it can deduce
the nodeB actual bandwidth taking into account the vcc trafficDescriptor.
To avoid that one E1 failure causes a complete traffic type interruption, it is recommended to replicate
each kind aal2 vcc and to assign them different HP values.
Aal2 vcc amount:
To take benefit of the nodeB IMA defense mechanism, it is necessary to replicate the aal2 vcc,
in such a way when part of the IMA linkGroup E1 fails, then each kind of aal2 traffic can still
be handling on a lower bandwidth:
Case of IMA Group associated to a sharedForTrafficTypes bwPool:
Up to four types of aal2 vcc (qos0, qos1, qos2 and qos3 vcc) are configured over the
IMA group. The amount of configured aal2 vcc per type depends on the amount of
E1 within the IMA group and if the hspa streaming traffic is handle by the nodeB:
- For each E1 within an IMA group, a set of userPlane vcc is configured. A set of
userPlane vcc is composed of one or several vcc, one or different type of vcc
(qos0, qos1, qos2 or qos3 vcc).
- Within the nodeB all the vcc within a set of userPlane vcc are set with the same
holdingPriority value.
The same HP value is assigned to all the aal2 vcc within a set of vcc.
Different HP values must be assigned to the aal2 vcc within different set of vcc.
Furthermore, within the RNC, the trafficDescriptor against the userPlane vcc
belonging to a set of userPlane vcc are set in such a way:
set of userPlane vcc ECRgcac = E1 bandwidth minus E1 bandwidth portion

reserved for the signaling.
The HP values are suggested in 5.5.1.
Case of IMA Group associated to a primaryForTrafficType bwPool composed of only qos3
vcc:
As many HSPA qos3 vcc are configured as amount of E1 within the IMA group.
Different nonZero HP values are assigned to each Hspa qos3 vcc.
Furthermore within the RNC, the rtVbr, nrtVbr or UBR+/MDCR is assigned to each
qos3 vcc, the trafficDescriptor assigned to each qos3 vcc are set in such a way qos3
vcc ECRgcac = E1 bandwidth minus E1 bandwidth portion reserved for the signaling.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 174/240
Case of IMA Group associated to a primaryForTrafficType bwPool composed of qos0, qos1,

qos2 and qos3 vcc:
Up to four types of aal2 vcc (qos0, qos1, qos2 or qos3 vcc) are configured over the
IMA group. The amount of configured aal2 vcc per type depends on the amount of
E1:
- For each E1 within an IMA group, a set of userPlane vcc is configured. A set of
userPlane vcc is composed of one or several vcc with different qos.
- Within the nodeB all the vcc within a set of userPlane vcc are set with the same
holdingPriority value.
Furthermore, within the RNC, the trafficDescriptor against the userPlane vcc
belonging to a set of userPlane vcc are set in such a way:
set of userPlane vcc ECRgcac = E1 bandwidth minus E1 bandwidth portion reserved for
the signaling.
The HP values are suggested in 5.5.1.
NodeB IMA Defense Activation/desactivation:
The nodeB IMA Defence mechanism is activated as an option at the OMC-B thanks to the
parameter: IMAGroup/imaDefenseDelay present at the OMCB:
- IMAGroup/imaDefenseDelay = unset, means the defense mechanism is desactivated,
- IMAGroup/imaDefenseDelay = x, indicates the delay the nodeB introduced between the
link failure event and the invocation of the Defence mechanism. If x=0, the nodeB starts
the defense mechanism since aware about the bandwidthReduction.
Triggers:
The nodeB releases some vcc in the following context:
- PCM LOS condition observed locally,
- PCM manually locked,
- Aal2 Vcc creation,
- Reception of ICP cell with physicalDefect information (case of PCM LOS observed by
the farEnd node).
The nodeB restores some vcc in the following context:
- PCM recovery,
- PCM manually unlocked
- Aal2 Vcc deletion.
3.5.10 MIX OF N * E1 XPCM AND P E1 IMA

On the NodeB side, the mix n*E1xPcm & p*E1 IMA configuration, consists in assigning p*E1 to an
IMA linkGroup while the n*E1 are managed independently (xPcm).
The nodeB handling up to 8 E1, n is the range [0, 8] and p in the range [0, 8].
Its not mandatory that the E1 within the IMA linkGroup are contiguous.
The fractional E1 feature is not compatible with the nodeB mix configuration.
The atm oam loopBack mechanism may be activated on the isolated E1 and is not available for E1
inserted in the IMA linkGroup.
Synchronisation:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 175/240
Either all the NodeB is synchronized on a reference clock given by a stratum one clock
source, or
One Iub E1 is chosen as the clock reference. The E1 designated as the clock reference must be
the E1 transported within the backbone over the media the less impacting in terms of delay,
e.g.: preferred E1 over leased line instead of E1 over DSL.
IMA:
It is still recommended to activate the IMA Defense on the NodeB side.
Hspa vcc amount:
- If the IMA linkGroup is dedicated to the Hspa traffic, it is recommended to configure as many
hspa vcc as amount of E1 within the IMA linkGroup, in such a way to relay on the nodeB
IMA defense mechanism.
- If the IMA linkGroup is shared between Hspa and Release99 traffic, the amount of hspa vcc
results from the need of simultaneous aal2 CID. One or two hspa vcc may be required (NodeB
hspa cac constraint).
- Over an E1 in a xPcm mode, only one Hspa vcc is enough.
Application exemples:
- The Release99 userPlane vcc, the signaling vcc and the oam vcc are configured on the
independent E1, whereas the hspa vcc are configured on the IMA LG.
The distribution of the Release99 userPlane vcc and the signaling vcc over the E1 in xPcm mode is
done as for the xPcm configuration, see 3.5.7.
3.5.11 QOS
The QOS is configured in the nodeB through the NodeB proprietary serviceCategory parameter, which is
an extension of the AtmForum serviceCategory.
List of the NodeB proprietary serviceCategory parameter values:
- CBR, CBR1, CBR2, CBR3,
- VBRrt, VBRrt1, VBRrt2, VBRrt3
- VBRnrt0, VBRnrt, VBRnrt2, VBRnrt3,
- UBR0, UBR1, UBR, UBR3,
- UBRPlus0, UBRPlus1, UBRPlus, UBRPlus3.
The highest priority is given to the CBR vcc and the lowest priority is given to the UBR vcc.
For vcc configured with the same AtmForum serviceCategory, the highest priority is given to the xBR0
vcc and the lowest priority is given to the xBR3 vcc.
The UBR and UBRPlus NodeB proprietary serviceCategory parameter values (without a numerical
suffix) are considered priority 2.
-
Case of trafficShaping NOT activated:

In such a way the trafficShaping is not activated, each nodeB Vcc are configured with the UBR or
the UBRPlus serviceCategory.
The UBRPlus is a serviceCategory which allows configuration of a MCR (MinimumCellRate) value
to the vcc.
The UBRPlus is also called also GBR (guaranteed bit Rate)
Since each nodeB vcc is configured with the same AtmForum serviceCategory, the QOS is no more
provided by the serviceCategory but by the numerical suffix attached to the serviceCategory.
Below the recommended serviceCategory to configure in the network and the proprietary SC to
configure in the nodeB when trafficShaping is NOT activated:
Rule: IubTEG_ Iub_NodeB-QOS_2
If TrafficShaping is NOT activated:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 176/240
When no hspa Streaming traffic:
suggested SC
in the network
VCC
ProprietarySC parameter
configured in the NodeB
qos0 vcc
rtVbr
UBR1
qos2 vcc
nrtVBR
UBR
qos3 vcc
UBR
UBRPlus3 (MCR)
CP
rtVbr
UBR1
CCP
rtVbr
UBR1
alcap
rtVbr
UBR1
OAM
UBR
UBRPlus3 (MCR)
/2/
When hspa Streaming traffic activated:
suggested SC
in the network
VCC
ProprietarySC parameter
configured in the NodeB
qos0 vcc
cbr
UBR0
qos1 vcc
rtVbr
UBR1
qos2 vcc
nrtVBR
UBR
qos3 vcc
UBR
UBRPlus3 (MCR)
CP
rtVbr
UBR1
CCP
rtVbr
UBR1
Alcap
rtVbr
UBR1
OAM
UBR
UBRPlus3 (MCR)
/2/
Remarks:
- The NodeB proprietary SC UBR means priority:2; the NodeB proprietary SC UBRPlus
means priority:2
- The qos3 vcc carries both hspa user traffic and hspa flowControl traffic. In such a way to
guarantee a minimum bandwidth for flowControl, a MCR value is assigned to Hsdpa Vcc.
NodeB QOS handling:
- The UBRx vcc and the UBRPlusx vcc get the same priority,
- Assuming two vcc configured with the same proprietary SC, if there are cells in both vcc
queues, the nodeB scheduler considers each queue with the same weight, indeed one cell is
extracted from first queue, then one cell from the second queue, then one cell is extracted
from first queue,
-
Case of trafficShaping activated:

Below serviceCategory and proprietary SC recommended values when trafficShaping is activated:
Rule: IubTEG_NodeB-QOS_1
If TrafficShaping activated:
VCC
SC configured in NodeB
Proprietary SC
qos0 vcc
rtVBR
rtVbr
qos1 vcc
nrtVBR
nrtVbr
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 177/240
qos3 vcc
Ubr
Ubr3
CP
rtVBR
rtVbr
CCP
rtVBR
rtVbr
Alcap
rtVbr
rtVbr
OAM
UBR+
UBRPlus
3.5.12 TRAFFIC MANAGEMENT

In nodeB only one trafficDescriptor is set per vcc. It applies either to uplink and to downlink direction.
3.5.12.1
TRAFFIC DESCRIPTOR PARAMETERS
MCR:
(see 4)
To avoid lowest priority vcc traffic starvation by highest priority vcc traffic, a MCR
(MinimumCellRate) value is configured on lowest priority vcc to guarantee a minimum bandwidth.
The MCR parameter is configured for UBR+ vcc.
The MCR is taken into account by CAC; UBR+ Vcc ECR = MCR.
MCR is not involved in TrafficShaping; whatever the MCR value, an UBR+ vcc may transmit at
linkRate.
Even if a lower priority vcc is configured with a MCR, a higher priority vcc is able to use the
complete link bandwidth, if available.
The MCR parameter may be configured against aal5 and aal2 vcc.
In the nodeB, the MCR value is configured against an UBR+ vcc through the vcc SCR parameter.
Indeed for a UBR+ vcc the SCR parameter is filled with the expected MCR value whereas for vcc
configured with another serviceCategory the SCR parameter is filled with the expected SCR value.
For an UBR+ vcc, the nodeB accepts only SCR filled with a nonzero value, rejects the SCR=0.
How to configure the MCR value through OMC-B, and impact on NodeB:
Rule: IubTEG_NodeB-TM_1
On OMC-B
Results on NodeB:
UBR, SCR=0
UBR, SCR=0, MCR=mcr with mcr <> 0
UBR
UBR, SCR=scr with scr <> 0

UBR, SCR=scr, MCR=mcr with scr and mcr<> 0
UBR+, MCR=scr
UBR+ , MCR=0, SCR=scr with scr <> 0
UBR+, MCR=scr
UBR+ , MCR=SCR=0
Error
UBR+, MCR=mcr with mcr <> 0, SCR=0
UBR+, MCR=SCR=0 = Error
Table 3-31 MCR Configuration
Minimum Vcc throughput:

The Vcc PCR and SCR must be set with a value higher than minimum Vcc throughput.
Case of multiPCM:
The minimum Vcc throughput for full PCM is PCM bandwidth/20.
E.g.:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 178/240
E1 throughput = 1, 92 Mbits/s = 4528 cell/s then minimum throughput = 1, 92 Mb/s / 20 = 96

kbits/s = 227 cell/s.
T1 throughput = 1, 544 Mbits/s = 3622 cell/s then minimum throughput = 1, 544 Mb/s / 20 =
77, 20 kbits/s = 182 cell/s.
Remark:
NodeB OAM converts kbits/s into bits/s using ratio 1000, reason why the E1
minimum throughput is 227cells/s, and the T1 minimum throughput is 182cells/s.
Case of E1 Drop&Insert 15/15, the minimal cell rate is 227/2 = 114 cells/s.
Case of T1 Drop&Insert 12/12, the minimal cell rate is 182/2 = 91 cells/s.
Case of IMA:
The minimum Vcc throughput is IMA linkGroup bandwidth / 160.
Eg: an IMA LG composed of 8 E1, the IMA LG bandwidth = 8 * 1,904 Mb/s = 15, 232 Mb/s
then the Vcc minimum throughput = 15, 232 Mb/s / 160 = 96 kb/s.
xPcm case:
Minimum Vcc throughput = PCM bandwidth / 20
IMA Case:
Minimum Vcc throughput = IMA LG bandwidth / 160
3.5.12.2
TRAFFIC SHAPING
In first UMTS Releases, trafficShaping was always activated at VC level. It becomes optional in last
UMTS Releases (see 4).
Since trafficShaping becomes optional,
- Activation of trafficShaping in NodeB consists in setting serviceCategory and proprietary SC
values indicated in rule Iub_NodeB-QOS_1.
- Non activation of trafficShaping in nodeB consists in setting serviceCategory and proprietary
SC values indicated in rule Iub_NodeB-QOS_2.
Remarks:
To remove TrafficShaping on NodeB, serviceCategory are change to UBR/UBR+, nevertheless keeps
on other Iub Atm nodes Iub recommended serviceCategory values, as indicated in rule Iub_NodeBQOS_2 column SC recommended for the interface.
Moreover when removing trafficShaping in nodeB:
- For UBR VCC, set SCR=MBS=0 on nodeB,
- For UBR+ VCC, set SCR and MCR according to rule Iub_NodeB-TM_1.
- Set PCR = LinkRate when IMA is not configured,
- Set PCR = [IMA LinkGroup Bandwidth IMA overhead], when IMA is configured. (see IMA).
Remarks:
PCR is still used for regulating Egress traffic, then set PCR to the interface bandwidth.
A mix of shaped atmConnections and notShaped atmConnections is not allowed on nodeB.
3.5.13 HSPA CAC

Hs-dsch leg regulation:
The NodeB Hsdpa CAC regulates amount of hs-dsch legs per H-BBU.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 179/240
The maximum amount of hs-dsch legs per H-BBU is configurable:

Parameter: hsdpaMaxNumberUserHbbu
Parameter range: [0, 65535],
Edch leg regulation:

The NodeB Hsupa CAC regulates the amount of edch legs per E-BBU.
The maximum amount of edch legs per E-BBU accepted by the Hsupa CAC is configurable:
Parameter: edchMaxNumberUserEbbu,
Parameter range: [0, 65535].
Beside the UA5-0 E-BBU product accepts up to 15 edch legs.
Remark: when the parameter edchMaxNumberUserEbbu is set to 0, the Hsupa CAC limits the amount
of edch legs per E-BBU to the E-BBU product capacity.
If the edch leg is rejected by the Hsupa CAC, the user session falls back to DCH.
3.5.14 ALCAP
The NodeB allows establishment of the aal2 connections either using the Nbap (UA5 behaviour) or the
Alcap protocol.
The choice of the protocol used for the aal2 connections establishment is determined by the setting of the
AlcapActivation parameter.
Rule: IubTEG_NodeB-Alcap_1
The nodeB AlcapActivation parameter must be set to true, for running Alcap protocol. Else the
aal2 callControl is achieved by NBAP.
It is mandatory to activate the Alcap protocol on the Iub interface.
Parameter: BtsEquipment / AlcapActivation (class0) values: True or false.

Since the alcap is activated on the Iub interface, one single alcap vcc must be configured per nodeB.
Alcap Cell Validity Timer:
The iBTS supports the Alcap Cell Validity Timer.
The objective of this timer is to avoid aal2 traffic instability when SCCOP connection
bouncing.
Alcap Cell Validity Timer definition:

- On Alcap SSCOP disconnection, the Alcap Cell Validity timer is started,
- At the expiration of the timer, the nodeB aal2 connections are released.
The aal2 connections are maintained as long as the Alcap Cell Validity timer is running.
If the nodeB Alcap Cell Validity Timer = 0 then the aal2 connections are released since
the Alcap is notified about SSCOP disconnection.
Rule: IubTEG_NodeB_Alcap_2
The iBTS NodeB Alcap Cell Validity must be set with a nonZero value.
3.5.15 OAM, IP OVER ATM

The NodeB oam own IP@ is either configured during I&C or obtained from a DHCP server.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 180/240
3.6
NODE B IP & HYBRID (IBTS)

This section covers the transport part of the native IP nodeB and the IP leg from the Hybrid NodeB.
3.6.1
NODEB IUB CONNECTIVITY

The NodeB populated with xCCM+GE MDA:
- GE MDA port: SFP1, SP2 or RJ45 GE ports,
- The SFP ports operate in 1000BASE-X/100BASE-FX mode, optical and electrical.
- The RJ45 port operates in 10/100/1000BASE-T mode.
Remark: SFP2 and RJ45 are connected to the same ethernet PHY. Therefore SFP2 and
RJ45 ports must not be used at the same time
- The xCCM motherBoard: 1 FE port and 4 PCM.
- ThroughPut up to 400 Mbps (200 Mb/s UL + 200 Mb/s DL) traffic.
The NodeB Populated with xCCM+ 4E1/T1 MDA:
- Supports: 1 FE and 8 PCM for Iub (and One FE dedicated to siteLan&localMaintenance),
- The average throughPut is 30 Mbps in DL and 15Mbps in UL.
Iub connectivities
xCCM/xCCM-U
Atm nodeB
4 PCM
Hybrid nodeB
4 PCM + 1 FE
8 PCM
+ 4 E1/T1 MDA
4 PCM
xCCM/xCCM-U
4 PCM
4 PCM
4 PCM + 1 FE
16 PCM
+ 12 E1/T1 MDA
12 PCM
xCCM / xCCM-U
4 PCM
Step1
12 PCM
4 PCM + FE
4 PCM
+ GE MDA
xCCM / xCCM-U
4 PCM
Step2
4 PCM
4 PCM
+ GE MDA
1 GE
8 PCM
+ 1 FE
16 PCM
+ 1 FE
Native IP
nodeB
1 FE (+ 4 PCM)
1 FE (+ 4 PCM)
4 PCM
+ 1 FE
FE + (4 PCM)
4 PCM
+ 1 GE
(4 PCM)
1 GE
Figure: NodeB Connectivity
Whatever the nodeB is populated with 4E1/T1 MDA or GE MDA:

- The 3 Iub transport alternatives are supported:
- Native IP Iub.
- Hybrid Iub and
- ATM Iub (up to 4 PCM (from the mother board) if GE MDA).
- Priority tagging (P-Tag) and vlan tagging are supported.
NodeB Iub connectivity enabling:
- To enable one or multiple ethernet ports, set the I&C parameter:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 181/240
I&C Parameter:
Ports enable:
Bit Specifying the eth port used to support Iub I/F

Dec
bit7 bit6 bit5 bit4 bit3 bit 2 bit 1
bit 0
motherBoard FE (2)
GE MDA RJ45 (5)
GE MDA SFP1 (3) and RJ45 (5)
GE MDA SFP2 (4) and RJ45 (5)
GE MDA SFP1 (3), SFP2 (4) and RJ45 (5)
This command is taken into consideration by the nodeB after nodeB reset.
One of the enable ports is used for Iub interface.
NodeB
NodeB
MotherBoard
MotherBoard
44 PCM
PCM
FE
FE
Iub
GE
GE MDA
MDA
SFP1
SFP1
SFP2
SFP2
RJ45
RJ45
- To enable Iub over either ethernet FE or GE, set the Bts Equipment parameter with value 2 or 3:
Field name
Field type / value
Type of incoming links - 0=PCM,

- /1=STM1/OC3 (future)/,
- 2=Fast Ethernet,
- 3=Gigabit Ethernet
- If the nodeB is populated with GE MDA and TypeOfIncomingLink = 2 (FE):

- Either the mother board FE port or the GE MDA RJ45 port (autoNegotiation supported) can
be used for Iub traffic.
- The Bit Specifying the eth port used to support Iub I/F I&C Parameter indicates which ports
are enable.
- If the nodeB is populated with GE MDA and TypeOfIncomingLink = 3 (GE):
- The Bit Specifying the eth port used to support Iub I/F I&C Parameter indicates which ports
are enable.
3.6.2
ETHERNET
Ethernet frames:
The NodeB transmits and receives ethernet v2 frames.
The NodeB handles the received IEEE802.3 frames but not transmits 802.3 frames.
Per definition:
- An ethernet v2 frame is fill with the EthernetType/Length field value > x0600.
- An IEEE 802.3 frame is fill with the EthernetType/Length field value < x05DC.
autoNegotiation:
On the GE MDA:
- The RJ45 and the SFP electrical ports port supports auto-negotiation,
- The SFP optical ports support partly auto-negotiation.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 182/240
3.6.2.1 ETHERNET MAC@:

The nodeB xCCM+4E1/T1MDA or GE MDA is pre-configured with two universal ethernet
MAC@:
One MAC@ for the Iub traffic (native IP and Hybrid nodeB)
One MAC@ for the local siteLan/debug (FastEthernet dedicated link).
No new MAC@ is needed when introducing the GE MDA.
In the context of NodeB PTP over Ethernet (ptpStack=1), the nodeb reachs the PTP timeserver(s)
through an Ethernet backbone, the nodeB must be configured with the main timeserver MAC@ and
with the fallback timeserver MAC@ if present.
Rule: IubTEG_NodeB_Ethernet_1
If ptpStack=1 (PTP over Eth) then the nodeB must be configured with the main
timeserver MAC@ and with the fallback timeserver MAC@ if present.
Parameters: mainTimeServerMacAddress and fallBackTimeServerMacAddress.
3.6.2.2 VLAN TAGGING (802.1Q):

The vlan tagging is supported as an option on the nativeIP and Hybrid nodeB.
The nodeB doesnt transmit simultaneously untagged and vlan tagged ethernet frames.
The Vlan tagging is activated in the nodeB through the parameter: vlanTaggingControl.
vlanTaggingControl=0, vlan tagging disable
vlanTaggingControl=1, vlan tagging enable
If Vlan tagging enable, the oam vlanId is set through the parameter: nodeBOamVlanId.
nodeBOamVlanId range [1, 4094], default value: vlanId=1
When the vlan tagging is activated, the priority tagging is per default disabled therefore the
transmitted ethernet frames are set with P-tag=0.
Since the vlan tagging is activated in the nodeB, as an option may be configured a telecom
dedicated vlanId and a ptp dedicated vlanId.
Parameter: telecomVlanId.
Parameter: ptpVlanId.
The telecomVlanId and ptpVlanId range: [0, 4095] including some reserved values:
- vlanId = 0:
Context of priority tagging enable and vlan tagging disable.
- vlanId = 4095:
Reserved. This vlanId value shall not be configured.
In Vlan mode, the nodeB supports up to 3 Vlan:
Native IP nodeB Vlan options:
- No Vlan,
- 1 Vlan:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 183/240
All the ethernet frames transmitted by the nodeB are tagged with the same vlanId
whatever the payload is UP, CP, ptp or Oam. The default vlanId is the
nodeBOamVlanId.
- 2 Vlan:
- 1 telecom Vlan: the ethernet frames with telecom payload (CP+UP) are tagged
with the telecom dedicated vlanId
- 1 oam+PTP Vlan: the Ethernet frames with oam and PTP payload are tagged
with the oam dedicated vlanId.
- 3 Vlan:
- 1 telecom Vlan: the ethernet frames with telecom payload (CP+UP) are tagged
with the telecom dedicated vlanId
- 1 PTP Vlan: the Ethernet frames with PTP payload are tagged with the ptp
dedicated vlanId.
- 1 oam Vlan: the Ethernet frames with oam payload are tagged with the oam
dedicated vlanId.
NodeB vlan parameter values according to the vlan formation:
Vlan formation:
No Vlan
1 Vlan
1 telecom vlan
1 oam&ptp vlan
1 telecom vlan
1 oam vlan
1 ptp vlan
isTelecomInVlan
1 (sameAsOam)
2 (other)
2 (other)
telecomVlanId
na
na
Telecom vlanId
Telecom vlanId
isPtpInVlan
1 (sameAsOam)
1 (sameAsOam)
2 (other)
ptpVlanId
na
na
na
Ptp vlanId
Parameters:
Table 32, NodeB vlan parameter values
Hybrid nodeB Vlan options:

- No Vlan,
- 1 Vlan: the transmitted ethernet frames with I/B Hspa payload are tagged with the
telecom dedicated vlanId.
Case of hybrid Iub, if vlan tagging is required then set parameter:
isTelecomInVlan = 2.
Remarks:
- The values isTelecomInVlan = 1 and isPtpInVlan = 1 are forbidden in the
context of Hybrid Iub.
- The parameter ptpVlanId doesnt apply in the context of Hybrid Iub.
3.6.2.3 PRIORITY TAGGING:

The priority tagging is supported as an option on the nativeIP and Hybrid nodeB.
The supported P-Tag value range is [0, 7] with P-Tag=7 the highest priority and P-Tag=0 the
lowest priority.
The priority tagging is activated through the parameters: pBitMarkingActivation. Per Default PTagging is disable.
If the priority tagging is activated then the DSCP to P-Tag mapping table must be configured.
The parameter: dscpToPBit takes into consideration the DSCP 3 MSB for the mapping (e.g.: no
distinct P-Tag mapping for AF41 and AF42).
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 184/240
Suggested DSCP to P-Tag mapping table:

DSCP
P-Tag
EF
AF4x
AF3x
AF2x
AF1x
DE
CS6
CS7
Table 33, DSCP to P-Tag mapping

Remark: P-Tag=2 not used since set to spare in 802.1D.
The Priority tagging may be activated within the nodeB whereas the vlan tagging is disable:
To perform the priority tagging without Q-Tagging:
- the vlan tagging must be enabled and
- oam vlanId set to Zero.
Remark: on Vlan activation, the priority tagging is disabled per default, the transmitted ethernet
frames are tagged with P-Tag=0.
3.6.2.5 HUBBING
3.6.3
IP
IPv4 supported. IP v6 not supported.
The IP MTU is configurable on both hybrid and native IP nodeB. The NodeB configured MTU applies to
all kinds of IP traffic forwarded by the nodeB on the Iub interface with exception of the PTP traffic.
Parameter: MTUSize, range = [541, 1500 bytes], default= 1500 bytes.
Remarks:
- It is expected that the IP packets with PTP payload are small size (541 bytes), reason why the
MTUSize parameter doesnt apply to PTP IP traffic.
- Jumbo frames are not supported.
3.6.3.1 OWN IP@:

Hybrid nodeB:
The NodeB is configured with two external IP@:
- 1 telecom external IP@ with its associated subnetMask and one single associated
nextHop IP@. This IP@ is manually configured and can not be allocated by a DHCP
server.
Parameter: telecomNodebIp@ and telecomNodebSubnetMask.
Rule: IubTEG_NodeB_IP_1
The parameters telecomNodebIp@ and telecomNodebSubnetMask
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 185/240
must be configured in the hybrid nodeB.

- 1 oam external IP@. This IP@ is either set during I&C or is assigned by a DHCP server.
The NodeB telecom IP@ is exchanged, call by call, with the RNC during the NBAP Radio
Link setup procedure.
Native IP nodeB:
Three nodeB configuration alternatives:
- One single own IP@: used for telecom, ptp and oam traffic, it is either set during
I&C or obtained from a DHCP server
- Two own IP@: one telecom IP@ and one oam/ptp IP@.
The telecom IP@ must be configured whereas the oam IP@ it is either set during
I&C or obtained from a DHCP server.
- Three own IP@: one telecom IP@, one oam IP@ and one PTP IP@.
The parameter IP RAN / dhcpUsed must be set to False to desable the
DHCP for the telecom IP@, case of hybrid and nativeIP nodeB.
Parameter setting according to amount of nodeB own IP@:

Own IP@
1 IP@
1 telecom IP@
1 oam&ptp IP@
1 telecom IP@
1 oam IP@
1 ptp IP@
Parameters:
I&C oam IP@, default IP@:
nodeB oam IP@
IP Address of the OMC-B
nodeB oam subnet mask
Sub-net mask
Telecom IP@:
False
True
telecomNodebIp@
Na
Telecom IP@
telecomNodebSubnetMask
Na
Telecom subnetMask
isSpecificTelecomNodebIp@Used
PTP IP@:
False
False
ptpNodebIpAddress
Na
Na
ptp IP@
ptpNodebIpSubnetMask
na
na
ptp subnetMask
isSpecificPTPNodebIpAddressUsed
True
Table 34, nodeB own IP@ parameters
The whole telecom traffic (controlPlane and userPlane) is initiated and terminates on the same
nodeB IP@, either the nodeB telecom IP@ or the nodeB oam IP@.
When the nodeB is configured with several own IP@, each IP@ must belong to
different subnets.
Interaction between: # vlan and # own IP@:

- If no Vlan, the nodeB can be configured with 1, 2 or 3 own IP@,
- If 1 Vlan, the nodeB must be configured with 1 own IP@,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 186/240
- If 2 Vlan (1 telecom vlan & 1 oam/ptp vlan), the nodeB must be configured with 2
own IP@ (1 telecom own IP@ & 1 oam/ptp own IP@),
- If 3 Vlan (1 telecom vlan, 1 oam vlan & 1 ptp vlan), the nodeB must be configured
with 3 own IP@ (1 telecom own IP@, 1 oam own IP@ & 1 ptp own IP@).
Remark: this rule results from test limitation, not from technical limitation.
DHCP:
The DHCP may be used for nodeB oam IP@ assignment, case of nativeIP, hybrid and atm
nodeB.
The DHCP must not be used for nativeIP and hybrid nodeB telecom IP@ assignment.
Parameter: IPRAN/dhcpUsed
3.6.3.2 DESTINATION IP@:

Oam:
I&C parameter.
PTP:
In the context of NodeB PTP over UDP/IP (ptpStack=0), the nodeB reachs the PTP
timeserver(s) through an Ethernet or IP backbone, the nodeB must be configured with
the main timeserver IP@ and with the fallback timeserver IP@ if present.
Parameters: ptpPreferredTimeServerIpAddress and ptpFallBackTimeServerIpAddress.
If ptpStack=0 (PTP over UDP/IP) then the nodeB must be configured with the main
timeserver IP@ and with the fallback timeserver IP@ if present.
The telecom destination hosts IP@ is not configured, the RNC transmits to the nodeB through
NBAP protocol the IP@ of the RNC Host in charge of handling the call. The NodeB
forwarding table must be configured in such a way to be able to route these IP@.
3.6.3.3 FORWARDING TABLE:

The nodeB supports only static routing.
The nodeB forwarding table is configured with one gateway IP@ per telecom, oam and ptp IP
routes.
The oam gateway IP@ is configured through the I&C.
Parameter: NodeBFirstHopRouterIP@.
The oam IP routing is used as default IP routing.
The telecom and PTP routing information are configured through the RAN IP parameter:
routingTableList. The routingTableList can be configured with up to 21 entries.
- One or several IP routes are configured for the RNC controlPlane, the RNC
userPlane and the PTP timeserver(s).
- One or several gateway IP@ / subnetMask are assigned to each IP route:
The gateway IP@ assigned to the telecom IP route, is the IP@ of the adjacent IP
router port (case of IP backbone on the Iub) or the RNC VR PP (case of Ethernet
backbone on the Iub).
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 187/240
The gateway IP@ assigned to the PTP route, is the IP@ of the adjacent IP router port
(case of IP backbone on the Iub) or the timeserver IP@ (case of Ethernet backbone
on the Iub).
A subnet size /30 is enough as long as no specific IP backbone feature activated.
Remark: with exception of the telecom contolPlane, this section applies also to the hybrid
nodeB.
3.6.3.4 QOS:
3.6.3.4.1 DSCP, MARKING

The nodeB supports the differentiatedService model.
The nodeB supports the DSCP values: EF, AFx, CS6, CS7 and DE.
On the Hybrid NodeB, the DSCP marking applies to the UP Hspa I/B.
On the native IP NodeB, the DSCP marking applies to UP, CP and oam traffic.
The IP packets with userPlane payload are marked with the DSCP value received from the RNC
(NBAP/TNL Qos IE). The NodeB rejects the NBAP RL Setup with an unrecognized DSCP value.
nodeB
RNC
NBAP RL Setup/Add/Reconf Request

- TLA IE: RNC IP@ (NSAP format)
- Binding IE: RNC UDP port
- TNL QOS: DSCP value.
NBAP RL Setup/Add Resp

- TLA IE: nodeB IP@ (NSAP format)
- Binding IE: nodeB UDP port
TEG
Figure 3-79, userPlane DSCP assigned by the RNC
The DSCP is configured for the IP packets with a payload other than userPlane.
The parameter: IP RAN DSCP is used to assign a DSCP value to each kind of nodeB traffic:
NodeB traffic
Default DSCP
Telecom CP (SCTP)
AF41
Proprietary umts heartBeat & UDP_Attach
AF41
PTP highPriority
CS7
PTP lowPriority
oam
DE
Table 35, DSCP mapping
Remark: Each DSCP value is mapped to one P-Tag value if Ethernet P-Tagging is enabled.
3.6.3.4.2 QUEUEING
The nodeB supports 8 EP (EmissionPriority): EP0 to EP7.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 188/240
One queue is assigned per EP.

Each EP is configured with a queue size, a PIR and a CIR value.
QueueSize:
The queue size is configured through the parameter: EpToQueueSize. The EpToQueueSize
parameter is fill with a percentage of uplink queueing available memory.
The EP0 to EP7 EpToQueueSize must be lower than 100%.
If queueSize=0% or if PIR=CIR=0%, the EP transmission is disabled.
DSCP to EP mapping:
The utran traffic is classified based on the DSCP value. Each resulting stream is assigned to an
EP.
The nodeB is configured with the DSCP to EP mapping table through the parameter:
DscpToEp.
Traffic
DSCP
EP
Qsize%
CIR%
PIR%
PTP
CS7
10
Conversational
EF
20
20
Dedicated SRB
CS6
20
Streaming + SCTP
AF4
17
25
R99 I/B
AF3+AF2
35
100
Hspa I/B + oam
AF2+DE
45
100
Table 36 QOS Parameter default values
Remarks:
- Only the DSCP 3 mostSignificantBits are taken into consideration in the DSCP to EP
mapping table.
- One or several DSCP values are mapped to one EP.
Scheduling:
The perEP queues are served according the scheduling policy.
The nodeB supports different scheduling algorithm: PQ, WRR, per default the PQ is enable.
3.6.3.5 TRAFFICSHAPING
- The nativeIP and hybrib nodeB populated with xCCM+4E1 MDA supports IP trafficShaping for the
userPlane traffic. The TS is not supported for the controlPlane, PTP and oam.
The trafficShaping is performed per EP. The EP egress traffic is shaped based on the parameters:
- ulBandwidth,
- CIR (Commited Information Rate),
- PIR (Peak Information Rate).
- The nativeIP and hybrib nodeB populated with xCCM+GE MDA supports IP trafficShaping for the
userPlane, controlePlane, oam and PTP traffic. The traffic shapping applies at EP level and at
interface level:
The EP egress traffic is shaped based on the parameters:
- ulBandwidth,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 189/240
- PIR (Peak Information Rate),

- CIR (Commited Information Rate).
The interface egress traffic is shaped based on the parameters:
- ulBandwidth.
The trafficShaping is activated as an option:
If ulBandwidth = 0 the traffic shaping is disabled, the egress traffic is handle with one single
global queue, therefore no more qos handling. The uplink traffic is then up to linkRate.
If ulBandwidth 0 the traffic shaping is enabled.
The ulBandwidth parameter is set with the portion of the NodeB ethernet link bandwidth allowed for
the Iub uplink traffic (controlePlane + userPlane + ptp + oam).
Each EP is configured with a CIR and PIR values through the parameters: EpToCIR and EpToPIR.
The CIR and PIR parameters are configured with a percentage of the configured ulBandwidth.
The CIR and PIR are involved in the per EP trafficShaping.
Minimum rates:
- NodeB populated with the 4 PCM MDA:
PIR and CIR must be configured either with Zero or a value greater or equal to 100 kb/s
- NodeB populated with the GE MDA:

Min_Rate
< ulBandwith 100 Mb/s
100 kb/s
100 Mb/s < ulBandwith 300 Mb/s
300 kb/s
300 Mb/s < ulBandwith 1000 Mb/s
1000 kb/s
EP0 to EP7 CIR must be lower than 100%, minimum CIR value: 5%.
- PIR CIR.
3.6.3.6 EDCHLOCALCONGESTIONCONTROL
The eDchLocalCongestionControl is triggered by perEP queue overflow (queue occupancyRate=100%).
When perEP queue overflow occurs, whatever the EP, the xCEM reduces the hsupa traffic.
The eDchLocalCongestionControl is activated as an option.
Parameter: BtsEquipment: edchLocalCongestionControlActivation.
The eDchLocalCongestion can be activated only if the trafficShaping is enable.
The eDchLocalCongestionControl is supported on nativeIP nodeB and hybrid nodeB both atm and ip
legs.
This mechanism applies to all the EP nevertheless only eDch traffic can be controlled by reducing grants
to UE.
3.6.4
UDP & TCP & SCTP PORTS:

Each telecom, ptp and oam application is identified either by an UDP, TCP or SCTP port,
reason why each of these applications may be identified at IP level either by a shared IP@ or
dedicated IP@.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 190/240
NodeB
NodeB
userPlane
Proprietary
umts
heartBeat
Proprietary
Attach_UDP
Nbap
OAM
UDP
UDP port
port
UDP
UDP port
port
UDP
UDP port
port
SCTP
SCTP Port
Port
TCP
TCP port
port
Telecom
Telecom Host
Host IP@
IP@
TIL,
Telnet
Radius
TCP
TCP port
port UDP
UDP port
port
OAM
OAM Host
Host IP@
IP@
PTP
UDP
UDP port
port
PTP
PTP Host
Host IP@
IP@
FE
FE or
or GE
GE link
link
TEG
Figure 3-80 UDP, TCP and SCTP ports, case of telecom IP@ and PTP IP@
- PTP over UDP: the IETF reserves the port 320 or 319 for the PTP,
- Iub userPlane UDP: the RNC allocates the UDP port for the userPlane from the range:
[49152, 65535],
- UMTS proprietary UDP_Attach: one port is configured from the range: [49152, 65535], see
3.6.6 AttachUdpPortNumber parameter.
- UMTS proprietary heartBeat: one port is configured from the range: [49152, 65535] through
the parameter: RAN IP heartBeatUDPPortNumber. Default value: 65535, range: [49152,
65535]
The nodeB must be configured with the Umts_Proprietary_HeartBeat UDP port which
matches with the Umts_Proprietary_HeartBeat UDP port configured on the RNC side.
3.6.5
SYNCHRONISATION
The nativeIP NodeB synchronization may be based on different method:
- IEEE 1588 v2, a.k.a. Precision Time Protocol (PTP),
- Local GPS,
- E1/T1 line timing: PCM is only used to synchronise the nodeB, no telecom traffic transmited
over the PCM.
- Synchronous Ethernet:
The synchronisation method is configured:
BtsEquipment::synchronizationMethodList:
Value: 0- PTP, 2- SynE, 3- dedicatedE1T1, 4- gpsClock, 5- sync2048kHz, 6dedicatedE3T3
The parameter BtsEquipment::synchronizationMethodList is class 3 parameter and
can be modified online from OMCB.
The PTP and syncE values are available only for the nativeIP nodeB.
3.6.5.1 SYNCHRONOUS ETHERNET

.The syncE (synchronous Ethernet) is a node-by-node based layer-1 frequency synchronization
mechanism.
The NodeB recovered clock accuracy is not affected by Packet Delay Variation and network congestion
conditions.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 191/240
The nodeB doesnt support combined [SyncE+PTP] mode .

The syncE is supported in the nativeIP NodeB populated with the xCCM/xCCM-U and GE/OC3 MDA.
Not applicable to ATM nodeB, Hybrid nodeB using the mother card ethernet link.
Not supported over the xCCM/xCCM-U FE port.
The three GE MDA ports: SFP1, SFP2 and RJ45 support synchroEthernet:
- The SFP1 and SFP2 support SynchroE only over optical fiber + 1000baseSX/LX
optical SFP transceiver. The 10/100/1000baseT electrical transceiver doesnt
propagate the synchroEthernet clock.
- The RJ45 supports synchroEthernet over copper cable.
Rule: IubTEG_NodeB_syncE_1
SyncE is available on SFP1 and SFP2 fiber transceiver and RJ45 port.
The GE port works only in syncE Slave mode, as long as no hubbing configured on the nodeB.
Within the NE (nodeB, EthernetSwitches), the clock supporting synchronous Ethernet networks is
called EEC.
The NodeB EEC provides +/- 50 ppb frequency accuracy as long as locked to the PRC traceable clock,
and +/-4,6 ppm frequency accuracy in free running mode.
Two options are specified for EEC:
EEC-Option 1: applies to Synchronous Ethernet equipment designed to interwork with
networks optimized for the 2048 kb/s hierarchy.
EEC-Option 2: applies to Synchronous Ethernet equipment designed to interwork with
networks optimized for the 1544 kb/s hierarchy.
SYNCHRO::eecOption,
Specifies the clock hierarchy to be used for syncE.
Value: 0- 2048kHz, 1- 1544kHz. Default value: 0
All the NE within a synchronization chain must be configured with the same EEC option.
3.6.5.1.1 NETWORKING:
Each network element in SyncE chain recovers clock from an ingress line and supplies to the next nodes
a synchronizing clock that is jitter attenuated and traceable to the ingress one.
The use of syncE requires that all network elements in the synchronization chain between the
PRC and the nodeB support synchE.
The longest synchronization network reference chain should not exceed:

- 10 SSUs and 60 EEC option 1, and
- Up to 20 EEC between two SSU.
Assuming no SSU in the synchronisation network:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 192/240
The nodeB is not more than 20th SyncE element from PRC.
Each of the 3 GE MDA ports can be connected to either Ethernet, xDSL, Wave backhaul or Satellite
(maximum one hop) with syncE enable as long as the backhaul nodes support synchroEthernet
compliant with ITU (G8261, G8262, G8264).
3.6.5.2 PTP
The PTP (Precision Time Protocol, IEEE1588 v2) provides both Frequency synchronization & Time
synchroniZation. The UMTS retrieves only Frequency synchronization.
The PTP is a layer2/3 synchronization method. It uses either the services from IP (PTP/UDP/IP) or the
services from Ethernet (PTP/Ethernet).
It is not mandatory that all the intermediate nodes be compliant with PTP.
The NodeB recovered clock accuracy is impacted by congestion condition and Packet Delay Variation
introduced by the network (between PRC and NodeB), therefore highest priority must given to the PTP
traffic (3.6.3.4).
Remark: The NodeB recovered clock accuracy is not impacted by Packet Delay.
PTP Requirements on the Iub:
Packet Delay Variation
< 500 s
Packet Delay Variation for the 10% fastest packets
< 150 s
Packet Loss Ratio
1 E-01
The PTP is supported on the nativeIP nodeB .
3.6.5.2.1 PTP PROTOCOL TRANSPORT SERVICES:

The PTP protocol uses either the services from UDP or Ethernet.
The transport type used by PTP is configured: ptpStack parameter value: ptpOverUdpIp,
ptpOver802_3.
- If PTP over Ethernet, the ethernet protocolType field value= 88F7 hexa.
- If PTP over UDP, the UDP port number = 319 and 320.
The PTP over ethernet is not supported if:
- the nodeB interworks with an IP backbone,
- the PTP TimeServer not support this stack.
The PTP over Ethernet is supported if the nodeB interworks with an ethernet backbone.
Rule: IubTEG_NodeB_PTP_1
When Iub interface uses the services of a layer3 backbone, the PTP over Ethernet must not
be chosen.
3.6.5.2.2 PTP TRANSPORT ADDRESSING:

The PTP may be configured in different Transport addressing modes:
If PTP over UDP:
The IP packet source IP@ is either:
the nodeB own oam IP@,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 193/240
the nodeB own dedicated PTP IP@.

If PTP over Ethernet:
The Ethernet frames are either:
Untagged,
Tagged with the oam vlanId
Tagged with the dedicated ptp vlanId.
The nodeB is configured with main and backup PTP timeserver Ethernet@ (see 3.6.2 )
The nodeB is configured with main and backup IP@ (see 3.6.3 )
3.6.6
SIGTRAN/SCTP
The nodeB supports:
- 1 SCTP endPoint,
- 1 single SCTP association,
- Up to 7 UL streams and 7 DL streams on the SCTP association,
- SCTP Path MTU discovery,
- SCTP HeartBeat.
Remark: the nodeB rejects the SCTP_Init message if the amount of requested streams is not equal to 7,
even if the amount of requested streams per association is negotiated between the RNC and the nodeB.
SCTP Port:
The nodeB must be configured with its own SCTP port.
Parameter: btsSctpPortNumber
This value is communicated to the RNC within the Attach_UDP message and used as destination SCTP
port in the SCTP_Init message sent by the RNC.
SCTP Timers
The NodeB SCTP timers are set with the default values:
NodeB SCTP timers and parameters
ackDelay
200 ms
heartbeatInterval
3000 ms
maxPathRtx
retransmissionTimeOutInitial
800 ms
retransmissionTimeOutMax
3200 ms
retransmissionTimeOutMin
800 ms
Table 37 NodeB default SCTP Timer values
SCTP HeartBeat:
Both the NodeB and the RNC run the SCTP heartBeat.
- The SCTP HeartBeat is always enabled within the nodeB,
- The SCTP HeartBeat interval is configurable.
Proprietary Attach_UDP:
To handle the proprietary attach_UDP procedure, the nodeB must be configured with:
- The RNC OMU IP@. The OMU IP@ is used as destination IP address in the IP packet with
proprietary Attach_UDP payload.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 194/240
Parameter: AttachRncIpAddress
The nodeB own UDP port for Attach_UDP. The UDP port is used as source UDP port in the IP
packet with proprietary Attach_UDP payload.
Parameter: AttachUdpPortNumber(default=65534)
Rule: IubTEG_IP-nodeB_SCTP_1
The same UDP port value must be configured in both:
- The RNC / IubAttachUdpPortNumber parameter and
- The nodeB / AttachUdpPortNumber parameter.
3.6.7
A value identifying the nodeB on the RNC side. The value of the RNC IubIf ( 5.4.1) is used as
nodeB identifier.
Rule: IubTEG_IP-nodeB_SCTP_2
The parameter AttachNodeBId is set with the IubIf value identifying the nodeB on the RNC
side.
DHCP
The DHCP Server may be used as an option for NodeB OAM IP @ acquisition whatever atm, hybrid or
native IP nodeB. Other nativeIP nodeB IP@ are configured on the nodeB (Telecom, PTP IP@).
Furthermore the DHCP Server provides the nodeB with subnetMak, nodeB TCP port, OAM IP@ & TCP
port related to the OAM flow.
DHCP RelayAgent:
- Case of atm backbone on the Iub interface, the atm RNC plays the role of DHCP relayAgent.
- Case of ip backbone on the Iub, it is preferable that an IP router within the backbone plays the
role of DHCP relayAgent.
VRRP:
When the VRRP feature is activated in the router(s) in front of the nodeB, the DHCP Server
must provide the nodeB with a subnet large enough to include VR primary IP@ and backup
IP@ (s).
Therefore the DHCP Server must be configured with a subnetMask size at least /29 for that
nodeB.
Rule: IubTEG_IP-nodeB_DHCP_1
The subnetMask configured per nodeB in the DHCP Server must be at least /29 if VRRP enable
in the IP Router(s) in front of the nodeB.
3.8
MICRO NODEB ATM (BTS 1120)
3.8.1
TRANSMISSION:
The NodeB atm supports the following kind of transmission links:
- Supports: E1, T1, J1,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 195/240
Up to 8 x E1/T1/J1
Ethernet 10/100 baseT for local Maintenance tool.
Not supported:
- Fractional E1/T1/J1 links (drop&Insert),
Atm bandwidth:
Case of E1 on the Iub interface, the micro NodeB atm must be configured with the E1 reserved
bandwidth (timeslot 0 and 16) and then the E1 bandwidth available for the user.
The TimeslotUsage parameter value is a 32 bit length word, in which each bit is a
representation of the E1 frame timeslot. The bits associated to the reserved timeslots are set to
0, whereas the bits associated to the timeslots usable by user are set to 1.
According to the ITU recommendation related to atm over E1, the timeslot 0 and 16 are
reserved., therefore the parameter timeslotUsage is set as following:
Rule: IubTEG_NodeB atm- 01
Case of E1, set timeslotUsage = 7FFF 7FFF
CRC4:
The CRC is activated as an option through the parameter lineFraming = basicFraming /
multiFraming.
If CRC is activated in the Nodeb, take care it is also activated in the adjacent node.
Synchronization:
The synchronization is derived from one active PCM. Each PCM (0 to 7) within an IMA LG
may be selected by configuration as primary synchronization source.
When the PCM used as primary synchronization source is outOfService, the NodeB selects
another still active E1 as primary synchronization source.
If no PCM may be used as primary synchronization source, the NodeB local clock is used as
synchronization source for the radio interface.
3.8.2
ATM:
Atm characteristics supported:
- Scrambling according to ITU, activated as an option,
Command: linePayloadScrambling = According to Standard, means scrambling is
automatically activated if the received cell is scrambled.
AtmConnection and atmConnection Identifier supported:
- Pvc,
- Aal2, aal5,
- Up to 16 aal2 vcc
- Up to 2 Vpi values may be configured on the NodeB Iub interface.
- UNI Vpi range: [0-255], Vci range: [32-65535].
IMA characteristics supported:
- IMA version 1.1, does not support IMA1.0,
- Up to one IMA LG,
- From 1 to 8 E1/T1/J1 within an IMA LG,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 196/240
IMA Identifier range: [0-255],

IMA Defense mechanism is identical to the NodeB IMA Defense.
Atm OAM characteristics:

- Activation/deactivation of F4 and F5 atm oam flows through the parameter: f4f5flow, per
default these flows are not activated.
Rule: IubTEG_NodeB atm- 02
Activate the F5 oam flows, to satisfy the RNC aal2CongestionManagement.
F4f5flow = F5 inUse.
Performance management:
- Collecting measurements from the different blocks within the BTS,
- Handling of PM jobs,
- Reporting of results.
Test functions:
- Monitoring status of physical link, IMA, F4/F5 etc,
- Ordering test model transmission,
- loopBack supported.
Qos:
-
Supported ServiceCategory: UBR, UBR+, CBR, rtVbr and nrtVBR,

Recommended serviceCategory per atmConnection:
Rule: IubTEG_ Iub_NodeB atm - 03

VCC
SC recommended on the NodeB
UP DS
rtVbr
UP NDS
nrtVBR
CP
rtVbr
CCP
rtVbr
HSDPA
UBR+
OAM
UBR+
TrafficManagement:
The NodeB performs No policing and performs trafficShaping at Vc level.
List of the trafficManagement parameters:
- PCR:
- PCR unit is cells/s,
- The PCR is mandatory for all vcc whatever the SC,
- PCR range = [ 1, 35 000 c/s],
- The PCR value can not exceed the linkRate,
- The maximum PCR value 4528 c/s if the vcc is configured on an E1,
- The maximum PCR value X * 4490 c/s if the vcc is configured on an IMA LG
composed of X E1,
- The maximum PCR value 3622 c/s if the vcc is configured on a T1.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 197/240
SCR:
- SCR unit is cells/s,
- SCR range = [ 1, 35 000 c/s],
- The SCR must be set for the vcc serviceCategory = rtVbr and nrtVbr, unused for other SC.
- 1 SCR PCR.
MBS:
- The MBS must be set for the vcc serviceCategory = rtVbr and nrtVbr,
- MBS 2,
MCR:
- The MCR must be set for the vcc serviceCategory = UBR+, unused for other SC.
- MCR range = [ 1, 35 000 c/s],
- 1 MCR PCR,
Atm CAC, rules taken into account by the atm CAC:
3.8.3
VBR Vcc SCR linkRate,

per link, CBR Vcc PCR linkRate,
per link, CBR Vcc PCR + VBR Vcc PCR + UBR+ Vcc PCR linkRate,
per link, CBR Vcc PCR + VBR Vcc SCR + UBR+ Vcc MCR linkRate,
CBR Vcc PCR + VBR Vcc PCR + UBR+ Vcc PCR linkRate x * linkRate,
per link,
If atm oam F4/F5 flow is activated, the linkRate taken into consideration by the CAC
is reduced by the bandwidth reserved for the F4/F5 atm oam vcc.
If IMA is configured, the linkRate taken into consideration by the CAC is reduced by
the IMA overhead. Eg: E1 bandwidth when inserted in IMA = 4490 c/s.
AAL2
Aal2 PathId:
The pathid is coded over 4 bytes, pathid range: [1, 7F FF FF FF]
Rule: IubTEG_ Iub_NodeB atm - 04
The RNC PathId being coded on 2 bytes whereas the NodeB atm pathid is coded on 4 bytes,
the Pathid value must be dictated by the RNC.
Aal2 CPS:
The aal2 CPS Packet payload length is configurable, choice of 45 or 64 bytes length:
Parameter
Meaning
Value
CPS-INFO
Maximal length of the CPS-INFO field in AAL2 CPS

Packets, i.e. CPS packet payload.
45 or 64 bytes
Rule: IubTEG_ Iub_NodeB atm 05
The aal2 CPS Packet payload must be 45 bytes length; CPS-INFO parameter = 45 bytes.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 198/240
3.8.4
SAAL:
List of the NodeB Saal parameters:
Parameter
Default value
Range
[1 10]
MaxCC
MaxPD
25
Timer_POLL
750 milliseconds
[100 5000] milliseconds
Timer_KEEP-ALIVE
2000 milliseconds
Timer_NO-RESPONSE
7000 milliseconds
Timer_IDLE
15000 milliseconds
Timer_CC
1000 milliseconds
The Timer_NO-RESPONSE should be set to at least the sum of Timer_KEEP-ALIVE and the
roundTripDelay:
Timer_NO-RESPONSE > Timer_KEEP-ALIVE + roundTripDelay.
The Timer_IDLE should be set to a considerably larger value than the Timer_KEEP-ALIVE:
Timer_IDLE >> Timer_KEEP-ALIVE
3.8.5
IP:
The NodeB support IPv4.
- DHCP:
The parameter dhcpInUse is set with a Boolean value to indicate if a DHCP server assigns an IP@
to the NodeB.
- inverseARP:
The inverseARP is supported.
- IP Addresses:
Up to two IP Addresses are configured in the NodeB:
- One IP Address identifying the NodeB UMTS OAM Host point of termination of the Iub
OAM IP over atm vcc. This Ip Address is called: ipoaIpAddress.
- One IP Address identifying the NodeB Host point of termination of the
LocalManagementTerminal Ethernet interface. This Ip Address is called: ethPortIpAddress.
Parameters:
ethPortIpAddress:
Range: [0.0.0.0 255. 255. 255. 255];
Default value: 192.168.0.2.
ethPortIPSubnetMask:
Range: [255. 255. 255. 255- 0.0.0.0];
Default value: 255.255.255.0.
IpoaIpAddress:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 199/240
Range: [0.0.0.0 255. 255. 255. 255];

IpoaIPSubnetMask:
Range: [255. 255. 255. 255- 0.0.0.0];
IpDefaultGateway: equivalent to the nextHop.
Range: [255. 255. 255. 255- 0.0.0.0];
MgrIpAddress1: OMC-B OAM Plateform IP@:

Range: [255. 255. 255. 255- 0.0.0.0];
MgrPort1: UDP port:
Range: [1-65535];
Default: 8162.
ntpIpAddress (networkTimeProtocol): same IP @ as for MgrIpAddress1:
Range: [255. 255. 255. 255- 0.0.0.0];
MgrIpAddress2: an optional second OAM Plateform IP@:
Range: [255. 255. 255. 255- 0.0.0.0];
MgrPort2: UDP port:
Range: [1-65535];
Default: 162.
Both the own NodeB IP addresses:
- ipoaIpAddress
- ethPortIpAddress
must belong to two different subnets.
Beside is configured the IP DefaultGatewayIpAddress in the same subnet as the ipoaIpAddress.
3.8.6
UMTS TRAFFIC FLOWS:

On Iub interface, the NodeB atm may be configured with:
- 1 CP Vcc, SC= rtVbr,
- Up to 3 CCP vcc, SC= rtVbr,
- Up to 16 aal2 Vcc, SC= rtVbr, nrtVbr,
-
Oam Vcc:
The Oam Vcc is per default configured with UBR+ and PCR = 150 c/s.
CP & CCP Vcc:

There is one common traffic control part and a number of dedicated traffic control parts inside
each NodeB.
Only one common traffic control part will be active in one NodeB, therefore one CP Vcc.
Each dedicated traffic control part uses one communication control port, up to 3 CCP Vcc:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 200/240

On a NodeB is configured:
- 1 CP vcc,
- As many CCP vcc as amount of sectorEquipment, up to 3 sector Equipment in a
NodeB.
UP Vcc:
On the NodeB are configured as many couple of (UP DS, UP NDS) Vcc as amount of E1 in the
IMA LG.
Hsupa Vcc (E-DCH):

HSUPA will be available as a software upgrade in a future release.
Each baseband block will be able to handle support common channels plus up to 30 simultaneous
radio links using HSDPA for downlink and HSUPA for uplink (including SRB).
- An Hsupa channel is always associated to a Hsdpa channel for the downLink leg.
- The NodeB CAC allows up to 30 simultaneous hsupa users.
3.9
PICO NODEB ATM (BTS 1010)
3.9.1
TRANSMISSION:
Supports E1 or Stm1/OC3 clearChannel.
Up to 4 E1 120 ohms twisted pair. Two E1 are available per ports:

- Physical port A: Pcm1 1 & 3,
- Physical port B: Pcm1 2 & 4,
Supports the CRC4 multiframe and basic framing,
Provides performance monitoring based on CRC4 operations.

Not supported:
3.9.2
Fractional E1.
ATM:
The pico NodeB atm is compliant with R35.
AtmInterface Type:
- Supports UNI interface type.
- Doesnt support GFC (GenericFlowCtrl). The GFC field is filled with 0000.
AtmConnection Type:
- Only PVC is supported.
AtmConnection Identifiers:
- Supports one Vpi per transmission link.
- Up to 2 vpi values on one picoNodeB.
- Two vpi values are supported in case of IMA.
AtmConnection Amount:
- Up to 16 aal2 vcc (TRB, dSRB and cSRB).
- 1 or 2 aal5 vcc:
- If 1 aal5 Vcc is configured, it carries both nbap-c and nbap-d,
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 201/240
If two aal5 Vcc are configured, one carries the nbap-c traffic (CP vcc), the second carries the
nbap-d traffic (CCP vcc),
1 aal5 vcc for UMTS OAM.
IMA:
-
IMA 1.1 according to [R57].

The IMA frame length is fixed to M=128 cells.
The IMA LG is composed of all the populated E1. If one E1 on the NodeB, IMA is not supported.
The IMA LG Identifier is configurable.
IMADefense: same behavior as the NodeB, see 3.5.9.6.
OAM:
- The endToEnd F4 and F5 flows supported according to R[36].
- The endToEnd VP and VC LoopBack supported.
Upon reception of AIS, the picoNodeB returned upstream a RAI (= RDI) according to R[34].
Atm Qos:
- ServiceCategory:
- Cbr, rt and nrtVBR, Ubr and Ubr+ are supported,
- Each SC can be assigned to each kind of vcc,
- CAC:
No CAC implemented in the PicoNodeB,
-
OverBooking:
Not Applicable since any CAC.
TrafficManagement:
- TrafficDescriptor:
The set of trafficDescriptor parameters to configure depends on the atmConnection
serviceCategory:
- Cbr vcc: PCR,
- Vbr vcc: PCR, MBS and SCR,
- UBR vcc: PCR,
- UBR+ vcc: PCR and MCR (Minimum Celle rate)
The PCR is a mandatory parameter for all the serviceCategories.
The PCR range is [0; IMA LG bw].
- TrafficShaping/Policing:
The trafficShaping at Vc level is always activated.
ShapingRate = PCR: whatever the Vcc serviceCategory, the configured PCR, and only this
parameter, is considered as the shapingRate (=GCRA(PCR) from the atmForum121).
The SCR, MBS are not taken into consideration by the trafficShaping.
The Policing is not supported.
3.9.3
AAL2:
Aal2 Qos: Yes
Aal2 Signaling:
- Supports ALCAP according to R[46].
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 202/240
When interworking with ALU RNC, no Alcap protocol is running on the Iub interface, the Alcap
function is provided by an enhanced Nbap-c. See R[310].
Pathid range: the pathid is coded over 4 bytes:
Rule: IubTEG_ Iub_picoNodeB atm 01
The RNC PathId range being smaller that the picoNodeB range, the configured pathids must
satisfied the RNC range.
A2EA: the NodeB must be configured with its own A2EA if Alcap is run on the Iub interface. This is not
the case when interworking with the ALU RNC.
3.9.4
IP:
-
3.9.5
IP v4 is supported, not IPv6,

The subnet size is configurable,
IP over atm encapsulation type: LLC encapsulation.
InverseARP is not supported.
UMTS TRAFFIC FLOWS:

The picoNodeB supports R99, hsdpa and Hsupa user traffic flows.
3.10
7670
The 7670 RSP provides a high capacity atm switching for large size atm backbone and all the sdh
hierarchy access rates from stm1/oc3 to stm16/oc48 either clearChannel or channelized nevertheless no
support for pdh link. The 7670 RSP has been specified to fulfil the backbone core services.
The 7670 ESE has been specified to fulfil the backbone edge services, the 7670 supports both pdh and
sdh access up to stm4/oc12, IMA E1/T1.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 203/240
7670 RSP (Release 6-2)
7670 ESE
Product architecture:
Either standalone or under control of the RSP
Either single shelf or Multishelves.

Multishelves architecture, up to 15 peripheral shelve
#slots for interface card/shelf

12 line cards
SingleShelf: 14 line cards

MultiShelf: 208 line cards (1+1 Config)
switching fabric throughput:

3,2 gb/s
from 50 to 450 Gb/s (bi-directional, redundant)
Roles:
atmSwitch, ip router, ethernet switch

Dslam.
atmSwitch, ip router, ethernet switch

Dslam (g.SHDSL),
MPLS switch (LER and LSR).
Synchronisation:
BITS E1/T1
Stratum3
internal (freerun)
Transmission:
interface card:
pdh
8p T1/E1 with IMA

32p T1/E1 with IMA
sdh/sonet up to oc12/Stm4
1p oc3/Stm1 unchannelized
4p oc3/Stm1 unchannelized
1p oc12/stm4 unchannelized
1p oc3/Stm1 channelized with IMA
ethernet
APS:
4p 10/100 Mb/s
1+1 for oc3/stm1 & oc12/stm4
up to oc48/Stm16
16p oc3/Stm1 optical unchannelized

8p oc3/Stm1 optical channelized
SingleShelf: up to 224 oc3/stm1 clearChannel links
up to 112 oc3/stm1 clearChannel links w
up to 14 oc48/stm16 clearChannel links
up to 14 oc48/stm16 Channelized links
up to 7 oc48/stm16 Channelized links w
multiShelves: up to 1760 oc3/stm1 clearChannel lin
up to 1664 oc3/stm1 clearChannel link
2pGE
SingleShelf: up to 56 GE links,
multiShelves: up to 440 GE links.
yes
1+1 APS detection + switching times < 50 ms
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 204/240
7670 RSP (Release 6-2)
7670 ESE
Atm:
vpi.vci range:
atmConnection:
type:
capacity:
UNI/NNI compliant to atmForum

Pvc/svc/spvc, pvp/svp/sPvp
64000 vc/node
Pvc/svc/spvc, pvp/svp/sPvp
up to 768 000 vc / node
up to 32 000 vp / node
8 serviceCategories: cbr, 2 rtVbr, 3 nrtVbr, abr, ubr/ubr+ (mdcr)
PerVc queues
WFQ
vpa (aka: vp endpoint), trafficShaping at vpa level
qos:
trafficManagement:
Signaling:
Pnni
trafficShaping & policing per vc/vp

Uni v3.1 & v4.1, Pnni v1.1
Pnni hierarchy
IMA:
OAM:
F4/F5
Aal2:
encoding:
Ethernet:
Vlan:
P-Tagging
Eth over atm:
LAG:
Uni v3.1 & v4.0, Pnni v1.1

3 pnni hierarchical levels
Up to 400 LGN in the 7670 topology dataBase
Up to 2,3 million nodes within a 3 level hierharchica
IMA v1.0 & IMA v1.1
IMA either T1 or E1 based
1 up to 8 Links per IMA Group (ESC card)
# IMA group / 1p oc3/stm1 ch = 42
# IMA group / 8p oc3/stm1 ch = 8*42=336
F1 to F5
G711
G726 and G726A/B compression & silence encodin
according to IEEE802.1Q
according to IEEE802.1P
according to rfc2684
no
according to IEEE802.3ad on GigE,

Up to 2 GE links within a LAG.
IP:
version:
ThroughPut:
MTU
PPP:
VPN:
Qos:
Classification:
Marking/Remarking:
Policing/shaping
Routing:
ICMP:
ECMP:
DHCP:
ipv4 and ipv6

Over 640 millions packets per second (pps) (IPv4)
Over 300 millions pps (IPv6)
Up to 9192 octets
PPP over E1/T1, 10/100 Mb/s, ...
IP over ATM on E1/T1, oc3/Stm1,
VPN
IP-VPN, layer2 & layer3 VPN according to rfc4364

Differentiated Services
Either BA or MFC classification according to the ca
yes.
yes.
StaticRouting, up to ?128 static routes or routers?) per ISC. staticRouting
ospfv2,
ospf, rip v1/v2, BGP-4, IGMPv2
supported
applicable to static and dynamic routes.
DHCP relay Agent supported.
MPLS:
supported
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 205/240
4 UMTS RELEASES
4.1
RNC
4.1.1
FP
4.1.1.1 RNC-IN, 16POC3/STM1 FP:

- UA6:
OUTPUT:
N/U
Iub
Icn
Hairpin
removed sPvc
Iub
Hairpin
PVC
Iub
Hairpin
sPvc
APC 3
Iu/Iur
Iu/Iur
Iu/Iur
Hairpin Hairpin N/U or
Hairpin
sPvc or PVC or
Iu/Iur
PVC Iub
Iub
Iu/Iur Shaped
Shaped
VPC
Shaped Shaped
VPT
VPC
VPT
Iub
Hairpin
PVC
N/U
Iu/IuR
PNNI
SDH14
SDH0
SDH1
SDH2
SDH3
SDH4
SDH5
SDH6
SDH7
SDH8
SDH9
SDH10
SDH11
SDH12
SDH13
12
12
12
12
2402
2402
2402
536
4802
536
536
64
2175
2175
2175
2175
536
200
AtmIf maxVpiBits
AtmIf CA maxVccs
Iu/Iur
Iub PNNI Iub PNNI Hairpin
sPvc
APC 2
Iub
PNNI
APC 1
APC 0
The pnni Hairpin removal feature applies.

- UA5-0 16pOC3 MS3 FP:
- The RNC supports the 16pOC3/stm1 MS3 FP.
- UA5-0 16pOC3 FP Attributes:
AtmIf CA maxVpcs
200
22
AtmIf CA minAutoSelectedVpi
4095
4095
4095
255
255
255
255
255
255
255
255
255
255
255
4095
AtmIf CA maxAutoSelectedVpi
4095
4095
4095
255
255
255
255
255
255
255
255
255
255
255
4095
AtmIf CA minAutoSelectedVciForVpiZero
13981
13981
13981
1023
1023
1023
1023
1023
4095
8191
8191
8191
8191
1023
487
AtmIf CA maxAutoSelectedVciForVpiZero
16383
16383
16383
1023
1023
1023
1023
1023
4095
8191
8191
8191
8191
1023
1023
511
AtmIf CA maxVpts
22
AtmIf Ca minAutoSelectedVciForNonZeroVpi
63
63
63
63
63
63
511
63
63
63
63
63
63
63
AtmIf Ca maxAutoSelectedVciForNonZeroVpi
63
63
63
63
63
63
511
63
63
63
63
63
63
63
511
16384
16384
16384
1024
1024
1024
1024
1024
4096
8192
8192
8192
8192
1024
1024
AtmIf ConnMap Ov numNonZeroVpisForVccs
200
22
22
AtmIf ConnMap Ov firstNonZeroVpiForVccs
AtmIf ConnMap Ov numVccsPerNonZeroVpi
64
64
64
64
64
64
512
64
64
64
64
64
64
64
512
16384
16384
16384
1024
13824
1024
12288
1024
4096
8192
8192
8192
8192
1024
12288
2403
2403
2403
537
5203
737
581
87
2176
2176
2176
2176
537
AtmIf ConnMap Ov numVccsForVpiZero
Per port limitation:

numVccsForVpiZero+(numVccsPerNonZeroVpi
* numNonZeroVpisForVccs) <= 23 654
Per card limitation: sum of (maxVccs +
maxVpcs + (maxVpts * 2) + 1)
Arc
Checks:
Lp Eng Arc Ov ConnectionPoolCapacity
1000
Lp Eng Arc Ov protectedConnectionPoolCapacity
28440
>
24900
8000
>
7746
7000
>
6608
6600
>
6529
3300
>
3251
Apc/0
Lp Eng Arc Apc Ov connectionPoolCapacity
Apc/1
Apc/2
Apc/3
Table 4-1, UA5 16pOC3 FP Attributes
4.1.1.2 RNC-AN, MSA32 FP:

UA5-0:
- SS MSA32 is available.
Since UMTS UA4-1 / PCR5-2:
- SparingPanel available,
Maximum amount of Links:

Since UA 4-1 / PCR5-2:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 206/240
The MSA32 supports up to 28 E1 or 30 DS1 IMA ports per FP, distributed across the two
Makers (block of ports #0-15 or 16-31) as up to:
- 14 E1 ports in up to 7 IMA groups per Maker, or
- 13 E1 ports in up to 13 IMA groups per Maker.
- 15 DS1 ports in up to 7 IMA groups per Maker, or
- 13 DS1 ports in up to 13 IMA groups per Maker.
Before UA 4-1:
The MSA32 supported up to 22 E1 or 24 DS1 IMA ports per FP, distributed across the
two Makers (block of ports #0-15 or 16-31) as up to:
- 11 E1 ports in up to 5 IMA groups per Maker, or
- 10 E1 ports in up to 10 IMA groups per Maker.
- 12 DS1 ports in up to 6 IMA groups per Maker, or
- 10 DS1 ports in up to 10 IMA groups per Maker.
4.1.1.3 RNC-AN, 2PSTM1 ELECTRICAL CHANNELIZED FP:

UMTS UA4-1 (FRS 23121):
2pStm1 Electrical Channelized FP is available on RNC-AN for the Passport release PCR52.
UMTS UA 4-0 & 3:
Not available.
4.1.1.4 RNC-AN, 2PSTM1 OPTICAL CHANNELIZED FP:

4.1.1.5 RNC-AN, 2POC3 CLEAR CHANNEL FP (FRS 23121):

UMTS UA4-1:
2pOC3 ClearChannel is available on RNC-AN for the Passport release PCR5-2.

UMTS UA 4-0 & 3:
Not available.
4.1.1.6 PP15K-POC, 4PDS3 CHANNELIZED FP:

UMTS UA4-1:
4pDS3 Ch FP is available on PP15k-POC.

UMTS UA 4-0 & 3:
Not available.
4.1.2
RNC TYPES:

UMTS UA4-1:
RNC 1500 is available.
UMTS UA 4-0 & 3:

RNC 1000 is available.
4.1.3
RNC CAPACITY:
-
UMTS UA 4-2:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 207/240
Up to 400 nodeBs per RNC, TBC

UMTS UA 4-1 and previous:
Up to 200 nodeBs per RNC,
4.1.4
IUXIF / IUBIF / AAL2IF:

-
UA4 -2:
The Iuxif component is removed and replaced by two components: IubIf and aal2If.
4.1.5
PATHID:
-
UA 6:
The RNC supports up to 9720 aal2 Paths.

UA 5-0 & 4:
The RNC supports up to 2100 aal2 Paths.
4.1.6
4.1.7
AAL2 PATH ASSIGNMENT TO PMC-PC
Release 4-2:
All Paths from one NodeB are assigned to one single PMC-PC. This modification is linked
the Hsdpa introduction.
The loadBalancing parameter is removed. This parameter was set to weighted on the Iub
interface and determined the way the Iub paths were assigned to the PMC-PC.
Release 4-1 and previous:

- All Paths from one NodeB may be assigned to different PMC-PCs. The Path assignment to
PMC-PC is dictated by the parameter loadBalancing set to weighted.
AAL2 LINK CAC:

Aal2 link CAC, AvailableCellRate (ACR):
-
UA 5-0:
Enhancement of the AAL2 link CAC in such a way the bandwidth taken into consideration
(ACR) is either
1/ the NodeB per Path bandwidth,
2/ the NodeB per aal2Qos bandwidth:
3/ the total NodeB aal2 bandwidth, per Iubif (Sum of Vcc ECRgcac).
UA4 -1:
Enhancement of the AAL2 link CAC in such a way the bandwidth taken into consideration
(ACR) is either
1/ The NodeB per aal2Qos bandwidth,
2/ The IuxIf bandwidth.
UA4 -0:
The RNC aal2Link CAC consider the per aal2 interface bandwidth when regulating.
The total NodeB aal2 bandwidth = per Iuxif (Sum of Vcc ECRgcac).
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 208/240
Aal2 link CAC, EquivalentBitRate (EBR):

UA 5-0:
One EBR values is set per RAB and per Utran interface (FRS27083).
The following parameters are removed and replaced by new ones inserted in 3:
DlRbSetConf/Qaal2equivalentBitRate /DL EBR/
UlRbSetConf/Qaal2equivalentBitRate /UL EBR/
DlRbSetConf/Qaal2equivalentSSSARSDULength /DL ESL/
UlRbSetConf/Qaal2equivalentSSSARSDULength /UL ESL/
UA 4-1:
One EBR values is set per RAB, it applies to all the Utran interfaces.
Dynamic reserved Bandwidth:
UA4 -1:
Bandwidth reserved by the aal2 Link CAC for an already established call, is updated when
bandwidth update occurred due to always on UMTS feature (see FRS 25647).
The reconfiguration of a user toward another RB occurs when the following mechanisms are
invoked:
- Always On downsizing
- Always On upsizing
- iRM Scheduling downgrading
- iRM Scheduling upgrading
- Downgrading because of iRM pre-emption
4.1.8
AAL2CONGESTIONMANAGEMENT

UA5-1
-
The aal2CongestionManagement regulates traffic according to the NodeB bandwidth or

according to bandwidthPool.
qos0+1+2 is the Cumulative counter for RNC local aal2 qos 0, aal2 qos1 and aal2 qos2 PDU
and DRNC Iur aal2 qos2 PDU.
UA 4-2, 5-0:
-
4.1.9
The aal2CongestionManagement regulates traffic according to the NodeB bandwidth.

qos0+1+2 is the Cumulative counter for RNC local aal2 qos 0, aal2 qos1 and aal2 qos2 PDU.
ICN VCC

UA4-1
Since RNC1500 is available, no more Icn interface is configured.

UA 3-2:
Since SS7 protocol stack migrates to RNC-IN, RANAP and RNSAP Vcc are no more
configured on Icn interface.
All other Icn Vcc are still configured.
4.1.10 TMU
-
UA 4 & 3:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 209/240
One TMU manages up to 160 CP/CCP vcc.

Remark: TMU Redundancy is N+1, if less than 9 TMU, else TMU redundancy is N+2.
RNC available configuration:
# TMU
11
12
14
# nodeB
80
120
140
140
200
200
200
Max # CP and CCP
480
800
960
980
1400
1400
1400
Note:
#TMU in the table indicates the sum of active and Spare TMU.
This corresponds to the maximum NodeB configuration equipped with 6 CEM, which
requires 1 CP + 6 CCP vcc per NodeB.
4.1.11 QOS
-
UA6
The qos mapping table is achieved through thr TransportMap
UA5-1:
The RNC is configured with one Qos information mapping table, which applies to all the Iub and
Iur interface:
TrafficClass
Aal2Qos
RNC serviceCategory
Conversational
0
rtVbr
Streaming
0
rtVbr
Interactive
1
nrtVbr
Background
1
nrtVbr
Hspa
2
- ubr, if hspa path within a shared bandwidthPool,
- nrtVbr, if hspa path within a hspa dedicated bandwidthPool.
4.2
NODEB ATM
4.2.1
CCM RELATED:

UA5-1:
- The NodeB supports the the CCM type: xCCM, iCCM2 and iCCM.
- When populated with xCCM, the nodeB supports up to 2 IMA linkGroups,
- When populated with iCCM or iCCM2, the nodeB supports simultaneously IMA and
multiPcm.
UA 5-0:
The nodeB is populated with the iCCM.
IMA simultaneously with xPcm is not supported.
4.2.2
CEM RELATED:
#CEM loaded with E-BBU role:

New CEM supported: xCEM128, xCEM256.
UA 5-0:
The NodeB supports up to one CEM loaded with E-BBU role.

New CEM supported: iCEM128.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 210/240
BBU Role assignment to BBU component:

UA 5-0:
An algorithm is in charge of assigning the different BBU roles to the CEM BBU
components. Therefore the kind of traffic handle by a CEM can not be predicted in
configuration phase.
UA 4-2:
Each BBU component is configured with one BBU role.
4.2.3
MULTIPCM:

UA5-1:
The xPcm mode is supported. Either all the nodeB E1 are in xPcm mode, or the nodeB is
configured with a mix of n*E1 IMA and p*E1 in xPcm.
Hspa over xPcm is supported.
UA 4-2, UA5-0:
The nodeB multiPCM configuration is no more supported.
4.2.4
IMA:

UA5-1:
Either all the nodeB E1 are inserted within an IMA linkGroup, or the nodeB is configured
with a mix of n*E1 IMA and p*E1 in xPcm.
UA 4-2, UA5-0:
The nodeB supports only IMA.

UA 4-1:
If IMA configured on the nodeB, all the E1 present on the nodeB must be inserted in the
IMA LG.
IMA LinkGroup Bandwidth:

UA 4-1:
The vcc PCR can be set with a value higher than 4490 cells/s, up to the IMA linkGroup
bandwidth, this value is taken into consideration by the NodeB without correction.
UA 4-0 & 3:
-
The vcc PCR must be set with a value lower than 4490 cells/s.
If a higher PCR value is set, nodeB automatically reduces PCR value to 4490 cell/s.
The CCM card allows configuring only one IMA linkGroup per nodeB.
All the PCM links declared from OMC-B have to be part of the IMA group (to avoid
managing mix configuration: IMA and not IMA).
IMA bandwidthReduction, Configuration of ImaDefense mechanism through OMC-R:

UA 5-0:
The NodeB IMA bandwidthReduction mechanism is enhanced with the HoldingPriority

parameter.

UA 4-2:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 211/240
The Previous IMA LG Bw reduction/Restoration is replaced by a new one. The NodeB

Call processing is no more involved in traffic reduction/restoration, beside atm Vcc are
deactivated/activated.
Reason for change: satisfies the RNC aal2 Congestion Management mechanism
introduced for Hsdpa traffic.
The parameters: IMA DefenseActivation and IMA WeightingFc are removed.

UA 4-1:
NodeB IMA bandwidthReduction defense mechanism is activated by setting the
parameter: IMA DefenseDelay.
The parameter IMA DefenseActivated is no more present.
IMA DefenseDelay parameter is optional.
UA 4-0 & previous:

NodeB IMA bandwidthReduction defense mechanism is activated by setting the
parameters: IMA DefenseActivated and IMA DefenseDelay.
IMA DefenseDelay parameter is mandatory.
4.2.5
N E1 XPCM + P E1 IMA:

UA 5-1:
The nodeB supports simultaneously n*E1 in xPCM mode and p*E1 in IMA mode.
Hspa vcc can be configured over single E1 (Hspa over xPcm)
4.2.6
AAL1 CES

4.2.7
UA 5-0:
AAL1 CES SDT NOT available.
QOS
NodeB set of priorityLevel values, case of trafficShaping Not activated:

UA 4-2:
Raison for Modification:
- Introduction of CES,
- Introduction of Hsdpa Vcc,
- MCR taken into account by NodeB.
See 3

UA 4-0 & 4-1:

Raison for Modification: MCR not taken into account by NodeB.
VCC
SC recommended
for the interface
SC configured in
NodeB
UP DS
rtVBR
UBR
UP NDS
nrtVBR
UBR
CP
rtVBR
UBR
CCP
rtVBR
UBR
PriorityLevel
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 212/240
UBR
OAM
UBR+/MCR
- As long as the MCR is not taken into account in NodeB, the CP and CCP serviceCategory is
changed from UBR+ to UBR, in parallel the UP DS PriorityLevel is changed from 0 to 1 (same
as CP and CCP PL).
- The MCR configured against the OAM Vcc is taken into account by the scheduling.

UA3:
Note: It was assumed that the MCR is taken into account by the NodeB)
VCC
4.2.8
SC recommended
for the interface
SC configured in
NodeB
PriorityLevel
UP DS
rtVBR
UBR
UP NDS
nrtVBR
UBR
CP
rtVBR
UBR+ / MCR
CCP
rtVBR
UBR+ / MCR
OAM
UBR
UBR+/MCR
TRAFFIC MANAGEMENT
4.2.8.1 TRAFFIC DESCRIPTOR PARAMETER VALUES

NodeB UBR+/MCR availability:
UA 4-2:
MCR configured for UBR+ VCC is taken into consideration by NodeB.
UBR+/MCR may be configured against aal5 and aal2 Vcc.

UA 4-1 > 3:
MCR configured for UBR+ VCC, is not taken into consideration by NodeB when
trafficShaping is not activated.
AAL2 Vcc can not be configured with UBR+ serviceCategory. Only AAL5 VCC may be
configured with UBR+.
NodeB Minimal VC Rate:

UA 4 & 3:
- Case of E1:
Minimum throughput for full E1 is: 1, 92 kbits/s / 20 = 96 kbits/s for both full
E1 and IMA linkGroup composed of up to 8 E1s. NodeB OAM converts
kbits/s into bits/s using ratio 1000. Therefore minimum throughput is
227cells/s.
Case of E1 Drop&Insert 15/15, the minimal cell rate is 227/2 = 114 cells/s.
Case of T1:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 213/240
Minimum throughput for full T1 is 1,544 Mbits/s / 20 = 77, 20 kbits/s; in

other words, Minimum throughput for full T1 is 3622 cells/s / 20 = 182
cells/s. Therefore minimum throughput is 182 cells/s.
Case of T1 Drop&Insert 12/12, the minimal cell rate is 182/2 = 91 cells/s.
OAM VCC UBR+ /MCR value:
UA 4-1 & 3:
The OAM Vcc is still provided by factory, configured with UBR+/MCR.
4.2.8.2 TRAFFIC REGULATION MECHANISMS

TrafficShaping:
UA 4-1:
TrafficShaping at VC level is optional.
When trafficShaping is not activated, case of IMA, the NodeB accepts and dont correct a
PCR value higher than E1 bandwidth. The maximum PCR value is #PCM*(PCM
bandwidth-IMA overhead). The nodeB cut the egress traffic at this PCR.

UA3:
TrafficShaping at VC level becomes optional.
When trafficShaping is not activated, case of IMA, the NodeB automatically reduces the
configured PCR value to [PCM LinkRate-IMA overhead] and cut the egress traffic at this
PCR.
Policing:
Policing is not activated.
UA 4:
Ingress traffic is cut at 16 Mb/s (equivalent to 8 E1).
UA 2:
Ingress traffic is cut at 8 Mb/s (equivalent to 4 E1).
4.3
NODEB IP
Native/hybrid nodeB:
UA7-1-1: NativeIP nodeB, hybrid and atm nodeB are supported.
UA7-0: Hybrid and atm nodeB are supported (not native IP nodeB).
GE/Oc3/Stm1 MDA:
UA7-1-2: GE/oc3/Stm1, LAG supported on the nodeB side
Ethernet Vlan:
UA7-1: Vlan supported on the nodeB side
UA6: the nodeB does not support Vlan.
Ethernet Priority tagging:
UA7-1: P-Tag supported on the nodeB side
UA6: the nodeB does not support P-Tag.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 214/240
IP MTU:
UA7-1: MTU is configured
UA6: MTU is not configured.
IP QOS:
UA7-1: the IP packets with proprietary umts heartBeat Response payload are marked
with a configured DSCP value.
UA6: the IP packets with proprietary umts heartBeat Response payload are marked
with the non configurable DE DSCP value.
4.4
MICRO NODEB

UA4-2:
The microNodeB atm is available.
4.5
PICO NODEB

UA4-2-5:
The picoNodeB atm is available.
4.6
PLANE RELATIVE
4.6.1
UMTS HSUPA PLANE:

UA5-0:
The UMTS HSUPA traffic flow is added.
The Hsdpa and Hsupa are carried over different dedicated vcc.
4.6.2
UMTS HSDPA PLANE:

UA4-2:
The UMTS HSDPA traffic flow is added.
Hsdpa is handled on Iub interface, not on Iur interface.
4.6.3
UMTS OAM PLANE:

UA4:
On nodeB side, OAM traffic is carried VCC=0/32, set in factory. Change of this VCC
value requires a NodeB reset.
4.6.4
UMTS CONTROL PLANE:

Radio Network ControlPlane, CP and CCP VCC, RNC TMU-R allocation:
UA4:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 215/240
Different TMU-R cards may be in charge of managing on one hand AccessStratum and on
other hand nonAccessStratum signaling relative to a nodeB.
4.6.5
UMTS USER PLANE

-
NodeB CEM card:
CommonSRB:

UA4:
4 commonSRB are set per UMTS Radio Cell. One more commonSRB is added per UMTS
cell, dedicated to a second FACH, it is called cellFach.
RAB mapping:

UA4:
CSD64 is mapped to UP DS VCC.
4.6.6
TRANSPORT NETWORK CONTROLPLANE:

UA4:
ALCAP is not implemented. NBAP protocol is enhanced in such a way to assume
ALCAP functions. Therefore NBAP is proprietary.
5 TRANSPORT IDENTIFIERS
Within the TEG, the transport identifiers are provided for the UMTS nodes: NodeB and RNC.
One decision tree is set per kind of bandwidthPool to make easier selection of table within this section:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 216/240
SharedForAllTrafficTypes
Without
Without hspa
hspa Streaming
Streaming
With
With hspa
hspa Streaming
Streaming
NodeB
NodeB vpi/vci/sc:
vpi/vci/sc:
Table
Table 5-3
5-3
NodeB
NodeB vpi/vci/sc:
vpi/vci/sc:
Table
Table 5-4
5-4
RNC vpi/vci/sc
RNC vpi/vci/sc
Tables:
iubIf
Tables:
iubIf
5-8
[1-200]
5-14
[1-200]
5-9
[201-400]
5-15
[201-400]
5-10
[401-600]
5-16
[401-600]
5-11
[601-800]
5-17
[601-800]
5-12
[801-1200]
5-18
[801-1200]
5-13
[1201-2400]
5-19
[1201-2400]
Iub
Iub pathId:
pathId:
Table
Table 5-27
5-27
Iub
Iub pathId:
pathId:
Table
Table 5-28
5-28
IMA
IMA HP:
HP:
Table
Table 5-34
5-34
IMA
IMA HP:
HP:
Table
Table 5-34
5-34
Figure 5-1, sharedForAllTrafficTypes decision tree
primaryForTrafficType
primaryForTrafficType
One Qos
Up to 4 qos
?#Qos?
xPcm
IMA & xPcm
?IMA/xPcm?
IMA
NodeB
NodeB vpi/vci/sc:
vpi/vci/sc:
Table
Table 5-5
5-5
NodeB
NodeB vpi/vci/sc:
vpi/vci/sc:
Table
Table 5-6
5-6
NodeB
NodeB vpi/vci/sc:
vpi/vci/sc:
Table
Table 5-7
5-7
RNC
RNC vpi/vci/sc:
vpi/vci/sc:
Table
Table 5-20
5-20
RNC
RNC vpi/vci/sc:
vpi/vci/sc:
Table
Table 5-21
5-21
RNC
RNC vpi/vci/sc:
vpi/vci/sc:
Table
Table 5-22
5-22
Iub
Iub pathId
pathId
Table
Table 5-29
5-29
Iub
Iub pathId
pathId
Table
Table 5-30
5-30
Iub
Iub pathId
pathId
Table
Table 5-30
5-30
IMA
IMA HP:
HP:
Table
Table 5-32
5-32
IMA
IMA HP:
HP:
Table
Table 5-33
5-33
Figure 5-2, primaryForTrafficType decision tree
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 217/240
5.1
ATM VCC
On the Iub interface are configured user plane vcc for different qos according to the kind of UMTS traffic
they are assigned to.
The following vcc naming rule applies:
After migration from UA5 to UA6, and in UA6 as long as the hspa streaming is not enabled:
Vcc name
serviceCategory
UMTS flows
qos0 vcc
rtVbr
R99 AMR, dSRB and cSRB
qos2 vcc
nrtVbr
R99 I/B, R99 Streaming
qos3 vcc
ubr
Hspa I/B
Since the hspa streaming traffic is enabled one more kind of vcc is created:
5.1.1
Vcc name
serviceCategory
UMTS flows
qos0 vcc
cbr
R99 AMR,dSRB and cSRB
qos1 vcc
rtVbr
R99 Streaming and Hspa Streaming
qos2 vcc
nrtVbr
R99 I/B
qos3 vcc
ubr or ubr+
Hspa I/B
UPGRADE FROM UA5 TO UA6

The UA6 upgrade and hspa streaming activation procedures described in this section, are applicable as
long as the network is configured according the IubTEG 5 addressing plane.
The UA6 upgrade procedure must be customized for other addressing planes.
5.1.1.1 BEFORE UPGRADE

The UA5 16pOC3 FP Attributes are kept unchanged.
? Are there some nodeB

identified by iubif >200?
Yes
- Assign to the nodeB an iubIf in the range [1-200]

- Update the nodeB vci accordingly
No
Add the alcap vcc for up to 200 nodeB:
Alcap vcc, RNC ECRacac = 0
Table 5-1, pre UA6 upgrade flowchart
5.1.1.2 UPGRADE
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 218/240
UA5-1 => UA6
advancedQos set to disable

16pOC3 FP Attributes update
Shared bwPool
- n DS rtVbr vcc, TDDS
- n NDS nrtVbr vcc, TDNDS
- 1 or 2 Hspa ubr vcc
Remark: n = [1 - 7]
Dedicated bwPool
- p Hspa nrtVbr vcc
=> sharedForAllTrafficTypes
=> n qos0 rtVbr vcc, TDDS
=> n qos2 nrtVbr vcc, TDNDS
=> 1 or 2 qos3 ubr vcc
=> preferredForTrafficType
=> p qos3 nrtvbr vcc
TransportMap:
- Iub sharedForAllTrafficType bwPool linked to transportMap/1
- Iub preferredForTrafficType bwPool linked to transportMap/2
- IuCS and Iur aal2If linked to transportMap/1
admissionControl:
- qos2bwReservation
- qos1bwReservation
=> qos3bwReservation
=> qos2bwReservation
congestionManagement:
- qosDt 0 0 1 xx 2 yy 3 0 => qosDt 0 0 1 0 2 xx 3 yy
- qosBp 0 0 1 xx 2 yy 3 0 => qosBp 0 0 1 0 2 xx 3 yy
The hspaStreaming feature is not activated during the upGrade.
table 5-2 UA6 upgrade flowChart
Note:
- Within a preferedForTrafficType bwPool, p qos3 vcc are configured, since the associated NodeB
IMA group is composed of p E1.
Overbooking factor:
Since more vcc configured on the Iub stm1 then more bandwidth reserved through the
trafficDescriptors, the overbooking factor must be re-calculated (atmIf/ ca bwpool 1 x 2 0 3 0 4
0 5 0), e.g.: x=700.
Pnni:
The pnni sPvc configured for the nodeB iubif [1, 200] in the previous release are not impacted
by the UA5 to UA6 migration procedure. After migration, these connections are still switched
on the pnni sPvc hairpins.
Only the pnni sPvc connections created for nodeB IubIf > 200 after migration terminate on the
application without being switched on the pnni sPvc hairpins.
5.1.1.3 HSPA STREAMING INTRODUCTION.

Since the RNC has been upgraded to the UA6, the hspaStreaming feature may be activated:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 219/240
UA6
Add Hspa Streaming
qos1 vcc:
Previously existing DS vcc.
sharedForAllTrafficTypes:
- n qos0 rtVbr vcc, TDDS:
- qos0 vcc [vci range 4 bottom values] => qos1 rtVbr vcc tdt=6, TDDS
- qos0 vcc [vci range 3 top values]
=> qos0 cbr vcc tdt=1, TD=0
- n qos2 nrtVbr vcc, TDNDS
- 1 or 2 qos3 ubr/ubr+ vcc
qos0 vcc:
Qos0 vcc is created with
cbr and TD=0.
Note: n=[1 - 7].
preferredForTrafficType:
- p qos3 nrtVbr vcc
=> p qos3 vbr/ubr/ubr+ vcc
advancedQos set to enable

TransportMap:
alt 1: upd the existing TM/1 (R99 Streaming mapping)
TransportMap:
alt 2: modify link between shared bwPool and TM
Figure 5-3, HspaStreaming feature activation flowChart
5.1.2
NODEB INTERFACE
The table below summarizes the maximum number of vcc supported by the NodeB:
Atm User
Oam
Cp
Aal
Aal5
Aal5
Max # vcc
1
1
Ccp
Aal5
Alcap
Aal5
User traffic
Aal2
16
Remarks:
-
The nodeB oam vcc is pre-provisioned in factory with default vpi.vci 0.32.
The nodeB oam vpi.vci, like other I&C parameters, can be modified using WICL or
remote TIL (for nodeB).
Since the nodeB is populated with up to 6 CEM then up to 6 CCP vcc may be configured.
The TEG provides several NodeB vpi.vci tables according to the Iub context:
- The vcc belongs to a RNC SharedForTrafficTypes BwPool or primaryForTrafficType
bwPool.
- Within a sharedForAllTrafficTypes BwPool, the hspa streaming is or is not supported on
the Iub.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 220/240
Within a sharedForAllTrafficTypes bwPool, the Hspa Streaming traffic is supported on the Iub as an
option. If supported then a dedicated to streaming traffic vcc is created. The streaming vcc carries both
hspa and R99 streaming traffic.
Since the hspa streaming traffic is optional then two nodeB vpi.vci addressing plans are suggested:
- one without streaming vcc and
- one with streaming vcc.
NodeB Iub interface, preference sharedForAllTraffic

VCC type:
qos0
qos2
qos3
CP
CCP
Alcap
NodeB OAM
AAL
aal2
aal2
aal2
aal5
aal5
aal5
aal5
Qos
0
2
3
na
VPI
1
1
1
1
1
1
0
41
49
48
35
VCI
to
to
+
34
to
33
32
47
55
56
40
nodeB SC
ubr1
ubr2
ubr+3
ubr1
ubr1
ubr1
ubr+3
POC SC
rtVbr
nrtVbr
ubr
rtVbr
rtVbr
rtVbr
ubr
#
7
7
2
1
6
1
1
16
table 5-3, NodeB vpi.vci, sharedForAllTrafficTypes when No hspa streaming supported
NodeB Iub interface, preference sharedForAllTraffic

VCC type:
qos0
qos1
qos2
qos3
CP
CCP
Alcap
NodeB OAM
AAL
aal2
aal2
aal2
aal2
aal5
aal5
aal5
aal5
Qos
0
1
2
3
na
VPI
1
1
1
1
1
1
1
0
VCI
45 to
41 to
49 to
48 +
34
35 to
33
32
47
44
55
56
40
nodeB SC
ubr0
ubr1
ubr2
ubr+3
ubr1
ubr1
ubr1
ubr+3
POC SC
cbr
rtVbr
nrtVbr
ubr
rtVbr
rtVbr
rtVbr
ubr
#
3
4
7
2
1
6
1
1
16
table 5-4, NodeB vpi.vci, sharedForAllTrafficTypes when hspa streaming supported
Remarks:
-
The vci 41 to 56 are reserved for the aal2 vcc. These vci values are shared between the
release99 and the hspa vcc. Per default two vci (vci=48, 56) are allocated to the hspa I/B
vcc. If more hspa I/B vcc are required either in the sharedForAllTrafficTypes or the
primaryForTrafficType BwPool then the highest vci from the qos2, qos1 or qos0 vci range
are going to be assigned to the hspa I/B vcc.
The Alcap vcc introduced in UA6 is identified with the vci not used in the previous
release.
When a primaryForTrafficType BwPool is configured, two options are available:

- The standard option consists in a primaryForTrafficType bwPool only composed of qos3 vcc,
- The alternative option in a primaryForTrafficType bwPool composed of different qos vcc.
The same vpi.vci range is assigned to both the vcc within the sharedForAllTrafficTypes BwPool and the
vcc within the primaryForTrafficType BwPool. The vpi.vci not assigned to the vcc within the
sharedForAllTrafficTypes BwPool are available for the vcc within the primaryForTrafficType BwPool:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 221/240
NodeB Iub interface, preference primaryForTrafficType

VCC type:
qos3
AAL
aal2
Qos
3
VPI
1
VCI
41 to 56
nodeB SC
ubr3
POC SC #
ubr
16
Table 5-5, NodeB vpi.vci, primaryForTrafficType, one qos.

NodeB Iub interface, preference primaryForTrafficType
VCC type:
qos1
qos2
qos3
AAL
Qos
VPI
aal2
aal2
aal2
1
2
3
1
1
1
VCI
42 to
43 to
44 to
nodeB SC
42
43
44
POC SC
ubr x
ubr x
ubr3
#
1
1
1
3
5.1.3
RNC INTERFACE
The vpi on the RNC-POC interface are fixed to 0 in such a way to optimize the RNC 16pOC3/Stm1
resources.
The vci on the RNC-POC interface are indexed by IubIf parameter value; each nodeB being identified
from the RNC side by means of an IubIf value called k in the following tables.
This section doesnt consider the vpi.vci to configure on the pnni Hairpin interface.
Rule description:
- On the classical 16pOC3 FP up to 1200 nodeB may be configured whereas on the 16pOC3
MS3 FP up to 2400 nodeB may be configured.
- On the classical 16pOC3 FP, the specified vpi.vci space allows to configure up to 800 nodeB
if 3 stm1/oc3 allocated to the Iub interface. A fourth stm1/oc3 must be allocated to the Iub
interface if more than 800 nodeB configured. Refer to default RNC port assignment on
5.2.1.2 .
- For the nodeB identified by IubIf [1, 200]: the associated vpi.vci naming rule applies on the
three stm1: 800, 801 and 802. This rule provides backward compatibility with the UA5
vpi.vci naming rule.
- For the nodeB identified by IubIf [201, 400]: the associated vpi.vci naming rule applies only
on the stm1 800,
on the stm1 801,
on the stm1 802,
- For the nodeB identified by IubIf [801, 1200]: a fourth stm1 from the classical 16pOC3 FP,
is going to be allocated to the Iub (e.g.: port 808), the associated vpi.vci naming rule applies
only on this stm1. The fourth stm1 is going to be assigned to the iub interface, since as soon
as the pnni hairpins are removed and the classical 16pOC3FP attributes set accordingly, see
3.3.11.6..
- For the nodeB identified by IubIf [1201, 2400]: the RNC must be populated with a 16pOC3
MS3 FP to support so many nodeB. The associated vpi.vci naming rule applies to all the
stm1 involved on the Iub.
- One additional vcc is reserved for POC oam. This vcc is used as an option.
- The TEG provides several suggestions for the RNC vpi.vci values according to the contexts:
- SharedForAllTrafficTypes or primaryForTrafficType preference,
- Hspa Streaming traffic supported or not within the SharedForAllTrafficTypes
bwPool.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 222/240
The nodeB spreading on the different RNC Iub stm1/oc3 is realized by assigning to the nodeB an IubIf
value from the different IubIf ranges: [0,200], [201, 400], [401, 600], [601, 800], [800, 1200].
For the nodeB k = [1201, 2400] configured on the RNC populated with the 16pOC3 MS3 FP, the vcc can
be configured on all the Iub port.
5.1.3.1 SHAREDFORTRAFFICTYPES BWPOOL, NO HSPA STREAMING

Six RNC vpi.vci tables are provided:
- One vpi.vci table for the nodeB identified by IubIf in the range: [1, 200]. This table
provides backward compatibilities with the UA5 vpi.vci numbering plane,
- One vpi.vci table for the nodeB identified by IubIf in the range: [201, 400],
- One vpi.vci table for the nodeB identified by IubIf in the range: [1201, 2400].
RNC Iub interface, preference sharedForAllTrafficTypes,
VCC type:
qos0
qos2
qos3
CP
CCP
NodeB oam
POC InBdOam
Alcap
AAL
aal2
aal2
aal2
aal5
aal5
aal5
aal5
aal5
Port
VPI
800
&
801
&
802
k = 1 to 200
VCI
34
42
41
50
51
33
+ 24*(k-1)
+ 24*(k-1)
+ 24*(k-1)
+ 24*(k-1)
+ 24*(k-1)
+ 24*(k-1)
to
to
+
40 + 24*(k-1)
48 + 24*(k-1)
49 + 24*(k-1)
to
56 + 24*(k-1)
32
5033 - k
SC
rtVbr
nrtVbr
ubr+ / ubr
rtVbr
rtVbr
ubr
ubr
rtVbr
#
7
7
2
1
6
1
1
1
Table 5-8, RNC vpi.vci, sharedForTrafficTypes, No hspa streaming, IubIf in the range [1, 200]

VCC type:
qos0
qos2
qos3
CP
CCP
NodeB oam
Alcap
AAL
aal2
aal2
aal2
aal5
aal5
aal5
aal5
port
VPI
800
5034
5042
5041
5050
5051
5033
5057
+ 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
k = 201 to 400
to
to
+
VCI
5040 + 25*(k-201)
5048 + 25*(k-201)
5049 + 25*(k-201)
to
5056 + 25*(k-201)
SC
rtVbr
nrtVbr
ubr+ / ubr
rtVbr
rtVbr
ubr
rtVbr
#
7
7
2
1
6
1
1
Table 5-9, RNC vpi.vci, sharedForTrafficTypes, No hspa streaming, IubIf in the range [201, 400]
VCC type:
qos0
qos2
qos3
CP
CCP
NodeB oam
Alcap
AAL
aal2
aal2
aal2
aal5
aal5
aal5
aal5
port
VPI
801
5034
5042
5041
5050
5051
5033
5057
+ 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
k = 401 to 600
to
to
+
VCI
5040 + 25*(k-401)
5048 + 25*(k-401)
5049 + 25*(k-401)
to
5056 + 25*(k-401)
SC
rtVbr
nrtVbr
ubr+ / ubr
rtVbr
rtVbr
ubr
rtVbr
#
7
7
2
1
6
1
1
Table 5-10, RNC vpi.vci, sharedForTrafficTypes, no hspa streaming, IubIf in the range [401,
600]
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 223/240

VCC type:
qos0
qos2
qos3
CP
CCP
NodeB oam
Alcap
AAL
aal2
aal2
aal2
aal5
aal5
aal5
aal5
port
VPI
802
5034
5042
5041
5050
5051
5033
5057
+ 25*(k-601)
+ 25*(k-601)
+ 25*(k-601)
+ 25*(k-601)
+ 25*(k-601)
+ 25*(k-601)
+ 25*(k-601)
k = 601 to 800
to
to
+
VCI
5040 + 25*(k-601)
5048 + 25*(k-601)
5049 + 25*(k-601)
to
5056 + 25*(k-601)
SC
rtVbr
nrtVbr
ubr+ / ubr
rtVbr
rtVbr
ubr
rtVbr
#
7
7
2
1
6
1
1
800]
VCC type:
qos0
qos2
qos3
CP
CCP
NodeB oam
Alcap
AAL
aal2
aal2
aal2
aal5
aal5
aal5
aal5
Port
VPI
808
k = 801 to 1200
VCI
34
42
41
50
51
33
57
+ 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
to
to
+
40 + 25*(k-801)
48 + 25*(k-801)
49 + 25*(k-801)
to
56 + 25*(k-801)
SC
rtVbr
nrtVbr
ubr+ / ubr
rtVbr
rtVbr
ubr
rtVbr
#
7
7
2
1
6
1
1
1200]
VCC type:
qos0
qos2
qos3
CP
CCP
NodeB oam
Alcap
AAL
aal2
aal2
aal2
aal5
aal5
aal5
aal5
Port
VPI
800
&
801
&
802
16383
16391
16390
16399
16400
16382
16406
k = 1201 to 2400
VCI
+ 25*(k-1201) to 16389 + 25*(k-1201)
+ 25*(k-1201) to 16397 + 25*(k-1201)
+ 25*(k-1201) + 16398 + 25*(k-1201)
+ 25*(k-1201)
+ 25*(k-1201) to 16405 + 25*(k-1201)
+ 25*(k-1201)
+ 25*(k-1201)
SC
rtVbr
nrtVbr
ubr+ / ubr
rtVbr
rtVbr
ubr
rtVbr
#
7
7
2
1
6
1
1
2400]
5.1.3.2 SHAREDFORTRAFFICTYPES BWPOOL, WITH HSPA STREAMING:

RNC Iub interface, preference sharedForAllTrafficTypes, k = 1 to 200
VCC type:
qos0
qos1
qos2
qos3
CP
CCP
NodeB oam
POC InBdOam
Alcap
AAL
aal2
aal2
aal2
aal2
aal5
aal5
aal5
aal5
aal5
port
VPI
800
&
801
&
802
38
34
42
41
50
51
33
+ 24*(k-1)
+ 24*(k-1)
+ 24*(k-1)
+ 24*(k-1)
+ 24*(k-1)
+ 24*(k-1)
+ 24*(k-1)
VCI
to
to
to
+
40
37
48
49
to
56 + 24*(k-1)
+ 24*(k-1)
+ 24*(k-1)
+ 24*(k-1)
+ 24*(k-1)
32
5033 - k
SC
cbr
rtVbr
nrtVbr
ubr+ / ubr
rtVbr
rtVbr
ubr
ubr
rtVbr
#
3
4
7
2
1
6
1
1
1
25
Table 5-14, RNC vpi.vci, SharedForTrafficTypes, hspa streaming, IubIf in the range [1, 200]
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 224/240

VCC type:
qos0
qos1
qos2
qos3
CP
CCP
NodeB oam
Alcap
AAL
aal2
aal2
aal2
aal2
aal5
aal5
aal5
aal5
port
VPI
800
5038
5034
5042
5041
5050
5051
5033
5057
+ 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
VCI
to
to
to
+
5040
5037
5048
5049
to
5056 + 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
+ 25*(k-201)
SC
cbr
rtVbr
nrtVbr
ubr+ / ubr
rtVbr
rtVbr
ubr
rtVbr
#
3
4
7
2
1
6
1
1
25

VCC type:
qos0
qos1
qos2
qos3
CP
CCP
NodeB oam
Alcap
AAL
aal2
aal2
aal2
aal2
aal5
aal5
aal5
aal5
port
VPI
801
5038
5034
5042
5041
5050
5051
5033
5057
+ 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
VCI
to
to
to
+
5040
5037
5048
5049
to
5056 + 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
+ 25*(k-401)
SC
cbr
rtVbr
nrtVbr
ubr+ / ubr
rtVbr
rtVbr
ubr
rtVbr
#
3
4
7
2
1
6
1
1
25

VCC type:
qos0
qos1
qos2
qos3
CP
CCP
NodeB oam
Alcap
AAL
aal2
aal2
aal2
aal2
aal5
aal5
aal5
aal5
port
VPI
802
5038
5034
5042
5041
5050
5051
5033
5057
+25*(k-601)
+25*(k-601)
+25*(k-601)
+25*(k-601)
+25*(k-601)
+25*(k-601)
+25*(k-601)
+25*(k-601)
VCI
to
to
to
+
5040
5037
5048
5049
to
5056 +25*(k-601)
+25*(k-601)
+25*(k-601)
+25*(k-601)
+25*(k-601)
SC
cbr
rtVbr
nrtVbr
ubr+ / ubr
rtVbr
rtVbr
ubr
rtVbr
#
3
4
7
2
1
6
1
1
25

VCC type:
qos0
qos1
qos2
qos3
CP
CCP
NodeB oam
Alcap
AAL
aal2
aal2
aal2
aal2
aal5
aal5
aal5
aal5
port
VPI
808
38
34
42
41
50
51
33
57
+ 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
VCI
to
to
to
+
40
37
48
49
to
56 + 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
+ 25*(k-801)
SC
cbr
rtVbr
nrtVbr
ubr+ / ubr
rtVbr
rtVbr
ubr
rtVbr
#
3
4
7
2
1
6
1
1
25
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 225/240

VCC type:
qos0
qos1
qos2
qos3
CP
CCP
NodeB oam
Alcap
AAL
aal2
aal2
aal2
aal2
aal5
aal5
aal5
aal5
port
VPI
800
&
801
&
802
16387
16383
16391
16390
16399
16400
16382
16406
+ 25*(k-1201)
+ 25*(k-1201)
+ 25*(k-1201)
+ 25*(k-1201)
+ 25*(k-1201)
+ 25*(k-1201)
+ 25*(k-1201)
+ 25*(k-1201)
VCI
to
to
to
+
16389
16386
16397
16398
+ 25*(k-1201)
+ 25*(k-1201)
+ 25*(k-1201)
+ 25*(k-1201)
to 16405 + 25*(k-1201)
SC
cbr
rtVbr
nrtVbr
ubr+ / ubr
rtVbr
rtVbr
ubr
rtVbr
#
3
4
7
2
1
6
1
1
25
Table 5-19, RNC vpi.vci, SharedForTrafficTypes, hspa streaming, IubIf in the range [1201,
2400]
Remarks:
-
Per default, within the SharedForTrafficTypes bwPool, up to two vci are allocated to the
hspa I/B vcc. If more hspa I/B vcc are required either in the sharedForAllTrafficTypes or
the primaryForTrafficType BwPool then the highest vci from the qos2, qos1 or qos0 vci
range are going to be assigned to the hspa I/B vcc.
In such a way to provide backward compatibility with the UA5 release, for each nodeB
identified by IubIf=[1, 200], the Alcap vci and the other nodeB vcc are not contiguous.
When Pnni is configured on the RNC/POC interface, then the RNC/POC atm interface is
NNI, the vpi field is coded on 12 bits; therefore the range of vpi values is: [0, 4095]. The
vpi/vci values are automatically chosen by Passport in a pre-configured range at Pnni sPvc
setup.
When a primaryForTrafficType bwPool is configured per nodeB, it is composed of a variable amount of

aal2 vcc; moreover these vcc may be configured with different qos vcc.
The same vpi.vci range is assigned to both:
- The vcc within the sharedForAllTrafficTypes bwPool and
- The vcc within the primaryForTrafficType bwPool.
The vpi.vci not assigned to the vcc within the sharedForAllTrafficTypes bwPool are going to be assigned
the vcc within the primaryForTrafficType bwPool.
5.1.3.3 PRIMARYFORTRAFFICTYPE BWPOOL, CASE OF ONLY QOS3 VCC:

The NodeB is populated with IMA; one primaryForTrafficType bwPool is associated to the NodeB IMA
group; the bwPool is composed of one or several qos3 vcc:
RNC Iub interface, preference primaryForTrafficType
VCC type:
qos3
AAL port VPI

VCI
aal2
0
vci that are not allocated to shared bwPool
Table 5-20, RNC vpi.vci, primaryForTrafficType, only qos3 vcc
SC
#
ubr/ubr+ 16
Remark: One available vci amongst the pool of vci reserved per nodeB.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 226/240

VCC type:
qos1
qos2
qos3
AAL
port
aal2
aal2
aal2
VPI
VCI
vci that are not allocated to shared bwPool
SC
rtVbr
nrtVbr
ubr/ubr+
1
1
1
3

VCC type:
qos1
qos2
qos3
AAL
port
aal2
aal2
aal2
VPI
VCI
vci that are not allocated to shared bwPpool
SC
rtVbr
nrtVbr
ubr/ubr+
4
4
5
13
5.1.3.6 TRAFFIC SHAPING AT VP LEVEL:

When the trafficShaping at vp level is activated on the RNC side and the vp formation consists of all the
vcc from one nodeB, as an example the RNC vcc are identified by the same vci as the NodeB vcc (
5.1.2) and with a vpi value per nodeB chosen by the operator.
If the RNC is populated with the classical 16pOC3 FP, the 16pOC3 FP attributes must be set accordingly.
5.1.4
PNNI
5.1.4.1 PNNI ATM CONNECTION IDENTIFIERS

On each intermediate interface, during the pnni sPvc establishment phase, the RNC and atmSwitches
select the vpi.vci on each crossed atm interface in a predefined range as following:
If the pnni sPvc originating node has a higher nodeId than pnni sPvc destination node:
The RNC or atmSwitch (Passport based) originating node selects a vpi=0 and a vci in
the range specified by the minAutoSelectedVciForVpiZero and
maxAutoSelectedVciForVpiZero attribute.
If no Vci are available for vpi=0, then a vci is chosen in the next vpi, vci range is then
delimited by the minAutoSelectedVciForNonZeroVpi and the
maxAutoSelectedVciForNonZeroVpi attribute.
Else, the sPvc originating node allows the sPvc destination node to assign the vpi.vci.
The NodeId attribute is under atmRouting Pnni ConfiguredNode.
5.1.4.2 PNNI SPVC HAIRPINS

Each Pnni sPvc Hairpin is composed of two ports. The atm interface between the two ports is declared as
UNI.
One port is configured with the attribute AtmIf Uni set to User, whereas the second is configured with the
attribute AtmIf Uni set to Network.
On the port with the attribute: AtmIf Uni = Network is configured the Destination (or Source) of the Pnni
sPvc.
On the port with the attribute: AtmIf Uni = User are configured the pvc.
Note: the ports assigned to Iub, Iu and Iur interfaces are configured with the attribute: AtmIf Pnni.
5.1.4.2.1 IUB PNNI SPVC HAIRPINS

ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 227/240
In UA6, the Iub pnni sPvc hairpin is still involved in the pnni iub traffic from the nodeB configured in
the previous release (up to 200 nodeB).
The pnni sPvc from the additional NodeB configured in UA6 dont terminate on the RNC pnni hairpins,
on the contrary the additional pnni sPvc originates (or terminates) on the application (atmMpe, aal2If,
iubIf).
Related to the nodeB already configured in UA5 and using the pnni, userPlane, CP, CCP and oam pnni
sPvc terminate on the pnni hairpins.
5.2
FP ATTRIBUTES
5.2.1
16POC3/STM1 FP ATTRIBUTES
5.2.1.1 MIGRATION FROM UA5 TO UA6:

Before starting the migration procedure, the UA5 16pOC3 FP attributes are kept unchanged. The Alcap
vcc are configured for the nodeB IubIf = [1, 200]. They are identified with vpi.vci values accepted by the
UA5 16pOC3 FP attributes, without overlapping with the vpi.vci already reserved in UA5 for the nodeB
IubIf =[1, 200].
During the migration, upgrade the 16pOC3 FP attributes (Ca, ConnMap and Engg) according to the Table
5-23, UA6, 16pOC3 Attribute.
NodeB k=801 to 1200:
To connect the nodeB k=801 to 1200, the RNC must be upgraded to UA6 and the pnni hairpins must be
removed. The 16pOC3 FP resources previously assigned to the pnni hairpin ports are allocated to the
port sdh8 in such a way this port supports the atm connections for the nodeB k=801 to 1200.
5.2.1.2 PORT ASSIGNMENT

As long as the pnni hairpins are required, the two following 16pOC3FP connectivity schemes are taken
into consideration for setting the RNC 16pOC3/Stm1 FP Attribute values:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 228/240
RNC
RNC
16pOC3/Stm1
16pOC3/Stm1 FP
FP
Em
Rec 7
15 Em
Rec
Em 6
Rec
14 Em
Rec
Iur/Iu UNI/NNI
Iu/Iur Shaped VPT

APC 33
APC
APC 11
APC
Em 5
Rec
13 Em
Rec
N/U
Iub Shaped VPT
Em 3
Rec
11 Em
Rec
UNI / Pnni
Em 2
Rec
10 Em
Rec
UNI / Pnni
Em 1
Rec
UNI / Pnni
Em 0
Rec
N/U
Iub
POC
POC
APC 22
APC
12 Em
Rec
APC 00
APC
Em 4
Rec
9 Em
Rec
User side
Iub sPVC Hairpins

UNI
Network side
User side
UNI
Iub sPVC Hairpins
Network side
8 Em
Rec
TEG
Figure 5-4 16pOC3 connectivity scheme, without Pnni on the Iu/Iur interface
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 229/240
RNC
RNC
16pOC3/Stm1
16pOC3/Stm1 FP
FP
N/U
User side
User side
Em 6
Rec
14 Em
Rec
Em 5
Rec
APC 33
APC
Network side
15 Em
Rec
APC 11
APC
Iu/Iur sPVC Hairpins
Em
Rec 7
13 Em
Rec
Em 4
Rec
12 Em
Rec
Em 3
Rec
11 Em
Rec
UNI / Pnni
Em 2
Rec
10 Em
Rec
UNI / Pnni
Em 1
Rec
Iur/Iu Pnni
N/U
User side
Iub sPVC Hairpins
Iu/Iur sPVC Hairpins
Iub
Network side
APC 22
APC
APC 00
APC
POC
POC
UNI / Pnni
Em 0
Rec
9 Em
Rec
UNI
Network side
User side
UNI
Iub sPVC Hairpins
Network side
8 Em
Rec
TEG
Figure 5-5 16pOC3 connectivity scheme, with Pnni on the Iu/Iur interface
Per default three stm1/oc3 are assigned to the Iub interface, in combination with the vpi.vci specified in
5.1, this allows to configure up to 800 nodeB. The configuration of up to 1200 nodeB requires the
allocation of a fourth stm1/oc3 to the Iub.
5.2.1.3 ATTRIBUTE VALUES

For the above 16pOC3FP connectivity schemes and taking into consideration the vpi.vci space specified
in 5.1.3, the table below is an example of 16pOC3 FP attributes values and can be used as default
values. For more specific RNC utilizations (e.g.: more shaped VPC, utranSharing and IuFlex with large
amount of coreNetwork nodes), these values should be customized.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 230/240
Iub
Iu/Iur
Iu/Iur/Iub
- Iub VPT
Iu/Iur/Iub
Iub VPC
Iu/Iur/Iub
Iu/Iur VPT
sPvc
or
Pvc
sPvc
or
Pvc
sPvc
or
Pvc
- Iu/Iur
sPvc H
- Iu/Iur
sPvc H
- Iu/Iur
sPvc H
- Iu/Iur
sPvc H
(network)
(user)
(network)
(user)
Iu/Iur
Iu/IurVPC
Not
Used
Iub
sPvc
Hairpin
(network)
Iub
Iub
sPvc
sPvc
Hairpin Hairpin
(user) (network)
APC 3
Iub
APC 2
Iub
APC 1
APC 0
Iub
sPvc
Hairpin
(user)
Not
Used
Iu/Iur
Iu/Iur
sPvc
or
Pvc
sPvc
or
Pvc
SDH15
SDH0
SDH1
SDH2
SDH3
SDH4
SDH5
SDH6
SDH7
SDH8
SDH9
SDH10
SDH11
SDH12
SDH13
SDH14
12
12
12
12
12
12
16384
16384
16384
1024
1024
1024
1024
1024
8192
8192
8192
8192
1024
1024
AtmIf ConnMap Ov firstNonZeroVpiForVccs
AtmIf ConnMap Ov numNonZeroVpisForVccs
200
22
64
64
AtmIf ConnMap Ov numVccsPerNonZeroVpi
64
64
64
64
64
64
64
64
8192
8192
8192
8192
64
512
512
AtmIf CA maxVccs
3401
3401
3401
536
4802
536
536
64
2500
2500
2500
2500
500
500
AtmIf CA maxVpcs
200
22
AtmIf CA maxVpts
200
22
AtmIf CA minAutoSelectedVciForVpiZero
12982
12982
12982
1023
1023
1023
1023
1023
5691
5691
5691
5691
523
523
AtmIf CA maxAutoSelectedVciForVpiZero
16383
16383
16383
1023
1023
1023
1023
1023
8191
8191
8191
8191
1023
1023
AtmIf CA minAutoSelectedVpi
4095
4095
4095
255
255
255
255
255
255
4095
4095
AtmIf CA maxAutoSelectedVpi
4095
4095
4095
255
255
255
255
255
255
4095
4095
AtmIf Ca minAutoSelectedVciForNonZeroVpi
63
63
63
63
63
63
63
63
32
8191
8191
8191
8191
63
511
511
AtmIf Ca maxAutoSelectedVciForNonZeroVpi
63
63
63
63
63
63
63
63
32
8191
8191
8191
8191
63
511
511
3402
3402
3402
537
5203
737
581
87
2501
2501
2501
2501
501
501
AtmIf CA maxVpiBits
AtmIf ConnMap Ov numVccsForVpiZero
[maxVccs+maxVpcs+2*maxVpts+1
10743
Lp Eng Arc Ov ConnectionPoolCapacity

Lp Eng Arc Ov protectedConnectionPoolCapacity
6608
7504
3504
1081
28359
Table 5-23, UA6, 16pOC3 Attribute values
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 231/240
5.2.2
16POC3/STM1 MS3 (ATM/POS) FP

Lp/Eng/Arc parameter:
The LP Eng/Arc component from the FP should be configured in such a way to offer a maximum amount
of protected atmConnections, and just a few nonProtected atmConnection available for debugging tool:
Rule: IubTEG_16pOC3/Stm1 atm/Pos_2
Lp/Eng/Arc protectedConnectionPoolCapacity = 31000
Lp/Eng/Arc connectionPoolCapacity = 1000
The parameters: maxVccs, maxVpcs and maxVpts are set per port according to expected amount of
required connections.
At FP level is checked that the resources reserved at port level are below the FP capacity:
atmIf [(maxVccs+maxVpcs) + 2* maxBasisicVpts + 3* maxStdVpts +1 ] < connCap+protConnCap.
5.3
IP
Within the RNC, each nodeB interface is identified by an ipIf instance.
Suggested ipIf values for up to 2400 nodeB:
ipIf
Interface:
Iub
IuPS
Values
to
2400
na
#
2400
Table 5-24, ipIf values
5.4
AAL2
5.4.1
IUBIF / AAL2IF
Between the RNC and the NodeB are configured the aal2 paths.
In the RNC, all the paths terminating in one nodeB are grouped within an aal2If component instance. The
aal2If instance is assigned to one IubIf instance. There is a one to one relationship between an aal2If
instance and an IubIf instance.
IubIf and aal2if instance value range:
iubIf
Interface:
Iub
Iub extension
1
300
Values
to
299
to
2400
#
299
2101
2400
Table 5-25, IubIf values
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 232/240
aal2If, no aal2 switch

Interfaces:
Iub
Iub extension
Iu
Iu extension
Iur
Iur extension
1
600
300
375
350
1225
Values
to
299
to
2700
to
349
to
564
to
374
to
1235
#
299
2101
50
190
25
11
Table 5-26, aal2If values
5.4.2
PATHID:
The TEG provides the pathId tables for the contexts:
- sharedForAllTrafficTypes bwPool:
- without hspa Streaming supported on the Iub,
- with hspa Streaming supported on the Iub,
- primaryForTrafficType bwPool.
Remark:
The pathId table for case of sharedForAllTrafficTypes bwPool without hspa streaming may be
also used during the migration between UA5 and UA6 with hspa streaming.
The table below indicates the suggested Pathid values to configure per nodeB according to iubIf value
assigned to NodeB. (The iubIf is noted k in the table).
1/ Case of sharedForAllTrafficTypes bwPool, without hspa streaming supported:
Iub
Path
qos0
qos2
qos3
QOS
PATHID
0
(16*k)
to ((16*k) - 6)
2
((16*k) - 8) to ((16*k) - 14)
3
((16*k) - 15) + ((16*k) - 7)
#
7
7
2
Range
1
43200
Table 5-27, PathIds for sharedForAllTrafficTypes, without hspa streaming
2/ Case of sharedForAllTrafficTypes bwPool, with hspa streaming supported:
Iub
Path
qos0
qos1
qos2
qos3
QOS
PATHID
0
(16*k)
to ((16*k)-2)
1
((16*k) - 3) to ((16*k)-6)
2
((16*k) - 14) to ((16*k) - 8)
3
((16*k) - 15) + ((16*k) - 7)
#
3
4
7
2
Range
1
43194
Table 5-28, PathIds for sharedForAllTrafficTypes, with hspa streaming
3/ Case of primaryForTrafficType bwPool, case of only qos3 vcc configured:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 233/240
1 qos
Iub
Path
QOS
Pathid
qos3
Pathids that are not allocated

to shared Bwpool
16
Table 5-29, PathIds for primaryForTrafficType, case of only qos3 vcc
4/ Case of primaryForTrafficType bwPool, case of qos1, qos2 and qos3 vcc configured:
3 qos
Path
Iub
QOS
Pathid
1
2
3
Pathids that are not allocated

to shared Bwpool
4
4
5
qos1
qos2
qos3
Table 5-30, PathIds for primaryForTrafficType, case of three kinds of qos vcc
5.5
IMA
5.5.1
NODEB HOLDING PRIORITY

Since the nodeB IMA Defence is activated, the HoldingPriority values must be set against the vcc.
The choice of the HoldingPriority value is determined in conjunction with the amount of links within the
IMA group, the amount of vcc per IMA group and the associated trafficDescriptor values.
The objective is that the NodeB IMA Defence behaves as expected by the RNC congestionManagement.
Are distinguished three Iub topologies:
- IMA Group associated to a sharedForTrafficTypes bwPool,
- IMA Group associated to a primaryForTrafficType bwPool composed of only qos3 vcc,
- IMA Group associated to a primaryForTrafficType bwPool composed of qos0, qos1,
qos2 and qos3 vcc.
Moreover are distinguished the cases of:
- Iub interface not supporting the Hspa streaming traffic,
- Iub interface supporting the Hspa streaming traffic.
Migration: The case of Iub interface not supporting the Hspa streaming traffic may be also considered as
the intermediate state of the migration from UA5-1 to UA6 with hspa streaming.
5.5.1.1 IMA GROUP ASSOCIATED TO A PRIMARYFORTRAFFICTYPE BWPOOL

COMPOSED OF ONLY QOS3 VCC:
As many qos3 vcc are configured as amount of links within the IMA Group.
Different HP values in range [1, 16] are assigned to each vcc.
The NodeB supporting up to 8 links within an IMA Group, then up to 8 qos3 vcc may be configured and
then up to 8 HP values may be allocated from the range: [1, 16].
Example:
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 234/240
E1_ 1
E1_ 2
E1_ 3
E1_ 4
E1_ 5
E1_ 6
E1_ 7
E1_ 8
Vcc
qos3
qos3
qos3
qos3
qos3
qos3
qos3
qos3
HP
1
2
3
4
5
6
7
8
Table 5-31, HP for primaryForTrafficType, only qos3 vcc
5.5.1.2 IMA GROUP ASSOCIATED TO A PRIMARYFORTRAFFICTYPE BWPOOL

COMPOSED OF QOS0, QOS1, QOS2 AND QOS3 VCC:
The IMA group is composed of up to 8 links beside the nodeB supports up to 16 aal2 vcc.
For each link within the IMA group is configured a set of aal2 vcc. A set of vcc is composed of one or
two aal2 vcc with different qos. The same HP value is assigned to both vcc with a set of vcc.
The set of vcc per link within the IMA Group are indicated in the below table:
Vcc
E1_ 1
E1_ 2
qos1
qos2
qos3
E1_ 3
E1_ 4
qos1
qos2
qos3
E1_ 5
E1_ 6
E1_ 7
E1_ 8
qos1
qos2
qos3
qos3
qos1
qos2
qos3
HP
1
2
3
4
5
6
7
8
Table 5-32, HP for primaryForTrafficType, 3 qosx vcc
5.5.1.3 IMA GROUP ASSOCIATED TO A SHAREDFORTRAFFICTYPES

BWPOOL:
Per E1 within the IMA group is configured a set of vcc. The same HP value is assigned to each vcc within
a set of vcc.
A set of vcc is composed of 1, 2, 3 or 4 vcc.
The table below indicates the HP value per vcc according to amount of links within the IMA group.
Furthermore are distinguished the case of Hspa streaming not supported and the case of Hspa streaming
supported.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 235/240
If NO Hspa Streaming traffic:
If Hspa Streaming traffic:
NodeB Vcc
CP
CCP
Alcap
OAM
rank
1
1 to 6
1
1
HP
qos0
qos2
qos3
1
1
1
1
1
1
1 E1
qos0
qos2
2
2
2
2
2 E1
qos0
qos2
qos0
qos2
qos2
qos2
qos2
3
3
4
4
5
6
7
3
3
4
5
6
7
8
3 E1
1 E1
2 E1
3 E1
4 E1
5 E1
6 E1
7 E1
8 E1
4 E1
5 E1
6 E1
7 E1
8 E1
12 aal2 vcc
NodeB Vcc
CP
CCP
Alcap
OAM
qos0
qos1
qos2
qos3
qos0
qos1
qos2
qos0
qos1
qos2
qos1
qos2
qos2
qos2
qos2
rank
1
1 to 6
1
1
1
1
1
1
2
2
2
3
3
3
4
4
5
6
7
HP
0
1
1
1
1
2
2
2
3
3
3
4
5
6
7
8
15 aal2 vcc
Table 5-33, HP, IMA group composed of up to 8 links
5.5.2
IMA LINKGROUP ID:

In the IMA protocol called ICP, the identifier of the IMA LinkGroup is carried in IMA ID field.
On NodeB side, when configuring IMA:
- Set backhaul protocol type to 1 (0 = multi PCM),
- define one IMA linkGroup with instance 0,
- Set VCC_interface_type to 1 for all VCCs (0 = multi PCM)
- Set VCC_externalPortId to 0 (= IMA group number)
5.5.3
TRAFFIC DESCRIPTOR
5.6
TRAFFIC DESCRIPTOR
for
all
VCCs.
The determination of TrafficDescriptor values should be the result of an UMTS Dimensioning study as
long as they are involved in the atm traffic regulation mechanismes.
5.6.1
AAL2 VCC TD
Within the RNC the vcc TD are taken into consideration by the atm Cac, the link Cac and the
congestionManagement. It is not recommended to activate the trafficShaping at vc level.
Within the RNC, as an option the VPC trafficShaping is activated, then the vpc TD is configured.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 236/240
The atmConnection TD values satisfy the atm Cac condition as long as the RNC port overbooking factor
is correctly set:
atmConnection ECRacac < overbookingFactor * linkRate.

To satisfy the RNC linkCac and congestionManagement, the RNC vcc TD must be set in such a way the
RNC has knowledge of the bandwidth populated on the nodeB side. The nodeB populated bandwidth
results from an UMTS dimensioning exercise.
The RNC linkCac and congestionManagement consider that the nodeB populated bandwidth is equivalent
to the vcc ECRgcac for all the vcc configured under a bandwidthPool. Therefore the vcc TD values must
be specified in relation with amount of aal2 vcc configured on the nodeB side.
# aal2 vcc per nodeB:
xPcm
IMA:
1
2
3
4
5
6
7
8
E1
E1
E1
E1
E1
E1
E1
E1
without hspa Streaming
with hspa Streaming
qos0 vcc qos2 vcc qos3 vcc

1
1
1 or 2
qos0 vcc qos1 vcc qos2 vcc qos3 vcc

1
1
1
1 or 2
1
2
3
4
4
4
4
4
1
2
3
3
4
5
6
7
1 or 2
1 or 2
1 or 2
1 or 2
1 or 2
1 or 2
1 or 2
1 or 2
1
2
3
3
3
3
3
3
1
2
3
4
4
4
4
4
1
2
3
3
4
5
6
7
1 or 2
1 or 2
1 or 2
1 or 2
1 or 2
1 or 2
1 or 2
1 or 2
Table 5-34, # aal2 vcc per nodeB
Rule: Iub_TD_
As long as the nodeB IMA is populated with 3 E1, as many qosx vcc are configured as # E1.
With x=[0 and 2] if no hspa streaming supported, x=[0, 1 and 2] if hspa streaming supported.
When a fourth E1 is added, configure one more qos0 vcc if no hspa streaming supported or one more qos1
vcc if hspa streaming supported.
When the fifth, the sixth, the seventh or the eighth E1 is added, configure one more qos2 vcc per added E1.
Vcc trafficDescriptor:
- As long as the nodeB IMA is populated with up to 3 E1 included, the nodeB is configured
with as many qosx vcc as amount of E1 on the nodeB side.
Per definition a set of vcc is composed of (1 qos0 vcc, 1 qos2 vcc) when no hspa streaming or
(1 qos0 vcc, 1 qos1 vcc, 1 qos2 vcc) when hspa streaming.
On the RNC side, the TD for a set of vcc are set in such a way
bandwidth minus bandwidth portion reserved for the signaling.
set
of vcc
ECRgcac = E1
- When adding the fourth E1, one more qos0 vcc is configured if no hspa streaming supported
or one more qos1 vcc is configured if hspa streaming supported.
The TD configured against the added vcc is set in such a way vcc ECRgcac = E1 bandwidth
minus bandwidth portion reserved for the signaling.
- When adding the fifth, the sixth, the seventh or the eighth E1, one more qos2 vcc is
configured per added E1.
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 237/240
The TD configured against the added qos2 vcc is set in such a way qos2vcc ECRgcac = E1
bandwidth minus bandwidth portion reserved for the signaling.
5.6.2
AAL5 VCC TD
On the RNC IMA interface, the Alcap, CP and CCP vcc trafficDescriptors are set in such a way ECR=0.
The ECR=0 is obtained when setting PCR=SCR=MBS=0.
The RNC doesnt allow to configure PCR=SCR=MBS=0 when the TDT = 6 (TrafficDescriptorType).
Therefore:
Rule: Iub_IMA_12
The TDT=1 is set against the Alcap, CP and CCP vcc. Beside the rtVbr serviceCategory is assigned to
the Alcap, CP and CCP vcc.
5.7
PARAMETERS
The aim of this section is to provide a complement of information on some Transport parameters.
5.7.1
TRAFFIC DESCRIPTOR TYPE

Before configuring trafficDescriptor on Passport based node, a TrafficDescriptorType value (TDT)
must be specified.
The TDT value implies available trafficDescriptor parameters.
SC
tdt
Tx tdp1
Rx tdt1
Tx tdp2
Rx tdt2
Tx tdp3
Rx tdt3
pcr
pcr
Vbr
pcr
pcr
scr
scr
mbs
mbs
Ubr
Ubr+
pcr
pcr
mdcr
mdcr
Cbr
5.7.2
PARAMETER CLASS
Parameters are described in NTP and UPUG documents. Target of this section is to bring some
additional information on some parameters.
Class of parameter:
Class 0: the NE must be restarted to take into account a new parameter value.
Class 2: the parameter can be changed on-line provided that the object (or its parent
object) is locked.
Class 3: the parameter can be changed on-line without impact on the service. The new
value is taken into account either immediately or for new calls only.
Operator : the parameter is configurable from the OMC and seen by the operator
Manufacturer : the parameter is configurable from the OMC and only seen by ALU
engineering teams
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 238/240
6 ABBREVIATIONS
AAL: ATM Adaptation Layer
ACAC: Actual CAC
AESA: ATM End Station Address
A2EA: AAL2 End Address
ALCAP:
Access Link Control Application Part
APS: Automatic Protection Switching
ASP: ATM Service Provider
AU-4: Administrative Unit 4 (149,74 Mb/s), from SDH STM1 [R40]
BER: Bit Error Rate
CAC: Connection Admission Control
CC:
Call Control
CDV: Cell Delay Variation
CDVT: Cell Delay Variation Tolerance
CES: Circuit Emulation Service
CLR : Cell Loss Ratio
CP:
Control Port
CPCH: Common Packet Channel
CCP: Communication Control Port
CID:
Channel IDentifier (aal2)
CRB: CommonRadioBearer
CRC: Cyclic Redundancy Code
DCH: Dedicated CHannel
DchFP: Dedicated Channel Frame Protocol
DS:
Delay Sensitive
DSCH: Downlink Shared Channel
ECR: Equivalent Cell Rate
E-DCH:
Extended Dedicated Channel
EEC: Ethernet Equipment Clock
ESMC: ethernet synchronization message channel
EP:
Emission Priority
FACH: Forward Access Channel
FEBE: Far End Block Errors,
FP:
Functional Processor (Passport definition)
GCAC: Generic CAC
GMM: GPRS Mobility Management
GPS: Global Positioning System
GQM: GenericQueueManager
HSDPA:
High Speed Downlink Packet Access.
HSUPA:
High Speed Uplink Packet Access
LCD: Loss of Cell Delineation
LLC: LogicalLinkControl
MBS: Maximum Burst Size
MPE: MultiProtocolEncapsulation
MSTE : MultiplexSection Terminating Equipment
MUX: Multiplexer
NBAP: NodeB Application Part
NBAP-c:
NBAP common
NBAP-d:
NBAP dedicated
NDS: Non Delay Sensitive
NSAP: Network Service Access Point
NNI: Network to Network Interface
OAM: Operation Administration Maintenance
OEM: Other Equipment Manufacturer
PCH: Paging Channel
PCM: Pulse Code Modulation
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 239/240
PCR: Peak Cell Rate

PDH: Plesiochrone Digital Hierarchy
PLCP: Physical layer Convergence Protocol
PNNI: Private NNI
POC: Point Of Concentration
POR: Plan Of Reccord
POS: Packet over SONET,
PPB: part per Billion (10-9)
PRC/PRS:
Primary Reference Clock (PRC) or Primary Reference Source (PRS)
PPM: part per Million (10-6)
PTE: Path Terminating Equipment
PTP:
Precision Time Protocol
QOS: Quality Of Service
RACH: Random Access Channel
RNC-AN: RNC Access Node
RNC-CN: RNC Control Node
RNC-IN:
RNC Interface Node
RNS: Radio Network System
RRC: Radio Resource Control
RRM: RadioResourceManagement
RSTE: RegeneratorSection Terminating Equipment
SC:
Service Category
SCR: Sustainable Cell Rate
SDH: Synchronous Digital Hierarchy
SDT: Stuctured Data Transfer
SDU: Service Data Unit
SEC/SMC:
SDH Equipment Clock (SEC) or SONET Minimum Clock (SMC)
SM:
Session Management
SOC: StateOfCompliance
SPVC: Soft Permanent Virtual Circuit (see PNNI)
SRB: Signalling Radio Bearer
SSM: Synchronization Status Message
SSU/BITS:
Synchronization Supply Unit (SSU) or Building Integrated Timing Supply (BITS)
TBM: Transport Bearer Manager
TMU-R: Traffic Management Unit (RNC-CNODE card)
TRB: TrafficRadioBearer
TTI:
Transmission Time Interval
UBR+: UBR+, an enhanced UBR service, provides a guaranteed minimum cell rate
(MCR), or more officially, minimum desired cell rate (MDCR) allocation per connection. ATM Forum has
standardized UBR+ as a TM 4.1 addendum.
UDT: Unstuctured Data Transfer
UNI: User to Network Interface
UP:
UserPlane
UPC: Usage Parameter Control
USCH: Up link Shared Channel
VC:
Virtual Channel
VCC: Virtual Channel Connection. VCC = VPI / VCI
VCI:
Virtual Channel Identifier
VP:
Virtual Path
VPI:
Virtual Path Identifier
VPNNI: Virtual PNNI
VPT: Virtual Path Terminator,
VR:
Virtual Router
END OF DOCUMENT
ALU confidential
UMT/IRC/APP/7149
9.01 / EN
Preliminary
20/09/2010
Page 240/240

Umt Irc App 007149 v09.01 Iub Teg Ua7.1.2 Preliminary

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Umt Irc App 007149 v09.01 Iub Teg Ua7.1.2 Preliminary

Diunggah oleh

Hak Cipta:

Format Tersedia

Iub Transport Engineering Guide

Copyright 2007 Alcatel-Lucent, All Rights Reserved

Iub Transport, engineering guide

FRS79363 syncE for IP nodeB.

3.4.9: mod dsd=multiService

3.2.3.3 RNC CM Thresh param: upd

- 3.7.7: Change, deadInterval reduced to 3 seconds

FRS 23479 Advanced QoS Transport Framework,

Iub Transport, engineering guide

- FRS 34237 RateController,

3.7.11: Icn: removed

3.7.9+4.1.8: FRS34012 Iur Hsdpa taken into consideration by

Add 3.7.9.1.4 1 IMA and 2 bwPool .

3.8.1.1 NodeB CEM upd

MicroNodeB: updates based on tests.

Hsupa, modification: one single dSRB per hsupa-hsdpa

FRS 33767: Iub over protected atm ring,

Change the Passport Release associated to the UA4-2.

Iub Transport, engineering guide

Iub Transport, engineering guide

Iub Transport, engineering guide

PLANE RELATIVE ...................................................................................................................218

Iub Transport, engineering guide

SCOPE OF THIS DOCUMENT

This document covers:

AUDIENCE FOR THIS DOCUMENT

Iub Transport, engineering guide

Iub Transport, engineering guide

UTRAN Iub: General Aspects and Principles

PDH, Digital Hierarchy Bit Rates

Iub Transport, engineering guide

Synchronous Optical Network (SONET)

NTP ATM TrafficManagement

3 IUB TRANSPORT NETWORK LAYER,

Iub Transport, engineering guide

(R99 & Hspa Str)

Figure 3-1, Atm and Hybrid IUB Protocol stack

Iub Transport, engineering guide

Figure 3-2 native IP IUB Protocol stack

Iub Transport, engineering guide

Figure 3-3 Iub topology

ATM RING ON IUB

Iub Transport, engineering guide

Each nodeB is populated with a small capacity atmSwitch supporting pnni .

Figure 3-4 Atm ring topology on Iub

Iub Transport, engineering guide

Figure 3-5 Sdh ring with IMA on the Iub

Iub Transport, engineering guide

Figure 3-6 Hybrid Utran topology

Iub Transport, engineering guide

TRANSPORT ADMISSION CONTROL

Iub Transport, engineering guide

3.2.1.1 EQUIVALENT BIT RATE

Iux + RAB (+THP option)

Identification of the ulRbSetConf and the dlRbSetConf within

Per direction (UL and DL) and

Iub Transport, engineering guide

[0..16777216], Step 1, Unit bit/s

[0..16777216], Step 1, Unit bit/s

[0..16777216], Step 1, Unit bit/s

[0..16777216], Step 1, Unit bit/s

[0..16777216], Step 1, Unit bit/s

[0..16777216], Step 1, Unit bit/s

Step 1, Unit bit/s