Iub Transport Engineering GuideUMT IRC APP 007149 V06.02

Iub Transport Engineering Guide
Document number: UMT/IRC/APP/7149

Document issue: 06.02 / EN
Document status: Standard
Date: 02/12/2007
Author: 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 UMTS Date ReasonsForChange
Edition Release:
6-2 5-1 25/09/07 § 3.7.11: Icn: removed

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

the congestionManagement.
6-0 18/07/07 Add §3.7.9.1.4 1 IMA and 2 bwPool .
Updated with CR:
- upd of §5 with several hspa vci .
10/07/07 - §3.8.1.1 NodeB CEM upd

- Nodeb ima defense update for IMA Hspa.
- FRS 33118: nE1 & 1 IMA over iCCM,
- FRS 33865,
- FRS 34094: Hspa over xPcm
- FRS 31830: 2 IMA groups on xCCM,
- picoNodeB updates.
5-0 5-0 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.
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
42-2 4-2 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.
42-1 05/01/05 §3.9.7: IMA LG Bw Reduction mechanism update
ALU confidential
UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

Page 3/198
§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.
4.1 4-0 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
§ 3.8, NodeB CRC4 added
4.0 4-0 01/08/04 Review UA 4-1, 25/07/04
Removal of Iub TrafficDescriptor values.
UA 4-1 Update:
& §3.7: MSA SparingPanel added
SS MSA32 FP added
2pStm1 e Ch FP added
3
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

Page 4/198
CONTENTS
1 INTRODUCTION ..................................................................................................................10
1.1 OBJECT ..................................................................................................................................10
1.2 SCOPE OF THIS DOCUMENT .....................................................................................................10
1.3 AUDIENCE FOR THIS DOCUMENT ..............................................................................................11
2 RELATED DOCUMENTS ....................................................................................................12
3 IUB TRANSPORT NETWORK LAYER, DESCRIPTION ....................................................15
3.1 TRANSMISSION .......................................................................................................................16
3.1.1 PDH:..............................................................................................................................16
3.1.2 SDH/SONET: ................................................................................................................19
3.2 ATM ......................................................................................................................................27
3.2.1 ATM interface Type .......................................................................................................27
3.2.2 VPC, VPT ......................................................................................................................28
3.2.3 OverSubscription...........................................................................................................34
3.2.4 CAC...............................................................................................................................34
3.2.5 Traffic Management ......................................................................................................36
3.2.6 QOS ..............................................................................................................................41
3.2.7 Fractional E1/T1 ............................................................................................................50
3.2.8 Addressing ....................................................................................................................56
3.2.9 PNNI..............................................................................................................................56
3.2.10 IMA ...............................................................................................................................60
3.2.11 ATM OAM......................................................................................................................65
3.3 AAL2.....................................................................................................................................72
3.3.1 Addressing ....................................................................................................................72
3.3.2 QOS ..............................................................................................................................73
3.4.1 CES IWF: ......................................................................................................................73
3.4.2 SDT/UDT:......................................................................................................................78
3.4.3 Full/PartialCell Fill: ........................................................................................................78
3.4.4 Reassembly buffer ........................................................................................................80
3.4.5 Qos:...............................................................................................................................82
3.4.6 TrafficManagement: ......................................................................................................83
3.4.7 Interaction with other services:......................................................................................85
3.5 IP ..........................................................................................................................................86
3.5.1 DHCP ............................................................................................................................86
3.5.2 InverseARP ...................................................................................................................86
3.5.3 SiteLAN .........................................................................................................................88
3.6 IUB TOPOLOGY .......................................................................................................................88
3.6.1 Iub Topology:.................................................................................................................89
3.6.2 Iub Topology with PP15k-POC: ....................................................................................90
3.6.3 Atm ring on Iub ..............................................................................................................91
3.7 RNC ......................................................................................................................................93
3.7.1 ASIC ..............................................................................................................................93
3.7.2 FP..................................................................................................................................93
3.7.3 RNC Types..................................................................................................................110
3.7.4 Aal2 Components:.......................................................................................................112
3.7.5 Aal2 Paths ...................................................................................................................113
3.7.6 Aal2 Path assignment to PMC-PC ..............................................................................113
3.7.7 Aal2 CID Distribution ...................................................................................................114
3.7.8 Aal2 CAC.....................................................................................................................115
3.7.9 Aal2 Congestion Management....................................................................................121
3.7.10 QOS ............................................................................................................................139
3.7.11 Hspa CAC ...................................................................................................................140
3.8 NODE B................................................................................................................................140
3.8.1 Cards...........................................................................................................................140
3.8.2 Transmission Layer: ....................................................................................................142
3.8.3 Synchronisation...........................................................................................................143
ALU confidential

Page 5/198
3.8.4 ATM Connections:.......................................................................................................143

3.8.5 MultiPCM.....................................................................................................................144
3.8.6 IMA ..............................................................................................................................144
3.8.7 Mix of N * E1 xPCM and p E1 IMA..............................................................................147
3.8.8 QOS ............................................................................................................................148
3.8.9 Traffic Management ....................................................................................................150
3.8.10 Hspa CAC ...................................................................................................................151
3.9 MICRO NODEB ATM (BTS 1120) ...........................................................................................152
3.9.1 Transmission: ..............................................................................................................152
3.9.2 Atm: .............................................................................................................................153
3.9.3 Aal2 .............................................................................................................................155
3.9.4 SAAL: ..........................................................................................................................155
3.9.5 IP: ................................................................................................................................156
3.9.6 UMTS traffic flows: ......................................................................................................157
3.10 PICO NODEB ATM (BTS 1010) ...............................................................................................158
3.10.1 Transmission: ..............................................................................................................158
3.10.2 Atm: .............................................................................................................................158
3.10.3 Aal2: ............................................................................................................................159
3.10.4 IP: ................................................................................................................................160
3.10.5 UMTS traffic flows: ......................................................................................................160
3.11 MSS ....................................................................................................................................160
3.11.1 IMA .............................................................................................................................160
3.11.2 Iub Topology:...............................................................................................................162
3.11.3 NAM connectivities:.....................................................................................................163
3.11.4 NAM ATM Characteristics:..........................................................................................164
3.11.5 NAM Interworking with other Features:.......................................................................164
3.11.6 NAM ATM Configuration .............................................................................................165
3.12 PLANE DESCRIPTION .............................................................................................................168
3.12.1 HSUPA Plane..............................................................................................................168
3.12.2 HSDPA Plane..............................................................................................................169
3.12.3 OAM Plane ..................................................................................................................172
3.12.4 Control Plane...............................................................................................................180
3.12.5 User plane ...................................................................................................................181
3.12.6 ATM Backbone Requirements ....................................................................................186
4 UMTS RELEASES .............................................................................................................187
4.1 RNC ....................................................................................................................................187
4.1.1 FP................................................................................................................................187
4.1.2 RNC Types:.................................................................................................................189
4.1.3 RNC capacity: .............................................................................................................189
4.1.4 Iuxif / IubIf / aal2If:.......................................................................................................190
4.1.5 Pathid: .........................................................................................................................190
4.1.6 Aal2 Path assignment to PMC-PC ..............................................................................190
4.1.7 AAL2 Link CAC: ..........................................................................................................190
4.1.8 aal2CongestionManagement ......................................................................................191
4.1.9 Icn VCC .......................................................................................................................191
4.1.10 TMU.............................................................................................................................191
4.2 NODEB ................................................................................................................................192
4.2.1 CCM related: ...............................................................................................................192
4.2.2 CEM related: ...............................................................................................................192
4.2.3 MultiPCM:....................................................................................................................193
4.2.4 IMA: .............................................................................................................................193
4.2.5 n E1 xPCM + p E1 IMA: ..............................................................................................194
4.2.6 AAL1 CES ...................................................................................................................194
4.2.7 QOS ............................................................................................................................194
4.2.8 Traffic Management ....................................................................................................195
4.3 MICRO NODEB .....................................................................................................................196
4.4 PICO NODEB ........................................................................................................................196
4.5 NAM....................................................................................................................................197
4.6 PLANE RELATIVE ...................................................................................................................197
ALU confidential

Page 6/198
4.6.1 UMTS HSUPA Plane: .................................................................................................197

4.6.2 UMTS HSDPA Plane: .................................................................................................197
4.6.3 UMTS OAM Plane:......................................................................................................197
4.6.4 UMTS Control Plane: ..................................................................................................197
4.6.5 UMTS User Plane .......................................................................................................197
4.6.6 Transport Network ControlPlane:................................................................................198
5 CONFIGURATION RULES................................................................................................198
5.1 ATM VCC CONFIGURATION RULE .........................................................................................199
5.1.1 NodeB interface ..........................................................................................................199
5.1.2 RNC Iub Interface .......................................................................................................200
5.1.3 PNNI............................................................................................................................202
5.2 FP ATTRIBUTES ....................................................................................................................204
5.2.1 16pOC3/Stm1 FP Attributes........................................................................................204
5.2.2 16pOC3/Stm1 Atm/Pos FP .........................................................................................211
5.2.3 MSA32 FP Attributes...................................................................................................213
5.3 AAL2...................................................................................................................................214
5.3.1 IubIf / aal2If..................................................................................................................214
5.3.2 IuxIf..............................................................................................................................215
5.3.3 Pathid: .........................................................................................................................215
5.3.4 AAL2 CAC ...................................................................................................................216
5.4 IMA .....................................................................................................................................216
5.4.1 NodeB Holding Priority................................................................................................216
5.4.2 PassPort Holding Priority ............................................................................................217
5.4.3 IMA LinkGroup ID:.......................................................................................................220
5.4.4 Traffic descriptor .........................................................................................................220
5.5 TRAFFIC CONTRACT..............................................................................................................220
5.5.1 Iub Traffic Descriptor, Release 4.................................................................................220
5.6 PARAMETERS .......................................................................................................................221
5.6.1 Traffic Descriptor Type................................................................................................221
5.6.2 Parameter Class .........................................................................................................221
6 ABBREVIATIONS..............................................................................................................222
ALU confidential

Page 7/198
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.
Note that two topology cases are considered:
- NodeB – ATM Backbone – RNC_SDH, and
- NodeB – RNC_PCM point to point connections.
1.2 SCOPE OF THIS DOCUMENT

The document is related to UMTS Release5-1.
Variations with previous releases are indicated in section 4.
UMTS system Release: UMTS03 UMTS 4-0 UMTS 4-1 UMTS 5-0
RNC Release: UA3 UA4.0 UA4.1 UA4.2 UA5.0

Passport Release: PCR4.1.1 for RNC PCR 4-1 SSUP4 PCR6-1 PCR7-2
PCR4.1.2 for MSS7k
CS CoreNetwork NSS16 NSS16, NSS18 and NSS19

Release:
Passport Release: PCR 4-2 PCR7-1
PS CoreNetwork PC03 PC04 PC05

Release:
Passport Release: PCR4-2 PCR5.2.2 PCR6-2
AN: PCR7-1
POC Release:
Passport Release: PCR4.1.x PCR4.1.4 PCR5.2.2 PCR6.1.1
OAM Release: OAM3 OAM4.1 OAM4.2 OAM5.0
This document covers:

- TRANSPORT network layers (Transmission, ATM, aal2, aal5, IP, …) relative to the
Iub interface,
- UMTS Nodes: NodeB and RNC and Remote E1 Concentrator called POC (case of
PP7k), and NAM. OtherVendor POC is not covered in this document.
- Impact of ATM backbone on the interface.
ALU confidential

Page 8/198
1.3 AUDIENCE FOR THIS DOCUMENT

UMTS NetworkDesign, R&D, OCAN, Customers.
ALU confidential

Page 9/198
2 RELATED DOCUMENTS
[ 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.
[[ R
R 21
22
23
24 ]] 3GPP TS 25.309 Rel6 FDD Enhancement Uplink, overall description, stage 2 (Release 6)
[ 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 User Adaptation (M3UA) Layer
[ R 75 ] RFC 2960 SCTP, Stream Control Transmission Protocol
[ R 76 ] RFC 3309 SCTP, Stream Control Transmission Protocol
ALU confidential

Page 10/198
[ R 80 ] GR253 Synchronous Optical Network (SONET)

[[ R
R 81
82
83 ]] GR2878 ATM HSL
[[ R 84
85
86 ]
R 87
88
89 ]
[ R 90 ] 241-5701-705 NTP ATM TrafficManagement
[ R 91 ] 241-5701-706 NTP ATM TrafficShaping and Policing
[ R 92 ] 241-5701-707 NTP ATM Queuing and Scheduling
[ R 93 ] 241-5701-708 NTP ATM CAC and Bandwidth
[[ R 94
95
96 ]] 241-5701-702 NTP Routing and Signaling
[ R
R 97
98
99 ]
[ R 100 ] UMT/IRC/APP/007147 PEI NodeB
[R R 101
102
103 ]] UMT/IRC/APP/7146 PEI RNC
[[[ R
R 104
105
R 106
107
108 ]]] UMT/DCL/DD/0020 UPUG
[R 109
110
111 ]
112
[ R 113
114 ]
115
[ R 116
117 ]]
118
[ R 119
[ R 120 ] 3GPP TS 23.002 R4 Network Architecture
[ R 121 ] 3GPP TS 23.221 Architectural Requirements
[ R 122 ] 3GPP TS 23.205 BICN; Stage 2
[ R 123 ] 3GPP TS 29.205 Application of Q.1900 Series to BICN Architecture; Stage 3
[ R 124 ] 3GPP TS 29.232 MGC, MG Interface, Stage 3”, Release 4
[ R 125 ] 3GPP 29.414 CN Nb Data Transport and Transport Signaling
[ R 126 ] 3GPP 29.415 CN Nb interface User Plane Protocols
[ R 127 ] 3GPP 29.232 TFO package
[ R 128 ]
[ R 129 ]
[ R 130 ]
[ R 150 ] FRS 25647 aal2LinkCac evolution
3 IUB TRANSPORT NETWORK LAYER,

DESCRIPTION
In UTRAN, the NodeB Signaling, userData and UMTS OAM are carried to the RNC over the Iub ATM
interface.
The Iub protocol stacks is specified by the 3Gpp.
The following ATM Adaptation layers are implemented on Iub [R60, R61]:
- AAL5 format is used for CP and ManagementPlane:
- NBAP common & dedicated,
- UMTS and ATM OAM flows,
- ALCAP,
- AAL2 format is used for UP:
- User traffic (Voice and Data),
- RRC (Radio Resource Control) Signaling, and RRC-User protocols:
- MM: Mobility Management,
- SM: Session Management,
- CC: Call Control,
- GMM: GPRS Mobility Management...
The SM, MM, GMM and CC are Non Access Stratum signaling (between the UE and the
Core Network) seen as “User data” from the Transport network. Such information, are
carried in following channels:
- Common SRB (SignallingRadioBearer): FACH, PCH and RACH
- Dedicated SRB.
ALU confidential

Page 11/198
This document covers the Transport Network layers.
Control Plane O&M User Plane
Network
Radio
Layer
RACH
DSCH
CPCH
FACH
DCH
PCH
NBAP c & d O&M
ALCAP
Transport Layer
SAAL UNI
SSCF-UNI IP
SSCOP Q2110
AAL5 AAL2
ATM
Physical
Node-B RNC-IN
Iu b
Figure 3-1IUB Protocol stack
Remark: ALCAP is not implemented on ALU UMTS Iub nodes.

CID value is assigned by RNC. AAL2 Connection is established between RNC and NodeB, by means
of NBAP RadioLinkSetup message containing CID .
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,
- 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 125µs.
ALU confidential

Page 12/198
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 doesn’t 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
F Header
F
F Header
F
F Header
F
ATM cell mapping field: 24 octets (TS1 ~ TS24)
Provides F3 OAM functions: ATM Header

– Detection of loss of frame alignment cell
– Performance monitoring (CRC-6)
– Transmission of FERF and LOC 53 octets T1302260-93
– Performance reporting
Since T1 payload is 192 bits each 125 µs, throughput available for ATM is 1,536 Mb/s,
Rule: IubTEG_T1_1
T1 ATM throughput is 1,536 Mb/s = 3622 Cells/s.
The first bit of a frame is designated an F-bit, and is used for:

- Performance monitoring, CRC6,
- Transmission OAM Signals
- Detection of loss of frame alignment.
For more information refer to [R47 & 48].
3.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.
ALU confidential

Page 13/198
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.
7 * T2 T3 T3 overhead
Throughput 7 * 6312 = 44 184 kb/s 44 736 kb/s 552 kb/s
# Bits 7 * 789 = 5523 bits 4760 bits (note) 56 bits
# Timeslot 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

Page 14/198
X1 F1 C11 F2 C12 F3 C13 F4

X2 F1 C21 F2 C22 F3 C23 F4
P1 F1 C31 F2 C32 F3 C33 F4
P2 F1 C41 F2 C42 F3 C43 F4
M1 F1 C51 F2 C52 F3 C53 F4
M2 F1 C61 F2 C62 F3 C63 F4
M3 F1 C71 F2 C72 F3 C73 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

Page 15/198
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:
Throughput Throughput
SDH SONET
Throughput User in User in
Level Level
Mb/s Cells/s
STM1 STS3 =
Clear OC3
155,52 Mb/s 149,76 Mb/s 353 207
Chann Concate
el nated
STS12
STM4 622,08 Mb/s 1 412 828
= OC12
Notation:
- STM-n stands for SynchronousTransfertModule level n. It identifies the level of SDH
signal.
- STS-n stands for SynchronousTransfertSignal level n. Electrical specification for signal
generation level.
- OC-n stands for OpticalCarrier level n: Optical specification for signal generation level.
3.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:
ALU confidential

Page 16/198
Carries Maintenance and Status signals related to SDH MultiplexSection / SONET Line.
- LowOrder Section OAM flow:
Carries Maintenance and Status signals related to SDH lowOrder PathSection / SONET
Path.
- HighOrder Section OAM flow:
Carries Maintenance and Status signals related to SDH highOrder PathSection / SONET
Path.
The mechanisms to provide OAM functions and to generate Transmission OAM flows depend on the
transport mechanism of the transmission system as well as on the supervision functions contained
within the physical layer termination functions of equipments. Three types of transmission can be
provided in ATM networks:
- SDH-based transmission systems;
- PDH-based transmission systems.

- Cell-based transmission systems;
Rule: TEG_SDH_OAM_1
On ALU nodes, the OAM Flow Type of Transmission implemented is SDH/PDH based. Not Cell
based.
The following transmission status event may be detected:

- LOS (Loss Of Signal): disconnection, idle signal, unequipped signal [R53, R110].
An LOS defect is detected when an all-zeros pattern on the incoming SDH/SONET
signal lasts 100 µs or longer. If an all-zeros pattern lasts 2.3 µs or less, an LOS defect is
not detected.
The 16-port OC-3 function processor does not monitor signal level for loss.
- LOF (Loss Of Frame):
An SEF (Severely Errored Framing) condition is detected when the incoming signal has
a minimum of four consecutive errored RSOH A1-A2 framing patterns.
A LOF defect is triggered when an SEF condition persists for 3 ms.
The following Maintenance signals may be generated on different kinds of transmission OAM levels:
- AIS (Alarm Indication Signal):
AIS signal notifies the adjacent downstream node that a failure has occurred upstream.
AIS may be generated at MultiplexSection, LowOrder and HighOrder PathSection level.
The SDH MS-AIS is renamed L-AIS in SONET.
AIS triggers: LOS, LOF condition within 125 µs on the incoming link.
The MS-AIS is generated in a STM-N / OC-N that contains a valid MultiplexSection
overhead, the K2 byte indicating MS-AIS and a all-ones pattern in the payload:
K2 byte Bits 6, 7, 8
111 MS-AIS
The HO & LO P-AIS are coded with as all one in the container and Path pointers.
ALU confidential

Page 17/198
- RDI (Remote Defect Indication):
RDI signal notifies the adjacent upstream node that a failure has occurred upstream.
RDI may be generated at MultiplexSection, LowOrder and HighOrder PathSection level.
The SDH MS-RDI is renamed L-RDI in SONET.
RDI triggers:
- LOS, LOF condition within 125 µs,
- Reception of AIS signal.
Remark: FERF is the old name for RDI.
The MS-RDI is coded within K2 byte:

K2 byte Bits 6, 7, 8
110 MS-RDI
The HO and LO RDI are coded in one bit of the HO / LO container overhead.
Examples of AIS and RDI generation on UMTS interface composed of SDH nodes:
POH P-RDI
MSOH K1 K2
0000 0000 0000 0 000
1
POH P-AIS - -
UMTS
UMTS UMTS
UMTS
LOS Condition AIS
ATM
ATM ATM
ATM
crossConnect Regenerator Selected Line

TX
TX
Line 1
RX
RX TX
TX RX
RX TX
TX RX
RX
W W W W
RX
RX TX
TX RX
RX TX
TX RX
RX TX
TX
PTE
PTE PTE
PTE
MSTE
MSTE RSTE
RSTE
TX
TX Line 0
RX
RX TX
TX RX
RX TX
TX RX
RX
P P
RX
RX TX
TX RX
RX TX
TX RX
RX TX
TX
MultiPlex Section 1 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)
ALU confidential

Page 18/198
ATTRIBUTE Aps protectionLine (protection)

Both the Working and the Protected lines carry the same payload in the transmit direction, but only the
Working line is used for received payload.
At the node startup, workingLine is selected for receiving user payload data.
Nodes permanently monitor quality of the received signal. Based on these measurements, either node
keeps the working line selected or decides to select protectionLine for receiving user payload data; this
operation is referred as APS Switch.
RNC UMTS
ActiveCard Node
Node
16pOC3
16pOC3 WorkingLine 16pOC3
16pOC3
Rx
Rx Tx
Tx
1 STM1 STM1
RNC
Tx Rx
RNC Traffic
Tx Rx
SDH Network
… …
2
Traffic generator
Rx
Rx Tx
Tx
Tx
Tx Rx
Rx
Same Signal
generator
16pOC3
16pOC3
Rx
Rx STM1 Tx
Tx
STM1
Tx
Tx Rx
Rx
… Protected Line …
Rx
Rx Tx
Tx
Tx
Tx Rx
Rx
16pOC3
16pOC3
1 Duplication of the egress stream
2 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)
It’s recommended to configure LAPS on each RNC 16pOC3/Stm1 FP port.
ALU confidential

Page 19/198
Rule: TEG_SDH_APS-3
It is recommended to configure the LAPS component between each port of the pair of
16pOC3/Stm1 FP even so the protected fiber is not connected to the RNC 16pOC3/Stm1
FP.
Remark:
If LAPS component is configured whereas the protected fiber is not connected, one port is in LOS
condition and then alarms appear on the Management platform for the non connected fiber; to
remove these useless alarms either lock the non populated port (lock Lp/9 Sdh/i) or activate the
"alarm filtering" (W-NMS).
3.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
ALU confidential

Page 20/198
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 doesn’t provide APS.
Beside, per default, the Revertive mode is activated.
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 will revert the receive 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)
ALU confidential

Page 21/198
This attribute specifies the minimum (BER) for which a Signal Degrade failure is
declared. Its value is the exponent of the BER, with possible values of -5 through -9
inclusive, which correspond to a BER range of 10e-5 through 10e-9.
The switch initiation time for a Signal Degrade varies depending on the observed BER:
BER - Switch Initiation Time
10e-3 - 10 milliseconds
10e-4 - 100 milliseconds
10e-5 - 1 second
10e-6 - 10 seconds
10e-7 - 100 seconds
10e-8 - 16 minutes 40 seconds
10e-9 - 2 hours 46 minutes 40 seconds
The clearing threshold for a Signal Degrade is one-tenth the signalDegradeRatio; for
example, if the provisioned signalDegradeRatio is -5, the corresponding clearing
threshold will be 10e-6. The clearing time varies depending on the clearing threshold
(not the observed BER), and can be determined from the above table.
Remark:
Since the SD BER is higher (eg: 10-5 10-9), it is necessary to monitor more data to
measure the error ratio, if more data are monitored then measurement period is higher.
Eg:
- BER = 10-5 : 100 000 SDH frames 12,5 seconds
=> 8 000 SDH frames 1 second
- BER = 10-9 : 1 000 000 000 SDH frames 125 000 seconds
=> 80 000 000 SDH frames 2 hours, 46 minutes, 40 sec.
Moreover in case of bidirectional mode, a SDH node is notified by means of K1 and K2 bytes
that APS has been invoked in the remote node, APS is then invoked on the local node.
See MML Attributes for APS monitoring:
ATTRIBUTE Aps nearEndRequest (neReq)
ATTRIBUTE Aps timeUntilRestore
This attribute indicates the amount of time until the received active line is automatically
switched back from the protection line to the working line.
On following figures are represented failure conditions which triggered APS in UMTS node:
ALU confidential

Page 22/198
POH No Path OAM signal LOS Condition

MSOH K1 K2
UMTS
UMTS 0000 0000 0000 0 110 UMTS
UMTS
- MS-RDI
ATM
ATM ATM
ATM
Regenerator Regenerator
TX
Line 1 Selected Line
TX RX
RX TX
TX RX
RX TX
TX RX
RX
W W
RX
RX TX
TX RX
RX TX
TX RX
RX TX
TX
PTE
PTE PTE
PTE
RSTE
RSTE RSTE
RSTE
TX
TX
RX
RX TX
TX RX
RX TX
TX RX
RX
P P
RX
RX TX
TX RX
RX TX
TX RX
RX TX
TX
MultiPlex Section APS Invokation
POH No Path OAM signal

MSOH K1 K2
1101 0001 0000 0000
SF HP Work Prot Idle
Figure 3-5 APS switch on LOS Condition

Remark:
APS is configured on the 16pOC3 FP, if one line is in LOS condition:
- No P-RDI is returned to the farEnd (If P-RDI would be returned the farEnd would discard the
traffic),
- The MS-RDI is returned to the farEnd.
POH No Path OAM signal MSOH K1 K2

2 MSOH K1 K2 0000 0000 0000 0 111
1
0000 0 110 - MS-AIS
0000 0000 - MS-RDI
UMTS
UMTS UMTS
UMTS
LOS Condition AIS
ATM
ATM ATM
ATM
Regenerator Regenerator Selected Line

TX
TX
Line 1
RX
RX TX
TX RX
RX TX
TX RX
RX
W W
RX
RX TX
TX RX
RX TX
TX RX
RX TX
TX
PTE
PTE PTE
PTE
RSTE
RSTE RSTE
RSTE
TX
TX
RX
RX TX
TX RX
RX TX
TX RX
RX
P P
RX
RX TX
TX RX
RX TX
TX RX
RX TX
TX
MultiPlex Section APS Invokation
2 MSOH K1 K2
1101 0001 0000 0000
SF HP Work
Figure 3-6 APS switch on MS-AIS reception
ALU confidential

Page 23/198
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 NNI
NodeB POC RNC-IN
User side Network side Network side User side
On the POC / RNC interface PNNI may be implemented.
RNC-SDH, Iub interface with ATM backbone:
UNI Public UNI

NodeB POC ATM BackBone RNC-IN
UNI UNI
User side Network side 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.
ALU confidential

Page 24/198
NodeB E1/T1s can be connected directly to ASP network or connected to a POC before reaching the
ASP.
- When the NodeB is connected directly to the ASP network, without POC, in a multiPCM
configuration, it is recommended to use one VPC for each E1/T1 link that connects NodeB to
the ASP. The ASP provides the E1/T1 access port as well as the VPC across the network.
There are per nodeB as many VPC configured in the ASP as amount of E1/T1 per nodeB.
However, the OAM VCC must still be configured separately; explanation is given in
trafficShaping section.
1 E1/T1
VC UP DS
VC UP NDS
NodeB VP x , rtVBR
VC CP
x VC CCP
VC OAM VC OAM RNC-SDH

RNC-SDH
ATM Backbone
VP x1
16pOC3/STM1 FP
1 E1/T1 VP y1
VC UP DS
VP z1
NodeB VC UP NDS VP y, rtVBR
VC CP
y VC CCP
VC OAM VC OAM VCC OAM x

VCC OAM y
1 E1/T1 VCC OAM z
VC UP DS
NodeB VC UP NDS VP z , rtVBR
VC CP
z VC CCP
VC OAM VC OAM
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

Page 25/198
POC
VC OAM VCC OAM
NodeB VC UP DS
VC UP NDS
k=x VC CP
VC CCPn RNC-SDH
VPu, rtVBR
VPu, rtVBR
VC UP DS
ATM Backbone
VC UP NDS VPv, rtVBR
NodeB VC CP
VC CCPn
RNC-IN
k=y
VC OAM VCC OAM
VCC OAM
POC
VCC OAM
VC UP DS VPv, rtVBR
VC UP NDS VCC OAM
NodeB 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

Page 26/198
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 E1/T1
ATM Switch
ATM Switch
STM1/OC3 RNC
E1/T1
NodeB
E1/T1
NodeB
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

Page 27/198
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 las s C o n n e c t io n S c h e d u le r : T r a n s m it
S c h e d u le r:
EP & M BG
W FQ O r SFQ P e rV C & c o m m o n Q u e u e s EP0
E P 0 Q u e ue s
EmissionPriority/MostUrgent
Com m on Q ueues: P er V C Q ueues :
VC C 1 Q u eue
W e ig h t 1
Port1 L in k C la s s
VC C 2 Q u eue
W e ig h t 2
EP2 CBR
Q ueue
fo r E P 0
V P C Q ueue
W e ig h t 3
EP3 rtVBR
Tx VPT … …
E P 1 to E P 7 Q u e u es
P er V C Q ueu es :
EP4 nrtVBR
Com m on Q ueues:
V C C 7 1 Q u eu e
W e ig h t 1
L in k C la s s
Q ueue
V C C 7 2 Q u eu e
fo r E P 7 W e ig h t 1
EP7 UBR
V C C 7 3 Q u eu e
W e ig h t 1
APC
Rx C la s s C o n n e c t io n S c h e d u le r: T r a n s m it
S c h e d u le r : W FQ O r S FQ P e rV C & c o m m o n Q u e u e s
EP & M BG
E P 0 Q ue u es
CBR rtVBR nrtVBR
Per VC Q ueues :
C om m on Q ueues:
EP0
VCC 1 Q ueue
W e ig h t 1
Port2 L i n k C la s s
Q ueue
VCC 2 Q ueue
W e ig h t 2
fo r E P 0 EP2
VPC Q ueue
W e ig h t 3
EP3
… …
Tx C om m on Q ueues:
E P 1 to E P 7 Q ue u es
Per VC Q ueues :
V C C 7 1 Q u eu e
EP4
W e ig h t 1
L i n k C la s s
Q ueue
V C C 7 2 Q u eu e
fo r E P 7
W e ig h t 1
EP7
V C C 7 3 Q u eu e
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

Page 28/198
− 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

Page 29/198
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 All SC
100%
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

Page 30/198
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

Page 31/198
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 it’s 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

Page 32/198
Context:
•TrafficSource: continuous
• DualRateShaping:
ATM-User traffic: Traffic is continuous • PCR = ¼ linkRate
• CDVT = 0
• SCR = 1/8 LR
• MBS = 3
=> BT = 2*(Ts-T)
1 23456
Shaped traffic
TAT TAT
Period2 Period3 Period4 Period5 Period6
1 2 3 4 5 6
δ t
T= 1/PCR
Ts= 1/SCR Ts= 1/SCR Ts= 1/SCR Ts= 1/SCR

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

Page 33/198
RRC PDCP RRC PDCP
RLC RLC
MAC MAC
Physical Physical
AAL2
ATM
Physical
UE NodeB RNC
Uu Iub
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
Example: RAB 64 • Tm = 20 ms
=> SCR = MBS/Tm = 200 c/s
E1: δ = 220 µs => Ts = 5 ms
STM1: δ = 2,8 µs • PCR = 2 * SCR
=> T = 2,5 ms
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 r io d 3 P e r io d 4
1 2 3 4
δ t
T = 1 /P C R
T s = 1 /S C R T s = 1 /S C R T s = 1 /S C R T s = 1 /S C R
BT
BT
BT
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

Page 34/198
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 TTI BlockSize #MaxBlocks Consecutive

/TTI ATM cells
Ms Bits Bytes For highest TF
Speech / DL 20 244 31 1 1
12,2 kb/s – 12,2 kb/s UL 20 244 31 1 1
CS Data / DL 40 576 72 1 2
14,4 kb/s– 14,4 kb/s UL 40 576 72 1 2
CSD 57, 6 DL 40 576 72 4 7

UL 40 576 72 4 7
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 RAB Direction TTI BlockSize #MaxBlocks Consecutive

ServiceClass /TTI ATM cells
Ms Bits Bytes For highest TF
64kb/s / 64 kb/s DL 20 336 42 4 4
Background
Interactive /
UL 20 336 42 4 4
64kb/s / 128 kb/s DL 20 336 42 8 8
UL 20 336 42 4 4
64kb/s / 384 kb/s DL 10 336 42 12 12
UL 20 336 42 4 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

Page 35/198
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
1 2 3 4 5 6
δ t
T= 1/PCR
Ts= 1/SCR Ts= 1/SCR Ts= 1/SCR Ts= 1/SCR

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

Page 36/198
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 nodeB’s 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

