Sie sind auf Seite 1von 263

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

2 RELATED DOCUMENTS

ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 10/263

Iub Transport, engineering guide

[
[
[
[[
[[
[
[
[
[
[
[
[
[
[
[
[
[[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[

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

Iub Transport, engineering guide

[
[
[[
[
[
[
[
[
[[
[
[
[[
[[
[[
[
[[
[
[
[
[
[
[
[
[
[
[
[
[

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

Iub Transport, engineering guide

- 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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

EmissionPriority/MostUrgent

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

ATM Connection 2 Queue


W eight 2

n3 cells

ATM Connection 3 Queue


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

EmissionPriority/MostUrgent

Or Comm on Queue:
EP0

cells

EP1

Connection Scheduler:
W FQ

CBR
EP2

I = [2, 3, 7]
rtVBR
EP3

EP i Queue
Per VC Queues :

To Link
Egress

Com mon
Queues:

nrtVBR
ATM Connection i1 Queue
W eight 1

EP4
EP5

LinkClass
Queue
for EP i

ATM Connection i2 Queue


W eight 1
EP6
ATM Connection i3 Queue
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

Iub Transport, engineering guide

AQM
Class
Scheduler:
EP & M BG

Transm it
PerVC & comm on Q ueues

Connection Scheduler:
W FQ Or 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

ATM Connection 2 Queue


W eight 2

n3 cells

ATM Connection 3 Queue


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:

ATM Connection 71 Queue


W eight 1

nrtVB R
EP4 (CLP1)

nrtVBR
(CLP0)

EP5
LinkClass
Queue
for EP i

ATM Connection 72 Queue


W eight 1
EP6
ATM Connection 73 Queue
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:
Rule: IubTEG_Buffer_02
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

Iub Transport, engineering guide

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
Rule: IubTEG_Buffer_03
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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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
ATM Connection 01 Queue
Weight 1
n2 cells

2/ CLP, SC and CC:


 cellDiscard

ATM Connection 02 Queue


Weight 2

n3 cells

ATM Connection 03 Queue


Weight 3

APC Mapping Table,

From PQC

EmissionPriority/MostUrgent

P0

To Link
Egress

EP1
CBR
EP2

EP 7 perVC Queues

EP 7 linkClass Queue

rtVBR
EP3

n1 cells
ATM Connection 71 Queue
Weight 1
n2 cells

ATM Connection 72 Queue


Weight 2

n3 cells

(EP & MBG)

ATM Connection 73 Queue


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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

EP4 queue is in CC2.


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

Iub Transport, engineering guide

No DiscardPriority parameter on the APC based card, the cell CLP values is directly compared to the buffer
occupancy:
Queues:

MappingTable :

ATM Interface :

EmissionPriority
EP0 Queue

Tagged cell

NonTagged cell

Most Urgent
90%

38%

CBR

CLP1

Cell2

CLP0

Cell1

EP0
VCC CBR
EP1
CC0 CC1 CC2

CC3
rtVBR

EP0 queue is in CC2.


Cell1, CLP0, is accepted.
Cell2, CLP1 is rejected.

EP2
EP3

EP4 Queue

Tagged cell

nrtVBR

NonTagged cell

EP4
CLP1
75%

Cell2

CLP0

Cell1

32%
EP5

VCC nrtVBR

EP6
CC0 CC1 CC2

CC3
UBR

EP4 queue is in CC2.


Cell1, CLP0, is accepted.
Cell2, CLP1, is rejected.

EP7
Least Urgent

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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.

Drop&Insert and IMA can not be configured together.

Connectivities:

On droppedNode, PCM1 port is configured

On droppingNode, PCM2 port is configured toward the droppedNode and PCM1


is configured toward the RNC.

Remarks:

F4/F5 AIS dedicated to dropped NodeB Atm connections go through the dropping
nodeB.

The POC based on MSS7k is not involved in T1 D&I, since doesnt provide T1
access.

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

Iub Transport, engineering guide

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.

Drop&Insert and IMA can not be configured together.

Connectivities:

On droppedNode, PCM1 port is configured,

On droppingNode, PCM2 port is configured toward the droppedNode and PCM1


is configured toward the RNC.

Remarks:

GSM BTS must be the dropping node, in order to not perturb GSM traffic,

Maximum number of available E1 TS is 30 since TS0 and 16 are reserved [R47].

Fractional rate E1 access is available on MSA32 FP which populates the MSS7k.

Fractional T1:
One T1 link is shared between one GSM BTS and one NodeB:
Rule: IubTEG_D&I_05
ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 51/263

Iub Transport, engineering guide

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.

Drop&Insert and IMA can not be configured together.

Connectivities:

On droppedNode, PCM1 port is configured,

On droppingNode, PCM2 port is configured toward the droppedNode and PCM1


is configured toward the RNC.

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

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

Iub Transport, engineering guide

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

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

Iub Transport, engineering guide

- 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

Iub Transport, engineering guide

- 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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

- 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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

Rule: IubTEG_16pOC3/Stm1 FP Attribute_02


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:

Rule: IubTEG_16pOC3/Stm1 FP Attribute_03


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:

Rule: IubTEG_16pOC3/Stm1 FP Attribute_04

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

Iub Transport, engineering guide

Vcc range: [0, , 16384]


Associated Rule:
Rule: IubTEG_16pOC3/Stm1 FP Attribute_05

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:
Rule: IubTEG_16pOC3/Stm1 FP Attribute_06

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.
ApplicationContexts:
- UMTS RNC: VPT port of the 2ports hairpin solution for VP trafficShaping.
Vpts range: [0, 4096]
Associated Rule:
Rule: IubTEG_16pOC3/Stm1 FP Attribute_07

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].
ApplicationContexts:
- 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].
ApplicationContexts:
- UMTS RNC: PNNI sPVCs.
Associated Rule:

ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 84/263

Iub Transport, engineering guide

Rule: IubTEG_16pOC3/Stm1 FP Attribute_08


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].
ApplicationContexts:
- UMTS RNC: PNNI sPVCs.
ATTRIBUTE AtmIf CA maxAutoSelectedVciForNonZeroVpi (maxVciNonZeroVpi)
Setting of the maximum Vci value of the autoSelected range for nonZeroVpi.
maxVciVpiZero range: [0, 65 535].
ApplicationContexts:
- UMTS RNC: PNNI sPVCs.
Associated Rule:
Rule: IubTEG_16pOC3/Stm1 FP Attribute_09
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:

Rule: IubTEG_16pOC3/Stm1 FP Attribute_10


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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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.

3.6.2.2.1 TRANSMISSION CHARACTERISTICS:


-

16 ports OC3 / Stm1 not channelized,


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

3.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:
Rule: IubTEG_16pOC3/Stm1 atm/Pos_02
ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 87/263

Iub Transport, engineering guide

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
Rule: IubTEG_16pOC3/Stm1 atm/Pos_03
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

Iub Transport, engineering guide

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.

Rule: IubTEG_16pOC3/Stm1 atm/Pos_04


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:
Rule: IubTEG_16pOC3/Stm1 atm/Pos_05
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.

Rule: IubTEG_16pOC3/Stm1 atm/Pos_06


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

Iub Transport, engineering guide

- The default weigh assigned by the Passport to the EP for case of MBG = Priority,
The following MBG values are suggested as default values:

Rule: IubTEG_16pOC3/Stm1 atm/Pos_7


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:

Rule: IubTEG_16pOC3/Stm1 atm/Pos_8

# 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:
Rule: IubTEG_16pOC3/Stm1 atm/Pos_9
DP
Cbr

Clp0
DP1

Clp1
DP3
ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 90/263

Iub Transport, engineering guide

rtVbr

DP1

DP3

nrtVbr

DP2

DP3

Ubr

DP3

DP3

WiseDiscard:
Within each 4 CC (congestionControl level), are set the EPD, PPD, and EFCI thresholds:
Rule: IubTEG_16pOC3/Stm1 atm/Pos_10
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

Iub Transport, engineering guide

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,
Rule: IubTEG_16pOC3/Stm1 atm/Pos_11
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

Iub Transport, engineering guide

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.
Rule: IubTEG_16pOC3/Stm1 atm/Pos_12
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

Iub Transport, engineering guide

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.

3.6.2.3.2 TRANSMISSION CHARACTERISTICS:


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.

3.6.2.3.3 ATM CHARACTERISTICS:


-

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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:
Rule: IubTEG_RNC-2pStm1Ch_2
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

Iub Transport, engineering guide

Figure 3-47 AQM internal Port number

ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 98/263

Iub Transport, engineering guide

3.6.2.6.2 TRANSMISSION CHARACTERISTICS:


The 2pStm1e Ch FP provides 2 STM1 electrical Channelized links.
Lets call SDH0 / SDH1 the first /Second STM1 link on the FP.
Rule: IubTEG_RNC-2pStm1Ch_3
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.

3.6.2.6.3 ATM CHARACTERISTICS:


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:
Rule: IubTEG_RNC-2pStm1Ch_4
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

Iub Transport, engineering guide

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.
Rule: IubTEG_RNC-2pStm1Ch_5
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
Rule: IubTEG_RNC-2pStm1Ch_6
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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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.
Rule: IubTEG_RNC aal2 Component_3
Each bwPool must be associated to a congestionManagement instance.
Definition:
- TrafficType: RNC classification of the umts traffic based on the: trafficClass and the RbSetQos
information.
Different types of bandwidthPool:
- primaryForTrafficType bandwidthPool:
The primaryForTrafficType bandwidthPool is supported only on the Iub interface and may be
specified for both the atm and the ip interfaces.
A limited range of UMTS trafficTypes is assigned to such a bandwidthPool: only the Hspa I/B
traffic can be handled over a primaryForTrafficType bwPool.
Within an ATM primaryForTrafficType bwPool, up to 3 qos streams: qos1, qos2 and qos3 may
be configured. The CM/backPressure applies to each 3 qos streams.
ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 107/263

Iub Transport, engineering guide

Rule: IubTEG_RNC aal2 Component_4


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

Rule: IubTEG_RNC aal2 Component_5


- 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.
Rule: IubTEG_RNC aal2 Component_6
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

Iub Transport, engineering guide

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

[TC=backGround, RbSetQos=2, ] => qos3

qos0
path

qos1
path

qos2
path

qos3
path

TransportMap j
interfaceType: Iub
BwPool/y

preference: primaryForTrafficType
transportServiceEntries:
[TC=interactive, RbSetQos=2, ] => qos3

qos3
path

[TC=backGround, RbSetQos=2, ] => qos3

TEG
Figure 3-51, NodeB with two atm bwPools

Exemple of one atm sharedForAllTrafficTypes bwPool and one ip primaryForTrafficType bwPool


associated to one nodeB:

ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 109/263

Iub Transport, engineering guide

RNCIN

RNCIN / IubIf
aal2If i

TransportMap i
interfaceType: Iub

BwPool/x

preference: sharedForAllTrafficTypes

qos0
path

qos1
path

qos2
path

qos3
path

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

[TC=backGround, RbSetQos=2, ] => qos3


TransportMap j

ipIf i

interfaceType: Iub
preference: primaryForTrafficType

BwPool/y

transportServiceEntries:

ipFlow/i
qos 3

[TC=interactive, RbSetQos=2, ] => qos3


[TC=backGround, RbSetQos=2, ] => qos3

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.

1 * primaryForTrafficType

Ip

1 * sharedForTrafficTypes

Atm

One sharedForTrafficType bwPool associated to one nodeB IMA link.

1 * primaryForTrafficType

Atm

One primaryForTrafficType bwPool associated to one nodeB IMA link.

1 * sharedForTrafficTypes

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

Iub Transport, engineering guide

Rule: IubTEG_RNC aal2 Component_7


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
PLMN A specific bwPool bwPool4

IP router

FE

IubIf i
aal2If i

ipIf i

PLMN B specific bwPool bwPool5

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.
Rule: IubTEG_RNC aal2 Component_8
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

Iub Transport, engineering guide

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

preference: sharedForAllTrafficTypes

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

preference: primaryForTrafficType

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

Iub Transport, engineering guide

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].
Rule: IubTEG_RNC_aal2Path_2

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.
Rule: IubTEG_RNC_aal2Path_3

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

Iub Transport, engineering guide

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
 qos2toQ2630QosCodepoint = 2
 qos3toQ2630QosCodepoint = 2
With hspaStreaming:
 qos0toQ2630QosCodepoint = 1
 qos1toQ2630QosCodepoint = 1
 qos2toQ2630QosCodepoint = 2
 qos3toQ2630QosCodepoint = 2

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

A transportMap is linked either to an ipIf bwPool, an aal2if bwPool or an aal2If (as long as no bwPool
configured under the aal2if, case of IucsIf or IurIf). One TransportMap may be shared between several
instances of ipIf bwPool, aal2If bwPool and aal2If, may also be shared between different utran interfaces.
Remark: No transportMap linked to ipFlow, aal2Path or iuPS components.
Rule: IubTEG_RNC-Atm_TMap_2
Each BwPool (or Aal2If if no BwPool declared) must be linked to exactly one TransportMap.
A transportMap is configured with the following parameters:

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.
Rule: IubTEG_RNC-Atm_TMap_3
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

Iub Transport, engineering guide

- 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

Iub Transport, engineering guide

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

qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z

aal2If i

qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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 ).
cacTransportInfoList(i ).

iurFpEquivalentBitRate
iurFpMaxBitRate

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


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

cacTransportInfoList(i ).
cacTransportInfoList(i ).

iuFpEquivalentBitRate
iuFpMaxBitRate

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


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

cacTransportInfoList(i ).
cacTransportInfoList(i ).
cacTransportInfoList(i ).

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

cacTransportInfoList(i ).
cacTransportInfoList(i ).

iurFpEquivalentBitRate
iurFpMaxBitRate

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


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

cacTransportInfoList(i ).
cacTransportInfoList(i ).

iuFpEquivalentBitRate
iuFpMaxBitRate

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


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

cacTransportInfoList(i ).
cacTransportInfoList(i ).
cacTransportInfoList(i ).

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.
dlCacTransportInfo.fpEquivalentBitRate
cacTransportInfo.
dlCacTransportInfo.fpMaxBitRate
cacTransportInfo.
ulCacTransportInfo.fpEquivalentBitRate
cacTransportInfo.
ulCacTransportInfo.fpMaxBitRate
RACH (Nodeb.FDDCell.RACH)
cacTransportInfo.
dlCacTransportInfo.fpEquivalentBitRate
cacTransportInfo.
dlCacTransportInfo.fpMaxBitRate
cacTransportInfo.
ulCacTransportInfo.fpEquivalentBitRate
cacTransportInfo.
ulCacTransportInfo.fpMaxBitRate

[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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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 UL availableBandwidth = bwPool2 vcc UL 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

Iub Transport, engineering guide

- 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.
Rule: IubTEG_RNC-Atm_AC_4
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

Iub Transport, engineering guide

aal2If i

bwPool x
Available bw =3200 c/s

Cacm = qos
qos0BwReservation=60%
qos1BwReservation=60%
qos2BwReservation=60%
qos3BwReservation=100%
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
Path, ul/dl ECRgcac=1000 c/s

bwPool y
Available bw =2000 c/s

qos 2
Path, ul/dl ECRgcac=1000 c/s
qos 3
Path, ul/dl ECRgcac=200 c/s
BwPool/y
qos 3
Path, ul/dl ECRgcac=2000 c/s

qos3 = 2000 c/s

Figure 3-59, cacm=qos for atm Rnc

Rule: IubTEG_RNC-Atm_AC_5
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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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 not enough bw within the first choice bwPool.


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

If not enough bw within the first choice bwPool.

dlPref & noPreference

If not enough bw within the first choice bwPool.


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

Iub Transport, engineering guide

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

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

admissionControl: Hs-dsch & E-dch IubFp EquivalentBitRate > 0


aal2If i
Cacm=qos

TransportMap x
interfaceType: Iub,
preference: sharedForAllTrafficTypes

BwPool/x
qosxbwReserv = 0%
qos3bwReserv = 100%

tse i: I/B, rbSetQos2, => qos3


tse j:

DL qosx ECR = 4266

qos x
path

UL qosx ECR = 4266

qos 3
3 hsDpa path

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

Iub Transport, engineering guide

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

preference: primaryForTrafficType
tse i: I/B, rbSetQos2, , ulDlPref = dlPref => qos3
UBR+, rx&tx tdt=9, rxTD= 4490-0-4490-0, txTD= 4490-0-4490-0

TransportMap y

UBR, rx&tx tdt=1


nrtVbr, rx&tx tdt=6
rtVbr, rx&tx tdt=6
cbr, rx&tx tdt=1

leasedLines

preference: sharedForAllTrafficTypes
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

Iub Transport, engineering guide

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.
Rule: IubTEG_RNC-Atm_CM _3

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

Iub Transport, engineering guide

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

qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z
qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z
2

BwPool/y

CongestionManagement j

path/k
path/l

Activation: [qosDiscard only, qosDiscard+backPressure]


qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z
qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z

ipIf i
3

BwPool/u

CongestionManagement k
Activation: [qosDiscard only, qosDiscard+backPressure]

ipFlow/i

qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z

ipFlow/l

qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z

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.
Rule: IubTEG_RNC-Atm_CM _4
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

Iub Transport, engineering guide

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,

Rule: IubTEG_RNC-Atm_CM _5
The RncIn enhancedQos parameter must be set to enable, when the congestionManagement
UA6 behavior is preferred.
Rule: IubTEG_RNC-Atm_CM _6

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.
Rule: IubTEG_RNC-Atm_CM _7

qosDt(0) qosDt(1) qosDt(2) qosDt(3)


A qosBP(n)=0 means that the backPressure doesnt apply for the qos n.
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

Iub Transport, engineering guide

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
the remote POC on the atm interfaces toward the NodeB.
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.

Rule: IubTEG_RNC-Atm_CM _8

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
Rule: IubTEG_RNC-Atm_CM _9

Case of No basicVPT trafficShaping on the Iub interface:


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

Quarter of the qos2 trafficVolume over the previous 40 ms uncongested period.

Q3e

Quarter of the qos3 trafficVolume over the previous 40 ms uncongested period.


Table 3-16, qosn estimated counters

ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 140/263

Iub Transport, engineering guide

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%.
Rule: IubTEG_RNC-Atm_CM _10

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

= Th0 - n [qosnBwReser * vcc ECRqosn /100], with n 1

Bw1exclus = qos1BwReser * vcc ECRqos1 /100


Bw2avail

= Th0 - n [qosnBwReser * vcc ECRqosn /100], with n 2

Bw2exclus = qos2BwReser * vcc ECRqos2 /100


Bw3avail

= Th0 - n [qosnBwReser * vcc ECRqosn /100], with n 3

Bw3exclus = qos3BwReser * vcc ECRqos3 /100

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:
qosDiscardThresholds
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.
qosDiscardThresholds
bpThn = dthn * qosBPtn/100

Table 3-22, qos backPressure thresholds

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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.

Rule: IubTEG_RNC_Alcap_2
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.
Rule: IubTEG_RNC_Alcap_3
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.
Rule: IubTEG_RNC_Alcap_4
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

Iub Transport, engineering guide

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.
Rule: IubTEG_RNC_Alcap_5
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.
Rule: IubTEG_RNC_Alcap_6
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

Iub Transport, engineering guide

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.
Rule: IubTEG_utranSharing_2
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

Iub Transport, engineering guide

The RNC is identified by one A2EA, and traffics with utran aal2 nodes (NodeB, neighbor RNC and
MGw):
Rule: IubTEG_utranSharing_4
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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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).
Rule: IubTEG_4pGE FP_2
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.
Rule: IubTEG_4pGE FP_3
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

Iub Transport, engineering guide

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:
Rule: IubTEG_4pGE FP_4
Transport Qos information mapping:
ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 152/263

Iub Transport, engineering guide

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:
Rule: IubTEG_4pGE FP_5
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.
Rule: IubTEG_4pGE FP_6
The P-Tag is ignored by the RNC

ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 153/263

Iub Transport, engineering guide

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

Rule: IubTEG_4pGE FP_7


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.
Rule: IubTEG_4pGE FP_8
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.
Rule: IubTEG_4pGE FP_9
- 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

Iub Transport, engineering guide

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.
Rule: IubTEG_4pGE FP_10
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
Rule: IubTEG_4pGE FP_11
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.
Rule: IubTEG_4pGE FP_12
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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

- 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

Iub Transport, engineering guide

Asymmetrical traffic.

One or several bwPool is/are configured under an ipIf component:


Rule: IubTEG_RNC IP Components_2
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.
Rule: IubTEG_RNC IP Components_6
- 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.

Rule: IubTEG_RNC IP Components_7


- 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

Iub Transport, engineering guide

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.
Rule: IubTEG_RNC IP Components_8
Each bwPool must be associated to a transportMap instance with the appropriated interfaceType.
Exemple of one atm sharedForAllTrafficTypes bwPool and one ip primaryForTrafficType bwPool
associated to one nodeB:

RNCIN

RNCIN / IubIf
aal2If i

TransportMap i
interfaceType: Iub

BwPool/x

preference: sharedForAllTrafficTypes

qos0
path

qos1
path

qos2
path

qos3
path

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

[TC=backGround, RbSetQos=2, ] => qos3


TransportMap j

ipIf i

interfaceType: Iub
preference: primaryForTrafficType

BwPool/y

transportServiceEntries:

ipFlow/i
qos 3

[TC=interactive, RbSetQos=2, ] => qos3


[TC=backGround, RbSetQos=2, ] => qos3

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

Iub Transport, engineering guide

Topology

N*E1+IMA

Hybrid Iub

2 IMA

1 IMA

bwPool/Preference

Transport

N * sharedForTrafficTypes

Atm

1 * primaryForTrafficType

Atm

1 * sharedForTrafficTypes

Atm

1 * primaryForTrafficType

Ip

1 * sharedForTrafficTypes

Atm

1 * primaryForTrafficType

Atm

1 * sharedForTrafficTypes

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
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.
Rule: IubTEG_RNC IP Components_9
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

Iub Transport, engineering guide

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
PLMN A specific bwPool bwPool4

IP router

FE

IubIf i
aal2If i

ipIf i

PLMN B specific bwPool bwPool5

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

Iub Transport, engineering guide

RNCIN

RNCIN / IubIf
aal2If i

TransportMap i
interfaceType: Iub

BwPool/x

preference: sharedForAllTrafficTypes

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
preference: primaryForTrafficType

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

Iub Transport, engineering guide

- 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

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

- 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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

RNC Iub VR routingTable:


VR /x
IP
Static
Route = 0.0.0.0, protected=y
NextHop = IP@ 1-2 /30
metric = 1
NextHop = IP@ 2-2 /30
metric = 2

FP0
FP0
GE 0

Route = 10.32.2.0 /25


NextHop = IP@ 2-2 /30

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

Iub Transport, engineering guide

RNC
RNC
RNC Iub VR routingTable:
VR /x

VR
VR

Group 2

PP1

IP@ 1-2

10.32.2.128

IP
Static
Route = 0.0.0.0, protected=y
NextHop = IP@ 1-2 /30
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

NextHop = IP@ 2-2 /30


metric = 2

FP0
FP0
GE 0
GE 1
GE 2
GE 3

Route = 10.32.2.1 to,


10.32.2.127
NextHop = IP@ 2-2 /30

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
Route = 0.0.0.0, protected=y
NextHop = IP@ 1-2 /30
metric = 1
NextHop = IP@ 2-2 /30
metric = 2
NextHop = IP@ 3-2 /30
metric = 3
NextHop = IP@ 4-2 /30
metric = 4
Route = 10.32.2.0 /25
NextHop = IP@ 2-2 /30

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

RNC Iub VR routingTable:


VR /x

RNC
RNC

lan

FP1
FP1
GE 0
GE 1
GE 2

Route = 10.32.3.0 /25


NextHop = IP@ 3-2 /30

GE 3

NodeB
NodeB

GE

10.32.2.1

GE

Route = 10.32.2.1 /25


NextHop = IP@ 4-2 /30

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

The primaryForTrafficType preference can be assigned to both atm bwPool and IP


bwPool.

Rule: IubTEG_Hybrid-RNC_ TMap _3


The interfaceType and Preference are mandatory parameters within the transportMap.
Rule: IubTEG_Hybrid-RNC_ TMap _4
The primaryForTrafficType Preference value is available only on the Iub interface.
- Transport serviceEntry:
- Inputs: TC, rbSetQos, ARP-PL, THP.
Each input may be set with a specific value or with the ignore value when the input
parameter doesnt apply to the UMTS flow.
- Output:
 qos i: with i in the range [0, 1, 2, 3], one associated transport qos value
involved in both the atm and ip interfaces,
 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

Rule: IubTEG_Hybrid-RNC_ TMap _5


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).
Rule: IubTEG_Hybrid-RNC_ TMap _6
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.
Rule: IubTEG_Hybrid-RNC_ TMap _7
A specific set of transportServiceEntry input values (TC, THP, ARP, RbSetQos) must be
unique under one transportMap instance.
Nevertheless a specific set of transportServiceEntry input values may be replicated into
different transportMap instances with different output values.
The 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

Iub Transport, engineering guide

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

qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z
qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z

IurIf

Congestionmanagement j

aal2If i

qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z

qos/i, paths

qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z

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

Iub Transport, engineering guide

The bandwidth granulary that the admissionControl takes into consideration for the regulation is
configured through the cacm parameter.
The cacm parameter is configured against an aal2if and an ipIf component, and applies to all the bwPools
under the aal2If and the ipIf components.
aal2If i
cacm

ipIf i
cacm

BwPool/x

BwPool/y

qosnBwReservation
qos 0
path
path
qos 1
path
path
qos 2
path
path
qos 3
path
path

iubIf 1
SignalingBearer
userPlane
aal2LinkToaal2if: aal2If i
ipLinkToIpif: ipIf i

BwPool/y
qosnBwReservation
qos 3
path
path

qosnBwReservation
IP Flow, qos3

congestionManagement i
transportMap j

congestionManagement n
transportMap m
congestionManagement x
transportMap y

TEG

Figure 3-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
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 UL availableBandwidth = bwPool2 vcc UL 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

Iub Transport, engineering guide

- Cacm = ipIf: The availableBandwidth taken into consideration by the admissionControl is the
calculated total bandwidth per bwPool and per direction,
E.g.: 1 bwPools under one ipIf then:

bwPool UL availableBandwidth = 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.

Rule: IubTEG_Hybrid-RNC_AC_4
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 = qosnBwReservation * bwPool qos i vcc UL ECRgcac,

 bwPool DL qos i availableBw = qosnBwReservation *bwPool qos i vcc DL ECRgcac.


Common for all qos available bandwidth:


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:
Per qos available bandwidth:

bwPool UL qos i availableBw = qosnBwReservation * bwPool qos i ipFlow UL ECRgcac,

 bwPool DL qos i availableBw = qosnBwReservation *bwPool qos i ipFlow DL ECRgcac.


Common for all qos available bandwidth:


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

Iub Transport, engineering guide

bwPool x
Available bw =3200 c/s

aal2If i
Cacm = qos
qos0BwReservation=60%
qos1BwReservation=60%
qos2BwReservation=60%
qos3BwReservation=100%
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

Path, ul/dl ECRgcac=1000 c/s


Path, ul/dl ECRgcac=200 c/s

ipIf i
Cacm = qos
BwPool/y
qos3BwReservation=100%
qos 3
ipFlow, ul/dl ERgcac=10000 kb/s

TEG

bwPool y
Available bw =10000 B/s

qos 3

Path, ul/dl ECRgcac=1000 c/s

qos0 = 600 c/s

qos3 = 10000 kb/s

Figure 3-85, cacm=qos for hybrid Rnc

Rule: IubTEG_Hybrid-RNC_AC_5
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:
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.

ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 182/263

Iub Transport, engineering guide

NT_UL_WaterMark_EBR_IpIf
- 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_DL_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_DL_WaterMark_EBR_IpIf
- 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.

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

Iub Transport, engineering guide

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.
Rule: IubTEG_Hybrid-RNC_CM_2
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.
Rule: IubTEG_Hybrid-RNC_CM_3
Each aal2Path must be linked to an appropriated congestionManagement table either through the
aal2If or aal2If/bwPool component it belongs to.
Rule: IubTEG_Hybrid-RNC_CM_4
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

Iub Transport, engineering guide

RNCIN

RNCIN

aal2If i

CongestionManagement i

BwPool/x

Activation: [qosDiscard only, qosDiscard+backPressure]

path/i
path/j

qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z
qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z
2

BwPool/y

CongestionManagement j

path/k
path/l

Activation: [qosDiscard only, qosDiscard+backPressure]


qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z
qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z

ipIf i
3

BwPool/u

CongestionManagement k
Activation: [qosDiscard only, qosDiscard+backPressure]

ipFlow/i

qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z

ipFlow/l

qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z

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,
Rule: IubTEG_Hybrid-RNC_CM_5
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

Iub Transport, engineering guide




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,

Rule: IubTEG_Hybrid-RNC_CM_6
The RncIn enhancedQos parameter must be set to enable, when the congestionManagement
UA6 behavior is preferred.
Rule: IubTEG_Hybrid-RNC_CM_7
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.
Rule: IubTEG_Hybrid-RNC_CM_8
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
o 3/ the remote POC is populated with a FP supporting standardVPT, the remote POC
acts as a VP switch (not VC switch) and the trafficShaping at VP level is activated in
the remote POC on the atm interfaces toward the NodeB.
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
the remote POC on the atm interfaces toward the NodeB.
ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 186/263

Iub Transport, engineering guide

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.
Rule: IubTEG_Hybrid-RNC_CM_9
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
Rule: IubTEG_Hybrid-RNC_CM_10
Case of No basicVPT trafficShaping on the Iub interface:
Case of 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

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

Quarter of the qos2 trafficVolume over the previous 40 ms uncongested period.

Q3e

Quarter of the qos3 trafficVolume over the previous 40 ms uncongested period.


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

Half of the qos 0 trafficVolume over the previous 20 ms period.

Q01

Q0+ Q1

(qos0 + qos1 traffic)

Q012

Q01 + Q2

(qos0 + qos1+ qos2 traffic)

Q0123

Q012 + Q3

(qos0 + qos1 + qos2 + qos3 traffic)

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

Iub Transport, engineering guide

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%.
Rule: IubTEG_Hybrid-RNC_CM_11
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.

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

Iub Transport, engineering guide

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:
qosDiscardThresholds
bpThn = dthn * qosBPtn/100

Table 3-32, qos backPressure thresholds

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

= Th0 - n [qosnBwReser * vcc ECRqosn /100], with n 0

Bw0exclus = qos0BwReser * vcc ECRqos0 /100


Bw1avail

= Th0 - n [qosnBwReser * vcc ECRqosn /100], with n 1

Bw1exclus = qos1BwReser * vcc ECRqos1 /100


Bw2avail

= Th0 - n [qosnBwReser * vcc ECRqosn /100], with n 2

Bw2exclus = qos2BwReser * vcc ECRqos2 /100


Bw3avail

= Th0 - n [qosnBwReser * vcc ECRqosn /100], with n 3

Bw3exclus = qos3BwReser * vcc ECRqos3 /100

Table 3-33, bwxavail & bwxexclus on atm interface

ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 189/263

Iub Transport, engineering guide

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

= Th0 - n [qosnBwReser * ipFlow ERqosn /100], with n 1

Bw1exclus = qos1BwReser * ipFlow ERqos1 /100


Bw2avail

= Th0 - n [qosnBwReser * ipFlow ERqosn /100], with n 2

Bw2exclus = qos2BwReser * ipFlow ERqos2 /100


Bw3avail

= Th0 - n [qosnBwReser * ipFlow ERqosn /100], with n 3

Bw3exclus = qos3BwReser * ipFlow ERqos3 /100

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

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.
qosDiscardThresholds
bpThn = dthn * qosBPtn/100

Table 3-36, qos backPressure thresholds

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

Iub Transport, engineering guide

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.
Rule: IubTEG_ NodeB-CEM_03
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.
Rule: IubTEG_ NodeB-CEM_04
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

Iub Transport, engineering guide

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.
Rule: IubTEG_ NodeB-CEM_01
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..
Rule: IubTEG_ NodeB-CEM_05
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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

- 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

Iub Transport, engineering guide

Application to the UMTS:


Rule: IubTEG_NodeB-IMA_2
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.
Rule: IubTEG_NodeB-IMA_3
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:
Rule: IubTEG_NodeB-IMA_4
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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

- 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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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.
Rule: IubTEG_NodeB-TM_2
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:
Rule: IubTEG_NodeB-TM_3
- 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

Iub Transport, engineering guide

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.
Rule: IubTEG_NodeB-TM_4
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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

[100 10000] milliseconds

Timer_NO-RESPONSE

7000 milliseconds

[1000 63000] milliseconds

Timer_IDLE

15000 milliseconds

[1000 63000] milliseconds

Timer_CC

1000 milliseconds

[100 5000] milliseconds

Rule: IubTEG_ Iub_NodeB atm 06


ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 208/263

Iub Transport, engineering guide

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

Iub Transport, engineering guide

Range: [255. 255. 255. 255- 0.0.0.0];


MgrPort2: UDP port:
Range: [1-65535];
Default: 162.
Rule: IubTEG_ Iub_NodeB atm 07
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:
Rule: IubTEG_ Iub_NodeB atm 08
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).
Rule: IubTEG_ Iub_NodeB atm 09
- 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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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 56 oc12/stm4 clearChannel links w
up to 28 oc12/stm4 clearChannel links w
up to 14 oc48/stm16 clearChannel links
up to 7 oc48/stm16 clearChannel links w
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
up to 440 oc12/stm4 clearChannel link
up to 416 oc12/stm4 clearChannel link
up to 110 oc48/stm16 clearChannel link
up to 104 oc48/stm16 clearChannel link
up to 110 oc48/stm16 Channelized links
up to 104 oc48/stm16 Channelized links
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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

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

ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 216/263

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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 Transport, engineering guide

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
Lp Eng Arc Apc Ov connectionPoolCapacity
Apc/2
Lp Eng Arc Apc Ov connectionPoolCapacity
Apc/3
Lp Eng Arc Apc Ov connectionPoolCapacity

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

SharedForAllTrafficTypes
SharedForAllTrafficTypes
Without
Without hspa
hspa Streaming
Streaming

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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)
- Iub sharedForAllTrafficType bwPool linked to transportMap/1
- Iub preferredForTrafficType bwPool linked to transportMap/2
- IuCS and Iur aal2If linked to transportMap/1
TransportMap:
alt 2: modify link between shared bwPool and TM
- Iub sharedForAllTrafficType bwPool linked to transportMap/3
- Iub preferredForTrafficType bwPool linked to transportMap/2
- IuCS and Iur aal2If linked to transportMap/1

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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,
- For the nodeB identified by IubIf [401, 600]: the associated vpi.vci naming rule applies only
on the stm1 801,
- For the nodeB identified by IubIf [601, 800]: the associated vpi.vci naming rule applies only
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

Iub Transport, engineering guide

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: [401, 600],
- One vpi.vci table for the nodeB identified by IubIf in the range: [601, 800],
- One vpi.vci table for the nodeB identified by IubIf in the range: [801, 1200],
- 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]

RNC Iub interface, preference sharedForAllTrafficTypes,


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]
RNC Iub interface, preference sharedForAllTrafficTypes,
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

Iub Transport, engineering guide

RNC Iub interface, preference sharedForAllTrafficTypes,


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

Table 5-11, RNC vpi.vci, sharedForTrafficTypes, no hspa streaming, IubIf in the range [601,
800]
RNC Iub interface, preference sharedForAllTrafficTypes,
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

Table 5-12, RNC vpi.vci, sharedForTrafficTypes, no hspa streaming, IubIf in the range [801,
1200]
RNC Iub interface, preference sharedForAllTrafficTypes,
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

Table 5-13, RNC vpi.vci, sharedForTrafficTypes, no hspa streaming, IubIf in the range [1201,
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

Iub Transport, engineering guide

RNC Iub interface, preference sharedForAllTrafficTypes, k = 201 to 400


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

Table 5-15, RNC vpi.vci, SharedForTrafficTypes, hspa streaming, IubIf in the range [201, 400]

RNC Iub interface, preference sharedForAllTrafficTypes, k = 401 to 600


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

Table 5-16, RNC vpi.vci, SharedForTrafficTypes, hspa streaming, IubIf in the range [401, 600]

RNC Iub interface, preference sharedForAllTrafficTypes, k = 601 to 800


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

Table 5-17, RNC vpi.vci, SharedForTrafficTypes, hspa streaming, IubIf in the range [601, 800]

RNC Iub interface, preference sharedForAllTrafficTypes, k = 801 to 1200


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

Table 5-18, RNC vpi.vci, SharedForTrafficTypes, hspa streaming, IubIf in the range [801, 1200]

ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 247/263

Iub Transport, engineering guide

RNC Iub interface, preference sharedForAllTrafficTypes, k = 1201 to 2400


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

Iub Transport, engineering guide

RNC Iub interface, preference primaryForTrafficType


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

RNC Iub interface, preference primaryForTrafficType


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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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 Transport, engineering guide

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
Lp Eng Arc Apc Ov connectionPoolCapacity

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

Iub Transport, engineering guide

5.2.2

16POC3/STM1 MS3 (ATM/POS) FP


Lp/Eng/Arc parameter:
The LP Eng/Arc component from the FP should be configured in such a way to offer a maximum amount
of protected atmConnections, and just a few nonProtected atmConnection available for debugging tool:
Rule: IubTEG_16pOC3/Stm1 atm/Pos_2
Lp/Eng/Arc protectedConnectionPoolCapacity = 31000
Lp/Eng/Arc connectionPoolCapacity = 1000
The parameters: maxVccs, maxVpcs and maxVpts are set per port according to expected amount of
required connections.
At FP level is checked that the resources reserved at port level are below the FP capacity:

atmIf [(maxVccs+maxVpcs) + 2* maxBasisicVpts + 3* maxStdVpts +1 ] < connCap+protConnCap.

5.3

IP
Within the RNC, each nodeB interface is identified by an ipIf instance.
Suggested ipIf values for up to 2400 nodeB:
ipIf
Interface:
Iub
IuPS

Values
to
2400
na

#
2400

Table 5-24, ipIf values

5.4

AAL2

5.4.1

IUBIF / AAL2IF
Between the RNC and the NodeB are configured the aal2 paths.
In the RNC, all the paths terminating in one nodeB are grouped within an aal2If component instance. The
aal2If instance is assigned to one IubIf instance. There is a one to one relationship between an aal2If
instance and an IubIf instance.
IubIf and aal2if instance value range:
iubIf
Interface:
Iub
Iub extension

1
300

Values
to
299
to
2400

#
299
2101
2400

Table 5-25, IubIf values

ALU confidential

UMT/IRC/APP/7149

07.02 / EN

Standard

29/06/2009
Page 254/263

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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

Iub Transport, engineering guide

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