RAS06 Feature Descriptions Dn70296245 1-5 En

WCDMA RAN System, Rel. RAS06,Feature Descriptions

DN70296245Issue 1-5 en13/06/2008

# Nokia Siemens Networks 1 (297)

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

The information or statements given in this documentation concerning the suitability, capacity, orperformance of the mentioned hardware or software products are given “as is” and all liabilityarising in connection with such hardware or software products shall be defined conclusively andfinally in a separate agreement between Nokia Siemens Networks and the customer. However,Nokia Siemens Networks has made all reasonable efforts to ensure that the instructionscontained in the document are adequate and free of material errors and omissions. NokiaSiemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues whichmay not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NOEVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THISDOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUTNOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESSOPPORTUNITY OR DATA, THAT MAYARISE FROM THE USE OF THIS DOCUMENT OR THEINFORMATION IN IT.

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

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark ofNokia 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 2008. All rights reserved.

2 (297) # Nokia Siemens Networks DN70296245Issue 1-5 en13/06/2008

WCDMA RAN System, Rel. RAS06, Feature Descriptions

Contents

Contents 3

Summary of changes 19

1 Radio resource management and telecom features 211.1 RAS06 documentation for radio resource management and telecom

features 211.2 RAN928: Directed Retry 251.2.1 Introduction 251.2.2 Functional description 251.2.3 System impact 251.2.3.1 Hardware requirements 251.2.3.2 Software requirements 261.2.3.3 Software sales information 261.2.3.4 Management plane 261.3 RAN831: Wideband AMR Codec Set (12.65, 8.85, 6.6) 261.3.1 Introduction 261.3.2 Functional description 271.3.3 System impact 271.3.3.1 Hardware requirements 271.3.3.2 Software requirements 271.3.3.3 Software sales information 271.3.3.4 Management plane 271.4 RAN1013: 16 kbit/s Return Channel DCH Data Rate Support for

HSDPA 291.4.1 Introduction 291.4.2 Functional description 291.4.3 System impact 301.4.3.1 Current implementation 301.4.3.2 Hardware requirements 301.4.3.3 Software requirements 301.4.3.4 Software sales information 301.4.3.5 Management plane 301.5 RAN852: HSDPA 15 Codes 311.5.1 Introduction 311.5.2 Functional description 321.5.3 System impact 321.5.3.1 Current implementation 321.5.3.2 Hardware requirements 321.5.3.3 Software requirements 331.5.3.4 Software sales information 331.5.3.5 Management plane 331.6 RAN853: HSDPA Code Multiplexing 351.6.1 Introduction 351.6.2 Functional description 361.6.3 System impact 361.6.3.1 Current implementation 361.6.3.2 Hardware requirements 36

DN70296245Issue 1-5 en13/06/2008


Contents

1.6.3.3 Software requirements 371.6.3.4 Software sales information 371.6.3.5 Management plane 371.7 RAN1033: HSDPA 48 Users per Cell 381.7.1 Introduction 381.7.2 Functional description 381.7.3 System impact 391.7.3.1 Current implementation 391.7.3.2 Hardware requirements 391.7.3.3 Interdependencies between features 391.7.3.4 Software requirements 391.7.3.5 Software sales information 391.7.3.6 Management plane 401.8 RAN1034: Shared HSDPA Scheduler for Baseband Efficiency 411.8.1 Introduction 411.8.2 Functional description 411.8.3 System impact 421.8.3.1 Current implementation 421.8.3.2 Hardware requirements 431.8.3.3 Software requirements 431.8.3.4 Software sales information 431.8.3.5 Management plane 431.9 RAN312: HSDPA Dynamic Resource Allocation 451.9.1 Introduction 451.9.2 Functional description 451.9.3 System impact 461.9.3.1 Current implementation 461.9.3.2 Hardware requirements 461.9.3.3 Software requirements 461.9.3.4 Software sales information 461.9.3.5 Management plane 471.10 RAN826: Basic HSUPA 481.10.1 Introduction 481.10.2 Functional description 481.10.3 System impact 521.10.3.1 Current implementation 521.10.3.2 Hardware requirements 521.10.3.3 Interdependencies between features 521.10.3.4 Software requirements 521.10.3.5 Software sales information 521.10.3.6 Management plane 521.11 RAN973: HSUPA Basic RRM 541.11.1 Introduction 541.11.2 Functional description 541.11.3 System impact 581.11.3.1 Hardware requirements 581.11.3.2 Software requirements 581.11.3.3 Software sales information 581.11.3.4 Management plane 581.12 RAN968: HSUPA BTS Packet Scheduler 621.12.1 Introduction 621.12.2 Functional description 62



1.12.3 System impact 621.12.3.1 Current implementation 621.12.3.2 Hardware requirements 621.12.3.3 Software requirements 631.12.3.4 Software sales information 631.12.3.5 Management plane 631.13 RAN970: HSUPA Handovers 641.13.1 Introduction 641.13.2 Functional description 651.13.3 System impact 651.13.3.1 Hardware requirements 651.13.3.2 Interdependencies between features 651.13.3.3 Software requirements 661.13.3.4 Software sales information 661.13.3.5 Management plane 661.14 RAN992: HSUPA Congestion Control 671.14.1 Introduction 671.14.2 Functional description 681.14.3 System impact 761.14.3.1 Current implementation 761.14.3.2 Hardware requirements 761.14.3.3 Interdependencies between features 761.14.3.4 Software requirements 761.14.3.5 Software sales information 761.14.3.6 Control and user plane 771.14.3.7 Management plane 771.14.3.8 Impact on system performance and capacity 791.15 RAN974: HSUPA with Simultaneous AMR Voice Call 791.15.1 Introduction 791.15.2 Functional description 791.15.3 System impact 791.15.3.1 Hardware requirements 791.15.3.2 Software requirements 801.15.3.3 Software sales information 801.15.3.4 Management plane 801.16 RAN1515: HSPA Inter-RNC Cell Change 811.16.1 Introduction 811.16.2 Functional description 811.16.3 System impact 811.16.3.1 Current implementation 811.16.3.2 Hardware requirements 821.16.3.3 Interdependencies between features 821.16.3.4 Software requirements 821.16.3.5 Software sales information 821.16.3.6 Management plane 821.17 RAN1011: HSPA Layering for UEs in Common Channels 831.17.1 Introduction 831.17.2 Functional description 831.17.3 System impact 841.17.3.1 Current implementation 841.17.3.2 Hardware requirements 841.17.3.3 Software requirements 84

DN70296245Issue 1-5 en13/06/2008


Contents

1.17.3.4 Software sales information 841.17.3.5 Management plane 841.18 RAN1249: HSDPA 10 Mbps per User 851.18.1 Introduction 851.18.2 Functional description 851.18.3 System impact 851.18.3.1 Current implementation 851.18.3.2 Hardware requirements 851.18.3.3 Interdependencies between features 861.18.3.4 Software requirements 861.18.3.5 Software sales information 861.18.3.6 Management plane 861.19 RAN1305: HSDPA 14.4 Mbps per Cell 871.19.1 Introduction 871.19.2 Functional description 871.19.3 System impact 881.19.3.1 Hardware requirements 881.19.3.2 Interdependencies between features 881.19.3.3 Software requirements 881.19.3.4 Software sales information 881.19.3.5 Management plane 881.20 RAN979: HSUPA 2.0 Mbps 891.20.1 Introduction 891.20.2 Functional description 891.20.3 System impact 901.20.3.1 Current implementation 901.20.3.2 Hardware requirements 901.20.3.3 Interdependencies between features 901.20.3.4 Software requirements 901.20.3.5 Software sales information 901.20.3.6 Management plane 901.21 RAN834: Flexible Iu 911.21.1 Introduction 911.21.2 Functional description 911.21.3 System impact 931.21.3.1 Current implementation 931.21.3.2 Hardware requirements 931.21.3.3 Interdependencies between features 931.21.3.4 Software requirements 931.21.3.5 Software sales information 931.21.3.6 Management plane 931.22 RAN1177: Emergency Call Redirect to GSM 941.22.1 Introduction 941.22.2 Functional description 941.22.3 System impact 951.22.3.1 Hardware requirements 951.22.3.2 Software requirements 951.22.3.3 Software sales information 951.22.3.4 Management plane 951.23 RAN1219: Latency Statistics for UE Positioning 951.23.1 Introduction 951.23.2 Functional description 96



1.23.3 System impact 961.23.3.1 Hardware requirements 961.23.3.2 Software requirements 961.23.3.3 Software sales information 961.23.3.4 Management plane 961.24 RAN1452: MORAN for up to 4 Operators 981.24.1 Introduction 981.24.2 Functional description 991.24.3 System impact 1011.24.3.1 Current implementation 1011.24.3.2 Hardware requirements 1011.24.3.3 Interdependencies between features 1011.24.3.4 Software requirements 1011.24.3.5 Software sales information 1011.24.3.6 Management plane 101

2 Transmission and transport features 1032.1 RAS06 documentation for transmission and transport features 1032.2 RAN1097: Ethernet Interface Unit IFUH (Iub User Plane) for AXC 1052.2.1 Introduction 1052.2.2 Functional description 1072.2.3 System impact 1082.2.3.1 Current implementation 1082.2.3.2 Hardware requirements 1082.2.3.3 Interdependencies between features 1082.2.3.4 Software requirements 1092.2.3.5 Software sales information 1092.2.3.6 Control and user plane 1092.2.3.7 Management plane 1092.2.3.8 Impact on system performance and capacity 1112.2.3.9 Impact on mobile terminals 1112.3 RAN1064: Ethernet+E1/T1/JT1 Interface Unit (Iub User Plane) for Flexi

WCDMA BTS 1112.3.1 Introduction 1112.3.2 Functional description 1132.3.3 System impact 1152.3.3.1 Current implementation 1152.3.3.2 Hardware requirements 1152.3.3.3 Interdependencies between features 1152.3.3.4 Software requirements 1162.3.3.5 Software sales information 1162.3.3.6 Control and user plane 1162.3.3.7 Management plane 1162.3.3.8 Impact on system performance and capacity 1182.3.3.9 Impact on mobile terminals 1182.4 RAN1099: Dynamic Scheduling for HSDPA with Path Selection 1182.4.1 Introduction 1182.4.2 Functional description 1222.4.3 System impact 1222.4.3.1 Current implementation 1222.4.3.2 Hardware requirements 1232.4.3.3 Interdependencies between features 123

DN70296245Issue 1-5 en13/06/2008


Contents

2.4.3.4 Software requirements 1232.4.3.5 Software sales information 1232.4.3.6 Control and user plane 1232.4.3.7 Management plane 1242.4.3.8 Impact on system performance and capacity 1262.4.3.9 Impact on mobile terminals 1262.4.3.10 Limitations and restrictions 1262.5 RAN1100: Dynamic Scheduling for NRT DCH with Path Selection 1272.5.1 Introduction 1272.5.2 System impact of RAN1100: Dynamic Scheduling for NRT DCH with Path

Selection 1332.5.2.1 Current implementation 1342.5.2.2 Interdependencies between features 1342.5.2.3 Software requirements 1342.5.2.4 Hardware requirements 1342.5.2.5 Control and user plane 1352.5.2.6 Management plane 1352.5.2.7 Impact on system performance and capacity 1372.5.2.8 Impact on mobile terminals 1382.5.2.9 Limitations and restrictions 1382.5.3 Functional description 1382.6 RAN759: Path Selection 1382.6.1 Introduction 1382.6.2 Functional description 1412.6.3 System impact 1452.6.3.1 Current implementation 1452.6.3.2 Hardware requirements 1462.6.3.3 Interdependencies between features 1462.6.3.4 Software requirements 1462.6.3.5 Software sales information 1462.6.3.6 Control and user plane 1472.6.3.7 Management plane 1472.6.3.8 Impact on system performance and capacity 1502.6.3.9 Impact on mobile terminals 1502.6.3.10 Limitations and restrictions 1502.7 RAN1096: Transport Bearer Tuning 1502.7.1 Introduction 1502.7.2 Functional description 1522.7.3 System impact 1522.7.3.1 Current implementation 1522.7.3.2 Hardware requirements 1522.7.3.3 Interdependencies between features 1522.7.3.4 Software requirements 1542.7.3.5 Software sales information 1542.7.3.6 Control and user plane 1552.7.3.7 Management plane 1552.7.3.8 Impact on system performance and capacity 1592.7.3.9 Impact on mobile terminals 1592.7.3.10 Limitations and restrictions 1622.8 RAN1095: UBR+ for Iub User Plane 1622.8.1 Introduction 1622.8.2 Functional description 164



2.8.3 System impact 1652.8.3.1 Current implementation 1652.8.3.2 Hardware requirements 1652.8.3.3 Interdependencies between features 1652.8.3.4 Software requirements 1662.8.3.5 Software sales information 1672.8.3.6 Control and user plane 1672.8.3.7 Management plane 1672.8.3.8 Impact on system performance and capacity 1702.8.3.9 Impact on mobile terminals 1702.8.3.10 Limitations and restrictions 1702.9 RAN1319: Flexi WCDMA BTS IMA Based AAL2 Uplink CAC 1712.9.1 Introduction 1712.9.2 Functional description 1712.9.3 System impact 1722.9.3.1 Current implementation 1722.9.3.2 Hardware requirements 1722.9.3.3 Interdependencies between features 1722.9.3.4 Software requirements 1722.9.3.5 Software sales information 1722.9.3.6 Management plane 1732.10 RAN1063: Hybrid Backhaul with Pseudo Wires 1732.10.1 Introduction 1732.10.2 Functional description 1752.10.3 System impact 1822.10.3.1 Current implementation 1822.10.3.2 Hardware requirements 1822.10.3.3 Interdependencies between features 1832.10.3.4 Software requirements 1832.10.3.5 Software sales information 1832.10.3.6 Control and user plane 1842.10.3.7 Management plane 1872.10.3.8 Impact on system performance and capacity 1892.10.3.9 Impact on mobile terminals 1892.10.3.10 Limitations and restrictions 1892.11 RAN1142: ATM over Ethernet for BTS 1892.11.1 Introduction 1892.11.2 Functional description 1892.11.3 System impact 1932.11.3.1 Current implementation 1932.11.3.2 Hardware requirements 1932.11.3.3 Interdependencies between features 1932.11.3.4 Software requirements 1942.11.3.5 Software sales information 1942.11.3.6 Control and user plane 1942.11.3.7 Management plane 1942.11.3.8 Impact on system performance and capacity 1992.11.3.9 Impact on mobile terminals 199

3 Operability features 2013.1 RAS06 documentation for operability features 2013.2 RAN1199: RNC GUI for BTS Connection Resources 203

DN70296245Issue 1-5 en13/06/2008


Contents

3.2.1 Introduction 2033.2.2 Functional description 2033.2.3 System impact 2053.2.3.1 Current implementation 2053.2.3.2 Hardware requirements 2053.2.3.3 Interdependencies between features 2053.2.3.4 Software requirements 2053.2.3.5 Software sales information 2053.2.3.6 Management plane 2063.2.3.7 Impact on system performance and capacity 2063.3 RAN1160: Collection of Key Counters 2063.3.1 Introduction 2063.3.2 Functional description 2063.3.3 System impact 2073.3.3.1 Current implementation 2073.3.3.2 Hardware requirements 2073.3.3.3 Interdependencies between features 2073.3.3.4 Software requirements 2073.3.3.5 Software sales information 2073.3.3.6 Control and user plane 2083.3.3.7 Management plane 2083.3.3.8 Impact on system performance and capacity 2083.3.3.9 Other impacts 2083.4 RAN1161: Alarms for PM Measurement Data Transfer Failures 2093.4.1 Introduction 2093.4.2 Functional description 2093.4.3 System impact 2103.4.3.1 Current implementation 2103.4.3.2 Hardware requirements 2103.4.3.3 Interdependencies between features 2103.4.3.4 Software requirements 2103.4.3.5 Software sales information 2103.4.3.6 Control and user plane 2103.4.3.7 Management plane 2113.4.3.8 Impact on system performance and capacity 2113.4.3.9 Other impacts 2113.5 RAN1150: RNC Support for Traffica 2113.5.1 Introduction 2113.5.2 Functional description 2123.5.3 System impact 2133.5.3.1 Current implementation 2133.5.3.2 Hardware requirements 2133.5.3.3 Software requirements 2133.5.3.4 Software sales information 2133.5.3.5 Management plane 2133.6 RAN1128: Dynamic Access Class Restriction 2143.6.1 Introduction 2143.6.2 Functional description 2143.6.3 System impact 2153.6.3.1 Current implementation 2153.6.3.2 Hardware requirements 2153.6.3.3 Interdependencies between features 215



3.6.3.4 Software requirements 2153.6.3.5 Software sales information 2153.6.3.6 Control and user plane 2153.6.3.7 Management plane 2163.6.3.8 Impact on system performance and capacity 2163.6.3.9 Other impacts 2163.7 RAN212: Selectable RNW Plan Activation Mechanism 2163.7.1 Introduction 2163.7.2 Functional description 2173.7.3 System impact 2173.7.3.1 Current implementation 2173.7.3.2 Hardware requirements 2173.7.3.3 Interdependencies between features 2173.7.3.4 Software requirements 2173.7.3.5 Software sales information 2183.7.3.6 Control and user plane 2183.7.3.7 Management plane 2183.7.3.8 Impact on system performance and capacity 2183.7.3.9 Other impacts 2183.8 RAN1059: Flexi WCDMA BTS Support for RNS Split 2193.8.1 Introduction 2193.8.2 Functional description 2193.8.3 System impact 2203.8.3.1 Current implementation 2203.8.3.2 Hardware requirements 2203.8.3.3 Interdependencies between features 2203.8.3.4 Software requirements 2203.8.3.5 Software sales information 2213.8.3.6 Control and user plane 2213.8.3.7 Management plane 2213.8.3.8 Impact on system performance and capacity 2213.8.3.9 Other impacts 2223.9 RAN1084: Direct Activation of RNW Changes Using NWI3 2223.9.1 Introduction 2223.9.2 Functional description 2223.9.3 System impact 2233.9.3.1 Current implementation 2233.9.3.2 Hardware requirements 2233.9.3.3 Interdependencies between features 2233.9.3.4 Software requirements 2243.9.3.5 Software sales information 2243.9.3.6 Control and user plane 2243.9.3.7 Management plane 2243.9.3.8 Impact on system performance and capacity 2243.10 RAN618: Centralised User Information Management for BTS 2253.10.1 Introduction 2253.10.2 Functional description 2253.10.3 System impact 2263.10.3.1 Current implementation 2263.10.3.2 Hardware requirements 2263.10.3.3 Interdependencies between features 2263.10.3.4 Software requirements 226

DN70296245Issue 1-5 en13/06/2008


Contents

3.10.3.5 Software sales information 2263.10.3.6 Control and user plane 2263.10.3.7 Management plane 2263.10.3.8 Impact on system performance and capacity 2273.11 RAN1159: IP Address & Port based Filtering for BTS LMPs 2273.11.1 Introduction 2273.11.2 Functional description 2273.11.3 System impact 2283.11.3.1 Current implementation 2283.11.3.2 Hardware requirements 2283.11.3.3 Interdependencies between features 2283.11.3.4 Software requirements 2283.11.3.5 Software sales information 2293.11.3.6 Management plane 2293.12 RAN33: IP Security for O&M Traffic between RNC and NetAct 2293.12.1 Introduction 2293.12.2 Functional description 2303.12.3 System impact 2303.12.3.1 Current implementation 2303.12.3.2 Hardware requirements 2303.12.3.3 Interdependencies between features 2303.12.3.4 Software requirements 2303.12.3.5 Software sales information 2303.12.3.6 Management plane 2303.13 RAN1451: Mass Change of Local BTS Passwords 2313.13.1 Introduction 2313.13.2 Functional description 2313.13.3 System impact 2313.13.3.1 Current implementation 2313.13.3.2 Hardware requirements 2313.13.3.3 Interdependencies between features 2313.13.3.4 Software requirements 2323.13.3.5 Software sales information 2323.13.3.6 Management plane 232

4 Performance monitoring features 2334.1 RAS06 documentation for performance monitoring features 2334.2 RAN1068: 3GPP TS 32.403 Related Counter Additions for RAN 2344.2.1 Introduction 2344.2.2 Functional description 2354.2.3 System impact 2364.2.3.1 Current implementation 2364.2.3.2 Hardware requirements 2374.2.3.3 Interdependencies between features 2374.2.3.4 Software requirements 2374.2.3.5 Software sales information 2374.2.3.6 Control and user plane 2374.2.3.7 Management plane 2374.2.3.8 Impact on system performance and capacity 2394.3 RAN868: ATM Transport Statistics Reporting in RAN 2394.3.1 Introduction 2394.3.2 Functional description 239



4.3.3 System impact 2404.3.3.1 Current implementation 2404.3.3.2 Hardware requirements 2404.3.3.3 Interdependencies between features 2414.3.3.4 Software requirements 2414.3.3.5 Software sales information 2414.3.3.6 Control and user plane 2414.3.3.7 Management plane 2414.3.3.8 Impact on system performance and capacity 2414.4 RAN86: Cell Throughput Measurements in Serving RNC 2424.4.1 Introduction 2424.4.2 Functional description 2424.4.3 System impact 2434.4.3.1 Current implementation 2434.4.3.2 Hardware requirements 2434.4.3.3 Interdependencies between features 2434.4.3.4 Software requirements 2434.4.3.5 Software sales information 2444.4.3.6 Control and user plane 2444.4.3.7 Management plane 2444.4.3.8 Impact on system performance and capacity 2454.5 RAN234: HSDPA Subscriber Trace 2454.5.1 Introduction 2454.5.2 Functional description 2464.5.3 System impact 2474.5.3.1 Current implementation 2474.5.3.2 Hardware requirements 2474.5.3.3 Interdependencies between features 2484.5.3.4 Software requirements 2484.5.3.5 Software sales information 2484.5.3.6 Control and user plane 2484.5.3.7 Management plane 2484.5.3.8 Impact on system performance and capacity 2494.6 RAN1052: HSUPA Subscriber Trace 2494.6.1 Introduction 2494.6.2 Functional description 2494.6.3 System impact 2514.6.3.1 Current implementation 2514.6.3.2 Hardware requirements 2514.6.3.3 Interdependencies between features 2514.6.3.4 Software requirements 2514.6.3.5 Software sales information 2514.6.3.6 Control and user plane 2514.6.3.7 Management plane 2514.6.3.8 Impact on system performance and capacity 252

5 RNC solution features 2535.1 RAS06 documentation for RNC solution features 2535.2 RAN1151: Linux Based OMS Replacing NEMU 2545.2.1 Introduction 2545.2.2 Functional description 2545.2.3 System impact 255

DN70296245Issue 1-5 en13/06/2008


Contents

5.2.3.1 Current implementation 2555.2.3.2 Hardware requirements 2555.2.3.3 Interdependencies between features 2555.2.3.4 Software requirements 2555.2.3.5 Software sales information 2555.2.3.6 Control and user plane 2555.2.3.7 Management plane 2565.2.3.8 Impact on system performance and capacity 2565.2.3.9 Other impacts 2565.3 RAN1623: Carrier Connectivity Optimised RNC450 2575.3.1 Introduction 2575.3.2 Functional description 2575.3.3 System impact 2585.3.3.1 Current implementation 2585.3.3.2 Hardware requirements 2585.3.3.3 Interdependencies between features 2595.3.3.4 Software requirements 2595.3.3.5 Software sales information 2595.3.3.6 Control and user plane 2595.3.3.7 Management plane 2595.3.3.8 Impact on system performance and capacity 260

6 BTS solution features 2616.1 RAS06 documentation for BTS solution features 2616.2 RAN906: Flexi WCDMA BTS 3GPP Antenna Tilt Support 2636.2.1 Introduction 2636.2.2 Functional description 2636.2.3 System impact 2636.2.3.1 Hardware requirements 2636.2.3.2 Software requirements 2636.2.3.3 Software sales information 2636.2.3.4 Management plane 2646.3 RAN908: Flexi WCDMA BTS AISG MHA Support 2646.3.1 Introduction 2646.3.2 Functional description 2646.3.3 System impact 2656.3.3.1 Current implementation 2656.3.3.2 Hardware requirements 2656.3.3.3 Interdependencies between features 2656.3.3.4 Software requirements 2656.3.3.5 Software sales information 2656.3.3.6 Control and user plane 2656.3.3.7 Management plane 2656.3.3.8 Impact on system performance and capacity 2666.4 RAN1670: UltraSite EDGE Wideband Combiner for WCDMA

Refarming 2666.4.1 Introduction 2666.4.2 Functional description 2676.4.3 System impact 2676.4.3.1 Current implementation 2676.4.3.2 Hardware requirements 2676.4.3.3 Interdependencies between features 268



6.4.3.4 Software requirements 2686.4.3.5 Software sales information 2686.4.3.6 Control and user plane 2686.4.3.7 Management plane 2686.4.3.8 Impact on system performance and capacity 2696.5 RAN1223: 40W Remote Radio Head 2100 2696.5.1 Introduction 2696.5.2 Functional description 2696.5.3 System impact 2706.5.3.1 Current implementation 2706.5.3.2 Hardware requirements 2706.5.3.3 Interdependencies between features 2706.5.3.4 Software requirements 2706.5.3.5 Software sales information 2706.5.3.6 Control and user plane 2706.5.3.7 Management plane 2706.5.3.8 Impact on system performance and capacity 2716.6 RAN1222: External GPS Synchronisation for Flexi BTS System Module

Rel 1 2716.6.1 Introduction 2716.6.2 Functional description 2716.6.3 System impact 2726.6.3.1 Current implementation 2726.6.3.2 Hardware requirements 2726.6.3.3 Interdependencies between features 2726.6.3.4 Software requirements 2726.6.3.5 Software sales information 2726.6.3.6 Control and user plane 2726.6.3.7 Management plane 2736.6.3.8 Impact on system performance and capacity 2736.7 RAN1463: Support for FRMB/C Unit in Flexi WCDMA BTS 2736.7.1 Introduction 2736.7.2 Functional description 2746.7.3 System impact 2746.7.3.1 Current implementation 2746.7.3.2 Hardware requirements 2746.7.3.3 Interdependencies between features 2746.7.3.4 Software requirements 2746.7.3.5 Software sales information 2746.7.3.6 Control and user plane 2756.7.3.7 Management plane 2756.7.3.8 Impact on system performance and capacity 2756.7.3.9 Other impacts 2756.8 RAN1139: FADB Flexi Multiradio Combiner for 900MHz 2756.8.1 Introduction 2756.8.2 Functional description 2766.8.3 System impact 2766.8.3.1 Current implementation 2766.8.3.2 Hardware requirements 2766.8.3.3 Interdependencies between features 2776.8.3.4 Software requirements 2776.8.3.5 Software sales information 277

DN70296245Issue 1-5 en13/06/2008


Contents

6.8.3.6 Management plane 2776.8.3.7 Impact on system performance and capacity 2776.8.3.8 Other impacts 2776.9 RAN1079: FACB Flexi Multiradio Combiner for 850MHz 2786.9.1 Introduction 2786.9.2 Functional description 2786.9.3 System impact 2786.9.3.1 Current implementation 2786.9.3.2 Hardware requirements 2796.9.3.3 Interdependencies between features 2796.9.3.4 Software requirements 2796.9.3.5 Software sales information 2796.9.3.6 Management plane 2796.9.3.7 Impact on system performance and capacity 2806.9.3.8 Other impacts 2806.10 RAN1462: FAGB Flexi Multiradio combiner for 2100MHz 2806.10.1 Introduction 2806.10.2 Functional description 2806.10.3 System impact 2816.10.3.1 Current implementation 2816.10.3.2 Hardware requirements 2816.10.3.3 Interdependencies between features 2816.10.3.4 Software requirements 2816.10.3.5 Software sales information 2816.10.3.6 Management plane 2816.10.3.7 Impact on system performance and capacity 2826.10.3.8 Other impacts 2826.11 RAN1127: Extended Cell (180km) 2826.11.1 Introduction 2826.11.2 Functional description 2826.11.3 System impact 2836.11.3.1 Current implementation 2836.11.3.2 Hardware requirements 2836.11.3.3 Interdependencies between features 2836.11.3.4 Software requirements 2836.11.3.5 Software sales information 2836.11.3.6 Control and user plane 2836.11.3.7 Management plane 2836.12 RAN923: Pico WCDMA BTS with Ethernet Transport 2856.12.1 Introduction 2856.12.2 Functional description 2866.12.3 System impact 2876.12.3.1 Current implementation 2876.12.3.2 Hardware requirements 2886.12.3.3 Interdependencies between features 2886.12.3.4 Software requirements 2886.12.3.5 Software sales information 2886.12.3.6 Management plane 2886.13 RAN1309: WMHD Mast Head Amplifier 2886.13.1 Introduction 2886.13.2 Functional description 2896.13.3 System impact 289



6.13.3.1 Current implementation 2896.13.3.2 Hardware requirements 2896.13.3.3 Interdependencies between features 2906.13.3.4 Software requirements 2906.13.3.5 Software sales information 2906.13.3.6 Control and user plane 2906.13.3.7 Management plane 2906.13.3.8 Impact on system performance and capacity 2916.13.3.9 Other impacts 2916.14 RAN1594: Pico WCDMA BTS Rel.2 sw 2916.14.1 Introduction 2916.14.2 Functional description 2916.14.3 System impact 2966.14.3.1 Current implementation 2966.14.3.2 Hardware requirements 2966.14.3.3 Interdependencies between features 2966.14.3.4 Software requirements 2976.14.3.5 Software sales information 2976.14.3.6 Management plane 297

DN70296245Issue 1-5 en13/06/2008


Contents



Summary of changes

Changes between document issues are cumulative. Therefore, the latestdocument issue contains all changes made to previous issues.

Changes between issues 1-5 and 1-4

The Excess Bandwidth Share (EBS) has been clarified for the followingfeature:

. RAN1100: Dynamic Scheduling for NRT DCH with Path Selection


Software sales information has been corrected to RAN928: Directed Retry.


Information on all features has been updated to RAS06 E5 level.

The following features will be published on top of RAS06:

. RAN928: Directed Retry

. RAN1670: UltraSite EDGE Wideband Combiner for WCDMARefarming

. RAN1223: 40W Remote Radio Head 2100

. RAN1463: Support for FRMB/C Unit in Flexi WCDMA BTS

. RAN1139: FADB Flexi Multiradio Combiner for 900MHz

. RAN1079: FACB Flexi Multiradio Combiner for 850MHz

. RAN923: Pico WCDMA BTS with Ethernet Transport

. RAN1594: Pico WCDMA BTS Rel.2 SW

Feature RAN1176: 40W Remote Radio Head 1.7/2.1 has been removed.

DN70296245Issue 1-5 en13/06/2008


Summary of changes



1 Radio resource management andtelecom features

1.1 RAS06 documentation for radio resourcemanagement and telecom features

See the following table for more detailed information on WCDMA RANfunctionality and feature activation:

Table 1. Radio resource management and telecom features

Feature ID: Name Functional Area Description Feature Activation Manual

RAN928: Directed Retry *

RAN831: Wideband AMR CodecSet (12.65, 8.85, 6.6)

Admission control overview inAdmission Control

Activating Wideband AMR CodecSet in Feature RAN831: WidebandAMR Codec Set, FeatureActivation Manual

RAN1013: 16 kbit/s ReturnChannel DCH Data Rate Supportfor HSDPA

RAS06 features in Radio ResourceManagement

Introduction to radio resourcemanagement of HSDPA in RadioResource Management of HSDPA

RAN852: HSDPA 15 Codes RAS06 features in Radio ResourceManagement

HSDPA resource handling andChannel type switching in RadioResource Management of HSDPA

Basic HSDPA functions in HSDPAin BTS

Overview of the resource managerin Resource Manager

Activating HSDPA 15 Codes inHSDPA Features, FeatureActivation Manual

RAN853: HSDPA CodeMultiplexing


DN70296245Issue 1-5 en13/06/2008


Radio resource management and telecom features

Table 1. Radio resource management and telecom features (cont.)


HSDPA code multiplexing in RadioResource Management of HSDPA

Activating HSDPA CodeMultiplexing in HSDPA Features,Feature Activation Manual

RAN1033: HSDPA 48 Users perCell


HSDPA 48 users per cell in RadioResource Management of HSDPA

Activating HSDPA 48 Users PerCell in HSDPA Features, FeatureActivation Manual

RAN1034: Shared HSDPAScheduler for Baseband Efficiency


Activating Shared HSDPAScheduler for Baseband Efficiencyin HSDPA Features, FeatureActivation Manual

RAN312: HSDPA DynamicResource Allocation


HSDPA resource handling in RadioResource Management of HSDPA

Handover control in HandoverControl

Introduction to the packetscheduler functionality in PacketScheduler

Admission control overview inAdmission Control

Overview of load control in LoadControl

Activating HSDPA DynamicResource Allocation in HSDPAFeatures, Feature ActivationManual

RAN826: Basic HSUPA RAS06 features in Radio ResourceManagement

HSUPA basic RRM in RadioResource Management of HSUPA

Activating basic HSUPA andHSUPA basic RRM in HSUPAFeatures, Feature ActivationManual

RAN973: HSUPA Basic RRM RAS06 features in Radio ResourceManagement



Overview of load control in LoadControl

Activating basic HSUPA andHSUPA basic RRM in HSUPAFeatures, Feature ActivationManual

RAN968: HSUPA BTS PacketScheduler


RAN970: HSUPA Handovers RAS06 features in Radio ResourceManagement



Table 1. Radio resource management and telecom features (cont.)


HSUPA handovers in RadioResource Management of HSUPA

RAN992: HSUPA CongestionControl

HSUPA Congestion Control inHSUPA in BTS

RAN974: HSUPA withSimultaneous AMR Voice Call


HSUPA with simultaneous AMRvoice call in Radio ResourceManagement of HSUPA

Activating HSUPA withsimultaneous AMR voice call inHSUPA Features, FeatureActivation Manual

RAN1515: HSPA Inter-RNC CellChange

RAN1011: HSPA Layering for UEsin Common Channels


Directed RRC connection setup forHSDPA layer in Handover Control

Activating HSDPA Layering forUEs in Common Channels inHSDPA Features, FeatureActivation Manual

RAN1249: HSDPA 10 Mbps perUser

HSDPA 10 Mbps per User inRadio Resource Management ofHSDPA

Activating HSDPA 10 Mbps perUser in HSDPA Features, FeatureActivation Manual

RAN1305: HSDPA 14.4 Mbps perCell


RAN979: HSUPA 2.0 Mbps Description of Radio ResourceManagement of HSUPA in RadioResource Management of HSUPA

RAN834: Flexible Iu Call setup and release in CallSetup and Release

Activating Flexible Iu in FeatureRAN834: Flexible IU, FeatureActivation Manual

RAN1177: Emergency CallRedirect to GSM

Location services overview inLocation Services

Call setup and release in CallSetup and Release

Activating Emergency CallRedirect to GSM in FeatureRAN1177: Emergency CallRedirect to GSM, FeatureActivation Manual

RAN1219: Latency Statistics forUE Positioning

RAN1452: MORAN for up to 4Operators

*) Delivered on top of RAS06.

DN70296245Issue 1-5 en13/06/2008



For information on the parameters, counters and alarms related to eachfeature, see the System impact sections of the feature descriptions in thisdocument.

For parameter descriptions, see:

. WCDMA RAN Parameter Dictionary

. Reference Information Service in NOLS for RNC parameters

For counter descriptions, see:

. RNC Counters - RNW Part

. RNC Counters – Transport and HW Part

. WBTS Counters

. Reference Information Service in NOLS

For alarm descriptions, see:

. Notices (0-999)

. Disturbances (1000-1999)

. Failure Printouts (2000-3999)

. Diagnosis Reports (3700-3999)

. Base Station Alarms (7000-7900)

. Flexi WCDMA Base Station Alarms and Troubleshooting

. Nokia UltraSite and MetroSite WCDMA Base Station Alarms andTroubleshooting in Nokia UltraSite and Nokia MetroSite ProductDocumentation

For information on licence management, see Licence Management inWCDMA RAN.



1.2 RAN928: Directed Retry

1.2.1 Introduction

Note

This feature is delivered on top of RAS06.

RAN928: Directed Retry initiates a handover to the GSM network in casecongestion is met in WCDMA RAN. It is performed i if a UE is trying toestablish a voice call in a WCDMA cell which is fully loaded.

Benefits for the operator

This improves KPIs concerning call setup success rate. The connectionsthat would face congestion in the AMR call RAB setup phase are directedto the GSM system to continue the connection setup.

1.2.2 Functional description

The RAN928: Directed Retry feature makes an inter-system handover tothe GSM system in case congestion is met in the source cell of RAN. It isdone for NB-AMR and WB-AMR calls. If a connection includes other RABsin addition to the AMR RAB no directed retry is made.

The directed retry takes place when the AMR RAB is set up. The RNCindicates an attempt to GSM by sending a RAB ASSIGNMENTRESPONSE message with a RAB ID included in the list of RABs failed toset up and a cause value of "Directed Retry". After that the RNC begins arelocation by sending a RELOCATION REQUIRED message to the CoreNetwork with the cause value "Directed Retry" and Cell Global ID toindicate the target cell. The handover is blind because no inter-RATmeasurements are performed for the connection in question before thehandover. The target cell is always the first GSM cell in the neighbour listof the source cell.

1.2.3 System impact

1.2.3.1 Hardware requirements

This feature does not require any new or additional HW.

DN70296245Issue 1-5 en13/06/2008



1.2.3.2 Software requirements

RAS RNCBTSUltra

BTSFlexi

BTSPico AXC

NetAct MSC SGSN MGW UE

Release

RAS06ED1

RN3.0 - - - - - - - - -

1.2.3.3 Software sales information

OSW/ASW RAS SW componentLicence control innetwork element

Licence controlattributes

ASW RAN - -

1.2.3.4 Management plane

Management data

Parameters Counters Alarms

No parameters related to thisfeature

No counters related to this feature No alarms related to this feature

1.3 RAN831: Wideband AMR Codec Set (12.65, 8.85,6.6)

1.3.1 Introduction

Wideband AMR speech codec enhances audio bandwidth from 300Hz -3.4 KHz to 50Hz - 7kHz, which improves the transparency of calls.Enhanced lower frequency response makes voice warmer whilstenhanced higher frequency response improves the intimacy of voice.


Wideband AMR provides step-like improvement on voice quality overcurrent telephony solutions without RAN capacity trade-offs since the bitrates are similar to AMR. The TrFO/TFO needed due to wideband AMR(WB-AMR) reduces the need of CN investments.




This feature supports a set of WB-AMR codec modes 12.65, 8.85 and 6.6kbps. WB-AMR provides better speech quality than narrowband AMR (NB-AMR) and fixed lines (G.711 PCM) between WB AMR capable UEs. Toavoid downsampling from 16kHz to 8kHz, yielding to quality degradation,either TFO or TrFO is needed.

The RNC handles the WB-AMR modes as well as multi-RABs similarly toNB-AMR. The codec modes 12.65, 8.85 and 6.6 kbps form a set of bitrates (TFS) that is assigned to every WB-AMR call. The limited TFCS inmulti-RAB cases, the functionality of TFO/TrFO and managing the IuSupport Mode are similar to the feature AMR Codec Sets (12.2, 7.95, 5.90,4.75) and (5.90, 4.75).

1.3.3 System impact




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - OSS4.2

M13.6 - U3C 3GPPRel-5




ASW RAN RNC parameter file Long-term ON/OFFlicence


NMS interfaces

Reporting Tools:

DN70296245Issue 1-5 en13/06/2008



. Existing RAN_KPI_0002 for AMR Service Setup Success includesautomatically W-AMR service setups

. Existing RAN_KPI_0006 for AMR Service Success includesautomatically W-AMR service releases

. New KPIs for W-AMR usage

Network element user interfaces

RNC Element Manager:

. The counters are added to the Traffic Measurement.

Management data


Configured CS WAMR mode sets DCH ALLO FOR WAMR 12.65KBPS IN SRNC

DCH ALLO FOR WAMR 6.6 KBPSIN SRNC

DCH ALLO DURA FOR WAMR12.65 KBPS IN SRNC

DCH ALLO DURA FOR WAMR 6.6KBPS IN SRNC

DCH ALLO FOR WAMR 12.65KBPS IN DRNC

DCH ALLO FOR WAMR 8.85KBPS IN DRNC

DCH ALLO FOR WAMR 6.6 KBPSIN DRNC

DCH ALLO DURA FOR WAMR12.65 KBPS IN DRNC

DCH ALLO DURA FOR WAMR8.85 KBPS IN DRNC

DCH ALLO DURA FOR WAMR 6.6KBPS IN DRNC

DCH MOD DUE TO SWITCHINGFROM WAMR TO NAMR IN SRNC

DCH MOD DUE TO SWITCHINGFROM NAMR TO WAMR IN SRNC

DCH MOD DUE TO SWITCHINGFROM WAMR TO NAMR IN DRNC

DCH MOD DUE TO SWITCHINGFROM NAMR TO WAMR IN DRNC

No alarms related to this feature



1.4 RAN1013: 16 kbit/s Return Channel DCH Data RateSupport for HSDPA

1.4.1 Introduction

The uplink (UL) dedicated channel (DCH) data rate of 16 kbit/s for high-speed downlink packet access (HSDPA) return channel is supported.


OPEX and CAPEX savings can be achieved by more flexible resourceallocations for HSDPA.


This feature adds 16 kbps data rate to the set of data rates available for anHSDPA UL-associated DCH. As a result, the enabled data rates are 16kbps, 64 kbps, 128 kbps and 384 kbps. Radio resource management(RRM) features RAN242: Flexible Upgrade of NRT DCH Data Rate andRAN409: Throughput-based Optimisation of the Packet SchedulerAlgorithm control the dynamic selection of HSDPA UL-associated DCHdata rate according to actual utilisation of the channel. The utilisationthresholds controlling the bit rate upgrades and downgrades are operator-configurable.

In case of baseband congestion, feature RAN395: Enhanced PriorityBased Scheduling and Overload control for NRT Traffic downgrades theexisting DCH(s) to a lower data rate. With growing traffic, the existingDCHs are downgraded from higher data rates eventually down to 16 kbit/suntil the maximum number of users in the BTS is achieved.

This feature provides flexibility for using HSDPA resources. High bit ratescan still be achieved with a low number of WSPs either with low load or byadjusting the minimum allowed bit rate of the UL DCH to 64 kbit/s (lessusers). By having 16 kbit/s data rate supported for HSDPA return channel,the operator can optimise the BTS WSP resource consumption.

Similarly, transport resources are saved, as overbooking functions moreefficiently when there is more granularity on the nominal bit rates.

16 kbps UL-associated DCH is supported also together with AMR/WB-AMR voice call.

DN70296245Issue 1-5 en13/06/2008



1.4.3 System impact

1.4.3.1 Current implementation

Prior to this feature, the supported data rates for HSDPA UL-associatedDCH are 64 kbps, 128 kbps and 384 kbps.




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - OSS4.2 - - - 3GPPRel-5




ASW HSPA RNC LK Long-term ON/OFFlicence


NMS interfaces

Reporting Tools:

. New RAN_KPI_0071 for HS-DSCH Session Setup Success

. Existing RAN_KPI_0038 for HS-DSCH Resource Setup Success

. New KPIs for 16 kbit/s return channel usage





. The new 16 kbit/s return channel counters will be added to the TrafficMeasurement.

. The HS-DSCH resource reservation counters are already existing inTraffic Measurement.

. The new HS-DSCH session counters are found in the new PacketCall Measurement.

Management data


HSDPA 16 kbps UL DCH returnchannel on/off switch

HSDPAminAllowedBitrateUL

HSDPAinitialBitrateUL

HS-DSCH 16 KBPS RETURN CHALLOCATIONS FORINTERACTIVE

HS-DSCH 16 KBPS RETURN CHALLOCATIONS FORBACKGROUND

HS-DSCH 16 KBPS RETURN CHDURATION FOR INTERACTIVE

HS-DSCH 16 KBPS RETURN CHDURATION FOR BACKGROUND

HS-DSCH 16 KBPS RETURN CHIUB TRANSPORT SETUPFAILURE FOR INTERACTIVE

HS-DSCH 16 KBPS RETURN CHIUB TRANSPORT SETUPFAILURE FOR BACKGROUND


1.5 RAN852: HSDPA 15 Codes

1.5.1 Introduction

RAN852: HSDPA 15 Codes allows higher peak rates as well as largercapacity. The average cell throughput is increased by about 50% in amacro cell environment compared to having 5 codes. The peak bit rate forsingle user is 7.2 Mbps. Peak cell level total throughput is 10.8 Mbps (withcode multiplexing). If features RAN1249: HSDPA 10 Mbps per User andRAN1305: HSDPA 14.4 Mbps per Cell are activated then the figures are10 Mbps per User and 14.4 Mbps per Cell.

DN70296245Issue 1-5 en13/06/2008




Higher data rates improve the end-user experience. HSDPA 15 codesprovides more cell capacity compared to HSDPA 10 codes solution. Newdata service availability results in increased revenue. Increased cellcapacity means savings in CAPEX and OPEX.


RAN852: HSDPA 15 Codes feature is a further evolution of featuresRAN763: Basic HSDPA with QPSK and 5 Codes and RAN764: HSDPA 16QAM Support allowing higher peak data rates and increased average cellthroughput. The peak bit rate for single user is 7.2 Mbps. The peak celllevel total throughput is 10.8 Mbps (with code multiplexing). If featuresRAN1249: HSDPA 10 Mbps per User and RAN1305: HSDPA 14.4 Mbpsper Cell are activated then the figures are 10 Mbps per User and 14.4Mbps per Cell.

Depending on the UE category, the RLC payload size of 640 bits may beused when RAN852: HSDPA 15 Codes is enabled.

RAN852: HSDPA 15 Codes allows higher peak rates as well as largercapacity. The average HSDPA cell throughput depends on the maximumnumber of allocated HS-PDSCH codes. When allocating the maximum of10 HS-PDSCH codes, the average cell throughput is increased by about30% in a macro cell environment compared to having only 5 HS-PDSCHcodes.

Allocating the maximum of 15 HS-PDSCH codes increases the averagecell throughput by about 50% compared to the same 5-code referencescenario. In a frequency layer dedicated for HSDPA, the gains aresignificantly higher, as well as in micro cells.

1.5.3 System impact


HSDPA with 5 codes and 16QAM modulation allow 3.6 Mbps air interfacepeak rate.






RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - OSS4.2 - SGN3 - 3GPPRel-5




ASW HSPA RNC LK Long-term capacitylicence


NMS interfaces

Reporting Tools:

. Current RAN_KPI_0042 for HSDPA effiency is updated with the newcounters.

. New RAN_KPI_0059 for SF code blocking rate.

. New KPI for HS-PDSCH code allocations.


BTS Element Manager:

. The new HARQ transmission vs. retransmission (per increased HS-PDSCH code amounts) counters are added to the HSPA in WBTSMeasurement.

. The counters produced by BTS are also viewable via RNC ElementManager.


. The HS-PDSCH code reservation counters are added to the CellResource Measurement.

. The new SF request counters are added to the Cell ResourceMeasurement.

DN70296245Issue 1-5 en13/06/2008



Management data


Maximum number of HS-SCCHcodes

HS-PDSCH code adjustment period

Bit rate threshold for RLC PDU size656 with HS-DSCH

Number of HS-PDSCH codes forgreater RLC PDU size

SIR threshold for RLC PDU size656 with HS-DSCH

Usage of RLC PDU size 656 withHS-DSCH

NRT DPCH over HS-PDSCH codeoffset

HS-PDSCH code upgrade marginfor SF128 codes

Maximum bit rate of NRT MAC-dflow

DURATION OF HSDPA 11 CODESRESERVATION





ORIGINAL MAC-HS PDUTRANSMISSION WITH 11 CODEBY QPSK





ORIGINAL MAC-HS PDUTRANSMISSION WITH 11 CODEBY 16QAM





MAC-HS PDU RETRANSMISSIONWITH 11 CODE BY QPSK









MAC-HS PDU RETRANSMISSIONWITH 11 CODE BY 16QAM





1.6 RAN853: HSDPA Code Multiplexing

1.6.1 Introduction

RAN853: HSDPA code multiplexing enables simultaneous transmission ofa maximum of three HSDPA users within a single cell during a singleTransmission Time Interval (TTI). HSDPA code multiplexing improves thecode resource utilisation and subsequently, improves the cell throughtputby 30 to 50% and beyond.


Improved end-user experience is acquired thanks to better cell throughputin the case of simultaneous users supporting a maximum of 5 codes.CAPEX and OPEX savings result from increased cell capacity.

DN70296245Issue 1-5 en13/06/2008




This feature allows sending data packets to more than one HSDPA usersimultaneously in each 2ms TTI. Code multiplexing can be used when atleast two high-speed secondary control channel (HS-SCCH) codes areallocated by the RNC. With this feature 2-3 users can be code-multiplexedon HS-PDSCH depending on HS-PDSCH and HS-SCCH allocation. Theavailable code and power resources are evenly shared between thescheduled users.

The decision on how many users are scheduled per cell is doneindependently on each TTI. The general rule is that when the UE categorywith the highest scheduling metric from proportional fair schedulingalgorithm is supporting less codes than the cell has available, thenpotentially (in case the first user cannot use all the available power) asecond UE is scheduled as well. The second UE to be scheduled is theone with the second highest scheduling metric. If the two scheduled UEsare both supporting a maximum of 5 codes each, then a third user ispotentially scheduled as well.

Note that code multiplexing does not provide any throughput gains in acase where the UEs support as many codes as the NW. In such ascenario, the optimal strategy from spectral efficiency point of view is toschedule a single user at a time. This decreases the power spent forcontrol channels (only one HS-SCCH needed instead of several) andincreases the gain from proportional scheduling.

With code multiplexing it is possible to use a code space that is larger thanfive codes also with UEs that support only five codes. The NW capacitygain from code multiplexing is similar to the gain from 15 codes in the casewhere most of the users are supporting a maximum of 5 codes.

1.6.3 System impact


Without code multiplexing a single user is scheduled in a cell per TTI.






RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - OSS4.2

- - - 3GPPRel-5






NMS interfaces

Reporting Tools:

. New KPIs for TTI users



. The TTI user amount counters are added to the HSPA in WBTSMeasurement.


Management data


Maximum number of HS-SCCHcodes

HSDPA USERS 0 IN TARGETCELL 1 IN OTHER CELL





DN70296245Issue 1-5 en13/06/2008









HSDPA USER BUFFERS WITHDATA IN THE BUFFER FOR EACHTTI

RECEIVED DATA IN MAC-D PDUS

DISCARDED DATA IN MAC-DPDUS

1.7 RAN1033: HSDPA 48 Users per Cell

1.7.1 Introduction

The maximum number of simultaneous HSDPA users in a cell is increasedto 48.


CAPEX and OPEX savings are achieved by increasing the number ofsimultaneous HSDPA end users in a cell. Instant access to data servicesafter momentary inactivity periods improves the end-user experience.


This feature allows 48 simultaneous HSDPA users per cell. Thisconsumes the whole UltraSite WSPC card/Flexi WCDMA BTS submoduleper cell.



A higher number of users allows higher user volumes to be served. Theend-user experience is improved in any ON/OFF type of service, that is, aservice with momentary inactivity periods, since a higher number of userscan be kept on cell_DCH state for longer periods. Such services are, forexample, web or WAP browsing and gaming.

1.7.3 System impact


Currently, the maximum number of simultaneous HSDPA users per cell is16. This is achieved by dedicating 32 Channel Elements (CE) from oneUltraSite WSPC card/Flexi WCDMA BTS sub-module for each HSDPAcapable cell.


WSPC card per HSDPA scheduler is required in UltraSite WCDMA BTS.Pico WCDMA BTS supports 32 users per cell.

1.7.3.3 Interdependencies between features

WSPC card per HSDPA scheduler is required in UltraSite BTS. Pico BTSsupports 32 users per cell.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - OSS4.2

- - - 3GPPRel-5





DN70296245Issue 1-5 en13/06/2008




NMS interfaces

Reporting Tools:

. New KPIs for average number of HSDPA users

. New KPIs for peak number of HSDPA users



. The new counters are added and the old ones are found in the CellResource Measurement.

Management data


HSDPA 48 users enabled DURATION OF ACTIVE HSDPAUSERS - 17 TO 20SIMULTANEOUS USERS

DURATION OF ACTIVE HSDPAUSERS - 21 TO 24SIMULTANEOUS USERS










1.8 RAN1034: Shared HSDPA Scheduler for BasebandEfficiency

1.8.1 Introduction

This feature enables simultaneous HSDPA transmission to a maximum ofthree HSDPA-capable cells by using a single UltraSite WSPC card or onesub-module in Flexi WCDMA BTS.

Shared HSDPA Scheduler supports 48 HSDPA users per BTS. 10.8 Mbpsmaximum HSDPA throughput per BTS is provided. 15 codes per cell and45 codes per BTS is supported. The peak bit rate for a single user is 7.2Mbps. If feature RAN1249: HSDPA 10 Mbps per User is activated, then thefigure is 10 Mbps per User.


Statistical multiplexing gain and superior baseband efficiency result inCAPEX and OPEX savings. HSDPA throughput and users from up to threecells can be multiplexed in a single Shared HSDPA Scheduler requiringonly one UltraSite WSPC card/Flexi WCDMA BTS sub-module. Superiorperformance is gained with a minimum number of CEs.

Increased HSDPA capacity means increased revenue and better end-userexperience. HSDPA capacity is increased both in terms of a number ofusers supported and cell throughput. The increased capacity improvesend-user performance with higher average bit rates.


The Shared HSDPA Scheduler for Baseband Efficiency allows a singleUltraSite WSPC card(Flexi WCDMA BTS sub-module to handle theprocessing of HSDPA for 1, 2 or 3 cells simultaneously. 48 simultaneousHSDPA users are supported by the card. These users can be divided inany combination among the cells handled by the card.

It is possible to use all 15 HSDPA codes in all three cells simultaneouslywith the RAN1034: Shared HSDPA Scheduler for Baseband Efficiencyscheduler. However, on each TTI the total bit rate over all cells has to bebelow 10.8 Mbps. Therefore, even though there is no code limitation, thethroughput is limited to 10.8 Mbps per UltraSite WSPC card/Flexi WCDMABTS sub-module. On those TTIs where the total bit rate for all scheduledUEs would exceed 10.8 Mbps, the NodeB will clip data from the highest bitrate user so that the maximum limit of 10.8 Mbps is not exceeded.

DN70296245Issue 1-5 en13/06/2008



Note that 15 codes simultaneously in each cell is beneficial even with thetotal bit rate limitation, since in optimal link adaptation the number of codesis increased prior to increasing coding rate or modulation. For example,the 15th code should be taken into use already at 2.4 Mbps when codesare available, since spectrally this is more efficient than using less codesbut having higher order modulation or less robust error protection coding.

Therefore, all 45 codes of three cells can be taken to full use when the totalthroughput in the BTS is 3*2.4 Mbps = 7.2 Mbps. As a result, the ability touse all 15 codes in each cell simultaneously increases the practicalaverage cell throughputs significantly, even though the theoretical peakthroughputs are not affected.

The benefit of RAN1034: Shared HSDPA Scheduler for BasebandEfficiency is more efficient utilisation of baseband capacity. For 1+1+1configuration, one UltraSite WSPC card/Flexi WCDMA BTS sub-modulewith RAN1034: Shared HSDPA Scheduler for Baseband Efficiency offersalmost the same performance as three UltraSite WSPCs/Flexi WCDMABTS sub-modules. The loss in performance is due to fact that the totalcombined bit rate on each TTI has to be below 10.8 Mbps. However, as theair interface limits the average cell throughput to around 2 Mbps in macroenvironment, there is no real difference in cell level throughput.

Note that code shared scheduler is offering clearly better performance onthe air interface than using 32 CE reservation per cell (RAS05.1configuration). This is because with a code shared scheduler each cell iscapable of achieving the peak bit rate of 10.8 Mbps when the other cellsare not loaded. Also as the code shared scheduler has no limitation on thenumber of codes (as opposed to the maximum of five codes per cell withRAS05.1 configuration), the link adaptation algorithm is able to usespectrally a more efficient method of increasing the number of codesbeyond five before going to more robust coding rate and higher ordermodulation. This means that in given SINR conditions, 1+1+1 NodeB withcode shared scheduler offers significantly better throughput than staticallocation of 5 codes per sector.

1.8.3 System impact


Currently there are two options for baseband allocation of HSDPA users inthe BTS:



. Option one (minimum baseband allocation): Single UltraSite WSPCcard/Flexi WCDMA BTS sub-module serves three HSDPA-capablecells and the HS-DSCH transmission is time-multiplexed betweenthe cells (only one HSDPA cell can be transmitted to at each TTI).The maximum air interface peak rate is 3.6 Mbps and a maximum of16 simultaneous HSDPA users per BTS can be served. 32 CE fromUltraSite WSPC card/Flexi WCDMA BTS sub-module is consumedfor HSDPA.

. Option two (dedicated baseband allocation): Single UltraSite WSPCcard/Flexi WCDMA BTS sub-module is dedicated for each HSDPAcell (all HSDPA cells can transmit simultaneously). 32 CE from eachUltraSite WSPC card/Flexi WCMDA BTS sub-module is consumedfor HSDPA, and the remaining 32 CE are used for DCH traffic (orcommon channels). The maximum air interface peak rate is 3.6Mbps per cell and 16 simultaneous HSDPA users per cell can beserved.




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

- - - - - - 3GPPRel-5




ASW HSPA BTS LK Long-term ON/OFFlicence


NMS interfaces

Reporting Tools:

DN70296245Issue 1-5 en13/06/2008



. New RAN_KPI_0063 and RAN_KPI_0064 for BTS Baseband useeffiency for HSUPA BTS CEs.

. Existing RAN_KPI_0046 and RAN_KPI_0047 for BTS Basebanduse effiency for all BTS CEs.



. The new HSUPA CE counters are added to the WBTS HWResource Measurement.

. The existing CE counters are found in the WBTS HW ResourceMeasurement.


Management data















1.9 RAN312: HSDPA Dynamic Resource Allocation

1.9.1 Introduction

Dynamic HSDPA channelisation codes allocation enables full cell resourceutilisation, better end-user experience and increased NW capacity.


The gain in cell throughput is achieved as the cell resources are betterutilised for a varying traffic mix. Operator control on resource divisionbetween NRT DCH and HSDPA allows flexible support of different pricingstrategies for DCH and HSDPA data.


NodeB dynamically controls the amount of power used for HSDPA. TheHSDPA power can be controlled by each TTI, that is, in intervals of 2 ms.All the power left after DCH traffic, HSUPA control channels and commonchannels is used for HSDPA. This means that as long as there is HSDPAtraffic in the cell, all the available PA power can be efficiently utilised.

RNC will still schedule the NRT DCH bit rates. The higher bit rates theRNC allocates for NRT DCHs, the less there is "spare" power that theNodeB can use for HSDPA. To avoid situations where very unfairdistribution of power is created between HSDPA and NRT DCH users, theRNC takes into account both the current number of NRT DCH and HSDPAusers in the cell when allocating NRT DCH bit rates. By default, the RNCwill treat NRT DCH and HSDPA users equal in the sense that NRT DCH bitrates are allocated in such way that roughly equal amount of tx power peruser is available to both NRT DCH users and HSDPA users. This does notmean that each user would have equal bit rates. It simply means that if in a20 W cell there happens to be 8 W of RTand common channel load, thenabout 12 W is available for NRT traffic. This 12 W is then divided so that incase of 2 NRT DCH users and 10 HSDPA users, about 2 W would begiven to the DCH side and 10 W to HSDPA side. The RNC does notdirectly guide the NodeB in allocating the power for HSDPA, but the RNCdoes affect this implicitly by a decision of NRT DCH bit rates.

On an operator choice, the priority between NRT DCH and HSDPA can beweighed so that power is aimed to be spent in relation p1 : p2, where p1represents the target tx power per user available for NRT DCH and p2 thetarget tx power per user available for HSDPA. In addition, users with higherTraffic Handling Priority (THP) can be counted more important when

DN70296245Issue 1-5 en13/06/2008



deciding the division between power for NRT DCH side and HSDPA side.THP is not taken into account in actual HSDPA scheduling, but all HSDPAusers are given roughly equal resources according to proportional fairscheduling principle.

The code allocation is dynamically following the power allocation. Inpractice this means that once the NRT DCH bit rates have been decided,based on equal power criterion, the code requirements for the DCH sidehave been fixed. All other codes are then given to the HSDPA (operatormay leave some margin to allow fast voice call allocation). In case of newDCH connections (for which the bit rate is again determined based onpower criteria), the required amount of HSDPA codes are given back to theDCH.

1.9.3 System impact


The RNC allocates fixed codes. In RAS05.1, the power is allocateddynamically by the BTS by HSDPA Dynamic Power Allocation. Theminimum adjustment period of HSDPA power is 100 ms in RAS05.1 and 2ms in RAS06.




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - OSS4.2 - - - -








NMS interfaces

Reporting Tools:

. New RAN_KPI_0069 for HSPA power level

. New RAN_KPI_0059 for SF blocking

. KPIs for HS-DSCH related SF allocation distribution (6-15)

. KPIs for HS_DSCH <> DCH switches

. KPIs for HSDPA power targets

. KPIs for HS-DSCH related state transition



. The new HSPA/HSDPA power and HS-PDSCH SF counters will beadded to the Cell Resource Measurement.

. The new channel switching counters will be added to the new PacketCall Measurement.

. The new HS-DSCH state transition counters will be added to theRRC Signaling Measurement.

Management data


Weight of NRT DCH UE

Weight of NRT DCH UE BG RAB

Weight of NRT DCH UE THP1RAB



Weight of HSPA UE

Weight of HSPA UE BG RAB

Weight of HSPA UE THP1 RAB



MINIMUM PTXTARGETPS

MAXIMUM PTXTARGETPS

AVERAGE PTXTARGETPS

PTXTARGETPS DENOM

MIN HSPA DL POWER

MAX HSPA DL POWER

AVE HSPA DL POWER

HSPA DL POWER SAMPLES




DN70296245Issue 1-5 en13/06/2008




Retry time for u-plane resourceallocation in Cell_DCH

High threshold of PtxTotal fordynamic HSDPA pwr alloc

DCH PS target adjust period fordyn HSDPA pwr alloc

Max DCH PS target for dynamicHSDPA pwr allocation

Min DCH PS target for dynamicHSDPA pwr allocation

DCH PS target step down fordynamic HSDPA pwr alloc

DCH PS target step up for dynamicHSDPA pwr alloc

HS-PDSCH code adjustment period

Bit rate threshold for RLC PDU size656 with HS-DSCH

Number of HS-PDSCH codes forgreater RLC PDU size

SIR threshold for RLC PDU size656 with HS-DSCH

Usage of RLC PDU size 656 withHS-DSCH

NRT DPCH over HS-PDSCH codeoffset

HS-PDSCH code upgrade marginfor SF128 codes

HSDPA Dynamic ResourceAllocation

PtxnonHSPA averaging windowsize for LC










CHANNELIZATION CODE SF4REQUESTED







HSDPA CH CODE DOWNGRADEDUE TO RT

HSDPA CH CODE DOWNGRADEDUE TO NRT DCH

CHANNEL TYPE SWITCH FROMDCH TO HS-DSCH FORINTERACTIVE

CHANNEL TYPE SWITCH FROMDCH TO HS-DSCH FORBACKGROUND

CELL FACH STATE TO HS-DSCH




SWI HS-DSCH/E-DCH TO HS-DSCH/DCH FOR INTERACTIVE

SWI HS-DSCH/E-DCH TO HS-DSCH/DCH FOR BACKGROUND

SWI HS-DSCH/E-DCH TO DCH/DCH FOR INTERACTIVE

SWI HS-DSCH/E-DCH TO DCH/DCH FOR BACKGROUND

SWI HS-DSCH/DCH TO HS-DSCH/E-DCH FOR INTERACTIVE

SWI HS-DCSH/DCH TO HS-DSCH/E-DCH FOR BACKGROUND

SWI DCH/DCH TO HS-DSCH/E-DCH FOR INTERACTIVE

SWI DCH/DCH TO HS-DSCH/E-DCH FOR BACKGROUND

1.10 RAN826: Basic HSUPA

1.10.1 Introduction

This feature provides the High Speed Uplink Packet Access (HSUPA)functionality, also known as Enhanced Uplink DCH (E-DCH). HSUPAfunctionality is based on the following techniques:

. BTS-controlled scheduling of the E-DCH within the limits set by theRNC

. Physical layer retransmission handling in the BTS


Increased UL average and peak data rates improve the end-userexperience. CAPEX and OPEX savings result from increased cell ULcapacity and increased Iub and BTS HW efficiency. New data serviceavailability increases revenue.


The basic characteristics of the feature are listed below:

DN70296245Issue 1-5 en13/06/2008



. HSUPA is supported only with co-existence of HSDPA.

. All cells in the BTS can be enabled for HSUPA.

. The maximum number of HSUPA users per BTS is 24 (in larger than6-cell configurations two local cell groups have to be used, and thenHSUPA is handled independently on both local cell groups). Themaximum number of HSUPA users in a cell is 20, limited byavailable signatures in E-RGCH/E-HICH channels. One E-AGCHand one E-RGCH/E-HICH code channels are configured to eachserving E-DCH cell. The maximum number of simultaneous HSUPAserving users is 19 in a cell, and one signature is reserved for non-serving HSUPA users.

. The operator can choose to set a lower threshold for the maximumnumber of users per cell and per BTS.

. TTI of 10 ms is used for maximizing the resulting UL range.

. The largest supported E-DCH category is 3 (1.44 Mbps),corresponding to two parallel codes of spreading factor four (2xSF4).

. HSUPA activation requires a static reservation of UltraSite WSPCcard/Flexi WCDMA BTS sub-module) capacity. Rest of the HSUPAbaseband capacity is fully pooled across cells, and also dynamicallyshared with R99 traffic. Up to two UltraSite WSPC cards/FlexiWCDMA BTS sub-modules can be in HSUPA use, R99 trafficallowing.

For Ultrasite WCDMA BTS it is possible to enable HSDPA andHSUPA in three sectors on a single shared WSPC card, usingRAS05 HSDPA 16 users per BTS scheduler. This allows operatorsto roll out a fast and cost-efficient HSUPA service.

In case of high capacity UltraSite WCDMA BTS HSPA sites, theoperator can select an alternative HSUPA activation on separatedWSPC cards. WSPC (64 CE) per BTS or WSPC per cell for HSDPAcan be used to increase HSDPA capacity.

These together provide a high-capacity HSPA solution:

. The maximum peak data rate per user is 1.44 Mbps as coded L1 bitrate (error protection coding is not counted into bit rate but L1retransmissions are). If feature RAN979: HSUPA 2.0 Mbps isactivated, then the peak data rate per user is 2.0 Mbps.

. One UltraSite WSPC card/Flexi WCDMA BTS sub-module supportsup to 24 HSUPA users.

. The minimum combined L1 baseband throughput of all users perUltraSite WSPC card/Flexi WCDMA BTS sub-module is 4.2 Mbps.



. HSUPA channel coding functionality includes E-DCH Absolute GrantChannel (E-AGCH), E-DCH Relative Grant Channel (E-RGCH) andE-DCH Hybrid Automatic Repeat Request (ARQ) Indicator Channel(E-HICH) encoding in DL and E-DCH Dedicated Physical DataChannel (E-DPDCH) and E-DCH Dedicated Physical ControlChannel (E-DPCCH) decoding in UL.

. HSUPA Hybrid Automatic Repeat Request (H-ARQ) operationhandling per UE in E-DCH Medium Access Control (MAC-e) entitywithin a BTS.

. HSUPA Service Indicator is supported.

The total cell data rate for HSUPA users is scheduled between theHSUPA-capable UEs in a cell. Scheduling is performed by the NodeB in afast cycle by using mainly relative grants. All UEs get as much bit rate asthey can send in a non-congested case. In case of congestion, roughlyequal noise rise contribution is allowed for each user.

For facilitating smooth mobility operations with non-HSUPA capable BTSs,Signaling Radio Bearer (SRB) is mapped on DCH.

HSUPA traffic is mapped on a dedicated Iub virtual channel connection(VCC), allowing Iub capacity consumption to be optimised for NRT HSUPAtraffic, while preserving the QoS of real-time services, which are mappedon another VCC. The operator may also configure a minimum service levelfor HSUPA by dedicating a minimum amount of baseband channelelements (CEs) for HSUPA.

HSUPA improves the UL packet data performance by providing higherdata rates over the whole cell area, increasing the peak data rate andreducing delay. HSUPA also increases the system capacity by improvingthe cell throughput and the efficiency of the transport and BTS hardwareresources. HSUPA benefits are especially significant for bursty high bitrate applications.

In a non-congested, single user case the maximum bit rates are greatlyimproved, since instead of practical maximum of 384 kbps with R99, 1.4Mbps can be reached with HSUPA. In a loaded NW with congestion, thecapacity gain from HSUPA is expected to be on the order of 20%-50%.

HSUPA Service Indicator indicates the HSUPA capability to the UEs.HSUPA-capable cell means that the UE may consider this cell/any cell inthe same sector as part of the HSUPA coverage area to display HSUPAservice indication.

DN70296245Issue 1-5 en13/06/2008



1.10.3 System impact


Prior to HSUPA, the maximum practical peak bit rate is 384 kbps, ULpacket scheduling is handled by the RNC and retransmissions arehandled by the RLC (as opposed to L1 HARQ retransmissions in HSUPA).




RAN923: Pico WCDMA BTS with Ethernet Transport supports 6 users percell.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0







NMS interfaces

Reporting Tools:

. New RAN_KPI_0063 and RAN_KPI_0064 for HSUPA CE UL vs. DLconsumption

. New RAN_KPI_0065 for HSUPA UL Power levels in BTS

. New KPI for HSUPA DL power levels in BTS



. New KPIs for HSUPA UE Capability

. New KPIs for HSUPA users per cell



. The HSUPA capability counters are added to the Service LevelMeasurement.

. The HSUPA user counters are added to the Cell resourceMeasurement.


. The HSUPA CE counters are added to the WBTS HW ResourceMeasurement.

. The HSUPA Power level counters are added to the HSPA in WBTSMeasurement.


Management data


Maximum Reordering Wait Time forMAC-es

E-DCH Capability

Operational E-DCH state

BTS HSUPA NOT HW LIMITEDDURATION

BTS HSUPA HW LIMITEDDURATION

BTS HSUPA HW NO CAPACITYDURATION

DURATION OF NO ACTIVEHSUPA USERS

DURATION OF ACTIVE HSUPAUSERS - 1 OR 2 SIMULTANEOUSUSERS




7780 HSUPA DISABLED IN WCEL

7782 HSUPA CONFIGURATIONFAILED

DN70296245Issue 1-5 en13/06/2008




DURATION OF ACTIVE HSUPAUSERS - 9 OR 10SIMULTANEOUS USERS






UE SUPPORT FOR E-DCHCATEGORY 1






UL E-DCH HARQRETRANSMISSIONS

TRANSFERRED DATA FOR NRTE-DCH

HSUPA DL PHYSICAL CHANNELPOWER DISTRIBUTION - CLASS01









HSUPA MINIMUM MAC-DTHROUGHPUT

HSUPA MAXIMUM MAC-DTHROUGHPUT

HSUPA AVERAGE MAC-DTHROUGHPUT

HSUPA UL MINIMUM PHYSICALCHANNEL POWER

HSUPA UL MAXIMUM PHYSICALCHANNEL POWER

HSUPA UL AVERAGE PHYSICALCHANNEL POWER

HSUPA UL PHYSICAL CHANNELPOWER SAMPLE COUNTER

MAXIMUM NUMBER OF USED CEFOR HSUPA UL

MINIMUM NUMBER OF USED CEFOR HSUPA UL

AVERAGE NUMBER OF USED CEFOR HSUPA UL

MAXIMUM NUMBER OF USED CEFOR HSUPA DL

MINIMUM NUMBER OF USED CEFOR HSUPA DL

AVERAGE NUMBER OF USED CEFOR HSUPA DL

HS-DSCH/E-DCH PACKET CALLATT FOR INTERACTIVE

HS-DSCH/E-DCH PACKET CALLATT FOR BACKGROUND

HS-DSCH/E-DCH ALLO AFTERHS-DSCH/E-DCH REQ FORINTERACTIVE

HS-DSCH/E-DCH ALLO AFTERHS-DSCH/E-DCH REQ FORBACKGROUND

HS-DSCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FORINTERACTIVE

DN70296245Issue 1-5 en13/06/2008




HS-DSCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FORBACKGROUND

DCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FORINTERACTIVE

DCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FORBACKGROUND

SWI HS-DSCH/E-DCH TO HS-DSCH/DCH FOR INTERACTIVE

SWI HS-DSCH/E-DCH TO HS-DSCH/DCH FOR BACKGROUND

SWI HS-DSCH/E-DCH TO DCH/DCH FOR INTERACTIVE

SWI HS-DSCH/E-DCH TO DCH/DCH FOR BACKGROUND

SWI HS-DSCH/DCH TO HS-DSCH/E-DCH FOR INTERACTIVE

SWI HS-DCSH/DCH TO HS-DSCH/E-DCH FOR BACKGROUND

SWI DCH/DCH TO HS-DSCH/E-DCH FOR INTERACTIVE

SWI DCH/DCH TO HS-DSCH/E-DCH FOR BACKGROUND

HS-DSCH/E-DCH PACKET CALLNORM REL FOR INTERACTIVE

HS-DSCH/E-DCH PACKET CALLNORM REL FOR BACKGROUND

HS-DSCH/E-DCH PACKET CALLREL DUE TO PRE-EMP FORINTERACTIVE

HS-DSCH/E-DCH PACKET CALLREL DUE TO PRE-EMP FORBACKGROUND

HS-DSCH/E-DCH PACKET CALLREL DUE TO RL FAIL FORINTERACTIVE

HS-DSCH/E-DCH PACKET CALLREL DUE TO RL FAIL FORBACKGROUND

HS-DSCH/E-DCH PACKET CALLREL DUE TO OTHER FAIL FORINTERACTIVE




HS-DSCH/E-DCH PACKET CALLREL DUE TO OTHER FAIL FORBACKGROUND

1.11 RAN973: HSUPA Basic RRM

1.11.1 Introduction

This feature provides the essential Radio Resource Management (RRM)functionality for HSUPA operation.


HSUPA RRM in the RNC algorithm reserves the required codes and powerfor the E-AGCH, E-RGCH and E-HICH physical channels in DL. In UL, acertain noise rise is reserved for the BTS packet scheduler. This allowsadmitting the DCH users according to the normal admission controlprocedure in the RNC while the remaining noise rise margin is efficientlyutilised for the HSUPA.

HSUPA RRM algorithm in the RNC also makes the E-DCH allocationdecisions. The decision between DCH and E-DCH allocation for a UE isbased on the service (RAB parameters), resource availability, multi-RABcombination and UE capability. HSUPA is supported only with co-existence of HSDPA per UE.

HSUPA RRM algorithm in the RNC also configures the RLC layer, radiobearer, transport channel and physical channel configuration for an E-DCHuser based on RAB parameters. This feature introduces operator-controllable RLC parameters for RB mapped on DCH, E-DCH or HS-DSCH. E-DCH is released based on low throughput detection in both ULand DL.

Furthermore, HSUPA RRM algorithm in the RNC performs combinedpower and throughput-based (hybrid) admission decision and packetscheduling for R99 DCH and/or E-DCH users in the cell. HSUPA RRMalgorithm in the RNC performs HSUPA outer loop power control.

DN70296245Issue 1-5 en13/06/2008







RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - OSS4.2 - - - 3GPPRel-6




OSW HSPA - -


NMS interfaces

Reporting Tools:

. New RAN_KPI_SSSR_PACKET_SESSION for Packet Sessionsetup success rates.

. New RAN_KPI_SSR_PACKET_SESSION for Packet Sessionsuccess rates.

. New RAN_KPI_0072 for E-DCH session allocation success.

. New RAN_KPI_0074 for E-DCH session release success.

. New RAN_KPI_0071 for HS-DSCH session allocation success.

. New RAN_KPI_0073 for HS-DSCH session release success.

. New RAN_KPI_0076 for DCH session allocation success.

. New RAN_KPI_0077 for DCH session release success.

. New RAN_KPI_0060 for E-DCH resource allocation success.

. New RAN_KPI_0061 for E-DCH resource release success.



. New KPI for RLC throughput amounts on E-DCH transport channel.

. New KPI for RLC throughput distribution on E-DCH transportchannel.



. The Packet Session/HS-DSCH/E-DCH/DCH request, reservation,setup failure and release counters will be added to the new PacketCall Measurement.

. The E-DCH request and allocation counters will be added to theTraffic Measurement.

. The RLC throughput counters are automatically added to RCPMRLC AM Measurement (via measurement object, that is, transportchannel object covers also E-DCH).

Management data


AM RLC maximum buffer allocationfor UE

AM RLC maximum buffer allocationfor UE capability 100




AM RLC configuration for PS NRTwith E-DCH

AM RLC status reports count forPS NRT with E-DCH

AM RLC MaxDAT transmissions forPS NRT with E-DCH

AM RLC MaxMRW transmissionsfor PS NRT with E-DCH

AM RLC maxRST transmissions forPS NRT with E-DCH

AM RLC status period max for PSNRT with E-DCH

MIN HSPA DL POWER

MAX HSPA DL POWER

AVE HSPA DL POWER

HSPA DL POWER SAMPLES

UL DCH SELECTED FORINTERACTIVE DUE TO MAXHSUPA USERS

UL DCH SELECTED FORBACKGROUND DUE TO MAXHSUPA USERS

UL DCH SELECTED FORINTERACTIVE DUE TO BTS HWLIMIT

UL DCH SELECTED FORBACKGROUND DUE TO BTS HWLIMIT

E-DCH ALLO CANCEL FORINTERACTIVE DUE TO NONACCEPTABLE AS

E-DCH ALLO CANCEL FORBACKGROUND DUE TO NONACCEPTABLE AS


DN70296245Issue 1-5 en13/06/2008




AM RLC status period min for PSNRT with E-DCH

AM RLC period Poll_PDU for PSNRT with E-DCH

AM RLC period Poll_SDU for PSNRT with E-DCH

AM RLC period Poll_Window forPS NRT with E-DCH

AM RLC status report triggers forPS NRT with E-DCH

AM RLC round trip time with E-DCH

DCH slope of the curve

Window size of E-DCH MAC-d flowthroughput measurement

Low throughput threshold of the E-DCH MAC-d flow

Low throughput time to trigger ofthe E-DCH MAC-d flow

E-DCH maximum number of HARQretransmissions

E-DCH QoS classes

EDCH slope of the curve

Factor to calculate EDCHmaximum bit rate

Happy bit delay condition for E-DCH

Periodicity for scheduling info

Power Offset for Scheduling Info

Step Size for DCH BLERcalculation

Step Size for EDCH BLERcalculation

Threshold to define maximum E-DPDCH SR

Threshold to define maximumEDPDCH SR 1920 kbps

Threshold to define maximumEDPDCH SR 960 kbps

HARQ RV Configuration

Maximum number of E-DCHs in thelocal cell group

DL DCH SELECTED FORINTERACTIVE DUE TO HSDPAPOWER

DL DCH SELECTED FORBACKGROUND DUE TO HSDPAPOWER

E-DCH SETUP FAILURE DUE TOUE FOR INTERACTIVE

E-DCH SETUP FAILURE DUE TOUE FOR BACKGROUND

E-DCH SETUP FAILURE DUE TOBTS FOR INTERACTIVE

E-DCH SETUP FAILURE DUE TOBTS FOR BACKGROUND

E-DCH SETUP FAILURE DUE TOTRANSPORT FOR INTERACTIVE

E-DCH SETUP FAILURE DUE TOTRANSPORT FOR BACKGROUND

E-DCH SETUP FAILURE DUE TOOTHER REASONS FORINTERACTIVE

E-DCH SETUP FAILURE DUE TOOTHER REASONS FORBACKGROUND

E-DCH ALLOCATIONS FORINTERACTIVE

E-DCH ALLOCATIONS FORBACKGROUND

E-DCH ALLOCATION DURATIONFOR FOR INTERACTIVE

E-DCH ALLOCATION DURATIONFOR FOR BACKGROUND

E-DCH NORMAL RELEASE FORINTERACTIVE

E-DCH NORMAL RELEASE FORBACKGROUND

E-DCH RELEASE DUE HS-DSCHSERVING CELL CHANGE FORINTERACTIVE

E-DCH RELEASE DUE HS-DSCHSERVING CELL CHANGE FORBACKGROUND

E-DCH RELEASE DUE TO RLFAILURE FOR INTERACTIVE




PS target tune period in HSPA-DCH interference sharing

Non-EDPCH interference averagingwindow size for LC

E-DCH minimum set E-TFCI

HSUPA enabled

Maximum number of E-DCHs in thecell

Maximum total uplink symbol rate

Number of E-DCHs reserved forSHO branch additions

DCH time limit for UL NRT DCHoverload in E-DCH cell

Interference margin for theminimum E-DCH load

Maximum target received wideband power for BTS

Max PS target in HSPA-DCHinterference sharing

Min PS target in HSPA-DCHinterference sharing

PS target step down in HSPA-DCHinterference sharing

Maximum E-DCH Downlink Power

The transmission power offset ofthe E-AGCH

The transmission power offset ofthe E-HICH

The transmission power offset ofthe E-RGCH

SIR target offset for DPCCH withE-DPCH

Target non-serving E-DCH to totalE-DCH power ratio

AAL2 UP Usage

E-DCH RELEASE DUE TO RLFAILURE FOR BACKGROUND

E-DCH RELEASE DUE TO OTHERFAILURE FOR INTERACTIVE

E-DCH RELEASE DUE TO OTHERFAILURE FOR BACKGROUND

E-DCH ALLO FOR INTER RNCHHO INTERACTIVE

E-DCH ALLO FOR INTER RNCHHO BACKGROUND

E-DCH SETUP FAIL FOR INTERRNC HHO INTERACTIVE

E-DCH SETUP FAIL FOR INTERRNC HHO BACKGROUND

CELL FACH STATE TO HS-DSCH

UL E-DCH HARQRETRANSMISSIONS

DN70296245Issue 1-5 en13/06/2008



1.12 RAN968: HSUPA BTS Packet Scheduler

1.12.1 Introduction

RAN968: HSUPA BTS Packet Scheduler is a fast BTS-based schedulerdetermining the bit rates to be used on E-DCH.

Moving packet scheduling from the RNC to BTS is the key change inHSUPA compared to Rel. 5. The BTS is able to make much fasterdecisions when the RNC does not have to be consulted. This increasesthe efficiency at which especially bursty data can be treated by the packetscheduler.


Increased UL data throughput improves the end-user experience. Inaddition, increased cell UL capacity results in CAPEX and OPEX savings.


HSUPA BTS Packet Scheduler (PS) is a cell-specific scheduler using 10ms scheduling periods with both Absolute Grants (AG) and RelativeGrants (RG). The scheduling decisions are based on the maximumallowed noise rise, minimum throughput and the physical layer feedbackfrom the UEs in a cell. The HSUPA BTS PS also takes into account theavailable baseband resources not needed for R99 DCHs.

In a case where air interface and NW resources are not limiting the datarates, each UE is given as much bit rate as they request, up to a maximumof 1.44 Mbps, and if feature RAN979: HSUPA 2.0 Mbps is activated thenup to 2.0 Mbps. The scheduling grant determined by the PS is applicableto all HARQ processes of the UE. (See RAN992: HSUPA CongestionControl.)



Without HSUPA, the RNC determines UL bit rates. This happens on arelatively slow cycle compared to the BTS-based HSUPA scheduling.






RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - - - - - 3GPPRel-6




OSW HSPA - -


NMS interfaces

Reporting Tools:

. New RAN_KPI_0075 for HSUPA Average MAC-es Throughput.

. New RAN_KPI_0080 for HSUPA MAC-es Data Volumes.

. New RAN_KPI_0062 for HSUPA BLER.



. The MAC-es throughput counters are added to the new CellThroughput Measurement.


. The HARQ retransmission counters are added to the HSPA inWBTS Measurement.


Management data


DN70296245Issue 1-5 en13/06/2008





MAC-E PDU RETRANSMISSIONS0 COUNTER













MAC-E PDU DTX COUNTER

MAC-E PDU HARQ FAILURECOUNTER

MAC-E PDU LOST COUNTER

MAC-E PDU RETRANSMISSIONSUNKNOWN COUNTER


1.13 RAN970: HSUPA Handovers

1.13.1 Introduction

This feature brings soft/softer handovers and serving cell changes forHSUPA users allowing HSUPA in the whole cell coverage area andbetween the cells.




This feature enables full mobility for the HSUPA users and widens thecoverage area of a given bit rate. The gain is significant especially withhigh bit rates. Soft handover (SHO) gain for E-DCH is similar in magnitudeto traditional R99 DCH SHO.


The following intra-frequency soft/softer handovers are supported for E-DCH:

. Intra-BTS intra-RNC softer handover

. Inter-BTS intra-RNC soft handover

In case of SHO, the active set for DCH can be different from the active setfor E-DCH. This allows adding a cell not supporting E-DCH into the activeset. In addition, in case of inter-BTS inter-RNC soft handover, the E-DCHwill not be configured to a SHO branch under the drift RNC. The serving E-DCH cell follows the serving cell for HS-DSCH of the UE. Thus, thealgorithms of HSDPA are followed. The HS-DSCH and E-DCH serving cellis always the same cell.

DCH to E-DCH channel switching is carried out if there is a need to changethe serving DCH cell into a cell supporting E-DCH. E-DCH to DCH channelswitching is carried out if there is a need to change the serving E-DCH cellinto a cell not supporting E-DCH or a cell under the drift RNC. E-DCH toDCH channel switching is also needed before compressed mode isactivated for inter-frequency or inter-system measurements.

E-DCH to DCH channel switching is carried out if there is a need to changethe serving E-DCH cell into a cell not supporting E-DCH or a cell under thedrift RNC. E-DCH to DCH channel switching is also needed beforecompressed mode is activated for inter-frequency or inter-systemmeasurements.



Pico WCDMA BTS supports 12.7 Mbps.


Pico WCDMA BTS supports 12.7 Mbps.

DN70296245Issue 1-5 en13/06/2008




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - OSS4.2 - - - 3GPPRel-6




OSW HSPA - -


NMS interfaces

Reporting Tools:

. New RAN_KPI_0066 for HSUPA Serving Cell change.

. New KPIs for HSUPA AS followup.



. The new E-DCH Serving Cell Change counters will be added to theIntra System Hard Handover Measurement.

. The new HSUPA AS counters will be added to the Soft HandoverMeasurement.

Management data


Allow E-DCH usage EcNo offset

CPICH EcNo offset E-DCH usageremoval

E-DCH channel type switch guardtimer

HSPA FMCS identifier

ONE CELL IN E-DCH ACTIVE SETDURATION

TWO CELLS IN E-DCH ACTIVESET DURATION

THREE CELLS IN E-DCH ACTIVESET DURATION





SOFTER HANDOVER DURATIONON THE SRNC SIDE FOR HSUPAMOBILITY

CELL ADDITION ATTEMPT REQBY UE TO E-DCH AS

CELL ADDITION SUCCESS TO E-DCH ACTIVE SET

CELL NOT ADDED TO E-DCHACTIVE SET BUT ADDED TO DCHAS

CELL ADDITION ATTEMPTRETRY TO E-DCH AS

E-DCH SERVING CELL CHANGESSTARTED

E-DCH INTRA BTS SERVINGCELL CHANGES SUCCESSFUL

E-DCH INTER BTS SERVINGCELL CHANGES SUCCESSFUL

E-DCH DOWNGRADED TO DCHIN SCC

1.14 RAN992: HSUPA Congestion Control

1.14.1 Introduction

The HSUPA Congestion Control was originally introduced in 3GPPTechnical Report to handle Iub transport related congestions. Thestandards provide means of congestion detection and indication but theyleave the actual mechanism for the vendors to decide. The tools that thestandards provide can detect delay originated congestion and transport-integrity originated congestion.

The HSUPA Congestion Control also aims to balance the workload of theRNC introduced by processing of the uplink traffic coming from the UEs.Congestion control for high speed uplink is a critical feature in the sensethat a situation where RNC can’t handle all the traffic generated by all theusers is avoided.

DN70296245Issue 1-5 en13/06/2008



Congestion can occur on the transport path to the RNC or inside the RNC.In both cases it is the responsibility of the RNC to take action to reduce thecongestion. Whatever the source of congestion is, the RNC must sendindication to the originator of the excess traffic.


This feature prevents packet losses because of congestion in the Iub orRNC and allows sensible Iub and RNC dimensioning. Lower rush hour E-DCH transmission delay as well as higher rush hour per user throughput isexpected because of congestion control (in comparison to a non-congestion control enabled network). E-DCH users are expected to havefair share of Iub transport resources and thus higher multiplexing ratioscan be applied. The solution also protects the RNC HW from getting intoan undesired level of load to guarantee the optimum usage of resources.

The operator can monitor the frequency of congestion indications todecide whether the capacity of Iub interface is on an adequate level. Thishelps to decide when it is time to upgrade the transport capacity of Iub.

The operator knows when the RNC processing resources are gettingloaded according to the related counters. Based on this information theoperator can upgrade the RNC capacity to increase service availability tothe customers.


Architecture

The feature HSUPA Congestion Control consists of multiple detectionentities separated into different parts of the system. Intention is to providefull coverage of congestion prevention over the system. The main entitiesof interest are Iub in terms of transport capabilities and the RNC in terms ofprocessing resources.

For Iub the congestion detection is based on delay related measurementsand data loss measurements. For RNC processing resource relateddetection the measurements are based on the ability of RNC HW to handlethe processing load. The RNC HW load can be divided into buffer fillingdegree based detection, load level based detection and into dataturnaround time based detection mechanisms. The HSUPA CC systemlevel architecture is depicted in Figure HSUPA CC system levelarchitecture.



The Iub transport originated congestion is detected according to delayvariation measurements taken form each E-DCH frame. Also data lossdetection is implemented to control situations where transport is alreadytoo congested to take care of the entire injected load. These detectionmechanisms work on FP bearer basis. This means that for a singleHSUPA user there can be multiple (one for each soft handover branch ofthe user) detection entities working to prevent transport-originatedcongestion. The actual control of the congestion is applied on Iub basis ina sense since each FP bearer on the Iub is equally likely to get controlled(presuming that these bearers share the same level of priority, e.g. QoS).HSUPA Congestion Control is described in detail in Section Algorithms.

Figure 1. HSUPA CC system level architecture

Note that FP branches are Iub specific which means that softer branchesare always combined in Node B.

The HW overload CC part of the HSUPA CC is logically implementedinside RNC L2 user plane processing unit. Two processors are involved inuser plane processing on this level and these are the units to getoverloaded when excess data are injected into the RNC. For each of theseprocessors, namely DSP and PPC, there is a mechanism to detect and

Iub

RNC

CoreNetwork

PPC

FPCC

HW CC

DSP

FPCC

FPCC

HW CC

Iub

Node B

Node B

Node B

Iub

CongestionControlInformation

Data

DN70296245Issue 1-5 en13/06/2008



control the load level. The function of these HW CC entities is toproactively control the rate of incoming data to prevent load levels wheredata would be lost. However, in this case the control is mostly restricted toHSUPA data only.

The actual control of congestion state is handled for each Iub separatelyand the entity in charge is the RNC E-DCH FP. This entity decides whattype of indication is sent and when this indication should be sent.

In this architecture the RNC is the master of the procedure and the Node Bacts as an executor of the congestion control. When the Node B receivescongestion indication, it starts the procedure of reducing the resourcesallocated for the given UE. This procedure is handled by the E-DCHpacket scheduler. The resources are kept reserved during the congestionsituation so that resources are not given to other UEs. The resources arereleased and reallocated when RNC indicates that the congestion is over.

Algorithms

Transport delay variation based algorithm:

The algorithm is based on well-known probability-based MECN. Theprobabilities of basic MECN are adapted to meet the target level of delayvariation on the Iub. Figure Probability functions of MECN shows theprobability functions used in MECN algorithm as well as how the evaluatedprobabilities are used to select the Congestion Indication (CI) type to besent to Node B. CIs are studied more in Section Congestion indicators.

MECN involves two probability functions P1 and P2 (functions of delayvariation). P1 is used to send an indication with lesser effect on the bit ratereduction and P2 is used to send the indication with greater effect on the bitrate. On the delay variation range from Thmin to Thmid only indicationaccording to P1 are sent. However, on the delay variation range from Thmid

to Thmax, the probability is first evaluated for the P2 function and in a caseof failed probability check, the P1 probability is evaluated consequently.

The target delay variation level is set to just a bit above the Thmin thresholdparameter. This delay variation level is set to guarantee optimal usage ofthe Iub transport in load situations.



Figure 2. Probability functions of MECN

The delay variation, which is the quantity of interest here, is defined asfollows:

Δd(n) = RNC_t(n) - RNC_t(n-1) - (NB_t(n) - NB_t(n-1))

where

RNC_t(n) equals the arriving time of a frame and NB_t(n) equals thesending time from Node B (contained in the E-DCH data frame). This delayvariation, Δd(n), is then averaged with a suitable filter to discard outliermeasurements.

Table Interpretation of delay variation amount with respect to MECNthreshold parameters describes how the amount of delay variation shouldbe understood with respect to the MECN algorithm threshold parameters.

Delay variation range Interpretation

Δd < Thmin The system operates at low workload.

Thmin ≤ Δd ≤ Thmid The system operates at typical load level where theoperation is close to optimal workload. The target levelof delay variation lies here. Somewhat congested statecan be seen close to Thmid.

No congestion Send CIaccording to

probability P1 (t)with delay

buildup status

Send CIaccording to

P2(t) (frame loss) or

P1 (t) (delay buildup)

Send CI withframe loss status

Thmax Delay (t)

P (t)

1

Pmax

Thmin Thmid

DN70296245Issue 1-5 en13/06/2008



Delay variation range Interpretation

Thmind ≤ Δd ≤ Thmax The system becomes heavily congested and moreforceful actions are needed to protect the system fromlosing integrity.

Thmax ≤ Δd The system is severely congested and cannot operateas intended.

The benefits of the algorithm, described here, are the following:

1. Global flow synchronizsation is avoided (all flows do not react at thesame time to congestion which could be harmful in terms of stability).

2. Fairness is guaranteed among the connections sharing the physicaltransport (the same rules are applied for each connection).

3. Distributed decision making (no information needs to be transmittedbetween decision entities)

Transport integrity based detection:

Transport integrity is measured by detecting whether the frames arriving insequence (in-sequence delivery is guaranteed) are all received in theRNC. The E-DCH FP frame includes a sequence number which ismaintained for each branch separately. Gaps can be easily detected fromthis sequence number.

A frame loss is considered a severe overload on the Iub transport and thusthe heavier bit rate reduction principles are used in this context. Forinformation on the indication types, see Section User actions.

HW overload detection:

HW overloads can occur in many forms but the common factor for all suchcases is that eventually data is going to be lost if no actions are taken tohandle the situation. To make the system to work in a sophisticated wayand to make use of all the processing capacity, some proactive operationsare needed to control the congestion.

The principles applied for HW overload detection are the following:



1. Processing of a frame should take less time than it takes a newframe to arrive into the processing unit.

2. If the previous case does not happen, the buffers storing the datashould not overflow.

3. If any of the previous cases can not be guaranteed, the sender of thedata (Node B) should stop sending for a while to let the processingunit solve the congestion situation.

The mechanism applied for processing delay based detection are similarto the one described for transport delay variation based detection inSection Transport delay variation based algorithm. Buffer filling degree-based detection is applied to avoid buffer overflow situations.

Algorithm parameters

Table Value ranges of MECN parameters describes the usage and valueranges of different MECN algorithm parameters.

Table 2. Value ranges of MECN parameters

Parameter Typical value range Description

Thmin [1ms, 3ms] Minimum threshold for MECNalgorithm to become operational.

Thmid [2ms, 6ms] Middle threshold for MECNalgorithm.

Thmax [3ms, 10ms] Maximum threshold for MECNalgorithm.

Pmax [0.01, 0.50] Maximum probability of CI sendingin the operational range.

There are few restrictions on how the parameters should be set so that thealgorithm functions as intended. These are

Thmin < Thmid < Thmax and

0.01< Pmax < 0.50.

Typically some kind of relation is used between the delay variationparameters. A default setting for this relation is defined as

3 ⋅ Thmin = 3/2 ⋅ Thmid = Thmax

but it should be varied according to the case.

DN70296245Issue 1-5 en13/06/2008



Congestion indicators

The Congestion Indication is a 3GPP frame protocol control frame withability to indicate two levels of congestion. The CI frame is also capable ofindicating resolved congestion situation. In general the first level ofindicated congestion is used for proactive operation of the algorithms andthe second level is used to take more control of the bit rate reduction.However, the first level indication is called ‘delay buildup’ CI and thesecond level indication is called ‘frame loss’ CI. The use of theseindications is not tied to their names.

The CI sending frequency of the algorithm is proportional to the delayvariation amount as indicated by the probabilities (see SectionAlgorithms). However, the maximum per connection CI sending frequencyis limited to keep the system stable.

The HW overload detection can trigger additional CI sending events. Thismechanism can trigger also both types of indications to be sent. Theseindications are used in the same way as in the delay variation baseddetection. The first level of indication is used for proactive operation andthe second level indication is used in a more serious situation.

It must be noted that during normal operation the algorithm sends CIs withsome low frequency and only when the CI sending frequency increasessignificantly from the typical, the system can be considered congested.

User actions

HSUPA Congestion Control does not require any user actions in thetypical meaning of the word. However, the algorithm parameters need tobe configured to reflect the transport characteristics. Typically thesecharacteristics do not vary a lot among different transport types ortopologies but for optimal functioning of the algorithm some tuning mightbe required. See Section Algorithm Parameters for hints on parametersetting.

Statistics

Section Management data introduced the feature related statisticscounters. Some information is given in Table Statistics usage andinterpretation on how to use and interpret the gathered data. For correctinterpretation it must be noted that these statistics are cell levelaccumulations over the measurement interval whose typical length is 60minutes.

Counter Linked algorithm/parameters Interpretation



Counter Linked algorithm/parameters Interpretation

M1022C69IUB_DELAY_CC_DELAY_IND

MECN/Thmin, Thmid, Thmax Iub delay variation based algorithmoperates at the typical (proactive)working range under load. Iubusage is close to optimal when thiscounter contains a non-zero (but notlarge) value. However, large valuein this counter is expectedcoincidently with the ‘Frame loss’ CIcounter.

M1022C72IUB_DELAY_CC_FRAME_LOSS_IND

MECN/Thmid, Thmax Iub delay variation based algorithmoperates at the high Iub load range.Low value is expected in loadsituation. High value representsoverloaded Iub transport and thiscould be an indication of under-dimensioned transport.

M1022C71IUB_LOSS_CC_FRAME_LOSS_IND

Iub integrity/No parameters Frames are lost in Iub transport.There is probably something wrongin resource allocation ordimensioning of Iub if this countercontains high values report afterreport. It could also be that thereexists some physical problem in Iub.

M1022C70HW_OVERL_CC_DELAY_IND

RNC HSUPA HW overload CC/Noparameters

User plane processing HW is actingproactively to control increasingload. Increase in this counter istypical when system is loaded.However, larger increase in countervalue is an indication of becomingHW overload.

M1022C73HW_OVERL_CC_FRAME_LOSS_IND

RNC HSUPA HW overload CC/Noparameters

User plane processing HW isheavily overloaded. There isprobably something wrong inresource allocation or dimensioningof RNC if this counter contains highvalues report after report.

M1022C77SUCC_REC_EDCH_FRAMES

None This counter contains the exactnumber of successively receiveddata.

M1022C76DELAYED_EDCH_FRAMES

MECN/Thmin Interpretation is similar to theexplanations above (including bothdelay variation cases) of MECNbased algorithm. This countercontains the exact number of all thedelayed frames.

M1022C75MISSED_EDCH_FRAMES

Iub integrity Interpretation is similar to theexplanation above about Iubintegrity CI counter. This countercontains the exact amount of lostframes.

DN70296245Issue 1-5 en13/06/2008



Feature activation

HSUPA Congestion Control is part of the HSUPA solution and thus noactivation procedure is required. However, the parameter setting requiressome user actions (see Section User actions). For more information, seeActivating Basic HSUPA and HSUPA Basic RRM in HSUPA Features,Feature Activation Manual.



This feature is implemented in RAS06.


This feature requires RN3.0 RNC and WBTS4.0 Node B hardwaredeliveries.


This feature is part of HSUPA implementation and it is going to beimplemented with RAN826 Basic HSUPA and RAN968 HSUPA BTSPacket Scheduler.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - - - - -




OSW HSPA - -



1.14.3.6 Control and user plane

HSUPA Congestion Control performs 3GPP Release 6 compliantsignalling using FP control frames during and at the end of the congestionsituation. This signalling is unidirectional – from SRNC to Node B withoutacknowledgements. For more information, see Figure HSUPA CongestionControl signalling for signalling scenario.

Figure 3. HSUPA Congestion Control signalling

Node B uses the standard 3GPP Release 6 E-DCH data frame headerfields to include HSUPA Congestion Control related information. Withoutthese information elements congestion control cannot be performed.

The Nokia RNC can perform HSUPA Congestion Control with othervendors’ Node Bs if these Node Bs use the standard interfaces forimplementing the feature.


NMS interfaces

Impact on planning tool:

No impact.

Impact on management tools:

No impact.

Impact on radio network configuration management tool:

Iub transport delay variation-based algorithm parameters are configured inthe management tool.

Impact on transport network configuration management tool:

Node B SRNC

TNL CONGESTION INDICATION

DN70296245Issue 1-5 en13/06/2008



No impact.

Impact on reporting tools:

New counters are added into NetAct for HSUPA Congestion Control.

Impact on monitoring tools:

No impacts on real time monitoring tools.

Impact on optimising tools:

No impact.


HSUPA Congestion Control related counters are added to the RNCElement Manager and NetAct user interfaces. Also configurationmanagement user interface is updated to handle the new parameters (seeSection Management data for available counters and parameters). SeeNokia NetAct Product Documentation for more detailed information onuser interface impacts.

Management data


Maximum Threshold for HSUPAcongestion handling delay

Middle Threshold value for HSUPAcongestion delay

Minimum Threshold value forHSUPA congestion - delay

ProbabilityFactor for CongestionIndication sending

DELAY BUILDUP INDICATIONSSENT DUE TO IUB DELAY

DELAY BUILDUP INDICATIONSSENT DUE TO HW OVERLOAD

FRAME LOSS INDICATIONS SENTDUE TO TRAFFIC LOSS

FRAME LOSS INDICATIONS SENTDUE TO IUB DELAY

FRAME LOSS INDICATIONS SENTDUE TO HW OVERLOAD

MISSED E-DCH FP FRAMES

DELAYED E-DCH FP FRAMES

SUCCESSFULLY RECEIVED E-DCH FP FRAMES

SUCCESSFUL E-DCH FPBRANCH SETUP




Signalling

No impact to signalling in addition to the ones described in Control anduser plane.

1.14.3.8 Impact on system performance and capacity

This feature has no impacts to existing functionality but the impacts toHSUPA performance are greatly positive. HSUPA user delays, averageuser data rates and data integrity figures are positively affected in a loadedsystem. HSUPA users are expected to have fair share of transportresources and thus higher multiplexing ratios can be applied.

1.15 RAN974: HSUPA with Simultaneous AMR VoiceCall

1.15.1 Introduction

This feature provides both HSUPA services and AMR voice callssimultaneously.


Simultaneous high speed data services and AMR voice calls in ULimprove the end-user experience.


PS data connection over E-DCH is supported simultaneously with AMRvoice call over DCH. This ensures that an AMR voice call initiation doesnot influence the NRT service data flow.




DN70296245Issue 1-5 en13/06/2008




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - OSS4.2 - - - 3GPPRel-6






NMS interfaces

Reporting Tools:

. KPIs for multi-RAB usage related to E-DCH



. The new AMR + E-DCH counters are added to the TrafficMeasurement.

Management data


Usage of AMR service with E-DCH

HSPA FMCS identifier for AMRmulti-service

AMR + E-DCH ALLOCATIONS

AMR + E-DCH NORMAL RELEASE




1.16 RAN1515: HSPA Inter-RNC Cell Change

1.16.1 Introduction

HSPA inter-RNC cell change introduces seamless HSPA mobility betweenRNCs. HSPA serving cell is directly changed from source RNC to targetRNC.


Improved end-user experience is achieved. HSPA high data rates can bemaintained in RNC border areas. HSPA capacity gains can be achievedalso in RNC border areas, reducing CAPEX.


When intra-frequency measurements indicate that the strongest cell in theactive set is located under the DRNC, HSPA intra-frequency inter-RNC cellchange is executed. Triggering point for inter-RNC cell change can bespecifically defined by the operator by management parameters.Functionality applies both to HSDPA and HSUPA.

HSPA intra-frequency inter-RNC cell change utilises SRNS relocation withUE involvement, meaning that UE is reconfigured according to the targetRNC resources during SRNS relocation. Source RNC deletes the oldconfiguration after succesful SRNS relocation. HSPA serving cell change(serving HS-DSHC/E-DCH cell change) is combined with SRNSrelocation.

HSPA data flow is not established over Iur-interface but HSPA resourcesare reserved and allocated under DRNC in conjunction of the SRNSrelocation. DCHs for SRBs and UL return channel can be set up over Iurinterface, whereas HS-DSCH and E-DCH are not used over Iur interface.HSPA inter-RNC cell change is supported also when Iur interface isdisabled, congested or does not exist.



HSPA service is switched to DCH at the RNC border area.

DN70296245Issue 1-5 en13/06/2008






Features RAN828: HSDPA Serving Cell Change and RAN829: HSDPASoft/softer Handover for Associated DPCH are required.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - - - - - 3GPPRel-6






Management data



There are counters related toresource reservations, inter-RNCHHOs, and Packet Sessionallocations




1.17 RAN1011: HSPA Layering for UEs in CommonChannels

1.17.1 Introduction

UEs are directed to the correct layer according to their HSDPA and high-speed uplink packet access (HSUPA) capability in state transition fromCell_FACH to Cell_DCH.


CAPEX savings can be achieved as the HSPA capability can beimplemented using the HSPA layering. Choosing the correct layer for theUE on each transition to cell_DCH guarantees correct layer based on theUE capability on all practical mobility scenarios. When several layerssupport HSPA, the feature chooses the layer in an optimal manner basedon the expected DL throughput on each HSPA layer.


This feature transfers UEs to the correct layer based on their HSDPA andHSUPA capability. The transfer occurs in connection with the statetransition from Cell_FACH to Cell_DCH.

Non-HSDPA UEs are transferred to the non-HSDPA layer. The HSDPAcapable UEs are transferred to the layer that supports HSDPA. TheHSUPA capable UEs are transferred to the layer that supports HSUPA. Ifthere are several HSDPA or HSDPA and HSUPA layers, load sharing isutilised. On HSPA layers, the selection criterion is the highest DLthroughput (most power per user available for HSDPA).

In addition, this feature covers some enhancements to the Directed RRCConnection Setup for HSDPA Layer feature. The requested service in theradio resource control (RRC) Connection Setup Request is taken intoaccount in decision making so that only HSDPA UEs requesting interactiveand background services are transferred to the HSDPA layer.

Also, HSUPA capability is taken into account when selecting the layer. Theinterworking with the directed RRC connection setup feature enables thenon-HSDPA load sharing between all the layers. The UE that cannotmanage with frequency change in the RRC connection setup phase or inthe state transition phase is detected and the feature is not used for thatspecific connection.

DN70296245Issue 1-5 en13/06/2008





Without the feature, the layer selection is only done at the RRC connectionsetup.




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - 3GPPRel-5






NMS interfaces

Reporting Tools:

. New KPIs for HSDPA layering.



. The new counters will be added to the RRC Signaling Measurement.

Management data






Services for DRRC connectionsetup for HSDPA layer

DRRC connection setup for HSDPAlayer enhancements

Disable power in decision makingfor HSDPA layering

HSDPA layers load sharingthreshold

Cell weight for HSDPA layering

DCH ALLO FOR SIG LINK FROMNON-HSPA TO HSPA LAYER

DCH ALLO FOR SIG LINK FROMHSPA TO NON-HSPA LAYER

DCH ALLO FOR SIG LINK FROMHSPA TO HSPA LAYER

FACH TO DCH FROM NON-HSPATO HSPA LAYER

FACH TO DCH FROM HSPA TONON-HSPA LAYER

FACH TO DCH FROM HSPA TOHSPA LAYER

1.18 RAN1249: HSDPA 10 Mbps per User

1.18.1 Introduction

The peak bit rate on HSDPA for single user is increased to 10 Mbps.


RAN1249: HSDPA 10 Mbps per User allows higher peak bit rates for asingle user.


HSDPA category 9 UE is capable of 10 Mbps peak air interface bit ratewith 15 codes. With this feature, a category 9 UE may receive data with itsmaximum bit rate when 15 codes for HSDPA are allocated in the cell.



Currently the peak bit rate for a single user is 3.6 Mbps.


CDSP-C interchangability D required in RNC

DN70296245Issue 1-5 en13/06/2008




RAN852: HSDPA 15 Codes is needed for this feature.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - OSS4.2 - SG6.0 - 3GPPRel-5






NMS interfaces

Reporting tools:

. New KPIs for HS-DSCH RLC Throughput user data volumes anduser data distribution.



. There will be new extended RLC Throughput Distribution countersadded to the RCPM RLC AM Measurement.

. There are already existing basic RLC Throughput (PDU) counters inthe RCPM RLC AM Measurement.

Management data



USER DL THROUGHPUTDISTRIBUTION - CLASS 11







1.19 RAN1305: HSDPA 14.4 Mbps per Cell

1.19.1 Introduction

Cell maximum throughput is increased to 14.4 Mbps with a cell-dedicatedscheduler.


There are CAPEX savings in the BTS baseband thanks to the increasedaverage cell throughput with a dedicated scheduler.


If HSDPA code multiplexing is used, the maximum theoretical cell-levelthroughput for simultaneously scheduled HSDPA users is 14.4 Mbps. Withthe Rel-6 HSDPA UE categories, the maximum theoretical cell-levelthroughput as defined by 3GPP is 13.9 Mbps with two cat 9 or cat10terminals. Practical throughput achievable with this feature is limited byradio reception.

Maximum theoretical throughput would require the use of coding rate closeto 1, meaning that it would require error-free reception. Targeting to error-free reception reduces the system efficiency and capacity. In all practicalconditions, the throughput is degraded if using coding rates close to 1, thatis, having effectively no error correction.

Quality of radio reception depends on aspects such as received signalstrength, radio channel and interference, transmitter and receiverimperfections.

DN70296245Issue 1-5 en13/06/2008





Dedicated UltraSite WSPC/Flexi WCDMA BTS sub-module per cell forHSDPA is needed in the BTS.

Pico WCDMA BTS supports a maximum of 12.8 Mbps


Dedicated UltraSite WSPC/Flexi BTS sub-module per cell for HSDPA isneeded in the BTS.

RAN923: Pico WCDMA BTS with Ethernet Transport supports maximum12.8 Mbps.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - - - - - -




OSW HSPA - -


NMS interfaces

Reporting Tools:

. The existing RAN_KPI_0044 follows the average HSDPA cellthroughput.

. The new RAN_KPI_0055 follows the HSDPA cell throughput datavolume.





. There are already existing HS-DSCH (MAC-d) throughput countersin the HSPA in WBTS Measurement


Management data




1.20 RAN979: HSUPA 2.0 Mbps

1.20.1 Introduction

The highest supported user peak rate on E-DCH is 2.0 Mbps,corresponding to two parallel codes of spreading factor two (2xSF2) and10 ms TTI.


HSUPA peak rate is increased to up to 2.0 Mbps per user.


HSUPA category 5 UE is capable of 2.0 Mbps peak air interface bit rate.HSUPA categories 4 and 6 have 2.0 Mbps peak bit rate in case of 10 msTTI. 2.0 Mbps user peak rate on E-DCH is supported in the RNC and BTSuser plane processing and in configuration (for example, RLC) of L2 doneby L3. BTS supports the reception of two SF/2 multicodes with 10 ms TTI.

DN70296245Issue 1-5 en13/06/2008





The highest supported user peak rate on E-DCH is 1.44 Mbps,corresponding to two parallel codes of spreading factor four (2xSF4) and10 ms TTI.




Pico WCDMA BTS supports a maximum of 1.44 Mbps.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0







NMS interfaces

Reporting Tools:

. The new RAN_KPI_0075 follows the average HSUPA cellthroughput.

. The new RAN_KPI_0080 follows the HSUPA cell throughput datavolume.

. New KPIs for E-DCH RLC Throughput user data volumes and userdata distribution.





. There will be new extended RLC Throughput Distribution countersadded to the RCPM RLC AM Measurement.

. There are already existing basic RLC Throughput (PDU) counters inthe RCPM RLC AM Measurement.

. There will be new E-DCH (MAC-es) throughput counters in the newCell Throughput Measurement.

Management data




1.21 RAN834: Flexible Iu

1.21.1 Introduction

RAN834: Flexible Iu provides a standardised mechanism for connectingmultiple MSCs and SGSNs to an RNC within a single operator NW.Flexible Iu is also known as 'Iu Flex' and 3GPP uses the names 'IntraDomain Connection of RAN Nodes to Multiple CN Nodes' and 'MultipointIu/Gb/A'.


Flexible Iu provides CAPEX and OPEX savings resulting from efficientCNs resource utilisation and load balancing. Increased service availabilityand better NW resilience improve the end-user experience.


This feature introduces the concept of Pool Areas. A UE may roam freelywithin a Pool Area (in either connected or idle mode) without the need tochange the CN serving node. The following figure shows an example ofthe Pool Area configurations in the NW.

DN70296245Issue 1-5 en13/06/2008



Pool Area configurations are done in the CN nodes. Pool Areasthemselves are not visible to the RAN but the RNC configuration has to bedone according to the CN Pool Area configurations so that the RNC is ableto route signalling messages to any CN node within a Pool Area.

The NAS Node Selector function (NNSF) is a mechanism used forselecting the CN node for the UE. The UE derives the value of theparameter NRI from the (P)-TMSI or IMSI and sends the NRI to the RNC inthe Initial Direct Transfer message. The RNC selects the CN nodecorresponding the NRI value configured in its database.

The NNSF in the RNC also contains the CN node recovery functionality,which balances the load between the CN nodes of a pool in differentcases, for example, with CN node failure, SW/HW update or adding orremoving a CN node to/from the pool.

Figure 4. Pool area example

Area 1 Area 2 Area 3 Area 4

Area 5 Area 6 Area 7 Area 8

MSC 3

MSC 2

MSC 1

MSC 6

MSC 5

MSC 4

MSC 7

RANnode

RANnode

SGSN 2

SGSN 1

RANnode

RANnode

RANnode

RANnode

SGSN 5

SGSN 4

SGSN 3

RANnode

RANnode

SGSN 6

PS pool-area 1

PS pool-area 2

CS pool-area 1

PS pool-area 2





This is a new feature.




Simultaneous usage of RAN834: Flexible Iu and RAN1452: MORAN for upto 4 Operators is not possible.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 M13.0 SG6.0 U2 -




ASW RAN RNC LK Long-term ON/OFFlicence


NMS interfaces

Reporting Tools:

. CN ID is already visible.



. CN ID is already visible in the relevant measurements.

DN70296245Issue 1-5 en13/06/2008



Management data


NRI list for CS Core routing

Maximum value of NRI range forCS Core routing

Minimum value of NRI range forCS Core routing

State of Iu interface

NRI list for PS Core routing

Maximum value of NRI range forPS Core routing

Minimum value of NRI range for PSCore routing

NRI length for CS Core Networks

NRI length for PS Core Networks

Null NRI value for CS Pool

Null NRI value for PS Pool


1.22 RAN1177: Emergency Call Redirect to GSM

1.22.1 Introduction

3G emergency call is directed to 2G NW as the latter one is assumed toprovide a better location service. If there is another call attempt within 60seconds, the call is established in 3G NW.


CAPEX and OPEX savings can be achieved if the operator can utilise theexisting 2G positioning system for emergency calls.


When a UE is trying to make an emergency call to the WCDMA NW, theRNC instructs the UE to make an inter-RAT handover to the GSM NW andto carry on with the emergency call in GSM. If for any reason the handovershould fail, and the UE returns to the WCDMA NW with the emergency callwithin 60 seconds, the call is set up and carried out in the WCDMA NW.







RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -






Management data


Emergency Call Redirect

Emergency Call Redirect Timer

RRC SETUP REJECT DUE TOEMERGENCY CALLREDIRECTION


1.23 RAN1219: Latency Statistics for UE Positioning

1.23.1 Introduction

Statistics of location system's latencies are collected for further analysis.

DN70296245Issue 1-5 en13/06/2008




Better end-user experience can be achieved as the operator haspossibilities to monitor and verify the improved location systemperformance.


Latency statistics for UE Positioning present new statistical latencyinformation concerning the UE positioning. The latency statistics presentoverall locationing service latencies, and detailed latency statistics for cell-based and A-GPS positioning methods. In addition, the feature presentsthe latency statistics of emergency call-related (inter-system handover)ISHO features.





RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -




OSW RAN - -


NMS interfaces

Reporting Tools:

. New KPIs for UE positioning delay.





. The new LCS Latency related counters will be added to the LocationServices Measurement.

Management data



SUM OF CIRTT LATENCY

DENOM CIRTT METHOD

CIRTT LATENCY LESS THAN 2SECONDS

CIRTT LATENCY BETWEEN 2 TO5 SECONDS

CIRTT LATENCY OVER 5SECONDS

SUM OF GPS LATENCY

DENOM GPS METHOD

GPS LATENCY LESS THAN 5SECONDS

GPS LATENCY BETWEEN 5 TO15 SECONDS

GPS LATENCY OVER 15SECONDS

SUM OF LCS TOTAL LATENCY

SQUARED SUM OF LCS TOTALLATENCY

DENOM LCS TOTAL LATENCY

SUM OF EMISHO LATENCY

DENOM EMISHO LATENCY

EMISHO LATENCY LESS THAN 2SECONDS

EMISHO LATENCY BETWEEN 2TO 5 SECONDS

EMISHO LATENCY OVER 5SECONDS

SUM OF EMERGENCY CIRTTLATENCY

DENOM EMERGENCY CIRTTMETHOD


DN70296245Issue 1-5 en13/06/2008




EMERGENCY CIRTT LATENCYLESS THAN 2 SEC

EMERGENCY CIRTT LATENCYBETWEEN 2 to 5 SEC

EMERGENCY CIRTT LATENCYOVER 5 SEC

SUM OF EMERGENCY GPSLATENCY

DENOM EMERGENCY GPSMETHOD

EMERGENCY GPS LATENCYLESS THAN 5 SECONDS

EMERGENCY GPS LATENCYBETWEEN 5 to 15 SECONDS

EMERGENCY GPS LATENCYOVER 15 SECONDS

SUM OF EMERGENCY LCSTOTAL LATENCY

SQUARED SUM OF EMERGENCYLCS TOTAL LATENCY

DENOM EMERGENCY LCSTOTAL LATENCY

1.24 RAN1452: MORAN for up to 4 Operators

1.24.1 Introduction

Multi-Operator RAN allows two to four operators to share radio accessnetwork. Operators' own end-user services are available in the sharednetwork area services. Sharing operators use their own frequencies andtheir own PLMN IDs. The solution is standards-compatible (3GPP) and it issupported with all 3G terminals. The MORAN solution allows independentcontrol of traffic for each operator; they have dedicated cell-levelparameters.




Using MORAN for radio network sharing can help operators to reduceCAPEX/OPEX and bring 3G services to the mass market quickly. Althoughthe radio network is shared, the operators still maintain perfromance andservice differentiation capabilities as MORAN allows the use of operator-specific cell-level parameters.


Nokia Siemens Networks Multi-Operator RAN allows two to four operatorsto share physical RNCs and BTSs. When this feature is used, all operatorshave their own CS and PS interfaces towards the RNC. In such a scenario,the subscribers of different operators use cells in different carrier layers(frequencies). The differentiation is based on the Mobile Country Code(MCC) and Mobile Network Code (MNC) of the cell. Each cell has MCCand MNC corresponding to the operator. This feature is implemented withan RNC software upgrade and it is compatible with R99 and R4 CoreNetworks.

Feature RAN1452: Multi-Operator RAN provides the following:

. Enables the operators to reduce the costs of their networks bysharing BTS and RNC hardware without losing control overoperator-specific radio cells.

. Operators can tune their cell Radio Resource Managementparameters and monitor their traffic individually on a cell basis.

. Neighbouring cell lists are operator-specific, which enables, forexample, own inter-system handover decisions.

. Operators are free to add additional BTSs in locations where theywant to provide better coverage or more capacity.

. Operators can use their own licensed frequencies and PLMN ID.

. UEs show the appropriate operator logo.

. Global roaming is easy.

. No extra support features from the UEs are needed. The featureworks with 3GPP Rel. 99 WCDMA UEs.

Typical areas where to use RAN1452: Multi-Operator RAN are:

DN70296245Issue 1-5 en13/06/2008



. Initial coverage when the service demand is still low

. Low traffic areas, for example rural and suburban areas

. Places where it is hard to find BTS spots, for example subways

Cost savings are achieved by sharing the RAN capital and operatingexpenditure:

. RNCs

. BTSs

. Site investments

. Transmission and Transport

. Installation and commissioning

. Operations support system

. Radio network planning

The described approach provides a technical solution for allowingoperators to share the Radio Access Network. It is required that the sharedRAN is operated in a co-operation mode so that:

. Network Operation and Maintenance

. Network Dimensioning

. Transport

. Network Planning and

. Synchronisation (Iu-interface)

are based on mutual co-operation.

The solution allows operators to individually plan and optimise their owncell parameters, whereas planning and dimensioning of global RNCparameters and BTS, RNC and transmission capacity need to be handledin co-operation.

Sharing the RAN offers the operators a lot of freedom in terms of decidingthe scope of their co-operation as well as when and where they want toprovide additional capacity or coverage of their own.





MORAN originally supports radio network sharing between two operators.




RAN2.0042: Nokia Multi-Operator RAN is the original MORAN solution.For more information, see Description of MORAN functionality.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -






NMS interfaces

Reporting Tools:

. PLMN ID already visible.



. CN ID already visible in relevant measurements

DN70296245Issue 1-5 en13/06/2008



Management data






2 Transmission and transport features

2.1 RAS06 documentation for transmission andtransport features


Table 3. Transmission and transport features


RAN1097: Ethernet Interface UnitIFUH (Iub User Plane) for AXC

RAN1064: Ethernet+E1/T1/JT1Interface Unit (Iub User Plane) forFlexi WCDMA BTS

RAN1099: Dynamic Scheduling forHSDPA with Path Selection

Activating Dynamic scheduling forHSDPA with Path Selection inHSDPA Features, FeatureActivation Manual

RAN1100: Dynamic Scheduling forNRT DCH with Path Selection

Activating Dynamic scheduling forNRT DCH with Path Selection inFeature RAN1100: DynamicScheduling for NRT DCH withPath Selection, Feature ActivationManual

RAN759: Path Selection Activating Path Selection inFeature RAN759: Path Selection,Feature Activation Manual

RAN1096: Transport BearerTuning

Activating Transport Bearer Tuningin Feature RAN1096: TransportBearer Tuning, Feature ActivationManual

RAN1095: UBR+ for Iub UserPlane

DN70296245Issue 1-5 en13/06/2008


Transmission and transport features

Table 3. Transmission and transport features (cont.)


Activating UBR+ for Iub UserPlane in Feature RAN1095: UBR+for Iub User Plane, FeatureActivation Manual

RAN1319: Flexi WCDMA BTS IMABased AAL2 Uplink CAC

RAN1063: Hybrid Backhaul withPseudo Wires

RAN1142: ATM over Ethernet forBTS

For an overview of transport features, see Transport overview in RAS06and RAS05.1 Transport Overview.








. WBTS Counters



. Notices (0-999)










2.2 RAN1097: Ethernet Interface Unit IFUH (Iub UserPlane) for AXC

2.2.1 Introduction

This feature belongs to AXC hardware and software.

It implements the Ethernet interface unit (IFUH) for AXC, to connect theBTS to a packet-switched network.

The IFUH is one of the building blocks of RAN1063: Hybrid Backhaul withPseudo Wires. RAN1142: ATM over Ethernet for BTS is required tooperate the Ethernet interfaces in order to convey Iub ATM traffic over apacket switched network. For RAN06 the IFUH will allow to transport up to60 Mbit/s of ATM traffic encapsulated in Ethernet frames of up to 100 Mbit/s.

The IFUH provides 2 Fast Ethernet (100Base-TX) interfaces and oneoptionally pluggable Gigabit Ethernet interface to connect the BTS to apacket-switched network. The interfaces operate in full duplex mode andhave a LED connected each to display the connectivity status. Autonegotiation for the duplex mode is supported by default, but can beswitched off too.

All 3 Ethernet interfaces featured by the IFUH are based on the IEEE802.3–2002 standard using the Ethernet II/DIX frame (i.e. interpretation ofthe type length field). In RAN06 the first of the fast Ethernet interfaces orthe optical gigabit interface can be used to connect an IFUH to a packetswitched network. The two remaining interfaces are intended for futureextensions.

The used interface supports Ethernet VLAN according to IEEE 802.1Q.The VLAN IDs is configurable and programmable priority bits aresupported. IPv4 according to is used for IP packets on the IFUH.

DN70296245Issue 1-5 en13/06/2008



The Ethernet MTU is fixed to 1500 octets which leads to a maximumEthernet frame length of 1518 octets for plain Ethernet or 1522 octets forEthernet using VLAN respectively.

The 2 Fast Ethernet interfaces have RJ-45 connectors, operate viaCategory 5 (or better) twisted pair cables and support Tx/Rx auto-detection.

The optional optical Gigabit Ethernet interface comes as pluggable SFPmodule (SFP: Small Formfactor Pluggable Transceiver acc. to INF-8074i)equipped with an LC-connector. The SFP module has a class 1 laser. Forsafety reasons modules deploying different laser classes are preventedfrom being operated. The SFP module can be of two different flavours,which are either:

. Long haul: 1000 Base-LX, typically up to 5000m distance achievablewith SMF (single mode fibre), wavelength around 1300nm, or

. Short haul: 1000 Base-SX, typically up to 550m distance achievable;wavelength around 800nm.

The IFUH can be added to any AXC configuration in UltraSite Supremeand Optima cabinets, including the AXC Compact. In a system equippedwith an AXUA/B the IFUH can be operated in any slot. In RAN06 only oneIFUH per system is foreseen. In systems with an AXCC the IFUH has to bein the rightmost slot.

The MetroSite and UltraSite GSM/EDGE BTS offer two AXC slots, one foran AXU, the second for an IFU. IFUH can also be used with thesecabinets. This implies that synchronization is provided through othermeans, for example, a 2MHz signal fed from a neighbouring GSM/EDGEBTS or a GPS receiver.

Naturally this cannot be used for an AXCC IFUH combination as it wouldrequire three slots.

The IFUH should not be used in stand-alone AXC configurations.


UltraSite WCDMA BTS can be backhauled over packet-switchedtechnologies, IP and Ethernet in particular. Operators can select from thefull variety of IP and Ethernet services. As the current backhaul networksare ill-suited to backhaul the large bandwidths and high peak ratesgenerated by HSPA Ethernet-based technologies have the potential toseparate cost from capacity, particularly for higher bandwidths.




When an IFUH is installed in an AXC it can be configured to convey ATMcells encapsulated in IPv4 packets using either a Fast Ethernet or aGigabit Ethernet interface. The configuration possibilities are described inRAN1142: ATM over Ethernet for BTS. The customer has to adapt theparameters listed in the Management data section to match the networksetup of the customer.

Activating the feature

The IFUH will transport any data only after downloading a license.

The configuration, as described in RAN1142: ATM over Ethernet for BTSand in Management data can be done without license.

Architecture

Ethernet Interface Unit IFUH (Iub User Plane) for AXC is one of thebuilding blocks of the RAN1063: Hybrid Backhaul with Pseudo Wires.

BTS is equipped with Ethernet and TDM interfaces. For more information,see RAN1063: Hybrid Backhaul with Pseudo Wires. The Pseudo Wiretermination function is carried out by the AXC IFUH inside the BTS. Thefollowing figure depicts this configuration.

Figure 5. AXC IFUH Pseudo Wire terminating function

The IFUH actually is the PWE3 gateway inside the BTS.

TDMI/F

ATM TDMI/F

TunnelEthernetI/F

PacketSwitchedNetwork

ATM

TDMI/F

TDMNetwork

BTS

AXC

ATMtermination

nxSTM1

IFUH

RNC

PWE3Gateway

DN70296245Issue 1-5 en13/06/2008



The IFUH can also be operated in a scenario as shown in the followingfigure.

Figure 6. IFUH alternative operating scenario

2.2.3 System impact


This feature is implemented in AXC C3.0, which belongs to RAS06.

Without this feature all data is carried via ATM over TDM basedtechnologies (SDH/PDH).


The IFUH hardware will be implemented to support the functionalitydescribed in RAN1063: Hybrid Backhaul with Pseudo Wires andRAN1142: ATM over Ethernet for BTS.

Requirements to IFUH HW Reason

AXC Sub rack

RNC PWE3 site solution


This feature is needed to support RAN1142: ATM over Ethernet for BTSand RAN1063: Hybrid Backhaul with Pseudo Wires.

TDMI/F

TDMI/F

TunnelEthernetI/F


ATM

BTS

AXC

ATMtermination

nxSTM1

IFUH

RNC

PWE3Gateway



A similar feature for another NE (FTM) is RAN1064: Ethernet+E1/T1/JT1Interface Unit (Iub User Plane) for Flexi WCDMA BTS.


This feature requires the AXC software to handle the new EthernetInterface Unit (IFUH). The AXC software will furthermore support allconfiguration management, fault management and performancemonitoring data described in RAN1142: ATM over Ethernet for BTS and inthe Management data section.

Other Network elements will implement accordingly in releases:

. BTS Ultra: WBTS 4.0 (containing AXC C3.0)

. OSS: OSS4.2

RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 - WBTS4.0

- - C3.0 OSS4.2 - - - -




OSW RAN - -


This feature has no impact on signalling interfaces.


NMS interfaces

This feature requires the NMS to manage all data described in RAN1142:ATM over Ethernet for BTS plus the data listed in the Management datasection. It does not change the behaviour of the interface itself.

DN70296245Issue 1-5 en13/06/2008




The AXC Element Manager will support the handling of the new Ethernetinterface unit (IFUH) and all data described in RAN1142: ATM overEthernet for BTS plus the data listed in the Management data section.

Management data

This feature itself adds a new unit type to the AXC management data. TheAXC software additionally implements all data described in RAN1142:ATM over Ethernet for BTS.

Additionally the AXC has to implement the following management data.

Files

Table 4. Ethernet Interface Unit IFUH (Iub User Plane) for AXC files impacts

File Impact

*.aml Parameters are supported in AXC configuration files (AML).

Statistics

For information on statistics, see RAN1142: ATM over Ethernet for BTS.

Parameters

Table 5. Ethernet Interface Unit IFUH (Iub User Plane) for AXC impact onparameters

File Use

AcceptableFrameTypes Controls if the VLAN Tag support for the Ethernet interface isenabled or not.

VLAN_ID Configures the used VLAN IDs used for the Ethernet interface.

Duplex Mode Switches autonegotiation for the duplex mode on or off.

Alarms

The IFUH will detect and report the trouble condition described in thefollowing table.



Table 6. Ethernet Interface Unit IFUH (Iub User Plane) for AXC impact onalarms

Alarm Description

LOS Loss of signal.

Additionally, there is the following management data related to this feature.



EthIfInOcts_15

EthIfOutOcts_15

EthIfInPkt_15

EthIfOutPkt_15

EthIfInPktErr_15

EthIfInUnknownProtos_15

EthIfOutDiscShaping_15

EthIfInUnknownVLAN_15

EthUnknownPSNHdr_15


Signalling

This feature has no impact on signalling.


This feature has no impact on system performance or capacity.

2.2.3.9 Impact on mobile terminals

This feature has no end-user requirements.

2.3 RAN1064: Ethernet+E1/T1/JT1 Interface Unit (IubUser Plane) for Flexi WCDMA BTS

2.3.1 Introduction

This feature belongs to FTM hardware and software.

DN70296245Issue 1-5 en13/06/2008



It implements the Ethernet + PDH interface unit (FTIA/FTJA) for FTM, toconnect the BTS to a packet-switched network. These interface unitscombine four PDH interfaces and interfaces to connect to a packet-switched network.

There are two types of interface units, as described below.

. FTIA: Interface unit needed to support the Ethernet interface in FlexiWCDMA BTS. E1/T1/JT1 interface with a symmetrical line is alsoprovided.

. FTJA: Interface unit needed to support the Ethernet interface in FlexiWCDMA BTS. E1 interface with a coaxial line is also provided.

The PDH part of these units is built similarly to the existing PDH interfaceunits FTEB and FTPB. The rest of this document focuses on the Ethernetextensions of these units.

The FTIA/FTJA is one of the building blocks of the RAN1063: HybridBackhaul with Pseudo Wires. RAN1142: ATM over Ethernet ApplicationSoftware is required to operate the Ethernet interfaces in order to conveyIub ATM traffic over a packet-switched network. For RAS06 the FTIA/FTJAallows to transport up to 30,74 Mbit/s of ATM traffic via the Ethernetinterface in uplink direction. In the downlink direction the overall capacity ofthe FTIA/FTJA is 70 Mbit/s of ATM. This is the sum of the Ethernetinterface and the used Pdh interfaces. The resulting data rate on theEthernet level is dependent on configuration, but up to 100Mbit/s.

The FTIA/FTJA provides 2 Fast Ethernet (100Base-TX) interfaces and oneoptionally pluggable Gigabit Ethernet interface to connect the BTS to apacket-switched network. The interfaces operate in full duplex mode andhave a LED connected each to display the connectivity status. Autonegotiation for the duplex mode is supported by default, but can beswitched off too.

All 3 Ethernet interfaces featured by the FTIA/FTJA are based on the IEEE802.3–2002 standard ) using the Ethernet II/DIX frame (that is,interpretation of the type length field). In RAS06 one out of the threeinterfaces can be used to connect an FTIA/FTJA to a packet-switchednetwork. The two remaining interfaces are intended for future extensions.

The interfaces support Ethernet VLAN according to IEEE 802.1Q. TheVLAN IDs are configurable and programmable priority bits are supported.IPv4 is used for IP packets on the FTIA/FTJA.



The Ethernet MTU is fixed to 1500 octets which leads to a maximumEthernet frame length of 1518 octets for plain Ethernet or 1522 octets forEthernet using VLAN respectively.

The 2 Fast Ethernet interfaces have RJ-45 connectors, operate viaCategory 5 (or better) twisted pair cables and support Tx/Rx auto-detection.

The optional optical Gigabit Ethernet interface comes as pluggable SFPmodule (SFP: Small Formfactor Pluggable Transceiver according to INF-8074i) equipped with an LC-connector. The SFP module has a class 1laser. For safety reasons modules deploying different laser classes areprevented from being operated. The SFP module can be of two differentflavours, which are either:

. Long haul: 1000 Base-LX, typically up to 5000m distance achievablewith SMF (single mode fiber), wavelength around 1300nm, or

. Short haul: 1000 Base-SX, typically up to 550m distance achievable;wavelength around 800nm.


Flexi WCDMA BTS can be backhauled over packet-switchedtechnologies, IP and Ethernet in particular. Operators can select from thefull variety of IP and Ethernet services. As the current backhaul networksare ill-suited to backhaul the large bandwidths and high peak ratesgenerated by HSPA Ethernet-based technologies have the potential toseparate cost from capacity, particularly for higher bandwidths.


When an FTIA/FTJA is powered up can be configured to convey ATM cellsencapsulated in IPv4 packets using either a Fast Ethernet or a GigabitEthernet interface. For information on the configuration possibilities, seeRAN1142: ATM over Ethernet for BTS. The parameter settings have tomatch the customers’ network setup. For information on the parameters,see Management data.


The FTIA/FTJA will transport any data only after activating a license.Configuration, as described in RAN1142: ATM over Ethernet for BTS andin Management data, can be done without a license.

DN70296245Issue 1-5 en13/06/2008



Architecture

Ethernet+E1/T1/JT1 Interface Unit (IUB User Plane) for Flexi WCDMABTS is one of the building blocks of RAN1063: Hybrid Backhaul withPseudo Wires.

As described in RAN1063: Hybrid Backhaul with Pseudo Wires, the BTS isequipped with Ethernet and TDM interfaces. The Pseudo Wire terminationfunction is carried out by the FTM FTIA/FTJA inside the BTS. Thefollowing figure depicts this configuration:

Figure 7. FTM FTIA/FTJA Pseudo Wire terminating function

The FTIA/FTJA actually is the PWE3 gateway inside the BTS.

The FTIA/FTJA can also be operated in a scenario as shown in thefollowing figure.

TDMI/F

ATM TDMI/F

Tunnel

PWE3Gateway


ATM

4*TDMI/F

TDMNetwork

Flexi WCDMA BTS

FTM

ATMtermination

nxSTM1Ethernet

I/F

RNC



Figure 8. FTIA/FTJA alternative operating scenario

2.3.3 System impact


This feature is implemented in FTM C3.0, which belongs to RAS06.

Without this feature all data is carried via ATM over TDM basedtechnologies.


The FTIA/FTJA hardware will be implemented to support the functionalitydescribed in RAN1063: Hybrid Backhaul with Pseudo Wires andRAN1142: ATM over Ethernet for BTS.

Requirement Reason

FTM Unit (FTIA/FTJA)

RNC PWE3 site solution


This feature is needed to support RAN1142: ATM over Ethernet for BTSand RAN1063: Hybrid Backhaul with Pseudo Wires.

TDMI/F

TDMI/F

TunnelEthernetI/F


ATM

BTS

AXC

ATMtermination

nxSTM1

IFUH

RNC

PWE3Gateway

DN70296245Issue 1-5 en13/06/2008



A similar feature for another NE (AXC) is RAN1097: Ethernet InterfaceUnit IFUH (Iub User Plane) for AXC.


This feature requires the FTM software to handle the new EthernetInterface Unit (FTIA/FTJA). The FTM software will furthermore support allconfiguration management, fault management and performancemonitoring data described in RAN1142: ATM over Ethernet for BTS and inManagement data.

Other Network elements will implement accordingly in releases:

. Flexi WCDMA BTS 4.0 (containing FTM C3.0)

. OSS: OSS4.2

RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 - - WBTS4.0

- - OSS4.2 - - - -




OSW RAN - -




NMS interfaces

This feature requires NMS to manage all data described in RAN1142: ATMover Ethernet for BTS and in the Management data section. It does notchange the behaviour of the interface itself.




The FTM Element Manager will support the handling of the new Ethernetinterface unit (FTIA/FTJA) and all data described in RAN1142: ATM overEthernet for BTS and the data listed in the Management data section.

Management data

This feature itself adds a new unit type to the FTM management data. TheFTM software additionally implements all data described in RAN1142:ATM over Ethernet for BTS.

Additionally the FTM has to implement the following management data.

Files

Table 7. Ethernet+E1/T1/JT1 Interface Unit (IUB User Plane) for FlexiWCDMA BTS file impacts

File Impact

*.tml Parameters are supported in FTM configuration files (TML) too.

Statistics

For information on statistics, see RAN1142: ATM over Ethernet for BTS.

Parameters

Table 8. Ethernet+E1/T1/JT1 Interface Unit (IUB User Plane) for FlexiWCDMA BTS impact on parameters

File Use

AcceptableFrameTypes Controls if the VLAN Tag support for the Ethernet interface isenabled or not.

VLAN_ID Configures the used VLAN IDs used for the Ethernet interface.

Duplex mode Switches the auto negotiation for the duplex mode on or off.

Alarms

The FTIA/FTJA will detect and report the trouble condition described in thefollowing table.

DN70296245Issue 1-5 en13/06/2008



Table 9. Ethernet+E1/T1/JT1 Interface Unit (IUB User Plane) for FlexiWCDMA BTSimpact on alarms

Alarm Description

LOS Loss of signal.

Additionally, there is the following management data related to this feature.



EthIfInOcts_15

EthIfOutOcts_15

EthIfInPkt_15

EthIfOutPkt_15

EthIfInPktErr_15

EthIfOutDiscShaping_15

EthIfInUnknownVLAN_15

EthUnknownPSNHdr_15


Signalling






2.4 RAN1099: Dynamic Scheduling for HSDPA withPath Selection

2.4.1 Introduction

This feature belongs to transmission and transport.



The Dynamic Scheduling for HSDPA with Path Selection feature containstwo functionalities. First, it introduces an enhanced internal flow control forHSDPA data and secondly it introduces a VCC bundling concept for thelast mile protection in transport network.

The dynamic flow control for HSDPA traffic operates between the AAL2and MAC layers in the RNC. It prevents packet loss in RNC’s AAL2 buffersand thus increases system performance and the end-users’ QoS. Inaddition, the feature makes the operating of the RNC and dimensioningthe network easier from the transport point of view. The feature alsoincreases Iub efficiency. The feature is used only on Iub.

An AAL2 buffer handled by the flow control mechanism contains oneoperator-configurable threshold ‘Low’ which triggers the ‘full rate’ sendingwhen the buffer is getting emptier. There are also other dynamicallyadjustable thresholds that affect the flow control message sending byreducing and increasing the incoming rate to the buffer. If the upper-mostthreshold is crossed the ‘full stop’ message is triggered.

The Low threshold is used to define how ‘aggressive’ the flow control is. Ifthe Low threshold is a relatively low value in respect to the AAL2 queuetarget delay, it can mean that the flow control restricts the data flow for toolong and thus reduces the performance.

On the other hand, if the Low threshold is set to a relatively high value inrespect to the AAL2 queue target delay, it can mean that all the thresholdsin the queue are close to each other, which then makes the flow controlfunctionality operate as if having only an ON / OFF mode. In addition, theinternal RNC load increases due to the increase of flow control messages.

The flow control functionality is also aware of the available bandwidthwhich can change (when the VCC bundling is used) and based on thebandwidth and queue situation a new set of queue thresholds arecalculated in short intervals and taken into use in order not to exceed theAAL2 queue target delay.

The AAL2 queue target delay is the additional maximum delay, which iscaused by the queuing in the AAL2 buffer. The flow control algorithm triesnot to exceed the defined AAL2 target delay. If the delay is less than thedefined value, the flow control does not tend to increase it.

The VCC bundling means that a common peak cell rate (PCR) can be setto a group of VCCs. This means that the total traffic amount of the bundledVCCs does not exceed the PCR set. The functionality is aimed for the lastmile or any other bottleneck in the system protection. If air interface is thebottleneck then VCC bundling isn’t any use. If dedicated VCCs are used tocarry different traffic types the total traffic amount will not exceed the PCR

DN70296245Issue 1-5 en13/06/2008



thus preventing congestion and traffic loss in the transmission network. Onthe other hand it is possible that the unused capacity of a VCC can beused for other VCCs. In a bundle there can be VCCs towards only oneBTS. There can be two VCC bundles defined for a BTS. Two bundles areuseful if HSDPA traffic uses different physical path than the DCH traffic, forexample, with BTS Hybrid backhaul.

Rules for configuring the bundles when only RAN1099 feature isenabled

Enabling the VCC bundle with the RAN1099 feature, allows using the flowcontrol only for HSDPA traffic, not for the NRT DCH traffic. This means thatthat the DCH traffic needs to be carried in DCH VCC where the NRT DCHflow control is not enabled. When VCCs are included in VCC bundleenabling only RAN1099 feature the following rules apply.

. When feature RAN1099: Dynamic Scheduling for HSDPA with PathSelection is enabled for a BTS, a VCC must be dedicated for HSDPAor HSPA traffic.

. The HSPA, HSDPA or HSUPA VCC must be UBR+ type.

. If the VCC bundle is used then all R99 VCCs must be in the sameVCC bundle.

. It is recommended that HSDPA VCC or HSPA VCC is equal tobundle PCR. This way the HSDPA traffic can use the all the bundlebandwidth if no other traffic.

The allowed configurations are given in the following table.

Table 10. Allowed configurations

RT DCH NRT DCH DCH HSDPA HSUPA HSPA

1. X X

2. X X X

3. X X

There can be one or more of each VCC type in bundle.

Enabling the bundle with RAN1100 contains different configuration rulesand enabling both RAN1100: Dynamic Scheduling for NRT DCH with PathSelection and RAN1099: Dynamic Scheduling for HSDPA with PathSelection for a BTS gives the most free configuration possibilities. For



more information about the RAN1100: Dynamic Scheduling for NRT DCHwith Path Selection and RAN1099: Dynamic Scheduling for HSDPA withPath Selection co-working, see Transport overview in RAS06 andRAS05.1 Transport Overview.

It should be noted that the RAS05.1 features RAN1020: Route Selectionand RAN324: Dynamic HSDPA Transport Scheduling are not supportedwith VCC bundling.

Figure 9. Example of VCC bundle

In the example VCC bundle the DCH VCC is scheduled first because ofthe tightest QoS requirements. The DCH VCC must be CBR and HSDPA /HSPA UBR+. If the HSDPA / HSPA VCC PCR is set equal to VCC bundlePCR, the HSDPA traffic can use all bandwidth if there is no other traffic.

A VCC bundle has a configuration parameter which defines how much ofthe VCC bundle bandwidth will be granted by the AAL2 CAC for NRT DCHtrafficHowever it is applied only when both HSDPA and NRT DCH are runon dedicated VCCs.

A2SUVCC BUNDLE

Line Card

Flowcontrol

AAL2Queue

HSDPA

Scheduler RLCMAC

RT and NRT DCH

DN70296245Issue 1-5 en13/06/2008




The feature improves the HSDPA throughput in the following ways:

. No AAL2 queue drops

. Less RLC Retransmissions

. Better throughput figures

. Smooth throughput graphs.

Also the bundling functionality is to avoid traffic loss in the last mile due tocongestion. That makes the transport network dimensioning easier andmore efficient.



RAN1099: Dynamic Scheduling for HSDPA with Path Selection activationrequires an RNC-specific capacity license. This means that the feature canbe activated according to purchased capacity. If a license exists, thefeature can be turned on with the ‘Internal HSDPA flow control method forBTS’ parameter.

For more information on feature activation, see Activating Dynamicscheduling for HSDPA with path selection in HSDPA Features, FeatureActivation Manual.

2.4.3 System impact


In RAS05.1, RAN324 Dynamic HSDPA Transport Scheduling is includedas an optional feature. The feature works only with CBR VCCs. AlsoRAN324 Dynamic HSDPATransport Scheduling works with both SHAREDand HSDPA dedicated VCCs.

Both RAS06 and RAS05.1 features are enabled using the same BTSspecific parameter, which means that the RAS05.1 RNC-specificparameter disappears.

Since both features are enabled with same parameter and both featureshave separate licenses, the system decides automatically which license ischarged.



If the HSDPA VCC or HSPA is included in the VCC bundle the RAN1099license is charged.

The RAN324 Dynamic HSDPA Transport Scheduling license can becharged only if CBR HSDPA VCC is configured outside the VCC bundle.

If neither of RAN1099: Dynamic Scheduling for HSDPA with PathSelection or RAN324 Dynamic HSDPA Transport Scheduling areactivated, only static rate control or ‘no control’ are available.


This feature has no hardware requirements.


This feature requires the RAN759: Path Selection feature. A VCC must bededicated to HSDPA traffic (HSDPA or HSPAVCC) in order to use the flowcontrol.

VCC bundling functionality is enabled also with dynamic scheduling forNRT DCH with path selection.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -




ASW RAN RNC LK Long-term capacitylicence



DN70296245Issue 1-5 en13/06/2008




NMS interfaces


No effects.


No effects.


The operator can configure the new parameters via NetAct or via RNCRNW Object Browser GUI. For information on the operator configurableparameters, see Management data.


No effects.


No effects.


No effects.


No effects.


The MML interface should not be used in configuring this feature.

Management data

Statistics:

There are no new counters related to this feature. The feature performancecan be monitored with the existing AAL2 scheduling performancemeasurement which measures the following:



. The AAL2 queue service rate in DL

. The estimated AAL2 layer buffering delay

. Flow control performance

. AAL2 traffic loss due to congestion

The counters in the measurement are:

Abbreviation

BE_QUE_PEAK

BE_QUE_SUM

BE_QUE_SAMPLES

BE_QUE_DELAY_PEAK

BE_QUE_DELAY_SUM

BE_QUE_DELAY_SAMPLES

BE_QUE_DOWN_MSGS

BE_QUE_UP_MSGS

BE_QUE_STOP_MSGS

BE_QUE_DRP_EVENTS

Also the RCPM Measurement (Radio Connection PerformanceManagement) is very useful to see the benefits of the feature, that is,reduced amount of RLC retransmission. In addition IP network protocolanalyzers can be used to see the increased TCP throughput figures.

Parameters:

Because two features are controlled with partially the same parameter set,the following table shows how parameters are related to features.

Parameter Use

VCC Bundle Peak Cell Rate (RAN1099) The maximum Peak Cell Rate the bundle allows totransmit

VCC Bundle Excess Bandwidth Share (RAN1099) Defines how the excess bandwidth is shared

VCC in Bundle (RAN1099) Defines whether VCC is included in bundle or not

VCC Bundle identifier (RAN1099) Identifies the bundle

Internal HSDPA flow control method for BTS(RAN1099 and RAN324)

Defines the used internal flow control method for theHSDPA traffic.

DN70296245Issue 1-5 en13/06/2008



Parameter Use

HSDPA flow control AAL2 queue low threshold fordedicated VCC (RAN1099 and RAN324)

The low threshold is an AAL2 buffer occupancythreshold in a dedicated VCC, which triggers sendingthe ‘full speed’

HSDPA flow control AAL2 queue target delay fordedicated VCC (RAN1099 and RAN324)

Defines the maximum allowed delay caused by AAL2queueing in a dedicated VCC.

HSDPA flow control AAL2 queue low threshold forshared VCC (RAN324)

The low threshold is an AAL2 buffer occupancythreshold in a shared VCC, which triggers sending the‘full speed’

HSDPA flow control AAL2 queue target delay forshared VCC (RAN324)

Defines the maximum allowed delay caused by AAL2queueing in a shared VCC.

The management data of this feature is listed in the following table.


VCC Bundle Excess BandwidthShare

VCC Bundle Peak Cell Rate

VCC In Bundle

VCC Bundle List

Internal HSDPA Flow ControlMethod for BTS


Signalling



The feature prevents packet loss in RNC AAL2 buffers and thus increasessystem performance and the end-users’ QoS.

The bundling functionality increases the bandwidth usage and makes thedimensioning easier when several VCCs are used.



2.4.3.10 Limitations and restrictions

RAN1099: Dynamic Scheduling for HSDPA with Path Selection can beused only if a VCC is dedicated to HSDPA traffic.



This feature is used on Iub only.

2.5 RAN1100: Dynamic Scheduling for NRT DCH withPath Selection

2.5.1 Introduction

This feature belongs to Transmission and transport.

The Dynamic Scheduling for NRT DCH with Path Selection featurecontains three functionalities. First, it introduces an RNC internal flowcontrol for NRT DCH downlink traffic. Secondly, it introduces a VCCbundling concept for NRT DCH traffic. Thirdly, it sets the activity factor ofNRT DCH bearers to 0.75 for both uplink and downlink. Setting the activityfactor of NRT DCH bearers to smaller than 1 makes it possible to establishmore AAL2 connections and as result increasing the capacity. The featureis used only on Iub interface.

The dynamic flow control for NRT DCH traffic operates between the AAL2and MAC layers in the RNC. It prevents packet loss in RNC AAL2 buffersin temporary congestion situation when activity factor is set below 1.

There are two thresholds in the AAL2 buffer, low and high. When the AAL2buffer is getting fuller the AAL2 buffering delay is increasing. When thehigh threshold is crossed upwards the flow control functionality sendsmessages to upper layer to reduce the speed the data is coming in. Thebearer speed is halved. In case of 384kbps bearer, the speed isdowngraded to 128kbps.

When the buffer is getting emptier and the low threshold is crosseddownwards the speed is increased back to original. The thresholds are seton the basis of the configuration parameter ‘NRTDCH Flow Control AAL2Queue Target Delay’. The parameter sets the target delay which the flowcontrol tries not to exceed. If the delay is less than the parameter value thedelay of traffic is not increased. When the NRT DCH traffic is carried in aUBR+ VCC inside the VCC bundle, the flow control algorithm can take thevarying amount of free bandwidth into account when calculating thethresholds.

DN70296245Issue 1-5 en13/06/2008



The flow control is not used for all the NRT DCH bearers that have peak bitrate more than 8kbps. Also, if the activity factor is set too low withRAN1096: Transport Bearer Tuning, the flow control uses the built-inminimum value of 0.1. However it is highly recommended that the lowestAF used for 384kbps bearers is 0.38 and for other traffic 0.5. If AF is setlower the possibility of loosing packets increases in high load situations.

When AF is set smaller than 1 the AAL2 delay increases in congestion. Ifdelay increases too much normally it means that data arrives too late to hitthe receiving window in BTS. For that reason the ToAW is set larger withthis feature in order to prevent transport channel synchronizationprocedure and this way RLC retransmission. The parameter ‘ToAWSOffset for overbooked NRT DCH AAL2 connection defines how much theToAW is increased when bearer is set up. When ever the offset value ischanged, changing the value of ‘NRTDCH Flow Control AAL2 QueueTarget Delay’ should be considered also.

The NRT DCH flow control can be enabled only in dedicated NRT DCHVCC. The VCC can be inside or outside the bundle. Outside the bundle theCBR must be used but inside the bundle UBR+ must be used if the flowcontrol needs to be enabled.

The VCC bundling means that a common peak cell rate (PCR) can be setto a group of user plane VCCs in RNC for downlink. This means that thetotal traffic amount of the bundled VCCs do not exceed the PCR set. Thefunctionality is aimed for preventing overflow in the last mile or any otherbottleneck in the system. If air interface is the bottleneck then VCCbundling does not bring any benefit. If dedicated VCCs are used to carrydifferent traffic types, the total traffic amount does not exceed the PCRthus preventing congestion and traffic loss in the transmission network. Onthe other hand it is possible that the unused capacity of a VCC can beused for other VCC if UBR+ is used. In a bundle there can be VCCstowards only one BTS. Two VCC bundles per BTS can be defined. IfRAN1099: Dynamic Scheduling for HSDPA with Path Selection is notenabled, only one bundle can be used with RAN1100: DynamicScheduling for NRT DCH with Path Selection. If the VCC bundle is usedfor DL in RNC, it is recommended to be used for UL in BTS also.

It is recommended that when the flow control is enabled the availablebandwidth for NRT DCH to be more than 1100cps. If no MDCR is definedto guarantee the bandwidth, that during high load, when availablebandwidth for NRT DCH is reduced to less than 1100cps, the flow controlmay not work optimally in all cases. Non optimal working means thatsometimes the flow control may reduce the sending rate of theconnections earlier than high bandwidth cases when trying to prevent the



traffic loss, and guarantee the QoS for admitted connections. Earlyreduction of sending rate means that some bandwidth may be left unused.In such a case no new connections are admitted, even though somebandwidth is available.

The recommendation applies to VCCs supporting NRT DCH flow controlno matter if they are bundled or not.

Rules for configuring the bundle when only RAN1100: DynamicScheduling for NRT DCH with Path Selection is enabled

Enabling the VCC bundle only with the RAN1100: Dynamic Scheduling forNRT DCH with Path Selection feature allows only bundling the DCH traffic,meaning that it is not possible to include VCCs carrying HSDPA traffic.When RTDCH and NRTDCH VCCs are included in VCC bundle enablingonly RAN1100: Dynamic Scheduling for NRT DCH with Path Selectionfeature the following rules must be followed.

. When RAN1100: Dynamic Scheduling for NRT DCH with PathSelection is enabled for a BTS, a VCC must be dedicated for NRTDCH traffic.

. The NRT DCH VCC must be UBR+ type.

. All VCCs carrying DCH traffic must be either inside one bundle oroutside both bundles.

. It is recommended that PCR of NRT DCH VCC is equal to bundlePCR. This way the NRT DCH traffic can use all the bundlebandwidth if there is no other traffic.

Enabling the bundle with RAN1099: Dynamic Scheduling for HSDPA withPath Selection contains different configuration rules and enabling bothRAN1100: Dynamic Scheduling for NRT DCH with Path Selection andRAN1099: Dynamic Scheduling for HSDPA with Path Selection for a BTSgives the most configuration possibilities. For more information aboutRAN1100: Dynamic Scheduling for NRT DCH with Path Selection andRAN1099: Dynamic Scheduling for HSDPA with Path Selection co-working, see Transport overview in RAS06 and RAS05.1 TransportOverview.

The allowed VCC bundle configuration with RAN1100: DynamicScheduling for NRT DCH with Path Selection is given in the followingtable.

DN70296245Issue 1-5 en13/06/2008



Table 11. Allowed configurations

RTDCH NRTDCH DCH HSDPA HSUPA HSPA

1. X X

There can be one or more of each VCC type in the bundle.

Figure 10. Example of VCC bundle

In a bundle the RT DCH VCC is scheduled first because of the tightestQoS requirements. The RT DCH VCC must be CBR type and the NRTDCH VCC UBR+. If the NRT DCH VCC PCR is set equal to bundle PCRthe NRT DCH traffic can use all the bandwidth if there is no other traffic.

HSDPANRT DCH

(PS)RT DCH(Voice)

RLCMAC

Flowcontrol

AAL2queues

UBR +VCC UBR + CBR

A2SU

SchedulerScheduler

Rate limited VCC bundle

VPC

Line



A bundle has a configuration parameter which defines how excessbandwidth is shared between NRT DCH and HSDPA traffic in a congestionsituation.

However the parameter is applied only when both HSDPA and NRT DCHare run on dedicated VCCs in the .same VCC bundle. For more details seeRAS06 and RAS05.1 Transport Overview, Feature Description.

The AAL2 CAC in the VCC bundle

The VCC bundle introduces a new way of doing the AAL2 CAC for NRTDCH downlink connections in RNC. If RAN1100: Dynamic Scheduling forNRT DCH with Path Selection is not enabled, then the AAL2 CAC is doneon the guaranteed bandwidth a VCC connection provides; that is, PCR incase of a CBR VCC and MDCR in case of a UBR+ VCC.

The actual available bandwith changes dynamically based on the totalload of the VCC bundle. If there is no RT DCH traffic in the VCC bundlethen the NRT can get all the bandwidth reserved for the RT DCH traffic.

When RT connections get admitted they get the required bandwidthbecause of higher priority which then reduces the amount of bandwidthavailable for NRT connections. And vice versa, when RT connections end,the amount of bandwidth available for NRT connections increases.

Note that if some bandwidth is reserved for HSPA traffic ( that is MDCR ofUBR+ VCC) the NRT DCH is not able to use that. The MDCR of HSDPA,HSUPA and HSPA are hard guaranteed and the NRT DCH traffic cannotuse that share of bandwidth either in AAL2 CAC or from a scheduling pointof view.

If no other traffic exists in bundle the VCC PCR can be up to bundle PCR ifdefined so. When RT DCH connections get admitted or HSDPA usersappear (if configured in same bundle with RAN1099: Dynamic Schedulingfor HSDPA with Path Selection) they get their designated share of thebandwidth which decreases the NRT DCH PCR. The NRT DCH PCR cannever be less than the MDCR defined for the NRT DCH VCC which isused as bandwidth reference without bundle.

If in RNC feature RAN1100: Dynamic Scheduling for NRT DCH with PathSelection is enabled then the VCC bundle mode for the AAL2 CAC in theBTS for uplink must be enabled, too. This mode performs the same AAL2CAC rules in the BTS for uplink. The following rules apply for the BTS:

DN70296245Issue 1-5 en13/06/2008



. RAN1095: UBR+ for Iub User Plane must be licensed and enabledin the BTS.

. There is no additional BTS license required for RAN1100: DynamicScheduling for NRT DCH with Path Selection.

. The BTS autonomously puts all the user plane VCC in the sameATM interface into a VCC bundle.

. The BTS calculates the uplink VCC Bundle rate autonomously byATM interface bandwidth minus all non AAL2 user plane VCCguaranteed bandwidth (that is, sum of CBR PCR and UBR+ MDCRof all VCC carrying non user plane traffic such as control plane ormanagement plane).

. For UltraSite WCDMA BTS, feature RAN1.5057: BTS AAL2Multiplexing must be enabled.

. UltraSite WCDMA BTS must be a leaf node (on ATM interfaces withterminated user plane VCC there must not be any other traffic cross-connected from other BTSs)

With the new bundle CAC algorithm the system performance is increased(that is, more calls get admitted) because the bandwidth reference of AAL2CAC for NRT DCH traffic inside bundle is between MDCR of the NRT DCHVCC and PCR of the bundle (not the MDCR as without bundle). If the NRTDCH DL traffic consumes more bandwidth than UL more calls getadmitted.

Note that when ever bundles are used they have to be used for both ULand DL.

The Path type in the VCC bundle

Outside the VCC bundle the path type can be set freely. However, whenVCC is included in the VCC bundle, the allowed values for path type arelimited.

For the RT DCH VCC and NRT DCH VCC the path type has to be set to“stringent” or “stringent bi-level”.

The reason for prohibiting the “tolerant” for RT DCH and NRT DCH VCCsis that there is no way to limit the amount of connections in the bundle incongestion situation and as a result decrease the possibilities for properfunction.


The feature increases the Iub efficiency in the following ways:



. more connections can be established due to lower AF,

. no AAL2 queue drops,

. less RLC Retransmissions,

. better throughput figures,

. smooth throughput graphics.

Also the bundling functionality is to avoid traffic loss in the last mile indownlink due to congestion. That makes the transport networkdimensioning easier and more efficient.

2.5.2 System impact of RAN1100: Dynamic Scheduling for NRT DCH withPath Selection

The table below gives a summary on the system impact of FeatureRAN1100: Dynamic Scheduling for NRT DCH with Path Selection. If thefeature has an impact on one of the areas listed, you will find moreinformation under the appropriate topic below. If the feature has no impact,the topic is only included in the table where the "no impact" information isshown.

Target / scope of impact Degree of impact

Current implementation Major

Interdependencies with other features Major

Software requirements Major

Hardware requirements Ultrasite AXU-B or AXC-C

Control and user plane No impact

Management plane Minor

NMS interfaces Minor

Network element user interfaces Minor

Management data No impact

System performance and capacity Major

Mobile terminals No impact

3 G system requirements No impact

Limitations and restrictions Minor

Compliance No impact

DN70296245Issue 1-5 en13/06/2008




This feature is implemented in RAS06. There are no interdependencies toearlier releases.


This feature requires the RAN759 Path Selection feature. A VCC must bededicated to NRT DCH bearers.

RAN1100: Dynamic Scheduling for NRT DCH with Path Selection affectsthe NRT DCH bearers’ activity factors (AF) similar to RAN1096: TransportBearer Tuning. If the AF is set too low with RAN1096: Transport BearerTuning, the flow control built-in minimum value 0.1 is used for CAC.

VCC bundling functionality is enabled also with the RAN1099: DynamicScheduling for HSDPA with Path Selection feature but the configurationrules differ.

If NRT DCH VCC is included in the VCC bundle it must be configured to beUBR+ type.

For UltraSite WCDMA BTS, feature RAN1.5057: BTS AAL2 Multiplexingmust be enabled and licensed.

RAN1095: UBR+ for Iub User Plane must be enabled and licensed.


The feature sets the following requirements:

. RAS06

. RNC: RN3.0

. OSS4.2

. AXC C3.0

. WBTS 4.0


If more than two user plane VCCs are configured on a route, the AAL2multiplexing functionality must be used in UltraSite BTS. One exception tothe rule above is that if RT DCH VCC + NRT DCH VCC are configured ona route (only two VCCs) the multiplexing is used also.






NMS interfaces


This feature has no effects on planning tool


This feature has no effects on management tools


The operator can configure the new parameters via NetAct or via RNCRNW Object Browser GUI. For information on operator configurableparameters, see Management data.


The operator can configure the new parameters via NetAct or via RNCRNW Object Browser GUI. The operator configurable parameters arelisted in Section Management data.

Impact on transport network configuration management tool

This feature has no effects on transport network configurationmanagement tool.


This feature has no effects on reporting tools.


This feature has no effects on monitoring tools.


This feature has no effects on optimising tools.

DN70296245Issue 1-5 en13/06/2008




See Nokia Siemens Networks WCDMA RNC Product Documentation formore detailed information.

Management data

Statistics:

There are no new counters related to this feature. The feature performancecan be monitored with the existing AAL2 scheduling performancemeasurement which measures the following:

. The AAL2 queue service rate in DL

. The estimated AAL2 layer buffering delay

. Flow control performance

. AAL2 traffic loss due to congestion

The counters in the measurement are:

Abbreviation

BE_QUE_PEAK

BE_QUE_SUM

BE_QUE_SAMPLES

BE_QUE_DELAY_PEAK

BE_QUE_DELAY_SUM

BE_QUE_DELAY_SAMPLES

BE_QUE_DOWN_MSGS

BE_QUE_UP_MSGS

BE_QUE_STOP_MSGS

BE_QUE_DRP_EVENTS

Also the RCPM Measurement (Radio Connection PerformanceManagement) is very useful to see the benefits of the feature, that is,reduced amount of RLC retransmission. In addition IP network protocolanalyzers can be used to see the increased TCP throughput figures.

Parameters:



Table 12. Dynamic Scheduling for NRT DCH with Path Selection impact onparameters

Parameter Use

VCC Bundle Peak Cell Rate Defines the peak traffic amount that can be sent

VCC Bundle Excess Bandwidth Share Defines how the excess bandwidth is shared

VCC in Bundle Defines whether VCC is included in bundle ornot

VCC Bundle identifier Identifies the bundle

Target AAL2 delay for NRT DCH The maximum AAL2 delay

Dynamic NRT DCH Scheduling with pathselection switch

Defines if the feature is turned on or off for theBTS.

ToAWS Offset for overbooked NRT DCH AAL2connection

Defines the offset value to be added to thecorresponding ToAWS_NRT_DCH_ttiXXparameter value whenever the overbookingmode is used for NRT DCH in the Iub interface.

Table 13. Dynamic Scheduling for NRT DCH with Path Selection impact onBTS parameters

BTS parameters Use

TRDE user label If any TRDE has a user label with string“VCC_BUNDLE” then the VCC Bundle mode forthe AAL2 CAC is enabled. Note, the correctspelling is important. The functionality is disabledin BTS by deleting or misspelling the string

Signalling



The feature itself improves the Iub capacity with the lower activity factorbecause it allows more AAL2 connections to be established. The flowcontrol functionality prevents packet loss and poor QoS in temporarycongestion situations. Also the feature helps if even lower AFs are set withRAN1096: Transport Bearer Tuning.

The bundling functionality increases the bandwidth usage and makes thedimensioning easier when several VCCs are used.

DN70296245Issue 1-5 en13/06/2008






The NRT DCH flow control can be used only if a VCC is dedicated to NRTDCH traffic.

If the AF of a bearer is changed with other features, the AF must be at least0.1 though it is recommended to use higher values.

This feature is used on Iub only.



RAN1100: Dynamic Scheduling for NRT DCH with Path Selectionactivation requires an RNC-specific capacity license. This means that thefeature can be activated only according to purchased capacity.

For more information on activating the feature, see Activating Dynamicscheduling for NRT DCH with path selection in Feature RAN1100:Dynamic Scheduling for NRT DCH with Path Selection, Feature ActivationManual .

The activation of the VCC Bundle mode for AAL2 CAC is BTS is by settinga string as described in this document.

2.6 RAN759: Path Selection

2.6.1 Introduction

This feature belongs to Transmission and Transport.

RAN759: Path Selection is an optional feature and it can be enabled perBTS in the RNC.

The feature contains the following main functionalities:



. User plane traffic can be divided into different dedicated VCCs.

. Path type can be defined for a VCC. Each path type has an ownAAL2 CAC algorithm.

. The ITU-T Q.2630.2 CS2 path type is included in an ERQ message.

. Interactive class NRT bearers can be treated according to TrafficHandling Priority (THP) as delay-sensitive or non-delay-sensitivetraffic

. The length of AAL2 buffer can be modified based on the VCC type.

RAN759: Path Selection allows dedicating VCCs for RT DCH, NRT DCHand HSDPA traffic. When dividing the traffic into different VCCs thetransport network will be able to support the overbooking or statisticalmultiplexing of different traffic types without affecting other traffic types.The overbooking and statistical multiplexing allow bandwidth savings inthe transport network. If wanted, the DCH VCC can be defined to carryboth RT and NRT DCH traffic on a same VCC. VCC can also be used asSHARED when DCH and HSDPA traffic types are carried in it. The HSUPAtraffic will require an own dedicated HSUPA VCC or it can be carriedtogether with HSDPA in HSPA VCC.

The dedicated VCCs (RT DCH, NRT DCH, HSDPA and HSUPA) containonly one AAL2 priority queue per VCC in the RNC but the DCH VCCcontains 2 and SHARED VCC 3 AAL2 priority queues. The commonchannels, control and SRB traffic are always using the same highestpriority queue as the RT DCH traffic. In DCH VCC the NRT DCH traffic ismapped to low priority queue. In SHARED VCC the NRT DCH traffic isusing the middle priority queue and the HSDPA traffic the low priorityqueue.

The HSPA VCC contains also 2 AAL2 priorities in RNC. The HSUPAcontrol traffic will use the high priority queue and the HSDPA traffic will usethe low priority queue. This way the HSUPA congestion control DLmessages get priority over HSDPA traffic.

A strict priority scheduler is used when scheduling traffic from the AAL2queues.

The reason for multiple AAL2 priorities in RNC is to support better the NRTDCH overbooking. With one AAL2 queue for R99 traffic overbooking of atraffic type affects the others traffic types as well which leads easily toincreased AAL2 delays and in worst case loss of cell synchronization andcell restart. With several AAL2 priorities for R99 traffic the NRT DCH trafficcan be overbooked without affecting the other traffic types. Withoverbooking, more connections get admitted thus increasing the systemperformance.

DN70296245Issue 1-5 en13/06/2008



The two-priority DCH VCC is used regardless of the license charged (thatis, RAN1020: Route Selection or RAN759: Path Selection). Also the 3priority SHARED VCC is used as default.

In Ultrasite WCDMA BTS and Flexi WCDMA BTS, there are no AAL2 levelpriorities for UL traffic inside a VCC.

When a VCC is created, a path type needs to be defined for it. Each pathtype has a different AAL2 admission control (CAC) algorithm in DL and UL.The AAL2 CAC algorithms used in RNC for DL are described in moredetail in chapter 3.

The path type can be set freely but it is recommended that the path type forRT DCH is stringent, for NRT DCH stringent bi-level and for HSDPA itshould be tolerant. When the VCC Bundle functionality is used there arelimitations in choosing the path type. For more details see the RAN1099and RAN1100 feature documents.

The selected path type is signaled to BTS in an establish request (ERQ)message as defined in ITU-T Q.2630.2 specification when as AAL2connection is established using the VCC in concern. The functionality is3GPP-compliant.

With Path Selection it is possible to define whether interactive class NRTbearer is treated as delay-sensitive or delay-tolerant based on its traffichandling priority (THP). THP values 1, 2 or 3 can be defined as delay-sensitive or delay-tolerant. If bearer’s THP has some other value it istreated as delay-tolerant. When an AAL2 connection is established overthe Iur interface, the THP is not delivered and the THP is considered tohave value 1.

If there are different VCCs configured to RT DCH and NRT DCH traffic, thedelay-sensitive NRT traffic (for example,. some game related traffic orstreaming service) is carried in RT DCH VCC due to less AAL2 delay inRNC: The activity factor for delay-sensitive NRT DCH traffic is 1regardless of how the activity factor is set with other features in order not toruin the QoS of RT traffic carried in the same VCC. If RT DCH and NRTDCH are carried in the same VCC this traffic handling priority does notmatter i.e. in DCH VCC and SHARED VCC the NRT DCH traffic willalways use the low or middle priority queue regardless of the THP values.For more information on THP, see 3GPP TS 23.107 Quality of Service(QoS) concept and architecture.

The AAL2 queue lengths according to the VCC type can also be modifiedwith this feature. If RAN 1100: Dynamic Scheduling for HSDPA with PathSelection or RAN1099: Dynamic Scheduling for NRT DCH with PathSelection is used, the AAL2 queue length affects the dynamic scheduling



performance. The queue length should correspond to the VCC bandwidth:the larger the bandwidth the longer the queue. If no dynamic scheduling isenabled, the longer buffer causes longer AAL2 delay in congestionsituation. The delay may also affect upper layer performance.


RAN759: Path Selection allows specifying dedicated VCCs for certaintraffic types. Those VCCs can use different transmission paths accordingto the specific QoS requirements, which can result in cost savings. Mostuseful the feature is when used with other new RAS06 transport features.

Path Selection is a mandatory feature for RAN 1100: Dynamic Schedulingfor HSDPA with Path Selection and RAN1099: Dynamic Scheduling forNRT DCH with Path Selection features.



Path Selection activation requires an RNC-specific capacity license. Thismeans that the feature can be activated only to a limited number of BTSs.A license is charged in three cases:

. The VCC type is set to something else than SHARED.

. The path type is set to any other value than ‘stringent’.

. UBR+ is used as ATM service category for a VCC. That is,RAN1020: Route Selection cannot be used with UBR+.

The RAS05.1 feature RAN1020 Route Selection allows dedicating VCCsfor DCH and HSDPA traffics. If both free RAN1020: Route Selection andRAN759: Path Selection licenses are in system, and created configurationis such that both could be charged (that is, DCH+HSDPA with both havingCBR as ATM service category), then RAN1020: Route Selection ischarged.

The UBR+ limitation with RAN1020: Route Selection applies only to DCHand HSDPA VCCs. If HSUPA is added on top route selection, the ATMservice category can be selected freely.

. DCH (CBR) + HSDPA (CBR) + HSUPA (UBR+) is allowed withRAN1020: Route Selection license.

. DCH (CBR) + HSDPA (UBR+) +HSUPA (UBR+) requires RAN759:Path Selection license.

DN70296245Issue 1-5 en13/06/2008



The following table illustrates what VCC combinations are allowed whenfeatures are enabled.

Table 14. Allowed VCC configurations

VCC type /Licence

SHARED

RT DCH NRTDCH

DCH HSDPA HSUPA HSPA

None X

RAN1020 X

X X

X X

RAN759 X X

X X X

X X

HSUPA X X

RAN1020 +HSUPA

X X X

X X X

RAN759 +HSUPA

X X X

X X

X X X X

X X X

In addition to the table the following rules apply:

. If more than 2 user plane VCC are configured on a route,RAN1.5057: BTS AAL2 multiplexing must be enabled.

. The RT DCH + NRT DCH configuration on a route is a special case.It requires also AAL2 MUX even though only 2 VCCs are configured.

. If several routes are configured to BTS (i.e. AAL2 MUX is not used)at least one route must contain a VCC for the HSDPA traffic (i.e.HSDPA or HSPA VCC).



. If several routes are configured, the HSPA VCC cannot be mixedwith HSDPA and HSUPA VCCs to same BTS. That is, if HSPA VCCis used on a route, there cannot be HSDPA or HSUPA VCCs onother routes to the same BTS. On the other hand if HSPAVCC is notused the HSDPA and HSUPA VCCs can freely selected as long asthe rule above is obeyed.

. · DCH + SHARED configuration is exception which is supported onlywith RAN1020: Route Selection.

RAN1020: Route Selection and RAN759: Path Selection do not have anyrestriction how different VCCs are configured to VPCs.

The ATM service categories for the VCCs can be CBR or UBR+ whenRAN759: Path Selection is used.

The feature can be verified by monitoring the ATM Virtual Channelconnection PM data and the reserved transport capacity of the AAL2connection.

For more information on feature activation, see Activating path selection inFeature RAN759: Path Selection, Feature Activation Manual.

Figure 11. Path Selection

The AAL2 CAC

WCDMABTS

WCDMABTS

ATMSWITCH

ATMSWITCH

1...n

RNC

Iub Transport Capacity

HubPoint

rt VCC

nrt VCC HSPAVCC

Aggregate rt VCC = S1..n rt VCC

Aggregate rt VCC S1..n rt VCC

DN70296245Issue 1-5 en13/06/2008



ATM service category and AAL2 CAC bandwidth referense

In order to serve its purpose the AAL2 CAC is done using the guaranteedbandwidth as reference. When CBR is used as ATM service category, thePCR of the VCC is used as reference. This has been used also in earlierreleases.

However, when UBR+ is used outside the VCC bundle as ATM servicecategory, the MDCR is used as bandwidth reference for AAL2 CAC andnot the PCR as in CBR case. This behavior should be noted especiallywhen UBR+ is used for NRT DCH traffic. Typically AAL2 CAC needs to beperformed for NRT DCH traffic and thus setting the value to 0 or othersmall value might not be a good idea.

For HSPA traffic, setting the MDCR does not matter from AAL2 CAC pointof view because all HSPA connections are best effort by nature and nobandwidth is reserved for individual connections. Of course, for HSPAtraffic also the MDCR needs to have a proper value if bandwidth guaranteeis required.

Path type and AAL2 CAC algorithm

The RNC has several AAL2 CAC algorithms in use. The used algorithmdepends on the used VCC type and the path type. If path type is set to“stringent bi-level” or “tolerant” the algorithms are simple.

. In AAL2 CAC point of view the path type does not matter much forVCCs carrying HSPA traffic. For HSPA traffic no AAL2 connectionspecific bandwidth reservations are done. Since the reservation isclose to zero the algorithm does not matter much. The HSPA trafficis best effort in nature.

. If path type is set to “tolerant” no AAL2 CAC is done. This applies toall VCC and traffic types. It is recommended that tolerant is usedonly for HSPA traffic.

. If path type is set to “stringent bi-level” the AAL2 CAC algorithm is:

0,05 * connection peak bit rate + 0,95 * connection average bit rate.

It is recommended that the stringent bi-level path type is used forNRT DCH VCCs.

. If path type is set to “stringent” the used CAC algorithm depends onthe traffic type. For traffic which is the most delay sensitive (that is,using the highest AAL2 priority in RNC when in SHARED and DCHVCCs) uses QTalgorithm which is based on the queue theorem. Thealgorithm output is not linear so the reserved bandwidth depends on



the amount of connections admitted. With small number ofconnections the reserved bandwidth is closer to connection’s peakrate. With dozens of connections admitted the good approximationfor the algorithm is:

0,2 * connection peak bit rate + 0,8 * connection average bit rate.

For other R99 connections which are using lower AAL2 priorities in RNC (I.e. for NRT DCH connections) QT is not used but the 20 / 80 algorithmdescribed above.

Generally for UL the AAL2 CAC is the same path type dependentalgorithms are used with the exception that QT is not used but the 20 / 80is used instead for all R99 connections.

If the UL VCC bundle is enabled the AAL2 CAC behaves differently. Formore details see RAN1100: Dynamic Scheduling for NRT DCH with PathSelection and Transport overview in RAS06 and RAS05.1 TransportOverview. Also see, Introduction to dimensioning WCDMA RAN inDimensioning WCDMA RAN.

2.6.3 System impact


In RAS05 release, only the SHARED VCC is available. In RAS06 releasethe SHARED VCC is still for carrying all user plane traffic except HSUPAeven though feature is enabled.

In RAS05.1, an optional RAN1020: Route Selection feature wasintroduced. It allowed dedicating different VCCs for HSDPA and DCHtraffic types.

In RAS05.1 and earlier releases, there was no support for CS2 path type.Also the AAL2 buffers had fixed lengths. The THP value of a bearer wasnot taken into account.

DN70296245Issue 1-5 en13/06/2008




If AXU-A is used (no BTS AAL2 multiplexing capability) in UltraSiteWCDMA BTS, only two user plane VCCs can be configured to a WAM unitin BTS. If it is necessary to separate user plane traffic to three differentVCCs (RT DCH, NRT DCH and HSDPA) an AXU-B (or later) unit with BTSAAL2 multiplexing capability is required in UltraSite WCDMA BTS. TheAAL2 multiplexing is required also if only RT DCH and NRT DCH VCCsare configured.

For Flexi WCDMA BTS there are no additional hardware requirements.

Requirement Reason

UltraSite WCDMA BTS: AXU-B unitor later

AAL2 multiplexing capability is required if RT DCH + NRT DCHconfiguration is used or three or more user plane VCCs are used on aroute.


RAN759: Path Selection does not require any other feature to function.

RAN759: Path Selection is mandatory for the following RAS06 transportfeatures


. RAN 1100: Dynamic Scheduling for HSDPA with Path Selection

If HSUPA is enabled with Path selection a new VCC type HSPA can beused. The HSPA VCC is for both HSDPA and HSUPA traffic.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 C3.0 OSS4.2 - - - -




ASW RAN RNC LK





Long-term capacitylicence


This feature adds the path type parameter in an ERQ message in Iub asdefined in ITU-T specification Q.2630.2. If CS2 is not supported in theother end the path type is just ignored.


NMS interfaces


There are new AAL2 CAC algorithms.


No effects.


The operator can configure the new parameters via NetAct or via RNCRNW Object Browser GUI. For information on operator configurableparameters, see Management data.


No effects.


No effects.


This feature adds four new counters in ‘ATM Virtual Channel Connection’measurement. They can be used to scale the measured traffic load toavailable bandwidth.

In addition to the new counters, the existing counters and measurementscan be used to follow the functionality.

DN70296245Issue 1-5 en13/06/2008



For more information, see Measuring ATM virtual channel connection inRNC Measurement Management and ATM/IP transport measurements inRNC Counters – Transport and HW Part.


No effects.


See Nokia WCDMA RNC Product Documentation for more detailedinformation.

Management data

Statistics:

There are the following new counters related to the RAN759: PathSelection feature.

Table 15. RAN759: Path Selection statistics

Statistics Use

IN_CAP_VC Configured ingress bandwidth for the virtual channelconnection

EG_CAP_VC Configured egress bandwidth for the virtual channelconnection

IN_CAP_VP Configured ingress bandwidth for the virtual pathconnection

EG_CAP_VP Configured egress bandwidth for the virtual pathconnection

Parameters:

Table 16. RAN759: Path Selection impact on parameters

Parameter Use

AAL2 UP Usage Defines what traffic type the VCC is for

BTS AAL2 UP Usage Defines what traffic type the VCC is for in UltraSiteWCDMA BTS

Path Type Defines the path type for the VCC

THP1 Delay Sensitivity Switch



Table 16. RAN759: Path Selection impact on parameters (cont.)

Parameter Use

Defines whether interactive class bearer with THP=1is treated as delay sensitive or delay tolerant traffic.

THP2 Delay Sensitivity Switch Defines whether interactive class bearer with THP=2is treated as delay sensitive or delay tolerant traffic.

THP3 Delay Sensitivity Switch Defines whether interactive class bearer with THP=3is treated as delay sensitive or delay tolerant traffic.

AAL2 queue length for HSDPA without Flow Control Defines the length of AAL2 queue for HSDPA VCCwhen dynamic scheduling is not used.

AAL2 queue length for HSDPA with Flow Control Defines the length of AAL2 queue for HSDPA VCCwhen dynamic scheduling is used.

AAL2 queue length for NRT DCH without Flow Control Defines the length of AAL2 queue for NRT DCH VCCwhen dynamic scheduling is not used.

AAL2 queue length for NRT DCH with Flow Control Defines the length of AAL2 queue for NRT DCH VCCwhen dynamic scheduling is used.

AAL2 queue length for RT DCH Defines the length of AAL2 queue for RT DCH VCC.

AAL2 queue length for HSUPA Defines the length of AAL2 queue for HSUPA VCC.

The queue lengths for SHARED, DCH and HSPA VCC are defined withthese parameters. See parameter definitions for more detail.



AAL2 Queue Length for NRT DCHWith Flow Control

AAL2 Queue Length for NRT DCHWithout Flow Control

AAL2 Queue Length for RT DCH

AAL2 Path Type

THP 1 Delay Sensitivity Switch



AAL2 UP Usage

AAL2 Queue Length for HSUPA

AAL2 Queue Length for HSDPAWith Flow Control

IN_CAP_VC

EG_CAP_VC

IN_CAP_VP

EG_CAP_VP


DN70296245Issue 1-5 en13/06/2008



The queue lengths for SHARED, DCH and HSPAVCC are defined with theabove parameters. See parameter definitions for more details.

Signalling

The path type is included in an ERQ message as specified in ITU-TQ.2630.2.


RAN759: Path Selection increases transport performance and capacity. Inaddition, when used together with other new features the efficiencyincreases. For example, with feature RAN1096: Transport Bearer Tuning,the RAN759: Path Selection feature makes it possible to use lower activityfactors when RT DCH and NRT DCH traffic is carried in different VCCs.

For more information, see Dimensioning WCDMA RAN.




When VCCs are configured to a BTS, a VCC for DCH traffic must alwaysbe configured. On a route there has to be ‘RTDCH and NRTDCH’ or DCHor SHARED VCC configured. Configuring VCC for HSDPA is notmandatory if only one route exists. If there are several routes at least oneroute need to have VCC for HSDPA traffic. (that is, SHARED or HSPA orHSDPA VCC).

Path Selection is only available for user plane in the Iub interface.

2.7 RAN1096: Transport Bearer Tuning

2.7.1 Introduction

With Transport Bearer Tuning, the operator can overbook DL and UL trafficand allow more AAL2 connections on the Iub interface. Traffic overbookingis based on statistical average, so that average rate of AAL2 connectionsallocated on the Iub, is less than the sum of all AAL2 connection’s peakrate.



Traffic overbooking is done by setting RNC specific activity factors of Iubtransport bearers lower than default value. The activity factor is defined asthe relation between average cell rate and peak cell rate of an AAL2connection. Average cell rate and peak cell rate are part of the transportbearer specific AAL2 Link characteristics (ALC). ALC parameters are usedby AAL2 CAC, when estimating whether an AAL2 connection can beestablished on VCC or not.

Tuning the activity factors is recommended to be done by the operator,based on the information of the actual activity of the bearers. In case theactual activity exceeds the configured activity factor, there is a risk of trafficloss on Iub and consequently, the performance of the system as a whole isdegraded.

The right activity factor, which suits all cases, is difficult to determinebecause activity depends on the traffic mix in the network. The activity of asingle bearer depends on e.g. the service used. If bearer is used fordownloading on FTP, the activity is considerable higher when compared toe.g. web browsing. With FTP service the activity can be close to 1 whenwith web browsing it can be 20%. Usually the higher the peak rate of theconnection is the lower is the activity. If correct activity factor can’t bedetermined reliably it is recommended that the activity factors are reducedgradually and the effects on traffic quality are monitored usingperformance counters.

Risk related to traffic loss can be reduced by utilising this feature withRAN759: Path Selection and RAN1100: Dynamic Scheduling for NRTDCH with Path Selection.

The operator is able to follow through new and old counters the RNC AAL2scheduling performance, dropped AAL2 packets, amount of allocatedAAL2 connections to the system and throughput of PS (RLC AM)connections. The counters are found in the related transport measurementdocuments.

Transport Bearer Tuning feature is compliant with ITU-T specificationQ.2630.x ALCAP signalling [1] that is used to carry ALC parameters to theBTS/AXC CAC.


Activity factor tuning allows more efficient transport resource usage andthus it decreases operator’s costs. Reducing activity factor allows moreDCH, DCCH signalling and common channel connections on the Iub.

DN70296245Issue 1-5 en13/06/2008





Transport Bearer Tuning activation requires RNC specific license. If thelicense is acquired, BTS specific Overbooking Switch is on as a default.This means that operator configured activity factors are used for all BTSsunder the RNC.

The operator can verify the feature by monitoring reserved transportcapacity of AAL2 connection.

Fore more information, see Activating Transport Bearer Tuning in FeatureRAN1096: Transport Bearer Tuning, Feature Activation Manual.

2.7.3 System impact


Currently activity factor is not available in the user interface but insteadpredefined values are used. An activity factor of 60% is assumed for voicebearers and an activity factor of 100% for NRT data bearers. For signallingradio bearers (SRBs) three predefined Af sets has been defined fromRAN04 onwards. The activity factor set of SRBs is operator selectable.

RAN1096: Transport Bearer Tuning is implemented in RAS06.




RAN1096: Transport Bearer Tuning is not dependent on any other feature.However, there are other features in RAS06 that enhance usability ofRAN1096: Transport Bearer Tuning. These features are:

. RAN759: Path Selection


RAN1096: Transport Bearer Tuning can also be used with all VCCs, alsowith SHARED and DCH VCCs because the NRT DCH traffic has differentAAL2 priority (different AAL2 queue in RNC) than RT DCH and CCCHsand thus increased AAL2 delay does not affect other traffic. However, it ishighly recommended that RAN1096: Transport Bearer Tuning is used with



the RAN759: Path Selection feature because it allows to dedicate an ownVCC for delay tolerant DCH traffic. Using own dedicated VCC for NRTDCH traffic allows much heavier overbooking for NRT DCH traffic forseveral reasons.

First, RAN1100: Dynamic Scheduling for NRT DCH with Path Selectioncan be used only with dedicated VCC which enables RNC internal flowcontrol for NRT DCH bearers to prevent AAL2 queue over flows in case ofheavy congestion. Second, the AAL2 queue is longer in dedicated VCCthus decreasing the probability for queue over flow. Third, when dedicatedVCC is used also the ToAW is enlarged to handle the increased AAL2delay. Larger ToAW decreases the probability of Transport ChannelSynchronization procedure to take place thus increasing the throughputdue to less of RLC retransmissions

Optimized Iub AAL2 Reservation for SRBs in RAN04 introduced defaultactivity factor sets for SRB bearers. When RAN1096: Transport BearerTuning is used, operator can define used activity factors for SRBs freely,so operator is not tied to Optimized Iub AAL2 Reservation default valuesanymore. The RAN1096: Transport Bearer Tuning default parameters forSRBs are, however, the same as a default set in feature Optimized IubAAL2 Reservation for SRBs.

For more information see Transport overview in RAS06 and RAS05.1Transport Overview.

Transport bearer tuning and Optimized Iub AAL2 reservations forCommon Channels

If AFs for common DL transport channels are tuned the used physicalchannel (SCCPCH) configuration should be taken into account. There canbe one to three common channels in one SCCPCH if RAN2.0094:Optimized Iub AAL2 reservations for Common Channels is used.

If a common channel is in a dedicated SCCPCH the common channel’s AFaffects the AAL2 bandwidth reservation as any other AF If severalcommon channels use same SCCPCH the AAL2 resources are reservedbased on the largest channel.

For example, if all common channels are using same SCCPCH modifyingthe AFs of FACH-C or PCH don’t have any effect on the AAL2 reservation.

The following table shows the relation of SCCPCH configuration and theactivity factor used for the reservation.

DN70296245Issue 1-5 en13/06/2008



Table 17. AF and SCCPCH relationship

Parameter Definition 1 SCCPCH 2 SCCPCH 3 SCCPCH

AfPCHDL This parameterdefines the activityfactor for PCH DLbearer.

Not used AF USED AF USED

AfFACHSDL This parameterdefines the activityfactor for FACH-S DLbearer.

Not used Not used *)

AfFACHUDL This parameterdefines the activityfactor for FACH-U DLbearer.

AF USED AF USED AF USED

AfFACHCIDL This parameterdefines the activityfactor for FACH-C/IDL bearer.

Not used Not used *)

AfFACHCCDL This parameterdefines the activityfactor for FACH-C/CDL bearer.

Not used Not used Not used

*) If an SCCPCH is configured for FACH-C/I and FACH-S to affect thetransport reservation size both of the AFs should be modified becausethey have identical ALC parameters.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 - OSS4.2 - - - -










NMS interfaces


No effects.


No effects.


The operator can configure via NetAct or via RNC RNW Object BrowserGUI, the new RNC object parameters. For information on operatorconfigurable parameters, see Management data.


No effects.


No effects.


This feature introduces some new counters . By using the new andexisting measurements the operator can follow functionality of RAN1096:Transport Bearer Tuning. Performance monitoring areas that are useful tofollow are:

. Amount of succeeded transport resource request for DCHconnections

. AAL2 scheduling delay and amount of AAL2 packets in AAL2 buffers

. Amount of AAL2 packet drop events

. Throughput of RLC AM connections

For more information on counters, see RNC counters - Transport and HWpart and RNC counters – RNW part.

DN70296245Issue 1-5 en13/06/2008



Amount of succeeded transport resource request for DCH connections:

The following counters enable the operator to follow the effects ofRAN1096: Transport Bearer Tuning on the amounts of allocation AAL2connections:

. SUM_RESERVED_CELL_RATE

. MIN_RESERVED_CELL_RATE

. MAX_RESERVED_CELL_RATE

. SUM_AAL2_CONNECTIONS

. MIN_AAL2_CONNECTIONS

. MAX_AAL2_CONNECTIONS

AAL2 scheduling delay and amount of AAL2 packets in AAL2 buffers:

The following counters enable the operator to follow how much RAN1096:Transport Bearer Tuning causes AAL2 delay and how many packets arequeued in AAL2 buffers.

. BE_QUE_PEAK

. BE_QUE_SUM

. BE_QUE_SAMPLES

. BE_QUE_DELAY_PEAK

. BE_QUE_DELAY_SUM

. BE_QUE_DELAY_SAMPLES

Amount of lost AAL2 packets in IPA2800 platform:

The following counter enables the operator to follow the amount of AAL2packet drop events:

. BE_QUE_DRP_EVENTS

Throughput of PS (RLC AM) connections:

The following measurement enables the operator to follow the throughputof RLC AM connections on RLC layer. This kind of information helps toadjust Af correctly.

. RCPM RLC (includes multiple counters)




No effects.


No effects

Management data

Parameters:

The RAN1096: Transport Bearer Tuning feature enables the operator toadjust an activity factor for all traffic types and for all speeds that are usedin the Nokia transport solution. The following table lists the parameterstructures that contain individual Activity Factor parameters. Theseparameters, and additional information, can be found in ParameterDictionary Database.

Activity factor parameters can be set separately in DL and UL direction.Parameters can be set online and a new parameter value is taken into usewhen new AAL2 connection is setup.

Af for a specific speed that is stored in PDDB is applicable to all differentTTI and CPS packet size combinations of that speed.

Table 18. RAN1096: Transport Bearer Tuning impact on parameters

Parameter Use

Activity factor for NRT DCH traffic bearers This parameter structure defines Activity Factors forNRT DCH traffic types

Activity factor for CS DCH traffic bearers This parameter structure defines Activity Factors forCS DCH traffic types

Activity factor for AMR DCH traffic bearers This parameter structure defines Activity Factors forCS DCH traffic types

Activity factor for RT PS traffic bearers This parameter structure defines Activity Factors forRT PS traffic types

Activity factor for DCCH traffic bearers This parameter structure defines Activity Factors forDCCH traffic types

Activity factor for FACH and RACH traffic bearers This parameter structure defines Activity Factors forFACH and RACH traffic types

Activity factor for PCH traffic bearers This parameter structure defines Activity Factors forPCH traffic types

Overbooking Switch

DN70296245Issue 1-5 en13/06/2008



Table 18. RAN1096: Transport Bearer Tuning impact on parameters (cont.)

Parameter Use

This parameter defines BTS specifically, whetherdefault Activity Factor or RNW database ActivityFactor is used to calculate ALC parameters for RAB



Activity factor for AMR DCH trafficbearers

Activity factor for 12.2 / 12.65 AMRDCH DL bearer

Activity factor for 12.2 / 12.65 AMRDCH UL bearer

Activity factor for 5.9 AMR DCH DLbearer

Activity factor for 5.9 AMR DCH ULbearer

Activity factor for CS DCH trafficbearers

Activity factor for 14.4 CSstreaming DL bearer

Activity factor for 14.4 CSstreaming UL bearer

Activity factor for 57.6 CSstreaming DL bearer

Activity factor for 57.6 CSstreaming UL bearer

Activity factor for 64 CSconversational DL bearer

Activity factor for 64 CSconversational UL bearer

Activity factor for DCCH trafficbearers

Activity factor for 12.8/13.6 DCCHDL bearer

Activity factor for 12.8/13.6 DCCHUL bearer

Activity factor for 1.6/1.7 DCCH DLbearer





Activity factor for 1.6/1.7 DCCH ULbearer

Activity factor for 3.2/3.4 DCCH DLbearer

Activity factor for 3.2/3.4 DCCH ULbearer

Activity factor for FACH and RACHtraffic bearers

Activity factor for FACH-C/C DLbearer

Activity factor for FACH-C/I DLbearer

Activity factor for FACH control ULbearer

Activity factor for FACH-S DLbearer

Activity factor for FACH-U DLbearer

Activity factor for RACH 20.8 ULbearer

Activity factor for RACH control DLbearer

Activity factor for NRT DCH trafficbearers

Activity factor for 128 NRT DCH DLbearer

Activity factor for 128 NRT DCH ULbearer









DN70296245Issue 1-5 en13/06/2008








Activity factor for PCH trafficbearers

Activity factor for PCH control ULbearer

Activity factor for PCH DL bearer

Activity factor for RT PS trafficbearers

Activity factor for 128 RT PS AMDL bearer

Activity factor for 128 RT PS AMUL bearer

Activity factor for 128 RT PS UMDL bearer

Activity factor for 128 RT PS UMUL bearer

Activity factor for 16 RT PS AM DLbearer

Activity factor for 16 RT PS AM ULbearer

Activity factor for 16 RT PS UM DLbearer

Activity factor for 16 RT PS UM ULbearer

Activity factor for 256 RT PS AMDL bearer

Activity factor for 256 RT PS UMDL bearer
















Overbooking Switch

Signalling



Transport Bearer Tuning affects transport performance and capacityrequirements. This is due to that RAN1096:Transport Bearer Tuning allowsoperator to adjust the activity factors of AAL2 connections and hence moreAAL2 connections fits into the system. Af parameter modification affectsonly new AAL2 connections, so an old (existing) AAL2 connections are notmodified according to the new AAL2 reservation size.

Setting the activity factors too low, additional delay and packet losses canoccur in the system. In the worst case situation (heavy Iub congestion) itcould be possible that some calls are dropped.

For more information, see Dimensioning WCDMA RAN.



DN70296245Issue 1-5 en13/06/2008




RAN1096: Transport Bearer Tuning can be used only on the Iub interface.Over Iur and IuCS default activity factors are used.

2.8 RAN1095: UBR+ for Iub User Plane

2.8.1 Introduction

This feature belongs to Transmission and Transport feature group and it isan optional feature.

The ATM Forum has specified several ATM service categories to providedifferentiated quality of service for user traffic. An ATM service categoryconsiders both, the traffic characteristics and the quality of service.

. Constant Bit Rate (CBR)

. Real-time Variable Bit Rate (rt-VBR)

. Non real-time Variable Bit Rate (nrt-VBR)

. Available Bit Rate (ABR)

. Unspecified Bit Rate (UBR)

The UBR service category provides best effort service without anythroughput guarantee. UBR has the least priority compared with the otherATM service categories.

Therefore, the ATM Forum has specified an optional traffic parameter asan extension of the UBR ATM service category denoted as MinimumDesired Cell Rate (MDCR). A UBR implementation that supports theMDCR parameter is commonly called UBR+. An UBR+ (Virtual Channel orVirtual Path) connection is defined by its Minimum Desired Cell Rate(MDCR) and Peak Cell Rate (PCR).

The ATM Connection Admission Control reserves the MDCR for eachUBR+ connection (and the PCR for CBR connections) in order toguarantee the throughput, so that the network elements do not allow thesum of the guaranteed bandwidth of the ATM connections to exceed theATM interface bandwidth.

Under high traffic load condition an UBR+ connection supplies the usertraffic with a throughput of at least the MDCR.



The UBR+ connections compete among each other for the bandwidth leftfrom other ATM connections with higher priorities if it exceeds their MDCR.The UBR+ connections share this bandwidth equally among each other bydefault. However, the Nokia UBR+ implementation provides the networkoperator an additional configuration parameter called UBRshare to favourindividual connections. How much bandwidth an UBR+ connection will getabove its MDCR depends on the current traffic conditions and theproportion of its individual UBRshare to the sum of UBRshare of all UBR+connections on the same ATM interface.

If the sum of all the guaranteed bandwidth is equal to the ATM interfacebandwidth then the UBRshare parameter does not have any impact on thetraffic scheduling (RNC and UltraSite). In this case the bandwidth left overfrom the other ATM connections is shared proportional to the fraction of itsMDCR to the sum of MDCRs of all UBR+ connections. Flexi WCDMA BTSdoes not have this limitation for traffic scheduling.

The RT VBR and NRT VBR service categories are often considered bestfor variable user traffic bit rates especially for bursty traffic. VBR servicecategory is characterized by the traffic parameters PCR, Sustainable CellRate (SCR) and Maximum Burst Size (MBS).VBR provides quality ofservice with respect to delay or ATM cell loss ratio.

While UBR+ may transfer user traffic up to the PCR for a long time period(if the traffic load conditions allow), VBR service category transfers usertraffic at the PCR only for a short time period (expressed by the MBS),however in average the maximum service rate is equal to the SCR and it isnot allowed to exceed the SCR in order not to harm the Quality of Servicerequirements of other CBR and VBR connections. On the other hand, theVBR service category makes sure that a burst is sent at PCR until MBS istransferred while UBR+ cannot give this guarantee. The ATM ConnectionAdmission Control typically reserves at least the SCR for VBRconnections.


UBR+ allows the efficient usage of the Iub capacity because:

. UBR+ connections share the available bandwidth,

. UBR+ service category does not limit the traffic on individualconnections,

. the UBRshare parameter allows to set priorities among the UBR+connections.

DN70296245Issue 1-5 en13/06/2008



On the other hand, the application using UBR+ is itself responsible for anyQuality of Service requirement because UBR+ does not give anyguarantees for delay or cell loss ratio. UBR+ only gives a throughputguarantee.

Therefore the AAL2 Connection Admission Control checks the bandwidthrequirements of AAL2 connections. There are two modes for the AAL2Connection Admission Control:

. VCC mode

. VCC bundle mode

In the VCC mode the upper bandwidth limit is given by the guaranteedrates of the individual VCCs, namely PCR for CBR and MDCR for UBR+ATM service category. Thus setting the MDCR to 0 or some other smallvalue when used with NRT DCH traffic is not in most cases a good ideadue to AAL2 CAC restriction. For HSPA traffic, setting the MDCR is notthat critical because the HSPA traffic is best effort in nature and nobandwidth is reserved for individual connections.

In the VCC mode the UBR+ is mainly useful for HSPA in connection withRAN1099: Dynamic scheduling of HSDPA with Path Selection.

In the VCC bundle mode the upper bandwidth limit for the AAL2 CAC isdetermined by a VCC bundle rate and the check is done across more thanone ATM VCC. The VCC bundle mode is included in the feature RAN1100:Dynamic Scheduling for NRT DCH with Path Selection.

The modes for the AAL2 CAC shall be equal in BTS and RNC, while RNCautonomously applies the VCC bundle mode for the AAL2 CAC, theoperator must enable it explicitly in the BTS.

UBR+ for Iub user plane complements other features as described inInterdependencies between features.


UBR+ for Iub user plane is a network wide feature and has to be enabledvia according license keys in Flexi WCDMA BTS and AXC. If the license ispresent then the AXC and Flexi WCDMA BTS require an explicitconfirmation to take UBR+ into use.

More information on configuring the network elements will be provided byrelevant network element specific documents.



For more information on feature activation, see Activating UBR+ for IubUser Plane in Feature RAN1095: UBR+ for Iub User Plane, FeatureActivation Manual.

2.8.3 System impact


The previous RAN releases support the UBR ATM service category onlyfor O&M traffic. MDCR is not supported.

The CBR ATM service category is applied for all other traffic; user planeand control plane.




RAN759: Path Selection

The UBR+ service category complements RAN759:Path Selection.RAN759: Path Selection provides the means for traffic differentiation bydifferent AAL2 path types: stringent, bi-level stringent and tolerant.

In connection with RAN759: Path Selection, it is recommended to use aUBR+ VCC as bi-level stringent path for NRT-DCH traffic, and anotherUBR+ VCC as tolerant path for HSPA traffic. Further, it is recommended touse a CBR VCC as stringent path for real-time traffic in order to maintainthe QoS.

Since NRT traffic carried over the DCH tolerates less transfer delay thanHSPA in the Iub interface, the UBR+ parameters need to be setaccordingly:

. MDCR value for NRT-DCH UBR+ VCC shall be set high enough forthe guaranteed throughput.

. UBRshare value for NRT-DCH shall be set higher to get a higherpriority over HSDPA.

The AAL2 CAC for bi-level stringent path reserves a little bit morebandwidth than the specified average rate of an AAL2 connection, whilethe AAL2 CAC for tolerant path does not reserve any bandwidth for anAAL2 connection.

DN70296245Issue 1-5 en13/06/2008



Such Path Selection allows the efficient usage of UBR+ for HSPA traffic.Feature RAN1096 Transport Bearer Tuning is recommended in connectionwith NRT DCH to be used in connection with UBR+, because the activityfactor of NRT DCH is by default 1 and the AAL2 CAC will limit the NRTDCH traffic to the MDCR. This should be noted when UBR+ is used withNRT DCH traffic.

It is also worth noting, that the Uplink HSDPA control channel isestablished in the NRT-DCH VCC.

RAN1099: Dynamic scheduling for HSDPA with Path Selection andRAN1100: Dynamic scheduling for NRT DCH with Path Selection

The dynamic scheduling mechanism for HSDPA provides an RNC internalflow control mechanisms to proactively react on traffic congestion insideRNC and a traffic rate shaping mechanism in the Iub interface to preventATM cell losses in capacity bottlenecks in the ATM network. Normally, thelast mile link to the node B will be the capacity bottleneck. With this featureRNC schedules Rel.99 traffic and HSDPA together such that Rel.99 traffichas a high priority and HSDPA traffic is filled up to the VCC bundle rate ifthe Rel.99 traffic leaves bandwidth. UBR+ provides here the requiredflexibility for HSDPA, but UBR+ has not any quality of service guarantee i.e. to adjust the traffic load in case of congestion.

RAN1100: Dynamic scheduling for NRT DCH with Path Selection

RAN1100: Dynamic scheduling for NRT DCH with Path Selection providesthe operator to combine the capacity of ATM VCCs going to one Node B,such that the NRT-DCH can make use of leftover (i.e. not reserved)bandwidth of CBR VCC. RNC applies the VCC bundle mode for the AAL2CAC implicitly while the operator must enable the VCC bundle mode forthe AAL2 CAC explicitly in the BTS.

RAN1096: Transport Bearer Tuning

RAN1096 Transport Bearer Tuning allows the operator to configure theactivity factors of Iub transport bearers. The smaller the activity factor of atransport bearer is the better is the UBR+ service category capabilitiesused.

RAN1096 Transport Bearer Tuning is especially useful for NRT DCH trafficto use leftover bandwidth of CBR VCC in uplink in connection with featureRAN1100: Dynamic scheduling for NRT DCH with Path Selection.


RAS RNC AXC MSC SGSN MGW UE



RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


BTSUltra

BTSFlexi

BTSPico

NetAct

Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 C3.0 OSS4.2 - - - -




ASW RAN FTM LK Long-term ON/OFFlicence




NMS interfaces

Impact on planning tool (Planner):

The dimensioning of the UBR+ parameters depends on the expected end-user traffic profile of the BTS location and on the combination of RANfeatures. The MDCR and UBRshare should be aligned accordingly.

In case RAN1100 Dynamic Scheduling for NRT DCH with Path Selectionis not used, the VCC mode of AAL2 CAC is used then the generalrecommendation is to set the values of the MDCR and UBRshare for NRTDCH greater than for HSPA. It is not recommended to use UBR+ for RTDCH but it is not prohibited either. If an operator uses UBR+ also for RTDCH then the corresponding UBR+ connection shall have the greatestUBRshare value.

If the UBRshare is used to differentiate traffic, then the ATM configurationshould not reserve all the ATM interface capacity in Ultrasite/AXC andRNC, because of some internal HW constraints of the ATM scheduler.FlexiBTS does not have this HW constraint.

In case RAN1100 Dynamic Scheduling for NRT DCH with Path Selectionis used then the VCC bundle mode for AAL2 CAC shall be enabled in theBTS. It is recommended to set:

DN70296245Issue 1-5 en13/06/2008



. the MDCR parameter of the NRT-DCH UBR+ VCC to 0,

. and the UBRshare parameter of the NRT VCC to a much greatervalue than the UBRshare parameter of the HSPA VCC.

Note, the VCC bundle mode for AAL2 CAC in the BTS is only applicable toleaf nodes.

UBR+ does not give any quality of service guarantee and also no servicerate guarantee for rates greater than MDCR. If ATM traffic load countersindicate significant ATM cell losses then a bandwidth bottleneck is verylikely. The end-user quality of service may also suffer in such a case.

The following actions may help to remove the bottleneck:

. Increase MDCR for individual services

. Increase transmission bandwidth

. Re-planning of the network topology

. Increase activity factor of NRT DCH


UBR+ introduces new configuration parameters.

Impact on reporting tools (Reporter):

There are no new feature-specific counters or Key Performance Indicators.ATM interface are able to provide counters per service categories: CBRand UBR/UBR+.


See Nokia WCDMA RNC Product Documentation for more information.

Management data

Files

Table 19. UBR+ for Iub user plane impacts

File Impact

AML New configuration parameters

FML New configuration parameters



AML belongs to the site configuration files for AXC/Ultrasite WCDMA BTS.FML belongs to site configuration files of Flexi WCDMA BTS. NetworkManagement tools such as RAC online provides those site configurationfiles.

Parameters

Table 20. UBR+ for Iub user plane impact on parameters

File Impact

PCR Defines the maximum ATM cell rate for a UBR+connection.

MDCR For the reservation to get a minimum ATM cellthroughput for a UBR+ connection.

UBRshare Determines the weight among UBR+ connections.

Traffic description user label (in UltraSite WCDMA BTSand Flexi WCDMA BTS)

String “VCC_BUNDLE” in the traffic descriptor userlabel to activate the VCC bundle mode for AAL2 CACin the BTS for UL. This string is case sensitive! Thefeature is disabled if the string is deleted or ismisspelled.

The additional management data of this feature is listed in the followingtable.



IN_REC_CELLS_VP

IN_QUEUED_CELLS_VP

EG_REC_CELLS_VP

EG_QUEUED_CELLS_VP

IN_REC_CELLS_VC

IN_QUEUED_CELLS_VC

EG_REC_CELLS_VC

EG_QUEUED_CELLS_VC

IN_CBR_REC_CELL

IN_CBR_TRANS_CELL

IN_CBR_QUEUED_CELL

EG_CBR_REC_CELL

EG_CBR_TR_CELL

EG_CBR_QUEUED_CELL

IN_UBR_PLUS_REC_CELL


DN70296245Issue 1-5 en13/06/2008




IN_UBR_PLUS_TR_CELL

IN_UBR_PLUS_QUEUED_CELL

EG_UBR_PLUS_REC_CELL

EG_UBR_PLUS_TRANS_CELL

EG_UBR_PLUS_QUEUED_CELL

IN_UBR_REC_CELL

IN_UBR_TR_CELL

IN_UBR_QUEUED_CELL

EG_UBR_REC_CELL

EG_UBR_TR_CELL

EG_UBR_QUEUED_CELL

IN_TOT_REC_CELL

IN_TOT_TR_CELL

IN_TOT_QUEUED_CELL

EG_TOT_REC_CELL

EG_TOT_TR_CELL

EG_TOT_QUEUED_CELL

IN_CAP

EG_CAP

DISC_HEC

ERR_HEC

Signalling



UBR+ provides a more flexible usage of the available bandwidthcompared to CBR.




UBR+ is only available in the Iub interface.

RNC does not support UBR+ for Virtual Path.



The VCC bundle mode for AAL2 CAC is only applicable if UltraSiteWCDMA BTS is a leaf node and in connection with BTS AAL2multiplexing.

2.9 RAN1319: Flexi WCDMA BTS IMA Based AAL2Uplink CAC

2.9.1 Introduction

Available capacity for Flexi WCDMA BTS AAL2 uplink AAL2 admissioncontrol is modified in case of a link failure in a terminating IMA group.


In case of a E1/T1 link failure in an IMA group, admission control limitstraffic to the value corresponding to the number of operational links in anIMA group. This results in a high quality of service for the admittedconnections, even in case of a link failure.


When an individual E1/T1 connection in an IMA group fails, Flexi WCDMABTS notices this through a physical layer alarm (Loss of signal), andassociates this with a particular IMA link. IMA group will reconfigure itselfto a lower number of links available.

Consequently, Flexi WCDMA BTS modifies the capacity available to equalthe number of links available in the IMA group

New calls are now admitted only up to the actual capacity available.

When the link is corrected, or when the user adds a new link to the group,the IMA group reconfigures to the full number of links, and the CAC willresume full capacity.

DN70296245Issue 1-5 en13/06/2008



Figure 12. Flexi WCDMA BTS IMA Based AAL2 Uplink CAC

2.9.3 System impact


In the current release, Flexi WCDMA BTS Uplink Admission controlavailable capacity is not modified by IMA link failures.




This feature has no related or interworking features.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 - - WBTS4.0

- - - - - - -




OSW RAN - -

BTS RNCIMA n*E1/T1

IMA transmission link




Management data




2.10 RAN1063: Hybrid Backhaul with Pseudo Wires

2.10.1 Introduction

RAN1063:Hybrid Backhaul with Pseudo Wires allows backhauling theBTS over packet-switched technologies, IP and Ethernet in particular.Operators can select from the full variety of IP and Ethernet services,ranging from low-cost to premium quality offerings. In the first case onlyHSPA traffic is offloaded to the packet-switched network; an existing path,based on ATM over TDM technologies, is used for all other traffic. In thelatter case all traffic can be conveyed over the packet-switched network.

This is not a sellable item and not a feature on its own rights, but a solution,which consists of several individual features.

Ethernet L2 networks and IP L3 networks can be supported.

The feature comprises two operating modes:

. Hybrid Pseudo Wire Backhaul

. Full Pseudo Wire Backhaul

The Hybrid Pseudo Wire Backhaul operating mode is based on theRAN05.1 RAN1020: Route Selection feature or the RAS06 RAN759: PathSelection feature. They are needed in order to separate the HSPA trafficfrom the R99 traffic. In this way it is possible to route the traffic overdifferent interfaces and via a gateway even over a packet network.

DN70296245Issue 1-5 en13/06/2008



In the Full Pseudo Wire Backhaul operating mode, all the Iub traffic iscarried over the packet-switched network, when a high quality connectionis available, avoiding the need for two transport networks. The RAN05.1RAN1020: Route Selection feature or the RAS06 RAN759: Path Selectionfeature is also needed in order to provide different Quality of Service toeach of the traffic types.

The backhauling over the packet-switched network is based on theemulation of the ATM service according to the PWE3 standard of IETF.The supported encapsulation is ATM/MPLS/IP/Ethernet. The Pseudo Wireextends between two PWE3 gateways, one inside the BTS and anotherstand-alone in the RNC site. The BTS gateway provides a Fast Ethernet orGigabit Ethernet interface towards the network. On the RNC site thecorresponding gateway provides STM-1 interfaces towards the RNC and aGigabit Ethernet interface towards the network.

Stand-alone gateways are supplied by a Nokia partner and can bepurchased as an integral part of the solution. Integrated BTS gateways areNokia Siemens Networks' own development (IFUH for AXC, and FTIA/FTJA for FTM and the application software).

VCCV-BFD is supported for Pseudo Wire OAM. It provides a light weightmechanism which enables to monitor the continuity of the service over theEthernet connection based on the periodic transmission of control packets.When the control packets are not received within a period of time, an alarmis raised in the BTS, and for stand-alone gateways, the alarm is raised inthe stand-alone gateway management system.


Ethernet is introduced as a BTS backhaul technology. Compared totraditional ATM over TDM technologies Ethernet can substantially reducetransport OPEX. To let operators select from the full variety of IP andEthernet services RAN1063: Hybrid Backhaul with Pseudo Wires supportsboth of the following applications:

. All traffic is conveyed over a packet-switched network. The QoSrequirements are set by the most sensitive traffic type (voice).Suitable services are predominantly available in metropolitan areas(Metro Ethernet), where data traffic is also highest.

. HSPA traffic is offloaded to a packet-switched network, while allother traffic remains to be conveyed over TDM. HSPA traffic is lesssensitive to delay and delay variation, and the QoS requirements tothe packet-switched network can be relaxed accordingly.




RAN1063: Hybrid Backhaul with Pseudo Wires is based on Iub ATMservice emulation over a packet-switched network. The emulation isperformed in accordance with the PWE3 (Pseudo Wire Emulation Edge toEdge) specification of IETF, meaning that ATM cells are encapsulated andtunnelled through the packet-switched network.

Architecture

According to Pseudo Wire Emulation Edge to Edge Architecture, the ATMservice emulation should offer a service equivalent to the native service.

For the Customer Edge 1 to Customer Edge 2 direction, native ATM trafficfrom the Customer Edge 1 is received at the ingress port at Provider Edge1. Provider Edge 1 encapsulates the traffic over PSN frames, and forwardsthe frames to Provider Edge 3 across PSN tunnels. Provider Edge 2 de-encapsulates the traffic and forwards it as native ATM traffic to CustomerEdge 2. For the Customer Edge 2 to Customer Edge 1 direction it operatesin the same way.

The following figure depicts the ATM service emulation architecture.

Figure 13. ATM service emulation architecture

In RAN1063: Hybrid Backhaul with Pseudo Wires, the RNC and the BTSshall be an instance of the Customer Edge. The RNC PWE3 gateway shallbe an instance of the Provider Edge.

IP tunnels are established across the packet-switched network betweenthe RNC site and each of the BTS. Each tunnel is identified by the IPaddresses of the end points.

CustomerEdge 1

ProviderEdge 1

ProviderEdge 2

CustomerEdge 2

nativeservice

PW 1

PW n

tunnel

PSNnativeservice

CE1 PE1 CE2PE2

Pseudo wire

Emulated Service

DN70296245Issue 1-5 en13/06/2008



Inside each tunnel, a variable number of Pseudo Wires are created inorder to carry the emulated service.

Tunnels and Pseudo Wires are statically created using managementprocedures since LDP is not supported.

The following figure depicts an example of the tunnel topology.

Figure 14. Example of tunnel topology

In a properly engineered network, the encapsulation and tunnelling do notaffect the service offered to the Radio Network Layer, which is completelyunaware of the emulation.

This feature supports two modes of operation:

. Hybrid Pseudo Wire Backhaul

. Full Pseudo Wire Backhaul

In the Hybrid Pseudo Wire Backhaul mode there are two paths betweenthe RNC and the BTS. One of the paths is based on traditional TDMtechnology, which is used to carry delay sensitive traffic and clockreference. The other path is over the packet-switched network using ATMservice emulation over Pseudo Wire which is used to carry HSDPA/HSUPA traffic. One sample configuration for this operation mode isdepicted in the following figure.

BTS

BTS

RNCIP/EthernetNetwork

IP AddressIP Address

IP Address

PWs

PWs

PSN tunnel

PWE3Gateway



Figure 15. Hybrid Pseudo Wire Backhaul mode

In the Full Pseudo Wire Backhaul mode only path over the packet-switched network is provisioned, which carries all the traffic between theRNC and the BTS. One sample configuration for this operation mode isdepicted in the following figure.

AAL2CID’s

AAL2CID’s

AAL2CID’s

AAL2CID’s

RT

NRT

O&MUBR + VCC

CBR VCC’s

UBR VCC’s

CBR VCC’s

O&M

RT

NRT

RNC

Tunnel

PHY

HSDPA

HSUPA

1 unshaped CBR VPC per Node B

Optional VCC bundle

nxE1

ATM port rate limiting

PHY

HSDPA

HSUPA

UBR VCC

CBR VCC’s

UBR + VCC’s

CBR VCC’s

PHY

Clock referenceClock recovery

ControlPlane

UBR +VCC’s

UBR +VCC’s CBR

VPC

PWE3Gateway

Ethernet port ratelimiting

Node BTransmission

CBRVPC


TDMNetwork

ATMSwitch

PWE3Gateway

nx-STM1

nx-STM1

UBR +VCC’s

CBRVPC

UBR +VCC’s

ControlPlane

CBRVPC

DN70296245Issue 1-5 en13/06/2008



Figure 16. Full Pseudo Wire Backhaul mode

In case the BTS is not connected to a TDM network, synchronization hasto be provided through other means, for example, a 2MHz signal fed froma neighbouring GSM/EDGE BTS or a GPS receiver.

There are two possible configurations for the BTS site:

. Integrated

. Stand-alone

In the integrated configuration the BTS is equipped with Ethernet and TDMinterfaces. The Pseudo Wire termination function is carried out by the BTS.The following figure depicts this configuration (Hybrid PW Backhaul modeshown).

PWE3Gate-way

CBRVPC

PHY

CBRVPC

ControlPlane

O&M

RT

NRTUBR + VCC

CBR VCC’s

PHY

CBR VCC’s

CBR VCC’s

CBRVPC

HSDPA

HSUPAPHYUBR + VCC’s

UBR + VCC’s

UBR + VCC

CBR VCC’s

UBR VCC CBRVPC

CBRVPC

PWE3Gate-way

ControlPlane

O&M

RT

NRT

HSDPA

HSUPA

CBR VCC’s

UBR + VCC’s

UBR + VCC’s


Tunnel

Clockreference(GPS, 2G,TDM, etc)

Node BTransmission RNC

Unshaped

VPC’s for other Node B’s

ATM port rate shaping

Ethernet port rate limiting

Optional VCC bundle

Shaped

nx-STM1



Figure 17. BTS Pseudo Wire terminating function (Ethernet and TDMinterfaces)

For trial purposes, a stand-alone configuration is supported, where there isan external gateway in the BTS site that terminates the Pseudo Wire. Theconnection between the gateway and the BTS is based on E1/T1/JT1. Thefollowing figure depicts this configuration (Hybrid PW Backhaul modeshown):

Figure 18. BTS Pseudo Wire terminating function (E1/T1/JT1)

TDMI/F

ATM TDMI/F

TunnelEthernetI/F


ATM

TDMI/F

TDMNetwork

BTS

ATMtermination

nxSTM1

RNC

ATMtermination

PWE3Gateway

PWE3Gateway

TunnelEthernetI/F


TDMI/F

TDMNetwork

BTS

ATMtermination

nxSTM1

RNC

ATMtermination

PWE3Gateway

TDMI/F

TDMI/F

TDMI/F

ATM

ATM

PWE3Gateway

DN70296245Issue 1-5 en13/06/2008



Quality of Service

In order to ensure that the different types of traffic receive appropriatequality of service, this feature implements Differentiated Services. Thefollowing mechanisms are provided:

. Traffic Management

The PWE3 gateways provide Pseudo Wire traffic prioritisation.

For the BTS solution, prioritization is based on the ATM serviceclass.

. Traffic Shaping

The Pseudo Wire traffic towards the packet-switched network isshaped in order to conform to the network SLA.

. Traffic Marking

For L3 networks, IP packets are marked with a configurable DSCPvalue. The DSCP is freely defined for each Pseudo Wire.

For L2 networks, Ethernet frames carry a VLAN tag withconfigurable priority bits. The priority bits are freely defined for eachPseudo Wire.


This feature does not require activation. However, it is required to activatethe features supporting RAN1063: Hybrid Backhaul with Pseudo Wires.See the documentation of the supporting features for further details.

PSN Fault Management

Usually PSNs do not support any end-to-end OAM functions.

The solution for RAN1063: Hybrid Backhaul with Pseudo Wires is basedon VCCV-BFD, which monitors the status of the Pseudo Wire. It isaccording to the IETF standards. It performs the continuity check of eachindividual Pseudo Wire, and if a failure is detected, it is reported by thePWE3 gateways to the management system.

VCCV-BFD control packets are sent over an associated control channel,which share the Pseudo Wire with the data traffic. The separation of thecontrol channel from the data traffic is done by using a Pseudo Wireassociated channel header instead of the control word. The format isdepicted in the following figure.



Figure 19. Format of the Pseudo Wire associated channel header

For RAS06, the values used are depicted in the following figure.

Figure 20. RAS06 settings for Pseudo Wire associated channel header

In order to enable the HSDPA service protection, it is necessary to forwardthe status of the PSN to the RNC. This is accomplished by the alarmforwarding function in the RNC PWE3 gateway. The following proceduresare supported:

. On PW forward defect state entry, ATM F5 AIS is forwarded to theRNC.

. On PW forward defect state exit, ATM F5 AIS forwarding is stopped.

. On PW reverse defect state entry, ATM F5 RDI is forwarded to theRNC.

. On PW reverse defect state exit, ATM F5 RDI forwarding is stopped.

Additional PSN fault management can be performed by using Ping orTraceroute tools from the RNC PWE3 gateway towards the BTS and viceversa.

Protection

Two different protection strategies are used for RAN1063: HybridBackhaul with Pseudo Wires:

. Link protection

. HSPA service protection

0001 Version Reserved Channel Type

0 3 4 7 8 15 16 31

0001 0000 00000000 0x0007

0 3 4 7 8 15 16 31

DN70296245Issue 1-5 en13/06/2008



Link protection is based on the redundancy of the physical links. Theprotection is applied to the following links:

. - ATM link, over the TDM network, between RNC and BTS. Protection is based on the existing SDH and PDH protection

features.

. ATM link, between RNC and RNC PWE3 gateway. Protection is based on SDH MSP 1+1.

. Ethernet link between the PWE3 gateway and the packet switchednetwork. Refer to the external equipment documentation.

HSPA service protection refers to the RAN capability to change thechannel type for the HSDPA and HSUPA traffic based on the availabilitytransport resource for the packet switched network path. On detection ofthe unavailability of the PSN path (Ethernet link, ATM link, RNC PWE3gateway or internal in RNC) the RNC will switch the HSDPA and HSUPAcalls to Release 99 calls over the TDM path.



Without RAN1063: Hybrid Backhaul with Pseudo Wires, all data is carriedover ATM over TDM-based technologies.



Requirement Reason

IFUH This interface unit is needed to support Ethernet interface in AXC.

FTIA Interface unit needed to support Ethernet interface in Flexi WCDMABTS. E1/T1/JT1 interface with symmetrical line is also provided.

FTJA Interface unit needed to support Ethernet interface in Flexi WCDMABTS. E1 interface with coaxial line is also provided.

RNC PWE3 GW External equipment used to support Pseudo Wire termination at theRNC side.




In order to separate the UMTS traffic into multiple VCCs, this featurerequires one of the two following optional features:

. RAN759: Path Selection

. RAN1020: Route Selection

Additionally, the following optional feature enables a more flexibleconfiguration in the RNC allowing multiple VCCs in more than one VPC:

. RAN619: Flexible Connection of VPCs for WBTS Object in RNC

For the SW support in the BTS, the following application software featureis required:

. RAN1142: ATM over Ethernet for BTS

For the HW support in the BTS, the following hardware features are alsorequired:

. RAN1064: Ethernet+E1/T1/JT1 Interface Unit (Iub User Plane) forFlexi WCDMA BTS (for Flexi WCDMA BTS)

. RAN1097: Ethernet Interface Unit IFUH (Iub User Plane) for AXC(for UltraSite WCDMA BTS)


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 - WBTS4.0

WBTS4.0

WP2.0 C3.0 OSS4.2 - - - -




ASW RAN - -

DN70296245Issue 1-5 en13/06/2008




RAN1063: Hybrid Backhaul with Pseudo Wires is based on the emulationof Iub ATM service by encapsulating ATM cells over IP according to theIETF draft Encapsulation Methods for Transport of ATM Over MPLSNetworks and Encapsulating MPLS in IP or Generic RoutingEncapsulation.

The transport network protocol stack is depicted in the following figure.

Figure 21. Transport network protocol stack

A variable number of ATM cells belonging to a single VCC or to multipleVCCs are concatenated, according to the N to 1 encapsulation mode.

The cell encapsulation is controlled by two parameters:

. Concatenation factor

It defines the maximum number of cells which can be concatenatedin one single packet. By adjusting the concatenation factor, thesystem can ensure that the MTU of the path is not exceeded.

A high concatenation factor will lead to efficient Pseudo Wire due tothe low relative overhead. A small concatenation factor will reducethe packetisation time.

. Packetisation timer

Upperlayer

protocols

ATM ATM

Control word

PW header (MPLS)

IPv4

Ethernet-Mac

Ethernet-Phy

ATM

Control word

PW header (MPLS)

IPv4

Ethernet-Mac

Ethernet-Phy

Upperlayer

protocols

RNC

PWEgateway

BTS

Airinterface



It defines the maximum packetisation time for a packet that iscreating by encapsulating cells before it is scheduled for forwarding.A small packetisation timer will introduce little delay in thepacketisation. A large packetisation timer will ensure that packetsare large, minimizing the overhead and increasing the efficiency.

Actual packet size depends on the concatenation factor, the packetisationtimer and the load of the tributary VCCs.

After concatenation, a control word is optionally appended. If VCCV-BFDis used, the control word is required. The format of the control word isdepicted in the following figure:

Figure 22. Format of the control word

For RAS06, all the fields are set to 0.

Figure 23. RAS06 settings for the control word

Each Pseudo Wire is identified by a label carried inside an MPLS shim.

The format of the MPLS shim is depicted in the following figure.

Figure 24. Format of the MPLS shim

For the Pseudo Wire application, the following format of the MPLS shim isused.

0000 Flags RES Length Sequence Number

0 3 4 7 8 9 10 15 16 31

0000 0000 00 000000 All 0’s

0 3 4 7 8 9 10 15 16 31

Label EXP S TTL

0 19 20 22 23 24 31

DN70296245Issue 1-5 en13/06/2008



Figure 25. Format of the MPLS shim (Pseudo Wire application)

The concatenated ATM cells, together with the control word and the MPLSshim are encapsulated inside IP packets. IP version 4 is used.

The IP packets are further encapsulated inside Ethernet frames. Ethernetframes can have optionally VLAN format. The following figure depicts thestructure of the Ethernet carrying a Pseudo Wire packet.

Figure 26. Structure of the Ethernet carrying a Pseudo Wire packet

PW 000 1 All 1’s

0 19 20 22 23 24 31

Ethernet trailer

0 31

VPI VCI PTI C

Cell Payload (48 bytes)


VPI VCI PTI C


VPI VCI PTI C

Control Word (optional)

Pseudo Wire Header

IP header

Ethernet header

Transmission order

Transmissionorder




NMS interfaces


No effects.


For information on Flexi WCDMA BTS and UltraSite WCDMA BTS, seeRAN1142: ATM over Ethernet for BTS.


No effects.


No effects.


For information on Flexi WCDMA BTS and UltraSite WCDMA BTS, seeRAN1142: ATM over Ethernet for BTS.


No effects.


No effects.


The configuration of the parameters defined in the Management datasection is performed by using the following tools:

. For Flexi WCDMA BTS: BTS Element Manager.

. For UltraSite WCDMA BTS: AXC Element Manager

. For external equipment: vendor specific Element Manager

See the product documentation for more detailed information.

DN70296245Issue 1-5 en13/06/2008



Management data

Files:

For the Flexi WCDMA BTS and UltraSite WCDMA BTS, see RAN1142:ATM over Ethernet for BTS.

For the RNC PWE3 gateway, refer to the external equipmentdocumentation.

Statistics:



Parameters:



Alarms:






PwUas_15

PwSes_15

PwtUnknownPWHdr_15

PwtPktRecv_15

PwtPktTransm_15




Signalling







In the Full PW Backhaul mode, Radio network synchronisation is notsupported by the Iub. Thus, it is required to provide another reference forthe clock: GPS, TDM link, GSM BTS, and so on.

2.11 RAN1142: ATM over Ethernet for BTS

2.11.1 Introduction

This feature consists of the BTS software to support in the emulation ofone or multiple ATM VCCs over a packet-switched network. The emulationis performed in accordance with the PWE3 (Pseudo Wire Emulation Edgeto Edge) specification of IETF, meaning that ATM cell flows are tunnelledthrough the packet-switched network. ATM cells are concatenated insideIP packets.

This feature is one of the building blocks of RAN1063: Hybrid Backhaulwith Pseudo Wires. ATM over Packet is supported for Ethernet interfaceson IFUH (UltraSite WCDMA BTS) and FTIA / FTJA (Flexi WCDMA BTS).


The BTS can be backhauled over packet-switched technologies, IP andEthernet in particular. Operators can select from the full variety of IP andEthernet services, ranging from low cost to premium quality offerings.



This is an optional feature that requires a license in the BTS.

DN70296245Issue 1-5 en13/06/2008



The following steps are required in order to configure the feature:

PWE3 node configuration

. Local IP address configuration (Note: this IP address is different tothe management IP address)

. Network mask configuration

. Default route configuration

. Remote IP address configuration

. Control word usage configuration

. Optional VLAN activation

. Optional VLAN id configuration (required if VLAN is enabled)

Port rate limiting configuration

. Ethernet Bandwidth configuration

. BTS ATM PW Port Bandwidth configuration

PW setup

. VCC to PW configuration

. Packetisation timer configuration

. UL cell concatenation factors configuration

. DL cell concatenation factors configuration

. PW labels configuration

. PHB Differentiated Services configuration

. Optional VCCV-BFD activation

VCCV-BFD configuration

. BFD Desired Minimum Transmission Interval configuration

. BFD Required Minimum Reception Interval configuration

PW Differentiated Services configuration

. PHB configuration

. DSCP configuration



. Optional VLAN priority configuration

. ATM traffic management configuration

Architecture

ATM over Ethernet BTS is one of the building blocks of RAN1063: HybridBackhaul with Pseudo Wires.

As described in RAN1063: Hybrid Backhaul with Pseudo Wires, for HybridPW Backhaul mode the BTS is equipped with Ethernet and TDMinterfaces. The Pseudo Wire termination function is carried out by the BTS.The following figure depicts the configuration.

Figure 27. BTS Pseudo Wire terminating function (Ethernet and TDMinterfaces)

For Full PW Backhaul mode the BTS is equipped only with Ethernetinterfaces. The Pseudo Wire termination function is also carried out by theBTS. The following figure depicts the configuration.

TDMI/F

ATM TDMI/F

TunnelEthernetI/F


ATM

TDMI/F

TDMNetwork

BTS

ATMtermination

nxSTM1

RNC

ATMtermination

PWE3Gateway

PWE3Gateway

DN70296245Issue 1-5 en13/06/2008



Figure 28. BTS Pseudo Wire terminating function (Ethernet interface)

VCCV-BFD functionality

VCCV-BFD provides a light weight mechanism which enables to monitorthe continuity of the service over the Ethernet connection based on theperiodic transmission of control packets.

Control packets are sent by the BTS and by the RNC PWE3 gateway toeach other. When the control packets are not received within a period oftime, an alarm is raised in the BTS, and for stand-alone gateway, the alarmis raised in the gateway management system.

When a BFD session is started, the BTS and the RNC PWE3 gateway willexchange the BFD parameters which determine the transmission intervalof the control packets in each direction, and the detection time.

The parameters are:

. DetectMult: number of BFD Control packets that have to be lostbefore declaring that the session is down.

. RequiredMinRxInterval: minimum interval between received BFDControl packets that the local system is capable of supporting.

. DesiredMinTXInterval: minimum interval that the local systemwould like to use when transmitting BFD Control packets.

The detection time is calculated with the following formula:

TDMI/F

TunnelEthernetI/F


ATM

Node B

ATMtermination

nxSTM1

RNC

ATMtermination

PWE3Gateway

PWE3Gateway



Detection time = DetectMult (received from the peer) x

MAX[RequiredMinRxInterval, DesiredMinTXInterval (received from the peer)]

The detection timer is reloaded every time a valid BFD control packet isreceived. If packets are not received before the timer expires, the link iningress direction is declared down.

In order to limit excessive detection times, the following upper limits arealso set:

. UltraSite WCDMA BTS:. maximum detection time = 30s

. Flexi WCDMA BTS. maximum detection time = 120s

If the calculated detection time exceeds these limits, the limit is usedinstead.



Without ATM over Ethernet for BTS, all data is carried over ATM overTDM-based technologies.



Requirement Reason

IFUH This interface unit is needed to support Ethernet interface in AXC.

FTIA Interface unit needed to support Ethernet interface in Flexi WCDMABTS. E1/T1/JT1 interface with symmetrical line is also provided.

FTJA Interface unit needed to support Ethernet interface in Flexi WCDMABTS. E1 interface with coaxial line is also provided.


This feature is needed for the following feature:

. RAN1063: Hybrid Backhaul with Pseudo Wires

The following hardware features are also required:

DN70296245Issue 1-5 en13/06/2008



. RAN1064: Ethernet+E1/T1/JT1 Interface Unit (Iub User Plane) forFlexi WCDMA BTS (for Flexi WCDMA BTS) (FTIA and FTJA units)

. RAN1097: Ethernet Interface Unit IFUH (Iub User Plane) for AXC(for UltraSite WCDMA BTS)


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 - - WBTS4.0

- C3.0 OSS4.2 - - - -




ASW RAN FTM LK Long-term ON/OFFlicence


For details on the effect over the control and user plane, see RAN1063:Hybrid Backhaul with Pseudo Wires.


NMS interfaces


No effects.


The configuration of the parameters is performed by the NetAct.Additionally, the license can be managed by the NetAct.


No effects.




No effects.


The counters for this feature are collected to NetAct from AXC or FlexiWCDMA BTS, depending on the used BTS type. The AXC counters aretransferred directly to NetAct and Flexi WCDMA BTS counters arecollected through RNC NEMU to NetAct. The PM data is saved to theNetAct database and it can be analysed using NetAct reportingapplications. The measurement data cannot be analysed in NEMU, sinceit is not saved to the NEMU database.


No effects.


No effects.


The configuration of the parameters defined in Management data isperformed by using the following tools:

. For Flexi WCDMA BTS: BTS Element Manager.

. For UltraSite WCDMA BTS: AXC Element Manager

See the product documentation for more detailed information.

Additionally, the Element Manager can manage the license.

The Element Manager also allows viewing the recent counter history (last24 hours).

Management data

Files:

Table 21. ATM over Ethernet for BTS file impacts

File Impact

AML New configuration parameters

TML New configuration parameters

DN70296245Issue 1-5 en13/06/2008



AML belongs to the site configuration files for AXC/ UltraSite WCDMABTS. TML belongs to site configuration files of Flexi WCDMA BTS.Network Management tools such as RAC online provides those siteconfiguration files.

Statistics:

Table 22. ATM over Ethernet for BTS statistics

Statistics Use

PwUas_15 Unavailable Seconds (UAS): Counts the number ofseconds for which the PW interface is unavailable.The interface is defined unavailable from either thebeginning of 10 contiguous SES and/or a defect. Aninterface is available again after a 10-secondabsence of all defects and SES. While the interfaceis unavailable, the only count that is incremented isUAS. Defect: BFD down in the ingress or egressdirection only.

PwSes_15 Severely Errored Seconds (SES): Counts the numberof seconds that contain a defect. Defect: BFD downin the ingress or egress direction. SES are notincremented during Unavailable Seconds (UAS).

PwtUnknownPWHdr_15 The number of received Ethernet frames whosepseudowire header is not configured or has areserved value.

PwtPktRecv_15 Number of received packets on a tunnel.

PwtPktTransm_15 Number of transmitted packets on a tunnel.

EthIfInOcts_15 Number of octets in valid frames received on theinterface.

EthIfOutOcts_15 Number of octets in valid frames transmitted on theinterface.

EthIfInPkt_15 Number of Ethernet packets received on the interface(errored and non-errored).

EthIfOutPkt_15 Number of transmitted Ethernet packets on theinterface.

EthIfInPktErr_15 Number of Ethernet packets received with FCSerrors.

EthIfInUnknownProtos_15 The number of packets received via the interfacewhich were discarded because of an unknown orunsupported protocol. (This counter not supported byFlexi WCDMA BTS).

EthIfOutDiscShaping_15 Number of Ethernet TX packets discarded due to rateshaping.



Table 22. ATM over Ethernet for BTS statistics (cont.)

Statistics Use

EthUnknownPSNHdr_15 The number of Ethernet frames received whose PSNheader is not configured or has a reserved value.

EthIfInUnknownVLAN_15 Number of received Ethernet packets with anunknown VLAN ID.

Parameters:

Table 23. ATM over Ethernet for BTS impact on parameters

Parameter Use

Set of registered vcCTPs List of VCC which are mapped to one PW.

Uplink MPLS Header Uplink MPLS Header (inner label)

Downlink MPLS Header Downlink MPLS Header (inner label)

Shaped Ethernet Bandwidth Shaped Ethernet bandwidth in kbps. Maximum is thecapacity of the Ethernet port 10, 100 or 1000 Mbps.

Control Word Enable Enables the use of the PW control word for all thePWs.

Packetization Timer Defines for each PW the maximum time allowed tocreate a PW frame.

Uplink Concatenation Factor Defines for each PW the maximum number of cellsthat can be encapsulated into a PW frame in theuplink direction. This parameter is used to verify thecontrol the encapsulation.

Local IPv4 Address Defines the local IPv4 address of the BTS where thePW is terminated.

Subnet Mask Defines the subnet mask for Iub the BTS.

Next Hop IP Address Defines the IPv4 address of the default gateway forthe BTS.

PSN priority map Mapping the Pseudo Wire Per-Hop-Behaviourpriorities to values for DSCP (TOS).

VLAN priority map Mapping the Pseudo Wire Per-Hop-Behaviourpriorities to VLAN priorities

Per Hop Behaviour DiffServ Defines the PHB for each PW or for the IP hosttraffic.

Bidirectional Forwarding Enable This parameter switches the BFD session on or offfor each PW.

Desired Minimum Transmit Interval Defines the minimum transmission interval for theBFD control packets.

DN70296245Issue 1-5 en13/06/2008



Table 23. ATM over Ethernet for BTS impact on parameters (cont.)

Parameter Use

Required Minimum Receive Interval Defines the minimum reception interval for the BFDcontrol packets that the BTS supports.

Remote IPv4 Address Defines the IPv4 address of the remote PWE3 GW(RNC GW) where the PW is terminated.

VLAN Tag List VLAN IDs allocated to one tunnel.

Alarms:

Table 24. ATM over Ethernet for BTS impact on alarms

Alarm Description

PW status alarm in the egress direction The alarm is set when the BFD message from the farend contains the diagnostic code = 'Control DetectionTime Expired' AND no ingress alarm is present.

The alarm is cleared when the BFD message fromthe far end contains a status different from 'Down' orwhen the BFD function is disabled.

PW status alarm in the ingress direction The alarm is set when no BFD message is receivedat the local end during the detection time.

The alarm is cleared once a BFD message isreceived at the local end or when the BFD function isdisable.

This alarm is independent from the alarm in egressdirection.

The additional management data of this feature is listed in the followingtable.




Signalling








DN70296245Issue 1-5 en13/06/2008





3 Operability features

3.1 RAS06 documentation for operability features


Table 25. Operability features


RAN1199: RNC GUI for BTSConnection Resources

Description of network elementmanagement in WCDMA RANNetwork Element Management

RAN1160: Collection of KeyCounters

Collection of Key Counters inWCDMA RAN PerformanceManagement

RAN1161: Alarms for PMMeasurement Data TransferFailures

Performance data management inWCDMA RAN PerformanceManagement

RAN1150: RNC Support forTraffica

Introduction in RNC Support forTraffica

Description of RAN Trafficamonitoring in WCDMA RANRealtime Monitoring

RNC support for Traffica in RNCPerformance Management

Activating RNC Support for Trafficain Feature RAN1150: RNC Supportfor Traffica, Feature ActivationManual

RAN1128: Dynamic Access ClassRestriction

Description of access regulation inWCDMA RAN Access Regulation

RAN212: Selectable RNW PlanActivation Mechanism

Optional functionality in WCDMARAN Mass Operations

Operation and maintenance inRNC Operation and Maintenance

RAN1059: Flexi WCDMA BTSSupport for RNS Split

Description of Mass Operations inWCDMA RAN Mass Operations

DN70296245Issue 1-5 en13/06/2008


Operability features

Table 25. Operability features (cont.)


RAN1084: Direct Activation ofRNW Changes Using NWI3

Direct activation in WCDMA RANDirect Configuration Operations


RAN618: Centralised UserInformation Management for BTS

Description of user security inWCDMA RAN User Security

RAN1159: IP Address & Portbased Filtering for BTS LMPs

IP address & port based filteringfor BTS LMPs in WCDMA RANO&M Network Security

RAN33: IP Security for O&MTraffic between RNC and NetAct

IP Security for O&M Trafficbetween RNC and Nokia NetAct inWCDMA RAN O&M NetworkSecurity

Activating IP Security for O&MTraffic between RNC and NetAct inFeature RAN33: IP Security forO&M Traffic between RNC andNetAct, Feature Activation Manual

RAN1451: Mass Change of LocalBTS Passwords

User management in WCDMARAN User Security








. WBTS Counters



. Notices (0-999)










3.2 RAN1199: RNC GUI for BTS Connection Resources

3.2.1 Introduction

This feature introduces new functionality to view RNC connectionrecources for BTS in the RNC GUI object browser application.


There are OPEX savings because of easier and faster troubleshootingcapabilitites in RNC.


The feature improves troubleshooting with RNC element manager byintroducing a new RNC GUI solution for tracking the operational status ofdifferent BTS connections and involved RNC HW units with their operatingstatuses.

The BTS Connection Resource information includes the followinginformation:

. RNC. RNC identification

. WBTS. WBTS name (RNW parameter WBTSName). WBTS additional information (RNW parameter

BTSAdditionalInfo). Related Connection Configuration Identifier

DN70296245Issue 1-5 en13/06/2008



. WCELs. WCEL state. HS-DSCH operative state. LcrId. LAC. Cid. SAC. RAC. UARFCN. PriScrCode. UE count. Operational states of Common channels (FACH, PCH, RACH,

FACH-C/Connect, FACH-C/Idle, FACH-U and FACH-S). Related DMCU units for Common channels. Snapshot of the amount of calls: emergency, signalling link,

AMR, RT CS, NRT CS, RT PS, NRT PS, HSDPA and HSUPA.(Note: In case of a HSUPA call, the HSDPA direction is notshown separately.)

. Iub link configuration. C-NBAP link. External TPI (ATM interface, VPI, VCI). ATM interface status. Operational state. Related ICSU index. D-NBAP links (1-6). External TPI (ATM interface, VPI, VCI). ATM interface status. Operational state. Related ICSU index. AAL2 signalling links (1-6). ATM interface status. External TPI (ATM interface, VPI, VCI). Operational state. Related ICSU index. AAL2 user plane links (1-18). ATM interface status. External TPI (ATM interface, VPI, VCI). Operational state. Related A2SU. AAL2 path ID



. A2EA

. Route ID

. AAL2 path bandwidth (UL / DL)

. Average total load of AAL2 path (UL / DL)

. Number of unsuccessful resource reservations

. Number of successful resource reservations

3.2.3 System impact


The data related to a WBTS connection can be seen in the RNW ObjectBrowser (for example, NBAP link states) and by using MMLs (for example:ATM link status). The information is scattered into different user interfaces.






RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - - - - - -





DN70296245Issue 1-5 en13/06/2008





Feature is available as RNC EM application in RNC OMS. Applicationprovides interface to browse through WBTS connection data. Applicationprovides topology tree from which WBTS's can be browsed one by one.

Management data





This feature has no special capacity requirements or effect.

3.3 RAN1160: Collection of Key Counters

3.3.1 Introduction

The feature enables NetAct to provide a set of Key Counters in shortintervals in a single new measurement. The key counters are collectedfrom the existing cell-level measurements produced by RNC.


CAPEX savings are achieved when accurate measurements are required.OPEX savings result from a possibility to improve measurement utilisation.


NetAct provides a new Key Counter measurement, which can include acollection of priority counters from the cell-level measurements producedby the RNC. The data is accessible the same way as any other PM datavia NetAct tools and interfaces.

Key Counter measurement provides an opportunity for capacity savings inthe NW management systems. The source measurements can becollected in parallel with the Key Counter measurement, but themeasurement interval for the new measurement can be set to be different.



This enables using the Key Counter measurement to collect some of thedata more frequently, without compromising too much on the systemcapacity by collecting everything at the finest granularity. The newmeasurement can be collected for example at 15min interval while keepingthe source measurements on 60 minutes.

There will be more flexibility on configuring the contents of the newmeasurement in OSS5, but this requires manual commissioning tasks,and there are restrictions also on, for example, retaining data overchanges in the measurement definition.

The measurement ID for Key Counter measurement is M1050. This is justfor the administrative purposes of the measurement itself. The counters inthe key counter measurement will have the same Mxxxx Id andabbreviation as used in the "originating" measurement.

3.3.3 System impact


Currently, the whole measurement with all the counters needs to becollected if any of the included counters is needed. The interval of thewhole measurement has to be set according to the finest time granularityneeded for any of its counters.




There are no dependencies with other RAN features, but the basic PMdata collection system has to be in place before the feature can be utilised.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -


OSW/ASW RAS SW component

DN70296245Issue 1-5 en13/06/2008





Licence control innetwork element




No effect.


NMS interfaces

The feature adds one new measurement, which is handled in a similar wayas the other existing radio network performance measurements generatedby RNC.


No changes in RAN NE UIs.

Management data





The feature adds one new measurement, which will require someprocessing and storing capacity from OMS and NetAct.

Properly used it allows reducing the total measurement load by offering away to collect the key counters as one entity with common interval settingsinstead of activating everything with for example 15 minutes interval.

3.3.3.9 Other impacts

The schedule of the source measurements will be adjusted to 24 hours, 7days a week.



3.4 RAN1161: Alarms for PM Measurement DataTransfer Failures

3.4.1 Introduction

The feature introduces new alarms for noticing problems in the PM datacollection.


OPEX savings result from faster discovery of problems in themeasurement collection mechanism.


This feature introduces new alarms for ensuring correct information aboutthe problems in the PM data transfer.

New alarms are introduced for the following failure situations:

. OMS is not able to retrieve Measurement data from RNC OMU orBTS

. NetAct is not able to retrieve Measurement data from OMS.

. There are problems in measurement data processing.

Alarms are cancelled when the situation is recovered.

There are various in-built mechanisms for recovering from problems, sothe alarms are only generated for situations that:

. Result in loss of data

. Require explicit action for resolution

. Indicate a problem in performance of measurement data processingor transfer

The new PM alarms are only intended to cover the PM-specific aspect ofthe data pipe. There are separate mechanisms to notice, for example,general problems with DCN or RNC - BTS connections.

New group for OMS alarms is added (71000-72000). New alarmsintroduced by this feature are:

DN70296245Issue 1-5 en13/06/2008



. 71000 PM FTP CONNECTION FAILED

. 71001 MEASUREMENT DATA NOT TRANSFERRED

. 71002 MEASUREMENT DATA ERROR

. 71003 OMS MEASUREMENT DATA PROCESSING OVERLOAD

3.4.3 System impact


There are mechanisms for noticing generic O&M-related failures, forexample, DCN breaks, but mostly no indicators for the PM-specificproblems.




There are no dependencies to other RAN features as such, but the basicFM and PM functionality has to be available.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -




OSW RAN - -


No effect.




NMS interfaces

No effect.



Management data



No counters related to this feature 71000 PM FTP CONNECTIONFAILED

71001 MEASUREMENT DATANOT TRANSFERRED

71002 MEASUREMENT DATAERROR

71003 OMS MEASUREMENTDATA PROCESSING OVERLOAD


This feature has no special capacity requirements or effect.


No effect.

3.5 RAN1150: RNC Support for Traffica

3.5.1 Introduction

Traffica tool supports real-time monitoring of RNC measurements. Real-time information is available on both transport and radio layer.


Statistical data is available in real-time.

DN70296245Issue 1-5 en13/06/2008




Traffica tool is taken into use also for the RNC measurements. Trafficasupports real time monitoring and this can be used, for example, fortroubleshooting purposes.

Information is provided on both transport and radio layer:

. For example, external ATM VC counter, AAL2 path CAC statistics,Internal CAC statistics and

. For example, call handling counters.

The Traffica Tool gets the data from one up to three RNC(s) by pre-definedevent based Real-time Traffic Reports (RTT).

The following event-triggered reports are UE-specific, meaning that theyalso includethe IMSI of the user thus enabling to monitor events related toa specific subscriber:

. RRC/RAB report for Service use cases provides detailed informationof each RRC connection and RAB that is established or released inthe RNC.

. Soft Handover Failure event triggered report for Mobility use cases.

Periodic reports that are produced with a 60-second interval:

. External AAL2 transport resource report for Resource use cases

. Internal AAL2 transport resource report for Resource use cases.With this report it is possible to see, for example, the number ofHSPA users per DMPG.

. ATM VC Traffic report provides information on the transferred dataon RNC external ATM interfaces. This is related to Throughput usecases.

. Call resource handling report. This report can be used, for example,to view the number of services (SRB, RT, NRT, HSPA) in each ICSU.

. Call resource error code report. This report shows the number ofmost common error codes related to call resource allocations. Thereasons for errors can be, for example, DMPG resource shortage orIub congestion.

The listed Use Cases are documented in WCDMAN RAN SystemDocumentation/Monitor.



RNC sends each RTT using a dedicated interface to the Primary TrafficaNetwork Server. There is always one Primary Traffica Network Server foreach RTT. This means that simultaneously only one Traffica Server canreceive the same RTT. Traffica analyses the data and creates KPIs basedon the data. These KPIs can be visualised in Traffica Real-time graphs.

Event data is also stored in Traffica database for short periods of time fortroubleshooting purposes. Optionally both KPIs and RTTs can be exportedfrom the Traffica system to long-term storage for long-term reportingpurposes.

3.5.3 System impact


This can be done by basic counters but the time to obtain the information istied to the measurements intervals. The intervals - at shortest 15 minutes,usually 1 hour - are too long for this kind of troubleshooting.




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -




ASW NetAct RAN - -


Management data



DN70296245Issue 1-5 en13/06/2008





3.6 RAN1128: Dynamic Access Class Restriction

3.6.1 Introduction

This feature introduces more flexible ways of controlling Radio NetworkAccess and Domain Specific Access Class (DSAC) restriction.

The operator can specify the Radio Network Access Restriction (RNAR)level separately in two different location areas and the DSAC restrictionlevel in four different location areas for both core types.


The feature makes it possible to control and restrict the user traffic inemergency situations.


This feature brings enhancements to the current RNAR and the DSACrestriction features by adding the usage of the cell groups.

The user can define 10 traffic restriction groups. Each group has the typeof restriction defined: 'RNAR' or 'CS-DSAC' or 'PS-DSAC'. Each group hasits own ID, restriction level definition and the functionality can be activatedindependently for each group. Each cell can be connected to a 'RadioNetwork Access Regulation function' or 'Domain Specific AccessRestriction' group by selecting the group ID for the cell.

In addition, it is possible to activate the RNAR functionality and DSACrestriction for all cells in the RNC with one selection.

Compliance: 3GPP Rel.6 TS 25.331 v6.5.0



3.6.3 System impact


n the RNAR function, one cell group is supported and cells are selected tothe group one by one.

The DSAC restriction can be set separately to both CN domains, but theaccess class restriction level is the same for both core types. Therestriction interval is common for the RNAR function and DSAC restrictioncell groups.




Both 'Radio Network Access Function' and 'Domain Specific Access ClassRestriction' are paused when RNW plan activation using fast mode isinitiated. If the traffic restriction period ends (timer set for RestrictionInterval expires) during plan activation, then the new restriction informationis not sent to cells. New restriction information (updated Access Classbarred list) is sent to the cells after RNW plan activation is complete.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - OSS4.2 - - - 3GPPRel-6






Both 'Radio Network Access Regulation Function' and 'Domain SpecificAccess Class Restriction' have the traffic restriction information included inSystem Information Block 3 message which is broadcasted in the cell.

DN70296245Issue 1-5 en13/06/2008




NMS interfaces

This feature is configured by using RNC RNW plan management interfaceor RNC element manager.


Both 'Radio Network Access Regulation Function' and 'Domain SpecificAccess Class Restriction' can be enabled by using RNW Object Browserof the RNC Element Manager. Feature status can also be followed in RNCEM.

Management data


Access Class Barred list No counters related to this feature 2868 LIMITED UE ACCESS TORADIO NETWORK


None.


None.

3.7 RAN212: Selectable RNW Plan ActivationMechanism

3.7.1 Introduction

This feature introduces a control mechanism for activation speed and NWavailability in the RNW configuration plan activation operation. Threealternative modes are supported.


OPEX saving are acquired thanks to the possibility of faster RNWconfiguration.




The operator can select which way the plan will be activated. The safeactivation mode is the slowest and has less influence on the traffic whilethe fast activation method may have influence on the existing traffic.

. Safe activation mode (existing method): The plan is activated withthe current method: one object at the time. This method has aminimal effect on the traffic.

. Normal activation mode: The existing NW is taken into account sothat simultaneous operations are not done to adjacent WCELs. Thismethod has a moderate effect on the traffic.

. Fast activation mode: The object dependencies are ignored.Operations are done parallel as a mass operation. This method hasthe largest effect on the traffic.

The purpose of the feature is to enable faster activation time for the RNWplan.

3.7.3 System impact


In the current implementation, the safe activation mode (mode 1) isavailable.




'Radio Network Access Regulation Function' (RNAR) and 'DomainSpecific Access Class Restriction' (DSAC) are paused when RNW planactivation using 'fast' mode is started. The existing traffic restriction appliedin the cells by using RNAR and DSAC remains same until RNW planactivation is complete.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - OSS4.2 - - - -

DN70296245Issue 1-5 en13/06/2008






ASW NetAct RAN NetAct -


No effect.


NMS interfaces

RNW plan activation mode is sent to RNC in the RNW plan activationcommand from NetAct.


There are no effects to RAN NE UIs.

Management data





Selection of RNW plan activation is a choice between speed of operationand the possible interruption in service level in RAN. Selecting 'safe' modeshall make the operation last longer with minor or no effect to the servicelevel in RAN. 'fast' mode will shorten operation time but can cause severeeffect to RAN service level during plan activation.


None.



3.8 RAN1059: Flexi WCDMA BTS Support for RNS Split

3.8.1 Introduction

The feature enables RNS Split plan management concept support for theFlexi WCDMA BTS. The execution of RNS split operation for the FlexiWCDMA BTS can be planned in advance and the BTS outage due tooperation is decreased.


OPEX savings are achieved due to the reduced time of Flexi WCDMABTS configuration and the reduced amount of possible human errorsduring configuration process.


With this feature the configuration of the Flexi WCDMA BTS transportmodule is included in the RNS Split concept.

The Flexi WCDMA BTS transport configuration upload, download andactivation operations can be triggered from the NetAct RNS splitapplication. The configuration data is transferred from the NetAct to the NEusing the NWI3 interface in XML format. The RNC mediates the NWI3 planmanagement interface to the BTS O&M interface for the Flexi WCDMABTS. Flexi WCDMA BTS forwards the configuration file information to theFTM. The operator can also schedule the configuration upload, downloadand activation operations.

DN70296245Issue 1-5 en13/06/2008



Figure 29. Flexi WCDMA BTS Support for RNS Split

3.8.3 System impact


Currently, the RNS Split operations can be executed only with UltraSiteWCDMA BTSs. All RNS configuration actions for a Flexi WCDMA BTSsmust be done manually.




This feature requires activation of the following licensed feature:

. RAN96: Automated RNS split


NetAct

UI

RNC

Flexi BTS/ NextGenerationWCDMABTS

NWI3Management interface

BTS O&MManagement interface

Radio AccessConfigurator/RNS splitapplication

mediator

UI BTS O&M FTM



RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - WBTS4.0

- - OSS4.2 - - - -






No effect.


NMS interfaces

Feature can be used by activating the NetAct RNS split application and byusing the NetAct RNS split application for the uploading, planning,downloading and activation of the FlexiBTS transport configuration files.



Management data





NetAct can send one upload, download or activation request per RNC for agroup of maximum 100 FlexiBTSs at a time. However, it is possible to sendsimultaneous upload, download and activation requests.

DN70296245Issue 1-5 en13/06/2008




None

3.9 RAN1084: Direct Activation of RNW Changes UsingNWI3

3.9.1 Introduction

This feature provides a mechanism for making direct parameter changesin the RNW configuration from the NetAct.


OPEX savings are achieved because of faster RNW parameter changesfrom NetAct.


With this feature, the NetAct Radio Access Configurator user is able toperform direct operations to individual parameters in the RNWconfiguration. The changes are distributed to the NW online withoutseparate activation procedures.

The following operations are supported:

. Create

. Modify

. Delete

. Lock / Unlock (WCEL)



Figure 30. Direct Activation of RNW Changes Using NWI3

3.9.3 System impact


In the current implementation, the RNW configuration changes aredistributed to the NW as plan files with separate download and activationprocedures. The plans are a good alternative for mass operations, but forsmall operations the plans are too tedious to create, pre-activate andactivate.




Direct activation request can not be executed during RNW plan operation(plan upload, rollback, download or activation). In case there are bothDirect Activation and RNW plan operations to be done for same RNC thenNetAct does Direct Activation operations first.

NetAct

UI

RNC

RNC RNWdatabase

WCDMA BTS

NWI3 Managementinterface

3GPP Iub & BTS O&MManagement interface

Radio AccessConfigurator

RNWmanagement

BTS configurationmanagement

DN70296245Issue 1-5 en13/06/2008




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -






No effect.


NMS interfaces

NetAct sends a 'Direct Activation' operation request to the RNC containingthe data to be changed in network.



Management data





Limitations and restrictions: This feature allows the following operations tothe following objects:

. WCEL: lock, unlock, create, modify and delete

. WBTS: create, modify and delete



. COCO: create, modify and delete

. WLCSE: create, modify and delete

. Adjacencies (ADJI, ADJS.ADJG): create, modify and delete

A NetAct user can give one direct activation request per RNC at a time.The request can include one object and one operation. A direct activationrequest cannot be executed during plan operations (plan upload, rollback,download or activation).

3.10 RAN618: Centralised User InformationManagement for BTS

3.10.1 Introduction

This feature enables a centralised user account management for BTS fromNetAct.


The centralised RAN system security results in enhanced riskmanagement and OPEX savings.


Both BTS element manager user and BTS host are identified to fulfill thesecurity requirements.

This feature enables new user creation, password change and userdeletion. The user is able to manage the access to the O&M NWseparately for each group or individual of the maintenance personnel on aBTS access level. BTS users have one type of authorisation access profilein use.

In the login phase, the network entity checks the user access right from theauthentication server located in the NetAct.

With this feature the user can access different network systems with thesame user name and password.

DN70296245Issue 1-5 en13/06/2008





In previous releases, the centralised user information management hasbeen implemented for the RNC and AXC.




This feature interacts with the Centralized User Event Log Managementfor BTS feature which has been planned to an upcoming release.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

WP2.0 C3.0 OSS4.2 - - - -






No effect


NMS interfaces

BTS O&M interface is used through a mediator to set up initialisationparameters and to update the NE account.


Commissioning of the initialisation parameters are added into the BTS SiteElement Manager GUI.



Management data





Authentication response time depends on different factors such as theoverall authentication request density and connection speed.

3.11 RAN1159: IP Address & Port based Filtering forBTS LMPs

3.11.1 Introduction

This feature allows selectively defining the access to/from IP DCN from/toall entry points at a NodeB site. Filtering is based on source anddestination IP address and port information.

This feature improves the protection of:

. IP DCN from harmful IP traffic originated from NodeB

. NodeB from harmful IP traffic arriving from IP DCN


Enhanced risk management is achieved because of improved RANsystem security.


The feature implements the means of access protection to thetransmission (AXC) of UltraSite WCDMA BTS and the transmission ofFlexi WCDMA BTS.

It is possible to filter IP traffic based on source and destination IP addressand TCP/UDP port number. This IP traffic supervision is covering allpacket flows in WCDMA BTS.

DN70296245Issue 1-5 en13/06/2008



The feature introduces a new mode to more selectively define the accessto/from IP DCN. Since WAM offers also an LMP, this feature increasessecurity with respect to all NodeB LMPs.

The operator can select between the following modes, independently foreach of the three packet flows:

. In an unrestricted mode, all IP traffic is allowed to pass through.

. In a restricted mode, no IP traffic is allowed to pass through. (Onlyavailable for AXC LMP <> IP DCN packet flow because WAM/AXCneeds at least IP connectivity towards Netact/NEMU.)

. In a restricted mode with exceptions, the AXC IP routing functionvalidates the source and destination information of each incoming IPpacket against the configuration in the related table. IP packets thatdo not match the criteria are discarded.

Whether only IP addresses or IP addresses and ports need to match is amatter of configuration. It is possible to configure IP filter rules for AXC/Flexi WCDMA BTS locally or remotely with site configuration files orelement manager.



Until now the operator could only select to either block all or transparentlypassthrough all IP traffic between the AXC LMP and IP DCN, by switchingthe restricted mode on/off. With the IP traffic between the WAM/AXC andIP DCN there was no possibility for any control at all.




The feature improves the restricted mode feature in AXC.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 - WBTS4.0

WBTS4.0

- C3.0 OSS4.2 - - - -






OSW RAN - -


Management data


IP filter rule. Unique rule name. Source and destination IP

address definitions. Ranges or wildcards can be

used. Source and destination port

definitions


3.12 RAN33: IP Security for O&M Traffic between RNCand NetAct

3.12.1 Introduction

This feature enables secure transmission of O&M traffic in the O&M DCNfor the connection between the RNC and NetAct.


Enhanced risk management is gained because of improved RAN systemsecurity. This feature strengthens the protection against both internal andexternal hostile attacks.

DN70296245Issue 1-5 en13/06/2008




Virtual Private Networks (VPN) are defined for the O&M traffic between theRNC and NetAct. IPSec is used to encrypt the data.

The most important part of the O&M traffic to be encrypted is naturally theinformation related to user management. IPSec configuration can be donebased on source and destination IP addresses and port numbers.



Currently no encryption is used for the O&M data in WCDMA RAN.






RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -







The feature is managed via MML and Windows user interface. IPSec rulesneed to be configured to the element.



Management data




3.13 RAN1451: Mass Change of Local BTS Passwords

3.13.1 Introduction

This feature introduces new functionality for performing a mass change oflocal BTS passwords remotely.


This feature improves system security and redcues the effort needed forpassword maintenance.


New element management functionality is introduced to make remotepassword changes for Flexi WCDMA BTS possible.

With this functionality, an operator can remotely change several BTSpasswords. New functionality is introduced in WN4.0 for Flexi WCDMABTS element manager release.



Local passwords are managed one by one with the BTS element manager.





DN70296245Issue 1-5 en13/06/2008




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 - - WBTS4.0

- - - - - - -




OSW RAN - -


Management data






4 Performance monitoring features

4.1 RAS06 documentation for performance monitoringfeatures


Table 26. Performance monitoring features


RAN1068: 3GPP TS 32.403Related Counter Additions forRAN

Call setup and release in CallSetup and Release

Handover control in HandoverControl

Measuring WCDMA RAN inMeasuring WCDMA RAN

RAN868: ATM Transport StatisticsReporting in RAN

RAN86: Cell ThroughputMeasurements in Serving RNC

Introduction to the packetscheduler functionality in PacketScheduler

RAN234: HSDPA SubscriberTrace

Description of Subscriber andEquipment Trace in WCDMA RANSubscriber and Equipment Trace

RAN1052: HSUPA SubscriberTrace

Description of Subscriber andEquipment Trace in WCDMA RANSubscriber and Equipment Trace


DN70296245Issue 1-5 en13/06/2008


Performance monitoring features







. WBTS Counters



. Notices (0-999)








4.2 RAN1068: 3GPP TS 32.403 Related CounterAdditions for RAN

4.2.1 Introduction

This feature adds new 3GPP-specified counters to Nokia SiemensNetworks Measure Solution.




OPEX savings result from easier operation of multi-vendor NWs.


This feature adds the following new 3GPP counters to RAN:

. RAB CS connection set-up time (Maximum)

. RAB PS connection set-up time (Maximum)

. RRC connection set-up time (Maximum)

. Failed RRC re-establishments

. Successful RRC re-establishments

. Not replied RRC re-establishments by the UE

. Attempted radio link additions to active link set (UE side)

. Successful radio link additions to active link set (UE side)

. Attempted radio link additions to active link set not replied by the UE(UE side)

. Attempted radio link deletions from active link set (UE side)

. Successful radio link deletions from active link set (UE side)

Nokia Siemens Networks specific names of the counters are used in theinterface between the RNC and NetAct. The 3GPP name is used in theNetAct Northbound (= 3GPP Itf-N) interface.

DN70296245Issue 1-5 en13/06/2008



Figure 31. 3GPP TS 32.403 Related Counter Additions for RAN

4.2.3 System impact


3GPP has specified the RNC-based counters for WCDMA RAN into 32-series specifications. TS 32.642 specifies the UTRAN Network ResourceModel (NRM), which links all counters to a specific resource to enablecounter utilisation in operating the NW. TS32.403 specifies the actualcounters. Currently a subset of the counters specified in TS32.403 isavailable in Nokia Siemens Networks RAN.

RNClub

NokiaNetAct

PM: Measurementactivation

lu-CS

Local MeasurementManagement

PM: Data Transfer

RAS06: Adding missingcounters accordingto TS.32.403

Report generation

Reporter

RNCElement Manager

NetAct Northbound interface3GPP named counters

3GPP Itf-N interface

RNC - NetActproprietary interface

Core Network

Counters withproprietarynames

Iub

3GPP Type Network Manager

Counters withproprietarynames








RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -




OSW RAN - -




NMS interfaces

Generic impacts:

. NetAct and RNC are using Nokia naming that is consistent with theother RNC statistics. 3GPP naming is applied in NetAct 3GPP Itf-NPM interface.

Reporting Tools:

. new KPIs for RRC and RAB maximum setup times

. new KPIs for RRC re-establishment rates

. new KPIs for SHO rates

DN70296245Issue 1-5 en13/06/2008





. New RRC and RAB setup max time counters added to Service LevelMeasurement.

. New RRC re-establishment counters added to RRC SignalingMeasurement.

. New radio link addition and deletion counters added to RRCSignaling Measurement.

Management data



RRC SETUP TIME MAX

RAB SETUP TIME MAX CS VOICE

RAB SETUP TIME MAX CS DATACONVERSATIONAL

RAB SETUP TIME MAX CSSTREAMING

RAB SETUP TIME MAX PSSTREAMING

RAB SETUP TIME MAX PSINTERACTIVE

RAB SETUP TIME MAX PSBACKGROUND

RRC RE-ESTABLISH SUCCESSNRT

RRC RE-ESTABLISH FAIL UE NRT

RRC RE-ESTABLISH FAIL NOREPLY NRT

ACTIVE SET UPDATE RL ADDATTEMPTS

ACTIVE SET UPDATE RL ADDSUCCESS

ACTIVE SET UPDATE RL ADDFAILURE UE

ACTIVE SET UPDATE RL ADDFAIL NO REPLY

ACTIVE SET UPDATE RL DELATTEMPTS

ACTIVE SET UPDATE RL DELSUCCESS






4.3 RAN868: ATM Transport Statistics Reporting inRAN

4.3.1 Introduction

This feature provides visibility to information from separate NW layers forbuilding an effective ATM transport NW performance reporting to theNetAct.


An efficient tool for ATM transport optimisation means OPEX savings.


This feature provides linking between RNW and transport NW topology forperformance statistics. The linking enables the building of WBTS-specifictransport NW performance reports in the NetAct Reporter and it is possibleto combine all transport resources related to a certain BTS into a singlereport. In addition, the mapping is done for the ATM connection type, whichmeans that user plane and control plane connections can be separated forreporting.

The current reporting in the NetAct is not affected, that is, reports based onATM layer connection identifiers are still possible.

The object information in the ATM Measurements provided by the PMfunction will contain both the radio and transport topology information.

The feature does not provide any new counters.

DN70296245Issue 1-5 en13/06/2008



Figure 32. ATM Transport Statistics Reporting in RAN

4.3.3 System impact


Performance statistics for ATM layer connections are identified using theATM connection identifiers. Because there is no linking available betweenthe ATM connections and the related RNW elements (for example, BTS),the operator needs to maintain some mapping tables to find out the ATMlayer connection identifiers for different RNW elements.



RNClub

NokiaNetAct

PM: Measurementactivation

lu-CS

Local MeasurementManagement

PM: Data Transfer

RAS06: Adding missingcounters accordingto TS.32.403

Report generation

Reporter

RNCElement Manager




Core Network

Reports forATM Total

throughput perBTS

Iub

ATM basedcountersfor troughputmeasuring






RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -




OSW RAN - -




NMS interfaces

Reporting tools:

. combined radio and transport layer reports


This feature has no impact on Network Element user interfaces.

Management data






DN70296245Issue 1-5 en13/06/2008



4.4 RAN86: Cell Throughput Measurements in ServingRNC

4.4.1 Introduction

This feature allows network-wide monitoring of the user plane datathroughput on SRNC level towards Iub.

As an example, this feature enables easy monitoring of the distribution ofHSDPA and DCH throughput and provides statistics for HSDPA and DCHcapacity optimization.


OPEX savings are gained because of optimised Iub throughput andtransport resource utilisation. Increased revenue results from improvedNW data throughput.


This feature introduces measurements to follow the user plane throughputof MAC-d layer for HSDPA (HS-DSCH), HSUPA (E-DCH), NRT(DCH) andRT (DCH) traffic.

(Note that E-DCH throughput counters are part of feature RAN973:HSUPA Basic RRM.

Counters are provided on cell-level for SRNC-related traffic.

The new counters in SRNC:

. Signaling RB DCH MAC-d throughput

. RT CS (AMR, Conversational and Streaming) DCH MAC-dthroughput

. RT PS (Streaming) DCH MAC-d throughput

. NRT (Interactive and Background) DCH MAC-d throughput

. NRT (Interactive and Background) HS-DSCH/E-DCH MAC-dthroughput

UL/DL separation is provided, Traffic Class separation is not provided.



The new counters are provided by the MAC user plane functionality inRNC.

The new cell counters will be added to new Cell Throughput Measurementin RNC.

This feature does not bring any new alarms.

Figure 33. Cell Throughput Measurements in Serving RNC

4.4.3 System impact


There are common channel (RACH, FACH, PCH) MAC-c throughputcounters per cell. There are also HS-DSCH MAC-d throughput counters atBTS per cell.




E-DCH-related cell throughput counters are a part of feature RAN973:HSUPA Basic RRM.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Iu

Iub

DMCU

A2SU/GTPU

PDCP/IUUP

RLC-U

MAC-d

FP

A2SU

Note: SFU andMXU units havebeen neglectedin this picture

MAC-d PDUthroughput ismeasured here

DN70296245Issue 1-5 en13/06/2008



RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -








NMS interfaces

Reporting Tools:

. The new RAN_KPI_0075 follows the average HSUPA cellthroughput.

. The new RAN_KPI_0080 follows the HSUPA cell throughput datavolume.

. The existing RAN_KPI_0044 follows already the average HSDPAcell throughput.

. The new RAN_KPI_0055 follows the HSDPA cell throughput datavolume.

. RAN KPIs for Iub Throughput (RAN_KPI_0067 and RAN_KPI_0068)available but will be based on ATM VP based counters.

Optimising Tools:

. The counters can be used for Capacity Optimization in NetActOptimizer.





. The new MAC-d and MAC-es throughput counters (in SRNC) will beadded to the new Cell Throughput Measurement.

Management data



TRANSFERRED DATA FORSIGNALLING RB DCH UL

TRANSFERRED DATA FORSIGNALLING RB DCH DL

TRANSFERRED DATA FOR CSCALL DCH UL

TRANSFERRED DATA FOR CSCALL DCH DL

TRANSFERRED DATA FOR PS RTDCH UL

TRANSFERRED DATA FOR PS RTDCH DL

TRANSFERRED DATA FOR NRTDCH UL

TRANSFERRED DATA FOR NRTDCH DL

TRANSFERRED DATA FOR HS-DSCH

TRANSFERRED DATA FOR NRTDCH FOR HSDPA RETURNCHANNEL UL

TRANSFERRED DATA FOR NRTE-DCH




4.5 RAN234: HSDPA Subscriber Trace

4.5.1 Introduction

This feature introduces HSDPA reporting for Subscriber and EquipmentTrace functionality.

DN70296245Issue 1-5 en13/06/2008




OPEX savings are acquired because of reduced time to troubleshoot theNEs and UE. Possible troubles can be detected and relevantmeasurement data can be presented simultaneously.


New HSDPA-related counters to be reported:

. Basic Trace Type/UE Capability Trace record additions:. UE HSDPA capability

. Basic Trace Type/Active set cell record additions:. HSDSCH Usage. Target cell of HSDPA Serving Cell Change. Failure cause and aimed Target Cell(s) if Serving Cell Change

fails

. Basic Trace Type/Dedicated Transport Channel record additions:. HS-DSCH release and related cause

The current Trace counters can be used to see non-HSDPA-specificissues, such as, the related CN(s), used RAB(s), DL RLC data, statetransition and so on.

HSDPA Tracing will be an extension to the previously released Tracefeatures.

All previous Trace features are simultaneously available with RAN234:HSDPA Subscriber Trace to enable, for example, simultaneous voiceconnection tracing.



Figure 34. HSDPA Subscriber Trace

4.5.3 System impact


The current implementation enables Trace to be used in a HSDPA-capable NW without disturbance in normal Tracing, but no HSDPA-specificreporting is available.



RNClub

NokiaNetAct

MML: Local TraceActivation

NWI3: Trace_Report

HSDPA Data andHSUPA Data

Report generation

Reporter

RNCElement Manager




Core Network

HSDPA Trace Data- UE capability- HS-DSCH HOs- HS-DSCH <-> DCH

HSUPA Trace Data- UE capability- E-DCH HOs- E-DCH <-> DCH

Iub

Activate Trace

DN70296245Issue 1-5 en13/06/2008




The HSDPA features must be active in order to get HSDPA-related data totrace records.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -






Signalling-based activation of Subscriber and Equipment Trace in theRNC uses a dedicated Core NW message to the RNC.


NMS interfaces

Monitoring tools:

. No changes to trace activation, that is, no separate activation forHSUPA tracing in the NetAct TraceViewer is possible.

. The HSDPA-related data will be visible in the NetAct TraceViewer.


Subscriber Trace may be locally activated in the RNC using RNC ElementManager.

Management data









4.6 RAN1052: HSUPA Subscriber Trace

4.6.1 Introduction

This feature introduces HSUPA reporting for Subscriber and EquipmentTrace functionality.


OPEX savings result from reduced time to troubleshoot the NEs and UE.Possible troubles can be detected and relevant measurement data can bepresented simultaneously.


New HSDPA-related counters to be reported:

. Basic Trace Type/UE Capability Trace record additions:. UE HSUPA capability

. Basic Trace Type/Active set cell record additions:. EdchUsage (to indicate use of E_DCH). Target cell of HSUPA Serving Cell Change. Failure cause and aimed Target Cell(s) if the Serving Cell

Change fails

. Basic Trace Type/Dedicated Transport Channel record additions:. E-DCH release and related cause

. Radio Trace Type/Downlink AM RLC record additions:. E-DCH UL RLC SDU data amounts. Active transmission time

. Radio Trace Type/Uplink Performance

DN70296245Issue 1-5 en13/06/2008



. UL BLER for E-DCH

The current Trace counters can be used to see non-HSUPA-specificissues, such as, the related CN(s), used RAB(s), DL RLC data, statetransition and so on.

HSUPA Tracing will be an extension to the previously released Tracefeatures.

All previous Trace features are simultaneously available with RAN1052:HSUPA Subscriber Trace to enable, for example, simultaneous voiceconnection tracing.

Figure 35. HSDPA Subscriber Trace

RNClub

NokiaNetAct

MML: Local TraceActivation

NWI3: Trace_Report

HSDPA Data andHSUPA Data

Report generation

Reporter

RNCElement Manager




Core Network

HSDPA Trace Data- UE capability- HS-DSCH HOs- HS-DSCH <-> DCH

HSUPA Trace Data- UE capability- E-DCH HOs- E-DCH <-> DCH

Iub

Activate Trace



4.6.3 System impact


The current implementation enables Trace to be used in a HSUPA-capable network without disturbance in normal Tracing. This new featureintroduces HSUPA-specific reporting.




The HSUPA features must be active in order to get HSUPA-related data totrace records.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -






Signaling based activation of Subscriber and Equipment Trace in RNCuses dedicated Core NW message to RNC.


NMS interfaces

Monitoring tools:

DN70296245Issue 1-5 en13/06/2008



. No changes to trace activation, that is, no separate activation forHSUPA tracing in the NetAct TraceViewer is possible.

. The HSUPA-related data will be visible in NetAct TraceViewer.


Subscriber Trace may be locally activated in the RNC using RNC ElementManager.

Management data





This feature has no impact on system performance or capacity



5 RNC solution features

5.1 RAS06 documentation for RNC solution features

See the following table for more detailed information on WCDMA RANfunctionality:

Table 27. RNC solution features


RAN1151: Linux Based OMSReplacing NEMU


RAN1623: Carrier ConnectivityOptimised RNC450








. WBTS Counters


DN70296245Issue 1-5 en13/06/2008


RNC solution features


. Notices (0-999)








5.2 RAN1151: Linux Based OMS Replacing NEMU

5.2.1 Introduction

Linux-based OMS replaces Windows-based NEMU.


New performance management and operability features can be usedwithout restrictions on performance and capacity.


Linux (RedHat Enterprise 4 update 3) replaces the Windows platform usedin NEMU (Network Management Unit) in the earlier releases. The nameOMS (O&M Server) will be used instead of NEMU.

Windows-based NEMU is not supported in RAS06/RN3.0 any longer.

The OMS functionality does not differ from NEMU. It is responsible for thesame tasks as NEMU but with higher performance and capacity. The Linuxoperating system also provides high stability for this type of application.

OMS is responsible for the following tasks:



. user interface, both GUI NEMU functionalities and MMI for MMLsessions

. NetAct interface

. O&M functions in the RNC

. post-processing support for measurement and statistics tasks

5.2.3 System impact


In earlier releases Windows-based NEMU is used.


MCP18-B is required for OMS.


RAN1181: RNC NEMU Firewall feature is not used in OMS any longer.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - OSS4.2 - - - -




OSW RAN - -


This feature has no effect on control and user plane.

DN70296245Issue 1-5 en13/06/2008




NMS interfaces

This feature has no effect on NMS interfaces.


Due to the operating system change the Graphical User Interface isvisually slightly changed but the usability principles are unchanged.

Management data



No counters related to this feature 71050 OMS EMT CONNECTIONCOULD NOT BE OPENED

71051 OMS EMT CONTROLCONNECTION FAILURE

71052 OMS FTP CONNECTIONCOULD NOT BE OPENED

71053 O&M SUPPORT FORINTEGRATED 3RD PARTYDEVICES

71054 WCDMA BTS O&MMEDIATION FAILURE

71055 NETWORK ELEMENTRESTARTED

71056 OMS TELNETCONNECTION COULD NOT BEOPENED

71057 RNW NOTIFICATIONMISSING


This feature has no effect on capacity and performance.


None.



5.3 RAN1623: Carrier Connectivity Optimised RNC450

5.3.1 Introduction

The operator can select either the standard original capacity-optimisedsteps of RNC450 or the coverage-optimised solution with high carriers/cellconnectivity and lower maximum PS data throughput.


Wide network coverage can be built under RNC when the PS datacapacities are low. This is beneficial, for example, in case of networkrollout phase or in the markets where the AMR traffic is dominant. Theoperator can optimise the number of needed RNCs in the network byselecting the right configuration that best supports their traffic profile.


The carrier connectivity solution is supported by each RNC450configuration. More carriers/cells and NodeBs can be configured under theRNC having lower PS data throughput. With RNC450/step2-300, AMRcapacity is increased to 6800. With RNC450/step3-450 carrier-optimisedconfiguration, AMR capacity is increased to 10 000 Erl.

The RNC HW configuration is always the same between the capacity andcoverage solution. Selection of the configuration mode is done by usingSW license keys. HSPA activation is made by using different parametersfor each mode.

For RNC450/step1-150 there are four different alternatives for thecoverage solution. Step1 solution is already available in RAS05.1 withouta license key. RNC450/step2-300 and RNC450/step3-450 supports onecarrier-optimised configuration for each step. License keys for all steps areintroduced in RAS06.

Capacities of the coverage solution are presented in the following figure.For information on the numbers of supported HSPA users for differentRNC configurations, see RNC450 capacity in Nokia WCDMA RNCProduct Description for RNC450.

DN70296245Issue 1-5 en13/06/2008



Figure 36. Capacities of the coverage solution

Table 28. Different configuration options for RNC450/150

Defaultcapacity

Coverageoptimised

Coverageoptimised

Coverageoptimised

Coverageoptimised

Iub throughputMbps

150 135 105 80 50

AMR Erlang 4000 4000 4000 4000 4000

Number ofcarriers

600 660 720 780 840

Number of BTSs(1+1+1)

200 220 240 260 280

5.3.3 System impact


In RAS05.1 carrier optimised configurations are supported for RNC450/step1-150 without license control. Coverage-optimized configurations arenot supported for RNC450/step2-300 or RNC450/step3-450 in RAS05.1.



RNC 450/1501 cabinet

150 Mbps DL4000 Erl200 BTSs (1+1+1)600 Cells

RNC 450/3001,5 cabinets


RNC 450/4502 cabinets





RAS06RAS06RAS05.1






RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 - - - - - - - - -




OSW RAN RNC LK Long-term capacitylicence


User plane capacity is decreased for Iub PS data.


NMS interfaces

This feature has no effect on NMS interfaces.


Different parameter values are used in HSPA activation phase for carrier-optimised configurations.

Management data




DN70296245Issue 1-5 en13/06/2008




Cell/carrier connectivity under RNC can be increased with lower PS datathroughput capacity.



6 BTS solution features

6.1 RAS06 documentation for BTS solution features

See the following table for a list of BTS solution features for RAS06.

Table 29. BTS solution features

Feature ID: Name

RAN906: Flexi WCDMA BTS 3GPP Antenna Tilt Support

RAN908: Flexi WCDMA BTS AISG MHA Support

RAN1670: UltraSite EDGE Wideband Combiner for WCDMARefarming *

RAN1223: 40W Remote Radio Head 2100 *

RAN1222: External GPS Synchronisation for Flexi BTS SystemModule Rel 1

RAN1463: Support for FRMB/C Unit in Flexi WCDMA BTS *

RAN1139: FADB Flexi Multiradio Combiner for 900MHz *

RAN1079: FACB Flexi Multiradio Combiner for 850MHz *

RAN1462: FAGB Flexi Multiradio combiner for 2100MHz

RAN1127: Extended Cell (180km)

RAN923: Pico WCDMA BTS with Ethernet Transport *

RAN1309: WMHD Mast Head Amplifier

RAN1594: Pico WCDMA BTS Rel.2 SW *

*) Delivered on top of RAS06.

For more information on Flexi WCDMA BTS, see the following documents:

DN70296245Issue 1-5 en13/06/2008


BTS solution features

. Flexi WCDMA BTS Description

. Flexi WCDMA BTS System Module Description

. Flexi WCDMA BTS RF Module and Remote Radio Head Description

. Flexi WCDMA BTS Optional Items Description

For information on RAN923: Pico WCDMA BTS with Ethernet Transportand RAN1594: Pico WCDMA BTS Rel.2 SW, see also Nokia PicoWCDMA BTS Product Documentation.








. WBTS Counters



. Notices (0-999)










6.2 RAN906: Flexi WCDMA BTS 3GPP Antenna TiltSupport

6.2.1 Introduction

Flexi WCDMA BTS has integrated Antenna Tilt control HW in Radiomodule to control the 3GPP Tilt Antennas. This integrated Antenna tilt HWis enabled by a specific SW licence. Nokia Siemens Networks officiallysupports only the following antennas: Kathrein, Powerwave, Andrew.


Antenna Tilt is integrated to the RF module of Flexi WCDMA BTS. It feedsDC power to the antenna and controls the antenna tilting.

In Flexi WCDMA BTS this 3GPP specified antenna tilting functionalitymust be enabled by a SW licence because the HW is integrated to all RFModules.

6.2.3 System impact


This feature does not require any new or additional HW..


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 - - WBTS4.0

- - - - - - -




DN70296245Issue 1-5 en13/06/2008





OSW RAN BTS LK -



The antenna tilt for detected devices can be changed via BTS elementmanager.

Management data




6.3 RAN908: Flexi WCDMA BTS AISG MHA Support

6.3.1 Introduction

Flexi WCDMA BTS has integrated Bias-T HW in Radio module to controlNokia Siemens Networks AISG 2.0 MHA's. This integrated HW based SWfunctionality is to be enabled by a specific SW licence.


Bias-T is integrated to the RF module of Flexi BTS. It feeds DC power tothe MHA and controls the MHA DC power current consumption. If thecurrent consumption is out of a specified window, an alarm is generated.AISG has specified additional control functionality for MHA. This control isdone over OOK modulation using the antenna feeder.

In UltraSite, the Bias-Ts have been separate HW units installed to the BTSantenna connectors and customer has paid the functionality in the Bias-THW price, typically 6 pieces for a 3 sector BTS.

In Flexi WCDMA BTS, this AISG 2.0 MHA power feeding and enhancedMHA alarm control must be enabled by a SW licence because the HW isintegrated to all RF Modules.



Nokia Siemens Networks supports only MHAs coded with AISG vendorcode 'NK'. For 3rd party MHAs there will be special licence key andsupported MHAs need to be decided case by case.

6.3.3 System impact


Used MHA parameters will be entered during comissioning.


Nokia Siemens Networks only supports its own AISG-compatible MHSwith AISG vendor code ‘NK’.


RAN905 license is not needed if AISG interface activated (with license).


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 - - WBTS4.0

- - - - - - -




OSW RAN BTS LK -


This feature has no impact on control and user plane


NMS interfaces

This feature has no impact on Management plane.

DN70296245Issue 1-5 en13/06/2008




The user can confirm (or change) the proposed values that haveautomatically been detected by Flexi BTS.

Management data





This feature has no impact on system performance and capacity.

6.4 RAN1670: UltraSite EDGE Wideband Combiner forWCDMA Refarming

6.4.1 Introduction

Note


The special UltraSite EDGE wideband combiner is a unit needed foradditional TX combining in 2G BTS when common antenna line sharing isdone using Multiradio combiner (MRC).

This special wbc unit is only needed when MRC is used and Flexi WCDMABTS modules are placed inside the UltraSite EDGE cabinet using thehorizontal installation kit (FMUB).




The UltraSite EDGE multimode BTS solution can be fully exploited in aWCDMA refarming application when MRC is used for common antennaline sharing - all the needed Flexi WCDMA modules and additional wbcrequired by MRC can be fitted inside the UltraSite EDGE cabinet (newIDCA/ODCA versions). This does not only lead to excellent cost and spaceefficiency, but also prevents the risk for increased site lease cost since nonew cabinet is needed with a WCDMA introduction.


Multiradio combiner (MRC) makes it possible to use common feeders andantennas for GSM and WCDMA systems operating on the samefrequency band. This solution provides a cost-efficient way to add aWDCMA BTS to an existing GSM site by combining signals of the twoBTSs into one antenna system. The MRC concept requires all TX signalsof one BTS to be combined in one antenna feeder. Therefore, the dualduplex setup in GSM BTS, which is typically used when having more thanone TRX per sector, has to be removed and an additional widebandcombining stage needs to be added (not applicable with cavity combining).When using MRC and having Flexi WCDMA modules placed inside theUltraSite EDGE BTS using the horisontal installation kit (FMUB), thespecial wideband combiner must be used to perform the additionalcombining of GSM TX signals. The new wbc is placed to the basebandunit rack of the BTS.

6.4.3 System impact


Exisiting UltraSite EDGE wide combiners do not support the additional TXcombining required by MRC when Flexi WCDMA modules are placedinside the UltraSite EDGE cabinet using the horisontal installation kit(FMUB).


The special UltraSite EDGE wbc is only applicable when MRC is used andFlexi WCDMA modules are placed inside the UltraSite EDGE BTS usingthe horizontal installation kit (FMUB). FMUB is only supported by the newversion of IDCA/ODCA cabinets (ver.2xx onwards). The special wbc unitcontains the additonal interconnecting cables needed with it.

DN70296245Issue 1-5 en13/06/2008




The special UltraSite EDGE wbc is only applicable when MRC is used andFlexi WCDMA modules are placed inside the UltraSite EDGE BTS usingthe horizontal installation kit (FMUB).


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06ED1

- - WBTS4.0ED1

- - - - - - -




OSW RAN - -




NMS interfaces

No impact.


TBD

Management data








6.5 RAN1223: 40W Remote Radio Head 2100

6.5.1 Introduction

Note


Flexi WCDMA BTS Mast Head RF Module can be used in various indoorand outdoor installation options (such as wall, pole, and mast) and siteapplications (mini, macro and distributed site solution). The form factor iswith antenna shape.


. Fully outdoor/indoor capable Mast Head RF Head for Wide Areasolutions

. Optical link between Head and System Module

. Supports Obsai/RP3 -interface (similar interface than in FlexiWCDMA BTS RF Module)

. No fans

. Supports only DC -voltage

. AC supply can be used when external AC/DC converter with amechanical kit is connected to Remote Radio Head

. Support for two carriers

. HW is 50W Power amplifier (40W in antenna connector)

. 20W (in antenna connector) is default o/p power. 40W carrier powersupport (RAN1002) and second carrier support (RAN1001) arelisenced features

. Operating temperature range -33 - +55C

. Antenna shape

DN70296245Issue 1-5 en13/06/2008



6.5.3 System impact


The Flexi Single and Dual RF modules have been used as remote headsolutions.


New Remote Radio Head HW is needed.




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06ED1

- - WBTS4.0ED1

- - - - - - -




OSW RAN - -




NMS interfaces

No impact.


The parameters will be confirmed during comissioning.



Management data






6.6 RAN1222: External GPS Synchronisation for FlexiBTS System Module Rel 1

6.6.1 Introduction

External GPS syncronisation is needed for the WCDMA BTSs with I-HSPAand also for other customers that have an Ethernet transport solution.


The operators that utilise I-HSPA or Ethernet transport need GPSsynchronisation.


The BTS will get sync signal (pps) from external GPS device. GPS signalis needed together with I-HSPA module or when the Ethernet transport isin use.

The GPS device is overvoltage-protected by a mediator box (FSEG) thatincludes the following functionalities and parts:

. Power output (12VDC) to the GPS receiver.

. GPS signal transfer from GPS receiver to MDR26 connector inSystem Module

. Overvoltage protection (4KV) must be guaranteed according tostandard for mast devices which prevents System Module failures.

. IP55 protection.

DN70296245Issue 1-5 en13/06/2008



. Two cables are in use (Sync in from mediator box to Rel1 SystemModule and 48V from system Module to Mediator box voltageconversion to GPS receiver (+ 12V)).

. In addition to the Mediator box, integrated GPS receiver andantenna kit(FYGA) is needed. A separate mounting kit (FYMA) canbe used for installation.

. Optionally 30m (FYHA) or 100m (FYHB) cables can be usedbetween the GPS receiver and the Mediator box.

6.6.3 System impact


There has been no GPS sync available earlier.


This solution is needed together with Rel1 system module.




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 - - WBTS4.0

- - - - - - -




OSW RAN - -






NMS interfaces

No impact.


WN3.2 and WN3.3 user had to select the correct sync source via FlexiTransport Module. If GPS sync is in use , it will be automatically used as async source.

Management data






6.7 RAN1463: Support for FRMB/C Unit in FlexiWCDMA BTS

6.7.1 Introduction

Note


FRMB/C Flexi Rectifier Module 6000 is an OEM-based rectifier solution forall Flexi WCDMA BTS-based applications. FRMB/C is equal to FlexiWCDMA BTS module in terms of dimensions, weight, fixing points andoutlook. FRMB/C will be available in indoor IP20 and outdoor IP55versions. FRMB/C maximum output power is 6kW providing DCconnection point to maximum 2 BTSs and 3 external battery strings.

DN70296245Issue 1-5 en13/06/2008



Benefits for the operator:

FRMB/C allows to supply multiple BTSs or different BTS generations froma single unit still providing sufficient charging capacity for bigger batterybanks.


FRMB/C consist of a maximum of three 2kW rectifier modules inside 3Uhigh casing. The amount of rectifier units is configurable on a need basis.The same 3U high casing also includes the DC-distribution (BTS andbattery breakers), controller unit with display, LMP port and space foroptional overvoltage protector.

6.7.3 System impact


This feature is a more powerful alternative for FPAA.






RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06ED1

- WBTS4.0ED1

WBTS4.0ED1

- - - - - - -




OSW RAN - -




No impact.


NMS interfaces

No impact.


No impact.

Management data





No impact.


No other impacts.

6.8 RAN1139: FADB Flexi Multiradio Combiner for900MHz

6.8.1 Introduction

Note


This feature provides a Multiradio Combiner for 900MHz.

DN70296245Issue 1-5 en13/06/2008




Enables sharing of one antenna system with two BTSs operating on thefrequency band.


Multiradio combiner (MRC) makes it possible to use common feeders andantennas for GSM and WCDMA systems operating on the samefrequency band. This solution provides a cost-efficient way to add aWDCMA BTS to an existing GSM site by combining signals of the twoBTSs into one antenna system. Using of MRC has minimal performanceimpact on WCDMA BTS. Low DL insertion loss of 0.5dB means only minorperformance impact in transmit power. MRC losses in UL path arecompensated with an MHA and if the BTS supports an adjustable front endgain (Flexi WCDMA BTS and UltraSite/Flexi EDGE BTS), impact onsensitivity is marginal.

The MRC concept requires all TX signals of one BTS to be combined inone antenna feeder. Therefore, the dual duplex setup in GSM BTS, whichis typically used when having more than one TRX per sector, has to beremoved and an additional wideband combining stage needs to added(not applicable with cavity combining). UL performance is maintained withan MHA in a similar way as with WCDMA BTS.

6.8.3 System impact


Both BTSs need their own antennas, MHAs and feeders.


The MRC unit can be installed to a standard 19" mechanics or inside aFlexi 2U casing (FTMA). When MRC is installed outside the 2G BTS, thecabling between the MRC and the two BTSs is done using cable kits foundfrom the current jumper cable portfolio. In case of installing the MRC insidethe UltraSite EDGE or CityTalk BTSs, the needed installation kits includerequired jumper cables for MRC. When using an MRC and having FlexiWCDMA modules placed inside the UltraSite EDGE BTS using thehorizontal installation kit (FMUB), a special wideband combiner must beused to perform the additional combining of GSM TX signals - thiscombiner also includes the additonal interconnecting cables needed withit.






RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06ED1

- - WBTS4.0ED1

- - - - - - -




OSW RAN - -



Multiradio Combiner is activated with BTS Site EM check box duringcommissioning.

Management data





This feature has no impact



DN70296245Issue 1-5 en13/06/2008



6.9 RAN1079: FACB Flexi Multiradio Combiner for850MHz

6.9.1 Introduction

Note


This feature provides a Multiradio Combiner for 850MHz.




Multiradio combiner (MRC) makes it possible to use common feeders andantennas for GSM and WCDMA systems operating on the samefrequency band. This solution provides a cost-efficient way to add aWDCMA BTS to an existing GSM site by combining signals of the twoBTSs into one antenna system. Using of MRC has minimal performanceimpact on WCDMA BTS. Low DL insertion loss of 0.5dB means only minorperformance impact in transmit power. MRC losses in UL path arecompensated with an MHA and if the BTS supports an adjustable front endgain (Flexi WCDMA BTS and UltraSite/Flexi EDGE BTS), impact onsensitivity is marginal.

The MRC concept requires all TX signals of one BTS to be combined inone antenna feeder. Therefore, the dual duplex setup in GSM BTS, whichis typically used when having more than one TRX per sector, has to beremoved and an additional wideband combining stage needs to added(not applicable with cavity combining). UL performance is maintained withan MHA in a similar way as with WCDMA BTS.

6.9.3 System impact


Both BTSs needs their own antennas, MHAs and feeders.




The MRC unit can be installed to a standard 19" mechanics or inside aFlexi 2U casing (FTMA). When MRC is installed outside the 2G BTS, thecabling between MRC and the two BTSs is done using cable kits foundfrom current jumper cable portfolio. In case of installing the MRC inside theUltraSite EDGE or CityTalk BTSs, the needed installation kits includerequired jumper cables for MRC. When using MRC and having FlexiWCDMA modules placed inside the UltraSite EDGE BTS using thehorizontal installation kit (FMUB), a special wideband combiner must beused to perform the additional combining of GSM TX signals - thiscombiner also includes the additonal interconnecting cables needed withit.




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06ED1

- - WBTS4.0ED1

- - - - - - -




OSW RAN - -



Multiradio Combiner is activated with BTS Site EM check box duringcommissioning.

Management data



DN70296245Issue 1-5 en13/06/2008








This feature has no other impact

6.10 RAN1462: FAGB Flexi Multiradio combiner for2100MHz

6.10.1 Introduction

This feature provides a MultiRadio Combiner for 2100MHz.




Multiradio combiner (MRC) makes it possible to use common feeders andantennas for two WCDMA systems operating on the same frequencyband. This solution provides a cost-efficient way to add new WDCMA BTSto an existing site by combining signals of the two BTSs into one antennasystem. Using of MRC has a minimal performance impact on WCDMABTS. Low DL insertion loss of 0.5dB means only minor performancedegradation in transmit power. The MRC losses in the UL path arecompensated with an MHA and if the BTS supports an adjustable front endgain (Flexi WCDMA BTS and UltraSite WCDMA BTS), the degradation oforiginal sensitivity is marginal.





Both BTSs need their own antennas, MHAs and feeders.


This feature does not require any new or additional HW. New cable kits arenot needed. All required jumper cables can be found from the currentportfolio.




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 - WBTS4.0

WBTS4.0

- - - - - - -




OSW RAN - -



Multi Radio Combiner is activated via BTS Site EM check box duringcommsioning.

Management data




DN70296245Issue 1-5 en13/06/2008







6.11 RAN1127: Extended Cell (180km)

6.11.1 Introduction

The cell radius is extended up to 180 km.


This feature provides an economical method to build WCDMA coverage inrural areas.


3G extended cell feature can be used to efficiently provide coverage incoastal and rural areas, where big capacity or high data rates are notneeded. Furthermore, new lower WCDMA frequency bands 850 MHz and900 MHz make it possible to achieve larger cell sizes and also utilise theexisting GSM cell raster.

The feature is also needed with optical repeater cases (train tunnels, FlexiWCDMA BTS remote RF heads) to overcome the decreased cell radiuscaused by the delay of optical cables. BTS has the main functionality ofthis feature. The feature is activated from the RNC/NetAct with the CellRange parameter. The operator has a possibility to modify the Cell RangeParameter up to 180 km.

In 3GPP, RACH/AICH detection & transmit power control delays define thecell range. SW implementation support up to 180 km cell range. TheExtended Cell is verified up to 150 km in RAS06 case of 2-port receiverdiversity. The feature activation is based on SW licences.





The maximum cell range is 20 km.


For UltraSite WCDMA BTS, it is advisable to have at least one WSPC foreach Extended cell (+WSP for normal CCCH) for optimal CE consumption.




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 RN3.0 WBTS4.0

WBTS4.0

- - OSS4.2 - - - -






This feature has no impact on Control and user plane.


NMS interfaces

Maximum value for cell range extended to 180km.


Maximum value for cell range extended to 180km.

DN70296245Issue 1-5 en13/06/2008



Management data


Cell range PRACH PROPAGATION DELAYCLASS 0

PRACH PROPAGATION DELAYCLASS 1
























6.12 RAN923: Pico WCDMA BTS with EthernetTransport

6.12.1 Introduction

Note


Pico WCDMA BTS is a very small indoor BTS. It has a single 5MHz carrier,the carrier frequency can be freely selected within the frequency band bySW and two-way receive diversity is supported. The antenna isintegrated., It is also possible to use external antennas.

Pico WCDMA BTS with Ethernet Transport interface has been designed tobe used together with the IP transmission.


The Pico WCDMA BTS is designed to enhance coverage and capacityand serve an additional number of indoor users within a localisedcoverage area.

For example, Pico WCDMA BTS can be used to cover white spots whereno coverage is supported by macro BTSs. It can also be used to provideadded capacity in local indoor hot spots and offices, and thereby improvethe overall quality in the 3G RNW by offloading the existing macro-basedNW. It is also possible to build cost- effcient large indoor coveragesolutions using Pico WCDMA BTS together with a small DistributedAntenna System (DAS) which can typically include four to eight antennas.

IP Transport gives operator savings in the transmission costs.

DN70296245Issue 1-5 en13/06/2008




The Pico WCDMA BTS is a low-power, high-capacity 3G base station,intended for voice and high-speed data services in indoor environments.The Pico WCDMA BTS is a complete Pico BTS unit with all functionalitiesin one single hardware unit that is easy to install and maintain. The PicoWCDMA BTS operates on a single 5MHz channel and it supports onecarrier and one sector with SHO between other BTSs in the RAN.

A complete Pico WCDMA BTS consists of:

. Support unit, including AC/DC converter

. BTS unit

. Internal antenna (optional)

. Cover

Pico WCDMA BTS unit with IP connect capability. Transmission interface10baseT/100baseT Ethernet connections from the Iub/LMT connector.

When using the BTS for IP Iub, then the physical Ethernet port of the unitwill be used for the connection between IP-BTS and the centralisedfunctions as OMC and RNC.

Remote management can be done either with NetAct or with a remoteLMT (for example, LMT connected to Iub LAN). If there is a need toconnect an LMT locally on-site, when the Pico WCDMA BTS is connectedto IP transport, then the BTS console port must be used. The BTS consoleport is a serial port which can be accessed from a PC using a standardRS485 connector. If the PCs does not have built-in RS485 ports then it ispossible to use a converter between USB and RS485 interfaces.

High quality oscillator in BTS

Pico WCDMA BTS relies on an oven-controlled reference oscillator withthe following specifications:

. Frequency drift up to 100 ppb per year due to aging

. Frequency drift up to 20 ppb due to temperature variations within thePico WCDMA BTS specification

Since the requirements for a local area BTS is 100 ppb there is no need tocompensate for a drift due to temperature variations.



However the BTSs reference oscillator needs to be compensated for a driftdue to aging to keep frequency accuracy within 3GPP specifications.

Pico WCDMA BTS with the IP Transport this is done with timestampscoming from an NTP server.

Timestamp packet

The Network Time Protocol (NTP) is a standard which makes it possible tosynchronise the clocks of different devices over an Ethernet network.

To compensate the frequency drift due to ageing the Pico WCDMA BTSwill depend on access to NTP server(s) located at the IP backbone.

The NTP server(s) used for Pico WCDMA BTS shall be of stratum level 2or better.

Figure 37. Nokia Pico WCDMA BTS



The current Pico WCDMA BTS offers the two ATM Transport interfaces:E1/T1/JT1 and STM-1. This feature offers a third option to the Iub transportinterfaces, IP transport in Ethernet.

DN70296245Issue 1-5 en13/06/2008




This feature is a HW feature for IP Pico WCDMA BTS.


This feature offers HW to Ethernet Tranpsort. To make it an IP Pico BTS itmust be used together with RAN1594: Pico WCDMA BTS Rel.2 SW.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06ED1

- - - WP2.0 - - - - - -




OSW RAN - -


Management data




6.13 RAN1309: WMHD Mast Head Amplifier

6.13.1 Introduction

WMHD Mast Head Amplifier is an upgrade on WMHC




WMHD adds the RET output connector and AISG controlling to WMHC.Remote antenna tilt users save RET bias-t and installing time.

RF performance, outlook and price are the same as with WMHC.


The WMHD is a dual amplifier, referred to as a UNIT, which comprises twoidentical amplifiers, referred to as LNA1 and LNA2. A general reference foreither LNA1 or LNA2 is MHA. Physically this means that there is oneenclosure with two BTS and ANT ports and one MHA for both branches.The purpose of the WMHD Standard Gain Dual Masthead Amplifier is tocompensate feeder losses with minimum over gain, and lowest possiblenoise contribution, The net effect is to optimise WCDMA BTS receive pathsensitivity.

This product has a fixed 12dB gain for both branches. The unit is designedfor duplex operation. This requires the use of duplex filters or a filtersystem within the unit to provide a transmit only path and receive only paththrough the LNA components.

The WMHD is capable of operating in AISG mode and current alarmmode.

Failure bypass is provided in case of LNA failure. The purpose of thefailure bypass mode is for the MHA to maintain an RF signal pass evenwhen an MHA alarm occurs or no DC power is present. On power up orpower recycle of the MHA, alarms reset and the unit attempts a normaloperation.

WMHD also provides output to the antenna tilt motor or another devicethrough the RET connector and additionally through the ANT1 port.



WMHC is outdated. There is no AISG support and no RET connector.



DN70296245Issue 1-5 en13/06/2008




This feature has an interdependency with feature RAN908: Flexi WCDMABTS AISG MHA Support.


RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06 - WBTS4.0

WBTS4.0

- - - - - - -




OSW RAN - -


This feature has no impact on signalling interfaces


NMS interfaces

No impact.


No impact.

Management data







12dB RX gain is achieved. Failure bypass is provided in case of LNAfailure or power brake, on bypass mode. There is 3dB of RX InsertionLoss. TX Insertion Loss is 0,5 dB.


No other impacts

6.14 RAN1594: Pico WCDMA BTS Rel.2 sw

6.14.1 Introduction

Note


Pico WCDMA BTS Rel.2 SW main features are IP Transport and NetActsupport. Pico WCDMA BTS Rel.2 SW can be used together with thefollowing products:

. Pico WCDMA BTS with E1

. Pico WCDMA BTS with STM-1

. Pico WCDMA BTS with Ethernet


The IP Transport option for the Pico WCDMA BTS offers a cost-efficienttransmission for the indoor solution.

With NetAct support the operator does not need a separate networkmanagement tool for the Pico WCDMA BTS.


Pico WCDMA BTS IP SW offers for the operator:

DN70296245Issue 1-5 en13/06/2008



. IP Transport together with the ATM-based Nokia RNC runningRAS05 or RAS06 using Transmission Gateway Unit TGU

. Interoperability with NetAct

. Installation options of Pico WCDMA BTS units either. directly on the IP backbone (that is, with public IP addresses). or behind firewalls protecting, for example, office LANs, home

LAN or other kinds of private LANs.

. IP security protecting both the centralised UTRAN functions (forexample, RNC and OMC) and the Pico WCDMA BTS units.

To enable a connection to RNC without IP interconnect a new transmissiongateway unit (TGU) makes the ATM/IP protocol conversion to the IP PicoWCDMA BTS.

IP security

To enable a connection of Pico WCDMA BTS units using a public IPNetwork a type of VPN client is implemented inside the BTS units; ThisVPN client enables an IPsec protected communication between the BTSunit and the centralised functions like RNC and NetACt.

The VPN tunnels from the BTS units need to be terminated in a SecurityGateway SGW located between the "public" IP network and the sensitivecentralised functions such as RNC and OMC. The SGW also acts as afirewall in front of the RNC/TGU and the NetAct, thus protecting thesesensitive centralised functions from intrusion and attacks.

To simplify the management of the VPN connectivity, each BTS unitestablishes two VPN tunnels to the SGW:

. one tunnel for Iub C-plane (NBAP and ALCAP) and OAM

. one tunnel for Iub U-plane (user plane signaling)

In the BTS, each tunnel end-point has a separate IP address, that is, onprotected LAN inside of the SGW, the BTS appears to have two differentIP addresses. The BTS IP address on the LAN/WAN where it is physicallyconnected does not show up inside the SGW; That IP address can beeither achieved with DHCP or fixed assigned.



Network topology

Figure Network architecture of WCDMA Pico BTS shows the proposednetwork architecture for the deployment of Pico WCDMA BTS for an IPNetwork. All other connections shown in the figure are IP connectionsusing, for example, Ethernet or Gigabit Ethernet. The following networkelements are shown in the figure:

. Pico WCDMA BTS; Pico WCDMA BTS unit with IP interconnect

. FW; Firewall protecting some kind of private LAN, for example, ahome LAN or office LAN. A firewall is most probably using NAT fortranslating local addresses of the LAN to public addresses used forthe public IP backbone.

. SGW "Security gateway", protecting the RNC/TGU from the publicIP backbone. The SGW handles IKE negotiations with, for examp,BTSs and terminates IPsec tunnels to the BTSs.

. TGU; The transmission gateway unit (TGU) translates from the ATM-based interface from the RNC to the IP network protocols used forcommunication with the IP BTS. For OAM of the TGUs, they shouldbe connected to an OAM LAN, where they can be monitored fromTGUM.

. TGUM; a tool for monitoring the state of one or more TGUs

. RNC; a UTRAN radio network controller (RNC) with ATMinterconnect capability the BTSs.

. OMC Operating and Maintenance Center for OA&M of the UTRANnetwork, NetAct.

. LMT Local maintenance terminal, a SW tool for managing a singleBTS at the time. The LMT may either be run locally on-site, fromOMC (via IPoA connections terminated in RNC) or from a PCconnected to the IUB LAN.

. DHCP Dynamic Host Configuration Protocol Server; which can beused by the nodes to retrieve local addresses on the different IP LANor a public IP addresses for nodes connected to the IP backbone.

. DNS server used by BTS to look up, for example, IP addresses ofNTP servers and other public IP addresses needed by the BTS. IPaddresses on Iub LAN or OAM LAN are not handled with public DNSservers.

. NTP Time Server; used by BTS for time and frequencysynchronisation.

DN70296245Issue 1-5 en13/06/2008



Transmission gateway unit (TGU)

The IP network solution described herein has been designed to enable anintroduction of IP transport to Pico WCDMA BTS units without having tomodify the RNC.

This is solved by the introduction of the transmission gateway unit (TGU),which is a translator between ATM- based transmission protocols used bythe RNC and the IP-based transmission protocols to the BTS. In essencethe TGU will (partly) hide the IP transport network for the RNC, thoughsome minor adjustments in the RNC may be needed (for example,parameter settings and timer settings)

The TGU is a protocol translator where

. for Iub C-plane it translates between ATM-AAL5 and IP-UDP

. for Iub U-plane it translates between ATM-AAL2 and IP-UDP

The transmission gateway unit TGU is based on a 2U compact PCIchassis. This chassis holds:

. 1-4 TGU processing boards

. 2 power supply modules (for redundancy)

. 2 fans (for redundancy)

Default configuration is 2 TGU processing boards per TGU.

Interfaces:

. STM-1 Interface. 4 STM-1 interfaces in each processing board. Connector type: SC. Interface type: STM-1 155 Mbps, ITU-T G.957-S1.1

. Gigabit Ethernet interfaces. 2 per processing board. interface 0 is used for OAM. interface 1 is used for IP-Iub

. Ethernet Interface. Connector type: RJ-45. Interface type: Ethernet 1000 Mbps, 1000 BASE-T



. Serial link with RS232 electrical levels to connect to a console. Connector type: Mini-DIN-8. Interface type: RS232. Configuration: 9600 baud, 8 data bits, No parity,1 stop bit, No

flow control

. Power Interface. Connector Type: IEC320 type C15. Interface Type: 230V AC or 100V AC or 48 V DC, max 500W

TGU Capacity

Each TGU board can handle up to 65535 "connections" between ATM andIP, where:

. Each AAL5 PVC consumes one connection.

. Each AAL2 PVC can consume up to 248 connections

Note that each fully configured AAL2 PVC consumes 248 connections(one per possible CID) regardless if these connections (CID) are in use ornot.

The number of IP-BTSs possible to connect to a TGU depends on howmany connections each IP-BTS requires:

. With one fully configured UserDataPort per BTS the capacity is 150IP-BTS per TGU board (not limited by "connections" but bythroughput)

. with two fully configured UserDataPorts per BTS the capacity is 130IP-BTS per TGU board

. with three fully configured UserDataPorts per BTS the capacity is 85IP-BTS per TGU board

. with four fully configured UserDataPorts per BTS the capacity is 65IP-BTS per TGU board

DN70296245Issue 1-5 en13/06/2008



Figure 38. Network architecture of WCDMA Pico BTS



Pico WCDMA BTS currently has ATM transmission with E1 or STM-1interface. The management is done with the Pico-specific tool.


This feature does not require any new or additional HW from the PicoWCDMA BTS. Release 1 ATM Pico WCDMA BTS can be used with thisfeature.



DHCP

LMTLMT

IP network topology for deployment of WCDMAPico BTS for IP Network with Nokia RAN

TGU lub LAN SGW FW

OMC TGUM

OAM LAN

RNC

DNS NTP

Pico BTS

IP "backbone"

Pico BTS

Office LAN




RAS RNCBTSUltra

BTSFlexi

BTSPico AXC


Release

RAS06ED1

RN3.0 - - WP2.0 - OSS4.2 - - - -




OSW RAN


Management data




DN70296245Issue 1-5 en13/06/2008



Date post:	27-Nov-2015
Category:	Documents
Upload:	alegarcab
View:	91 times
Download:	15 times

RAS06 Feature Descriptions Dn70296245 1-5 En

Documents