Page 37/198
- 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 Connection Scheduler: Transm it
Scheduler: SFQ PerVC & com m on Q ueues
E P & M BG ATM IP FP Q O S M apping
EP0 Queue • SC
Com m on Per VC Queues : FRO M
EP
Queues: ATM Connection 1 Queue
(5 EP, from EP0 to EP7)
n1 cells W eight 1
PQ C
• CLP, SC and CC
ATM Connection 2 Queue Cell discard
LinkClass n2 cells W eight 2
Queue
for EP0
ATM Connection 3 Queue
n3 cells W eight 3 EmissionPriority/M ostUrgent
Or Comm on Queue:
cells EP0
EP1
… … EP2
CBR
Connection Scheduler: I = [2, 3, … 7]

rtVBR
W FQ EP3
EP i Queue
Per VC Queues :
nrtVBR
Com m on ATM Connection i1 Queue EP4
To Link Queues: W eight 1
Egress EP5
LinkClass ATM Connection i2 Queue
Queue W eight 1
for EP i EP6
ATM Connection i3 Queue UBR

W eight 1 EP7
Or Comm on Queue:
APC M apping Table,

SC m apped to EP configurable
Figure 3-15 Buffers within APC based card
ALU confidential

Page 38/198
AQM
Class Connection Scheduler: Transm it
Scheduler: W FQ O r SFQ PerVC & com m on Q ueues
E P & M BG ATM IP FP Q O S M apping
EP0 Queue (according to AQ M
Com m on Per VC Queues : FRO M
M apping Table) :
Queues: ATM Connection 1 Queue
• SC and CLP
n1 cells W eight 1
EP PQ C
(EP0 to EP 7)
ATM Connection 2 Queue DP
LinkClass n2 cells W eight 2
Queue
(DP0 to DP7)
for EP0
n3 cells W eight 3 E missionPriority/M ostUrgent
Or Comm on Queue:
cells EP0
EP1
… … CBR
EP2 (CLP1)
CBR
(CLP0)
I = [2, 3, … 7]
rtVBR rtVBR
EP i Queue EP3 (CLP1) (CLP0)
Per VC Queues :
Com m on nrtVBR nrtVBR
Queues: ATM Connection 71 Queue EP4 (CLP1) (CLP0)
To Link W eight 1
Egress EP5
LinkClass ATM Connection 72 Queue
Queue W eight 1
for EP i EP6
ATM Connection 73 Queue UBR

W eight 1 EP7 (CLP0+1 DiscardPriority
Or Comm on Queue: )
DP3 DP2 DP1 DP0
AQM M apping Table,
SC m apped to EP & DP. configurable
Figure 3-16 Buffer within AQM based card
Rule: IubTEG_Buffer_01
In the context of UMTS network, only perVC queuing is configured.
Within a serviceCategory, buffers allocated to each AtmConnection have the same characteristics (Size,
thresholds).
The size of the buffer depends on the serviceCategory. For the most urgent serviceCategory (CBR), the
buffer size is short, since delay is not allowed, whereas for less urgent serviceCategory (nrtVBR), buffer
size is high, since delay is acceptable. On the other hand when buffer size is short, cells are more
candidates to discard than when buffer size is high.
The buffer size is configurable; nevertheless within the context of UMTS network the default values are
used with exception of the shaped VPC queue case. Indeed the default queue size calculated by the
Passport for the shaped VPC configured on the 16pOC3/Stm1 FP is too short:
On the 16pOC3/Stm1 FP port configured with shaped rtVbr Vpc, set:
atmIf Ca rtVbr TxQueueLimit = 4000 cells
The Vpc being configured with:
atmIf Vpc Vpd Tm txQueueLimit (txQlim) = sameAsCa
Example of MML commands for CBR serviceCategory buffer size setting:

ATTRIBUTE AtmIf CA Cbr txQueueLimit (txql)
This attribute specifies the default maximum queue length for the emission queues used to buffer the
traffic of the CBR service category. It is used as the basis for setting both:
- the queue length and
- the discard thresholds
ALU confidential

Page 39/198
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 BufferSize
serviceCategory maximum effective ratio
CBR 96 86 90%
rtVBR 480 432 90%
nrtVBR 10240 7680 75%
UBR 10240 7680 75%
Figure 3-17 xpOC3 FP buffer size

− MSA32 FP:
MSA32 BufferSize
serviceCategory maximum effective ratio
CBR 96 86 90%
rtVBR 288 259 90%
nrtVBR 1792 1344 75%
UBR 1792 1344 75%
Figure 3-18 MSA32 Buffer Size
Within these tables:

BufferSize/Maximum is the size of the buffer, configured in ATTRIBUTE AtmIf CA Cbr txQueueLimit
(txql).
The Ratio is the buffer threshold at which Clp0 cells are discarded.
The effective BufferSize is the buffer occupancy at which incoming cells, whatever their CLP value, are
discarded.
BufferSize/Effective = Ratio * BufferSize/Maximum
When setting trafficDescriptor, BufferSize/Effective is used by the CAC for processing
ECR.
ALU confidential

Page 40/198
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
ALU confidential

Page 41/198
When traffic is running:

• 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:
1/ SC:
EP 0 linkClass Queue EP 0 perVC Queues
n1 cells
EP, (5 EP (O, 2, 3, 4, 7)
Weight 1 2/ CLP, SC and CC:
cellDiscard
n2 cells
Weight 2
… From PQC
n3 cells ATM Connection 03 Queue APC Mapping Table,
Weight 3
P0
To Link
Egress … … EP1
CBR
EP2
EP 7 perVC Queues rtVBR

EP 7 linkClass Queue EP3
n1 cells
ATM Connection 71 Queue nrtVBR
Weight 1 EP4
n2 cells
ATM Connection 72 Queue EP5
Weight 2
… EP6
n3 cells ATM Connection 73 Queue UBR
Weight 3 EP7
(EP & MBG)
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:

ALU confidential

Page 42/198
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.
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:
congestion state
congestion state
Less severe
Most severe
90% 75% 35%
CC0 CC1 CC2 CC3
No Cell discarded
DP2 & DP3 cells
Node discards
Node discards
Node discards
DP1 & DP2 &
DP3 cells
DP3 cells
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
CBR CBR
EP2 (CLP1) (CLP0)
rtVBR rtVBR
EP3 (CLP1) (CLP0)
nrtVBR nrtVBR
EP4 (CLP1) (CLP0)
EP5
EP6
UBR
EP7 (CLP0&1)
least Urgent DP3 DP2 DP1 DP0

DiscardPriority
Least important 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.
ALU confidential

Page 43/198
E.g.: on reception of a cell with CLP=1 within an nrtVBR atmConnection, DiscardPriority 3 is associated
to the cell.
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
EP0 Queue Most Urgent
CBR CBR CLP1 Cell2 CLP0 Cell1
EP0 (CLP1) (CLP0)
VCC CBR
rtVBR rtVBR
EP1 (CLP1) (CLP0)
CC0 CC1 CC2 CC3
EP0 queue is in CC2. EP2

Cell1, DP1, is accepted.
Cell2, DP3, is rejected.
EP3
nrtVBR nrtVBR Tagged cell NonTagged cell

EP4 (CLP1) (CLP0)
EP4 Queue CLP1 Cell2 CLP0 Cell1
EP5 VCC nrtVBR
EP6
CC0 CC1 CC2 CC3
UBR
EP4 queue is in CC2. EP7 (CLP0+1 DiscardPriority
Cell1, DP2, is accepted. )
Cell2, DP3, is rejected. Least Urgent DP3 DP2 DP1 DP0
Least important 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:
90% 38%
CBR CLP0 discard CLP1 discard
CC0 CC1 CC2 CC3
90% 38%
rtVBR CLP0 discard CLP1 discard
CC0 CC1 CC2 CC3
75% 32%
nrtVBR CLP0 discard CLP1 Discard
CC0 CC1 CC2 CC3
ALU confidential

Page 44/198
Figure 3-23 CongestionControl levels on APC card.
No DiscardPriority parameter on the APC based card, the cell CLP values is directly compared to the
buffer occupancy:
Queues: MappingTable : ATM Interface :
EmissionPriority
EP0 Queue Tagged cell NonTagged cell
Most Urgent
90% 38% CBR CLP1 Cell2 CLP0 Cell1
EP0
VCC CBR
EP1
CC0 CC1 CC2 CC3
rtVBR
Cell1, CLP0, is accepted.
Cell2, CLP1 is rejected.
EP3
EP4 Queue nrtVBR Tagged cell NonTagged cell

EP4
CLP1 Cell2 CLP0 Cell1
75% 32%
EP5 VCC nrtVBR
EP6
CC0 CC1 CC2 CC3
UBR
Cell1, CLP0, is accepted.
Cell2, CLP1, is rejected. 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.
ALU confidential

Page 45/198
According to CDVT value, cells arriving before TAT, in the limit of CDVT, are declared conformed.
CDVT =< ( T – δ ), e g : C D V T = ( T – δ ):
TAT TAT TAT TAT
P e r io d 1 P e r io d 2 P e r io d 3 P e r io d 4
1 2 3 4
δ t
T = 1 /P C R
CDVT CDVT CDVT CDVT
CDVT > ( T – δ ), e g : C D V T = 2 *( T – δ ):
TAT TAT TAT TAT

P e r io d 1 P e r io d 2 P e r io d 3 P e r io d 4
1 2 3 4 5
δ t
T = 1 /P C R
CDVT
CDVT
CDVT
CDVT
Figure 3-25 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 SDU’s and SDU’s received
from the dropped node.
ALU confidential

Page 46/198
3.2.7.1 CASE OF UMTS/UMTS D&I:
Fractional E1:
One E1 and only one is shared between two NodeBs.
Dropped Dropping
NodeB NodeB
E1 n°2 E1 n°1
NodeB NodeB
RNC- ATM over unchannelise RNC-
N°2 N°1 TDM
ANode STM-1
d INode
TDM backbone
UMTS IBTS UMTS IBTS
1 Fract E1 backbone 1 Fract E1 e/w MSA 32
14 TS 12 TS with STM-1
Example:
MSA32 splits UMTS traffic for 2 nodeBs on same E1 N°1 :
− NodeB N°1 Iub ATM stream from 12 TS (E1 n°1, TS 2-13) is sent over STM-
1 to RNC-IN,
− NodeB N°2 ATM stream from 14 TS (E1 n°1 TS 17-30) is sent over STM-1
to RNC-IN.
E1 N°2 :
− NodeB N°2 Iub ATM stream from 14 TS (TS 17-30) is switched on E1 n°1
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:
ALU confidential

Page 47/198
− On droppedNode, PCM1 port is configured

− 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
32 Timeslots 32 Timeslots
ATM1 Not used Not used ATM2 Not used
E1 E1
32 Timeslots 32 Timeslots
ATM1 ATM2 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 Dropping
NodeB NodeB
T1 n°2 T1 n°1
UMTS UMTS
ATM over unchannelised
OC-3
RNC
IBTS N°2 IBTS N°1 TDM OC-3/T1
TDM backbone connector
UMTS IBTS UMTS IBTS
12
1 Fract T1 backbone 12
1 Fract T1
14 TS TS 14 TS
TS
ALU confidential

Page 48/198
Rule: IubTEG_D&I_03
− D&I of 2 nodes B max,
− Only one T1 is supported (fractional T1):
− UMTS node B requires 12 TS on T1 for delay reason,
− D/I is not supported with NodeB multiPCM configuration.

− A nodeB traffic flow may not use consecutive TimeSlots.
− Connectivities:
− On droppedNode, PCM1 port is configured

Remarks:
• F4/F5 AIS dedicated to dropped NodeB Atm connections go through the dropping
nodeB.
− The POC based on MSS7k is not involved in T1 D&I, since doesn’t provide T1
access.
3.2.7.2 CASE OF UMTS/GSM D&I
Fractional E1:
UMTS GSM
NodeB BTS
E1 n°1
UMTS IBTS 1 Fract E1
1 Fract E1 ATM over Unchannelised STM1
8 TS
22 TS
RNC-INode
RNC-ANode
GSM BTS TDM backbone
1 Fract E1 TDM shared between
15 TS
GSM backbone UMTS & GSM
e/w MSA 32
BTS with STM-1 E1 n°6
backbone
E1 n°2
TDM
E1 n°4
E1 n°5 BSC
GSM
UMTS E1 n°3
NodeB 1 Fract E1 BTS GSM BTS E1 n°7
2 Fract E1
15 TS
10 + 8 TS
One E1 link is shared between one GSM BTS and one NodeB:
ALU confidential

Page 49/198
Example:
MSA32 splits GSM and UMTS traffic from 2 incoming E1
E1 N°1:
- 8 GSM TS (TS 1, 5-11) are mapped onto TS1 and TS5-TS11 of E1 N°6.
- NodeB ATM stream from 22 TS (E1 N°1 TS 2-4, 12-15, 17-31) is sent over
STM-1 to RNC.
E1 N°2:
- 15 GSM TS (TS 2, 17-30) are switched on E N° 4 and then mapped onto
TS1-TS15 of E1 N°7.
E1 N°3:
- NodeB stream from 15 TS (E1 N°3 TS 17-31) is switched on E1 N°5 and
then sent over STM-1 to RNC.
E1 N°4:
- 10 GSM TS (TS 1, 5-13) are mapped onto TS2 and TS17-TS26 of E1 N°6.
- 8 GSM TS (TS 6-13) are mapped onto TS17-TS25 of E1 N°7.
E1 N°6&7: Carries GSM Abis from 3 GSM BTS to BSC.

STM-1: Carries Iub aggregation traffic from many IBTS including the ones from other
MSA (full or fractional E1).
Rule: IubTEG_D&I_04
− GSM BTS must be the dropping node, whereas the UMTS NodeB must be the dropped
node.
− Minimum number of TS for UMTS is 12 to insure acceptable delay; therefore in best
case 18 TS are available for GSM.
− D/I is not supported with NodeB multiPCM configuration, or BTS multiPCM.

− The GSM and UMTS TS can be non consecutive.
− The extraction of the GSM TS will be performed by ALU Networks MSS7K. The
limitations are the same as for UMTS-UMTS D&I except that no hairpin is required on
MSA32 card.
− Connectivities:
− On droppedNode, PCM1 port is configured,

Remarks:
− GSM BTS must be the dropping node, in order to not perturb GSM traffic,
− Maximum number of available E1 TS is 30 since TS0 and 16 are reserved [R47].
− Fractional rate E1 access is available on MSA32 FP which populates the MSS7k.
Fractional T1:
One T1 link is shared between one GSM BTS and one NodeB:
ALU confidential

Page 50/198
Rule: IubTEG_D&I_05
− GSM BTS must be the dropping node, whereas the UMTS NodeB must be the dropped
node.
− Maximum guaranteed configuration 2 dropped nodes: 1 GSM BTS and 1 UMTS nodeB.
The dropping node being a GSM BTS.
− D/I is not supported with NodeB multiPCM configuration, or BTS multiPCM.
− Number of TS for UMTS is 12 to insure acceptable delay; therefore up to 12 TS are

available for GSM.
− The GSM and UMTS TS can be non consecutive.
− Connectivities:
− On droppedNode, PCM1 port is configured,

Remarks:
− GSM BTS must be the dropping node, in order to not perturb GSM traffic,
− Maximum number of available T1 TS is 24.
− The MSS7k is not involved in T1 D&I, since doesn’t provide T1 access.
− Fractional T1 is not available on 4 ports DS3ch IMA nor on 4 port DS3ch CES.
3.2.8 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 SVC’s 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.
ALU confidential

Page 51/198
Applying hierarchy in a PNNI network consists in grouping the nodes in different sub networks called
peerGroup, e.g.: all Iub ATM switches behind a RNC may be grouped into one peer group, ATM
switches connected to another RNC may be grouped in another peerGroup.
ATM addressing plane has to reflect the topology choice.
In the example above, all nodes belonging to the same peerGroup have the same prefix level88 (88
bits), whereas prefix level 104 distinguishes nodes within a peerGroup (16 bits).
3.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 B-
ISDN [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:
CalledParty Node:
Calling vcc: 3/33
vcc= 2/32
Called vcc= 2/32
Address = AESA_1
CalledAddress = AESA_1
ATM
ATM switch
switch ATM
ATM switch
switch ATM
ATM switch
switch
Or
Or intermediate
intermediate Or
Or
RNC
RNC RNC
RNC
CalledParty
CalledParty sPVC CalledParty
CalledParty
Vcc 3/33 Vcc 2/32
Figure 3-27 sPVC example

ALU confidential

Page 52/198
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.
ALU confidential

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

FP reset 45,000 Connections 2 min
Shelf reset 200,000 Connections 35 min
Figure 3-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 UMTS
UMTS
1/ RELEASE 1/ RELEASE
PNNI 2/ SETUP PNNI PNNI PNNI 2/ SETUP PNNI

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

Page 54/198
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
RNC-AN RNC-IN
NodeB
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 RNC-
IN.
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

Page 55/198
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
NodeB
RNC
POC
POC
NodeB
RNC
POC
POC
Stm1
IMA linkGroup
IMA linkGroup
NodeB
NodeB
E1 E1
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.
- ITC (IndependentTransmitClock): transmitClock is independently derived from one
or several links within an IMA linkGroup.
3.2.10.2 ICP (IMA CONTROL PROTOCOL)

Each RNC card supports ICP compliant to atmForum.
NodeB supports both IMA1.1 and IMA1.0 ATM Forum.
Rule: IubTEG_IMA_02
ALU confidential

Page 56/198
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 IMA Frame 1 IMA Frame 2 …
ICP 1 2 127 ICP 1 2 127 ICP 1 2 127
Link 0
128 cells 128 cells 128 cells
ATM node
ATM node
1 ICP 2 127 1 ICP 2 127 1 ICP 2 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

Page 57/198
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 IDCR IDCR IDCR-MBG

w/o IMA (kb/s) (Cell/s) (kb/s) (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: 3.11.1.1.
The NodeB IMA LinkGroup bandwidth Reduction mechanism is described in section: 3.8.6.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 (0) 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,
− Case of less than 8 PCM within the IMA LG, one couple (Up Ds vcc, Up Nds Vcc) is released
for each PCM defect,
ALU confidential

Page 58/198
− 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 (§ 0)
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 §5.4.2.2), 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 doesn’t take care about the aal2 qos, in
other words doesn’t 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.
Moreover, in such a way to satisfy UMTS application traffic, the IMA differential delay should be
limited to a maximum value of 2ms.
ALU confidential

Page 59/198
Rule: IubTEG_IMA_06
The IMA Differential Delay should remain below 2 ms.
In order to keep the IMA differentialDelay below the limitation, the PCM links within the IMA LG
should follow the same path and then cross the same nodes.
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:
Both ends of the IMA LG may be configured with different amounts of tolerable differential delay (i.e.,
say one up to 25 ms and one greater than 25 ms).
3.2.11 ATM OAM

Reference: [R49].
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.
ATM OAM Information is bidirectional; it is carried once the ATM connection is established.
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)
ALU confidential

Page 60/198
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]).
NodeB OAM Boundary

NodeB RNC
RNC
VCC ATM ATM VCC / VPC
ATM ATM
switch
switch 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
ALU confidential

Page 61/198
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:
Function
Cell Header OAM Type Function Specific Field Reserved CRC-10
Type
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:
OAM Type Function Type
0001 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 Source ID Unused
indication Tag
1 bytes 4 bytes 16 bytes 16 bytes 8 bytes
Where:
- LoopBack indication: The source loopBack point fills this field with value: 0000 0001.
The destination loopBack point returns the value: 0000 0000.
- Correlation Tag: Identifier of the loopBack invocation checked in loopBack source point
on reception of loopBack answer.
- LoopBack Location ID: Identification of the node where loopback has to occur.
- Source ID: Coded as an option, identification of the loopBack source point.
3.2.11.3 ATM OAM SIGNALS

AIS:
ALU confidential

Page 62/198
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 IN 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).
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 doesn’t 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 doesn’t allow calls on this Path.
When activating aisGeneration on source and Destination of a sPVC, failure of the sPVC, is a
trigger for aisGeneration on Permanent AtmConnections, the sPVC is switched on at the
source and destination:
ALU confidential

Page 63/198
PVC PNNI sPVC PNNI sPVC PVC

ATM ATM
F5 AIS Switch PNNI Switch
AtmIf
AtmIf
AtmIf
AtmIf
F5 AIS
sPVC CdPyNb, sPVC CgPyNb,

AisGeneration AisGeneration
activated 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,
- Reception of F4/F5 AIS Segment in a Segment boundary node,
RDI frequency generation is usually 1 cell/s. RDI generation stops when failure detection is
removed.
Remark:
AIS generation attribute available when configuring dynamic AtmConnection PNNI sPVC,
allows activating/deactivating both AIS and RDI signals.
ALU confidential

Page 64/198
LOS Condition
UMTS
UMTS UMTS
UMTS
ATM
ATM ATM
ATM ATM
ATM
P-AIS F4/F5-AIS
TX
TX RX
RX TX
TX RX
RX TX
TX RX
RX
PTE
PTE MSTE
MSTE PTE
PTE PTE
PTE
RX
RX TX
TX RX
RX TX
TX RX
RX TX
TX
MS-RDI
Ete F4/F5-RDI Ete F4/F5-RDI Ete F4/F5-RDI
VPC/VCC VPC/VCC VPC/VCC

EndPoint node ConnectionPoint node 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 TX
TX RX
RX TX
TX RX
RX
PTE
PTE PTE
PTE RSTE
RSTE PTE
PTE
RX
RX TX
TX RX
RX TX
TX RX
RX TX
TX
Ete F4/F5-RDI Ete F4/F5-RDI Ete F4/F5-RDI

Figure 3-34 F4/F5 RDI generation on Reception of MS-AIS
ALU confidential

Page 65/198
LOS Condition
UMTS
UMTS UMTS
UMTS
ATM
ATM ATM
ATM ATM
ATM
TX
TX RX
RX TX
TX RX
RX TX
TX RX
RX
PTE
PTE PTE
PTE RSTE
RSTE PTE
PTE
RX
RX TX
TX RX
RX TX
TX RX
RX TX
TX
Path-RDI
Ete F4/F5-RDI Ete F4/F5-RDI

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 don’t 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

Page 66/198
- 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

Page 67/198
- 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 QOS
An Aal2 QOS value is associated to each path.
The Iub Aal2 Paths carry delaySensitive traffic, nonDelaySensitive traffic and Hsdpa traffic.
Rule: IubTEG_Aal2 Qos_1

- AAL2 Qos value 0, is assigned to aal2 Paths carrying DS traffic,
- AAL2 Qos value 1, is assigned to aal2 Paths carrying NDS traffic,
- AAL2 Qos value 2, is assigned to aal2 Path carrying Hsdpa traffic.
ALU confidential

Page 68/198
3.4.1 CES IWF:

ATM
ATM CBR VCC CBR VCC
ATM
ATM
E1
E1 Eqt
Eqt CES
CES ATM
ATMBB
BB CES
CES E1
E1 Eqt
Eqt
IWF
IWF IWF
IWF
E1/DS1
NodeB
NodeB
N*64
CBR VCC CBR VCC PP7K
PP7K
NodeB
NodeB ATM
ATMBB
BB BSC
MSA32
MSA32 BSC
E1/DS1
BTS
BTS E1/DS1
N*64
N*64
TimeSlot
TimeSlot mapping
mapping function
function
E1
E1 // DS1,
DS1, N*64
N*64 Services
Services
AAL1 AAL1 …AAL1

AAL1 AAL1 AAL1
PHY
PHY PHY
PHY ATM
ATM
TDM ATM
PHY
PHY
E1/DS1 TS CBR VCC
CBR VCC
E1/DS1 TS …
CES IWF
3.4.2 SDT/UDT:
3.4.3 FULL/PARTIALCELL FILL:

CellPayloadAssemblyDelay Xmin N Kmin
= 1 ms 8 1 8
= 8 * 125 µs 8 2 16
8 3 24
8 4 32
8 5 40
3.4.4 REASSEMBLY BUFFER
3.4.5 QOS:
ALU confidential

Page 69/198
3.4.6 TRAFFICMANAGEMENT:
Cell Payload size, avg (bytes) 46,875
Cell Payload size, min (bytes) 46
Cell Payload size, max (bytes) 47
StructuredBlock size, N (bytes) 1 2 3 4 5 6 … 12 13 14 15 16
#structuredBlocks perCell Xmax 46 23 15 11 9 7 3 3 3 3 2
( = #PCM frames involved)
#TS perCell (bytes) 46 46 46 46 46 46 46 46 46 46 46
CellPayloadAssembly Delay (µs) 5750 2875 1875 1375 1125 875 375 375 375 375 250
PCR (cell/s) 171 342 512 683 854 1024 2048 2219 2390 2560 2731
(kb/s) 73 146 218 290 363 435 869 941 1014 1086 1158
StructuredBlock size, N (bytes) 1 2 3 4 5

Min #structBlocks perCell Xmin 8 8 8 8 8
#structuredBlocks perCell X 8 8 8 8 8
X Range 8 < 46 8 < 23 8 < 15 8 < 11 8<9
Min #TS perCell Kmin 8 16 24 32 40
#TS perCell K (bytes) 8 16 24 32 40
#IdlePattern bytes perCell (bytes) 38 30 22 14 6
CellPayloadAssembly Delay (µs) 1000 1000 1000 1000 1000
PCR (cell/s) 1000 1000 1000 1000 1000
(kb/s) 424 424 424 424 424
StructuredBlock size, N (bytes) 1 2 3 4 5

Min #structBlocks perCell Xmin 8 8 8 8 8
#structuredBlocks perCell X 46 23 15 11 9
X Range 8 < 46 8 < 23 8 < 15 8 < 11 8<9
Min #TS perCell Kmin 8 16 24 32 40
#TS perCell K (bytes) 46 46 45 44 45
#IdlePattern bytes perCell (bytes) 0 0 1 2 1
CellPayloadAssembly Delay (µs) 5750 2875 1875 1375 1125
PCR (cell/s) 174 348 534 728 889
(kb/s) 74 148 227 309 377
INTERACTION
WITH OTHER SERVICES:
3.5 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.5.1 DHCP
See §Plane description/OAM Plane.
3.5.2 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@).
ALU confidential

Page 70/198
InverseARP uses services of AAL5. On the Iub interface, InverseARP traffic is carried in the OAM
Vcc:
IP ARP
LLC/SNAP
AAL5
ATM
Layer1
An IP node sends InvARP Request to the remote IP node, and expects to receive InvARP Reply with
remote Host IP address included. Then the ARP table is updated with the mapping between VCC and
Host IP address.
Within Passport based nodes, ARP table is updated periodically, according to the setting of MML.
Remark:
In the context of IP over ATM network, ARP is not invoked, only InverseARP is
invoked. Therefore this section treats only InverseARP.
…
DHCP Request
DHCP Request
Ack
NodeB IP@
InvARP
Request
InvARP Reply
NodeB IP@
InvARP
Request
InvARP Reply
NodeB IP@
NodeB
NodeB RNC-IN
RNC-IN
VCC OAM
NodeB
NodeB ARP
ARP Table:
Table: RNC-IN
RNC-IN ARP
ARP Table:
Table:
ATM@
ATM@ VpiVci
VpiVci IP
IP @Age
@Age ATM@
ATM@ VpiVci
VpiVci IP
IP @Age
@Age
Empty
Emptyifif PVC
PVC OAM
OAM Vpi.Vci
Vpi.Vci RNC
RNC IP@
IP@ xxx
xxx Empty
Empty ifif PVC
PVC OAM
OAM Vpi.Vci
Vpi.Vci NodeB
NodeB IP@
IP@ xxx
xxx
Figure 3-39 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.
ALU confidential

Page 71/198
Rule: IubTEG_ARP_1
Within UMTS nodes, on IP over ATM interfaces, it is recommended to activate InverseARP with
exception of:
- Interface terminating on otherVendor nodes not supporting InverseARP.
On nodeB by default is activated dynamic ARP.
On RNC-IN, choice of Dynamic or Static InverseARP, impacts the PassPort ATM MPE component
configuration.
When configuring an ATM MPE component, type of encapsulation must be specified:
Encapsulation type values:
- IpVcEncapsulation: is set when only IP packets are inserted in ATM cells. No
InverseARP packet may be inserted. Therefore with such an encapsulation mechanism
InverseARP can not be configured, only StaticARP applies.
- LlcEncapsulation: is set when IP packets, InverseARP packets, and other kinds of

packets are inserted in ATM cells. Then an LLC and SNAP overhead is added to the
encapsulated packet. Within SNAP overhead two bytes are filled with the EthernetType
to reflect the type of inserted packet:
- EthernetType = 0x0800 for IP packet,

- EthernetType = 0x0806 for InverseARP packet.
Rule: IubTEG_ARP_2
When configuring ATM MPE,
EncapsulationType must be set with value LLC Encapsulation value.
Remark:
If StaticArp is configured for all nexthop Ip@ used on the PP, EncapsulationType=
IpVcEncapsulation may be configured.
Moreover on RNC-IN, when VPT is configured, DynamicARP works correctly only if ATTRIBUTE
AtmIf faultHoldOffTime is set to 0 on port where is configured the VPT.
Rule: IubTEG_ARP_3
If VPT activated, Set ATTRIBUTE AtmIf faultHoldOffTime = 0 on RNC port where is
configured VPT.
Passport MML for dynamic InverseARP:

COMPONENT Vr Ip Arp DynHostEntry (DynHost)
ATTRIBUTE AtmMpe encapType (etype)
Passport MML for static InverseARP:

COMPONENT Vr Ip Arp HostEntry (Host)
This component defines a static host entry in the ARP table.
ATTRIBUTE Vr Ip Arp Host permanentVirtualCircuitNumber (pvcNo)
This attribute specifies the number of the PVC for the static host entry.
ATTRIBUTE Vr Ip Arp autoRefreshTimeout
ALU confidential

Page 72/198
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.5.3 SITELAN
3.6 IUB TOPOLOGY

Iub topology has to answer to following issues:
- Is NodeB and RNC connected by direct E1/T1 or Fractional E1/T1 link,
- If Fractional Rate E1/T1, do we have GSM BTS in the link as well (Use D&I – RNC
AN CES for cross connecting),
- Is NodeB connected to RNC via ATM Network, public or private ATM backbone,
- Is it a policed ATM network,
- Is the remote Concentrator (POC) a PP7k or a OEM,
- Are NAMs inserted on Iub interface …
POC (Point of Concentration) is a basic ATM Switch; its function is to aggregate ATM traffic received
from several physical links on a lower amount of links. Moreover a POC may be involved in the
transmission adaptation PDH / SDH.
A POC may be a Passport ATM Switch or an otherVendor ATM switch.
NAM is described in ATM Feature section.
Below are presented some examples of network topologies on Iub interface:
ALU confidential

Page 73/198
3.6.1 IUB TOPOLOGY:

NodeB Iub
E1
E1
NodeB
BTS
TDM E1 BSC
BSC
NodeB
TDM E1
NodeB N*E1
N*E1 POC
POC RNC
NodeB POC
POC OC3/STM1 RNC
N*E1
NodeB
NodeB POC
POC
N*OC3/STM1
NodeB N*E1
ATM
NodeB POC
POC
ATM
Backbone
Backbone
N*E1
NodeB
NodeB
NodeB
Figure 3-40 Iub topology
The atm backbone that provides connectivity on Iub interface might be either a UMTS/UTRAN
dedicated atm backbone or a public atm Service Provider Network (ASP).
When connecting NodeBs to RNC through ASP, remote concentrators (called POC) are required. POC
are based on 7670, MSS or OEM ATM switches. Remote concentrators may be part of ASP network or
may be managed by UMTS operator.
When UMTS Operator manages remote concentrators it is recommended to group Vcc into a Vpc that
traverses ASP. The oam Vcc must be configured separately and are not enclosed within the VPC.
When the atm backbone polices Iub traffic by exercising UPC, in the remote concentrator and RNC
connection points, the vpc must be shaped by the RNC in downlink direction and by POC in uplink
direction in such a way the transmitted traffic throughput is conform to the expected throughput.
In case when the NodeB is connected directly to policed ATM Network, without POC, it is
recommended to use one Vpc per E1/T1 link. This vpc is shaped by the RNC in downlink direction.
ALU confidential

Page 74/198
3.6.2 IUB TOPOLOGY WITH PP15K-POC:
RNC-SDH
RNC-SDH RNC-SDH
RNC-SDH
16pOC3
16pOC3 16pOC3
16pOC3
16pOC3
16pOC3 16pOC3
16pOC3
- Iub PNNI sPVCs

- Iu PVCs
- Iur PVCs
N*T1 Iub OC3c

+ IMA
NodeB
NodeB PVCs
4pDS3
4pDS3 (1)
CrossConnect
CrossConnect
CrossConnect
CrossConnect
16pOC3
16pOC3
N*T1 16pOC3
16pOC3 PVCs
(1)
+ IMA SDH Backbone
NodeB
NodeB IuCS
PP15k-POC
PP15k-POC
…
DS3 IuPS&PC
16pOC3
16pOC3
Channelized
16pOC3
16pOC3
4pDS3
Iur
4pDS3 (10)
+ IMA
NodeB
NodeB N*T1
+ IMA
(10)
OC3c
Figure 3-41 Iub topology based on RNC-SDH and PP15k-POC
There is no D&I on nodeB.

