Iur Teg Ua6 External Ed 06.02 STD 090611

Iur Transport, engineering guide
Document number:
Document issue:
Document status:
Date:
Author:
UMT/IRC/APP/12509
06.02 / EN
Standard
11/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.
Iur interface, engineering guide
PUBLICATION HISTORY
External
Edition:
Date:
ReasonsForChange:
11-06-09
Standard
06.01
01-02-00
3.7 updates
06.00
17-09-08
Preliminary Edition
06.02
UMTS
Release:
UA6
FRS 29869 RNC Dimensioning,
FRS 30744.9 Hsupa over Iur,
FRS 33912 #neighbor RNC,
FRS 34202 BwPool,
FRS 34220 dual stack SS7,
FRS 34237 RateController,
05.01
UA5-1
060907
FRS 34012: hsdpa supported

congestionManagement
05.00
UA5-0
11/11/06
FRS 27083: RNC aal2 linkCac enhancement,
FRS 30089: Up to 24 neighbor RNC,
FRS 30782: 16pOC3 MS3 FP
042-01
UA4-2
09/01/06
on
Iur
and
aal2
- First UA4-2 IurTEG edition.

- Interworking cases.
041.01
UA4-1
09/01/06
First UA4-1 IurTEG Edition
UA4-0
30/07/04
Modification for UA04-0:
?
01.01
- Indication: PNNI not supported on Iur.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 2/48
CONTENTS
1
INTRODUCTION....................................................................................................................5
1.1
OBJECT ....................................................................................................................................5
1.2
SCOPE OF THIS DOCUMENT .......................................................................................................5
1.3
AUDIENCE FOR THIS DOCUMENT ................................................................................................5

2
RELATED DOCUMENTS ......................................................................................................7
TRANSPORT NETWORK LAYER, DESCRIPTION .............................................................9
3.1
TRANSMISSION .......................................................................................................................10
3.2
ATM ......................................................................................................................................10
3.3
PNNI .....................................................................................................................................11
3.4
AAL2......................................................................................................................................11
3.5
3.4.1
Addressing: ...................................................................................................................11
SAAL-NNI ..............................................................................................................................11
3.6
SS7.......................................................................................................................................11
3.6.1
SCCP: ...........................................................................................................................11
3.6.2
MTP3B: .........................................................................................................................12
3.7
RNC TRANSPORT CHARACTERISTICS.......................................................................................13
3.7.1
Limitation .......................................................................................................................13
3.7.2
FP and PSFP ................................................................................................................13
3.7.3
SS7 protocol Stack........................................................................................................13
3.7.4
Alcap .............................................................................................................................13
3.7.5
Aal2 QOS ......................................................................................................................13
3.7.6
Aal2 Components..........................................................................................................14
3.7.7
RNC own A2EA.............................................................................................................18
3.7.8
QOS ..............................................................................................................................18
3.7.9
Transport admission Control .........................................................................................23
3.7.10 CongestionManagement ...............................................................................................24
3.7.11 Utran Sharing ................................................................................................................24
3.8
IUR TOPOLOGY ......................................................................................................................26
3.9
INTERWORKING CASES ...........................................................................................................28
3.9.1
Nokia RNC ....................................................................................................................28
3.9.2
Ericsson RNC................................................................................................................30
3.10
PLANE DESCRIPTION...............................................................................................................32
3.10.1
3.10.2
3.10.3
4
Hspa plane ....................................................................................................................32

Control Plane.................................................................................................................32
User plane .....................................................................................................................36
VARIATIONS BETWEEN RELEASES................................................................................37
4.1
LIMITATION .............................................................................................................................37
4.2
PNNI ......................................................................................................................................38
4.3
AAL2......................................................................................................................................38
4.3.1
Aal2 Path assignment to PMC-PC ................................................................................38

ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 3/48

4.3.2
congestion management...............................................................................................38
4.3.3
Transport admission Control .........................................................................................38
4.3.4
AAL2 PC CAC ...............................................................................................................39
4.3.5
ALCAP...........................................................................................................................39
4.3.6
Aal2 Components..........................................................................................................39
4.3.7
A2EA .............................................................................................................................40
4.3.8
Qaal2 alternate routing..................................................................................................40
4.4
SS7.......................................................................................................................................40
4.5
SOC .......................................................................................................................................41
5
TRANSPORT IDENTIFIERS................................................................................................42
5.1
VPC .......................................................................................................................................42
5.2
MIGRATION FROM UA5 TO UA6...............................................................................................42
5.3
CONTROL PLANE ....................................................................................................................43
5.4
5.3.1
atm vcc ..........................................................................................................................43
USER PLANE ..........................................................................................................................43
5.4.1
IurIf and aal2If: ..............................................................................................................43
5.4.2
aal2 Pathid: ...................................................................................................................44
5.4.3
atm vcc: .........................................................................................................................45
5.5
TRAFFIC CONTRACT ................................................................................................................46
6
ABBREVIATIONS................................................................................................................47
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 4/48
1 INTRODUCTION
1.1
OBJECT
This document intends to describe the Transport network layers on UMTS nodes, Iur interface. It includes
the following aspects:
-
Transport layers description in the context of the UMTS Iur interface,
Engineering rules,
Configuration of the UMTS nodes, in point to point connection or through a Transport network.
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:
UA 5-0
UA 5-1
OAM5.0
OAM5.0
PCR6-1
OAM Release:
OAM4.2
PCR7-2
PCR8-2
This document covers:

- TRANSPORT network layers (Transmission, ATM, aal2, aal5, Alcap, IP, Ss7 ) relative
to the Iur interface,
- UMTS Nodes: RNC.
- Impact of Atm, Aal2, Ss7 Transport networks on the UTRAN node interfaces.
1.3
AUDIENCE FOR THIS DOCUMENT
Operators, R&D, WPS, VO, Trial, networkDesign.
Mietek Surazski
UMTS UTRAN System Architect
Pascal Treillard
R&D System
JJ Genet
PLM
Alan Paddock
PLM
Norbert Sulzbacher
PLM
M Higgins
PLM
David Pauli
R&D
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 5/48

YAN LING
R&D
Michael Libbos
R&D Test
David Hoffman
R&D Test
Xavier Chalvidan
WIPS
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 6/48
2 RELATED DOCUMENTS
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 7/48

[R1
]
UMT/IRC/APP/7149
Iub TEG
[R2
]
UMT/IRC/APP/011674 Iu TEG
[R3
]
UMT/IRC/APP/12509
Iur TEG
[[ R
465
]]
Addressing TEG
R
[[ R
R 987
]]
[ R 10 ]
3GPP TS 25 430
UTRAN Iub: General Aspects and Principles
[ R 11 ]
3GPP TS 25 442
UTRAN Implementation Specific O&M Transport
[ R 12 ]
3GPP TS 34 108
RAB definition
[ R 13 ]
3GPP TS 25.410
UTRAN IU Interface: general aspects and principles
[ R 14 ]
3GPP TS 25. 412
UTRAN IU Interface: Signaling transport, Rel99
[ R 15 ]
3GPP TS 25. 414
UTRAN IU Interface: Data & Signaling transport
[ R 16 ]
3GPP TS 29.060
GTP
[ R 17 ]
3GPP TS 25 420 v3.5.0 Iur general aspect and principles
[ R 18 ]
3GPP TS 25.422 v3.6.0 Iur Signalling transport
[ R 19 ]
3GPP TS 23.236 v5.4.0 Intra-domain connection of RAN node to multiple CN node (Release5)
[ R 20 ]
3GPP TS 25.425 v3.6.0 Iur User Plane protocols for common Transport Channel data Streams.
21
3GPP TS 25.309 Rel6
FDD Enhancement Uplink, overall description, stage 2 (Release 6)
[[ R
23 ]]
R 22
24
[ R 25 ]
G702
PDH, Digital Hierarchy Bit Rates
[ R 26 ]
G703
PDH, Physical/Electrical Characteristics of Hierarchical Digital interfaces
[ R 27 ]
G707
Network node interface for the SDH
[ R 28 ]
G804
ATM cell mapping into PDH
[ R 29 ]
G700 to 706
MTP NarrowBand
[ R 30 ]
Q711 to Q 714
SCCP
[ R 31 ]
G832
Transport of SDH element on PDH network
[ R 32 ]
G783
Characteristics of SDH equipments
[ R 33 ]
G841
Types & Characteristics of SDH Network Protection Architectures
[ R 34 ]
G775
LOS and AIS defect detection and clearance criteria
[ R 35 ]
I361
Specification of ATM layer for B-ISDN.
[ R 36 ]
I610
OAM for broadband ISDN
[ R 37 ]
I363-1
AAL1
[ R 38 ]
I363-2
AAL2
[ R 39 ]
I363-5
AAL5
[ R 40 ]
I732
Functional Characteristics of ATM Equipment
[ R 41 ]
I761
IMA
[ R 42 ]
I762
ATM over fractional physical link
[ R 43 ]
Q2210
MTP3 functions & messages using the services of Q2140
[ R 44 ]
Q2931
B-ISDN
[ R 45 ]
Q2630.1
Aal2 Signaling, capabilitySet1
[ R 46 ]
Q2630.2
Aal2 Signaling, capabilitySet2
[ R 47 ]
E191
B-ISDN numbering & addressing
[ R 48 ]
X213
Addresses
[ R 49 ]
Q2941.2
GIT
[ R 50 ]
Q1970 and 1990
Nb interface info
[ R 51 ]
Q.1950
Specifications of signaling related to Bearer Independent Call Control (BICC)
[ R 52 ]
Q.765.5
Application transport mechanism: Bearer Independent Call Control (BICC)
[ R 53 ]
Q.2150.1
[ R 54 ]
G711
PCM of Voice Frequencies
[ R 55 ]
atmf 0055.000
PNNI version 1.0
[ R 56 ]
af-phy-0086.000
IMA v1-0
[ R 57 ]
af-phy-0086.001
IMA v1-1.
[ R 58 ]
af-phy-0130.00
ATM on fractional E1/T1.
[ R 59 ]
af-ra-0105.000
Addressing, userGuide. V1.0
[ R 60 ]
af-tm-0121.000
TrafficManagement Specification.
[ R 61 ]
af-vtoa-0078.000
AAL1
[ R 62 ]
af-cs-0173.000
Domain based rerouting
[ R 63 ]
af-vtoa-0113.000
Atm Trunking using Aal2 for narrowband Services
[ R 64 ]
[ R 65 ]
RFC 1541
DHCP
[ R 66 ]
RFC 2225
IP & ARP over ATM
[ R 67 ]
RFC 1629
Guideline for OSI NSAP allocation in internet
[ R 68 ]
RFC1293
InverseARP
[ R 69 ]
RFC826
ARP
[ R 70 ]
RFC1485
IP over ATM
[ R 71 ]
RFC1483
IP over AAL5
[ R 72 ]
RFC2991
ECMP
[ R 73 ]
RFC 3331
SS7 MTP2 User Adaptation (M2UA) Layer
[ R 74 ]
RFC 3332
SS7 MTP3 ALU
Userconfidential
Adaptation (M3UA) Layer
[ R 75 ]
RFC 2960
SCTP, Stream Control Transmission Protocol
[ R 78
76 ]
RFC 3309
Transmission Protocol
77
UMT/IRC/APP/12509
06.02 / ENSCTP, Stream Control
Standard
11/06/2009
Page 8/48
[ R 79
]

