umt irc app 007149 iub teg ua6 external std ed7-2 std 090629

Upload: erlinda-melicado

Post on 06-Jan-2016

225 views

Category:

Documents


0 download

DESCRIPTION

exter

TRANSCRIPT

  • Iub Transport Engineering Guide Document number: UMT/IRC/APP/7149 Document issue: 07.02 / EN Document status: Standard Date: 29/06/2009

    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

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 3/263

    PUBLICATION HISTORY External

    Edition UMTS

    Release: Date ReasonsForChange

    7-2 29/06/09 3.6.2.1.3: add the qos mapping table for the 16pOC3 PQC FP 3.8.7.2+5.5.1.3: Modification: sharedForTrafficType qos3 vcc HP=0 to HP=1. Standard

    26/01/09 3.6.2.2.3: upd, 16pOC3 MS3 FP ECMP. 3.6.10.5.1: upd, asym traffic with 1 bwPool.

    7-1

    02/12/08 - 3.7.7: Change, deadInterval reduced to 3 seconds - 3.12 7670: add - 3.5: topology update - 3.6.10 &3.7.10: upd, transport AC - 3.6.6 aal2Qos: add - 3.2.10 maxDiffDelay: upd - 3.6.9 updated

    26/08/08 - Preliminary Edition. - CM: qosDiscardThreshold formula update,

    7-0

    UA6

    26/06/08 - FRS 23479 Advanced QoS Transport Framework, - FRS 28018 Iub Alcap, - FRS 29869 RNC Dimensioning, - FRS 33334 & 33365 Iub Hybrid, - FRS 33334 NodeB Hybrid, - FRS 34105 UtranSharing, - FRS 34202 BwPool, - FRS 34237 RateController, - FRS 34682 NodeB IMA Defence. -

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

    5-1

    18/07/07 Add 3.7.9.1.4 1 IMA and 2 bwPool . Updated with CR: - upd of 5 with several hspa vci .

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 4/263

    10/07/07 - 3.8.1.1 NodeB CEM upd - Nodeb ima defense update for IMA Hspa. - FRS 33118: nE1 & 1 IMA over iCCM, - FRS 33865, - FRS 34094: Hspa over xPcm - FRS 31830: 2 IMA groups on xCCM, - picoNodeB updates.

    22/01/07 - MicroNodeB: updates based on tests.

    10/01/07 - Hsupa, modification: one single dSRB per hsupa-hsdpa

    session, - Hsupa: the xCEM card removed, - NodeB & RNC Hspa CAC corrections.

    10/11/06 - FRS 33767: Iub over protected atm ring, - FRS 26376: Insertion of picoNodeB atm, - FRS 33865: NodeB nE1 & 1 IMA linkGroup. -

    5-0 5-0

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

    &

    3

    26/11/04 3 SDH OAM flow renaming, and update, 3 ATM IMA: fallback information update, 3 ATM OAM:

    AIS trigger update, LoopBack comments added,

    5, 16pOC3 attributes: update 3.8, NodeB CRC4 added

    4.0 4-0 01/08/04 Review UA 4-1, 25/07/04

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 5/263

    &

    3

    Removal of Iub TrafficDescriptor values. UA 4-1 Update: 3.7: MSA SparingPanel added

    SS MSA32 FP added 2pStm1 e Ch FP added 2pOC3 FP added 3&4&5: RNC1500 information.

    3.3.6.3: TS update: isolate OAM VCC from VPC. 3.3.12.3: ATM LoopBack modification. 3.4: InverseARP added 5-4 Add PCR value for OAM VCC, case of no TrafficShaping on NodeB. 3.3.11.5.2 add NodeB IMA bandwidthReduction parameters

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 6/263

    CONTENTS

    1 INTRODUCTION............................................................................................................................9 1.1 OBJECT....................................................................................................................................9 1.2 SCOPE OF THIS DOCUMENT .......................................................................................................9 1.3 AUDIENCE FOR THIS DOCUMENT ................................................................................................9

    2 RELATED DOCUMENTS ............................................................................................................10 3 IUB TRANSPORT NETWORK LAYER, DESCRIPTION............................................................12

    3.1 TRANSMISSION .......................................................................................................................13 3.1.1 PDH:..............................................................................................................................13 3.1.2 SDH/SONET: ................................................................................................................17

    3.2 ATM ......................................................................................................................................24 3.2.1 ATM interface Type.......................................................................................................24 3.2.2 VPC, VPT ......................................................................................................................25 3.2.3 OverSubscription...........................................................................................................31 3.2.4 CAC...............................................................................................................................31 3.2.5 Traffic Management ......................................................................................................33 3.2.6 QOS ..............................................................................................................................38 3.2.7 Fractional E1/T1............................................................................................................47 3.2.8 Addressing ....................................................................................................................52 3.2.9 PNNI..............................................................................................................................52 3.2.10 IMA ...............................................................................................................................56 3.2.11 ATM OAM......................................................................................................................61

    3.3 AAL2.....................................................................................................................................69 3.3.1 Addressing ....................................................................................................................69 3.3.2 Alcap .............................................................................................................................69

    3.4 IP ..........................................................................................................................................71 3.4.1 InverseARP ...................................................................................................................71 3.4.2 SiteLAN .........................................................................................................................73

    3.5 IUB TOPOLOGY .......................................................................................................................73 3.5.1 ATM Backbone:.............................................................................................................75 3.5.2 Atm ring on Iub ..............................................................................................................75 3.5.3 SDH ring........................................................................................................................76 3.5.4 Hybrid UTRAN...............................................................................................................77 3.5.5 Ethernet topology ..........................................................................................................78

    3.6 RNC ATM .............................................................................................................................79 3.6.1 ASIC ..............................................................................................................................79 3.6.2 FP..................................................................................................................................80 3.6.3 RNC capacity ..............................................................................................................105 3.6.4 Aal2 Components:.......................................................................................................106 3.6.5 Aal2 Paths ...................................................................................................................113 3.6.6 Aal2 QOS ....................................................................................................................114 3.6.7 aal5 connections .........................................................................................................114 3.6.8 QOS ............................................................................................................................115 3.6.9 TransportMap..............................................................................................................117 3.6.10 Transport admission Control .......................................................................................124 3.6.11 Congestion Management bandwidth Limitation a.k.a rate Control .............................137 3.6.13 NodeB discrimination ..................................................................................................143 3.6.14 Alcap ...........................................................................................................................144 3.6.15 Utran Sharing ..............................................................................................................147 3.6.16 PNNI Hairpin removal .................................................................................................149

    3.7 RNC HYBRID........................................................................................................................150 3.7.1 FP................................................................................................................................150 3.7.2 RNC capacity ..............................................................................................................156 3.7.3 IP Components............................................................................................................157 3.7.4 Virtual Router RNC composition .................................................................................163 3.7.5 LocalMedia ..................................................................................................................165

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 7/263

    3.7.6 PDR.............................................................................................................................168 3.7.7 ICMP HeartBeat ..........................................................................................................172 3.7.8 QOS ............................................................................................................................174 3.7.9 TransportMap..............................................................................................................176 3.7.10 Transport admission Control .......................................................................................179 3.7.11 CongestionManagement bandwidth Limitation a.k.a rate Control ..............................183 3.7.12 Routing: .......................................................................................................................190 3.7.13 NodeB discrimination ..................................................................................................190 3.7.14 Utran Sharing ..............................................................................................................191

    3.8 NODE B (IBTS).....................................................................................................................191 3.8.1 Cards...........................................................................................................................191 3.8.2 PDH Layer:..................................................................................................................193 3.8.3 Ethernet Layer:............................................................................................................194 3.8.4 Synchronisation...........................................................................................................194 3.8.5 ATM Connections:.......................................................................................................194 3.8.6 MultiPCM.....................................................................................................................195 3.8.7 IMA ..............................................................................................................................196 3.8.8 Mix of N * E1 xPCM and p E1 IMA..............................................................................198 3.8.9 IP .................................................................................................................................199 3.8.10 QOS ............................................................................................................................200 3.8.11 Traffic Management ....................................................................................................202 3.8.12 Hspa CAC ...................................................................................................................204 3.8.13 Alcap ...........................................................................................................................204

    3.9 NODEB (ONEBTS)................................................................................................................205 3.9.1 Alcap ...........................................................................................................................205

    3.10 MICRO NODEB ATM (BTS 1120) ...........................................................................................205 3.10.1 Transmission: ..............................................................................................................205 3.10.2 Atm: .............................................................................................................................206 3.10.3 Aal2 .............................................................................................................................208 3.10.4 SAAL: ..........................................................................................................................208 3.10.5 IP: ................................................................................................................................209 3.10.6 UMTS traffic flows: ......................................................................................................210

    3.11 PICO NODEB ATM (BTS 1010)...............................................................................................211 3.11.1 Transmission: ..............................................................................................................211 3.11.2 Atm: .............................................................................................................................211 3.11.3 Aal2: ............................................................................................................................212 3.11.4 IP: ................................................................................................................................212 3.11.5 UMTS traffic flows: ......................................................................................................213

    3.12 7670....................................................................................................................................213 3.13 UMTS PLANE DESCRIPTION ..................................................................................................214

    3.13.1 HSUPA Plane..............................................................................................................214 3.13.2 HSDPA Plane..............................................................................................................216 3.13.3 OAM Plane ..................................................................................................................218 3.13.4 Control Plane...............................................................................................................225 3.13.5 User plane ...................................................................................................................226 3.13.6 ATM Backbone Requirements ....................................................................................227

    4 UMTS RELEASES.....................................................................................................................228 4.1 RNC....................................................................................................................................228

    4.1.1 FP................................................................................................................................228 4.1.2 RNC Types:.................................................................................................................230 4.1.3 RNC capacity: .............................................................................................................230 4.1.4 Iuxif / IubIf / aal2If: .......................................................................................................230 4.1.5 Pathid: .........................................................................................................................230 4.1.6 Aal2 Path assignment to PMC-PC..............................................................................231 4.1.7 AAL2 Link CAC: ..........................................................................................................231 4.1.8 aal2CongestionManagement ......................................................................................232 4.1.9 Icn VCC .......................................................................................................................232 4.1.10 TMU.............................................................................................................................232 4.1.11 QOS ............................................................................................................................233

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 8/263

    4.2 NODEB ................................................................................................................................233 4.2.1 CCM related: ...............................................................................................................233 4.2.2 CEM related: ...............................................................................................................233 4.2.3 MultiPCM:....................................................................................................................233 4.2.4 IMA: .............................................................................................................................234 4.2.5 n E1 xPCM + p E1 IMA: ..............................................................................................235 4.2.6 AAL1 CES ...................................................................................................................235 4.2.7 QOS ............................................................................................................................235 4.2.8 Traffic Management ....................................................................................................236

    4.3 MICRO NODEB .....................................................................................................................237 4.4 PICO NODEB........................................................................................................................237 4.5 PLANE RELATIVE ...................................................................................................................237

    4.5.1 UMTS HSUPA Plane: .................................................................................................237 4.5.2 UMTS HSDPA Plane: .................................................................................................237 4.5.3 UMTS OAM Plane:......................................................................................................237 4.5.4 UMTS Control Plane: ..................................................................................................238 4.5.5 UMTS User Plane .......................................................................................................238 4.5.6 Transport Network ControlPlane:................................................................................238

    5 TRANSPORT IDENTIFIERS .....................................................................................................238 5.1 ATM VCC............................................................................................................................240

    5.1.1 UpGrade from UA5 to UA6 .........................................................................................240 5.1.2 NodeB interface ..........................................................................................................242 5.1.3 RNC Interface..............................................................................................................244 5.1.4 PNNI............................................................................................................................249

    5.2 FP ATTRIBUTES....................................................................................................................250 5.2.1 16pOC3/Stm1 FP Attributes........................................................................................250 5.2.2 16pOC3/Stm1 MS3 (Atm/Pos) FP ..............................................................................254

    5.3 IP ........................................................................................................................................254 5.4 AAL2...................................................................................................................................254

    5.4.1 IubIf / aal2If..................................................................................................................254 5.4.2 Pathid: .........................................................................................................................255

    5.5 IMA .....................................................................................................................................256 5.5.1 NodeB Holding Priority................................................................................................256 5.5.2 IMA LinkGroup ID:.......................................................................................................258 5.5.3 Traffic descriptor .........................................................................................................258

    5.6 TRAFFIC DESCRIPTOR...........................................................................................................258 5.6.1 Aal2 vcc TD.................................................................................................................259 5.6.2 Aal5 vcc TD.................................................................................................................260

    5.7 PARAMETERS .......................................................................................................................260 5.7.1 Traffic Descriptor Type................................................................................................260 5.7.2 Parameter Class .........................................................................................................260

    6 ABBREVIATIONS......................................................................................................................262

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 9/263

    1 INTRODUCTION

    1.1 OBJECT This document intends to describe the Transport layers on the Iub interface. It also provides:

    - Engineering rules inserted in a red square, - Configuration of UMTS Node Transport interfaces, - Traffic parameters over Iub interface.

    1.2 SCOPE OF THIS DOCUMENT

    The document is related to the release: UA6 GlobalMarket The variations between the releases are indicated in section 4.

    UTRAN Release: UA 4-1 UA 5-0 UA 5-1 Passport Release: PCR6-1 PCR7-2 PCR8-2 OAM Release: OAM4.2 OAM5.0 OAM5.0

    This document covers: - TRANSPORT network layers (Transmission, ATM, aal2, aal5, Alcap, IP, ) relative to the Iub

    interface, - UMTS Nodes: NodeB and RNC. OtherVendor equipments are not covered in this document. - Impact of backhaul on the UTRAN node interfaces.

    1.3 AUDIENCE FOR THIS DOCUMENT

    The operators, R&D, WPS, VO, Trial, networkDesign.

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 10/263

    2 RELATED DOCUMENTS

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 11/263

    [ R 1 ] UMT/IRC/APP/7149 Iub TEG [ R 2 ] UMT/IRC/APP/011674 Iu TEG[ R 3 ] UMT/IRC/APP/12509 Iur TEG[ R 4 ] Addressing TEG[ R 5 ][ R 6 ][ R 7 ][ R 8 ][ R 9 ][ 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 21 ] 3GPP TS 25.309 Rel6 FDD Enhancement Uplink, overall description, stage 2 (Release 6)[ R 22 ][ R 23 ][ R 24 ][ R 25 ] G702 PDH, Digital Hierarchy Bit Rates[ R 26 ] G703 PDH, Physical/Electrical Characteristics of Hierarchical Digital interfaces[ R 27 ] G707 Network node interface for the SDH[ R 28 ] G804 ATM cell mapping into PDH[ R 29 ] G700 to 706 MTP NarrowBand[ R 30 ] Q711 to Q 714 SCCP[ R 31 ] G832 Transport of SDH element on PDH network[ R 32 ] G783 Characteristics of SDH equipments[ R 33 ] G841 Types & Characteristics of SDH Network Protection Architectures[ R 34 ] G775 LOS and AIS defect detection and clearance criteria[ R 35 ] I361 Specification of ATM layer for B-ISDN.[ R 36 ] I610 OAM for broadband ISDN[ R 37 ] I363-1 AAL1[ R 38 ] I363-2 AAL2[ R 39 ] I363-5 AAL5[ R 40 ] I732 Functional Characteristics of ATM Equipment[ R 41 ] I761 IMA[ R 42 ] I762 ATM over fractional physical link[ R 43 ] Q2210 MTP3 functions & messages using the services of Q2140[ R 44 ] Q2931 B-ISDN[ R 45 ] Q2630.1 Aal2 Signaling, capabilitySet1[ R 46 ] Q2630.2 Aal2 Signaling, capabilitySet2[ R 47 ] E191 B-ISDN numbering & addressing[ R 48 ] X213 Addresses[ R 49 ] Q2941.2 GIT[ R 50 ] Q1970 and 1990 Nb interface info[ R 51 ] Q.1950 Specifications of signaling related to Bearer Independent Call Control (BICC)[ R 52 ] Q.765.5 Application transport mechanism: Bearer Independent Call Control (BICC) [ R 53 ] Q.2150.1[ R 54 ] G711 PCM of Voice Frequencies[ R 55 ] atmf 0055.000 PNNI version 1.0[ R 56 ] af-phy-0086.000 IMA v1-0[ R 57 ] af-phy-0086.001 IMA v1-1.[ R 58 ] af-phy-0130.00 ATM on fractional E1/T1.[ R 59 ] af-ra-0105.000 Addressing, userGuide. V1.0[ R 60 ] af-tm-0121.000 TrafficManagement Specification.[ R 61 ] af-vtoa-0078.000 AAL1[ R 62 ] af-cs-0173.000 Domain based rerouting[ R 63 ] af-vtoa-0113.000 Atm Trunking using Aal2 for narrowband Services[ R 64 ][ R 65 ] RFC 1541 DHCP[ R 66 ] RFC 2225 IP & ARP over ATM[ R 67 ] RFC 1629 Guideline for OSI NSAP allocation in internet[ R 68 ] RFC1293 InverseARP[ R 69 ] RFC826 ARP[ R 70 ] RFC1485 IP over ATM[ R 71 ] RFC1483 IP over AAL5[ R 72 ] RFC2991 ECMP[ R 73 ] RFC 3331 SS7 MTP2 User Adaptation (M2UA) Layer[ R 74 ] RFC 3332 SS7 MTP3 User Adaptation (M3UA) Layer[ R 75 ] RFC 2960 SCTP, Stream Control Transmission Protocol[ R 76 ] RFC 3309 SCTP, Stream Control Transmission Protocol[ R 77 ][ R 78 ][ R 79 ]

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 12/263

    [ R 80 ] GR253 Synchronous Optical Network (SONET)[ R 81 ] GR2878 ATM HSL[ R 82 ][ R 83 ][ R 84 ][ R 85 ][ R 86 ][ R 87 ][ R 88 ][ R 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 ] 241-5701-702 NTP Routing and Signaling[ R 95 ][ R 96 ][ R 97 ][ R 98 ][ R 99 ][ R 100 ] UMT/IRC/APP/007147 PEI NodeB[ R 101 ] UMT/IRC/APP/7146 PEI RNC[ R 102 ][ R 103 ][ R 104 ] UMT/DCL/DD/0020 UPUG[ R 105 ][ R 106 ][ R 107 ][ R 108 ][ R 109 ][ R 110 ][ R 111 ][ R 112 ][ R 113 ][ R 114 ][ R 115 ][ R 116 ][ R 117 ][ R 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[ R 151 ] FRS 33767 Iub over protected atm ring

    [ R 160 ] UMT_SYS_DD_023235 UA6_Bandwidth_Pools_FN[ R 161 ] UMT/Sys/DD/023092 Hybrid Iub FN

    3 IUB TRANSPORT NETWORK LAYER, DESCRIPTION

    The IP interface is optional on the Iub interface. If present, the IP interface can be used only for HSPA Interactive and Background traffic. The ATM interface is used for transmitting the Signaling, oam, R99, Hspa Streaming and as an option the HSPA Interactive and Background traffic.

    On the ATM interface, two different atm adaptation layers are implemented [R60, R61]: - AAL5 format is used for signalings and oam:

    - NBAP common & dedicated, - ALCAP, - UMTS and ATM OAM flows.

    - AAL2 format is used for userPlane: - User traffic (Voice and Data), - NonAccessStratum signalings.

    The nonAccessStratum signaling encompasses the RRC protocols: - MM: Mobility Management, - SM: Session Management,

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 13/263

    - CC: Call Control, - GMM: GPRS Mobility Management...

    The SM, MM, GMM and CC non Access Stratum signaling exchanged between the UE and the Core Network are seen as User data from the Transport network. Such information, are carried in following channels:

    - Common SRB (SignallingRadioBearer): FACH, PCH and RACH - Dedicated SRB.

    On the IP interface, the UDP protocol is implemented.

    This document covers the Transport Network layers.

    UPUPTransport CP

    EthernetEthernetIPIP

    UDPUDP

    FPFP

    ATMATMAAL2AAL2

    FPFP

    AAL5AAL5

    NBAPNBAP

    SSCF-UNISSCF-UNI

    SSCOPSSCOP

    Q2150.2Q2150.2

    Q2630.2Q2630.2

    umts CP(R99 & Hspa Str) (Hspa I/B)

    RNL

    TNL

    OAM applOAM appl

    LLC/SNAPLLC/SNAP

    IPIPTCPTCP

    OAM

    Iub TEG

    UPUPTransport CP

    EthernetEthernetIPIP

    UDPUDP

    FPFP

    ATMATMAAL2AAL2

    FPFP

    AAL5AAL5

    NBAPNBAP

    SSCF-UNISSCF-UNI

    SSCOPSSCOP

    Q2150.2Q2150.2

    Q2630.2Q2630.2

    umts CP(R99 & Hspa Str) (Hspa I/B)

    RNL

    TNL

    OAM applOAM appl

    LLC/SNAPLLC/SNAP

    IPIPTCPTCP

    OAM UPUPTransport CP

    EthernetEthernetIPIP

    UDPUDP

    FPFP

    ATMATMAAL2AAL2

    FPFP

    AAL5AAL5

    NBAPNBAP

    SSCF-UNISSCF-UNI

    SSCOPSSCOP

    Q2150.2Q2150.2

    Q2630.2Q2630.2

    umts CP(R99 & Hspa Str) (Hspa I/B)

    RNL

    TNL

    OAM applOAM appl

    LLC/SNAPLLC/SNAP

    IPIPTCPTCP

    OAM

    Iub TEG

    Figure 3-1, IUB Protocol stack

    3.1 TRANSMISSION

    3.1.1 PDH: Different kinds of PDH links are specified either at ITU or at ANSI.

    - ITU PDH links: - E1, 2048 kbit/s, - E2, 8448 kbit/s, multiplex of 4 E1, - E3, 34368 kbit/s, multiplex of 4 E2, - E4, 139264 kbit/s, multiplex of 4 E3, or - E5, 564992 kbit/s, multiplex of 4 E4.

    - ANSI PDH links : - T1, 1544 kbit/s, - T2, 6312 kbit/s, multiplex of 4 T1, - T3, 44736 kbit/s, multiplex of 7 T2,

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 14/263

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

    3.1.1.1 T1 LINK: T1 frame is 193 bits length. The frame repetition rate is 125s. Therefore the T1 throughput is 1,544 Mb/s = 3622 cellules per second. The T1 frame is split in:

    - 1 bit, first bit of the frame, called F bit, dedicated to synchronisation, it is set to 1 for odd frame, and to 0 for even frame, followed by

    - 24 timeSlots, 64 kb/s throughput each when configured with ATM.

    Remarks: MSA32 FP doesnt manage T1 links.

    3.1.1.1.1 ATM ON T1:

    ATM cells are mapped into bits 2 to 193 (i.e. time slots 1 to 24 described) of the 1544 kbits/s frame with the byte structure of the cell aligned with the byte structure of the frame:

    T1302260-93

    FFFFFF

    Header

    Header

    Header

    Header

    193 bits/125 sec

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

    ATMcell

    53 octets

    Provides F3 OAM functions: Detection of loss of frame alignment Performance monitoring (CRC-6) Transmission of FERF and LOC 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].

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 15/263

    3.1.1.1.2 CRC:

    On T1 is configured as an option CRC. CRC6 is specified for T1 Signal. A T1 multiframe is composed of 24 T1 frames. Within the 24 F bits of a T1 multiframe, 6 bits are reserved for CRC.

    3.1.1.2 T3 LINK: T3 link is resulting from the multiplexing of seven T2 tributaries. T3 throughput is 44 736 kbits/s = 7 * 6312 kb/s + second stage multiplexing Overhead.

    There are two formats for T3, T3 signal may be either Channelized or unchannelized: - Channelized means that T3 signal results from the two stages multiplexing:

    T3 = 7 * T2 and T2 = 4 * T1. A Channelized T3 is the result of the multiplexing of 28 DS1 links. A Channelized T3 is composed of 7 * 4 * 24 = 672 timeSlots.

    - Unchannelized means that T3 payload is filled with bulk data, either cell direct mapping or PLCP based. Only Channelized T3 is defined in this section, since unchannelized are not used in UMTS network.

    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.

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 16/263

    X1 F1 C11 F2 C12 F3 C13 F4X2 F1 C21 F2 C22 F3 C23 F4P1 F1 C31 F2 C32 F3 C33 F4P2 F1 C41 F2 C42 F3 C43 F4M1 F1 C51 F2 C52 F3 C53 F4M2 F1 C61 F2 C62 F3 C63 F4M3 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):

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 17/263

    Idle Signal consists in setting information bits are set to a 1100... sequence, starting with a binary one (1) after each M-bit, F-bit, X-bit, and C-bit. The C-bits are set to binary zero (C1 = 0, C2 = 0, C3 = 0), in the third M-subframe (C31, C32, C33); the remaining C-Bits (three C-bits in M-subframes 1, 2, 4, 5, 6, and 7) may be individually set to one or zero, and may vary with time. The X-bits are set to binary one (X1 = 1, X2 = 1).

    3.1.2 SDH/SONET: Reference: [R50, 51, 40, 110]. SONET is recommended by ANSI, whereas SDH is recommended by ITU. Difference between SDH and SONET:

    Frame field terminology,

    Minor differences in the application of certain overhead bytes, level of detail beyond the scope of this document.

    3.1.2.1 THROUGHPUT Two levels of SDH/SONET signals are used within UMTS network. These levels and associated throughputs are presented in the following table:

    SDH Level SONET Level Throughput Throughput User in Mb/s Throughput

    User in Cells/s STM1

    ClearChannel STS3 = OC3 Concatenated 155,52 Mb/s 149,76 Mb/s 353 207

    STM4 STS12 = OC12 622,08 Mb/s 1 412 828

    Notation: - STM-n stands for SynchronousTransfertModule level n. It identifies the level of SDH

    signal.

    - STS-n stands for SynchronousTransfertSignal level n. Electrical specification for signal generation level.

    - OC-n stands for OpticalCarrier level n: Optical specification for signal generation level.

    3.1.2.2 TRANSMISSION OAM Severe problems in signal transmission are notified by means of Maintenance Signals and Status Signals. Maintenance signals are resulting from problem detected on the incoming SDH/SONET signal.

    At Transmission layer are defined four levels of OAM Flows. These OAM flows carry Maintenance and Status signals related to different SDH/SONET sections:

    - Regenerator Section OAM flow:

    Carries Maintenance and Status signals related to SDH RegeneratorSection / SONET Section.

    - Multiplex Section OAM flow:

    Carries Maintenance and Status signals related to SDH MultiplexSection / SONET Line. - LowOrder Section OAM flow:

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 18/263

    Carries Maintenance and Status signals related to SDH lowOrder PathSection / SONET Path.

    - HighOrder Section OAM flow:

    Carries Maintenance and Status signals related to SDH highOrder PathSection / SONET Path.

    The mechanisms to provide OAM functions and to generate Transmission OAM flows depend on the transport mechanism of the transmission system as well as on the supervision functions contained within the physical layer termination functions of equipments. Three types of transmission can be provided in ATM networks:

    - SDH-based transmission systems;

    - PDH-based transmission systems.

    - Cell-based transmission systems;

    Rule: TEG_SDH_OAM_1

    On ALU nodes, the OAM Flow Type of Transmission implemented is SDH/PDH based. Not Cell based.

    The following transmission status event may be detected: - LOS (Loss Of Signal): disconnection, idle signal, unequipped signal [R53, R110].

    An LOS defect is detected when an all-zeros pattern on the incoming SDH/SONET signal lasts 100 s or longer. If an all-zeros pattern lasts 2.3 s or less, an LOS defect is not detected. The 16-port OC-3 function processor does not monitor signal level for loss.

    - LOF (Loss Of Frame): An SEF (Severely Errored Framing) condition is detected when the incoming signal has a minimum of four consecutive errored RSOH A1-A2 framing patterns. A LOF defect is triggered when an SEF condition persists for 3 ms.

    The following Maintenance signals may be generated on different kinds of transmission OAM levels: - AIS (Alarm Indication Signal):

    AIS signal notifies the adjacent downstream node that a failure has occurred upstream. AIS may be generated at MultiplexSection, LowOrder and HighOrder PathSection level. The SDH MS-AIS is renamed L-AIS in SONET. AIS triggers: LOS, LOF condition within 125 s on the incoming link. The MS-AIS is generated in a STM-N / OC-N that contains a valid MultiplexSection overhead, the K2 byte indicating MS-AIS and a all-ones pattern in the payload:

    K2 byte Bits 6, 7, 8

    111 MS-AIS

    The HO & LO P-AIS are coded with as all one in the container and Path pointers.

    - RDI (Remote Defect Indication): RDI signal notifies the adjacent upstream node that a failure has occurred upstream. RDI may be generated at MultiplexSection, LowOrder and HighOrder PathSection level.

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 19/263

    The SDH MS-RDI is renamed L-RDI in SONET. RDI triggers:

    - LOS, LOF condition within 125 s,

    - Reception of AIS signal.

    Remark: FERF is the old name for RDI.

    The MS-RDI is coded within K2 byte:

    K2 byte Bits 6, 7, 8

    110 MS-RDI

    The HO and LO RDI are coded in one bit of the HO / LO container overhead.

    Examples of AIS and RDI generation on UMTS interface composed of SDH nodes:

    Figure 3-3 AIS/RDI Generation

    3.1.2.3 APS Reference: [R50 & R51 & R110], Each Iub ATM SDH line is duplicated on the RNC, referred as 1+1 port redundancy, to ensure that the network will continue operation when a single SDH line is defective. The duplicated SDH line is either located:

    - In the same card case of MSA32E1/Oc3, it is referred as intraCard APS or

    - In a twin card case of 16pOC3 FP, it is referred as interCard APS.

    One line is configured as the Working line, whereas the associated line is configured as the Protected Line. See MML Attributes:

    ATTRIBUTE Aps workingLine (working) ATTRIBUTE Aps protectionLine (protection)

    Both the Working and the Protected lines carry the same payload in the transmit direction, but only the Working line is used for received payload. At the node startup, workingLine is selected for receiving user payload data.

    W

    P

    PTEPTE

    ATMATM

    UMTSUMTS

    LOS Condition

    TXTX

    TXTX

    RXRX

    RXRX

    MSTEMSTE

    RXRX

    TXTX

    RXRX

    TXTX

    TXTX

    TXTX

    RXRX

    RXRX

    PTEPTE

    ATMATM

    UMTSUMTS

    TXTX

    RXRX

    crossConnect

    MultiPlex Section 2

    RSTERSTE

    RXRX

    TXTX

    RXRX

    TXTX

    TXTX

    TXTX

    RXRX

    RXRX

    Line 1Regenerator Selected Line

    P-AISPOH P-AISPOH

    TXTX

    RXRX

    W

    0 000000000000000

    MSOH

    POH

    --

    K2K1

    P-RDI

    0 000000000000000

    MSOH

    POH

    --

    K2K1

    P-RDI

    1

    AIS

    W W

    MultiPlex Section 1

    Line 0P

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 20/263

    Nodes permanently monitor quality of the received signal. Based on these measurements, either node keeps the working line selected or decides to select protectionLine for receiving user payload data; this operation is referred as APS Switch.

    The Line switching time in case of a fault (SF/SD on the line) is within 50 ms

    Figure 3-4 APS mechanism

    Rule: TEG_SDH_APS-1 It is recommended to activate APS on all 16pOC3 FP ports. Moreover it is recommended to configured them as

    - WorkingLine, Stm1 links on the 16pOC3/Stm1 FP located on RNC-IN Slot 8, - ProtectedLine, Stm1 links on the 16pOC3/Stm1 FP located on RNC-IN Slot 9.

    Abnormal Case: In some cases, operators may decide temporarily not to connect the second fiber on some interfaces. In such a context:

    - IuxIf constraint: If LAPS component is configured on one port supporting AAL2 Vcc, LAPS must be configured on all RNC 16pOC3 FP ports supporting AAL2 Vcc, even if the second fiber not connected, in order to ensure a proper behavior of the equipment.

    - No constraint on other application: AtmMpe, - Moreover to minimize outage duration, for conformity with R&D platform RNC configuration

    and to facilitate introduction of future features (eg: Y-Splitter) Its recommended to configure LAPS on each RNC 16pOC3/Stm1 FP port.

    Rule: TEG_SDH_APS-3 It is recommended to configure the LAPS component between each port of the pair of

    RNCRNC UMTSNode

    UMTSNode

    16pOC316pOC3

    RxRx

    Same Signal

    Protected Line

    RN

    C T

    raffic g

    enerato

    rR

    NC

    Traffic

    gen

    erator

    TxTx

    RxRx

    TxTx

    16pOC316pOC3

    RxRx

    TxTx

    RxRx

    TxTx

    STM1

    16pOC316pOC3

    TxTx

    RxRx

    TxTx

    RxRx

    STM1

    16pOC316pOC3

    TxTx

    RxRx

    TxTx

    RxRx

    SDH

    Netw

    ork

    STM1

    STM1

    WorkingLineActiveCard

    Duplication of the egress stream

    1

    1

    2 Decision of the ingress stream to take into consideration

    2

    RNCRNC UMTSNode

    UMTSNode

    16pOC316pOC3

    RxRx

    Same Signal

    Protected Line

    RN

    C T

    raffic g

    enerato

    rR

    NC

    Traffic

    gen

    erator

    TxTx

    RxRx

    TxTx

    16pOC316pOC3

    RxRx

    TxTx

    RxRx

    TxTx

    STM1

    16pOC316pOC3

    TxTx

    RxRx

    TxTx

    RxRx

    STM1

    16pOC316pOC3

    TxTx

    RxRx

    TxTx

    RxRx

    SDH

    Netw

    ork

    STM1

    STM1

    WorkingLineActiveCard

    Duplication of the egress stream

    1

    1

    2 Decision of the ingress stream to take into consideration

    2

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 21/263

    16pOC3/Stm1 FP even so the protected fiber is not connected to the RNC 16pOC3/Stm1 FP.

    Remark: If LAPS component is configured whereas the protected fiber is not connected, one port is in LOS condition and then alarms appear on the Management platform for the non connected fiber; to remove these useless alarms either lock the non populated port (lock Lp/9 Sdh/i) or activate the "alarm filtering" (W-NMS).

    3.1.2.3.1 APS OPTIONS (CONFIGURABLE) Unidirectional/bidirectional mode:

    Unidirectional mode: APS switching occurs only in the node which detects misbehavior, when APS is configured in unidirectional mode. There is no APS switching in the remote node. Indeed on node which detects traffic disturbance, selected line is switched from the working line to the protected line, whereas on adjacent node selected line remains the working line. Even in unidirectional APS, K1 byte is still used to inform the remote SDH node of the local action. Moreover, K2 byte/Bit5 is set to 0 to reflect unidirectional mode.

    Bidirectional mode: APS switching occurs in the node which detect misbehavior on one hand, and then in the remote node on the other hand, when APS is configured in bidirectional mode. Node which detects misbehavior on a link invokes APS and informs remote node by means of SDH MSOH K1 bytes on the protected line that this link is experiencing a defect. K1 byte is set with the channel number, 0 or 1 in case of redundancy 1+1, and the nature of the defect which occurs on this link e.g.: SF, SD Indeed on both adjacent nodes, selected line is switch from working line to protected line. The K2 byte is transmitted too on the protected line.

    Remark: According to SONET recommendation, each node extremity of a SONET link has to

    be configured with the same mode unidirectional or bidirectional. If nodes are configured on different way, each node will apply unidirectional mode.

    See MML Attribute: ATTRIBUTE Aps mode Unidirectional is the default mode on RNC.

    Revertive mode: After APS switching has been invoked, APS feature allows, since misbehavior has been corrected, to come back to the initial configuration, if Revertive option is enabled. Such information is exchanged between SDH nodes by means of K1 bytes set with: WaitToRestore: the protection line is active and the working line has recovered from a

    Signal Fail or Signal Degrade. After the period defined by attribute waitToRestorePeriod the working line will automatically revert to being the received active line and the request will change to noRequest.

    ReverseRequest: This request is only applicable when the provisioned mode is bidirectional. DoNotRevert: the protection line is active, and Revertive option is not activated. the

    working line has recovered from a signalFail or signalDegrade; or a forcedSwitch or manualSwitch request has been cleared.

    NoRequest: the working line is active and no other requests are in effect.

    APS option rules:

    Rule: TEG_SDH_APS-4 It is recommended to set APS in bidirectional mode, on ALU RNC and MGw and SGSN nodes, with exception of the following cases where APS has to be configured in unidirectional mode:

    VPT 2 ports. ALU UMTS node to an otherVendor Node which doesnt provide APS.

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 22/263

    Remark: Bidirectional APS setting allows identifying with any doubt the working fiber. Unidirectional APS setting is slightly more robust because it can tolerate a failure on the working fiber transmit side and failure on the protected fiber receive side.

    See MML Attribute: ATTRIBUTE Aps revertive When this attribute is yes, the Aps reverts the received active line from protection back to working when a working line request is cleared, after the provisioned waitToRestorePeriod has expired. ATTRIBUTE Aps waitToRestorePeriod (wtrPeriod) This attribute specifies the time during which the protection line will remain the received active line after the working line recovers from the fault that caused the switch.

    3.1.2.3.2 APS TRIGGERS APS invocation is triggered on two different criteria: SF (SignalFail) or SD (SignalDegrade):

    - SF criteria, is based on following indicators/Conditions:

    - LOS (LossOfSignal) condition, it results from reception during at least 100 s, of SDH frame filed with only 0.

    Example: This event occurs on link failure. - LOF (LossOfFrame) condition, it results from reception of 4 consecutive errored

    frames.

    Example: Bad timing, faulty A1, A2 bytes - Reception of MS-AIS.

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

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

    - SD criteria, is based on one indicator:

    SD BER (BlockErrorRate) threshold is reached. SD BER threshold is in the range 10-3 to 10-10. BER is calculated on the multiplex section overhead. BER counts discrepancy between received BIP-24N (Bit Interleaved Parity) B2 byte within the SDH MultiplexSection overhead, and Even parity code calculated on the received SDH frame. See MML Attribute: ATTRIBUTE Aps signalDegradeRatio (sdRatio) This attribute specifies the minimum (BER) for which a Signal Degrade failure is declared. Its value is the exponent of the BER, with possible values of -5 through -9 inclusive, which correspond to a BER range of 10e-5 through 10e-9. The switch initiation time for a Signal Degrade varies depending on the observed BER:

    BER - Switch Initiation Time 10e-3 - 10 milliseconds

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 23/263

    10e-4 - 100 milliseconds 10e-5 - 1 second 10e-6 - 10 seconds 10e-7 - 100 seconds 10e-8 - 16 minutes 40 seconds 10e-9 - 2 hours 46 minutes 40 seconds

    The clearing threshold for a Signal Degrade is one-tenth the signalDegradeRatio; for example, if the provisioned signalDegradeRatio is -5, the corresponding clearing threshold will be 10e-6. The clearing time varies depending on the clearing threshold (not the observed BER), and can be determined from the above table. Remark:

    Since the SD BER is higher (eg: 10-5 10-9), it is necessary to monitor more data to measure the error ratio, if more data are monitored then measurement period is higher. Eg:

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

    Figure 3-5 APS switch on LOS Condition

    APS Invokation

    W

    P

    PTEPTE

    ATMATM

    UMTSUMTS

    LOS Condition

    TXTX

    TXTX

    RXRX

    RXRX

    RSTERSTE

    RXRX

    TXTX

    RXRX

    TXTX

    TXTX

    TXTX

    RXRX

    RXRX

    PTEPTE

    ATMATM

    UMTSUMTS

    TXTX

    RXRX

    Regenerator

    MultiPlex Section

    RSTERSTE

    RXRX

    TXTX

    RXRX

    TXTX

    TXTX

    TXTX

    RXRX

    RXRX

    Line 1

    Line 0

    RegeneratorSelected Line

    Selected Line

    MSOH

    POH

    IdleProtWorkSF HP

    0000000000011101

    K2K1

    No Path OAM signal

    MSOH

    POH

    IdleProtWorkSF HP

    0000000000011101

    K2K1

    No Path OAM signal

    TXTX

    RXRX

    W

    P

    MSOH

    POH

    MS-RDI-

    0 110000000000000

    K2K1

    No Path OAM signal

    MSOH

    POH

    MS-RDI-

    0 110000000000000

    K2K1

    No Path OAM signal

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 24/263

    Remark: APS is configured on the 16pOC3 FP, if one line is in LOS condition:

    - No P-RDI is returned to the farEnd (If P-RDI would be returned the farEnd would discard the traffic),

    - The MS-RDI is returned to the farEnd.

    Figure 3-6 APS switch on MS-AIS reception

    Remark: ATM switches and UMTS Nodes take appropriate action on reception of Transmission OAM signals, or under Transmission defect conditions:

    - APS invocation, - F4, F5 OAM message generation.

    3.2 ATM

    3.2.1 ATM INTERFACE TYPE ATM implemented on RNC is compliant with [R52]. Two types of ATM interfaces are specified: UNI and NNI. On UNI interface, VPI field is 8 bits length, whereas on NNI interface VPI field is 12 bits length. On Iub interface, NodeB, and RNC are configured with ATM Interface type UNI according to 3Gpp. Public ATM backbones provide only UNI accesses.

    RNC-PCM, Iub interface:

    NodeB POC UNI

    User side Network side

    RNC-IN

    Network side User side

    NNI

    APS Invokation

    W

    P

    PTEPTE

    ATMATM

    UMTSUMTSLOS Condition

    TXTX

    TXTX

    RXRX

    RXRX

    RSTERSTE

    RXRX

    TXTX

    RXRX

    TXTX

    TXTX

    TXTX

    RXRX

    RXRX

    PTEPTE

    ATMATM

    UMTSUMTS

    TXTX

    RXRX

    Regenerator

    MultiPlex Section

    RSTERSTE

    RXRX

    TXTX

    RXRX

    TXTX

    TXTX

    TXTX

    RXRX

    RXRX

    Line 1

    Line 0

    Regenerator Selected Line

    Selected Line

    MSOH

    MS-AIS-

    0 111000000000000

    K2K1MSOH

    MS-AIS-

    0 111000000000000

    K2K1

    TXTX

    RXRX

    W

    P

    0 1100000

    MSOH

    POH

    MS-RDI-00000000

    K2K1

    No Path OAM signal

    0 1100000

    MSOH

    POH

    MS-RDI-00000000

    K2K1

    No Path OAM signal1

    MSOH

    WorkSF HP

    0000000000011101

    K2K1MSOH

    WorkSF HP

    0000000000011101

    K2K12

    AIS

    2

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 25/263

    On the POC / RNC interface PNNI may be implemented.

    RNC-SDH, Iub interface with ATM backbone:

    NodeB ATM BackBone UNI

    RNC-IN UNI

    POC

    User side Network side User side UNI UNI

    Public

    Figure 3-7 ATM Protocol type

    Interface between RNC-IN and ATM Network is UNI.

    3.2.2 VPC, VPT A VPC (Virtual Path Connection) is an ATM Connection resulting from the grouping of different Vcc. A VPC is identified by VPi (Virtual Path Identifier). The AtmForum defines the notion of a VP endPoint. A VP endPoint is the node which is responsible for the grouping of Vcc within a VPC. This function is implemented in Passport nodes as a VPT component (VirtualPathTermination). The reason of grouping several Vcc within one VPC, by means of VPT, is to apply a common treatment to the set of Vcc, e.g.: TrafficManagement, OAM.

    3.2.2.1 VPC

    The target of this section is to summarize contexts where VPCs are required. NodeB E1/T1s can be connected directly to ASP network or connected to a POC before reaching the ASP.

    - When the NodeB is connected directly to the ASP network, without POC, in a multiPCM configuration, it is recommended to use one VPC for each E1/T1 link that connects NodeB to the ASP. The ASP provides the E1/T1 access port as well as the VPC across the network. There are per nodeB as many VPC configured in the ASP as amount of E1/T1 per nodeB. However, the OAM VCC must still be configured separately; explanation is given in trafficShaping section.

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 26/263

    RNC-SDHRNC-SDH

    NodeB

    x

    VC UP DSVC UP NDSVC CPVC CCP

    VC OAM

    VP x , rtVBR

    VC OAM

    NodeB

    y

    VP y, rtVBR

    VP x1

    VCC OAM x

    NodeB

    z

    VP z , rtVBR

    VC OAM

    VC OAM

    VP y1VP z1

    VCC OAM yVCC OAM z

    ATM

    Backb

    on

    e

    1 E1/T1

    VC UP DSVC UP NDSVC CPVC CCP

    VC OAM

    1 E1/T1

    VC UP DSVC UP NDSVC CPVC CCP

    VC OAM

    1 E1/T1

    16pOC

    3/STM1

    FPRNC-SDHRNC-SDH

    NodeB

    x

    VC UP DSVC UP NDSVC CPVC CCP

    VC OAM

    VP x , rtVBR

    VC OAM

    NodeB

    y

    VP y, rtVBR

    VP x1

    VCC OAM x

    NodeB

    z

    VP z , rtVBR

    VC OAM

    VC OAM

    VP y1VP z1

    VCC OAM yVCC OAM z

    ATM

    Backb

    on

    e

    1 E1/T1

    VC UP DSVC UP NDSVC CPVC CCP

    VC OAM

    1 E1/T1

    VC UP DSVC UP NDSVC CPVC CCP

    VC OAM

    1 E1/T1

    16pOC

    3/STM1

    FP

    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.

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 27/263

    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:

    RNC-SDH

    VC UP DS VC UP NDS VC CP VC CCPn

    VC OAM

    POC

    RNC-

    IN

    POC

    NodeB

    k = y

    NodeB

    k = z

    NodeB

    k = x

    VC UP DS VC UP NDS VC CP VC CCPn

    VC OAM

    VC UP DS VC UP NDS VC CP VC CCPn

    VC OAM

    VPu, rtVBR

    VPv, rtVBR

    VCC OAM

    VCC OAM

    VCC OAM

    VCC OAM

    VCC OAM

    VPu, rtVBR

    VPv, rtVBR

    VCC OAM

    ATM

    B

    ack

    bon

    e

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 28/263

    A VPC initiated in the ASP and terminated in the RNC, if no bandwidth constraint between ASP and RNC, then

    o VPC PCR could be set at NodeB(s)*E1_bandwidth, and o SCR of PVP could be set at NodeB(s)*E1_bandwidth*E1_UsageRate.

    With UsageRate = 80% Remark: If on RNC, trafficShaping at VP level is activated, only PCR is taken into account since 16pOC3 FP provides singleRate shaping (linearShaping).

    - Case of NodeBs connected to a POC: A VPC initiated in the POC and terminated in the RNC, if no bandwidth constraint between POC and RNC, then VPC PCR and SCR may be defined by cumulative traffic from NodeBs.

    o VPC PCR could be set at #NodeB(s)*E1_bandwidth, and o VPC SCR could be set at #NodeB(s)*E1_bandwidth*E1_UsageRate.

    With UsageRate = 80% Remark: If on RNC, trafficShaping at VP level is activated, only PCR is taken into account since 16pOC3 FP provides singleRate shaping (linearShaping).

    - Case of private ATM backbone inserted between nodeBs and RNC: The ATM backbone provides transmission bandwidth to RNC, lower than sum of nodeB bandwidth, then within ATM backbone: The VPC PCR is set with ATM Backbone available link bandwidth. In the example below, VPC PCR may be set with E1 bandwidth on RNC side and ATM switch side

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

    NodeB

    NodeB

    NodeB

    E1/T1

    ATM

    Sw

    itch

    ATM

    Sw

    itch STM1/OC3 RNC

    E1/T1

    E1/T1

    E1/T1

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 29/263

    Moreover when activating trafficShaping at VP level on one port of the 16pOC3/Stm1 FP, the size of the assigned perVc queue need to be configured with an appropriate value see 3.2.6.1.

    3.2.2.2 VPT

    Within Passport two kinds of VPTs are available: - basicVPT and - StandardVPT.

    BasicVPT is available on APC based card, e.g.: 16pOC3 FP and AQM based cards, e.g.: 4pOC3 FP, whereas StandardVPT is available only on AQM based cards.

    When configuring basicVPT on a port, activation of trafficShaping is not allowed. For activating trafficShaping at VP level, a second port and a hairpin is required; VPT is configured on one port, traffic is diverted to a second port where trafficShaping is activated. It is called the two port solution.

    C o m m o n Q u e u e s :

    C o m m o n Q u e u e s :

    C o n n ec t io n S c h e d u le r : W F Q O r S F Q

    C la s s S c h e d u le r : E P & M B G

    E P 0 Q u e u e s P e r V C Q u e u e s :

    V C C 1 Q u e u e W e ig h t 1

    E P 1 to E P 7 Q u e u e s P e r V C Q u e u e s :

    T ra n s m it P e rV C & c o m m o n Q u e u e s

    A P C

    L in k C la s s Q u e u e fo r E P 0

    L in k C la s s Q u e u e fo r E P 7

    V C C 2 Q u e u e W e ig h t 2

    V P C Q u e u e W e ig h t 3

    V C C 7 1 Q u e u e W e ig h t 1

    V C C 7 2 Q u e u e W e ig h t 1

    V C C 7 3 Q u e u e W e ig h t 1

    V P T

    CBR

    nrtVBR

    rtVBR

    UBR

    Emis

    sio

    nPr

    iorit

    y/M

    ostU

    rgen

    t

    EP7

    EP4

    EP3

    EP2

    EP0

    CBR

    Emis

    sio

    nPr

    iorit

    y/M

    ostU

    rgen

    t

    EP7

    EP4

    EP3

    EP2

    EP0 rtVBR

    nrtVBR

    C o m m o n Q u e u e s :

    C o m m o n Q u e u e s :

    C o n n e c t io n S c h e d u le r : W F Q O r S F Q

    C la s s S c h e d u le r : E P & M B G

    E P 0 Q u e u e s P e r V C Q u e u e s :

    V C C 1 Q u e u e W e ig h t 1

    E P 1 t o E P 7 Q u e u e s P e r V C Q u e u e s :

    T r a n s m i t P e r V C & c o m m o n Q u e u e s

    A P C

    L i n k C la s s Q u e u e f o r E P 0

    L i n k C la s s Q u e u e f o r E P 7

    V C C 2 Q u e u e W e ig h t 2

    V P C Q u e u e

    W e ig h t 3

    V C C 7 1 Q u e u e W e ig h t 1

    V C C 7 2 Q u e u e W e ig h t 1

    V C C 7 3 Q u e u e

    W e ig h t 1

    Port1

    Port2

    BackPlane

    Rx

    Tx

    Rx

    Tx

    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:

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 30/263

    Identifying the VPC by means of a VPi, VPi range [0, 4095], Grouping Vcc within the VPC,

    Configuring kind of OAM loopBack, segment or endToEnd.

    If trafficShaping is required, it is activated on a second port.

    AtmIf n1

    VPd

    VPT vpi

    - SegmentLoopBack on, off, sameAsInterface- EndToEndLoopBack on, off, sameAsInterface

    AtmIf n2

    VPd

    VPC vpi

    TM

    - SegmentLoopBack on, off, sameAsInterface- EndToEndLoopBack on, off, sameAsInterface

    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

    VPd

    VPT vpi

    - SegmentLoopBack on, off, sameAsInterface- EndToEndLoopBack on, off, sameAsInterface

    TM- TrafficShaping disabled, sameAsCa- ServiceCategory,- Tx TrafficDescriptor Type & Parameters,- Rx TrafficDescriptor Type & Parameters,

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 31/263

    3.2.3 OVERSUBSCRIPTION 3.2.3.1 PASSPORT, OVERSUBSCRIBTION:

    When configuring Passport, the port bandwidth is allocated to one bandwidth pool or distributed over several bandwidth pool (bandwidthPool is a Passport component). One to five bandwidth pools are available. Then an association is configured between each bandwidth pool and the atm serviceCategory (ies). Either one bandwidth pool per serviceCategory or all serviceCategories associated to the same bandwidth pool.

    Rule: IubTEG_OvS_01 It is recommended to allocate all the port bandwidth to one single bandwidth pool, and associate all the service categories to this bandwidth pool.

    Here below described setting of bandwidthPools: Passport

    BwPoll-1 100%

    E1/T1 All SC

    Figure 3-11 OverSubscription

    Bandwidth pool equal 100% of link capacity in case of normal subscription. Bandwidth pool is higher than 100% of link capacity in case of over subscription. Passport node permits over-subscription for each bandwidth pool at 64 times the port capacity. Over subscription is configured when setting bandwidth pool component. The setting of oversubscription influences the CAC.

    The Overbooking factor is determined according to the traffic needs.

    3.2.3.2 NODEB:

    OverSubscription feature is not available on NodeB.

    3.2.4 CAC CAC (Connection Admission Control) is a generic function which checks that connections request less bandwidth than available. Different algorithm may be used for CAC implementation

    CAC is an algorithm invoked at AtmConnection setup. It verifies that bandwidth required for the new atmConnection is below than bandwidth available on the physical link. For Permanent VC, CAC is invoked in provisioning phase, whereas CAC is invoked in establishment phase for a Switched VC. Based on atmConnection trafficDescriptor, CAC calculates the ECR (EquivalentCellRate) associated to this atmConnection. ECR is the bandwidth required for an atmConnection from the CAC point of view.

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 32/263

    AtmConnection is rejected when it requires more bandwidth than available at physical link.

    Different kinds of CAC Algorithm: - NodeB:

    Equivalent cell rate is calculated as following: - ECR = PCR for a CBR atmConnection, - ECR = SCR for a VBR atmConnection, - ECR = MCR for a UBR+ atmConnection, - ECR = 0 for a UBR atmConnection,

    Remark: CDVT is not managed at NodeB level.

    - Passport based nodes: Two kinds of CAC are implemented in Passport: ACAC (Actual CAC) and GCAC (Generic CAC). - ACAC (Actual CAC):

    The ACAC is a ALU algorithm implemented in Passport. It is a hop-by-hop reservation scheme performed in the egress and ingress direction regardless of the connection type: PVC, PVP, SPVC, SPVP, SVC and SVP. It is invoked each time a pvc is provisioned or a svc is established. The ACAC calculates the ECR per atmConnection, based on the following ATM QOS and TrafficManagement parameters: - Buffer size, - LinkRate, - ServiceCategory, - CLR (CellLossRate). - PCR, SCR, CDVT, MBS

    Moreover the ACAC checks that the sum of ECR for all the atmConnections configured on a link is lower than link bandwidth. If not, then some atmConnections are rejected.

    In such a way to avoid such a situation, before provisioning phase, when determining amount of atmConnections per link and atmConnection trafficDescriptors, the ACAC algorithm Excel macro is used to estimate the bandwidth (ECR) required per atmConnections. Since atmConnection bandwidth (ECR) is known, the amount of atmConnections per link and atmConnection trafficDescriptors may be tuned in such a way sum of ECR of all atmConnections configured on a link is lower than link bandwidth.

    - GCAC (Generic CAC): The GCAC algorithm is by the Pnni sPvc originating node when setting up the sPvc connections, Moreover the GCAC algorithm is taken into account by the aal2 Link CAC, invoked at the umts call establishment. The GCAC is based on simplified formula:

    Rule: IubTEG_CAC_O1 ECRGCAC = 2 * PCR * SCR / (PCR + SCR)

    - Hsdpa CAC:

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 33/263

    The Hsdpa CAC is invoked in RAB AssignmentRequest phase, (same as for the aal2LinkCac), it consists in counting amount of Hsdpa calls per NodeB radio cell. The amount of allowed Hsdpa calls per NodeB radio cell is configured through the parameter:

    HsdpaCellClass/maximumNumberOfUsers Range: [0..50], Class 0, Granularity RNC, defaultValue 20

    3.2.5 TRAFFIC MANAGEMENT At ATM level, bandwidth per ATM Connection is managed by means of TrafficDescriptor parameters. TrafficDescriptor parameters may be involved in traffic regulation, when its activated. Regulation of traffic on Egress side is achieved by trafficShaping whereas regulation of traffic on Ingress side is achieved by means of Policing.

    3.2.5.1 TRAFFICDESCRIPTOR PARAMETER PRESENTATION

    Pictures below indicate relationship between PCR, SCR and MBS. Let us called , the ATM Cells transmission duration. depends on the physical link throughput:

    - = 220 s for an E1,

    - = 2,83 s for an STM1,

    For a VBR service category, traffic is considered bursty, and then cells are sent within a burst, bursts are sent periodically. Such traffic is described at ATM level by means of 2 throughput parameters: PCR and SCR and size of the burst MBS:

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 34/263

    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]

    Context:TrafficSource: continuous DualRateShaping:

    PCR = linkRate CDVT = 0 SCR = 1/8 LR MBS = 3=> BT = 2*(Ts-T)

    Ts= 1/SCR

    TAT TAT

    t T= 1/PCR

    2 1 3 4 5 6

    BT BT

    BT BT

    Period2 Period3 Period4 Period5 Period6

    Ts= 1/SCR Ts= 1/SCR Ts= 1/SCR

    2 1 3 4 5 6

    ATM-User traffic: Traffic is continuous

    Shaped traffic

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 35/263

    RRC PDCP

    RLC MAC

    Physical

    UE NodeB RNC

    RRC PDCP

    RLC MAC

    Physical

    AAL2

    ATM

    Physical

    Iub Uu

    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:

    Figure 3-13 RAB / TrafficDescriptor relationship

    This example may be generalized to both userPlane Vcc: DelaySensitive UP VCC:

    T s = 1 /S C R

    T A T T A T

    T = 1 /P C R

    2 1 3

    B T B T

    B T B T

    P e r io d 2 P e r io d 3 P e r io d 4

    T s = 1 /S C R T s = 1 /S C R T s = 1 /S C R

    T m = M B S / S C R

    2 1 3

    R A B 6 4 , B lo c k s

    A T M T D

    t

    4

    T T I= 2 0 m s

    4

    2 1 3 4

    T T I= 2 0 m s

    t

    E1: = 220 sSTM1: = 2,8 s

    Example: RAB 64

    Context: MBS = 4 Tm = 20 ms

    => SCR = MBS/Tm = 200 c/s=> Ts = 5 ms

    PCR = 2 * SCR=> T = 2,5 ms

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 36/263

    DS UP VCC carries traffic: - TRB for UMTS serviceClass: Conversational,

    - DedicatedSRB relative to all TRB (DS and NDS), - CommonSRB.

    TRB for UMTS ServiceClass: Conversational and Streaming are handled by means of following RABs, the most restricting RAB transportFormat is shown in this table, see [R62] for a complete RAB definition, moreover is considered that a RAB block fills totally an ATM Cell payload:

    RAB Direction TTI

    BlockSize #MaxBlocks /TTI

    Consecutive ATM cells

    Ms Bits Bytes For highest TF

    DL 20 244 31 1 1 Speech / 12,2 kb/s 12,2 kb/s UL 20 244 31 1 1

    DL 40 576 72 1 2 CS Data / 14,4 kb/s 14,4 kb/s UL 40 576 72 1 2

    DL 40 576 72 4 7 CSD 57, 6 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 ServiceClass

    RAB Direction TTI

    BlockSize #MaxBlocks /TTI

    Consecutive ATM cells

    Ms Bits Bytes For highest TF 64kb/s / 64 kb/s DL 20 336 42 4 4 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

    Inte

    ract

    ive

    /

    Bac

    kgro

    un

    d

    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:

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 37/263

    Determination of ControlPlane VCC trafficDescriptor is the result of a dimensioning study.

    Remark: In RNC, only Egress trafficDescriptor is provisioned per VCC or per VPC, Ingress trafficDescriptor is set with same as Egress. On this way provisioned TrafficDescriptor applies for both directions.

    3.2.5.3 TRAFFICSHAPING

    Traffic shaping regulates egress traffic according to trafficDescriptor parameter values. TrafficShaping is presented in a PowerPoint file stored on Transport web site. Here an extract from this file. According to line card, different kinds of trafficShaping are available: singleRate and dualRate shaping. (SingleRate TS is also called LinearShaping; dualRate TS is also called InverseVBR TS) On 16pOC3/STM1, only SingleRate TrafficShaping is available, whereas on 4pOC3 both kinds of trafficShaping are available. LinearShaping regulates egress traffic according to PCR, whereas dualRate Shaping regulates egress traffic according to PCR, SCR and MBS. DualRate Shaping may be called VBR shaping.

    For a continuous flow of traffic has to be transmitted, and dualRate Shaping is activated, MBS cells are sent at PCR, following cells are sent at SCR:

    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.

    Ts= 1/SCR

    TAT TAT

    t T= 1/PCR

    2 1 3 4 5 6

    BT BT

    BT BT

    Period2 Period3 Period4 Period5 Period6

    Ts= 1/SCR Ts= 1/SCR Ts= 1/SCR

    2 1 3 4 5 6

    ATM-User traffic: Traffic is continuous

    Shaped traffic

    Cell6 suffers a Delay of 27 , so the whole frame is delayed by 4*Ts

    Ts= 1/SCR

    TAT TAT

    t T= 1/PCR

    2 1 3 4 5 6

    BT BT

    BT BT

    Period2 Period3 Period4 Period5 Period6

    Ts= 1/SCR Ts= 1/SCR Ts= 1/SCR

    2 1 3 4 5 6

    ATM-User traffic: Traffic is continuous

    Shaped traffic

    Cell6 suffers a Delay of 27 , so the whole frame is delayed by 4*Ts

  • Iub Transport, engineering guide

    ALU confidential

    UMT/IRC/APP/7149 07.02 / EN Standard 29/06/2009 Page 38/263

    Rule: IubTEG_ATM-TM_1

    To the extent that public ATM backbone is not involved on the UMTS interface, It is not recommended to activate TrafficShaping or Policing function, in order to avoid cell delay and cell discard.

    Rule: IubTEG_ATM-TM_2

    When a policed ATM backbone is inserted on the UMTS interface, It is recommended to activate TrafficShaping at VP level. According to the Iub topology, the VPC results either from the grouping of all Vcc from a NodeB with exception of the OAM VCC, or from the grouping from all Vcc from nodeBs behind the POC, with exception of NodeB OAM Vcc.