RNC-SDH is populated with one pair of 16pOC3 FP. Four OC3 concatenated links are configured on
the RNC / PP15k-POC interface:
− Two OC3c links for Iub,
− One OC3c link for IuPS + IuPC and
− One OC3c link for IuCS and Iur.
All UTRAN interfaces from a RNC go through the PP15k-POC.

Two kinds of ATM connection are configured between RNC-IN and PP15k-POC:
− PNNI sPVCs for Iub atmConnections,
− PVCs for IU and Iur atmConnections.
PP15K-POC is connected to 1 or 2 RNC-SDH nodes.

It is used as a concentrator point for all UTRAN ATM connections.
It is populated with:
− Two pairs of LAPS protected 16pOC3 FP’s configured with Concatenated OC3 links:
− One pair of 16pOC3 FP is dedicated to connections with RNC,
− The second pair is dedicated to connections toward USGSN and UMGw.

− Up to ten 4pDS3 Channelized FP’s:
− Up to 560 IMA linkGroups per PP15k-POC,
− Up to 28*4*10 = 1120 DS1 per PP15k-POC.
OCAN doesn’t cover PP15k-POC.
ALU confidential

Page 75/198
3.6.3 ATM RING ON IUB

[R151]
The Iub Network is composed of NodeB, Passport 7420, Passport 7480, RNC and a SDH channelized
ring.
Each nodeB is populated with a Passport 7420, providing the nodeB with more sophistical atm features
(eg: PNNI) and more Transport performance.
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 PP7480 provides transmission adaptation between stm1 channelized links and stm1 clearChannel
links available on the RNC 16pOC3/Stm1 FP. Moreover the PP7480 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 PP7480 is the point of termination of the
Pnni atm connections initiated in the PP7420, indeed the RNC is not involved in the PNNI network, all
its CPU capacity is then dedicated to UMTS processing.
Src
PVC
Pnni sPvc
nodeB
nodeB 11 … PP7420
PP7420
6 E1 6 E1 Dst
IMA IMA AESA
6 E1
IMA
ADM
ADM
Stm1
nodeB
nodeB 22 … PP7420
PP7420 Atm loop … PP7480
PP7480 RNC
RNC
ADM
ADM
ADM
ADM vc12 Stm1
6 E1 Vc4
Stm1
Src IMA Vc4
Src Vc12
Pnni sPvc …
6 E1
- IMA must be configured on the NodeB / PP7420 interface.
nodeB
nodeB 10
10… PP7420
PP7420 IMA
- 1 PP7420 per NodeB,
6 E1 - Up to 10 NodeB/PP7420 per atmRing.
IMA
Figure 3-42 Atm ring topology on Iub
The figure below is a synthesis of the Passport FP involved on the Iub backbone:
ALU confidential

Page 76/198
IMA LG on NodeB IMA LG between two PP7420 IMA LG between PP7480 and PP7420
PP7420
PP7420
nodeB1
nodeB1 … MSA32
MSA32 FP
FP
IMA IMA
… … 6 E1
IMA Defense in NodeB 6 E1
ADM
ADM
PP7420
PP7420 ADM
ADM 2pStm1oCh
2pStm1oCh FP
FP
Stm1 …
nodeB2
nodeB2 … MSA32
MSA32 FP
FP
Atm loop vc12
PP7480
PP7480 RNC
RNC
ADM 2pOC3
2pOC3 FP
FP
ADM Stm1
6 E1 6 E1 Vc4
… Vc12
IMA … IMA
nodeB3
nodeB3 … PP7420
PP7420
Figure 3-43 Passport FP involved in the atm ring
3.7 RNC
3.7.1 ASIC
The different Passport FP, are based either on APC or AQM trafficManagement ASIC. The type of
ASIC determines the FP trafficManagement behaviour.
3.7.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:
− 5 EmissionPriority values (EP0 to EP7),
− Basic VPT,
− SingleRate trafficShaping (also called Linear Shaping),
− Traffic shaping only on Emission Priorities 0.
3.7.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]
ALU confidential

Page 77/198
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.7.2 FP
3.7.2.1 16POC3/STM1 FP
RNC-IN is populated with 16pOC3/STM1 FP.
Iub, Iu, Iur transmission links are connected to the 16pOC3/STM1 FP.
3.7.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:
- 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.
ALU confidential

Page 78/198
3.7.2.1.2 ATM CHARACTERISTICS:

16pOC3 FP card is based on APC TrafficManagement ASIC. Therefore the 16pOC3 FP ATM
characteristics are those from the APC.
- AtmConnection capacity:
If 16pOC3/STM1 FP is configured to handle IP traffic (IPRts>0), then 16pOC3/STM1 FP capacity is
29 440 atmConnections. This capacity is distributed, by means of ConnMap parameters on each port
of the card see §5.
- AtmQOS Scheduling:
The 16pOC3/STM1 ATM FP first allocates to each EP its minimum bandwidth guaranteed, and then
allocates the remaining bandwidth among the EPs according to a strict priority such that a lower EP
may not receive any extra bandwidth if the higher EPs have consumed it all.
The MBG has precedence on EP0 and EP1.
This type of scheduling is referred to as Priority Guaranteed Queuing (PGQ).
3.7.2.2 16POC3/STM1 ATM/POS FP

The 16pOC3/Stm1 ATM/POS FP is supported since Passport release PCR5-2 on PP15k , PP20K and
RNC1500.
Prerequisite:
Before replacing the 16pOC3/Stm1 ATM FP by the 16pOC3/Stm1 ATM/POS 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.

- 16 ports OC3 / Stm1 not channelized,
- SONET and SDH transmission types; Sonet ports and SDH ports may be configured on one FP,
- 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’.

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

Page 79/198
- AtmConnection types: Pvc, Pvp, Svc, Svp, sPvc, and sPvp,

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

- EFCI: One EFCI threshold is set per CC (CongestionControl level).
− Not Supported: CES.
3.7.2.2.2.1 QOS/QOSINFORMATION:
- serviceCategories: Cbr, rtVbr, nrtVbr, Ubr, Ubr with Mdcr,

- EP (EmissionPriority) range: [0, 7],

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
- Not supported: ABR serviceCategory.
3.7.2.2.2.2 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:
- AbsolutePriority for EP0 and EP1,
- MBG available for EP2 to EP7,
Since the absolute EP (EP0 and EP1) have been served, the 16pOC3PosAtm 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.
Remark:
The 16pOC3/STM1 ATM FP first allocates to each EP its minimum bandwidth guaranteed,
and then allocates the remaining bandwidth among the EPs according to a strict priority such
that a lower EP may not receive any extra bandwidth if the higher EPs have consumed it all.
The MBG has precedence on EP0 and EP1.
This type of scheduling is referred to as Priority Guaranteed Queuing (PGQ).
ALU confidential

Page 80/198
3.7.2.2.2.3 MBG:
The MBG parameter configured against nonAbsolute EP is taken into consideration by the
ClassScheduler.
The MBG is set through the command:
ATTRIBUTE AtmIf Ep minimumBandwidthGuarantee (minBw).
The parameter is set with either with:
- a MBG value in the range [0, 100] or
- The value ‘Priority’.
The mix of ‘priority’ and MBG provisioning is not supported on the 16pOC3/Stm1 Atm/Pos FP. What is
supported is either specifying the ‘priority’ option for all EPs, or the explicit configuration of the MBG
value for all used EPs used on one atmInterface.

On one16pOC3/Stm1Atm/Pos FP atm interface:
- if a MBG value is configured against an EP, then a MBG value must be configured against
each non absolute EP (EP2 to EP7),
- Else, the minimumBandwidthGuarantee is set with ‘Priority’ value for each non absolute
EP,
A mix of explicit MBG values and ‘Priority’ is not allowed on atm interface.
The explicit configured MBG values must satisfy the following rules:
If each non absolute EP is configured with an explicit MBG value,
On one atm interface, the MBG values must be chosen in such a way to satisfy:
− Σ EP2 to EP7 MBG = 100%
− MBG EP2 > MBG EP3 > MBG EP4 > MBG EP5 > MBG EP6 > MBG EP7.
Expected QOS behavior according to the explicit configured MBG value or with ‘Priority:
1/ Case of the MBG = explicit configured MBG value in the range [0, 100]:
The MBG configured against the non absolute EPi (EP2 to EP7), specifies the proportion of
the bandwidth assigned to the EPi after absolute priority EP have been served.
Eg, case of 4 non absolute EP:
GuaranteedBw for EP3 =
[linkRate – (EP0+EP1) traffic] * MBGEP3 / (MBGEP2 + MBGEP4 + MBGEP7)
The MBG does not protect low priority traffics against traffic Starvation resulting from the two
absolute Priorities.

On GQM based FP, the MBG assigned against an EP has no precedence over absolute
EmissionPriority (EP0, EP1).
Remark:
- On APC based card, the guaranteed bandwidth = MBG * link bw, in other word the
guaranteed bandwidth does not take into consideration the AbsolutePriorities: EP0 and
EP1.
- If real time traffic (eg: CBR or rtVbr) is mapped to EP2, then the MBG assigned to EP7
add potential Delay and Jitter on the real time traffic.
ALU confidential

Page 81/198
- 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), don’t consume any bandwidth, whatever the MBG
configured against the non absolute EP, the non absolute EP may transmit up to the
linkRate.
See MBG value in §5.
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.
See MBG value in §5.
3.7.2.2.2.4 QOS/DISCARD MECHANISM:
Same mechanism as for the AQM based FP.

Four discardPriority thresholds are set on a connection queue, Default values:
Threshold
DP0 100%
DP1 90%
DP2 75%
DP3 35%
The discard thresholds apply to the common and the perVc queues.
The four DP thresholds are not configurable.
The mapping of (SC+CLP) to DP (DiscardPriority) is hardcoded:
DP Clp0 Clp1
Cbr DP1 DP3
rtVbr DP1 DP3
nrtVbr DP2 DP3
Ubr DP3 DP3
WiseDiscard:
Within each 4 CC (congestionControl level), are set the EPD, PPD, and EFCI thresholds:

The CC, EPD, PPD and EFCI thresholds are hardcoded with the following values:
perVc Queue
Thresholds
DP PPD EPD EFCI
CCO 100% 99% 90%
CC1 90% 89% 80%
35%
CC2 75% 74% 65%
CC3 35% 34% 25%
ALU confidential

Page 82/198
Remark:
On the AQM based card, the EPD thresholds are configured through the epdOffset attribute, which
is not supported by the GQM.
3.7.2.2.2.5 TRAFFICMANAGEMENT:
The trafficManagement features are provided by the GQM:

- Policing:
- dual rate GCRA, discarding, tagging,
- TrafficShaping:
- SingleRate and dualRate trafficShaping,
- The ShapeFairQueueing may apply to up 4 EP, with EP in the range [0, 7],
- Unshaped atmConnections are permitted on a shaped EP
- Basic VPT shaping supported .

The minimum shaping rate is 100 cells/s
3.7.2.2.2.6 AAL5:
- EPD, PPD, LPD and W-RED supported,

(Only EPD supported in the 16pOC3/Stm1 APC based FP)
3.7.2.2.2.7 OAM:
- According to I610,
- PM and CC not supported,
3.7.2.2.3 IP CHARACTERISTICS:
The FP IP forwarding capacity: 2,5 Gb/s (instead of 600 Mb/s)
The FP supports:
- Static routing,
- No support of ECMP,
- MPE,
- inverseARP,
- LocalMedia.
The AtmMpe Pnni sPvc Src/Dest carrierGrade.
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 (new)
|--------IP
|
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:
ALU confidential

Page 83/198
serviceCategory dropPrecedence Tx CLP

Cbr 1 0
Cbr 2 0
Cbr 3 1
rtVbr 1 0
rtVbr 2 0
rtVbr 3 1
nrtVbr 1 0
nrtVbr 2 0
nrtVbr 3 1
ubr 1 1
Ubr 2 1
ubr 3 1
Conclusion:
- The ubr atmConnection cells are always tagged
- The cbr and vbr atmConnection are tagged only for dropPrecedence
3.
3.7.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.7.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.
ALU confidential

Page 84/198
3.7.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.7.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.
Let’s 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.

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

