wcdma ran atm transport

WCDMA RAN, Rel. RU30, Operating Documentation, Issue 13

WCDMA RAN ATM Transport

DN70569254

Issue 03DApproval Date 2012-11-26

Confidential

2 DN70569254Issue 03D


Id:0900d805809888edConfidential

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright Nokia Siemens Networks 2011. All rights reserved

f Important Notice on Product SafetyThis product may present safety risks due to laser, electricity, heat, and other sources of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having carefully read the safety information applicable to this product.

The safety information is provided in the Safety Information section in the Legal, Safety and Environmental Information part of this document or documentation set.

The same text in German:

f Wichtiger Hinweis zur Produktsicherheit Von diesem Produkt knnen Gefahren durch Laser, Elektrizitt, Hitzeentwicklung oder andere Gefahrenquellen ausgehen.

Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter Sicherheitshinweise im Teil Legal, Safety and Environmental Information dieses Dokuments oder dieses Dokumentations-satzes.

DN70569254 3



Table of contentsThis document has 99 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1 Changes in ATM transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1 New in RAS05.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 New in RAS06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 New in RU10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.4 New in RU20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.5 Removed in RU20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 ATM description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1 ATM basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.1 ATM cell header format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.1.1 Payload Type Identifier (PTI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.1.2 Cell Loss Priority (CLP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.1.3 Header Error Correction (HEC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.1.4 Payload bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.2 ATM virtual channel (VC). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1.3 ATM virtual path (VP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.4 VC Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.4.1 VC bundle configuration rules when only the RAN1099 feature is enabled

172.1.4.2 VC bundle configuration rules when only the RAN1100 feature is enabled

182.1.4.3 VC bundle configurations rules when both RAN1099 and RAN1100 fea-

tures are activated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.4.4 VC Bundle and VP traffic shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.5 Configuration of ATM VCs and VPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.6 Hierarchy of ATM related entities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.7 ATM cross-connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.8 ATM service categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.8.1 Excessive Bandwidth Share among UBR+ connections (UBRshare) . . 232.1.8.2 UBR+ support for User Plane, Control Plane and management plane . 24

3 Interfaces and protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1 Protocol stacks in RAN interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.1 Protocol stack for Iub interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.2 Protocol stack for Iur interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.3 Protocol stack for Iu interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1.4 Protocol stack for the Iu-BC interface . . . . . . . . . . . . . . . . . . . . . . . . . . 283.1.5 Protocol stack for the O&M interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2 IP and ATM Transport Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.1 Iub Transport Media Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.2 IP Network Failure Handling in Dual Iub or Hybrid Backhaul Configurations

31

4 Signaling in the ATM network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 DN70569254



5 Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 Resource state values of ATM entities . . . . . . . . . . . . . . . . . . . . . . . . . . 376.1 Administrative state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2 Operational state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7 Fault management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.1 AIS / RDI failure reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.2 Continuity check (CC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427.3 Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

8 ATM Adaptation Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448.1 ATM Adaptation Layer type 5 (AAL5) . . . . . . . . . . . . . . . . . . . . . . . . . . . 448.2 ATM Adaptation Layer type 2 (AAL2) . . . . . . . . . . . . . . . . . . . . . . . . . . . 448.2.1 Setup of AAL2 VCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458.2.2 Creation of AAL2 connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458.2.3 Shutdown of AAL2 VCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.2.4 Reset of AAL2 VCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.2.5 AAL2 path selection (traffic separation, CS2PATH) . . . . . . . . . . . . . . . . 468.2.5.1 Main changes between RAS06 and RU10 for the RAN759 feature . . . . 468.2.5.2 Overview of RAN759 functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.2.5.3 RAN759 functionality: VC selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.2.5.4 RAN759 functionality: VC combinations . . . . . . . . . . . . . . . . . . . . . . . . . 508.2.5.5 RAN759 functionality: VP/VC selection . . . . . . . . . . . . . . . . . . . . . . . . . 538.2.5.6 RAN759 functionality: VC change in connection modification . . . . . . . . 538.2.5.7 RAN759 functionality: AAL2 priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . 538.2.5.8 RAN759 functionality: path type in ERQ message . . . . . . . . . . . . . . . . . 548.2.5.9 Interdependencies with other features . . . . . . . . . . . . . . . . . . . . . . . . . . 558.2.5.10 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.2.5.11 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.2.5.12 Parameters associated with the Path Selection feature . . . . . . . . . . . . . 558.2.5.13 Difference between RNC and AXC AAL2UPUsages in RU10 . . . . . . . . 568.2.5.14 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578.2.5.15 Activating the feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578.2.6 AAL2 connection handling for Iur and Iu-CS. . . . . . . . . . . . . . . . . . . . . . 57

9 Traffic control functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599.1 UPC and NPC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599.2 Traffic shaping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599.2.1 Traffic shaping in ATM cross-connects. . . . . . . . . . . . . . . . . . . . . . . . . . 609.3 Connection admission control (ATM and AAL2 layer CAC) . . . . . . . . . . 609.3.1 ATM CAC for UBR+ connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609.3.2 ATM service category and AAL2 CAC bandwidth reference . . . . . . . . . 619.3.3 AAL2 CAC for Flexi WCDMA BTS and Ultrasite WCDMA BTS . . . . . . . 619.3.4 RNC AAL2 CAC: Path type and AAL2 CAC algorithm . . . . . . . . . . . . . . 619.3.5 VC Bundle mode for CAC in RNC and BTS . . . . . . . . . . . . . . . . . . . . . . 639.3.6 Transport bearer tuning (RAN1096) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649.3.6.1 Activity factor tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659.3.6.2 Overbooking Iur interfaces with RAN1096 . . . . . . . . . . . . . . . . . . . . . . . 66

DN70569254 5



9.3.6.3 Transport bearer tuning and optimized Iub AAL2 reservations for Common Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

9.3.6.4 RAN1096 interdependencies with other features . . . . . . . . . . . . . . . . . 679.3.6.5 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689.3.6.6 Parameters used with the RAN1096 feature . . . . . . . . . . . . . . . . . . . . . 689.3.6.7 Activating RAN1096. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699.3.7 Dynamic Scheduling for HSDPA with Path Selection (RAN1099, DSH-

PATH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699.3.7.1 Main changes between RAS06 and RU10 for the RAN1099 (DSHPATH)

feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709.3.7.2 Dynamic internal flow control for NRT HSDPA (DSHPATH) in RU10 . . 709.3.8 Dynamic Scheduling for NRT DCH with Path Selection (RAN1100, DSN-

PATH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729.3.8.1 RNC internal dynamic flow control for NRT DCH downlink data (DSN-

PATH) in RU10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729.3.9 Extended UL AAL2 CAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749.3.10 AXC ATM interface oversubscription (overbooking) . . . . . . . . . . . . . . . 75

10 Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7710.1 ATM Connection configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7710.1.1 Iub VC configuration with several ATM interfaces and VPs for one BTS 7810.1.2 AAL2 User Plane resources at the Iub interface . . . . . . . . . . . . . . . . . . 79

11 Additional functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8311.1 RACH Transport Capacity Reservation Dependent on Air-interface Capac-

ity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

12 Optional features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

13 Features per release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

14 Management data for ATM transport . . . . . . . . . . . . . . . . . . . . . . . . . . . 8814.1 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8814.1.1 Alarms: RAN1449: Dual Iub for Flexi WCDMA BTS . . . . . . . . . . . . . . . 8814.1.2 Alarms: RAN1633: Dual Iub for UltraSite WCDMA BTS . . . . . . . . . . . . 8814.2 Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8814.2.1 Counters: RAN1253: Iub Transport QoS . . . . . . . . . . . . . . . . . . . . . . . . 8914.2.2 Counters: RAN1449 Dual Iub for Flexi WCDMA BTS . . . . . . . . . . . . . . 9014.2.3 Counters: RAN1701: AXCF unit for UltraSite WCDMA BTS . . . . . . . . . 9114.3 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9314.3.1 Parameters: RAN1701: AXCF unit for UltraSite WCDMA BTS . . . . . . . 9314.3.2 Parameters: RAN164: Satellite Iub . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9314.3.3 Parameters: RAN1192: UBR+ for Control Plane and Iu-Iur User Plane 9314.3.4 Parameters: RAN1253: Iub transport QoS . . . . . . . . . . . . . . . . . . . . . . 9314.3.5 Parameters: RAN1449: Dual Iub for Flexi WCDMA BTS. . . . . . . . . . . . 9714.3.6 Parameters: RAN1449: Dual Iub for Flexi WCDMA BTS and RAN1633:

Dual Iub for UltraSite WCDMA BTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

15 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

6 DN70569254



List of figuresFigure 1 UMTS protocol model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figure 2 Iub ATM protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figure 3 Iur ATM protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figure 4 Iu-CS ATM protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figure 5 Iu-PS ATM protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figure 6 Iu-BC ATM protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figure 7 O&M interface protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figure 8 Transport technology selection with RAN1449 and RAN1633 . . . . . . . . 30Figure 9 AIS/RDI mechanism and the generated alarms (Iub interface) . . . . . . . 41Figure 10 AIS/RDI mechanism and the generated alarms (Iur interface) . . . . . . . . 42Figure 11 Basic Iub VC configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Figure 12 Iub configuration with one ATM interface and two VPs for one BTS connec-

tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Figure 13 Iub configuration with two ATM interface and three VPs for one BTS con-

nection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Figure 14 AAL2 User Plane link example configuration, UltraSite WCDMA BTS with

AXU-A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Figure 15 AAL2 User Plane link example configuration A, UltraSite WCDMA BTS with

AXU-B/C/D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Figure 16 AAL2 User Plane link example configuration B, UltraSite WCDMA BTS with

AXU-B/C/D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Figure 17 AAL2 User Plane link example configuration, Flexi BTS . . . . . . . . . . . . 82

DN70569254 7



List of tablesTable 1 ATM cell header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Table 2 Supported VC bundle configurations with RAN1099 . . . . . . . . . . . . . . 18Table 3 Supported VC bundle configurations with RAN1100 . . . . . . . . . . . . . . 18Table 4 Supported VC bundle configurations depending on the availability of Dy-

namic Scheduling features RAN1099 and RAN1100 . . . . . . . . . . . . . . 20Table 5 Allowed combinations for transport bearers on IP transport network . . 30Table 6 NRT HSPA call establishment/re-establishment in Dual Iub scenario in

case of IP network failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Table 7 UMTS QoS classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Table 8 Causes for resource state changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Table 9 Fault management functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Table 10 Provision of ATM OAM functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Table 11 RAS06 and new RU10 terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Table 12 VC labels for VC selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Table 13 SRB on HSPA and RT HSPA transport bearer allocation to AAL2 VCs 50Table 14 Iub VC combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Table 15 Mapping bearers to AAL2 priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Table 16 Parameters associated with the Path Selection feature . . . . . . . . . . . . 55Table 17 Mapping of RNC and AXC AAL2UPUsages . . . . . . . . . . . . . . . . . . . . . 56Table 18 Sample AXC configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Table 19 HSPA over Iur AAL2 VCC combinations . . . . . . . . . . . . . . . . . . . . . . . 58Table 20 AAL2 CAC algorithms in the RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Table 21 AF and SCCPCH relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Table 22 Parameters used with the RAN1096 feature . . . . . . . . . . . . . . . . . . . . 68Table 23 Parameters used with the RAN1099 feature . . . . . . . . . . . . . . . . . . . . 71Table 24 VCs on NPS1 for which NRT DCH internal flow control can be enabled .

73Table 25 Parameters used with the RAN1100 feature . . . . . . . . . . . . . . . . . . . . 74Table 26 AAL2 User Plane link example configuration, UltraSite WCDMA BTS with

AXU-A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Table 27 AAL2 User Plane link example configuration A, UltraSite WCDMA BTS with

AXU-B/C/D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Table 28 AAL2 User Plane link example configuration B, UltraSite WCDMA BTS

with AXU-B/C/D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Table 29 AAL2 User Plane link example configuration, Flexi BTS . . . . . . . . . . 82Table 30 Features per release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Table 31 Alarms: RAN1449: Dual Iub for Flexi WCDMA BTS . . . . . . . . . . . . . . . 88Table 32 Alarms: RAN1633: Dual Iub for UltraSite WCDMA BTS . . . . . . . . . . . . 88Table 33 Counters: RAN1253: Iub Transport QoS . . . . . . . . . . . . . . . . . . . . . . . 89Table 34 Counters: RAN1449 Dual Iub for Flexi WCDMA BTS . . . . . . . . . . . . . . 90Table 35 Counters: RAN1701: AXCF unit for UltraSite WCDMA BTS . . . . . . . . 91Table 36 Parameters: RAN1701: AXCF unit for UltraSite WCDMA BTS . . . . . . 93Table 37 Parameters: RAN164: Satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Table 38 Parameters: RAN1192: UBR+ for Control Plane and Iu-Iur User Plane 93Table 39 Parameters: RAN1253: Iub transport QoS . . . . . . . . . . . . . . . . . . . . . . 93Table 40 Parameters: RAN1253: Iub transport QoS for ATM transport . . . . . . . 96

8 DN70569254



Table 41 Parameters: RAN1449: Dual Iub for Flexi WCDMA BTS . . . . . . . . . . . . 97Table 42 Parameters: RAN1449: Dual Iub for Flexi WCDMA BTS and RAN1633:

Dual Iub for UltraSite WCDMA BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

DN70569254 9

WCDMA RAN ATM Transport Summary of changes

Id:0900d80580988a99Confidential

Summary of changesChanges between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues.

Please note that our issue numbering system is changing. For more information, see Guide to WCDMA RAN Operating Documentation.

Changes between issues 03C (2011-12-23, RU30) and 03D (2012-11-26, RU30)ATM description (2) Section ATM cell header format has been updatedChanges between issues 03B (2011-09-10, RU30) and 03C (2011-12-23, RU30)Additional functionalities (11) MML command enabling the PRFILE parameter has been corrected. MML command disabling the PRFILE parameter has been corrected.Changes between issues 03A and 03BSignaling in the ATM network (4) Section AAL2 signaling for Iur and Iu-CS has been added.Changes between issues 03 and 03AAAL2 connection handling for Iur and Iu-CS (8.2.6) Section AAL2 connection handling for Iur and Iu-CS has been updated.ATM Adaptation Layers (8) Table 9 HSPA over Iur AAL2 VCC combinations has been added.

10 DN70569254


Id:0900d80580988a99Confidential

Summary of changes

DN70569254 11

WCDMA RAN ATM Transport Changes in ATM transport

Id:0900d805807459daConfidential

1 Changes in ATM transportThis chapter describes new, modified, and removed functionality as compared to earlier releases.

1.1 New in RAS05.1 Feature RAN96: Automated RNS Split Feature RAN165: IP Based Control Plane at Iu and Iur Feature RAN324: Dynamic HSDPA Transport Scheduling Feature RAN849: HSDPA Proportional Fair Resource Packet Scheduler Feature RAN882: AXC ATM Layer Configuration Management for BTS Feature RAN900: Nokia Flexi WCDMA BTS Feature RAN905: Flexi WCDMA BTS Nokia MHA Support Feature RAN935: BTS AAL2 Multiplexing for Flexi WCDMA BTS Feature RAN939: Flexbus Interface for Flexi WCDMA BTS Feature RAN940: E1 Interface for Flexi WCDMA BTS Feature RAN941: JT1 Interface for Flexi WCDMA BTS Feature RAN946: T1 Interface for Flexi WCDMA BTS Feature RAN1020: Route Selection

g The feature removed in RU20. Feature RAN1062: IMA (Flexi WCDMA BTS) Feature RAN1086: AXC ATM Interface Oversubscription

1.2 New in RAS06 Feature RAN759: Path Selection Feature RAN1063: Hybrid Backhaul with Pseudowires Feature RAN1064: Ethernet+E1/T1/JT1 Interface Unit (Iub User Plane) for Flexi

WCDMA BTS Feature RAN1095: UBR+ for Iub User Plane Feature RAN1096: Transport Bearer Tuning Feature RAN1097: Ethernet Interface Unit IFUH (Iub User Plane) for AXC Feature RAN1099: Dynamic Scheduling for HSDPA with Path Selection Feature RAN1100: Dynamic Scheduling for NRT DCH with Path Selection Feature RAN1142: ATM over Ethernet for BTS Feature RAN1319: Flexi WCDMA BTS IMA Based AAL2 Uplink CAC

1.3 New in RU10 Feature RAN1192: UBR+ for Control Plane and Iu-Iur User Plane Feature RAN1253: Iub Transport QoS Feature RAN164: Satellite Iub Feature RAN1449: Dual Iub for Flexi WCDMA BTS

12 DN70569254


Id:0900d805807459daConfidential

Changes in ATM transport

1.4 New in RU20 Feature RAN1633: Dual Iub for Ultrasite WCDMA BTS Feature RAN1701: AXCF unit for UltraSite WCDMA BTS Feature RAN1578: HSPA transport fallback (for details, see FAD WCDMA RAN

network protection)

1.5 Removed in RU20 Feature RAN1020: Route Selection

DN70569254 13

WCDMA RAN ATM Transport ATM description

Id:0900d80580988a8dConfidential

2 ATM descriptionThis document describes the transport network arrangements for the UMTS between its WCDMA BTS, RNC, Serving GPRS Support Node (SGSN) and Media Gateway (MGW) network nodes. "Transport network" is a generic term for the protocol layers and related functions that handle the signaling transport and the user data transport.

The scope of this document is to describe the characteristics and the realization of the ATM transport layer of the transport network. The document covers four transport layers: Transport layer for the User Plane Transport layer for the UMTS Control Plane Transport layer for the transport network Control Plane (TNCP) Transport layer for control and management plane connections.In the vertical dimension, this document covers Layer 2 (link layer) and Layer 3 (network layer) of the Open Systems Interconnection (OSI) Model. In the transport network Control Plane, the signaling protocol application is also covered. The physical layer (Layer 1) and layers above the network layer are not discussed in this document. Its focus is on the Asynchronous Transfer Mode (ATM) and its associated ATM Adaptation Layers (AAL). In the horizontal dimension, the interfaces Iub, Iur and Iu are covered.

2.1 ATM basicsThis section provides a short overview of the ATM principles. Details are covered from chapter 3 Interfaces and protocols onward. Further information is also found in the ATM Layer in RNC document.

In ATM networks, data is sent in packets of 53 octets (called ATM cells) through point-to-point connections. An ATM cell consists of a five-octet header and a payload of 48 octets. The point-to-point connections are established between end-points configured in the network elements. An end-point can either terminate a connection or cross-connect it with another connection toward a third network element.

ATM provides its connections on two layers: ATM virtual channel connections (VCCs or VCs) and virtual path connections (VPCs or VPs). The data transfer capacity provided by the underlying physical layer is usually distributed over several VPs and VCs. Each ATM cell contains a label in its header to identify the VC and VP to which it belongs. This label consists of two parts, the VC identifier (VCI, size 16 bit) and the VP identifier (VPI, size 8 bit or 12 bit). A third layer of connections can be added using the ATM Adaptation Layer Type 2 (AAL2) on top of the ATM protocol stack. AAL2 distributes the capacity of an ATM VC over a maximum of 248 AAL2 links. The ATM VC then carries an AAL2 path. The end-points of the AAL2 links inside an AAL2 path, and those of the AAL2 path itself are located in the entity where also the VC end-points are located. In addition to VCI and VPI, AAL2 data packets use an additional byte of the ATM cell payload to identify the AAL2 link, that is, the CID (channel identification) value. ATM cells with identical VCI and VPI are transported through the same network route.

Quality of service (QoS)ATM connections (VCs and VPs) are characterized by three categories: ATM service categories, traffic parameters and QoS parameters. To take full advantage of all trans-port resources, these categories can be mapped to corresponding Radio Network Layer

14 DN70569254



ATM description

parameters. The section Quality of Service provides more details about the QoS provi-sion in the ATM layer.

2.1.1 ATM cell header formatTable 1 ATM cell header shows the structure of an ATM cell header. Its elements are:

VPI and VCI: As defined in Recommendation ITU-T I.361, the network-to-network inter-face (NNI) ATM cell format reserves 12 bits in the cell header for the VPI value. The user-to-network interface (UNI) cell format has eight VPI bits and reserves four bits for Generic Flow Control (GFC),not required in RAN. GFC is not supported and the corre-sponding bits are set to 0 in egress and ignored in ingress. The network elements do not support all VPI values.

NMS and EM are able to configure the cell format for each ATM link either as UNI or NNI. Flexi WCDMA BTS and S-AXC (stand-alone ATM cross-connect) support only the UNI cell header format. Flexi WCDMA BTS supports the whole VPI range, and VCI range per VP is 0 to 4095; the number of connections is limited. The RNC supports the whole VPI/VCI value range, but the installed memory limits the number of connections in an RNC/ATM module to 50000.

g ATM cell header (as defined in ITU-T Recommendation I.361) is defined with 8/12-bit VPI field and 16-bit VCI field.Full VPI range is supported. When the ATM interface is defined as UNI, the maximum-number of VPI bits is 8. When the interface is defined as NNI, the maximum number of VPI bits is 12.

The supported VCI range depends on the ATM network interface unit type:

With NPS1 and NPS1P units (STM-1/OC-3c), full VCI range is supported (up to 16VCI bits).

With NIS1 and NIS1P units (STM-1/OC-3c), partial VCI range is supported (up to 14VCI bits).

With NIP1 unit (E1/T1/JT1), partial VCI range is supported (up to 7 VCI bits).The network level planning determines how the ATM interface and its access profile and the connections should be created. For example, there can be many virtual paths witha

7 6 5 4 3 2 1 0

UNI: Generic Flow Control (GFC)

NNI: VPI

VPI

VPI VCI

VCI

VCI PTI CLP

HEC

Payload, byte 1

...

Payload, byte 48

Table 1 ATM cell header

DN70569254 15



few virtual channels inside each path, or only a few large virtual paths with numerous virtual channels inside each path.

The AXC default configuration reserves four bits for VPI values (0 to 15) and 8 bits for VCI values (0 to 127) per physical interface. The value range of AXC is configurable up to eight VPI bits. The combination of VPI and VCI values cannot exceed 13 bits.

ATM cells are discarded if VPI or VCI are unassigned or out of range. ATM cells are also discarded if the PTI (payload type) is invalid.

2.1.1.1 Payload Type Identifier (PTI)These three bits are used to characterize the type of payload, for example to indicate User Plane and Control Plane data.

2.1.1.2 Cell Loss Priority (CLP)The CLP bit can be used to indicate ATM cells as likely candidates for deletion if measures must be taken to avoid buffer overflows or congestion.

CLP is not supported in both the WBTS and RNC.

2.1.1.3 Header Error Correction (HEC)The transmitter generates a check sum over all remaining header bytes and sends it in the HEC field. The receiver uses the HEC field to verify that the cell header is not cor-rupted. The HEC field is also used to synchronize the receiver to the ATM bit stream. This is necessary because ATM cells do not have any dedicated start or end marking. For synchronization, the receiver opens a moving window of five-byte size and notices when the check sum generated over the first four bytes matches the value in the fifth byte. If this is successful for a defined number of ATM cells, the receiver can assume that it has found the correct boundaries between cells and is now synchronized.

2.1.1.4 Payload bytesThe payload of an ATM cell has a fixed size of 48 octets (bytes).

2.1.2 ATM virtual channel (VC)A VC is a point-to-point communication channel between VC end-points (VC connection termination points). In the WCDMA RAN, VC termination points are located in RNC, MGW, AXC within BTS, stand-alone AXC (S-AXC), SGSN and BTS / Flexi WCDMA BTS. In a VC termination point, the cell information field is exchanged between the ATM layer and the user of the ATM layer. A VCI identifies a particular VC for a given VP. A specific value of VCI is assigned wherever a VC is cross-connected in the network. The physical port that terminates a VC is identified by its ATM End System Address (AESA). AESAs must be unique across the whole RAN. VCs are configured (created and deleted) by network operators according to mid-term and long-term network plans. In the event of failure, ATM connections remain configured in all NEs, and their operational state values reflect their current conditions.

16 DN70569254



ATM description

A termination point for an ATM VP or ATM VC is responsible for checking the conditions of the connection, maintaining its status values, and for emitting alarms in the event of failures.

2.1.3 ATM virtual path (VP)A VP groups together a number of VCs that use the same route through the network between the VP end-points (VP connection termination points). In the WCDMA RAN, these VP termination points are located in the Flexi WCDMA BTS, RNC, MGW, and AXC. VP connections are supported as point-to-point connections only. Multicast or broadcast connections are not supported in the ATM network. A specific value of VPI is assigned wherever a VP is cross-connected in the network. A VP endpoint is the point where the VCI are originated, translated, or terminated.

In the RNC Element Manager, VP and VC end-points are managed with the ZLC (VP/VC Link Termination Point Handling) command.

2.1.4 VC BundleA VC bundle is a group of User Plane ATM VCs in the Iub interface for which a common PCR (VCCBundlePCR parameter) is defined. This means that unused capacity assigned to one of the bundled VCs can be used by other VCs of the same bundle, and at the same time the total traffic of the bundled VCs does not exceed the bundle's PCR. The bundles PCR must be smaller than the VPs PCR to leave capacity for Control Plane traffic and/or other User Plane traffic outside VC bundles. The VC bundling func-tionality serves to avoid traffic loss in the last mile due to congestion, making transport network dimensioning easier and more efficient. VC bundle is a Nokia Siemens Networks proprietary feature.

All VCs in a bundle must belong to the same Iub instance (that is, they must be termi-nated by the same BTS). The RNC supports two VC bundles per BTS. Configuring two VC bundles is useful if HSDPA traffic and DCH traffic use different physical paths, for example with Hybrid BTS Backhaul. In the BTS, these VC bundles are terminated in separate ATM interfaces. VC bundles can be used in both downlink and uplink. DL VC bundles are configured in the RNC, UL VC bundles are configured in the BTS. If VCs carrying R99 RT and NRT traffic are configured in the same uplink VC bundle, they must also be in the same downlink VC bundle.

The VCCInBundle parameter of an AAL2 VC determines whether the VC is not part of a VC bundle (value 0) or part of either bundle 1 or bundle 2. If a VC bundle is used for DL in the RNC, it is recommended for better efficiency to use also a UL VC bundle in the BTS.

The VC bundle is a part of the RAN1099: Dynamic Scheduling for HSDPA with Path Selection and RAN1100: Dynamic Scheduling for NRT DCH with Path Selection (in these feature descriptions, the RAS06 implementation is described). These features were introduced in RAS06 and further developed in RU10. The RU10 implementation of these features is described in Traffic control functions. A basic VC bundle feature is acti-vated if either RAN1099 or RAN1100 is activated. Full flexibility requires both RAN1099 and RAN1100 to be activated.

The VC bundle function of the RAN1100 feature also introduces a new way of perform-ing AAL2 CAC for NRT DCH downlink connections in the RNC. This is described in the section about ATM and AAL2 layer CAC.

DN70569254 17



The VCCBundleEBS (VCC Bundle Excess Bandwidth Share) parameter defines how excess bandwidth is shared between NRT DCH and HSDPA traffic in a congestion sit-uation. The parameter is taken into account only when both HSDPA and NRT DCH are carried in dedicated VCs in the same VC bundle. For more information, see VC bundle configurations rules when both RAN1099 and RAN1100 features are activated.

Some properties are different between DL VC bundles configured on A2SU units and DL VC bundles configured on NPS1 units: The A2SU unit has a minimum scheduling rate of 255 cps for UBR+ VCs and allo-

cates at least this much bandwidth even if MDCR is set to a smaller value, which in turn can cause the bundle's PCR to be exceeded.

Another A2SU restriction applies if RAN1099 is activated and RAN1100 is not acti-vated. In this case, AAL2 CAC is used to estimate the bandwidth requirements of the traffic types in the VC bundle, and the balance is controlled through the activity factor parameters for the various traffic types. If the NRT DCH activity factor is set too high, some reserved bandwidth will be unavailable for HSDPA traffic. If the NRT DCH activity factor is set too low, there is a possibility that R99 traffic might exceed the estimate made by CAC, and in consequence the total outgoing traffic may exceed the bundles PCR.

On A2SU units, the VCCBundleEBS parameter works as described in RAS06 doc-uments. On NPS1, VCCBundleEBS has no influence on reserving scheduling resources. VCCBundleEBS is taken into account only in AAL2 CAC where it defines the share of the excessive bandwidth given to NRT DCH traffic.

If RAN1100 is activated, and the VC bundle is configured on an A2SU unit, the estimate for RT bandwidth requirements is more accurate and thus the PCR is not likely to be exceeded. However, the activity factor for NRT DCH traffic should still be carefully matched to the real activity.

The NPS1 unit provides considerably more accurate rate limiting than the A2SU. When dynamic internal flow control (IFC) is enabled in the VC bundle, virtual sched-uling and virtual queues are used. The scheduling inside the VC bundle can be con-trolled through IFC profiles that you define with the ZLJP MML command.

If only the RAN1099 feature is activated, and two or more tolerant VCs of the same type (AAL2UPUsage) are configured in a VC bundle, the bandwidth is shared differ-ently between them on different interface units. The NPS1 scheduler is able to use the bandwidth efficiently according to the real activity. On A2SU units, the bandwidth is divided according to the number of admitted users in each VC. This means that on an A2SU unit, a tolerant VC cannot use the bandwidth left unused by another VC of the same type (AAL2UPUsage).

2.1.4.1 VC bundle configuration rules when only the RAN1099 feature is enabledEnabling VC bundle with the RAN1099: Dynamic Scheduling for HSDPA with Path Selection feature allows using flow control only for NRT HSDPA traffic but not for NRT DCH traffic. For RT HSPA traffic there is no internal flow control in the bundle, nor outside of the bundle. Table 2 Supported VC bundle configurations with RAN1099 shows the supported VC bundle configurations. The table applies for both NPS1 and A2SU units.

18 DN70569254



ATM description

The following rules apply: Any VC in the shown configurations can be left out of the bundle. For example, the

configuration #3 could also consist of just the DCH+Stringent&Stringent bi-level, HSDPA+Tolerant VCs, and HSUPA+Tolerant VCs.

There can be one or more VCs of each type.As the table shows, the HSPA traffic has to be carried in either the dedicated HSDPA and HSUPA VCs or in a shared HSPA VC. Also the path types must not overlap, that is, you cannot have HSPA+Stringent&Stringent bi-level and HSPA+Stringent bi-level in the same VC bundle.

For more information on the RAN1100 and RAN1099 coworking, see VC bundle config-urations rules when both RAN1099 and RAN1100 features are activated.

2.1.4.2 VC bundle configuration rules when only the RAN1100 feature is enabledEnabling VC bundle only with the RAN1100 feature allows bundling the DCH traffic only. In this case, it is not possible to include VCs carrying NRT HSDPA or NRT HSUPA traffic in the VC bundle configured. Table 3 Supported VC bundle configurations with RAN1100 shows the supported VC bundle configurations.

AAL2 UP Usage

Path Type combinations Config #1

Config #2

Config #3

Config #4

Config #5

Config #6

ATM service

category

DCH Stringent&Stringent bi-level x x x x x CBR

HSDPA Tolerant x x UBR+

HSUPA Tolerant x x UBR+

HSPA Tolerant x x x x UBR+

HSPA Stringent x CBR

HSPA Stringent&Stringent bi-level x CBR/UBR+

HSPA Stringent bi-level x CBR/UBR+

DCH&HSPA Stringent&Stringent bi-level x CBR

DCH&HSPA Stringent CBR

DCH&HSPA Stringent bi-level CBR/UBR+

HSDPA Stringent&Stringent bi-level x CBR/UBR+

HSUPA Stringent&Stringent bi-level x CBR/UBR+

Table 2 Supported VC bundle configurations with RAN1099

AAL2 UP Usage

Path Type com-binations

Config #1

Config #2

Config #3

Config #4

ATM service

category

DCH Stringent x x x x CBR

Table 3 Supported VC bundle configurations with RAN1100

DN70569254 19



The following rules apply: Any VC in the shown configurations can be left out of the bundle. For example, the

config #2 could also consist of just the DCH+Stringent, DCH+Stringent bi-level and HSPA+Stringent VCs.

There can be one or more VCs of each type.In a bundle, the RT DCH traffic is scheduled first because of the tightest QoS require-ments. If the DCH+stringent bi-level VC's PCR is set equal to the bundle PCR, the NRT DCH traffic can use all available bandwidth.

For more information on the RAN1100 and RAN1099 coworking, see VC bundle config-urations rules when both RAN1099 and RAN1100 features are activated.

2.1.4.3 VC bundle configurations rules when both RAN1099 and RAN1100 features are activatedWith VC bundling, it is possible to define a common peak cell rate (bundle capacity) for a group of VCs, so that the total capacity of the bundled VCs does not exceed the con-figured bundle capacity. This configuration offers the possibility to tune the traffic flow according to the capacity on the last mile to the BTS. At the same time, the AAL2 CAC also uses the bundle capacity as a reference instead of the individual UBR+ VCs MDCR values.

The VC bundling concept is a part of two features: RAN1099: Dynamic Scheduling for HSDPA with Path Selection and RAN1100: Dynamic Scheduling for NRT DCH with Path Selection. These features have individual configuration rules, but when both features are enabled, more transport configuration options become available. These features were introduced in RAS06 and further developed in RU10. Their RU10 implementation is described in WCDMA RAN ATM Transport.

Both features have individual configuration rules, but when both features are enabled, more transport configuration options become available. When a dedicated HSDPA + Tolerant VC or DCH + Stringent bi-level VC is included in a bundle, the RNC internal flow control is enabled. An HSDPA + Tolerant VC or DCH + Stringent bi-level VC can only be used within a bundle if the respective features are enabled. Also, the DCH +

DCH Stringent bi-level x x x x UBR+

HSPA Stringent x UBR+

HSPA Stringent&Strin-gent bi-level

x CBR / UBR+

HSPA Stringent bi-level x CBR / UBR+

HSDPA Stringent&Strin-gent bi-level

x CBR / UBR+

HSUPA Stringent&Strin-gent bi-level

x CBR / UBR+

AAL2 UP Usage

Path Type com-binations

Config #1

Config #2

Config #3

Config #4

ATM service

category

Table 3 Supported VC bundle configurations with RAN1100 (Cont.)

20 DN70569254



ATM description

Stringent bi-level VC and HSDPA/HSPA/HSUPA + Tolerant VC must always be of UBR+ type inside the bundle. DCH + Stringent VC and DCH + Stringent & Stringent bi-level VC must be CBR. The allowed configurations are shown in Table 4.

* Contains one of the following AAL2 path usages with the AAL2 path type either Tolerant or Stringent bi-level & Tolerant:

HSDPA VCs HSDPA and HSUPA VCs HSPA VCs

Options 3 to 7 are suitable if RAN1004: Streaming QoS for HSPA is activated.

g The VCs with the same AAL2 VC type must belong to the same VC bundle, or be outside the bundle. For example, if HSPA + Tolerant is included in the bundle, all the VCs with the same VC type must be included in the VC bundle.

2.1.4.4 VC Bundle and VP traffic shapingDL VC bundles are supported with shaped VPs and with unshaped VPs. This applies to both NPS1 and A2SU (NIP/NIS) hardware units. Shaped VP

If the VP is shaped, the bundled User Plane VCs can belong to only one shaped VP. In addition to User Plane VCs, there can be O&M and signaling VCs in the same shaped VP. On NPS1 units, VP shaping maintains accurate VP throughput while the PCR of

the VC bundle may be temporarily exceeded. If the bundle PCR is exceeded,

VC bundle combination

VC type 1 2 3 4 5 6 7

AAL2UPUsage AAL2PathType

RAN 1099 RAN 1100

RAN 1099 RAN 1100

RAN 1099 RAN 1100

RAN 1099 RAN 1100

RAN 1099 RAN 1100

RAN 1099 RAN 1100

RAN 1099 RAN 1100

DCH Stringent X

DCH Stringent bi-level X X

HSDPA Tolerant/Strin-gent bi-level

X * X * X * X * X *HSUPA Tolerant/Strin-gent bi-level

HSPA Tolerant/Strin-gent bi-level X

DCH & HSPA Stringent & Strin-gent bi-level X

DCH & HSPA Stringent X X

DCH & HSPA Stringent bi-level X X X X

Table 4 Supported VC bundle configurations depending on the availability of Dynamic Scheduling features RAN1099 and RAN1100

DN70569254 21



the VP shaping function prioritizes traffic according to existing prioritization mechanisms.

On A2SU units, VP shaping maintains accurate VP throughput. The VC bundle-rate-limiting accuracy depends on the used VC configuration. If both HSDPA and NRT DCH internal flow controls (IFC) are enabled, the bundle PCR may not be exceeded. With the NRT IFC disabled, the bundle PCR may be exceeded, if real bandwidth usage is higher than the estimated usage. If the bundle PCR is exceeded, the VP shaping function prioritizes traffic according to existing priori-tization mechanisms.

Unshaped VPIf the VP is unshaped, the bundled VCs can belong to more than one unshaped VP.NPS1 units provide accurate rate limiting for the bundled VCs.On A2SU units, the bundle rate limiting accuracy depends on the used VC configu-ration. If both HSDPA and NRT DCH internal flow controls (IFC) are enabled, the bundle PCR is not exceeded. If NRT IFC is disabled, the bundle PCR may be exceeded if the real bandwidth usage exceeds the estimated usage. If the bundle PCR is exceeded, the VP shaping function prioritizes traffic according to existing pri-oritization mechanisms.

2.1.5 Configuration of ATM VCs and VPsIn the WCDMA RAN, ATM VCs and VPs are permanent connections. They are config-ured (established), modified, and released by operators. This can be done either from the local element manager (EM), via a remote management session, or via a network management system (NMS). Modifications of existing ATM connections and new con-figuration requests need to be accepted by the ATM connection admission control (CAC) function of the NE. ATM CAC determines if the requested connection in the egress side of the NE can be supported. Modification of ATM connections is restricted to their peak cell rate (PCR). Other properties can only be changed by deleting a con-nection and creating a new one with the desired properties.

In WCDMA, AAL2 is the transport layer that is used dynamically, with resource alloca-tion controlled through transport signaling (that is, AAL2 signaling). AAL2 service end-points can setup and delete AAL2 links according to current traffic requirements. With support of Q.2630.2 this capability is extended to the modification of the bandwidth of existing AAL2 links. All ATM VCs for AAL5 and for AAL2 are of the permanent type. As a result, there is no ATM connection control signaling capability in the system.

2.1.6 Hierarchy of ATM related entitiesWCDMA platform software is based on the Object Oriented Programming (OOP) scheme. The properties (attributes and activities) of software entities are defined in abstract class definitions, which are the basis for creating "objects", each representing one instance of a class. Classes can inherit properties from parent classes and to sub-classes. This results in a hierarchy of class definitions, and a hierarchy of objects in the platform's database. As a consequence, objects in the database must be created starting with parent objects, and must be deleted starting from the bottom of the hierar-chy.

A sample and generic object hierarchy is shown below. Actual implementation is more complex and varies between NE types:

22 DN70569254



ATM description

ATM interface+--Access profile related to an ATM interface. . +-- VP link termination point. . . . +-- VP connection. . . . . . +-- ATM VP cross-connection. . . . . . +-- VC link termination point. . . . . . . . +-- VC connection. . . . . . . . +-- ATM VC cross-connection

2.1.7 ATM cross-connectionATM cross-connections are relay functions that transfer a data stream from one VP (VC) to another VP (VC) without acting as termination points. ATM cross-connections are supported by the AXC and AXCF hardware components. The AXCF unit is introduced by the RAN1701: AXCF unit for UltraSite WCDMA BTS feature. The AXC/AXCF inside a WBTS can act in both ways: It terminates VCs/VPs addressed to itself. It multiplexes (cross-connects) VCs/VPs coming from concatenated BTSs in direc-

tion to the RNC.

In a VP cross-connection only the VPI value of incoming ATM cells is translated to the VPI value for the outgoing cells. In VC cross-connections both the VPI and VCI of incoming ATM cells are translated.

The ATM functionality inside the RNC is mainly intended to terminate ATM connections but it may also be used as VP/VC cross-connect. The RNC provides VP cross-connects only in the STM-1 interfaces, and for CBR VP/VCs only.

In the RNC Element Manager, cross-connections are managed through the ZLB (ATM Semi-Permanent Cross-connection Handling) MML command group.

2.1.8 ATM service categoriesThe ATM layer supports the CBR (constant bit rate) and Unspecified Bit Rate (UBR/UBR+) ATM service category. CBR connections are assigned a fixed, guaranteed bandwidth, irrespective of actual demand. The CBR service category may be applied for VPs and VCs.

UBR connections do not guarantee any minimum capacity, and can provide as their maximum capacity (PCR, peak cell rate) all capacity that is otherwise left unused. UBR connections that support guaranteeing a minimum capacity, as specified by the Minimum Desired Cell Rate (MDCR) parameter, are also known as UBR+ connections. Thus, UBR is a subset of UBR+; a pure UBR service can be created by setting its MDCR=0. The MDCR is not subjected to the usage parameter control function. A UBR+ VC can at maximum use up all capacity of the ATM VP.

For CBR VPs, ATM CAC does not accept a VC inside a VP if the sum of the VC PCRs (and the MDCRs of all UBR+ VCs) exceeds the VP's PCR. For UBR+ VPs, ATM CAC does not accept a VC inside a VP if the sum of MDCRs exceeds the VP's MDCR.

ATM CAC does not accept a VP inside an ATM interface if the sum of all guaranteed bit rates for VPs (i.e. the sum of all CBR PCRs and UBR MDCRs) exceeds the guaranteed bandwidth of the ATM interface. For a CBR VP, the guaranteed bandwidth is its peak cell rate (PCR). For a UBR+ VP, the guaranteed bandwidth is its MDCR. A CBR VP may contain both CBR and UBR+ VCs. A UBR+ VP may contain only UBR+ VCs.

DN70569254 23



Support of UBR+ VP connections in the RNC is introduced with RU10.

To avoid loss of ATM cells, the maximum capacity of an UBR+ connection is enforced by traffic shaping functions in the transmitting NE (for traffic shaping in general, see Traffic Shaping), as follows: UltraSite WCDMA BTS/AXC:

In the Control Plane, shaping is performed on the PCR of UBR+ VC Connections applied for DCN, AAL2 signaling, NBAP signaling and Neighbor Node Discovery

In the User Plane, if BTS AAL2 multiplexing is disabled then the PCR of a User Plane UBR+ VC Connection is subjected to shaping. Otherwise no shaping of User Plane UBR+ VCs takes place.

Flexi WCDMA BTS does not shape the PCR of any UBR+ VC or VP connections. PCR configuration parameters are accepted by NetAct tools but do not take effect.

The RNC shapes the PCR of all UBR+ Virtual Channel Connections. RNC, AXC, Flexi WCDMA BTS support UBR+ on Iub interfaces. BTS and AXC do not support shaping for VP and UBR+ User Plane connections.The implementation of UBR+ connections with respect to the parameters PCR and MDCR has the following characteristics: CBR connections are served before any UBR+ connection, independent of their

MDCR. The minimum bandwidth for UBR+ connections is equal to the MDCR plus a share

of the excessive bandwidth. In the borderline case where the sum of the UBR+ MDCRs and the CBR PCRs is

equal to the available bandwidth, a UBR+ connection with MDCR=0 does not get any guaranteed service.

2.1.8.1 Excessive Bandwidth Share among UBR+ connections (UBRshare)You can share the excessive bandwidth above the guaranteed bit rates among UBR+ connections according to your own policy. The excessive bandwidth is the bandwidth of an ATM interface that is not reserved by ATM CAC for CBR or UBR+ connections. The bandwidth that a UBR+ connection gets is therefore given as its MDCR, plus a share of the excessive bandwidth. The excessive bandwidth depends on the traffic load condi-tions. If some CBR or UBR+ connections do not use their reserved bandwidth, then this bandwidth is also shared among UBR+ connections that in turn can send data at a higher rate than is indicated by their MDCR. The distribution of excessive bandwidth to UBR+ VCs is controlled by the UBRshare parameter.The scope of excessive bandwidth sharing depends on whether a VP is shaped or unshaped: UBRshare affects all UBR+ VCs within a shaped VP (for example, shaped CBR VP), or in case of an unshaped VP, (for example, unshaped UBR+ VPC) all UBR+ VCs within the ATM interface.

UBR+ support is provided by the following features: RAN1192: UBR+ for Control Plane and Iu/Iur User Plane. This feature is part of

Operational Software and can be used without licensing. RAN1095: UBR+ for Iub User Plane.

24 DN70569254



ATM description

2.1.8.2 UBR+ support for User Plane, Control Plane and management planeUBR+ is supported for all applications on Iub, Iur, Iu-CS, Iu-PS, Iu-BC interfaces and can be used independently on these interfaces.

There is full flexibility to map applications to different ATM service categories. On Iub, the UBR+ service category improves the call set-up time if the Iub links are not over-loaded. UBR+ User Plane support is mainly intended for HSPA and NRT-DCH, but not limited to these. Although it is not recommended, you can also use UBR+ for RT-DCH.

DN70569254 25

WCDMA RAN ATM Transport Interfaces and protocols

Id:0900d805808098f1Confidential

3 Interfaces and protocolsFigure 1 UMTS protocol model shows the general protocol model for the Iu, Iur, and Iub interfaces of a UMTS network. In the vertical dimension, the interface consists of two layers, the transport network layer, and, on top of, it the radio network layer. The trans-port network layer consists of User Plane and its own Control Plane. The radio network layer consists of the radio network Control Plane and the User Plane. Both planes are users of the transport network layer.

The service provided by the transport network for the UMTS on a given interface is a transport bearer, which enables end-to-end connectivity between the Core Network and the Uu interface. Transport bearers are either signaling bearers or data bearers. For example, the Control Plane protocols of the radio network layer (RNSAP for Iur, NBAP for Iub, RANAP for Iu) are carried on a signaling bearer provided by the transport network layer.

Figure 1 UMTS protocol model

The transport network Control Plane does not include any radio network layer informa-tion, and is completely located in the transport network layer. It includes the ALCAP pro-tocol(s) needed for setting up the transport bearers (data bearers) for the User Plane. It also includes the appropriate signaling bearer(s) needed for the ALCAP protocol(s).

The lower layers of the transport network layer are ATM, AAL and IP. IP transport is described in the WCDMA RAN IP transport functional area description. The choice between ATM and IP can be made individually for each Iub, Iur, and Iu instance.

3.1 Protocol stacks in RAN interfaces

3.1.1 Protocol stack for Iub interfacesThe Iub interface connects RNC and WCDMA BTS. Figure 2 Iub ATM protocol stack shows its protocol stack.

26 DN70569254



Interfaces and protocols

Figure 2 Iub ATM protocol stack

g Starting from RAS06 RNC is implementing Path Type IE according to ALCAP Q.2630.2. protocol for Iub interface.3.1.2 Protocol stack for Iur interfaces

The Iur interface connects two RNCs. Iur is used to support soft handovers within the RAN. All necessary data from the serving RNC (SRNC) is transferred to the drifting RNC (DRNC) across the Iur interface. Iur is an open and standardized interface.

Figure 3 Iur ATM protocol stack

g Starting from RU20 On Top RNC is implementing Path Type IE according to ALCAP Q.2630.2. protocol for Iur interface.

DN70569254 27



3.1.3 Protocol stack for Iu interfacesThe Iu interface between the core network and the RNC is divided into two separate functional parts, Iu-CS and Iu-PS, to support circuit-switched and packet-switched services to the core network.

Figure 4 Iu-CS ATM protocol stack

g Starting from RU20 On Top RNC is implementing Path Type IE according to ALCAP Q.2630.2. protocol for Iu-CS interface.The Iu-PS interface connects the SGSN to the RAN. It carries data and signaling, and also the direct communication between the SGSN and the UE; communication is trans-parent to the RNC.

Figure 5 Iu-PS ATM protocol stack

28 DN70569254




3.1.4 Protocol stack for the Iu-BC interfaceThis interface connects the RNC to the SMS Cell Broadcast Center.

Figure 6 Iu-BC ATM protocol stack

3.1.5 Protocol stack for the O&M interfaceThis interface connects the RAN NEs with the operator's management platform, for example NetAct. O&M functions are split into logical O&M and implementation-specific O&M. The Logical O&M functions are standardized by 3GPP as part of the NBAP (3GPP TS25.433), whereas the implementation-specific O&M is left non-standardized by 3GPP. The transport layer aspects of implementation-specific O&M are specified in 3GPP TS25.442. Logical O&M shares the same transport bearer as other Common NBAP communication. Implementation-specific O&M is carried using the classic IP over ATM method according to RFC2225.

Figure 7 O&M interface protocol stack

3.2 IP and ATM Transport OptionStarting in RU10, IP transport option and ATM transport option are supported simulta-neously in the RNC interfaces according to 3GPP, both at the network element level and at the logical interface level.

With the RAS05.1 RAN165 IP Based Control Plane at Iu and Iur feature, you can use IP transport for the Control Plane on Iu-PS, Iu-CS, and Iur interfaces while using ATM transport for the User Plane.

Since RU10, different instances of one logical Iub interface (for example towards differ-ent WBTSs) are able to use either IP transport option or the ATM transport option, but

DN70569254 29



not both simultaneously (except if Dual Iub is enabled). For Iur, Iu-CS and Iu-PS, it is possible to carry control plane and user plane either over ATM or over IP, independently of the transport technology of the other plane.

With the RAN1449: Dual Iub for Flexi WCDMA BTS or RAN1633: Dual IP for UltraSite WCDMA BTS feature activated, IP and ATM transport options for the User Plane are supported simultaneously in the BTS and the RNC over the same logical interface. With these features, only HSPA and NRT DCH traffic can be carried over IP. With the Dual Iub features you can select which traffic types go to the ATM path. If you want to further divide the ATM traffic into dedicated VCs, you need a RAN759: Path Selection license.

The chosen Iub configuration is reflected in the RNC as follows:

Full ATM IubA COCO object is assigned to the WBTS object. No IPNB can be assigned to the WBTS. IPNBId is set to not defined.

Dual IubA COCO object assigned to the WBTS object. No IPNB can be assigned to the WBTS (since the control plane is still on the ATM path). IPNBId is set to not defined.

Full IP based IubNo COCO object can be assigned to the WBTS object. COCOId is set to not defined. ATMIf, VPI, VCI are set to not defined. An IPNB object is assigned to the WBTS object. The IubTransportMedia parameter (in the WBTS object) can only be set to IP Iub for the User Plane connections.

The RAN1878: IP over ML-PPP on E1/T1 Interfaces feature allows to carry IP traffic on top of PPP protocol over one or multiple PDH links. It is used to enable IP transport on PDH-based infrastructure like TDM microwave radios and PDH interface units in the BTS.

3.2.1 Iub Transport Media SelectionTransport media selection allows to simultaneously exploit ATM-based and IP-based transport networks on Iub. The key features for this functionality are RAN1449: Dual Iub for Flexi WCDMA BTS (from RU10) and RAN1633: Dual Iub for Ultrasite WCDMA BTS (from RU20).

The HSPA and the NRT DCH transport bearers can be set up in either the ATM or IP transport network on Iub. Transport media selection is a BTS-specific function in the RNC. As a default configuration, all transport channels are carried over ATM. You can configure the traffic type to be carried over the IP transport, based on the transport channels type (HSDPA, HSUPA or DCH), radio bearer type (Signalling Radio Bearer, RAB), and UMTS Traffic Class as follows:

With RAN1449: Dual Iub for Flexi WCDMA BTS and RAN1633: Dual Iub for Ultrasite WCDMA BTS, you can configure the transport media for DCH NRT, HSDPA NRT, HSUPA NRT; with the restriction that if DCH NRT is configured to be carried over IP, both HSDPA and HSUPA NRT must also be carried over IP.

30 DN70569254




In case of support of both RAN1449 and RAN1004: Streaming QoS for HSPA, or both RAN1633 and RAN1004: Streaming QoS for HSPA, transport media selection is extended and allows independent configuration for HSDPA Real Time (Stream-ing), HSDPA Non Real Time (Interactive, Background) traffic, HSUPA RT, HSUPA NRT and DCH NRT; with the restriction that if DCH NRT is configured to be carried over IP, both HSDPA and HSUPA NRT must also be carried over IP.

With the feature RAN1470: HSUPA 2ms TTI or RAN1201: Fractional DPCH (SRB on HSPA), Dual Iub allows to separate the following traffic classes: SRB HSPA Associated DL SRB DCHWhen the SRB on HSPA is carried on top of IP path the combinations 2-5 from the table Allowed combinations for transport bearers on IP transport network are recom-mended to be used for the user data/RAB traffic.

Depending on the selected transport technology, the transport bearer is established using either ALCAP signaling (ATM transport) or NBAP Control Plane signaling (IP transport) as summarized in the figure Transport technology selection with RAN1449 and RAN1633.

Figure 8 Transport technology selection with RAN1449 and RAN1633

The Dual Iub feature is available for Flexi WCDMA BTS and UltraSite WCDMA BTS. The provision of an "All IP" based transport network on Iub is introduced in RU10 for Flexi WCDMA BTS with RAN74, and in RU20 for Ultra WCDMA BTS with RAN1634. In

PS NRT DCH

NRT HSDPA

NRT HSUPA

Streaming HSDPA

Streaming HSUPA

1. HSDPA non-realtime traffic offload

x

2. HSPA non-realtime offload x x

3. HSPA traffic offload x x x x

4. PS non-realtime traffic offload x x x

5. Full PS traffic offload x x x x x

Table 5 Allowed combinations for transport bearers on IP transport network

RAB assignmentUL/DL capacity request

-> HSPA transport bearer setup

ATM / IPATM IP

NBAP: RL setup,RL Recon. Prepare(TNL QoS-AAL2pr )i

ALCAP: ERQ / ECF(Standard AAL2 PT)

RAB priority to AAL2 priority +AAL2 PT Mapping table

NBAP: RL setup,RL Reconf. Prepare(TNL QoS-DSCP)

RAB priority to DSCPmapping table

AAL2 priority and AAL2 PT retrievedfor ALCAP signaling

DSCP retri ved forNBAP signaling

e

Transport mediaselection

DN70569254 31



this case, all Iub traffic (both Control Plane and User Plane) is carried over an IP based transport network.

With a RU30 feature RAN2269: Flexible Dual Iub OAM path assignment Management Plane can be alternatively configured to IP-over-Ethernet transport, while previously it was statically configured to IP-over-ATM.

3.2.2 IP Network Failure Handling in Dual Iub or Hybrid Backhaul Config-urationsWith a Hybrid Backhaul feature configuration, an IP path failure is detected by the BTS and by the Pseudowire Gateway by means of a BFD session. Once the BFD state indi-cates that the IP path on Pseudowire is broken, the Pseudowire Gateway initiates ATM-RDI/AIS towards the RNC, which in turn causes the related AAL2 paths to go into blocked state. The blocked AAL2 paths are not selected for new AAL2 connections in the radio link setup.

In case of a Dual Iub configuration, an IP network failure can also be detected in the RNC by means of a BFD session. In RU10, if the BFD entity is linked to the IP Based Route entity in the RNC IP layer configuration, a BFD alarm is raised but the faulty IP path is still selected for new transport bearers. In RU20, if the BFD entity is linked to the IP Based Route entity in the RNC IP layer configuration, new transport bearer setup to the IP path is blocked because of the BFD state. In both Hybrid Backhaul and Dual Iub cases, if the RAN1578: HSPA transport fallback feature is not activated, the existing HSPA connections using the IP transport network are dropped. Re-established radio links are configured on NRT R99 DCH on the ATM path (only if NRT R99 DCH is con-figured to ATM), and from there, the RNC tries to upgrade them back to HSPA channel type again.

With the RAN1578: HSPA transport fallback feature activated, you can define which traffic classes are protected and treated by the feature. HSPA Transport Fallback can be applied for both Hybrid Backhaul and Dual Iub feature configurations. In the event of interruption of the IP network, the affected radio links are dropped. If the affected HSPA calls are protected, the RNC re-establishes them over ATM network without class deg-radation. New HSPA calls are established over ATM network. When the IP network is available again, ongoing protected traffic is not switched back to the IP network but newly established Radio Links are set up on the IP path. This means that the PS RABs will be gradually allocated back to IP network along with normal UE state change proce-dures for example. For more information on HSPA Transport Fallback functionality, see Application layer protection in WCDMA RAN Network Protection.

For detail information on how an IP link failure is handled by the RNC in Dual Iub sce-nario, see Table 6 NRT HSPA call establishment/re-establishment in Dual Iub scenario in case of IP network failure.

release new NRT HSPA calls ongoing NRT HSPA calls

RU10 1. The faulty IP based route is still selected for new transport bearers.2. New transport bearers keep being established with zero throughput over IP transport.

Table 6 NRT HSPA call establishment/re-establishment in Dual Iub scenario in case of IP network failure

32 DN70569254




* BFD session must be bound to the respective IP based route. NRT DCH must be configured to be carried over ATM.

RU20 * 1. The faulty IP based route is not selected for new transport bearers.

2. New calls are established as NRT DCH over ATM transport.

1. The ongoing calls are re-established as NRT DCH over ATM transport.

2. The RNC starts regular channel type switch attempts from DCH to HSPA, which fail internally in RNC as long as IP network is down (that is, as long as IP based route is unavailable because of BFD session being down).The throughput of this call and other ongoing calls is not affected by these channel type switch attempts.

RU20 * with RAN1578

If NRT HSPA traffic type is protected, new calls are established as NRT HSPA over ATM trans-port.

If NRT HSPA traffic type is protected, ongoing calls are re-established as HSPA over ATM transport.

If NRT HSPA traffic type is unprotected, the system behaves as in RU20.

release new NRT HSPA calls ongoing NRT HSPA calls

Table 6 NRT HSPA call establishment/re-establishment in Dual Iub scenario in case of IP network failure

DN70569254 33

WCDMA RAN ATM Transport Signaling in the ATM network

Id:0900d805808c5f06Confidential

4 Signaling in the ATM networkThe WCDMA ATM layer provides signaling bearers for upper protocol layers. Signaling for the ATM layer itself is not required since ATM VPs and VCs are permanent, and con-figuration changes are performed either locally (on site) or through connections in the management plane. In the ATM Adaptation protocol layer, AAL2 links are dynamically set up and deleted during network operation; this requires signaling message exchange between NEs.

AAL2 signaling data is carried in AAL type 2 VCs. These VCs are managed in the RNC EM via the ZLS (AAL2 Signaling Handling) MMI command. AAL2 signaling links can be created, deleted, blocked, unblocked like other VCs. In addition, they can be reset, and ongoing resets can be stopped. When acting as DRNC, the RNC also supports signal-ling radio bearer (SRB) modification between 13.6 kbps and 3.4 kbps when requested from an SRNC.

AAL2 signalingAAL2 signaling is employed for managing the AAL2 connections between AAL2 termi-nation points. It is performed using either AAL2 signaling capability set 1 (CS1, ITU-T Recommendation Q.2630.1) or capability set 2 (CS2, ITU-T Recommendation Q.2630.2). Most notably, with CS1 signaling, AAL2 connections cannot be modified without service interruption; they must instead be deleted and created again with the desired properties. CS2 modification of AAL2 connections is not supported, but signal-ling of CS2 path type IE is supported.

The AAL2 signaling protocol uses the AAL2 Service Endpoint Address (A2EA, embedded E.164 or NSAP addressing). This address must be known in a source NE when sending an AAL2 Establish Request (that is, connection establishment) message. The A2EA that is used in the transport bearer setup is assumed to be provided by the destination node through UTRAN control plane signaling. The A2EA is analyzed in order to identify the target for routing the AAL2 connection.

It is possible to have NEs with Q.2630.1 (CS1) and Q.2630.2 (CS2) capabilities in the same network. To ensure backward compatibility with NEs (AAL2 end-points) support-ing only CS1, the NEs supporting CS2 need to properly set the 'compatibility field' that is provided for the signaling message and for individual parameters. The compatibility field contains 8 bits which define the receiving NE's behavior when dealing with the sig-naling message.

AAL2 signaling for Iur and Iu-CSRNC supports ITU-T Q.2630.2 AAL Type 2 QoS Code Point (AAL2 Path Type) signalling over the Iur and Iu-CS interfaces.

From RU20 On Top onwards the SRNC AAL2 PT signalling is present as a generic func-tionality without a possibility of separately activating or disabling. To ensure backward compatibility with NEs (AAL2 end-points) supporting only CS1, RNC sets the compati-bility field to discard IE.

From RU30 EP1 onwards the SRNC AAL2 PT signalling is operator-configurable and has to be separately activated per neighbor network element with the RNW IUR and IUCS object class parameters.

In the DRNC role NSN RNS is capable to receive any AAL2 PT value without effect to call processing or system performance.

34 DN70569254


Id:0900d805808c5f06Confidential

Signaling in the ATM network

The AAL2 PT signalling is used for example in case of common Iur and Iu-CS transport network, where the AAL2 PT based AAL2 switching is applied. In case the AAL2 PT sig-nalling is activated, the following values are signalled by the SRNC within the ALCAP ERQ.

The bearer type to AAL2 PT value allocation is based on the traffic characteristics description within the ITU-T I.356:

Stringent class: SRB, AMR, UDI (R99 RT), CS over HSPA, Iu-CS Tolerant class: HSPA Interactive / Background (NRT HSPA) Stringent bi-level class: R99 PS Interactive/Background (includes associated UL

DCH for HSDPA), Streaming HSPA

The above list contains the whole set of bearer types to AAL2 Path Types mapping. For the actual traffic types supported over the Iur interface, see the RAN1231: HSPA over Iur feature documentation.

DN70569254 35

WCDMA RAN ATM Transport Quality of Service (QoS)

Id:0900d805807459e2Confidential

5 Quality of Service (QoS)The main service of UMTS is to provide a connection between two end-points with a certain QoS. For this purpose, UMTS defines a set of UMTS QoS classes which are: conversational, streaming, interactive, background. The UMTS part of an end-to-end connection of a desired UMTS QoS class is provided by an UMTS bearer service. This UMTS bearer service consists of a Radio Access Bearer (RAB) service and a Core Network Bearer service. A RAB, in turn, consists of a Radio Bearer and an Iu Bearer. All these bearers are carried through the network by means of transport bearers. The pro-vision of a certain UMTS QoS class therefore requires that the properties of all interme-diate bearer services be matched to its requirements. Consequently, UMTS defines a mapping table between the UMTS QoS classes and RAB attributes, and another mapping table between RAB attributes and transport bearer properties. For ATM as the transport network layer, a transport bearer is characterized by its ATM service category, its traffic parameters, and its QoS parameters. For AAL2 bearers, the corresponding QoS property is the path type value which can be stringent, stringent bi-level, or tolerant.

Table 7 UMTS QoS classes shows the UMTS QoS classes and examples.

[3GPP TS23.107] also defines the relationships between UMTS QoS classes and RAB attributes.

If IP over Ethernet is chosen as the transport network mechanism, a similar chain of mapping of service properties can be performed between RAB attributes and the DSCP, PHB and VLAN priority values of IP packets, in order to define QoS properties in all protocol layers. For details, see the WCDMA RAN IP transport functional area descrip-tion.

At the set-up time of an ATM connection, a traffic contract is put into place that specifies the desired ATM service category, the desired Quality of Service (QoS), the traffic parameters, and associated tolerance values. ATM connection admission control (CAC) uses the traffic parameters to check whether the requested QoS can be guaranteed with the available resources. Usage Parameter Control (UPC) uses the traffic parameters and their associated tolerance values to check whether the actual incoming traffic is compliant to the specified traffic parameters. The ATM traffic parameters for a network

Traffic class Conversational class

(Conversational RT)

Streaming class(Streaming RT)

Interactive class(Interactive best

effort)

Background (Background best

effort)

Fundamental char-acteristics

Preserve time relation (variation) between informa-tion entities of the stream?

Conversational pattern (stringent and low delay)

Preserve time relation (variation) between informa-tion entities of the stream

Request response pattern. Preserve payload content

Destination is not expecting the data within a certain time.

Preserve payload content

Sample application Voice Streaming video Web browsing Background download of emails

Table 7 UMTS QoS classes

36 DN70569254



Quality of Service (QoS)

element do not contain end-to-end objectives such as end-to-end delay. End-to-end QoS objectives are subject of network planning.

DN70569254 37

WCDMA RAN ATM Transport Resource state values of ATM entities


6 Resource state values of ATM entitiesResource state attributes provide detailed information about the current condition of network resources. Within the WCDMA NEs, most physical and logical entities support such attributes. State values are initialized at startup or creation time, and are modified either by actions of the operator (administrative state: locking and unlocking), or as a consequence of events occurring during operation (operational state, for example because of hardware failures).

6.1 Administrative stateThe administrative state of an ATM resource can take on the following values: locked

The locked state indicates a condition in which the service has been stopped by means of a command. The device or resource is out of service. In this state, diag-nosis, replacement and other tasks can be performed on it.

unlockedThe unlocked state indicates that the device is in service. Providing network services is only possible if the resource is unlocked. In this state, operation and maintenance tasks cannot be performed on it.

shutdownThe service continues performing services for existing users, but does not accept any new users. This value can be set on the local side and is shown as remotely blocked on the remote side. This value is supported by ATM interfaces, VPs and VCs.

remotely blockedThis value is used when performing a shutdown of ATM VCs without interrupting user traffic. It is shown when a shutdown is initiated by the remote side.

ATM interfaces, VP connection termination points, and VC connection termination points support the administrative state value.

In the RNC Element Manager, the administrative state for ATM interfaces is managed using the ZLAS MMI command.

6.2 Operational stateVP and VC connection termination points in all NEs support the operational state value. This value can be either of: disabled

The state value disabled indicates that the resource is totally inoperable and unable to provide service.

enabledThe state value enabled indicates that the resource is fully or partly operable and able to provide service.

n/a.The n/a (not applicable) value is assigned to entities that are not yet created in the NE's database.

The operational state of an ATM entity is changed to reflect its current capabilities. Changes of the operational state can be caused by faults and alarms, for example as a result of an ATM OAM functions such as AIS/RDI or Continuity Check. The cause for a

38 DN70569254



Resource state values of ATM entities

change can be located in the entity itself or in another, related entity. For example, a fault in a Physical layer trail termination point (PhyTTP) leads to the operational state disabled in both the PhyTTP and the related ATM VC (F3 level).

OAM flow level

From To Substate Reason Notifications

F3 N/A Enabled Created OAM supervision started success-fully for an ATM interface

Main state enabled, substate created

F3 N/A Disabled Created OAM supervision started success-fully for an ATM interface - Physical resource faulty


F3 Enabled Disabled Phy defect The operational state of the underly-ing PhyTTP changed from enabled to disabled

Main state disabled, substate physical defect

F3 Disabled Enabled Unspecif The operational state of the underly-ing PhyTTP changed from disabled to enabled

Main state enabled, substate unspecified

F4 N/A Enabled Created OAM supervision started success-fully for a VP connection termination point (VC or VP switched)


F4 Enabled Disabled AIS/RDI/LOC

AIS, RDI, or LOC defect declared for the TP of the ATM connection

Main state disabled, substate AIS/RDI/LOC

F4 Disabled Enabled Unspecif AIS, RDI, or LOC defect cleared for the TP of the ATM connection


F5 N/A Enabled Created OAM supervision started success-fully for a VC connection termination point (VC or VP switched)


F5 Enabled Disabled AIS/RDI/LOC

AIS, RDI, or LOC defect declared for the TP of the ATM connection

Main state disabled, substate AIS/RDI/LOC

F5 Disabled Enabled Unspecif AIS, RDI, or LOC defect cleared for the TP of the ATM connection


Table 8 Causes for resource state changes

DN70569254 39

WCDMA RAN ATM Transport Fault management

Id:0900d8058077b1b4Confidential

7 Fault managementFault management comprises functions that monitor, detect and report failure conditions in the ATM network. The functions are also called Operation and Maintenance (OAM) functions. OAM functions are defined on five levels F1 to F5, of which the F4 and F5 levels are mapped to ATM protocol layers: F1 Regenerator Section Level (physical layer) F2 Digital Section Level (physical layer) F3 Transmission Path Level (physical layer: SDH, PDH) F4 Virtual Path Level (ATM VP) F5 Virtual Channel Level (ATM VC)In the ATM layer, OAM functions are based on OAM cells, which are ATM cells with certain reserved values in the VPI/VCI fields of their headers. OAM cells are therefore not transported inside any operator-configured VP or VC. OAM cells are sent out from an originating (source) NE and, depending on the function, are forwarded, returned, or discarded in the NEs along the ATM connection.

OAM functions can be performed either on the entire VC or VP connection (end-to-end, ete) or on a portion of the VC or VP connection (segment, seg). End-to-end OAM func-tions are carried out between the termination points of a VC or VP. Segment OAM func-tions are carried out between segment end points. VC/VP termination points and ATM cross-connects can be configured as segment end points. In the BTS, the OAM func-tions are located inside the AXC, which does not support OAM segments.

In an NE that acts as ATM cross-connect, OAM cells are forwarded (and are not acted upon) if the related OAM function is not activated in this NE. In an NE that terminates an ATM connection, OAM cells are discarded if the related OAM function is not activated.

The following Fault Management (OAM) functions are available:

OAM function Purpose

Alarm Indication Signal (AIS) Reporting of defect indications in the forward direc-tion

Remote Defect Indication (RDI) Reporting remote defect indications in the backward direction

Continuity Check (CC) Monitoring continuity

Loopback On-demand connectivity monitoring

Fault localization

Pre-service connectivity verification.

Table 9 Fault management functions

NE BTS_Flexi/FlexiTrans-port

BTS_WN/ AXC RNC/ IPA2800

Type ete seg ete seg ete seg

VP-AIS - - yes - yes yes

Table 10 Provision of ATM OAM functions

40 DN70569254


Id:09

wcdma ran atm transport

Documents