[
[
[[
[
[
[
[
[
[[
[
[
[[
[[
[[
[
[[
[
[
[
[
[
[
[
[
[
[
[
[
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 TRANSPORT NETWORK LAYER, DESCRIPTION

The UMTS UTRAN protocol stacks are composed of the RNL and TNL:
-
The RNL (RadioNetworkLayers) are the top layers of the UMTS Utran protocol stacks. In the context
of the Iur interface, the RNL encompasses the procedures related to the interaction of a Serving-RNC
and a neighbor RNC within a PLMN, it consists in an UMTS Control plane and an UMTS User Plane.
The User plane Frame protocols are the following: DCH, DSCH, RACH/CPCH, FACH.
The TNL (TransportNetworkLayers) are the bottom layers of the UMTS Utran protocol stacks. The
TNL is the scope of the TEG. In the context of the Iur interface, the TNL is composed of 3 kinds of
protocol stacks:
-
The Transport UserPlane which provides services to UMTS controlPlane. It is composed of Sccp,
Mtp3, SaalNni, and Aal5 over Atm. It is identical to the Transport UserPlane used on the IuCS and
IuPS ControlPlane.
The Transport UserPlane which provides services to UMTS userPlane. It is composed of Aal2 over
Atm. It is identical to the Transport UserPlane used on the Iub userPlane.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 9/48

-
The Transport controlPlane which does not provides services to UMTS layers, but uses as
callControl signaling for the aal2 bearer. It is composed of Alcap, Mtp3, SaalNni and aal5 over
atm. It is identical to the Transport controlPlane used on the IuCS Transport controlPlane.
Since there are similarities between the Iur protocol stacks and the Iub and Iu protocol stacks, then
instead of copy/paste common information from the Iu and Iub TEG to the Iur TEG, the Iur TEG
refers to the iubTEG and IuTEG for the common topics.
UMTS CP
RNL
TRANSPORT
CP
RNSAP
UMTS UP
UMTS UP
ALCAP
SCCP
Q2150.1
MTP3B
SSCF-NNI
TNL
SSCOP
AAL5
AAL2
ATM
PHY
IUR
RNC
RNC
RNC
RNC
TEG
Figure 3-1 Iur protocol stack
Remark: the M3UA/SCTP/IP (SIGTRAN) protocol stack is not supported by the RNC on the Iur interface.
3.1
TRANSMISSION
The Transmission on the Iur interface is identical to the Transmission on the Iu interface, then refer to [R2
3].
3.2
ATM
The Atm on the Iur interface is identical to the Atm on the Iub and Iu interfaces, then refer to [R1 3, R2
3].
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 10/48
3.3
PNNI
The Pnni on the Iur interface is identical to the Pnni on the IuCS interface then refer to [R2 3].The use of
Pnni sPvc on the Iur interface provides recovery against network outage.
Rule: IurTEG_PNNI_1
If Pnni is activated on the Iur interface,
it is suggested to configure pnni sPvc for both the UMTS Control and User Planes.
Since the 16pOC3 FP doesnt allow configuration of Pnni sPvc under aal2If and SS7 applications, the Iur
traffic must go cross a pnni sPvc external hairpin.
It is suggested that the Iur and Iu traffic share the same two pnni sPvc Hairpins different from the pnni sPvc
Hairpins dedicated to the Iub. Refer to [R2 5].
3.4
AAL2
The Aal2 on the Iur interface is identical to the aal2 on the Iub interface then refer to [R1 3].As long as the
sigtran is not available, the Iur alcap uses services from MTP3B/SaalNni over Atm.
The optional case of aal2Switch (es) inserted on the Iu & Iur interfaces is treated in the IuTEG, refer to [R2
3]. The RNC supports up to 10 aal2Switches (see Erreur ! Source du renvoi introuvable.).
3.4.1 ADDRESSING:
The ALU RNC is identified by one aal2 address called A2EA. The RNC is configured with its own A2EA,
see the AddressingTEG . Beside the A2EA from each neighbour RNC, are configured in the RNC aal2
translation table.
The RNC aal2 address is involved in the aal2 connection establishment on the Iur interface only, it is not
used on the IuCS interface.
Some otherVendor RNC may required to be identified by means of more than one A2EA, see 3.9.
3.5
SAAL-NNI
The SaalNni on the Iur interface is identical to the SaalNni on the Iu interface, then refer to [R2 3].
3.6
SS7
The SS7 on the Iur interface is identical to the SS7 on the Iu interface, then refer to [R2 3].
3.6.1 SCCP:
The RNSAP uses the services from both Sccp connectionless (Class0) and connection-oriented (Class2).
The RNSAP uses one Sccp connection per neighbor RNC and UE where a UE is having one or more active
radio links [R17].
The Sccp connection establishment is initiated by the SRNC, when the SRNC needs to request dedicated
resources, i.e. a DCH, from a DRNC.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 11/48
Before sending a RNSAP/RadioLinkSetup Request to the drift RNC, the serving RNC opens a SCCP
Connection (sending of Sccp CR). Nevertheless the RNC doesnt insert the RNSAP/RadioLinkSetup
Request in the Sccp CR userField but in the pending Sccp DT userField.
The insertion of the RNSAP/RadioLinkSetup Request in the Sccp CR userField is optional according to
[R17].
The RNC (acting as a driftRNC) supports reception of RNSAP/RadioLinkSetup Request inserted in the
Sccp/CR userField by an otherVendor neighbor RNC .
The sending of RNSAP/RadioLinkAddition Request to the drift RNC, doesnt trigger the establishment of a
new Sccp connection in the serving RNC, on the contrary the serving RNC relies on the Sccp connection
previously opened when sending the RNSAP/RadioLinkSetup Request.
The RNSAP is identified at Sccp layer by the SSN Indicator = 1000 1111, [R17].
Rule: IurTEG_Sccp_1
RNSAP SSN = 1000 1111.
3.6.2 MTP3B:
Each neighbor RNC is identified in the local RNC by one or several Point Code values.
Rule: IurTEG_MTP3_1
It is recommended to identify the neighbor RNC by one single PC
Rule: IurTEG_MTP3_2
The PC identifying the Local RNC and the PC identifying the neighbor RNC must belong
to the same signaling network identified by one NI value (NetworkIndicator).
As long as the neighbor RNC is identified by one pointCode value, both the Rnsap and the Alcap signaling
are transported over one single routeSet.
Rule: IurTEG_MTP3_3
In the case of the Iur interface delimited by two ALU RNC, one single routeSet is
configured.
If the otherVendor neighbor RNC is identified by two or more pointCode values, the Rnsap signaling is
transported within one dedicated routeSet, whereas the Alcap signaling is transported over one or several
different routeSet(s).
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 12/48
3.7
RNC TRANSPORT CHARACTERISTICS
3.7.1 LIMITATION
Rule: IurTEG_RNC_1
The RNC supports up to 36 neighbours RNC.
3.7.2 FP AND PSFP

Refer to [R2 3]
3.7.3 SS7 PROTOCOL STACK

Refer to [R2 3]
3.7.4 ALCAP
Reference: [R45 & 46]
The Alcap protocol is enhanced in the RNC in such a way to improve the interworking with the aal2Switch
on the UTRAN.
The RNC includes the aal2Qos information in the transmitted ERQ message.
The aal2Switch since informed about the requested aal2Qos, is able to seize downstream a path with the
requested aal2Qos.
The RNC currently doesnt allow the bandwidth modification via Q.2630.2; this is the reason why the RNC
Alcap is partly compliant with [R46].
3.7.5 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:
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 13/48

qos0toQ2630QosCodepoint = 1
With hspaStreaming:
3.7.6 AAL2 COMPONENTS

Refer to [R2 3]
One IurIf instance is created per neighbor RNC.
Rule: IurTEG_RNC-aal2_1
Each neighbor RNC must be identified by one IurIf instance.
A/ In the case of no aal2Switching function on the Iur interface, the Paths configured between the two
neighboring RNC are grouped under one aal2If instance. The aal2If is assigned to the IurIf instance.
The IurIf instance is populated with one single aal2If.
Without aal2Switch on the Iur, all the paths ending in one neighbor RNC are grouped together under
one aal2If instance.
There is a relation one to one between the IurIf instance and the aal2If instance.
B/ In the case of one or several aal2Switches on the Iur interface, all the paths terminating on one
aal2Switch are grouped together under one aal2If instance.
There are as many aal2If instances configured as amount of aal2Switch on the Iur interface.
With aal2Switch on the Iur, all the paths ending in one aal2Switch are grouped together under one
aal2If instance.
Up to 10 aal2If instances may be configured under one IurIf instance.
Therefore up to 10 aal2Switches may be inserted on one RNC aal2 interface.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 14/48

RNC
aal2If i
Paths
Qaal2 Parameters
atmConnection
Originating A2EA
aal2Qos [0, 1, 2, 3]
Qaal2 timers
pathOwner [Yes, No]
Qaal2endPoints:
Alcap bearer: Adjacent aal2 node.

AlcapConn: DPC, NI
Aal2endPoint/1 = A2EA 1
Qaal2Route/1 = aal2If 1
Aal2endPoint/2 = A2EA 2
Qaal2Route/1 = aal2If 2
aal2If j
Paths
Alcap bearer: Adjacent aal2 node.
AlcapConn: DPC, NI
iuRIf 1, 2,
UserPlane
aal2If i
aal2If j
Figure 3-2 RNC aal2 components
Application:
Assuming two aal2Switches inserted on the Iur interface and 3 neighboring RNC then the local RNC is
configured with 3 IurIf instances and 2 aaL2If instances, each IurIf instance is populated with the two aal2If
instances:
IurIf 10 IurIf 11 IurIf 12

,
s 1, 2
Path
aal2If 1
AAL2
switch
1
Pa
th
ths
Pa
RNC 10
A2EA 10
PC 10
Paths
RNC 11
A2EA 11
PC 11
PC 21
RNC 1
A2EA 1
PC 1
Path
s 1, 2
,
aal2If 2
AAL2
switch
2
Paths
PC 22
RNC 12
A2EA 12
PC 12
TEG
Figure 3-3 Example of Iur aal2 network
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 15/48
3.7.6.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 (TBM) 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 Iur and IuCS interface all the paths under a particular aal2If are distributed over different PMC-PC.
Rule: IurTEG_RNC_aal2_4
All the aal2 paths under a particular aal2If are not assigned to one single PMC-PC.
The load of a Path is estimated by means of its ECRgcac with ECRgcac = 2*SCR*PCR / (SCR+PCR).
The load of a PMC-PC is estimated by summing ECR from each Path configured on it.
3.7.6.2 AAL2 CID SELECTION

Refer to [R2 3]
Dual seizure avoidance:
Unlike the IuCS UP interface, the Iur UP interface is symmetrical in other word each RNC at the
extremity of one Iur interface is able to seize one aal2 CID over one aal2 Path.
To avoid dual seizure, on one Iur interface, the RNC provides a mechanism called path ownership. Each
path is configured with the attribute pathOwnerShip set to Yes or No.
To reduce the probability of CID collision, one Path must be configured as the pathOwner in one aal2
node (a RNC or a aal2Switch) and NOT configured as the pathOwner in the adjacent aal2 node.
The RNC where the path is declared the pathOwner, seizes the CID from the top CID range up to the
bottom CID range, whereas in the RNC where the path is NOT declared as the pathOwner, the path
seizes the CID from the bottom CID range up to the top CID range. The CID range being: [8, 255].
It is suggested to declare the path as pathOwner in the RNC with the highest RNCid.
CID election since the Path is chosen:

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.
Set cidSelectMethod = standardQ2630 for the aal2If assigned to Iur interface, or assigned to both
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 16/48

Iur+Iucs (case of aal2Switch),
Else set cidSelectMethod = roundRobin.
3.7.6.3 AAL2 TRANSLATION TABLE

Within the RNC aal2 translation table, is configured against each A2EA identifying one neighbor RNC, one
or several aal2If (see 3.7.6):
-
One single aal2if instance is configured against one A2EA in the case of either no aal2Switch or
one single aal2Switch on the Iur interface,
More than one and up to ten aal2if instances are configured against one A2EA in the case of more
than one aal2Switch inserted on the Iur interface.
If several aal2If instances configured against one A2EA, a policy may be configured for traffic distribution
over the different aal2If. Based on the cost parameter assigned against each aal2If, the policy dictates the
traffic distribution over the different aal2If for the traffic destinated to a RNC identified by an A2EA.
Under the aal2If component are configured:
-
The PC and the NI of the adjacent aal2 node, either the RNC or an aal2Switch, and
The aal2 paths terminating in the adjacent aal2 node.

Up to ten aal2Switches may be inserted on one Iur interface = up to ten aal2If under one
IurIf instance.
Up to 32 A2EA or 32 A2EA Prefix may be associated to one aal2Switches PC.
Upon reception of the message: RNSAP/RadioLink Setup Response, RNSAP/RadioLink Addition Response
or RNSAP/RadioLink Reconfiguration Response, including the neighbor RNC A2EA in the
TransportLayerAddress IE, based on its provisioned aal2 translation table the serving RNC determines:
-
The aal2If associated to the neighbor RNC,
The aal2 paths and the NI-PC configured under the aal2If.
Each path is then configured with its aal2Qos, its ownership and its associated atmConnection.
For information, below is represented a standard call flow for link addition over the Iur interface:
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 17/48

Neighbor
Neighbor UE
UE
Neighbor
Neighbor NodeB
NodeB
Drift
Drift RNC
RNC
Serving
Serving RNC
RNC
RRC/ Measurement Report

NBAP/RadioLink setup Req
RNSAP/RadioLink Setup Req
NBAP/RadioLink setup Resp
RNSAP/RadioLink Setup Resp

- Binding Id
- TransportAddress IE: A2EA
New aal2 CIDs are setup for both
the DCCH and the DTCH.
ALCAP/ERQ
RNC
aal2 Translation table:
A2EA:
=> aal2If i,
aal2If i:
=> Path (s)
=> NI, PC.
ALCAP/ECF
ALCAP/ERQ
ALCAP/ECF
FP/DL Sync (CFN)
FP/DL Sync (CFN)
FP/UL Sync (ToA)
FP/UL Sync (ToA)
RRC/ Active set update

RRC/ Active set update complete
Figure 3-4 Iur Protocol flow
3.7.6.4 QAAL2 ALTERNATE ROUTING

Refer to [R2, R201]
3.7.7 RNC OWN A2EA

The RNC is configured with its own single A2EA.
Rule: IurTEG_Aal2-A2EA_1
The ALU RNC must be configured with its own A2EA.
Remark:
The RNC own A2EA address is configured in the RNC parameter:

RNC/Qaal2Parameters/originatingA2EA. See Figure 3-2 RNC aal2 components
3.7.8 QOS
The transportMap component is the way to configure the UMTS qos information mapping table within
the RNC.
The transportMap applies to the IuCS, Iur and Iub interface, it doesnt apply to the IuPS interface.
Based on the UMTS traffic qos requirement (trafficClass, RbSetQos, ARP-PL, THP), the transportMap
identifies a specific transport bearer which satisfies the UMTS qos requirements.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 18/48

The transportMap tables apply to all the utran interfaces, with exception of the IuPS.
Several transportMap tables may be configured within the RNC.
Rule: IurTEG_RNC-Atm_QOS_1
The RNC may be configured with up to 64 transportMap components.
A transportMap is linked either to 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 aal2If
bwPool and aal2If, may also be shared between different utran interfaces.
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 5, 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.
When several bwPools serving one nodeB, e.g.: two bwPools under one aal2if, or one
aal2if/bwPool and one ipIf/bwPool, and several transportMap tables mapping with the
requested trafficType (trafficType=TC+RbSetQos) then when selecting the transport
bearer
is
given
higher
priority to
the
transportMap
set
with
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 19/48

Preference=primaryForTrafficType than
Preference=sharedForAllTrafficTypes.
to
the
transportMap
set
with
The interfaceType and Preference are mandatory parameters within the transportMap.
Rule: IurTEG_RNC-Atm _QOS_4
The primaryForTrafficType Preference value is available only on the Iub interface.
- Transport serviceEntry:
- Inputs: TC, rbSetQos, ARP-PL, THP.
Each input may be set with a specific value or with the ignore value when the input
parameter doesnt apply to the UMTS flow.
- Output:
qos i: with i in the range [0, 1, 2, 3], one associated transport qos value
involved in both the atm and ip interfaces,
The DSCP value is not taken into consideration on the ATM interface.
INPUT values
TC
rbSetQos
ARP-PL
THP
OUTPUT Values
UlDlPreference
DSCP
Qos i
- 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 ulDlPreference for the
selection of a transportServicesEntry.
The ulDlPreference allows the transport admissionControl to select different
bandwidth pools for call uplink legs and downlink legs. E.g: eDch versus hs-dsch.
When two transportEntries matching the UMTS qos information, one transportEnty
set with ulDlPreference=preferredForUlAndDl and the second set with
ulDlPreference=noPreference then when selecting the transport bearer is given higher
priority to the transportEntry set with ulDlPreference=preferredForUlAndDl than to
the transportEntry set with ulDlPreference= noPreference.
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.
A specific set of transportServiceEntry input values 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.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 20/48
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.
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 6, transportMap exemple
3.7.8.1.1 TRANSPORTMAP TABLES:

Two transportMap tables are specified for the Iur interface, which also apply to the Iub and IuCS
interfaces.
The distinction between them is related to the Iub Hspa Streaming activation or not.
- TransportMap/1:
ApplicationContext:
- UA5 backward compatibility
- InterfaceType: Iub, IuCS and Iur,
- Hspa streaming: with hspa streaming NOT supported,
- Preference: SharedForAllTrafficTypes,
- Transport: atm, enhancedQos not activated.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 21/48

Transport MAP /1
Tse
TC
1 Common
2 signaling
3 conversational
4 conversational
5 conversational
6 streaming
7 streaming
8 streaming
9 streaming
10 streaming
11 streaming
ARP
ignore
ignore
THP
ignore
ignore
ignore
ignore
rbsetQos
0
0
qos
0
0
DSCP
default
uldlpreference
noPreference
default
noPreference
default
noPreference
default
noPreference
ignore
default
noPreference
ignore
default
nopreference
ignore
2
0
1
ignore
ignore
ignore
default
nopreference
default
default
nopreference
noPreference
default
noPreference
ignore
default
noPreference
12 streaming
13 streaming
14 streaming
15 interactive
ignore
default
noPreference
ignore
default
noPreference
ignore
0
default
default
noPreference
noPreference
16 interactive
17 interactive
default
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
18 interactive
19 interactive
20 interactive
21 interactive
22 interactive
23 interactive
24 interactive
25 interactive
26 interactive
27 interactive
28 interactive
29 interactive
30 interactive
31 interactive
32 interactive
33 background
34 background
35 background
36 background
37 background
38 background
2
0
1
2
0
2
2
0
0
2
0
2
0
1
2
ignore
ignore
2
0
1
ignore
ignore
ignore
ignore
Table 3-1, ATM sharedForAllTrafficTypes withOut Iub hspa Streaming

- TransportMap/3:
ApplicationContext:
- InterfaceType: Iub, IuCS and Iur,
- Hspa streaming: hspa streaming supported,
- Preference: SharedForAllTrafficTypes,
- Transport: atm, enhancedQos activated.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 22/48

Transport MAP /3
Tse
TC
1 Common
2 signaling
ARP
ignore
ignore
3 conversational
4 conversational
5 conversational
6 streaming
7 streaming
8 streaming
9 streaming
10 streaming
11 streaming
THP
ignore
ignore
ignore
ignore
rbsetQos
0
0
qos
0
0
DSCP
default
uldlpreference
noPreference
default
noPreference
default
noPreference
default
noPreference
ignore
default
noPreference
ignore
default
nopreference
ignore
2
0
1
ignore
ignore
ignore
default
nopreference
default
default
nopreference
noPreference
default
noPreference
ignore
default
noPreference
12 streaming
13 streaming
14 streaming
15 interactive
ignore
default
noPreference
ignore
default
noPreference
ignore
0
default
default
noPreference
noPreference
16 interactive
17 interactive
default
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
18 interactive
19 interactive
20 interactive
21 interactive
22 interactive
23 interactive
24 interactive
25 interactive
26 interactive
27 interactive
28 interactive
29 interactive
30 interactive
31 interactive
32 interactive
33 background
34 background
35 background
36 background
37 background
38 background
2
0
1
2
0
2
2
0
0
2
0
2
0
1
2
ignore
ignore
2
0
1
ignore
ignore
ignore
ignore
Table 3-2, ATM sharedForAllTrafficTypes with Iub hspa Streaming
3.7.9 TRANSPORT ADMISSION CONTROL

Ref: [R1].
The transport admissionControl applying to the RNC Iur interface is described in [R1, 3/RNC atm].
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 23/48

The RNC must be configured with equivalentBitRate and maxBitRate parameter values dedicated to the Iur
interface.
Each Iur interface is configured with cacm parameter specifying the granularity of the transport
admissionControl regulation. Cacm = [aal2If, qos, path]
FallBack mechanism:
If no more available resource for the requested qos, the admissionControl seizes a CID over lower qos path.
e.g.: no more qos3 available CID, on Iur hspa call establishment the admissionControl seizes CID over qos2
then qos1 path.
3.7.10 CONGESTIONMANAGEMENT
The congestionManagement is described in [R1 3/RNC ATM/].
On the Iur interface, as an option, the congestion management may be activated.
The egress traffic from both the SRNC and the DRNC is then regulated by the congestionManagement.
Since the congestionManagement is based on counters implemented in the PMC-PC, all the paths within a
bwPool must be assigned to the same PMC-PC.
According to 3.7.6.1 the paths within an Iur aal2If are distributed over different PMC-PC then an Iur
bwPool can not be composed of the different paths under one aal2if.
Rule: IurTEG_congestionManagement_
An Iur bwPool must be composed of one single aal2 vcc.
Furthermore the qosDt and qosBp parameters must be set for each bwPool:
Rule: IurTEG_congestionManagement_
A congestionManagement table with activation=qosDiscard&qosBackPressure must be
linked to each Iur bwPool.
3.7.11 UTRAN SHARING

The objective of the UTRAN sharing feature is to allow the UTRAN network to be shared between
several UMTS operators:
Rule: IurTEG_utranSharing_1
The UTRAN is shared between up to 4 operators.
The RNC equipment is then composed of as many logical RNC as amount of Plmn sharing the utran.
The RNC is partly or completely shared between the Plmn.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 24/48

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.7.11.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 Iub userPlane Transport resources are either shared between all the PLMN sharing the
utran or dedicated per PLMN sharing the utran (see [1] per Plmn bwPool ):
- 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.
- The cp vcc, oam vcc and the 1 6 ccp vcc are common to all the Plmn.
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 must be configured between 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.7.11.2
TRANSPORT IDENTIFIERS:
The RNC equipment is composed of one logical RNC per PLMN sharing the RNC equipment.
One logical RNC is identified by its global RNC Id:
Global RNC Id = PLMN Id + RNC Id = MCC + MNC + RNC Id
One RNC Id is configured in the RNC equipment; it is common to all the logical RNC.
The RNC Id numbering plan of all the Plmn sharing the utran operators must be coordinated.
The RNC equipment is identified by its own single ss7 PC within one networkIndicator (NI) common to
all the Plmn sharing the utran.
The ss7 PC must be coordinated between all the Plmn sharing the utran.
The ss7 nodes from all the Plmn sharing the utran must be identified within the same NI.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 25/48

The RNC is identified by one A2EA, and traffics with utran aal2 nodes (NodeB, neighbor RNC and
MGw):
The A2EA numbering plan must be coordinated between all the Plmn sharing the utran.
Example of utran network with utranSharing activated:
Operator A, own MNC
UE
UE
MGw1
On the Iub, the Transport

resources are common to
both operators unless
PLMN bwPools are
configured per PLMN.
MGw2
MGC1
Operator A:
CP & UP vcc
MGw10
Mc
Operator B:
UE
UE
Mc
NRI = 1
Nc
MGw1
CP & UP vcc
MGC2
NRI = 2
UE
UE
UE
UE
RNC
RNC
UE
UE
NODE B
B
NODE
MGw10
Iub
atm
atm
Shared
resources
Iu Plmn 1
Iu Plmn2
dedicated
resources
ATM
ATM
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,
Plmn1, RNC
RNC
Plmn1,
UE
UE
Operator B, own MNC
3.8
IUR TOPOLOGY
The figure below represents different supported Iur topologies:

-
Iur point to point connection,
Aal2Switching on the Iur,
Atm Switching on the Iur,
Combination of atm and aal2 switching functions between two RNC,
Iur and Iu sharing same links.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 26/48
RNC
RNC
RNC
RNC
RNC
RNC
Aal2Switch
Aal2Switch
Iur
MGw
MGw
Iu & Iur
RNC
RNC
RNC
RNC
Atm
Atm
backbone
backbone
Iu & Iur
MGw
MGw
TEG
Figure 3-7 Iur Point to Point topologies
The Figure below represents the Iur interface with several aal2Switches inserted on the Utran, allowing the
traffic distribution over different path, the securisation of the traffic against Node/Link failure (see
qaal2alternateRouting feature):
IurIf 10 IurIf 11 IurIf 12

,
s 1, 2
Path
aal2If 1
AAL2
switch
1
Pa
th
ths
Pa
RNC 10
A2EA 10
PC 10
Paths
RNC 11
A2EA 11
PC 11
PC 21
RNC 1
A2EA 1
PC 1
Path
s 1, 2
,
aal2If 2
AAL2
switch
2
Paths
PC 22
RNC 12
A2EA 12
PC 12
TEG
Figure 3-8 Topology with several aal2Switch
The Figure below represents one more case of topology, on the RNC side the IuCS and Iur traffic share one
common transmission links, an aal2Switch is inserted between the RNC and the remote aal2 endPoint n
odes (MGw and neighbor RNC):
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 27/48
RNC
RNC
RNC
RNC
RNC
RNC
ALCAP
Port
Port
MTP3 MTP3
Saal
Saal
ATM
ATM
ATM
Backbone
16p OC3/STM1
OC3/STM1 FP
FP
16p
Transport CP
IuCS & IuR common resources:
- ALCAP SL,
- Paths.
AAL2
ATM
MTP3 RouteSet configuration:

- OPC = RNC PC,
- DPC = AAL2 Switch PC.
Port
Port
(option)
ATM
UP
AAL2
AAL2
Switch
Switch
ATM
Backbone
IuCS & Iur
IuR:
- ALCAP SLs,
- Paths,
- (CP VCCs).
IuCS:
- ALCAP SL,
- Paths,
- (CP VCCs )
CS
CS
coreNetwork
coreNetwork
(option)
STM1
IuR Translation table:

Per RNC:
- PC,
- A2EA,
- Paths.
IuCS Translation table:

Per MGw:
- PC,
- A2EA,
- Paths.
TEG
Figure 3-9 IuCS and Iur switched at aal2 layer.
3.9
INTERWORKING CASES
3.9.1 NOKIA RNC

The Nokia RNC Iur Transport characteristics:
1/ No support of the aal2 Qos,
2/ the aal2 Path are associated to a Cbr Vcc,
3/ the pathId is coded over four bytes, whereas coded on two bytes in ALU RNC.
Suggestion to cover characteristics 3/:

For the case of Nokia / ALU Iur Interworking, specify the pathId in the range: [1 65535].
Suggestion to cover characteristics 1 and 2/:

ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 28/48

Even if one single atm qos configured on the Nokia RNC side, on the ALU RNC different qos are
configured.
Impact of the Characteristic 1/:
-
Context: Nokia RNC = serving RNC and ALU RNC = driftRNC,

The Nokia RNC acting as the serving RNC, seizes a CID over an Iur aal2 path without doing any
differentiation between Path and between the different UMTS Radio Bearers.
No Qos applies on the Nokia RNC side between UMTS bearers.
Beside the ALU RNC acting as the drift RNC, select an Iub Path taking into account the required
aal2Qos.
servingRNC = Nokia RNC

IuPS
Iur
qos0Path, cbr vcc
Path,
Path, cbr
cbr vcc
vcc
qos0Path, cbr vcc
Path,
Path, cbr
cbr vcc
vcc
qos1Path, rtVbr vcc
Path,
Path, cbr
cbr vcc
vcc
qos1Path, rtVbr vcc
Iur CID Seizure
The Nokia RNC, acting as the serving RNC, seizes a

CID over an Iur Path, since no aal2 qos on Nokia side,
the Nortel RNC expects to handle each kind of UMTS
bearer on qos0 path, and qos1 path. Beside the Nortel
RNC applies the aal2 qos on the Iub interface.
UMTS DS calls
Iub qos1Path,nrtVbr
qos1Path,nrtVbr Vcc
Vcc
Iub
Path,
Path, cbr
cbr vcc
vcc
Iub qos0Path,
qos0Path, rtVbr
rtVbr Vcc
Vcc
Iub
Aal5 vcc
vcc
Aal5
Aal5 vcc
vcc
Aal5
Iu Path
Path
Iu
Iu Path
Path
Iu
Iu Path
Path
Iu
Iu Path
Path
Iu
UMTS DS and NDS calls
Nortel RNC
RNC
Nortel
(drift Rnc)
Rnc)
(drift
Nokia RNC
RNC
Nokia
(serving
Rnc)
(serving Rnc)
IuCs
Iub CID
Seizure
Iub
UMTS NDS calls
NodeB
NodeB
Figure 3-10 Iw with Nokia RNC acting as the serving RNC
Context: ALU RNC = serving RNC and NoKia RNC = driftRNC,

The ALU RNC acting as the serving RNC, seizes a CID over an Iur aal2 path applying the required
configured aal2 qos.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 29/48
servingRNC = Nortel RNC

IuPS
Iur
Path,
Path, cbr
cbr vcc
vcc
qos0Path, cbr vcc
Path,
Path, cbr
cbr vcc
vcc
qos1Path, rtVbr vcc
Path,
Path, cbr
cbr vcc
vcc
qos1Path, rtVbr vcc
Path,
Path, cbr
cbr vcc
vcc
Iur CID Seizure

UMTS NDS calls
Iub Path,
Path, Vcc
Vcc
Iub
qos0Path, cbr vcc
Iub Path,
Path, Vcc
Vcc
Iub
Aal5 vcc
vcc
Aal5
Aal5 vcc
vcc
Aal5
Iu Path
Path
Iu
Iu Path
Path
Iu
Iu Path
Path
Iu
Iu
Path
Iu Path
UMTS DS calls
Nokia RNC
RNC
Nokia
(driftRnc)
Rnc)
(drift
Nortel RNC
RNC
Nortel
(serving
Rnc)
(serving Rnc)
IuCS
Iub
The Nortel RNC, acting as the serving RNC, seizes a
CID over an Iur Path and achieve qos between Umts
bearers.
NodeB
NodeB
Figure 3-11 Iw with Nokia RNC acting as the drift RNC

The following figure represents a summary of the different UMTS flows on the Iur Transport bearers in case
of interworking with Nokia RNC:
DS & NDS CID seized by the Nokia servingRNC
IuPS
+ DS CID seized by the Nortel serving RNC.
qos0Path, cbr vcc
Path,
Path, cbr
cbr vcc
vcc
qos1Path, rtVbr vcc
Path,
Path, cbr
cbr vcc
vcc
qos1Path, rtVbr vcc
Iur CID Seizure
DS & NDS CID seized by the Nokia servingRNC

+ NDS CID seized by the Nortel serving RNC.
UMTS DS calls
Iub qos1Path,nrtVbr
qos1Path,nrtVbr Vcc
Vcc
Iub
qos0Path, cbr vcc
Path,
Path, cbr
cbr vcc
vcc
Iub qos0Path,
qos0Path, rtVbr
rtVbr Vcc
Vcc
Iub
Aal5 vcc
vcc
Aal5
Aal5 vcc
vcc
Aal5
Iu Path
Path
Iu
Iu Path
Path
Iu
Iu Path
Path
Iu
Iu Path
Path
Iu
Iur
Path,
Path, cbr
cbr vcc
vcc
Nortel RNC
RNC
Nortel
Nokia RNC
RNC
Nokia
IuCs
Iub CID
Seizure
Iub
UMTS NDS calls
NodeB
NodeB
Figure 3-12 Summary of UMTS flows distribution on Iur paths
3.9.2 ERICSSON RNC

The E/// RNC Iur Transport characteristics:
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 30/48

1/ The E/// neighbor RNC is identified by a pool of A2EA addresses. Each A2EA within this pool
identifies a nodeB under control of the E/// neighbor RNC.
2/ The E/// RNC doesnt support aal2 qos on the Iur interface.
The impact of the second characteristic is already treated in the 3.9.1.

To cover the first characteristic, two ways of filling the ALU RNC aal2 Translation table are suggested
below, follow by the otherVendor RNC configuration:
First suggestion:
-
On ALU RNC side:

-
In the aal2 Translation table:

-
Associate one aal2If instance to all the A2EA identifying the neighbor NodeB under
neighbor E/// RNC control: [a2ea 1-00, a2ea 1-xx] => aal2If 350,
The ALU RNC supports up to 128 A2EA shared by all the Utran aal2 interfaces
Assigned the Qos0Path = 4433 and Qos1Path = 4473 to the aal2If 350,
Assigned the E/// neighbor RNC PC=pc10 and the NI to the aal2If 350,
Associate the Path 4433 to a Cbr Vcc and the Path 4473 to an rtVbr Vcc.
On E/// RNC side:

-
Configure the ALU RNC NI / PC,
The ALU RNC own A2EA,
Path 4433, Path 4473 and associate them to the Vcc and serviceCategory suggested by E///.
Second suggestion:
-
On E/// RNC side:

-
Assign to each NodeB under E/// RNC control and neighbor of the NodeB under ALU RNC
control, an A2EA including a common Prefix, lets called it the A2EAPrefix.
Configure the ALU RNC NI / PC,
The ALU RNC own A2EA,
Path 4433, Path 4473 and associate them to the Vcc and serviceCategory suggested by E///.
On ALU RNC side:

-
In the aal2 Translation table:

-
Rely on the A2EAPrefix feature see Erreur ! Source du renvoi introuvable.; associate
one aal2If instance to the A2EAPrefix identifying the neighbor NodeB under neighbor E///
RNC control: [A2EAPrefix] => aal2If 350,
Indeed one single entrance is used in the RNC aal2 Translation Table.
Assigned the Qos0Path = 4433 and Qos1Path = 4473 to the aal2If 350,
Assigned the E/// neighbor RNC PC=pc10 and the NI to the aal2If 350,
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 31/48

-
3.10
Associate the Path 4433 to a Cbr Vcc and the Path 4473 to an rtVbr Vcc.
PLANE DESCRIPTION
The Iur interface uses the services from ATM Transport.

The Iur interface doesnt use the services from ip Transport.
3.10.1 HSPA PLANE

The RNC supports the interactive, background and streaming Hspa traffic on the Iur interface.
Since the hspa streaming is enable on the Iur interface, it is transmitted together with R99 CS Streaming
over the qos1 vcc.
The DRNC aal2 congestionManagement status is taken into consideration for determining the hspa credit
allocation information transmitted to the SRNC through the FP protocol (outside of the TEG scope see
[R226]).
3.10.2 CONTROL PLANE

This section covers both the UMTS and Transport control Plane.
The figure below represents the ALU RNC components involved in the Iur control plane:
RNSAP
RNSAP
RNSAP
RNSAP
SCCP
SCCP
SCCP
SCCP
ALCAP
ALCAP
ALCAP
ALCAP
MTP3B
MTP3B
MTP3B
MTP3B
SSCF
SSCF
SSCF
SSCF
SSCOP
SSCOP
SSCOP
SSCOP
AAL5
AAL5
AAL5
AAL5
ATM
ATM
ATM
ATM
PHY
PHY
PHY
PHY
Atm
Atm
Backbone
Backbone
PDC
PDC
TMU
TMU PMC-M
PMC-M AP-NI
AP-NI saalNni
saalNni FP
FP
(option)
(option)
ALU
ALU RNC
RNC
RNC
RNC
Stm1 Cl
ALU or
otherVendor
Figure 3-13 RNC, Iu CP implementation
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 32/48
3.10.2.1
SS7
The neighbor RNC is identified by means of at least one PC.

If the neighbor RNC is identified by one single PC then one single routeSet is configured on the Iur
interface, identified by the local RNC PC and the neighbor RNC PC. The routeSet carries both RNSAP and
Alcap protocols.
RNSAP
SCCP
ALCAP
MTP3B
SSCF-NNI
RNC
RNC
SSCOP
AAL5
PC
PC xx
Neighb
Neighb
RNC
RNC
ATM
PHY / STM1
PC
PC yy
RouteSet: OPC x / DPC y
Aal2endPoint
endPoint
Aal2
Aal2endPoint
endPoint
Aal2
qos0 aal2 Paths

qos1 aal2 Paths
qos2 aal2 Paths
qos3 aal2 Paths
TEG
Figure 3-14 the neighbor RNC identified by one PC
If the neighbor RNC is identified by more than one PC then one neighbor RNC PC is used to identify one
routeSet which carries RNSAP, whereas the other neighbor RNC PC are used to identified other routeSet
dedicated to the Alcap protocols.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 33/48

RNSAP
SCCP
RNC
RNC
PC
PC xx
ALCAP
MTP3B
MTP3B
SSCF-NNI
SSCF-NNI
SSCOP
SSCOP
AAL5
AAL5
ATM
ATM
PHY / STM1
PHY / STM1
Neighb
Neighb
RNC
RNC
PC
PC yy
RouteSet: OPC x / DPC z
PC
PC zz
Aal2endPoint
endPoint
Aal2
Aal2endPoint
endPoint
Aal2
qos0 aal2 Paths

qos1 aal2 Paths
qos2 aal2 Paths
qos3 aal2 Paths
TEG
Figure 3-15 Neighbouring RNC, identified by two PC
Furthermore, the SS7 topology is impacted in case of insertion of aal2Switch on the Iur interface as
indicated in the following figures:
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 34/48

RNSAP
SCCP
MTP3B
SSCF-NNI
SSCF-NNI
SSCOP
SSCOP
AAL5
AAL5
ATM
ATM
PHY / STM1
PHY / STM1
RNC
RNC
PC
PC xx
ALCAP
MTP3B
RouteSet: OPC x / DPC z
PC
PC yy
Aal2Switch
Aal2Switch
PC
PC zz
Aal2endPoint
endPoint
Aal2
qos3 aal2 Paths
qos1 aal2 Paths

qos2 aal2 Paths
qos3 aal2 Paths
Aal2endPoint
endPoint
Aal2
qos2 aal2 Paths
qos0 aal2 Paths
Aal2endPoint
endPoint
Aal2
Aal2endPoint
endPoint
Aal2
qos0 aal2 Paths

qos1 aal2 Paths
Neighb
Neighb
RNC
RNC
TEG
Figure 3-16 Aal2Switch inserted on the Iur interface
One RNSAP routeSet is configured between the two neighbour RNC, whereas the Alcap routeSet is initiated
in one RNC and end in the aal2Switch.
3.10.2.2
ATM
One atm connection is associated to each SL configured at Mtp3 level. Therefore as many CP vcc are
configured as amount of SL, whatever the amount of routeSet configured on the Iur interface.
The atm connections configured in the UMTS control plane originate in the RNC-IN of one RNC and
terminate in the adjacent RNC.
As an option, these atm connections may be switched in atmSwitch (es) inserted on the Iur interface, or ends
within an intermediate aal2Switch.
The Iur Rnsap and Alcap CP vcc are configured with the rtVbr serviceCategory which is mapped to EP=3.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 35/48
3.10.3 USER PLANE

IuCS
UP
IUR
IuCS
UP
IUR UP
UP
IUR
IUR UP
UP
AAL2
AAL2
ATM
ATM
ATM
ATM
PHY
PHY
PMC-Rab
PMC-PC
PMC-Rab PMC-PC
PHY
PHY
FP
FP
ALU
ALU RNC
RNC
Stm1 Cl
PHY
PHY
AAL2
AAL2
AAL2
AAL2
ATM
ATM ATM
ATM
ATM
ATM
PHY
PHY
PHY
PHY
PHY
PHY
Optional
Optional
atmSwitch
atmSwitch
all2Switch
all2Switch
RNC
RNC
ALU or
otherVendor
Figure 3-17 Iur User Plane protocol stack
3.10.3.1
AAL2-USER
On the Iur interface, the aal2-users are the UMTS TRB (TrafficRadioBearer) and dSRB (dedicated
SignalingRadioBearer).
The ALU RNC doesnt support the cSRB on the Iur interface (commonSSRB: RACH, FACH, HS-DSCH).
One aal2 CID is seized per TRB and one aal2 CID is seized per dedicatedSRB.
In the specific case of one UE involved in one CS and PS calls and moving from one RNC area to another
then 3 CID are seized: on CID is seized for the CS TRB, one CID is seized for the PS TRB and one single
CID is seized for the dSRB.
The amount of CID seized by the TRB and the dedicated SRB is directly proportional to the user traffic.
Application:
Each Iur link addition induces the seizure of 2 CID (one for TRB and one for dSRB) as a result one aal2
path supports up to 248/2= 124 UMTS links (abstraction of the commonSRB).
[R17&20].
3.10.3.2
AAL2:
Within the ALU RNC, each Neighbor RNC is identified by means of one IurIf and as many aal2If instances
as amount of SS7 ALCAP PC s identifying the adjacent aal2 node (either neighbor RNC or aal2Switch)
Assuming a neighbor RNC identified at MTP3 level by means of one single PC, then one single aal2If
values is assigned to this neighbor RNC in the local RNC.
The aal2If identifies the Neighbor RNC Transport UserPlane.
Under each aal2If instance identifying one adjacent aal2 node, are per default configured 2 qos0 paths, 2
qos1 paths, 2 qos2 paths, 2 qos3 paths.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 36/48

The amount of required aal2 connections between two RNC s results from a UMTS dimensioning study
based on the customer expected traffic.
3.10.3.3
ATM:
Per default are configured: 2 qos0 vcc, 2 qos1 vcc, 2 qos2 vcc, 2 qos3 vcc.
Based on the UMTS Dimensioning on the Iur interface, different amount of aal2 vcc may be requested.
The ATM connections originate in the RNC and terminate either in the adjacent RNC or as an option
terminate in an aal2Switch or are switched in an atmSwitch.
Four atm qos are configured:

Qos mapping
UMTS flows
vcc
Atm Qos
AMR, dSRB, cSRB, (R99 CS Streaming)
qos0 vcc
Cbr
EP2
R99 & hspa CS Streaming
qos1 vcc
rtVbr
EP3
R99 I/B
qos2 vcc
nrtVbr
EP4
Hspa I/B
qs3vcc
ubr
EP7
Remark:
The reason why the cbr was assigned against the qos0 vcc and not the rtVbr serviceCategory as on the
Iub interface is to satisfy the case where both IuCS and Iur traffics shared the same transmission link.
4 VARIATIONS BETWEEN RELEASES

The indicated variations concern the ALU RNC.
4.1
LIMITATION
Amount of neighbor RNC:
UA6:
UA5:
UA:
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 37/48

Hsdpa / Hsupa Umts traffic:
UA5-1:
The Hsdpa traffic is supported on the Iur interface.
4.2
UA4-2:
The Hsdpa traffic is not supported on the Iur interface.
PNNI
4.3
UA 4-1:
The RNC supports Pnni on all 3 UTRAN interfaces.
AAL2
4.3.1 AAL2 PATH ASSIGNMENT TO PMC-PC

UA4-2:
The loadBalancing = [weight, spread] parameter is removed.
A new algorithm is in charge of distributed the Utran aal2 vcc over the PMC-PC.
UA4-1 and previous releases:

The path assignment algorithm is based on the parameter loadBalancing set to spread.
4.3.2 CONGESTION MANAGEMENT

UA6:
Supported
4.3.3 TRANSPORT ADMISSION CONTROL

AAL2 Link CAC:
UA4&3:
AAL2 CAC is always activated on RNC IuCS and Iur interfaces.
Aal2 link CAC, AvailableCellRate (ACR):
UA 5-0:
As an option the ACR definition is either:

- per IuxIf ACR = ECRgcac for all the aal2 paths under one IuxIf whatever the Path
aal2Qos,
- per aal2Qos ACR = ECRgcac for all the aal2 paths with the same aal2Qos,
- per aal2Path ACR = Path ECRgcac.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 38/48

UA 4-2:
aal2Qos,
- per aal2Qos ACR = ECRgcac for all the aal2 paths with the same aal2Qos,
UA 4-1:

aal2Qos.
- per aal2Qos ACR = ECRgcac for all the aal2 paths with the same aal2Qos.
UA 4-0 and previous:
ACR = ECRgcac for all aal2 path under one IuxIf whatever the Path aal2Qos.
Aal2 link CAC, EquivalentBitRate (EBR):

UA 5-0:
One EBR values is set per RAB and per Utran interface (FRS27083).
UA 4-1:
One EBR values is set per RAB, it applies to all the Utran interfaces.
4.3.4 AAL2 PC CAC

UA 4&3:
The PC-CAC is active on RNC.
4.3.5 ALCAP
UA 4-2 :
- Alcap is implemented in the PMC-M.
- The Alcap is partly compliant with [R46], the RNC Alcap inserts the aal2Qos information in the
Alcap ERQ.
UA 4-1 & previous release:

- Alcap is implemented in the TMU.
- Alcap is based on [R45].
4.3.6 AAL2 COMPONENTS

UA 4-2 :
The IuxIf component is replaced by the IurIf and Aal2If components

Within the ALU RNC, each adjacent aal2 node (aal2Switch or neighbor RNC) is identified by one
IuxIf instance.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 39/48
4.3.7 A2EA
UA 4-2:
RNC aal2 Translation Table:
- Up to 128 A2EA 20 bytes length or 128 A2EA prefix,

- Up to 32 A2EA 20 bytes length or 128 A2EA prefix associated to one Alcap PC,
UA 4-1:
RNC aal2 Translation Table:
- Up to 32 A2EA 20 bytes length associated to one Alcap PC,
4.3.8 QAAL2 ALTERNATE ROUTING

UA 4-2 :
Supported.

Not supported.
4.4
SS7
SS7 Stack migration:

UA 4-0:
The MTP3B the saalNni and the Alcap protocols are implemented in the RNC-IN within the PDCSaalNni and AP-NI components.
UA 3-1:
The MTP3B the saalNni and the Alcap protocols are implemented in the RNC-CN.
SS7, PC amount:
UA 5-0:
The RNC supports up to 64 PC on the UTRAN.
UA 4-2:
The RNC supports up to 43 PC on the UTRAN.
Alcap PC:
UA 4-1 & 4-2:

The RNC supports up to 10 Alcap destination PC per neighbor RNC,
UA 4-0:
The RNC supports up to 2 Alcap destination PC per neighbor RNC,
SS7 Topology:
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 40/48

UA 4-1:
The RNC supports the quasiAssociatedMode and Associated Mode.
Up to UA 4-0 and previous:
The RNC supports only the Associated Mode.
Aal2 Topology:
4.5
UA 4-2:
The RNC supports up to 10 aal2Switches on each aal2 interface.
Up to UA 4-1:
The RNC supports up to 2 aal2Switches on each aal2 interface.
SOC
MTP3 SOC:
- MTP3 and MTP3-B are supported (not concurrently);
ITU-T and China variants are supported;
When changeOver occurs, non transmitted and non acknowledge MSU are discarded.
This MTP3 implementation does not support the following:

-
Route management
Signaling Transfer Points
Forced rerouting
Controlled rerouting
Multiple congestion thresholds
SCCP SOC:
SS7 Stack migration to RNC-IN:
-
ITU-T Q.711-715 (1996) is supported;
Class 0 and Class 2 are supported;
Class1 and Class 3 are not supported;
Global Title Translation not supported;
Congestion Control is not supported (SCC is not supported);
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 41/48
5 TRANSPORT IDENTIFIERS
5.1
VPC
To cover the case of Iur and Iu traffic sharing the same RNC link, the Iur vpi range values must be
different from the Iu vpi range values. Beside it is not forecasted to transmit the Iu, Iur and Iub traffic on
one single stm1 link.
Reserved Iur Vpi values:
-
Initial Iur Vpi range: [ 3 to 22 ] + [ 34 to 39 ]
Extension Iur vpi range: [40 to 49] (note)
Note :
- If both Iur and IuCS atm connections are configured on the same RNC link, verify that that the vpi
= [40 to 49] is not already used on the IuCS interface. If this range is used then select a range of vpi
already assigned to another CS coreNetwork node and not used.
-
5.2
Another alternative is to configure the Iur vcc on two RNC stm1.
MIGRATION FROM UA5 TO UA6

Prerequisite: Initialy 16 vci were reserved for rnsap, and 16 vci reserved for alcap. Before upgrading
reduce each amount of vci to 8, the bottom range of the previously assigned values.
UA5-1 => UA6

Without Hspa Streaming
UA6
Add Hspa Streaming
advancedQos set to disable
advancedQos set to enable
Shared bwPool
- 2 DS cbr vcc, TDDS
- 2 nDS rtVbr vcc, TDNDS
- 1 or 2 Hspa ubr vcc
Shared bwPool
=> sharedForAllTrafficTypes
- 2 qos0 cbr vcc, TDDS
- 2 qos1 rtVbr vcc, TDxx
- 2 qos2 nrtVbr vcc, TDNDS
- 1 or 2 qos3 ubr/ubr+ vcc
=> sharedForAllTrafficTypes
=> 2 qos0 cbr vcc, TDDS
=> 2 qos2 rtVbr vcc, TDNDS
=> 1 or 2 qos3 ubr/ubr+ vcc
TransportMap:
- Iur aal2If linked to transportMap/1
TransportMap:
- Iur aal2If linked to transportMap/1
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 42/48
5.3
CONTROL PLANE
5.3.1 ATM VCC

SS7 Signalling Links are used for carrying RNSAP and ALCAP signalling.
As discussed in SS7 section, either
-
one single routeSet is configured per Iur interface, identified by PCRNC and PCneighborRNC, then the
SL within the routeSet carry both RNSAP and Alcap, or
one RNSAP dedicated routeSet identified by PCRNC and PCneighborRNC and one or several ALCAP
routeSets identified by PCRNC and PCAlcapNeighborRNC are configured.
In the case of the Iur interface composed of two ALU RNC, one single routeSet is configured.
In any cases, one Iur CP vcc is associated to each SL.
According to ITU, one routeSet is composed of up two 16 SL, moreover it is recommended to configured at
least 2 SL per routeSet, furthermore the amount SL within a routeSet should be a 2 power of n.
In a broadband context, assume up to 8 SL is enough per routeSet.
The rule below provides the suggested vpi.vci on the RNC side for the Iur CP vcc:
Iur
without hspa stream

Vcc name:
qos0 vcc
aal
aal2
SC
cbr
Vpi
qos2 vcc
qos3 vcc
CP Rnsap
CP Alcap
aal2
aal2
aal5
aal5
rtVbr
ubr
rtVbr
rtVbr
< 33
and
34 < 39
48
Vci
to
49
#
2
50
52
32
54
to
to
to
to
51
53
39
61
2
2
8
8
Table 5-1, Iur CP vcc
Remark: The table is applicable as long as the vpi: [40-49] are not already used by the IuCS.
5.4
USER PLANE
The Iur UMTS userPlane traffic uses the services from aal2 /atm.
5.4.1 IURIF AND AAL2IF:

Each neighbor RNC is identified in the local ALU RNC by one IurIf instance. The table below provides the
suggested IurIf range:
iurIf
Interface:
Iur
Values
to
36
#
36
Table 5-2, IurIf reserved values

ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 43/48

Remark: The ALU RNC may be configured with up to 36 neighbours RNC.
In case of no aal2Switch on the Iur interface, one aal2if instance is assigned per neighbour RNC, else one
aal2if is assigned per adjacent aal2Switch. The table below provides the suggested Iur aal2If range:
aal2If, no aal2 switch

Interfaces:
Iub
Iub extension
Iu
Iu extension
Iur
Iur extension
Values
1
to
299
600
to
2700
300
to
349
375
to
564
350
to
374
1225
to
1235
#
299
2101
50
190
25
11
Table 5-3, Iur aal2If reserved values
The pool of aal2if supported by the ALU RNC may be shared between the Iur and the IuCS interface, in the
case of aal2Switch (es) inserted on the IuCS and Iur interface.
Remark: The aal2If dedicated to the Iub interface can not be shared with the other Utran aal2 interfaces.
The table below provides the suggested aal2If range in case of aal2Swiching function applying to both IuCS
& Iur interface:
aal2If, aal2 switches Iucs/Iur
Interfaces:
Iu/Iur
300
Values
to
309
#
10
Table 5-4, Iur aal2If reserved values case of aal2Switch
5.4.2 AAL2 PATHID:

The amount of requested aal2 Paths on the Iur interface depends on the amount of mobiles in
InterRNCSHO, it results from an UMTS dimensioning exercise on the Iur interface.
Without specific Dimensioning calculation:

- As long as the hspa streaming is not activated, it is suggested per default: 2 qos0 paths, 2 qos2 paths and 1
or 2 qos3 vcc per Iur interface.
- Since the hspa streaming is activated, it is suggested to add 2 qos1 vcc per neighbor RNC.
Therefore per default: 2 qos0 paths, 2 qos1 paths, 2 qos2 paths and 1 or 2 qos3 vcc per Iur interface.
A RNC supporting up to 36 neighbors RNC, then are reserved 72 qos0 pathId values, 72 qos1 pathId values,
72 aal2Qos2 pathId values and 72 aal2Qos2 pathId values.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 44/48

The pathId must be unique under one aal2 interface identified by one aal2If instance, beside it is not
necessary that the pathId values are unique over all all2 interfaces of the RNC.
Remark:
In such a way to make protocol analysis easier, it was agreed to avoid overlap between Iur and IuCS
PathId values, since Iur and IuCS traffic may share the same transmission link.
Since it is not forecasted that Iub traffic share the same transmission link as Iur and IuCS traffic, it was
agreed to allow overlap between Iub pathId and (IuCS, Iur) pathId values.
The rule below provides the suggested pathId values for the Iur interface; it encompasses the range assigned
in previous releases and an extended range to cover the current release requirement:
without hspa stream
Path
Iur
QOS
qos0
qos2
qos3
4425
4569
PATHID
to
4472
to
4592
4473
4593
4521
4617
to
to
to
to
4520
4616
4568
4640
#
48
24
48
24
48
24
Table 5-5, Iur Pathid reserved values, case of no hspa streaming
with hspa stream

Path
Iur
QOS
qos0
qos1
qos2
qos3
4425
4569
4641
4473
4593
4521
4617
PATHID
to
to
to
to
to
to
to
4472
4592
4712
4520
4616
4568
4640
#
48
24
72
48
24
48
24
Table 5-6, Iur Pathid reserved values, case of hspa streaming
5.4.3 ATM VCC:

One Iur UP vcc is associated to each aal2 Path. As a result there are as many Iur UP vcc as Iur aal2 Paths.
Since up to four different qos are configured at the aal2 level, up to four different qos are configured at atm
level.
The rule below provides the suggested atm connection identifiers according to hspa streaming is enable or
not:
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 45/48
Iur
without hspa stream

Vcc name:
qos0 vcc
aal
aal2
SC
cbr
Vpi
qos2 vcc
qos3 vcc
CP Rnsap
CP Alcap
aal2
aal2
aal5
aal5
rtVbr
ubr
rtVbr
rtVbr
< 33
and
34 < 39
48
Vci
to
49
#
2
50
52
32
54
to
to
to
to
51
53
39
61
2
2
8
8
49
41
51
53
39
61
#
2
2
2
2
8
8
Table 5-7, Iur UP vcc, case of no hspa streaming
Iur
with hspa stream

Vcc name:
qos0 vcc
qos1 vcc
qos2 vcc
qos3 vcc
CP Rnsap
CP Alcap
aal
aal2
aal2
aal2
aal2
aal5
aal5
SC
cbr
rtVbr
nrtVbr
ubr
rtVbr
rtVbr
Vpi
< 33
and
34 < 39
48
40
50
52
32
54
Vci
to
to
to
to
to
to
Table 5-8, Iur UP vcc, case of hspa streaming
Remark: These tables are applicable as long as the vpi: [40-49] are not already used by the IuCS.
5.5
TRAFFIC CONTRACT
The trafficDescriptor values are specific to a network; they depend on the customer traffic expectation on
the interface and the customer strategy.
The setting of the atm TrafficDescriptor is the result of an UMTS Traffic Dimensioning study , which uses
as input:
- The customer trafficModel,
- The node hardware composition (eg: #RNC PSFP, ),
- The result of the network architecture studies (eg: #SL, VP formation, transmission
ports assignment to UMTS interfaces).
The trafficDescriptor values are taken into account by:

- the atm CAC when configuring the pvc, and at pnni sPvc establishment,
- the RNC Transport admissionControl,
- AS AN OPTION, by the trafficShaping if activated.
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 46/48
6 ABBREVIATIONS
A2EA
AAL2 Service Endpoint Address
AAL
ATM Adaptation Layer
AAL2 CPS
Common Part Sublayer
AAL2 SSSAR
Service Specific Segmentation and Reassembly
AAL5 CP
Common Part (CPCS & SAR)
AAL5 SSCS
Service Specific Convergence Sublayer (=SSCF-NNI or SSCF-UNI)
AESA
ATM End System Address
ALCAP
Access Link Control Application Part
APS
Automatic Protection Switching
ASP
ATM Service Provider
CP
Control Port
CPCH
Common Packet Channel
CCP
Communication Control Port
CID
Channel IDentifier (aal2)
DchFP
Dedicated Channel Frame Protocol
DRNC
Drift RNC
DS
Delay Sensitive
DSCH
Downlink Shared Channel
EP
Emission Priority
FACH
Forward Access Channel
FP
Functional Processor (Passport definition)
GMM
GPRS Mobility Management
NBAP-c
NBAP common
NBAP-d
NBAP dedicated
NDS
Non Delay Sensitive
NNI
Network to Network Interface
OEM
Other Equipment Manufacturer
PCH
Paging Channel
PNNI
Private NNI
POC
Point Of Concentration
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 47/48

POR
Plan Of Record
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 Subsystem
RRM
Radio Resource Management
SC
Service Category
SPVC
Soft Permanent Virtual Circuit
SRB
Signalling Radio Bearer
SRNC
Serving RNC
STC
Signalling Transport Converter (Q2150.1)
TMU-R
Traffic Management Unit (RNC-CNODE card)
UNI
User to Network Interface
UP
User Plane
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 (ATM network entity that unbundles a VPC into its VCC
elements for processing)
VR
Virtual Router
END OF DOCUMENT
ALU confidential
UMT/IRC/APP/12509
06.02 / EN
Standard
11/06/2009
Page 48/48

Iur Teg Ua6 External Ed 06.02 STD 090611

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Iur Teg Ua6 External Ed 06.02 STD 090611

Hochgeladen von

Copyright:

Verfügbare Formate

Iur Transport, engineering guide

Copyright 2007 Alcatel-Lucent, All Rights Reserved

Iur interface, engineering guide

FRS 29869 RNC Dimensioning,

FRS 30744.9 Hsupa over Iur,

FRS 33912 #neighbor RNC,

FRS 34202 BwPool,

FRS 34220 dual stack SS7,

FRS 34237 RateController,

FRS 34012: hsdpa supported

FRS 27083: RNC aal2 linkCac enhancement,

FRS 30089: Up to 24 neighbor RNC,

FRS 30782: 16pOC3 MS3 FP

- First UA4-2 IurTEG edition.

First UA4-1 IurTEG Edition

Modification for UA04-0:

- Indication: PNNI not supported on Iur.

Iur interface, engineering guide

SCOPE OF THIS DOCUMENT .......................................................................................................5

AUDIENCE FOR THIS DOCUMENT ................................................................................................5

RELATED DOCUMENTS ......................................................................................................7

TRANSPORT NETWORK LAYER, DESCRIPTION .............................................................9

INTERWORKING CASES ...........................................................................................................28

Hspa plane ....................................................................................................................32

VARIATIONS BETWEEN RELEASES................................................................................37

Aal2 Path assignment to PMC-PC ................................................................................38

Iur interface, engineering guide

MIGRATION FROM UA5 TO UA6...............................................................................................42

CONTROL PLANE ....................................................................................................................43

Iur interface, engineering guide

Transport layers description in the context of the UMTS Iur interface,

SCOPE OF THIS DOCUMENT

This document covers:

AUDIENCE FOR THIS DOCUMENT

Operators, R&D, WPS, VO, Trial, networkDesign.

UMTS UTRAN System Architect

Iur interface, engineering guide

Iur interface, engineering guide

Iur interface, engineering guide

Iur interface, engineering guide

Synchronous Optical Network (SONET)

NTP ATM TrafficManagement

3 TRANSPORT NETWORK LAYER, DESCRIPTION

Iur interface, engineering guide

Iur interface, engineering guide

Iur interface, engineering guide

Iur interface, engineering guide

RNC TRANSPORT CHARACTERISTICS

3.7.2 FP AND PSFP

3.7.3 SS7 PROTOCOL STACK

3.7.5 AAL2 QOS

Iur interface, engineering guide

3.7.6 AAL2 COMPONENTS

Iur interface, engineering guide

pathOwner [Yes, No]

Alcap bearer: Adjacent aal2 node.

IurIf 10 IurIf 11 IurIf 12

Iur interface, engineering guide

3.7.6.1 AAL2 PATH ASSIGNMENT TO PMC-PC

3.7.6.2 AAL2 CID SELECTION

CID election since the Path is chosen:

Iur interface, engineering guide

3.7.6.3 AAL2 TRANSLATION TABLE