DS MSA32 FP (doubleSlot):
SingleMode is used. (Since 16 ports STM-1 FP supports SingleMode only).
2 OC3/Stm1 port, one is the APS working line whereas the second is the APS protection line.
If APS is not configured, only one STM1 links may be used for traffic.
SS MSA32 FP:
The SS MSA32 FP doesn’t 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 FP’s (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.
ALU confidential

Page 85/198

- 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.7.2.3.3.1 ATM TRAFFICMANAGEMENT CHARACTERISTICS:
The MSA32 FP ATM TrafficManagement characteristics are those from the AQM.
3.7.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.
- 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.7.2.3.4 SPARING PANEL:

The MSS7K (therefore RNC AN) sparing system supports 6+1 sparing scheme for SS and DS MSA32
FP’s.
This mechanism allows switchover of E1/DS1 lines and related functionality from failed FP to a Sparing
FP.
ALU confidential

Page 86/198
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.
RNC Working Line Protected Line

16pOC3/Stm1
16pOC3/Stm1 FPFP 16pOC3/Stm1
16pOC3/Stm1 FP FP
STM1
1 spare FP:
MSS7K 00 11 22 33 44 55 66 77 88 99 10
10 11
11 12
12 13
13 14
14 15
15
MSA32
MSA32
MSA32
MSA32
MSA32
MSA32
MSA32
MSA32 E1/Stm1
MSA32 E1/Stm1
MSA32 E1/Stm1
MSA32 E1/Stm1
MSA32 E1/Stm1
MSA32 E1/Stm1
MSA32 E1/Stm1
SPARING
SPARING
6 main FP:
E1/Stm1 FP
E1/Stm1 FP
E1/Stm1 FP
E1/Stm1 FP
E1/Stm1 FP
E1/Stm1 FP
E1/Stm1 FP
FP
FP
FP
FP
FP
FP
FP
… … … … … … …
7 * 32 E1
SparingPanel
SparingPanel
6 * 32 E1 … … … … … …
Figure 3-44 MSA32 Sparing Panel
3.7.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:
ALU confidential

Page 87/198
- 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.7.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 VC12’s 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 doesn’t handle IP.
3.7.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
FP’s 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 FP’s.
A RNC-AN, PP7k based, has 16 slots, typically with 2 reserved for CP.
If RNC-AN is populated with four 2pSTM1e Ch FP’s, then 8 slots are reserved.
Six slots remain available for RNC / Mss7k interface. These six slots may be populated with three
MSA32E1/STM1 FP’s 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 FP’s, in such a way to be able to provide
Iub up to 4 STM1 Channelized links secured by sparingPanel.
When configuring a VC12, on one SDH link, a (k, l, m) triplet value is assigned to the VC12. This triplet
value identifies the VC12 within the VC4.
- ‘k’ is in the range [1, 2, 3],
- ‘l’ is in the range [1, …, 7] and
- ‘m’ is in the range [1, 2, 3].
From the VC12 assigned triplet value, the 2pStm1e Ch FP, computes the “AQM internal port number”
using the following formula:
AQM port number for an isolated E1:
AQM InternalPort number = (k-1) * 21+ (l-1) + (m-1) * 7
ALU confidential

Page 88/198
# SDH k l m AQM InternalPort # # SDH k l m AQM InternalPort #

0 1 1 1 0 1 1 1 1 0
0 1 2 1 1 1 1 2 1 1
0 1 3 1 2 1 1 3 1 2
0 1 4 1 3 1 1 4 1 3
0 1 5 1 4 1 1 5 1 4
0 1 6 1 5 1 1 6 1 5
0 1 7 1 6 1 1 7 1 6
0 1 1 2 7 1 1 1 2 7
0 1 2 2 8 1 1 2 2 8
0 1 3 2 9 1 1 3 2 9
0 1 4 2 10 1 1 4 2 10
0 1 5 2 11 1 1 5 2 11
0 1 6 2 12 1 1 6 2 12
0 1 7 2 13 1 1 7 2 13
AQM 0
AQM 2
0 1 1 3 14 1 1 1 3 14
0 1 2 3 15 1 1 2 3 15
0 1 3 3 16 1 1 3 3 16
0 1 4 3 17 1 1 4 3 17
0 1 5 3 18 1 1 5 3 18
0 1 6 3 19 1 1 6 3 19
0 1 7 3 20 1 1 7 3 20
0 2 1 1 21 1 2 1 1 21
0 2 2 1 22 1 2 2 1 22
0 2 3 1 23 1 2 3 1 23
0 2 4 1 24 1 2 4 1 24
0 2 5 1 25 1 2 5 1 25
0 2 6 1 26 1 2 6 1 26
0 2 7 1 27 1 2 7 1 27
0 2 1 2 28 1 2 1 2 28
0 2 2 2 29 1 2 2 2 29
0 2 3 2 30 1 2 3 2 30
0 2 4 2 31 1 2 4 2 31
0 2 5 2 32 1 2 5 2 32
0 2 6 2 33 1 2 6 2 33
0 2 7 2 34 1 2 7 2 34
0 2 1 3 35 1 2 1 3 35
0 2 2 3 36 1 2 2 3 36
0 2 3 3 37 1 2 3 3 37
0 2 4 3 38 1 2 4 3 38
0 2 5 3 39 1 2 5 3 39
0 2 6 3 40 1 2 6 3 40
0 2 7 3 41 1 2 7 3 41
0 3 1 1 42 1 3 1 1 42
0 3 2 1 43 1 3 2 1 43
0 3 3 1 44 1 3 3 1 44
0 3 4 1 45 1 3 4 1 45
AQM 1
AQM 3
0 3 5 1 46 1 3 5 1 46
0 3 6 1 47 1 3 6 1 47
0 3 7 1 48 1 3 7 1 48
0 3 1 2 49 1 3 1 2 49
0 3 2 2 50 1 3 2 2 50
0 3 3 2 51 1 3 3 2 51
0 3 4 2 52 1 3 4 2 52
0 3 5 2 53 1 3 5 2 53
0 3 6 2 54 1 3 6 2 54
0 3 7 2 55 1 3 7 2 55
0 3 1 3 56 1 3 1 3 56
0 3 2 3 57 1 3 2 3 57
0 3 3 3 58 1 3 3 3 58
0 3 4 3 59 Not Used when ATM 1 3 4 3 59
0 3 5 3 60 standalone E1. 1 3 5 3 60
0 3 6 3 61 1 3 6 3 61
0 3 7 3 62 1 3 7 3 62
Figure 3-45 AQM internal Port number
ALU confidential

Page 89/198

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

2pStm1e Ch FP supports ATM, IMA and AAL1 unstructured CES.
ATM service is used in so called multi-PCM configuration, where UMTS NodeBs are connected to RNS
via multiple E1 that operate as separate links (not linked into IMA group).
ATM interfaces support:

- PNNI and UNI protocols,
- PVC, SPVC and SVC,
- CBR, rtVBR, nrtVBR and UBR service categories,
- 114 E1s ports per FP (57 per STM-1 port).
Note that STM-1 Channelized supports 63 VC12. 6 of them cannot be used for ATM service
(VC12 identified by k=3, l= 2 to 7, m = 3),
- UNI / NNI Atm interface types (maxVpiBits set with value 8/12),
- up to 8000 PVCs (nPVCs) per FP,
- up to (16000-nPVCs) SPVCs per FP,
- up to 200 VCC with F5 OAM loopBacks configured,
The 2pStm1 e Ch Fp is composed of 4 AQM components. The capacity of the FP and the AQM in terms
of amount of atmConnections is configured through the commands:
- Lp Eng Arc Ov connectionPoolCapacity,
- Lp Eng Arc Ov protectedConnectionPoolCapacity,
- Lp Eng Arc Ov Aqm/n connectionPoolCapacity, with n in the range: [0, 3].
Remark: the protectedConnectionPoolCapacity command refers to the use of sparingPanel.
The setting of these components must satisfy the rules:
Arc Ov connectionPoolCapacity + Arc Ov protectedConnectionPoolCapacity ≤ 16 000
Aqm/n Ov connectionPoolCapacity ≤ 6 000
Σ n = [0, 3] Aqm/n Ov connectionPoolCap ≤ Arc Ov connectionPoolCap + protConnectionPoolCap
Each CES connection provisioned on the 2pSTM1eCh FP requires 1 connection resource.
The connectionPoolCapacity is set with a value higher or equal to the expected maximum unprotected
atmConnections and CES connections.
The protectedConnectionPoolCapacity is set with a value higher or equal to the expected maximum
protected atmConnections and CES connections.
ALU confidential

Page 90/198
3.7.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.7.2.6.5 IMA CHARACTERISTICS:

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

AAL1 CES interfaces support:
- Unstructured (full E1)
ALU confidential

Page 91/198
- 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.7.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
Here below a representation of the Mss7k populated with 2pStm1ElectricalChannelized FP

protected with SparingPanel.
PP7K:
2pStm1 Ch 0 1 2 3 4 5 6 8 9 10 11 12 13 14 15 16
SparingPanel
2pOC3 Clear FP
2pOC3 Clear FP
2pOC3 Clear FP
2pSTM1 e Ch
2pSTM1 e Ch
2pSTM1 e Ch
2pSTM1 e Ch
SparingPanel
SparingPanel
CP2
CP2
SparingPanel SparingPanel
Stm1 Stm1 Stm1 Stm1
Figure 3-46 SparingPanel on 2pStm1ElectricalChannelized FP protected.
3.7.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.7.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

Page 92/198
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.7.3 RNC TYPES
3.7.3.1 RNC 1500:

Reference: [R101].
The RNC-CN is removed from the RNC. The RNC-IN supports all the functions previously assured by
the RNC-CN. All the signaling (NBAP, RANAP, RNSAP, ALCAP and SAAL-NNI and MTP3) are
managed by the RNC-IN. The RNC 1500 is functionally equivalent to the RNC 1000 i.e. same feature
content, capacity, performance and reliability.
The Impacts on Transport:

- No more Icn interface,
- The Iub CP and CCP atmConnections go through the PNNI sPvc Hairpins,
- 16pOc3/Stm1 Attributes are updated to reflect the new Transmission and Atm connection
connectivity scheme.
As an option, a POC is included in the RNC 1500.
A PS-FP is composed of 6 PMC cards.

Six different kinds of PMC roles are specified: PMC-PC, PMC-RAB, PMC-M, PMC-NI, PMC-TMU
and PMC-OMU.
The PMC Role is driven by the position of the PSFP Card in the shelf:
- The PMC-M are hosted by the PSFP 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 TMU on a 12 PSFP shelf. The PMC-
TMU is in position 1 on each PSFP card. PSFP cards with two TMUs are located in slot 10 and 11
and the second PMC-TMU is in PMC position 5,
- All the remaining PMC are assigned the role of RAB,
- The active and standby CP are in slot 0 and 1 respectively
- The active and standby 16p/OC3 FP are in slot 8 and 9 respectively.
Moreover each PS-FP is populated with one PDC processor.
The PS-FP components:
ALU confidential

Page 93/198
- PDC:
Each PDC provides a management functions for that one PS-FP card only. Moreover the Saal-
NNI is implemented on PDC. The Saal-NNI functions are load shared across the PDC of all the
PS-FP cards with exception of those running PMC-NI.
- PMC-OMU:
The OAM functionality and TMU management functions are implemented on 2 PMC-OMU
components located on different PS-FP cards.
The sparing scheme is 1+1. The PMC-OMU switch of activity involves no interruption of
service except in case of double fault scenarios.
- PMC-M:
The PMC-M hosts the CID management and the Alcap for IuCS and Iur interfaces.
The RNC is populated with two PMC-M components, working in 1+1 redundancy scheme.
Two PMC-M components reside on different PS-FP cards.
The PMC-M switch of activity involves 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 functions are implemented on two PMC-NI components located on
different PS-FP cards.
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 of activity involves no interruption of existing
calls or service except in double fault scenarios.
- PMC-TMU:
The PMC-TMU is in charge of processing UMTS call protocols: RANAP, RNSAP, and NBAP
(Supports RRM, RRC, aal2Link CAC).
Up to 14 PMC-TMU components are spread over all the PS-FP in load sharing mode. The
sparing scheme is N+1 if 7 or fewer PS-FP 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’s within 30 seconds but individual
Radio Links are lost. Individual calls are managed by all the PMC-TMU’s 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-RAB’s spread over all the PS-FP 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’s on
other PS-FP cards with no loss of common channel service. Individual call user planes are
managed by all the PMC-RAB’s in load sharing mode. If a PMC-RAB fails the calls on
that PMC-RAB are lost.
- PMC-PC:
The aal2 to UDP conversion function is implemented on one PMC-PC per PS-FP. 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’s located on other PS-FP cards without interruption of cell
common channels or calls in progress.
ALU confidential

Page 94/198
RNC-IN
PS
PS FP
FP 00 PS
PS FP
FP 11 PS
PS FP
FP 22 PS
PS FP
FP 33 PS
PS FP
FP 44 PS
PS FP
FP 55 PS
PS FP
FP 66 PS
PS FP
FP 77 PS
PS FP
FP 88 PS
PS FP
FP 99 PS
PS FP
FP 10
10 PS
PS FP
FP 11
11
Pdc
Pdc Pdc
Pdc Pdc
Pdc Pdc
Pdc Pdc
Pdc Pdc
Pdc Pdc
Pdc Pdc
Pdc Pdc
Pdc Pdc
Pdc
Pdc
Pdc Pdc
Pdc
saalnni
saalnni saalnni
saalnni saalnni
saalnni saalnni
saalnni saalnni
saalnni saalnni
saalnni saalnni
saalnni saalnni
saalnni saalnni
saalnni saalnni
saalnni
2 Slots for 16pOC3 FP

RAB
RAB RAB
RAB OMU
OMU OMU
OMU RAB
RAB RAB
RAB TMU
TMU TMU
TMU RAB
RAB RAB
RAB RAB
RAB RAB
RAB 5
2 Slots for CP3
PC
PC PC
PC PC
PC PC
PC PC
PC PC
PC PC
PC PC
PC PC
PC PC
PC PC
PC PC
PC 4
RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB 3
RAB
RAB RAB
RAB NI
NI NI
NI RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB 2
TMU
TMU TMU
TMU TMU
TMU TMU
TMU TMU
TMU TMU
TMU TMU
TMU TMU
TMU TMU
TMU TMU
TMU TMU
TMU TMU
TMU 1
PMC-M
PMC-M PMC-M
PMC-M RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB RAB
RAB 0
Slot 2 Slot 3 Slot 4 Slot 5 Slot 6 Slot 7 Slot 10 Slot 11 Slot 12 Slot 13 Slot 14 Slot 15
Figure 3-47 RNC 1500 PS-FP PMC assignment Example
3.7.4 AAL2 COMPONENTS:

Within the RNC, the IuxIf component is removed and replaces by IucsIf/IurIf/IubIf and aal2If
components.
All the aal2 Paths configured between the RNC and an adjacent aal2 point node are configured under an
aal2If instance.
In the context of Iub interface, the adjacent aal2 Point is a NodeB, the case of aal2Switch is not
supported.
Therefore an aal2If instance is assigned to each nodeB, within an aal2If instance are grouped all paths
serving the NodeB.
Moreover an IubIf instance is assigned to each NodeB. The NodeB assigned aal2If is associated to the
NodeB assigned IubIf.
Rule: IubTEG_RNC aal2 Component_1

On Iub interface, there is a one to one relation between aal2If and IubIf.
The aal2if instances associated to the IubIf instances cannot be assigned to any other IucsIf,
IurIf or IubIf instances.
Range of the RNC aal2 components:
Rule: IubTEG_ RNC aal2 Component _2

• Up to 2 IucsIf instances.
• Up to 20 IurIf instances ..
• Up to 200 IubIf instances .
• Up to 10 aal2If instances under an IucsIf instance,
• Up to 10 aal2If instances under an IurIf instance,
• Up to 16 aal2If instances per remote aal2 endPoint node (A2EA).
ALU confidential

Page 95/198
aal2If i
Paths aal2If 1
Alcap bearer: Adjacent aal2 node. Paths
AlcapConn: DPC, NI
aal2If j
Iub
Paths
iubIf 1
Alcap bearer: Adjacent aal2 node. SignalingBearer
AlcapConn: DPC, NI userPlane
aal2If 1
iuCSIf 1
UserPlane
aal2If i
aal2If j
aal2If 2
iuRIf 1, 2, … Paths
UserPlane
aal2If i
aal2If j Iub iubIf 2
SignalingBearer
2/ Association between aal2If and aal2Path and PC. userPlane
aal2If 2
3/ Association between IubIf, IucsIf, IurIf and aal2If instance.
Figure 3-48 RNC aal2 mapping table
Remark:
Note that for aal2If that are used for IubIf, there is no Alcap bearer or AlcapConn.
3.7.5 AAL2 PATHS

The RNC supports up to 2100 paths. This capacity is shared between all the aal2 interfaces of the RNC.
The pathId is coded on 2 bytes in the range [0, 65535].
Rule: IubTEG_RNC-aal2-Path_1
The RNC supports up to 2100 paths, identified by a pathId in the range [0, 65535].
The pathIds must be unique within an aal2If, even if the PathIds belongs to different bandwidthPool.
3.7.6 AAL2 PATH ASSIGNMENT TO PMC-PC

At RNC start up phase, the already configured Paths are assigned to PMC-PCs.
An algorithm within the TBM is in charge of distributing configured Iub, Iur and IuCS aal2 Paths on the
different PSFP cards in such a way the PMC-PC are equally loaded.
On Iub interface all Paths under a particular aal2If are assigned to one single PMC-PC, whatever the
aal2 Path Qos.
ALU confidential

Page 96/198
Aal2If
Aal2If ii
PathGroup 1
Qos 0
Path 1
Path 2
PathGroup 2
Qos 1
Path 3
Path 4
PathGroup 3
Qos 2
Path 5
Qos 3
Figure 3-49 pathGroup definition
Rule: IubTEG_PathAssignment_1
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.7.7 AAL2 CID DISTRIBUTION

All Paths within an aal2If (=within an IubIf) are assigned to one single PMC-PC.
The loadBalancingMethod parameter configured on an UTRAN aal2 interface, determines the choice of
a path for a CID seizure.
− 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: Iu_CidDistribution_1
On Iub interface, the loadBalancingMethod is set with Link.
Remark: the loadBalancingMethod is set with PC on IuCS and Iur interface.
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’s.
Abnormal cases:
If the PC-CAC rejects the call, no other CID selection is done, since all paths within the aal2If are
assigned to the same PMC-PC.
ALU confidential

Page 97/198
3.7.8 AAL2 CAC

The Aal2 CAC’s described in this section is the RNC implementation.
For AAL2 Connections, is implemented in RNC two CAC algorithms: the AAL2 Link CAC and the
AAL2 PC CAC, which regulate traffic in call establishment phase, either at Iuxif level or at PMC-PC
level.
3.7.8.1 AAL2 LINK CAC:

The aal2Link CAC is a trafficRegulation mechanism located in the RNC.
It is based on GCAC algorithm.
Unlike the atm CAC, the aal2Link CAC is invoked when traffic is running before requesting a CID for
the call.
Moreover the aal2Link CAC achieves a Load balancing on the Iub downlink direction.
3.7.8.1.1 AAL2 LINK CAC PARAMETERS

On the Iub interface, the RNC regulates traffic either on:
- per aal2 interface basis (IubIf) or
- per aal2 interface and per aal2 qos basis (aal2 qos within the IubIf), or
- per aal2 path basis.
For each kind of regulation granularity, the bandwidth taken into consideration depends on the configured
vcc trafficDescriptor values.
Beside is configured per Utran interface and per kind of call, a bandwidth to reserve.
3.7.8.1.1.1 AVAILABLE CELL RATE:
For each aal2 vcc, by means of GCAC algorithm, RNC computes the ECRgcac.
The bandwidth considered by the aal2Link Cac, called the ACR (AvailableCellRate), is either the aal2If
bandwidth, the per aal2interface and per aal2Qos bandwidth or the per aal2Path bandwidth.
These 3 options allow either a regulation at NodeB aal2 interface level, at NodeB aal2Qos level or at path
level.
The choice of the bandwidth reference for the regulation is set through the component cacMethod
(cacm):
- If cacm= aal2if:
The bandwidth reference for regulation is the bandwidth per adjacent aal2 node, whatever the
aal2Qos,
- If cacm= Qos:
The bandwidth reference for regulation is the bandwidth per adjacent aal2 node and per
aal2Qos: UP DS bandwidth on one side and UP NDS bandwidth on other side,
- If cacm= Path:
The bandwidth reference for regulation is the bandwidth per aal2Path,
In the specific case of cacm=Qos, the RNC allows specifying a bandwidth for each aal2Qos and a
bandwidth common for all the aal2Qos traffic through the parameter: aal2If/qosXBwReservation.
Indeed by means of configuration part of the aal2 vcc bandwidth is reserved for the associated aal2 qos,
the vcc remaining bandwidth is reserved for the aal2 traffic whatever the aal2 qos required:
In the specific case of cacm=Path, the parameter: aal2If/qosXBwReservation is useless.
ALU confidential

Page 98/198
Exemple:
IuxIf x
Interface aal2 bw distribution:
CAC Method = qos CAC
qos0BwReservation = 10%
qos1BwReservation = 50% Qos0 + Qos1
ACR =
IuxIf ACR = 3000 c/s

QOS 0 1900 c/s
Path 1
Vcc ECRgcac = 1000 c/s Qos0 ACR
= 100 c/s
QOS 1
Path 2 Qos1 ACR
= 1000 c/s
Vcc ECRgcac = 1000 c/s
Path 3
Vcc ECRgcac = 1000 c/s
Figure 3-50 per aal2 qos CAC exemple
According to the bandwidthReference option, the ACR is calculated as following:
Rule: IubTEG_CAC_01
If cacm= aal2if, Aal2LinkCAC bandwidthReference:
ACR = ΣIub UP DS+NDS VCC ECRGCAC
If cacm= Qos, Aal2LinkCAC bandwidthReference:

ACR QOS0 = qos0BwReservation% * ΣIub UP DS VCC ECRGCAC
ACR QOS1 = qos1BwReservation% * ΣIub UP NDS VCC ECRGCAC
ACR QOS2 = qos2BwReservation% * Iub UP Hsdpa Vcc ECRGCAC
Common ACR =
(100% - qos0BwReservation%) * ΣIub UP DS VCC ECRGCAC +
(100% - qos1BwReservation%) * ΣIub UP NDS VCC ECRGCAC +

(100% - qos2BwReservation%) * Iub UP Hsdpa Vcc ECRGCAC
If cacm= Path, Aal2LinkCAC bandwidthReference:

Aal2LinkCAC bandwidthReference = ACR = Iub UP Vcc ECRGCAC
See MML: aal2If/CAC Method Attribute = aal2If CAC, Qos CAC, Path.
See MML: aal2If/qosXBwReservation = % of the Vcc ECRgcac supporting this aal2 Qos traffic. Range:
Decimal (0…100)
Rule: IubTEG_CAC_02
It is recommended to regulate aal2 traffic at aal2 interface bandwidth, in other word cacm= aal2if.
Cacm=Qos or Path is reserved for specific contexts of interworking with some otherVendor nodes.
ALU confidential

Page 99/198
An ACR is calculated by the RNC for each both transmission side.

Since on the RNC Side, the Reception and Transmission trafficDescriptors are configured with the same
values, then one ACR value applies per NodeB for each transmission side.
Remark:
If cacm=aal2if, then the parameter qosXbwReservation is not taken into consideration by the
RNC aal2LinkCac.
All value in the range [0, 100%] are accepted by the RNC and has no effect on the aal2 Link
Cac regulation since cacm=aal2if.
Remark:
- Reason for regulating at IubIf bandwidth and not at Path bandwidth, is due to the fact that if
crossing an ATM backbone, ATM regulation would apply at VP level instead of at VC level
(Policing); assuming that the VP formation consists in all the aal2 vcc serving one remote aal2
endPoint node.
- If one path fails (link failure, or reception of AIS/RDI), the IubIf bandwidth is reduced by the path
bandwidth.
3.7.8.1.1.2 EQUIVALENT BIT RATE:
In the RNC is configured per Utran interface, per direction and per type of traffic (TRB, dSRB, cSRB)
an estimation of the required bandwidth.
The estimation of bandwidth per kind of traffic is the result of a UMTS Dimensioning exercise.
List of the parameters specifying the reserved bandwidth per kind of traffic, per direction and per Utran
interface:
DlRbSetConf/IuQaal2equivalentBitRate /DL IuEBR/
DlRbSetConf/IurQaal2equivalentBitRate /DL IurEBR/
DlRbSetConf/IubQaal2equivalentBitRate /DL IubEBR/
DlRbSetConf/IuQaal2MaxBitRate
DlRbSetConf/IurQaal2MaxBitRate
DlRbSetConf/IubQaal2MaxBitRate
UlRbSetConf/IuQaal2equivalentBitRate /UL IuEBR/

UlRbSetConf/IurQaal2equivalentBitRate /UL IurEBR/
UlRbSetConf/IubQaal2equivalentBitRate /UL IubEBR/
UlRbSetConf/IuQaal2MaxBitRate
UlRbSetConf/IurQaal2MaxBitRate
UlRbSetConf/IubQaal2MaxBitRate
For all the above parameters, the range is [0, 2 097 152 bit/s] by step 64.
All these parameters are class3, then accessible to the customer. With exception of the
parameters specifying the commonSRB (FACH, PCH and RACH) reserved bandwidth which
are class0.
Rule: IubTEG_CAC_04
The “qaal2IuxequivalentBitRate” is configured by step of 64 bit/s: X = N * 64.
On the OMC is configured X, whereas RNC considers N.
The maximum value for qAAL2equivalentBitrate is:
− Xmax = [2048*1024 bits/s] in RNC,
− Nmax = [2048*1024 bits/s] / 64, in OMC.

ALU confidential

Page 100/198
Therefore QAAL2equivalentBitRate range is:

− [0… 32768] in the RNC,
− [0… 2 097 152] in the OMC.
The “qAAL2equivalentBitrate” is an evaluation of RadioBearer bandwidth at aal2 SSAR subLayer.

Since the aal2linkCAC works at atm layer (The ACR is calculated at atm layer), the RNC takes into
consideration aal2 CPS subLayer overhead and calculates the radio Bearer bandwidth to reserve at atm
layer. It is considered that CPS subLayer generates an overhead of 21% of the SDU whatever the
radioBearer.
Assume that ebr (equivalent Bit Rate) is the bandwidth reserved per radioBearer at ATM layer:
Ebr (cells/s) = [1, 21 * qAAL2equivalentBitrate] / [53*8].
with qAAL2equivalentBitrate, the value configured in the RNC.
UL Iub qaal2equivalentBitRate UL Iub EBR DL Iub qaal2equivalentBitRate DL Iub EBR

RAB (bit/s at SSSAR layer) (cell/s) (bit/s at SSSAR layer) (cell/s)
Speech 12.2K 16384 46,76 15616 44,56
Conv 64K UL- 64K DL 66816 190,68 65984 188,30
Str 14.4K UL- 14.4K DL 15808 45,11 15424 44,02
Str 57.6K UL- 57.6K DL 59008 168,40 58624 167,30
Str 16 UL - 64 DL 19584 55,89 66624 190,13
SRB 3.4K 5184 14,79 4800 13,70
IB 8K UL- 8K DL 9792 27,94 9408 26,85

IB 32K UL- 32K DL 35008 99,90 34624 98,81
I/B 64K UL-64K DL 70016 199,81 69184 197,44
I/B 64K UL-128K DL 70016 199,81 136384 389,21
I/B 64K UL-256K DL 70016 199,81 272832 778,60
I/B 64K UL-384K DL 70016 199,81 407232 1162,15
I/B 128K UL-128K DL 137216 391,58 68224 194,70
I/B 64K UL-HSDPA DL 70016 199,81 0 0,00
I/B 128K UL-HSDPA DL 137216 391,58 0 0,00
I/B 384K UL-HSDPA DL 409600 1168,91 0 0,00
FACH [1] (IB32K) 0 0,00 0 0,00

FACH [0] (CCCH+DCCH) 0 0,00 0 0,00
PCH 0 0,00 16000 45,66
RACH (with IB32K) 0 0,00 0 0,00
Figure 3-51 Example of Ebr values
When the traffic is running, each time a cid is requested by the RNC-CN, either for TRB, dedicated or
commonSRB, the RNC-CN includes in the request the corresponding RAB reception and transmission
bandwidth, through the parameter “qAAL2equivalentBitrate”.
This value is compared to the remaining bandwidth (ECR – bandwidth already reserved by other CIDs).
If the requested bandwidth is available, the cid is established and the remaining bandwidth is updated.
Otherwise, the cid request is rejected.
Moreover each time a TRB is setup, a dedicatedSRB is associated. Therefore the ACR is reduced by
TRB associated ebr and per dedicated associated ebr.
Furthermore, for each nodeB, the ACR is reduced by the ebr associated to commonSRB. Amount of set
of commonSRB depends on NodeB configuration (amount of radio cell per nodeB).
One CID is required per:

- TRB,
- dedicatedSRB,
- RACH commonSRB,
- FACH commonSRB, as many CIDs reserved as amount of configured FACHs,
ALU confidential

Page 101/198
- PCH commonSRB,
3.4.2.1.2 AAL2 LINK CAC TRAFFIC REGULATION:

For each call establishment request, the EBR value configured against the RAB type, is compared to the
ACR:
- if EBR < ACR, the call is accepted and ACR = ACR –EBR,
- if EBR > ACR, the call is rejected.
Exemple:
Assuming:
- qaal2IubequivalentBitRate configured for DL bearer 384 = 408 000 bits/s , then at atm layer
ebr = 1164 cells / s
- SCR = 2000
- PCR = 4000
Then ECRGCAC computed is: ECRGCAC = 2667.
On first PS 64/384 call establishment request, the cid is allocated and the call established.
Remaining bandwidth is updated: ACR = 2667 – 1164 = 1503,
On second PS 64/384 call establishment request, the cid is allocated and the call established.
Remaining bandwidth is updated: ACR = 1503 –1164 = 339.
On third PS 64/384 call establishment request, the cid request will be rejected by the IN because
1164 > 339, so the RNC will reject the Rab Assignment for that call.
In this example are not taken into account, the dedicatedSRB associated to the TRB and
commonSRBs.
Furthermore the bandwidth reserved per call at the aal2 Link CAC level may vary [R150].
Indeed when a user is reconfigured towards a lower or higher RB bit rate, the aal2Link CAC updates le
bandwidth reserved for the call, taking into consideration the EBR configured against the target RB for
both DL and UL.
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.
If the trafficShaping at VC level is activated in the NodeB, the setting of the NodeB Vcc
trafficDescriptor and the setting of the RNC EBR must be coordinated. Indeed two regulation
mechanisms are activated on the Iub interface:
- The NodeB trafficShaping: regulation of the atm Vcc uplink traffic,
- The RNC Aal2 linkCac: regulation of amount of simultaneous UMTS calls per nodeB, in call
establishment phase.
The setting of the RNC EBR values and the TrafficDescriptor values are the result of an UMTS
Dimensioning exercise. This exercise must takes into account the conjunction of these two regulation
mechanisms on the Iub interface.
3.7.8.1.2 AAL2 LINK CAC TRAFFICMEASUREMENT:

Two trafficMeasurement counters are available on AAL2 CAC:
CID_LINK_CAC_FAIL_CNT:
Keeps track of cid allocation/setup failures as a direct result of link CAC.
ALU confidential

Page 102/198
LINK_CAC_THRES_CNT:
Keeps track of the number of times the accumulated bandwidth on an access comes within a certain
percentage or threshold of the provisioned ECR of an access.
3.7.8.1.3 AAL2 LINK CAC PRINTOUT:

By means of command: ‘showTbmIuxPath(Iuxif value,Pathid value)’, is displayed ECRgcac calculated
by the RNC-IN based on configured trafficDescriptors.
ECRgcac is displayed in parameter ProvECR:
provEcr = 1000 * ECRgcac
This command required two imput parameters: IuxIf which identified the remote UMTS AAL2 node, and
Pathid which identified an aal2 path.
E.g.:
(iuxifIUR=350, path=4433 QOS=0)
-> showTbmIuxPath(Iuxif value,Pathid value)
IuxIfId = IuxIf value
PathId = PathId value
numOfIdleCids = 248
numOfAllocCids = 0
provEcr = 2164295
accuULEcr =0
accuDLEcr =0
pcLoad =0
Note:
AccuUL/DSLEcr!: Accumulated ECR represents the utilization of the VCC. Unit: 1000 * Cell/s.
ProvECR is calculated by RNC, based on following trafficDescriptor:
0> d AtmIf/815 Vcc/3.48 tm
AtmIf/815 Vcc/3.48 Tm
TxTrafficDescType = 6
TxTrafficDescParm = 1: 2358
2: 2000
3: 20
4: 0
5: 2358
Conclusion:
ProvECR = 1000 * [2*2358*2000/(2000+2358)].
ACR equals to sum of [provEcr/1000] related to an IuxIf.
3.7.8.2 AAL2 PC CAC:

The PC CAC is not invoked on Iub interface.
ALU confidential

Page 103/198
3.7.9 AAL2 CONGESTION MANAGEMENT

Since Hsdpa traffic is supported, the RNC PMC-PC and PMC-RAB are enhanced with aal2 congestion
management mechanisms in such a way to improve the traffic efficiency on the Iub interface:
- It ensures that the Hsdpa traffic not permanently transmits at a throughput higher than can be
carried over the Iub interface.
- It prevents incomplete Hsdpa frames to reach NodeB.
- It also controls delays, therefore no R99 frames that arrive at NodeB would miss the receive
window.
=> Therefore there is no useless traffic sent on Iub transport.
The aal2 congestion management mechanism consists in discarding excess aal2 traffic for a given aal2
qos, moreover the aal2 congestion management mechanism anticipates congestion state by interrupting
momentarily transmission.
The RNC Iub aal2 congestion management encompasses two regulation mechanisms:
- ControlledDiscard and
- BackPressure.
Rule: IubTEG_aal2CongestionManagement_1
If regulation is required, it is recommended to activate both together:
ControlledDiscard and BackPressure.
The Iub aal2 congestionManagement applies only to Iub interface (IubIf), on downlink traffic.
It is not supported by the other UTRAN aal2 interfaces (IuCS/Iur).
The regulation applies either to the NodeB whole bandwidth or per nodeB bandwidthPool.
Activation/deactivation:
Initially, the aal2 congestion management mechanism was activated/deactivated for all the
nodeB under the RNC. MML:
RNC-IN/IubTransportFlowControl (Fc)=Disabled/DiscardOny/Discard&BackPressure.
In the current release the mechanism may be activated/deactivated either for:

- All the nodeB under the RNC, or
- Per nodeB, or
- Per bandwidthPool.
This enhancement was possible thanks to the introduction of the new subComponent:
CongestionMgt under aal2If and BwPool component.
MML:
- RNC-IN/IubTransportFlowControl (Fc)
- RNC-IN/aal2If/congestionMgt (Cm)/ qosBPt
- RNC-IN/aal2If/congestionMgt (Cm)/ qosDt,
- RNC-IN/aal2If/BwPool/congestionMgt (Cm)/ qosBPt
- RNC-IN/aal2If/BwPool/congestionMgt (Cm)/ qosDt,
Regulation granularity:
Initially, the aal2 congestion management mechanism applies regulation at the whole nodeB
bandwidth.
In the current release, the aal2 congestion management mechanism applies regulation either at
the whole nodeB bandwidth or at bandwidthPool level.
ApplicationContext:
Initially, the aal2CongestionManagement was available only if NodeB configured with one
IMA linkGroup.
ALU confidential

Page 104/198
In the current release, the aal2CongestionManagement is available for different NodeB

transport configuration:
- IMA, or
- xPcm, or
- Mix of IMA and xPcm.
The congestion management is compatible with both aal2 link CAC methods:
Aal2If CacMethod = aal2IF,
Aal2If CacMethod = Qos.
The cacm is set according to the kind of bandwidthPool.
3.7.9.1 BANDWIDTHPOOL:
A bandwidthPool is a set of aal2Paths all terminating on one nodeB.
The bandwidthPool concept has been introduced in the RNC to distinguish the aal2Paths from a nodeB,
configured on different NodeB Transport media:
- The NodeB paths configured on two different IMA linkGroups,
- The NodeB paths configured on different E1 (mode xPcm),
- The NodeB paths configured on one side on an IMA linkGroups, and the NodeB
configured on single E1 (mix of xPcm and IMA mode),
- Moreover the aal2 paths configured on a single nodeB IMA group may be
distributed on different bandwidthPools.
The bandwidthPool granularity is taken into consideration by the aal2CongestionManagement

mechanism, and not considers by the aal2 linkCac.
The composition of a bandwidthPool with a set of Path is done by configuration.
Definitions:
- A dedicated bandwidthPool is a set of paths handling exclusively Hspa or R99 traffic,
- A shared bandwidthPool is a set of paths handling both Hspa and R99 traffic,
Aal2CongestionManagement:
Each bandwidthPool has its own instance of aal2CongestionManagement parameters and thresholds.
Limitations:
Rule: IubTEG_ aal2bandwidthPool_1

- Up to 16 bandwidthPools per aal2If,
- Each bandwidthPool may be populated with up to 16 aal2 paths.
- within an aal2If and within a bandwidthPool, the pathId must be unique,
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.
ApplicationContexts:
The bandwidthPool concept has been specified to still permit the activation of the
aal2CongestionManagement regulation for the following nodeB Transport configurations:
- n*E1 xPcm and p*E1 IMA:
- The R99 up, oam and signaling vcc are configured on xPcm, whereas the Hspa vcc are
configured over the IMA.
⇒ The RNC is then configured with n R99 dedicated bandwidthPool and 1 Hspa dedicated
bandwidthPool.
- n*E1 xPcm:
- The R99 up, Hspa, oam and signaling vcc are distributed over the single E1. Some E1
may be dedicated to either R99 or to Hspa traffic; some others may be shared between
R99 and Hspa traffic.
⇒ The RNC is then configured with n bandwidthPools.
- 2 IMA linkGroups:
ALU confidential

Page 105/198
- Since the xCCM is supported, the nodeB may be configured with two IMA linkGroups,
each IMA linkGroup may be dedicated to R99 or Hspa traffic, or shared between R99
and Hspa traffic.
⇒ The RNC is then configured with 2 bandwidthPools.
- 1 IMA linkGroups and several bandwidthPools:

- The nodeB is configured with one single IMA linkGroup, on the RNC side are
configured two or more shared or dedicated bandwidthPools. In other words the RNC
split the NodeB IMA linkGroup bandwidth in several set of bandwidth.
RNC parameters:
The bandwidthPool component is introduced in the RNC aal2 model as a subComponent of the
aal2If, the aal2Path being a subComponent of the bandwidthPool:
The RNC aal2CongestionManagement regulates the downlink traffic for the bandwidthPool
granularity.
The RNC aal2 congestionManagement regulation thresholds are based on:

- The trafficDescriptor from the aal2 vcc belonging to the bwPool,
- The QosDt and qosBp parameters configured either at:
- RncIn level through: IubTransportFlowControl component, or
- aal2If level through: Congestionmanagement component, or
- bwPool level through: Congestionmanagement component.
Remarks:
- In the previous releases, only one set of QosDt and qosBp parameters for the whole
RNC Iub configured under Rnc root.
- The parameters configured at the bandwidthPool level overlap those configured at the
aal2If or the RNC levels.
- The parameters configured at the aal2If level overlap those configured at the RNC
levels.
- Ability to activate aal2 congestionManagement for one BwPool, and not activate it on
another BwPool under the same aal2If.
- Ability to activate aal2 congestionManagement for one aal2If, and not activate it on
another aal2if under the same RNC.
- If no hspa vcc under 1 bandwidthPool, the RNC aal2CongestionManagement may be
deactivated for this bandwidthPool.
ALU confidential

Page 106/198
RNCIN
IubTransportFlowControl (Fc)
qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z
qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z
aal2If i
congestionMgt (Cm) / optional

BwPool/x qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z
path/i
path/j
BwPool/y
path/k qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z
path/l
qosDiscardThreshold, qosDt 0 0 1 x 2 y 3 z
Figure 52 CongestionManagement parameter
Each following sections is an analyze of the different contexts which can be covered by the
bandwidthPool feature:
Remarks:
- The bandwidthPool component is also available under the aal2If assigned to the Iur and the
IuCS, but not used.
3.7.9.1.1 N*E1 XPCM & P*E1 IMA

The NodeB is configured with n*E1 in xPcm mode and p*E1 within an IMA linkGroup.
The Hspa vcc are configured over the IMA linkGroup whereas the R99+Sig+Oam vcc are distributed
over the single E1 in xPcm mode.
On the RNC side:
- One R99 dedicated bandwidthPool is configured per single E1 (xPcm); it consists in
one aal2Qos0 and one aal2Qos1 Paths configured over the E1, and
- One Hspa dedicated bandwidthPool is configured; it consists of all the aal2Qos2 paths
configured over the IMA linkGroup.
ALU confidential

Page 107/198
IubIf i
xPcm
E1 BwPool i aal2If i
Qos0 Path
Qos1 Path
E1 BwPool j
Qos0 Path
atmSwitch
Qos1 Path
NodeB
RNC
BwPool k
Qos2 Path
Qos2 Path
Qos2 Path
IMA 3 E1
Hspa vcc amount:

In such a way to take benefit of the NodeB IMA defense, as many Hspa vcc are configured as
amount of E1 within the IMA linkGroup.

Within an Hspa dedicated bandwidthPool associated to a NodeB IMA linkGroup, are
configured as many Hspa vcc as amount of E1 within the IMA linkGroup
QOS, ServiceCategory:
The nrtVbr serviceCategory is assigned against the Hspa vcc configured over an Hspa
dedicated bandwidthPool.
Indeed trafficDescriptor values are configured against the hspa vcc. The pcr and scr are taken
into consideration by the aal2CongestionManagement for estimating the bandwidth of the
bandwidthPool.

The nrtVbr serviceCategory is assigned against the Hspa vcc configured within an Hspa
Remark: whatever nrtVbr or ubr serviceCategory configured against the hspa vcc in the RNC,
the ubr serviceCategory is always assigned to hspa vcc within the Iub backbone and the nodeB.
TrafficManagement:
Hspa vcc trafficDescriptor
Since as many hspa vcc configured as amount of E1 within the IMA linkGroup, the hspa vcc
pcr and scr are going to be set in such a way the aal2CongestionManagement is aware about
the nodeB IMA bandwidth:

Within an Hspa dedicated bandwidthPool associated to a NodeB IMA linkGroup,
The hspa vcc pcr = scr = 4490 c/s.
Within an Hspa dedicated bandwidthPool associated to a single E1,
The hspa vcc pcr = scr = 4528 c/s.
Indeed the RNC aal2CongestionManagement is going to consider the Hspa bandwidthPool =

p*4490 c/s.
ALU confidential

Page 108/198
Remark: The signaling associated to the hspa traffic is transmitted over the single E1, within
the CP and CCP vcc.
Release99 vcc trafficDescriptor

Assuming one up ds vcc and one up nds vcc per single E1, the R99 up vcc pcr and scr are
going to be set in such a way the aal2CongestionManagement is aware about the nodeB E1
bandwidth available for the aal2 traffic.
Beside the R99 aal2 vcc trafficDescriptor must be set in such a way that part of the available
bandwidth remains available for the signaling.
As an exemple, it is assumed that the total user traffic over the IMA and xPcm generates a
volume of signaling equivalent to 5% of the total bandwidth, assuming that the signaling is
well distributed over n E1 xPcm, then set the R99 aal2 vcc, on a way that:
ACR = up ds ECRgcac + up nds ECRgcac = 4528 – 5% (n + p)/n * 4528 c/s
Aal2 linkCac:
The aal2 linkCac is not invoked for hspa calls.
Nevertheless in the case of hspa dedicated bandwidthPool, a bandwidth is reserved for the hspa
vcc through the trafficDescriptors which influences the aal2linkCac ACR.
In such a way the aal2LinkCac R99 traffic regulation is not influenced by the hspa vcc
trafficDescriptor then set appropriately the cacm parameter:

If an Hspa dedicated bandwidthPool is configured for a nodeB, then set the aal2 linkCac
parameters:
- Cacm = aal2Qos,
- Qos2BwReservation = 100%.
Remark: Moreover setting qos0BwReservation = qos1BwTReservation = 0% for cacm =

aal2Qos is equivalent as setting cacm = aal2If.
ALU confidential

Page 109/198
aal2If x
CAC Method = aal2 qos
BwPool i (single E1)
Shared ACR:
QOS 0 Qos0&1&2 ACR
= 4 000 c/s
ECRgcac = 1000 c/s
aal2If ACR = 11 000 c/s

Path 1
Path 2 ECRgcac = 1000 c/s

DS
QOS 1 Qos0 ACR=0 c/s
NDS
Path 3 ECRgcac = 1000 c/s Qos1 ACR=0 c/s
BwPool j (IMA)
HSPA
Qos2 ACR
QOS 2
= 7 000 c/s
Figure 53 aal2linkCac, cacm=Qos, qos0&1bwReervations=0%
RNC Aal2 linkCAC session distribution:

• If the aal2Qosx RB EBR > 0, (aal2Qos0 or 1 traffic)
• if aal2Qosx ACR > EBR, the session is accepted,
• The least loaded aal2Qosx path is chosen (the path with the largest ACR).
=> aal2Qosx ACR = aal2Qosx ACR – EBR
• if aal2Qosx ACR < EBR,
• if the common aal2Qos0&1 ACR > EBR, the session is accepted,
• The least loaded aal2Qosx path is chosen (the path with the largest
ACR).
• Common aal2Qos0&1 ACR = common aal2Qos0&1 ACR – EBR.
• Else, the Hspa session is rejected.
• If the aal2Qosx RB EBR = 0 (case of Hspa session),

• The traffic distribution is on purely round robin between available HSPA
paths (the path with the lowest seized CID).
IMA:
In case of E1 failure within the IMA linkGroup, one hspa vcc is released on the NodeB side.
Since informed, the RNC removes from the bandwidthPool bandwidth the released path
bandwidth.
When the E1 is restored, the hspa vcc comes back into service and the RNC add the path
bandwidth into the bandwidthPool bandwidth.
The order in which the Hspa vcc are released by the NodeB is determined based on the HP
configured against each hspa vcc. Each Hspa vcc must be configured with different HP value
different from 0. See § 5.4.1
Aal2 CongestionManagement:
Only the qosDt2 and qosBp2 parameters apply in the context of a Hspa bandwidthPool.
The qosBp2 is still set to 95% as indicated in §3.7.9.3.
The value of the qosDt2 depends on the shortest atmConnection queue length within the
backbone.
ALU confidential

Page 110/198
atmSwitch
atmSwitch
nodeB
nodeB
RNC
RNC
…
E1 stm1
queueSize = 10240 c
45 c / 10 ms
Assuming a large atmConnection queue length the the qosDt2 may be set to 1000:
qosDt2 0 0 1 350 2 1000
Indeed, the RNC may send large periodic bursts which are store in the backbone
atmConnection queue as long as there is no opportunity to send.
Assuming a small atmConnection queue length the the qosDt2 may be set to 300.
qosDt2 0 0 1 150 2 300
Indeed, the RNC may send limited size bursts. The traffic is retained in the RNC since
no large atm queue storage capacity in the backbone.
The Aal2CongestionManagement thresholds applying to the Hspa bandwidthPool may be

specified on the following way:
Th0 = Σ[(DS vcc ECRGCAC =0) + (NDS vcc ECRGCAC =0) + (Hspa vcc ECRGCAC /100)]
Th0 = Σ[Hspa vcc ECRGCAC /100], Since RNC hspa vcc TD ≠ 0 the Hspa vcc ECR ≠ 0
Th2 = qosDt2/100 * Th0
3.7.9.1.2 N*E1 XPCM, HSPA OVER XPCM

The bandwidth feature covers the different contexts:
- 1/ E1 is dedicated to R99 traffic, and/or
- 2/ E1 supports a mix of R99 and Hsdpa, and/or
- 3/ E1 is dedicated to Hspa,
⇒ The RNC assigns one bandwidthPool per E1.
E1 BwPool i aal2If i
Case 1/ Qos0 Path
Qos1 Path
E1 BwPool j
Qos0 Path
Qos1 Path
atmSwitch
NodeB
RNC
E1 Case 2/ Qos0 Path BwPool k

Qos1 Path
Qos2 Path
E1 Case 3/ BwPool l
Qos2 Path
.
Case 1/: E1 dedicated to R99 & Signaling & Oam:
One R99 dedicated bandwidthPool is associated to the E1.
Within the R99 dedicated bandwidthPool are configured 1 aal2Qos0 path and 1 aal2Qos1 path.
Beside on the NodeB interface, the oam, cp and ccp vcc are configured on the E1 dedicated to R99 or
E1 shared by R99 and hspa traffic.
ALU confidential

Page 111/198
Aal2 linkCac:
If no Hspa dedicated bandwidthPool configured under the aal2If then
cacm = aal2If, ACR = Σ aal2if aal2Path ECRgcac, or
cacm = aal2Qos, ACR = Σ aal2Qos/aal2if aal2Path ECRgcac, or
If some Hspa dedicated bandwidthPools configured under the aal2If then

cacm = aal2Qos, ACR = Σ aal2Qos/aal2if aal2Path ECRgcac.
Qos2BwReservation = 100%
TrafficManagement:
For the R99 dedicated bandwidthPool associated to an E1, the aal2 vcc trafficDescriptors are
set in such a way remains an available bandwidth for the signaling and oam vcc, if cp, ccp and
oam vcc configured on this E1.
Assuming that the NodeB signaling volume is equivalent to 5% of its total bandwidth
UP ds ECRgcac+ UP nds ECRgcac = 4528 * (1 – 5% (x+y)/x) c/s,
With x: #E1 dedicated to R99 and shared by R99 and Hspa,
And y: #E1 dedicated to Hspa
If no signaling and oam vcc configured on the E1, the aal2 vcc trafficDescriptors are set in
such a way:
UP ds ECRgcac+ UP nds ECRgcac = 4528 c/s.
Aal2CongestionManagement:
The aal2CongestionManagement is activated for the R99 bandwidthPool. The regulation
applies then to aal2Qos0 and aal2Qos1 traffic.
Case 2/: An E1 shared by R99 and Hsdpa :

One shared bandwidthPool is associated to the E1.
Within the shared bandwidthPool are configured 1 aal2Qos0 path, 1 aal2Qos1 path and 1 aal2Qos2
path.
Beside on the NodeB interface, the oam, cp and ccp vcc may be configured on the E1 shared by the R99
and hspa traffic.
Qos:
The ubr serviceCategory is assigned to the Hspa vcc.
Beside, rtVbr is assigned to the up ds vcc and nrtVbr assigned to the up nds vcc.
Rule: IubTEG_ aal2bandwidthPool _6

The serviceCategory ubr is assigned against the Hspa vcc configured over a shared
bandwidthPool.
TrafficManagement:
For the shared bandwidthPool associated to an E1, the aal2 vcc trafficDescriptors are set in
such a way remains an available bandwidth for the signaling and oam vcc, if cp, ccp and oam
vcc configured on this E1.
And y: #E1 dedicated to Hspa
Aal2 congestionManagement:
ALU confidential

Page 112/198
The RNC aal2 congestionManagement regulates the aal2 traffic for the shared bandwidthPool,
according to the up ds and up nds vcc TD, and qosDt/qosBp parameters.
Aal2 linkCac:
If no Hspa dedicated bandwidthPool configured under the aal2If then
cacm = aal2If, ACR = Σ aal2if aal2Path ECRgcac, or
cacm = aal2Qos, ACR = Σ aal2Qos/aal2if aal2Path ECRgcac, or
If some Hspa dedicated bandwidthPools configured under the aal2If then

cacm = aal2Qos, ACR = Σ aal2Qos/aal2if aal2Path ECRgcac
Case 3/: An E1 is dedicated to Hsdpa :

One hspa dedicated bandwidthPool is associated to the E1.
Within the hspa dedicated bandwidthPool is configured 1 aal2Qos2 path.
On the NodeB interface, the oam, cp and ccp vcc are not configured on the E1 dedicated to hspa traffic.
Qos:
Rule: IubTEG_aal2bandwidthPool _7
The serviceCategory nrtVbr is assigned against the Hspa vcc configured over a Hspa
dedicated bandwidthPool associated to an E1.
TrafficManagement:
The hspa vcc PCR = SCR = 4528 c/s then ACR = 4528 c/s.
Aal2 linkCac:
In such a way the hspa vcc configured on a hspa dedicated E1with non null trafficDescriptor,
doesn’t influence the aal2 link CAC then cacm = aal2Qos.
Beside the aal2 linkCac qos2Bwr = 100%, in such a way hspa assigned bandwidth doesn’t
influence the aal2 linkCac regulation for aal2Qos0&1.

Case of single E1 dedicated to hspa traffic,
- Aal2 linkCac cacm = aal2Qos.
- Aal2 linkCac qos2Bwr = 100%.
3.7.9.1.3 2 IMA LINKGROUP PER NODEB

The NodeB is configured with two IMA linkGroup, one dedicated to Hspa, the second either dedicated to
R99 traffic or shared by R99 and Hspa traffic.
For such a configuration, the NodeB must be populated with xCCM,.
ALU confidential

Page 113/198
IubIf i
R99 aal2If i
Qos0 Path BwPool i
Qos1 Path
Qos0 Path
Qos1 Path
Qos2 Path Option
atmSwitch
IMA 2 E1
NodeB
RNC
Hspa
Qos2 Path BwPool j

Qos2 Path
Qos2 Path
Qos2 Path
IMA 4 E1
# Hspa vcc:
Within the hspa dedicated bandwidthPool, to be able to rely on the IMA defense, are configured as
many hspa paths as amount of E1 within the IMA linkGroup dedicated to hspa.

Within the hspa dedicated bandwidthPool:
# hspa paths = # E1 within the hspa dedicated IMA linkGroup
Within the R99 bandwidthPool, as an option is configured one hspa vcc.
On hspa session establishment the hspa vcc within the Hspa dedicated bandwidthPool is selected first.
In case of rejection (Path outOfService, CID exhaustion), the hspa vcc over the shared bandwidthPool is
then selected.
Qos:
The nrtVbr SC is assigned to hspa vcc when configured over an Hspa dedicated IMA group whereas ubr
SC is assigned to the optional Hspa vcc under the R99 bandwidthPool.
Rule: IubTEG_aal2bandwidthPool _10

Within the hspa dedicated bandwidthPool:
The nrtVbr serviceCategory is assigned to the hspa vcc.
Within the shared bandwidthPool:
The ubr serviceCategory is assigned to the hspa vcc.
TrafficManagement:
Each Hspa Vcc configured over the Hspa dedicated bandwidthPool are set with:
Hspa Vcc PCR = SCR = 4490 c/s
No bandwidth is reserved for the optional hspa vcc within the shared bandwidthPool.
Assuming that the NodeB signaling volume is equivalent to 5% of its total bandwidth, then per E1
within the shared or dedicated R99 IMA link group, are configured: 1 up ds and 1 up nds vcc with
trafficDescriptors satisfying the relation:
With x: #E1 within the shared or R99 dedicated IMA linkGroup,
And y: #E1 within the Hspa dedicated IMA linkGroup.
Aal2 linkCac:
ALU confidential

Page 114/198
The aal2 link CAC is set with cacm = aal2Qos and qos2Bwr = 100%, then the aal2Qos2 reserved
bandwidth doesn’t influence the aal2 linkCac when regulating aal2Qos0&1 traffic:

Case of 2 IMA group per NodeB,
- Aal2 linkCac cacm = aal2Qos.
3.7.9.1.4 1 IMA LINKGROUP AND 2 BANDWIDTHPOOL:

The nodeB is configured with one single IMA linkGroup.
On the RNC are configured two bandwidthPools:
- One shared bandwidthPool and
- One hspa dedicated bandwidthPool.
Example:
NodeB is populated with 7 E1, the R99 traffic transmits up to 2 E1 bandwidth whereas the
Hspa transmits up to 5 E1 bandwidth.
- Within the RNC R99 bandwidthPool are configured as many couple (aal2Qos0 vcc,
aal2Qos1 vcc) as amount of nodeB E1 dedicated to R99 traffic. As an option, one or more
an hspa vcc are configured in this bandwidthPool.
- Within the RNC Hspa bandwidthPool are configured as many aal2Qos2 vcc as amount of
E1 dedicated to hspa traffic (to satisfy the NodeB Ima Defense).
IubIf i
aal2If i
BwPool i
IMA 7 E1
aal2Qos0 vcc
aal2Qos1 vcc
aal2Qos0 vcc
aal2Qos0 vcc
aal2Qos1 vcc
Atm
aal2Qos0 vcc aal2Qos1 vcc

AtmbackBone

aal2Qos2 vcc
NodeB
backBone
RNC
aal2Qos2 vcc BwPool j

aal2Qos2 vcc
NodeB vcc, qos and trafficManagement:
ALU confidential

Page 115/198
NodeB Vcc aal2Qos atmQos PCR SCR/MCR

UP DS aal2Qos0 ubr1 8980 0
UP NDS aal2Qos1 ubr 8980 0
Hspa aal2Qos2 ubr3+ 8980 236 Shared bwPool
CP NA ubr1 8980 0
CCP NA ubr1 8980 0
Oam NA ubr3+ 8980 236
NodeB Vcc aal2Qos atmQos PCR SCR/MCR

Hspa aal2Qos2 ubr3+ 22450 236 Hspa dedicated bwPool
RNC vcc, qos and trafficManagement:
Vcc aal aal2Qos atmQos Tdt EP PCR SCR MBS CDVT Shared bwPool
UP DS aal2 aal2Qos0 rtVbr 6 3 4490 870 10 notUsed
UP NDS aal2 aal2Qos1 nrtVbr 6 4 4490 1500 14 notUsed
CP aal5 NA rtVbr 1 3 0 0 0 notUsed
CCP aal5 NA rtVbr 1 3 0 0 0 notUsed
(Hspa) aal2 aal2Qos2 ubr 1 7 0 0 0 notUsed
Oam aal5 NA ubr 1 7 0 0 0 notUsed
Hspa dedicated bwPool
Hspa aal2 aal2Qos2 nrtVbr 1 4 4490 4490 x notUsed
NodeB holdingPriorities:
- HP values assigned to the vcc belonging to the shared BwPool:
NodeB VCC
HP
Type Instance
CP 1
CCP 1 to 6 0
OAM 1
DS UP 1 1
NDS UP 1 1
DS UP 2 2
NDS UP 2 2
(Hspa) 1 0
- HP values assigned to the vcc belonging to the shared BwPool:

NodeB VCC
HP
Type Instance
Hspa 1 1
Hspa 2 2
Hspa 3 3
Hspa 4 4
Hspa 5 5
3.7.9.1.5 SYNTHESIS:
#Hspa vcc:
Within an hspa dedicated bandwidthPool:
- 1 hspa vcc is configured is the bandwidthPool associated to one E1 (xPcm)
- As many hspa vcc are configured as amount of E1 within the IMA group associated
to the bandwidthPool.
Within a shared bandwidthPool, as an option one or several hspa vcc may be configured.
ALU confidential

Page 116/198
Cp, ccp and Oam vcc:

The CP and CCP vcc are not configured on the Hspa dedicated bandwidthPool, but either on a
R99 bandwidthPool or a shared bandwidthPool
Qos:
The serviceCategory rtVbr is assigned against the Hspa vcc configured within an Hspa
Whereas the serviceCategory ubr is assigned against the Hspa vcc configured within a shared
bandwidthPool.
TrafficManagement:
RNC/ Hspa vcc TD:
Within a hspa dedicated bandwidthPool,
- case of xPcm: Hspa nrtVbr vcc PCR = SCR = 4528 c/s,
- case of IMA: Hspa nrtVbr vcc PCR = SCR = 4490 c/s,
Within a hspa shared bandwidthPool,
- Hspa ubr vcc PCR = SCR = 0 c/s.
RNC/ R99 vcc TD:
Per E1 dedicated to R99 or shared by R99 and Hspa, 1 up ds and 1 up nds vcc are
configured with trafficDescriptors satisfying the relation:
And y: #E1 dedicated to Hspa (either IMA or xPcm).
It may be necessary to overbook the RNC Iub Stm1 interface:

atmIf CA bandwidthPool 1 200 2 0 3 0 4 0 5 0
Aal2 linkCac:
Since several bandwidthPools configured under an aal2If and some bandwidthPools dedicated
to Hspa:
Aal2If/Cacm = aal2Qos,
Aal2If/qos2BwReservation = 100%.
Remark: The cacm is a subComponent of aal2If component, then the cacm value apply to all
the bandwidthPools under the aal2If.
Aal2 congestionManagement:
Since some bandwidthPools are configured, the aal2 congestionManagement regulation applies
at bandwidthPool level. The mechanism can be set per bandwidthPool.
The sum of the bandwidth reserved for the bandwidthPool under one aal2If instance, must be
lower than the bandwidth reserved for the aal2If. In other word one bandwidthPool can not
overlap bandwidth reserved for another bandwidth pool within the same aal2If:
Σ aal2if BwPool Th0 ≤ aal2If Th0
ALU confidential

Page 117/198
3.7.9.1.6 RESILIENCY:
- On path failure within the hspa dedicated bandwidthPool, the already established RB are released.
- If all the paths within the hspa dedicated bandwidthPool are outOfService or no more CID available,
the new Hspa establishementRequest are served by another bandwidthPool which includes some
aal2Qos2 Path(s).
Remark: the hspa dedicated bandwidth pools are always selected first for an hspa session
establishment..
- If no aal2Qos2 path is available, the new HSPA session fall-back to R99 DCH.
- Case of failure of the E1/or IMA supporting the CP vcc,

⇒ all established calls are lost,
⇒ the NodeB is taken out of service after certain timeout (-SSCOP timeout – around 15 sec),
- Case of failure of the E1/or IMA supporting the OAM vcc,
⇒ The NodeB is no more supervised,
⇒ The NodeB will be eventually taken out of service.
3.7.9.2 CONTROLLED DISCARD:

When congestion state is detected for a specific aal2 qos, the regulation consists in discarding the per
aal2 qos traffic.
Since the Calls are accepted by the Aal2 Link CAC, the qos0, 1 and 2 aal2 traffics are running, the
PMC-PC looks after the per aal2 Qos trafficVolume transmitted on the Iub interface over period of 10
ms.
1/ Thresholds:
Three Discard thresholds are implemented in the PMC-PC called Th0, Th1 and Th2.
The three discardThresholds are set by the RNC based on:

- the configured Iub aal2 vcc trafficDescriptors and
- the parameters:
RncIn level: IubTransportFlowControl (Fc) / qosDiscardThreshold (qosDt) 0 0 1 x 2 y 3 z.
aal2If level: CongestionManagement / qosDiscardThreshold (qosDt) 0 0 1 x 2 y 3 z, or
bwPool level: CongestionManagement/ qosDiscardThreshold (qosDt) 0 0 1 x 2 y 3 z.
with:
- qosDt0 = 0, this value is not used. The Th0 value is not influenced by qosDt0.
- qosDt1 = x, this value influences the value of the Th1,
- qosDt2 = y, this value influences the value of the Th2,
- qosDt3 = z, this value influences the value of the Th3, not used
The qosDiscardThresholdi range is: [0-1000%].
The three different discardThresholds are set by the RNC based on the following formulas:
- Th0 = the ACR (in cell/s) / 100,
Th0 = [Σ (ECRDS + ECRNDS + (ECRHsdpa = 0))] /100
With ECR calculated according to GCAC.
Meaning: the Iub aal2 traffic volume over 10 ms, this is an estimation of the Iub aal2
interface bandwidth.
- Th1 = Th0 + (qosDt1/100 – 1) * ( Σ ECRNDS / 100 ), initial value at the RNC start up,
Updated each second according to the second formula:
Th1 = Th0 + (qosDt1/100 - 1) * (Th0 - aal2Qos0_traffic)
With:
- qosDt1: qosDiscardThreshold parameter for aal2Qos1 traffic
- aal2Qos0_traffic: aal2Qos0 MEASURED trafficVolume during the previous second,
Meaning:
ALU confidential

Page 118/198
The Iub qos0 & qos1 aal2 traffic volume over 10 ms, it encompasses traffic transmitted to
nodeB and traffic stored in atm queues.
Since the sum of aal2Qos0 and aal2Qos1 traffic reaches the threshold Th1, the aal2 qos1
traffic received from the PMC-RAB(s) is discarded in the PMC-PC.
The Th1 represents:
- the maximum burst of aal2Qos1 data that may be sent over the whole Iub interface or
the bandwidthPool during 10 ms.
- The maximum queuing delay for aal2Qos 1 traffic.
- Th2 = qosDt2/100 * Th0, the threshold for aal2qos2 cell discarding.

Meaning:
The Iub qos0, qos1 & qos2 aal2 traffic volume over 10 ms, it encompasses traffic
transmitted to nodeB and traffic stored in atm queues.
Since the sum of aal2Qos0, aal2Qos1 and aal2Qos2 traffic reaches the threshold Th2, the
aal2 qos2 traffic received from the PMC-RAB(s) is discarded in the PMC-PC.
The Th2 represents:
- the maximum burst of aal2Qos2 data that may be sent on Iub interface over 10 ms.
- The maximum queuing delay for aal2 qos 2 traffic.
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:
1/ the trafficShaping at VP level is activated in the RNC 16pOC3/Stm1 FP Iub interfaces, or
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
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 aal2 Congestion Management Discard
Threshold set of values case of ‘basicVPT trafficShaping on the Iub interface’.
- Context ‘No basicVPT trafficShaping on the Iub interface’ encompasses one Iub configuration:
1/ the trafficShaping is not activated neither in the RNC nor in the POC,
VC switch (not VP switch) and the trafficShaping at VP level is activated in the remote POC
For these two Iub configurations, apply on the RNC the aal2 Congestion Management Discard
Threshold set of values case of ‘No basicVPT trafficShaping on the Iub interface’.
Rule: IubTEG_ aal2CongestionManagement_3
Case of No basicVPT trafficShaping on the Iub interface:

qosDt 0 0 1 350 2 500 3 0
Case of basicVPT trafficShaping on the Iub interface:
qosDt 0 0 1 300 2 500 3 0
Remarks:
- aal2Qos3 is currently not used on Iub interface.
- The parameters qosDiscardThreshold_i will be set according to the NDS and Hsdpa
NodeB Receive window size (Eg: NDS NodeB Receive window size = 70 ms) and the
estimation of the distribution of aal2 qos0, qos1 and qos2 traffic over the Iub
interface.
2/ Counters:
ALU confidential

Page 119/198
The PMC-PC maintains for each aal2Qos, the current count in aal2 PDU of the downLink
traffic received from the PMC-RAB per NodeB or per nodeB bandwidthPool, via three
counters:
- qos0 :
Counter for RNC local aal2 qos 0 PDU,
- qos0+1:
Cumulative counter for RNC local aal2 qos 0 and aal2 qos1 PDU.
- qos0+1+2:
Cumulative counter for RNC local aal2 qos 0, aal2 qos1 and aal2 qos2 PDU
and DRNC Iur aal2 qos2 PDU .
Remark:
- Since the Hsdpa traffic is supported on the Iur Interface, on the DRNC the Hsdpa
traffic received from the Iur interface is counted together with the RNC local Hsdpa
traffic in the qos0+1+2 counter.
- The DRNC Iur aal2 qos1 PDU are not counted in qos0+1 nor qos0+1+2 counters.
Every 10 ms, the PMC-PC decrements the three counters: qos0, qos0+1, qos0+1+2 by Th0, up
to 0; the Th0 is considered to be either the whole NodeB bandwidth or one NodeB
bandwidthPool bandwidth. This corresponds to transmitted Iub traffic volume within 10 ms per
nodeB or per nodeB bandwidthPool.
The exceeding traffic is assumed to be stored in atm queues:
- qos0 - TH0,
- qos0+1 - TH0,
- qos0+1+2 - TH0.
The qos counters minimal value is 0.
To avoid congestion in the launch phase, the aal2qos counters are initially set with
initialization values:
- qos0 = TH0,
- qos0+1 = TH1,
- qos0+1+2 = TH2.
When PMC-PC fails, all counters are reset with the initialization values.
Moreover in such a way to guarantee enough bandwidth for aal2 qos0 (DS) traffic, the PMC-
PC counts the trafficVolume of DS during the last 20 ms; the aal2 qos1 (NDS) traffic cannot
exceed min (Th1-Q0pr, Th1-Q0).
3/ Start Discarding:
On reception of traffic from the PMC-RAB(s), the PMC-PC starts discarding per aal2qos
traffic, when the qos counters exceed the thresholds:
- PMC-PC discards aal2qos2 traffic if qos0+1+2 > TH2,
- PMC-PC discards aal2qos1 traffic if qos0+1 > TH1,
- Aal2Qos0 traffic is never discarded.
Since the atm cells for a given qos are discarded, the discard carries on till the end of the 10 ms
current period.
4/ Stop Discarding:
The PMC-PC stops discarding per aal2qos traffic, when the qos counters fall down to
thresholds:
- The PMC-PC stops discarding aal2qos1 traffic received from PMC-RAB, when after
the 10 ms decrement time, [qos0 – Th0 < 0],
- The PMC-PC stops discarding aal2qos2 traffic received from PMC-RAB, when after
the 10 ms decrement time, [qos0+1 – Th0 < 0],
ALU confidential

Page 120/198
This reflects the fact that some qos1 or/and qos2 traffic has been transmitted to NodeB during
previous 10 ms.
3.7.9.3 RNC BACKPRESSURE MECHANISM:

Before congestion occurs, since the PMC-PC expects a congestion state, it notifies the PMC-RAB(s) in
charge of handling the Iub traffic. The PMC-RAB delays (and not discard) the traffic at RLC level.
- The backpressure mechanism applies to:

- The aal2qos1 (NDS) and aal2qos 2 (hsdpa) downLink traffics,
- The Iub interface,
- To the whole NodeB bandwidth or to the nodeB bandwidthPools,
- The RAB specified with a TTI value lower than the Xoff Transmission Interruption duration.
No impact on RAB having a TTI larger than the Xoff Transmission Interruption duration.
- The backpressure mechanism doesn’t apply to:
- The Aal2qos 0 (DS) traffic,
- The Iur interface.
1/ Xoff signal:
The Xoff is ALU RNC proprietary internal signal. The Xoff signal is initiated by the PMC-PC, and
destinated to the PMC-RAB. Within the Xoff signal is specified the aal2 qos and the duration for the
transmission interruption. On reception of the Xoff signal, the RLC within the PMC-RAB stops the
transmission of RLC PDU during the required period.
2/ Thresholds for backpressure mechanism:

The backPressure thresholds called Xoff1 and Xoff2 are calculated by the RNC based on:
- the qosDiscard Thresholds and
- the parameter qosBackPressurei (qosBPi):
RncIn level: IubTransportFlowControl/qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z
aal2If level: CongestionManagemen /qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z, or
bwPool level: CongestionManagement/ qosBackPressureThreshold (qosBPt) 0 0 1 x 2 y 3 z.
with:
- qosBP0=0, this value is not used.
- qosBP1 = x, this value influences the value of the Xoff1 threshold,
- qosBP2 = y, this value influences the value of the Xoff2 threshold,
- qosBP3 = z, not used.
With Xoffi range: [0%, 100%]
The Xoff i thresholds are expressed as a percentage of the ControlledDiscard thresholds: Th i based on
the formulas:
- Xoff1 = qosBP1 * Th1,
- Xoff2 = qosBP2 * Th2
Two sets of qosBackPressure values are suggested which satisfy two different Iub contexts:
- The context ‘basicVPT trafficShaping on the Iub interface’:
It encompasses 3 Iub configurations:
1/ the trafficShaping at VP level is activated in the RNC 16pOC3/Stm1 FP Iub interfaces, or
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
VP switch (not VC switch) and the trafficShaping at VP level is activated in the remote POC
For these 3 Iub configurations, apply on the RNC the aal2 Congestion Management
qosBackPressure Threshold set of values case of ‘basicVPT trafficShaping on the Iub
interface’.
- Context ‘No basicVPT trafficShaping on the Iub interface’:

ALU confidential

Page 121/198
1/ the trafficShaping is not activated neither in the RNC nor in the POC,
VC switch (not VP switch) and the trafficShaping at VP level is activated in the remote POC
For these two Iub configurations, apply on the RNC the aal2 Congestion Management
qosBackPressure Threshold set of values case of ‘No basicVPT trafficShaping on the Iub
interface’.
Rule: IubTEG_aal2CongestionManagement_4
qosBPt 0 0 1 95 2 95 3 0
qosBPt 0 0 1 33 2 20 3 0
Within the Xoffi signal, the PMC-PC inserts the duration of the transmission interruption, called the
Txoff. One Txoff value applies per aal2Qos.
The Txoffi value is calculated by the RNC according to the formula:
Txoff=ceil((Xoffi / 2)/Th0)*10ms
Taking into account the recommended qosDt and qosBP values from this TEG, the following Txoff
values are taken into consideration by the RNC:
Rule: IubTEG_ aal2CongestionManagement_5

- TXoff1 : Xoff1 Transmission Interruption duration = 20 ms,
- TXoff2 : Xoff2 Transmission Interruption duration = 30 ms,

- TXoff1 Transmission Interruption duration = 10 ms,
- TXoff2 Transmission Interruption duration = 10 ms,
Since Xoff1 threshold is reached, a Xoff signal is sent by the PMC-PC to all PMC-RAB(s) involved in
the traffic from the congested Iub interface, in such a way the PMC-RAB (at RLC level) delays the
transmission of aal2 qos1 traffic for a specified duration.
Since Xoff2 threshold is reached, a Xoff signal is sent by the PMC-PC to all PMC-RAB(s) involved in
the traffic from the congested Iub interface, in such a way the PMC-RAB delays (a RLC level) the
transmission of aal2 qos2 traffic for a specified duration.
On reception of Xoff signal, the PMC-RAB stops transmitting traffic (RLC PDU) for the specified Iub
interface and aal2 qos, during a period of time stated in the Xoff signal.
3.7.9.4 ABNORMAL CASES

[R252]
In case of IMA bandwidth reduction, the Th0, Th1, Th2, Xoff1 and Xoff2 thresholds are updated to
reflect the actual available bandwidth. They apply at the beginning of the next 10 ms period.
When IMA bandwidth restoration occurs, the thresholds recover their initial values. They apply at the
beginning of the next 10 ms period.
3.7.10 QOS
The RNC is configured with one Qos information mapping table, which applies to all the Iub and Iur
interface:
ALU confidential

Page 122/198
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,
3.7.11 HSPA CAC

E-dch leg regulation:
No Hsupa CAC activated in the RNC.
Hs-dsch leg regulation:

The Hsdpa CAC implemented in the RNC, regulates amount of Hsdpa legs per NodeB H-BBU.
It is configured through the parameter:

HsdpaCellClass/maximumNumberOfUsers
Range: [0..50], Class 0, Granularity RNC, recommended Value: 48
(The NodeB H-BBU supports up to 48 H-BBU legs, 3.8.10)
A nodeB being configured with up to 6 radio cells, the RNC hsdpa CAC allows up to 6*48= 288 hs-dsch
legs for full capacity NodeB, in other words up to 288 aal2 CID.
Rule: IubTEG_Hsdpa_6
HsdpaCellClass/maximumNumberOfUsers is set with 48.
In case the Hsdpa CAC rejects the call, the Hsdpa leg falls back to a DCH.
3.8 NODE B
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 doesn’t support hsupa traffic.
BBU Component:
ALU confidential

Page 123/198
The different kinds of CEM are populated with different amounts BBU components (BaseBandUnit) in
charge of handling the UMTS traffic:
- The iCEM64 is composed of one BBU,
- The iCEM128 is composed of two BBU.
BBU Role:
Each BBU component within a CEM is loaded with a BBU role; the different BBU roles:
- D-BBU: The BBU dedicated to the release99 traffic (dedicatedServices).
- H-BBU: The BBU dedicated to the hsdpa traffic,
- E-BBU: The BBU dedicated to the hsupa traffic.

The NodeB supports up to four E-BBU roles.
One BBU component loaded with E-BBU role is able to handle simultaneously up to 15 hsupa legs.

One E-BBU handles up to 15 Hsupa simultaneous sessions.
Since UA5-0, an algorithm is in charge of assigning the different BBU roles to the CEM BBU
components. Therefore the kind of traffic handle by a CEM can not be predicted in configuration phase.
CCP Vcc:
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 don’t require terminating one aal5 CCP Vcc.
Since the BBU role assignment to BBU component is devolved to an algorithm, no way to determine
which CEM requiring a ccp vcc and which CEM nor requiring ccp vcc.
As a consequence, it is recommended to configure as many ccp vcc as amount of CEM within the nodeB,
whatever the traffic handle by the CEM.
The ccp vcc configured on the CEM dedicated to hspa is set disable by the nodeB without alarm
generation.

One CCP Vcc is configured per CEM Card,
The CCP Vcc configured on the Iub interface is switched in the CCM to the CEM.
CEM Characteristics:
− The iCEM64 is composed of one BBU component.
The iCEM64 handles one kind of traffic amongst three: Release99, hsdpa and hsupa traffics,
according to the BBU role loaded.
The iCEM64 capacity is up to 15 simultaneous hsupa legs.
− The iCEM128 is composed of 2 BBU components.

The iCEM128 handles either:
- Simultaneously two kinds of traffic amongst three: Release99, hsdpa and hsupa traffics
according to the two different BBU roles loaded, or
- One kind of UMTS traffic, if both BBU are loaded with the same BBU role: Release99 or hsdpa.
One iCEM128 can not be populated with two E-BBU s.
The iCEM128 capacity is up to 15 simultaneous hsupa legs.
− The xCEM supports up to 1 E-BBU, and up to 64 hsupa legs..
ALU confidential

Page 124/198

The iCEM128 may be loaded with only one E-BBU role.
Slot 1 Slot 2
D-BBU
iCEM64 H-BBU NA
E-BBU
Slot 1 Slot 2
D-BBU D-BBU
D-BBU H-BBU
H-BBU D-BBU
H-BBU H-BBU
iCEM128 D-BBU E-BBU
E-BBU D-BBU
E-BBU E-BBU
E-BBU H-BBU
H-BBU E-BBU
Figure 3-54 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.
- The xCCM supports two IMA linkGroups.
3.8.2 TRANSMISSION LAYER:

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

Page 125/198
- An automatic configuration: the nodeB is configured in such a way that the CRC4 activation is
conditioned by the presence of the CRC4 in the received multiframe. For that the NodeB
E1pcmFrame parameter is set with the value: “multiframeAuto”, the ReceiveCRC parameter is
ignored.
3.8.3 SYNCHRONISATION
The nodeB is synchronized either from:
- A reference clock given by a stratum 1 clock source, or
- A connected Iub E1.
In the context of synchronization on Iub E1, and CP vcc configured over a single E1 (xPCM) then the E1
where is configured the CP vcc is considered per default as the E1 clock reference.
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.4 ATM CONNECTIONS:

AtmConnection identifier range:
Rule: IubTEG_ NodeB-atm_01

Vpi range: [ 0 to 7]:
- Up to 8 Vpi values can be configured simultaneously.
- The same vpi value may be configured simultaneously on the IMA group and on
multiPcm E1.
Vci range: [ 0 to 255].
AtmConnection type and amount:

Up to 32 vcc may be configured (including aal5, aal2 and aal1), including up to 16 aal2 Vcc).
UserPlane Vcc:
Up to 16 UP vcc may be configured per nodeB.
CCP Vcc:
As many CCP vcc are configured as amount of CEM card in the NodeB.
Up to 6 CCP vcc may be configured per nodeB.
Remark: see exception in §3.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):
ALU confidential

