Umt Irc App 007149 Iub Teg Ua6 External STD Ed7-2 STD 090629

Iub Transport Engineering Guide
Document number:
Document issue:
Document status:
Date:
Author:
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
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
7-2
UA6
29/06/09
26/01/09
7-1
ReasonsForChange
3.6.2.1.3: add the qos mapping table for the 16pOC3 PQC FP
3.8.7.2+5.5.1.3: Modification: sharedForTrafficType qos3 vcc
HP=0 to HP=1.
Standard
3.6.2.2.3: upd, 16pOC3 MS3 FP ECMP.
3.6.10.5.1: upd, asym traffic with 1 bwPool.
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
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 .
7-0
6-2
5-1
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,
FRS 34237 RateController,
FRS 34682 NodeB IMA Defence.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 3/263
5-0
5-0
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.
42-2
4-2
42-1
4.1
4-0
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.
05/01/05
3.9.7: IMA LG Bw Reduction mechanism update

4.4.1: Hsdpa upd.
5: add vpi/vci for Iu/Iur pnni sPvc Hairpins.
3.9.5 MCR is added to the Hsdpa Vcc
5: MSA32FP Attributes added.
3.9.5: NodeB PriorityLevel value modifications.
UA 4-2 Update:
- 5 aal2 Id range increased to cover 400 nodeBs,
- 5: IuCS UP, IuxIf replaced by IubIf+aal2If.
- 3 + 5.1.1: AAL1 CES added,
- 3, 5: HSDPA UMTS Flow,
- 3 aal2LinkCac ACR enhancement.
26/11/04
3 SDH OAM flow renaming, and update,

3 ATM IMA: fallback information update,
3 ATM OAM:
AIS trigger update,
LoopBack comments added,
5, 16pOC3 attributes: update
3.8, NodeB CRC4 added
01/08/04
Review UA 4-1, 25/07/04
&
3
4.0
4-0
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 4/263
Removal of Iub TrafficDescriptor values.

UA 4-1 Update:
3.7: MSA SparingPanel added
SS MSA32 FP added
2pStm1 e Ch FP added
2pOC3 FP added
3&4&5: RNC1500 information.
&
3.3.6.3: TS update: isolate OAM VCC from VPC.

3.3.12.3: ATM LoopBack modification.
3.4: InverseARP added
5-4 Add PCR value for OAM VCC, case of no TrafficShaping
on NodeB.
3.3.11.5.2 add NodeB IMA bandwidthReduction parameters
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 5/263
CONTENTS
1
INTRODUCTION............................................................................................................................9
OBJECT ....................................................................................................................................9
SCOPE OF THIS DOCUMENT .......................................................................................................9
AUDIENCE FOR THIS DOCUMENT ................................................................................................9
2
RELATED DOCUMENTS ............................................................................................................10
3
IUB TRANSPORT NETWORK LAYER, DESCRIPTION ............................................................12
3.1
TRANSMISSION .......................................................................................................................13
3.1.1
PDH:..............................................................................................................................13
3.1.2
SDH/SONET: ................................................................................................................17
3.2
ATM ......................................................................................................................................24
3.2.1
ATM interface Type .......................................................................................................24
3.2.2
VPC, VPT ......................................................................................................................25
3.2.3
OverSubscription...........................................................................................................31
3.2.4
CAC...............................................................................................................................31
3.2.5
Traffic Management ......................................................................................................33
3.2.6
QOS ..............................................................................................................................38
3.2.7
Fractional E1/T1 ............................................................................................................47
3.2.8
Addressing ....................................................................................................................52
3.2.9
PNNI..............................................................................................................................52
3.2.10
IMA ...............................................................................................................................56
3.2.11 ATM OAM......................................................................................................................61
3.3
AAL2.....................................................................................................................................69
3.3.1
Addressing ....................................................................................................................69
3.3.2
Alcap .............................................................................................................................69
3.4
IP ..........................................................................................................................................71
3.4.1
InverseARP ...................................................................................................................71
3.4.2
SiteLAN .........................................................................................................................73
3.5
IUB TOPOLOGY .......................................................................................................................73
3.5.1
ATM Backbone:.............................................................................................................75
3.5.2
Atm ring on Iub ..............................................................................................................75
3.5.3
SDH ring........................................................................................................................76
3.5.4
Hybrid UTRAN...............................................................................................................77
3.5.5
Ethernet topology ..........................................................................................................78
3.6
RNC ATM .............................................................................................................................79
3.6.1
ASIC ..............................................................................................................................79
3.6.2
FP..................................................................................................................................80
3.6.3
RNC capacity ..............................................................................................................105
3.6.4
Aal2 Components:.......................................................................................................106
3.6.5
Aal2 Paths ...................................................................................................................113
3.6.6
Aal2 QOS ....................................................................................................................114
3.6.7
aal5 connections .........................................................................................................114
3.6.8
QOS ............................................................................................................................115
3.6.9
TransportMap ..............................................................................................................117
3.6.10 Transport admission Control .......................................................................................124
3.6.11 Congestion Management bandwidth Limitation a.k.a rate Control .............................137
3.6.13 NodeB discrimination ..................................................................................................143
3.6.14 Alcap ...........................................................................................................................144
3.6.15 Utran Sharing ..............................................................................................................147
3.6.16 PNNI Hairpin removal .................................................................................................149
3.7
RNC HYBRID........................................................................................................................150
3.7.1
FP................................................................................................................................150
3.7.2
RNC capacity ..............................................................................................................156
3.7.3
IP Components............................................................................................................157
3.7.4
Virtual Router RNC composition .................................................................................163
3.7.5
LocalMedia ..................................................................................................................165
1.1
1.2
1.3
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 6/263
3.7.6
PDR.............................................................................................................................168
3.7.7
ICMP HeartBeat ..........................................................................................................172
3.7.8
QOS ............................................................................................................................174
3.7.9
TransportMap ..............................................................................................................176
3.7.10 Transport admission Control .......................................................................................179
3.7.11 CongestionManagement bandwidth Limitation a.k.a rate Control ..............................183
3.7.12 Routing: .......................................................................................................................190
3.7.13 NodeB discrimination ..................................................................................................190
3.7.14 Utran Sharing ..............................................................................................................191
3.8
NODE B (IBTS).....................................................................................................................191
3.8.1
Cards...........................................................................................................................191
3.8.2
PDH Layer:..................................................................................................................193
3.8.3
Ethernet Layer:............................................................................................................194
3.8.4
Synchronisation...........................................................................................................194
3.8.5
ATM Connections:.......................................................................................................194
3.8.6
MultiPCM.....................................................................................................................195
3.8.7
IMA ..............................................................................................................................196
3.8.8
Mix of N * E1 xPCM and p E1 IMA..............................................................................198
3.8.9
IP .................................................................................................................................199
3.8.10 QOS ............................................................................................................................200
3.8.11 Traffic Management ....................................................................................................202
3.8.12 Hspa CAC ...................................................................................................................204
3.8.13 Alcap ...........................................................................................................................204
3.9
NODEB (ONEBTS)................................................................................................................205
3.9.1
Alcap ...........................................................................................................................205
3.10
MICRO NODEB ATM (BTS 1120) ...........................................................................................205
3.10.1 Transmission: ..............................................................................................................205
3.10.2 Atm: .............................................................................................................................206
3.10.3 Aal2 .............................................................................................................................208
3.10.4 SAAL: ..........................................................................................................................208
3.10.5 IP: ................................................................................................................................209
3.10.6 UMTS traffic flows: ......................................................................................................210
3.11
PICO NODEB ATM (BTS 1010) ...............................................................................................211
3.11.1 Transmission: ..............................................................................................................211
3.11.2 Atm: .............................................................................................................................211
3.11.3 Aal2: ............................................................................................................................212
3.11.4 IP: ................................................................................................................................212
3.11.5 UMTS traffic flows: ......................................................................................................213
3.12
7670....................................................................................................................................213
3.13
UMTS PLANE DESCRIPTION ..................................................................................................214
3.13.1 HSUPA Plane..............................................................................................................214
3.13.2 HSDPA Plane..............................................................................................................216
3.13.3 OAM Plane ..................................................................................................................218
3.13.4 Control Plane...............................................................................................................225
3.13.5 User plane ...................................................................................................................226
3.13.6 ATM Backbone Requirements ....................................................................................227
4
UMTS RELEASES.....................................................................................................................228
4.1
RNC....................................................................................................................................228
4.1.1
FP................................................................................................................................228
4.1.2
RNC Types:.................................................................................................................230
4.1.3
RNC capacity: .............................................................................................................230
4.1.4
Iuxif / IubIf / aal2If:.......................................................................................................230
4.1.5
Pathid: .........................................................................................................................230
4.1.6
Aal2 Path assignment to PMC-PC ..............................................................................231
4.1.7
AAL2 Link CAC: ..........................................................................................................231
4.1.8
aal2CongestionManagement ......................................................................................232
4.1.9
Icn VCC .......................................................................................................................232
4.1.10 TMU.............................................................................................................................232
4.1.11 QOS ............................................................................................................................233
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 7/263
4.2
NODEB ................................................................................................................................233
4.2.1
CCM related: ...............................................................................................................233
4.2.2
CEM related: ...............................................................................................................233
4.2.3
MultiPCM:....................................................................................................................233
4.2.4
IMA: .............................................................................................................................234
4.2.5
n E1 xPCM + p E1 IMA: ..............................................................................................235
4.2.6
AAL1 CES ...................................................................................................................235
4.2.7
QOS ............................................................................................................................235
4.2.8
Traffic Management ....................................................................................................236
4.3
MICRO NODEB .....................................................................................................................237
4.4
PICO NODEB ........................................................................................................................237
4.5
PLANE RELATIVE ...................................................................................................................237
4.5.1
UMTS HSUPA Plane: .................................................................................................237
4.5.2
UMTS HSDPA Plane: .................................................................................................237
4.5.3
UMTS OAM Plane:......................................................................................................237
4.5.4
UMTS Control Plane: ..................................................................................................238
4.5.5
UMTS User Plane .......................................................................................................238
4.5.6
Transport Network ControlPlane:................................................................................238
5
TRANSPORT IDENTIFIERS .....................................................................................................238
5.1
ATM VCC............................................................................................................................240
5.1.1
UpGrade from UA5 to UA6 .........................................................................................240
5.1.2
NodeB interface ..........................................................................................................242
5.1.3
RNC Interface..............................................................................................................244
5.1.4
PNNI............................................................................................................................249
5.2
FP ATTRIBUTES ....................................................................................................................250
5.2.1
16pOC3/Stm1 FP Attributes........................................................................................250
5.2.2
16pOC3/Stm1 MS3 (Atm/Pos) FP ..............................................................................254
5.3
IP ........................................................................................................................................254
5.4
AAL2...................................................................................................................................254
5.4.1
IubIf / aal2If..................................................................................................................254
5.4.2
Pathid: .........................................................................................................................255
5.5
IMA .....................................................................................................................................256
5.5.1
NodeB Holding Priority................................................................................................256
5.5.2
IMA LinkGroup ID:.......................................................................................................258
5.5.3
Traffic descriptor .........................................................................................................258
5.6
TRAFFIC DESCRIPTOR ...........................................................................................................258
5.6.1
Aal2 vcc TD .................................................................................................................259
5.6.2
Aal5 vcc TD .................................................................................................................260
5.7
PARAMETERS .......................................................................................................................260
5.7.1
Traffic Descriptor Type................................................................................................260
5.7.2
Parameter Class .........................................................................................................260
6
ABBREVIATIONS......................................................................................................................262
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 8/263
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: UA6 GlobalMarket
The variations between the releases are indicated in section 4.
UTRAN Release:
UA 4-1
Passport Release:
OAM Release:
OAM4.2
UA 5-0
PCR6-1
UA 5-1
PCR7-2
OAM5.0
OAM5.0
PCR8-2
This document covers:

- TRANSPORT network layers (Transmission, ATM, aal2, aal5, Alcap, IP, ) 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
07.02 / EN
Standard
29/06/2009
Page 9/263
2 RELATED DOCUMENTS
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 10/263
[
[
[
[[
[[
[
[
[
[
[
[
[
[
[
[
[
[[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
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
07.02 / EN
Standard
29/06/2009
Page 11/263
[
[
[[
[
[
[
[
[
[[
[
[
[[
[[
[[
[
[[
[
[
[
[
[
[
[
[
[
[
[
[
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 IP interface is optional on the Iub interface. If present, the IP interface can be used only for HSPA
Interactive and Background traffic.
The ATM interface is used for transmitting the Signaling, oam, R99, Hspa Streaming and as an option the
HSPA Interactive and Background traffic.
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,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 12/263
- 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.
On the IP interface, the UDP protocol is implemented.
This document covers the Transport Network layers.
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
UDP
UDP
AAL5
AAL5
AAL2
AAL2
IP
IP
ATM
ATM
OAM
umts CP
Ethernet
Ethernet
Transport CP
UP
UP
(R99 & Hspa Str)
(Hspa I/B)
Iub TEG
Figure 3-1, IUB Protocol stack
3.1
TRANSMISSION
3.1.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,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 13/263
T4, 274176 kbit/s, multiplex of 6 T3.
3.1.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.1.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:
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].
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 14/263
3.1.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.1.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
# Bits
# Timeslot
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
7 * 96 = timeSlots
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 15/263
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-2 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) :
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.1.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):

ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 16/263
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.1.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.1.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:
Notation:
-
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
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.1.2.2 TRANSMISSION OAM

Severe problems in signal transmission are notified by means of Maintenance Signals and Status
Signals.
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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 17/263
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
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 18/263
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
RX
RX
RX
RX
RX
RX
TX
TX
Selected Line
TX
TX
RX
RX
TX
TX
TX
TX
RX
RX
RX
RX
TX
TX
PTE
PTE
RSTE
RSTE
MSTE
MSTE
TX
TX
Regenerator
W
TX
TX
PTE
PTE
TX
TX
Line 0
MultiPlex Section 1
RX
RX
TX
TX
TX
TX
RX
RX
RX
RX
TX
TX
MultiPlex Section 2
Figure 3-3 AIS/RDI Generation
3.1.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.
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 19/263
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
Tx
Tx
Rx
Rx
Tx
Tx
Rx
Rx
16pOC3
16pOC3
STM1
Tx
Tx
Rx
Rx
Protected Line
Tx
Tx
Rx
Rx
16pOC3
16pOC3
Duplication of the egress stream
Decision of the ingress stream to take into consideration

Figure 3-4 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.
- 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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 20/263
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.1.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:

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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 21/263
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.
See MML Attribute:

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.1.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:
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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 22/263
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:
100 000 SDH frames 12,5 seconds
- BER = 10-5 :
=> 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:
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
TX
TX
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
POH
No Path OAM signal
MSOH
K1
1101
K2
0001
0000
0000
SF HP Work
Prot
Idle
Figure 3-5 APS switch on LOS Condition

ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 23/263
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
MSOH
No Path OAM signal
MSOH
K1
0000 0000
K1
0000
K2
0000
0 110
MS-RDI
K2
0000
0000
0 111
MS-AIS
UMTS
UMTS
UMTS
UMTS
LOS Condition
AIS
ATM
ATM
ATM
ATM
Regenerator
Regenerator
TX
TX
RX
RX
TX
TX
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-6 APS switch on MS-AIS reception

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.2
ATM
3.2.1
ATM INTERFACE TYPE

ATM implemented on RNC is compliant with [R52].
Two types of ATM interfaces are specified: UNI and NNI.
On UNI interface, VPI field is 8 bits length, whereas on NNI interface VPI field is 12 bits length.
On Iub interface, NodeB, and RNC are configured with ATM Interface type UNI according to 3Gpp.
Public ATM backbones provide only UNI accesses.
RNC-PCM, Iub interface:
UNI
NodeB
NNI
POC
Network side Network side
User side
RNC-IN
User side
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 24/263
On the POC / RNC interface PNNI may be implemented.

RNC-SDH, Iub interface with ATM backbone:
Public
UNI
NodeB
POC
UNI
User side
ATM BackBone
Network side
UNI
RNC-IN
UNI
User side
Figure 3-7 ATM Protocol type

Interface between RNC-IN and ATM Network is UNI.
3.2.2
VPC, VPT
A VPC (Virtual Path Connection) is an ATM Connection resulting from the grouping of different Vcc. A
VPC is identified by VPi (Virtual Path Identifier).
The AtmForum defines the notion of a VP endPoint. A VP endPoint is the node which is responsible for
the grouping of Vcc within a VPC. This function is implemented in Passport nodes as a 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.2.2.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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 25/263
1 E1/T1
VC UP DS
NodeB
x
VC UP NDS
VC CP
VC CCP
VP x , rtVBR
VC OAM
VC OAM
VC UP NDS
VC CP
VC CCP
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
ATM Backbone
VC UP DS
RNC-SDH
RNC-SDH
Figure 3-8 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.
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 26/263
POC
VC OAM
NodeB
VCC OAM
VC UP DS
VC UP NDS
k=x
VC CP
RNC-SDH
VC CCPn
VPu, rtVBR
VC UP NDS
VC CP
VC CCPn
k=y
VC OAM
VCC OAM
POC
VPv, rtVBR
RNC-IN
NodeB
ATM Backbone
VPu, rtVBR
VC UP DS
VCC OAM
VCC OAM
VC UP DS
NodeB
VPv, rtVBR
VC UP NDS
VCC OAM
VC CP
VC CCPn
k=z
VC OAM
VCC OAM
Figure 3-9 VPC setting when NodeB connected to ASP through POC
Rule: IubTEG_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
Rule: IubTEG_VP_02
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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 27/263
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:
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.
Rule: IubTEG_VP_03
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).
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 28/263
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 3.2.6.1.
3.2.2.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.
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-10 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:

ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 29/263
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.
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,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 30/263
3.2.3
OVERSUBSCRIPTION
3.2.3.1 PASSPORT, OVERSUBSCRIBTION:

When configuring Passport, the port bandwidth is allocated to one bandwidth pool or distributed over
several bandwidth pool (bandwidthPool is a Passport component).
One to five bandwidth pools are available.
Then an association is configured between each bandwidth pool and the atm serviceCategory (ies).
Either one bandwidth pool per serviceCategory or all serviceCategories associated to the same
bandwidth pool.
Rule: IubTEG_OvS_01
It is recommended to allocate all the port bandwidth to one single bandwidth pool, and associate all
the service categories to this bandwidth pool.
Here below described setting of bandwidthPools:
Passport
E1/T1
BwPoll-1
100%
All SC
Figure 3-11 OverSubscription

Bandwidth pool equal 100% of link capacity in case of normal subscription.
Bandwidth pool is higher than 100% of link capacity in case of over subscription.
Passport node permits over-subscription for each bandwidth pool at 64 times the port capacity.
Over subscription is configured when setting bandwidth pool component.
The setting of oversubscription influences the CAC.
The Overbooking factor is determined according to the traffic needs.
3.2.3.2 NODEB:
OverSubscription feature is not available on NodeB.
3.2.4
CAC
CAC (Connection Admission Control) is a generic function which checks that connections request less
bandwidth than available.
Different algorithm may be used for CAC implementation
CAC is an algorithm invoked at AtmConnection setup. It verifies that bandwidth required for the new
atmConnection is below than bandwidth available on the physical link.
For Permanent VC, CAC is invoked in provisioning phase, whereas CAC is invoked in establishment
phase for a Switched VC.
Based on atmConnection trafficDescriptor, CAC calculates the ECR (EquivalentCellRate) associated to
this atmConnection. ECR is the bandwidth required for an atmConnection from the CAC point of view.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 31/263
AtmConnection is rejected when it requires more bandwidth than available at physical link.
Different kinds of CAC Algorithm:
- NodeB:
Equivalent cell rate is calculated as following:
- 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:
CDVT is not managed at NodeB level.
-
Passport based nodes:

Two kinds of CAC are implemented in Passport: ACAC (Actual CAC) and GCAC (Generic CAC).
- ACAC (Actual CAC):
The ACAC is a ALU algorithm implemented in Passport. It is a hop-by-hop reservation
scheme performed in the egress and ingress direction regardless of the connection type: PVC,
PVP, SPVC, SPVP, SVC and SVP. It is invoked each time a pvc is provisioned or a svc is
established.
The ACAC calculates the ECR per atmConnection, based on the following ATM QOS and
TrafficManagement parameters:
- Buffer size,
- LinkRate,
- ServiceCategory,
- CLR (CellLossRate).
- PCR, SCR, CDVT, MBS
Moreover the ACAC checks that the sum of ECR for all the atmConnections configured on a
link is lower than link bandwidth. If not, then some atmConnections are rejected.
In such a way to avoid such a situation, before provisioning phase, when determining amount
of atmConnections per link and atmConnection trafficDescriptors, the ACAC algorithm Excel
macro is used to estimate the bandwidth (ECR) required per atmConnections. Since
atmConnection bandwidth (ECR) is known, the amount of atmConnections per link and
atmConnection trafficDescriptors may be tuned in such a way sum of ECR of all
atmConnections configured on a link is lower than link bandwidth.
GCAC (Generic CAC):

The GCAC algorithm is by the Pnni sPvc originating node when setting up the sPvc connections,
Moreover the GCAC algorithm is taken into account by the aal2 Link CAC, invoked at the umts
call establishment.
The GCAC is based on simplified formula:
Rule: IubTEG_CAC_O1
ECRGCAC = 2 * PCR * SCR / (PCR + SCR)
Hsdpa CAC:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 32/263
The Hsdpa CAC is invoked in RAB AssignmentRequest phase, (same as for the aal2LinkCac), it
consists in counting amount of Hsdpa calls per NodeB radio cell.
The amount of allowed Hsdpa calls per NodeB radio cell is configured through the parameter:
HsdpaCellClass/maximumNumberOfUsers
Range: [0..50], Class 0, Granularity RNC, defaultValue 20
3.2.5
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.
3.2.5.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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 33/263
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
Ts= 1/SCR
BT
BT
Figure 3-12 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.2.5.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.
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]
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 34/263
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,
therefore since one block filled an ATM cell, MBS is set equal to 4, and Tm =
20 ms = MBS/SCR:
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:
= 220 s
STM1: = 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= 2 0 m s
ATM
TD
TAT
TAT
P e r io d 2
P e rio d 3
P e rio d 4
T = 1 /P C R
T s = 1 /S C 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 BS / SCR
T T I= 2 0 m s
Figure 3-13 RAB / TrafficDescriptor relationship
This example may be generalized to both userPlane Vcc:

DelaySensitive UP VCC:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 35/263
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-1 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
64kb/s / 64 kb/s
DL
TTI
Background
Interactive /
Ms
UL
64kb/s / 128 kb/s
DL
64kb/s / 384 kb/s
DL
UL
BlockSize
Bits
Bytes
#MaxBlocks
/TTI
Consecutive
ATM cells
For highest TF
20
336
42
20
336
42
20
336
42
20
336
42
10
336
42
12
12
UL
20
336
42
4
Table 3-2 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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 36/263
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.2.5.3 TRAFFICSHAPING
Traffic shaping regulates egress traffic according to trafficDescriptor parameter values.
TrafficShaping is presented in a PowerPoint file stored on Transport web site. Here an extract from this
file.
According to line card, different kinds of trafficShaping are available: singleRate and dualRate shaping.
(SingleRate TS is also called LinearShaping; dualRate TS is also called InverseVBR TS)
On 16pOC3/STM1, only SingleRate TrafficShaping is available, whereas on 4pOC3 both kinds of
trafficShaping are available.
LinearShaping regulates egress traffic according to PCR, whereas dualRate Shaping regulates egress
traffic according to PCR, SCR and MBS. DualRate Shaping may be called VBR shaping.
For a continuous flow of traffic has to be transmitted, and dualRate Shaping is activated, MBS cells are
sent at PCR, following cells are sent at SCR:
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
Cell6 suffers a Delay of 27 , so the whole frame is delayed by 4*Ts

Figure 3-14 DualRate trafficShaping
TrafficShaping is recommended on UMTS nodes, when policing is activated in ATM Backbone
included on the interface.
For such a configuration trafficShaping will be activated at VP level. Therefore before activating
trafficShaping, it is necessary to group Vcc within a VPC by means of VPT.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 37/263
Rule: IubTEG_ATM-TM_1
To the extent that public ATM backbone is not involved on the UMTS interface, 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.
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.2.5.4 NODEB
Node-B VCC can be either shaped or not shaped (see 4 NodeB release compliancy).
When TrafficShaping applies, nodeB transmits MBS cells at PCR, and following cells are sent at SCR.
In certain configuration, when connecting NodeB to RNC across ATM backbone, a VPC may be used
on the POC / RNC interface. All Vcc on NodeB E1/T1 with exception of OAM VCC will be carried on
this VPC. As all E1 /T1 traffic is carried on VPC, this VPC is equivalent to leased line E1/T1.
VP EndPoint is not provided by NodeB.
3.2.5.5 RNC
Traffic shaping is not activated by default in RNC downlink direction.
Traffic shaping is not recommended on a per VC basis since, since it impacts delay.
Moreover, TrafficShaping is available on 16pOC3/STM1 card only with EP0.
Nevertheless in case of RNC-SDH/SONET, when crossing ATM Public network, Traffic Shaping at VP
level is recommended at remote concentrator level and at RNC nodes.
On RNC-IN, hairpins are required on 16p/OC3-STM1 card when invoking on one hand VPT (only
basic VPT available on APC) and on other hand TrafficShaping, what is called the 2portSolution.
As 16 ports STM-1 FP supports only linear shaping, the same linear traffic shaping method should be
used on remote concentrator.
3.2.6
QOS
Within ALU UMTS node, QOS is handled at ATM level, by means of:
Different parameters:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 38/263
ATM Parameters: serviceCategory, CTD, CDV, CLR,
ALU parameters: emissionPriority, discardPriority.
Mechanism: Scheduling.
3.2.6.1 BUFFER
This section concerns Passport based UMTS nodes only.
A queue may be provisioned either per ATM Connection or per serviceCategory; it is referred as
perVcQueuing or Common Queuing.
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
W FQ
CBR
EP2
I = [2, 3, 7]
rtVBR
EP3
EP i Queue
Per VC Queues :
To Link
Egress
Com mon
Queues:
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-15 Buffers within APC based card
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 39/263
AQM
Class
Scheduler:
EP & M BG
Transm it
PerVC & comm on Q ueues
W FQ Or SFQ
EP0 Q ueue
Per VC Queues :
Com mon
Queues:
LinkClass
Queue
for EP0
n1 cells

W eight 1
n2 cells

W eight 2
n3 cells

W eight 3
AT M IP FP QOS M apping
(according to AQ M
Mapp ing Table) :
SC and CLP
EP
(EP0 to EP7)
DP
(DP0 to DP7)
FROM
PQC
E missionPriority/MostUrgent
Or Comm on Queue:
EP0
cells
EP1
CBR
EP2 (CLP1)
CBR
(CLP0)
rtVBR
EP3 (CLP1)
rtVB R
(CLP0)
I = [2, 3, 7]
EP i Queue
Per VC Queues :
To Link
Egress
Com mon
Queues:

W eight 1
nrtVB R
EP4 (CLP1)
nrtVBR
(CLP0)
EP5
LinkClass
Queue
for EP i

W eight 1
EP6
W eight 1
Or Comm on Queue:
UBR
EP7 (CLP0+1
)
DP3
DiscardPriority
DP2
DP1
DP0
AQM M apping Table,

SC m apped to EP & DP. configurable
Figure 3-16 Buffer within AQM based card

Rule: IubTEG_Buffer_01
In the context of UMTS network, only perVC queuing is configured.
Within a serviceCategory, buffers allocated to each AtmConnection have the same characteristics (Size,
thresholds).
The size of the buffer depends on the serviceCategory. For the most urgent serviceCategory (CBR), the buffer
size is short, since delay is not allowed, whereas for less urgent serviceCategory (nrtVBR), buffer size is high,
since delay is acceptable. On the other hand when buffer size is short, cells are more candidates to discard than
when buffer size is high.
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. Indeed the default queue size calculated by the Passport for the
shaped VPC configured on the 16pOC3/Stm1 FP is too short:
On the 16pOC3/Stm1 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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 40/263
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 and 4pOC3/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-17 xpOC3 FP buffer size
MSA32 FP:
MSA32
serviceCategory
CBR
rtVBR
nrtVBR
UBR
BufferSize
maximum effective
96
288
1792
1792
86
259
1344
1344
ratio
90%
90%
75%
75%
Figure 3-18 MSA32 Buffer Size

Within these tables:
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
When setting trafficDescriptor, BufferSize/Effective is used by the CAC for processing ECR.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 41/263
3.2.6.2 CLR
CLR (Cell Loss Ratio) is defined as the number of lost cells divided by the total number of transmitted
cells per ATM Connection.
CLR is specified per ServiceCategory at PVC provisioning. It is involved in ECR calculation done by
ATM CAC.
A small CLR value (for example 10-10) configured on a serviceCategory, results in reserving more
bandwidth for ATM Connections configured with this serviceCategory, in other word results in a larger
ECR.
If CLR=0, means that no bandwidth is reserved per ATM connection.
No CLR is configured for UBR serviceCategory, since no bandwidth is reserved for UBR
atmConnections.
Suggested CLR values:
CLR values:
rtVBR
nrtVBR
If CSD64 mapped on UP NDS
-10
-9
If CSD64 mapped on UP DS
-10
-7
Remark:
CSD 64 is mapped on UP NDS VCC in release2, whereas it is recommended to map it
to UP DS VCC in release3.
3.2.6.3 SCHEDULING
At ATM level, QOS is provided by means of Scheduling mechanism. Scheduling takes into account
ATM Connection ServiceCategory Parameter.
Scheduling applies to egress traffic.
This section describes Scheduling within Passport node.
Passport provides a two stage Scheduling:
Connection Scheduling and
Class Scheduling.
On Passport Node ServiceCategory values are mapped to an EmissionPriority parameter value, EP is a

Passport internal parameter.
At provisioning time:
QOS mapping table in configured:
1/ per port, An EP value is associated to each SC,

2/ a set of perVC queues is available on each EP,
ATM Connections are configured with SC and TD,
3/ a VCC is configured with a specific SC, (An EP is associated to this SC, a pool
of perVC queues is associated to this EP)
4/ a perVC queue within the EP pool of queues, is assigned to the VC,
5/ cells to be transmitted on this VCC, are buffered in the queue dedicated to this
VCC
When traffic is running:

ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 42/263
Connection Scheduler (WFQ or SFQ):

-
Within each EP pool of Queues, cells are extracted from each perVC queues,
and are stored in the associated linkClass Queue.
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)
Class Scheduler:
Each linkClass (5 for APC, and 8 for AQM) queue is pulled 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

Weight 3
APC Mapping Table,
From PQC
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-19 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.
3.2.6.4 DISCARD POLICY

Discard policy depends on type of card. A card is populated with one of the two TrafficManagement devices:
- APC+PQC,
- AQM+PQC
AQM Discard Policy description:

According to AtmConnection serviceCategory, and CLP field value within the received cell, Passport node
associates a DiscardPriority value to the received cell. According to buffer load and DiscardPriority value
associated to the received cell, cell is buffered or discarded.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 43/263
Less severe
congestion state
Most severe
congestion state
The AQM perVC buffers are implemented with 3 hardcoded thresholds, called CongestionControl levels,
involved in the discard policy. The CC level thresholds are identical for each serviceCategory:
Node discards
DP2 & DP3 cells
35%
CC2
CC3
No Cell discarded
CC1
75%
Node discards
DP3 cells
CC0
Node discards
DP1 & DP2 &
DP3 cells
90%
Figure 3-20 CongestionControl levels on AQM card.

The buffer CC thresholds work in conjunction with DiscardPriority value associated to a serviceCategory.
For each serviceCategory is associated two DiscardPriority values; one for cell with CLP field set to 0, and a
second for CLP field set to 1.
EmissionPriority
Most Urgent
EP0
EP1
EP2
CBR
(CLP1)
CBR
(CLP0)
EP3
rtVBR
(CLP1)
rtVBR
(CLP0)
EP4
nrtVBR
(CLP1)
nrtVBR
(CLP0)
EP5
EP6
EP7
UBR
(CLP0&1)
least Urgent
DP3
DP2
Least important
DP1
DP0
DiscardPriority
Most important
Figure 3-21 QOS mapping table example

On reception of a cell from the backplane, according to the QOS mapping table, the cell CLP value and the
serviceCategory of the AtmConnection, a discardPriority value is assigned to the cell.
E.g.: on reception of a cell with CLP=1 within an nrtVBR atmConnection, DiscardPriority 3 is associated to the
cell.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 44/263
Then a comparison is done between discardPriority value associated to the cell and buffer load, resulting in
storage or discard of the cell:
When buffer load is below CC2 threshold, all cells candidate to transmission are accepted in the buffer.
When buffer load has reached CC1 threshold, cells with discardPriority value 3, are discarded, whereas cells
with discardPriority value 2, 1 and 0 are stored in the buffer.
When buffer load has reached CC0 threshold, cells with discardPriority value 3, 2 and 1, are discarded,
whereas cells with discardPriority value 0 are stored in the buffer.
Queues:
MappingTable :
ATM Interface :
EmissionPriority
Tagged cell
NonTagged cell
Most Urgent
EP0 Queue
CBR
EP0 (CLP1)
CBR
(CLP0)
rtVBR
EP1 (CLP1)
rtVBR
(CLP0)
CLP1
Cell2
CLP0
Cell1
VCC CBR
CC0 CC1 CC2
CC3
EP0 queue is in CC2.

Cell1, DP1, is accepted.
Cell2, DP3, is rejected.
EP2
EP3
nrtVBR
EP4 (CLP1)
Tagged cell
nrtVBR
(CLP0)
EP4 Queue
CLP1
EP5
Cell2
NonTagged cell
CLP0
Cell1
VCC nrtVBR
EP6
CC0 CC1 CC2
CC3

Cell1, DP2, is accepted.
Cell2, DP3, is rejected.
UBR
EP7 (CLP0+1
)
Least Urgent
DP3
DiscardPriority
DP2
DP1
Least important
DP0
Most important
Figure 3-22 Discard Policy on AQM card, based on an example of QOS mapping table.
APC Discard Policy description:

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:
CBR
90%
CLP0 discard
CC0
CC1
38%
CLP1 discard
CC2
CC3
90%
rtVBR
nrtVBR
CLP0 discard
CC0
38%
CLP1 discard
CC1
CC2
CLP0 discard
CC0
CC1
75%
CLP1 Discard
CC2
CC3
32%
CC3
Figure 3-23 CongestionControl levels on APC card.

ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 45/263
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

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

Cell1, CLP0, is accepted.
Cell2, CLP1, is rejected.
EP7
Least Urgent
Figure 3-24 Discard Policy on APC card, based on an example of QOS mapping table.
3.2.6.5 CDV, CDVT

CDV (Cell Delay variation) is the jitter introduced in transmission of ATM cells due to buffering and
Scheduling.
Increasing buffer size, or selecting a lower priority serviceCategory, increases CDV, on the other hand
decreases cell Loss.
Decreasing buffer size, or selecting a higher priority serviceCategory, decreases CDV, on the other hand
increases cell Loss.
Selecting a SC for an ATM Connection, or when determining buffer size for a service category, is a
trade-off between CDV and cell Loss.
When no trafficShaping applies, and for the highest priority serviceCategory, CDV may be calculated
on the following way:
CDV = BufferSize/ EgressLinkThroughput
Some adaptations of this formula have to be done for lower priority SC.
Due to CDV introduced by ATM backbone, ATM cells arrive in the downstream node, before or after
the TAT (Theorical Arrival Time). ATM Cells arriving after TAT are conformed on the other hand
ATM Cells arriving before TAT are not conformed.
Non conformed cells are rejected by Policing, when activated.
CDVT (CellDelayVariationTolerance) is a tolerance taken into account by Policing, which applies to
cells arriving before TAT.
Setting CDVT 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 46/263
CDVT =< ( T
), e g : C D V T = ( T ):
TAT
P e r io d 1
P e r io d 2
TAT
P e r io d 3
TAT
P e r io d 4
TAT
t
T = 1 /P C R
CDVT
CDVT > ( T
CDVT
CDVT
), e g : C D V T = 2 *( T ):
TAT
P e r io d 1
CDVT
P e r io d 2
TAT
P e r io d 3
TAT
P e r io d 4
TAT
t
T = 1 /P C R
CDVT
CDVT
CDVT
Figure
3-25
CDVT
CDVT
representation
A consequence of setting CDVT is backToBack cell.
BackToBack cells are cells transmitted at linkRate. When setting CDVT, backToBack
cells are declared conformed.
Amount of cells transmitted backToBack declared conformed depends on CDVT
value:
N = Integer [1 + CDVT / (T )],
with:
N: amount of cells transmitted backToBack,
T = 1/PCR,
: cell transmission time duration, depends on kind of link.
3.2.7
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 47/263
3.2.7.1 CASE OF UMTS/UMTS D&I:

Fractional E1:
One E1 and only one is shared between two NodeBs.
Dropped NodeB
Dropping NodeB
E1 n1
E1 n2
NodeB
N2
NodeB
N1
TDM
backbone
UMTS IBTS
1 Fract E1
14 TS
RNCANode
TDM
backbone
UMTS IBTS
1 Fract E1
12 TS
ATM over unchannelise

STM-1
d
RNCINode
e/w MSA 32
with STM-1
Example:
MSA32 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:
On droppedNode, PCM1 port is configured

ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 48/263
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 :
RNC-ANode
32 Timeslots
ATM1
Not used
MSA32 card
Node-B 1
Node-B 2
CCM
CCM
ATM1
32 Timeslots
Not used
E1
ATM1
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-26 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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 49/263
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:
On droppedNode, PCM1 port is configured

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.2.7.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
E1 n2
RNC-ANode
e/w MSA 32
with STM-1
E1 n6
TDM
backbone
GSM
BTS
TDM backbone
shared between
UMTS & GSM
E1 n4
E1 n5
UMTS E1 n3
NodeB 1 Fract E1
15 TS
BSC
GSM
BTS
GSM BTS
2 Fract E1
10 + 8 TS
E1 n7
One E1 link is shared between one GSM BTS and one NodeB:
Example:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 50/263
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:
- 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.
The extraction of the GSM TS will be performed by ALU Networks MSS7K. The
limitations are the same as for UMTS-UMTS D&I except that no hairpin is required on
MSA32 card.
Connectivities:
On droppedNode, PCM1 port is configured,

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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 51/263
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:
On droppedNode, PCM1 port is configured,

Remarks:
3.2.8
GSM BTS must be the dropping node, in order to not perturb GSM traffic,
Maximum number of available T1 TS is 24.
The MSS7k is not involved in T1 D&I, since doesnt provide T1 access.
Fractional T1 is not available on 4 ports DS3ch IMA nor on 4 port DS3ch CES.
ADDRESSING
Since UNI signaling or PNNI is configured in network, ATM addresses are required. ATM addresses
are called AESA (ATM End System Address). AESA is structured according to NSAP format (Network
Service Access Point)
To establish sPVCs or SVCs across the network, ATM source and destination points need to be
uniquely identified with ATM addresses.
NodeB does not support neither UNI signaling nor PNNI.
3.2.9
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.2.9.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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 52/263
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.2.9.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
3.2.9.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 are 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-27 sPVC example
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 53/263
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.2.9.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.
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 54/263
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-28 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).
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-29PNNI 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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 55/263
3.2.9.5 PNNI ON IUB INTERFACE
3.2.9.5.1 RNC-PCM:
The PNNI is used to participate to the Iub interface reliability between POC and RNC (RNC-PCM
configuration). More precisely, the Pnni Rerouting mechanism provides a protection against POC
OC3/Stm1 ClearChannel FP failure eg: MSA32 or 2pOC3 FP.
Rule: IubTEG_PNNI_01
PNNI is recommended for RNC-PCM configuration, on RNC-IN/MSS7k interface.
When a MSA32 card fails, both the APS Working and Protected lines from this card become unavailable,
the PNNI determines the paths terminating on the other FP and re establishes the impacted
atmConnections under condition there is enough available bandwidth on these paths.
RNC-PCM
PNNI signalling
UNI
NodeB
RNC-AN
RNC-IN
E1
STM 1
On the MSS7k / RNC interface, 3 stm1 links are configured for capacity and reliability reasons.
In normal condition, when the 3 stm1 are active, the Iub pnni atmConnections are distributed over the 3
stm1 links.
Even if 3 stm1 links are configured on the Rnc / MSS7k interface, a bandwidth equivalent to 2 stm1 is
reserved for the Iub atmConnections through the trafficDescriptors.
Then in case of failure of one stm1 due to MSA32 FP failure, the two still active stm1, are able to support
all the Iub atmConnections.
The activation of Pnni on the RNC implies the configuration of some pnni sPvc Hairpins on the RNC
16pOC3/STM1 FP card.
The amount of sPvc hairpins is determined based on the bandwidth required on the RNC Iub interface.
Since Iub VCC TrafficManagement parameter had been set in such a way two stm1 bandwidth is enough,
2 sPvc hairpins are set.
The Pnni sPvc source node may be either the RNC-IN, the MSS7k or an atmSwitch.
Rule: IubTEG_PNNI_02
It is preferred to initiate the pnni sPvc in the MSS7k or in an atmSwitch instead of in the RNCIN.
The reason for pnni sPvc source in the atmSwitch is to better managed the case of PCM failure. Indeed
if the pnni sPvc source is configured in the atmSwitch doing the interworking between Pcm interfaces
and sdh interfaces, the pnni atmConnection releasing and rerouting invocations can be synchronized
with PCM failure/restoration events.
3.2.10 IMA
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 56/263
IMA stands for Inverse Multiplexing Atm.

The IMA sets together multiple E1/T1 physical links into a single atm high speed link. This link is
called an IMA linkGroup.
The IMA is configured between two neighbor atm nodes; it is not possible to configured IMA through
an atm network.
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.2.10.5.
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 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.2.10.1
SYNCHRONISATION
Two ways of managing clock are suggested:

- CTC (CommonTransmitClock): the same transmitClock applies for all links within
the IMA linkGroup.
-
3.2.10.2
ITC (IndependentTransmitClock): transmitClock is independently derived from one

or several links within an IMA linkGroup.
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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 57/263
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).
-
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
ATM node
ATM node
IMA Frame 1
127
Link 1
IMA Frames sent

simultaneously
on each link
IMA
IMA
Figure 3-30 IMA Frame
3.2.10.3
IMA LG BANDWIDTH
The process of IMA framing and control slightly reduces the capacity of individual physical
links within an IMA link group.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 58/263
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.
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-31 IMA LG bandwidth

For IMA LG Bandwidth Reduction/Restoration mechanisms, see the RNC/IMA and the NodeB/IMA.
3.2.10.4
IMA LG BANDWIDTH REDUCTION MECHANISM
The RNC IMA LinkGroup bandwidth Reduction mechanism is described in section: Erreur ! Source
du renvoi introuvable..
The NodeB IMA LinkGroup bandwidth Reduction mechanism is described in section: 3.8.7.2.
The IMA LinkGroup bandwidth Reduction mechanism is activated as an option in the NodeB, the RNC
or the Passport.
On one IMA interface, the IMA LinkGroup bandwidth Reduction mechanism should not be activated in
both nodes extremity of the IMA interface; the mechanism should be activated in one node at the
extremity of the IMA interface.
The node where is activated the IMA LinkGroup bandwidth Reduction mechanism, since aware about
PCM defect (s), releases one or several Vcc(s) and notifies the adjacent node thanks to atm oam signals.
A/ In case of interworking with an otherVendor atmSwitch, the operator decides to activate the IMA LG
bandwidth Reduction mechanism in:
- The ALU node (the NodeB, the Passport or the RNC) or
- The otherVendor atmSwitch.
If the IMA bandwidth Reduction mechanism is activated in the otherVendor atmSwitch and not in the
ALU NodeB, the operator should take care that the otherVendor bandwidth Reduction mechanism
behavior is compliant with the expectations of the RNC aal2 congestionManagement (3.6.7) and
aal2LinkCac. The otherVendor node must be able to notify the RNC thanks to endToEnd atm oam
signals, about the vcc which have been released, in such a way the RNC is aware about the available
bandwidth on Iub interface.
In fact, the ALU RNC expects that the otherVendor bandwidth Reduction mechanism has same
behavior as the ALU NodeB bandwidth Reduction mechanism.
Expected bandwidth Reduction mechanism behavior from the otherVendor atmSwitch:
Case of 8 PCM within the IMA LG, one PCM defect, then one Up Ds vcc is released,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 59/263
Case of less than 8 PCM within the IMA LG, one couple (Up Ds vcc, Up Nds Vcc) is released
for each PCM defect,
Notification to the atm endPoint nodes about the Vcc release.
If the otherVendor behaves differently than the ALU nodeB, then a specific interworking study will be
required.
Rule: IubTEG_IMA_04
In case of OtherVendor atmSwitch on an Iub IMA interface, the IMA defense mechanism should
be activated in the NodeB or in the otherVendor atmSwitch under condition it provides same IMA
defense behavior as the NodeB
This rule is dictated by the RNC aal2 Congestion Management mechanism.
B/ In case of an IMA interface delimited by a ALU NodeB and a Passport atmSwitch or ALU RNC:
Argument 1:
In the context of IMA LG bandwidthReduction, the RNC aal2 Congestion Management (
3.6.7) expects that:
Only one Up Ds Vcc is released when one PCM defect occurs on an IMA LG
composed of 8 PCM and configured with 8 up ds vcc and 7 up nds Vcc,
At each PCM failure within an IMA LG, one couple (up ds Vcc, up nds Vcc) is
released.
The 4 HP values assigned to the aal2 Vcc within the MSS7k (see Erreur ! Source du renvoi
introuvable.), don't allow to have such a behavior in case of more than 4 PCM within an IMA
LG.
Argument 2:
In the context of IMA LG bandwidthRestoration, the RNC or the Passport restores the vcc
according to the perVc reserved bandwidth (vcc ECR) and the IMA LG available bandwidth.
When restoring the UP aal2 vcc, the RNC or Passport doesnt take care about the aal2 qos, in
other words doesnt guarantee the restoration of as many UP ds aal2 vcc as UP nds vcc.
Beside, in the context of IMA LG bandwidthRestoration, the nodeB restores a couple of (UP
ds, UP nds) vcc each time a PCM is restored.
The NodeB IMA LG bandwidthRestoration algorithm works as expected by the RNC aal2
CongestionManagement mechanism.
Rule: IubTEG_IMA_05
On an IMA interface delimited by the ALU NodeB and either a Passport atmSwitch or the
ALU RNC, it is recommended to activate the IMA LG bandwidth Reduction mechanism
in the NodeB whatever amount of PCM in the IMA LG.
Remark:
When the IMA LinkGroup bandwidth Reduction mechanism is activated on the nodeB, when
bandwidth reduction occurs, the nodeB releases 1 or several Vcc, and returns an endToEnd
oam RDI signal for each released Vcc. On reception of the RDI in the RNC-IN, the Vcc
rdiState is changed to bad, and the aal2/x path/y (linked to the vcc) localBlockingStatus is
changed from unblocked to blocked.
3.2.10.5
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 60/263
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]).
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.2.11 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 (see Transmission/OAM section), and at
ATM level.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 61/263
The atm OAM Information is bidirectional; it is carried once the ATM connection is established.
The atm OAM PDU are directly encapsulated within and ATM cell payload, without AAL (ATM
AdaptationLayer).
3.2.11.1
ATM NODE, OAM TYPE
This section is dedicated to Passport node.

Within an ATM network, are considered at OAM point of view, different types of node:
- VPC/VCC endPoint node: ATM node where ATM-User SDUs 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.
OAM Type of node 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.
- 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.2.11.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]).
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 62/263
NodeB
NodeB OAM Boundary
VCC
RNC
RNC
ATM
ATM
switch
switch
VCC / VPC
ATM
ATM
switch
switch
Segment OAM flow

EndToEnd OAM flow
See Passport MML commands:

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:
- 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, 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,
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-32 ATM OAM Cell Format

The table below indicates the OAM Cell Field values used within UMTS networks:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 63/263
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:
-
3.2.11.3
LoopBack indication: The source loopBack point fills this field with value: 0000 0001.
The destination loopBack point returns the value: 0000 0000.
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.
ATM OAM SIGNALS
AIS:
Target of AIS (AlarmIndicationSignal) is to notify downstream endPoint node with 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 (PVC or PVP).
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 64/263
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-OAM
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:
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:
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.
RDI is an upstream signal, whereas AIS is a downstream signal.
F4/F5 EndToEnd RDI is generated by a VP/VC EndPoint node, whereas 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,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 65/263
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.
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-33 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-34 F4/F5 RDI generation on Reception of MS-AIS
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 66/263
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-35 RDI generation on LOS Condition

LoopBack:
This feature consists in inserting a pattern in an ATM Connection, 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 continuity of an AtmConnection.
Rule: ATM-OAM_1
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. 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
07.02 / EN
Standard
29/06/2009
Page 67/263
- ALU Product 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.
Rule: ATM-OAM_2
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.
Within Passport based nodes, following MML are involved in LoopBack:
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.2.11.4
NODES CHARACTERISTICS & COMPLIANCY:
RNC: 16pOC3/STM1 FP:

Partly compliant withI.610:
- Supported:
Fault management:
- Alarm Indication Signal (AIS), Remote Defect Indication (RDI),
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 68/263
- LoopBack.
Not Supported:
- PerformanceManagement,
- FaultManagement: ContinuityCheck.
NodeB:
On the reception of F4/F5 AIS the NodeB takes appropriate actions: alarm generation, send RDI.
The NodeB does not initiate the AIS signal since nodeB is an atm endPoint node not an atmSwitch.
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.
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-IN
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.3
AAL2
3.3.1
ADDRESSING
Aal2 address is called A2EA [R41].
AAL2 addresses are not used on Iub, since ALCAP is not implemented.
3.3.2
ALCAP
The RNC Iub interface and the NodeB (iBTS are enhanced with the Alcap protocol.
Beside the oneNodeB still supports the Alcap.
The implemented Alcap is conformed to Q2630-2, with the exception:
- Q2630-2 aal2 connection modification procedure not supported (since achieved at RNL layer).
- Alternative routing not supported.
The Alcap uses the services of SAAL-UNI, one SSCOP connection is dedicated to the Iub Alcap.
Beside one SSCOP connection is established for the Nbap-c and one SSCOP connection is established
per Nbap-d.
One Alcap vcc is assigned to the Alcap SSCOP connection.
On the Iub interface, the Alcap is used to establish the aal2 bearer:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 69/263
NodeB
NodeB
RNC
RNC
NBAP/RadioLink Setup Request
NBAP/RadioLink Setup Response
TLA = nodeB A2EA + Binding Id1,
TLA = nodeB A2EA + Binding Id2 +
RNC QAAL2 Translation table:

A2EA => aal2If => aal2Paths.
The RNC selects within the aal2if
a path for the requested qos.
Q2630.2 ERQ
A2EA, SUGR = Binding Id1, PathId, CID, PathType, LC
Q2630.2 ECF
synchronisation
Q2630.2 ERQ
A2EA, SUGR = Binding Id2, PathId, CID, PathType, LC
Q2630.2 ECF
synchronisation
TEG
Figure 3-36, Iub Alcap call flow
The RNC may request several aal2 connection establishments when sending the Nbap/RL Setup Request
message to the nodeB.
Within the Alcap/ERQ/LinkCharacteristics parameter the RNC specifies:
- Maximum CPS-SDU bit rate
- Average CPS-SDU bit rate
- Maximum CPS-SDU size
- Average CPS-SDU size
The nodeB does not take into consideration these values
Within the Alcap/ERQ/pathType parameter the RNC inserts the requested aal2 qos to inform the
downstream aal2 node.
In the case of calls initiated on the Iur interface, the LinkCharacteristics values inserted in the alcap ERQ
sent on the Iub interface is determined by the driftRNC whereas the LinkCharacteristics values inserted
in the alcap ERQ sent on the Iur interface is determined by the servingRNC:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 70/263
NodeB
NodeB
DRNC
DRNC
SRNC
SRNC
RNSAP/RadioLink Setup Request
NBAP/RadioLink Setup Request

NBAP/RadioLink Setup Response
TLA = nodeB A2EA for one aal2 connection + Binding Id1,
TLA = nodeB A2EA for one aal2 connection + Binding Id2 +
Q2630.2 ERQ
PathType, LC determined by the DRNC
Q2630.2 ECF
RNSAP/RadioLink Setup Response
Q2630.2 ERQ
PathType, LC determined by SRNC
Q2630.2 ECF
TEG
Figure 3-37, Iub & Iur Alcap call flow
3.4
IP
Since only IP services are only used by UMTS OAM plane, most of IP items are described in the UMTS
OAM plane subsection.
3.4.1
INVERSEARP
Reference: ARP [R68 & 66]
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 71/263
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-38 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.
- 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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 72/263
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
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.4.2
SITELAN
3.5
IUB TOPOLOGY
Different topologies apply to the Iub interface according to:
- The RNC type: ATM RNC or Hybrid RNC,
- Backbone transport node: atmSwitch, sdh nodes, IP Router, ethernetSwitch,
- Backbone transmission interface: cupper, optical, Wave, Satellite, DSL
Related to the ATM RNC, the following options are considered for the choice of topology:
- NodeB transmission option:
- E1/T1 or Fractional E1/T1,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 73/263
If Fractional Rate E1/T1, do we have GSM BTS in the link as well (usage of
CES for cross connecting),
- MultiPCM or IMA,
Atm backbone:
- ThirdParty atm backbone, or backbone owns by the umts operator,
- Backbone dedicated to the UMTS or shared with others Telecom traffic
sources,
- Is the policing activated,
- Vc or vp switching,
- Atm signaling or permanent connections,
Sdh backbone:
- Either clearChannel or channelized access,
DSL technology,
Related to the Hybrid RNC, the following options are considered for the choice of topology:
Same options as for the atm RNC backbone and option related to the IP / Ethernet interfaces:
- IP backbone
- Ethernet backbone
- LAN / VLAN,
- DSL technology,
-
Below are presented some examples of network topologies on the Iub interface:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 74/263
3.5.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-39 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.5.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
07.02 / EN
Standard
29/06/2009
Page 75/263
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-40 Atm ring topology on Iub
3.5.3
SDH RING
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 76/263
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-41 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.5.4
HYBRID UTRAN
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
07.02 / EN
Standard
29/06/2009
Page 77/263
R99 traffic,
Signaling,
Oam
Hspa stream.
Hspa I/B (opt)
RNC
RNC
CS
CS core
core
RNC
RNC
ATM
ATM
Backbone
Backbone
OC3
OC3
ATM
ATM
Backbone
Backbone
OC3
OC3
OC3
OC3
SGSN
SGSN
OC3
OC3
NodeB
NodeB
GE
GE GE
GE
SGSN
SGSN
IP
IPBackHaul
BackHaul
ATM
ATM
Backbone
Backbone
Hspa I/B
SGSN
SGSN
SGw
SGw
TEG
Figure 3-42 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
On the Ethernet backhaul, the different UMTS flows may be isolated within VLAN:
GE
GE
Router
Eth
Eth
Bridge
Bridge
Eth
Eth
Bridge
Bridge
NodeB
NodeB
NodeB
NodeB
NodeB
NodeB
SGSN
SGSN
NodeB
NodeB
NodeB
NodeB
Vlan z
GE
GE
Vlan u
Vlan v
Vlan x
RNC
RNC
Vlan x
Vlan y
Vlan z
Vlan y
Vlan u
Vlan v
NodeB
NodeB
Ethernet Switching with VLAN and IP routing:
TEG
Figure 3-43, VLAN on Ethernet backhaul

The IP router is a point of termination for the VLAN. The IP router allows communication between hosts
configured on different VLAN.
3.5.5
ETHERNET TOPOLOGY
The Ethernet backhaul may present on the Iub interface, nevertheless at least one IP router must be
present. Therefore an ethernet backhaul may be inserted between the RNC and the IP backbone and
between the IP backbone and the NodeB.
Different Ethernet topologies may apply in such a way to guarantee the robustness against link, port node
failures:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 78/263
Eth
Bridge
RNC
GigE
6
Router
RNC
GigE
Eth
Bridge
GigE
Eth
Bridge
GigE
Eth
Bridge
GigE
RNC
Eth
Bridge
GigE
Router
GigE
RNC
Eth
Bridge
GigE
Router
GigE
RNC
Eth
Bridge
GigE
Router
GigE
RNC
GigE
Eth
Bridge
Router
Eth
Bridge
Router
Eth
Bridge
Router
Router
Router
Figure 3-44, ethernet topologies

A solution with one bridge is less desirable since one single point of failure.
3.6
RNC ATM
This section covers the ATM RNC. A new section is dedicated to the Hybrid RNC.
The ATM RNC is populated with the 16pOC3/Stm1 FP and provides atm accesses on all the UTRAN
interfaces.
The hybrid RNC is populated with both the 16pOC3/Stm1 FP and the 4pGE FP and provides both atm
and IP accesses on the Iub interfaces, atm accesses on the IuCS and Iur interfaces, and both ATM and IP
on the IuPS interface.
Rule: IubTEG_hybridRNC
On the Iub, the IP interface when present is dedicated to Hsdpa and Hsupa interactive/Background
whereas the atm is dedicated to R99, signaling, Hspa streaming, oam and as an option Hspa
interactive/Background.
3.6.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.6.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,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 79/263
- SingleRate trafficShaping (also called Linear Shaping),

- Traffic shaping only on Emission Priorities 0.
3.6.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:
- 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.
3.6.2
FP
3.6.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.6.2.1.1 TRANSMISSION CHARACTERISTICS:
one FP manages 16 STM1/OC3 ports,
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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 80/263
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.6.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.
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.6.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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 81/263
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:
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-45 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,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 82/263

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,
3.6.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.6.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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 83/263
Vcc range: [0, , 16384]

Associated Rule:
maxVcc < [nZVcc + (nVpis * nVcc) 1 ]

-
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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 84/263

The VCI range delimitated by minVciVpiZero and maxVciVpiZero must be a subset
of connMap nZVcc:
maxVciVpiZero =< connMap nZVcc
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,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 85/263
maxAutoSelectedVpi] is consumed by dynamic established VP Connections: SVP, PNNI

sPVP.
3.6.2.1.3 QOS:
-
FP Scheduler:
The 16pOC3/STM1 FP supports 5 EP: EP0, EP2, EP3, EP4 and EP7.
The 16pOC3/STM1 FP supports 4 classQueues .
The MBG is configured against the EP2, EP3, EP4 and EP7; no MBG configured against the EP0.
The 16pOC3/STM1 FP first allocates to each EP its minimum bandwidth guaranteed and then
allocates the remaining bandwidth among the different EP according to a strict priority.
The MBG has precedence over the EP0 and EP1.
This type of scheduling is referred to as Priority Guaranteed Queuing (PGQ).
Qos mapping table:

This qos mapping should apply to all the IP over Atm utran interfaces (Iub oam and IuPS UP).
It is suggested to set the DSD = multiService.
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
CS7, CS6, CS5, CS1, EF, AF1y, DE
wirelessUmts
CS7, CS6, CS1, EF, AF3y, AF2y, DE
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.
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 3 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)
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 86/263
Table 4 discard policy for the 16pOC3 PQC FP
3.6.2.2 16POC3/STM1 MS3 FP

The 16pOC3/Stm1 MS3 FP (aka: ATM/POS) is supported since Passport release PCR5-2 on MSS15k, PP20K
and RNC1500.
Prerequisite:
Before replacing the 16pOC3/Stm1 ATM 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 .
The FP supports 16 ATM over SONET/SDH links or 16 POS links.
The 16pOC3/Stm1 ATM/POS FP is also known as 16pOC3/Stm1 MS3 FP, while MS3 is the new architecture
name for the FP.
The 16pOC3 MS3FP card is based on GQM TrafficManagement ASIC, its behaviour in terms of qos and
trafficmanagement depends on the GQM.

-
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.6.2.2.2 ATM CHARACTERISTICS:

-
atmInterface type: UNI, NNI,

Vpi range: [0, 256] 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,
The FP resources:
Rule: IubTEG_16pOC3/Stm1 atm/Pos_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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 87/263
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.6.2.2.2.1
QOS
Qos Information mapping:

- serviceCategories:
o Supported: Cbr, rtVbr, nrtVbr, Ubr, Ubr with Mdcr,
o Not supported: ABR.
- EP (EmissionPriority) range: [0, 7], Up to 4 EP can be simultaneously configured.
- Up to 4 classQueues
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
QOS/Scheduling:
The QOS Scheduling is provided by the GQM ASIC:
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:
- The shaping rate is either the PCR or both PCR and SCR,
ClassScheduler:
- Up to 4 classQueues,
- 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 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.
The priority of the EP has no impact on the amount of bandwidth it receives.
As a consequence the MBG has a major impact on the QOS: cell loss, delay and jitter.
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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 88/263
The value Priority.
The mix of priority and MBG provisioning is not supported on the 16pOC3/Stm1 Atm/Pos
FP. What is supported is either specifying the priority option for all EPs, or the explicit
configuration of the MBG value for all used EPs used on one atmInterface.

On one16pOC3/Stm1Atm/Pos FP atm interface:
- if a MBG value is configured against an EP, then a MBG value must be configured against
each non absolute EP (EP2 to EP7),
- Else, the minimumBandwidthGuarantee is set with Priority value for each non absolute
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:
If each non absolute 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]:
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.
Eg, case of 4 non absolute EP:
GuaranteedBw for EP3 = [linkRate (EP0+EP1) traffic] * MBGEP3 / (MBGEP2
+ MBGEP4 + MBGEP7),
With EP0 and EP1 traffic = 0 for this example.
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:
On APC based card, the guaranteed bandwidth = MBG * link bw, in other word the guaranteed
bandwidth does not take into consideration the AbsolutePriorities: EP0 and EP1.
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 non absolute 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,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 89/263
- 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:
# Used
non absolute
EP
1st EP
Weight assigned to the non absolute EP
1
2
100
99
90
77
18
2d EP
3d EP
4th EP
100
100
100
100
QOS/Discard mechanism:
Same mechanism as for the AQM based FP.
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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 90/263
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%
Remark:
On the AQM based card, the EPD thresholds are configured through the epdOffset attribute,
which is not supported by the GQM.
CLP:
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 DP of
IP packets can have a value of low (1), medium (2) or high (3). In our case the IP packets
originate from the PMC-RAB, therefore the DP is set there.
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 91/263
3.6.2.2.2.2
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.6.2.2.2.3
AAL5:
EPD, PPD, LPD and W-RED supported,

(Only EPD supported in the 16pOC3/Stm1 APC based FP)
3.6.2.2.2.4
OAM:
According to I610,
PM and CC not supported,
3.6.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)
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 92/263
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.6.2.2.4 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.6.2.2.5 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.6.2.3 MSA32 FP
MSA32E1 FP is a PP7k card. It is inserted in the Mss7k to provide E1/DS1 connectivity on Iub interface, and as
an option STM1 connectivity on RNC / Mss7k interface.
3.6.2.3.1 HARDWARE CHARACTERISTICS:

The original MSA32 is using a Double Slots (reason for naming DS MSA32 FP).
In the most recent UMTS Releases (see 4.1.1.2) a single Slot MSA32 is available.
Lets called DS MSA32 (DoubleSlot) the original MSA32, and SS MSA32 (SingleSlot) the most recent FP.
The MSA32 supports 32 E1/DS1 and as an option 2 Stm1/Oc3.
The MSA32 is composed of two processors for handling the E1/DS1 links, called Maker.
The MSA32 FP 32 ports are split in two sets of 16 ports, called makers:
- One Maker processor is in charge of ports 0 to 15,
- The second Maker processor is in charge of ports 16 to 31.
One Stm1/oc3 is active. The second Stm1/oc3 may be used as the protected line if the APS is configured, else
not used.
The MSA32E1/Stm1 is composed of two AQM equipments:
- The Aqm/0 is involved in E1/DS1 traffic management whereas
- The Aqm/1 is involved in Stm1/Oc3 traffic management.
A MSS7k has 16 slots, typically with 2 reserved for CP.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 93/263
As an example, the MSS7k may be populated with:

- 3 DS MSA32 E1/Stm1 FP which provide STM1 connectivity on IN/AN interface, and E1
connectivity on nodeB side, and
- Either, up to 4 DS MSA32 FP or
- Up to 8 SS MSA32 FP.
All engineering/capacity figures for the SS MSA32 and DS MSA32 FP are the same.

DS MSA32 FP (doubleSlot):
SingleMode is used. (Since 16 ports STM-1 FP supports SingleMode only).
2 OC3/Stm1 port, one is the APS working line whereas the second is the APS protection line.
If APS is not configured, only one STM1 links may be used for traffic.
SS MSA32 FP:
The SS MSA32 FP doesnt provide STM1 access.
APS:
1+1 APS line protection (intra-card, in case of line/port failure), one optical port is active, the
other can only be run as APS backup
Note: inter-card APS equipment protection (for optical switchover on card failure) is not
supported on any MSS7k FPs (with exception of the 2pOC3 ClearChannel FP), only PP15k &
PP20k.
In case of OC3/STM1 line or port failure, traffic is switched to the backup within 50 ms
The MSA32/Stm1 FP is compliant with [R32].
The APS is configured through aps component in PP7k.

-
The MSA32 is AQM based,

VPT capabilities.
Supports UDT and SDT (partialCellFill as an option) AAL1 CES service.
DS MSA32 FP and SS MSA32 FP:

- Up to 30 E1 ports may be used for ATM purpose: 16 ports on the first Maker and 14 ports on the
second Maker. The ports from port 0 to 29 can be used for ATM (without IMA) whereas the
port 30 and 31 can not be used.
- Up to 32 E1 ports for AAL1 CES, (E1 port is configured as aal1ces port in D&I configuration),
3.6.2.3.3.1
ATM TRAFFICMANAGEMENT CHARACTERISTICS:
The MSA32 FP ATM TrafficManagement characteristics are those from the AQM.
3.6.2.3.3.2
-
IMA CHARACTERISTICS:
Unchannelized E1 ports only may participate in IMA linkGroup.
Fractional rate E1s are not allowed.
ATM UNI, PNNI are all supported over IMA. In basic configuration ATM UNI is configured on
IMA AtmIf,
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 LG per Maker, or
- 13 E1 ports in up to 13 IMA LG per Maker.
- 15 DS1 ports in up to 7 IMA LG per Maker, or
- 13 DS1 ports in up to 13 IMA LG per Maker.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 94/263
Ports #30-31 can be used for IMA if part of an IMA LG with ports in the range 16-29.
From 1 to 8 ports per IMA LG.
All ports in an IMA link group must be in same port-block (Maker).
Do not mix services on same port-block as IMA:
When IMA is activated on a port block, other services are not supported on that port block:
Mixing of IMA with e.g. single port ATM or AAL1 CES is not recommended on the same port
block (port 0-15, 16-31).
In terms of link selection criteria, the MSA32 FP supports only the delay metric (leastDelay) and
not the bandwidth metric (maximumBandwidth).
Compliancy:
- IMA1.0 vs. IMA1.1: Technically MSA32 supports both. An MSA32 IMA port first comes
up in IMA1.1 mode then negotiates the remote end; if it is IMA1.0, then MSA32 changes to
IMA1.0 to match. Otherwise it stays in IMA1.1 mode and runs successfully. MSA32
display commands always show the port running in IMA1.0 mode.
IMA Clock Modes:
- The ports within an IMA group may use the Module, Line or a combination of the two for
the transmit clocking configuration. The clocking options in the IMA feature are:
- Common Transmit Clock mode (CTC) and
- Independent Transmit Clock mode (ITC).
- If the shelf clock is available the default for clocking source is Module.
Rule: IubTEG_MSA32 FP_1

As CTC is used for an IMA LG, all transmit clocks within the IMA LG must derived from a
common source (Module).
3.6.2.3.4 SPARING PANEL:

The MSS7K (therefore RNC AN) sparing system supports 6+1 sparing scheme for SS and DS MSA32 FPs.
This mechanism allows switchover of E1/DS1 lines and related functionality from failed FP to a Sparing FP.
InterCard STM1/OC3 line sparing is not supported.
Switchover back from the spare FP to the Main card requires manual intervention.
There are two modes of FP sparing defined by lp/n oneForNSparingBehavior attribute:
- delayedSwitchOver (delayedSO):
The switchover to the spare card is delayed (sparingTimer t1). This option avoids the
switchover to the spare card, in case of main card short failure.
Remark: After switchover to the spare card, main cards are no more protected.
- immediateSwitchOver (immediateSO):
A FP failure event is the trigger of an immediate switchover to the spare card.
Rule: IubTEG_RNC-MSA32 FP_2
To minimize UTRAN outage time is proposed to use immediateSwitchOver approach.
For fully loaded UTRAN Mss7k, it is expected that number of ATM Vcc should be in range of 200 - 300 per FP,
therefore recovery time should not exceed 2 min. The establishment of SPVCs should not increase this recovery
time.
Within the Mss7k, one FP is designated as spare FP, whereas others are designated as Main FP, by means of
configuration.
Rule: IubTEG_RNC-MSA32 FP_3
The MSA FP configured for sparing function, must be one without STM1 connectivity to RNC.
The connectivity of the Mss7k is reduced since one MSA FP is reserved for acting as spare FP. The Mss7k is
then populated with up to 6 effective MSA32 FP.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 95/263
Working Line
16pOC3/Stm1
16pOC3/Stm1 FP
FP
RNC
Protected Line
16pOC3/Stm1
16pOC3/Stm1 FP
FP
STM1
1 spare FP:
66
77
88
99 10
10 11
11 12
12 13
13 14
14 15
15
MSA32 E1/Stm1
E1/Stm1 FP
FP
MSA32
SPARING
SPARING
55
MSA32 E1/Stm1
E1/Stm1 FP
FP
MSA32
44
MSA32 E1/Stm1
E1/Stm1 FP
FP
MSA32
33
MSA32 E1/Stm1
E1/Stm1 FP
FP
MSA32
6 main FP:
22
MSA32 E1/Stm1
E1/Stm1 FP
FP
MSA32
11
MSA32 E1/Stm1
E1/Stm1 FP
FP
MSA32
00
MSA32 E1/Stm1
E1/Stm1 FP
FP
MSA32
MSS7K
7 * 32 E1
SparingPanel
SparingPanel
6 * 32 E1
Figure 3-46 MSA32 Sparing Panel
3.6.2.5 8PE1/T1 ATM FP

The 8pE1/T1 ATM FP is a PP7k card, and may be inserted in the NAM.
It is based on CQC Asic.
Characteristics:
- Maximum amount of IMA LinkGroups: 8
- Maximum amount of links per IMA LinkGroups: 8
- Mix of independent and IMA Groups: allowed
- Supports proprietary ALU IMA and ATM standard IMA v1.0
3.6.2.6 2 P STM1 E CH FP
(Reference [R254, R255 & R40])
The 2pStm1 e ch FP is a PP7k card.
This FP may be introduced in the Mss7k when NodeBs and RNC traffic transits through a SDH backbone.
It provides 2 STM1 ports electrical and channelized.
According to ITU, 63 E1 links are included within a STM1 Channelized. Each E1 link is encapsulated within a
VC12; 63 VC12s are encapsulated within a VC4. Within a VC4, each VC12 is identified by a triplet value
called: (k, l, m).
Therefore the 2pSTM1e Ch FP supports up to 126 E1 links.
The 2pSTM1e Ch FP doesnt handle IP.
3.6.2.6.1 HARDWARE CHARACTERISTICS:

The 2pSTM1e Ch FP is a dual slot FP.
If sparing panel is configured 4 slots are reserved for 2 STM1 links.
The 2pSTM1e Ch FP is composed of 4 AQM components.
Taking into consideration that the RNC / Mss7k is configured in a way to carry a traffic volume equivalent to up
to 2 STM1 links, on other hand in order to provide enough equivalent E1 connectivity on nodeB side, assume
that 3 or 4 STM1 e Channelized links may be required; therefore two 2pSTM1e Ch FPs are required on Mss7k.
Moreover to secure Iub traffic, the SparingPanel may be configured, which provides a redundancy scheme (1:1);
therefore Mss7k may be populated with four 2pSTM1e Ch FPs.
A RNC-AN, PP7k based, has 16 slots, typically with 2 reserved for CP.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 96/263
If RNC-AN is populated with four 2pSTM1e Ch FPs, then 8 slots are reserved.
Six slots remain available for RNC / Mss7k interface. These six slots may be populated with three
MSA32E1/STM1 FPs reserving 6 slots, indeed providing 3 STM1 links, or with three 2pOC3 FP reserving 3
slots.
Rule: IubTEG_RNC-2pStm1Ch_1
Eight Mss7k slots are reserved for the 2pSTM1e Ch FPs, in such a way to be able to provide Iub up to
4 STM1 Channelized links secured by sparingPanel.
When configuring a VC12, on one SDH link, a (k, l, m) triplet value is assigned to the VC12. This triplet value
identifies the VC12 within the VC4.
- k is in the range [1, 2, 3],
- l is in the range [1, , 7] and
- m is in the range [1, 2, 3].
From the VC12 assigned triplet value, the 2pStm1e Ch FP, computes the AQM internal port number using the
following formula:
AQM port number for an isolated E1:
AQM InternalPort number = (k-1) * 21+ (l-1) + (m-1) * 7
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 97/263
k
1
1
1
1
1
1
1
l
1
2
3
4
5
6
7
m
1
1
1
1
1
1
1
AQM InternalPort #
0
1
2
3
4
5
6
# SDH
1
1
1
1
1
1
1
k
1
1
1
1
1
1
1
l
1
2
3
4
5
6
7
m
1
1
1
1
1
1
1
AQM InternalPort #
0
1
2
3
4
5
6
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
2
3
4
5
6
7
2
2
2
2
2
2
2
7
8
9
10
11
12
13
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
2
3
4
5
6
7
2
2
2
2
2
2
2
7
8
9
10
11
12
13
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
2
3
4
5
6
7
3
3
3
3
3
3
3
14
15
16
17
18
19
20
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
2
3
4
5
6
7
3
3
3
3
3
3
3
14
15
16
17
18
19
20
0
0
0
0
0
0
0
2
2
2
2
2
2
2
1
2
3
4
5
6
7
1
1
1
1
1
1
1
21
22
23
24
25
26
27
1
1
1
1
1
1
1
2
2
2
2
2
2
2
1
2
3
4
5
6
7
1
1
1
1
1
1
1
21
22
23
24
25
26
27
0
0
0
0
0
0
0
2
2
2
2
2
2
2
1
2
3
4
5
6
7
2
2
2
2
2
2
2
28
29
30
31
32
33
34
1
1
1
1
1
1
1
2
2
2
2
2
2
2
1
2
3
4
5
6
7
2
2
2
2
2
2
2
28
29
30
31
32
33
34
0
0
0
0
0
0
0
2
2
2
2
2
2
2
1
2
3
4
5
6
7
3
3
3
3
3
3
3
35
36
37
38
39
40
41
1
1
1
1
1
1
1
2
2
2
2
2
2
2
1
2
3
4
5
6
7
3
3
3
3
3
3
3
35
36
37
38
39
40
41
0
0
0
0
0
0
0
3
3
3
3
3
3
3
1
2
3
4
5
6
7
1
1
1
1
1
1
1
42
43
44
45
46
47
48
1
1
1
1
1
1
1
3
3
3
3
3
3
3
1
2
3
4
5
6
7
1
1
1
1
1
1
1
42
43
44
45
46
47
48
0
0
0
0
0
0
0
3
3
3
3
3
3
3
1
2
3
4
5
6
7
2
2
2
2
2
2
2
49
50
51
52
53
54
55
1
1
1
1
1
1
1
3
3
3
3
3
3
3
1
2
3
4
5
6
7
2
2
2
2
2
2
2
49
50
51
52
53
54
55
0
0
3
3
1
2
3
3
56
57
1
1
3
3
1
2
3
3
56
57
58
58
59
59
60
60
61
61
62
62
Not Used when ATM

standalone E1.
AQM 2
# SDH
0
0
0
0
0
0
0
AQM 3
AQM 1
AQM 0
Figure 3-47 AQM internal Port number
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 98/263

The 2pStm1e Ch FP provides 2 STM1 electrical Channelized links.
Lets call SDH0 / SDH1 the first /Second STM1 link on the FP.
2pStm1e Ch FP, E1 capacity:
- The FP supports 126 E1 links when configured with AAL1 unstructured CES,
- The FP supports 114 E1 links when configured with ATM,
When configured with IMA, the 2pStm1e Ch FP handles up to 126 E1 links involved in up to 57 IMA
LG per SDH link.
No APS available on the FP, equipment protection is provided thanks to sparingPanel.

2pStm1e Ch FP supports ATM, IMA and AAL1 unstructured CES.
ATM service is used in so called multi-PCM configuration, where UMTS NodeBs are connected to RNS via
multiple E1 that operate as separate links (not linked into IMA group).
ATM interfaces support:
- PNNI and UNI protocols,
- PVC, SPVC and SVC,
- CBR, rtVBR, nrtVBR and UBR service categories,
- 114 E1s ports per FP (57 per STM-1 port).
Note that STM-1 Channelized supports 63 VC12. 6 of them cannot be used for ATM service
(VC12 identified by k=3, l= 2 to 7, m = 3),
- UNI / NNI Atm interface types (maxVpiBits set with value 8/12),
- up to 8000 PVCs (nPVCs) per FP,
- up to (16000-nPVCs) SPVCs per FP,
- up to 200 VCC with F5 OAM loopBacks configured,
The 2pStm1 e Ch Fp is composed of 4 AQM components. The capacity of the FP and the AQM in terms of
amount of atmConnections is configured through the commands:
- Lp Eng Arc Ov connectionPoolCapacity,
- Lp Eng Arc Ov protectedConnectionPoolCapacity,
- Lp Eng Arc Ov Aqm/n connectionPoolCapacity, with n in the range: [0, 3].
Remark: the protectedConnectionPoolCapacity command refers to the use of sparingPanel.
The setting of these components must satisfy the rules:
Arc Ov connectionPoolCapacity + Arc Ov protectedConnectionPoolCapacity 16 000
Aqm/n Ov connectionPoolCapacity 6 000
n = [0, 3] Aqm/n Ov connectionPoolCap Arc Ov connectionPoolCap + protConnectionPoolCap

Each CES connection provisioned on the 2pSTM1eCh FP requires 1 connection resource.
The connectionPoolCapacity is set with a value higher or equal to the expected maximum unprotected
atmConnections and CES connections.
The protectedConnectionPoolCapacity is set with a value higher or equal to the expected maximum protected
atmConnections and CES connections.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 99/263
3.6.2.6.4 ATM TRAFFICMANAGEMENT CHARACTERISTICS:

2pStm1e Ch FP card is based on AQM TrafficManagement ASIC. Therefore 2pStm1e Ch FP ATM
TrafficManagement characteristics are those of the AQM.
3.6.2.6.5 IMA CHARACTERISTICS:

In most cases where there are multiple E1 links per nodeB, IMA service is used instead of multiPCM/ATM
service.
FP IMA interfaces support:
- Ctc clocking ,
- IMA version 1.1,
- 63 E1 links per STM1 are available,
- Up to 57 IMA linkGroups per STM-1 port,
- IMA linkGroup is composed of E1 from one lonely STM-1 port,
- The different E1 inserted in an IMA LG, may be assigned to the two different AQM
managing traffic from one Stm1,
- IMA linkGroup composed of 1 and up to 32 E1 links (no fractional rate supported),
- Differential link delay 2 ms,
- IMA bw reduction: using holding priority defined for each VCC and/or Service
category,
- IMA frame length 128 not configurable,
- Stuffing cell 1/2048 not configurable.
IMA linkGroup instance is in the range [0 56] for the SDH0 link.
IMA linkGroup instance is in the range [57 113] for the SDH1 link.
An IMA linkGroup uses one port of an AQM. From the configured IMA linkGroup instance, the 2pStm1 FP
determines the AQM internalPort number:
On SDH0: AQM internalPort # <= IMA linkGroupInstance,
On SDH1: AQM internalPort # <= IMA linkGroupInstance - 57.
E.g.:
IMA LG # 1 (SDH0) is assigned to AQM internalPort# 1
IMA LG # 112 (SDH1) is assigned to AQM internalPort# 55
The IMA linkGroup instance must be chosen in such a way:
- The AQM internalPort number associated to IMA LG is in the range [0-56],
- The AQM internalPort number associated to IMA LG is not already associated to a standalone E1
(not included in an IMA LG),
- The IMA linkGroup instance is chosen in such a way the associated AQM internal port is the one
already associated to one E1 inserted in this IMA LG.
Remark:
-
The AQM internalPort number [57-62] can not be assigned to an IMA LG.
Nevertheless the E1 links associated to AQM internalPort number [57-62] may be included in an
IMA LG.
The AQM internalPort assigned to the IMA LG, may be an AQM internal port associated to one E1
belonging to this IMA LG, or to another IMA LG. For simplicity, the rule above suggests to assign
to the IMA LG an AQM internalPort already associated to an E1 belonging to this IMA LG.
3.6.2.6.6 AAL1 CES CHARACTERISTICS:

AAL1 CES interfaces support:
- Unstructured (full E1)
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 100/263
Network synchronization clocking (no SRTS, adaptive)
Up to 126 E1 ports per FP (63 ports per STM-1 port)
PVC, SPVC and SVC support (over PNNI only)
The CES connections may be configured only on AQM1 and AQM3; no CES connection configured on
AQM0 and AQM2.
3.6.2.6.7 SPARING PANEL:

As an Option, Equipment protection requires use of sparing panel. When one FP fails, sparing panel
switches to sparing FP STM-1 electrical ports.
The equipment protection is provided as follows:
- ATM 1:1 hot standby (switchover <100ms), the atm Vcc are not released when sparing
occurs,
-
AAL1 CES warm standby (< 16 sec), the aal11 CES is released when sparing occurs, and
services need to be reconnected
IMA warm standby (< 32 sec), ima/atm Vcc is released when sparing occurs, and
services need to be reconnected
2pOC3 Clear FP
10
11
SparingPanel
Stm1
12
Stm1
13
14
15
16
CP2
2pOC3 Clear FP
2pSTM1 e Ch
SparingPanel
2pSTM1 e Ch
2pSTM1 e Ch
SparingPanel
2pSTM1 e Ch
2pOC3 Clear FP
PP7K:
2pStm1 Ch
SparingPanel
CP2
Here below a representation of the Mss7k populated with 2pStm1ElectricalChannelized FP

protected with SparingPanel.
SparingPanel
Stm1
Stm1
Figure 3-48 SparingPanel on 2pStm1ElectricalChannelized FP protected.
3.6.2.7 2 P STM1 OPTICAL CHANNELIZED FP

The 2pSTM1channelized optical FP is a PP7K card.
The 2pSTM1channelized optical FP characteristics:
- Single slot, while the electrical card is dual slot,
- Supports inter card APS while the electrical card protection relies on a sparing panel
3.6.2.8 2POC3 FP
The 2pOC3 FP is a PP7k card.
This FP is used as an alternative to the MSA32 Stm1 FP, for interface with the RNC-IN.
Three 2pOC3 FP may be populated on the Mss7k, in such a way to have on RNC/Mss7k interface 3 STM1 Links
APS protected.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 101/263
The 2pOC3 FP Transmission Characteristics:

- Two optical ports STM1/OC3,
- SingleMode and multiMode,
- ClearChannel,
- intraCard APS.
Remark: If APS is not configured, the 2 STM1 links may be used independently.
The 2pOC3 FP ATM Characteristics
- UNI signaling,
- PNNI ,
- AQM based,
The 2pOC3 FP IP Characteristics:
- atmMPE.
3.6.2.9 PSFP OR DCPS FP:

The UA6 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.
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.6.2.9.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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 102/263
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 UMTS protocols: RANAP, RNSAP, and NBAP
(Supports RRM, RRC, and aal2Link CAC).
Moreover PMC-TMU is in charge of the UMTS heartBeat.
Up to 14 PMC-TMU components in the ATM RNC, up to 12 PMC-TMU in the Hybrid RNC
are spread over all the PSFP/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 NodeBs 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-TMUs 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 RNC, in up to 32
PMC-RABs within an 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 103/263
RNC Iub UP IP Interface, PMC-PC function:

The PMC-PC is the IP route point of termination.
One external IP@ is 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.6.2.9.2 RNC PSFP/DCPS FP COMPOSITION:

Two cases are taken into consideration: atm RNC and Hybrid RNC.
A Hybrid RNC is populated with both 16pOC3 FP and 4pGE FP interface card whereas the ATM RNC is
populated with only the 16pOC3 FP interface card.
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.
RNC
0&1
8&9
10
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
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
RAB
RAB
RAB
RAB
PMC-M
PMC-M PMC-M
PMC-M
16pOC3 FP
16pOC3 FP
CP3
CP3
DCPS
DCPS 00 DCPS
DCPS 11 DCPS
DCPS 22 DCPS
DCPS 33 DCPS
DCPS 44 DCPS
DCPS 55
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
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
TEG
Figure 3-49, ATM 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 104/263
Up to 32 PMC-RAB.
RNC
0&1
8&9
DCPS
DCPS 00 DCPS
DCPS 11 DCPS
DCPS 22 DCPS
DCPS 33 DCPS
DCPS 44 DCPS
DCPS 55
10
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
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
4pGE FP
4pGE FP
PMC-M
PMC-M PMC-M
PMC-M
16pOC3 FP
16pOC3 FP
CP3
CP3
Pdc
Pdc
0
3
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
TMU
TMU
TMU
TMU
TMU
TMU
TMU
TMU
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
PC
TEG
Figure 3-50, Hybrid RNC DCPS FP composition
Rule: IubTEG_PSFP
The RNC supports up to 10 PSFP/DCPS FP since populated with two 16pOC3 FP and two 4pGE FP.
3.6.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_
- 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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 105/263
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
- 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.6.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
AAL2 COMPONENTS:
3.6.4.1 AAL2IF
All the aal2 Paths configured between the RNC and an adjacent aal2 point node are configured under an
aal2If instance.
Rule: IubTEG_RNC aal2 Components_0
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.6.14 .
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.6.4.2 IUBIF:
Moreover an IubIf instance is assigned to each NodeB. The aal2if and the IubIf instances assigned to the
nodeB are linked together within the RNC.
Rule: IubTEG_RNC aal2 Component_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 going to be reserved to identify up to 2400 nodeB.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 106/263
3.6.4.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.
The bandwidthPool concept has been extended to takes into consideration:
- The nodeB ip interface, see 3.7.11. 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.
Rule: IubTEG_RNC aal2 Component _2
- 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.
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 107/263

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

- 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.6.9. 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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 108/263
RNCIN
RNCIN / IubIf
aal2If i
TransportMap i
interfaceType: Iub
BwPool/x
preference: sharedForAllTrafficTypes
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
preference: primaryForTrafficType
[TC=interactive, RbSetQos=2, ] => qos3
qos3
path
TEG
Figure 3-51, NodeB with two atm bwPools
Exemple of one atm sharedForAllTrafficTypes bwPool and one ip primaryForTrafficType bwPool

ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 109/263
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-52, 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.
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 110/263

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-53, 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,
- Only to on the Iub interface,
- On both the atm and the ip interfaces.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 111/263
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-54 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-54 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.
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 112/263
3.6.5
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-5, #aal2 connections
The pathId is coded on 2 bytes in the range [0, 65535].

Rule: IubTEG_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.6.5.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.6.5.2 AAL2 CID SEIZURE

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.
Rule: Iub_RNC_aal2Path_4
On Iub interface, the loadBalancingMethod must be set to Link.

Remark:
- 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 113/263
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 first free CID is seized.
cidSelectMethod = standardQ2630: the least recently used CID is seized.
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.6.6
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:
3.6.7
AAL5 CONNECTIONS
The amount of aal5 connection supported by the RNC 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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 114/263
Table 3-6, #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.6.7.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. 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-7, 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.6.3):
all6mPktServSP
allPktServSP2
allPktServSP2FullDim
120
120
200
Max # nodeB per serviceGroup
Table 3-8, max #NodeB per serviceGroup
3.6.8
QOS
3.6.8.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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 115/263
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.
The UMTS qos information is mapped to the Transport Qos information through the configurable
TransportMap RNC component.
3.6.8.2 SERVICECATEGORY
The RNC supports the serviceCategories: cbr, rtVbr, nrtVbr, ubr and ubr+.
To each serviceCategory is assigned a trafficDescriptoType value which determines which
trafficDescriptor parameters must be set against the vcc:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 116/263
SC
Cbr
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
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_RNC-Atm _QOS_7
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.6.9
TRANSPORTMAP
The TransportMap realizes Classification for atm and ip interfaces and moreover Marking for the ip
interface:
- Classification:
- Up to 4 UMTS streams are identified 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 umts stream.
- Marking:
- A DSCP value is assigned per Umts stream identified by the Umts qos information:
trafficClass, RbSetQos, ARP-PL, THP.
Remark: The transportMap is the way to configure the Umts to Transport qos mapping table within the
RNC.
The transportMap tables apply to all the utran interfaces, with exception of the IuPS.
Several transportMap tables may be configured within the RNC.
Rule: IubTEG_RNC-Atm_TMap_1
The RNC may be configured with up to 64 transportMap components.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 117/263
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.
Each BwPool (or Aal2If if no BwPool declared) must be linked to exactly one TransportMap.
A transportMap is configured with the following parameters:
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-55, 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.
The interfaceType and Preference are mandatory parameters within the transportMap.
Rule: IubTEG_RNC-Atm _ TMap _4
The primaryForTrafficType Preference value is available only on the Iub interface.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 118/263
- 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.
INPUT values
TC
rbSetQos
ARP-PL
THP
OUTPUT Values
UlDlPreference
DSCP
Qos i
Rule: IubTEG_RNC-Atm_ TMap _5

Four qosi values (qos0, qos1, qos2 and qos3) are supported on the atm
primaryForTrafficType and sharedForAllTrafficTypes 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.6.10.3).
Rule: IubTEG_RNC-Atm _ TMap _6
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-Atm _ 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 UMTS traffic qos requirement is compared to the combination of the transportServiceEntry and
ulDlPreference by the transport admissionControl for selecting 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
07.02 / EN
Standard
29/06/2009
Page 119/263
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-56, transportMap exemple
Several transportMap tables are suggested for the RNC atm interfaces for different applicationContexts:
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
3.6.9.1 TRANSPORTMAP TABLES:

- 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
07.02 / EN
Standard
29/06/2009
Page 120/263
Transport MAP /1
Comments:
IuCS, Iur, Iub
Tse
TC
1 Common
2 signaling
R99
"
"
IuCS
R99
"
"
Iub, Iur
R99
"
Hspa
"
"
Iub, Iur
R99
"
18 interactive
19 interactive
20 interactive
"
"
"
"
"
"
Hspa
"
27 interactive
28 interactive
29 interactive
"
"
"
R99
30 interactive
31 interactive
32 interactive
33 background
Hspa
34 background
35 background
36 background
"
"
"
Iub, Iur
"
"
21 interactive
22 interactive
23 interactive
24 interactive
25 interactive
26 interactive
"
"
Iub, Iur R99
"
12 streaming
13 streaming
14 streaming
15 interactive
16 interactive
17 interactive
"
Iub, Iur
6 streaming
7 streaming
8 streaming
9 streaming
10 streaming
11 streaming
"
Iub, Iur
3 conversational
4 conversational
5 conversational
37 background
38 background
ARP
ignore
ignore
THP
ignore
ignore
ignore
ignore
ignore
ignore
ignore
2
0
1
ignore
ignore
ignore
ignore
ignore
ignore
ignore
0
rbsetQos
0
0
0
qos
0
0
0
0
1
noPreference
default
noPreference
default
noPreference
default
noPreference
default
nopreference
default
nopreference
default
default
nopreference
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
default
noPreference
noPreference
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
default
noPreference
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
default
noPreference
noPreference
default
noPreference
default
default
noPreference
noPreference
default
noPreference
default
noPreference
default
default
2
1
uldlpreference
noPreference
2
0
0
DSCP
default
2
ignore
ignore
2
0
1
ignore
ignore
ignore
ignore
Table 3-9, ATM sharedForAllTrafficTypes withOut hspa Streaming
- TransportMap/2:
ApplicationContext:
- UA5 backward compatibility,
- InterfaceType: Iub,
- Preference: PrimaryForTrafficType,
- Transport: ip or atm with only qos3 vcc.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 121/263
Transport MAP /2
Tse
TC
ARP
THP
1 interactive
2 interactive
3 interactive
4 interactive
5 interactive
6 interactive
7 interactive
8 interactive
9 interactive
rbsetQos
qos
DSCP
uldlpreference
AF11
preferredForUlAndDl
preferredForUlAndDl
preferredForUlAndDl
preferredForUlAndDl
2
AF12
preferredForUlAndDl
preferredForUlAndDl
preferredForUlAndDl
AF13
10 background
11 background
ignore
ignore
12 background
ignore
preferredForUlAndDl
preferredForUlAndDl
preferredForUlAndDl
DE
preferredForUlAndDl
preferredForUlAndDl
Table 3-10, IP or ATM primaryForTrafficType, 1 qos
- TransportMap/3:
ApplicationContext:
- InterfaceType: Iub, IuCS and Iur,
- Hspa streaming: hspa streaming supported,
- Preference: SharedForAllTrafficTypes,
- Transport: atm, enhancedQos activated.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 122/263
Transport MAP /3
Comments:
IuCS, Iur, Iub
Tse
TC
1 Common
2 signaling
R99
"
"
IuCS
R99
"
"
Iub, Iur
R99
Hspa
"
"
Iub, Iur
R99
"
"
"
"
"
"
"
Hspa
"
"
"
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
Hspa
34 background
35 background
36 background
"
"
ignore
R99
"
"
6 streaming
7 streaming
8 streaming
9 streaming
ignore
30 interactive
31 interactive
32 interactive
33 background
"
THP
ignore
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
ignore
qos
0
0
0
default
noPreference
default
noPreference
default
nopreference
default
nopreference
default
default
nopreference
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
default
noPreference
noPreference
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
default
noPreference
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
noPreference
default
default
noPreference
noPreference
2
0
1
2
ignore
0
1
noPreference
noPreference
noPreference
default
default
default
2
0
uldlpreference
noPreference
default
DSCP
default
2
1
rbsetQos
0
0
ignore
2
0
1
ignore
ignore
ignore
ignore
default
noPreference
default
default
noPreference
noPreference
default
noPreference
default
noPreference
Table 3-11, ATM sharedForAllTrafficTypes with hspa Streaming
- Transportmap/4:
ApplicationContext:
- InterfaceType: Iub,
- Preference: PrimaryForTrafficType,
- Transport: atm, four qosx vcc.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 123/263
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-12, ATM primaryForTrafficType, 3 qos
3.6.10 TRANSPORT ADMISSION CONTROL

Ref: [R160]
The transport admissionControl regulates amount of simultaneous established calls. It applies on both atm
and ip interfaces.
The regulation is invoked in call establishment phase.
The regulation may be achieved with different granularities: aal2 interface, aal2 qos or aal2 path.
The regulation takes into consideration a bandwidth configured against each rab and the available
bandwidth either per interface, per qos or per path.
Moreover the transport admissionControl achieves a Load balancing on the Iub atm downlink direction.
3.6.10.1
EQUIVALENTBITRATE
For each utran aal2 interface (Iub, Iur and IuCS), per direction (ul and dl), per trafficClass and as an
option per THP are configured:
- an equivalentBitRate (EBR),
- a maximumBitRate (MBR) and
- a rbSetQos value.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 124/263
admissionControl
- Iux: iubif, iurif or iucsif
Iux +TC (+THP option)
- TC: trafficClass
Identification of the cacTransportInfoList (i) with

cacTransportInfoInstanceCharacterisctics = TC (+ THP opt)
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-57 admissionControl, EBR configuration
The configured EBR value is taken into consideration by the admissionControl during radioBearer
establishment phase when selecting a bwPool.
The configured RbSetQos is an input parameter for the transportMap table.
The equivalentBitRate is an estimation of the bandwidth consumed by a rab at RNL layer. The Transport
overhead must not be taken into consideration when configuring the equivalentBitRate values.
When executing the admissionControl, the RNC applies a transport overhead ratio to the
equivalentBitRate.
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-Atm_AC_1
The configured equivalentBitRate must not take into account the transport overhead.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 125/263
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-13, equivalentBitRate and maxBitRate
Rule: Iub_RNC-Atm_AC_2
Three set of EBR values can be configured for the Interactive trafficClass; one set of EBR values
per THP.
Remark:
Either are configured:
- 1 EBR for interactive THP=0,
+ 1 EBR for interactive THP=1,
+ 1 EBR for interactive THP2.
Or is configured:
- 1 EBR for interactive unspecifiedTHP,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 126/263
On both the Iub and the Iur interfaces, the equivalentBitRate for the streaming trafficClass over hsdpa, is
derived from the received Ranap GBR and from the HspaTransportEbrCorrectiveFactor parameter values
configured against the streaming trafficClass:
Hspa streaming EBR = f (GBR * HspaTransportEbrCorrectiveFactor).
RNC/radioAccessService//HspaTransportEbrCorrectiveFactor range: [0, 200%].
If HspaTransportEbrCorrectiveFactor = 0%, then EBR=0 the admissionControl doesnt apply to the
stream.
The Operator ensures the consistency of the configured EBR value based on his desired allocation
strategy.
3.6.10.2
INTERFACE BANDWIDTH
On the atm interface, the admissionControl determines the aal2path bandwidth for each direction based
on the configured UL and DL vcc trafficDescriptor and the generic CAC 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 determines 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
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 127/263
aal2If i
Cacm=qos
qosnBwReservation
BwPool/x
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
congestionManagement n
transportMap m
congestionManagement x
transportMap y
BwPool/y
qos 3
path
path
TEG
Figure 3-58, admissionControl attributes
Cacm parameter value range: [aal2If, ipIf, qos, aal2path].

For the atm interface, the admissionControl supported granularities are: bwPool, aal2Qos and aal2Path.
Rule: IubTEG_RNC-Atm_AC_3
It is recommended to regulate the traffic at aal2 interface bandwidth (cacm= aal2if).
Cacm=Qos is reserved for specific contexts.
Remark:
- 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 = bwPool1 vcc UL ECRgcac,
bwPool1 DL availableBandwidth = bwPool1 vcc DL ECRgcac,
bwPool2 DL availableBandwidth = bwPool2 vcc DL ECRgcac.

Remark: If one single bwPool under the aal2If, then cacm=aal2If availableBandwidth has same
definition as in previous releases.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 128/263
- 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.
Furthermore when setting the qosnBwReservation with a non zero value, 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 parameter value is taken into consideration by the admissionControl on both
downLink and upLink.
The qosnBwReservation is applicable only if cacm=qos.
The qosnBwReservation parameters are either configured against the bwPool component or against
the aal2If then apply to all the bwPool under the aal2If.
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,
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].
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 129/263
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-59, cacm=qos for atm Rnc
In such a way qos3BwReservation > 0% is effective then:
- 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.6.10.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
07.02 / EN
Standard
29/06/2009
Page 130/263
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-60, 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
07.02 / EN
Standard
29/06/2009
Page 131/263
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-61 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.6.10.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
07.02 / EN
Standard
29/06/2009
Page 132/263
Definition:
NT_DL_Watermark_EBR_Aal2If
- Type: cumulative,
- Granularity: qos,
- Definition:
NT_DL_WaterMark_EBR_IpIf
- Type: cumulative,
- Granularity: qos,
- Definition:
3.6.10.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.6.10.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 other 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 hdsl leg. The
atmSwitches within the backbone switch the hsdpa traffic over the adsl leg.
- NodeB bandwidth:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 133/263
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
HSDPA
100%
100%
nrtVBR
RNC ATM tx
PCR
SCR
4490
900
MBS/ ECR per

MDCR
VCC
20
1499
30
2766
30
4266
4266
4266
4490 1999
1
nrtVBR
4490 4063
UBR+
4490
Backhaul
RNC ATM rx
ECR per
HP
4266
4267
4266
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
1
2
Qos
UBR1
UBR
UBR+3
UBR
ADSL
UBR+3
HSDPA
100%
UBR+
4490
4266
4266
4266
ADSL
UBR+3
HSDPA
100%
UBR+
4490
4266
4266
4266
ADSL
UBR+3
ALU confidential
UMT/IRC/APP/7149
N
HP
07.02 / EN
Standard
29/06/2009
Page 134/263
admissionControl: Hs-dsch & E-dch IubFp EquivalentBitRate > 0

aal2If i
Cacm=qos
TransportMap x
interfaceType: Iub,
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
UBR+, rx&tx tdt=9, rxTD= 0-0-0-0-0, txTD= 4490-0-4063-0
1 hsUpa path
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
RNC
RNC
NodeB
NodeB
(Option: qos1 vcc)
Stm1
HsDpa qos3 vcc
IMA 5 E1
TEG
Figure 3-62 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.
o Hsupa sc= ubr+ if a minimum bandwidth needs to be reserved for HSUPA traffic at
the FP atm scheduler level.
o 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 135/263
Within the bwPool x, a qos3 vcc with the most available upLink bandwidth is
selected.
The e-dch leg is accepted if the bwPool x available bandwidth is higher than the e-dch
overhead*iubFpEquivalentBitRate.
3.6.10.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
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
4 qos3 vcc
BwPool x
aal2If i
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-63, 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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 136/263
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.
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.6.11 CONGESTION MANAGEMENT BANDWIDTH LIMITATION

A.K.A RATE CONTROL
Reference: [R160]
The congestionManagement mechanism consists in discarding excess traffic for a given qos, moreover
the mechanism anticipates congestion state by interrupting momentarily the transmission.
The traffic is regulated at bandwidthPool level.
The RNC congestionManagement is supported on the Iub interface and the Iur interface [R3] downlink
traffic.
The RNC Iub congestionManagement encompasses two regulation mechanisms:

- The qosDiscard algorithm,
- The backPressure algorithm.
Rule: IubTEG_RNC-Atm_CM _1
If regulation is required, it is recommended to activate both together qosDiscard and

BackPressure.
For both algorithms and per qos, the RNC measures the per qos realTime traffic and determines
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].
Remark: qosDt(0) and qosBp(0) are set to zero therefore no regulation applies to the qos0 traffic.
3.6.11.1
CONGESTIONMANAGEMENT TABLE:
The congestionManagement parameters involved in the qosDiscard and backPressure thresholds setting,
are configured through the RncIn/CongestionManagement tables.
Rule: IubTEG_RNC-Atm_CM_2
The RNC supports up to 64 congestionManagement tables.

Each aal2If/BwPool or aal2If is linked to a CongestionManagement table.
Each aal2Path must be linked to an appropriated congestionManagement table either through the
aal2If or aal2If/bwPool component it belongs to.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 137/263
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 parameters involved in the qosDiscard threshold determination,
- The per qos parameters involved in the backPressure threshold determination.
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-64, congestionManagement links
3.6.11.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:
o New formula for Txoff,
o New formulas for qosDiscard and qosBackPressure thresholds,
o The congestionFlag is inserted in the Xoff signal, always set to No.
Remarks:
o Supports up to 3 qos, No support of Hspa streaming,
o GBR and minBr not supported.
The RncIn enhancedQos parameter must be set to disable, when the congestionManagement
UA5 equivalent behavior is preferred.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 138/263
If enhancedQos=enable, the congestionManagement provides the UA6 behaviour:

o Support up to 4 qos,
o Support of Hspa streaming
o The CM algorithm specified in [R160] introduces:
The Xon signal,
The congestionFlag set either to yes or no is inserted within the Xoff
signal,
The GBR for streaming Hsdpa and Dch,
The minBrForHspa for interactive and background Hsdpa,
The minBrForR99 for interactive and background Dch,
Suggested minBr values:
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-14, suggested minBr vaues
The qosnBwReservation is taken into consideration,
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.6.11.3
QOSDT AND QOSBP PARAMETERS
Since up to 4 qos are supported, up to four qosDiscard thresholds and 4 qosBackPressure thresholds are
set then one qosDt parameter is set per qos and one qosBP parameter is set per qos.
qosDt(0) qosDt(1) qosDt(2) qosDt(3)

A qosBP(n)=0 means that the backPressure doesnt apply for the qos n.
For the case of no hspa streaming supported, two sets of qosDiscardThreshold values are suggested which
satisfy two different Iub contexts:
- The context basicVPT trafficShaping on the Iub interface.
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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 139/263
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.
For these 3 Iub configurations, apply on the RNC the congestionManagement Discard Threshold
set of values case of basicVPT trafficShaping on the Iub interface.
Context No basicVPT trafficShaping on the Iub interface:
o 1/ the trafficShaping is not activated neither in the RNC nor in the POC,
o 2/ 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
For these two Iub configurations, apply on the RNC the congestionManagement Discard
Threshold set of values case of No basicVPT trafficShaping on the Iub interface.
Case of No basicVPT trafficShaping on the Iub interface: qosDt 0 0 1 0 2 350 3 500

Case of basicVPT trafficShaping on the Iub interface:
qosDt 0 0 1 0 2 300 3 500
Case of No basicVPT trafficShaping on the Iub interface:

3.6.11.4
qosBPt 0 0 1 0 2 95 3 95
qosBPt 0 0 1 0 2 33 3 35
COUNTERS:
Two kinds of real time counters are implemented which measure the trafficVolume per 10 ms period:
- The per qos real time counters: Q010ms, Q110ms, Q210ms and Q310ms,
- The per cumulative qos counters: Qxxx, in extenso: Q0, Q01, Q012 and Q0123.
The four per qos counters provide per qos the trafficVolume over a 10 ms period:
Qn10 ms Counters
Qos
Q010 ms
Qos0
Q110 ms
Qos1
Q210 ms
Qos2
Q310 ms
Qos3
Table 3-15, per qos counters
Furthermore the RNC estimates the per qos expected trafficVolume over the next 10 ms period, based
on the per qos measured trafficVolume over the previous 10 ms periods. For that the RNC set the Qne
(estimated) counters:
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-16, qosn estimated counters
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 140/263
The counter unit is either cell/10ms for the atm interface or bytes/10ms for the ip interface.
The four per cumulative qos counters Qxxx provide the trafficVolume over a 10 ms period for qos0,
qos0+qos1, qos0+qos1+qos2, qos0+qos1+qos2+qos3:
Qxxx Counters
definition
Q0
= Q0e, Half of the qos0 trafficVolume over the previous 20 ms period.
Q01
= Q0e + Q1
(qos0 + qos1 traffic)
Q012
= Q01 + Q2
(qos0 + qos1+ qos2 traffic)
Q0123
= Q012 + Q3
(qos0 + qos1 + qos2 + qos3 traffic)
Table 3-17, 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= 0% in the context of UA6 behaviour.
- 10msdecrqosn = bwnavail since the qosnBwReservation > 0% in the context of UA6 behavior.
3.6.11.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.
The qosnBwReservation parameters are involved in the Transport admissionControl.
The qosnBwReservation parameters are also involved in the congestionManagement thresholds
determination if:
- the enhancedQos = enabled,
- cacm=qos,
- qosnBwReservation > 0%.
The qosnbwReservation is taken into consideration by the congestionManagement if:

- The RncIn enhancedQos = enable,
- The cacMethod = qos.
3.6.11.5.1 CASE OF QOSNBWRESERVATION= 0%:

The qosnBwReservation parameter values dont influence the thresholds determination.
QosDiscardThresholds, UA6 and UA5 equivalent behaviours:
One discard threshold is set per qos. 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 141/263
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-18, 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-19, qos backPressure thresholds

-
The BP thresholds are recalculated each 50 ms.

When qosBPTn = 0, no backpressure mechanism is applicable.
3.6.11.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,
- A bandwidth portion shared between all the different qos.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 142/263
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-20, bwxavail & bwxexclus on atm interface
Per period of 10 ms, an estimation of the per qos 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-21, discard threshold when qosnBwReservation > 0%
The qosBP threshold formulas are not impacted by the qosnBwReservation nevertheless the qosBP
threshold values are impacted by the qosnBwReservation.
3.6.13 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 last bit must be set to 1 for Hybrid NodeB, else set to
0 for atm NodeB.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 143/263
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-65, 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.
Rule: IubTEG_RNC_ nodeB discrimination _2
The RNC/NodeB/ nodeBCapability last bit must be set to:
- 1 if Hybrid NodeB,
- 0 if atm NodeB.
3.6.14 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_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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 144/263
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-66 Alcap protocol flow
Both the RNC-IN and the RNC-CN models are involved in the Alcap configuration.
The RNC-IN model:
Root
Aal2if i
- Cacm
IubIf i
RNC
- CidSelectMeth
Sig (07)
- Qosparameters
- saalUni
Nap/ atmConnection
- LoadBalancingMeth
- UmtsInterfaceList (up to 16)
UPlane
- linkTo aal2If
IubTransport flowCtrl
- activation
Qaal2Parameters
- orig A2EA,
- Qaal2 timers,
- aal2RouteList (up to 128)

bwPool x
Qaal2 endPoints
A2EA (0):
PathId i
- atmConnection
aal2If, cost
- Qos
A2EA (16 383):
- pathOwner
aal2If, cost
Alcap bearer
-saalUni
Nap/ atmConnection
TEG
Figure 3-67, RNC-IN Model
The RNC-CN model:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 145/263
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-68, 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:
- 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 146/263
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.
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.6.15 UTRAN SHARING

The objective of the UTRAN sharing feature is to allow the UTRAN network to be shared between
several UMTS operators:
Rule: IubTEG_utranSharing_1
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 147/263
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.
3.6.15.1
UTRAN INTERFACE IMPACT:
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 userPlane Transport resources are either shared between all the PLMN sharing the
utran or dedicated per PLMN sharing the utran (see 3.6.4.3):
- The Iub cp and ccp vcc are shared between all the Plmn sharing the Utran,
- The IubTransport userPlane resources may be either shared between all the different
PLMN sharing the utran or dedicated per Plmn.
When the IubTransport userPlane resources are dedicated per PLMN, one or several
bwPool(s) is/are configured per Plmn. Within these bwPools are grouped the
userPlane resources (aal2 Path, ipFlow) dedicated to the Plmn see 3.6.4.3.
A bwPool is either shared between all the PLMN sharing the UTRAN (PLMN
Common bwPool) or a bwPool is dedicated to one PLMN (PLMN specific bwPool).
Both the PLMN specific bwPool and the PLMN Common bwPool may coexist within
a RNC. A PLMN specific bwPool is set with the corresponding PLMNId.
Iur interface impact:

- A shared RNC may have Iur interfaces with both shared and not shared RNC
- The Iur user and control plane Transport resources are common to all the PLMN sharing the
utran,
- No Iur interface configured between the two logical RNC.
Iu interface impact:
- Each Plmn has its own CS and PS coreNetwork nodes,
- The Iu user and control plane Transport resources are dedicated per Plmn. On the RNC is
configured one IuCS and one IuPS interfaces per Plmn.
- The IuBC vcc is shared between the different PLMN sharing the RNC.
- The UtranSharing feature is compatible with the BICN and IuFlex features.
- IuPS: utranSharing applies to both the atm and the ip interfaces.
3.6.15.2
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 148/263
The RNC is identified by one A2EA, and traffics with utran aal2 nodes (NodeB, neighbor RNC and
MGw):
The A2EA numbering plan must be coordinated between all the Plmn sharing the utran.
Example of utran network with utranSharing activated:
Operator A, own MNC
UE
UE
MGw1
On the Iub, the Transport

resources are common to
both operators unless
PLMN bwPools are
configured per PLMN.
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
SGSN 1
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,
ATM
ATM
Operator B, own MNC
3.6.16 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 149/263
3.7
RNC HYBRID
The hybrid RNC is populated with both the 16pOC3/Stm1 FP and the 4pGE FP and provides:
- Both atm and ip on the Iub interface,
- Only atm available on the IuCS and Iur interfaces,
- Both atm and ip on the IuPS interface.
The features related to the atm interfaces are described in the section 3.6 RNC ATM.
This section cover the hybrid RNC features related to the IP over Ethernet interfaces.
Rule: IubTEG_hybridRNC_1
On the Iub, the IP interface is dedicated to Hsdpa and Hsupa interactive/Background whereas the atm
is dedicated to R99, signaling, Hspa streaming, oam and as an option Hspa interactive/Background.
3.7.1
FP
3.7.1.1 4PGE FP
The 4 pGE FP provides 4 Ethernet accesses:
- Ethernet port throughput: 1 Gb/s
- FP throughput: 2,5 Gb/s.
3.7.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.7.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).
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 150/263
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.7.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).
3.7.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:
- the mapping between each DSCP value and the classQueue,
- classQueue properties,
- The per DSCP discard policy.
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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 151/263
EF, CS5
Premium
CS4, AF4y
Platinum
CS3, AF3y
Gold
CS2, AF2y
CS1, AF1y
Silver
Bronze
DE
Standard
Table 3-23, 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 schedulingClass range value: [0, 7].
Without customisation, the following default mapping applies:
trafficClass
Critical
schedulingClass
7
Network
Premium
Platinum
6
4
Gold
Silver
Bronze
1
Standard
0
Table 3-24, schedulingClass
ClassQueues properties:
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
EP5
10
7
EP6
EP7
3
Table 3-25, 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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 152/263
DSCP
CS6
AF4y
AF3y
AF2y
AF1y
DE
with y = (1, 2, 3)
trafficClass
critical
premium
network
platinium
gold
silver
bronze
Standard
schedulingClass
7
6
5
4
3
2
1
0
EP
0
1
2
3
4
5
6
7
MBG%
na
na
50
25
10
7
5
3
Queue Size
100 K
300 K
300 K
300 K
7000 K
4200 K
3000 K
2200 K
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:
- 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-26 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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 153/263
3.7.1.1.5 LAN / VLAN

The ethernet Vlan objective is to split an ethernet port into several sub virtual ports each identified by a
Vlan Identifier and moreover by configuring vlan on a backhaul reduces the broadcast traffic.
The Vlan is an optional ethernet concept. If Vlan configured on the Iub interface, since the Iub backhaul
includes IP routers, 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.
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.
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-69, port mode versus Vlan mode components

The choice between port Mode and Vlan mode is set at the port 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.7.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. Each Vlan is linked to one VR PP. Beside a RNC VR
supports up to 60 protocol ports. As a consequence up to 60 Vlan may be linked to one RNC
VR.
Moreover up to 4 Vlan are supported per 4pGE FP port when PDR is activated.
- Up to 400 Vlan per RNC,
- Up to 60 Vlan per VR,
- Up to 8 Vlan per 4pGE FP port when PDR activated.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 154/263
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.
- 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.7.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 consuming one 4pGE FP ARP
table entries,
- A RNC VR protocol port configured with a /24 subnet size consuming 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.7.1.1.7 SOC
IP
IP
Supported
IPv4
Not Supported
Ipv6
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 155/263
IP static routing
OSPF, RIP
ICMP
ECMP (note1)
ARP
IPSec
DHCP relayAgent
Fragmentation (note2)
DifferentiatedServices
PDR (protection Default Route)
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)
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.7.2
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_
- 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
07.02 / EN
Standard
29/06/2009
Page 156/263
- 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.7.3
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
IP COMPONENTS
3.7.3.1 IPIF:
The IpIf component identifies the remote UMTS node ip interface, e.g.: NodeB ip interface.
Remark: The ipIf component is supported only on the Iub interface (Not supported on the IuPS).
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, 5000] 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.7.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.
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.
The bandwidthPool concept has been extended to takes into consideration:
- The nodeB ip interface: 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 157/263
Asymmetrical traffic.
One or several bwPool 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 trafficErreur ! Liaison incorrecte.
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.
The qosnBwReservation is configured either under ipIf/bwPool.
The qosnBwReservation can not be configured under ipIf.
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 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 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.

- The R99 and Hspa streaming traffic is handle only on the atm sharedForAllTrafficTypes
bandwidth pool.
- As an option the Hspa I/B traffic is handle on the sharedForAllTrafficTypes bandwidth pool.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 158/263
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.6.9. 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
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-70, NodeB with one atm bwPools and one ip bwPool
According to the iub topology, different bwPool strategies may be chosen:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 159/263
Topology
N*E1+IMA
Hybrid Iub
2 IMA
1 IMA
bwPool/Preference
Transport
N * sharedForTrafficTypes
Atm
Atm
Atm
Ip
Atm
Atm
Atm
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
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
07.02 / EN
Standard
29/06/2009
Page 160/263
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-71, 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.
Rule: IubTEG_RNC aal2 Component
The asymmetrical traffic handling applies:
- only to the hspa I/B traffic,
- 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,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 161/263
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-72 Asymmetrical bwPools case of hybrid iub
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-72 Asymmetrical bwPools case of hybrid iub:
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.7.3.3 IPFLOW:
One ipIf/bwPool is populated with one or up to 4 ipFlow component(s), each configured with different
qos.
Nevertheless, in UA6 only one qos3 stream is supported under an ipIf/bwPool, therefore one ipIf/bwPool
is populated with one single ipFlow set with either qos3.
Furthermore is configured against each ipFlow component, the expected traffic through the attributes:
- downLinkCommitedRate (kb/s)
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 162/263
- upLinkCommitedRate (kb/s)
- downLinkPeakRate (kb/s)
- 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 j
SignalingBearer
userPlane
ipLink
ipIf i
cacm
BwPool/y
transportMap
congestionmanagement
PLMN Mcc & Mnc (utranSharing)
qosnBwReservation
(with n =[0, 1, 2, 3]
IP Flow:
qos3
downLinkCommitedRate (kb/s)
upLinkCommitedRate (kb/s)
downLinkPeakRate (kb/s)
upLinkPeakRate (kb/s)
transportMap i
congestionManagement i
TEG
Figure 3-73, RNC IP components
3.7.4
VIRTUAL ROUTER RNC COMPOSITION

Reference: [R161]
Within the RNC, the VR routes the IP traffic on the Iub and IuPS interface.
Two RNC virtualRouter compositions are considered: the segmentedVR and consolidated VR.
The RNC segmented VR composition is considered as the default one whereas the consolidated VR
composition is considered as an alternative.
- The segmented VR composition consists in assigning two different VR for Iub userPlane traffic and
IuPS traffic.
The RNC is configured with 6 VR:
- 1 VR dedicated to the OAM traffic,
- 1 VR dedicated to the Iub userPlane traffic,
- 1 VR dedicated to the IuPS userPlane and controlPlane traffic,
- 1 VR dedicated to the locationServices traffic,
- 1 VR dedicated to the cellBroadcast traffic,
- 1 VR dedicated to the RNC internal traffic.
Exemple of VR instance number:
- VR0 dedicated to the OAM traffic,
- VR5 dedicated to the Iub userPlane traffic,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 163/263
VR1 dedicated to the IuPS userPlane and controlPlane traffic,

VR3 dedicated to the locationServices traffic,
VR4 dedicated to the cellBroadcast traffic,
VR2 dedicated to the RNC internal traffic.
- The consolidated VR composition consists in assigning one single VR for both Iub userPlane traffic
and IuPS traffic.
Indeed the RNC is configured with 5 VR:
- 1 VR dedicated to the OAM traffic,
- 1 VR dedicated to the IuPS userPlane, controlPlane traffic and the Iub userPlane traffic,
- 1 VR dedicated to the locationServices traffic,
- 1 VR dedicated to the cellBroadcast traffic,
- 1 VR dedicated to the RNC internal traffic.
Exemple of VR instance number:
- VR0 dedicated to the OAM traffic,
- VR1 dedicated to the IuPS userPlane, controlPlane traffic and the Iub userPlane traffic,
- VR3 dedicated to the locationServices traffic,
- VR4 dedicated to the cellBroadcast traffic,
- VR2 dedicated to the RNC internal traffic.
Note: this VR instance number example is used within the TEG to identify each virtualRouter.
Remark: For both VR compositions, the oam, the internal, the locationServices and cellBroadcast traffic
are served by their own separate VR.
Rule: IubTEG_RNC IP VR_1
One VR is dedicated to the Iub userPlane IP traffic, if Segmented VR.
One VR is shared between the Iub userPlane and the IuPS traffic, if Consolidated VR
The VR is dedicated to the Iub OAM traffic.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 164/263
RNC,
RNC, segmented
segmented VR
VR
IuPS
Hybrid Iub
OAM VR 0
PP
PP PP
PP
UP VR 5
PP
PP PP
PP
IuPS VR 1
PP
PP PP
PP
LS VR 3
CBS VR 4
int VR 2
PP
PP
PP
PP
PP
PP
4pGE
4pGE
RNC,
RNC, consolidated
consolidated VR
VR
Iub
IuPS & Hybrid Iub
OAM VR 0
IuPS & IubVR 1
PP
PP PP
PP
PP
PP PP
PP
4pGE
LS VR 3
CBS VR 4
int VR 2
PP
PP
PP
PP
PP
PP
4pGE
TEG
Figure 3-74, RNC VR composition
Segmented VR advantage:
Provides more flexibility to operators,
Makes easier node maintenance and debugging.

Segmented VR drawback:
May consume more IP addresses,
Taken into consideration up to 2 VR supporting PDR, it may be preferable to reduce amount of
VR.
3.7.5
LOCALMEDIA
Reference: [R161]
The localMedia is a RNC IP media functionality which provides a functional interface to the PMC that
are unaware of the Virtual Router. 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].
A trafficType value is assigned to the LocalMedia interface which identifies the nature of the traffic
supported by the interface.
TrafficType values:
- trafficType = iubUPlane: LocalMedia interface dedicated to Iub User Plane traffic,
- trafficType = iubUPinternal: LocalMedia interface dedicated to the PMC-TMU,
application: UMTS Proprietary loopBack on Iub routes,
- trafficType = ss7CPlane: LocalMedia interface dedicated to IuPS Control Plane traffic,
- trafficType = oam: LocalMedia interface dedicated to the RNC Oam traffic.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 165/263
- trafficType = ls: locationService,

- trafficType = cbs: cellBroadcastService,
Rule: IubTEG_localMedia_1
- TrafficType = oam must be configured against the localMedia interface assigned to RNC
Oam flow.
- TrafficType = iubUPlane must be configured against the localMedia interface assigned to
UMTS Iub UP flow.
- TrafficType = iubUPlaneInternal must be configured against the localMedia interface
assigned to UMTS Iub User Plane failure detection (umts proprietary heartbeat).
There is no constraint on the LocalMedia interface instance numbering. The following LocalMedia
interface instance is given as an example:
- The LocalMedia interface 2 with trafficType = oam, is assigned to RNC Oam flow.
- The LocalMedia interface 5 with trafficType = iubUPlane is assigned to UMTS Iub UP flow.
- The LocalMedia interface 6 with trafficType = iubUPlaneInternal is assigned to UMTS Iub User
Plane failure detection (proprietary heartbeat).
Furthermore a localMedia interface is linked to a VR protocolPort that has an IpLogicalInterface defined.
The localMedia supports 3 IP address assignment policies:
fixed IP@ assignment policy,
Movable IP@ assignment policy,
Configurable IP@ assignment policy,
They are described in the AddressingTEG [R4].
An IP subnet is assigned to the VR PP linked to a localMedia interface supporting fixed IP@ or movable
IP@ assignment policy. The IP@ from the VR PP subnet are assigned to each PMC involved in the
traffic handle by the localMedia interface trafficType according to the assignment policy.
The two figures below represent the IP and ATM paths within an hybrid RNC and LocalMedia
parameters for segmented VR on one side and consolidated VR on other side:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 166/263
RNC
RNC
Case: outOfBand oam.

inBand & outBand Oam supported.
TMU0
TMU0 RAB
RAB
TMU13
TMU13 RAB
RAB
RAB
RAB
M
M 00
M
M 11
RAB
RAB
Iub OAM and Sig are carried over atm.

The Iub UP traffic is handle by the PMC-RAB.
tT: traffic Type
RAB
RAB
RAB
RAB
RAB
RAB
RAB
RAB
OMU0
OMU0
OMU1
OMU1 PC0
PC0 PC11
PC11
PP
PP
VR1
PP
nodeB (hybrid)
(hybrid)
nodeB
IP
IP
VR0
PP
PP
(V)LAN
MPE
GigE
GigE xx
GigE
GigE xx
R99 UP
R99 CP
PP
VR5
Iub
If/2
oam
tT: iubUP
If/5
If/6
tT: rnc
If/0
R99 traffic,
Signaling,
Oam
Hspa stream.
Hspa I/B (opt)
Hspa I/B.
tT: iubUPint
LM
LM
PP
MPE
16pOC3
16pOC3
16pOC3
16pOC3
ATM
ATM
Figure 3-75 Segmented VR
RNC
RNC
Figure 3-76
Consolidated VR
TMU0
RAB
TMU0 NI
NI 00 RAB
RAB
RAB
TMU13
RAB
RAB
TMU13 NI1
NI1 over
RAB
RAB
The user traffic handle
the
RNC
IP interface is routed through the VR5 in case of the VR segmented
RAB
RAB
RAB
RAB
mode, whereas
VR1
in
case
of
the
VR
consolidated mode.
M
PDC0
M 00 PDC0
OMC
eth
OMC
eth
IP
PDC1
M
PDC1 RAB
M 11
IP
RAB
RAB
RAB
PDC2
PDC2
Assuming the VR
segmented mode, the VR5 is configured with one or more PP to the network. More
PDC3
PDC3
OMU0
OMU0
than oneOMU1
PP to the
network
may
required if Iub layer2 backhaul and the subnet size doesnt allow to
bePC9
PDC9
PC0
OMU1
PDC9
PC0
PC9
address all the connected nodeB.
localMedia
CP
localMedia
CP
tT: CBS
If/4
MPE
MPE
If/2
tT: LS
If/3
SS7
oam
If/1
tT: internal
tT: rnc
If/0
If/7
tT: ss7CP
& Iub
tT: iubUP
If/5
IuPS CP & UP
If/6
tT: iubUPint
The VR5 is configured with two PP to the LocalMedia:

- One PP linked to the LocalMedia interface 5 with trafficType=IubUPPlane: on this link all the
user traffic is exchanged between the PMC-PC and the nodeB, including the UMTS Proprietary
heartBeat traffic.
PP
PP
PP
PP
PP
PP
PP
PP
- One PP linked to the LocalMedia
interface
6 PP
with trafficType=IubUPinternal:
onIuPC,
this isIuBC
exchanged
IuPS, Iub,
VR0
VR2 traffic
VR3 between
VR4the PMC-TMU
theVR1
UMTS Proprietary heartBeat
and the PMC-PC.
PP
PP
PP
PPbetweenPP
SGSN
and
The user traffic
is routed through the VR1
the PMC-PC
the PMC-RAB.
SGSN
ATM
ATM
MPE
(V)LAN
MPE
NodeB
NodeB
16pOC3
16pOC3
16pOC3
16pOC3
IP
IP
GigE
GigE xx
GigE
GigE xx
SGSN
SGSN
TEG
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 167/263
tT = iubUPinternal
PP
PP
TMU 00
TMU
TMU 11
TMU
itf = 6
VR 55
VR
TMU 11
11
TMU
UMTS Proprietary HeartBeat:
4pGE
4pGE
PP
PP
tT = rnc
itf = 0
VR1
VR1
PP
PP
PP
PP
RAB
RAB
RAB
RAB
RAB
RAB
UMTS user plane handling:
localM
localM
PC 00
PC
PC 11
PC
PC9
PC9
tT = iubUPlane
itf = 5
(V)LAN
(V)LAN
TEG
Figure 3-77 Segmented VR, traffic flows
The UMTS Proprietary heartbeat checks the continuity of the overall Iub userPlane datapath between the
RNC and the Node B.
3.7.6
PDR
Reference: [R161]
The Protected default route (PDR) is a layer3 sparing mechanism which guarantees a traffic disruption
less than one second; this time includes the failure detection and the traffic diversion.
The PDR is a protection against port and line failure.
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
If PDR is used, only the static default route must be the protected route.
The VR default route acts as a protected 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 168/263
The RNC may be configured with up to 2 VR with protected default route:

Rule: IubTEG_PDR_5
The RNC supports up to two VR with PDR enable.
The VR routing table may consist of both: protected default routes and more specific routes, the more
specific route is selected first when forwarding IP packets. On more specific route failure, its traffic is
diverted to the protected default route (if available).
A protected default route provides a protection against more specific route failure and against protected
default route nextHop failure:
- Case of more specific route failure, its traffic is diverted to the protected default route
more preferred nextHop,
- Case of protected default route nextHop failure, its traffic is diverted to a less preferred
protected default route nextHop (if present).
RNC Iub VR routingTable:

VR /x
R
R 33
Y
IP@ 3-2
IP
Static
Route = 0.0.0.0, protected=y
NextHop = IP@ 1-2 /30,
lan
RNC
RNC
Path 3
GE
VR
VR
NodeB
NodeB
PP3
metric=1
PP2
PP1
IP@ 3-1 IP@ 2-1
R
R 22
NodeB
NodeB
Backhaul
Backhaul
IP@ 2-2
lan
lan
lan
metric=2
Route = X.X.X.X,
NextHop = IP@ 3-2 /30
lan
GE
Path 2
GE
GE
FP1
FP1
GE
FP2
FP2
SGSN
SGSN
NextHop = IP@ 2-2 /30,
IP@ 1-1
R
R 11
Y
IP@ 1-2
lan
GE
Path 1
TEG
Figure 3-78 PDR with 3 routes and 3 routers
Comments:
Assuming metric=1 assigned to the RNC VR PP1 and metric=2 assigned to the RNC VR PP2,
Under normal condition:
- The RNC sends the IP packets with DA = x.x.x.x to router 3,
- The RNC sends the IP packets with DA x.x.x.x to router 1.
Under Path1 failure:
- The RNC forwards the IP packets with DA x.x.x.x to the router 2,
Under Path3 failure:
- If the RNC is aware about the path3 failure, it forwards the IP packets with DA
x.x.x.x to the router 1.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 169/263
In this case the ICMP Heartbeat is not a trigger for PDR since the ICMP heartbeat is not
supported on the more specific IP route ( 0.0.0.0).
A protected static default route should be configured with several nextHops in such a way to be able to
divert the traffic to a less preferred nextHop in case of failure of the 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_6
At least 2 nextHops and up to 4 nextHops are 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_7
Each PDR nextHop should be configured over different Ethernet links from different 4pGE FP
and should be connected to different adjacent IP routers.
The more specific route nextHop and the 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).
The following figures provide different topologies when PDR is activated on the RNC side, according to
one or several adjacent IP routers, 2 or more IP routes between the RNC and the routers:
RNC
RNC
R
R 11
Y
GE
GE
lan
IP@ 2-1
Group 1
lan
PP2
IP@ 1-1
10.32.2.253
lan
Backhaul
Backhaul
NodeB
NodeB
IP@ 1-2
NodeB
NodeB
10.32.2.128
PP1
X
IP@ 2-2
Group 2
VR
VR
lan

VR /x
IP
Static
metric = 1
metric = 2
FP0
FP0
GE 0
Route = 10.32.2.0 /25

GE 1
GE 2
GE 3
NodeB
NodeB
10.32.2.1
FP1
FP1
GE 0
GE 1
GE 2
NodeB
NodeB
10.32.2.127
GE 3
TEG
Figure 3-79, with 2 routes, 1 router, assuming up to 253 nodeB
Remarks: a solution with one router is less desirable since one single point of failure.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 170/263
RNC
RNC
VR /x
VR
VR
Group 2
PP1
IP@ 1-2
10.32.2.128
IP
Static
metric = 1
IP@ 2-1
NodeB
NodeB
PP2
IP@ 1-1
R
R 11
GE
lan
Path 1
lan
lan
NodeB
NodeB
Backhaul
Backhaul
10.32.2.253
Group 1
NodeB
NodeB
R
R 22
Y
10.32.2.1

metric = 2
FP0
FP0
GE 0
GE 1
GE 2
GE 3
Route = 10.32.2.1 to,

10.32.2.127
IP@ 2-2
lan
GE
Path 2
NodeB
NodeB
FP1
FP1
GE 0
GE 1
GE 2
GE 3
10.32.2.127
Remark: the LAN connections could be replaced with VLAN

connections to share the same fibre between Iub and IuPS over IP.
TEG
Figure 3-80, PDR with 2 routes, 2 routers, assuming up to 253 nodeB
Group 4
NodeB
NodeB
10.32.3.128
R
R 11
NodeB
NodeB
GE
FP0
FP0
GE 0
GE 1
GE 2
NodeB
NodeB
GE 3
R
R 22
10.32.2.128
Group 1
lan
IP@ 2-2
10.32.2.253
lan
lan
lan
IP
Static
metric = 1
metric = 2
metric = 3
metric = 4
Route = 10.32.2.0 /25
X
IP@ 4-2
NodeB
NodeB
PP4
IP@ 4-1
Group 2
IP@ 2-1
GE
Backhaul
Backhaul
NodeB
NodeB
PP2
lan
lan
10.32.3.127
PP3
IP@ 3-1
lan
10.32.3.1
IP@ 1-1
NodeB
NodeB
PP1
IP@ 1-2
Group 3
VR
VR
X
IP@ 3-2
10.32.3.253

VR /x
RNC
RNC
lan
FP1
FP1
GE 0
GE 1
GE 2
Route = 10.32.3.0 /25

GE 3
NodeB
NodeB
GE
10.32.2.1
GE
Route = 10.32.2.1 /25

NodeB
NodeB
10.32.2.127
TEG
Figure 3-81, PDR with 4 routes and 2 routers, assuming up to 400 nodeB
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 171/263
Preferred nextHop selection:

The metric assigned to the different protected default route nextHops (Vr Ip Static Route
Nexthop) are used to determine the preferred nextHop.
The highest preference is given to the nextHop with the lowest metric value.
Revertive:
- If all the protected default route nextHops with same metric, the protection is nonrevertive. When the previously failed nextHop comes back into service, the traffic is
not switched back to the initial nextHop.
- If the protected default route nextHops with different metric values, the protection is
revertive. When the previously failed nextHop comes back into service, the traffic is
switched back to the initial nextHop set with the lowest metrics.
Remark:
If several protected default route nextHops with same metric, the port that comes into
service earlier will have the higher preference. The nextHop preference remains
unchanged as long as the associated port status remains in service (unlocked,
enabled).
Triggers:
- Layer 1 failure (fiber cut, FP failure),
- administrative locking of: GE port, VLAN, VR PP, IpPort (near and far End)
- The ICMP HeartBeat is a trigger for PDR traffic diverting; nevertheless this tigger doesnt
guarantee a traffic disruption less than 1 second.
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_8
The preConfigFwdPath attribute must be enabled for both protected and unprotected routes to
resolve ARP prior to route installation.
General Remarks on PDR:
- In case of consolidated VR mode, both Iub and IuPS traffic routed through the same VR, then
the protected default route provides IP flow protection for both Iub and IuPS traffic.
- Even if one single PDR path is active for transmission, the RNC handles the traffic received
on all the PDR paths (active and alternate paths). Therefore the adjacent IP router is allowed
to distribute the upLink traffic on the different PDR paths according to its own policies.
3.7.7
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.
Rule: IubTEG_ICMP_0
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
07.02 / EN
Standard
29/06/2009
Page 172/263
Since the ICMP Heartbeat is a trigger for RNC PDR:

Rule: IubTEG_ICMP_1
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 per IP route through the RNC attribute: VR Ip Static Route heartbeat.
This attribute is taken into consideration by the RNC since 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_2
The ICMP heartbeat deadInterval must be set to 3 seconds.
The ICMP Heartbeat enabled on an IP route applies to all the nextHops involved in the IP route traffic
forwarding.
The ICMP Heartbeat packet Dscp value is configured (RNC attribute: phbGeneralSource).
Failure time detection:
The ICMP echo request is sent every 1second.
Since the ICMP echo reply is received, the heartbeatState of the nextHop is declared up.
If no ICMP response has been received for heartbeatDeadInterval seconds (range: [3, 60 seconds], the
heartbeatState of the nextHop is declared down. As a result, the heartbeat failure time detection is at least
3 seconds since the ICMP echo is sent.
- When no ICMP echo reply for a nextHop used by an unprotected staticRoute, the nextHop is
still considered reachable, but is less preferred over an alternate next hop with a valid
heartbeat.
- When no ICMP echo reply for a nextHop used by a protected staticRoute (PDR Route), the
nextHop is considered unreachable. The traffic destinated to the failed nextHop is diverted to
another nextHop used by the protected static route.
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
07.02 / EN
Standard
29/06/2009
Page 173/263
RNC NH
IP router
ICMP EchoRequest
ICMP EchoReply
Periodicity = 1 s
ICMP EchoRequest
ICMP EchoReply
Periodicity = 1 s
ICMP EchoRequest
ICMP EchoRequest
ICMP EchoRequest
ICMP EchoRequest
deadInterval = 3 s
NH down
ICMP EchoRequest
ICMP EchoReply
NH up
TEG
The ICMP Heartbeat allows the RNC to be aware about a failure occurring on a not-directly-connectedto-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: The preferred PDR nextHop is the one with up heartbeat state, the lowest metric assigned.
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.7.8
QOS
Reference: [R160]
The differentiedServices Qos model applies into the UTRAN network.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 174/263
3.7.8.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.
The UMTS qos information are mapped to the Transport Qos information through the configurable
TransportMap RNC component.
3.7.8.2 DSCP VALUES

The selection of the valid DSCP values may be done at the VR level or at the Lan level through
DifferentiatedServicesDomain (dsd) component. It must be configured at VR level.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 175/263
Rule: IubTEG_Hybrid-RNC_Qos_7
Whatever IP over atm or IP over Ethernet UTRAN interface, the differentiatedServicesDomain
must be configured at VR level.
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
CS7, CS6, CS5, CS1, EF, AF1y, DE
wirelessUmts
CS7, CS6, CS1, EF, AF3y, AF2y, DE
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 enable 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
One DifferentiatedServicesDomain instance must be configured to allow a flexible tagging.
The suggested DSD instance: assuredForwarding.
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.7.1.1.4.
3.7.9
TRANSPORTMAP
The TransportMap realizes Classification for atm and ip interfaces and moreover Marking for the ip
interface:
- Classification:
- Up to 4 UMTS streams are identified 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 umts stream.
- Marking:
- A DSCP value is assigned per Umts stream identified by the Umts qos information:
trafficClass, RbSetQos, ARP-PL, THP.
Remark: The transportMap is the way to configure the Umts to Transport qos mapping table within the
RNC.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 176/263
The transportMap components apply to all the utran interfaces, with exception of the IuPS.
Several transportMap tables may be configured within the RNC.
Rule: IubTEG_Hybrid-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_Hybrid-RNC_ TMap _2
Each bwPool or aal2If (if no declared bwPool) configured on the Iub, Iur and IuCS interfaces must
be linked to one or several transportMap (s).
A transportMap is configured with the following parameters:
RNCIN
TransportMap i
interfaceType:
Iub, Iur, IuCS, ( not iuPS)
preference:
sharedForAllTrafficTypes, or
primaryForTrafficType(only Iub case).
transportServiceEntry 1:
[TC, RbSetQos, ARP PL, Thp] => (DSCP), qos i
ulDlPreference.
transportServiceEntry n:
[TC, RbSetQos, ARP PL, Thp] => (DSCP), qos i
ulDlPreference.
TEG
Figure 3-82, 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 177/263
The primaryForTrafficType preference can be assigned to both atm bwPool and IP

bwPool.

The interfaceType and Preference are mandatory parameters within the transportMap.
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,
a DSCP value taken into consideration by the marking function if ip
interface.
INPUT values
TC
rbSetQos
ARP-PL
THP
OUTPUT Values
UlDlPreference
DSCP
Qos i

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.6.10.3).
The ulDlPreference is supported only to the Iub, for both the atm and the ip interfaces.
Remark: one or several transportServiceEntry instances are configured under one transportMap
instance.
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 UMTS traffic qos requirement is compared to the combination of the transportServiceEntry and
ulDlPreference by the transport admissionControl for selecting 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
07.02 / EN
Standard
29/06/2009
Page 178/263
RNCIN
RNCIN
IubIf
aal2If i
TransportMap 1
interfaceType: Iub/IuCS, Iur
BwPool/x
qos/i Paths
Preference: sharedForAllTrafficTypes
qos/j, Paths
TransportMap 2
interfaceType: Iub
ipIf i
Preference: primaryForTrafficType
BwPool/x
ipFlow/i
IucsIf
Congestionmanagement i
aal2If i
qos/i, path/m
IurIf
Congestionmanagement j
aal2If i
qos/i, paths
qos/j, paths
TEG
Figure 3-83, transportMap exemple
On the RNC IP interface, the transportMap/2 table applies per default (3.6.9)
3.7.10 TRANSPORT ADMISSION CONTROL

See 3.6.10
3.7.10.1
EQUIVALENTBITRATE
See 3.6.10.1
3.7.10.2
INTERFACE BANDWIDTH
On the atm interface, the admissionControl determines the aal2path bandwidth for each direction based
on the configured UL and DL vcc trafficDescriptor and the generic CAC 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 determines the ipFlow bandwidth based on the configured UL
and DL ipFlow peak and committed rates and the generic CAC algorithm:
ERgcac = 2*PR*CR/(PR+CR) kb/s
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 179/263
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
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-84, 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_Hybrid-RNC_AC_3
It is recommended to regulate the traffic at aal2 or ip interface bandwidth (cacm= aal2if or ipIf).
Cacm=Qos is reserved for specific contexts of interworking with some otherVendor nodes.
Remark: 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
E.g.: 2 bwPools under one aal2If then:
bwPool1 DL availableBandwidth = bwPool1 vcc DL ECRgcac,
bwPool2 DL availableBandwidth = bwPool2 vcc DL ECRgcac.

Remark: If one single bwPool under the aal2If, then cacm=aal2If availableBandwidth has same
definition as in previous releases.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 180/263
- Cacm = ipIf: The availableBandwidth taken into consideration by the admissionControl is the
E.g.: 1 bwPools under one ipIf then:
bwPool UL availableBandwidth = bwPool UL ipFlow ER,
bwPool DL availableBandwidth = bwPool DL ipFlow ER.
- 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 whatever atm or ip interface.
Furthermore when setting the qosnBwReservation with non zero value, the admissionControl takes
into consideration a additional bandwidth portion available for all the qos.
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 parameter value is taken into consideration by the admissionControl on both
downLink and upLink.
The qosnBwReservation is applicable only if cacm=qos.
The qosnBwReservation parameters are either configured against the bwPool component or against
the aal2If then apply to all the bwPool under the aal2If.
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:
bwPool UL qos i availableBw = qosnBwReservation * bwPool qos i vcc UL ECRgcac,
bwPool DL qos i availableBw = qosnBwReservation *bwPool qos i vcc DL ECRgcac.

bwPool UL common qos availableBw = qosi (100%-qosnBwReservation) * bwPool qos i

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

vcc DL ECRgcac, with i = [0, 1, 2, 3].
Case of ip interface, the availableBandwidth is the sum of the bandwidth of all the ipFlow for one qos
within a bwPool, assuming one bwPool under an ipIf and one ipFlow under the bwPool then:
bwPool UL qos i availableBw = qosnBwReservation * bwPool qos i ipFlow UL ECRgcac,
bwPool DL qos i availableBw = qosnBwReservation *bwPool qos i ipFlow DL ECRgcac.

bwPool UL common qos availableBw = qosi (100%-qosnBwReservation) * bwPool qos i

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

ipFlow DL ECRgcac, with i = [0, 1, 2, 3].
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 181/263
bwPool x
aal2If i
Cacm = qos
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
qos3 = 10000 kb/s
Figure 3-85, cacm=qos for hybrid Rnc
In such a way qos3BwReservation > 0% is effective then:
- a non nul bandwidth must be assigned to the qos3 vcc, therefore the ubr serviceCategory must
not be assigned to the qos3 vcc,
- a non nul bandwidth must be assigned to the qos3 ipFlow.
3.7.10.3
ALGORITHM
See 3.6.10.3
3.7.10.4
TRAFFICMEASUREMENT
NT_UL_Watermark_EBR_Aal2If
- Type: cumulative,
- Granularity: qos,
- Definition:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 182/263
NT_UL_WaterMark_EBR_IpIf
- Type: cumulative,
- Granularity: qos,
- Definition:
NT_DL_Watermark_EBR_Aal2If
- Type: cumulative,
- Granularity: qos,
- Definition:
NT_DL_WaterMark_EBR_IpIf
- Type: cumulative,
- Granularity: qos,
- Definition:
3.7.11 CONGESTIONMANAGEMENT BANDWIDTH LIMITATION

A.K.A RATE CONTROL
Reference: [R160]
The congestionManagement mechanism consists in discarding excess traffic for a given qos, moreover
the mechanism anticipates congestion state by interrupting momentarily the transmission.
The traffic is regulated at bandwidthPool level.
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_Hybrid-RNC_CM_1
If regulation is required, it is recommended to activate both together qosDiscard and
BackPressure.
For both algorithms and per qos, the RNC measures the per qos realTime traffic and determines
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],
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 183/263
3.7.11.1
qosBP(n), for the backPressure thresholds, with n=[0, 1, 2, 3].
CONGESTIONMANAGEMENT TABLE:
The congestionManagement parameters involved in the qosDiscard and backPressure thresholds setting,
are configured through the RncIn/CongestionManagement tables.
The RNC supports up to 64 congestionManagement tables.
Each aal2If/BwPool or aal2If is linked to a CongestionManagement table.

Each ipIf/bwPool is linked to a CongestionManagement table.
Remark: The ipIf component can not be linked to a congestionManagement table.
Each aal2Path must be linked to an appropriated congestionManagement table either through the
aal2If or aal2If/bwPool component it belongs to.
Each ipFlow must be linked to an appropriated congestionManagement instance through the
ipIf/bwPool component.
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 parameters involved in the qosDiscard threshold determination,
- The per qos parameters involved in the backPressure threshold determination.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 184/263
RNCIN
RNCIN
aal2If i
CongestionManagement i
BwPool/x
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-86, congestionManagement links
3.7.11.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:
o New formula for Txoff,
o New formulas for qosDiscard and qosBackPressure thresholds,
o The congestionFlag is inserted in the Xoff signal, always set to No.
Remarks:
o Supports up to 3 qos, No support of Hspa streaming,
o 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:

o Support up to 4 qos,
o Support of Hspa streaming,
o The CM algorithm specified in [R160] introduces:
The Xon signal,
The congestionFlag set either to yes or no is inserted within the Xoff
signal,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 185/263

The GBR for streaming,

The minBrForHspa and minBrForR99 for interactive and backGround,
Suggested minBr values:
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-27, suggested minBr vaues
The qosnBwReservation is taken into consideration,
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.7.11.3
QOSDT AND QOSBP PARAMETERS
Since up to 4 qos are supported, up to four qosDiscard thresholds and 4 qosBackPressure thresholds are
set then one qosDt parameter is set per qos and one qosBP parameter is set per qos.
qosDt(0) qosDt(1) qosDt(2) qosDt(3)
A qosBP(n)=0 means that the backPressure doesnt apply for the qos n.
For the case of no hspa streaming supported, two sets of qosDiscardThreshold values are suggested which
satisfy two different Iub contexts:
- The context basicVPT trafficShaping on the Iub interface.
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
acts as a VP switch (not VC switch) and the trafficShaping at VP level is activated in
For these 3 Iub configurations, apply on the RNC the congestionManagement Discard Threshold
set of values case of basicVPT trafficShaping on the Iub interface.
- Context No basicVPT trafficShaping on the Iub interface:
o 1/ the trafficShaping is not activated neither in the RNC nor in the POC,
acts as a VC switch (not VP switch) and the trafficShaping at VP level is activated in
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 186/263
For these two Iub configurations, apply on the RNC the congestionManagement Discard
Threshold set of values case of No basicVPT trafficShaping on the Iub interface.
Case of No basicVPT trafficShaping on the Iub interface: qosDt 0 0 1 0 2 350 3 500
qosDt 0 0 1 0 2 300 3 500
Case of No basicVPT trafficShaping on the Iub interface:
3.7.11.4
qosBPt 0 0 1 0 2 95 3 95
qosBPt 0 0 1 0 2 33 3 35
COUNTERS:
Two kinds of real time counters are implemented which measure the trafficVolume per 10 ms period:
- The per qos real time counters: Q010ms, Q110ms, Q210ms and Q310ms,
- The per cumulative qos counters: Qxxx, in extenso: Q0, Q01, Q012 and Q0123.
The four per qos counters provide per qos the trafficVolume over a 10 ms period:
Qn10 ms Counters
Qos
Q010 ms
Qos0
Q110 ms
Qos1
Q210 ms
Qos2
Q310 ms
Qos3
Table 3-28, per qos counters
Further the RNC estimates the per qos expected trafficVolume over the next 10 ms period, based on the
per qos measured trafficVolume over the previous 10 ms periods. For that the RNC set the Qne
(estimated) counters:
Qne Counter
definition
Q0e
Q1e
Q2e
Q3e

Table 3-29, qosn estimated counters
The four per cumulative qos counters Qxxx provide the trafficVolume over a 10 ms period for qos0,
qos0+qos1, qos0+qos1+qos2, qos0+qos1+qos2+qos3:
Qxxx Counters
definition
Q0
Q01
Q0+ Q1
(qos0 + qos1 traffic)
Q012
Q01 + Q2
(qos0 + qos1+ qos2 traffic)
Q0123
Q012 + Q3
(qos0 + qos1 + qos2 + qos3 traffic)
Table 3-30, Qxxx per cumulative qos counters
The counter unit is either cell/10ms for the atm interface or bytes/10ms for the ip interface.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 187/263
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.7.11.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.
The qosnBwReservation parameters are involved in the Transport admissionControl.
The qosnBwReservation parameters are also 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.7.11.5.1 CASE OF QOSNBWRESERVATION= 0%:

The qosnBwReservation parameter values dont influence the thresholds determination.
QosDiscardThresholds, UA6 and UA5 equivalent behaviours:
One discard threshold is set per qos. 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.
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-31, qosDiscardThresholds
The ECR is the result of the GCAC algorithm.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 188/263
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:
The BP thresholds are recalculated each 50 ms.

When qosBPTn = 0, no backpressure mechanism is applicable.
3.7.11.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,
- A bandwidth portion shared between all the different qos.
Atm Bw available and Atm bw exclusively reserved per qos
Bw0avail

Bw1avail

Bw2avail

Bw3avail
Table 3-33, bwxavail & bwxexclus on atm interface
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 189/263
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-34, bwxavail & bwxexclus on ip interface
Per period of 10 ms, an estimation of the per qos 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-35, 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.
3.7.12 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.7.13 NODEB DISCRIMINATION

See 3.6.13.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 190/263
3.7.14 UTRAN SHARING

The utranSharing issupported on the atm and ip interfaces.
See 3.6.15.
3.8
NODE B (IBTS)
The oneBTS is the ex Nortel nodeB.
3.8.1
CARDS
Two kinds of nodeB card: the CEM and the CCM impact the NodeB Transport part.
3.8.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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 191/263
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:
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
07.02 / EN
Standard
29/06/2009
Page 192/263
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-87 i CEM BBU roles
3.8.1.2 CCM:
For Card hardware aspects see [R100]
In NodeB, CCM is in charge of OAM management, part of call processing and internal/external data flow
switching/combining.
Inside CCM, The BRIC (BTS Router Interface Controller) provides the main processing and control for
the NodeB.
The BRIC operates internally at atm level (aal2 for UMTS traffic, aal5 for UMTS Signaling and OAM)
and supports atm aal2/aal5 backhaul to the RNC for UMTS operation.
The CCM terminates the aal5 CP Vcc and manages the associated SSCOP connections.
This CCM provides E1/T1 interfaces to the network. The CCM supports up to 8E1/T1 and one single
IMA linkGroup.
Different CCM card characteristics:
- The initial CCM does not support simultaneously IMA and xPcm.
- The CCM types: iCCM and iCCM2 supports simultaneously: IMA and xPcm.
Ethernet accesses are not supported when the nodeB is populated with the iCCM.
- The xCCM supports two IMA linkGroups and two FastEthernet accesses.
The xCCM provides a 100Mbps Ethernet port, anyway the ThroughPut is
limited to 30 Mbps in DL and 15Mbps in UL.
3.8.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,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 193/263
3.8.3
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.
ETHERNET LAYER:
The nodeB populated with xCCM supports up to 8 E1/T1 and two FastEthernet links.
The nodeB populated with xCCM supports 2 fast ethernet accesses on copper.
One FE link is used for UMTS traffic, the second is used either for siteLan or for localMaintenance.
Per definition: the FE throughput is 100 Mb/s
Ethernet frames:
The NodeB supports:
- 802.3 MAC Frame
The NodeB doesnt support:
- 802.3 Q-Tagged MAC Frame
- Ethernet version2 MAC Frame (the RNC sends only EthV2 frames)
Q-Tag: the nodeB does not support Vlan.
P-Tag: 802.1P is not supported. If received, it is ignored.
The auto-negociation is not supported.
3.8.4
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.
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.8.5
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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 194/263
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.8.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.8.6
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.
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 195/263
- 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.8.7
PCM6
1 hspa vcc
IMA
The IMA linkGroup configured on the nodeB is either shared by the Release99 and Hspa traffic or
dedicated the Hspa traffic.
3.8.7.1 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.
- One IMA linkGroup may be configured, IMA ID = 0,
- 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.8.7.2 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 196/263
Application to the UMTS:

All the aal5 vcc are set with HP=0.
All the aal2 vcc are set with an HoldingPriority in the range [1, 16], then these aal2 vcc are candidate to
release in case of link failure.
- 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 197/263
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.
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.8.8
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 198/263
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:
- 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.8.6.
3.8.9
IP
IP version:
- IPv4 supported. IP v6 not supported.
IP routing:
- IP routing protocols are not supported; static routing applies.
IP@:
The NodeB is configured with two external IP@:
- 1 external IP@ for the userPlane with its associated subnetMask and one single associated
nextHop IP @,
- 1 external IP@ for the OAM.
The NodeB doesnt support DHCP then the NodeB IP@ must be manually configured (can not
automatically be set by a DHCP Server).
The NodeB-UserPlane-IP@ is exchanged, call by call, with the RNC during the NBAP Radio Link
setup procedure.
NodeB IP@ parameters:
The nodeB addressing parameters (if no DHCP):
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 199/263
- BTSipRanNodeBAddress,
- BTSipRanNodeBsubnetMask,
- IP@nextHopGateway.
3.8.10 QOS
3.8.10.1
IP QOS
The nodeB supports the differentiatedService model.

The NBAP/TNL/QoS IE contains the DSCP value to be used for each particular MAC-D flow.
HSPA I/B traffic over IP

RNC
Node B
NBAP RL setup/add/reconf request
- TLA IE: RNC IP @ in NSAP format
- Binding IE: RNC UDP port
- TNL QoS: DSCP
NBAP CTCH/RL setup/add response
- TLA IE: Node B IP @ in NSAP format
- Binding Id: contains Node B UDP port
TEG
The NodeB rejects the NBAP RL Setup with an unrecognized DSCP value.
3.8.10.2
ATM 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 200/263
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:
When no hspa Streaming traffic:
VCC
suggested SC
in the network
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:

VCC
suggested SC
in the network
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,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 201/263
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
qos3 vcc
Ubr
Ubr3
CP
rtVBR
rtVbr
CCP
rtVBR
rtVbr
Alcap
rtVbr
rtVbr
OAM
UBR+
UBRPlus
3.8.11 TRAFFIC MANAGEMENT

In nodeB only one trafficDescriptor is set per vcc. It applies either to uplink and to downlink direction.
3.8.11.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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 202/263
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-37 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.:
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.8.11.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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 203/263
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.8.12 HSPA CAC

Hs-dsch leg regulation:
The NodeB Hsdpa CAC regulates amount of hs-dsch legs per H-BBU.
The maximum amount of hs-dsch legs per H-BBU is configurable:
Parameter: hsdpaMaxNumberUserHbbu
Parameter range: [0, 65535],
UA5-0:
-
hsdpaMaxNumberUserHbbu = 48 hs-dsch legs per H-BBU

UA5-0: up to 6 H-BBU per nodeB.
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.8.13 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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 204/263
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.9
NODEB (ONEBTS)
3.9.1
ALCAP
Alcap Cell Validity Timer:
The NodeB (oneBTS) doesnt support the Alcap Cell Validity Timer.
3.10
MICRO NODEB ATM (BTS 1120)
3.10.1 TRANSMISSION:
The NodeB atm supports the following kind of transmission links:
- Supports: E1, T1, J1,
- 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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 205/263
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.10.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,
- 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,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 206/263
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.
- 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:
VBR Vcc SCR linkRate,

per link, CBR Vcc PCR linkRate,
per link,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 207/263
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,
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.
3.10.3 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.
3.10.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

ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 208/263
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.10.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:
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@:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 209/263
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.10.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:
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 210/263
3.11
PICO NODEB ATM (BTS 1010)
3.11.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:
Fractional E1.
3.11.2 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,
- 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.8.7.2.
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].
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 211/263
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.11.3 AAL2:
Aal2 Qos: Yes
Aal2 Signaling:
- Supports ALCAP according to R[46].
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.11.4 IP:
-
IP v4 is supported, not IPv6,

The subnet size is configurable,
IP over atm encapsulation type: LLC encapsulation.
InverseARP is not supported.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 212/263
3.11.5 UMTS TRAFFIC FLOWS:

The picoNodeB supports R99, hsdpa and Hsupa user traffic flows.
3.12
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.
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
07.02 / EN
Standard
29/06/2009
Page 213/263
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
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
IMA:
OAM:
F4/F5
Aal2:
encoding:
Ethernet:
Vlan:
P-Tagging
Eth over atm:
LAG:
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:
3.13
supported
UMTS PLANE DESCRIPTION

The Iub interface uses the services of either atm Transport or a mix of atm and ip.
The Iub interface can not use the sevices from only ip Transport.
3.13.1 HSUPA PLANE

The Hsupa combined with Hsdpa dynamically adapts and maximizes the subscriber peak data rate traffic
according to the radio interface load and the Iub interface availability.
The Hsupa traffic is carried over an uplink RNL channel called: E-DCH.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 214/263
The Hsdpa traffic is carried over a downlink RNL channel called: HS-DSCH.
The eDCH uplink channel is always associated to a HS-DSCH downlink channel, not to a DCH, whereas
a HS-DSCH is associated to either a DCH or E-DCH.
The introduction of hsupa feature consists in NodeB and RNC software upgrade.
On the Iub interface, the UMTS hsupa traffic uses the services from the atm/aal2.
The PS Streaming, Interactive and Background trafficClass may use Hsupa services. The Conversational
trafficClass traffic remains assigned to DCH.
Any PS RAB request with Streaming, Interactive or Background trafficClass is matched to the E-DCH
Radio Bearer if the mobile is E-DCH capable and the primary cell of the active set supports E-DCH. If it
is not the case, the request is mapped on DCH as usual.
Rule: IubTEG_Hsupa_
When adding the HSPA Streaming on the Iub, The rncIn enhancedQos parameter must be set to
enable.
The dedicatedSRB associated to hsupa session is carried over the UP DS Vcc.
3.13.1.1
AAL2:
Each hsupa leg is carried over one aal2 dedicated connection identified by one CID. One different aal2
connection is seized for the associated hsdpa leg. As a consequence 2 CID are seized for one hsupa/hsdpa
user session.
One more aal2 Cid is seized on the aal2Qos0 path for the hspa dedicated SRB.
The CID from one aal2 path may be seized either by hsupa leg and hsdpa leg. The aal2 paths configured
for the hsupa and hsdpa are called Hspa Paths.
The streaming hspa paths are assigned to qos1 vcc within a sharedForAllTrafficTypes bwPool.
The Interactive/background hspa paths are either assigned to qos3 vcc within a sharedForAllTrafficTypes
bwPool or either to qos3, qos2, qos1 or qos0 vcc within a primaryForTrafficType bwPool.
CID
Path /qos0 vcc
CID
CID
CID
CID
Hsupa Streaming TRB

Hsdpa Streaming TRB
R99 Streaming TRB
Hsupa I/B TRB

Hsdpa I/B TRB
Hsdpa flowControl
RNC
NodeB
CID
CID
CID
CID
Path /qos3 vcc
dSRB
AMR TRB
CID
Path /qos1 vcc
Hsdpa & Hsupa dSRB

sharedForAllTrafficTypes bwPool
CID
CID
Figure 3-88 HSPA aal2 Connections
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 215/263
3.13.1.2
ATM:
3.13.1.2.1 ATM QOS:

Lets call Hspa traffic, the combination of both Hsdpa and Hsupa traffic.
Each Hspa I/B aal2 Path is associated to one qos3 vcc within a sharedForAllTrafficTypes bwPool.
Within a primaryForTrafficType bwPool, each Hspa I/B aal2 Path is associated to either one qos3 vcc or
to different qosx vcc (qos3 vcc, qos2 vcc, qos1 and qos0 vcc).
The Hspa Streaming traffic together with the R99 Streaming traffic is handling over the qos1 vcc within a
3.13.1.2.2 ATM #VCC:

The maximum amount of Hspa I/B vcc to configure per Iub interface is determined taking into account
the NodeB and the RNC limitations:
- Amount of CEM per nodeB handling Hspa traffic,
- NodeB different kind of CEM traffic capacity, see 3.8.1.1,
- RNC Hsdpa CAC, see 3.6.12.
Rule: IubTEG_Hsupa
Up to two Hspa I/B qos3 vcc are configured per sharedForAllTrafficTypes bwPool.
Up to 4 Streaming qos1 vcc are configured per sharedForAllTrafficTypes bwPool.
Up to 16 Hspa I/B qosx vcc are configured per primaryForTrafficType bwPool.
3.13.2 HSDPA PLANE

The UMTS Hsdpa traffic flow used the services from the atm/aal2.
The Hsdpa traffic is carried over a downlink RNL channel called: HS-DSCH. The HS-DSCH UMTS leg
is either combined with a DCH leg or a E-DCH leg.
The PS Streaming, Interactive and Background trafficClass may use Hsdpa services. The Conversational
trafficClass traffic remains assigned to DCH.
Rule: IubTEG_Hsupa
When adding the HSPA Streaming on the Iub, The rncIn enhancedQos parameter must be set
to enable.
3.13.2.1
ATM REQUIRED SERVICES:
The Hsdpa traffic is downLink direction traffic.

Its traffic characteristics are: large burst and high volume of traffic.
Eg: Hsdpa frame 1500 bytes length split in 34 transportBlocks transmitted within a period TTI=10 ms.
The HSDPA I/B traffic is less urgent than the already existing Release99 traffic.
To avoid traffic starvation and supplementary delay in downLink on others umts flows, the Hsdpa I/B
traffic is carried over a dedicated vcc:
- qos3 vcc within a sharedForAllTrafficTypes bwPool,
- qos3, qos2, qos1 and/or qos0 vcc within a primaryForTrafficType bwPool.
The Hspa Streaming traffic together with the R99 Streaming traffic is handling over the qos1 vcc within a
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 216/263
The hspa traffic is handle on the Iub interface whatever IMA or multiPcm on the nodeB side.
3.13.2.1.1 HSPA ATM VCC QOS AND TM:

On RNC side, within a sharedForAllTrafficTypes, no bandwidth is reserved for the qos3 vcc, the lowest
priority is assigned to the qos3 vcc:
Rule: IubTEG_Hsdpa
Within a sharedForAllTrafficTypes:
Qos3 vcc UBR, EP7, tdt=1, tdp=0 0 0 0 0
Remark: The oam vcc and the qos3 vcc are configured under the EP7, providing them the same QOS
treatment. A distinct Qos treatment may be applied to both kind of vcc by setting differently their
associated parameter: ATTRIBUTE AtmIf Vcc Vcd Tm weight.
In the case the RNC 16pOC3/Stm1 FP configured with ShapedVPT and the VP formation includes the
the oam and the qos3 Vcc, since both vcc are configured with the same serviceCategory that implies
both vcc queues belong to the same EmissionPriority pool of queues, in such a way the connection
Scheduler considers with more Importance the hsdpa flow than the oam flow, the Hsdpa and oam
associated perVC queue weight would be set as following:
Rule: IubTEG_Hsdpa
Hspa vcc queue weight = 40,
OAM vcc queue weight = 2.
On the nodeB side, the qos3 vcc is set with UBR serviceCategory, PriorityLevel=3 (since no uplink user
traffic, only Hsdpa flowControl, then the lowest priority is enough). See 3/NodeB/Qos.
CID
Path /qos0 vcc
CID
CID
CID
CID
Hsupa Streaming TRB

Hsdpa Streaming TRB
R99 Streaming TRB
Hsupa I/B TRB

Hsdpa I/B TRB
Hsdpa flowControl
RNC
NodeB
CID
CID
CID
CID
Path /qos3 vcc
dSRB
AMR TRB
CID
Path /qos1 vcc
Hsdpa & Hsupa dSRB

sharedForAllTrafficTypes bwPool
CID
CID
Figure 3-89 Atm Vcc involved in Hsdpa
3.13.2.1.2 HSPA VCC ON IMA:

In such a way the qos3 vcc within a shareForAllTrafficType bwPool is not released by the nodeB in case
of IMA bandwidth reduction:
Rule: IubTEG_Hsdpa_
On the nodeB side the HoldingPriority = 0 is assigned to the qos3 vcc within a
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 217/263
shareForAllTrafficType bwPool.
Whereas if the Hspa traffic is transmitted over a primaryForTrafficType bwPool and IMA, different HP
values are set against the different qosx vcc (see5).
3.13.2.2
AAL2 REQUIRED SERVICES:
HSDPA I/B aal2 CID requirements:

- 1 CID from the qos0 path is seized for hsdpa dedicatedSRB,
- 1 CID from the sharedForAllTrafficTypes qos3 path is seized for HSDPA DL TRB and
flowControl or one CID from one primaryForTrafficType qosx path.
- 1 CID from the qos2 path is seized for the uplink DCH leg or one CID from the qos3 path is
seized for E-Dch uplink leg associated to the HS-Dsch leg,
-
3.13.2.3
TRAFFIC REGULATION:
Not Reviewed:
3.13.2.3.1 RNC HSDPA CAC:

The RNC checks amount of Hsdpa simultaneous legs per NodeB CEM, to limit Qos degradation and
UTRAN memory resource usage.
Any Interactive/background RAB request is admitted on Hsdpa until the maximum number of
simultaneous users per nodeB cell allowed on Hsdpa is not reached.
In case the Hsdpa CAC rejects the call, the Hsdpa leg falls back to a DCH (FRS32602).
See the Hsdpa CAC 3.6.12.
3.13.2.3.2 HSDPA RNC AAL2LINK CAC:

Once the HSDPA CAC has been invoked, the RNC performs the admission on the associated DCHs
thanks to aal2LinkCac:
- DL SRB admission, aal2LinkCAC is performed as usual,
- UL TRB admission, aal2LinkCAC is performed as usual.
- DL TRB admission based on the Hsdpa DL EBR.
The Hsdpa DL EBR=0 to cancel the DL regulation [according to R233].
3.13.2.3.3 RNC IUB AAL2 CONGESTION MANAGEMENT:

The aal2 congestion management mechanisms, implemented in the RNC, consists in discarding excess
aal2 traffic for a given aal2 qos in case of congestion. Moreover the mechanism anticipates congestion
case by interrupting momentarily transmission. This algorithm is described in 3.6.7.
3.13.3 OAM PLANE

The NodeB Umts OAM traffic is composed of:
- Configuration data,
- Software download,
- Performance management and
- Fault management
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 218/263
The Umts OAM traffic exchanged between the NodeB and the RNC is encapsulated in TCP/IP packets.
The IP packets are carried within the Umts OAM vcc.
Rule: IubTEG_OAM_01
On the Iub interface, the UMTS OAM traffic must be transmitted over the atm interface. It is not
supported over the ip interface.
3.13.3.1
ATM:
One OAM vcc is configured per nodeB.

Within the RNC, the OAM IP traffic flows from the different nodeB, from the RNC and as an option
from the backbone atmSwitches may be transmitted to the OMC on two different ways: InBand or
OutBand OAM.
Rule: IubTEG_OAM_02
On the RNC / OMC interface, the UMTS OAM traffic is either transmitted inBand on the Iub atm
Interface or outBand via the RNC CP ethernet interface.
-
InBand OAM:
On the RNC Iub interface are configured as many Iub oam vcc as amount of connected nodeB.
Moreover may be configured as an option additional oam vcc related to backbone atmSwitches.
The OAM InBand solution consists within the RNC, in aggregating:
- the different nodeB umts OAM flows,
- the RNC own OAM flow and
- as an option the backbone atmSwitch OAM flow(s)
into one OAM vcc, configured on one atm transmission link also used by the UMTS traffic vcc.
The OAM vcc carried aggregated oam traffic destinated to the OMC. It may be switched within an
atmBackbone and as an option within umts coreNetwork nodes.
The aggregation operation is done by the RNC VR 0.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 219/263
RNC
RNC
IP@: 10.9.1.1
NodeB 11
NodeB
Subnet@: 10.9.1.0
PMC-OMU
PMC-OMU
SubnetMask: /24
CP
CP
CP
CP
PMC-OMU
PMC-OMU
Vcc 1.32
Ethernet
IP@: 10.9.0.3
LM
LM
E1
Subnet@: 10.9.0.1
PP3
IP@: 10.9.1.2
SubnetMask: /24
Vcc 1.32
E1
PP6
Subnet@: 10.9.1.0
SubnetMask: /30
MPE/1000
MPE/1001
AC3
AC3
E1
atmIf /801
STM1
MPE/1002
AC1
AC1
OAM vcc
(POC oam vcc)
AC1
AC1
POC oam vcc
Nb3 oam vcc
Nb2 oam vcc
nodeB oam vcc
Nb1 oam vcc
NodeB 150
150
NodeB
Iub
Vcc 1.32
PP1
SubnetMask: /24
IP@: 10.9.1.150
SubnetMask: /24
IP@: 10.9.0.10
PP7
Subnet@: 10.9.0.8
AC1
AC1 AC2
AC2
Subnet@: 10.9.1.0
SubnetMask: /29
VR
VR 00
IP@: 10.9.1.254
ATM Switch
NodeB 22
NodeB
Subnet@: 10.9.1.0
PP2
Iu
OAM vcc
CP & UP vcc
atmIf /815
STM1
TEG
Figure 3-90 inBand OAM
Remark: The IP addresses are given as an example.
OutBand OAM:
Within the RNC, the aggregated OAM flows destinated to the OMC, are transmitted over the
ethernet links present on the RNC CP card.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 220/263
RNC
RNC
IP@: 10.9.1.1
Vcc 1.32
LM
LM
E1
PP3
IP@: 10.9.1.2
SubnetMask: /24
Vcc 1.32
E1
PP6
Subnet@: 10.9.1.0
PP7
SubnetMask: /24
MPE/1000
AC1
AC1 AC2
AC2
(POC oam vcc)

E1
MPE/1001
AC1
AC1
POC oam vcc
nodeB oam vcc
AC3
AC3
Nb3 oam vcc
SubnetMask: /24
Nb2 oam vcc
NodeB 150
150
NodeB
Iub
Subnet@: 10.9.1.0
Nb1 oam vcc
IP@: 10.9.1.150
Vcc 1.32
PP2
VR
VR 00
IP@: 10.9.1.254
ATM Switch
NodeB 22
NodeB
Subnet@: 10.9.1.0
OMC
OMC
CP
CP
CP
CP
PMC-OMU
PMC-OMU
BackBone
BackBone
PMC-OMU
PMC-OMU
SubnetMask: /24
Hub
Hub
NodeB 11
NodeB
Subnet@: 10.9.1.0
atmIf /801
STM1
TEG
Figure 3-91 outBand OAM
Remark: The IP addresses are given as an example.
TrafficManagement: the OAM vcc carrying the aggregated OAM flows should be configured with UBR
ServiceCategory.
3.13.3.2
IP:
The Iub oam vcc and the aggregated oam vcc carry IP based OAM traffic between the NodeB and RNC
and between the RNC and the OMC. The oam IP packets are routed within the RNC to the OMC.
3.13.3.2.1 MPE
The RNC may be connected to up to 2400 nodeB.
The RNC atmMpe supports up to 255 atmConnections.
Therefore to address the maximum amount of nodeB, are required:
- up to 10 atmMPE,
- 10 PP under the Iub OAM VR0 with /24 subnet size.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 221/263
OMU0
OMU0
OAM
OAM plateform
plateform
OMU1
OMU1
eth
eth
IP
IP
oam
LM
LM
If/2
CP
CP
127.255.0.0 /24
movable
PP
PP
VR0
Iub oam
PP
Iub oam
PP
Iub oam
PP
MPE 10
MPE 11
MPE 19
16pOC3
16pOC3
TEG
Figure 3-92 RNC OAM
Note: The atmMpe instance number are given in the Figure as an example.
Rule: IubTEG_OAM_03
10 atmMpe components must be configured for the Iub OAM traffic when up to 2400 nodeB
connected to the RNC.
3.13.3.2.2 ADDRESSING:
See [R80]
One dedicated to oam IP@ is assigned to the NodeB either on a static or dynamic way by means of
DHCP. This IP@ may be either a Private or a Public IP@. It is involved in the dialogue between the
NodeB and the remote OMC or a remote TIL.
Moreover, one local IP address is configured on NodeB Ethernet port, involved in local communication
between TIL and NodeB.
If public IP backbone is crossed, the NodeB-OMC IP session is managed through a VPN access.
If Static allocation applies, one oam IP@ is configured against each nodeB. On the RNC side either the
mapping between NodeB IP@ and NodeB oam vcc is configured or since the inverseARP is enable the
ARP table is automatically updated.
The Dynamic allocation implies that the DHCP is supported by the network.
The DHCP is composed of three functions:
- DHCP Client: located in the nodeB,
- DHCP Relay Agent: the DHCP routing function inserted in an UMTS node, and
- DHCP Server: located in the OMC.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 222/263
The DHCP server provides the nodeB with:

- The dynamic IP@,
- List of OMC IP@,
- The nodeB subnet mask.
The DHCP dialogue is supported on the IP/ATM protocol stack. The nodeB OAM vcc carries the DHCP
information flow.
DHCP
Port 67
Port 68
UDP
Proto = 17
IP
IP
DHCP
DHCP
Server
Server
AAL5
ATM
DHCP
DHCP
OAM
OAM Server
Server
backbone
backbone
NodeB
DHCP Client
RNC
Iub
OAM Vcc
DHCP
RelayAgent
DHCP
DHCP
Server
Server
X
Iu
DHCP Servers
Atm
Ethernet
TEG
Figure 3-93 DHCP Protocol stack, InBand OAM case
One or several DHCP Servers may be included in the network. They may be located on the OMC.
Rule: IubTEG_OAM_03
The RNC DHCP Relay Agent can forward messages to up to 3 DHCP Servers.
The DHCP which answers first to the nodeB request is selected.
The DHCP Relay Agent must be located in the UMTS node which handles the Aggregation of the nodeB
oam vcc. Indeed the inverseARP has to be executed in the node which manages 1 OAM vcc per nodeB.
Rule: IubTEG_OAM_04
The DHCP Relay Agent must be located in the RNC, since each nodeB oam vcc terminate in the
RNC.
The DHCP is invoked at the nodeB start up phase.
The DHCP dialogue between the NodeB and DHCP server in three phases:
- Broadcast IP dialogue from the NodeB to each DHCP server. One DHCP servers provide
the nodeB with an IP@. The selected DHCP is the first which answers to the nodeB
request.
- Broadcast IP dialogue from the NodeB to each DHCP; the NodeB indicates to all the
DHCP Servers the selected DHCP server. The selected DHCP returns the configuration
parameters.
- The inverse ARP protocol is invoked for configuration parameter check, it results with an
update of the RNC ARP tables (NodeB oam vcc, nodeB IP@).
- Unicast IP dialogue between the NodeB and the selected DHCP server.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 223/263
Since the IP@ ia allocated to the nodeB, the nodeB is ready to receive OAM traffic on the iub oam vcc.
When nodeB reparenting, a new IP@ is allocated to nodeB, if DHCP Servers connected to Source RNC
and target RNC are different.
As long as up to 200 nodeB per RNC, the class C IP@ are enough to identify a nodeB in the RNS.
Rule: IubTEG_OAM_05
NodeB IP@ is a Class C IP address.
Subnet mask: 255.255.255.0
As long as one class C subnet is defined, then up to 255 IP@ are allowed. Among the 255 IP
addresses, 2 are reserved:
- All host bits set to 0 for Subnet IP address,
- All host bits set to 1 for broadcast address.
Therefore 253 IP@ are available to identify the nodeB. It is suggested to assign 200 IP@ from
the class C subnet to the nodeB and keep 53 IP@ available for the case of reparenting.
Rule: IubTEG_OAM_06
Its not mandatory for OMC-B to be in the same subnet as nodeB.
NodeB IP address shall be a private IP address .
DHCP Configuration:
Rule: IubTEG_OAM_07
Range 192.168.0.0 to 192.168.255.0 is reserved for nodeB internal subnet and then shall not
be used by DHCP.
DHCP Relay Agent Configuration:
The DHCP Relay Agent is a routing function implemented in the RNC. The functionality consists in
routing IP packets which contains DHCP information to DHCP Servers.
Rule: IubTEG_OAM_08
The RNC DHCP Relay Agent is provisioned with:
- Its own DHCP Relay Agent IP@, and
- The IP@ of each connected DHCP Server
Remark: the DHCP Relay Agent IP@ and NodeB IP@ may be in different subnet.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 224/263
OAM
OAM Plateform
Plateform
DHCP Clients
Clients
DHCP
DHCP
DHCP
Server
Server
DHCP
DHCP
Server
Server
IP@
IP@
DHCP
DHCP
Server
Server
IP@
Ethernet
Option
Iub
POC
POC
RNC
RNC
PP
atm
atm
AC
Ethernet
OAM vcc
AtmMPE
AC
AtmIf
AC
AtmIf
AC
PP
AtmIf
NodeB 3
E1
AC
PP
AtmMPE
NB3 OAM VCC
AtmIf
NB2 OAM VCC
VR
PP
AtmMPE
NB1 OAM VCC
VCC 0 / 32
atmSwitch
atmSwitch
++ IP
IP Router
Router
VR 0
AtmIf
AtmIf
IP flow
AtmIf
VCC 0 / 32
CP
CP
PP
AtmIf
NodeB 2
IP flow
AtmIf
NodeB 1
VCC 0 / 32
Iu
DHCP
RelayAgent
IP flow
Ethernet
Stm1
Stm1
TEG
Figure 3-94 DHCP Dialogue synoptique
3.13.4 CONTROL PLANE

The UMTS controlPlane uses the services from SaalNNI / aal5 / atm.
The UMTS controlPlane over ip is not supported.
The CP (Control Port) and CCP (Communication Control Port) vcc respectively carry the NBAP-c and
NBAP-d signaling.
Remark:
A SRB is allocated to Non Access Stratum signaling (RRC/CM, SM, MM); SRB is carried on Iub UP
Vcc.
The amount of CP and CCP vcc depends on nodeB configuration:
- The number of CCP vcc depends on the number of CEM (1 CCP per CEM board), up to 6
CEM boards in the NodeB,
- One CP vcc is configured per NodeB, since one CCM card is configured on nodeB.
The CP & CCP vcc originate in the NodeB respectively CCM card and CEM card, and terminate in the
RNC TMU.
One TMU card is able to manage each UTRAN protocols:
- NBAP-c, CP vcc on Iub interface,
- NBAP-d, CCP vcc on Iub interface.
- RANAP CS and PS vcc on Iu interface,
- ALCAP vcc on Iu and Iur interfaces,
- RNSAP vcc on Iur interface,
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 225/263
The RNC TMU cards handle CP and CCP signaling.

All the CP and CCP vcc relatives to one nodeB are allocated to one TMU.
A RNC algorithm is in charge of the assignement of the nodeB vcc to the TMU. The Algorithm is
invoked in the start up phase of the RNC, and when an active TMU fails for selecting a spare TMU.
This algorithm is independent from the RNC algorithm in charge of assigning the UE NonAccessStratum
Signaling (SRB) to the TMU.
Therefore the TMU which relays NAS Signaling relative to an UE may be different from the TMU which
manages ControlPlane traffic (CP and CCP) relative to the nodeB where the UE is connected.
3.13.5 USER PLANE

The UMTS R99 userPlane uses only the services from atm.
The UMTS hspa userPlane uses either the services from atm, from ip or both atm and ip.
3.13.5.1
ATM BASED USERPLANE
The UMTS userPlane uses the servives from aal2 / atm.

The userPlane aal2 paths originate in the nodeB and terminate in the RNC. The userPlane vcc originate in
the nodeB then switched in the atm backbone and terminate in the RNC.
The required amount of Iub UP vcc depends on the nodeB transmission configuration:
- Amount of E1 on the nodeB side and
- Either multiPcm or IMA.
When migrating from UA5 to UA6, and in UA6 as long as the Hspa streaming is not handle over the Iub
interface, three different kinds of Iub userPlane vcc are configured over the Iub interface:
- The qos0 vcc in charge of handling the dedicated and common SRB and the TRB associated to R99
Conversational and Streaming trafficClass (RbSetQos = 0),
- The qos2 vcc in charge of handling the TRB associated to R99 I/B (RbSetQos = 1),
- The qos3 vcc in charge of handling the TRB associated to Hspa I/B (RbSetQos = 2).
When enabling the hspa streaming traffic over the Iub interface, the qos1 vcc is created dedicated to the
Hspa and R99 Streaming traffic.
- The qos0 vcc in charge of handling the dedicated and common SRB and the TRB associated to R99
Conversational,
- The qos1 vcc in charge of handling the R99 and Hspa Streaming traffic,
- The qos2 vcc in charge of handling the TRB associated to R99 interactive and background
(RbSetQos = 1),
- The qos3 vcc in charge of handling the TRB associated to Hspa interactive and background.
The amount of different type of vcc is given in 5.
AAL2 CID usage:
One aal2 CID is seized per:
- TRB,
- DedicatedSRB; on the dedicatedSRB are transmitted NonAccessStratum Signaling: CC,
SM, MM, and GMM signalings,
- Common SRB; one CID for RACH, one CID per FACH and one CID per PCH.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 226/263
Remark: the NAS Signaling carried over the dedicatedSRB is initiated by the UE, goes through
nodeB transparently up to the RNC within Iub qos0 vcc. Within the RNC, the PMC-TMU is in
charge of handling this traffic.
3.13.5.2
IP BASED USERPLANE
Only the UMTS hspa I/B userPlane is allowed to use the services from ip.
The transport bearer is identified by the UDP port numbers and the IP addresses (source UDP port
number, destination UDP port number, source IP address, destination IP address).
The bearer identifiers (UDP port numbers and IP addresses) are exchanged over ATM between RNC and
Node B at each Radio Link Setup via NBAP signaling messages.
3.13.6 ATM BACKBONE REQUIREMENTS

When UTRAN interfaces cross an ATM Backbone, the third party ATM Backbone operator may provide
VP switching services, which implies specific configuration in UMTS nodes:
3.13.6.1
TRAFFICMANAGEMENT
The third party ATM backbone may provide policed accesses which are characterized by pcr, cdvt, scr
and mbs.
Then to avoid cell discard by the atm backbone, the UMTS Nodes should shape the atmConnection to the
atm backbone, in such a way the traffic received in the ATM Backbone is conformed to the expected
traffic (SLA).
The service offers by the atm backbone is either vc or vp Switching.
An atm backbone providing vp switching services is preferred to an atm backbone providing vc switching
services. Indeed when activating Atm trafficRegulation mechanisms, the shaping rate must be determined
based on expected / forecast traffic.
Each vcc traffic source is considered to be erratic; the vp traffic, resulting from different vcc sources, is
expected to be more constant (multiplexing Gain). More vcc are included in the vpc, more constant is
expected to be the vp traffic.
Applying atm traffic Regulation at vp level, is then more economical (Improvement of bandwidth usage),
the shaping rate is determined more easily (expected traffic more constant), moreover the vp atm traffic
regulation has less impact (cell delay and discard) on the traffic than the vc atm traffic regulation.
If the atm backbone provides VP switching services, and policed accesses:
Rule: IubTEG_BB_01
When crossing a policed ATM backbone which provides vp switching services, the vpc are initiated in
the RNC (VPT feature) and trafficShaping is activated at vp level.
The Iub OAM vcc must not be inserted in the vp formation, to avoid QOS disturbance by the OAM
flow.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 227/263
3.13.6.2
OAM FLOW
The OAM vcc is configured with the lowest priority, UBR ServiceCategory.
To avoid traffic starvation, a minimum cell rate is reserved for OAM Vcc within UMTS passport based
Nodes by means of MBG. On NodeB, the parameter MCR is assigned to lowest priority Vcc for
guarantying them a minimum bandwidth (see nodeB/MCR availability in 4) .
In such a way to avoid traffic starvation within the ATM backbone, it is recommended to configure OAM
vcc within the ATM backbone with a minimum bandwidth.
Rule: IubTEG_BB_02
The OAM vcc must be configured with a MCR (MinimumCellRate) within the ATM
backbone.
4 UMTS RELEASES
4.1
RNC
4.1.1
FP
4.1.1.1 RNC-IN, 16POC3/STM1 FP:

- UA6:
The pnni Hairpin removal feature applies.
- UA5-0 16pOC3 MS3 FP:
- The RNC supports the 16pOC3/stm1 MS3 FP.
- UA5-0 16pOC3 FP Attributes:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 228/263
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
Shaped Shaped
VPC
VPT
VPC
VPT
APC 2
Iub
PNNI
Iu/Iur
Iub PNNI Iub PNNI Hairpin
sPvc
APC 1
APC 0
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
AtmIf CA maxVccs
2402
2402
2402
536
4802
536
536
64
2175
2175
2175
2175
536
AtmIf CA maxVpcs
200
22
AtmIf CA maxVpts
200
22
4095
4095
4095
255
255
255
255
255
255
255
255
255
255
255
4095
4095
AtmIf maxVpiBits
AtmIf CA minAutoSelectedVpi
AtmIf CA maxAutoSelectedVpi
4095
4095
4095
255
255
255
255
255
255
255
255
255
255
255
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 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
200
AtmIf ConnMap Ov numVccsForVpiZero

AtmIf ConnMap Ov numNonZeroVpisForVccs
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
Per port limitation:

numVccsForVpiZero+(numVccsPerNonZeroVpi
* numNonZeroVpisForVccs) <= 23 654
Per card limitation: sum of (maxVccs +
maxVpcs + (maxVpts * 2) + 1)
Checks:
Arc
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:
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):
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 229/263
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:
-
4.1.4
UMTS UA 4-2:
Up to 400 nodeBs per RNC, TBC
UMTS UA 4-1 and previous:
Up to 200 nodeBs per RNC,
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 230/263
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).
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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 231/263
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:
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 232/263
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
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.
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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 233/263
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:
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:
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 234/263
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
OAM
UBR
UBR+/MCR
PriorityLevel
- 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
UP DS
SC recommended
for the interface
rtVBR
SC configured in
NodeB
UBR
PriorityLevel
0
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 235/263
4.2.8
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:
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 236/263
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
MICRO NODEB

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

UA4-2-5:
The picoNodeB atm is available.
4.5
PLANE RELATIVE
4.5.1
UMTS HSUPA PLANE:

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

UA4-2:
The UMTS HSDPA traffic flow is added.
Hsdpa is handled on Iub interface, not on Iur interface.
4.5.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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 237/263
4.5.4
UMTS CONTROL PLANE:

Radio Network ControlPlane, CP and CCP VCC, RNC TMU-R allocation:
UA4:
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.5.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.5.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
07.02 / EN
Standard
29/06/2009
Page 238/263
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
07.02 / EN
Standard
29/06/2009
Page 239/263
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
07.02 / EN
Standard
29/06/2009
Page 240/263
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
07.02 / EN
Standard
29/06/2009
Page 241/263
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
07.02 / EN
Standard
29/06/2009
Page 242/263
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
07.02 / EN
Standard
29/06/2009
Page 243/263
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.6.16..
- 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
07.02 / EN
Standard
29/06/2009
Page 244/263
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
800
&
801
&
802
VPI
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
800
VPI
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
801
VPI
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
07.02 / EN
Standard
29/06/2009
Page 245/263

VCC type:
qos0
qos2
qos3
CP
CCP
NodeB oam
Alcap
AAL
aal2
aal2
aal2
aal5
aal5
aal5
aal5
port
802
VPI
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
808
VPI
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
800
&
801
&
802
VPI
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
800
&
801
&
802
VPI
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
07.02 / EN
Standard
29/06/2009
Page 246/263

VCC type:
qos0
qos1
qos2
qos3
CP
CCP
NodeB oam
Alcap
AAL
aal2
aal2
aal2
aal2
aal5
aal5
aal5
aal5
port
800
VPI
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
801
VPI
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
802
VPI
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
808
VPI
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
07.02 / EN
Standard
29/06/2009
Page 247/263

VCC type:
qos0
qos1
qos2
qos3
CP
CCP
NodeB oam
Alcap
AAL
aal2
aal2
aal2
aal2
aal5
aal5
aal5
aal5
port
800
&
801
&
802
VPI
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
07.02 / EN
Standard
29/06/2009
Page 248/263

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

VCC type:
qos1
qos2
qos3
AAL
port
VPI
VCI
vci that are not allocated to shared bwPpool
aal2
aal2
aal2
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
07.02 / EN
Standard
29/06/2009
Page 249/263
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
07.02 / EN
Standard
29/06/2009
Page 250/263
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
07.02 / EN
Standard
29/06/2009
Page 251/263
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
07.02 / EN
Standard
29/06/2009
Page 252/263
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
07.02 / EN
Standard
29/06/2009
Page 253/263
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:
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
07.02 / EN
Standard
29/06/2009
Page 254/263
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
07.02 / EN
Standard
29/06/2009
Page 255/263
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
07.02 / EN
Standard
29/06/2009
Page 256/263
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 or 3 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
07.02 / EN
Standard
29/06/2009
Page 257/263
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

Note: /090629/ on wps request, the qos3 vcc is moved from HP=0 to HP=1.
Remark: one more aal2 vcc may be added to the above table.
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 258/263
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.
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.
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 259/263
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.
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
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 260/263
Manufacturer : the parameter is configurable from the OMC and only seen by ALU
engineering teams
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 261/263
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
EP:
Emission Priority
FACH: Forward Access Channel
FEBE: Far End Block Errors,
FP:
Functional Processor (Passport definition)
GCAC: Generic CAC
GMM: GPRS Mobility Management
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
PCR: Peak Cell Rate
PDH: Plesiochrone Digital Hierarchy
PLCP: Physical layer Convergence Protocol
ALU confidential
UMT/IRC/APP/7149
07.02 / EN
Standard
29/06/2009
Page 262/263
PNNI: Private NNI

POC: Point Of Concentration
POR: Plan Of Reccord
POS: Packet over SONET,
PTE: Path Terminating Equipment
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
SM:
Session Management
SPVC: Soft Permanent Virtual Circuit (see PNNI)
SRB: Signalling Radio Bearer
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
07.02 / EN
Standard
29/06/2009
Page 263/263

Umt Irc App 007149 Iub Teg Ua6 External STD Ed7-2 STD 090629

Uploaded by

Copyright:

Available Formats

You might also like

Umt Irc App 007149 Iub Teg Ua6 External STD Ed7-2 STD 090629

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Umt Irc App 007149 Iub Teg Ua6 External STD Ed7-2 STD 090629

Uploaded by

Copyright:

Available Formats

Iub Transport Engineering Guide

Copyright 2007 Alcatel-Lucent, All Rights Reserved

Iub Transport, engineering guide

- 3.7.7: Change, deadInterval reduced to 3 seconds

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 .

FRS 23479 Advanced QoS Transport Framework,

Iub Transport, engineering guide

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.

3.9.7: IMA LG Bw Reduction mechanism update

3 SDH OAM flow renaming, and update,

Review UA 4-1, 25/07/04

Iub Transport, engineering guide

Removal of Iub TrafficDescriptor values.

3.3.6.3: TS update: isolate OAM VCC from VPC.

Iub Transport, engineering guide

Iub Transport, engineering guide

Iub Transport, engineering guide

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

- CC: Call Control,

(R99 & Hspa Str)

Iub Transport, engineering guide

T4, 274176 kbit/s, multiplex of 6 T3.

3.1.1.1.1 ATM ON T1:

193 bits/125 sec

ATM cell mapping field: 24 octets (TS1 ~ TS24)

Provides F3 OAM functions:

The first bit of a frame is designated an F-bit, and is used for:

Iub Transport, engineering guide

7 * 6312 = 44 184 kb/s

7 * 789 = 5523 bits

4760 bits (note)

T3 multiframe is composed of 7 frames 680 bits length, called M-sub-frames.

Iub Transport, engineering guide

Figure 3-2 T3 multiframe structure

X1 = X2 = 1 during error free condition,

X1 = X2 = 0 if Loss of Signal (LOS), Out of Frame (OOF), Alarm

P-bits (P1, P2):

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 multiframe alignment signal 010 (M1 = 0, M2 = 1, M3 = 0) is used to locate all