Page 126/198
Segment F4 OAM vcc is automatically configured in the NodeB with

ServiceCategory UBR.
3.8.5 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.
- 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 PCM 2 PCM 3 PCM 4 PCM5 PCM6

1 oam vcc 1 cp vcc
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 1 hspa vcc
3.8.6 IMA
The IMA linkGroup configured on the nodeB is either shared by the Release99 and Hspa traffic or
dedicated the Hspa traffic.
3.8.6.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 is compliant with atmForum V1.1.
ALU confidential

Page 127/198
3.8.6.2 IMA LG BANDWIDTH REDUCTION/RESTORATION MECHANISM:

In the context of link failure within the IMA linkGroup, the nodeB decides to release some vcc.
Followed by the context of link restoration, the nodeB decides to restore some vcc.
When IMA LinkGroup bandwidth Reduction occurs, the nodeB deactivates two vcc configured with non
zero HP. The order in which the vcc are released depends on the HoldingPriority parameter value
assigned against the vcc:
- In the context of nodeB IMA linkGroup composed of n E1, configured with n up ds vcc, n up
nds vcc and 1 hspa vc, the nodeB IMA defense releases 1 up ds vcc and 1 up nds vcc each time
an E1 fails. The hspa configured with HP=0 is never released.
- In the context of nodeB IMA linkGroup composed of n E1, configured with n hspa vc, the
nodeB IMA defense releases 1 hspa vcc each time an E1 fails, the hspa vcc set with the highest
hp value.
Moreover the nodeB notifies the RNC about vcc deactivation, thanks to atm oam signals. The RNC is
indeed aware about the actual Iub IMA linkGroup bandwidth.
When IMA LinkGroup bandwidth Restoration occurs, the nodeB brings some vcc back into service.
To avoid that one E1 failure within the IMA linkGroup doesn’t imply complete R99 or Hspa traffic
interruption, it is suggested to duplicate the different kinds of aal2 vcc, and to assign against them
convenient HoldingPriority values.
HoldingPriority (HP):
A HoldingPriority value is configured against each NodeB vcc (UP, Hspa, CP, CCP and Oam). The
HP value determines:
- In which order the vcc are released when bandwidth reduction occurs,
- In which order the vcc are restored when bandwidth restoration occurs.
The HP is in the range [0-16]:
- The vcc configured with HP=0 are never released,
- In the IMA bandwidthReduction context:
- The vcc configured with HP=16 are the first candidate to release,
- The vcc configured with HP=1 are the last candidate to release,
- In the IMA bandwidthRestoration context:
- The vcc configured with HP=16 are the last restored,
- The vcc configured with HP=1 are the first restored.
The HP is a Class3 parameter.
Aal2 vcc amount:

To take benefit of the nodeB IMA defense mechanism, it is necessary to duplicate the aal2 vcc, in
such a way when part of the IMA linkGroup E1 fails, then the aal2 traffic can still be handling on a
lower bandwidth:
Rule: IubTEG_NodeB-IMA_02
- On an IMA linkGroup dedicated to Release99 traffic or shared by the Release99 and
Hspa traffic, it is recommended to configure as many couple(s) of (UP DS Vcc, UP
NDS Vcc) as amount of pcm within the IMA LG.
- On an IMA linkGroup dedicated to Hspa traffic, it is recommended to configure n Hspa

vcc when the IMA linkGroup is composed of n E1.
Exception: case of IMA linkGroup composed of 8 pcm, since the nodeB supports up to 16 aal2 vcc,
then x hspa vcc and (16-x) R99 vcc are configured. Eg: if 1 hspa vcc configured then 8 up ds vcc, 7
up nds vcc are configured.
ALU confidential

Page 128/198
NodeB IMA Defense Activation/desactivation:

The nodeB IMA LinkGroup bandwidth Reduction 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 bandwidth reduction event and the invocation of the Defense mechanism. If x=0,
the nodeB starts the defense mechanism since aware about the bandwidthReduction.
Triggers:
The nodeB IMA LinkGroup bandwidth Reduction mechanism is triggered by the following events:
- PCM LOS condition observed locally or in the far end node,
- PCM manually locked,
- Aal2 Vcc creation,
- Reception of ICP cell with physicalDefect information (case of PCM LOS observed by the
farEnd node).
The nodeB IMA LinkGroup bandwidth Restoration mechanism is triggered by the following
events:
- PCM recovery,
- PCM manually unlocked
- Aal2 Vcc deletion.
NodeB IMA LinkGroup bandwidth Reduction/Restoration mechanism algorithm:

TBupdated with: cases
- IMA group configured only with Hspa Vcc.
- nE1 and IMA:
o case of E1 failure within IMA, impact on the vcc with highest Hpri configured on the
nE1.
- New hpri value assigned to the different hspa vcc configured on the IMA dedicated to HSPA
see §5.4.1.
-
In case of one E1 failure, the nodeB releases all the vcc assigned with the highest HoldingPriority
value.
In case of one E1 restoration, the nodeB restores all the vcc assigned with the lowest
HoldingPriority value.
The HoldingPriority values suggested in §5.4.1 , are set in such a way the following relation is
always satisfied in the nodeB:
# [ Σ (DS + NDS aal2 Vcc) configured with HP ≠ 0 ] = 2* # active PCM
And same amount of active DS and NDS vcc.
- If # (Σ (DS + NDS aal2 Vcc) configured with HP ≠ 0) > 2* # active PCM,

=> The nodeB releases some vcc with the highest HP value in such a way to satisfy its
objective. The HP values are set in such a way (see § 5.4.1 ), the couple of (up ds vcc, up
nds vcc) with the highest HP value is released,
=> Then the nodeB returns the endToEnd F5 RDI to the RNC with a periodicity of 1
second.
- If # (Σ (DS + NDS aal2 Vcc) configured with HP ≠ 0) < 2* # active PCM,

=> The nodeB restores some vcc with the lowest HP value in such a way to satisfy its
objective. The HP values are set in such a way (see §5.4.1), the couple of (up ds vcc, up
nds vcc) with the lowest HP value is restored,
=> The nodeB stops returning the endToEnd F5 RDI to the RNC.
ALU confidential

Page 129/198
3.8.7 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].
It’s not mandatory that the E1 within the IMA linkGroup are contiguous.
The fractional E1 feature is not compatible with the nodeB mix configuration.
The atm oam loopBack mechanism may be activated on the isolated E1 and is not available for E1
inserted in the IMA linkGroup.
Synchronisation:
- 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, two up to four hspa vcc may be
required.
- 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.5.
The following figure shows the distribution of the vcc over the different E1, for the context: 4 E1
in xPcm mode and one IMA LG composed of 4 E1:
ALU confidential

Page 130/198
PCM2:
UP DS vcc =1/41 Aal2 Connections:
UP NDS vcc =1/49 UP DS vcc:
CP vcc =1/34 VCC=0 / 34+24*(k-1) to 0 / 37+24*(k-1)
CCP vcc =1/35-40 UP NDS vcc:
PCM1: VCC=0 / 42+24*(k-1) to 0 / 45+24*(k-1)
UP DS vcc =1/41 Hspa vcc:
UP NDS vcc =1/49 PCM3, 4, … : VCC=0 / 40+24*(k-1) + 0 / 41+24*(k-1)
CCP vcc UP DS vcc =1/41
=1/35 VCC=0 / 48+24*(k-1) + 0 / 49+24*(k-1)
UP NDS vcc =1/49
OAM vcc =0.32
CCP vcc =1/35-40 Aal5 Connections:
CP vcc:
VCC=0 / 50+24*(k-1)
CCPn vcc: RNC
RNC
VCC=0 / 51+24*(k-1) to 0 / 56+24*(k-1)
Pcm 1 OAM vcc:
Pcm 2
NodeB
16pOC3/Stm1
NodeB (k
16pOC3/Stm1FP
Pcm 3
16pOC3/Stm1
16pOC3/Stm1FP
Pcm 4
POC
ATM
ATM
POC
STM1 BackBone
BackBone STM1
(k == x)
Pcm 5
x)
FP
Pcm 6
FP
Pcm 7
Pcm 8
Hspa vcc = 1/48+47+56+55
Figure 3-55 Exemple of 4 E1 within the IMA LG and 4 independent E1
3.8.8 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 a UBRPlus NodeB proprietary serviceCategory parameter values (without a numerical suffix)
are considered priority 2.
- Case of trafficShaping NOT activated:

In such a way the trafficShaping is not activated, each nodeB Vcc are configured with the UBR or
the UBRPlus serviceCategory.
The UBRPlus is a serviceCategory which allows configuration of a MCR (MinimumCellRate) value
to the vcc.
The UBRPlus is also called also GBR (guaranteed bit Rate)
Since each nodeB vcc is configured with the same AtmForum serviceCategory, the QOS is no more
provided by the serviceCategory but by the numerical suffix attached to the serviceCategory.
ALU confidential

Page 131/198
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:
VCC recommended SC ProprietarySC parameter

in the network configured in the NodeB
UP DS rtVbr UBR1
UP NDS nrtVBR UBR
CP rtVbr UBR1
CCP rtVbr UBR1
HSPA UBR UBRPlus3 (MCR)
OAM UBR UBRPlus3 (MCR)
Remarks:
- The NodeB proprietary SC UBR means priority:2; the NodeB proprietary SC UBRPlus
means priority:2
- Since the UP DS Vcc proprietary SC is changed from 0 to 1; the UP DS, CP and CCP Vcc
are set with the same proprietary SC value, then there is no more need to assign a MCR to
CP and CCP Vcc. As a conclusion the CP and CCP Vcc serviceCategory is changed from
UBR+ to UBR.
- With exception of the Hsdpa flowControl traffic, the Hsdpa vcc carries only downLink
traffic then the nodeB associated proprietary SC is the least urgent.
- The Hsdpa vcc carries both user traffic and Hsdpa flowControl traffic. In such a way to
guarantee a minimum bandwidth for flowControl, a MCR value is assigned to Hsdpa Vcc.
- Case of IMA linkGroup dedicated to Hspa traffic, the Hspa vcc are still configured with
UBRPlus3,
NodeB QOS handling:

- The UBRx vcc and the UBRPlusx vcc get the same priority,
- Assuming two vcc configured with the same proprietary SC, if there are cells in both vcc
queues, the nodeB scheduler considers each queue with the same weight, indeed one cell is
extracted from first queue, then one cell from the second queue, then one cell is extracted
from first queue, …
- Case of trafficShaping activated:

Below serviceCategory and proprietary SC recommended values when trafficShaping is activated:
Rule: IubTEG_NodeB-QOS_1
If TrafficShaping activated:
VCC SC configured in NodeB Proprietary SC
UP DS rtVBR rtVbr
UP NDS nrtVBR nrtVbr
CP rtVBR rtVbr
CCP rtVBR rtVbr
HSPA UBR UBR3
ALU confidential

Page 132/198
OAM UBR+ UBRPlus

In nodeB only one trafficDescriptor is set per vcc. It applies either to uplink and to downlink direction.
3.8.9.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
UBR, SCR=0, MCR=mcr with mcr <> 0
UBR, SCR=scr with scr <> 0 UBR+, MCR=scr
UBR, SCR=scr, MCR=mcr with scr and mcr<> 0
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-10 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.
ALU confidential

Page 133/198
Case of E1 Drop&Insert 15/15, the minimal cell rate is 227/2 = 114 cells/s.
Case of T1 Drop&Insert 12/12, the minimal cell rate is 182/2 = 91 cells/s.
Case of IMA:
The minimum Vcc throughput is IMA linkGroup bandwidth / 160.
Eg: an IMA LG composed of 8 E1, the IMA LG bandwidth = 8 * 1,904 Mb/s = 15, 232 Mb/s
then the Vcc minimum throughput = 15, 232 Mb/s / 160 = 96 kb/s.
xPcm case:
Minimum Vcc throughput = PCM bandwidth / 20
IMA Case:
Minimum Vcc throughput = IMA LG bandwidth / 160
3.8.9.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_NodeB-
QOS_2 column ‘SC recommended for the interface’.
Moreover when removing trafficShaping in nodeB:
- For UBR VCC, set SCR=MBS=0 on nodeB,
- For UBR+ VCC, set SCR and MCR according to rule Iub_NodeB-TM_1.
- Set PCR = LinkRate when IMA is not configured,
- Set PCR = [IMA LinkGroup Bandwidth – IMA overhead], when IMA is configured. (see §IMA).
Remarks:
PCR is still used for regulating Egress traffic, then set PCR to the interface bandwidth.
A mix of shaped atmConnections and notShaped atmConnections is not allowed on nodeB.
3.8.10 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],
ALU confidential

Page 134/198
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 configable:
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.9 MICRO NODEB ATM (BTS 1120)
3.9.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
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:
ALU confidential

Page 135/198
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.9.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 two 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,
- loopBack supported.
Qos:
- Supported ServiceCategory: UBR, UBR+, CBR, rtVbr and nrtVBR,
- Recommended serviceCategory per atmConnection:
ALU confidential

Page 136/198
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:

• per link, Σ VBR Vcc SCR ≤ linkRate,
• per link, Σ CBR Vcc PCR ≤ linkRate,
• per link, Σ CBR Vcc PCR + Σ VBR Vcc PCR + Σ UBR+ Vcc PCR ≤ linkRate,
• per link, Σ CBR Vcc PCR + Σ VBR Vcc SCR + Σ UBR+ Vcc MCR ≤ linkRate,
• Σ CBR Vcc PCR + Σ VBR Vcc PCR + Σ UBR+ Vcc PCR linkRate ≤ x * linkRate,
• 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.
ALU confidential

Page 137/198
• 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.9.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 45 or 64 bytes
Packets, i.e. CPS packet payload.
Rule: IubTEG_ Iub_µNodeB atm – 05
The aal2 CPS Packet payload must be 45 bytes length; CPS-INFO parameter = 45 bytes.
3.9.4 SAAL:
List of the µNodeB Saal parameters:
Parameter Default value Range
MaxCC 4 [1 – 10]
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
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:
ALU confidential

Page 138/198
Timer_IDLE >> Timer_KEEP-ALIVE
3.9.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@:

Range: [255. 255. 255. 255- 0.0.0.0];
MgrPort2: UDP port:
Range: [1-65535];
Default: 162.

ALU confidential

Page 139/198
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.9.6 UMTS TRAFFIC FLOWS:

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

There is one “common traffic control part” and a number of “dedicated traffic control parts” inside
each µNodeB.
Only one common traffic control part will be active in one µ NodeB, therefore one CP Vcc.
Each dedicated traffic control part uses one communication control port, up to 3 CCP Vcc:

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

HSUPA will be available as a software upgrade in a future release.
Each baseband block will be able to handle support common channels plus up to 30 simultaneous
radio links using HSDPA for downlink and HSUPA for uplink (including SRB).
- An Hsupa channel is always associated to a Hsdpa channel for the downLink leg.
- The µNodeB CAC allows up to 30 simultaneous hsupa users.
ALU confidential

Page 140/198
3.10 PICO NODEB ATM (BTS 1010)
3.10.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.10.2 ATM:
The pico NodeB atm is compliant with R35.
AtmInterface Type:
- Supports UNI interface type.
- Doesn’t 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 two 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.6.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].
Atm Qos:
- ServiceCategory:
- Cbr, rt and nrtVBR, Ubr and Ubr+ are supported,
ALU confidential

Page 141/198
- 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.10.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.10.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

Page 142/198
3.10.5 UMTS TRAFFIC FLOWS:

The picoNodeB supports R99, hsdpa and Hsupa user traffic flows.
3.11 MSS
3.11.1 IMA
On Iub interface, Mss7k, POC, Passport nodes may perform IMA.
IMA is provided by following FP cards:
- 8pE1/T1 ATM FP
- MSA32 FP
- 4pE3/DS3 ATM FP
- 2pStm1 e Channelized FP
See section 3.7.2.
3.11.1.1 IMA LG BANDWIDTH REDUCTION/RESTORATION:

This section doesn’t apply to RNC-SDH configuration.
On Passport equipment, the component “HoldingPriority” indicates the order in which Vcc are to be
taken into outOfService in case of bandwidth reduction due to E1/T1 failure. The HoldingPriority is in
the range 0-4 while the HoldingPriority=4 indicates the least important VCC. See provisioning section.
When a link from an IMA linkGroup goes down, Passport dynamicBandwidthControl system takes
down Vcc according to HoldingPriority parameter value. On the other hand, when a link joins an IMA
linkGroup, vcc are getting re-established.
For any operation of adding or releasing link within an IMA linkGroup, ACAC is invoked to check the
correlation between ECR and available link bandwidth.
Algorithm description:
On the RNC-PCM or the Passport, when configuring vcc on an IMA linkGroup, a holdingPriority
parameter value is assigned against each vcc.
When a link within an IMA linkGroup fails, bandwidth on the interface is reduced, the RNC then
decides to remove some vcc in such a way the bandwidth reserved for the Vcc is lower than the IMA
LG available bandwidth.
The order, in which vcc are eligible for removal, depends on VCC assigned holdingPriority value.
Rule: IubTEG_Passport-IMA_01
VCC with the highest holdingPriority value will be the first removed. Whereas VCC with the
lowest holdingPriority value will be the last removed.
For security reason, to cover case of link failure within an IMA linkGroup, it is recommended to set
several UP DS & NDS vcc within an IMA linkGroup.
Rule: IubTEG_ Passport-IMA_02

It is recommended to configure as many UP DS vcc, and UP NDS vcc as amount of links
within the IMA linkGroup.
Exception:
ALU confidential

Page 143/198
case of hsdpa flow supported and IMA LG=8 PCM then either
- 8 UP DS vcc, 7 UP NDS vcc and 1 hsdpa Vcc are configured.
- 7 UP DS vcc, 7 UP NDS vcc and 2 hsdpa Vcc are configured.
In such a way, CP and CCP vcc are re-established first after failure of all links within an IMA
linkGroup, it is suggested to set CP & CCP vcc ECR = 0. Therefore CP and CCP vcc PCR, SCR and
MBS equal to 0.
Rule: IubTEG_ Passport-IMA_03

CP and CCP ECR = 0
On Passport node, use TDT=1, to be able to set PCR=SCR=MBS = ECR = 0.
Remark:
Impact on WFQ: since vcc ECR = 0, Passport automatically assigns a weight = 1 to this
connection. This weight value may be overridden by means of the MML: ATTRIBUTE AtmIf
Vcc Vcd Tm weight
Deactivation of the PassPort IMA bandwidth Reduction mechanism:

The IMA bandwidth Reduction mechanism within the Passport based node, may be deactivated
by setting a high overbooking factor to 800% on the atm interface, see the MML:
ATTRIBUTE AtmIf CA bandwidthPool (bwPool).
The overbooking is configured in the Passport node which ends the IMA interface.
3.11.2 IUB TOPOLOGY:

3.11.3 NAM CONNECTIVITIES:
3.11.4 NAM ATM CHARACTERISTICS:
3.11.5 NAM INTERWORKING WITH OTHER FEATURES:

3.11.6 NAM ATM CONFIGURATION
3.12 PLANE DESCRIPTION
3.12.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.
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.
Only the PS Interactive and Background trafficClass may use Hsupa services. The Streaming and
Conversational trafficClass traffic remain assigned to DCH.
Any PS RAB request with 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.
ALU confidential

Page 144/198
The dedicatedSRB associated to hsupa session is carried over the UP DS Vcc.
3.12.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 aal2Qos2 is assigned to the Hspa path(s).
Figure 3-56 HSPA aal2 Connections
3.12.1.2 ATM:
3.12.1.2.1 ATM QOS:
Let’s call Hspa traffic, the combination of both Hsdap and Hsupa traffic.
The hspa traffic expects a bestEffort service from the Transport layers, then a lower priority is assigned to
hspa traffic than to R99 traffic.
Each Hspa aal2 Path is associated to one Hspa vcc.
On the RNC side, the UBR serviceCategory is assigned to the Hspa Vcc.
On the NodeB side, the UBR serviceCategory priorityLevel 3 is assigned to the Hspa Vcc, moreover a
MCR is assigned to these vcc to avoid hsdpa flowControl traffic starvation from traffic with higher
priority.
3.12.1.2.2 ATM TM:

The hsupa traffic is expected to be very bursty.
3.12.1.2.3 ATM #VCC:

The maximum amount of Hspa 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.7.11.
ALU confidential

Page 145/198
Rule: IubTEG_Hsupa_1
Two Hspa vcc are configured per nodeB.
Beside up to 7 up ds vcc and up to 7 up nds vcc may be configured per NodeB according to the
amount of E1 per IMA linkGroup.
Arguing for determining amount of Hspa vcc:
Context1: UA5-0, NodeB populated with iCEM64 or iCEM128, up to 1 E-BBU per NodeB:
- Up to one E-BBU per NodeB whatever amount of CEM in the NodeB,
- One E-BBU is able to handle up to 15 hsupa user sessions,
=> UA5-0: a nodeB is able to handle up to 15 hsupa user sessions = up to 15 aal2 CID for
hsupa TRB,
- An hsupa leg always being associated to a hsdpa leg, 2*15 = 30 CID are required for
hsupa/hsdpa sessions.
The RNC Hsdpa CAC allowing up to 48 hsdpa legs per radio cell equivalent to up to
6*48=288 hsdpa legs for a NodeB populated with 6 radio cells, then a nodeB required up
to 288 + 15 = 303 aal2 CID = 2 HSPA Vcc.
Iub capacity: Up to 15 hsupa/hsdpa sessions and up to 273 DCH/hsdpa sessions.
3.12.1.3 TRAFFIC REGULATION

On the RNC side:
- The hsdpa CAC regulates amount of simultaneous Hsdpa legs per NodeB CEM regardless they are
associated to Release99 legs or Hsupa legs. See §3.7.11.
- The EBR associated to the Hsupa traffic is set to 0, in such a way to des-activate the aal2linkCac.
- The aal2CongestionManagement is not involved in the regulation of the hsupa traffic. It is only
involved in the regulation of the Iub aal2 downLink traffic (hsdpa, up nds and up ds).
On the NodeB side, the Hsupa CAC regulates amount of Hsupa leg per CEM. See § 3.8.10
3.12.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.
3.12.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 traffic is less urgent than the already existing Release99 traffic.
Then to avoid traffic starvation and supplementary delay in downLink on already existing UP NDS flow,
the Hsdpa traffic will not be carried in the UP NDS Vcc. Dedicated Vcc is/are created per nodeB, let’s
call it Iub Hspa Vcc.
Beside the Hspa Vcc carries the UL&DL Hsdpa flowControl traffic.
Since Hsdpa is handled on Iub interface, it’s mandatory to configure either single PCM or IMA on the Iub
interface. It’s not planned to handle Hsdpa traffic over a MultiPCM interface. The RNC PMC-PC aal2
congestion management considers only case of IMA and single PCM Transport solution.
IMA or single PCM are mandatory on Iub interface when Hsdpa traffic is handled.
In the specific context of 8 PCM per NodeB, ALU currently suggests to configured 8 UP DS and 8 UP
NDS Vcc, while the NodeB allows up to 16 aal2 Vcc, in such a way to be able to configure the new
Hsdpa Vcc, the recommendation is updated on following way:
ALU confidential

Page 146/198
When nodeB is populated with 8 PCM’s then are configured:
- 8 UP DS Vcc, 7 UP NDS vcc and 1 Hspa vcc per NodeB,
- 7 UP DS Vcc, 7 UP NDS vcc and 2 Hspa vcc per NodeB,.
If less than 8 PCM on the NodeB, keep the current recommendations for Release99 aal2 vcc and add the
new Hspa vcc.
3.12.2.1.1 HSPA ATM VCC QOS AND TM:

On RNC side, the Hspa Vcc is set with UBR serviceCategory, EP7, tdt=1, tdp=0 0 0 0 0.
Remark: Oam Vcc and Hspa 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 case RNC 16pOC3/Stm1 FP configured with ShapedVPT and the VP formation includes the OAM
and the Hsdpa Vcc, since both Vcc are configured with the same serviceCategory that implies the 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:
Hspa vcc queue weight = 40,
OAM vcc queue weight = 2.
On NodeB side, the Hspa 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.
Iub
DS UP dSRB
CID
NDS UP dSRB
CID
Hsdpa dSRB
UP DS Path /qos0 CID
Hsupa dSRB
CID
UP DS TRB
CID
NodeB
RNC
CID UP NDS TRB

UP NDS Path / qos1 UP NDS TRB
CID
Hsdpa DL TRB
CID Hsdpa flowControl
Hspa Path / qos2
HsUpa UL TRB
CID
Figure 3-57 Atm Vcc involved in Hsdpa
3.12.2.1.2 HSPA VCC ON IMA:

The Hsdpa Vcc configured on an IMA LG, is set on RNC side with HoldingPriority = 0 (highest)
The Hsdpa Vcc HoldingPriority is set with the highest priority: HP= 0.
ALU confidential

Page 147/198
3.12.2.2 AAL2 REQUIRED SERVICES:

- HSDPA AAL2 CID requirements:
- 1 CID from the UP DS path is seized for HSDPA dedicatedSRB,
- 1 CID from the UP NDS path is seized for DCH or E-DCH uplink leg associated to the
HSDPA leg,
- 1 CID from the Hspa path is seized for HSDPA DL TRB and flowControl.
- HSDPA AAL2 Path requirements:

- One aal2Path is assigned per Hspa Vcc.
- HSDPA AAL2 QOS requirements (impact Iub and Iur):

- UP NDS aal2 Path Qos = 0,
- UP NDS aal2 Path Qos = 1,
- HSPA aal2 Path Qos = 2,
The Hspa Aal2 Path(s) is assigned to aal2 QOS 2.
Iub
hsdpa dSRB s
CID
UP DS Path / qos0 Release99 dSRB s
CID
Release99 DCH UL TRB

NodeB
CID
UP NDS Path / qos1
RNC
Hsdpa DL TRB
Hspa Path / qos2 CID
Bidirectional Hsdpa flowControl
Figure 3-58 aal2 connections involved in Hsdpa
3.12.2.3 TRAFFIC REGULATION:
3.12.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 § 3.7.11.
ALU confidential

Page 148/198
3.12.2.3.2 HSDPA RNC AAL2LINK CAC:

Once the HSDPA CAC has been invoked, the RNC performs the admission on the associated DCH’s
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.12.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 § 0.
3.12.3 OAM PLANE

NodeB OAM information is:
- Configuration data,
- Software download,
- Performance management and

- Fault management
OAM information exchanged between NodeB and RNC-IN, are encapsulated in IP packets, IP packets
are carried in UMTS OAM VCC.
On Iub interface, OAM traffic is handled with the following protocol stack:
NodeB RNC-AN RNC-CN RNC-IN
IP IP IP IP IP
ATM ATM Eth Eth ATM
NodeB RNC-AN OMU RNC-IN RNC-IN

CCM MSA32 CP3 16pOC3
Ethernet link
Iub Iu WG,
1 MDM VCC
VCC 0 / 32 #NodeB * OAM VCC 1 OAM VCC OAM
MDM
InBand OAM Aggregation of OAM flows
Figure 3-59 Iub OAM Plan Protocol stack, OAM inBand case
3.12.3.1 ATM:
One OAM vcc is configured per nodeB.

Within the RNC, OAM IP traffic flows from:
- NodeBs,
- POC (option),
ALU confidential

Page 149/198
may be treated in two different ways InBand or OutBand OAM.
- InBand OAM:
OAM InBand means that both UMTS and OAM flows are carried over the same transport network
Consists in switching OAM Vcc from different ingress Links on the same physical link as user
traffic Vcc, instead of transmitted them on dedicated links, e.g.: Ethernet links.
VCC OAM VCC UP
Link 1
VCC OAM VCC UP VCC OAM1 VCC OAM2 VCC OAM3 VCC UP1 VCC UP2 VCC UP3
RNC-AN
Link 2 Link 4
VCC OAM VCC UP
Link 3
Figure 3-60 InBand OAM
OAM traffic is carried on VCC 0-32, on NodeB E1 links, elsewhere this VCC is switched and
VPI/VCI may change.
Case of RNC-SDH:
NodeB OAM Vcc terminate at the RNC-IN.
Different NodeB OAM VCC traffics are aggregated in the RNC-IN (See IP section below) and
transmitted in a common OAM VCC to the ATM Backbone or to the coreNetwork.
Moreover RNC-IN OAM traffic is aggregated at IP layer within the common OAM VCC
together with NodeB OAM traffic.
Furthermore the PMC-OMU traffic is aggregated into the common OAM VCC.
The NodeB OAM Vcc are switched at the POC and terminates at the RNC. Different nodeB
OAM Vcc are aggregated in the RNC (See IP section below). Moreover RNC OAM traffic is
aggregated with NodeB OAM traffic.
The aggregated OAM traffic flow is routed to OAM platform through SGSN/MGw and
optionally ATM backbone.
ALU confidential

Page 150/198
IP@: 10.9.1.1
OMU
RNC-CN
NodeB 1
Subnet@: 10.9.1.0 OMU

RNC-CN
SubnetMask: /24 Ethernet
Vcc 1.32
RNC-IN
RNC-IN
E1 CP3
IP@: 10.9.0.3 CP3
IP@: 10.9.1.2 Subnet@: 10.9.0.1
RNC-AN or ATM Switch

NodeB 2
Subnet@: 10.9.1.0 SubnetMask: /29 PP2 NextHop:

SubnetMask: /24
IP@: 10.9.0.9
VR0
Vcc 1.32
IP@: 10.9.1.254 PP6 PP1 IP@: 10.9.0.10
E1
Subnet@: 10.9.1.0 Subnet@: 10.9.0.8
SubnetMask: /24 SubnetMask: /30
…
Iub Iub MPE 1000 MPE 808 Iu

AC1
AC1 AC2
AC2
… AC200
AC200 AC1
AC1
Vcc 200.32
Vcc 1.32
Vcc 2.32
Vcc 18.52
IP@: 10.9.1.200
Vcc 200.32
NodeB 200
Subnet@: 10.9.1.0 … OAM VCC

SubnetMask: /24 Vcc 2.32 CP VCCs
Vcc 1.32 UP VCCs
Vcc 1.32 atmIf
atmIf 804
804 atmIf
atmIf 815
815
STM1 STM1
Figure 3-61 RNS OAM inBand
- OutBand OAM:
OAM Traffic is carried on dedicated Ethernet links from RNC different shelves to OAM platform
with exception of the RNC-AN OAM flow which is transmitted inBand to the RNC-IN:
ALU confidential

Page 151/198
IP@: 10.9.1.1 RNC-CN

RNC-CN OMU
CP3
OMU
NodeB 1
OAM
Subnet@: 10.9.1.0 OMU
OAM Plateform
SubnetMask: /24
Hub
Hub
Vcc 1.32 RNC-IN
RNC-IN
Plateform (MDM,
E1 IP@: 10.9.0.3
CP3
CP3
RNC-AN or ATM Switch

IP@: 10.9.1.2 Subnet@: 10.9.0.1
Subnet@: 10.9.1.0 SubnetMask: /29 PP2
SubnetMask: /24
NodeB 2
VR0
(MDM, OMC-R,
IP
Vcc 1.32 IP@: 10.9.1.254 PP6
IPBackBone
E1 Subnet@: 10.9.1.0
BackBone
SubnetMask: /24
OMC-R, OMC-B)
… Iub
Iub MPE 1000
OMC-B)
Ethernet
AC1 …
AC1 AC2
AC2 AC200
AC200
IP@: 10.9.1.200 (MDM VCC)
Vcc 200.32
Vcc 1.32
Vcc 2.32
Subnet@: 10.9.1.0 Vcc 200.32

NodeB 200
…
SubnetMask: /24
Vcc 2.32
Vcc 1.32 Vcc 1.32
atmIf
atmIf 804
804
E1 STM1
Figure 3-62 RNS OAM outBand
OAM VCC is switched at RNC-AN (if present), it terminates at the RNC-IN.

All nodeB OAM Vcc are aggregated in the RNC-IN.
Aggregated OAM traffic flow is routed to OMC-B through CP3 Ethernet port.
TrafficManagement: OAM VCC should be configured with UBR ServiceCategory.
3.12.3.2 IP:
OAM VCC transports IP based OAM information between NodeB and RNC-IN. IP packets are routed
to OAM Platform.
3.12.3.2.1 ADDRESSING:
See [R218 & R80]

A local IP address is configured on NodeB Ethernet port, involved in local communication between TIL
and NodeB,
Moreover NodeB is configured with an IP@ either static Allocation or dynamic Allocation by means of
DHCP, this IP@ either Private/Public is involved in remote dialogue between NodeB and TIL through
ATM and OAM dialogue between OAM platform and nodeB.
If public IP backbone is crossed (on Gn or Gi) interface, NodeB-OAM platform IP sessions are
managed through a VPN access.
If Static allocation, each nodeB is provisioned with an IP@, by means of inverseATM_ARP, RNC-IN
routing tables are updated with nodeB IP@.
ALU confidential

Page 152/198
‘Dynamic allocation’ implies that a DHCP function is inserted in the network.

DHCP is composed of three functions:
- DHCP Client, which is the nodeB,
- DHCP Relay Agent, which is a routing function inserted in an UMTS node, and
- DHCP Server.
DHCP server provides NodeBs with:

- Dynamic IP@ allocated to nodeB,
- List of OMC-B IP@,
- NodeB subnet mask.
DHCP dialogue is supported by IP/ATM protocol stack. NodeB OAM VCC carries the DHCP
information flow.
DHCP
Port 67 Port 68
UDP
Proto=17
IP
AAL5 OAM
ATM
DHCP
NodeB RNC WG PP8k
DHCP Client DHCP Server
Figure 3-63 DHCP Protocol stack, InBand OAM case
DHCP Server may be located on the OAM platform, one or several DHCP Servers may be included in
the network.
Rule: Iub_OAM_00
Passport DHCP Relay Agent can forward messages to up to 3 DHCP Servers.
DHCP which answers first to the nodeB request is selected.

DHCP Relay Agent is located in the UMTS node which handles the Aggregation, for routing reason,
indeed inverseATM_ARP has to be executed in the node which manages 1 OAM VCC per nodeB.
Rule: Iub_OAM_01
DHCP Relay Agent is located in the UMTS node which handles the Aggregation.
Aggregation is recommended in the RNC-IN, therefore DHCP Relay Agent is located in the RNC-IN.
Rule: Iub_OAM_02
DHCP Relay Agent is located in the RNC-IN.
ALU confidential

Page 153/198
DHCP is invoked at the nodeB start up phase for allocating a permanent or dynamic IP@ to each
nodeB.
DHCP dialogue between NodeB and DHCP is encapsulated in IP packet and carried on the OAM VCC.
DHCP Dialogue consists in three phases:
- Broadcast IP dialogue between a NodeB and each DHCP. DHCP servers provide nodeB
with an IP@. DHCP selected is the first which answers.
- Broadcast IP dialogue between a NodeB and each DHCP, NodeB indicates to all DHCP
Servers the selected one. The selected DHCP returns the configuration parameters.
- Inverse ATM ARP protocol is invoked for configuration parameter check, it results with
an update of the RNC-IN routing tables: mapping between nodeB ATM address and
nodeB IP@.
- Unicast IP dialogue between a NodeB and the selected DHCP server.
After obtaining IP address, NodeB is ready to receive OAM information encapsulated in IP packet, IP
packets carried in OAM VCC.
When nodeB reparenting, a new IP@ is allocated to nodeB, if DHCP Servers connected to Source RNC
and target RNC are different.
DHCP Configuration:
Rule: Iub_OAM_03
Range 192.168.0.0 to 192.168.255.0 is reserved for nodeB internal subnet and then shall not
be used by DHCP.
Since up to 200 nodeBs may be connected to a RNC, class C IP@ are enough to identify a nodeB in the
RNS.
Rule: Iub_OAM_04
NodeB IP@ is a Class C IP address.
Network mask: 255.255.255.0
One subnet is defined, therefore 255 IP hosts 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.
As a result 253 IP@ are available to identify nodeBs. 200 IP@ are allocated to connected nodeBs, and
the 53 IP@ are free to be used when reparenting.
Rule: Iub_OAM_05
One NodeB OAM subnet.
Subnet Mask: /24.
Rule: Iub_OAM_06
It’s not mandatory for OMC-B to be in the same subnet as nodeB.
NodeB IP address shall be a private IP address .
ALU confidential

Page 154/198
DHCP Relay Agent Configuration:

DHCP Relay Agent is a routing function implemented in the UMTS node which handles aggregation,
RNC-IN in this case. The functionality consists in routing IP packets which contains DHCP information
to DHCP Servers.
Rule: Iub_OAM_07
RNC-IN / DHCP Relay Agent is provisioned with:
− Its own DHCP Relay Agent IP@.
− IP@ of each connected DHCP Server
Rule: Iub_OAM_08
DHCP Relay Agent IP@ and NodeB IP@ may be in different subnet.
OAM
OAM Plateform
Plateform
DHCP
DHCP DHCP
DHCP DHCP
DHCP
Server
Server Server
Server Server
Server
IP@ IP@ IP@
DHCP
DHCP Clients
Ethernet
Option
Clients
Iub RNC-
RNC- RNC-IN
RNC-IN Iu WG-AN
WG-AN
AN
AN
DHCP
DHCP
NodeB 1
IP flow RelayAgent CP3

CP3
RelayAgent
AtmIf
AtmIf
VCC 0 / 32 PP
MVR MVR
IP flow
AtmIf
PP8k
NodeB 2
PP8k
PP PP PP PP
VCC 0 / 32
NB1 OAM VCC
AtmIf
AtmMPE
AC
AtmMPE
AtmMPE
AtmIf
AtmIf
NB2 OAM VCC

AtmMPE
AtmIf
IP flow OAM VCC

AtmIf
AtmIf
AC OAM VCC AC AC
NB3 OAM VCC AC
AC
NodeB 3
…
VCC 0 / 32
AtmIf
E1 Stm1 Stm1 Stm1
Figure 3-64 DHCP Dialogue synoptique
3.12.3.2.2 ROUTING:
On RNC, no IP routing protocol is activated, IP routing table is manually configured.

It is achieved by assigning a nexthop for each reachable IP Hosts, or using default gateway routing.
Rule: Iub_OAM_09
No Routing protocol is activated, Static routes are used.
ALU confidential

Page 155/198
3.12.3.2.3 AGGREGATION:
Definition:
Aggregation consists in multiplexing IP flows received in different ingress VCC’s, in one egress VCC,
using IP routing.
Node which aggregates, extracts IP packets from Vcc, and routes IP packets from different Vcc to one
VCC.
PassPort
VR
pp pp pp IP@
IP flow MPE
1 VCC ac
Link 1
IP flow IP@
IP flow IP@
IP flow IP flow IP@
MPE MPE
1 VCC ac ac 1 VCC
Link 2 Link 4
IP flow MPE
1 VCC ac
Link 3
Figure 3-65 Aggregation
When OAM InBand is configured on the RNC-AN / RNC-IN interface, aggregation may occur on
different nodes of the UTRAN interface: POC if PP7k based, RNC-AN (case of RNC-PCM), or in the
RNC-IN. ALU recommends only aggregation within the RNC-IN.
Rule: Iub_OAM_10
Case of RNC-PCM or RNC-SDH configuration, Aggregation occurs in RNC-IN.
On RNC-IN, IP flows received from NodeB in OAM Vcc, are aggregated with RNC-AN and RNC-IN
OAM flows by means of Management virtualRouter. Resulting IP flows are carried in one VCC to the
coreNetwork if inBand solution.
On coreNetwork aggregationNode, IP flows received from RNC-IN in OAM VCC, are aggregated with
coreNetwork aggregationNode and coreNetwork different shelves OAM flows by means of
Management VirtualRouter. Resulting IP flow is carried in one VCC to the PP8k.
PP8k is connected to OAM Platforms:

- OMC-B, OAM platform for NodeB,
- OMC-R, OAM platform for RNC-CN,

- MDM, OAM platform for Passport.
ALU confidential

Page 156/198
OMC-R OMC-B MDM

IP@ IP@ IP@
RNC-CN
RNC-CN
PP8k
PP8k
IP
-WG-AN OAM
Eth RNC-CN OAM flow
-WG Shelf OAM
Ethernet external link -RNC-CN OAM
-RNC-IN OAM
OMU
OMU -NodeB OAM,
-RNC-AN OAM
Iub RNC-AN
RNC-AN RNC-IN
RNC-IN Iu AggregationNode
AggregationNode
IP@
VR CP2
CP2
pp CP3 MVR CP3 MVR
pp
CP3 CP3
NodeB
NodeB 11
pp
IP@ pp pp pp pp IP@ pp pp pp pp
MPE
IP@ IP@ IP@ IP@ IP@
1 OAM VCC
IP@ IP@ IP@
ac
OAM IP flow
E1 1 MDM VCC
AtmIf
VCC 0 / 32
NodeB
ac
MPE
MPE
NodeB 22
AtmIf
ac
IP@
ac
NodeB1 OAM VCC 1 OAM VCC
ac
AtmIf
AtmIf
AtmIf
AtmIf
MPE
MPE
OAM IP flow
NodeB2 OAM VCC
ac
ac
AtmIf
VCC 0 / 32
E1 NodeB3 OAM VCC
ac
NodeB
NodeB 33
IP@ OAM IP flow STM1 MPE MPE

AtmIf
AtmIf
AtmIf
STM1 ac ac
VCC 0 / 32
E1 AtmIf AtmIf
-RNC-CN OAM
-NodeB OAM, -RNC-IN OAM
-RNC-AN OAM, -NodeB OAM,
-RNC-AN OAM.
MGw
MGw or
or MGw
MGw or
or
SGSN
SGSN SGSN
SGSN
Figure 3-66 OAM Base Line, InBand OAM
Remark:
Aggregation of OAM IP flows within the RNC-AN or within the POC/PP7k, has not been tested by
R&D, therefore not recommended in this document.
3.12.4 CONTROL PLANE

ATM, Aal5, and SaalNNI protocols are involved in Transport layers.
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.
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 a NodeB.
- One CP VCC is configured per NodeB, since one CCM card is configured on nodeB.
CP & CCP Vcc originate in the NodeB respectively CCM card and CEM card, and terminate in the
RNC-CNODE, TMU-R card.
ALU confidential

Page 157/198
RNC-CN is populated with up to 14 TMU-R cards. Among these 14 TMU-R cards, two are reserved for
Spare and 12 TMU-R are active.
If RNC is populated with less than 9 TMU’s, only one TMU is reserved for spare.
One TMU-R 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,
3.12.4.1 RNC HANDLING:
RNC-CN TMU cards handle CP and CCP signaling.
Rule: IubTEG_CP_O1
All CP and CCP Vcc relatives to one nodeB are allocated to one TMU-R.
One TMU-R is able to manage up to 20 nodeBs. Nevertheless a RNC manages up to 200
nodeBs.
A RNC-CN algorithm is in charge of the choice of the TMU-R. Algorithm is invoked at the start up
phase of the RNC, and when an active TMU-r fails for selecting a spare TMU-r.
This algorithm is independent from the RNC-CN algorithm which allocates a TMU-R to an UE for
NonAccessStratum Signaling (SRB).
Therefore TMU-R which relays NAS Signaling relative to an UE may be different from the TMU-R
which manages ControlPlane traffic (CP and CCP) relative to the nodeB where the UE is connected.
3.12.5 USER PLANE

ATM and AAL2 protocols are involved in Transport layers.
NodeB RNC-AN RNC-CN RNC-IN
RRC RRC
Aal2 Aal5 Aal5 Aal2
ATM ATM ATM ATM ATM
NodeB RNC-AN TMU RNC-IN RNC-IN

?? MSA32 16pOC3 16pOC3
Icn
Internal VCCs
Iub
NDS UPVCC NDS UPVCC
DS UPVCC DS UPVCC
Figure 3-67 UserPlane Protocol stack
ALU confidential

Page 158/198
UserPlane Vcc originate in the nodeB and terminate in the RNC-INODE.
Required amount of UP Vcc is determined based on the nodeB configuration (amount of CEM cards),
available physical bandwidth, and PCM characteristic either MultiPCM or IMA.
The pool of userPlane Vcc is split in two different groups, a different QOS values are associated to each
group.
Configuration rules in section 5 cover up to 16 user plane Vcc and split the pool UP Vcc in two groups
of 8 Vcc,
- QOS value 0 is associated to one group of Vcc; these Vcc are dedicated to UserPlane
DelaySensitive traffic (part of TRB), dedicated and common SRB’s.
- QOS value 1 is associated to the second group of Vcc, these Vcc are dedicated to
UserPlane nonDelaySensitive traffic (part of TRB),
Definition of traffic carried in UserPlane Vcc:
Rule: IubTEG_UP_01
Each aal2 VCC supports up to 248 sub-flows identified in aal2 protocol by Pathid and CID
[see R41].
The AAL2 CIDs are consumed as following:
- 1 CID per TRB: (TrafficRadioBearer, user traffic DS and NDS),

- 1 CID per DedicatedSRB: (SignallingRadioBearer). On dedicatedSRB are
transmitted NonAccessStratum Signalings: CC, SM, MM, and GMM signalings,
- 1 CID per CommonSRB:

- 3 CommonSRB are set per UMTS Cell, one for RACH, one for FACH and one
for PCH. There are up to 6 UMTS cells per nodeB.
- - One more commonSRB dedicated to a second FACH (see §4 for release

compliancy).
User traffic is carried either in the DelaySensitive VCC (QOS=0) or in the

NonDelaySensitive VCC (QOS=1), according to the UMTS serviceClass. UMTS
ServiceClass is inserted in the cause field of the RRC/ConnectionRequest message from
the UE. Document
ServiceClasses RadioBearer UP VCC type

Conversational AMR TRB
Conversational 64 kb/s: VT, (videoTelephony) TRB
Conversational 64 kb/s: CSD, (circuitSwitchedData) TRB
CS streaming 14.4 kb/s TRB UP DS VCC
CS streaming 57,6 kb/s TRB
dedicatedSRB
commonSRB
PS Streaming TRB UP NDS VCC
ALU confidential

Page 159/198
PS interactive TRB
PS background TRB
Table 3-11 Iub UserPlane QOS mapping
Concerning NAS Signaling carried in dedicatedSRB, this traffic received from the UE
goes through nodeB transparently, is carried to the RNC-IN within Iub UP DS Vcc. RNC-
IN forwards this traffic to the RNC-CN within internal Vcc where it is handled by a TMU-
R before transmitted to the coreNetwork via RNC-IN.
On invoking IMSI_attach, MOC and MTC procedures, UE transmits to RNC-CN RRC

ConnectionRequest message in RACH. RNC-CN allocates a TMU-R to this UE. A RNC-
CN algorithm is in charge of selecting a TMU-R, in such a way the traffic is equally
distributed on each available TMU-R. The selected TMU-R is associated to a UE. The
selected TMU-R may be different from the TMU-R dedicated to the nodeB ControlPlane
traffic (CP and CCP). See §4 for release compliancy.
A/ Calculation of amount of UP Vcc:

Required amount of UP Vcc depends on 3 different limiting factors:
- NodeB CEM card capacity,
- AAL2 VCC CID capacity and
- E1 bandwidth.
Below analysis per limiting factor:

• NodeB CEM Card capacity:
Amount of CEM cards and CEM card type impact the amount of UP Vcc.
o A nodeB may be populated with up to 6 CEM cards (see ControlPlane section).
o NodeB CEM capacity depends on CEM type:
CEMALPHA and iCEM64 handle up to 64 simultaneous calls (RAB CS 12,2 kb/s

speech),
iCEM 128 handles up to 128 simultaneous calls.
CEM type availability is indicated in section 4.

Mixed of iCEM different type is allowed on one NodeB.
• AAL2 VCC CID capacity:
A Voice call or a Data session is handled on a TRB (Traffic Radio Bearer). A dedicatedSRB
(SignalingRadioBearer) is associated to each TRB.
At Aal2 layer, TRB on one hand, SRB on other hand are identified by means of a CID. An Aal2
path (versus an Aal2 VCC, since one aal2 path per VCC) handles up to 248 CIDs.
As an example, indicating that the CEM capacity is 128 simultaneous calls, means that 128
TRB’s and 128 SRB’s may be handled simultaneously by a CEM. In other words, 128
CIDs are required for TRB and 128 CID are required for SRB’s simultaneously by a CEM.
Therefore 256 CID values may be required.
Furthermore according to QOS requirements, UserPlane NodeB traffic may be carried either on UP
DS VCC or UP NDS VCC:
- TRB associated to user call/session may be carried either UP DS VCC (QOS=0) or UP
NDS VCC (QOS=1).
- DedicatedSRB associated to TRB is always carried in UP DS VCC (QOS=0).
ALU confidential

Page 160/198
- CommonSRB associated to NodeB Cells are carried in UP DS VCC (QOS=0).
Rule: IubTEG_UP_02
- UP DS VCC carries:
- TRB for DS,
- dedicatedSRB for DS and NDS,

- commonSRB
- UP NDS VCC carries:
- TRB for NDS
In the table below, CE stands for Channel Element.

A CE represents a unit of CEM capacity. The cost of one speech Radio Link with its dedicated SRB is
1CE
The pool of CEM is composed either of CEMALPHA or CEM128 cards.
E.g.: for CE=128, the pool of CEMs is composed either of 2 CEMALPHA cards or 1 CEM128.
AAL2 CI Limiting Factor

#CE #TRB #SRB #UP VCCs #UP VCCs
DS (Qos0) or NDS (QOS1) DS NDS
Release2, covered by CEM64 cards

64 64 or 64 64 1 1
128 128 or 128 128 2 1
Release3, covered by CEM64 or CEM128 cards

192 192 or 192 192 2 1
256 256 or 256 256 3 2
320 320 or 320 320 3 2
384 384 or 384 384 4 2
448 448 or 448 448 4 2
512 512 or 512 512 5 3
576 576 or 576 576 5 3
640 640 or 640 640 6 3
704 704 or 704 704 6 3
768 768 or 768 768 7 4
Table 3-12 UP VCC amount calculation
• E1 bandwidth:
E1 bandwidth is another limiting factor.

One E1 payload is 4528 cells/s.
A speech call, which is the greediest in terms of AAL2 CID, generates on DS UP VCC, a load of:
- 50 cells/s per TRB for AF=100%, or
- 30 cells per TRB for an AF=60%, as an example, and
ALU confidential

Page 161/198
- 25 cells/s for SRB which is the uppest range estimation. SRB may transmit at 25 cells/s
but sporadically.
The SRB traffic and traffic distribution on a period required a dimensioning study.
Therefore an E1 is able to carry
- up to 60 speech calls for an AF=100%,
- up to 82 speech calls for an AF=60%,
Table below, is based on 3GPP RAB definition, and indicates per RAB type, allowed throughput in
cell/s. Sporadicity of traffic per RAB is represented by means of AF parameter (ActivityFactor). In the
table below only Speech AF is set for calculating E1 capacity in terms of amount of speech call:
RAB Definition: ATM TD Parameters:

Domain: RAB: TTI: #Blocks SCR AF
(kb/s) (ms) per TTI (Cells/s)
With AF
DL UL: TF DL UL: DL UL: DL UL:
CS/Speech 12,2 12,2 2 20 20 1 1 30 30 60%
CSD 14.4 14,4 14,4 1 40 40 2 2 50 50
UP DS
CSD 64 64 64 1 20 20 4 4 200 200

CSD57,6 57,6 57,6 4 40 40 4 4 175 175
DedicatedSRB 3,4 3,4 40 40 1 1 15 15
CommonSRB 32 32
UP NDS
PS I/B 64 64 4 20 20 4 4 200 200

PS I/B 128 64 4 20 20 8 4 400 200
PS I/B 384 64 5 10 20 12 4 1200 200
Determining amount of UP DS and NDS Vcc consists in a trade off between the three above limiting
factors:
o amount of UP DS VCC:
One E1 carries up to 82 simultaneous speech calls (with ActivityFactor=60%), more

than CEMALPHA capacity.
A CEMALPHA handles up to 64 simultaneous Speech calls, therefore up to 64 TRB’s

and 64 dedicatedSRB’s may be carried on DS UP VCC, requiring 128 CID values.
For DS UP VCC, CEMALPHA is more restricting than E1 bandwidth and AAL2 CID
limitation.
As a result one UP DS VCC per E1 is enough, moreover 1 UP DS VCC per
CEMALPHA is enough.
One CEM128 handles up to 128 speech calls simultaneously, in other words 128 TRB
+ 128 SRB; therefore 256 CID values are required, more than available on one AAL2
VCC (248). Nevertheless an E1 manages up to 82 speech calls.
As a result one UP DS VCC per E1 is enough.
o Amount of UP NDS VCC:
One E1 carries up to 22 simultaneous RAB64/64 (AF=100%), CEMALPHA card

allows up to 16 simultaneous calls whereas CEM128 card allows up to 32
simultaneous calls. For NDS UP VCC, CEM limitation and E1 bandwidth are more
restricting than AAL2 CID limitation.
ALU confidential

Page 162/198
As a result one UP NDS VCC per E1 is enough.
Conclusion:
Analysis shows that E1 bandwidth and NodeB CEM capacity are more restricting than
AAL2 CID limitation.
Since E1 bandwidth and NodeB CEM capacity are more restricting factor than AAL2
CID limitation, 1 UP DS VCC and 1 UP NDS VCC are configured on one E1.
In such a way to distribute load, 1 UP DS VCC and 1 UP NDS VCC are configured
per E1 link.
Rule: IubTEG_UP_03
On each E1 link configured on a nodeB, is provisioned:
- 1 UP DS VCC,
- 1 UP NDS VCC.
On each E1, 2 UP Vcc are configured, therefore 2*248 CID are available per E1.
B/ Calculation of amount of nodeB E1 links:

MultiPCM feature allows configuring up to 4 E1 links on nodeB, and IMA feature allows IMA
LinkGroup with up to 8 E1.
The amount of E1 per nodeB is the result of a dimensioning study based on the customer callModel.
Moreover a customer may specify specific requirements which modify dimensioning results.
3.12.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.12.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 switching 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.
ALU confidential

Page 163/198
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 Vpcs 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.
3.12.6.2 OAM FLOW
The OAM Vcc are 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
OAM Vcc have to 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 MS3 FP:
UA5-0:
The RNC supports the 16pOC3/stm1 MS3 FP.
FP IP:
PCR5-2: IP is not supported,
PCR6-1 or 7-1: IP over Atm,
FP MPLS:
− PCR5-2: MPLS not supported.
− PCR 6-1 or 7-1: MPLS supported
• Rfc2547: BGP MPLS VPN,
• Rfc2764: IP VPN
FP POS:
ALU confidential

Page 164/198
− PCR5-2: POS not supported.
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):
2pStm1 Electrical Channelized FP is available on RNC-AN for the Passport release PCR5-
2.
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.
ALU confidential

Page 165/198
4.1.2 RNC TYPES:

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

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

UA4 -2:
The Iuxif component is removed and replaced by two components: IubIf and aal2If.
4.1.5 PATHID:
UA 5-0-A :
The RNC supports up to 4000 aal2 Paths.
UA 5-0 & 4:
The RNC supports up to 2100 aal2 Paths.
4.1.6 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’.
4.1.7 AAL2 LINK CAC:

Aal2 link CAC, AvailableCellRate (ACR):
UA 5-0:
ALU confidential

Page 166/198
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:
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 Mise en forme : Puces et
according to bandwidthPool. numéros
- 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:
- 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. Mise en forme : Puces et
numéros
ALU confidential

Page 167/198
4.1.9 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 4 6 7 9 11 12 14
# nodeB 80 120 140 140 200 200 200
Max # CP and CCP 480 800 960 980 1400 1400 1400
Note:
− #TMU in the table indicates the sum of active and Spare TMU.
− This corresponds to the maximum NodeB configuration equipped with 6 CEM, which
requires 1 CP + 6 CCP vcc per NodeB.
4.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.
ALU confidential

Page 168/198
BBU Role assignment to BBU component:

UA 5-0:
An algorithm is in charge of assigning the different BBU roles to the CEM BBU
components. Therefore the kind of traffic handle by a CEM can not be predicted in
configuration phase.
UA 4-2:
Each BBU component is configured with one BBU role.
4.2.3 MULTIPCM:
UA5-1:
The xPcm mode is supported. Either all the nodeB E1 are in xPcm mode, or the nodeB is
configured with a mix of n*E1 IMA and p*E1 in xPcm.
Hspa over xPcm is supported.
UA 4-2, UA5-0:
The nodeB multiPCM configuration is no more supported.
4.2.4 IMA:
UA5-1:
Either all the nodeB E1 are inserted within an IMA linkGroup, or the nodeB is configured
with a mix of n*E1 IMA and p*E1 in xPcm.
UA 4-2, UA5-0:
The nodeB supports only IMA.

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

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

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

parameter.
ALU confidential

Page 169/198
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:

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

UA 5-0:
AAL1 CES SDT NOT available.
4.2.7 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 SC configured in PriorityLevel

for the interface NodeB
- - - 0
UP DS rtVBR UBR 1
UP NDS nrtVBR UBR 2
ALU confidential

Page 170/198
CP rtVBR UBR 1
CCP rtVBR UBR 1
OAM UBR UBR+/MCR 3
- 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 SC recommended SC configured in PriorityLevel

for the interface NodeB
UP DS rtVBR UBR 0
UP NDS nrtVBR UBR 2
CP rtVBR UBR+ / MCR 1
CCP rtVBR UBR+ / MCR 1
OAM UBR UBR+/MCR 3

4.2.8.1 TRAFFIC DESCRIPTOR PARAMETER VALUES
NodeB UBR+/MCR availability:

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

UA 4 & 3:
- Case of E1:
− Minimum throughput for full E1 is: 1, 92 kbits/s / 20 = 96 kbits/s for both full
E1 and IMA linkGroup composed of up to 8 E1s. NodeB OAM converts
kbits/s into bits/s using ratio 1000. Therefore minimum throughput is
227cells/s.
− Case of E1 Drop&Insert 15/15, the minimal cell rate is 227/2 = 114 cells/s.
- Case of T1:
ALU confidential

Page 171/198
− Minimum throughput for full T1 is 1,544 Mbits/s / 20 = 77, 20 kbits/s; in

other words, Minimum throughput for full T1 is 3622 cells/s / 20 = 182
cells/s. Therefore minimum throughput is 182 cells/s.
− Case of T1 Drop&Insert 12/12, the minimal cell rate is 182/2 = 91 cells/s.
OAM VCC UBR+ /MCR value:

− UA 4-1 & 3:
The OAM Vcc is still provided by factory, configured with UBR+/MCR.
4.2.8.2 TRAFFIC REGULATION MECHANISMS
TrafficShaping:
UA 4-1:
TrafficShaping at VC level is optional.
When trafficShaping is not activated, case of IMA, the NodeB accepts and don’t 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 NAM
E3 connectivity is not offered in Release3
ALU confidential

Page 172/198
4.6 PLANE RELATIVE
4.6.1 UMTS HSUPA PLANE:

UA5-0:
The UMTS HSUPA traffic flow is added.

The Hsdpa and Hsupa are carried over different dedicated vcc.
4.6.2 UMTS HSDPA PLANE:

UA4-2:
The UMTS HSDPA traffic flow is added.

Hsdpa is handled on Iub interface, not on Iur interface.
4.6.3 UMTS OAM PLANE:

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

Radio Network ControlPlane, CP and CCP VCC, RNC TMU-R allocation:
UA4:
Different TMU-R cards may be in charge of managing on one hand AccessStratum and on
other hand nonAccessStratum signaling relative to a nodeB.
4.6.5 UMTS USER PLANE

- NodeB CEM card:
- CommonSRB:
UA4:
4 commonSRB are set per UMTS Radio Cell. One more commonSRB is added per UMTS
cell, dedicated to a second FACH, it is called cellFach.
- RAB mapping:
UA4:
CSD64 is mapped to UP DS VCC.
4.6.6 TRANSPORT NETWORK CONTROLPLANE:

UA4:
ALCAP is not implemented. NBAP protocol is enhanced in such a way to assume

ALCAP functions. Therefore NBAP is proprietary.
ALU confidential

Page 173/198
5 CONFIGURATION RULES
Engineering provides configuration files for the Iub provisioning at:
• NodeB level,
• RNC-IN level,
• RNC-CN level,
• RNC-AN level,
• Other remote nodes are not covered by OCAN.
The provisioning is done by means of WPS, the offline UMTS provisioning tool. The tool federates
data for all UTRAN NE thus allowing cross-checking and ATM plan consistency.
Following sections provide Transport provisioning data according to the network configuration.
For the ATM Provisioning Data, Identify your network configuration in the tree below, and go to the
concerned section:
IubTransport Configuration
RNC-PCM Configuration RNC-SDH Configuration

§ 5.1.1 § 5.1.2
Public ATM Backbone Private ATM Backbone

§ 5.1.2 Not Covered
with POC without POC

§ 5.1.2.1 § 5.1.2.2
Figure 5-1 section organisation
5.1 ATM VCC CONFIGURATION RULE

The table below summarizes the maximum number of VCC per NodeB:
format Type Max # Total max
Aal5 OAM 1
Aal5 CP 1 8
Aal5 CCP 6
Aal2 Traffic 16 16
Remarks:
- The OAM vcc is pre-provisioned in factory with default vpi.vci 0 /32.
- The OAM vpi.vci on nodeB, like other I&C parameters, can be modified using WICL or
remote TIL (for nodeB).
ALU confidential

Page 174/198
- Since the nodeB is populated with up to 6 CEM then up to 6 CCP vcc may be configured.
5.1.1 NODEB INTERFACE

Table below provides the suggested vpi.vci values on the NodeB Iub interface:
NodeB Iub interface
VCC type: AAL VPI VCI #
Ces AAL1 1 57 to 64 8
UP DS / Hspa AAL2 1 41 to 47 7
UP NDS / Hspa AAL2 1 49 to 55 7
UP Hspa AAL2 1 48 + 56 2
CP AAL5 1 34 1
CCP AAL5 1 35 to 40 6
NodeB OAM AAL5 0 32 1
Table 5-1 NodeB Vpi/Vci
The vci 41 to 56 are reserved for the aal2 vcc. These vci values are used to identify either release99 or
hspa vcc.
This aal2 vci range is split in two sub-ranges: one sub-range for R99 DS traffic and one sub-range for
R99 NDS traffic.
The highest vci values from the two aal2 vci subranges are going to be assigned to hspa vccs, whereas
the lowest vci values from the two aal2 vci subranges are going to be assigned to the release 99 vccs.
Exemple:
Assuming a nodeB populated with 8 E1, configured with one IMA linkGroup composed of 7 E1 and
one single E1 (xPcm), 7 hspa vcc configured over the IMA linkGroup, 2 R99 vcc and 1 Hspa vcc
configured over the single E1:
The Hspa vcc are identified by vci: 56, 55, 54, 53 and 48, 47, 46, 45.
The R99 vcc are identified by vci: 41 and 49.
Remarks:
- On some atmBackbones providing VP switching services, the vpi 1 may not be available. For
such atmBackbone, the atmConnections identified by vpi=1 are switched at vc level.
- The assigned vci value starts from 32 since the first 32 vci (0-31) values are reserved.
- The vci = 33 was reserved for ALCAP in future releases.
5.1.2 RNC IUB INTERFACE

The vpi on the RNC-POC interface are fixed to 0, since no atmBackbone on this interface and 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.
It is considered that IubIf is in the range [1, 253].
One OAM-MDM vcc per link is reserved to carry POC OAM InBand traffic to the MDM.
Table below provides suggested vpi, vci values on the RNC-POC interface, moreover these rules may
apply on the atmBackbone interfaces; ‘k’ represents the IubIf value:
ALU confidential

Page 175/198
RNC Iub interface, POC interfaces

VCC type: AAL VPI VCI #
UP DS / Hspa AAL2 0 34+24*(k-1) to 40+24*(k-1) 7
CP NBAP c AAL5 0 50+24*(k-1) 1
CCPn NBAP d AAL5 0 51+24*(k-1) to 56+24*(k-1) 6
UP NDS / Hspa AAL2 0 42+24*(k-1) to 48+24*(k-1) 7
UP Hspa AAL2 0 41+24*(k-1) 49+24*(k-1) 2
NodeB OAM AAL5 0 33+24*(k-1) 1
POC InBdOAM AAL5 0 32 1
Table 5-2 RNC-POC vcc provisioning rule
The vci 34+24*(k-1) to 49+24*(k-1) are reserved for the aal2 vcc. These vci values are used to identify
either release99 or hspa vcc.
This aal2 vci range is split in two sub-ranges: one sub-range for R99 DS traffic and one sub-range for
R99 NDS traffic.
The highest vci values from the two aal2 vci subranges are going to be assigned to hspa vccs, whereas
the lowest vci values from the two aal2 vci subranges are going to be assigned to the release 99 vccs.
Remarks:
- No ces vcc is configured on the RNC-AN /RNC-IN interface, since the RNC-IN can not act as a
ces iwf.
- 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.
Example of vpi.vci values on the RNC-POC interface according to the k=iubIf value:
k 1 2 3 253
VPI 0
OAM Vci: 33 57 81 6081
34 58 82 6082
UPDS Vci: … …
40 64 88 6088
42 66 90 6090
UPNDS Vci: … …
48 72 96 6096
CP Vci: 50 74 98 6098
51 75 99 6099
CCP Vci: … …
56 80 104 6104
41 65 89 6089
Hspa Vci:
49 73 97 6097
Figure 5-2 RNC-POC vpi.vci value exemple
The following figure illustrates the usage of the vpi.vci rules on the different transport interfaces of a
RNC-PCM Iub:
ALU confidential

Page 176/198
Aal2 Connections:
VC UP DS
VCC=0 / 34+24*(k-1) to 0 / 40+24*(k-1)
VC UP DS VCC=1/41-47 VC UP NDS
VC UP NDS VCC=1/49-55 VCC=0 / 42+24*(k-1) to 0 / 48+24*(k-1)
VC Hspa VCC=1/48+56 VC Hspa
VC CP VCC=1/34 VCC=0 / 41+24*(k-1) + 0 / 49+24*(k-1)
Aal5 Connections:
VC CCP VCC=1/35-40 VC CP
VC OAM VCC=0.32 VCC=0 / 50+24*(k-1)
VC CCPn
NodeB
NodeB
(k
(k == x)
VCC=0 / 51+24*(k-1) to 0 / 56+24*(k-1)
POC
VC OAM
POC
E1
x)
NodeB
NodeB
(k
(k == ))
VCC=0 / 33+24*(k-1) RNC-PDH

RNC-PDH
E1
STM1
NodeB
NodeB
(k
(k ==NodeB
NodeB
y)
y)
(k
(k == ))
STM1
POC
ATM
POC
E1
ATM STM1
RNC-IN
RNC-IN
BackBone
BackBone
POC
POC
E1 STM1
NodeB
NodeB
(k
(k == z)
RNC-AN
RNC-AN
E1
z)
E1 STM1
NodeB
NodeB
(k
(k == w)
Note: if no PNNI.
E1
w)
5.1.3 PNNI
5.1.3.1 PNNI ATM CONNECTION IDENTIFIERS
On each intermediate interface, in PNNI sPvc establishment phase, the Passport selects 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:
PassPort 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.
NodeId attribute is under atmRouting Pnni ConfiguredNode.
5.1.3.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 of the Pnni sPvc.
On the port with the attribute AtmIf Uni = User are configured the Pvc.
ALU confidential

Page 177/198
Beside the ports assigned to Iub, Iu and Iur interfaces are configured with the attribute AtmIf Pnni.
5.1.3.2.1 IU/IUR PNNI SPVC HAIRPINS

Connection Identifiers:
Since Pnni is involved in Iu and Iur atmConnection establishment, two Pnni sPVC Hairpins dedicated to
Iu and Iur interfaces must be configured on the 16pOC3.
I such a way to save the 16pOC3/Stm1 FP resources, it is preferred to identify all atmConnections
configured on the Iu/Iur pnni sPvc Hairpin, with Vpi=0:
IU / IUR Pnni sPVC Hairpin
VCC: AAL Vpi VCI #

CS Ranap CP AAL5 32 to 35 4
IU CS
CS UP AAL2 0 56 to 103 48
Transport CP (Alcap) AAL5 36 to 55 20
PS CP AAL5 104 to 107 4

PS UP IpCos0 AAL5 108 1
IU PS
PS UP IpCos2 AAL5 0 110 1

UMTS OAM AAL5 112 1
IuPC AAL5 113 to 113 1
VCC RNSAP AAL5 114 to 153 40

VCC Alcap AAL5 154 to 193 40
IUR
0
VCC UP DS AAL2 194 to 213 20
VCC UP NDS AAL2 214 to 233 20
Figure 5-3 Vpi/Vci on Iu/Iur pnni sPvc Hairpin
5.1.3.2.2 IUB PNNI SPVC HAIRPINS
On the sPvc hairpins are switched not only the UP and OAM Vcc, but also the Iub CP and CCP Vcc,
therefore on the Pnni sPvc Hairpin port, new VPi/VCi naming rules, new Attributes and new
TrafficDescriptors:
ALU confidential

Page 178/198
#VCC on Iub interface: For 200 nodeBs #VCC on sPVC Hairpins:

UP VCCs = 2400 (200*(7DS+5NDS))
OAM VCCs = 200 UP VCCs = 2400 (200*(7DS+5NDS))
CP VCCs = 200 OAM VCCs = 200
CCP VCCs = 1200 CP VCCs = 200
Σ VCCs = 4000 CCP VCCs = 1200
Σ VCCs = 4000
Σ VCCs are splitted on two STM1. On each STM1, VCCs are grouped in one VP:
Moreover, per VP, 32 reserved VCCs are added. #VCC per sPVC Hairpins:
#VCC on Iub interface per STM1: 2032 Σ VCCs = 2000
RNC-AN RNC-IN
MSA 32_4 to 7
AtmIf:
E1 AESA: X1
RNC-PCM: NodeB/RNC-AN interface Destination IuxIf/1 atmMpe/x
AtmIf: Path/16 AC/y

VCC type: AAL VPI VCI # E1
AESA: Y1
UP DS AAL2 1 41 to 48 8 Destination
UP NDS AAL2 1 49 to 56 8 ... sPVC Hairpin VCCs:

UP DS VCC OAM VCC
CP AAL5 1 34 1 AtmIf:
E1 AESA: Z1
CCP AAL5 1 35 to 40 6 VCC type: AAL VPI VCI #
Destination
NodeB OAM AAL5 0 32 1 UP DS AAL2 0 34+24*(k-1) to 41+24*(k-1) 8
... UP NDS AAL2 0 42+24*(k-1) to 49+24*(k-1) 8

NodeB OAM AAL5 0 33+24*(k-1) 1
MSA 32_1
16pOC3/STM1 FP CP AAL5 0 50+24*(k-1) 1
AtmIf:
E1 CCP AAL5 0 51+24*(k-1) to 56+24*(k-1) 6
AESA: X2
Destination
AtmIf: AtmIf:
STM1
AtmIf:
E1 2
AESA: Y2
Destination
... AtmIf: AtmIf:

User side Nep
AtmIf:
E1 12
AESA: Z2
Destination AtmIf:
Netw side
Source
MSA 32_2 11
AtmIf: sPVC
E1 AESA: X3 sPVC
Destination
AtmIf: AtmIf:
STM1
AtmIf:
E1 1
AESA: Y3
Destination AtmIf:
User side
Nep
... AtmIf:
10
AtmIf:
AtmIf:
E1 AESA: Z3 Netw side Source
Destination
09
MSA 32_3
AtmIf: sPVC
E1 AESA: X7
Destination
AtmIf: AtmIf:
STM1
AtmIf:
E1 0
AESA: Y7
AtmIf:
Destination
...
AtmIf: AtmIf:
E1 AESA: Z7 Source
Destination
8
Figure 5-4 RNC1500, RNC-IN / RNC-AN interface, PNNI provisioning
5.2 FP ATTRIBUTES
5.2.1 16POC3/STM1 FP ATTRIBUTES
ALU confidential

Page 179/198
5.2.1.1 16POC3/STM1 FP ATTRIBUTE DEFINITION

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, don’t apply to AQM based
FP.
5.2.1.1.1 ATMIF CONNMAP OV ATTRIBUTES:

The objective of AtmIf ConnMap attributes is the reservation of Vci range for vcc. The Vci reservation
is done for vcc identified with Vpi = 0 on one hand and for vcc identified with a nonZero Vpi on other
hand.
The AtmIf ConnMap attributes are set per port.
AtmIf ConnMap ov Attribute list:
- ATTRIBUTE AtmIf ConnMap Ov numVccForVpiZero (nZVcc):
Reservation of the Vci range for vcc identified with a Vpi = 0.
The Vci range = [0 … (nZVcc-1)].
The value assigned to this attribute must take into account the Vci values: 0 to 31 reserved by
ITU.
The allowed values are power of 2.
The attribute range is (0 … 16384)
- ATTRIBUTE AtmIf ConnMap Ov numNonZeroVpisForVcc (nVpis):
Setting of the supported contiguous Vpi values for vcc.
The attribute range is [0, … 255] for UNI atmInterface, and [0, … 4095] for NNI atmInterface.
- ATTRIBUTE AtmIf ConnMap Ov firstNonZeroVpiForVcc (firstVpi):
Setting of the first nonZero Vpi value used for vcc.
If nVpi = 0 then this attribute is ignored.
The attribute range is [1,… 255] for UNI atmInterface, and [1,… 4095] for NNI atmInterface.
- ATTRIBUTE AtmIf ConnMap Ov numVccPerNonZeroVpi (nVcc):

Reservation of the Vci range for vcc identified with the nonZero Vpi values.
The Vci range = [0 … (nVcc-1)].
The value assigned to this attribute must take into account the Vci values: 0 to 31 reserved by
ITU.
The allowed values are power of 2.
The attribute range is (0 … 16384)
The vcc space delimited by [firstVpi, firstVpi+nVpi] is consumed by endPoint vcc, vcc
configured under VPT, and switched vcc.
The ConnMap parameter values may be illustrated as following:
ALU confidential

Page 180/198
VCI
65535
16384
2048
1024
nZVcc 511
Vpi0 VCC Space
nVcc 255 Programmable VCC space,

Vci reservation for
independant VCCs and the
32 VCCs under VPTs.
0 1 2 3 4 18 19 20 255 UNI VPI
firstVpi firstVpi+nVpi 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 5-5 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 + 2* (255 – nVpi) + nVpi * nVcc ] < 113 664
For NNI atmInterfaces:
Σport 0, …3 [ nZVcc + 2* (4095 – nVpi) + nVpi * nVcc ] < 113 664
In such a way to optimize the APC Memory usage,

When specifying the Vpi.Vci addressing scheme:
− Choice the lowest Vci values (32, …),
− Avoid gap between the chosen Vci values,
− Avoid gap between the chosen Vpi values,
ALU confidential

Page 181/198
5.2.1.1.2 LP ENG ARC OV & LP ENG ARC APC OV ATTRIBUTES:

The Lp Eng Arc ov and Lp Eng Arc Apc ov attributes provide the ability to set the FP and APC capacity
in terms of amount of atmConnections.
Lp Eng Arc ov Attribute list:

- Lp Eng Arc Ov connectionPoolCapacity (connCap)
The attribute specifies the maximum number of unspared (no APS) connectionResources.
UMTS RNC context: since all 16pOC3/Stm1 FP ports are configured with Laps, unprotected
connectionResources are used only for test purpose.
- Lp Eng Arc Ov protectedConnectionPoolCapacity (protConnCap)

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

RNC 16pOC3/Stm1 FP Capacity:
connCap + protConnCap < 29440
- Lp Eng Arc Apc Ov connectionPoolCapacity (connCap)

The attribute specifies per APC the maximum number connectionResources.
The attribute value must satisfy the rule:

Σ APC 0, …, 3 Lp Eng Arc Apc Ov connCap < connCap + protConnCap
The FP and APC connectionResources are consumed by CA attribute values.
5.2.1.1.3 ATMIF CA ATTRIBUTES:

The AtmIf CA attributes provide the ability to set the port capacity in terms of amount of
atmConnections.
Moreover atmIf CA attributes are used for setting the port atmInterfaceType.
The AtmIf CA attributes are set per port.
AtmIf CA Attribute list:
- ATTRIBUTE AtmIf CA maxVcc (vcc)
Setting of the maximum amount of vc Connections that can be configured on a port.
It encompasses both independent vcc and vcc configured under a VPT.
Vcc range: [0, …, 16384]
Associated Rule:

maxVcc < [nZVcc + (nVpis * nVcc) – 1 ]
- ATTRIBUTE AtmIf CA maxVpcs (vpcs)

ALU confidential

Page 182/198
Setting of the maximum amount of VP Connections that can be configured on a port.

- VP Switching for VPs identified with a Vpi value outside of [firstVpi, firstVpi+nVpi]
range,
- UMTS RNC: VPC port of the 2ports hairpin solution for VP trafficShaping.
Vpcs range: [0, … 4096]
Associated Rule:

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

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

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

Setting of the minimum Vci value of the autoSelected range for Vpi=0.
minVciVpiZero range: [0, … 65 535].
- UMTS RNC: PNNI sPVCs.
- ATTRIBUTE AtmIf CA maxAutoSelectedVciForVpiZero (maxVciVpiZero)
Setting of the maximum Vci value of the autoSelected range for Vpi=0.
maxVciVpiZero range: [0, … 65 535].
Associated Rule:

The VCI range delimitated by minVciVpiZero and maxVciVpiZero must be a subset
of connMap nZVcc:
maxVciVpiZero =< connMap nZVcc
ALU confidential

Page 183/198
- ATTRIBUTE AtmIf CA minAutoSelectedVciForNonZeroVpi (minVciNonZeroVpi)

Setting of the minimum Vci value of the autoSelected range for nonZeroVpi.
minVciNonZeroVpi range: [5, … 65 535].
- ATTRIBUTE AtmIf CA maxAutoSelectedVciForNonZeroVpi (maxVciNonZeroVpi)
Setting of the maximum Vci value of the autoSelected range for nonZeroVpi.
maxVciVpiZero range: [0, … 65 535].
Associated Rule:

The VCI range delimitated by minVciNonZeroVpi and maxVciNonZeroVpi must be
a subset of connMap nVcc:
maxVciNonZeroVpi =< connMap nVcc
The CA Attribute values consumed FP resources. Therefore check the APC connectionResource
UsageRate:

For each APC:
Σport 0, …3 (maxVcc + maxVpcs + (maxVpts * 2) + 1) < Apc ConnCap
It is assumed that the formula 4 is satisfied,
Remark:
- The formula 10 is valid for basicVPT, and not valid for standardVPT (StandardVPT is not
available on 16pOC3/Stm1 FP).
- ATTRIBUTE AtmIf CA maxVpiBits

Setting of the atmInterfaceType: UNI or NNI,
maxVpi = 8 for UNI, maxVpi = 12 for NNI,
Remark:
The CA attributes: minAutoSelectedVpi and maxAutoSelectedVpi are not introduced in the TEG
since not used in the RNC. The VPC space delimited by [minAutoSelectedVpi,
maxAutoSelectedVpi] is consumed by dynamic established VP Connections: SVP, PNNI
sPVP.
5.2.1.2 16POC3FP ATTRIBUTES FOR RNC1500

The two following 16pOC3FP connectivity schemes are taken into consideration for setting the RNC
1500 16pOC3FP Attributes:
ALU confidential

Page 184/198
RNC-IN
16pOC3/STM1
Iu/IuR PNNI
N/U Em 15 Em
Rec 7 Rec
user side Iu/IuR PNNI
Em 6 14 Em
APC 3
Rec Rec
APC 1
Iu/Iur sPVC Hairpin
Em 5 13 Em
Rec Rec
N/U
netw side
user side 4 12 Em
user side
Em
Rec Rec
Iu/Iur sPVC Hairpin Iub sPVC Hairpin

Em 3 11 Em
netw side Rec Rec netw side
Em 2 10 Em user side
APC 2
APC 0
Rec Rec
RNC-AN
MSA32)
Iub sPVC Hairpin

(Up to 7
NodeBs
E1 Em 1 9 Em
Rec Rec netw side
E1 Em 0 8 Em
Rec Rec N/U
Iub, PNNI
Figure 5-6 16pOC3 connectivity scheme, option1
RNC-IN
16pOC3/STM1
Em 15 Em
VPC Rec 7 Rec
Iu/Iur Shaped VPT
Em 6 14 Em
ATM VPT
APC 3
APC 1
Rec Rec
Backbone
Em 5 13 Em
VPC Rec Rec
N/U
Iub Shaped VPT user side
Em 4 12 Em
VPT
Rec Rec
Iub sPVC Hairpin

Em 3 11 Em
Rec Rec netw side
Em 2 10 Em user side
APC 0
APC 2
Rec Rec
RNC-AN
MSA32)
Iub sPVC Hairpin

(Up to 7
NodeBs
E1 Em 1 9 Em
Rec Rec netw side
E1 Em 0 8 Em
Rec Rec N/U
Iub, PNNI
Figure 5-7 16pOC3 connectivity scheme, option2
Table below summarizes 16pOC3FP Attribute values for the above 16pOC3FP connectivity schemes:
ALU confidential

Page 185/198
Iu/Iur Iu/Iur
Iu/Iur
Hairpin Hairpin N/U or
Iu/Iur Hairpin N/U Iub Iub Iub Iub
APC 0
APC 1
APC 2
APC 3
Iub sPvc or PVC or Iu/Iur Iu/IuR Iu/IuR
Iub PNNI Iub PNNI Hairpin PVC Iub Icn Hairpin Hairpin Hairpin Hairpin N/U
PNNI Iub Iu/Iur Shaped PNNI PNNI
sPvc Shaped removed sPvc PVC sPvc PVC
Shaped Shaped VPC
VPT
VPC VPT
OUTPUT: SDH0 SDH1 SDH2 SDH3 SDH4 SDH5 SDH6 SDH7 SDH8 SDH9 SDH10 SDH11 SDH12 SDH13 SDH14 SDH15
AtmIf maxVpiBits 12 12 12 8 8 8 8 8 8 8 8 8 8 8 12 12
AtmIf CA maxVccs 2402 2402 2402 536 4802 536 536 64 0 2175 2175 2175 2175 0 536 536
AtmIf CA maxVpcs 0 0 0 0 0 200 0 22 0 0 0 0 0 0 0 0
AtmIf CA maxVpts 0 0 0 0 200 0 22 0 0 0 0 0 0 0 0 0
AtmIf CA minAutoSelectedVpi 4095 4095 4095 255 255 255 255 255 255 255 255 255 255 255 4095 4095
AtmIf CA maxAutoSelectedVpi 4095 4095 4095 255 255 255 255 255 255 255 255 255 255 255 4095 4095
AtmIf CA minAutoSelectedVciForVpiZero 13981 13981 13981 1023 1023 1023 1023 1023 4095 8191 8191 8191 8191 1023 487 487
AtmIf CA maxAutoSelectedVciForVpiZero 16383 16383 16383 1023 1023 1023 1023 1023 4095 8191 8191 8191 8191 1023 1023 1023
AtmIf Ca minAutoSelectedVciForNonZeroVpi 63 63 63 63 63 63 511 63 63 63 63 63 63 63 511 511
AtmIf Ca maxAutoSelectedVciForNonZeroVpi 63 63 63 63 63 63 511 63 63 63 63 63 63 63 511 511
AtmIf ConnMap Ov numVccsForVpiZero 16384 16384 16384 1024 1024 1024 1024 1024 4096 8192 8192 8192 8192 1024 1024 1024
AtmIf ConnMap Ov numNonZeroVpisForVccs 0 0 0 0 200 0 22 0 0 0 0 0 0 0 22 22
AtmIf ConnMap Ov firstNonZeroVpiForVccs 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
AtmIf ConnMap Ov numVccsPerNonZeroVpi 64 64 64 64 64 64 512 64 64 64 64 64 64 64 512 512
Per port limitation:

numVccsForVpiZero+(numVccsPerNonZeroVpi 16384 16384 16384 1024 13824 1024 12288 1024 4096 8192 8192 8192 8192 1024 12288 12288
* numNonZeroVpisForVccs) <= 23 654
Per card limitation: sum of (maxVccs + 2403 2403 2403 537 5203 737 581 87 1 2176 2176 2176 2176 1 537 537
maxVpcs + (maxVpts * 2) + 1)
Arc Checks:
Lp Eng Arc Ov ConnectionPoolCapacity 1000
Lp Eng Arc Ov protectedConnectionPoolCapacity 28440 > 24900
Apc/0
Lp Eng Arc Apc Ov connectionPoolCapacity 8000 > 7746
Apc/1
Apc/2
Apc/3
Figure 5-8 16pOC3 Attributes for RNC1500
5.2.2 16POC3/STM1 ATM/POS FP

5.2.2.1 LP/ENG/ARC PARAMETER
The LP Eng/Arc component from the FP should be configured in such a way to offer a maximum amount
of protected atmConnections, and just a few nonProtected atmConnection available for debugging tool:

- Lp/Eng/Arc protectedConnectionPoolCapacity = 31000
- Lp/Eng/Arc connectionPoolCapacity = 1000
5.2.2.2 MBG
Case1: For each non absolute EP, an explicit MBG value is configured
Based on:
- The previous releases recommendation indicating to set an MBG=2% against the EP7,
- The QOS Information mapping table specified in the previous release,
- The default weigh assigned by the Passport to the EP for case of MBG = Priority,
- The following MBG values are suggested as default values:
Cbr rtVbr nrtVbr Ubr

EP2 EP3 EP4 EP7 Σ
MBG 77 17 4 2 100
ALU confidential

Page 186/198
Case2: For each non absolute EP, MBG value is configured with Priority.
The weigh assigned to the non absolute EP, depends on how many EP are used:
# Used Weight assigned to the non absolute EP

non absolute 1st EP 2d EP 3d EP 4th EP
EP Σ
1 100 100
2 99 1 100
3 90 9 1 100
4 77 18 4 1 100
MBG Command description:

ATTRIBUTE AtmIf Ep minimumBandwidthGuarantee (minBw)
Access Read and write
…
For 16pOC3PosAtm cards, the following description applies:
The minimum bandwidth guarantee specified is the proportion of the bandwidth which remains after all
traffic at EP 0 and EP 1 is served.
In other words, the bandwidth allocated to an EP is:
(bandwidth unused by EP 0 and 1) * minimumBandwidthGuarantee
(the sum of the minimumBandwidthGuarantees for all active EPs)
For example,
if EP 0 and EP 1 traffic consumes 20% of the link bandwidth, the minimum bandwidth
guarantee applies to the remaining 80% of the link bandwidth. Assume Ep/2, Ep/3, and Ep/4
have a minimumBandwidthGuarantee of 70, 20, and 10 respectively.
If all EPs are actively sending traffic, then the bandwidth is allocated as follows:
o EP 2 = 80% * 70/(70+20+10) = 56% of the link bandwidth
If some time later EP 3 has no traffic to send, then its share of the bandwidth is allocated
to EP 2 and EP 4 in proportion to their minimumBandwidthGuarantees as follows:
o EP 2 = 80% * 70/(70+10) = 70% of the link bandwidth
o EP 4 = 80% * 10/(70+10) = 10% of the link bandwidth
If some time later only one out the EP 2, EP 3, and EP 4 has traffic to send, then it would
be allocated the entire 80% of the link bandwidth.
Additionally, if both EP 0, and EP 1 have no traffic to send, the remaining active EP would be
allocated 100% of the link bandwidth irrespective of the value of its
minimumBandwidthGuarantee attribute.
The value priority emulates the strict precedence of emission priority by assigning default values
to the
minimumBandwidthGuarantee attribute.
Depending on how many EPs are in use in the guaranteed bandwidth range 2 through 7, these
default values change:
- For one EP, the value is 100.
- For two EPs, the values are 99, and 1.
- For three EPs, the values are 90, 9, and 1.
- For four EPs, the values are 77, 18, 4, and 1.
For all cards, when specifying a value for the minimumBandwidthGuarantee attribute, consider
the effect on cell delay variation (CDV) of traffic which would normally be of higher priority.
ALU confidential

Page 187/198
For example, if RtVbr service category traffic is assigned to Ep/2 and Ubr traffic is assigned on
Ep/7 where Ep/7 has a minimumBandwidthGuarantee of 25, there can be a large impact on the
CDV of the RtVbr traffic. Traffic of the Cbr or RtVbr service category which is sensitive to
CDV, and is of known volume, can be assigned on EP 0 or EP 1 which are independent of the
effects of minimum bandwidth guarantee.
…
Values: either Decimal (1..100) or priority
Units % / Default: priority
5.2.3 MSA32 FP ATTRIBUTES

The MSA32 FP is composed of two AQM ASIC’s, the aqm/0 in charge of the PCM links, the aqm/1 in
charge of the STM1/OC3 links.
The MSA32 and each aqm support a limited amount of atmConnections:
Rule: IubTEG_MSA32E1/Stm1 FP Attribute_01

- Lp Eng Arc Ov connectionPoolCapacity ≤ 16000
- Lp Eng Arc Aqm/0 Ov connectionPoolCapacity ≤ 8000
- Lp Eng Arc Aqm/1 Ov connectionPoolCapacity ≤ 16000
Considering the MSA32 PDH interface:

Each E1/DS1 link is configured with 5 Vcc, moreover 32 Vcc are reserved by the protocol,
implies less than 40 vcc per E1, which is configured through:
AtmIf CA maxVcc (vcc) = 40.
Beside no need for Vpc and Vpt:

AtmIf CA maxVpcs = 0 and
AtmIf CA maxVpts = 0.
A MSA32 supporting up to 30 E1/Atm, up to 30 * 40 = 1200 Vcc are then configured per

MSA32 Aqm/0:
Lp Eng Arc Aqm/0 Ov connectionPoolCapacity = 1500.
Considering the MSA32 SDH interface:

Assuming APS configured and the most restricting atm configuration: 200 NodeBs, each
configured with 24 Vcc. The 3 STM1 on the RNC-IN / RNC-AN interface should support:
[(200*24 / 2) + 32 ] = 2432 vcc:
AtmIf CA maxVcc (vcc) = 2432.
Which implies the aqm/1 capacity:

Lp Eng Arc Aqm/1 Ov connectionPoolCapacity = 2500.
Considering the global MSA32 SDH & PDH interfaces:

Whatever APS is configured or not, the Lp Eng Arc protectedConnnectionPoolCap = 0.
The atmConnections configured on a APS protected Stm1, consume resources from the
MSA32/Stm1 FP ConnCap attribute.
Case of MSA32 E1/Stm1 FP:

In such a way to be able to support enough atmConnection on PDH and SDH interfaces, the
MSA32/Stm1 may be configured with the capacity:
- Lp Eng Arc connnectionPool = 1500 + 2500 = 4000

- Lp Eng Arc protectedConnnectionPoolCap = 0
ALU confidential

Page 188/198
Case of MSA32 E1 FP (without Stm1):

In such a way to be able to support enough atmConnection on PDH interfaces, the MSA32 Fp may be
configured with the capacity:
- Lp Eng Arc connnectionPool = 1500

It is suggested to set:

On MSA32 E1/Stm1 FP:
- On PDH port: AtmIf CA maxVcc (vcc) = 40
- On SDH port: AtmIf CA maxVcc (vcc) = 2432.
- Lp Eng Arc Aqm/0 Ov connectionPoolCapacity value = 1500.

- Lp Eng Arc connnectionPoolCap = 4000

On MSA32 E1 FP (without Stm1):

- On PDH port: AtmIf CA maxVcc (vcc) = 40
- Lp Eng Arc connnectionPoolCap = 1500

5.3 AAL2
5.3.1 IUBIF / AAL2IF

Between the RNC and 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.
The migration procedure consists in assigning to IubIf and aal2If, the instance value from the IuxIf they
replace.
IubIf and aal2if instance value range:
Rule: Iu_ RNC aal2 component _3

iubIf
Interface: Values #
Iub 1 to 299 299
Iub extension 484 to 634 151
ALU confidential

Page 189/198
aal2If, no aal2 switch

Interfaces: Values #
Iub 1 to 299 299
Iub extension 484 to 634 151
Iu 300 to 309 10
Iu extension 310 to 349 40
Iu extension 374 to 483 110
Iur 350 to 373 24
5.3.2 IUXIF
This section applies up to UA4-2 not included.
Within RNC, IuxIf parameter identifies an adjacent AAL2 Node.
Therefore, Iuxif values are distributed on the 3 UTRAN interfaces, according to the following table:
IuxIf
Interfaces: Values #
Iub 1 255 255
Iu 300 331 32
Iur 350 400 50
On Iub interface, even if 255 IuxIf values are reserved on NodeB, up to 253 may be useable, since the
Iub OAM IP Subnet allows reaching of up to 253 nodeBs.
A RNC may be populated with up to 200 nodeBs, nevertheless 253 IuxIf values are reserved on Iub, to
cover case of reparenting.
5.3.3 PATHID:
A pathid value identifies an aal2 path. On Iub interface one aal2 Path is assigned to each UP aal2 vcc.
Table below indicates the suggested Pathid values to configure on Iub according to aal2If assigned to
NodeB. (The aal2If is noted k in the table).
Iub
Path QOS PATHID # Range
DS 0 (16*k) to ((16*k) - 6) 7 1
NDS 1 ((16*k) - 8) to ((16*k) - 14) 7 …
Hspa 2 ((16*k) - 15) + ((16*k) - 7) 2 4048
k = aal2If
k identifies a NodeB.
Table 5-3 Pathid values
Application:
Pathid values for k in the range [1-400]
ALU confidential

Page 190/198
k= 1 2 … 200 … 253 …
DS 10 to 16 26 to 32 … 3194 to 3200 … 4042 to 4048 …
Pathid
NDS 2 to 8 18 to 24 … 3186 to 3192 … 4034 to 4040 …
Hspa 1 & 9 17 & 25 … 3185 & 3193 … 4033 & 4041 …
5.3.4 AAL2 CAC

Configuring the AAL2 CAC consists in setting bandwidth estimation per radioBearer and per
transmission side by means of parameter: qAAL2equivalentBitrate.
Release4 values:
EBR values result from a UMTS dimensioning exercise based on Customer

UMTS User traffic Volume and Distribution (in the time).
Release3 values:
RAB Definition: AAL2 CAC:

Domain: RAB: Ebr qAAL2equivalentBitrate qAAL2equivalentBitrate
(kb/s) (Cells/s) (bits/s) multiple of 64, bits/s
In OMC in RNC-CN
DL UL: DL UL: DL UL DL UL
CS/Speech 12,2 12,2 45 48 16000 16832 250 263
CSD 14.4 14,4 14,4 44 45 15616 16000 244 250
UP DS
CSD 64 64 64 189 191 66432 67200 1038 1050

CSD 56
DedicatedSRB 3,4 3,4 14 15 5056 5440 79 85
CommonSRB 321 66 112768 23360 1112 365
UP NDS
PS I/B 64 64 198 200 69632 70400 1088 1100

PS I/B 128 64 390 200 136832 70400 2138 1100
PS I/B 384 64 1164 200 408000 70400 6375 1100
Figure 5-9 Suggested Ebr values for Release3
5.4 IMA
5.4.1 NODEB HOLDING PRIORITY

Since the bandwidthReduction mechanism is activated in the nodeB, in such a way it behaves as expected
by the RNC aal2CongestionManagement mechanism, it is recommended to configure the NodeB HP
parameter which determines in which order the vcc are released/restored.
It is distinguished two cases:

1/ the NodeB E1 or IMA linkGroup supporting both hspa and R99 traffic, and
2/ the NodeB E1 or IMA linkGroup supporting only hspa traffic.
1/ Case of NodeB E1, or IMA linkGroup shared by R99 and Hspa traffic:
Rule: IubTEG_IMA_07
ALU confidential

Page 191/198
NodeB VCC
HP
Type Instance
AAL1-CES vcc /
HSPA vcc 1
HSPA vcc 2
0
CP vcc 1
CCP vcc 1 to 6
OAM vcc 1
DS UP vcc 1 1
NDS UP vcc 1 1
DS UP vcc 2 2
NDS UP vcc 2 2
DS UP vcc 3 3
NDS UP vcc 3 3
DS UP vcc 4 4
NDS UP vcc 4 4
DS UP vcc 5 5
NDS UP vcc 5 5
DS UP vcc 6 6
NDS UP vcc 6 6
DS UP vcc 7 7
NDS UP vcc 7 7
DS UP vcc 8 8
NDS UP vcc 8 8
2/ Case of NodeB E1, or IMA linkGroup dedicated to Hspa traffic:
Rule: IubTEG_IMA_08
Case of E1 or IMA LG supporting only Hspa traffic:
NodeB VCC
HP
Type Instance
Hspa vcc 1 1
Hspa vcc 2 2
Hspa vcc 3 3
Hspa vcc 4 4
Hspa vcc 5 5
Hspa vcc 6 6
Hspa vcc 7 7
Hspa vcc 8 8
5.4.2 PASSPORT HOLDING PRIORITY

This section applies in case the IMA linkGroup terminating Point is a Passport node and the operator
decides to activate the IMA bandwidthReduction in the PassPort.
On an IMA interface delimited by a ALU NodeB and a Passport, it s recommended to activate the IMA
bandwidthReduction in the NodeB.
In a situation where the link bandwidth fluctuates within an IMA link, Passport holdingPriority parameter
is used to determine which connections are held and which are released.
- Holding priority 4 connections are the first to be released.
- Holding priority 0 connections are the last to be released
ALU confidential

Page 192/198
HoldingPriority Parameter is associated either to a serviceCategory (perQOS), or to an ATM Connection

(perVC).
Rule: IubTEG_IMA_08
Permanent ATM Connections, the holding priority of PVC’s is configurable on a per-QoS class basis
and per-connection basis.
Dynamic ATM Connection, the holding priority of SVC’s and S-PVC’s is configurable on a per-QoS
class basis, only.
Following diagram indicates where HP perQOS and HP per AtmConnection are taken into account:
PVC SPVC
IMA IMA optical

IMA
ATM switch 2 ATM switch 1 AN IN
vp, vc Dst nothing provisionnable between Src

Specific defense mechanism
But has no significance

No provisioned VC,
No provisioned VC,
No provisioned VC,
No provisioned VC,
On optical interface
so HP per CoS
so HP per CoS
so HP per CoS
so HP per CoS
No provisioned HP
HP per VC
HP per VC
(if necessary)
HP per VC – atmif/* vcc/*(vpt/* vcc/*) vcd tm hpri

HP per Cos – atmif/* ca <service category>/0 hpri
What will pass if we configure atmif/* vcc/* vcd tm hpri and ohpri attributes with different values on the interface,
where Dst is provisioned?
Remarks:
Unspecified bit rate (UBR) connections are not released, since no bandwidth is reserved for such a
VCC. A connection with a holding priority equal to zero is non-releasable.
5.4.2.1 CASE OF DYNAMIC VC (SPVC, SVC):

HoldingPriority is set in ATTRIBUTE:
AtmIf CA serviceCategory holdingPriority (hpri).
Values: 0, 1, 2, 3, 4; Default: 3
Under link failure, the svc and sPvc atm connections can be dynamically re-established to a different path
if one with sufficient bandwidth exists.
SPvc and Svc perQOS HP setting:

Summary of vcc SC on the Iub interface, and the suggested HoldingPriority value per serviceCategory:
ALU confidential

Page 193/198
Rule: Iub_IMA_09
VCC ServiceCategory HoldingPriority
AAL1-CES CBR 2
UP DS
CP rtVBR 0
CCP
UP NDS nrtVBR 1
HSDPA
UBR 0
OAM
Table 5-4 perQos HoldingPriority values
An UBR VCC doesn’t reserve any bandwidth.

Even if no bandwidth is reserved for the UBR atmConnection, a holding priority value is assigned against
such an atmConnection. It does not do anything, but to be on safe side, set it up to the highest holding
priority (0) such that OAM vcc are not released.
On this way, when bandwidth reduction occurs, first are released nrtVBR vcc that means UP NDS VCC,
and later if necessary rtVBR vcc that means UP DS, CP and CCP vcc (in case of no CES vcc on the IMA
interface).
The target is to keep alive the longest, the vcc which carried signaling:
- NonAccessStratum signaling within UP DS vcc, and
- AccessStratum signaling within CP and CCP vcc.
Moreover, on PNNI sPvc source and Destination component, per atmConnection HP is set with same
values as for case of Permanent VC.
5.4.2.2 CASE OF PERMANENT VC (PVC):

HoldingPriority is set in ATTRIBUTE:
AtmIf Vcc Vcd Tm holdingPriority (hpri), and
AtmIf CA holdingPriority (hpri).
Values: 0, 1, 2, 3, 4; Default: 2
PerQOS HoldingPriority is set as for Dynamic ATM Connection. Moreover perVC HoldingPriority is
available.
PVC, perVC HoldingPriority setting:
Rule: IubTEG_IMA_10
VCC HoldingPriority
AAL1-CES
HSDPA
0
CP & CCP
OAM
DS UP VCC1 & 5 1
DS UP VCC2 & 6 2
DS UP VCC3 & 7 3
DS UP VCC4 & 8 4
NDS UP VCC1 & 5 1
NDS UP VCC2 & 6 2
NDS UP VCC3 & 7 3
NDS UP VCC4 4
ALU confidential

Page 194/198
Table 5-5 perVC HoldingPriority values
5.4.3 IMA LINKGROUP ID:

In the IMA protocol called ICP, the identifier of the IMA LinkGroup is carried in IMA ID field.
On Passport MSA32 FP side:

When configuring IMA in the Passport, LP/IMA, an IMA instance is provisioned.
The IMA instance is in the range 0-29 for the MSA32.
On the MSA32 FP, the ports involved in an IMA linkGroup must be in the range [0 – 15], or in
the range [16 – 31], mixed is not allowed.
The instance number of an IMA group must be in the same sub-range as all of its ports:
Rule: IubTEG_IMA_11
IMA group Id = miniPortNumber in this IMA linkGroup.
In the Passport implementation, the IMA ID ICP field is set equal to the Component IMA
instance number.
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 VCC’s (0 = multi PCM)
- Set VCC_externalPortId to 0 (= IMA group number) for all VCC’s.
5.4.4 TRAFFIC DESCRIPTOR

On Passport node, IMA interface, CP and CCP VCC trafficDescriptors are set in such a way ECR=0.
ECR=0 is obtained when setting PCR=SCR=MBS=0.
Passport doesn’t allow to configure PCR=SCR=MBS=0 with TDT = 6 (TrafficDescriptorType).
Therefore:
Rule: Iub_IMA_12
TDT = 1 is set for CP and CCP VCC. CP and CCP serviceCategory remains unchanged.
5.5 TRAFFIC CONTRACT
5.5.1 IUB TRAFFIC DESCRIPTOR, RELEASE 4

The determination of TrafficDescriptor values is the result of an UMTS Dimensioning study, therefore
not described in this document.
The VCC/VPC TrafficDescriptor parameters are set according to the expected volume and shape UMTS
traffic carried on this VCC/VPC.
The TrafficDescriptor values are provided by an Excel Dimensioning tool which calculates bandwidth
per UMTS flow based on UMTS Customer expected traffic.
ALU confidential

Page 195/198
5.6 PARAMETERS
The aim of this section is to provide a complement of information on some Transport parameters.
5.6.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.
TDT SC TD parameters to set
3 CBR PCR, CDVT
6 VBR PCR, SCR, MBS
1 UBR No TD Parameter
5.6.2 PARAMETER CLASS

Parameters are described in NTP and UPUG documents. Target of this section is to bring some
additional information on some parameters.
Class of parameter:
− Class 0: the NE must be restarted to take into account a new parameter value.
− Class 2: the parameter can be changed on-line provided that the object (or its parent
object) is locked.
− Class 3: the parameter can be changed on-line without impact on the service. The new
value is taken into account either immediately or for new calls only.
− Operator : the parameter is configurable from the OMC and seen by the operator
− Manufacturer : the parameter is configurable from the OMC and only seen by ALU
engineering teams
ALU confidential

Page 196/198
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

Page 197/198
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

Page 198/198

Iub Transport Engineering GuideUMT IRC APP 007149 V06.02

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Iub Transport Engineering GuideUMT IRC APP 007149 V06.02

Загружено:

Авторское право:

Доступные форматы

Iub Transport Engineering Guide

Document number: UMT/IRC/APP/7149

Author: Philippe DELMAS

Copyright 2007 Alcatel-Lucent, All Rights Reserved

ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of

6-2 5-1 25/09/07 § 3.7.11: Icn: removed

6-1 06/09/07 §3.7.9+4.1.8: FRS34012 Iur Hsdpa taken into consideration by

10/07/07 - §3.8.1.1 NodeB CEM upd

10/11/06 - FRS 33767: Iub over protected atm ring,

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

§4.4.1: Hsdpa upd.

4.1 4-0 26/11/04 §3 SDH OAM flow renaming, and update,

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

3.8.4 ATM Connections:.......................................................................................................143

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

4.6.1 UMTS HSUPA Plane: .................................................................................................197

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

1.2 SCOPE OF THIS DOCUMENT

RNC Release: UA3 UA4.0 UA4.1 UA4.2 UA5.0

CS CoreNetwork NSS16 NSS16, NSS18 and NSS19

PS CoreNetwork PC03 PC04 PC05

OAM Release: OAM3 OAM4.1 OAM4.2 OAM5.0

This document covers:

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

1.3 AUDIENCE FOR THIS DOCUMENT

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

[ R 80 ] GR253 Synchronous Optical Network (SONET)

[ R 150 ] FRS 25647 aal2LinkCac evolution

3 IUB TRANSPORT NETWORK LAYER,

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

This document covers the Transport Network layers.

Control Plane O&M User Plane

Figure 3-1IUB Protocol stack

Remark: ALCAP is not implemented on ALU UMTS Iub nodes.

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

Therefore the T1 throughput is 1,544 Mb/s = 3622 cellules per second.

3.1.1.1.1 ATM ON T1:

193 bits/125 µsec

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

Provides F3 OAM functions: ATM Header

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:

On T1 is configured as an option CRC.

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

Within the 24 F bits of a T1 multiframe, 6 bits are reserved for CRC.

T3 ATM throughput is 104 268 Cells/s.

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

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

X1 F1 C11 F2 C12 F3 C13 F4

Figure 3-2 T3 multiframe structure

Overhead bits functions:

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

- P1 = P2 = 0 if the digital sum of all payload bits is zero.

The multiframe alignment signal 010 (M1 = 0, M2 = 1, M3 = 0) is used to locate all

The M-subframe alignment signal 1001 (F1 = 1, F2 = 0, F3 = 0, F4 = 1) is used to

Either used for bit Parity, or bit stuffing.

− Alarm Indication Signal (AIS):

− Idle Signal (Idle):

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007

3.1.2.2 TRANSMISSION OAM

Carries Maintenance and Status signals related to SDH RegeneratorSection / SONET

UMT/IRC/APP/7149 06.02 / EN Standard 02/12/2007