Feature Ru51

Nokia Siemens Networks WCDMA RAN, rel. RU20, operating documentation, pre-release, issue 2

WCDMA RAN, rel. RAS05.1, feature descriptions

DN0934844

Issue 01Approval Date 2009/09/04

2 DN0934844Issue 01


Id:0900d8058060a37e

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

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

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

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

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

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

Copyright © Nokia Siemens Networks 2009. All rights reserved

f Important Notice on Product Safety Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts may also have elevated operating temperatures.

Non-observance of these conditions and the safety instructions can result in personal injury or in property damage.

Therefore, only trained and qualified personnel may install and maintain the system.

The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to comply with the applicable safety standards.

The same text in German:

Wichtiger Hinweis zur Produktsicherheit

In elektrischen Anlagen stehen zwangsläufig bestimmte Teile der Geräte unter Span-nung. Einige Teile können auch eine hohe Betriebstemperatur aufweisen.

Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverlet-zungen und Sachschäden führen.

Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die Anlagen installiert und wartet.

Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.

DN0934844Issue 01

3


Id:0900d8058060a37e

Table of ContentsThis document has 306 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1 Radio resource management and telecom features . . . . . . . . . . . . . . . 251.1 Radio Resource Management and Telecom features overview . . . . . . 251.1.1 Radio Resource Management and Telecom features overview . . . . . . 251.1.2 Further information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.2 RAN223: UE Based A-GPS Using External Reference Network. . . . . . 291.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.2.2 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.3 RAN384 and 814: Emergency and Intelligent Emergency Call Inter-system

Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331.3.2 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331.3.3 Configuration requirements for EMISHO and intelligent EMISHO. . . . . 351.3.4 Functional restrictions on EMISHO and intelligent EMISHO . . . . . . . . . 361.3.5 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361.3.6 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361.3.6.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361.4 RAN875: Network Based A-GPS Using External Reference Network. . 371.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371.4.2 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2 Transmission and transport features . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.1 RAS05.1 transmission and transport features overview . . . . . . . . . . . . 402.1.1 Further information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.2 RAN165: IP Based Control Plane at Iu and Iur . . . . . . . . . . . . . . . . . . . 412.2.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.2.1.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.2.1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.2.1.3 Resource requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.2.1.4 Interaction with other features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.2.1.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.2.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.2.2.1 Using IP-based control plane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.2.2.2 Activating IP-based control plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.2.2.3 Verifying IP-based control plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.2.2.4 Deactivating IP-based control plane . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.2.2.5 Feature management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.2.2.6 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.2.2.7 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.2.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.3 RAN324: Dynamic HSDPA Transport Scheduling. . . . . . . . . . . . . . . . . 452.3.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.3.1.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.3.1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 DN0934844Issue 01


Id:0900d8058060a37e

2.3.1.3 Resource requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.3.1.4 Interaction with other features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.3.1.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.3.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.3.2.1 Using Dynamic HSDPA Transport Scheduling . . . . . . . . . . . . . . . . . . . . 482.3.2.2 Activating Dynamic HSDPA Transport Scheduling. . . . . . . . . . . . . . . . . 482.3.2.3 Verifying Dynamic HSDPA Transport Scheduling . . . . . . . . . . . . . . . . . 482.3.2.4 Deactivating Dynamic HSDPA Transport Scheduling. . . . . . . . . . . . . . . 492.3.2.5 Feature management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.3.2.6 Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.3.2.7 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.3.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.3.4 Static rate control for the HSDPA data . . . . . . . . . . . . . . . . . . . . . . . . . . 502.3.4.1 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.3.5 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.4 RAN717: Iu-PS IP Quality of Service Support (DiffServ in GTPU) . . . . . 532.4.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.4.1.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.4.1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.4.1.3 Resource requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.4.1.4 Interaction with other features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.4.1.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.4.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.4.2.1 Using DiffServ in GTPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.4.2.2 Activating Iu-PS IP Quality of Service Support (DiffServ in GTPU) . . . . 552.4.2.3 Verifying DiffServ in GTPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.4.2.4 Deactivating DiffServ in GTPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.4.2.5 Feature management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.4.2.6 Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.4.2.7 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562.4.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562.5 RAN935: BTS AAL2 Multiplexing for Flexi WCDMA BTS. . . . . . . . . . . . 572.5.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572.6 RAN939: Flexbus Interface for Flexi WCDMA BTS . . . . . . . . . . . . . . . . 582.6.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582.7 RAN940: E1 Interface for Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . . 592.7.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592.8 RAN941: JT1 Interface for Flexi WCDMA BTS. . . . . . . . . . . . . . . . . . . . 602.8.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602.9 RAN942: SDH STM-1 Interface for Flexi WCDMA BTS . . . . . . . . . . . . . 612.9.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612.9.2 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . . 612.9.3 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612.10 RAN944: Use of GSM Transmission (Flexi WCDMA BTS) . . . . . . . . . . 622.10.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622.11 RAN946: T1 Interface for Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . . 632.11.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

DN0934844Issue 01

5


Id:0900d8058060a37e

2.12 RAN1020: Route Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642.12.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642.12.1.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692.12.1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692.12.1.3 Resource requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692.12.1.4 Interaction with other features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702.12.1.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702.12.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702.12.2.1 Using Route Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702.12.2.2 Activating Route Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702.12.2.3 Verifying Route Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712.12.2.4 Deactivating Route Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712.12.2.5 Feature management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712.12.2.6 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712.12.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712.13 RAN1062: IMA (Flexi WCDMA BTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 722.13.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722.14 RAN1086: AXC ATM interface oversubscription . . . . . . . . . . . . . . . . . . 732.14.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732.14.1.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742.14.1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752.14.1.3 Resource requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752.14.1.4 Interaction with other features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752.14.1.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752.14.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762.14.2.1 Using AXC ATM interface oversubscription. . . . . . . . . . . . . . . . . . . . . . 762.14.2.2 Activating AXC ATM interface oversubscription . . . . . . . . . . . . . . . . . . 762.14.2.3 Verifying AXC ATM interface oversubscription . . . . . . . . . . . . . . . . . . . 762.14.2.4 Deactivating AXC ATM interface oversubscription . . . . . . . . . . . . . . . . 762.14.2.5 Feature management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762.14.2.6 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762.14.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3 Operability features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783.1 RAS05.1 operability features overview . . . . . . . . . . . . . . . . . . . . . . . . . 783.1.1 Further information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793.2 RAN893: Alarm Architecture for Flexi WCDMA BTS . . . . . . . . . . . . . . . 803.2.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803.2.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813.2.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823.3 RAN369: Automated IP Address Configuration for BTS . . . . . . . . . . . . 833.3.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833.3.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833.3.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.4 RAN96: Automated RNS Split . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853.4.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853.4.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 863.4.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6 DN0934844Issue 01


Id:0900d8058060a37e

3.5 RAN882: AXC ATM Layer Configuration Management for BTS. . . . . . . 893.5.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 893.5.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903.5.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903.6 RAN1290: AXC Local Account Mass Change . . . . . . . . . . . . . . . . . . . . 913.6.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913.6.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913.6.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923.7 RAN1091: BTS SW Management with RNC/NEMU Mediation . . . . . . . 933.7.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 933.7.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943.8 RAN557: Combined HW Management for Flexi WCDMA BTS and its

Transport Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953.8.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953.8.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953.9 RAN817: Combined SW Management for Flexi WCDMA BTS and its

Transport Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963.9.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963.9.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 973.9.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983.10 RAN1040: Data Backup for AXC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993.10.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 993.10.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003.11 RAN1167: Domain Specific Access Class Restriction . . . . . . . . . . . . . 1013.11.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013.11.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1023.12 RAN619: Flexible Connection of VPCs for WBTS Object in RNC . . . . 1053.12.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053.12.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063.13 RAN812: Local User Authentication for BTS . . . . . . . . . . . . . . . . . . . . 1093.13.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093.13.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093.13.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113.14 RAN1302: Non-Performing Cell Recovery . . . . . . . . . . . . . . . . . . . . . . 1123.14.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123.14.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133.15 RAN801: Radio Network Access Regulation Function . . . . . . . . . . . . . 1153.15.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153.15.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1163.16 RAN375: Read Only-Access for RNC & AXC Element Managers . . . . 1183.16.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1183.16.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1193.16.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1203.17 RAN615: Remote User Event Log Management for AXC . . . . . . . . . . 1213.17.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1213.17.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1223.17.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

DN0934844Issue 01

7


Id:0900d8058060a37e

3.18 RAN183: Remote User Event Log Management for RNC . . . . . . . . . . 1243.18.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243.18.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1253.18.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1263.19 RAN617: Remote User Information Management for AXC . . . . . . . . . 1273.19.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1273.19.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1283.19.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1333.20 RAN181: Remote User Information Management for RNC . . . . . . . . . 1343.20.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1343.20.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1353.20.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1403.21 RAN1152: WCEL Lock and Unlock during RNW Plan Activation . . . . 1413.21.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413.21.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1423.22 RAN1453: Iu Link Break Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 1433.22.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1433.22.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1443.23 RAN1193: Plan based RNC ATM/IP Configuration . . . . . . . . . . . . . . . 1453.24 RAN1181: RNC NEMU Firewall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1463.25 BTS Channel Element Capacity Measuring feature description . . . . . 1473.25.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1483.25.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1483.25.3 Resource requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1483.25.4 Interaction with other features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1493.25.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1493.26 RAN1153: Complementary Counters in RAS05.1 . . . . . . . . . . . . . . . . 1503.26.1 Introduction to RAN1153: Complementary Counters in RAS05.1 . . . . 1503.26.2 System impact of RAN1153: Complementary Counters in RAS05.1. . 1503.26.2.1 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1503.26.2.2 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . 1503.26.3 RAN1153: Complementary Counters in RAS05.1 functional description .

1503.27 Radio Connection Performance Measurements for RLC TM and UM and

Outer Loop Power Control feature description. . . . . . . . . . . . . . . . . . . 1523.27.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1523.27.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1523.27.3 Resource requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1523.27.4 Interaction with other features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533.27.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533.28 RAN1163: Iu-PS Throughput Measurement for GTP Traffic . . . . . . . . 1543.28.1 Iu-PS Throughput Measurement for GTP Traffic feature description . 1543.28.1.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1553.28.1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1563.28.1.3 Resource requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1563.28.1.4 Interaction with other features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1563.28.1.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

8 DN0934844Issue 01


Id:0900d8058060a37e

3.28.2 Main functionality of Iu-PS Throughput Measurement for GTP Traffic . 1573.28.2.1 Using the Iu-PS throughput measurement for GTP traffic . . . . . . . . . . 1573.28.2.2 Activating the Iu-PS throughput measurement for GTP traffic . . . . . . . 1573.28.2.3 Verifying the Iu-PS throughput measurement for GTP traffic . . . . . . . . 1573.28.2.4 Deactivating the Iu-PS throughput measurement for GTP traffic . . . . . 1573.28.2.5 Feature management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573.28.2.6 Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573.28.2.7 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573.29 Downlink Packet Data Throughput for Subscriber and Equipment Trace

feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1583.29.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593.29.2 Resource requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593.29.3 Interaction with other features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1603.29.4 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1603.30 RAN189: Automatic Definition of Neighbouring Cells . . . . . . . . . . . . . . 1613.31 CPICH Ec/No Coverage Measurements and Optimisation feature descrip-

tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1633.31.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1643.31.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1643.31.3 Resource requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1643.31.4 Interaction with other features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1643.31.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1643.32 RAN1186: RNC450. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1653.33 RAN1514: Number of Supported HS-DSCH Users in RNC196 and

RNC450 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1663.34 RAN1036: RNC196 Capacity Upgrades . . . . . . . . . . . . . . . . . . . . . . . . 1673.35 RAN900: Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1693.36 RAN999: Flexi WCDMA BTS 1700/2100 . . . . . . . . . . . . . . . . . . . . . . . 1713.37 RAN916: Flexi WCDMA BTS 900. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723.38 RAN917: Flexi WCDMA BTS 850. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733.39 RAN907 Antenna line supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743.40 RAN1046 Feederless site solution for Flexi WCDMA BTS. . . . . . . . . . 1753.41 RAN905 Flexi WCDMA BTS MHA support. . . . . . . . . . . . . . . . . . . . . . 1763.42 RAN1093 HSDPA 16QAM SW licence support . . . . . . . . . . . . . . . . . . 1773.43 RAN912: Licence Based BTS Channel Capacity . . . . . . . . . . . . . . . . . 1783.44 RAN943: Synchronising WCDMA RAN (Flexi WCDMA BTS) . . . . . . . 1793.45 RAN1000: Baseband Extension for Flexi WCDMA BTS. . . . . . . . . . . . 1803.46 RAN1133: Configurable 3rd Party MHA Support for FlexiBTS . . . . . . . 1813.47 RAN1002 Flexi WCDMA BTS 40 W carrier power support . . . . . . . . . 1823.48 RAN1144 Flexi WCDMA BTS 8 W RF power limitation . . . . . . . . . . . . 1833.49 RAN1146: Flexi WCDMA BTS Horizontal Mounting Kit for GSM EDGE

BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1843.50 RAN1145: Flexi WCDMA BTS RF Module with AC Input Power . . . . . 1853.51 RAN1001: Flexi WCDMA BTS Second Carrier Support . . . . . . . . . . . . 1863.52 RAN1439: Distributed BTS Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 1873.53 RAN1469: Flexi Mounting Shields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1883.54 RAN607: Connectivity Support for 512 BTSs . . . . . . . . . . . . . . . . . . . . 1893.55 RAN640: Star Configuration: 512 BTSs . . . . . . . . . . . . . . . . . . . . . . . . 190

DN0934844Issue 01

9


Id:0900d8058060a37e

3.56 BTS solution features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1913.56.1 BTS Solution Features Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1913.56.1.1 BTS solution features overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1913.56.1.2 Further information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1923.57 Performance monitoring features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1933.57.1 RAS05.1 performance monitoring features overview . . . . . . . . . . . . . 1933.57.1.1 Further information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1933.57.2 RAN189: Automatic Definition of Neighbouring Cells . . . . . . . . . . . . . 1943.57.2.1 Automatic Definition of Neighbouring Cells feature description . . . . . . 1943.57.2.2 Main functionality of Automatic Definition of Neighbouring Cells. . . . . 1963.57.2.3 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1993.57.3 RAN956: BTS Channel Element Capacity Measuring . . . . . . . . . . . . . 2013.57.3.1 BTS Channel Element Capacity Measuring feature description . . . . . 2013.57.3.2 Main functionality of BTS Channel Element Capacity Measuring . . . . 2043.57.4 RAN232: CPICH Ec/No Coverage Measurements and Optimisation . 2053.57.4.1 CPICH Ec/No Coverage Measurements and Optimisation feature descrip-

tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2053.57.4.2 Main functionality of CPICH Ec/No Coverage Measurements and Optimis-

ation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2073.57.5 RAN1054: Downlink Packet Data Throughput for Subscriber and Equip-

ment Trace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2083.57.6 RAN190: Radio Connection Performance Measurements for RLC TM and

UM and Outer Loop Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 2093.57.6.1 Radio Connection Performance Measurements for RLC TM and UM and

Outer Loop Power Control feature description. . . . . . . . . . . . . . . . . . . 2093.57.6.2 Main functionality of Radio Connection Performance Measurements for

RLC TM and UM and Outer Loop Power Control . . . . . . . . . . . . . . . . 2113.57.6.3 Connection type classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2133.57.7 RAN1163: Iu-PS Throughput Measurement for GTP Traffic . . . . . . . . 2143.57.7.1 Iu-PS Throughput Measurement for GTP Traffic feature description . 2143.57.7.2 Main functionality of Iu-PS Throughput Measurement for GTP Traffic 2173.57.8 RAN1153: Complementary Counters in RAS05.1 . . . . . . . . . . . . . . . . 2183.57.8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2183.57.8.2 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2183.57.8.3 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2203.58 Transmission and transport features . . . . . . . . . . . . . . . . . . . . . . . . . . 2223.58.1 RAS05.1 transmission and transport features overview . . . . . . . . . . . 2223.58.1.1 Further information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2223.58.2 RAN165: IP Based Control Plane at Iu and Iur . . . . . . . . . . . . . . . . . . 2233.58.2.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2233.58.2.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2243.58.2.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2263.58.3 RAN324: Dynamic HSDPA Transport Scheduling. . . . . . . . . . . . . . . . 2273.58.3.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2273.58.3.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2303.58.3.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2323.58.3.4 Static rate control for the HSDPA data . . . . . . . . . . . . . . . . . . . . . . . . 2323.58.3.5 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

10 DN0934844Issue 01


Id:0900d8058060a37e

3.58.4 RAN717: Iu-PS IP Quality of Service Support (DiffServ in GTPU) . . . . 2353.58.4.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2353.58.4.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2363.58.4.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2383.58.5 RAN935: BTS AAL2 Multiplexing for Flexi WCDMA BTS. . . . . . . . . . . 2393.58.5.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2393.58.6 RAN939: Flexbus Interface for Flexi WCDMA BTS . . . . . . . . . . . . . . . 2403.58.6.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2403.58.7 RAN940: E1 Interface for Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . 2413.58.7.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2413.58.8 RAN941: JT1 Interface for Flexi WCDMA BTS. . . . . . . . . . . . . . . . . . . 2423.58.8.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2423.58.9 RAN942: SDH STM-1 Interface for Flexi WCDMA BTS . . . . . . . . . . . . 2433.58.9.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2433.58.9.2 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 2433.58.9.3 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2433.58.10 RAN944: Use of GSM Transmission (Flexi WCDMA BTS) . . . . . . . . . 2443.58.10.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2443.58.11 RAN946: T1 Interface for Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . 2453.58.11.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2453.58.12 RAN1020: Route Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2463.58.12.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2463.58.12.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2523.58.12.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2533.58.13 RAN1062: IMA (Flexi WCDMA BTS) . . . . . . . . . . . . . . . . . . . . . . . . . . 2543.58.13.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2543.58.14 RAN1086: AXC ATM interface oversubscription . . . . . . . . . . . . . . . . . 2553.58.14.1 Feature description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2553.58.14.2 Main functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2583.58.14.3 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2583.59 Radio resource management and telecom features . . . . . . . . . . . . . . . 2593.59.1 Radio Resource Management and Telecom features overview . . . . . . 2593.59.1.1 Radio Resource Management and Telecom features overview . . . . . . 2593.59.1.2 Further information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2623.59.2 RAN223: UE Based A-GPS Using External Reference Network . . . . . 2633.59.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2633.59.2.2 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2643.59.3 RAN384 and 814: Emergency and Intelligent Emergency Call Inter-system

Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2673.59.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2673.59.3.2 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2673.59.3.3 Configuration requirements for EMISHO and intelligent EMISHO . . . . 2693.59.3.4 Functional restrictions on EMISHO and intelligent EMISHO . . . . . . . . 2703.59.3.5 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2703.59.3.6 Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2703.59.4 RAN875: Network Based A-GPS Using External Reference Network . 2713.59.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

DN0934844Issue 01

11


Id:0900d8058060a37e

3.59.4.2 Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

4 Performance monitoring features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2744.1 RAS05.1 performance monitoring features overview . . . . . . . . . . . . . 2744.1.1 Further information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2744.2 RAN189: Automatic Definition of Neighbouring Cells . . . . . . . . . . . . . 2754.2.1 Automatic Definition of Neighbouring Cells feature description . . . . . . 2754.2.1.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2754.2.1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2754.2.1.3 Resource requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2764.2.1.4 Interaction with other features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2764.2.1.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2764.2.2 Main functionality of Automatic Definition of Neighbouring Cells. . . . . 2774.2.2.1 Using Automatic Definition of Neighbouring Cells . . . . . . . . . . . . . . . . 2774.2.2.2 Activating Automatic Definition of Neighbouring Cells . . . . . . . . . . . . . 2774.2.2.3 Verifying Automatic Definition of Neighbouring Cells. . . . . . . . . . . . . . 2774.2.2.4 Deactivating Automatic Definition of Neighbouring Cells. . . . . . . . . . . 2784.2.2.5 Feature management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2784.2.2.6 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2784.2.2.7 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2794.2.3 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2804.3 RAN956: BTS Channel Element Capacity Measuring . . . . . . . . . . . . . 2824.3.1 BTS Channel Element Capacity Measuring feature description . . . . . 2824.3.1.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2834.3.1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2834.3.1.3 Resource requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2834.3.1.4 Interaction with other features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2844.3.1.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2844.3.2 Main functionality of BTS Channel Element Capacity Measuring . . . . 2854.3.2.1 Using BTS Channel Element Capacity Measuring . . . . . . . . . . . . . . . 2854.3.2.2 Activating BTS Channel Element Capacity Measuring . . . . . . . . . . . . 2854.3.2.3 Verifying BTS Channel Element Capacity Measuring . . . . . . . . . . . . . 2854.3.2.4 Deactivating BTS Channel Element Capacity Measuring . . . . . . . . . . 2854.3.2.5 Feature management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2854.3.2.6 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2854.3.2.7 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2854.4 RAN232: CPICH Ec/No Coverage Measurements and Optimisation . 2864.4.1 CPICH Ec/No Coverage Measurements and Optimisation feature descrip-

tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2864.4.1.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2874.4.1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2874.4.1.3 Resource requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2874.4.1.4 Interaction with other features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2874.4.1.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2874.4.2 Main functionality of CPICH Ec/No Coverage Measurements and Optimis-

ation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2884.4.2.1 Using CPICH Ec/No Coverage Measurements and Optimisation . . . . 2884.4.2.2 Activating CPICH Ec/No Coverage Measurements and Optimisation . 288

12 DN0934844Issue 01


Id:0900d8058060a37e

4.4.2.3 Verifying CPICH Ec/No Coverage Measurements and Optimisation . . 2884.4.2.4 Deactivating CPICH Ec/No Coverage Measurements and Optimisation . .

2884.4.2.5 Feature management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2884.4.2.6 Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2884.4.2.7 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2884.5 RAN1054: Downlink Packet Data Throughput for Subscriber and Equip-

ment Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2894.6 RAN190: Radio Connection Performance Measurements for RLC TM and

UM and Outer Loop Power Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2904.6.1 Radio Connection Performance Measurements for RLC TM and UM and

Outer Loop Power Control feature description . . . . . . . . . . . . . . . . . . . 2904.6.1.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2904.6.1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2904.6.1.3 Resource requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2904.6.1.4 Interaction with other features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2914.6.1.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2914.6.2 Main functionality of Radio Connection Performance Measurements for

RLC TM and UM and Outer Loop Power Control . . . . . . . . . . . . . . . . . 2924.6.2.1 Using Radio Connection Performance Measurements for RLC TM and UM

and Outer Loop Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2924.6.2.2 Activating Radio Connection Performance Measurements for RLC TM and

UM and Outer Loop Power Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2924.6.2.3 Verifying Radio Connection Performance Measurements for RLC TM and

UM and Outer Loop Power Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2924.6.2.4 Deactivating Radio Connection Performance Measurements for RLC TM

and UM and Outer Loop Power Control . . . . . . . . . . . . . . . . . . . . . . . . 2924.6.2.5 Feature management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2924.6.2.6 Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2934.6.2.7 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2934.6.3 Connection type classification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2944.7 RAN1163: Iu-PS Throughput Measurement for GTP Traffic . . . . . . . . 2954.7.1 Iu-PS Throughput Measurement for GTP Traffic feature description . . 2954.7.1.1 Operator benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2964.7.1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2974.7.1.3 Resource requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2974.7.1.4 Interaction with other features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2974.7.1.5 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2974.7.2 Main functionality of Iu-PS Throughput Measurement for GTP Traffic . 2984.7.2.1 Using the Iu-PS throughput measurement for GTP traffic . . . . . . . . . . 2984.7.2.2 Activating the Iu-PS throughput measurement for GTP traffic . . . . . . . 2984.7.2.3 Verifying the Iu-PS throughput measurement for GTP traffic . . . . . . . . 2984.7.2.4 Deactivating the Iu-PS throughput measurement for GTP traffic . . . . . 2984.7.2.5 Feature management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2984.7.2.6 Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2984.7.2.7 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2984.8 RAN1153: Complementary Counters in RAS05.1 . . . . . . . . . . . . . . . . 2994.8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

DN0934844Issue 01

13


Id:0900d8058060a37e

4.8.2 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2994.8.3 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3014.8.3.1 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3014.8.3.2 Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . 3014.8.3.3 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3014.8.3.4 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3014.8.3.5 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3024.8.3.6 Operational aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

5 BTS solution features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3035.1 BTS Solution Features Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3035.1.1 BTS solution features overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3035.1.2 Further information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

Related information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

14 DN0934844Issue 01


Id:0900d8058060a37e

List of FiguresFigure 1 UE based A-GPS positioning method. . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figure 2 EMISHO call flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figure 3 iEMISHO call flow when location accuracy was not sufficient enough . . 35Figure 4 Network based A-GPS positioning method. . . . . . . . . . . . . . . . . . . . . . . 39Figure 5 Protocol stack for the supported interfaces. . . . . . . . . . . . . . . . . . . . . . . 41Figure 6 Architecture of IP-based control plane . . . . . . . . . . . . . . . . . . . . . . . . . . 44Figure 7 HSDPA flow control architecture with shared VCC. . . . . . . . . . . . . . . . . 45Figure 8 The thresholds of an AAL2 queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Figure 9 The calculation of MVHBD value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Figure 10 Architecture of lu-PS IP Quality of Service Support (DiffServ of GTPU). 56Figure 11 Flexbus Interface for Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . . . . . . 58Figure 12 E1 Interface for Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Figure 13 JT1 Interface for Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Figure 14 SDH STM-1 Interface for Flexi WCDMA BTS. . . . . . . . . . . . . . . . . . . . . 61Figure 15 T1 Interface for Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Figure 16 Route selection network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 65Figure 17 Network topology containing hub points . . . . . . . . . . . . . . . . . . . . . . . . . 66Figure 18 CBR-UBR conversion of HSDPA VCC . . . . . . . . . . . . . . . . . . . . . . . . . . 67Figure 19 Example of AXC-A configuration with three HSDPA-capable WAM units .

68Figure 20 Example of AXU-B or AXU-C configuration with three HSDPA-capable

WAM units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Figure 21 Network topology for AXC ATM interface oversubscription . . . . . . . . . . 73Figure 22 Alarm Architecture for Flexi WCDMA BTS, architecture . . . . . . . . . . . . . 82Figure 23 Network before the BTS rehosting operation . . . . . . . . . . . . . . . . . . . . . 87Figure 24 Network after the BTS rehosting operation. . . . . . . . . . . . . . . . . . . . . . . 88Figure 25 AXC Local Account Mass Change architecture . . . . . . . . . . . . . . . . . . . 92Figure 26 BTS SW Management with RNC/NEMU Mediation architecture . . . . . . 94Figure 27 Combined SW Management for the Flexi WCDMA BTS and its Transport

Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Figure 28 Data Backup for AXC architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Figure 29 Architecture of DSAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Figure 30 Flexible Connection of VPCs for WBTS Object in RNC, architecture . . 107Figure 31 Basic Iub VCC configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Figure 32 Iub configuration with one ATM interface and two VPCs for one BTS con-

nection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Figure 33 Iub configuration with two ATM interface and three VPCs for one BTS con-

nection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Figure 34 Local User Authentication for BTS architecture . . . . . . . . . . . . . . . . . . 110Figure 35 Non-Performing Cell Recovery architecture . . . . . . . . . . . . . . . . . . . . . 114Figure 36 RNAR architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Figure 37 User Information Management for read-only access rights . . . . . . . . . 119Figure 38 User NE login authentication/User authorisation . . . . . . . . . . . . . . . . . 119Figure 39 Remote User Event Log Management for AXC architecture . . . . . . . . 123Figure 40 Remote User Event Log Management for RNC, architecture . . . . . . . . 126Figure 41 Remote User Information Management for AXC, architecture . . . . . . . 132

DN0934844Issue 01

15


Id:0900d8058060a37e

Figure 42 Remote User Information Management for RNC, architecture . . . . . . 139Figure 43 Architecture of WCEL Lock and Unlock during RNW Plan Activation . 142Figure 44 BTS channel element capacity measuring in WCDMA measure solution .

147Figure 45 WCDMA measure solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Figure 46 Iu-PS throughput measurement for GTP traffic in WCDMA measure solu-

tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Figure 47 Iu-PS interface termination in RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Figure 48 WCDMA RAN Trace Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Figure 49 The essential interfaces and objects in the automatic definition of neigh-

bouring cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Figure 50 BTS channel element capacity measuring in WCDMA measure solution .

201Figure 51 RCPM OLPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213Figure 52 RCPM UEQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213Figure 53 Iu-PS throughput measurement for GTP traffic in WCDMA measure solu-

tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Figure 54 Iu-PS interface termination in RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Figure 55 Protocol stack for the supported interfaces . . . . . . . . . . . . . . . . . . . . . 223Figure 56 Architecture of IP-based control plane. . . . . . . . . . . . . . . . . . . . . . . . . 226Figure 57 HSDPA flow control architecture with shared VCC . . . . . . . . . . . . . . . 227Figure 58 The thresholds of an AAL2 queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Figure 59 The calculation of MVHBD value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232Figure 60 Architecture of lu-PS IP Quality of Service Support (DiffServ of GTPU) . .

238Figure 61 Flexbus Interface for Flexi WCDMA BTS. . . . . . . . . . . . . . . . . . . . . . . 240Figure 62 E1 Interface for Flexi WCDMA BTS. . . . . . . . . . . . . . . . . . . . . . . . . . . 241Figure 63 JT1 Interface for Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . . . . . . . . 242Figure 64 SDH STM-1 Interface for Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . 243Figure 65 T1 Interface for Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Figure 66 Route selection network configuration . . . . . . . . . . . . . . . . . . . . . . . . . 247Figure 67 Network topology containing hub points . . . . . . . . . . . . . . . . . . . . . . . 248Figure 68 CBR-UBR conversion of HSDPA VCC . . . . . . . . . . . . . . . . . . . . . . . . 249Figure 69 Example of AXC-A configuration with three HSDPA-capable WAM units .

250Figure 70 Example of AXU-B or AXU-C configuration with three HSDPA-capable

WAM units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Figure 71 Network topology for AXC ATM interface oversubscription . . . . . . . . . 255Figure 72 UE based A-GPS positioning method . . . . . . . . . . . . . . . . . . . . . . . . . 265Figure 73 EMISHO call flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268Figure 74 iEMISHO call flow when location accuracy was not sufficient enough 269Figure 75 Network based A-GPS positioning method . . . . . . . . . . . . . . . . . . . . . 273Figure 76 The essential interfaces and objects in the automatic definition of neigh-

bouring cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Figure 77 BTS channel element capacity measuring in WCDMA measure solution .

282Figure 78 RCPM OLPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294Figure 79 RCPM UEQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294Figure 80 Iu-PS throughput measurement for GTP traffic in WCDMA measure solu-

16 DN0934844Issue 01


Id:0900d8058060a37e

tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295Figure 81 Iu-PS interface termination in RNC. . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

DN0934844Issue 01

17


Id:0900d8058060a37e

List of TablesTable 1 Radio Resource Management and Telecom features . . . . . . . . . . . . . 25Table 2 Transmission and transport features for RAS05.1 . . . . . . . . . . . . . . . . 40Table 3 DSCP to traffic class mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Table 4 RAS05.1 operability features overview . . . . . . . . . . . . . . . . . . . . . . . . . 78Table 5 Management parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Table 6 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Table 7 Management parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Table 8 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Table 9 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Table 10 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Table 11 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Table 12 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Table 13 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Table 14 Estimated usage of channel elements in the WBTS . . . . . . . . . . . . . . 148Table 15 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Table 16 SW requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Table 17 RAS05.1 performance monitoring features . . . . . . . . . . . . . . . . . . . . . 156Table 18 Classes for CPICH Ec/No coverage measurements . . . . . . . . . . . . . 163Table 19 SW requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Table 20 BTS solution features for RAS05.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 191Table 21 RAS05.1 performance monitoring features . . . . . . . . . . . . . . . . . . . . . 193Table 22 SW requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195Table 23 Essential parameters in autotuning algorithm . . . . . . . . . . . . . . . . . . . 199Table 24 Estimated usage of channel elements in the WBTS . . . . . . . . . . . . . . 202Table 25 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Table 26 Classes for CPICH Ec/No coverage measurements . . . . . . . . . . . . . 205Table 27 SW requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Table 28 SW requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210Table 29 RAS05.1 performance monitoring features . . . . . . . . . . . . . . . . . . . . . 216Table 30 Transmission and transport features for RAS05.1 . . . . . . . . . . . . . . . 222Table 31 DSCP to traffic class mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Table 32 Radio Resource Management and Telecom features . . . . . . . . . . . . 259Table 33 RAS05.1 performance monitoring features . . . . . . . . . . . . . . . . . . . . . 274Table 34 SW requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276Table 35 Essential parameters in autotuning algorithm . . . . . . . . . . . . . . . . . . . 280Table 36 Estimated usage of channel elements in the WBTS . . . . . . . . . . . . . . 283Table 37 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Table 38 Classes for CPICH Ec/No coverage measurements . . . . . . . . . . . . . 286Table 39 SW requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287Table 40 SW requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291Table 41 RAS05.1 performance monitoring features . . . . . . . . . . . . . . . . . . . . . 297Table 42 BTS solution features for RAS05.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

18 DN0934844Issue 01


Id:0900d8058060a437

Summary of changes

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

Changes in issue 01This is the first issue of the document. It contains a compilation of all features described in the following documents:

• RAS05.1 Radio Resource Management and Telecom Features • RAS05.1 Transmission and Transport Features • RAS05.1 Operability Features • RAS05.1 Performance Monitoring Features • RAS05.1 BTS Solution Features

These documents were separate documents in previous documentation releases so changes are described for each document respectively.

Radio resource management and telecom features

Changes between issues 2-0 and 3-0The following features have been added to the list of RAS05.1 features:

• RAN1195: Multi-band Support for RNC • RAN1184: Configurable Location Shapes

The ID number of feature RAN1224: HSDPA Dynamic Power Allocation has been cor-rected.

Changes between issues 1-2 and 2-0The title of the document has been modified from Radio Resource Management and Telecom Features Overview to RAS05.1 Radio Resource Management and Telecom Features.

Radio Resource Management and Telecom Features Overview

• The name of the chapter has been modified from RAS05.1 Radio Resource Man-agement and Telecom Features to.Radio Resource Management and Telecom Features Overview

Changes between issues 1-1 and 1-2RAS05.1 Radio Resource Management and Telecom features

• The release name has been added to the name of the chapter. • The name of Feature RAN814 has been modified. • The lists of features included in RAN1.5, RAN04, and RAS05 releases have been

moved to RAN04 and RAS05 Radio Resource Management Features and RAN04 and RAS05 Telecom Features.

Transmission and transport features

Changes between issues 2-0 and 2-1The following features have been added:

• RAN935: BTS AAL2 Multiplexing for Flexi WCDMA BTS • RAN939: Flexbus Interface for Flexi WCDMA BTS

DN0934844Issue 01

19

WCDMA RAN, rel. RAS05.1, feature descriptions Summary of changes

Id:0900d8058060a437

• RAN940: E1 Interface for Flexi WCDMA BTS • RAN941: JT1 Interface for Flexi WCDMA BTS • RAN942: SDH STM-1 Interface for Flexi WCDMA BTS • RAN944: Use of GSM Transmission (Flexi WCDMA BTS) • RAN946: T1 Interface for Flexi WCDMA BTS • RAN1062: IMA (Flexi WCDMA BTS)

Changes between issues 1-2 and 2-0Editorial changes have been made.

Changes between issues 1-1 and 1-2Section RAS05.1 transmission and transport features overview:

• Section RAN1.5, RAN04 and RAS05 transmission and transport features overview has been removed and the chapter renamed.

Section RAN1020: Route Selection:

• Information about plain mode and enhanced mode have been added. • Sections Feature description, Operator requirements and Activating Route Selec-

tion have been updated.

Operability features

Changes between issues 2-0 and 3-0

Feature See

RAN1193: Plan based RNC ATM/IP Configu-ration

RAN1193: Plan based RNC ATM/IP Configu-ration

RAN1181: RNC NEMU Firewall RAN1181: RNC NEMU Firewall

BTS Channel Element Capacity Measuring feature description

BTS Channel Element Capacity Measuring feature description

RAN1153: Complementary Counters in RAS05.1


Radio Connection Performance Measure-ments for RLC TM and UM and Outer Loop Power Control feature description

Radio Connection Performance Measure-ments for RLC TM and UM and Outer Loop Power Control feature description

RAN1163: Iu-PS Throughput Measurement for GTP Traffic


Downlink Packet Data Throughput for Sub-scriber and Equipment Trace feature descrip-tion

Downlink Packet Data Throughput for Sub-scriber and Equipment Trace feature descrip-tion

RAN189: Automatic Definition of Neighbouring Cells


CPICH Ec/No Coverage Measurements and Optimisation feature description

CPICH Ec/No Coverage Measurements and Optimisation feature description

RAN1186: RNC450 RAN1186: RNC450

RAN1514: Number of Supported HS-DSCH Users in RNC196 and RNC450

RAN1514: Number of Supported HS-DSCH Users in RNC196 and RNC450

Table The following features have been added to the document

20 DN0934844Issue 01


Id:0900d8058060a437

Summary of changes

Changes between issues 1-2 and 2-0Activation and deactivation instructions have been updated to RAN1302: Non-Perform-ing Cell Recovery.

Changes between issues 1-1 and 1-2See Table Changes in RAS05.1 Operability Features, Issue 1-2 for information on content changes in the document.

Note that feature RAN1193: Plan based RNC ATM/IP Configuration is implemented in RAS05.1 ED. The feature has been documented in RAS05.1 as part of Automated RNS Split.

RAN1036: RNC196 Capacity Upgrades RAN1036: RNC196 Capacity Upgrades

RAN900: Flexi WCDMA BTS RAN900: Flexi WCDMA BTS

RAN999: Flexi WCDMA BTS 1700/2100 RAN999: Flexi WCDMA BTS 1700/2100

RAN916: Flexi WCDMA BTS 90 RAN916: Flexi WCDMA BTS 90

RAN917: Flexi WCDMA BTS 850 RAN917: Flexi WCDMA BTS 850

RAN907 Antenna line supervision RAN907 Antenna line supervision

RAN1046 Feederless site solution for Flexi WCDMA BTS

RAN1046 Feederless site solution for Flexi WCDMA BTS

RAN905 Flexi WCDMA BTS MHA support RAN905 Flexi WCDMA BTS MHA support

RAN1093 HSDPA 16QAM SW licence support RAN1093 HSDPA 16QAM SW licence support

RAN912: Licence Based BTS Channel Capacity

RAN912: Licence Based BTS Channel Capacity

RAN943: Synchronising WCDMA RAN (Flexi WCDMA BTS)


RAN1000: Baseband Extension for Flexi WCDMA BTS

RAN1000: Baseband Extension for Flexi WCDMA BTS

RAN1133: Configurable 3rd Party MHA Support for FlexiBTS

RAN1133: Configurable 3rd Party MHA Support for FlexiBTS

RAN1002 Flexi WCDMA BTS 40 W carrier power support

RAN1002 Flexi WCDMA BTS 40 W carrier power support

RAN1144 Flexi WCDMA BTS 8 W RF power limitation

RAN1144 Flexi WCDMA BTS 8 W RF power limitation

RAN1146: Flexi WCDMA BTS Horizontal Mounting Kit for GSM EDGE BTS


RAN1145: Flexi WCDMA BTS RF Module with AC Input Power


RAN1001: Flexi WCDMA BTS Second Carrier Support

RAN1001: Flexi WCDMA BTS Second Carrier Support

RAN1439: Distributed BTS Solution RAN1439: Distributed BTS Solution

RAN1469: Flexi Mounting Shields RAN1469: Flexi Mounting Shields

RAN607: Connectivity Support for 512 BTSs RAN607: Connectivity Support for 512 BTSs

RAN640: Star Configuration: 512 BTSs RAN640: Star Configuration: 512 BTSs

Table The following features have been added to the document (Cont.)

DN0934844Issue 01

21


Id:0900d8058060a437

Chapter Modification See

RAS05.1 operability features overview

Section RAN1.5, RAN04 and RAS05 operability features overview removed and the chapter renamed.

Table RAS05.1 operability features overview updated with new features.

• RAS05.1 operability features overview

• Operability features overview in RAN04 and RAS05 Operability Features

Feature information in section Further information updated.

Further information

RAN893: Alarm Architecture for Flexi WCDMA BTS

Software requirements and acti-vation instructions updated.

RAN893: Alarm Architecture for Flexi WCDMA BTS

RAN369: Automated IP Address Configuration for BTS

Software requirements and acti-vation instructions updated.

RAN369: Automated IP Address Con-figuration for BTS

RAN96: Automated RNS Split Software requirements updated. RAN96: Automated RNS Split

RAN882: AXC ATM Layer Configuration Management for BTS

Software requirements updated. RAN882: AXC ATM Layer Configura-tion Management for BTS

RAN1290: AXC Local Account Mass Change

A new feature description. RAN1290: AXC Local Account Mass Change

RAN1091: BTS SW Manage-ment with RNC/NEMU Media-tion

A new feature description. RAN1091: BTS SW Management with RNC/NEMU Mediation

RAN817: Combined SW Man-agement for Flexi WCDMA BTS and its Transport Module

Software requirements updated. RAN817: Combined SW Management for Flexi WCDMA BTS and its Transport Module

RAN1040: Data Backup for AXC

Software requirements and information on interaction with other features updated.

RAN1040: Data Backup for AXC

RAN1167: Domain Specific Access Class Restriction

Default value of management parameter CellAccessRestric-tion updated.

RAN1167: Domain Specific Access Class Restriction

RAN619: Flexible Connection of VPCs for WBTS Object in RNC

A new feature description. RAN619: Flexible Connection of VPCs for WBTS Object in RNC

RAN812: Local User Authenti-cation for BTS

Software requirements updated. RAN812: Local User Authentication for BTS

RAN1302: Non-Performing Cell Recovery

A new feature description. RAN1302: Non-Performing Cell Recovery

RAN801: Radio Network Access Regulation Function

Default value and value range of management parameter CellAc-cessRestriction updated.

RAN801: Radio Network Access Regu-lation Function

RAN615: Remote User Event Log Management for AXC

Software requirements updated. RAN615: Remote User Event Log Man-agement for AXC

Table Changes in RAS05.1 Operability Features, Issue 1-2

22 DN0934844Issue 01


Id:0900d8058060a437

Summary of changes

Performance monitoring features

Changes between issues 2-0 and 2-1Section RAN1153 Complementary Counters in RAS05.1 has been added.

Changes between issues 1-1 and 2-0Due to restructuring of the subscriber and equipment trace documents, content of RAN1054: Downlink Packet Data Throughput for Subscriber has been moved into Sub-scriber and Equipment Trace Feature Description.

Changes between issues 1-0 and 1-1Table Changes in RAS05.1 Performance Monitoring Features describes the content changes in Issue 1-1.

BTS solution features

Changes between issues 3-0 and 4-0Feature RAN1469: Flexi Mounting Shields has been added to in Chapter RAS05.1 BTS solution features overview.

Changes between issues 2-1 and 3-0Editorial corrections have been implemented in the document:

RAN183: Remote User Event Log Management for RNC

Software requirements updated. RAN183: Remote User Event Log Man-agement for RNC

RAN1453: Iu Link Break Pro-tection

A new feature description. RAN1453: Iu Link Break Protection

Chapter Modification See

Table Changes in RAS05.1 Operability Features, Issue 1-2 (Cont.)

Changed chapter Description of the change See

RAS05.1 performance monitoring features overview

Feature RAN1163: Iu-PS Through-put Measurement for GTP Traffic has been added to the table

RAS05.1 performance mon-itoring features overview

Section RAN04 and RAS05 perfor-mance monitoring features overview has been removed and the chapter renamed.

• RAS05.1 performance monitoring features overview

• Performance monitor-ing features overview in RAN04 and RAS05 Performance Monitor-ing Features

RAN1163: Iu-PS Through-put Measurement for GTP Traffic

A new feature description has been added to the document.

RAN1163: Iu-PS Through-put Measurement for GTP Traffic

Table Changes in RAS05.1 Performance Monitoring Features

DN0934844Issue 01

23


Id:0900d8058060a437

• the title of the document has changed from BTS Solution Features Overview to RAS05.1 BTS Solution Features

• the title of Chapter RAS05.1 BTS solution features has changed to BTS Solution Features Overview

Changes between issues 2-0 and 2-1Feature RAN1439 Distributed BTS solution has been added to RAS05.1 ED in Chapter RAS05.1 BTS solution features overview.

The distribution of features between RAS05.1 and RAS05.1 ED has been corrected in Chapter RAS05.1 BTS solution features overview.

24 DN0934844Issue 01


Id:0900d8058060a437

Summary of changes

DN0934844Issue 01

25

WCDMA RAN, rel. RAS05.1, feature descriptions Radio resource management and telecom features

Id:0900d805805d88bb

1 Radio resource management and telecom features

1.1 Radio Resource Management and Telecom features overview

1.1.1 Radio Resource Management and Telecom features overview

Feature name Available in release

See

RAN140: Load and Service Based IS/IF Handover

RAS05.1 • Features Under Develop-ment (FUD)

• Feature RAN140: Load and Service Based IS/IF Han-dover, Handover Control, Admission Control, and Packet Scheduler in WCDMA RNC Product Doc-umentation

RAN242: Flexible Upgrade of NRT DCH Data Rate


• Packet Scheduler, Radio resource management of HSDPA, Radio Resource Management , and RAN242 and RAN409: Flexible Upgrade of NRT DCH Data Rate and Throughput-based Optimisation of the Packet Scheduler Algorithm Feature Activation Manual in WCDMA RNC Product Doc-umentation

RAN409: Throughput-Based Optimisation of the Packet Scheduler Algorithm


• Packet Scheduler, Packet Data Transfer States, and RAN242 and RAN409: Flexible Upgrade of NRT DCH Data Rate and Throughput-based Optimisa-tion of the Packet Scheduler Algorithm Feature Activation Manual in WCDMA RNC Product Documentation

Table 1 Radio Resource Management and Telecom features

26 DN0934844Issue 01


Id:0900d805805d88bb


RAN146: Power Balanc-ing


• Feature RAN146: Power Bal-ancing, and Power Control in WCDMA RNC Product Doc-umentation

RAN830: AMR Codec Sets (12.2, 7.95, 5.90, 4.75) and (5.90, 4.75)


• Admission Control, and RAN830: AMR Codec Set with AMR Codec Selection Feature Activation Manual in WCDMA RNC Product Doc-umentation

RAN849: HSDPA Pro-portional Fair Resource Packet Scheduler


• HSDPA in BTS in WCDMA RNC Product Documentation

RAN1224: HSDPA Dynamic Power Alloca-tion


• HSDPA in BTS • Dimensioning WCDMA RAN

RAN839: HSDPA 16 Users per Cell


• HSDPA in BTS, Packet Scheduler, and RNC Product Description in WCDMA RNC Product Documentation

RAN1164: HSDPA Service Indicator


RAN829: HSDPA Soft/softer Handover for Associated DPCH


• Radio resource management of HSDPA, and Radio Resource Management in WCDMA RNC Product Doc-umentation

RAN828: HSDPA Serving Cell Change


• Radio resource management of HSDPA, Radio Resource Management, and Radio Resource Management, Packet Data Transfer State in WCDMA RNC Product Documentation


See

Table 1 Radio Resource Management and Telecom features (Cont.)

DN0934844Issue 01

27

WCDMA RAN, rel. RAS05.1, feature descriptions Radio resource management and telecom features

Id:0900d805805d88bb

RAN827: HSDPA with Simultaneous AMR Voice Call



RAN223: UE Based A-GPS Using External Reference Network


• Feature RAN223: UE Based A-GPS Using External Refer-ence Network, and RAN223: UE based A-GPS using external reference network Feature Description in WCDMA RNC Product Doc-umentation

RAN814: Intelligent Directed Emergency Call Inter-system Handover for US


• Features RAN384 and RAN814: Emergency and Intelligent Emergency Call Inter-System Handover, Feature Activation Manual in WCDMA RNC Product Doc-umentation

RAN134: Support for Tandem/Transcoder Free Operation


• Call setup and release, Feature RAN134: Support for Tandem/Transcoder Free Operation in WCDMA RNC Product Documentation

RAN1180: Wireless priority service

RAS05.1 ED • Features Under Develop-ment (FUD)

• Handover Control and Admission Control in WCDMA RNC Product Doc-umentation

RAN875: Network Based A-GPS Using External Reference Network


• RAN875: Network Based A-GPS Using External Refer-ence Network Feature Acti-vation Manual, and Call Setup and Release in WCDMA RNC Product Doc-umentation


See


28 DN0934844Issue 01


Id:0900d805805d88bb


1.1.2 Further informationFor feature descriptions, see Functional Area Descriptions in WCDMA RNC Product Documentation, and HSDPA in BTS in WCDMA RAN System Documentation.

For feature activation instructions, see WCDMA RNC Product Documentation.

For parameters, counters and alarms per feature, see Interdependencies of Telecom Features and Interdependencies of Radio Resource Management Features.

For more detailed information on parameters, counters and alarms, see Reference infor-mation in WCDMA RNC Product Documentation.

For information on software requirements, see Network compatibility matrix in WCDMA RAN Compatibility.

For listings of RAN1.5, RAN04 and RAS05 features, see Radio resource management features overview in RAN04 and RAS05 Radio Resource Management Features and Telecom features overview in RAN04 and RAS05 Telecom Features.

RAN815: Point-to-Point Iu-pc Interface


• WCDMA RAN Interfaces

RAN1195: Multi-band Support for RNC


RAN1184: Configurable Location Shapes


• WCDMA RAN Location Services


See


DN0934844Issue 01

29


Id:0900d8058061e9eb

1.2 RAN223: UE Based A-GPS Using External Reference NetworkUser Equipment UE Based Assisted Global Positioning System (A-GPS) Using External Reference Network RAN feature belongs to application software.

WCDMA RAS05.1 supports the UE based A-GPS positioning method. The UE based assisted GPS is a method to establish a GPS reference network whose receivers have an unobstructed view of the sky and can operate continuously. At the request of a user equipment or a network based application, the RAN collects the required GPS data from this reference network and generates the required assistance data elements for the UE. The assistance data from the reference network is transmitted to the UE to improve the GPS receiver performance. To be more specific, the assistance data speeds up the location calculation function within the UE, thereby reducing UE battery consumption.

ComplianceThis feature is compatible with 3GPP Rel-5 specification and backwards compatible with 3GPP R99 and Rel-4.

1.2.1 Requirements

SoftwareThe software requirements for network elements BTS and RNC are the following:

• BTS: any RAS05.1 compliant BTS with the related software • RNC: RN2.2 software

The RNC integrated serving mobile location centre (SMLC) functionality is imple-mented as a software upgrade in the interface control and signalling unit (ICSU) and radio resource management (RRMU) units. For more information, refer to RNC Product Description and Engineering in RNC in RNC documentation.

HardwareThe hardware requirements for this feature are:

• There must be RRMU units on the RNC. • A stand-alone SMLC (SAS) or A-GPS server is needed for GPS assistance data. • Location services (LCS) A-GPS Site Solution related hardware for transmission is

needed between the RNC and the SAS/A-GPS server. • A-GPS hardware is required in the UE.

End-user equipmentThe UE must support the A-GPS feature. In practice, the UE must be equipped with a GPS receiver. Furthermore, the UE must be able to receive assistance data from the network and calculate the GPS positioning.

In addition, mobile-originated location requests (that is, a location request from a client UE to the location service server made over the WCDMA radio interface) need UE support. Other types of location requests do not need additional UE support. The feature works with WCDMA UEs compatible with 3GPP Rel-4, Rel-5 and 3GPP R99 standards.

30 DN0934844Issue 01


Id:0900d8058061e9eb

OperatorBefore activating this feature, the operator has to enable the LCS - Cell coverage based (RTT) with geographical coordinates feature.

The operator has to plan and configure the RNC radio network configuration and to con-figure the external reference network for GPS assistance data. The related radio network management objects are WCDMA serving mobile location centre (WSMLC) and WCDMA location services entity (WLCSE). The WSMLC object contains also the parameters needed for the external interface configuration.

1.2.2 FunctionalityGPS positioning depends on accurate GPS time, navigation data containing satellite orbital parameters, and distance measurements. Should any of these three elements be missing, it would prevent the GPS based positioning. Unfortunately, this is often the case in urban areas due to poor satellite visibility. However, to recover positioning, the missing elements (except distance measurements) can be delivered through the cellular network. The cellular network can be equipped with a reference GPS receiver located in a place having an unobstructed view to the sky. Using the reference receiver, the network can receive navigation data, exact time, and so on, and relay this data over the cellular air interface to the user equipment.

An LCS client can request the UE location for example from the intelligent gateway mobile location centre (iGMLC) or from the UE. After validating the location requestor and the need to locate the UE, the iGMLC performs a request to the DX MSC (MSC). The MSC performs the UE search with, for example, paging and privacy checks, and subsequently sends a location reporting request to the serving RNC (SRNC). The SRNC requests the round-trip time (RTT) measurement for the UE from the base trans-ceiver station (BTS) and the Rx-TX (=TD) time difference measurements from the UE. The serving mobile location centre (SMLC) functionality calculates the UE location.

However, if the requested location accuracy cannot be fulfilled with cell-based location methods and the UE is GPS-capable, an A-GPS location method is initiated. The RNC itegrated SMLC function collects GPS assistance data from an A-GPS server or from SAS and sends the data with a location request (by using the RRC: Measurement Control message) to the UE. The UE uses the network provided assistance data and its GPS receiver to locate itself, and sends its coordinates to the RNC. The RNC vali-dates the UE positioning results, and returns the positioning responce to the core network.

ArchitectureThe network architecture and its elements for the A-GPS positioning method are shown in figure UE-based A-GPS positioning method - signalling flow for mobile-terminated (MT) location request (LR).

DN0934844Issue 01

31


Id:0900d8058061e9eb

Figure 1 UE based A-GPS positioning method

The WCDMA RAN A-GPS solution includes an RNC integrated SMLC and an interface to the SAS or A-GPS server. This interface can be a 3GPP standard Iu-PC interface, or a proprietary binary interface (ADIF) to the external GPS reference network. The SAS/A-GPS Server depending on the operator's SAS/A-GPS Server vendor selection tracks all GPS satellites and is the responsibility of the SAS/A-GPS Server vendor.

AccuracyThe A-GPS positioning method improves the standard GPS accuracy by increasing its coverage; navigation messages are obtained through the UMTS terrestrial radio access network (UTRAN), which allows the GPS to operate in situations where the GPS data is disturbed (for example some indoor environments).

InterfacesThe following interfaces are involved in location procedures:

AGPS data interface (ADIF) A proprietary binary interface used for communication between the RNC Integrated SMLC and a A-GPS Server within RAN. The external GPS reference network tracks all GPS satellites. This interface passes the requested GPS assistance data to the UE through RAN.

Iu interface (radio access network application part (RANAP) protocol) The Iu inter-face passes location requests and responses from authenticated internal and external LCS applications between LCS entities in the core network and WCDMA RAS.

Iub interface (node B application part (NBAP) protocol) The Iub interface is used for communication between the LCS functional entities in the serving RNC and BTS. This interface passes the request for measurements, mea-surement result, and requests for LCS related transmissions or radio operations needed by the positioning method.

Iupc interface The Iupc interface is used for communication between the RNC inte-grate SMLC and a stand-alone SMLC (SAS) within the RAN. This 3GPP

Extrenalreferencenetwork

A-GPSdata Server

or SAS

UE

BTS

Assistance data RNC

X, Y, Z

N 61'26"47.75E 23'51"45.02

186.2m

32 DN0934844Issue 01


Id:0900d8058061e9eb

standard interface passes the requested GPS assistance data to the UE through the RAN.

For instructions, see Feature RAN2.0041: LCS – Cell Coverage Based (RTT) with Geo-graphical Coordinates, Feature Activation Manual in WCDMA RNC Product Documen-tation.

DN0934844Issue 01

33


Id:0900d8058061ea23

1.3 RAN384 and 814: Emergency and Intelligent Emergency Call Inter-system Handover

1.3.1 DescriptionEmergency Call Inter-system Handover (EMISHO) and intelligent Emergency Call Inter-system Handover (iEMISHO) features belong to the application software. The iEMISHO feature offers enhancements to the EMISHO feature.

The premise of the EMISHO feature is when a Wideband Code Division Multiple Access WCDMA user makes an emergency call, the network recognises that it is an emergency call from the related locationing request, and begins the handover procedures to the GSM network. As a backup, the positioning of the user is initiated simultaneously in the WCDMA RAN. Once the call has been established in the GSM network, the GSM location technology computes a caller location estimate and the result is routed to the Public Safety Answering Point (PSAP). If the Inter-System Handover (ISHO) fails, the WCDMA network uses any or all of the available methods when trying to fulfill the requested Quality of Service (QoS).

In the intelligent EMISHO solution, the location is first computed in the WCDMA network using the CI+RTT locationing method. If the cell-based solution can fulfill the requested accuracy, the position coordinates are forwarded to the Core Network (CN) as a response. If the required location accuracy cannot be fulfilled with the CI+RTT, the solution will check the assisted GPS (A-GPS) capability in the UE and RAN, and compute an A-GPS location if it is supported. If A-GPS cannot be initiated, the solution checks if iEMISHO is enabled. If it is, an ISHO is initiated. If the ISHO fails, the CI+RTT location result is returned to the core network. If the A-GPS method can be initiated, emergency call ISHO is not initiated in any case. If the A-GPS calculation is successful, position coordinates calculated with A-GPS are returned to CN (regardless of achieved accuracy). If the A-GPS fails, the CI+RTT location result is returned to the core network.

The EMISHO call-flow is shown in Figure EMISHO call-flow and, respectively, the iEMISHO call flow is shown in Figure iEMISHO call-flow.

1.3.2 FunctionalityThe call flows and signalling scenarios with EMISHO and iEMISHO feature are described in the following chapters.

EMISHO FunctionalityWhen a user makes an emergency call within the WCDMA network, the call flows and signalling scenarios with EMISHO feature are depicted in the figures below:

34 DN0934844Issue 01


Id:0900d8058061ea23

Figure 2 EMISHO call flow

From the Radio Access Network (RAN) perspective, the EMISHO is activated when a RANAP: Location Reporting Control message for an emergency call (that is, CLIENT TYPE = Emergency Services) is received in the Radio Network Controller RNC. Simultaneously, the RNC initiates the normal location procedure and the normal ISHO. If the location procedure is finished before the ISHO attempt, the location result is stored within the RNC to wait for an ISHO attempt.

If the ISHO is successful, the location results are destroyed and the ISHO is completed according to the normal ISHO procedure (by sending the RANAP: Relocation Required message to the CN).

If the ISHO fails, the location result generated in the WCDMA RAN is returned to the CN as a fall-back solution.

iEMISHO FunctionalityWhen a user makes an emergency call within the WCDMA network, the call flows and signalling scenarios with iEMISHO feature are depicted in the figures below:

3G MSC

GSM MSC

SourceUMTS RAN

TargetGSM BSS

3. Handover to GSM

1. Emergency CallEstablishment

2. Location Request

5. Positioning 4. Location Request

6. Location

7. Location

8. LocationRequest

9. Location

PSAP

Route of callbefore handover

Route of callafter handover

GMLC

DN0934844Issue 01

35


Id:0900d8058061ea23

Figure 3 iEMISHO call flow when location accuracy was not sufficient enough

From the radio access network perspective, the iEMISHO is activated when a RANAP: Location Reporting Control message for an emergency call (that is, CLIENT TYPE = Emergency Services) is received in the RNC. Based on the locationing request, the RNC initiates the normal location procedure. If the location procedure successfully fulfills the requested QoS, the WCDMA RAN reports the achieved location estimate to the CN. Any available method can be used to fulfill the requested accuracy (CI+RTT, A-GPS), but if the A-GPS method can be initiated, the emergency call ISHO is not initiated in any case. If the A-GPS calculation is successful, position coordinates calculated with A-GPS are returned to CN (regardless of achieved accuracy). If A-GPS fails, the CI+RTT location result is returned to the core network.

If the CI+RTT method does not fulfill the requested accuracy and the A-GPS method cannot be initiated, an ISHO is initiated to handover the call to the GSM network. The location result generated by the WCDMA RAN is stored within the RNC to wait for an ISHO attempt.



1.3.3 Configuration requirements for EMISHO and intelligent EMISHOThe configuration requirements for the EMISHO and intelligent EMISHO solution are as follows:

• The GSM network must have overlapping coverage. • The GSM location service must be available.

3G MSC

GSM MSC

SourceUMTS RAN

TargetGSM BSS

4. Handover to GSM


2. Location Request


7. Location

8. Location

9. Location

PSAP



3. Positioning

GMLC

36 DN0934844Issue 01


Id:0900d8058061ea23

• In the core network, the Non-call-associated Signalling (NCAS) method must be selected to deliver the location estimate to the emergency center.

1.3.4 Functional restrictions on EMISHO and intelligent EMISHOThe EMISHO and intelligent EMISHO features rely on the fact that there is interopera-bility between the GSM and WCDMA networks and that a phase II compliant location technology exists in the GSM network.

1.3.5 ParametersThe following parameters are related to the feature:

• LCS Functionality • WCDMA GSM Inter-System Handover

For more information, see WCDMA RAS05.1 Parameter Dictionary in the RN2.2 library.

1.3.6 Concepts

1.3.6.1 Abbreviations • A-GPS = Assisted Global Positioning System • CN = Core Network • ISHO = Inter-System Handover • NCAS = Non-Call-Associated Signalling • RAN = Radio Access Network • RNC = Radio Network Controller • WCDMA = Wideband Code Division Multiple Access

DN0934844Issue 01

37


Id:0900d8058061ea48

1.4 RAN875: Network Based A-GPS Using External Reference NetworkNetwork Based Assisted Global Positioning System (A-GPS) Using External Reference Network RAN feature belongs to application software.

WCDMA RAS05.1 supports the network based assisted GPS (A-GPS) positioning method. Network based A-GPS is a method to establish a GPS reference network with a GPS position calculation entity. The GPS reference network receivers have an unob-structed view of the sky and can operate continuously. At the request of a user equip-ment or a network based application, the RAN collects the required GPS data from this reference network and generates the required assistance data elements for the UE. The assistance data from the GPS reference network can be transmitted to the UE to improve the GPS receiver performance. To be more specific, the assistance data speeds up the signal measurement function in the UE, thereby reducing UE battery con-sumption. The UE's GPS signal measurements are sent back to the network. RAN uses these measurements and the GPS position calculation entity to determine the UE's loca-tion.


1.4.1 Requirements





• There must be RRMU units on the RNC. • A stand-alone SMLC (SAS) is needed for GPS assistance data and for position cal-

culation. • Location services (LCS) A-GPS Site Solution related hardware for transmission is

needed between the RNC and the SAS. • A-GPS hardware is required in the UE.

End-user equipmentThe UE must support the A-GPS feature. In practice, the UE must be equipped with a GPS receiver. Furthermore, the UE must be able to receive assistance data from the network, take measurements from the appropriate GPS satellites, and send the mea-surement results to the network.

38 DN0934844Issue 01


Id:0900d8058061ea48




1.4.2 FunctionalityGPS positioning depends on accurate GPS time, navigation data containing satellite orbital parameters, and distance measurements. Should any of these three elements be missing, it would prevent the GPS based positioning. Unfortunately, this is often the case in urban areas due to poor satellite visibility. However, to recover positioning, the missing elements (except distance measurements) can be delivered through the cellular network. The cellular network can be equipped with a reference GPS receiver located in a place having an unobstructed view to the sky. Using the reference receiver, the network can receive navigation data, exact time, and so on, and relay this data over the cellular air interface to the user equipment.


However, if the requested location accuracy cannot be fulfilled with cell-based location methods and the UE is GPS-capable, an A-GPS location method is initiated. The RNC SMLC function collects GPS assistance data from the SAS and sends the data with a location request (by using the RRC: Measurement Control message) to the UE. The UE uses the network provided assistance data and its GPS receiver to make the GPS signal measurements and sends the signal measurements to the RNC.

The RNC sends the GPS measurement information to the SAS requesting the position calculation. The SAS calculates the UE location and responds to the RNC request. After receiving the UE location from the SAS, the RNC sends the locationing result to the core network.

ArchitectureThe network architecture and its elements for the A-GPS positioning method are shown in figure Network based A-GPS positioning method. This figure depicts the signalling flow for a mobile-terminated (MT) location request (LR).

DN0934844Issue 01

39


Id:0900d8058061ea48

Figure 4 Network based A-GPS positioning method

The WCDMA RAN A-GPS solution includes an RNC integrated SMLC and an interface to the SAS. This interface is a 3GPP standard Iu-PC interface. The external GPS refer-ence network tracks all GPS satellites and is the responsibility of the SAS vendor.

AccuracyThe A-GPS positioning method improves the standard GPS accuracy by increasing its coverage; navigation messages are obtained through the UMTS terrestrial radio access network (UTRAN), which allows the GPS to operate in situations where the GPS data is disturbed (for example indoors).




Iupc interface The Iupc interface is used for communication between the RNC inte-grated SMLC and a stand-alone SMLC (SAS) within the RAN. This 3GPP standard interface passes the requested GPS assistance data to the UE through the RAN, receives raw measurements from the UE through the RAN, and passes computed A-GPS positions to the RAN.



SAS

UE

BTS

Assistance data

Raw measurements RNC

N 61'26"47.75E 23'51"45.02

186.2m

XYZ

40 DN0934844Issue 01


Id:0900d805805e5450

Transmission and transport features

2 Transmission and transport features

2.1 RAS05.1 transmission and transport features overview

2.1.1 Further informationFor feature activation instructions, see WCDMA RNC Product Documentation.

For more detailed information on parameters, counters and alarms, see WCDMA Radio Network Configuration Parameters, Overview of WBTS Counters and Alarm Structure documents.

For information on RAN1.5, RAN04 and RAS05 features, see Section Transmission and transport features overview in RAN04 and RAS05 Transmission and Transport Fea-tures.

Feature name Available in releases

RAN165: IP Based Control Plane at Iu and Iur

RAS05.1

RAN324: Dynamic HSDPA Transport Scheduling

RAS05.1

RAN717: Iu-PS IP Quality of Service Support (DiffServ in GTPU)

RAS05.1

RAN935: BTS AAL2 Multiplexing for Flexi WCDMA BTS

RAS05.1

RAN939: Flexbus Interface for Flexi WCDMA BTS

RAS05.1

RAN940: E1 Interface for Flexi WCDMA BTS

RAS05.1

RAN941: JT1 Interface for Flexi WCDMA BTS

RAS05.1

RAN942: SDH STM-1 Interface for Flexi WCDMA BTS

RAS05.1

RAN944: Use of GSM Transmission (Flexi WCDMA BTS)

RAS05.1

RAN946: T1 Interface for Flexi WCDMA BTS

RAS05.1

RAN1020: Route Selection RAS05.1

RAN1062: IMA (Flexi WCDMA BTS) RAS05.1

RAN1086: AXC ATM interface oversub-scription

RAS05.1

Table 2 Transmission and transport features for RAS05.1

DN0934844Issue 01

41


Id:0900d805805e5428

2.2 RAN165: IP Based Control Plane at Iu and Iur

2.2.1 Feature descriptionThe IP-based control plane is introduced as an option to the ATM-based control plane transport architecture. It supports the evolution of the mobile core network towards an all-IP network.

This feature enables the use of IETF Signalling Transmission (SIGTRAN) protocols (M3UA and SCTP) in the RNC in order to transport the signalling protocols over IP trans-port networks.

The IP-based control plane is available at Iu-PS, Iu-CS, and Iur interfaces.

The feature requires IP over ATM transport and, therefore, is supported in ATM inter-faces. No other ATM layer is supported.

The following figure depicts the protocol stack for the three interfaces.

Figure 5 Protocol stack for the supported interfaces

For Iu-PS, IuCS and for Iur the protocol stack is according to the 3GPP IP transport option, with IP signalling stack.

2.2.1.1 Operator benefitsWith this feature, the operator is able to connect the RNC to other network elements, which already implement IP-based signalling.

2.2.1.2 ComplianceThis feature is compliant with the 3GPP and IETF standards for the control plane proto-cols.

ATM is the only data link protocol supported.

2.2.1.3 Resource requirements

System requirementsThis feature requires ATM core network.

RANAP RNSAP

SCCP

M3UA

AAL5

lu-CS & lu-PS lur

SCTP

IPv4

ATM

Physical Layer

42 DN0934844Issue 01


Id:0900d805805e5428

Software requirementsThis feature sets the following requirements:

• RAS release: RAS05.1 • RNC release: RN2.2

Hardware requirementsThis feature has no hardware requirements.

Operator requirementsThe operator has to configure the RNC with the IP-based signalling protocol stack during the integration phase.

Any other network element connected to the RNC through a signalling interface where this feature is activated should also support SIGTRAN and have a compatible configu-ration.

If the network element connected to the RNC does not support SIGTRAN over an ATM link, an appropriate interworking device should be used.

End-user requirementsNot applicable.

2.2.1.4 Interaction with other featuresNot applicable.

2.2.1.5 Limitations and restrictionsIP-based control plane is supported only over ATM interfaces.

2.2.2 Main functionality

2.2.2.1 Using IP-based control planeIf some or all of the network elements connected to the RNC through Iu and Iur inter-faces that use IP-based control plane, the feature can be activated for those interfaces. The other interfaces can be configured for ATM-based control plane.

In RNC implementation, the IP protocol is encapsulated over ATM. If the RNC is to be connected to other network elements, which do not support IP over ATM, a router should be used to convert IP over ATM into the appropriate network technology (such as Ether-net). Using a router is particularly required when connecting the RNC to the Nokia Combi-SGSN.

Configuration and management of this feature is done by using the MMI system and MML commands during the configuration of the signalling links at the RNC integration phase.

Prior to the configuration, it is required to perform the planning for ATM, IP, and the sig-nalling networks.

DN0934844Issue 01

43


Id:0900d805805e5428

2.2.2.2 Activating IP-based control planeNetwork planning will make the network parameters available for configuring the feature. The main steps, needed to take the feature into use, are given below.

The main steps needed to take the feature into use are given below.

To activate IP-based control plane:

1. Create the association sets and associations.2. Assign IP addresses to ATM interfaces and create routes.3. Create the signalling link.4. Create the signalling route.5. Activate the configuration.

2.2.2.3 Verifying IP-based control planeThe feature can be verified with the steps given below.

To verify IP-based control plane:

1. Interrogate the IP configuration.2. Interrogate the association states.3. Verify M3UA alarms status.

2.2.2.4 Deactivating IP-based control planeThe main steps needed to deactivate the feature are given below.

To deactivate IP-based control plane:

1. Remove the SSCP-level configuration.2. Remove the M3UA and SCTP -level configuration.3. Delete the IP signalling link.

2.2.2.5 Feature managementThe following parameter sets are needed for this feature:

• Association set parameters • SCTP association -level parameters

If the default values are not suitable, they can be modified by using MML commands.

Additionally, a set of alarms is available for verifying the status of the signalling.

2.2.2.6 ArchitectureThe following figure illustrates the architecture of this feature and the relations with other network elements.

44 DN0934844Issue 01


Id:0900d805805e5428

Figure 6 Architecture of IP-based control plane

2.2.2.7 CapacityNot applicable.

2.2.3 Network managementNot applicable.

RNC

ATM I/F

lur

ATMI/F

ATMI/F ATM I/Flu-CS

lu-PS

ATM I/F

Ethernet I/F

Ethernet I/F

IP over ATM

SGSN

MGW

ICSU

ICSU

ICSU

RNC

DN0934844Issue 01

45


Id:0900d805805e542b

2.3 RAN324: Dynamic HSDPA Transport Scheduling

2.3.1 Feature descriptionThe Dynamic High-speed Downlink Packet Access (HSDPA) Transport Scheduling feature introduces a dynamic flow control for HSDPA traffic between the ATM adapta-tion layer type 2 (AAL2) and Medium Access Control (MAC) layers in the RNC. It prevents packet loss in RNC AAL2 buffers and thus increases system performance and Quality of Service (QoS) for end users. In addition, the feature makes operating of the RNC easier from the transport point of view. The feature also increases Iub efficiency.

3GPP HSDPA flow control is not aware of the Iub capacity available for the HSDPA, and thus may request more data than there is capacity for in the Iub. This may cause the AAL2 queue to overflow, which causes RLC or TCP retransmissions. The HSDPA flow control is not used on Iur.

Dynamic HSDPA Transport Scheduling is an optional feature. If it is disabled, static rate control is used which is a basic functionality in the RNC. The functionality is described in section Static Rate Control for HSDPA Data.

In addition, it is possible to disable both dynamic scheduling and rate control. If both are disabled, there is no functionality controlling the HSDPA data transfer from the transport point of view. The parameter internal HSDPA flow control method defines the method used.

The feature is for both shared Virtual Channel Connection (VCC) and dedicated VCC transport solutions.

The figure HSDPA flow control architecture with shared VCC below depicts the archi-tecture:

Figure 7 HSDPA flow control architecture with shared VCC

When the dynamic HSDPA transport scheduling feature is turned on, each VCC that handles HSDPA user plane traffic in the downlink direction has its own flow control func-tionality. When flow control messages are sent, they are sent to all HSDPA data sending entities in the MAC layer that send data to the VCC in question.

An AAL2 buffer handled by the flow control mechanism contains one operator-configu-rable threshold (Low), which is shown in the following figure The thresholds of an AAL2

NRT DCH(PS Data)

RT DCH(Voice)HSDPA

Scheduler

RLCMAC

DMPG

AAL2 queues

Low priority High priority

A2SUVCC

Priorityscheduler

HSDPA AAL2flow control

46 DN0934844Issue 01


Id:0900d805805e542b

queue. There are also other dynamically adjustable thresholds that affect the flow control message sending by reducing and increasing the incoming rate to the buffer.

Figure 8 The thresholds of an AAL2 queue

The Low threshold is used to define how aggressively flow control functions.

• If the Low threshold is a relatively low value in respect to the AAL2 queue target delay, it can mean that the flow control restricts the data flow too much. This reduces the performance.

• If the Low threshold is set to a relatively high value in respect to the AAL2 queue target delay, it can mean that all the thresholds in the queue are close to each other. This makes the flow control functionality to operate as if it had only an ON/OFF mode. Additionally, the internal RNC load increases due to the growth of flow control messages.

The flow control functionality checks the service rates (throughputs) of both:

• the Dedicated Traffic Channel (DCH) queue (in shared VCC situation); • HSDPA queue in short intervals.

After a window of intervals, a new set of queue thresholds are calculated and taken into use to avoid exceeding the AAL2 queue target delay.

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

If a dedicated VCC for HSDPA is used, the threshold values are calculated differently, because the available bandwidth for the HSDPA is constant.

The dynamic HSDPA transport scheduling functionality is independent of the HSDPA flow control defined by the 3GPP. However, the RNC is able to provide interworking between these two flow controls for the best performance.

2.3.1.1 Operator benefitsThis feature enhances the HSDPA capacity management on Iub. This leads to a better QoS of HSDPA users and more optimised usage of the Iub transport resources.

Incoming rate

AAL2queue

Service rate

High

Low

LHigh

HLow

DN0934844Issue 01

47


Id:0900d805805e542b

2.3.1.2 ComplianceThe feature is 3GPP compliant.


System requirementsThis feature has no system requirements

Software requirementsThe feature sets the following requirements:



Operator requirementsThe dynamic flow control for HSDPA is managed in the RNC with the parameters listed below. The parameters are stored in the radio network database. More information on parameters can be found in the parameter dictionary.

If the following parameter values are changed, it should be done when the user and traffic amount is low to minimize the disturbance to the HSDPA traffic. After the change, the counters of the AAL2 scheduling performance measurement should be checked very carefully that the outcome is what was wanted.

It should be noted that if the ‘Internal HSDPA flow control method‘–parameter is set to DYNAMIC, the ‘Shared HSDPA flow control allocation’ parameter value is not used for anything.

Parameter name: Internal HSDPA flow control method

Abbreviated name: InternalHSDPAflowControlMethod

Description: Defines the used internal flow control method for the HSDPA traffic. Either static rate control or dynamic flow control can be used. Both control methods can also be turned off. When they are turned off, there is no control method for the HSDPA data used. This applies both to shared and dedicated VCC solutions.

Parameter name: HSDPA flow control AAL2 queue low threshold for shared VCC

Abbreviated name: HSDPAflowControlLowThresholdSharedVCC

Description: The low threshold is an AAL2 buffer occupancy threshold in a shared VCC, which triggers sending the ‘full rate’ (that is, the max. allowed rate) flow control messages to the HSDPA data sending entities it is passed downward (that is, the buffer is getting emptier).

Parameter name: HSDPA flow control AAL2 queue target delay for shared VCC

Abbreviated name: HSDPAflowControlTargetDelaySharedVCC

48 DN0934844Issue 01


Id:0900d805805e542b

End-user requirementsThe feature has no end-user requirements.

2.3.1.4 Interaction with other featuresRoute Selection makes it possible to dedicate a VCC for HSDPA.

2.3.1.5 Limitations and restrictionsDynamic HSDPA Transport Scheduling is an optional feature. When it is enabled, the static rate control for HSDPA is disabled.


2.3.2.1 Using Dynamic HSDPA Transport SchedulingThe feature parameters are handled via the RNC RNW Object Browser GUI or via Nokia NetAct™. The new parameters of the feature are listed in Section Operator require-ments.

2.3.2.2 Activating Dynamic HSDPA Transport SchedulingThe license for the feature has to be purchased, and the internal HSDPA flow control method parameter must be given the value DYNAMIC.

2.3.2.3 Verifying Dynamic HSDPA Transport SchedulingThe feature must be enabled and turned on. After this, a HSDPA call needs to be made, and new counters are updated (for example, measuring AAL2 delay).

Description: Defines the maximum allowed delay caused by AAL2 queueing in a shared VCC.

Parameter name: HSDPA flow control AAL2 queue low threshold for dedicated VCC

Abbreviated name: HSDPAflowControlLowThresholdDedicatedVCC

Description: The low threshold is an AAL2 buffer occupancy threshold in a dedicated VCC, which triggers sending the ‘full rate’ (that is, the max. allowed rate) flow control messages to the HSDPA data sending entities when it is passed downward (that is, the buffer is getting emptier).

Parameter name: HSDPA flow control AAL2 queue target delay for dedicated VCC

Abbreviated name: HSDPAflowControlTargetDelayDedicatedVCC

Description: Defines the maximum allowed delay caused by AAL2 queueing in a dedi-cated VCC.

DN0934844Issue 01

49


Id:0900d805805e542b

2.3.2.4 Deactivating Dynamic HSDPA Transport SchedulingThe parameter internal HSDPA flow control method needs to be given the value STATIC or NONE.

2.3.2.5 Feature managementParameters related to the feature are displayed in Sections Operator requirements and Resource requirements. There are no special alarms related to this feature.

There are new performance counters available for monitoring the performance and opti-mising the parameters for the feature. These counters are grouped into a new measure-ment: AAL2 scheduling performance in RNC. The measurement object is the ATM VC connection termination point in the RNC A2SU unit. Measured connections are identi-fied with the RNC-external interface ID / VPI / VCI values.

The AAL2 scheduling performance is measured for HSDPA traffic only (i.e. low priority queue). In the case of congestion the low priority queue length increases and the Iub delay for HSDPA traffic increases. If there is no HSDPA functionality activated in the network, the counters will not be updated. Therefore, the counters are updated only for Iub interface AAL2 connections.

The counters can be used to monitor the following issues:.

Measuring the AAL2 queue service rate in DL:

• Average number of sent AAL2 CPS packets (HSDPA queue) • Peak value of sent AAL2 CPS packets (HSDPA queue)

The service rate is sampled constantly (once per second) and the average values can be calculated as an average of all sampled values. The counters are not updated if there is no traffic during the sampling period. Peak value is the highest of the sampled values during the measurement period.

Measuring the estimated AAL2 layer buffering delay:

• Average AAL2 layer buffering delay (HSDPA queue) • Peak value of the delay caused by AAL2 layer buffering (HSDPA queue)

The delay is sampled constantly (once per second) and average delay values can be calculated as an average of all sampled values. Peak value is the highest of the sampled values during the measurement period. The counters are not updated if there is no traffic during the sampling period. These counters can be used to follow the long term trend of buffering delay and as a measure of Iub load in downlink.

Measuring HSDPA flow control performance:

• Number of “slow down” flow control messages sent to the MAC layer • Number of “speed up” flow control messages sent to the MAC layer • Number of 'full stop' flow control messages sent to the MAC layer

These counters indicate the flow control mechanism activity.

Measuring AAL2 traffic loss due to congestion:

• Number of events when AAL2 CPS packets were dropped from the AAL2 buffer due to too high a delay or buffer overflow (HSDPA queue). These counters indicate if there is traffic loss in RNC due to Iub congestion (i.e. all traffic sent from MAC layer has not fit in to the ATM VCC).

50 DN0934844Issue 01


Id:0900d805805e542b

2.3.2.6 ArchitectureThe feature architecture is explained in Section Feature description.

2.3.2.7 CapacityThe feature prevents packet loss in RNC AAL2 buffers and thus increases system per-formance and the end-users’ QoS.

2.3.3 Network managementDynamic HSDPA Transport Scheduling is an internal feature in the RNC and thus does not have any effects on the network management.

PlanThe feature has no effects on network planning.

IntegrateThe feature has no effects on network integration.

Trouble managementNone.

2.3.4 Static rate control for the HSDPA dataStatic Rate Control for HSDPA Data is the applied functionality if Dynamic HSDPA Transport Scheduling is not enabled. The static rate control for HSDPA functionality limits the data amount, sent by a DMPG unit to a specific value. This quantity depends on the number of HSDPA users in the cell and on the allowed Iub bandwidth of a VCC to the cell in question. The value is called Maximum VCC HSDPA Bit rate per DMPG (MVHBD).

The MVHBD value is calculated with the following formula shown in the Figure The cal-culation of MVHBD value:

Figure 9 The calculation of MVHBD value

In the formula above, SHFCA is the shared HSDPA flow control allocation parameter.

This functionality is needed because a major difference between Iub capacity and DMPG throughput might cause AAL2 queues to overflow.

For example, if there is one VCC carrying HSDPA traffic and there are three HSDPA users in a cell and they are all in different DMPGs, each DMPG is allowed to send an amount of MVHBD value which is one-third of the bandwidth indicated by the SHFCA. If all three HSDPA users are located in the same DMPG, the DMPG is equal to the SHFCA, and thus, the DMPG is allowed to send the worth of the SHFCA. The MVHBD is updated and signalled after every HSDPA connection setup and release in a cell to the DMPGs which are sending data to it.

If there are more that one VCCs for HSDPA traffic on the route, the SHFCA value is divided with the number of VCCs.

This applies both to shared and dedicated VCC solutions.

MVHBD =Number of VCC HSDPA users in a DMPG

Total ammount of HSDPA users in a VCCx SHFCA

DN0934844Issue 01

51


Id:0900d805805e542b

Operator requirementsStatic rate control for HSDPA is managed in the RNC with the parameters listed below. The parameters are stored in the radio network database. More information about parameters can be found in the parameter dictionary.

If the ‘Internal HSDPA flow control method’ is set to STATIC and the route has more than one VCC carrying the HSDPA traffic, the parameter ‘Shared HSDPA AAL2 VCC Selection Method’ parameter should be set to value 1. That is, divide the Shared HSDPA AAL2 allocation to all VCCs because the Shared HSDPA Flow Control Allocation is divided also and thus the Iub bandwidth is used more efficiently.

2.3.4.1 Main functionality

Activating Static rate control for the HSDP dataThe internal HSDPA flow control method parameter has to be given the value STATIC.

Verifying static rate control for HSDPA dataA HSDPA call needs to be made, and PM counters are updated.

Deactivating static rate control for HSDPA dataThe parameter internal HSDPA flow control method needs to be given the value DYNAMIC or NONE.

Feature managementWith this functionality, no new performance counters are available. The AAL2 schedul-ing performance in RNC measurement can be used to monitor the possible Iub conges-tion that is visible through increased delays and AAL2 CPS packet dropping. However, not all counters are updated, since the Dynamic HSDPA Transport Scheduling feature is not activated




Parameter name: Shared HSDPA flow control allocation

Abbreviated name: SharedHSDPAFlowControlAllocation

Description: This ATM protocol level parameter defines the maximum amount of HSDPA traffic which the RNC is allowed to send to a VCC on Iub. This parameter is WBTS specific. Although the max value in the range is 14.4 Mbps, the value of this parameter must not be set to be bigger than the Iub capacity between the BTS and the RNC. If the value is modified online, it is taken into use next time the shared HSDPA allocation is set up on the BTS

52 DN0934844Issue 01


Id:0900d805805e542b

ArchitectureThe feature architecture and functionality are explained at the beginning of Section Static rate control for the HSDPA data.

CapacityThis functionality prevents packet loss in RNC AAL2 buffers and thus increases system performance and the end-users’ QoS when compared to a situation where there is no control for HSDPA data at all.

2.3.5 Network managementThis is an internal functionality in the RNC and thus does not have any effects on the network management.

DN0934844Issue 01

53


Id:0900d805805e542e

2.4 RAN717: Iu-PS IP Quality of Service Support (DiffServ in GTPU)

2.4.1 Feature descriptionThe Iu-PS IP Quality of Service Support (DiffServ in GTPU) solution enables the differ-entiation of ingress traffic and the prioritisation of one traffic class over the other. This prevents small real-time packets from being delayed by large non-real time packets.

The prioritisation is independent for each available GTPU.

With this feature, the Differentiated Services Code Point (DSCP) of the packet is used to classify the traffic into two traffic classes:

• Real Time (RT) • Non-Real Time (NRT)

An example of this type of mapping is presented in Table DSCP to traffic class mapping.

The priority of the two traffic classes will be defined by using the RT/NRT ratio parame-ter. It determines the number of RT packets that are processed before one single NRT packet is processed.

If there are no packets of one class, packets of the other class will be processed.

The count of the number of processed RT packets will be reset in the following cases:

• one NRT packet is processed, and/or • the maximum value of the count (RT/NRT ratio) is reached.

When the total rate of the received NRT and RT packets is higher than the GTPU pro-cessing capacity, congestion will occur for both traffic classes. Incoming packets will be lost, regardless of the traffic class.

2.4.1.1 Operator benefitsThis solution allows more flexible Iu-PS connections and GTPU capacity usage for dif-ferent traffic combinations and enables more efficient packet data handling in the RNC. With this feature, NRT and RT traffic can be handled by the same GTPU and NRT traffic delay is also reduced.

The feature also enables the end-to-end deployment of DiffServ in the Iu-PS interface in the downlink direction.

DSCP Traffic Class

101110 RT

001010, 001100, 001110 RT

010010, 010100 010110 NRT

011010, 011100, 011110 NRT

100010, 100100, 100110 NRT

000000 NRT

Table 3 DSCP to traffic class mapping

54 DN0934844Issue 01


Id:0900d805805e542e

2.4.1.2 ComplianceThe feature is compliant with 3GPP and IETF standards.


System requirementsNone.



Hardware requirementsThe feature has no special hardware requirements.

Operator requirementsThis feature is optional, and therefore, a license is required.

The feature has to be activated for the whole RNC. If the default configuration is not suit-able, it should be changed. The changes in the configuration will affect all the GTPUs in the RNC.

If the feature is not activated, NRT and RT packets will be treated with the same priority.

The operator has to configure the following parameters with the Service Terminal Exten-sion:

• DSCP to Traffic Class mapping • RT/NRT ratio

The SGSN configuration should be consistent with the DSCP to Traffic Class mappings, that is, the RT and NRT packets should use the same DSCPs as in the RNC. Otherwise, the performance of the network might degrade.

End-user requirementsNone.

2.4.1.4 Interaction with other featuresNone.

2.4.1.5 Limitations and restrictionsThis feature is supported only for ingress traffic.


2.4.2.1 Using DiffServ in GTPUThe feature is configured in OMU at the network element level by using the Service Terminal Extension. Therefore, the configuration affects all the GTPUs.

DN0934844Issue 01

55


Id:0900d805805e542e

The RT traffic class must be defined for each DSCP allocated to that class. Otherwise, the DSCP is allocated to the default NRT traffic class.

The RT/NRT ratio must also be defined. The default ratio is 0.

The configuration can be changed during the operation of the Iu-PS interface without losing traffic.

2.4.2.2 Activating Iu-PS IP Quality of Service Support (DiffServ in GTPU) The feature has to be activated for the whole network element by using the Service Terminal Extension before it can be used by any GTPU.

The feature is activated when the RT/NRT ratio is other than 0. As long as the RT/NRT ratio remains 0, the feature will not be active.

2.4.2.3 Verifying DiffServ in GTPUThe DiffServ configuration can be verified by using the Service Terminal Extension con-nected to OMU.

The following information is printed out:

• Traffic Class for each DSCP • RT/NRT ratio

2.4.2.4 Deactivating DiffServ in GTPUThe feature can be deactivated for the whole network element by using the Service Terminal Extension connected to OMU.

The feature is deactivated when the RT/NRT ratio is equal to 0.

2.4.2.5 Feature managementNot applicable

2.4.2.6 ArchitectureThe following figure illustrates the architecture of the feature.

56 DN0934844Issue 01


Id:0900d805805e542e

Figure 10 Architecture of lu-PS IP Quality of Service Support (DiffServ of GTPU)

2.4.2.7 CapacityNot applicable.

2.4.3 Network managementNot applicable.

Unclassifiedpackets

Classified packetsbased on DSCP

GTPU

TCP/UDP/IP

rt1 rt2nrt1 nrt2

rt1 rt2 nrt1 nrt2

RNC upper layers

DSCP toTraffic classmappings

RT/NRTratio

ParameterDatabase

RNC

Iu-PS interface rt nrt

DSCP marking

SGSN

DN0934844Issue 01

57


Id:0900d805805e5431

2.5 RAN935: BTS AAL2 Multiplexing for Flexi WCDMA BTS

2.5.1 Feature descriptionBTS AAL2 Multiplexing enables statistical multiplexing gain at AAL2 layer. In addition this feature allows simpler network configuration with a reduced number of AAL2-VCCs.

AAL2 Multiplexing is inherent to the Next Generation WCDMA BTS architecture and therefore available from the first FTM release onwards.

58 DN0934844Issue 01


Id:0900d805805e5434

2.6 RAN939: Flexbus Interface for Flexi WCDMA BTS

2.6.1 Feature descriptionEach Flexbus interface enables a single-cable connection between the BTS and Flexi-Hopper/MetroHopper microwave radio outdoor units. No external transmission equip-ment is needed.

The coaxial Flexbus cable carries user plane data and O&M traffic, and also supplies power (30W) to the radio outdoor unit. The user plane capacity is 16x2M. ATM is mapped into E1, with support of IMA. In addition TDM cross connections are supported at 2M level.

Figure 11 Flexbus Interface for Flexi WCDMA BTS

DN0934844Issue 01

59


Id:0900d805805e5437

2.7 RAN940: E1 Interface for Flexi WCDMA BTS

2.7.1 Feature descriptionFlexi WCDMA BTS supports standard compliant E1 (UNI) interfaces, both twisted pair (symmetrical, 120 Ohm) and coaxial (asymmetrical, 75 Ohm).

The following transport sub modules are available:

• FTPB, 8xE1/T1/JT1 (symmetrical, 120 Ohm) • FTEB, 8xE1 coaxial (asymmmetrical, 75 Ohm) • FTIA, 4xE1/T1/JT1 (symmetrical, 120 Ohm), 2xFast Ethernet, 1xGigabit Ethernet

(optional) • FTJA, 4xE1 coaxial (asymmetrical, 75 Ohm), 2xFast Ethernet, 1xGigabit Ethernet

(optional)

This feature supports E1/T1/JT1 interfaces only. Please see RAN1064: Ether-net+E1/T1/JT1 Interface Unit (Iub User Plane) for Flexi WCDMA BTS for Ethernet inter-faces.

Figure 12 E1 Interface for Flexi WCDMA BTS

60 DN0934844Issue 01


Id:0900d805805e543a

2.8 RAN941: JT1 Interface for Flexi WCDMA BTS

2.8.1 Feature descriptionFlexi WCDMA BTS supports standard compliant JT1 (UNI) interfaces.


• FTPB, 8xE1/T1/JT1 (symmetrical, 120 Ohm) • FTIA, 4xE1/T1/JT1 (symmetrical, 120 Ohm), 2xFast Ethernet, 1xGigabit Ethernet

(optional)


Figure 13 JT1 Interface for Flexi WCDMA BTS

DN0934844Issue 01

61


Id:0900d805805e543d

2.9 RAN942: SDH STM-1 Interface for Flexi WCDMA BTS

2.9.1 Feature descriptionFTOA offers 1xSTM-1/VC-4 interface with a tailored throughput for a tail site.

Flexi WCDMA BTS supports standard compliant optical STM1 (VC4) interfaces.

Flexi WCDMA BTS transport sub-module FTOA supports one STM-1/VC-4 interface with a throughput that is limited to the equivalent of 16xE1. This capacity might be enhanced by additional software development effort in a later release if there is a need.

The same applies for Sonet support.

Figure 14 SDH STM-1 Interface for Flexi WCDMA BTS

2.9.2 Interdependencies between featuresThe FTOA transmission sub-module with STM-1/VC-4 interface needs to be installed to the Flexi WCDMA BTS System Module.

2.9.3 Hardware requirementsFlexi WCDMA BTS Transmission sub-module FTOA

62 DN0934844Issue 01


Id:0900d805805e5440

2.10 RAN944: Use of GSM Transmission (Flexi WCDMA BTS)

2.10.1 Feature descriptionATM cells from WCDMA BTSs are carried in PDH/SDH layer time slots, frames or virtual containers. The GSM transmission network, based on either PDH or SDH, delivers the bandwidth the ATM layer needs. The WCDMA appears as a capacity increase.

Existing physical transmission media, microwave (MW), fibre, copper and leased lines, can all be used. WCDMA BTS sites integrate with existing GSM sites and a common access link can be shared to act as both Iub and Abis.

DN0934844Issue 01

63


Id:0900d805805e5443

2.11 RAN946: T1 Interface for Flexi WCDMA BTS

2.11.1 Feature descriptionFlexi WCDMA BTS supports standard compliant T1 (UNI) interfaces.



(optional)


Figure 15 T1 Interface for Flexi WCDMA BTS

64 DN0934844Issue 01


Id:0900d805805e5446

2.12 RAN1020: Route Selection

2.12.1 Feature descriptionIn the RAS05 release, only the shared VCC transport solution is supported on the Iub interface. This means that RT/NRT DCH traffic is carried in the same CBR VCC(s) as HSDPA traffic. The shared VCC solution is efficient from the Iub interface’s point of view, but it also has limitations. For example, it is not possible to treat traffic types differently to achieve overbooking for HSDPA traffic without disturbing other traffic types.

In the shared solution, DCH traffic has priority over HSDPA traffic, which means that HSDPA traffic is transported only if there is free capacity in the VCC. The HSDPA traffic is thus treated as best effort.

More flexibility has been requested in selecting VCCs for different bearer types. The Route Selection feature for the RAS05.1 release is the first step to this direction, because it enables a dedicated user plane downlink VCC for HSDPA and DCH traffic only. Route Selection is an optional feature and it can be enabled per BTS.

The Route Selection feature does not require the support of Q.2630.2 CS-2 signalling. It is 3GPP compliant.

The feature can be used in two modes; plain or enhanced, depending on how the VCCs are configured in a route from DCH traffic point of view. In plain mode, there are only dedicated VCCs on a route. In enhanced mode there are both dedicated and shared VCCs on a route. Both modes have benefits and drawbacks

Plain modeThe main idea of using the RouSel feature in plain mode is to enable the operator to dedicate a VCC for HSDPA traffic only. In a route to BTS there is VCC(s) for DCH traffic and VCC(s) for HSDPA traffic. The transport network can support the overbooking or statistical multiplexing of HSDPA traffic, which allows bandwidth savings in the transport network.

When considering Route Selection, the transport network needs to be divided into three sections. The local switch section consists of the RNC and the ingress side of the local ATM switch, the hub section consists of the egress side of the local switch to the egress of the last mile switch, and the BTS section is the last link to the AXC/BTS as shown in Figure Route selection network configuration. The BTS section is usually called ‘the last mile’, and it is considered to be the bottleneck of the transmission network.

DN0934844Issue 01

65


Id:0900d805805e5446

Figure 16 Route selection network configuration

Generally, the transmission networks are dimensioned so that packet loss is minimised. While this method ensures that the transmission network does not decrease the end user QoS, it may also lead to inefficiency in network dimensioning, if it is dimensioned according to the rush hour.

The Route Selection feature enables the usage of statistical multiplexing of the HSDPA traffic in the transmission network. With statistical multiplexing, there is always the pos-sibility of losing traffic, but with proper dimensioning, this can be minimised.

In Route Selection, the VCCs in the RNC need to be configured so that there are dedi-cated CBR VCCs for each BTS (one for DCH traffic and the other for HSDPA traffic). The dimensioning of the VCCs on downlink depends on the need. If both VCCs are set half (or close) to the last mile capacity, there won’t be traffic loss in last mile but downsize is that either traffic type can’t use the bandwidth fully. On the other hand if both VCCs are dimensioned equal (or close) to the last mile capacity, the HSDPA traffic can use the last mile capacity fully if there is no DCH traffic, and vice versa. But the problem with such overbooking is that RNC may send more traffic to network than the last mile can handle and thus the HSDPA traffic will be lost. Also the need of AAL2 connectivity is doubled.

As the HSDPA VCC is configured to be of the CBR type, it gives HSDPA traffic a priority over O&M traffic, which is typically configured to be of the UBR type.

In uplink direction the associated DCH is established on the DCH VCC. On a HSDPA VCC only the FP-level control messaging is sent uplink. For these reasons the dedicated VCCs are recommended to be asymmetric. HSDPA downlink should have more band-width than HSDPA uplink and for DCH VCC the uplink should have more bandwidth than the downlink. Asymmetric configuration is for two purposes: it saves AAL2 connectivity and it prevents the uplink becoming the bottleneck of the system. Only in the VP level bandwidth needs to be symmetric.

The hub section consists of third-party ATM switches and the network between them. Getting benefits of statistical multiplexing requires a certain topology of the transmission network. There must be the so-called ‘hub points’ in which the de-multiplexing of several BTSs is done. In addition, there should be enough BTSs behind the hub points to get bandwidth savings (roughly 20 BTSs or more). In the hub section, the local switch should perform a CBR-UBR conversion (or CBR-VBR conversion) for the incoming HSDPA VCCs, because multiplexing CBR VCCs does not have any benefits. If there are

ATMswitch

BTS

BTS

RNC

lu-ps to SGSN(incl. HSDPA)

lu-cs to MGW(voice)

DCH traffic

HSDPA traffic

ATMswitch

BTS

lub

66 DN0934844Issue 01


Id:0900d805805e5446

no hub points, that is, the network has the ‘form of a star’ in which the RNC is in the middle, there are no benefits in using statistical multiplexing. The Figure Network topology containing hub points shows a possible network topology where statistical mul-tiplexing could be used.

Figure 17 Network topology containing hub points

With hub points, multiplexing and some clever network planning (that is, the rush hour is not in every BTS at the same time), the VCCs can be dimensioned in a way that the sum of ingress HSDPA VCCs in the local switch is less than the sum of egress HSDPA VCCs, thus saving bandwidth.

Correspondingly, the local switch needs to perform an UBR-CBR conversion in the uplink VCC. The main issues in the local switch section are the VCC configuration in the RNC and the conversion of HSDPA VCC in the ATM switch. The Figure The CBR-UBR conversion of HSDPA VCC shows where the CBR-UBR conversion is needed. The con-version for HSDPA VCCs is needed for both uplink and downlink directions.

RNCBTS RNC

BTSSGSN

MSC

BTS

RNC BTS BTS BTS

BTSBTS BTS BTS

BTSBTS

BTSBTS

BTS BTS

BTS

BTS

BTS

BTS

BTS

BTS

= Potential Hub Points

Iur

Iu-cs

Iu-ps

Iub

Iur

DN0934844Issue 01

67


Id:0900d805805e5446

Figure 18 CBR-UBR conversion of HSDPA VCC

It should be noted that statistical multiplexing makes it possible to lose traffic in the trans-mission network during congestion, because the RNC may send more data than the network can handle. The best way to see the amount of lost data is in ATM switches in the network. The ATM switches need to have counters for, for example, lost cells due to congestion. With this PM information, the amount of overbooking can be adjusted. The RNC does not know what happens in the transmission network, but if data is lost there, it always causes a RLC retransmission, which can be an indication of a problem in the transmission network. The RLC PM data in the RNC cannot separate if the RLC is retransmitted due to poor radio conditions or lost cells in the transmission network. The amount of overbooking is the operator’s responsibility and cannot be affected by the RNC.

Route Selection differs also from the current shared VCC solution in the way that there is no need to perform shared HSDPA AAL2 allocation in the VCC to ensure the band-width for HSDPA traffic. The idea of shared HSDPA AAL2 allocation is to reserve some of the Iub capacity for HSDPA downlink traffic only to guarantee bandwidth, and thus QoS. In Route Selection, the capacity is ensured with its own CBR VCC.

One drawback of Route Selection is that it increases the need for AAL2 connectivity in the RNC if the dedicated VCCs are overbooked In some cases, the connectivity may become an issue if the RNC is limited in connectivity.

It is highly recommended to use AXU-B or AXU-C instead of AXU-A, because AXU-B and AXU-C have an AAL2 multiplexing functionality. With AAL2 multiplexing, there is less to configure in the RNC and AXCs, and also, there are bandwidth savings due to a less fragmented bandwidth. The Figures The AXC-A configuration with three HSDPA-capable WAM units and The AXU-B or AXU-C configuration with three HSDPA-capable WAM units depict the issue.

Hub Switch Local SwitchNodeB

NodeB

RNC

HSDPACBR VCCs

CBR

UBR

68 DN0934844Issue 01


Id:0900d805805e5446

Figure 19 Example of AXC-A configuration with three HSDPA-capable WAM units

Figure 20 Example of AXU-B or AXU-C configuration with three HSDPA-capable WAM units

There is additional reason to use AXU-B or AXU-C over AXU-A with Route Selection. If there is a failure in HSDPA capable WSP, the HSDPA functionality transfers to a new WSP.

If the new WSP is under different WAM the transport has to be preconfigured, that is, there has to be already a HSDPA VCC for continuation of the HSDPA service. If a HSDPA VCC cannot be dedicated for backup for all WAMs offering HSDPA it is recom-mended that all the HSDPA capable WSPs are configured under one WAM if the Route Selection is used with AXU-A unit.

AXC-ABT RNC

VPC

DCH

HSDPA

AAL2 Sig

WAMSector2

DCH

HSDPA

AAL2 Sig

WAMSector

DCH

HSDPA

AAL2 Sig

WAMSector

AXC-B

DCH

HSDPA

AAL2 Sig

BT RNC

AAL2MUX

VPC

WAMSector2

WAMSector

WAMSector

DN0934844Issue 01

69


Id:0900d805805e5446

Enhanced modeIn the enhanced mode there are dedicated VCC(s) and shared VCC(s) in the same route, that is, DCH VCC + SHARED VCC. The DCH traffic is primarily allocated in DCH VCC but in case of congestion (lack of bandwidth or lack of CIDs), SHARED VCC is used for DCH traffic. In SHARED VCC the DCH traffic has priority over HSDPA traffic.

One benefit of the enhanced mode is that if the DCH VCC is congested, the call is admitted instead of being rejected. Also, if DCH connection is about to be upgraded and there is not enough bandwidth in DCH VCC, the AAL2 connection is moved to SHARD VCC for the upgrade to succeed.

The drawback is that if the enhanced mode is used in same way as the plain mode, the CBR-UBR conversions in intermediate network endanger the QoS of DCH traffic in case of congestion.

2.12.1.1 Operator benefitsThe Route Selection feature with the use of ATM hub points allows the use of statistical multiplexing for HSDPA. As a result Iub capacity is saved in the intermediate ATM network between the BTS and RNC. In addition, using AXC-B or AXC-C instead of AXC-A increases savings.

2.12.1.2 ComplianceRoute Selection is 3GPP compliant.


System requirementsProper network topology is required, that is, there must be ‘hub points’ for getting the benefits of statistical multiplexing.

The third-party ATM switches need to be able to perform CBR-UBR and UBR-CBR con-versions and VC switching in the ATM network. In addition, the third-party switches need to be able to produce counters for dimensioning and trouble management purposes.


• RAS release: RAS05.1 • RNC release: RN2.2 • BTS release (Ultra): WBTS3.1 • Flexi BTS release WBTS3.2 • AXC: 2.7 • OSS: 4.1

Hardware requirementsNo hardware requirements.

Operator requirementsWhen the VCCs are created, the AAL2 UP Usage -parameter needs to be set. If the parameter valaue is set as HSDPA, the VCC is for HSDPA traffic only. If the parameter

70 DN0934844Issue 01


Id:0900d805805e5446

value is DCH, only DCH traffic is carried in it. If the value of ‘AAL2 UP Usage’ is SHARED, both HSDPA and DCH are carried in the VCC.

For a BTS, there has to be at least one VCC for DCH traffic. The VCC can be either DCH or SHARED type, because a shared VCC is also for DCH traffic. The HSDPA VCC is not mandatory.

End-user requirementsThis feature has no end-user requirements

2.12.1.4 Interaction with other features • Iub transport • BTS AAL2 Multiplexing • Dynamic HSDPA Transport Scheduling

2.12.1.5 Limitations and restrictionsWhen additional CBR VCCs are configured in the RNC, additional AAL2 connectivity is needed. A BTS needs to support two user plane VCCs in a WAM unit.


2.12.2.1 Using Route SelectionRoute Selection is an optional feature and thus the license must be purchased

To use Route Selection, some VCCs need to be configured to be HSDPA VCCs which are then used for HSDPA traffic only. If a VCC is configured to be shared, it is used for both DCH and HSDPA traffic. More information on the VCC configuring can be found in the RNW Administration document.

2.12.2.2 Activating Route SelectionRoute Selection is an optional feature and thus the license must be purchased.

In the RNC, the Iub VCC type need to be set when configured to HSDPA, DCH, or SHARED. The HSDPA tag means that the VCC is for HSDPA traffic only. Correspond-ingly, the DCH tag marks VCC for DCH traffic only. SHARED means that the VCC is for both HSDPA and DCH traffic.

In the AXC, the HSDPA VCC must be configured to a UBR VCC instead of a CBR VCC as in the RNC if the plain mode is used. In the AXC, the prioritising of the HSDPA UBR VCC is done by setting a higher Peak Cell Rate (PCR) parameter value to it than to other UBR VCCs, even though the PCR is not enforced. For more information on configuring the AXC, see Planning the AXC and Comissioning and Integrating the AXC in UltraSite WCDMA BTS documentation.

In the Flexi BTS, the HSDPA VCC needs to be UBR as in the AXC in plain mode. The priority for HSDPA VCC is given also by the PCR parameter. The higher the PCR value, the higher the VCC priority. In the Flexi BTS, the PCR is enforced. More information on configuring the Flexi BTS can be found in Flexi BTS product documentation.

DN0934844Issue 01

71


Id:0900d805805e5446

Selecting the ATM service category in enhanced mode is not straightforward. If the DCH traffic is admitted to SHARED VCC on regular basis, it is recommended to use CBR in last mile also.

2.12.2.3 Verifying Route SelectionWhen the system is configured, a test call can be made and the selected VCC can be verified in the PM data.

2.12.2.4 Deactivating Route SelectionThere is no single parameter which enables the feature in the RNC. The VCCs need to be configured in the RNC as SHARED, and the corresponding

2.12.2.5 Feature managementNo new Route Selection-related alarms, PM counters, or additional parameters.

2.12.2.6 CapacityThe need for AAL2 connectivity might increase, depending on the PCRs set to the VCCs.

2.12.3 Network management

PlanThe feature increases the number of VCCs and the amount of AAL2 connectivity needed, which needs to be taken into account when planning the RNC configuration. In addition, the amount of overbooking in the transport network needs to be considered carefully to get maximal benefits with minimal traffic loss.

IntegrateA BTS needs to support two user plane VCCs for a WAM unit.


72 DN0934844Issue 01


Id:0900d805805e544a

2.13 RAN1062: IMA (Flexi WCDMA BTS)

2.13.1 Feature descriptionIMA (Inverse Multiplexing for ATM) is supported for E1, T1, JT1 and Flexbus interfaces of Flexi WCDMA BTS

DN0934844Issue 01

73


Id:0900d805805e544d

2.14 RAN1086: AXC ATM interface oversubscription

2.14.1 Feature description Asynchronous Transfer Mode Cross Connection (AXC ATM) Interface Oversubscrip-tion provides the means to oversubscribe the physical bandwidth of an ATM interface in order to dimension the physical trunk transport capacity in Hub Node B / stand-alone AXC (S-AXC) , which has a smaller capacity than the aggregate of the transport capacity allocated to the Node Bs it is concentrating.

Figure 21 Network topology for AXC ATM interface oversubscription

Figure Network topology for AXC ATM interface oversubscription shows a typical network topology to take advantage of this feature: a Hub Node B’s AXC or a S-AXC aggregates the traffic from several Node Bs. Another Node B’s AXC or S-AXC in front of the Radio Network Controller (RNC) provides the original bandwidth allocations. Therefore RNC is not aware of the ATM interface oversubscription.

The AXC ATM Interface Oversubscription allows configuring the ATM bandwidth inde-pendent of the actual available physical bandwidth. Simply said, the physical bandwidth and the ATM interface bandwidth are controlled by two different network element func-tional layers:

• The physical layer function adapts the ATM traffic rate to the physical line rate. The physical layer inserts idle ATM cells if it does not receive any user ATM cells from the ATM layer.

• The ATM layer function performs Traffic management functionality e.g. Connection Admission Control (CAC) and performs the traffic scheduling among the ATM service categories and ATM connections.

A network element’s CAC usually reserves bandwidth for individual ATM connections to make sure that each ATM connection receives the required service quality.

ATM traffic scheduling regulates the ATM cell streams among different ATM connec-tions according to their ATM service categories and service requirements:

RadioNetwork

Controller

e.g. STM-1(155 Mbit/s)

AXC ATMinterface

bandwidthe.g. 3 Mbit/s

physical bandwidthe.g. E1/T1 (e.g. 2

Mbit/s)

S-AXCor Node B

S-AXCor Node B

physicalbandwidthe.g. E1/T1

(e.g. 2 Mbit/s)

Node B

Node B

Node B

VPC e.g.1 Mbit/s

74 DN0934844Issue 01


Id:0900d805805e544d

• If the actual ATM traffic stream associated with a particular ATM CBR connection is greater than the reserved bandwidth, the traffic scheduler buffers the ATM cells (and finally discards the ATM cells as soon as the buffer is occupied). This regulation is necessary to guarantee the quality of the service for the other CBR connections. If the actual ATM cell stream associated with a particular ATM CBR connection is smaller than the bandwidth that is not used, it cannot be used for the traffic of another CBR connection.

• ATM cells of Unspecified Bit Rate (UBR) connections are only sent if no ATM cell of a CBR connection is eligible for transfer.

A canonical ATM traffic management function aligns its traffic scheduling with the avail-able physical bandwidth in order to grant always the required quality of service espe-cially under high traffic load conditions. Implicitly, the canonical traffic management rejects to establish Constant Bit Rate (CBR) connections if the sum of the Peak Cell Rate (PCRs) is greater than the physical transmission bandwidth. If the actual traffic in a CBR connection is smaller than the reserved bandwidth, it cannot be used by the traffic of another CBR connection.

AXC ATM interface oversubscription allows you to apply the ATM traffic management functions with a less strict bandwidth reservation policy for the individual ATM connec-tions. It introduces an additional configuration for the bandwidth that the ATM traffic management takes into account: the ATM interface bandwidth.

The ATM interface bandwidth is set to a value greater than the physical bandwidth to oversubscribe.

All the AXC ATM traffic management functions will properly work until the actual traffic volume exceeds the physical bandwidth. This is typically the case because not all the Node Bs will generate their maximum traffic volume at the same time.

However, if the ATM interface oversubscription is in use and the actual ATM traffic exceeds the physical bandwidth:

1. AXC starts to buffer and finally discards ATM cells.2. First UBR connections are affected, but also CBR connections may suffer because

the reserved bandwidth is not guaranteed.3. AXC will then randomly discard ATM cells from the CBR connection.4. Therefore AXC provides counters (called utilizationZone%) to monitor the actual

traffic load on the physical interface. • The counters called utilizationZone%xx expresses how much time of fifteen-

minutes period the physical bandwidth is used (see Maintaining the AXC for more detailed information).

2.14.1.1 Operator benefitsWhen using NodeB or S-AXCs to aggregate traffic from Node Bs, operators allocate dedicated bandwidth for each Node B through the transport network. In practice, the aggregate bandwidth reservation is greater than the actual traffic volumes, because not all the Node Bs generate maximum traffic at the same time.

AXC ATM interface oversubscription provides the means to reduce the reserved trunk capacity and with it to reduce Operating Expenditure (OPEX) that is, the costs for leased line services.

DN0934844Issue 01

75


Id:0900d805805e544d

The AXC ATM interface oversubscription feature supports the operator's intention to smoothly oversubscribe the physical link capacity by reducing the safety margin provided by ATM Quality of Service means and by taking the risk of ATM cell discards.

2.14.1.2 ComplianceAXC ATM interface oversubscription is transparent to the Iub functionality and therefore, it is 3GPP compliant.


System requirementsThe recommended network topology requires either a Node B AXC or an S-AXC as a hub point to aggregate traffic from several Node Bs, and another S-AXC in front of the RNC. You can also use other third-party ATM equipment that offers similar oversub-scription features used at RNC site.


• AXC: 2.7 • OSS: 4.1 CD Set 1

Hardware requirementsThe feature does not have hardware requirements. It is applicable to all AXU variants.

Operator requirementsOperator shall not aggressively overbook the physical bandwidth to reduce the risk of traffic drops.

The operator shall monitor the ATM interface utilization with the provided ATM traffic load counters to proactively react on bandwidth bottlenecks.


2.14.1.4 Interaction with other featuresRoute Selection feature will complement the ATM interface oversubscription, because operators have then the option to oversubscribe dedicated traffic, for example, Rel99 real-time or non real-time traffic on a different interface than the HSDPA traffic.

2.14.1.5 Limitations and restrictionsThe maximum value for the ATM interface bandwidth is 3532970 cps (equal to 10*STM-1 bandwidth). The maximum Peak Cell Rate value for an ATM connection is 1412828 cps (equal to 4*STM-1 bandwidth).

76 DN0934844Issue 01


Id:0900d805805e544d


2.14.2.1 Using AXC ATM interface oversubscriptionAXC ATM interface overbooking is an optional feature and thus the corresponding license must be purchased.

2.14.2.2 Activating AXC ATM interface oversubscriptionIf you have obtained the required license, the AXC allows you to configure the ATM interface bandwidth above the available physical transmission bandwidth.

For more information on configuring the AXC, see Planning the AXC and Commission-ing and Integrating the AXC in UltraSite WCDMA BTS documentation.

The traffic monitoring counters are available without the AXC ATM interface oversub-scription license.

2.14.2.3 Verifying AXC ATM interface oversubscriptionWhen you have configured the system, you can make a test call to monitor the traffic volume.

2.14.2.4 Deactivating AXC ATM interface oversubscriptionThere is no particular parameter to disable AXC ATM interface oversubscription. The ATM interface bandwidth is set to the available physical transmission bandwidth.

2.14.2.5 Feature managementAXC introduces new counters to monitor the actual ATM traffic load of the ATM inter-face. The operator monitors the traffic load to pro-actively react on bandwidth bottle-necks.

2.14.2.6 CapacityAXC ATM interface oversubscription does not have any special capacity requirements.


PlanAXC ATM interface overbooking allows to configure the ATM interface bandwidth inde-pendently of the physical transmission bandwidth. The overbooking ratio of ATM inter-face bandwidth to physical transmission bandwidth needs carefully planning.

IntegrateNo specific rules apply.

Trouble managementIf the ATM interface utilization counters show a steady high traffic load then the physical interface bandwidth needs to be increased or the network topology has to be re-planned.

DN0934844Issue 01

77


Id:0900d805805e544d

A steady high traffic load may cause ATM cells discard due to ATM buffer overflow. Accordingly, the end-to-end quality of service may suffer at radio layer.

78 DN0934844Issue 01


Id:0900d805806063f4

Operability features

3 Operability features

3.1 RAS05.1 operability features overview

* RAN1193: Plan based RNC ATM/IP Configuration has been documented as part of RAN96: Automated RNS Split.


RAN893: Alarm Architecture for Flexi WCDMA BTS RAS05.1

RAN369: Automated IP Address Configuration for BTS RAS05.1

RAN96: Automated RNS Split RAS05.1

RAN882: AXC ATM Layer Configuration Management for BTS

RAS05.1

RAN1290: AXC Local Account Mass Change RAS05.1 ED

RAN1091: BTS SW Management with RNC/NEMU Mediation

RAS05.1

RAN557: Combined HW Management for Flexi WCDMA BTS and its Transport Module

RAS05.1

RAN817: Combined SW Management for Flexi WCDMA BTS and its Transport Module

RAS05.1

RAN1040: Data Backup for AXC RAS05.1

RAN1167: Domain Specific Access Class Restriction RAS05.1

RAN619: Flexible Connection of VPCs for WBTS Object in RNC

RAS05.1 ED

RAN812: Local User Authentication for BTS RAS05.1

RAN1302: Non-Performing Cell Recovery RAS05.1 ED

RAN1193: Plan based RNC ATM/IP Configuration * RAS05.1 ED

RAN801: Radio Network Access Regulation Function RAS05.1

RAN375: Read Only -Access for RNC & AXC Element Managers

RAS05.1

RAN615: Remote User Event Log Management for AXC

RAS05.1

RAN183: Remote User Event Log Management for RNC

RAS05.1

RAN617: Remote User Information Management for AXC

RAS05.1

RAN181: Remote User Information Management for RNC

RAS05.1

RAN1181: RNC NEMU Firewall RAS05.1

RAN1152: WCEL Lock and Unlock During RNW Plan Activation

RAS05.1

RAN1453: Iu Link Break Protection RAS05.1

Table 4 RAS05.1 operability features overview

DN0934844Issue 01

79

WCDMA RAN, rel. RAS05.1, feature descriptions Operability features

Id:0900d805806063f4


For parameters, counters and alarms per feature, see the following chapters in Interde-pendencies of Operability Features:

• RAS05.1 parameters, counters and alarms • RAN1.5, RAN04 and RAS05 parameters, counters and alarms


For information on software requirements, see Feature compatibility in WCDMA RAN Compatibility.

For information on RAS05.1 features not described in this document (RAN1193: Plan based RNC ATM/IP Configuration, and RAN1181: RNC NEMU Firewall), see Features Under Development (FUD) and Functional Area Descriptions in WCDMA RNC Product Documentation.

For information on RAN1.5, RAN04 and RAS05 features, see RAN04 and RAS05 Oper-ability Features.

80 DN0934844Issue 01


Id:0900d8058060630f

3.2 RAN893: Alarm Architecture for Flexi WCDMA BTS

3.2.1 Feature descriptionThis feature introduces a BTS-integrated FM solution for the Flexi Wideband Code Division Multiple Access Base Transceiver Station (WCDMA BTS) transport module.

In the Ultra BTS family, the ATM Cross Connect (AXC) transport unit is handled as a separate network element. This feature introduces a new kind of operation and mainte-nance architecture for the Next Generation WCDMA BTS.

The transport module alarms are collected to the Flexi WCDMA BTS alarm system and reported to the management system as BTS alarms. The transport module alarms are also included in the BTS alarm upload. The transport module alarms are visible in the mediating Radio Network Controller (RNC) alarm system as BTS alarms.

Operator benefitsThe benefit compared to the old architecture used with the WCDMA Ultra BTS is that the transport module alarms are now directly mapped to the related BTS object already in the BTS alarms system. This makes the fault management easier because the infor-mation of the affected radio resource on WCDMA Base Station (WBTS) object level is included in the alarm. The new architecture makes it also possible to observe the trans-port module related alarms with the User interface (UI) of the RNC alarm system.

The architecture is simplified and with further development in later releases it enables the possibility to remove the other of the two currently used management interfaces (NWI3) needed in the BTS. This will make the BTS integration simpler and faster and allows more efficient usage of the NetAct computing capacity.

ComplianceNo references.

Resource requirementsSystem Requirements

The functionality must be available in the RNC before the Next Generation BTSs are integrated.

Software Requirements

• RNC: RN2.2 • BTS: WBTS3.2

Hardware Requirements

Standard HW for the Next Generation WCDMA BTS.

Operator Requirements

No special requirements. The system uses the old alarm architecture for the Ultra BTS transmission alarms, and the Next Generation BTS transmission alarms are automati-cally handled as BTS alarms.

End-user Requirements

This feature sets no additional end-user requirements.

Interaction with other featuresNo interaction with other features.

DN0934844Issue 01

81


Id:0900d8058060630f

Limitations and restrictionsNo special limitations or restrictions.


Using Alarm architecture for Flexi WCDMA BTSObserving the BTS site originated transmission alarms:

1. The Next Generation WCDMA BTS Transport Module forwards its alarms to the Base Transceiver Station Operation and Maintenance (BTS O&M). • The alarms can be observed with the BTS element manager.

2. The BTS forwards the alarms to the RNC with the BTS O&M Interface among the BTS originated alarms. • The alarms can be observed with the RNC element manager.

3. The RNC forwards the alarms to NetAct with the NWI3 interface among the RNC originated alarms. • The alarms can be observed with the NetAct alarm applications.

Activating Alarm architecture for Flexi WCDMA BTSNo special action is needed for taking the feature in use. The new architecture is used for all Next Generation WCDMA BTSs connected to the RNC.

Possible correlation rules in the NetAct should be checked for creating the needed new rules for the alarms targeted to the WBTS object instead of AXC as with Ultra BTS trans-mission alarms.

Verifying Alarm architecture for Flexi WCDMA BTSA transmission alarm is generated and cancelled to the Next Generation WCDMA BTS. The results are observed from BTS and RNC Element Managers and NetAct alarm applications.

Deactivating Alarm architecture for Flexi WCDMA BTSNo special action is needed for taking the feature out of use. The new architecture is used for all Next Generation WCDMA BTSs connected to the RNC.

Feature managementNo special management actions are needed for this feature.

82 DN0934844Issue 01


Id:0900d8058060630f

Architecture

Figure 22 Alarm Architecture for Flexi WCDMA BTS, architecture

CapacityNo capacity requirements.


PlanNo effects to the network planning.

IntegrateNo effects to the WCDMA BTS integration. Although the direct NWI3 interface in the BTS to NetAct is not used for the transport module alarms as with Ultra BTS AXC, in RAN05.1 the NWI3 interface in the Next generation WCDMA BTS is still needed for other management purposes.

Trouble managementNo effects to the trouble management as such, although the Next generation WCDMA BTS transport module alarms are now available in the RNC alarm system as well, which is not the case with Ultra BTS and AXC.

Next Generation WCDMA BTS

Alarm systemTransportmodule

UI

RNC

Alarm systemUI

BTS O&M Managementinterface

NetAct

Alarm systemUI

NWI3 Managementinterface

DN0934844Issue 01

83


Id:0900d80580606322

3.3 RAN369: Automated IP Address Configuration for BTS

3.3.1 Feature descriptionThis feature introduces automatic configuration of Base Transceiver Station (BTS) IP address allowing more automated IP address allocation for the BTS. After BTS reset, BTS fetches its own IP address and Radio Network Controller (RNC) IP address auto-matically from ATM Cross Connect (AXC) (these values have to be configured to AXC by user before reset). RNC IP address is needed in BTS for Operation and Maintenance (O&M) connection between the BTS and the RNC.

Operator benefitsThe IP layer configuration becomes simpler, when IP addresses of BTS site are config-ured only to AXC.

ComplianceNo impact.


No impact.


• AXC C2.7 • WBTS3.2


This feature sets no special hardware requirements.


IP address of BTS has to be configured to AXC instead of BTS.



Interaction with other featuresAutomated IP address configuration for BTS feature is required in the Automated RNS split feature.

The feature is implemented together with AXC ATM layer configuration management for BTS feature.

The feature configures IP address parameters for DCN.

Limitations and restrictionsNo impact.


Using Automated IP address configuration for BTSThe operator can set the BTS IP layer configuration parameters by modifying the AXC configuration either with the help of NetAct radio access Configurator applications, or AXC Element Manager.

84 DN0934844Issue 01


Id:0900d80580606322

Activating Automated IP address configuration for BTSNo special action is needed for taking the feature into use.

Verifying Automated IP address configuration for BTSAfter the AXC configuration file activation, the operator can launch the Element Manager of each BTS connected the AXCs to check that the new values of Asynchronous Transfer Mode (ATM) and IP layer parameters are adopted by the BTS.

Deactivating Automated IP address configuration for BTSNo special action is needed for taking the feature out of use.

Feature managementThere are no new parameters, alarms or counters related to this feature. This feature manages IP layer parameters related to DCN.

ArchitectureThis feature introduces a new internal management interface between the AXC and the BTS.

CapacityNo impact


PlanNo impact.

IntegrateThere is no BTS specific IP layer configuration for WAMs any more. BTS IP layer con-figuration is included to the AXC configuration file.

Trouble managementNo effects on the trouble management.

DN0934844Issue 01

85


Id:0900d80580606333

3.4 RAN96: Automated RNS Split

3.4.1 Feature descriptionBTS rehosting is an operation where a BTS is moved from under control of the current Radio Network Controller (RNC) to the control of another RNC. A similar procedure is used when a BTS is moved from under one Asynchronous Transfer Mode (ATM) inter-face to another under the same RNC . Typically BTS sites are rehosted when there is a need for more capacity in the network and therefore a new RNC is integrated to the network. It is recommended to keep all the BTS sites situated at the same area under the same RNC. To achieve this a number of already existing sites are moved from under control of the current RNC (source RNC) to under the control of the new (target) RNC. This operation is called an RNS split.

The RNS split operation requires reconfiguration of the radio network parameters and the ATM layer and IP network configuration in several network elements in a way that the network element downtime is minimised and the DCN connection for the Operation and Maintenance (O&M) traffic is not lost to any network element for which the configu-ration action is not completed.

In the automated RNS split feature, the configuration upload, download and activation operations can be triggered from the new NetAct RNS split application. Configuration data is transferred from the NetAct to the network element with the NWI3 in XML format. The operator can also schedule configuration upload, download and activation opera-tions.

Automated RNS split requires the following steps from the operator:

1. Selecting the re-hosted network elements2. Planning the new configuration and storing it in the NetAct databases3. Using the NetAct BTS Rehosting tool for

• planning the re-hosting procedure (activation schedule for configuration files) • generating and distributing the configuration files to relevant network elements • activating the downloaded configuration files in the network elements according

to the pre-planned activation schedule.4. Testing and checking the changed configuration. The old configuration (for example,

unnecessary ATM links) is removed and the new configuration is taken into use.

The base station ATM layer and IP network configuration are part of the ATM Cross Connect (AXC) configuration file. The AXC configuration changes can be implemented by modifying the AXC configuration file and by activating it. The changes required for the BTS configuration (identifiers of the BTS and the controlling RNC, BTS ATM layer configuration and IP network configuration including BTS and RNC IP addresses) are included into the AXC configuration file and transferred to the BTS during the AXC con-figuration file activation. RNC configuration files modified in the RNS split operation are RNW plan, ATM plan and IP plan.

Operator benefitsThe benefit gained by using this feature is that there is less interaction required from the operator as compared with the current system. The execution of the RNS split operation can be planned in advance and the Base Transceiver Station (BTS) outage due to the operation is decreased. In addition, this feature minimises the risk of human error in

86 DN0934844Issue 01


Id:0900d80580606333

operations, where simultaneous configuration changes are needed in several network elements.

ComplianceNo impact.


New NetAct application for RNS split planning, scheduling and execution.


• RNC: RN2.2 • NetAct: OSS4.1 • AXC: C2.7 • WBTS3.2




The operator has to define the BTS sites to be rehosted and the new parameter values to be used in the rehosted network elements using the new NetAct BTS Rehosting tool.

Operator has to configure the BTS related ATM parameters as well as BTS IP address, BTS id, BTS name and RNC id for BTS, to the AXC configuration file.



Interaction with other featuresAutomated RNS split feature requires the implementation of the following features:

• AXC ATM layer configuration management for BTS; • Automated IP address configuration for BTS.

Limitations and restrictionsThe target RNC has to exist under control of the same NetAct as the source RNC.


Using Automated RNS splitFeature can be used by activating the NetAct RNS split application, and by using the application for the RNS split planning and uploading, downloading and activation of the AXC and RNC configuration files.

Activating Automated RNS splitThe feature is optional. To activate the feature, the separate NetAct '3G rehosting' and 'ATM/IP parameter management for BTS' licences have to be purchased.

Verification

To verify that the feature is active, upload, download and activate the AXC and RNC configuration with the tool.

DN0934844Issue 01

87


Id:0900d80580606333

Verifying Automated RNS splitThe user can upload, download and activate the AXC and RNC configuration with the tool.

Deactivating Automated RNS splitThe feature can be deactivated by deactivating the related licences.

Feature managementThere are no new parameters, alarms or counters related to this feature.

ArchitectureThe following figures present the network architecture before and after BTS rehosting.

Figure 23 Network before the BTS rehosting operation

BTS1 & AXC1 BTS2 & AXC2 BTS3 & AXC3

RNC New RNW configurationRNC New ATM configuration

Source RNC

BTS4 & AXC4 BTS5 & AXC5

AXC New ATMconfiguration

BTS6 & AXC6 Target RNC

Transfer Point BTS

BTS7 & AXC7Removed connections

AXC New ATMconfiguration

88 DN0934844Issue 01


Id:0900d80580606333

Figure 24 Network after the BTS rehosting operation

CapacityNo impact.


PlanThere is a possibility to use the CSV (Comma Separated Values) interface, which is spe-cifically created for the BTS Site Rehosting application. If this is used, then the opera-tor's own planning & data warehousing tools (if any) can be modified so that they are able to produce "BTS Site Rehosting" application -compliant CSV files.

IntegrateNo impact.

Trouble managementThe results of the automated RNS split operations are saved to the NetAct operation log file. NetAct updates the operation log file on-line during the RNS split operation. The log file includes all the messages, which are received and send by NetAct and all the NetAct transactions during the RNS split operation. The operation log can be used as the primary source of information about the operation results for the user.

BTS1 & AXC1 BTS2 & AXC2 BTS3 & AXC3

New ATM configurationNew RNW configuration

Source RNC

BTS4 & AXC4

BTS New RNWconfiguration, new

IP configurationAXC New IPconfiguration

BTS5 & AXC5

BTS New RNWconfiguration, new

IP configurationAXC New IP

configuration, newATM configuration

BTS6 & AXC6

New ATMconfiguration

Target RNC

Transfer Point BTS

BTS7 & AXC7New connections

DN0934844Issue 01

89


Id:0900d80580606337

3.5 RAN882: AXC ATM Layer Configuration Management for BTS

3.5.1 Feature descriptionWith this feature the ATM Cross Connect (AXC) hides the Asynchronous Transfer Mode (ATM) layer configuration in the Wideband Application Manager (WAM) unit from the user. The AXC introduces the new or changed configurations to the connected WAM units via an internal management interface.

From the operator point view this means that no separate ATM level configuration is needed for the BTS WAMs. The AXC takes care of all ATM layer related O&M tasks in the BTS, including the ATM Operations, Administrations and Maintenance (OAM) cell handling for the connections that are terminated in Node B.

Also the ATM transport configuration in Nokia NetAct and Tellabs ATM Manager is sim-plified as all Node B related configuration is done now in one point.

Operator benefitsThe ATM layer configuration becomes simpler when the amount of the RAN network entities containing ATM layer configuration is almost halved as compared with the previous situation. The possibility of configuration errors is also decreased in the same proportion. In addition, remote access to the BTS is possible without commissioning a BTS, only the AXC needs to be configured.

ComplianceThere is no need for BTS or AXC recommissioning when upgrading SW. BTS will use existing ATM settings until configuring tools are used to override existing parameters.


No impact.


• AXC: C2.7 • WBTS3.2




AXC configuration file contains all ATM parameters. BTS configuration file does not contain any ATM parameters.



Interaction with other featuresAXC ATM layer configuration management for BTS feature is required in the Automated RNS split feature.

Feature is implemented together with the Automated IP address configuration for BTS feature.

90 DN0934844Issue 01


Id:0900d80580606337

Limitations and restrictionsNo impact.


Using AXC ATM layer configuration management for BTSThe operator can set the BTS ATM layer configuration parameters by modifying the AXC configuration either with the help of NetAct Radio Access Configurator applications, the ATM Manager, or the AXC Element Manager.

Activating AXC ATM layer configuration management for BTSNo special action is needed for taking the feature into use.

Verifying AXC ATM layer configuration management for BTSVerifying AXC ATM layer configuration management for BTS After the AXC configura-tion file activation the user can launch the BTS Element Manager of each BTS con-nected the AXC and check that new ATM layer configuration parameter values are adopted by BTS.

Deactivating AXC ATM layer configuration management for BTSNo special action is needed for taking the feature out of use.

Feature managementThere are no new parameters or counters related to this feature.

If the AXC does not have all the configuration parameters required by BTS, BTS uses the existing parameter values from the Site Configuration File for all parameters. In this case, BTS also raises a local alarm, which is visible in the BTS Element Manager.

ArchitectureThis feature introduces a new internal management interface between the AXC and the BTS.

CapacityNo impact.


PlanNo impact.

IntegrateThere is no BTS specific ATM layer configuration for WAMs any more. BTS ATM layer configuration is included to the AXC configuration file.


DN0934844Issue 01

91


Id:0900d8058060633f

3.6 RAN1290: AXC Local Account Mass Change

3.6.1 Feature descriptionWith this feature it is possible to update AXC local user accounts remotely from NetAct using the NWI3 Mediator tool. It enables the operator to mass update AXC local user account.

Operator benefitsUpdating the local accounts in network elements is a time consuming operation, which needs to be done frequently. Mass updating functionality helps to keep network element local accounts up to date.

Security aspect is remarkable; knowledge about the old account might have spread widely.

ComplianceThis feature has no references to standards.


This functionality must be available at the same time with RUIM.


• NetAct: OSS4.1 CD set 2 • AXC: C2.7




This feature sets no additional operator requirements.


This feature sets no special end-user requirements.

Interaction with other featuresSee System Requirements.

Limitations and restrictionsAfter the update the manual RAC CM upload is needed to keep the data consistent. Oth-erwise, the next RAC configuration download would reset the local account to its previous value.


Using AXC Local Account Mass ChangeNetAct user creates a list about those AXC network elements whose local user accounts will be updated together with new user account credentials information. User executes the update command through command line interface and account updating happens automatically to all AXC network elements mentioned in the list.

92 DN0934844Issue 01


Id:0900d8058060633f

Activating AXC Local Account Mass ChangeNo special action is needed for taking the feature in use.

Verifying AXC Local Account Mass ChangeOld local user account in several AXC network elements is replaced with a new one. Login is made into AXC network elements using the new account.

Deactivating AXC Local Account Mass ChangeNo special action is needed for taking the feature out of use.

Feature ManagementNo special management actions are needed for this feature.

Architecture

Figure 25 AXC Local Account Mass Change architecture

CapacityUpdating happens parallel to all AXC network elements in the list, amount of AXC network elements at one time can be configured.


PlanNo effects.

Integrate No effects.

Trouble managementNo effects.

Local user accounts NetAct(RAS05.1 NWB Mediator tool)

(NWI3-usage of NWI3-LocalSec Fragment)

AXC

DN0934844Issue 01

93


Id:0900d80580606343

3.7 RAN1091: BTS SW Management with RNC/NEMU Media-tion

3.7.1 Feature descriptionThis feature enhances WCDMA BTS SW management operation by changing BTS SW distribution mechanism. In this new mechanism BTS SW package is first transferred from NetAct to RNC NEMU. BTS SW package downloading and activation from RNC NEMU is controlled by NetAct SW management. NetAct sends a SW management command for each involved RNC including a list of BTS’s which have been selected by the user. RNC O&M mediator starts processing the given BTS list and sends required messaging to each BTS via BTS management interface. When the BTS has finished the required SW management operation, it gives feedback to O&M mediator and O&M Mediator sends the BTS specific feedback to NetAct.

Operator benefitsIncreased SW downloading capacity for BTS software. Reduced DCN load between NetAct and RNC.




• NetAct: OSS4.1 • RNC: RN2.2







Interaction with other featuresNo interaction with other features

Limitations and restrictionsOne mass SW download or activation request shall contain one SW package and BTSes using the same package.

There can be maximum 100 SW download operations ongoing at the same time in one RNC. The user can order SW downloads for a bigger amount of BTSes, but the NetAct executes the download procedures to maximum 100 BTSs simultaneously in one RNC. The other SW download orders for the same RNC are put in a queue.

It is recommended to execute software download operations during the midnight (main-tenance window) when the existing traffic is lowest.

94 DN0934844Issue 01


Id:0900d80580606343


Using BTS SW Management with RNC/NEMU MediationNetAct user opens NetAct SW Manager application and selects the BTSs and the oper-ation (download, upload, activation or download and activation) to be executed. Status of the operation is shown to the user in the UI. Status is shown separately of each selected BTS.

Activating BTS SW Management with RNC/NEMU Mediation No special action is needed for taking the feature in use.

Verifying BTS SW Management with RNC/NEMU Mediation User can download and activate new BTS SW for a selected group of BTSes or upload current BTS SW of the selected group of BTSes to the NetAct from the NetAct SW Manager application.

Deactivating BTS SW Management with RNC/NEMU MediationNo special action is needed for taking the feature out of use.

Feature ManagementNo special management actions are needed for this feature.

Architecture

Figure 26 BTS SW Management with RNC/NEMU Mediation architecture

CapacityThis feature has no special capacity effects.

NetworkManagementInterface

BTSmanagementinterface

UI

AdministratorNetAct

BTS BTS BTS BTS

SWmanager

SWmanager

SWmanager

SWmanager

RNC

O&Mmediator

SoftwareManager

DN0934844Issue 01

95


Id:0900d80580606347

3.8 RAN557: Combined HW Management for Flexi WCDMA BTS and its Transport Module

3.8.1 Feature descriptionIn the current implementation, the Base Transceiver Station (BTS) hardware information is uploaded to NetAct HW inventory application, but the HW information of the Flexi Transport Module has not been included in these data. This feature integrates the Flexi Transport Module HW information to the Flexi WCDMA Base Station (WCDMA BTS) HW inventory data.

Operator benefitsThe integration of the Flexi Transport Module (FTM) into the Flexi BTS HW information improves the possibility to track the HW inventory of the network.


Using Combined HW Management for Flexi WCDMA BTS and its Transport ModuleThe Flexi Transport Module (FTM) HW configuration information is stored in the Flexi WCDMA Base Station (WBTS) as part of the BTS HW inventory. The FTM HW informa-tion is reported to NetAct HW inventory with the same mechanism as it is used for other Flex iBTS HW.

Although this feature requires no licence as such, the HW inventory application in the NetAct is an optional feature.

Activating Combined HW Management for Flexi WCDMA BTS and its Transport ModuleThis feature is part of the operating software, so no special action is needed for taking the feature into use.

Verifying Combined HW Management for Flexi WCDMA BTS and its Transport ModuleThe Flexi Transport Module HW information is observed from the NetAct HW inventory application after HW information upload.

96 DN0934844Issue 01


Id:0900d8058060634b

3.9 RAN817: Combined SW Management for Flexi WCDMA BTS and its Transport Module

3.9.1 Feature descriptionThe transport module SW management is handled by the Base Transceiver Station (BTS). The SW download and activation commands are targeted for the BTS, which handles the transport module SW management as a part of the BTS SW.

In Ultra BTS family, the transport unit ATM Cross Connect (AXC) is managed as a separate network element. This means that both units, BTS and AXC, must be upgraded separately.

This feature combines SW management functionality of the next generation BTS and its transport module (MRS). The transport module SW is included in the BTS SW package. The transport module is upgraded in the next generation BTS SW upgrade as an integral part of the BTS.

Operator benefitsThe new architecture solution simplifies the operator task of upgrading the RAN SW. In practice, the number of nodes to be updated in SW upgrade is only half as compared to the Ultra BTS architecture.

The architecture is simplified, and with further development in later releases, it enables the possibility to remove the other of the two, currently used management interfaces (NWI3) needed in the BTS. This makes the BTS integration simpler and faster and provides for a more efficient usage of the NetAct computing capacity.

ComplianceNo references.


Next Generation WCDMA BTS.


• WBTS3.2 • FTM: FTM2.0


Standard HW for the Next Generation WCDMA BTS.


No special requirements. The system uses the old SW management architecture for the Ultra BTS, and the Next Generation BTS transmission SW is automatically handled as part of the BTS SW build.


No end-user requirements.


DN0934844Issue 01

97


Id:0900d8058060634b

Limitations and restrictionsNo special limitations or restrictions.


Using Combined SW management for Flexi WCDMA BTS and its transport moduleThe BTS OM forwards the SW management actions to the BTS transport module, which acts according to the commands received from the BTS.

From the user point of view, no separate SW management actions are needed for the next generation WNDAM BTS transport module. The SW management actions are targeted to the BTS only.

From the user point of view, the SW download and activation procedure is identical to the one used with Ultra BTS. The only difference is that the additional SW management for transport unit in the ATM Cross Connect Unit (AXU) for the Ultra BTS is not needed.

Activating Combined SW management for Flexi WCDMA BTS and its transport moduleNo special action is needed for taking the feature in use.

Verifying Combined SW management for Flexi WCDMA BTS and its transport moduleThe feature can be verified by performing local and remote SW upgrade task for the BTS.

Deactivating Combined SW management for Flexi WCDMA BTS and its transport moduleNo special action is needed for taking the feature out of use.

Feature managementNo special management actions are needed for this feature.

ArchitectureThe following figure presents the architecture of Feature RAN817: Combined SW Man-agement for Flexi WCDMA BTS and its Transport Module.

98 DN0934844Issue 01


Id:0900d8058060634b

Figure 27 Combined SW Management for the Flexi WCDMA BTS and its Transport Module

CapacityNo capacity requirements.


PlanNo effects on the network planning.

IntegrateNo effects on the WCDMA BTS integration. Although the direct NWI3 interface in the BTS to NetAct is not used for the transport module SW management as with Ultra BTS AXC, in RAS05.1 the NWI3 interface in the Flexi WCDMA BTS is still needed for other management purposes.


Next Generation WCDMA BTS

SW ManagerTransportmodule

UI

RNC

BTS O&M Managementinterface

NetAct

AdministratorUI

NWI3 Managementinterface

mediator

DN0934844Issue 01

99


Id:0900d8058060634f

3.10 RAN1040: Data Backup for AXC

3.10.1 Feature descriptionWith this feature, the Nokia NetAct is able to manage the ATM Cross Connect (AXC) configuration data backup.

The feature is composed of three new network management actions:

• uploading the AXC configuration backup; • downloading the AXC configuration backup; • activating the downloaded AXC configuration backup.

The AXC backup upload operation can be scheduled in NetAct. This means that the user can define specific schedules when the NetAct starts the backup upload from the AXCs in the network. For example, the upload can be scheduled for night-time when the traffic is lighter.

The AXC configuration files are stored in the NetAct. The restoration of the data can be done either remotely from the NetAct, provided that the remote connection exists, or the configuration files can be downloaded to a laptop computer for local recommissioning.

Operator benefitsThe feature enables the operator to store the AXC configuration files to a remote loca-tion, which ensures fast recovery even in massive catastrophe situations.



NetAct offers user a possibility to upload, download activate AXC configuration from the NetAct.


• NetAct: OSS4.1 CD set 1 • AXC: C2.6, C2.7




This feature sets no special operator requirements.




Limitations and restrictionsThis feature has no special limitations or restrictions..

100 DN0934844Issue 01


Id:0900d8058060634f


Using Data Backup for AXCWith this feature the user can upload the data backup files from the AXCs with the NetAct Radio Access Configurator CM Operations Manager application. The old AXC configuration can be restored in the network element by downloading and activating the data backup file. This is done as a command line operation in the NetAct.

Activating Data Backup for AXCThe feature is optional. To activate the feature, the separate NetAct AXC_PARAMETER_MANAGEMENT licence has to be purchased.

Verifying Data Backup for AXCThe user can upload, download and activate AXC configuration backup data.

Deactivating Data Backup for AXCThe feature can be deactivated by removing the AXC_PARAMETER_MANAGEMENT licence in the NetAct.


ArchitectureThe following figure presents the architecture of the Data Backup for AXC feature.

Figure 28 Data Backup for AXC architecture

CapacityThe feature has no special effects on capacity.

NetAct

UI/Command

Line

RadioAccess

Configurator

NWI3Management

interface

AXC

AXCconfiguration

data

AXCconfigurationmanagement

DN0934844Issue 01

101


Id:0900d80580606353

3.11 RAN1167: Domain Specific Access Class Restriction

3.11.1 Feature descriptionThe Domain Specific Access Class Restriction (DSAC) is used for restricting the traffic based on the core network domain. As in the Radio Network Access Class Restriction feature, also in the DSAC the access classes are restricted in a sequential manner.

The mobile terminals with access classes 0-9 are included in the DSAC restriction. According to the user set parameters, the system changes the restriction sequentially so that each of the access classes 0-9 is restricted for a certain period of time.

Operator benefitsThe DSAC allows operator to restrict the user traffic in a more controlled way than with the Radio Network Access Regulation (RNAR) function. The DSAC allows the user to define what kind of traffic (Circuit Switched (CS) or Packet Switched (PS)) is restricted.

DSAC can be used, for example, in natural catastrophes, when the user traffic may exceed the network capacity, thus introducing performance problems. For example, the CS traffic can be restricted to a higher degree in order to leave the PS capacity available for the users to check the possible instructions from the authorities on the web.

ComplianceThis feature originates from CR 2526 for 3GPP TS 25.331 v6.4.0.


Legacy UEs do not support DSAC. DSAC is supported within 3GPP rel.6 mobile termi-nals.


• RNC: RN2.2 • NetAct: OSS4.1







Interaction with other featuresDSAC uses same RNW parameters with RNAR. It is likely that both RNAR and DSAC are needed in order to achieve the target traffic restriction level in network. When both DSAC and RNAR are used at the same time, older mobiles follow barring situation set with RNAR while the rel6 mobiles follow DSAC setting in cell. Population of 3GPP rel.6 UEs compared to older UEs should be considered when restriction levels for DSAC and RNAR are set.

102 DN0934844Issue 01


Id:0900d80580606353

Limitations and restrictionsDomain specific traffic restriction is applied to all cells which are connected to CN domain that has been selected to have DSAC active.


Using DSACPreconditions for using the feature

The Core Network (at least one CS core network), NetAct, Radio Network Controller (RNC), and at least one WCDMA Base Station (WBTS) must be up and running.

Actions to be taken by the user

The following actions have to be taken by the user:

1. NetAct RAC or RNC Radio Network (RNW) Object Browser is used to select the core domain (CS, PS, or both) to which the DSAC is applied.

2. Feature parameters are set to reach the required restriction level by using: • the RNW plan file, using NetAct with the parameters set to plan file.

The RNW plan file is downloaded and activated.or

• the RNC RNW Object Browser

The amount of access classes barred at one period is defined with parameter CellAccessRestriction.

Parameter DSAC is used to select which traffic is being restricted (CS, PS, Both).

Parameter RestrictionInterval is used to define the length of the barring period. When the period is over, the RNC selects next access classes to be barred.

Parameter ACBarredListSystem indicates which access classes are currently barred. The parameter value is updated in the RNC RNW Object Browser every time parameter value is changed.

Activating DSACThis feature is part of the application software. To activate the feature, a separate license has to be bought and the DSAC parameters need to be set.

Verifying DSACThere is always minor alarm set when the feature is functional. Same alarm is used when RNAR is activated. The alarm will be cancelled by the system when neither the DSAC or RNAR is no longer used in any cell. Test calls using different access classes in SIM have to be made.

Deactivating DSACFeature is disabled by setting either RNW parameter RestrictionInterval to 0 or RNW parameter DSAC to value ‘None’. Note that setting parameter RestrictionInterval to '0' deactivates RNAR as well.

Feature managementThere is the alarm Radio Network Access Regulation Function activated set when feature is active and cancelled when feature is disabled.

DN0934844Issue 01

103


Id:0900d80580606353

Following table illustrates the Radio Network (RNW) parameters used to configure this feature.

ArchitectureThis feature uses existing interfaces and requires no changes to the architecture.

Figure 29 Architecture of DSAC

The WBTS sends BCCH information using the interval defined with parameter RestrictionInterval. The BCCH information contains System Information Block 3, including new Information Element (IE) ‘Domain Specific Access Restriction Parame-ters’. The IE contains a list of barred access classes for both CS and PS domain. Before establishing the RRC connection, the UE traces whether its own access class is barred.

Parameter name Value range Default value

RNW object

Description

CellAccessRestriction 10...100, step 10

10 RNC Defines how large percentage of the Access Classes is barred at one time. This parameter is used also with the Radio Network Access Regulation Function feature.

RestrictionInterval 0, 20, 30, 40..1800, step 10

0 RNC Defines the duration of one barring period. This parameter is used also with the Radio Network Access Regulation Function feature.

DSAC None, CS, PS, Both

None RNC Defines if the DSAC is used in CS/PS domain. All CS/PS nodes are affected by this parameter.

ACBarredListSystem Special range, representation is 10 ‘bits’

Empty RNC This parameter is updated by RNC. It is not user configurable. When the Radio Network Access Regulation Function or DSAC is active, this parameter indicates which Access Classes are barred. The parameter value is updated by the RNC every time a new restriction period is started. The length of the restriction period is defined with parameter Restric-tionInterval. This parameter is used also with the Radio Network Access Regula-tion Function feature.

Table 5 Management parameters

RNC

WCDMA BTS

Network Management interface

BTS NBAP interfaceBCCH

informationUE

NetAct

RAC

CM SW

104 DN0934844Issue 01


Id:0900d80580606353

CapacityThe feature has no special effects on capacity.

DN0934844Issue 01

105


Id:0900d80580606356

3.12 RAN619: Flexible Connection of VPCs for WBTS Object in RNC

3.12.1 Feature descriptionCurrently, it is possible to have one ATM interface and Virtual Path (VP) related to each BTS in the RNC Connection Configuration (COCO logical object). The purpose of this feature is to introduce flexibility for the ATM layer configuration on the Iub interface, and also support the RAN1020 Route Selection feature.

With this feature it is possible to use the advantages of Route Selection also in networks where the Iub interface ATM layer cross-connections are done on a VP level, without heavy configuration change for Virtual Channel (VC) level ATM cross-connections at the Iub ATM transport network.

The feature allows connecting up to six ATM interfaces and VPs for a BTS at the RNC.

Operator benefitsWith this feature the operator is able to configure up to six ATM interfaces and VPs for the BTS-related COCO object.




• RNC: RN2.2 CD2.0 • OSS4.1 CD set







Interaction with other featuresRAN1020 Route Selection

This feature supports the utilisation of the Route Selection feature.

Limitations and restrictionsThe maximum number of related ATM interfaces and VPs per BTS in the RNC Connec-tion Configuration is increased from one to six.

106 DN0934844Issue 01


Id:0900d80580606356


Using Flexible Connection of VPCs for WBTS Object in RNCInstead of using the COCO object specific ATM interface and VP configuration for the WBTS in the RNC, the VPCs are defined for each link in the COCO object. For example, one user plane AAL2 connection can be related to one VPC while the other link uses another VPC.

The user may select whether to use one or several ATM interfaces and VPCs in the COCO object configuration. There is no need to change the old configuration for WBTSs where several ATM interface and VPs are not used.

Backwards compatibilityThe model of the COCO object (Connection Configuration) is changed for enabling the flexible connections. Since the COCO object can be defined with the RNC Object Browser, or with the Radio Access Configurator tools in NetAct, the RNC implements support also for the old model of the COCO object with one VPC. Therefore it is not man-datory to convert the existing configuration if this feature is not taken into use. Also the double object model support enables trialing of the flexible connections also where the matching version of the NetAct is not used without losing the RNW configuration back-wards compatibility.

Activating Flexible Connection of VPCs for WBTS Object in RNCThe feature is licensed. The license limits the amount of COCO objects in the RNC con-figuration where the use of the flexible connections is allowed.

To take the flexible connections into use, the configuration is changed so that the COCO object specific ATM interface and VP definition is replaced by link-specific ATM interface and VP definitions.

Verifying Flexible Connection of VPCs for WBTS Object in RNCTo verify the correct configuration, all connections in the new configuration must be verified – for example, with test calls using all user plane connections.

Deactivating Flexible Connection of VPCs for WBTS Object in RNCNo special deactivation action is required. Link-specific VPCs can be used also if only one VPC is required for the WBTS, but in this case each link in the COCO object points to the same VPC.

Feature ManagementThe parameters related to this feature are the parameters for the COCO object in the RNC.

Related COCO parameters:

• VPLTPList - VPLTP • COCOVPI Virtual Path Identifier • VPLTPATMIfId VPLTP ATM interface identifier

• CNBAPTP • CNBAPTPATMIfId C-NBAP ATM interface identifier • CNBAPVPI C-NBAP Virtual Path Identifier • CNBAPVCI C-NBAP Virtual Channel Identifier

• DNBAPTPList - DNBAPTP

DN0934844Issue 01

107


Id:0900d80580606356

• DNBAPATMIfId D-NBAP ATM interface identifier • DNBAPVPI D-NBAP Virtual Path Identifier • DNBAPVCI D-NBAP Virtual Channel Identifier

• AAL2SignLinkTPList - AAL2SignLinkTP • AAL2SignLinkATMIfId AAL2 signalling link ATM interface identifier • AAL2SignLinkVPI AAL2 signalling link Virtual Path Identifier • AAL2SignLinkVCI AAL2 signalling link Virtual Channel Identifier

• AAL2TPList - AAL2TP • AAL2SignLinkATMIfId AAL2 sign link reference ATM interface identifier • AAL2SignLinkVPI AAL2 sign link reference Virtual Path Identifier • AAL2SignLinkVCI AAL2 signalling link Virtual Channel Identifier • AAL2UPATMIfId AAL2 user plane ATM interface identifier • AAL2UPVPI AAL2 user plane Virtual Path Identifier • AAL2UPVCI AAL2 user plane Virtual Channel Identifier

For more information on the relevant parameters, see WCDMA RAN Parameter Diction-ary in WCDMA RNC Product Documentation.

ArchitectureThis feature makes it possible to configure up to six ATM interfaces and virtual paths (six separate ATM interface id /VPI pairs) to one COCO object in the RNC. This makes it possible to use more flexible ways in utilising the ATM interfaces and VPs for the BTS connections at the RNC The Iub ATM transport configurations and examples are repre-sented in the following figures.

Figure 30 Flexible Connection of VPCs for WBTS Object in RNC, architecture

Figure Basic Iub VCC configuration represents the basic example Iub ATM VCC config-uration with having one ATM interface and one VPC configured for the VCCs of the BTS.

Figure 31 Basic Iub VCC configuration

Figure Iub configuration with one ATM interface and two VPCs for one BTS connection represents the configuration example with one ATM interface and two VPCs configured

RNC WBTS

ConnectionConfiguration

VCC - signaling

VCC - signaling

VCC - user plane

Multiple VPC

VCC - user plane

VCC - user plane

Iub interface

RNCC-NBAP

D-NBAP

AAL2 SL

AAL2 VCC

AAL2 VCC

AAL2 VCC

BTS

108 DN0934844Issue 01


Id:0900d80580606356

for the BTS connections. In this case the AAL2 VCC reserved for the HSDPA traffic is configured to own VPC to utilise the VP level cross-connections at the ATM transport. This configuration requires that the HSDPA and Route Selection features are purchased in addition to the Flexible Connection of VPCs for WBTS Object in RNC feature.

Figure 32 Iub configuration with one ATM interface and two VPCs for one BTS con-nection

Figure Iub configuration with two ATM interface and three VPCs for one BTS connection depicts a configuration example with two separate ATM interfaces and three VPCs con-figured for the BTS connections. In this example the HSDPA and Route Selection features are also active along with the Flexible Connection of VPCs for WBTS Object in RNC feature.

Figure 33 Iub configuration with two ATM interface and three VPCs for one BTS con-nection

The Iub ATM transport configurations presented here are only examples of the possible configurations. The actual Iub ATM transport VPC and VCC configuration is imple-mented according to the operators’ own transport network planning.

CapacityThis feature has no special effects on capacity.

BTS

RNCC-NBAP

D-NBAP

AAL2 SL

AAL2 VCC, R99 DCH

AAL2 VCC, HSDPA

Network interface

Virtual path

AAL2 VCC, R99 DCH

BTS

RNCC-NBAP

D-NBAP

AAL2 SL

AAL2 VCC, R99 DCH

AAL2 VCC, HSDPA

Network interface

Virtual path

AAL2 VCC, R99 DCH

DN0934844Issue 01

109


Id:0900d80580606359

3.13 RAN812: Local User Authentication for BTS

3.13.1 Feature descriptionWith this feature, the Element Manager access to a Base Transceiver Station (BTS) is protected with a configurable password. The user authentication is done locally in the BTS. The user can change the local BTS user password and username with the BTS Element Manager.

Operator benefitsThis feature offers the possibility to manage the super-user account of the BTS. The advantage is the increased security in network management.

ComplianceThis feature is not tied with any specific standard.


This feature does not need any additional functionality outside BTS.


• BTS: WBTS3.2


No special hardware is needed.


Management of User Account needs administrative work for each BTS.


It is the end-user’s responsibility to remember the password.


Limitations and restrictionsOnly one user account exists, which is the super-user. If the authentication is not acti-vated during commissioning, login is possible to make without a password.


Using Local User Authentication for BTSUser will be asked standard style to input his/her username and password at login.

Activating Local User Authentication for BTSThe authentication can be activated in the commissioning phase. Later on the local administrative password maintenance is performed with Network Element Manager.

Verifying Local User Authentication for BTSIncorrect user ID/password causes login failure.

110 DN0934844Issue 01


Id:0900d80580606359

Deactivating Local User Authentication for BTSSuper-user account can be deactivated with the Element Manager.

Feature managementParameters

Architecture

Figure 34 Local User Authentication for BTS architecture

Interface

BTS and Element Manager communicate with each other through XML over HTTP on TCP/IP.

CapacityNo effect on system performance.

Parameters

Parameter name: Password length [password parameter]

Managed object: BTS

Description: Describes the length of the password.

Range: 8 – 14 characters

Parameter name: Account length [password parameter]

Managed object: BTS

Description Describes the length of the username.

Range/Default: 4 – 16 characters

Parameter name: Idle timeout [session parameter]

Managed object: BTS

Description Describes how long time the session can be in an idle state before session is closed automati-cally

Range/Default: 0 – 999 min / 30 min (0 = disabled)

Table 6 Parameters

AdminBTS localuser Db

Maintain locallywith BTS Manager

Allow-forbid session

Request entry

Local authentication

User BTS

DN0934844Issue 01

111


Id:0900d80580606359


PlanThis feature has no effect to the network planning.

IntegrateThis feature does not need any new integration methods.

Trouble managementThis feature has no effect on the trouble management.

112 DN0934844Issue 01


Id:0900d8058060635c

3.14 RAN1302: Non-Performing Cell Recovery

3.14.1 Feature descriptionWith this feature the RNC is able to trigger advanced cell recovery actions based on the errors in common channel or common measurement performance.

The RNC implements phased recovery-automate, where different level of recovery actions are performed. If the first recovery action fails to correct the fault, the next recovery action step is performed. The final action is to perform a BTS restart if other actions did not help.

The RNC discovers the failures in the common channel and common measurement ini-tialization. The initialization is retried several times until it succeeds. If the initialization fails, the RNC orders a BTS restart for recovery purpose.

The RNC discovers the missing common measurements. The re-initialization of common measurements is tried several times until it succeeds. If the initialization fails, the RNC orders a BTS restart for recovery purpose.

In order to avoid unnecessary BTS restarts, the RNC limits the use of BTS restart as a recovery action to two times per day per BTS.

Operator benefitsThe feature reduces the need of manual intervention in cases where a BTS restart could help in recovery. The need of manual work is smaller, and the lost service is recovered faster.




• RNC: RN2.2 CD2.0







Interaction with other featuresThis feature has no interaction with other features.

Limitations and restrictionsThis feature has no special limitations or restrictions.

DN0934844Issue 01

113


Id:0900d8058060635c


Using Non-Performing Cell RecoveryThe Non-performing Cell Recovery performs the recovery actions without user actions.

When the function has performed a BTS restart as the final attempt for recovery, an alarm is issued for informing the user about the cause of the restart.

Activating Non-Performing Cell RecoveryThe feature is standard operation software in RNC.

To activate the feature the PRFILE parameter RN22_FEATURE_OPT_ 009 is set as enabled by the MML command.

The parameter can have following values:

• 0: maximum two BTS restarts are allowed per day as a recovery action (default value).

• 1, 3-A: maximum x BTS restarts are allowed per day as recovery action. • F: Non-Performing Cell Recovery is disabled.

Default value is 0.

The feature can be activated with the following MML command:

ZWOC:2,1296, X;

(where X can have value: 0-A).

For more information about the parameter and activation, refer to WCDMA RNC Product Documentation for Administer – Software management – Interrogating and modifying PRFILE parameters.

Verifying Non-Performing Cell RecoveryThe restart ordering from the RNC is done using the BTS O&M Interface link. These messages can be observed using a protocol analyzer connected to the Iub interface.

The re-initialization of the common channels or common measurements or the RNC ordered BTS restart can be examined from the C-NBAP link.

The BTS restart can be observed additionally from a specific Non-performing Cell Recovery alarm.

Deactivating Non-Performing Cell RecoveryTo deactivate the feature the Non/performing Cell Recovery parameter is set as disabled (=F).

The feature can be deactivated with the following MML command:

ZWOC:2,1296,F;

Feature Management

• RNC PRFILE parameter for setting the functionality on and off • Alarm for indicating a BTS restart because of recovery actions

114 DN0934844Issue 01


Id:0900d8058060635c

Architecture

Figure 35 Non-Performing Cell Recovery architecture


UI/CommandLine

PRFILE

Recoveryfunctionality

RNC

C - NBAPO&Minterface

BTS

DN0934844Issue 01

115


Id:0900d8058060635f

3.15 RAN801: Radio Network Access Regulation Function

3.15.1 Feature descriptionA network becomes congested when the amount of user accesses goes far beyond the maximum user access capacity at a certain location. It, by and large, can be divided into two cases:

• Small area (such as a baseball park, a soccer stadium, a concert hall, or a shrine on New Year holidays).Before the core network becomes congested, the maximum user access capacity of the cell is exceeded and the cell may be placed in permanently inaccessible state.

• Considerably large area (city, town, or village level) in case of emergency, such as a natural disaster like an earthquake.Users try to access the network in a vast amount at the same time (for emergency calls such as inquiring about the safety of their family). In this case, the core side may become congested because of overcrowded lines.

The access right to the network (allowed/restricted) is broadcast to all User Equipment (UE) in the System Information message on Access Level basis. In a normal situation, the network access is allowed for all Access Levels. If the network access needs to be limited due to above-mentioned reasons, the operator can activate the access control algorithm, which allows and restricts the network access of Access Level 0 to 9 users in predefined intervals. Access Levels 10 to 15 belonging to authorities (for example the fire service or the police) are not restricted.

New restricted/allowed information is broadcast in the System Information message to all UEs in the cycle of the access control algorithm’s interval. The UEs at the restricted Access Level stop transmitting the connection request messages until the status of the Access Level in system Information is changed to 'allowed'.

Operator benefitsRadio Network Access Regulation (RNAR) can restrict access in units of BTS or cell under a specific Radio Network Controller (RNC), alleviate excessive traffic to the Core Network in a specific period of time, and prevent DX MSC (MSC) from collapsing because of excessive traffic.

The use of broadcast information allows restrictions on network access to control network traffic in advance, thus preventing excessive network access.

Access can be controlled timely in units of geographical area.

The minimum number of access users can be reserved quite easily and access priorities can be set.



This feature sets no requirements outside RAN.


• RNC: RN2.2 • NetAct: OSS4.1

116 DN0934844Issue 01


Id:0900d8058060635f








Limitations and restrictionsThis feature allows only one configuration for the restriction which can be applied to all cells under one RNC. It is not possible to configure multiple different regulation areas under one RNC.


Using RNARPreconditions for using the feature

The Core Network, NetAct, RNC and at least one WBTS must be up and running. Sudden increase of traffic has been noticed or there will be a public event that will generate too much traffic for RAN to handle. Some traffic restriction is needed.

Actions to be taken by user

The following actions have to be taken by the user:

1. The NetAct is used to select the cells in which the RNAR will be applied.2. The Radio Network (RNW) plan file is prepared with the NetAct with the parameters

set to plan file so that the wanted restriction level will be reached.3. The RNW plan file is downloaded and activated.

An alternative way to use the feature is to make the RNW configuration changes with the RNW Object Browser.

It is recommended to have all the cells preconfigured so that they are all included in this traffic restriction by default. Thus, there will be no need to modify cell objects any more when the restriction is applied and the feature ramp-up time will be much faster. A cell is included in the restriction by setting the parameter AccessClassRegulation value to 'enabled'.

The appropriate restriction level (the amount of access classes allowed in a particular period) may not be easy to define since the UE’s access classes in some cells may not be evenly distributed (all users may even have the same AC). The amount of access classes barred in one period is defined with parameter CellAccessRestriction.

Parameter RestrictionInterval is used to define the length of the barring period. When the period is over, the Radio Network Controller (RNC) selects the next access classes to be barred.

Activating RNARThis feature is part of the application software. To activate the feature, a separate licence has to be bought and RNAR parameters to be set.

DN0934844Issue 01

117


Id:0900d8058060635f

Verifying RNARThere is always a minor alarm set when the feature is functional. The alarm is cancelled by the system when the RNAR is no longer used in any cell. Test calls with different SIM cards (access classes) have to be made.

Deactivating RNARFeature is disabled by setting the RNW parameter RestrictionInterval to '0'.

Feature managementThere is the alarm Radio Network Access Regulation Function activated set when feature is active and cancelled when feature is disabled.

Following table illustrates RNW parameters used to configure this feature.

ArchitectureThis feature uses existing interfaces and requires no changes to architecture.

Figure 36 RNAR architecture

The WBTS sends BCCH information using the interval defined with parameter RestrictionInterval.

CapacityThis feature has no special effects on capacity.

Parameter name Value range Default value RNW object Description

CellAccessRestriction 10...100, step 10 10 RNC Defines how many per-centage of the access classes is barred at one time.

RestrictionInterval 0, 20, 30, 40.. 1800, step 10

0 RNC Defines how long one barring period lasts.

AccessClassRegulation Disabled (0) Enabled (1)

Disabled (0) WCEL Defines if RNAR is used in a cell.

Table 7 Management parameters

RNC

WCDMA BTS

NWI3 Management interface

BTS NBAP interfaceBCCH

informationUE

NetAct

RAC

CM SW

118 DN0934844Issue 01


Id:0900d80580606362

3.16 RAN375: Read Only-Access for RNC & AXC Element Managers

3.16.1 Feature descriptionWith this feature the operator can set read-only access rights for an Element Manager user of the Network Element (NE). The access rights are defined for each user for each NE type. This means, for example, that the same user may have full access to one NE type but only read-only access for another.

Operator benefitsThis feature offers the possibility to differentiate users according to the need of usage by giving only browsing privilege into a certain NE without possibility to execute network management operations there.



This feature does not need any additional functionality outside AXC, RNC and NetAct.


RNC: RN2.2 [IPA2800 – A4.2; NEMU – NM3.3]

NetAct: OSS4.1

AXC: C2.7


See Remote User Information Management (RUIM)..


Management of User Accounts with associated authorization roles needs creation and maintenance work. See NetAct documentation for details.

It is the operator’s task to plan in which cases it wants to grant only read-only operating privileges to its personnel.


It is the end-user’s responsibility to be aware of the possessed privileges of his/her account.

Interaction with other featuresThis feature is based on 'Remote User Information Management for AXC and RNC' feature and it is a sub-functionality of Remote User Information Management (RUIM).

Limitations and restrictionsThis feature does not offer any extended functionality beyond RUIM.

DN0934844Issue 01

119


Id:0900d80580606362


Using Read only access for RNC and AXC EMsNetwork management connection is authenticated and authorised when the user begins to perform network management tasks with the Network Element Manager. The user will be asked, in a standard style, to input his/her username and password at login. In this case, authorisation will give read-only operative permissions to the user.

Activating Read only access for RNC and AXC EMsSince the feature is a standard one (belongs to RUIM), there is no need to activate it separately.

User management and user read-only rights are initialised and maintained by the security system administrator. The NetAct tools are used to initialise and maintain the central Authentication Server user database. The local administrative initialisation and maintenance is performed with Network Element (NE) Manager.

Verifying Read only access for RNC and AXC EMsThe user attempts to execute operations, which need to update, delete, or add data are unsuccessful.

Deactivating Read only access for RNC and AXC EMsSince the feature is a standard one (belongs to RUIM), there is no need to deactivate it separately.

The security system administrator can modify read-only rights and accordingly increase/decrease access permission level.

Feature managementSee RUIM.

ArchitectureThe Figures User Information Management for read-only access rights and User NE login authentication/User authorisation present the architecture of Read Only-Access for Radio Network Controller (RNC) & ATM Cross Connect (AXC) Element Managers (logical usage).

Figure 37 User Information Management for read-only access rights

Figure 38 User NE login authentication/User authorisation

AdminCentraluser Db

NE localuser Db

Maintain centrallyro-rights withNetAct tools

Maintain locallyro-rights with

NetAct/NE Manager

AuthenticationServer

NEUser

Requestentry/operation

Authenticate/Authorise user

Allow-forbidsession/operation

Grant-denyaccess/Deliver profile

Local authentication/authorisation

120 DN0934844Issue 01


Id:0900d80580606362

Interface

The network elements (RNC and AXC) communicate with the Authentication Server through Lightweight Directory Access Protocol (LDAP) interface.

CapacitySee RUIM.


PlanThis feature has no effect to the network planning.

IntegrateSee RUIM.


DN0934844Issue 01

121


Id:0900d80580606365

3.17 RAN615: Remote User Event Log Management for AXC

3.17.1 Feature descriptionThis feature enables the centralised aggregating of user event logs from the ATM Cross Connects (AXCs) in the Nokia NetAct. The operator can trace changes in the network based on user or network element information.

The upload is triggered from Nokia NetAct, and XML file format is used as the transfer log file format. The Nokia NetAct can also produce the data in the User Event Collection with their original content. It is also possible to get normalized log records, which can be converted into, for example, XML-format.

File Transfer Protocol (FTP) is used for the log file collection from network elements. The Nokia NetAct provides tools for processing the collected log files.

Operator benefitsThis feature enables fast tracking of suspected illegal user actions. Besides increased security, the overall view of operations executed in NEs can help to organise mainte-nance work more effectively, which can save time and costs.



This feature does not need any additional functionality outside the AXC, RNC and the NetAct.


• NetAct: OSS4.1 CD set 1 • AXC: C2.7


Dedicated computer is allocated to host the Audit trail -application in NetAct.


The operator needs to keep following logs, and to arrange enough disk space for the storing of log files.


The end-users have to be aware of that their actions are logged.

Interaction with other featuresUser identification with associated Network Element (NE) operations is written to the log file. The identification is based on the fact that 'Remote User Information Management for AXC and RNC' feature has been taken into the use.

Limitations and restrictionsLog file size is limited in NEs in order to save space.

Some of the log data can be lost if network connections are down, and NE starts to rewrite the full size log file.

122 DN0934844Issue 01


Id:0900d80580606365


Usting Remote User Event Log Management for AXCAll important network operations and events in the NE are securely logged automatically with user identification. For more information, see NetAct Audit Trail Documentation.

Log collection is activated when file has become full, or separately requested from the NetAct.

Activating Remote User Event Log Management for AXCSince the feature is a standard one, there is no need to activate it separately.

Verifying Remote User Event Log Management for AXCLogs can be viewed through NetAct applications and has to be compared to actions executed in the network element.

Deactivating Remote User Event Log Management for AXCSince the feature is a standard one, there is no separate deactivation.

Feature managementSee the associated NetAct-documentation to find out the complete list of configurable RUEM parameters.

Parameters

ArchitectureRemote User Event Log Management for AXC architecture is presented in the following figure.

Parameters

Parameter name: Number of upload attempts

Managed object: NMS

Description: Describes how many times consecutively log file tries to reload if the first upload fails.

Range: 1 – 5 times

Default value: -

Parameter name: Frequency of upload

Managed object: NMS

Description: Describes what is the period length between log file uploads.

Range: days

Default value: -

Table 8 Parameters

DN0934844Issue 01

123


Id:0900d80580606365

Figure 39 Remote User Event Log Management for AXC architecture

Interface

Log collection request/responses are delivered through the NWI3 interface between NetAct and AXC. FTP is used for moving the log file.

CapacitySimultaneous log file uploads from several NEs to NetAct can cause in a theory a per-formance problem.


PlanThis feature has no effect on the network planning.



NetAct

User eventcollection

Logfile transfer

NE NE NE

124 DN0934844Issue 01


Id:0900d80580606368

3.18 RAN183: Remote User Event Log Management for RNC

3.18.1 Feature descriptionThis feature enables the centralised aggregating of user event logs from the Radio Network Controllers (RNCs) in the Nokia NetAct. The operator can trace changes in the network based on user or network element information.

The upload is triggered from Nokia NetAct, and XML file format is used as the transfer log file format. The Nokia NetAct can also produce the data in the User Event Collection with their original content. It is also possible to get normalized log records, which can be converted into, for example, XML-format.

File Transfer Protocol (FTP) is used for the log file collection from network elements. The Nokia NetAct provides tools for processing the collected log files.

Operator benefitsThis feature enables fast tracking of suspected illegal user actions. Besides increased security, the overall view of operations executed in NEs can help to organise mainte-nance work more effectively, which can save time and costs.



This feature does not need any additional functionality outside the AXC, RNC and the NetAct.


• RNC: RN2.2 [IPA2800 – A4.2; NEMU – NM3.3] • NetAct: OSS4.1 CD set 1


Dedicated computer is allocated to host the Audit trail application in the NetAct.


The operator needs to keep following logs, and to arrange enough disk space for the storing of log files.


The end-users have to be aware of that their actions are logged.

Interaction with other featuresUser identification with associated Network Element (NE) operations is written to the log file. The identification is based on the fact that 'Remote User Information Management for AXC and RNC' feature has been taken into the use.

Limitations and restrictionsLog file size is limited in NEs in order to save space.

Some of the log data can be lost if network connections are down, and NE starts to rewrite the full size log file.

DN0934844Issue 01

125


Id:0900d80580606368


Using Remote User Event Log Management for RNCAll important network operations and events in the NE are securely logged automatically with user identification. For more information, see NetAct Audit Trail Documentation.

Log collection is activated when file has become full, or separately requested from the NetAct.

Activating Remote User Event Log Management for RNCSince the feature is a standard one, there is no need to activate it separately.

Verifying Remote User Event Log Management for RNCLogs can be viewed through NetAct applications and has to be compared to actions executed in the network element.

Deactivating Remote User Event Log Management for RNCSince the feature is a standard one, there is no separate deactivation.

Feature managementSee the associated NetAct documentation to find out the complete list of configurable RUEM parameters.

Parameters

ArchitectureRemote User Event Log Management for RNC architecture is presented in the following figure.

Parameters

Parameter name: Number of upload attempts

Managed object: NMS

Description: Describes how many times consecutively the log file tries to reload if the first upload fails.

Range: 1 – 5 times

Default value: -

Parameter name: Frequency of upload

Managed object: NMS

Description: Describes what is the period length between log file uploads.

Range: days

Default value: -

Table 9 Parameters

126 DN0934844Issue 01


Id:0900d80580606368

Figure 40 Remote User Event Log Management for RNC, architecture

Interface

Log collection request/responses are delivered through the NWI3 interface between NetAct and RNC. FTP is used for moving the log file.

CapacitySimultaneous log file uploads from several NEs to NetAct can cause in a theory a per-formance problem.





NetAct

User eventcollection

Logfile transfer

NE NE NE

DN0934844Issue 01

127


Id:0900d8058060636c

3.19 RAN617: Remote User Information Management for AXC

3.19.1 Feature descriptionBoth the user and the hosts must be identified for access to the management system (NetAct) to fulfill the security requirements.

This feature offers centralised user authentication and authorisation for Nokia NetAct and Element Manager users (ATM Cross Connect (AXC)).

The minimum management requirements for user information are:

• creation of new users; • password change; • deletion of users.

With this feature the user is able to manage the access to the Operation and Mainte-nance (O&M) network separately for each group or individual of the maintenance per-sonnel. In the User Information Management system, the operator can define different access classes for different user groups and network elements.

Operator benefitsThis feature offers the possibility to manage the user accounts of the Network Elements from the NetAct. It allows user to login to different Network Elements with a same user-id and password. User authorization profiles can be customized according different roles.

In addition to the increased security, it also provides a more efficient way to manage users generally. It can save costs and time by reducing site visits related to user man-agement.

ComplianceThis feature is not tied with any specific standard. Closely related is the Open Group Technical Standard, Authorization (AZN) API, Document Number: C908.





NetAct: OSS4.1

AXC: C2.7


Specific Lightweight Directory Access Protocol (LDAP) server(s) supporting Remote User Information Management (RUIM) schema.


Management of User Accounts with associated authorisation roles needs creation and maintenance work. See NetAct documentation for details.

It is the operator’s task to plan what kind of operating privileges it wants to give to its maintenance personnel.


128 DN0934844Issue 01


Id:0900d8058060636c

It is the end-user’s responsibility to remember his/her username/password, and be aware of the possessed privileges of his/her account.

Interaction with other featuresWhen user is executing management operations in the NE, the user identity together with an operation is recorded into the log file. Log file is used by the 'Remote User Event Log Management for AXC and RNC' feature.

Limitations and restrictionsThe system is not capable at the moment of informing the user about few certain network wide account and password policies. This can occur for example when user’s account has been locked in Authentication Server.

The user is not able to change his/her central account password from the NE client (AXC).

For both above situations, the user has to contact central security administrator.


Using Remote User Information Management for AXCNetwork management connection is authenticated and authorised when the user begins to perform network management tasks with the Network Element Manager. The user will be asked in a standard style to input his/her username and password at login.

Network elements themselves authenticate as well when they connect to each other’s to perform system administration tasks like software updates. This happens with a special Network Element account.

The security system administrator can remove user accounts and NE accounts from the Authentication Server using the NetAct tools.

NE local user accounts can be used during commissioning tasks and in situations, where connection to Authentication Server is broken.

Activating Remote User Information Management for AXCSince the feature itself is a standard one, there is no need to activate it separately.

User management and user rights are initialised and maintained by the security system administrator. The NetAct tools are used to initialise and maintain the central Authenti-cation Server user database. The local NE user information administrative initialisation and maintenance is performed with associated Network Element Manager (in some cases it can also be performed with NetAct tools).

Central or local user authentication mode of the network element (AXC) is selected with Network Element Manager (not RNC OMU – fixed order).

Network element accounts are created automatically.

Verifying Remote User Information Management for AXCIn the case that authentication rules are violated, the resulting action can be a locked user session or an alarm. Authorisation rule violations are logged.

Deactivating Remote User Information Management for AXCSince the feature itself is a standard one, there is no need to deactivate it separately.

DN0934844Issue 01

129


Id:0900d8058060636c

The single Network Element can deactivate the central authentication in the case of RNC IPA.

Feature managementParameter ranges and default values here refer to NetAct central parameter usage. Locally used AXC and RNC parameter values differ from those. See each associated NE parameter documentation for the complete descriptions.

Parameters


Description: Describes how long time the session can be in an idle state before session is closed automati-cally.

Range/Default: 1 – 60 min / 10 min, 0 means disabled (restricted usage in RAN05.1)

Scope Central (Websphere) / Local usage by RNC (IPA+NEMU), AXC

Parameter name: Number of unsuccessful login attempts [session parameter]

Description: Describes how many consecutive unsuccessful login attempts are allowed before the granting of the next session will be delayed.

Range/Default: 1 – 5 times / 3

Scope: Central (LDAP, ITIM) / Local usage by RNC (IPA+NEMU), AXC

Parameter name: Time to reset delay [session parameter]

Description: Describes after the how long time the login delay will be reset.

Range/Default: 1 – 999 min / - (restricted usage in RAN05.1)


Parameter name: Password history [password parameter]

Description: Describes how many previous passwords are remembered to prevent the usage of the same password.

Range/Default: 1 – 24 times / 10 times

Scope: Central usage (ITIM)

Parameter name: Maximum password age [password parameter]

Description: Describes how many days maximum the same user password can be in use.

Table 10 Parameters

130 DN0934844Issue 01


Id:0900d8058060636c

Range/Default: 0 – 999 days / 0 (no limit – NOTE permanent setting in RAN05.1)

Scope: Central (LDAP, ITIM) / Local usage by RNC IPA

Parameter name: User must change password at next logon [pass-word parameter]

Description: Describes if the user is forced to change password during next login.

Range/Default: yes/no /\ - (restricted usage in RAN05.1)

Scope: Central (ITIM) / Local usage by RNC NEMU

Parameter name: User cannot change password [password parameter]

Description: Describes if the user is not able to change pass-word.

Range/Default: yes/no /\ -


Parameter name: Time interval when NMS changes NE’s own account password [password parameter]

Description: Describes the frequency NE account password is changed by NMS.

Range/Default: 0 – 90 days / 30 days

Scope: Central usage


Description: Describes the minimum length of the password.

Range/Default: 8 – 32 characters / -

Scope: Central (ITIM) / Local usage by AXC, RNC (IPA+NEMU)

Parameter name: Lock time [account parameter]

Description: Describes the length an account will be locked as a result of login rule violation.

Range/Default: 0 – 9999 minutes / 60 minutes

Scope: Central usage (LDAP) / Local usage by RNC NEMU

Parameter name: Failed password attempts [account parameter]

Parameters

Table 10 Parameters (Cont.)

DN0934844Issue 01

131


Id:0900d8058060636c

Description: Describes the number of false password usage attempts before the account will be locked.


Scope: Central usage (LDAP, ITIM)

Parameter name: Time to reset failed password attempt counter [account parameter]

Description: Describes the time until the new login attempt is allowed again after the ‘failed password attempts’.



Parameter name: Account locking [account parameter]

Description: Describes if the locking is enabled.

Range/Default: yes/no /\ no

Scope: Central usage (LDAP, ITIM) / Local usage by RNC NEMU

Parameter name: Logon hours [account parameter]

Description: Describes the timeframe login is allowed to perform.

Range/Default: freely selectable time / -

Scope: Central usage (Active Directory)

Parameter name: Account expiration [account parameter]

Description: Describes the end time for user account validity.

Range/Default: any date and time / -


Parameter name: Account length [account parameter]

Description: Describes the length of the user name.


Scope: Central / Local usage by RNC (IPA+NEMU), AXC

Parameter name: Authentication method [method parameter]

Description: Describes the authentication source.

Range/Default: 0 / 1 (local / authentication server) / -

Parameters


132 DN0934844Issue 01


Id:0900d8058060636c

Architecture

Figure 41 Remote User Information Management for AXC, architecture

Interface

The AXC communicates with the Authentication Server through the LDAP interface. Network element account administration operations (creating accounts and updating passwords) from NetAct to NE are performed through the NWI3 interface.

CapacityTheoretically, it is possible that high density of authentication/authority requests can cause performance problems (like NetAct MMI-connections to RNC).

Scope: Local usage by RNC (IPA+NEMU), AXC

Alarms

Alarm name: Attempt of access to a NE by using wrong cre-dentials

Managed object: RNC, NMS, AXC

Description: User ID or password is tried to guess. NE acti-vates the alarm after the five consecutive failed login attempts with wrong credentials.

Alarm name: Remote authentication mode disabled

Managed object: RNC, NMS

Description: Authentication mode transfer from central to local is activated. RNC NEMU implements this alarm.

Table 11 Alarms

Parameters


Grant-deny access/Deliver profile

NE

Centraluser Db

NE localuserDb

Maintain locally withNetAct/NE Manager

Maintain centrallywith NetAct tools

Admin

UserAuthentication

Server





DN0934844Issue 01

133


Id:0900d8058060636c



IntegrateLDAP server(s) are integrated into the operator’s network.

Network Element LDAP clients are configured so that they are able to communicate with LDAP Authentication Server.

Network Elements will register their existence to NetAct for the NE account setup. See more information in the corresponding NE documentation.


134 DN0934844Issue 01


Id:0900d80580606370

3.20 RAN181: Remote User Information Management for RNC

3.20.1 Feature descriptionBoth the user and the hosts must be identified for access to the management system (NetAct) to fulfill the security requirements.

This feature offers centralised user authentication and authorisation for Nokia NetAct and Element Manager users (Radio Network Controller (RNC)).

The minimum management requirements for user information are:

• creation of new users; • password change; • deletion of users.

With this feature the user is able to manage the access to the Operation and Mainte-nance (O&M) network separately for each group or individual of the maintenance per-sonnel. In the User Information Management system, the operator can define different access classes for different user groups and network elements.

Operator benefitsThis feature offers the possibility to manage the user accounts of the Network Elements from the NetAct. It allows user to login to different Network Elements with a same user-id and password. User authorization profiles can be customized according different roles.

In addition to the increased security, it also provides a more efficient way to manage users generally. It can save costs and time by reducing site visits related to user man-agement.

ComplianceThis feature is not tied with any specific standard. Closely related is the Open Group Technical Standard, Authorisation (AZN) API, Document Number: C908.





NetAct: OSS4.1

AXC: C2.7


Specific Lightweight Directory Access Protocol (LDAP) server(s) supporting Remote User Information Management (RUIM) schema.


Management of User Accounts with associated authorisation roles needs creation and maintenance work. See NetAct documentation for details.

It is the operator’s task to plan what kind of operating privileges it wants to give to its maintenance personnel.


DN0934844Issue 01

135


Id:0900d80580606370

It is the end-user’s responsibility to remember his/her username/password, and be aware of the possessed privileges of his/her account.

Interaction with other featuresWhen user is executing management operations in the NE, the user identity together with an operation is recorded into the log file. Log file is used by the 'Remote User Event Log Management for AXC and RNC' feature.

Limitations and restrictionsThe system is not capable at the moment of informing the user about few certain network wide account and password policies. This can occur for example when user’s account has been locked in Authentication Server.

The user is not able to change his/her central account password from the NE client (RNC).

For both above situations, the user has to contact central security administrator.


Using Remote User Information Management for RNCNetwork management connection is authenticated and authorised when the user begins to perform network management tasks with the Network Element Manager. The user will be asked in a standard style to input his/her username and password at login.

Network elements themselves authenticate as well when they connect to each other’s to perform system administration tasks like software updates. This happens with a special Network Element account.

The security system administrator can remove user accounts and NE accounts from the Authentication Server using the NetAct tools.

NE local user accounts can be used during commissioning tasks and in situations, where connection to Authentication Server is broken.

Activating Remote User Information Management for RNCSince the feature itself is a standard one, there is no need to activate it separately.

User management and user rights are initialised and maintained by the security system administrator. The NetAct tools are used to initialise and maintain the central Authenti-cation Server user database. The local NE user information administrative initialisation and maintenance is performed with associated Network Element Manager (in some cases it can also be performed with NetAct tools).

Central or local user authentication mode of the network element (AXC) is selected with Network Element Manager (not RNC OMU – fixed order).

Network element accounts are created automatically.

Verifying Remote User Information Management for RNCIn the case that authentication rules are violated, the resulting action can be a locked user session or an alarm. Authorisation rule violations are logged.

Deactivating Remote User Information Management for RNCSince the feature itself is a standard one, there is no need to deactivate it separately.

136 DN0934844Issue 01


Id:0900d80580606370

The single Network Element can deactivate the central authentication in the case of RNC IPA.

Feature managementParameter ranges and default values here refer to NetAct central parameter usage. Locally used AXC and RNC parameter values differ from those. See each associated NE parameter documentation for the complete descriptions.

Parameters


Description: Describes how long time the session can be in an idle state before session is closed automati-cally.

Range/Default: 1 – 60 min / 10 min, 0 means disabled (restricted usage in RAN05.1)

Scope Central (Websphere) / Local usage by RNC (IPA+NEMU), AXC

Parameter name: Number of unsuccessful login attempts [session parameter]

Description: Describes how many consecutive unsuccessful login attempts are allowed before the granting of the next session will be delayed.

Range/Default: 1 – 5 times / 3


Parameter name: Time to reset delay [session parameter]

Description: Describes after the how long time the login delay will be reset.

Range/Default: 1 – 999 min / - (restricted usage in RAN05.1)


Parameter name: Password history [password parameter]

Description: Describes how many previous passwords are remembered to prevent the usage of the same password.



Parameter name: Maximum password age [password parameter]

Description: Describes how many days maximum the same user password can be in use.

Table 12 Parameters

DN0934844Issue 01

137


Id:0900d80580606370

Range/Default: 0 – 999 days / 0 (no limit – NOTE permanent setting in RAN05.1)

Scope: Central (LDAP, ITIM) / Local usage by RNC IPA

Parameter name: User must change password at next logon [pass-word parameter]

Description: Describes if the user is forced to change password during next login.

Range/Default: yes/no /\ - (restricted usage in RAN05.1)


Parameter name: User cannot change password [password parameter]

Description: Describes if the user is not able to change pass-word.

Range/Default: yes/no /\ -


Parameter name: Time interval when NMS changes NE’s own account password [password parameter]

Description: Describes the frequency NE account password is changed by NMS.

Range/Default: 0 – 90 days / 30 days

Scope: Central usage


Description: Describes the minimum length of the password.


Scope: Central (ITIM) / Local usage by AXC, RNC (IPA+NEMU)

Parameter name: Lock time [account parameter]

Description: Describes the length an account will be locked as a result of login rule violation.


Scope: Central usage (LDAP) / Local usage by RNC NEMU

Parameter name: Failed password attempts [account parameter]

Parameters


138 DN0934844Issue 01


Id:0900d80580606370

Description: Describes the number of false password usage attempts before the account will be locked.



Parameter name: Time to reset failed password attempt counter [account parameter]

Description: Describes the time until the new login attempt is allowed again after the ‘failed password attempts’.



Parameter name: Account locking [account parameter]

Description: Describes if the locking is enabled.

Range/Default: yes/no /\ no

Scope: Central usage (LDAP, ITIM) / Local usage by RNC NEMU

Parameter name: Logon hours [account parameter]

Description: Describes the timeframe login is allowed to perform.

Range/Default: freely selectable time / -

Scope: Central usage (Active Directory)

Parameter name: Account expiration [account parameter]

Description: Describes the end time for user account validity.

Range/Default: any date and time / -


Parameter name: Account length [account parameter]

Description: Describes the length of the user name.


Scope: Central / Local usage by RNC (IPA+NEMU), AXC

Parameter name: Authentication method [method parameter]

Description: Describes the authentication source.

Range/Default: 0 / 1 (local / authentication server) / -

Parameters


DN0934844Issue 01

139


Id:0900d80580606370

Architecture

Figure 42 Remote User Information Management for RNC, architecture

Interface

The RNC communicates with the Authentication Server through the LDAP interface. Network element account administration operations (creating accounts and updating passwords) from NetAct to NE are performed through the NWI3 interface.

CapacityTheoretically, it is possible that high density of authentication/authority requests can cause performance problems (like NetAct MMI-connections to RNC).

Scope: Local usage by RNC (IPA+NEMU), AXC

Alarms

Alarm name: Attempt of access to a NE by using wrong cre-dentials

Managed object: RNC, NMS, AXC

Description: User ID or password is tried to guess. NE acti-vates the alarm after the five consecutive failed login attempts with wrong credentials.

Alarm name: Remote authentication mode disabled

Managed object: RNC, NMS

Description: Authentication mode transfer from central to local is activated. RNC NEMU implements this alarm.

Table 13 Alarms

Parameters


Grant-deny access/Deliver profile

NE

Centraluser Db

NE localuserDb

Maintain locally withNetAct/NE Manager

Maintain centrallywith NetAct tools

Admin

UserAuthentication

Server





140 DN0934844Issue 01


Id:0900d80580606370



IntegrateLDAP server(s) are integrated into the operator’s network.

Network Element LDAP clients are configured so that they are able to communicate with LDAP Authentication Server.

Network Elements will register their existence to NetAct for the NE account setup. See more information in the corresponding NE documentation.


DN0934844Issue 01

141


Id:0900d80580606373

3.21 RAN1152: WCEL Lock and Unlock during RNW Plan Acti-vation

3.21.1 Feature descriptionCurrently, plan operations are the main way to make bigger Radio Network (RNW) con-figuration changes. During the plan activation, access to all RNW objects in the Radio Network Controller (RNC) database is restricted. In some cases, plan activation can be a lengthy operation, so it can be frustrating to wait until the plan activation is over.

With this feature, the administrative states of the WCDMA Cell (WCEL) object can be changed with the RNC Object Browser (OBRO) even when an RNW plan activation pro-cedure is ongoing. The user is not allowed to perform other RNW related management tasks during the RNW plan activation. However, the WCEL lock and unlock operations are the most commonly needed operations during the plan activation.

Operator benefitsWith this feature, the operator can lock and unlock cells also during the RNW plan acti-vation. Especially, if the plan activation causes some fault situations, the possibility to lock or unlock a cell is highly important.



This feature sets no special system requirements.


• RNC: RN2.2






It is recommended that the user does not lock or unlock cells which are going to be modified in the ongoing RNW plan activation.


Limitations and restrictionsThe user is not allowed to do other RNW related management tasks during the RNW plan activation.

142 DN0934844Issue 01


Id:0900d80580606373


Using WCEL lock and unlock during RNW plan activationThe user can lock and unlock WCEL from the RNC Object Browser during the RNW plan activation operation.

Activating WCEL lock and unlock during RNW plan activationThis feature is part of the operating software, so no special action is needed for taking the feature into use.

Verifying WCEL lock and unlock during RNW plan activationTo verify the feature, the user can start with downloading an RNW plan for a certain RNC from the NetAct Radio Access Configurator. Then the user can continue with the RNW plan activation from the NetAct. During the activation, the user can lock and unlock a WCDMA cell under the given RNC from the RNC Object Browser.

Deactivating WCEL lock and unlock during RNW plan activationThis feature is operating software, so no special action is needed for taking the feature out of use.


ArchitectureThe figure below presents the architecture of WCEL Lock and Unlock during RNW Plan Activation.

Figure 43 Architecture of WCEL Lock and Unlock during RNW Plan Activation


NetAct

RNC

BTS

Radio AccessConfigurator

Network management interface

3GPP NBAP

RNWConfigurationManagement

BTS Configuration Management

RNC ObjectBrowser

DN0934844Issue 01

143


Id:0900d80580606378

3.22 RAN1453: Iu Link Break Protection

3.22.1 Feature descriptionThe Iu Link Break Protection feature gives the operator a possibility to balance and reduce signalling load caused by short Iu breaks. The operator can also optimise the recovery speed of its network to minimise revenue loss in case of Iu link failure.

The Iu service barring feature is used for informing the UEs about Core Network (CN) services. When the Circuit Switched (CS) or Packet Switched (PS) service is lost, system information update (SIB1) is sent to UEs to inform them that the concerned service is not available. At the SIB reception, the reaction of the UE is different depend-ing on the implementation chosen by the manufacturer - some UEs stay attached to the concerned cell, and others decide to leave this cell and select another one where the service is available. When both services, CS and PS, are lost, also SIB3 must be sent. This SIB3 means cell barring, that is, no services are available and UEs need to find a new cell.

The Iu Link Break Protection can be used for preventing UEs from changing cells when the CN service is temporarily unavailable. The Iu Link Break Protection functionality delays the SIB1 sending and if the lost CN service is recovered before the waiting time has passed, no SIB1 update is needed and UEs remain in the cell the whole time. The operator can define the timer value which defines when the SIB1 should be sent after the Iu link break. There are separate timer values for CS CN and PS CN.

When the CN service is recovered, SIB updates the new Iu link information to UEs immediately. SIB information is updated to cells in groups because the cell group size affects the RNC load. With this new functionality, the operator can optimise the recovery speed of the network. The operator can choose the amount of cells to which the SIB information is updated at a time. There are separate parameters for CS and PS CN cell amounts.

When Iu link becomes established, the first group of cells (operator defined cell amount) receive the system information update. After this a specific timer is set to wait before the next set of cells receive the system information updates

Operator benefitsThere will be OPEX and CAPEX savings due to preventing actions of core melt down in case of short-term link failure. There will be also revenue increase due to shorter service recovery time.




• RNC: RN2.2





144 DN0934844Issue 01


Id:0900d80580606378



Interaction with other featuresSimultaneous usage of Iu Link Break protection and the Nokia-specific Multiple Core Networks Support or Multi-Operator RAN feature is not possible.

Limitations and restrictionsTimer utilisation of CS core network affects also emergency call attempts, so the Nokia Siemens Networks recommended timer value for the CS core timer is 0.



Using Iu Link Break ProtectionThe feature itself is executed by the system, so no user action is required.

The user can change the CS and PS timer values and CS and PS cell amount values in PRFILE using RNC MML.

Activating Iu Link Break ProtectionTo activate the feature, a new customer specific optional feature file order is required.

Verifying Iu Link Break Protection One of the CN links is put down. When RNC notices the link break, it starts the CN specific timer for SIB updating. When the timer expires, RNC sends SIB1 to all working cells connected to the given CN.

When the CN link is recovered, the RNC sends the updated SIB1 to all working cells connected to the given CN. The sending is done in groups defined by a CN-specific cell amount parameter.

If both CS and PS CN are down, the RNC sends both SIB1 and SIB3 for all working cells connected to the given CS and PS CN without delays.

Deactivating Iu Link Break ProtectionThe feature can be deactivated by setting the feature-related PRFILE parameters to value 0 using RNC MML.

Feature ManagementThis is an optional feature. A new customer-specific optional feature file order is required to take this feature into use.

PRFILE parameters are used for feature management. The operator can change the parameter values using RNC MML.

For further information, see Feature RAN1453: Iu Link Break Protection, Feature Acti-vation Manual in WCDMA RNC Product Documentation.

DN0934844Issue 01

145


Id:0900d8058060637c

3.23 RAN1193: Plan based RNC ATM/IP ConfigurationSummaryThis feature introduces plan based ATM/IP configuration management via NetAct Radio Access Configurator.

Benefits for the operatorOPEX savings are gained because of a faster RNC configuration demanding less user actions.

Functional descriptionThe feature introduces plan based ATM/IP configuration management for the RNC via NetAct Radio Access Configurator.

The ATM and IP layer configuration is planned in the NetAct tools. The ATM/IP config-uration plan is downloaded to RNCs and taken into use.

The plan management mechanism is the same as with the RNW configuration.

Operational aspects

146 DN0934844Issue 01


Id:0900d8058060637f

3.24 RAN1181: RNC NEMU FirewallSummaryFeature introduces a new firewall SW support in RNC NEMU.

Benefits for the operatorEnhanced risk management result from improved RAN system security.

Functional descriptionCommercial firewall SW 'VisNetic' is installed to NEMU. The firewall examines all data to see if it meets certain criteria. If it does, it is routed between the NWs, otherwise it is stopped.

The firewall can also manage public access to private networked resources such as host applications.

The firewall can filter packets based on their source, destination addresses and port numbers.

Note! If the NEMU firewall SW is used the same time as NEMU AntiVirus SW, the MCP18-B CPU is highly recommended in NEMU.

DN0934844Issue 01

147


Id:0900d80580606382

3.25 BTS Channel Element Capacity Measuring feature descriptionThe BTS channel element capacity measuring feature has the feature number RAN956.This feature is part of the WCDMA RAN measure solution (see Figure BTS channel element capacity measuring in WCDMA measure solution).

Figure 44 BTS channel element capacity measuring in WCDMA measure solution

This feature introduces new statistics for monitoring the BTS channel element capacity consumption from the BTS and the RNC point of view. The BTS counts min./max./aver-age availability of the channel element capacity and min./max./average usage of the channel element capacity. The RNC counts the average usage of the channel element capacity per RB type. The RB type refers in this measurement to the Traffic class and the allocated bit rate.

The BTSThe channel element measurement is based on the WSP capacity in Nora BTS and on the FSP capacity in FlexiBTS. In the Nora BTS case the available capacity means the maximum capacity (installed in the WBTS) – the disabled capacity (for example, the blocked). In the FlexiBTS case the available capacity means the maximum capacity – (the disabled capacity + the not licensed capacity). The measured channel element values are reported to the BTS EM and to the NetAct via the RNC (NEMU). If the baseband pooling is not in use or the BTS is a FlexiBTS, the values of the counters are

RNC

3GPP Itf-N interface

Nokia proprietary interface

RNCElement Manager

Reportgeneration

NetAct Northbound interface3GPP named counters

PM:Measurement

activation

PM:DataTransfer

LocalMeasurementManagement

Core Network

lub

lub

added

taadded

DL: Quality(Measured)

UL: BLER ar

Options Close

Radio 1

NokiaNetAct

Reporter

BTS Channel ElementCapacity Reports

- Available ChannelElements per BTS

- Used ChannelElements per BTS

BTS CECounters

148 DN0934844Issue 01


Id:0900d80580606382

calculated to the LCG_0 (this is the same as BTS level calculation). If the baseband pooling is in use the calculation is made per LCG.

The RNCOn the RNC side the channel element measurement is based on the estimated usage of channel elements in the WBTS. The estimation is done according to the following mapping table:

The measured RB types in the RNC are the following:

• CS voice call (AMR) • CS data call (conversational / streaming) • PS call (streaming/interactive/background)

3.25.1 Operator benefitsThe BTS channel element capacity measuring provides the operator the network level monitoring of the availability and utilisation of the BTS HW resources. This measure-ment also gives planning possibilities for the present and future needs of the BTS HW resources.

3.25.2 ComplianceThis feature has no references to the standards.

3.25.3 Resource requirements

System requirementsThis feature sets no requirements outside RAN.

Software requirementsThe software requirements are presented in the following table:

DCH data rate / kbps Used channel element

AMR 1

<=16 1

32 2

64 4

128 4

256 8

384 16

Table 14 Estimated usage of channel elements in the WBTS

RAN RNC BTS AXC NetAct SGSN MSC MGW UE

Release RN2.2 WN3.2 - OSS4 - - - -

Table 15 Software requirements

DN0934844Issue 01

149


Id:0900d80580606382

Hardware requirementsThis feature sets no special hardware requirements.

Operator requirementsThis feature sets no special operator requirements.

End user requirementsThis feature sets no additional end user requirements.

3.25.4 Interaction with other featuresThis feature interacts with the RAS05 feature: RAN21 Licence management for BTS.

3.25.5 Limitations and restrictionsThis feature has no special limitations or restrictions.

150 DN0934844Issue 01


Id:0900d80580606385

3.26 RAN1153: Complementary Counters in RAS05.1

3.26.1 Introduction to RAN1153: Complementary Counters in RAS05.1The RAN1153: Complementary Counters in RAS05.1 feature provides counters for selected improvement aspects related to NRT RAB drops in CELL_PCH state, refer-ence cell changes behind the RRC and RAB connections, holding times of RRC and RABs in reference cells, drops for selected Multi RABs, and availability monitoring of WCDMA RAN.

Benefits for the operatorBy this feature the operator will be able to follow-up:

• Drops of NRT RABs in Cell-PCH stateThe drop in CELL-PCH has no visibility for the user and therefore these counters can be used for RAN KPIs in order to achevive better visibility of RAB performance from end user perspective.

• Reference cell changes behind RRC and RABsThe reference cell change (SHO related) has impact on RRC and RAB counters if they are used for a specific cell. By introducing these counters the operator will have a possibility to monitor RRC and RAB performance from one cell perspective.

• Multi RAB Active Failures • Holding times of RRC and RABs for a reference cell

The counters can be used to monitor how frequently a cell is the reference compared to to other cells.

• Availability of: • WCELLs and Iub interfaces • Iur interfaces • Iu interfaces

3.26.2 System impact of RAN1153: Complementary Counters in RAS05.1

3.26.2.1 Current implementationThe current Cell Availability counters are based on monitoring the Code Tree. Based on the availability of the Code Tree the Resource Manager updates related counters. These counters are currently used also for cell availability monitoring.

3.26.2.2 Impact on system performance and capacityRAN KPIs for NRT RAB performance and WCELL/Iu/Iur availability will be introduced or updated.

3.26.3 RAN1153: Complementary Counters in RAS05.1 functional descrip-tion

ArchitectureThe RAN1153: Complementary Counters in RAS05.1 feature is part of the WCDMA RAN measure solution (see Figure WCDMA measure solution).

DN0934844Issue 01

151


Id:0900d80580606385

Figure 45 WCDMA measure solution

RNC



RNCElement Manager

Reportgeneration


PM:Measurement

activation

PM:DataTransfer


Core Network

lub

lub

added

taadded


UL: BLER ar

Options Close

Radio 1

NokiaNetAct

Reporter




BTS CECounters

152 DN0934844Issue 01


Id:0900d80580606388

3.27 Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power Control feature descrip-tionThe feature radio connection performance measurements for RLC TM and UM and outer loop power control has the feature number RAN190.

This feature extends the monitoring capabilities of the radio connection. That is, the RCPM measurement area is extended. The RCPM RLC measurement has been pre-sented in RAS05. With this feature two new measurements are produced: the RCPM OLPC and RCPM UEQ measurements.

The RCPM measurement area is optional. All RCPM measurements are under the same option. The following new measured items are seen in the new RCPM measure-ments:

• For uplink the DCH-specific BLER, BER and Eb/No are derived from the outer loop power control (OLPC) algorithm (including the RCPM OLPC measurement).

• For connections using UM or TM RLC the downlink BLER is obtained by setting the UE quality (UEQ) measurement (including the RCPM UEQ measurement).

• The DL radio link transmission power is obtained from the dedicated measurement report message received from the BTS. The measurement result is associated with the service (RAB) and transport channel (DCH) carried on the radio link. The average, variance and outage percentage of the transmission power is calculated for different traffic classes, bit rates and error targets (including the RCPM OLPC measurement).

In the RCPM OLPC/ RCPM UEQ measurements the classification for separating the measured object level is used. The classification can be done for RAB/RB by traffic classes with different bit rates. For more information on the classification, see Connec-tion type classification.

3.27.1 Operator benefitsThe RCPM OLPC and RCPM UEQ measurements extend the monitoring capabilities to measure the uplink and downlink performance of the radio connection between the BTS and the UE.

The RL transmission power calculation is useful for network capacity optimising pur-poses.




Software requirementsThe software requirements are presented in the table SW requirements.

DN0934844Issue 01

153


Id:0900d80580606388




3.27.4 Interaction with other featuresThe UEQ measurement can be started only for RBs using UM-RLC or the transparent mode RLC. The RCPM RLC measurement is meant for AM-RLC connections.

3.27.5 Limitations and restrictionsWith radio connection performance measurements for RLC TM and UM and outer loop power control, the measurement interval should not be shorter than 60 minutes.

Note that there are some limitations in large radio networks.

g NEMU (RNC):

The recommended maximum number of cells to be measured is 600. With this number of cells the load of NEMU stays on an acceptable level.

g NetAct:

Due to the large number of measured objects, the amount of RCPM data exceeds the NetAct processing capacity if the measurements are activated in all RNCs/NEMUs under a NetAct regional cluster. Thus, RCPM should be activated only in one RNC/NEMU at a time.

However, these restrictions are only an estimate, but at least the following factors affect the feature:

• the RCPM settings • the traffic mix • the settings for other RAN measurements • the size of the network • other measurements than the RAN measurements • NetAct HW and the number of servers • the SW build • the number of users


Release RN2.2 - - OSS4 - - - -

Table 16 SW requirements

154 DN0934844Issue 01


Id:0900d8058060638b

3.28 RAN1163: Iu-PS Throughput Measurement for GTP Traffic

3.28.1 Iu-PS Throughput Measurement for GTP Traffic feature descriptionThe Iu-PS throughput measurement for GTP traffic feature has feature number RAN1163. This feature is a part of the WCDMA RAN measure solution (see Figure Iu-PS throughput measurement for GTP traffic in WCDMA measure solution).

Figure 46 Iu-PS throughput measurement for GTP traffic in WCDMA measure solution

This feature introduces a new measurement, located in RNC, to follow the Iu-PS inter-face traffic volumes and the number of GTP protocol specific events. The measurement provides counters that updated per GTPU unit in RNC. The RNC specific or RAN total Iu-PS statistics can be calculated by summing the GTPU specific counters in NetAct. The Iu-PS interface termination in RNC and the relation to GTPU units is described in Figure Iu-PS interface termination in RNC.

RNC

lub

NokiaNetAct

PM: Measurementactivation

lu-CS lu-PS

Local MeasurementManagement

PM: Data Transfer

New: measurement: Iu-PSthroughput measurementfor GTP traffic

GTPU

Report generation

Reporter

RNCElement Manager




CS CoreNetwork

PS CoreNetwork

Network level reports:- Iu-PS interface totalthroughput- PS domain trafficvolumes per UMTS TC- Number of GTPtunnels

RNC levelCounters

Iub

DN0934844Issue 01

155


Id:0900d8058060638b

Figure 47 Iu-PS interface termination in RNC

The GTP layer traffic volume is reported through following counters. The counters do not include IP, UDP or GTP transport layer headers, but only the user payload data.

• Total number of bytes received • Total number of IP packets received • Number of bytes received, UMTS TC Conversational (not supported) • Number of bytes received, UMTS TC Streaming • Number of bytes received, UMTS TC Interactive • Number of bytes received, UMTS TC Background • Total number of bytes sent • Total number of IP packets sent • Number of bytes sent, UMTS TC Conversational (not supported) • Number of bytes sent, UMTS TC Streaming • Number of bytes sent, UMTS TC Interactive • Number of bytes sent, UMTS TC Background

The counters that report the Iu-PS interface and GTPU protocol performance calculate the number of sent and received echo messages, GTP error messages and number of tunnels.

The following events are reported through counters:

• Echo request received • Echo response received • Echo response sent • Error indication received • Error indication sent • Extension header notification received • Average number of GTP tunnels • Peak number of GTP tunnels

3.28.1.1 Operator benefitsThe new measurement enables monitoring the Iu-PS resource usage and dimensioning the network resources based on the actual traffic volumes.

GTPU-1

GTPU-2

GTPU-n

Iu-PSPS core

RNC

There are 1-4 GTPU in RNC. The maximum throughputsupported by RNC over Iu-PS is 405 Mbit/s

One GTPU can handle both background and delay sensitivetraffic, if the feature RAN717 (IPQOS) is enabled. OtherwiseGTPU is dedicated based on UMTS traffic classes.

156 DN0934844Issue 01


Id:0900d8058060638b

The information of PS traffic volumes can be used to dimension the Iu-PS interface transmission capacity, plan the RNC capacity upgrades and to report the PS domain traffic volumes in general for different business purposes. The maximum Iu-PS through-put supported by RNC is 405 Mbit/s, which is supported for HSDPA traffic in downlink. The RNC capacity statement includes the GTP headers, which are not included to the counter values.

3.28.1.2 ComplianceThis feature has no references to the standards.



Software requirementsThe software requirements are presented in the Table SW requirements.


Operator requirementsOperator needs to activate the measurement and select the measured objects.

End-user requirementsThis feature sets no additional end-user requirements.

3.28.1.4 Interaction with other featuresThis feature supports monitoring the RAS05.1 feature “Iu-PS IP Quality of Service Support (DiffServ in GTPU)”. This feature can be used also in the case the Iu-PS IP Quality of Service Support feature is not activated.

3.28.1.5 Limitations and restrictionsThere is a limitation related to measurement management, which is common to all trans-port and HW related measurements in RNC. These measurements can not be activated from NetAct, but they need to be activated separately for each RNC.


RAS05.1ED

RN2.2 ED

- - OSS4.1 CD set 2

- - - -

Table 17 RAS05.1 performance monitoring features

DN0934844Issue 01

157


Id:0900d8058060638b

3.28.2 Main functionality of Iu-PS Throughput Measurement for GTP Traffic

3.28.2.1 Using the Iu-PS throughput measurement for GTP trafficThe Iu-PS throughput measurement is operated similarly as other transport and HW related performance measurements in RNC. It is managed by using the RNC Element Manager GUI application in RAS05.1 or alternatively using MML commands.

3.28.2.2 Activating the Iu-PS throughput measurement for GTP trafficThis feature is part of the application software. The measurement and the data transfer from RNC to NetAct is activated either by using NE Measurement Explorer application in the RNC Element Manager or using ZT2 MML command group. The measurement data can be viewed either locally using NE Measurement Explorer or with NetAct report-ing tools.

3.28.2.3 Verifying the Iu-PS throughput measurement for GTP trafficWhen the feature works as planned, the measurement data is collected and stored in the PM databases and can be viewed with available PM tools.

3.28.2.4 Deactivating the Iu-PS throughput measurement for GTP trafficThe measurement and the data transfer from RNC to NetAct is deactivated either by using NE Measurement Explorer application in the RNC Element Manager or using ZT2 MML command group.

3.28.2.5 Feature managementThe related counters are described more in detail in RNC Counters – Transport and HW part in WCDMA RNC Product Documentation.

3.28.2.6 ArchitectureFor more information, see Figure Iu-PS throughput measurement for GTP traffic in WCDMA measure solution.

3.28.2.7 CapacityThis feature has no special capacity effects.

158 DN0934844Issue 01


Id:0900d8058060638e

3.29 Downlink Packet Data Throughput for Subscriber and Equipment Trace feature descriptionA new trace record is included in Subscriber and Equipment Trace solution. This new record allows collecting RLC Acknowledged Mode data.

The RLC Acknowledged Mode Downlink record contains the following data for each Radio Bearer of the traced UE:

• Average buffer occupancy • RLC activity time, i.e. time when there was RLC data to send • PDU size • Total number of transmitted PDUs • Number of re-transmitted PDUs • Number of discarded PDUs • Number of received SDUs • Number of transmitted SDUs • Number of discarded SDUs • SDU transfer delay

The Radio Bearer Trace Record will obtain the following UE Quality Measurement related data for each Radio Bearer of the traced UE:

• Generation Time • DCH ID • UE Quality Reporting Period • BLER

This feature will be part of WCDMA RAN Trace Solution (see Figure WCDMA RAN Trace Solution).

DN0934844Issue 01

159


Id:0900d8058060638e

Figure 48 WCDMA RAN Trace Solution

3.29.1 Operator benefitsThis feature enables the operator to more accurately verify the performance of the packet data Radio Bearers and to optimise the related parameters. Optimal parameters enable maximum radio interface throughput for all subscribers.


System RequirementsThis feature sets no requirements outside RAN.

Software RequirementsRNC RN2.2

OSS OSS4.1

Hardware RequirementsThis feature sets no special hardware requirements.

Operator RequirementsNone

RNC



RNCElement Manager

Reportgeneration

NetAct Northbound interface

NWI3: TRACE_REPORTRLC Data Included

MML: LocalTrace Activation

Core Network

lub

lub

Options Close

Radio 1

NokiaNetAct

TraceViewer

RANAPCN_INVOKE_TRACE

Activate Trace

RLCAM DL TraceRecords

Received data andbuffer occupancySent vs. not sent

data.Average Transfer

delay

160 DN0934844Issue 01


Id:0900d8058060638e

End-User RequirementsThis feature sets no additional end-user requirements.

3.29.3 Interaction with other featuresThis feature adds new content to Subscriber and equipment trace functionality which was introduced in RAN04 as the "Subscriber Trace" feature. The Subscriber Trace feature belongs to application software.


DN0934844Issue 01

161


Id:0900d80580606391

3.30 RAN189: Automatic Definition of Neighbouring CellsSummaryThis feature introduces new measurements for HO statistics to verify the performance of current adjacencies.

These measurements can be used for Neighbour Cell list optimization.

Benefits for the operatorOPEX savings result from faster and less resource consuming neighbour list optimiza-tion.

Increased revenue and improved end user experience are acquired through smaller number of dropped calls and better data throughput. Neighbouring Cell list optimization reduces the signalling load and ensures fast and reliable HO process of Mobile Termi-nals.

Functional descriptionThe automatic definition of neighbouring cells consists of operational and basic RNW measurement aspects.

Operational aspect

The operational aspect means the centralised performance analysis of current adjacen-cies and automated optimisation of the adjacency lists using the performance statistics from RAN. HO adjacency lists are initially defined with RNW planning based on geo-graphical locations and the estimated behaviour of the cells. However, this is not the optimal case; unnecessary cells may be included or necessary cells excluded.

In order to guarantee good NW performance immediately after launch, it is essential to be able to analyse the performance of current adjacency lists, and if needed, to optimise the adjacencies according to the performance statistics from operational cells. This process needs to be fast and reliable and therefore aided with appropriate tools. In the portfolio, NetAct Optimizer provides means to optimise the adjacency lists based on measurements, while the other NetAct tools complement the solution with centralised change management and performance data collection and reporting tools.

Basic radio network performance measurement aspect

In order to enable the NW management system to optimise the cell neighbour lists, several counters supplied by the RAN are needed (such as cell to cell HO statistics). The new HO measurements for the automatic definition of neighbouring cells are:

• 1013 Autodef SHO • 1014 Autodef IFHO • 1015 Autodef ISHO

However, the new HO measurements can be activated and used as any other basic RAN performance measurements.

When optimizing neigbours, the NetAct Optimizer also uses CPICH Ec/No difference information between the source and target cells. The optimizer retrieves this information directly from the RNC. This information is planned to be available as basic counters in later releases.

162 DN0934844Issue 01


Id:0900d80580606391

Operational aspectsThere have been introduced the new SHO, Intra Frequency and Inter System HHO PM measurements. In each measurement there will be counters for attempt and success HO.

DN0934844Issue 01

163


Id:0900d80580606394

3.31 CPICH Ec/No Coverage Measurements and Optimisation feature descriptionThe CPICH Ec/No coverage measurements and optimisation feature has the feature number RAN232.

This feature is a part of the WCDMA RAN measure solution.

When the UE sends the 1A event triggered intra-frequency measurement report to the SRNC in the MEASUREMENT REPORT (RRC) message, the CPICH Ec/No measuring is done. The received measurement report contains the cell-specific information about the CPICH Ec/No value mapped from the CPICH Ec/Io reporting range by the UE.

The CPICH Ec/No measuring is done for the best SRNC side cell, which can be either one of the current active set cells or one of the event triggered cells.

To gather the data into a logical format the CPICH Ec/No measurement can be split into classes in relation to the reported CPICH Ec/No value. These classes represent the measured quantity value area in dB. Table Classes for CPICH Ec/No coverage mea-surements below shows how the classes are linked with the reported CPICH Ec/No values.

When the RNC receives the 1A report from the UE, a classification counter correspond-ing to the reported CPICH Ec/No value is updated.

Classes condition Measured quantity value area (dB)

Condition (reported CPICH Ec/No value)

Class 9 CPICH Ec/Io < -24 CPICH_Ec/No _value = 0

Class 8 -24 ≤ CPICH Ec/Io < -22 1 ≤ CPICH_Ec/No _value < 5








Class 0 -5 ≤ CPICH Ec/Io 39 ≤ CPICH_Ec/No _value ≤ 49

Table 18 Classes for CPICH Ec/No coverage measurements

164 DN0934844Issue 01


Id:0900d80580606394

3.31.1 Operator benefitsAfter the 3G network launch, the operator can tune the CPICH power to:

• increase the network capacity and coverage • control the interference

The capacity gain in an interference limited case can be approximately 5% or higher since all common channels are set up with respect to the CPICH power.








3.31.4 Interaction with other featuresThis feature has no interaction with other features.





DN0934844Issue 01

165


Id:0900d805806063a6

3.32 RAN1186: RNC450SummaryNew RNC450 with enhanced mechanics and new capacity steps is introduced. Total throughput in RAS05.1 release for RNC450 in DL+UL direction is 585 Mbps. In RAS06 RNC450 DL+UL throughput is increased to 639 Mbps.

Benefits for the operatorRNC with enhanced capacity is introduced. It supports the future evolution towards the gigabit capacity.

Functional descriptionRNC450 includes three different capacity steps with Iub throughput figures 150 Mbit/s, 300 Mbit/s and 450 Mbit/s as described in the figure below. The cabinet and the mechanics including the power distribution and cooling system are enhanced to support the future capacity increase towards the gigabit capacity.

The main capacity figures for the maximum 450 Mbit/s configuration are:

• Iub throughput: 450 Mbit/s • AMR capacity: 8000 Erl • AAL2UP connectivity: 3.594 Gbit/s

Operational aspects

166 DN0934844Issue 01


Id:0900d805806063ab

3.33 RAN1514: Number of Supported HS-DSCH Users in RNC196 and RNC450SummaryMore subscribers can be supported when fixed line type of services are provided with HSDPA.

Benefits for the operatorMore optimised RNC for case where HSDPA used as replacement for fixed line connec-tions.

Functional descriptionRAS05.1/RN2.2 implementation is such that certain number DMPG units (so called "HSDPA SW pools") can be used for HSDPA traffic processing NRT R99 data traffic is prioritized over HSDPA.

The number of supported active HSDPA users in each RNC196 and RNC450 configu-rations with different associated UL capacities in RAS05.1/RN2.2 are listed in table below.

When the HSDPA service is provided as replacement for fixed line/DSL service the user behavior is different compared to typical mobile user.

Users stay longer in HSDPA state with very low background traffic (like keep alive mes-saging, VPN etc.) during the time between the actual traffic bursts with higher peak rates. The average throughput per users is decreased and thus the number of users in RNC level can be increased.

New HSDPA configuration alternative is supported in RAS05.1ED / RN2.2 CD2. This can be used for fixed line type of users with low average throughputs when there are less R99 NRT data users in the network.

Implementation of this is such that all DMPG units in RNC can be used for HSDPA traffic processing. (so called "flat HSDPA SW pool")

Max RNC data throughput or max AMR capacity do not change. HSDPA traffic is prior-itized over NRT R99 traffic. Activity factor for the associated UL channels for HSDPA is dimensioned to be 69 % which means that more users that have low average throughput can be supported.

Originally supported HSDPA configuration is still supported in RAS05ED/RN2.2 CD2 as well. HSPA SW pool type can be configured by operator.

The number of supported HSDPA users in different RNC196 and RNC450 configura-tions with different UL capacities when new "flat SW pool" configurations is used are pre-sented in the table belo. "Flat SW pool" concept is not supported with RNC450/150 carrier/coverage optimized configurations.

Operational aspectsNew configuration paremeters values used for HSDPA activation.

Hardware requirementsCDSP-C required generally for HSDPA.

DN0934844Issue 01

167


Id:0900d805806063ae

3.34 RAN1036: RNC196 Capacity UpgradesSummaryTwo new capacity steps RNC196/300M and RNC196/450M are introduced.

Benefits for the operatorThe purpose of the 300 Mbit/s and 450Mbit/s capacity upgrades is to increase Iub capacity, for example, for HSDPA services. This upgrade can be done to 196Mbits/s RNC's (or from 300Mbit/s) to make installed base RNC's more suitable to increased Iub traffic.

Functional descriptionTwo new capacity steps are introduced to RNC196: RNC196/300M:

The capacity of RNC196/196M is increased to 300Mbit/s (Iub) by removing some units and replacing those with other functional units.

• NIP1 and FDU are removed. Optionally, one NIP1 can be left to the configuration. FDU, that is, the magneto-optical disk drive functionally is replaced by external USB memory stick supported with OMU. The external USB memory stick can be used for transferring data to or from the RNC. The OMU unit must be upgraded with new HW variant (CCP18-B) that supports the USB interface.

• Additional units for A2SU, ICSU, MXU, GTPU. • The number of STM-1 interfaces can be increased up to 24 protected interfaces. • HDS-A plug-in-unit unit is replaced by a new variant (HDS-B) that supports two hard

disk units in one card.

The minimum HW requirements that must be fulfilled in the RNC196/196M before the upgrade to RNC196/300M are described below. Separate unit upgrade packages are available in case the requirements are not met.

Functional unit Minimum HW level

The main capacity figures for RNC196/300M are:

• Iub throughput: 300 Mbit/s • AMR capacity: 6800 Erl • * AAL2UP connectivity: 1.3 Gbit/s with AL2S-B, 3.594 Gbit/s with AL2S-D

RNC196/450M:

RNC196/450M includes the same number of units as RNC196/300 but the minimum HW requirements for the units are different. The minimum HW requirements for

ICSU CCP10

GTPU CCP10

RRMU CCP10

RRSU CCP10

MXU MX622-D

DMCU CDSP-C

OMU CCP18-A

NEMU MCP18-B

168 DN0934844Issue 01


Id:0900d805806063ae

RNC196/450M are listed below. Separate unit upgrade packages are available in case the requirements are not met.

Functional unit Minimum HW level

The main capacity figures for RNC196/450M are:

• Iub throughput: 450 Mbit/s • AMR capacity: 8000 Erl • AAL2UP connectivity: 3.594 Gbit/s

Operational aspectsFirst the minimum HW requirements need to be fulfilled with separate unit upgrade packets. RNC196/300M upgrade includes the required extra units than are added to the configuration. Cabling changes are needed.

ICSU CCP18-A

GTPU CCP18-A

RRMU CCP18-A

RRSU CCP18-A

MXU MX622-D

DMCU CDSP-C

OMU CCP18-A

NEMU MCP18-B

A2SU AL2S-D

DN0934844Issue 01

169


Id:0900d805806063b1

3.35 RAN900: Flexi WCDMA BTSSummaryFlexi WCDMA BTS is a new truly modular, very compact and high capacity wide-area WCDMA BTS that can be used in various indoor and outdoor installation options (such as floor, wall, stand, pole, mast, cabinet, 19" rack) and site applications (mini, macro and feederless site solutions). This solution can also be used as multimode upgrade to the existing UltraSite EDGE BTS with WCDMA carriers.

Benefits for the operatorFlexi WCDMA BTS offers the following key benefits:

• Improved OPEX, electricity savings up to 60 % (Power Amplifier efficiency 30 %, higher RF and BB integration level)

• CAPEX savings (cost efficient flexible and expandable modular unit structure) • IMPEX savings, the installation time is 1/3 compared to cabinet-based 1st genera-

tion WCDMA BTS (modular architecture, same building blocks for Macro Indoor, Outdoor and Mini sites)

• Advanced site support features (more own equipment space and back up time) • Optimised antenna line (integrated mast head amplifier and antenna tilt control with

SW upgrade) • The architecture supports future features (Distributed BTS, Smart Antenna, MIMO) • IP-capable HW • Full HSDPA support, HSUPA support with SW upgrade

Functional descriptionFlexi WCDMA BTS consists of self-supporting BTS modules that are small and light enough for one person to carry to the site:

• Radio Module • System Module • Optional Power Supply Module with Battery back-up

Optional Outdoor and Indoor Cabinets with long term battery back-up is also available.

Flexi WCDMA BTS architecture and modules will provide 12-carrier capacity: up to six sectors or four carriers per sector configurations are available in later SW releases according to Nokia Siemens Networks RAN Roadmap. The output power min 20W and min 40W per carrier is available with Radio Module equiped with one or two 50W Power Amplifiers.

Dual Radio Module can support one or two sectors. For 1+1+1 (min 40W per carrier) or 2+2+2 (min 20W per carrier) configurations only one System Module and one Dual and one Single Radio Modules are required for a complete WCDMA BTS system.

Up to 1+1+1 @ 20 or 40W are supported in RAS05.1 release.

Up to 2+2+2 @ 20 or 40W are supported in RAS05.1 ED release.

With three Dual Radio Modules configurations up to 4+4+4 and 2+2+2+2+2+2 can be obtained and uneven configurations, such as 1+2+2, are available in later SW releases according to Nokia Siemens Networks RAN Roadmap.

The baseband capacity of the System Module can be added remotely with a SWlicense when needed.

170 DN0934844Issue 01


Id:0900d805806063b1

Flexi WCDMA BTS is based on the OBSAI (Open Base Station Architecture Initiative) architecture enabling the multiradio platform for future radio technologies.

DN0934844Issue 01

171


Id:0900d805806063b4

3.36 RAN999: Flexi WCDMA BTS 1700/2100Functional description1700/2100 MHz (UL/DL) is a new frequency variant of Flexi WCDMA BTS. Two new Radio modules are introduced:

• - FRIA, 1700/2100 MHz with two Power Amplifiers supporting one or two carrier layers

• - FRIB, 1700/2100 MHz with one Power Amplifier supporting one carrier layer

172 DN0934844Issue 01


Id:0900d805806063b8

3.37 RAN916: Flexi WCDMA BTS 900SummaryFlexi WCDMA BTS to support 900 MHz band with new RF modules

Functional descriptionFlexi WCDMA BTS 900 MHz RF Modules (HW& SW) and System Module SW support for 900 MHz band.

FRDA is Flexi WCDMA RF Module 900 MHz with 2 PA supporting one or two sectors.

FRDB is Flexi WCDMA RF Module 900 GHz with 1 PA supporting one sector.

This is band VIII in 3GPP spec rel-7:

• Uplink: 880 - 915 MHz • Downlink: 925 - 960 MHz

DN0934844Issue 01

173


Id:0900d805806063bd

3.38 RAN917: Flexi WCDMA BTS 850SummaryFlexi WCDMA BTS to support 850 MHz RF band with 850 MHz RF Module variants.

Functional descriptionNew 850 MHz units:

• FRCA - RF Module 850 MHz with 2 PA supporting one or two sectors. • FRCB - RF Module 850 MHz with 1 PA supporting one sector • This is band V in 3GPP rel-6 spec: • Uplink: 824 - 849MHz • Downlink: 869-894MHz

174 DN0934844Issue 01


Id:0900d805806063c0

3.39 RAN907 Antenna line supervisionFlexi WCDMA BTS has integrated Bias-Ts in the Radio module to control the antenna line condition by voltage standing wave ratio (VSWR) measurement. This integrated HW-based functionality is enabled by a specific SW licence.

Antenna line supervision is integrated to the RF module of Flexi WCDMA BTS. It measures the VSWR, that is, the reflected RF power of the BTS TX antenna branch.

Benefits for the operatorThe operator is able to monitor the TX antenna remotely.

SW requirement for other network element SWThe feature is available in the following or later software releases:

• NetAct release OSS4.1 CD set

BTS HW requirementThis feature has no special hardware requirements.

BTS parametersNo parameters are related to this feature.

DN0934844Issue 01

175


Id:0900d805806063c3

3.40 RAN1046 Feederless site solution for Flexi WCDMA BTSFlexi WCDMA feederless BTS site solution refers to a situation where the system module and RF modules are installed apart from each other. The distance between the modules varies from a few metres to up to 200 metres. A multimode optical cable connects the system module to the RF module.

The radio head (RH) is as close to the antenna as possible. The distance between the RH and the antenna is only a few meters. Thus, in practice the feederless site is a solution which does not require traditional thick feeder cables.

The licensed key is needed when the distance between the system module and the RF module is more than 2m.

Benefits for the operatorFeederless site solution for Flexi WCDMA BTS offers an alternative way to provide WDCMA BTS site solutions. Especially cost and performance degradation coming from installation of long feeder cables can be avoided.

Because the system module is placed closer to the transmission termination point, it is usually easier to access for the operator.


• RAS05.1

For more information on software compatibility, see Feature compatibility in WCDMA RAN Compatibility.



176 DN0934844Issue 01


Id:0900d805806063c6

3.41 RAN905 Flexi WCDMA BTS MHA supportFlexi WCDMA BTS has an integrated Bias-Ts in the Radio module to control the Masthead Amplifier (MHA) (for an example WMHC). This integrated HW is enabled by a specific SW licence.

The Bias-T is integrated to the RF module of Flexi WCDMA BTS. It feeds DC power to the MHA and controls the MHA DC power current consumption. If the current consump-tion is out of a specified window range, an alarm is generated.

Benefits for the operatorThe integrated Bias-T doesn’t require additional external hardware. The MHA faults are remotely monitored by triggering the alarm.


• RAS05.1



DN0934844Issue 01

177


Id:0900d805806063c9

3.42 RAN1093 HSDPA 16QAM SW licence supportThis feature enables SW licensing to the HSDPA 16QAM feature (RAN764).

This feature allows increasing the HSDPA air interface peak data rate from 1.8 Mbps (QPSK with 5 codes) to 3.6 Mbps with the use of higher order modulation (16QAM). The link adaptation algorithm in the BTS (MAC-hs) selects 16QAM when the channel quality is sufficient. This selection is done every 2 ms TTI along with choosing the number of codes and the coding rate.

Benefits for the operatorThis feature increases the average HSDPA cell throughput for the end user.


• RAS05.1



178 DN0934844Issue 01


Id:0900d805806063cc

3.43 RAN912: Licence Based BTS Channel CapacityFunctional descriptionIn Flexi WCDMA BTS HW channel capacity is integrated to Flexi WCDMA BTS System Module without any plug-in cards. The operator can dynamically enable as many channel elements as needed to Flexi WCDMA BTS site by downloading a Capacity SW Licence key file. Costly BTS site visits to install more HW channel plug-in cards are thus avoided.

DN0934844Issue 01

179


Id:0900d805806063cf

3.44 RAN943: Synchronising WCDMA RAN (Flexi WCDMA BTS)Functional descriptionFor proper operation, all RAN elements need to be synchronised to a common clock source. The synchronisation needs to be considered when the RAN network is planned so that a good quality clock is available everywhere in the RAN network.

The primary clock source for all RAN elements is the RNC. All BTSs are connected to the RNC, typically with transmission equipment in between. Even though the BTSs log-ically connect directly to the RNC, the actual network topology may differ a lot from the logical one. For complex topologies there may be several options in obtaining the syn-chronisation.

Each element basically synchronises its operation to one of its physical transmission line interfaces. This is the normal operating condition. If a connection is broken, the syn-chronisation is lost and the element starts using the next predefined source (another line interface). Ultimately, if all secondary sources fail, the element operates on its local clock, with typically poorer frequency accuracy. When required the RNC can be con-nected to external synchronisation source (e.g., GPS) via E1 interface.

The BTSs require a highly accurate, stable clock for the air interface. The basic refer-ence is typically still obtained via the transmission line interface, but the clock signal is first purified from jitter & wander.

180 DN0934844Issue 01


Id:0900d805806063d2

3.45 RAN1000: Baseband Extension for Flexi WCDMA BTSSummarySecond System Module (FSMB) in extension mode bring additional baseband process-ing power and capacity to BTS site to handle more different type of air interface services.

Functional descriptionSecond System Module is not equiped with transmission submodule. For using System Module as extension module will require Extension Kit (FSKA, i.e. cables and dummy transmission submodule)

DN0934844Issue 01

181


Id:0900d805806063d5

3.46 RAN1133: Configurable 3rd Party MHA Support for FlexiBTSSummaryThe customer can define the maximum power supply current limit for MHAs

Benefits for the operatorCAPEX and OPEX savings because the operator can use existing MHAs.

Functional descriptionThe alarm limit for the maximum value of the supply current consumption of MHAs can be set by an operator. FlexiBTS HW rel. 1 supports this feature.

The alarm limit values for the maximum current are:

• -120 to 775 mA in 5 mA steps (12 V power supply) • -Measurement accuracy: +/- 20 mA

182 DN0934844Issue 01


Id:0900d805806063d8

3.47 RAN1002 Flexi WCDMA BTS 40 W carrier power supportThe Flexi WCDMA BTS 40 W carrier power licence will activate full 40 W power to the Flexi WCDMA BTS Radio module.

This feature is distributed as an enhancement delivery (ED) on top of RAS05.1.


• Enhancement Delivery (ED) on top of RAS05.1. • NetAct release OSS4 CD1 set

The feature is available in the following or later software releases:

For software compatibility, see Feature compatibility in WCDMA RAN Compatibility.



For more information on the feature, see Nokia WCDMA RAS System Information Set, Rel. RAS05.1, System Documentation..

DN0934844Issue 01

183


Id:0900d805806063db

3.48 RAN1144 Flexi WCDMA BTS 8 W RF power limitationThis feature enables 8 W RF power operation with Flexi WCDMA BTS. The feature is distributed as an enhancement delivery (ED) on top of RAS05.1.

With this new feature, the operator can limit the Flexi BTS RF power to 8 W with the current 20/40 W RF module. Thus it is possible to limit the maximum allowed RF exposure from the BTS especially on micro sites. The RF exposure limits depend on the national or local legislation in each country.

The operator can select the 8 W mode in the commissioning phase of Flexi WCDMA BTS. The RF module will internally limit the output power to 8W with a control cycle of less than 1ms. The output power dynamic range will be reduced from 18 dB to 14 dB when the 8 W mode is selected.

Benefits for the operatorThe same Flexi WCDMA BTS HW variant can be used on macro and micro sites. Logis-tics and spare part costs will be lower.


• Enhancement Delivery (ED) on top of RAS05.1. • NetAct release OSS4 CD1 set

For software compatibility, see Feature compatibility in WCDMA RAN Compatibility.



For more information on the feature, see Nokia WCDMA RAS System Information Set, Rel. RAS05.1, System Documentation..

184 DN0934844Issue 01


Id:0900d805806063de

3.49 RAN1146: Flexi WCDMA BTS Horizontal Mounting Kit for GSM EDGE BTSSummaryMounting kit provides FlexiBTS modules (max 5 pcs) support for Ultrasite GSM EDGE in horizontal position.

Functional descriptionCustomer can "empty" low part of GSM EDGE BTS (6 TRX's rack) in the field and add kit into the cabinets which then gives room for FlexiBTS modules.

Same kit can be installed either to Indoor or Outdoor GSM EDGE BTS.

DN0934844Issue 01

185


Id:0900d805806063e1

3.50 RAN1145: Flexi WCDMA BTS RF Module with AC Input PowerSummaryOptional AC/DC module can be equipped to FlexiBTS 1-sector RF module in an empty place of second antenna filter.

Benefits for the operatorThe feature brings more integrated feederless site (RF head) solution compared to the existing one.

Functional descriptionAC/DC converter (FPAB) is installed inside the Single RF Module (FRGD).

Operator can use 100...240V (1-phase) nominal input AC voltage.

186 DN0934844Issue 01


Id:0900d805806063e4

3.51 RAN1001: Flexi WCDMA BTS Second Carrier SupportSummaryIn Next Generation WCDMA BTS, second RF carrier using the same radio module HW can be enabled by a SW Licence key.

Benefits for the operatorCAPEX and OPEX savings; because there's no need to add new HW at the site there's no need for a site visits either.

Functional descriptionIn Flexi WCDMA, the second RF carrier can be enabled by a SW Licence key. The Flexi WCDMA BTS 40 W RF module HW (=TX and Power Amplifier) has the capability to support either

• One RF carrier @ min. 20 W as default, or • (- One RF carrier @ min. 40 W with a separate SW Licence key feature, or) • Two carriers @ min. 20 W. Usage of the second RF carrier can be enabled remotely

by a SW Licence key without adding any new HW at the BTS site, thus no need for site visit.

DN0934844Issue 01

187


Id:0900d805806063e7

3.52 RAN1439: Distributed BTS SolutionSummaryThe Distributed Site Solution refers to site concept where the distance up to 15 km can be between the System Module and RF Modules. The single mode cables and single mode tranceivers need to be used to connect System Module to RF Module optically.

Benefits for the operatorThe operators are able to utilise new site solutions by using long optical cables between the Flexi Rf and System Modules.

Functional descriptionRf modules can be installed 15km (75us delay) from system module by utilising single mode lasers and optical cables.

When installing RF modules to same system module Rf modules should locate 3km from each others when RF modules are adjacent cells in network.

Hardware requirements:Flexi system module, Flexi Single RF Modules, Flexi Optical SFP A 1310nm 3G 15km singlemode (FOSA), SM cables

188 DN0934844Issue 01


Id:0900d805806063ea

3.53 RAN1469: Flexi Mounting ShieldsSummaryExtra vandal resistant minicabinets can be used to protect Flexi modules. There are two versions available , FMSA and FMSB. FMSA (6U)is meant for two Flexi modules and cables installed on pole, wall or floor. FSMB (18U) is meant for six Flexi modules and cables installed on the floor.

Benefits for the operatorProtecting RF modules in the site places against vandals.

Functional descriptionFMSA weight is 12kg (empty) and 600x350x600. FMSB weight is 20kg (empty) and 600x600x910. Flexi Plinth FMFA is required in both cases.

DN0934844Issue 01

189


Id:0900d805806063ee

3.54 RAN607: Connectivity Support for 512 BTSsFunctional descriptionThe connectivity capacity of a fully equipped RNC is increased from 384 to 512 BTSs. The maximum number of carriers is unchanged, that is, 1152.

In configuration steps from 1 to 5, the maximum number of BTSs is increased accord-ingly (configuration 1: 170 BTSs, configuration 2: 256 BTSs, configuration 3: 340 BTSs, configuration 4: 420 BTSs, configuration 5: 512 BTSs).

Operational aspectsMinimum HW requirement in the RNC: CCP10 in all ICSU units.

190 DN0934844Issue 01


Id:0900d805806063f1

3.55 RAN640: Star Configuration: 512 BTSsFunctional descriptionThe maximum number of BTS O&M connections in a star configuration is increased from 384 to 512. Hence, all BTSs under a particular RNC can be connected using the star topology. Also a tree model and a combination of the star and tree topologies can be used.

Operational aspectsMinimum HW requirement in RNC: CCP10 in OMU.

DN0934844Issue 01

191


Id:0900d80580608cac

3.56 BTS solution features

3.56.1 BTS Solution Features Overview

3.56.1.1 BTS solution features overview


RAN999: Flexi WCDMA BTS 1700/2100 RAS05.1

RAN946: T1 Interface for Flexi WCDMA BTS RAS05.1


RAS05.1


RAS05.1

RAN941: JT1 Interface for Flexi WCDMA BTS RAS05.1

RAN940: E1 Interface for Flexi WCDMA BTS RAS05.1

RAN939: Flexbus Interface for Flexi WCDMA BTS RAS05.1

RAN935: BTS AAL2 Multiplexing for Flexi WCDMA BTS RAS05.1

RAN912: Licence Based BTS Channel Capacity RAS05.1

RAN907: Antenna Line Supervision RAS05.1

RAN905: Flexi WCDMA BTS MHA Support RAS05.1

RAN900: Flexi WCDMA BTS RAS05.1

RAN1093: HSDPA 16QAM SW Licence Support RAS05.1


RAN1046: Feederless site solution for Flexi WCDMA RAS05.1

RAN1469: Flexi Mounting Shields RAS05.1

RAN942: SDH STM-1 Interface for Flexi WCDMA BTS RAS05.1 ED

RAN917: Flexi WCDMA BTS 850 RAS05.1 ED




RAS05.1 ED


RAS05.1 ED

RAN1144: Flexi WCDMA BTS 8 W RF power limitation RAS05.1 ED

RAN1133: Configurable MHA alarms for Flexi BTS RAS05.1 ED

RAN1002: Flexi WCDMA BTS 40 W Carrier Power Support

RAS05.1 ED

RAN1001: Flexi WCDMA BTS Second Carrier Support RAS05.1 ED

RAN1000: Baseband Extension for Flexi WCDMA BTS RAS05.1 ED

Table 20 BTS solution features for RAS05.1

192 DN0934844Issue 01


Id:0900d80580608cac

For information on RAS05.1 features, see Features Under Development (FUD) docu-mentation and Flexi WCDMA Base Station, Product Documentation.

3.56.1.2 Further informationFor feature descriptions, see Flexi WCDMA BTS Product and Release Documentation and HSDPA in BTS in WCDMA RAN System Documentation.

For more detailed information on parameters, counters and alarms, see Reference infor-mation in WCDMA RNC Product Documentation and WCDMA BTS Product Documen-tation for release WBTS3.2.

For listings of RAN1.5, RAN04, and RAS05 features, see BTS solution features overview in RAN04 and RAS05 BTS Solution Features.

RAN1439: Distributed BTS solution RAS05.1 ED


Table 20 BTS solution features for RAS05.1 (Cont.)

DN0934844Issue 01

193


Id:0900d805805f1a8f

3.57 Performance monitoring features

3.57.1 RAS05.1 performance monitoring features overview

3.57.1.1 Further informationFor feature activation instructions, see WCDMA RNC Product Documentation.

For parameters, counters and alarms per feature, see RAN1.5, RAN04 and RAS05 parameters, counters and alarms and RAS05.1 parameters, counters and alarms in Interdependencies of Performance Monitoring Features.



For information on the RAN1153: Complementary Counters in RAS05.1 feature, see the following documents:

• Measuring WCDMA RAN • WCDMA RAN Key Performance Indicators • RNC Counters - RNW Part in WCDMA RNC Product Documentation • Features Under Development (FUD)

For information on RAN04 and RAS05 features, see RAN04 and RAS05 Performance Monitoring Features.



RAS05.1

RAN956: BTS Channel Element Capacity Mea-suring

RAS05.1

RAN232: CPICH Ec/No Coverage Measure-ments and Optimisation

RAS05.1


RAS05.1

RAN1054: Downlink Packet Data Throughput for Subscriber and Equipment Trace

RAS05.1

RAN190: Radio Connection Performance Mea-surements for RLC TM and UM and Outer Loop Power Control

RAS05.1


RAS05.1 ED


RAS05.1


194 DN0934844Issue 01


Id:0900d805805f1a69

3.57.2 RAN189: Automatic Definition of Neighbouring Cells

3.57.2.1 Automatic Definition of Neighbouring Cells feature descriptionThe automatic definition of neighbouring cells consists of operational and basic radio network measurement aspects.

Operational aspectThe operational aspect means automatic updates and optimisation of adjacency lists from NMS.

Handover adjacency lists are initially defined with radio network planning based on geo-graphical locations and the estimated behaviour of the cells. However, this is not the optimal case; unnecessary cells may be included or necessary cells excluded. During the evolution of the network, new cells are also added and relevant parameters of the existing cells changed. In this case it becomes practical that adjacency lists can be updated automatically and the lists are optimised based on measurements without a laborious radio network planning process.

Basic radio network performance measurement aspectIn order to enable the network management system to optimise the cell neighbour lists, several counters are needed to be supplied by the RAN such as cell to cell handover statistics and cell to cell CPICH Ec/No difference measurements.

The new handover measurements for the automatic definition of neighbouring cells are:


However the new handover measurements can be activated and used as any other basic RAN performance measurements.


When optimising neigbours the NetAct Optimizer also uses CPICH Ec/No difference information between source and target cells. Optimizer retrieves this information directly from RNC. This information is planned to be available as basic counters in later releases.

Operator benefitsThis feature improves the network quality and reduces manual workload on network optimisation. Correct adjacency definitions are a basic assumption for further perfor-mance optimisation or traffic balancing.

The signalling load is reduced, and UE measurements and handovers take place faster when unnecessary cells are not listed. On the other hand, when all necessary cells are listed on neighbour cell lists, the call quality also improves and dropped calls are avoided.

ComplianceThe new RAN performance measurement counters are 3GPP TS 32.403 compliant.

DN0934844Issue 01

195


Id:0900d805805f1a69

Resource requirements




Operator requirementsThe NetAct support for this feature is optional and the operator needs to have the auto-matic adjacency optimisation module in order to be able to use this functionality. For more information, see the Optimiser 2.0 customer documentation.



Limitations and restrictionsThe provisioning of any changes in the cell neighbour lists must take place while the cells are operating under low traffic because the cells must be stopped from operation before the feature can be activated. Usually network planners are using some tech-niques to obligate all users in the those cells, where neighbour lists are to be modified, to handover to some other neighbouring cells because adjacency lists cannot be modified while the cell is operating. In order to avoid any capacity problems, it is prefer-able to make those changes while the traffic is low in that part of the network.

RNC OSS

RAN2.2 OSS4.1CD


196 DN0934844Issue 01


Id:0900d805805f1a63

3.57.2.2 Main functionality of Automatic Definition of Neighbouring Cells

Using Automatic Definition of Neighbouring CellsThis feature is used with the help of the NetAct optimiser optional feature (automatic adjacency optimisation). In the optimiser, there is a special work space, from which the user is able to launch the automatic definition of neighbouring cells. The UI enables the user to set all the needed parameters for completing the task. The most important parameters are described in Parameters. The optimiser uses the new RAN handover statistics (intra-frequency (1013 Autodef SHO), inter-frequency (1014 Autodef IFHO), inter-system (1015 Autodef ISHO) handover statistics) collected by the RAN, in order to measure the performance for adjacencies in the optimisation scope. On the RAN side this feature operates like any other feature in the RAN. Needed RAN performance mea-surements operate similarly as other RAN performance measurements. These are managed by using the RNC Element Manager GUI application in RAN05.1 or the NetAct Administration of Measurements application.

Activating Automatic Definition of Neighbouring Cells

RAN performance measurementsThe needed RAN performance measurements are activated with the RNC Element Manager GUI application in RAS05.1 or with the NetAct Administration of Measure-ments application.

NetActThis feature is part of the NetAct application software. To activate the feature a separate “NetAct optmiser automatic adjacency optimisation” licence has to be bought.

For more information, see the Optimiser 2.0 customer documentation.

Verifying Automatic Definition of Neighbouring CellsThe user can verify that:

1. the defined minimum and maximum number of adjacencies of all types defined in the UI do not exceed the available adjacencies´ IDs.

2. the tool is able to get the performance measurements.3. the created adjacencies are the strongest according to the selection criteria unless

one of the constraints is violated, then the priority of that constraint is taken into account.

4. the angles and distance thresholds are fully respected

For more information about the post conditions, see the NetAct optimiser documenta-tion.

The RAN performance measurement data is collected and stored in the PM databases and can be viewed with available PM tools.

Deactivating Automatic Definition of Neighbouring Cells

RAN performance measurementsThe RAN performance measurements are deactivated with RNC EM GUI and with NetAct.

DN0934844Issue 01

197


Id:0900d805805f1a63

NetActThis feature is part of the NetAct operating software, so no special action is needed to take the feature out of use.

Feature management

RAN performance measurementsFor more information on the monitored counters in measurements 1013 Autodef SHO, 1014 Autodef IFHO and 1015 Autodef ISHO, see RNC Counters for RAS05.1 trial.

NetActThe main input parameters and monitored counters are explained in Parameters. For more information, see the Optimiser 2.0 customer documentation.

ArchitectureTo be able to optimise the adjacencies with the NetAct optimiser, the following modules must be in place:

198 DN0934844Issue 01


Id:0900d805805f1a63

Figure 49 The essential interfaces and objects in the automatic definition of neigh-bouring cells

Capacity

RAN performance measurementsThis feature has no special capacity effects.

NetActIn the pool creation phase of the adjacency optimisation, all possible candidates are identified in the optimiser plan. After that the rotation phase starts. In each rotation portion of the candidate, adjacencies are provisioned to the network and then a round of collecting performance measurements starts. It is recommended that in each round, the number of rotated adjacencies does not exceed 10 adjacencies per cell. Assuming that the number of adjacencies per RNC is about 400, the number of rotated adjacencies might be about 4000 adjacencies.

Configurator

NetAct

RNC

Planning tool

Measurementreport

BTS

Radio

MS

Optimizer

Plan download/upload

Measurementreport

H0decision

H0decision

List

List

HCMeas. Man

RNW stats

NEMU

Start command+ params

Autotuned/initial lists H0statistics(XML)

NWI3(TCP/IP, Corba)

Meas. Man

CSV report

Initial lists

Reporter

PMfragment

FTP(TCP/IP, Corba)

NW3I IF(TCP/IP, Corba)

XML (TCP/IP)

Conf.DB

DN0934844Issue 01

199


Id:0900d805805f1a66

3.57.2.3 ParametersList of essential parameters needed for the automatic definition of neighbouring cells using the optimiser.

Parameter Description

Initialisation

HandoverType

Uiname (Measurement Based CheckBox common for ADJS and ADJG in Starting Dialog): ADJS checkbox: (adjacency type to be optimised)

DB: User options

Selection of the handover type to be opti-mised.

Range: intra-frequency/ inter-system

Default: intra-frequency

Pool

AdjacencyCreationLimitDistance (D) UI name (existing in common tab): Max Distance

Weight factor for the distance in the formula of the ADJ creation factor

Range: [0-20000]

Default: 10000

Dynrotation UI Names (UI: (3G meas tab): radionbuttons): Static, Dynamic. Group label: Rotation for ADJS and ADJG

Defines whether the rotation uses a dynamic or static rotation process.

Range: [YES, NO]

Default: NO

Rotations

MaxNeighborListSize (Existing in Common)

The maximum length of the neighbour cell list

Range: [1..31]

Default: 31

MinNumberOfRotatedCells

UI: (3G meas tab): Minimum Number of Rotated Cells ADJS

Defines the minimum number of pool can-didates to be tested during each rotation. In case the algorithm does not reach the minimum number of candidate cells, this is notified to the operator.

Range: [0..100]

Default: 0

MaxNumberOfRotatedCells

UI: (3G meas tab): Maximum Number of Rotated Cells ADJS

Defines the maximum number of pool can-didates to be tested during each rotation.

Range: [0..100]

Default: 8

Fitness evaluation

[EcnoLow, EcN0High]

UI: (3G meas tab): EcN0 Low, EcNO High

Low and high threshold for Ec/No metric

Range: -20..10

Default: [-1.5, 0]

Table 23 Essential parameters in autotuning algorithm

200 DN0934844Issue 01


Id:0900d805805f1a66

[HoSuccessLow, HoSuccessHigh]

Low and high threshold for HO success rate metric

Range: 0.00..1.00

Default: [0.75, 0.95]

[HoRatioLow, HoRatioHigh]

Low and high threshold for HO share metric

Range: 0.00..1.00

Default: [0.01, 0.1]

EcnoDifferenceThreshold

Threshold for Ec/No metric filtering

Range: -20..10

Default: -6

EcnoScalingRange

Scaling parameters for Ec/No metric

Range: -20..10

Default: [-6, 3]

HoSuccessScalingRange

Scaling parameters for HO success rate metric

Range: 0.0..1.0

Default: [0.5, 1.0]

HoRatioScalingRange

Scaling parameters for HO share metric

Range: 0.0..1.0

Default: [0.0, 0.2]

IntrafrequencyClass[XYZ]

Evaluation matrix: XYZ class where X, Y, Z=[Low,Med,High] referring to [Ec/No, HOshare, HOsuccess]

Range: 0..7 (0=mandatory)

Default:

ntraFrequencyClassXRanking

Scaled metrics to be used in the ranking cost function for adjacencies in class. X=1..7.

Default: Ec/No, HOratio, Hosuccess

Selection criteria

BasicListCumulativeHoRatioLimit

UI: (3G meas tab): Basic List Cumulative HO Ratio Threshold for ADJS: DB: ADCEOPTP_CUM_HO_RATIO_ADJS_TH

The cumulative %SHO threshold for the definition of the basic neighbour cell

Range: [0.10-0.99] percentage

Default: 0.95


Table 23 Essential parameters in autotuning algorithm (Cont.)

DN0934844Issue 01

201


Id:0900d805805f1a71

3.57.3 RAN956: BTS Channel Element Capacity Measuring

3.57.3.1 BTS Channel Element Capacity Measuring feature descriptionThe BTS channel element capacity measuring feature has the feature number RAN956.This feature is part of the WCDMA RAN measure solution (see Figure BTS channel element capacity measuring in WCDMA measure solution).




RNC



RNCElement Manager

Reportgeneration


PM:Measurement

activation

PM:DataTransfer


Core Network

lub

lub

added

taadded


UL: BLER ar

Options Close

Radio 1

NokiaNetAct

Reporter




BTS CECounters

202 DN0934844Issue 01


Id:0900d805805f1a71





Operator benefitsThe BTS channel element capacity measuring provides the operator the network level monitoring of the availability and utilisation of the BTS HW resources. This measure-ment also gives planning possibilities for the present and future needs of the BTS HW resources.

ComplianceThis feature has no references to the standards.





AMR 1

<=16 1

32 2

64 4

128 4

256 8

384 16





DN0934844Issue 01

203


Id:0900d805805f1a71




Interaction with other featuresThis feature interacts with the RAS05 feature: RAN21 Licence management for BTS.


204 DN0934844Issue 01


Id:0900d805805f1a6e

3.57.3.2 Main functionality of BTS Channel Element Capacity Measuring

Using BTS Channel Element Capacity MeasuringThe BTS channel element capacity measuring operates similarly as other network per-formance measurements. The BTS channel element capacity measuring calculation is added to the current cell resource measurement on the RNC side. On the BTS side the BTS channel element capacity measuring calculation is included in the new WBTS HW resource measurement. It is managed by using the RNC Element Manager GUI appli-cation in RAS05.1 or the NetAct Administration of Measurements application. The BTS channel element capacity measuring monitoring is also possible via BTS EM.

The measurement interval for the BTS channel element capacity measurement in the RNC is selectable. The selection can be done using the RNC EM GUI or NetAct. In the BTS the measurement interval is fixed to 1 hour.

Activating BTS Channel Element Capacity MeasuringThe measurement data transfer from BTS to RNC and NetAct is activated either by using the RNC EM GUI or the NetAct Administration of Measurements application. In the BTS the measuring is always active and results can be viewed with the BTS EM regardless of data transfer settings.

Verifying BTS Channel Element Capacity MeasuringWhen the feature works as planned, the measurement data is collected and stored in the PM databases and can be viewed with available PM tools.

Deactivating BTS Channel Element Capacity MeasuringThe measurement data transfer from the BTS to the RNC and NetAct is deactivated either by using the RNC EM GUI or the NetAct Administration of Measurements appli-cation. In the BTS the measuring is always active and results can be viewed with the BTS EM regardless of data transfer settings.

Feature managementThe related counters are described more in detail in WBTS Counters.

ArchitectureFor more information, see Section BTS Channel Element Capacity Measuring feature description.


DN0934844Issue 01

205


Id:0900d805805f1a79

3.57.4 RAN232: CPICH Ec/No Coverage Measurements and Optimisation

3.57.4.1 CPICH Ec/No Coverage Measurements and Optimisation feature descriptionThe CPICH Ec/No coverage measurements and optimisation feature has the feature number RAN232.



















206 DN0934844Issue 01


Id:0900d805805f1a79

Operator benefitsAfter the 3G network launch, the operator can tune the CPICH power to:















DN0934844Issue 01

207


Id:0900d805805f1a76

3.57.4.2 Main functionality of CPICH Ec/No Coverage Measurements and Optimisation

Using CPICH Ec/No Coverage Measurements and OptimisationThe CPICH Ec/No coverage measurements and optimisation calculation is added to the current soft handover measurement. Thus, the CPICH Ec/No coverage measurements and optimisation feature operates similarly as other network performance measure-ments. It is managed by using the RNC Element Manager GUI application in RAS05.1 or the NetAct Administration of Measurements application.

Activating CPICH Ec/No Coverage Measurements and OptimisationThe measurement is activated with the RNC EM GUI and/or NetAct.

Verifying CPICH Ec/No Coverage Measurements and OptimisationWhen the feature works as planned, the measurement data is collected and stored in the PM databases and can be viewed with available PM tools.

Deactivating CPICH Ec/No Coverage Measurements and Optimisa-tionThe measurement is deactivated with the RNC EM GUI or NetAct.

Feature managementFor more information on related counters, see RNC Counters for RAS05.1 trial.

ArchitectureFor more information, see CPICH Ec/No Coverage Measurements and Optimisation feature description.


208 DN0934844Issue 01


Id:0900d805805f1a7b

3.57.5 RAN1054: Downlink Packet Data Throughput for Subscriber and Equipment TraceFor information on RAN1054: Downlink Packet Data Throughput for Subscriber and Equipment Trace, see Subscriber and Equipment Trace Feature Description.

DN0934844Issue 01

209


Id:0900d805805f1a87

3.57.6 RAN190: Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power Control

3.57.6.1 Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power Control feature descriptionThe feature radio connection performance measurements for RLC TM and UM and outer loop power control has the feature number RAN190.







Operator benefitsThe RCPM OLPC and RCPM UEQ measurements extend the monitoring capabilities to measure the uplink and downlink performance of the radio connection between the BTS and the UE.






210 DN0934844Issue 01


Id:0900d805805f1a87




Interaction with other featuresThe UEQ measurement can be started only for RBs using UM-RLC or the transparent mode RLC. The RCPM RLC measurement is meant for AM-RLC connections.

Limitations and restrictionsWith radio connection performance measurements for RLC TM and UM and outer loop power control, the measurement interval should not be shorter than 60 minutes.


g NEMU (RNC):


g NetAct:







DN0934844Issue 01

211


Id:0900d805805f1a81

3.57.6.2 Main functionality of Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power Control

Using Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power ControlThe feature radio connection performance measurements for RLC TM and UM and outer loop power control is managed by using the RNC Element Manager GUI applica-tion.

Activating Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power ControlThis feature is part of the application software.

The RCPM includes the RCPM RLC, UEQ and OLPC measurements. The RCPM RLC measurement has been implemented already in RAS05.

The measurement is activated with the RNC EM GUI.

The following parameters need to be defined when starting the RCPM UEQ or RCPM OLPC measurement:

• the measurement schedule, including period start/stop times and intervals • the measured WCDMA cells • the radio connection type, including radio access bearer and radio bearer type • the handover mode selection to define how the calls in soft handover are measured

When starting the measurement, the user must use these parameters to define what types of calls are measured.

The feature radio connection performance measurements for RLC TM and UM and outer loop power control is managed by using the RNC Element Manager GUI applica-tion in RAS05.1. The measurement data is stored in the NEMU database and it is trans-ferred to NetAct.

Verifying Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power ControlWhen the feature works as planned, the measurement data is collected and stored in the PM databases and can be viewed with the available PM tools.

Deactivating Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power ControlThe measurements are deactivated and the measured objects can be changed with the RNC EM GUI.

Feature managementFor more information on related counters, see RNC Counters for RAS05.1 trial.

212 DN0934844Issue 01


Id:0900d805805f1a81

ArchitectureFore more information, see Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power Control feature description.

CapacityIn a large radio network it may be necessary to select only a subset of the available measured objects, or in a restricted network area, to reduce the amount of data pro-cessed in NEMU (RNC) and sent to NetAct. For more information, see Limitations and restrictions.

DN0934844Issue 01

213


Id:0900d805805f1a84

3.57.6.3 Connection type classificationThe connection type is classified hierarchically for the RCPM OLPC and RCPM UEQ measurement as described in the following tree presentations.

Figure 51 RCPM OLPC

Figure 52 RCPM UEQ

Signalling

Conversational

CS Voice

CS Transparent Data

Streaming

CS Non Transparent Data

PS RT Data

Interactive

PS NRT Data

Background

PS NRT Data

Conversational

CS Voice

CS Transparent Data

Streaming


214 DN0934844Issue 01


Id:0900d805805f1a89

3.57.7 RAN1163: Iu-PS Throughput Measurement for GTP Traffic

3.57.7.1 Iu-PS Throughput Measurement for GTP Traffic feature descriptionThe Iu-PS throughput measurement for GTP traffic feature has feature number RAN1163. This feature is a part of the WCDMA RAN measure solution (see Figure Iu-PS throughput measurement for GTP traffic in WCDMA measure solution).



RNC

lub

NokiaNetAct


lu-CS lu-PS


PM: Data Transfer


GTPU

Report generation

Reporter

RNCElement Manager




CS CoreNetwork

PS CoreNetwork


RNC levelCounters

Iub

DN0934844Issue 01

215


Id:0900d805805f1a89







Operator benefitsThe new measurement enables monitoring the Iu-PS resource usage and dimensioning the network resources based on the actual traffic volumes.

GTPU-1

GTPU-2

GTPU-n

Iu-PSPS core

RNC



216 DN0934844Issue 01


Id:0900d805805f1a89









Interaction with other featuresThis feature supports monitoring the RAS05.1 feature “Iu-PS IP Quality of Service Support (DiffServ in GTPU)”. This feature can be used also in the case the Iu-PS IP Quality of Service Support feature is not activated.

Limitations and restrictionsThere is a limitation related to measurement management, which is common to all trans-port and HW related measurements in RNC. These measurements can not be activated from NetAct, but they need to be activated separately for each RNC.


RAS05.1ED

RN2.2 ED

- - OSS4.1 CD set 2

- - - -


DN0934844Issue 01

217


Id:0900d805805f1a89

3.57.7.2 Main functionality of Iu-PS Throughput Measurement for GTP Traffic

Using the Iu-PS throughput measurement for GTP trafficThe Iu-PS throughput measurement is operated similarly as other transport and HW related performance measurements in RNC. It is managed by using the RNC Element Manager GUI application in RAS05.1 or alternatively using MML commands.

Activating the Iu-PS throughput measurement for GTP trafficThis feature is part of the application software. The measurement and the data transfer from RNC to NetAct is activated either by using NE Measurement Explorer application in the RNC Element Manager or using ZT2 MML command group. The measurement data can be viewed either locally using NE Measurement Explorer or with NetAct report-ing tools.

Verifying the Iu-PS throughput measurement for GTP trafficWhen the feature works as planned, the measurement data is collected and stored in the PM databases and can be viewed with available PM tools.

Deactivating the Iu-PS throughput measurement for GTP trafficThe measurement and the data transfer from RNC to NetAct is deactivated either by using NE Measurement Explorer application in the RNC Element Manager or using ZT2 MML command group.

Feature managementThe related counters are described more in detail in RNC Counters – Transport and HW part in WCDMA RNC Product Documentation.

ArchitectureFor more information, see Figure Iu-PS throughput measurement for GTP traffic in WCDMA measure solution.


218 DN0934844Issue 01


Id:0900d805805f1a8c

3.57.8 RAN1153: Complementary Counters in RAS05.1

3.57.8.1 IntroductionThe new counters provide improved monitoring for selected functionalities in RAN. The counters are complements for the monitoring of the already existing functionality in RAN. For monitoring of new features in RAS05.1, the new counters are found through the corresponding feature description.

Benefits for the operatorOPEX savings are gained because of the reduced NE troubleshooting time.

3.57.8.2 Functional description

The new counters for NRT RAB drops in Cell_PCH state:

• Interactive RAB drop in CELL_PCH • Background RAB drop in CELL_PCH

The new counters are provided by the UE specific PS function in the RNC.

The new counters are added to existing PM Measurement - Service Level - in the RNC.

The new counters for Reference Cell Changes. Counters to indicate that a cell is no longer a reference cell for a RRC or RAB:

• RRC • AMR, Conversational, Streaming, Interactive or Background (5 counters) • AMR 12.2, Conversational 64, Streaming 14.4, Streaming 57.6 (4 counters) • Streaming 16/64 (Maximum and Guaranteed) • Streaming 16/64 (Maximum) 8/32 (Guaranteed) • NRT 64/64, 64/128, 64/256, 64/384 (4 counters) • NRT 128/64, 128/128, 128/384 (3 counters) • NRT 384/384, 384/64 (2 counters)

Counters to indicate that a cell has become a reference cell for a RRC or RAB:



The new counters are added to the existing PM Measurement - Service Level - in the RNC.

The new counters for RRC and RAB holding times in reference cell:

• RRC • AMR, AMR 12.2 (2 counters)

DN0934844Issue 01

219


Id:0900d805805f1a8c

• Conversational, Conversational 64 (2 counters) • Streaming, Streaming 14.4, Streaming 57.6. (3 counters)



The new counters for Multi RAB drops:

• Multi RAB Active fails for AMR 12.2 + PS NRT (64/384, 128/384, 384/384) (3 coun-ters)

• Multi RAB Active fails for AMR 12.2 + 2 PS NRT (I/I, I/B, B/B) (3 counters) • Multi RAB Active fails for AMR 12.2 + 3 PS NRT • Multi RAB Active fails for AMR Multimode + PS NRT (64/384, 128/384, 384/384) (3

counters) • Multi RAB Active fails for AMR Multimode + 2 PS NRT (I/I, I/B, B/B) (3 counters) • Multi RAB Active fails for AMR Multimode + 3 PS NRT • Multi RAB Active fails for Conversational + PS NRT (64/384, 128/384, 384/384) (3

counters) • Multi RAB Active fails for Conversational + 2 PS NRT (I/I, I/B, B/B) (3 counters) • Multi RAB Active fails for Conversational + 3 PS NRT • Multi RAB Active fails for Streaming (Guaranteed equals Maximum bitrate) + PS

NRT (64/384, 128/384, 384/384) (3 counters) • Multi RAB Active fails for Streaming (Guaranteed less than Maximum bitrate) + PS

NRT (64/384, 128/384, 384/384) (3 counters) • Multi RAB Active fails for 2 PS NRT (I/I, I/B, B/B) (3 counters) • Multi RAB Active fails for 3 PS NRT



The new counters for Cell Availability:

• The cell is created in DB • The cell is created in DB but blocked by User • The cell is created in DB and in WO state

The new counters are provided by the Radio Network Database in the RNC.

The new counters are added to the existing PM Measurement - L3 Signaling at Iu - in the RNC.

The new counters for Iu Availability:

• Iu Availability (in 10 second samples) • Iu Unavailability (in seconds) • Iu interface - changes to WO state

The new counters are provided by the RANAP interface function in the RNC.


220 DN0934844Issue 01


Id:0900d805805f1a8c

The new counters for Iur Availability:

• Iur Availability (in 10 second samples) • Iur Unavailability (in seconds) • Iur interface - changes to WO state

The new counters are provided by the RNSAP interface function in the RNC.

The new counters are added to the existing PM Measurement - L3 Signaling at Iur - in the RNC.

With these counters the operator is able to monitor:

• The drops of NRT RABs in Cell-PCH state. The drop in CELL-PCH has no visibility to the user and therefore these counters can be used for RAN KPIs to achieve better visibility of RAB performance from the end user perspective.

• The reference cell changes behind RRC and RABs.The reference cell change (SHO related) has impact on RRC and RAB counters if they are used for a specific cell. By introducing these counters, the operator will have a possibility to monitor the RRC and RAB performance from one cell perspective.

• The Multi RAB Active Failures. • The Holding times of RRC and RABs for a reference cell.

The counters can be used to monitor how frequently a cell is the reference in com-parison to other cells.

• The availability of WCELLs and Iub interfaces, Iur interfaces, Iu interfaces.

3.57.8.3 System impact

Hardware requirementsThis feature does not require any new or additional HW.

Interdependencies between featuresThis feature has no related or interworking features.

Current implementationThe current Cell Availability counters are based on monitoring the Code Tree. Based on the availability of the Code Tree, the Resource Manager updates the related counters. Currently, these counters are used also for cell availability monitoring.

Software requirements

RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC

Release RAS05.1 RN2.2 - - - - OSS4.1 CD set 1

-

DN0934844Issue 01

221


Id:0900d805805f1a8c

Software sales information

Operational aspectsThis feature will be a part of the WCDMA RAN Measure Solution. RAN KPIs for NRT RAB performance and WCELL/Iu/Iur availability will be introduced or updated.

BSW/ASW RAS SW component

BSW RAN

222 DN0934844Issue 01


Id:0900d805805e5450

3.58 Transmission and transport features

3.58.1 RAS05.1 transmission and transport features overview

3.58.1.1 Further informationFor feature activation instructions, see WCDMA RNC Product Documentation.

For more detailed information on parameters, counters and alarms, see WCDMA Radio Network Configuration Parameters, Overview of WBTS Counters and Alarm Structure documents.

For information on RAN1.5, RAN04 and RAS05 features, see Section Transmission and transport features overview in RAN04 and RAS05 Transmission and Transport Fea-tures.


RAN165: IP Based Control Plane at Iu and Iur

RAS05.1

RAN324: Dynamic HSDPA Transport Scheduling

RAS05.1

RAN717: Iu-PS IP Quality of Service Support (DiffServ in GTPU)

RAS05.1

RAN935: BTS AAL2 Multiplexing for Flexi WCDMA BTS

RAS05.1

RAN939: Flexbus Interface for Flexi WCDMA BTS

RAS05.1

RAN940: E1 Interface for Flexi WCDMA BTS

RAS05.1

RAN941: JT1 Interface for Flexi WCDMA BTS

RAS05.1

RAN942: SDH STM-1 Interface for Flexi WCDMA BTS

RAS05.1


RAS05.1

RAN946: T1 Interface for Flexi WCDMA BTS

RAS05.1

RAN1020: Route Selection RAS05.1


RAN1086: AXC ATM interface oversub-scription

RAS05.1

Table 30 Transmission and transport features for RAS05.1

DN0934844Issue 01

223


Id:0900d805805e5428

3.58.2 RAN165: IP Based Control Plane at Iu and Iur

3.58.2.1 Feature descriptionThe IP-based control plane is introduced as an option to the ATM-based control plane transport architecture. It supports the evolution of the mobile core network towards an all-IP network.

This feature enables the use of IETF Signalling Transmission (SIGTRAN) protocols (M3UA and SCTP) in the RNC in order to transport the signalling protocols over IP trans-port networks.

The IP-based control plane is available at Iu-PS, Iu-CS, and Iur interfaces.

The feature requires IP over ATM transport and, therefore, is supported in ATM inter-faces. No other ATM layer is supported.

The following figure depicts the protocol stack for the three interfaces.

Figure 55 Protocol stack for the supported interfaces

For Iu-PS, IuCS and for Iur the protocol stack is according to the 3GPP IP transport option, with IP signalling stack.

Operator benefitsWith this feature, the operator is able to connect the RNC to other network elements, which already implement IP-based signalling.

ComplianceThis feature is compliant with the 3GPP and IETF standards for the control plane proto-cols.

ATM is the only data link protocol supported.


System requirementsThis feature requires ATM core network.

RANAP RNSAP

SCCP

M3UA

AAL5

lu-CS & lu-PS lur

SCTP

IPv4

ATM

Physical Layer

224 DN0934844Issue 01


Id:0900d805805e5428

Software requirementsThis feature sets the following requirements:



Operator requirementsThe operator has to configure the RNC with the IP-based signalling protocol stack during the integration phase.

Any other network element connected to the RNC through a signalling interface where this feature is activated should also support SIGTRAN and have a compatible configu-ration.

If the network element connected to the RNC does not support SIGTRAN over an ATM link, an appropriate interworking device should be used.

End-user requirementsNot applicable.

Interaction with other featuresNot applicable.

Limitations and restrictionsIP-based control plane is supported only over ATM interfaces.


Using IP-based control planeIf some or all of the network elements connected to the RNC through Iu and Iur inter-faces that use IP-based control plane, the feature can be activated for those interfaces. The other interfaces can be configured for ATM-based control plane.

In RNC implementation, the IP protocol is encapsulated over ATM. If the RNC is to be connected to other network elements, which do not support IP over ATM, a router should be used to convert IP over ATM into the appropriate network technology (such as Ether-net). Using a router is particularly required when connecting the RNC to the Nokia Combi-SGSN.

Configuration and management of this feature is done by using the MMI system and MML commands during the configuration of the signalling links at the RNC integration phase.

Prior to the configuration, it is required to perform the planning for ATM, IP, and the sig-nalling networks.

DN0934844Issue 01

225


Id:0900d805805e5428

Activating IP-based control planeNetwork planning will make the network parameters available for configuring the feature. The main steps, needed to take the feature into use, are given below.

The main steps needed to take the feature into use are given below.

To activate IP-based control plane:

1. Create the association sets and associations.2. Assign IP addresses to ATM interfaces and create routes.3. Create the signalling link.4. Create the signalling route.5. Activate the configuration.

Verifying IP-based control planeThe feature can be verified with the steps given below.

To verify IP-based control plane:

1. Interrogate the IP configuration.2. Interrogate the association states.3. Verify M3UA alarms status.

Deactivating IP-based control planeThe main steps needed to deactivate the feature are given below.

To deactivate IP-based control plane:

1. Remove the SSCP-level configuration.2. Remove the M3UA and SCTP -level configuration.3. Delete the IP signalling link.

Feature managementThe following parameter sets are needed for this feature:

• Association set parameters • SCTP association -level parameters

If the default values are not suitable, they can be modified by using MML commands.

Additionally, a set of alarms is available for verifying the status of the signalling.

ArchitectureThe following figure illustrates the architecture of this feature and the relations with other network elements.

226 DN0934844Issue 01


Id:0900d805805e5428

Figure 56 Architecture of IP-based control plane

CapacityNot applicable.

3.58.2.3 Network managementNot applicable.

RNC

ATM I/F

lur

ATMI/F

ATMI/F ATM I/Flu-CS

lu-PS

ATM I/F

Ethernet I/F

Ethernet I/F

IP over ATM

SGSN

MGW

ICSU

ICSU

ICSU

RNC

DN0934844Issue 01

227


Id:0900d805805e542b

3.58.3 RAN324: Dynamic HSDPA Transport Scheduling

3.58.3.1 Feature descriptionThe Dynamic High-speed Downlink Packet Access (HSDPA) Transport Scheduling feature introduces a dynamic flow control for HSDPA traffic between the ATM adapta-tion layer type 2 (AAL2) and Medium Access Control (MAC) layers in the RNC. It prevents packet loss in RNC AAL2 buffers and thus increases system performance and Quality of Service (QoS) for end users. In addition, the feature makes operating of the RNC easier from the transport point of view. The feature also increases Iub efficiency.

3GPP HSDPA flow control is not aware of the Iub capacity available for the HSDPA, and thus may request more data than there is capacity for in the Iub. This may cause the AAL2 queue to overflow, which causes RLC or TCP retransmissions. The HSDPA flow control is not used on Iur.

Dynamic HSDPA Transport Scheduling is an optional feature. If it is disabled, static rate control is used which is a basic functionality in the RNC. The functionality is described in section Static Rate Control for HSDPA Data.

In addition, it is possible to disable both dynamic scheduling and rate control. If both are disabled, there is no functionality controlling the HSDPA data transfer from the transport point of view. The parameter internal HSDPA flow control method defines the method used.

The feature is for both shared Virtual Channel Connection (VCC) and dedicated VCC transport solutions.

The figure HSDPA flow control architecture with shared VCC below depicts the archi-tecture:

Figure 57 HSDPA flow control architecture with shared VCC

When the dynamic HSDPA transport scheduling feature is turned on, each VCC that handles HSDPA user plane traffic in the downlink direction has its own flow control func-tionality. When flow control messages are sent, they are sent to all HSDPA data sending entities in the MAC layer that send data to the VCC in question.

An AAL2 buffer handled by the flow control mechanism contains one operator-configu-rable threshold (Low), which is shown in the following figure The thresholds of an AAL2

NRT DCH(PS Data)

RT DCH(Voice)HSDPA

Scheduler

RLCMAC

DMPG

AAL2 queues

Low priority High priority

A2SUVCC

Priorityscheduler

HSDPA AAL2flow control

228 DN0934844Issue 01


Id:0900d805805e542b

queue. There are also other dynamically adjustable thresholds that affect the flow control message sending by reducing and increasing the incoming rate to the buffer.

Figure 58 The thresholds of an AAL2 queue

The Low threshold is used to define how aggressively flow control functions.

• If the Low threshold is a relatively low value in respect to the AAL2 queue target delay, it can mean that the flow control restricts the data flow too much. This reduces the performance.

• If the Low threshold is set to a relatively high value in respect to the AAL2 queue target delay, it can mean that all the thresholds in the queue are close to each other. This makes the flow control functionality to operate as if it had only an ON/OFF mode. Additionally, the internal RNC load increases due to the growth of flow control messages.

The flow control functionality checks the service rates (throughputs) of both:

• the Dedicated Traffic Channel (DCH) queue (in shared VCC situation); • HSDPA queue in short intervals.

After a window of intervals, a new set of queue thresholds are calculated and taken into use to avoid exceeding the AAL2 queue target delay.

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

If a dedicated VCC for HSDPA is used, the threshold values are calculated differently, because the available bandwidth for the HSDPA is constant.

The dynamic HSDPA transport scheduling functionality is independent of the HSDPA flow control defined by the 3GPP. However, the RNC is able to provide interworking between these two flow controls for the best performance.

Operator benefitsThis feature enhances the HSDPA capacity management on Iub. This leads to a better QoS of HSDPA users and more optimised usage of the Iub transport resources.

Incoming rate

AAL2queue

Service rate

High

Low

LHigh

HLow

DN0934844Issue 01

229


Id:0900d805805e542b

ComplianceThe feature is 3GPP compliant.


System requirementsThis feature has no system requirements




Operator requirementsThe dynamic flow control for HSDPA is managed in the RNC with the parameters listed below. The parameters are stored in the radio network database. More information on parameters can be found in the parameter dictionary.

If the following parameter values are changed, it should be done when the user and traffic amount is low to minimize the disturbance to the HSDPA traffic. After the change, the counters of the AAL2 scheduling performance measurement should be checked very carefully that the outcome is what was wanted.

It should be noted that if the ‘Internal HSDPA flow control method‘–parameter is set to DYNAMIC, the ‘Shared HSDPA flow control allocation’ parameter value is not used for anything.




Parameter name: HSDPA flow control AAL2 queue low threshold for shared VCC

Abbreviated name: HSDPAflowControlLowThresholdSharedVCC

Description: The low threshold is an AAL2 buffer occupancy threshold in a shared VCC, which triggers sending the ‘full rate’ (that is, the max. allowed rate) flow control messages to the HSDPA data sending entities it is passed downward (that is, the buffer is getting emptier).

Parameter name: HSDPA flow control AAL2 queue target delay for shared VCC

Abbreviated name: HSDPAflowControlTargetDelaySharedVCC

230 DN0934844Issue 01


Id:0900d805805e542b

End-user requirementsThe feature has no end-user requirements.

Interaction with other featuresRoute Selection makes it possible to dedicate a VCC for HSDPA.

Limitations and restrictionsDynamic HSDPA Transport Scheduling is an optional feature. When it is enabled, the static rate control for HSDPA is disabled.


Using Dynamic HSDPA Transport SchedulingThe feature parameters are handled via the RNC RNW Object Browser GUI or via Nokia NetAct™. The new parameters of the feature are listed in Section Operator require-ments.

Activating Dynamic HSDPA Transport SchedulingThe license for the feature has to be purchased, and the internal HSDPA flow control method parameter must be given the value DYNAMIC.

Verifying Dynamic HSDPA Transport SchedulingThe feature must be enabled and turned on. After this, a HSDPA call needs to be made, and new counters are updated (for example, measuring AAL2 delay).

Deactivating Dynamic HSDPA Transport SchedulingThe parameter internal HSDPA flow control method needs to be given the value STATIC or NONE.

Description: Defines the maximum allowed delay caused by AAL2 queueing in a shared VCC.

Parameter name: HSDPA flow control AAL2 queue low threshold for dedicated VCC

Abbreviated name: HSDPAflowControlLowThresholdDedicatedVCC

Description: The low threshold is an AAL2 buffer occupancy threshold in a dedicated VCC, which triggers sending the ‘full rate’ (that is, the max. allowed rate) flow control messages to the HSDPA data sending entities when it is passed downward (that is, the buffer is getting emptier).

Parameter name: HSDPA flow control AAL2 queue target delay for dedicated VCC

Abbreviated name: HSDPAflowControlTargetDelayDedicatedVCC

Description: Defines the maximum allowed delay caused by AAL2 queueing in a dedi-cated VCC.

DN0934844Issue 01

231


Id:0900d805805e542b

Feature managementParameters related to the feature are displayed in Sections Operator requirements and Resource requirements. There are no special alarms related to this feature.

There are new performance counters available for monitoring the performance and opti-mising the parameters for the feature. These counters are grouped into a new measure-ment: AAL2 scheduling performance in RNC. The measurement object is the ATM VC connection termination point in the RNC A2SU unit. Measured connections are identi-fied with the RNC-external interface ID / VPI / VCI values.

The AAL2 scheduling performance is measured for HSDPA traffic only (i.e. low priority queue). In the case of congestion the low priority queue length increases and the Iub delay for HSDPA traffic increases. If there is no HSDPA functionality activated in the network, the counters will not be updated. Therefore, the counters are updated only for Iub interface AAL2 connections.

The counters can be used to monitor the following issues:.

Measuring the AAL2 queue service rate in DL:

• Average number of sent AAL2 CPS packets (HSDPA queue) • Peak value of sent AAL2 CPS packets (HSDPA queue)

The service rate is sampled constantly (once per second) and the average values can be calculated as an average of all sampled values. The counters are not updated if there is no traffic during the sampling period. Peak value is the highest of the sampled values during the measurement period.

Measuring the estimated AAL2 layer buffering delay:

• Average AAL2 layer buffering delay (HSDPA queue) • Peak value of the delay caused by AAL2 layer buffering (HSDPA queue)

The delay is sampled constantly (once per second) and average delay values can be calculated as an average of all sampled values. Peak value is the highest of the sampled values during the measurement period. The counters are not updated if there is no traffic during the sampling period. These counters can be used to follow the long term trend of buffering delay and as a measure of Iub load in downlink.

Measuring HSDPA flow control performance:

• Number of “slow down” flow control messages sent to the MAC layer • Number of “speed up” flow control messages sent to the MAC layer • Number of 'full stop' flow control messages sent to the MAC layer

These counters indicate the flow control mechanism activity.

Measuring AAL2 traffic loss due to congestion:

• Number of events when AAL2 CPS packets were dropped from the AAL2 buffer due to too high a delay or buffer overflow (HSDPA queue). These counters indicate if there is traffic loss in RNC due to Iub congestion (i.e. all traffic sent from MAC layer has not fit in to the ATM VCC).

ArchitectureThe feature architecture is explained in Section Feature description.

232 DN0934844Issue 01


Id:0900d805805e542b

CapacityThe feature prevents packet loss in RNC AAL2 buffers and thus increases system per-formance and the end-users’ QoS.

3.58.3.3 Network managementDynamic HSDPA Transport Scheduling is an internal feature in the RNC and thus does not have any effects on the network management.

PlanThe feature has no effects on network planning.

IntegrateThe feature has no effects on network integration.


3.58.3.4 Static rate control for the HSDPA dataStatic Rate Control for HSDPA Data is the applied functionality if Dynamic HSDPA Transport Scheduling is not enabled. The static rate control for HSDPA functionality limits the data amount, sent by a DMPG unit to a specific value. This quantity depends on the number of HSDPA users in the cell and on the allowed Iub bandwidth of a VCC to the cell in question. The value is called Maximum VCC HSDPA Bit rate per DMPG (MVHBD).

The MVHBD value is calculated with the following formula shown in the Figure The cal-culation of MVHBD value:

Figure 59 The calculation of MVHBD value

In the formula above, SHFCA is the shared HSDPA flow control allocation parameter.

This functionality is needed because a major difference between Iub capacity and DMPG throughput might cause AAL2 queues to overflow.

For example, if there is one VCC carrying HSDPA traffic and there are three HSDPA users in a cell and they are all in different DMPGs, each DMPG is allowed to send an amount of MVHBD value which is one-third of the bandwidth indicated by the SHFCA. If all three HSDPA users are located in the same DMPG, the DMPG is equal to the SHFCA, and thus, the DMPG is allowed to send the worth of the SHFCA. The MVHBD is updated and signalled after every HSDPA connection setup and release in a cell to the DMPGs which are sending data to it.

If there are more that one VCCs for HSDPA traffic on the route, the SHFCA value is divided with the number of VCCs.

This applies both to shared and dedicated VCC solutions.

MVHBD =Number of VCC HSDPA users in a DMPG

Total ammount of HSDPA users in a VCCx SHFCA

DN0934844Issue 01

233


Id:0900d805805e542b

Operator requirementsStatic rate control for HSDPA is managed in the RNC with the parameters listed below. The parameters are stored in the radio network database. More information about parameters can be found in the parameter dictionary.

If the ‘Internal HSDPA flow control method’ is set to STATIC and the route has more than one VCC carrying the HSDPA traffic, the parameter ‘Shared HSDPA AAL2 VCC Selection Method’ parameter should be set to value 1. That is, divide the Shared HSDPA AAL2 allocation to all VCCs because the Shared HSDPA Flow Control Allocation is divided also and thus the Iub bandwidth is used more efficiently.

Main functionality

Activating Static rate control for the HSDP dataThe internal HSDPA flow control method parameter has to be given the value STATIC.

Verifying static rate control for HSDPA dataA HSDPA call needs to be made, and PM counters are updated.

Deactivating static rate control for HSDPA dataThe parameter internal HSDPA flow control method needs to be given the value DYNAMIC or NONE.

Feature managementWith this functionality, no new performance counters are available. The AAL2 schedul-ing performance in RNC measurement can be used to monitor the possible Iub conges-tion that is visible through increased delays and AAL2 CPS packet dropping. However, not all counters are updated, since the Dynamic HSDPA Transport Scheduling feature is not activated




Parameter name: Shared HSDPA flow control allocation

Abbreviated name: SharedHSDPAFlowControlAllocation

Description: This ATM protocol level parameter defines the maximum amount of HSDPA traffic which the RNC is allowed to send to a VCC on Iub. This parameter is WBTS specific. Although the max value in the range is 14.4 Mbps, the value of this parameter must not be set to be bigger than the Iub capacity between the BTS and the RNC. If the value is modified online, it is taken into use next time the shared HSDPA allocation is set up on the BTS

234 DN0934844Issue 01


Id:0900d805805e542b

ArchitectureThe feature architecture and functionality are explained at the beginning of Section Static rate control for the HSDPA data.

CapacityThis functionality prevents packet loss in RNC AAL2 buffers and thus increases system performance and the end-users’ QoS when compared to a situation where there is no control for HSDPA data at all.

3.58.3.5 Network managementThis is an internal functionality in the RNC and thus does not have any effects on the network management.

DN0934844Issue 01

235


Id:0900d805805e542e

3.58.4 RAN717: Iu-PS IP Quality of Service Support (DiffServ in GTPU)

3.58.4.1 Feature descriptionThe Iu-PS IP Quality of Service Support (DiffServ in GTPU) solution enables the differ-entiation of ingress traffic and the prioritisation of one traffic class over the other. This prevents small real-time packets from being delayed by large non-real time packets.

The prioritisation is independent for each available GTPU.

With this feature, the Differentiated Services Code Point (DSCP) of the packet is used to classify the traffic into two traffic classes:

• Real Time (RT) • Non-Real Time (NRT)

An example of this type of mapping is presented in Table DSCP to traffic class mapping.

The priority of the two traffic classes will be defined by using the RT/NRT ratio parame-ter. It determines the number of RT packets that are processed before one single NRT packet is processed.

If there are no packets of one class, packets of the other class will be processed.

The count of the number of processed RT packets will be reset in the following cases:

• one NRT packet is processed, and/or • the maximum value of the count (RT/NRT ratio) is reached.

When the total rate of the received NRT and RT packets is higher than the GTPU pro-cessing capacity, congestion will occur for both traffic classes. Incoming packets will be lost, regardless of the traffic class.

Operator benefitsThis solution allows more flexible Iu-PS connections and GTPU capacity usage for dif-ferent traffic combinations and enables more efficient packet data handling in the RNC. With this feature, NRT and RT traffic can be handled by the same GTPU and NRT traffic delay is also reduced.

The feature also enables the end-to-end deployment of DiffServ in the Iu-PS interface in the downlink direction.

DSCP Traffic Class

101110 RT

001010, 001100, 001110 RT

010010, 010100 010110 NRT

011010, 011100, 011110 NRT

100010, 100100, 100110 NRT

000000 NRT

Table 31 DSCP to traffic class mapping

236 DN0934844Issue 01


Id:0900d805805e542e

ComplianceThe feature is compliant with 3GPP and IETF standards.


System requirementsNone.



Hardware requirementsThe feature has no special hardware requirements.

Operator requirementsThis feature is optional, and therefore, a license is required.

The feature has to be activated for the whole RNC. If the default configuration is not suit-able, it should be changed. The changes in the configuration will affect all the GTPUs in the RNC.

If the feature is not activated, NRT and RT packets will be treated with the same priority.

The operator has to configure the following parameters with the Service Terminal Exten-sion:

• DSCP to Traffic Class mapping • RT/NRT ratio

The SGSN configuration should be consistent with the DSCP to Traffic Class mappings, that is, the RT and NRT packets should use the same DSCPs as in the RNC. Otherwise, the performance of the network might degrade.

End-user requirementsNone.

Interaction with other featuresNone.

Limitations and restrictionsThis feature is supported only for ingress traffic.


Using DiffServ in GTPUThe feature is configured in OMU at the network element level by using the Service Terminal Extension. Therefore, the configuration affects all the GTPUs.

DN0934844Issue 01

237


Id:0900d805805e542e

The RT traffic class must be defined for each DSCP allocated to that class. Otherwise, the DSCP is allocated to the default NRT traffic class.

The RT/NRT ratio must also be defined. The default ratio is 0.

The configuration can be changed during the operation of the Iu-PS interface without losing traffic.

Activating Iu-PS IP Quality of Service Support (DiffServ in GTPU) The feature has to be activated for the whole network element by using the Service Terminal Extension before it can be used by any GTPU.

The feature is activated when the RT/NRT ratio is other than 0. As long as the RT/NRT ratio remains 0, the feature will not be active.

Verifying DiffServ in GTPUThe DiffServ configuration can be verified by using the Service Terminal Extension con-nected to OMU.

The following information is printed out:

• Traffic Class for each DSCP • RT/NRT ratio

Deactivating DiffServ in GTPUThe feature can be deactivated for the whole network element by using the Service Terminal Extension connected to OMU.

The feature is deactivated when the RT/NRT ratio is equal to 0.

Feature managementNot applicable

ArchitectureThe following figure illustrates the architecture of the feature.

238 DN0934844Issue 01


Id:0900d805805e542e

Figure 60 Architecture of lu-PS IP Quality of Service Support (DiffServ of GTPU)

CapacityNot applicable.

3.58.4.3 Network managementNot applicable.

Unclassifiedpackets

Classified packetsbased on DSCP

GTPU

TCP/UDP/IP

rt1 rt2nrt1 nrt2

rt1 rt2 nrt1 nrt2

RNC upper layers

DSCP toTraffic classmappings

RT/NRTratio

ParameterDatabase

RNC

Iu-PS interface rt nrt

DSCP marking

SGSN

DN0934844Issue 01

239


Id:0900d805805e5431

3.58.5 RAN935: BTS AAL2 Multiplexing for Flexi WCDMA BTS

3.58.5.1 Feature descriptionBTS AAL2 Multiplexing enables statistical multiplexing gain at AAL2 layer. In addition this feature allows simpler network configuration with a reduced number of AAL2-VCCs.

AAL2 Multiplexing is inherent to the Next Generation WCDMA BTS architecture and therefore available from the first FTM release onwards.

240 DN0934844Issue 01


Id:0900d805805e5434

3.58.6 RAN939: Flexbus Interface for Flexi WCDMA BTS

3.58.6.1 Feature descriptionEach Flexbus interface enables a single-cable connection between the BTS and Flexi-Hopper/MetroHopper microwave radio outdoor units. No external transmission equip-ment is needed.

The coaxial Flexbus cable carries user plane data and O&M traffic, and also supplies power (30W) to the radio outdoor unit. The user plane capacity is 16x2M. ATM is mapped into E1, with support of IMA. In addition TDM cross connections are supported at 2M level.

Figure 61 Flexbus Interface for Flexi WCDMA BTS

DN0934844Issue 01

241


Id:0900d805805e5437

3.58.7 RAN940: E1 Interface for Flexi WCDMA BTS

3.58.7.1 Feature descriptionFlexi WCDMA BTS supports standard compliant E1 (UNI) interfaces, both twisted pair (symmetrical, 120 Ohm) and coaxial (asymmetrical, 75 Ohm).


• FTPB, 8xE1/T1/JT1 (symmetrical, 120 Ohm) • FTEB, 8xE1 coaxial (asymmmetrical, 75 Ohm) • FTIA, 4xE1/T1/JT1 (symmetrical, 120 Ohm), 2xFast Ethernet, 1xGigabit Ethernet

(optional) • FTJA, 4xE1 coaxial (asymmetrical, 75 Ohm), 2xFast Ethernet, 1xGigabit Ethernet

(optional)


Figure 62 E1 Interface for Flexi WCDMA BTS

242 DN0934844Issue 01


Id:0900d805805e543a

3.58.8 RAN941: JT1 Interface for Flexi WCDMA BTS

3.58.8.1 Feature descriptionFlexi WCDMA BTS supports standard compliant JT1 (UNI) interfaces.



(optional)


Figure 63 JT1 Interface for Flexi WCDMA BTS

DN0934844Issue 01

243


Id:0900d805805e543d

3.58.9 RAN942: SDH STM-1 Interface for Flexi WCDMA BTS

3.58.9.1 Feature descriptionFTOA offers 1xSTM-1/VC-4 interface with a tailored throughput for a tail site.

Flexi WCDMA BTS supports standard compliant optical STM1 (VC4) interfaces.

Flexi WCDMA BTS transport sub-module FTOA supports one STM-1/VC-4 interface with a throughput that is limited to the equivalent of 16xE1. This capacity might be enhanced by additional software development effort in a later release if there is a need.

The same applies for Sonet support.

Figure 64 SDH STM-1 Interface for Flexi WCDMA BTS

3.58.9.2 Interdependencies between featuresThe FTOA transmission sub-module with STM-1/VC-4 interface needs to be installed to the Flexi WCDMA BTS System Module.

3.58.9.3 Hardware requirementsFlexi WCDMA BTS Transmission sub-module FTOA

244 DN0934844Issue 01


Id:0900d805805e5440

3.58.10 RAN944: Use of GSM Transmission (Flexi WCDMA BTS)

3.58.10.1 Feature descriptionATM cells from WCDMA BTSs are carried in PDH/SDH layer time slots, frames or virtual containers. The GSM transmission network, based on either PDH or SDH, delivers the bandwidth the ATM layer needs. The WCDMA appears as a capacity increase.

Existing physical transmission media, microwave (MW), fibre, copper and leased lines, can all be used. WCDMA BTS sites integrate with existing GSM sites and a common access link can be shared to act as both Iub and Abis.

DN0934844Issue 01

245


Id:0900d805805e5443

3.58.11 RAN946: T1 Interface for Flexi WCDMA BTS

3.58.11.1 Feature descriptionFlexi WCDMA BTS supports standard compliant T1 (UNI) interfaces.



(optional)


Figure 65 T1 Interface for Flexi WCDMA BTS

246 DN0934844Issue 01


Id:0900d805805e5446

3.58.12 RAN1020: Route Selection

3.58.12.1 Feature descriptionIn the RAS05 release, only the shared VCC transport solution is supported on the Iub interface. This means that RT/NRT DCH traffic is carried in the same CBR VCC(s) as HSDPA traffic. The shared VCC solution is efficient from the Iub interface’s point of view, but it also has limitations. For example, it is not possible to treat traffic types differently to achieve overbooking for HSDPA traffic without disturbing other traffic types.

In the shared solution, DCH traffic has priority over HSDPA traffic, which means that HSDPA traffic is transported only if there is free capacity in the VCC. The HSDPA traffic is thus treated as best effort.

More flexibility has been requested in selecting VCCs for different bearer types. The Route Selection feature for the RAS05.1 release is the first step to this direction, because it enables a dedicated user plane downlink VCC for HSDPA and DCH traffic only. Route Selection is an optional feature and it can be enabled per BTS.

The Route Selection feature does not require the support of Q.2630.2 CS-2 signalling. It is 3GPP compliant.

The feature can be used in two modes; plain or enhanced, depending on how the VCCs are configured in a route from DCH traffic point of view. In plain mode, there are only dedicated VCCs on a route. In enhanced mode there are both dedicated and shared VCCs on a route. Both modes have benefits and drawbacks

Plain modeThe main idea of using the RouSel feature in plain mode is to enable the operator to dedicate a VCC for HSDPA traffic only. In a route to BTS there is VCC(s) for DCH traffic and VCC(s) for HSDPA traffic. The transport network can support the overbooking or statistical multiplexing of HSDPA traffic, which allows bandwidth savings in the transport network.

When considering Route Selection, the transport network needs to be divided into three sections. The local switch section consists of the RNC and the ingress side of the local ATM switch, the hub section consists of the egress side of the local switch to the egress of the last mile switch, and the BTS section is the last link to the AXC/BTS as shown in Figure Route selection network configuration. The BTS section is usually called ‘the last mile’, and it is considered to be the bottleneck of the transmission network.

DN0934844Issue 01

247


Id:0900d805805e5446

Figure 66 Route selection network configuration

Generally, the transmission networks are dimensioned so that packet loss is minimised. While this method ensures that the transmission network does not decrease the end user QoS, it may also lead to inefficiency in network dimensioning, if it is dimensioned according to the rush hour.

The Route Selection feature enables the usage of statistical multiplexing of the HSDPA traffic in the transmission network. With statistical multiplexing, there is always the pos-sibility of losing traffic, but with proper dimensioning, this can be minimised.

In Route Selection, the VCCs in the RNC need to be configured so that there are dedi-cated CBR VCCs for each BTS (one for DCH traffic and the other for HSDPA traffic). The dimensioning of the VCCs on downlink depends on the need. If both VCCs are set half (or close) to the last mile capacity, there won’t be traffic loss in last mile but downsize is that either traffic type can’t use the bandwidth fully. On the other hand if both VCCs are dimensioned equal (or close) to the last mile capacity, the HSDPA traffic can use the last mile capacity fully if there is no DCH traffic, and vice versa. But the problem with such overbooking is that RNC may send more traffic to network than the last mile can handle and thus the HSDPA traffic will be lost. Also the need of AAL2 connectivity is doubled.

As the HSDPA VCC is configured to be of the CBR type, it gives HSDPA traffic a priority over O&M traffic, which is typically configured to be of the UBR type.

In uplink direction the associated DCH is established on the DCH VCC. On a HSDPA VCC only the FP-level control messaging is sent uplink. For these reasons the dedicated VCCs are recommended to be asymmetric. HSDPA downlink should have more band-width than HSDPA uplink and for DCH VCC the uplink should have more bandwidth than the downlink. Asymmetric configuration is for two purposes: it saves AAL2 connectivity and it prevents the uplink becoming the bottleneck of the system. Only in the VP level bandwidth needs to be symmetric.

The hub section consists of third-party ATM switches and the network between them. Getting benefits of statistical multiplexing requires a certain topology of the transmission network. There must be the so-called ‘hub points’ in which the de-multiplexing of several BTSs is done. In addition, there should be enough BTSs behind the hub points to get bandwidth savings (roughly 20 BTSs or more). In the hub section, the local switch should perform a CBR-UBR conversion (or CBR-VBR conversion) for the incoming HSDPA VCCs, because multiplexing CBR VCCs does not have any benefits. If there are

ATMswitch

BTS

BTS

RNC

lu-ps to SGSN(incl. HSDPA)

lu-cs to MGW(voice)

DCH traffic

HSDPA traffic

ATMswitch

BTS

lub

248 DN0934844Issue 01


Id:0900d805805e5446

no hub points, that is, the network has the ‘form of a star’ in which the RNC is in the middle, there are no benefits in using statistical multiplexing. The Figure Network topology containing hub points shows a possible network topology where statistical mul-tiplexing could be used.

Figure 67 Network topology containing hub points

With hub points, multiplexing and some clever network planning (that is, the rush hour is not in every BTS at the same time), the VCCs can be dimensioned in a way that the sum of ingress HSDPA VCCs in the local switch is less than the sum of egress HSDPA VCCs, thus saving bandwidth.

Correspondingly, the local switch needs to perform an UBR-CBR conversion in the uplink VCC. The main issues in the local switch section are the VCC configuration in the RNC and the conversion of HSDPA VCC in the ATM switch. The Figure The CBR-UBR conversion of HSDPA VCC shows where the CBR-UBR conversion is needed. The con-version for HSDPA VCCs is needed for both uplink and downlink directions.

RNCBTS RNC

BTSSGSN

MSC

BTS

RNC BTS BTS BTS

BTSBTS BTS BTS

BTSBTS

BTSBTS

BTS BTS

BTS

BTS

BTS

BTS

BTS

BTS

= Potential Hub Points

Iur

Iu-cs

Iu-ps

Iub

Iur

DN0934844Issue 01

249


Id:0900d805805e5446

Figure 68 CBR-UBR conversion of HSDPA VCC

It should be noted that statistical multiplexing makes it possible to lose traffic in the trans-mission network during congestion, because the RNC may send more data than the network can handle. The best way to see the amount of lost data is in ATM switches in the network. The ATM switches need to have counters for, for example, lost cells due to congestion. With this PM information, the amount of overbooking can be adjusted. The RNC does not know what happens in the transmission network, but if data is lost there, it always causes a RLC retransmission, which can be an indication of a problem in the transmission network. The RLC PM data in the RNC cannot separate if the RLC is retransmitted due to poor radio conditions or lost cells in the transmission network. The amount of overbooking is the operator’s responsibility and cannot be affected by the RNC.

Route Selection differs also from the current shared VCC solution in the way that there is no need to perform shared HSDPA AAL2 allocation in the VCC to ensure the band-width for HSDPA traffic. The idea of shared HSDPA AAL2 allocation is to reserve some of the Iub capacity for HSDPA downlink traffic only to guarantee bandwidth, and thus QoS. In Route Selection, the capacity is ensured with its own CBR VCC.

One drawback of Route Selection is that it increases the need for AAL2 connectivity in the RNC if the dedicated VCCs are overbooked In some cases, the connectivity may become an issue if the RNC is limited in connectivity.

It is highly recommended to use AXU-B or AXU-C instead of AXU-A, because AXU-B and AXU-C have an AAL2 multiplexing functionality. With AAL2 multiplexing, there is less to configure in the RNC and AXCs, and also, there are bandwidth savings due to a less fragmented bandwidth. The Figures The AXC-A configuration with three HSDPA-capable WAM units and The AXU-B or AXU-C configuration with three HSDPA-capable WAM units depict the issue.

Hub Switch Local SwitchNodeB

NodeB

RNC

HSDPACBR VCCs

CBR

UBR

250 DN0934844Issue 01


Id:0900d805805e5446

Figure 69 Example of AXC-A configuration with three HSDPA-capable WAM units

Figure 70 Example of AXU-B or AXU-C configuration with three HSDPA-capable WAM units

There is additional reason to use AXU-B or AXU-C over AXU-A with Route Selection. If there is a failure in HSDPA capable WSP, the HSDPA functionality transfers to a new WSP.

If the new WSP is under different WAM the transport has to be preconfigured, that is, there has to be already a HSDPA VCC for continuation of the HSDPA service. If a HSDPA VCC cannot be dedicated for backup for all WAMs offering HSDPA it is recom-mended that all the HSDPA capable WSPs are configured under one WAM if the Route Selection is used with AXU-A unit.

AXC-ABT RNC

VPC

DCH

HSDPA

AAL2 Sig

WAMSector2

DCH

HSDPA

AAL2 Sig

WAMSector

DCH

HSDPA

AAL2 Sig

WAMSector

AXC-B

DCH

HSDPA

AAL2 Sig

BT RNC

AAL2MUX

VPC

WAMSector2

WAMSector

WAMSector

DN0934844Issue 01

251


Id:0900d805805e5446

Enhanced modeIn the enhanced mode there are dedicated VCC(s) and shared VCC(s) in the same route, that is, DCH VCC + SHARED VCC. The DCH traffic is primarily allocated in DCH VCC but in case of congestion (lack of bandwidth or lack of CIDs), SHARED VCC is used for DCH traffic. In SHARED VCC the DCH traffic has priority over HSDPA traffic.

One benefit of the enhanced mode is that if the DCH VCC is congested, the call is admitted instead of being rejected. Also, if DCH connection is about to be upgraded and there is not enough bandwidth in DCH VCC, the AAL2 connection is moved to SHARD VCC for the upgrade to succeed.

The drawback is that if the enhanced mode is used in same way as the plain mode, the CBR-UBR conversions in intermediate network endanger the QoS of DCH traffic in case of congestion.

Operator benefitsThe Route Selection feature with the use of ATM hub points allows the use of statistical multiplexing for HSDPA. As a result Iub capacity is saved in the intermediate ATM network between the BTS and RNC. In addition, using AXC-B or AXC-C instead of AXC-A increases savings.

ComplianceRoute Selection is 3GPP compliant.


System requirementsProper network topology is required, that is, there must be ‘hub points’ for getting the benefits of statistical multiplexing.

The third-party ATM switches need to be able to perform CBR-UBR and UBR-CBR con-versions and VC switching in the ATM network. In addition, the third-party switches need to be able to produce counters for dimensioning and trouble management purposes.


• RAS release: RAS05.1 • RNC release: RN2.2 • BTS release (Ultra): WBTS3.1 • Flexi BTS release WBTS3.2 • AXC: 2.7 • OSS: 4.1

Hardware requirementsNo hardware requirements.

Operator requirementsWhen the VCCs are created, the AAL2 UP Usage -parameter needs to be set. If the parameter valaue is set as HSDPA, the VCC is for HSDPA traffic only. If the parameter

252 DN0934844Issue 01


Id:0900d805805e5446

value is DCH, only DCH traffic is carried in it. If the value of ‘AAL2 UP Usage’ is SHARED, both HSDPA and DCH are carried in the VCC.

For a BTS, there has to be at least one VCC for DCH traffic. The VCC can be either DCH or SHARED type, because a shared VCC is also for DCH traffic. The HSDPA VCC is not mandatory.


Interaction with other features • Iub transport • BTS AAL2 Multiplexing • Dynamic HSDPA Transport Scheduling

Limitations and restrictionsWhen additional CBR VCCs are configured in the RNC, additional AAL2 connectivity is needed. A BTS needs to support two user plane VCCs in a WAM unit.


Using Route SelectionRoute Selection is an optional feature and thus the license must be purchased

To use Route Selection, some VCCs need to be configured to be HSDPA VCCs which are then used for HSDPA traffic only. If a VCC is configured to be shared, it is used for both DCH and HSDPA traffic. More information on the VCC configuring can be found in the RNW Administration document.

Activating Route SelectionRoute Selection is an optional feature and thus the license must be purchased.

In the RNC, the Iub VCC type need to be set when configured to HSDPA, DCH, or SHARED. The HSDPA tag means that the VCC is for HSDPA traffic only. Correspond-ingly, the DCH tag marks VCC for DCH traffic only. SHARED means that the VCC is for both HSDPA and DCH traffic.

In the AXC, the HSDPA VCC must be configured to a UBR VCC instead of a CBR VCC as in the RNC if the plain mode is used. In the AXC, the prioritising of the HSDPA UBR VCC is done by setting a higher Peak Cell Rate (PCR) parameter value to it than to other UBR VCCs, even though the PCR is not enforced. For more information on configuring the AXC, see Planning the AXC and Comissioning and Integrating the AXC in UltraSite WCDMA BTS documentation.

In the Flexi BTS, the HSDPA VCC needs to be UBR as in the AXC in plain mode. The priority for HSDPA VCC is given also by the PCR parameter. The higher the PCR value, the higher the VCC priority. In the Flexi BTS, the PCR is enforced. More information on configuring the Flexi BTS can be found in Flexi BTS product documentation.

DN0934844Issue 01

253


Id:0900d805805e5446

Selecting the ATM service category in enhanced mode is not straightforward. If the DCH traffic is admitted to SHARED VCC on regular basis, it is recommended to use CBR in last mile also.

Verifying Route SelectionWhen the system is configured, a test call can be made and the selected VCC can be verified in the PM data.

Deactivating Route SelectionThere is no single parameter which enables the feature in the RNC. The VCCs need to be configured in the RNC as SHARED, and the corresponding

Feature managementNo new Route Selection-related alarms, PM counters, or additional parameters.

CapacityThe need for AAL2 connectivity might increase, depending on the PCRs set to the VCCs.

3.58.12.3 Network management

PlanThe feature increases the number of VCCs and the amount of AAL2 connectivity needed, which needs to be taken into account when planning the RNC configuration. In addition, the amount of overbooking in the transport network needs to be considered carefully to get maximal benefits with minimal traffic loss.

IntegrateA BTS needs to support two user plane VCCs for a WAM unit.


254 DN0934844Issue 01


Id:0900d805805e544a

3.58.13 RAN1062: IMA (Flexi WCDMA BTS)

3.58.13.1 Feature descriptionIMA (Inverse Multiplexing for ATM) is supported for E1, T1, JT1 and Flexbus interfaces of Flexi WCDMA BTS

DN0934844Issue 01

255


Id:0900d805805e544d

3.58.14 RAN1086: AXC ATM interface oversubscription

3.58.14.1 Feature description Asynchronous Transfer Mode Cross Connection (AXC ATM) Interface Oversubscrip-tion provides the means to oversubscribe the physical bandwidth of an ATM interface in order to dimension the physical trunk transport capacity in Hub Node B / stand-alone AXC (S-AXC) , which has a smaller capacity than the aggregate of the transport capacity allocated to the Node Bs it is concentrating.

Figure 71 Network topology for AXC ATM interface oversubscription

Figure Network topology for AXC ATM interface oversubscription shows a typical network topology to take advantage of this feature: a Hub Node B’s AXC or a S-AXC aggregates the traffic from several Node Bs. Another Node B’s AXC or S-AXC in front of the Radio Network Controller (RNC) provides the original bandwidth allocations. Therefore RNC is not aware of the ATM interface oversubscription.

The AXC ATM Interface Oversubscription allows configuring the ATM bandwidth inde-pendent of the actual available physical bandwidth. Simply said, the physical bandwidth and the ATM interface bandwidth are controlled by two different network element func-tional layers:

• The physical layer function adapts the ATM traffic rate to the physical line rate. The physical layer inserts idle ATM cells if it does not receive any user ATM cells from the ATM layer.

• The ATM layer function performs Traffic management functionality e.g. Connection Admission Control (CAC) and performs the traffic scheduling among the ATM service categories and ATM connections.

A network element’s CAC usually reserves bandwidth for individual ATM connections to make sure that each ATM connection receives the required service quality.

ATM traffic scheduling regulates the ATM cell streams among different ATM connec-tions according to their ATM service categories and service requirements:

RadioNetwork

Controller

e.g. STM-1(155 Mbit/s)

AXC ATMinterface

bandwidthe.g. 3 Mbit/s

physical bandwidthe.g. E1/T1 (e.g. 2

Mbit/s)

S-AXCor Node B

S-AXCor Node B

physicalbandwidthe.g. E1/T1

(e.g. 2 Mbit/s)

Node B

Node B

Node B

VPC e.g.1 Mbit/s

256 DN0934844Issue 01


Id:0900d805805e544d

• If the actual ATM traffic stream associated with a particular ATM CBR connection is greater than the reserved bandwidth, the traffic scheduler buffers the ATM cells (and finally discards the ATM cells as soon as the buffer is occupied). This regulation is necessary to guarantee the quality of the service for the other CBR connections. If the actual ATM cell stream associated with a particular ATM CBR connection is smaller than the bandwidth that is not used, it cannot be used for the traffic of another CBR connection.

• ATM cells of Unspecified Bit Rate (UBR) connections are only sent if no ATM cell of a CBR connection is eligible for transfer.

A canonical ATM traffic management function aligns its traffic scheduling with the avail-able physical bandwidth in order to grant always the required quality of service espe-cially under high traffic load conditions. Implicitly, the canonical traffic management rejects to establish Constant Bit Rate (CBR) connections if the sum of the Peak Cell Rate (PCRs) is greater than the physical transmission bandwidth. If the actual traffic in a CBR connection is smaller than the reserved bandwidth, it cannot be used by the traffic of another CBR connection.

AXC ATM interface oversubscription allows you to apply the ATM traffic management functions with a less strict bandwidth reservation policy for the individual ATM connec-tions. It introduces an additional configuration for the bandwidth that the ATM traffic management takes into account: the ATM interface bandwidth.

The ATM interface bandwidth is set to a value greater than the physical bandwidth to oversubscribe.

All the AXC ATM traffic management functions will properly work until the actual traffic volume exceeds the physical bandwidth. This is typically the case because not all the Node Bs will generate their maximum traffic volume at the same time.

However, if the ATM interface oversubscription is in use and the actual ATM traffic exceeds the physical bandwidth:

1. AXC starts to buffer and finally discards ATM cells.2. First UBR connections are affected, but also CBR connections may suffer because

the reserved bandwidth is not guaranteed.3. AXC will then randomly discard ATM cells from the CBR connection.4. Therefore AXC provides counters (called utilizationZone%) to monitor the actual

traffic load on the physical interface. • The counters called utilizationZone%xx expresses how much time of fifteen-

minutes period the physical bandwidth is used (see Maintaining the AXC for more detailed information).

Operator benefitsWhen using NodeB or S-AXCs to aggregate traffic from Node Bs, operators allocate dedicated bandwidth for each Node B through the transport network. In practice, the aggregate bandwidth reservation is greater than the actual traffic volumes, because not all the Node Bs generate maximum traffic at the same time.

AXC ATM interface oversubscription provides the means to reduce the reserved trunk capacity and with it to reduce Operating Expenditure (OPEX) that is, the costs for leased line services.

DN0934844Issue 01

257


Id:0900d805805e544d

The AXC ATM interface oversubscription feature supports the operator's intention to smoothly oversubscribe the physical link capacity by reducing the safety margin provided by ATM Quality of Service means and by taking the risk of ATM cell discards.

ComplianceAXC ATM interface oversubscription is transparent to the Iub functionality and therefore, it is 3GPP compliant.


System requirementsThe recommended network topology requires either a Node B AXC or an S-AXC as a hub point to aggregate traffic from several Node Bs, and another S-AXC in front of the RNC. You can also use other third-party ATM equipment that offers similar oversub-scription features used at RNC site.


• AXC: 2.7 • OSS: 4.1 CD Set 1

Hardware requirementsThe feature does not have hardware requirements. It is applicable to all AXU variants.

Operator requirementsOperator shall not aggressively overbook the physical bandwidth to reduce the risk of traffic drops.

The operator shall monitor the ATM interface utilization with the provided ATM traffic load counters to proactively react on bandwidth bottlenecks.


Interaction with other featuresRoute Selection feature will complement the ATM interface oversubscription, because operators have then the option to oversubscribe dedicated traffic, for example, Rel99 real-time or non real-time traffic on a different interface than the HSDPA traffic.

Limitations and restrictionsThe maximum value for the ATM interface bandwidth is 3532970 cps (equal to 10*STM-1 bandwidth). The maximum Peak Cell Rate value for an ATM connection is 1412828 cps (equal to 4*STM-1 bandwidth).

258 DN0934844Issue 01


Id:0900d805805e544d


Using AXC ATM interface oversubscriptionAXC ATM interface overbooking is an optional feature and thus the corresponding license must be purchased.

Activating AXC ATM interface oversubscriptionIf you have obtained the required license, the AXC allows you to configure the ATM interface bandwidth above the available physical transmission bandwidth.

For more information on configuring the AXC, see Planning the AXC and Commission-ing and Integrating the AXC in UltraSite WCDMA BTS documentation.

The traffic monitoring counters are available without the AXC ATM interface oversub-scription license.

Verifying AXC ATM interface oversubscriptionWhen you have configured the system, you can make a test call to monitor the traffic volume.

Deactivating AXC ATM interface oversubscriptionThere is no particular parameter to disable AXC ATM interface oversubscription. The ATM interface bandwidth is set to the available physical transmission bandwidth.

Feature managementAXC introduces new counters to monitor the actual ATM traffic load of the ATM inter-face. The operator monitors the traffic load to pro-actively react on bandwidth bottle-necks.

CapacityAXC ATM interface oversubscription does not have any special capacity requirements.

3.58.14.3 Network management

PlanAXC ATM interface overbooking allows to configure the ATM interface bandwidth inde-pendently of the physical transmission bandwidth. The overbooking ratio of ATM inter-face bandwidth to physical transmission bandwidth needs carefully planning.

IntegrateNo specific rules apply.

Trouble managementIf the ATM interface utilization counters show a steady high traffic load then the physical interface bandwidth needs to be increased or the network topology has to be re-planned.

A steady high traffic load may cause ATM cells discard due to ATM buffer overflow. Accordingly, the end-to-end quality of service may suffer at radio layer.

DN0934844Issue 01

259


Id:0900d805805d88bb

3.59 Radio resource management and telecom features

3.59.1 Radio Resource Management and Telecom features overview

3.59.1.1 Radio Resource Management and Telecom features overview


See

RAN140: Load and Service Based IS/IF Handover


• Feature RAN140: Load and Service Based IS/IF Han-dover, Handover Control, Admission Control, and Packet Scheduler in WCDMA RNC Product Doc-umentation

RAN242: Flexible Upgrade of NRT DCH Data Rate


• Packet Scheduler, Radio resource management of HSDPA, Radio Resource Management , and RAN242 and RAN409: Flexible Upgrade of NRT DCH Data Rate and Throughput-based Optimisation of the Packet Scheduler Algorithm Feature Activation Manual in WCDMA RNC Product Doc-umentation

RAN409: Throughput-Based Optimisation of the Packet Scheduler Algorithm


• Packet Scheduler, Packet Data Transfer States, and RAN242 and RAN409: Flexible Upgrade of NRT DCH Data Rate and Throughput-based Optimisa-tion of the Packet Scheduler Algorithm Feature Activation Manual in WCDMA RNC Product Documentation

RAN146: Power Balanc-ing


• Feature RAN146: Power Bal-ancing, and Power Control in WCDMA RNC Product Doc-umentation

Table 32 Radio Resource Management and Telecom features

260 DN0934844Issue 01


Id:0900d805805d88bb

RAN830: AMR Codec Sets (12.2, 7.95, 5.90, 4.75) and (5.90, 4.75)


• Admission Control, and RAN830: AMR Codec Set with AMR Codec Selection Feature Activation Manual in WCDMA RNC Product Doc-umentation

RAN849: HSDPA Pro-portional Fair Resource Packet Scheduler


• HSDPA in BTS in WCDMA RNC Product Documentation

RAN1224: HSDPA Dynamic Power Alloca-tion


• HSDPA in BTS • Dimensioning WCDMA RAN

RAN839: HSDPA 16 Users per Cell


• HSDPA in BTS, Packet Scheduler, and RNC Product Description in WCDMA RNC Product Documentation

RAN1164: HSDPA Service Indicator


RAN829: HSDPA Soft/softer Handover for Associated DPCH


• Radio resource management of HSDPA, and Radio Resource Management in WCDMA RNC Product Doc-umentation

RAN828: HSDPA Serving Cell Change




See


DN0934844Issue 01

261


Id:0900d805805d88bb

RAN827: HSDPA with Simultaneous AMR Voice Call



RAN223: UE Based A-GPS Using External Reference Network


• Feature RAN223: UE Based A-GPS Using External Refer-ence Network, and RAN223: UE based A-GPS using external reference network Feature Description in WCDMA RNC Product Doc-umentation

RAN814: Intelligent Directed Emergency Call Inter-system Handover for US


• Features RAN384 and RAN814: Emergency and Intelligent Emergency Call Inter-System Handover, Feature Activation Manual in WCDMA RNC Product Doc-umentation

RAN134: Support for Tandem/Transcoder Free Operation


• Call setup and release, Feature RAN134: Support for Tandem/Transcoder Free Operation in WCDMA RNC Product Documentation

RAN1180: Wireless priority service


• Handover Control and Admission Control in WCDMA RNC Product Doc-umentation

RAN875: Network Based A-GPS Using External Reference Network


• RAN875: Network Based A-GPS Using External Refer-ence Network Feature Acti-vation Manual, and Call Setup and Release in WCDMA RNC Product Doc-umentation


See


262 DN0934844Issue 01


Id:0900d805805d88bb

3.59.1.2 Further informationFor feature descriptions, see Functional Area Descriptions in WCDMA RNC Product Documentation, and HSDPA in BTS in WCDMA RAN System Documentation.

For feature activation instructions, see WCDMA RNC Product Documentation.

For parameters, counters and alarms per feature, see Interdependencies of Telecom Features and Interdependencies of Radio Resource Management Features.


For information on software requirements, see Network compatibility matrix in WCDMA RAN Compatibility.

For listings of RAN1.5, RAN04 and RAS05 features, see Radio resource management features overview in RAN04 and RAS05 Radio Resource Management Features and Telecom features overview in RAN04 and RAS05 Telecom Features.

RAN815: Point-to-Point Iu-pc Interface


• WCDMA RAN Interfaces

RAN1195: Multi-band Support for RNC


RAN1184: Configurable Location Shapes


• WCDMA RAN Location Services


See


DN0934844Issue 01

263


Id:0900d8058061e9eb

3.59.2 RAN223: UE Based A-GPS Using External Reference NetworkUser Equipment UE Based Assisted Global Positioning System (A-GPS) Using External Reference Network RAN feature belongs to application software.

WCDMA RAS05.1 supports the UE based A-GPS positioning method. The UE based assisted GPS is a method to establish a GPS reference network whose receivers have an unobstructed view of the sky and can operate continuously. At the request of a user equipment or a network based application, the RAN collects the required GPS data from this reference network and generates the required assistance data elements for the UE. The assistance data from the reference network is transmitted to the UE to improve the GPS receiver performance. To be more specific, the assistance data speeds up the location calculation function within the UE, thereby reducing UE battery consumption.


3.59.2.1 Requirements





• There must be RRMU units on the RNC. • A stand-alone SMLC (SAS) or A-GPS server is needed for GPS assistance data. • Location services (LCS) A-GPS Site Solution related hardware for transmission is

needed between the RNC and the SAS/A-GPS server. • A-GPS hardware is required in the UE.

End-user equipmentThe UE must support the A-GPS feature. In practice, the UE must be equipped with a GPS receiver. Furthermore, the UE must be able to receive assistance data from the network and calculate the GPS positioning.



264 DN0934844Issue 01


Id:0900d8058061e9eb


3.59.2.2 FunctionalityGPS positioning depends on accurate GPS time, navigation data containing satellite orbital parameters, and distance measurements. Should any of these three elements be missing, it would prevent the GPS based positioning. Unfortunately, this is often the case in urban areas due to poor satellite visibility. However, to recover positioning, the missing elements (except distance measurements) can be delivered through the cellular network. The cellular network can be equipped with a reference GPS receiver located in a place having an unobstructed view to the sky. Using the reference receiver, the network can receive navigation data, exact time, and so on, and relay this data over the cellular air interface to the user equipment.


However, if the requested location accuracy cannot be fulfilled with cell-based location methods and the UE is GPS-capable, an A-GPS location method is initiated. The RNC itegrated SMLC function collects GPS assistance data from an A-GPS server or from SAS and sends the data with a location request (by using the RRC: Measurement Control message) to the UE. The UE uses the network provided assistance data and its GPS receiver to locate itself, and sends its coordinates to the RNC. The RNC vali-dates the UE positioning results, and returns the positioning responce to the core network.

ArchitectureThe network architecture and its elements for the A-GPS positioning method are shown in figure UE-based A-GPS positioning method - signalling flow for mobile-terminated (MT) location request (LR).

DN0934844Issue 01

265


Id:0900d8058061e9eb

Figure 72 UE based A-GPS positioning method

The WCDMA RAN A-GPS solution includes an RNC integrated SMLC and an interface to the SAS or A-GPS server. This interface can be a 3GPP standard Iu-PC interface, or a proprietary binary interface (ADIF) to the external GPS reference network. The SAS/A-GPS Server depending on the operator's SAS/A-GPS Server vendor selection tracks all GPS satellites and is the responsibility of the SAS/A-GPS Server vendor.

AccuracyThe A-GPS positioning method improves the standard GPS accuracy by increasing its coverage; navigation messages are obtained through the UMTS terrestrial radio access network (UTRAN), which allows the GPS to operate in situations where the GPS data is disturbed (for example some indoor environments).


AGPS data interface (ADIF) A proprietary binary interface used for communication between the RNC Integrated SMLC and a A-GPS Server within RAN. The external GPS reference network tracks all GPS satellites. This interface passes the requested GPS assistance data to the UE through RAN.



Iupc interface The Iupc interface is used for communication between the RNC inte-grate SMLC and a stand-alone SMLC (SAS) within the RAN. This 3GPP


A-GPSdata Server

or SAS

UE

BTS

Assistance data RNC

X, Y, Z

N 61'26"47.75E 23'51"45.02

186.2m

266 DN0934844Issue 01


Id:0900d8058061e9eb

standard interface passes the requested GPS assistance data to the UE through the RAN.


DN0934844Issue 01

267


Id:0900d8058061ea23

3.59.3 RAN384 and 814: Emergency and Intelligent Emergency Call Inter-system Handover

3.59.3.1 DescriptionEmergency Call Inter-system Handover (EMISHO) and intelligent Emergency Call Inter-system Handover (iEMISHO) features belong to the application software. The iEMISHO feature offers enhancements to the EMISHO feature.

The premise of the EMISHO feature is when a Wideband Code Division Multiple Access WCDMA user makes an emergency call, the network recognises that it is an emergency call from the related locationing request, and begins the handover procedures to the GSM network. As a backup, the positioning of the user is initiated simultaneously in the WCDMA RAN. Once the call has been established in the GSM network, the GSM location technology computes a caller location estimate and the result is routed to the Public Safety Answering Point (PSAP). If the Inter-System Handover (ISHO) fails, the WCDMA network uses any or all of the available methods when trying to fulfill the requested Quality of Service (QoS).

In the intelligent EMISHO solution, the location is first computed in the WCDMA network using the CI+RTT locationing method. If the cell-based solution can fulfill the requested accuracy, the position coordinates are forwarded to the Core Network (CN) as a response. If the required location accuracy cannot be fulfilled with the CI+RTT, the solution will check the assisted GPS (A-GPS) capability in the UE and RAN, and compute an A-GPS location if it is supported. If A-GPS cannot be initiated, the solution checks if iEMISHO is enabled. If it is, an ISHO is initiated. If the ISHO fails, the CI+RTT location result is returned to the core network. If the A-GPS method can be initiated, emergency call ISHO is not initiated in any case. If the A-GPS calculation is successful, position coordinates calculated with A-GPS are returned to CN (regardless of achieved accuracy). If the A-GPS fails, the CI+RTT location result is returned to the core network.

The EMISHO call-flow is shown in Figure EMISHO call-flow and, respectively, the iEMISHO call flow is shown in Figure iEMISHO call-flow.

3.59.3.2 FunctionalityThe call flows and signalling scenarios with EMISHO and iEMISHO feature are described in the following chapters.

EMISHO FunctionalityWhen a user makes an emergency call within the WCDMA network, the call flows and signalling scenarios with EMISHO feature are depicted in the figures below:

268 DN0934844Issue 01


Id:0900d8058061ea23

Figure 73 EMISHO call flow

From the Radio Access Network (RAN) perspective, the EMISHO is activated when a RANAP: Location Reporting Control message for an emergency call (that is, CLIENT TYPE = Emergency Services) is received in the Radio Network Controller RNC. Simultaneously, the RNC initiates the normal location procedure and the normal ISHO. If the location procedure is finished before the ISHO attempt, the location result is stored within the RNC to wait for an ISHO attempt.



iEMISHO FunctionalityWhen a user makes an emergency call within the WCDMA network, the call flows and signalling scenarios with iEMISHO feature are depicted in the figures below:

3G MSC

GSM MSC

SourceUMTS RAN

TargetGSM BSS

3. Handover to GSM


2. Location Request


6. Location

7. Location

8. LocationRequest

9. Location

PSAP



GMLC

DN0934844Issue 01

269


Id:0900d8058061ea23

Figure 74 iEMISHO call flow when location accuracy was not sufficient enough

From the radio access network perspective, the iEMISHO is activated when a RANAP: Location Reporting Control message for an emergency call (that is, CLIENT TYPE = Emergency Services) is received in the RNC. Based on the locationing request, the RNC initiates the normal location procedure. If the location procedure successfully fulfills the requested QoS, the WCDMA RAN reports the achieved location estimate to the CN. Any available method can be used to fulfill the requested accuracy (CI+RTT, A-GPS), but if the A-GPS method can be initiated, the emergency call ISHO is not initiated in any case. If the A-GPS calculation is successful, position coordinates calculated with A-GPS are returned to CN (regardless of achieved accuracy). If A-GPS fails, the CI+RTT location result is returned to the core network.

If the CI+RTT method does not fulfill the requested accuracy and the A-GPS method cannot be initiated, an ISHO is initiated to handover the call to the GSM network. The location result generated by the WCDMA RAN is stored within the RNC to wait for an ISHO attempt.



3.59.3.3 Configuration requirements for EMISHO and intelligent EMISHOThe configuration requirements for the EMISHO and intelligent EMISHO solution are as follows:

• The GSM network must have overlapping coverage. • The GSM location service must be available.

3G MSC

GSM MSC

SourceUMTS RAN

TargetGSM BSS

4. Handover to GSM


2. Location Request


7. Location

8. Location

9. Location

PSAP



3. Positioning

GMLC

270 DN0934844Issue 01


Id:0900d8058061ea23

• In the core network, the Non-call-associated Signalling (NCAS) method must be selected to deliver the location estimate to the emergency center.

3.59.3.4 Functional restrictions on EMISHO and intelligent EMISHOThe EMISHO and intelligent EMISHO features rely on the fact that there is interopera-bility between the GSM and WCDMA networks and that a phase II compliant location technology exists in the GSM network.

3.59.3.5 ParametersThe following parameters are related to the feature:

• LCS Functionality • WCDMA GSM Inter-System Handover

For more information, see WCDMA RAS05.1 Parameter Dictionary in the RN2.2 library.

3.59.3.6 Concepts

Abbreviations • A-GPS = Assisted Global Positioning System • CN = Core Network • ISHO = Inter-System Handover • NCAS = Non-Call-Associated Signalling • RAN = Radio Access Network • RNC = Radio Network Controller • WCDMA = Wideband Code Division Multiple Access

DN0934844Issue 01

271


Id:0900d8058061ea48

3.59.4 RAN875: Network Based A-GPS Using External Reference NetworkNetwork Based Assisted Global Positioning System (A-GPS) Using External Reference Network RAN feature belongs to application software.

WCDMA RAS05.1 supports the network based assisted GPS (A-GPS) positioning method. Network based A-GPS is a method to establish a GPS reference network with a GPS position calculation entity. The GPS reference network receivers have an unob-structed view of the sky and can operate continuously. At the request of a user equip-ment or a network based application, the RAN collects the required GPS data from this reference network and generates the required assistance data elements for the UE. The assistance data from the GPS reference network can be transmitted to the UE to improve the GPS receiver performance. To be more specific, the assistance data speeds up the signal measurement function in the UE, thereby reducing UE battery con-sumption. The UE's GPS signal measurements are sent back to the network. RAN uses these measurements and the GPS position calculation entity to determine the UE's loca-tion.


3.59.4.1 Requirements





• There must be RRMU units on the RNC. • A stand-alone SMLC (SAS) is needed for GPS assistance data and for position cal-

culation. • Location services (LCS) A-GPS Site Solution related hardware for transmission is

needed between the RNC and the SAS. • A-GPS hardware is required in the UE.

End-user equipmentThe UE must support the A-GPS feature. In practice, the UE must be equipped with a GPS receiver. Furthermore, the UE must be able to receive assistance data from the network, take measurements from the appropriate GPS satellites, and send the mea-surement results to the network.

In addition, mobile-originated location requests (that is, a location request from a client UE to the location service server made over the WCDMA radio interface) need UE

272 DN0934844Issue 01


Id:0900d8058061ea48

support. Other types of location requests do not need additional UE support. The feature works with WCDMA UEs compatible with 3GPP Rel-4, Rel-5 and 3GPP R99 standards.



3.59.4.2 FunctionalityGPS positioning depends on accurate GPS time, navigation data containing satellite orbital parameters, and distance measurements. Should any of these three elements be missing, it would prevent the GPS based positioning. Unfortunately, this is often the case in urban areas due to poor satellite visibility. However, to recover positioning, the missing elements (except distance measurements) can be delivered through the cellular network. The cellular network can be equipped with a reference GPS receiver located in a place having an unobstructed view to the sky. Using the reference receiver, the network can receive navigation data, exact time, and so on, and relay this data over the cellular air interface to the user equipment.


However, if the requested location accuracy cannot be fulfilled with cell-based location methods and the UE is GPS-capable, an A-GPS location method is initiated. The RNC SMLC function collects GPS assistance data from the SAS and sends the data with a location request (by using the RRC: Measurement Control message) to the UE. The UE uses the network provided assistance data and its GPS receiver to make the GPS signal measurements and sends the signal measurements to the RNC.

The RNC sends the GPS measurement information to the SAS requesting the position calculation. The SAS calculates the UE location and responds to the RNC request. After receiving the UE location from the SAS, the RNC sends the locationing result to the core network.

ArchitectureThe network architecture and its elements for the A-GPS positioning method are shown in figure Network based A-GPS positioning method. This figure depicts the signalling flow for a mobile-terminated (MT) location request (LR).

DN0934844Issue 01

273


Id:0900d8058061ea48

Figure 75 Network based A-GPS positioning method

The WCDMA RAN A-GPS solution includes an RNC integrated SMLC and an interface to the SAS. This interface is a 3GPP standard Iu-PC interface. The external GPS refer-ence network tracks all GPS satellites and is the responsibility of the SAS vendor.

AccuracyThe A-GPS positioning method improves the standard GPS accuracy by increasing its coverage; navigation messages are obtained through the UMTS terrestrial radio access network (UTRAN), which allows the GPS to operate in situations where the GPS data is disturbed (for example indoors).




Iupc interface The Iupc interface is used for communication between the RNC inte-grated SMLC and a stand-alone SMLC (SAS) within the RAN. This 3GPP standard interface passes the requested GPS assistance data to the UE through the RAN, receives raw measurements from the UE through the RAN, and passes computed A-GPS positions to the RAN.



SAS

UE

BTS

Assistance data

Raw measurements RNC

N 61'26"47.75E 23'51"45.02

186.2m

XYZ

274 DN0934844Issue 01


Id:0900d805805f1a8f

Performance monitoring features

4 Performance monitoring features

4.1 RAS05.1 performance monitoring features overview


For parameters, counters and alarms per feature, see RAN1.5, RAN04 and RAS05 parameters, counters and alarms and RAS05.1 parameters, counters and alarms in Interdependencies of Performance Monitoring Features.



For information on the RAN1153: Complementary Counters in RAS05.1 feature, see the following documents:

• Measuring WCDMA RAN • WCDMA RAN Key Performance Indicators • RNC Counters - RNW Part in WCDMA RNC Product Documentation • Features Under Development (FUD)

For information on RAN04 and RAS05 features, see RAN04 and RAS05 Performance Monitoring Features.



RAS05.1

RAN956: BTS Channel Element Capacity Mea-suring

RAS05.1

RAN232: CPICH Ec/No Coverage Measure-ments and Optimisation

RAS05.1


RAS05.1

RAN1054: Downlink Packet Data Throughput for Subscriber and Equipment Trace

RAS05.1

RAN190: Radio Connection Performance Mea-surements for RLC TM and UM and Outer Loop Power Control

RAS05.1


RAS05.1 ED


RAS05.1


DN0934844Issue 01

275


Id:0900d805805f1a69

4.2 RAN189: Automatic Definition of Neighbouring Cells

4.2.1 Automatic Definition of Neighbouring Cells feature descriptionThe automatic definition of neighbouring cells consists of operational and basic radio network measurement aspects.

Operational aspectThe operational aspect means automatic updates and optimisation of adjacency lists from NMS.

Handover adjacency lists are initially defined with radio network planning based on geo-graphical locations and the estimated behaviour of the cells. However, this is not the optimal case; unnecessary cells may be included or necessary cells excluded. During the evolution of the network, new cells are also added and relevant parameters of the existing cells changed. In this case it becomes practical that adjacency lists can be updated automatically and the lists are optimised based on measurements without a laborious radio network planning process.

Basic radio network performance measurement aspectIn order to enable the network management system to optimise the cell neighbour lists, several counters are needed to be supplied by the RAN such as cell to cell handover statistics and cell to cell CPICH Ec/No difference measurements.

The new handover measurements for the automatic definition of neighbouring cells are:




When optimising neigbours the NetAct Optimizer also uses CPICH Ec/No difference information between source and target cells. Optimizer retrieves this information directly from RNC. This information is planned to be available as basic counters in later releases.

4.2.1.1 Operator benefitsThis feature improves the network quality and reduces manual workload on network optimisation. Correct adjacency definitions are a basic assumption for further perfor-mance optimisation or traffic balancing.

The signalling load is reduced, and UE measurements and handovers take place faster when unnecessary cells are not listed. On the other hand, when all necessary cells are listed on neighbour cell lists, the call quality also improves and dropped calls are avoided.

4.2.1.2 ComplianceThe new RAN performance measurement counters are 3GPP TS 32.403 compliant.

276 DN0934844Issue 01


Id:0900d805805f1a69





Operator requirementsThe NetAct support for this feature is optional and the operator needs to have the auto-matic adjacency optimisation module in order to be able to use this functionality. For more information, see the Optimiser 2.0 customer documentation.


4.2.1.4 Interaction with other featuresThis feature has no interaction with other features.

4.2.1.5 Limitations and restrictionsThe provisioning of any changes in the cell neighbour lists must take place while the cells are operating under low traffic because the cells must be stopped from operation before the feature can be activated. Usually network planners are using some tech-niques to obligate all users in the those cells, where neighbour lists are to be modified, to handover to some other neighbouring cells because adjacency lists cannot be modified while the cell is operating. In order to avoid any capacity problems, it is prefer-able to make those changes while the traffic is low in that part of the network.

RNC OSS

RAN2.2 OSS4.1CD


DN0934844Issue 01

277


Id:0900d805805f1a63

4.2.2 Main functionality of Automatic Definition of Neighbouring Cells

4.2.2.1 Using Automatic Definition of Neighbouring CellsThis feature is used with the help of the NetAct optimiser optional feature (automatic adjacency optimisation). In the optimiser, there is a special work space, from which the user is able to launch the automatic definition of neighbouring cells. The UI enables the user to set all the needed parameters for completing the task. The most important parameters are described in Parameters. The optimiser uses the new RAN handover statistics (intra-frequency (1013 Autodef SHO), inter-frequency (1014 Autodef IFHO), inter-system (1015 Autodef ISHO) handover statistics) collected by the RAN, in order to measure the performance for adjacencies in the optimisation scope. On the RAN side this feature operates like any other feature in the RAN. Needed RAN performance mea-surements operate similarly as other RAN performance measurements. These are managed by using the RNC Element Manager GUI application in RAN05.1 or the NetAct Administration of Measurements application.

4.2.2.2 Activating Automatic Definition of Neighbouring Cells

RAN performance measurementsThe needed RAN performance measurements are activated with the RNC Element Manager GUI application in RAS05.1 or with the NetAct Administration of Measure-ments application.

NetActThis feature is part of the NetAct application software. To activate the feature a separate “NetAct optmiser automatic adjacency optimisation” licence has to be bought.

For more information, see the Optimiser 2.0 customer documentation.

4.2.2.3 Verifying Automatic Definition of Neighbouring CellsThe user can verify that:

1. the defined minimum and maximum number of adjacencies of all types defined in the UI do not exceed the available adjacencies´ IDs.

2. the tool is able to get the performance measurements.3. the created adjacencies are the strongest according to the selection criteria unless

one of the constraints is violated, then the priority of that constraint is taken into account.

4. the angles and distance thresholds are fully respected

For more information about the post conditions, see the NetAct optimiser documenta-tion.

The RAN performance measurement data is collected and stored in the PM databases and can be viewed with available PM tools.

278 DN0934844Issue 01


Id:0900d805805f1a63

4.2.2.4 Deactivating Automatic Definition of Neighbouring Cells

RAN performance measurementsThe RAN performance measurements are deactivated with RNC EM GUI and with NetAct.

NetActThis feature is part of the NetAct operating software, so no special action is needed to take the feature out of use.

4.2.2.5 Feature management

RAN performance measurementsFor more information on the monitored counters in measurements 1013 Autodef SHO, 1014 Autodef IFHO and 1015 Autodef ISHO, see RNC Counters for RAS05.1 trial.

NetActThe main input parameters and monitored counters are explained in Parameters. For more information, see the Optimiser 2.0 customer documentation.

4.2.2.6 ArchitectureTo be able to optimise the adjacencies with the NetAct optimiser, the following modules must be in place:

DN0934844Issue 01

279


Id:0900d805805f1a63

Figure 76 The essential interfaces and objects in the automatic definition of neigh-bouring cells

4.2.2.7 Capacity

RAN performance measurementsThis feature has no special capacity effects.

NetActIn the pool creation phase of the adjacency optimisation, all possible candidates are identified in the optimiser plan. After that the rotation phase starts. In each rotation portion of the candidate, adjacencies are provisioned to the network and then a round of collecting performance measurements starts. It is recommended that in each round, the number of rotated adjacencies does not exceed 10 adjacencies per cell. Assuming that the number of adjacencies per RNC is about 400, the number of rotated adjacencies might be about 4000 adjacencies.

Configurator

NetAct

RNC

Planning tool

Measurementreport

BTS

Radio

MS

Optimizer

Plan download/upload

Measurementreport

H0decision

H0decision

List

List

HCMeas. Man

RNW stats

NEMU

Start command+ params

Autotuned/initial lists H0statistics(XML)

NWI3(TCP/IP, Corba)

Meas. Man

CSV report

Initial lists

Reporter

PMfragment

FTP(TCP/IP, Corba)

NW3I IF(TCP/IP, Corba)

XML (TCP/IP)

Conf.DB

280 DN0934844Issue 01


Id:0900d805805f1a66

4.2.3 ParametersList of essential parameters needed for the automatic definition of neighbouring cells using the optimiser.


Initialisation

HandoverType

Uiname (Measurement Based CheckBox common for ADJS and ADJG in Starting Dialog): ADJS checkbox: (adjacency type to be optimised)

DB: User options

Selection of the handover type to be opti-mised.

Range: intra-frequency/ inter-system

Default: intra-frequency

Pool

AdjacencyCreationLimitDistance (D) UI name (existing in common tab): Max Distance

Weight factor for the distance in the formula of the ADJ creation factor

Range: [0-20000]

Default: 10000

Dynrotation UI Names (UI: (3G meas tab): radionbuttons): Static, Dynamic. Group label: Rotation for ADJS and ADJG

Defines whether the rotation uses a dynamic or static rotation process.

Range: [YES, NO]

Default: NO

Rotations

MaxNeighborListSize (Existing in Common)

The maximum length of the neighbour cell list

Range: [1..31]

Default: 31

MinNumberOfRotatedCells

UI: (3G meas tab): Minimum Number of Rotated Cells ADJS

Defines the minimum number of pool can-didates to be tested during each rotation. In case the algorithm does not reach the minimum number of candidate cells, this is notified to the operator.

Range: [0..100]

Default: 0

MaxNumberOfRotatedCells

UI: (3G meas tab): Maximum Number of Rotated Cells ADJS

Defines the maximum number of pool can-didates to be tested during each rotation.

Range: [0..100]

Default: 8

Fitness evaluation

[EcnoLow, EcN0High]

UI: (3G meas tab): EcN0 Low, EcNO High

Low and high threshold for Ec/No metric

Range: -20..10

Default: [-1.5, 0]

Table 35 Essential parameters in autotuning algorithm

DN0934844Issue 01

281


Id:0900d805805f1a66

[HoSuccessLow, HoSuccessHigh]

Low and high threshold for HO success rate metric

Range: 0.00..1.00

Default: [0.75, 0.95]

[HoRatioLow, HoRatioHigh]

Low and high threshold for HO share metric

Range: 0.00..1.00

Default: [0.01, 0.1]

EcnoDifferenceThreshold

Threshold for Ec/No metric filtering

Range: -20..10

Default: -6

EcnoScalingRange

Scaling parameters for Ec/No metric

Range: -20..10

Default: [-6, 3]

HoSuccessScalingRange

Scaling parameters for HO success rate metric

Range: 0.0..1.0

Default: [0.5, 1.0]

HoRatioScalingRange

Scaling parameters for HO share metric

Range: 0.0..1.0

Default: [0.0, 0.2]

IntrafrequencyClass[XYZ]

Evaluation matrix: XYZ class where X, Y, Z=[Low,Med,High] referring to [Ec/No, HOshare, HOsuccess]

Range: 0..7 (0=mandatory)

Default:

ntraFrequencyClassXRanking

Scaled metrics to be used in the ranking cost function for adjacencies in class. X=1..7.

Default: Ec/No, HOratio, Hosuccess

Selection criteria

BasicListCumulativeHoRatioLimit

UI: (3G meas tab): Basic List Cumulative HO Ratio Threshold for ADJS: DB: ADCEOPTP_CUM_HO_RATIO_ADJS_TH

The cumulative %SHO threshold for the definition of the basic neighbour cell

Range: [0.10-0.99] percentage

Default: 0.95


Table 35 Essential parameters in autotuning algorithm (Cont.)

282 DN0934844Issue 01


Id:0900d805805f1a71

4.3 RAN956: BTS Channel Element Capacity Measuring

4.3.1 BTS Channel Element Capacity Measuring feature descriptionThe BTS channel element capacity measuring feature has the feature number RAN956.This feature is part of the WCDMA RAN measure solution (see Figure BTS channel element capacity measuring in WCDMA measure solution).




RNC



RNCElement Manager

Reportgeneration


PM:Measurement

activation

PM:DataTransfer


Core Network

lub

lub

added

taadded


UL: BLER ar

Options Close

Radio 1

NokiaNetAct

Reporter




BTS CECounters

DN0934844Issue 01

283


Id:0900d805805f1a71





4.3.1.1 Operator benefitsThe BTS channel element capacity measuring provides the operator the network level monitoring of the availability and utilisation of the BTS HW resources. This measure-ment also gives planning possibilities for the present and future needs of the BTS HW resources.






AMR 1

<=16 1

32 2

64 4

128 4

256 8

384 16





284 DN0934844Issue 01


Id:0900d805805f1a71




4.3.1.4 Interaction with other featuresThis feature interacts with the RAS05 feature: RAN21 Licence management for BTS.

4.3.1.5 Limitations and restrictionsThis feature has no special limitations or restrictions.

DN0934844Issue 01

285


Id:0900d805805f1a6e

4.3.2 Main functionality of BTS Channel Element Capacity Measuring

4.3.2.1 Using BTS Channel Element Capacity MeasuringThe BTS channel element capacity measuring operates similarly as other network per-formance measurements. The BTS channel element capacity measuring calculation is added to the current cell resource measurement on the RNC side. On the BTS side the BTS channel element capacity measuring calculation is included in the new WBTS HW resource measurement. It is managed by using the RNC Element Manager GUI appli-cation in RAS05.1 or the NetAct Administration of Measurements application. The BTS channel element capacity measuring monitoring is also possible via BTS EM.

The measurement interval for the BTS channel element capacity measurement in the RNC is selectable. The selection can be done using the RNC EM GUI or NetAct. In the BTS the measurement interval is fixed to 1 hour.

4.3.2.2 Activating BTS Channel Element Capacity MeasuringThe measurement data transfer from BTS to RNC and NetAct is activated either by using the RNC EM GUI or the NetAct Administration of Measurements application. In the BTS the measuring is always active and results can be viewed with the BTS EM regardless of data transfer settings.

4.3.2.3 Verifying BTS Channel Element Capacity MeasuringWhen the feature works as planned, the measurement data is collected and stored in the PM databases and can be viewed with available PM tools.

4.3.2.4 Deactivating BTS Channel Element Capacity MeasuringThe measurement data transfer from the BTS to the RNC and NetAct is deactivated either by using the RNC EM GUI or the NetAct Administration of Measurements appli-cation. In the BTS the measuring is always active and results can be viewed with the BTS EM regardless of data transfer settings.

4.3.2.5 Feature managementThe related counters are described more in detail in WBTS Counters.

4.3.2.6 ArchitectureFor more information, see Section BTS Channel Element Capacity Measuring feature description.


286 DN0934844Issue 01


Id:0900d805805f1a79

4.4 RAN232: CPICH Ec/No Coverage Measurements and Opti-misation

4.4.1 CPICH Ec/No Coverage Measurements and Optimisation feature descriptionThe CPICH Ec/No coverage measurements and optimisation feature has the feature number RAN232.



















DN0934844Issue 01

287


Id:0900d805805f1a79

4.4.1.1 Operator benefitsAfter the 3G network launch, the operator can tune the CPICH power to:










4.4.1.4 Interaction with other featuresThis feature has no interaction with other features.

4.4.1.5 Limitations and restrictionsThis feature has no special limitations or restrictions.




288 DN0934844Issue 01


Id:0900d805805f1a76

4.4.2 Main functionality of CPICH Ec/No Coverage Measurements and Optimisation

4.4.2.1 Using CPICH Ec/No Coverage Measurements and OptimisationThe CPICH Ec/No coverage measurements and optimisation calculation is added to the current soft handover measurement. Thus, the CPICH Ec/No coverage measurements and optimisation feature operates similarly as other network performance measure-ments. It is managed by using the RNC Element Manager GUI application in RAS05.1 or the NetAct Administration of Measurements application.

4.4.2.2 Activating CPICH Ec/No Coverage Measurements and OptimisationThe measurement is activated with the RNC EM GUI and/or NetAct.

4.4.2.3 Verifying CPICH Ec/No Coverage Measurements and OptimisationWhen the feature works as planned, the measurement data is collected and stored in the PM databases and can be viewed with available PM tools.

4.4.2.4 Deactivating CPICH Ec/No Coverage Measurements and Optimisa-tionThe measurement is deactivated with the RNC EM GUI or NetAct.

4.4.2.5 Feature managementFor more information on related counters, see RNC Counters for RAS05.1 trial.

4.4.2.6 ArchitectureFor more information, see CPICH Ec/No Coverage Measurements and Optimisation feature description.


DN0934844Issue 01

289


Id:0900d805805f1a7b

4.5 RAN1054: Downlink Packet Data Throughput for Sub-scriber and Equipment TraceFor information on RAN1054: Downlink Packet Data Throughput for Subscriber and Equipment Trace, see Subscriber and Equipment Trace Feature Description.

290 DN0934844Issue 01


Id:0900d805805f1a87

4.6 RAN190: Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power Control

4.6.1 Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power Control feature descriptionThe feature radio connection performance measurements for RLC TM and UM and outer loop power control has the feature number RAN190.







4.6.1.1 Operator benefitsThe RCPM OLPC and RCPM UEQ measurements extend the monitoring capabilities to measure the uplink and downlink performance of the radio connection between the BTS and the UE.





DN0934844Issue 01

291


Id:0900d805805f1a87





4.6.1.4 Interaction with other featuresThe UEQ measurement can be started only for RBs using UM-RLC or the transparent mode RLC. The RCPM RLC measurement is meant for AM-RLC connections.

4.6.1.5 Limitations and restrictionsWith radio connection performance measurements for RLC TM and UM and outer loop power control, the measurement interval should not be shorter than 60 minutes.


g NEMU (RNC):


g NetAct:







292 DN0934844Issue 01


Id:0900d805805f1a81

4.6.2 Main functionality of Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power Control

4.6.2.1 Using Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power ControlThe feature radio connection performance measurements for RLC TM and UM and outer loop power control is managed by using the RNC Element Manager GUI applica-tion.

4.6.2.2 Activating Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power ControlThis feature is part of the application software.

The RCPM includes the RCPM RLC, UEQ and OLPC measurements. The RCPM RLC measurement has been implemented already in RAS05.

The measurement is activated with the RNC EM GUI.

The following parameters need to be defined when starting the RCPM UEQ or RCPM OLPC measurement:

• the measurement schedule, including period start/stop times and intervals • the measured WCDMA cells • the radio connection type, including radio access bearer and radio bearer type • the handover mode selection to define how the calls in soft handover are measured

When starting the measurement, the user must use these parameters to define what types of calls are measured.

The feature radio connection performance measurements for RLC TM and UM and outer loop power control is managed by using the RNC Element Manager GUI applica-tion in RAS05.1. The measurement data is stored in the NEMU database and it is trans-ferred to NetAct.

4.6.2.3 Verifying Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power ControlWhen the feature works as planned, the measurement data is collected and stored in the PM databases and can be viewed with the available PM tools.

4.6.2.4 Deactivating Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power ControlThe measurements are deactivated and the measured objects can be changed with the RNC EM GUI.

4.6.2.5 Feature managementFor more information on related counters, see RNC Counters for RAS05.1 trial.

DN0934844Issue 01

293


Id:0900d805805f1a81

4.6.2.6 ArchitectureFore more information, see Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power Control feature description.

4.6.2.7 CapacityIn a large radio network it may be necessary to select only a subset of the available measured objects, or in a restricted network area, to reduce the amount of data pro-cessed in NEMU (RNC) and sent to NetAct. For more information, see Limitations and restrictions.

294 DN0934844Issue 01


Id:0900d805805f1a84

4.6.3 Connection type classificationThe connection type is classified hierarchically for the RCPM OLPC and RCPM UEQ measurement as described in the following tree presentations.

Figure 78 RCPM OLPC

Figure 79 RCPM UEQ

Signalling

Conversational

CS Voice

CS Transparent Data

Streaming


PS RT Data

Interactive

PS NRT Data

Background

PS NRT Data

Conversational

CS Voice

CS Transparent Data

Streaming


DN0934844Issue 01

295


Id:0900d805805f1a89

4.7 RAN1163: Iu-PS Throughput Measurement for GTP Traffic

4.7.1 Iu-PS Throughput Measurement for GTP Traffic feature descriptionThe Iu-PS throughput measurement for GTP traffic feature has feature number RAN1163. This feature is a part of the WCDMA RAN measure solution (see Figure Iu-PS throughput measurement for GTP traffic in WCDMA measure solution).



RNC

lub

NokiaNetAct


lu-CS lu-PS


PM: Data Transfer


GTPU

Report generation

Reporter

RNCElement Manager




CS CoreNetwork

PS CoreNetwork


RNC levelCounters

Iub

296 DN0934844Issue 01


Id:0900d805805f1a89







4.7.1.1 Operator benefitsThe new measurement enables monitoring the Iu-PS resource usage and dimensioning the network resources based on the actual traffic volumes.

GTPU-1

GTPU-2

GTPU-n

Iu-PSPS core

RNC



DN0934844Issue 01

297


Id:0900d805805f1a89









4.7.1.4 Interaction with other featuresThis feature supports monitoring the RAS05.1 feature “Iu-PS IP Quality of Service Support (DiffServ in GTPU)”. This feature can be used also in the case the Iu-PS IP Quality of Service Support feature is not activated.

4.7.1.5 Limitations and restrictionsThere is a limitation related to measurement management, which is common to all trans-port and HW related measurements in RNC. These measurements can not be activated from NetAct, but they need to be activated separately for each RNC.


RAS05.1ED

RN2.2 ED

- - OSS4.1 CD set 2

- - - -


298 DN0934844Issue 01


Id:0900d805805f1a89

4.7.2 Main functionality of Iu-PS Throughput Measurement for GTP Traffic

4.7.2.1 Using the Iu-PS throughput measurement for GTP trafficThe Iu-PS throughput measurement is operated similarly as other transport and HW related performance measurements in RNC. It is managed by using the RNC Element Manager GUI application in RAS05.1 or alternatively using MML commands.

4.7.2.2 Activating the Iu-PS throughput measurement for GTP trafficThis feature is part of the application software. The measurement and the data transfer from RNC to NetAct is activated either by using NE Measurement Explorer application in the RNC Element Manager or using ZT2 MML command group. The measurement data can be viewed either locally using NE Measurement Explorer or with NetAct report-ing tools.

4.7.2.3 Verifying the Iu-PS throughput measurement for GTP trafficWhen the feature works as planned, the measurement data is collected and stored in the PM databases and can be viewed with available PM tools.

4.7.2.4 Deactivating the Iu-PS throughput measurement for GTP trafficThe measurement and the data transfer from RNC to NetAct is deactivated either by using NE Measurement Explorer application in the RNC Element Manager or using ZT2 MML command group.

4.7.2.5 Feature managementThe related counters are described more in detail in RNC Counters – Transport and HW part in WCDMA RNC Product Documentation.

4.7.2.6 ArchitectureFor more information, see Figure Iu-PS throughput measurement for GTP traffic in WCDMA measure solution.


DN0934844Issue 01

299


Id:0900d805805f1a8c

4.8 RAN1153: Complementary Counters in RAS05.1

4.8.1 IntroductionThe new counters provide improved monitoring for selected functionalities in RAN. The counters are complements for the monitoring of the already existing functionality in RAN. For monitoring of new features in RAS05.1, the new counters are found through the corresponding feature description.

Benefits for the operatorOPEX savings are gained because of the reduced NE troubleshooting time.

4.8.2 Functional description

The new counters for NRT RAB drops in Cell_PCH state:

• Interactive RAB drop in CELL_PCH • Background RAB drop in CELL_PCH


The new counters are added to existing PM Measurement - Service Level - in the RNC.

The new counters for Reference Cell Changes. Counters to indicate that a cell is no longer a reference cell for a RRC or RAB:


Counters to indicate that a cell has become a reference cell for a RRC or RAB:




The new counters for RRC and RAB holding times in reference cell:

• RRC • AMR, AMR 12.2 (2 counters)

300 DN0934844Issue 01


Id:0900d805805f1a8c

• Conversational, Conversational 64 (2 counters) • Streaming, Streaming 14.4, Streaming 57.6. (3 counters)



The new counters for Multi RAB drops:

• Multi RAB Active fails for AMR 12.2 + PS NRT (64/384, 128/384, 384/384) (3 coun-ters)

• Multi RAB Active fails for AMR 12.2 + 2 PS NRT (I/I, I/B, B/B) (3 counters) • Multi RAB Active fails for AMR 12.2 + 3 PS NRT • Multi RAB Active fails for AMR Multimode + PS NRT (64/384, 128/384, 384/384) (3

counters) • Multi RAB Active fails for AMR Multimode + 2 PS NRT (I/I, I/B, B/B) (3 counters) • Multi RAB Active fails for AMR Multimode + 3 PS NRT • Multi RAB Active fails for Conversational + PS NRT (64/384, 128/384, 384/384) (3

counters) • Multi RAB Active fails for Conversational + 2 PS NRT (I/I, I/B, B/B) (3 counters) • Multi RAB Active fails for Conversational + 3 PS NRT • Multi RAB Active fails for Streaming (Guaranteed equals Maximum bitrate) + PS

NRT (64/384, 128/384, 384/384) (3 counters) • Multi RAB Active fails for Streaming (Guaranteed less than Maximum bitrate) + PS

NRT (64/384, 128/384, 384/384) (3 counters) • Multi RAB Active fails for 2 PS NRT (I/I, I/B, B/B) (3 counters) • Multi RAB Active fails for 3 PS NRT



The new counters for Cell Availability:

• The cell is created in DB • The cell is created in DB but blocked by User • The cell is created in DB and in WO state

The new counters are provided by the Radio Network Database in the RNC.


The new counters for Iu Availability:

• Iu Availability (in 10 second samples) • Iu Unavailability (in seconds) • Iu interface - changes to WO state

The new counters are provided by the RANAP interface function in the RNC.


DN0934844Issue 01

301


Id:0900d805805f1a8c

The new counters for Iur Availability:

• Iur Availability (in 10 second samples) • Iur Unavailability (in seconds) • Iur interface - changes to WO state

The new counters are provided by the RNSAP interface function in the RNC.

The new counters are added to the existing PM Measurement - L3 Signaling at Iur - in the RNC.

With these counters the operator is able to monitor:

• The drops of NRT RABs in Cell-PCH state. The drop in CELL-PCH has no visibility to the user and therefore these counters can be used for RAN KPIs to achieve better visibility of RAB performance from the end user perspective.

• The reference cell changes behind RRC and RABs.The reference cell change (SHO related) has impact on RRC and RAB counters if they are used for a specific cell. By introducing these counters, the operator will have a possibility to monitor the RRC and RAB performance from one cell perspective.

• The Multi RAB Active Failures. • The Holding times of RRC and RABs for a reference cell.

The counters can be used to monitor how frequently a cell is the reference in com-parison to other cells.

• The availability of WCELLs and Iub interfaces, Iur interfaces, Iu interfaces.

4.8.3 System impact

4.8.3.1 Hardware requirementsThis feature does not require any new or additional HW.

4.8.3.2 Interdependencies between featuresThis feature has no related or interworking features.

4.8.3.3 Current implementationThe current Cell Availability counters are based on monitoring the Code Tree. Based on the availability of the Code Tree, the Resource Manager updates the related counters. Currently, these counters are used also for cell availability monitoring.

4.8.3.4 Software requirements

RAS RNC BTS Ultra BTS Flexi BTS Pico AXC NetAct MSC

Release RAS05.1 RN2.2 - - - - OSS4.1 CD set 1

-

302 DN0934844Issue 01


Id:0900d805805f1a8c

4.8.3.5 Software sales information

4.8.3.6 Operational aspectsThis feature will be a part of the WCDMA RAN Measure Solution. RAN KPIs for NRT RAB performance and WCELL/Iu/Iur availability will be introduced or updated.

BSW/ASW RAS SW component

BSW RAN

DN0934844Issue 01

303

WCDMA RAN, rel. RAS05.1, feature descriptions BTS solution features

Id:0900d80580608cac

5 BTS solution features

5.1 BTS Solution Features Overview

5.1.1 BTS solution features overview


RAN999: Flexi WCDMA BTS 1700/2100 RAS05.1

RAN946: T1 Interface for Flexi WCDMA BTS RAS05.1


RAS05.1


RAS05.1

RAN941: JT1 Interface for Flexi WCDMA BTS RAS05.1

RAN940: E1 Interface for Flexi WCDMA BTS RAS05.1

RAN939: Flexbus Interface for Flexi WCDMA BTS RAS05.1

RAN935: BTS AAL2 Multiplexing for Flexi WCDMA BTS RAS05.1

RAN912: Licence Based BTS Channel Capacity RAS05.1

RAN907: Antenna Line Supervision RAS05.1

RAN905: Flexi WCDMA BTS MHA Support RAS05.1

RAN900: Flexi WCDMA BTS RAS05.1

RAN1093: HSDPA 16QAM SW Licence Support RAS05.1


RAN1046: Feederless site solution for Flexi WCDMA RAS05.1

RAN1469: Flexi Mounting Shields RAS05.1

RAN942: SDH STM-1 Interface for Flexi WCDMA BTS RAS05.1 ED





RAS05.1 ED


RAS05.1 ED

RAN1144: Flexi WCDMA BTS 8 W RF power limitation RAS05.1 ED

RAN1133: Configurable MHA alarms for Flexi BTS RAS05.1 ED

RAN1002: Flexi WCDMA BTS 40 W Carrier Power Support

RAS05.1 ED

RAN1001: Flexi WCDMA BTS Second Carrier Support RAS05.1 ED

RAN1000: Baseband Extension for Flexi WCDMA BTS RAS05.1 ED

Table 42 BTS solution features for RAS05.1

304 DN0934844Issue 01


Id:0900d80580608cac

BTS solution features

For information on RAS05.1 features, see Features Under Development (FUD) docu-mentation and Flexi WCDMA Base Station, Product Documentation.

5.1.2 Further informationFor feature descriptions, see Flexi WCDMA BTS Product and Release Documentation and HSDPA in BTS in WCDMA RAN System Documentation.

For more detailed information on parameters, counters and alarms, see Reference infor-mation in WCDMA RNC Product Documentation and WCDMA BTS Product Documen-tation for release WBTS3.2.

For listings of RAN1.5, RAN04, and RAS05 features, see BTS solution features overview in RAN04 and RAS05 BTS Solution Features.

RAN1439: Distributed BTS solution RAS05.1 ED


Table 42 BTS solution features for RAS05.1 (Cont.)

DN0934844Issue 01

305

WCDMA RAN, rel. RAS05.1, feature descriptions Related information

Id:

Related informationConcepts

ReferencesFeature RAN2.0060: IMSI-based Handover, Feature Activation Manual in WCDMA RNC Product Documentation

BTS Channel Element Capacity Measuring feature descriptionWBTS Counters in WCDMA BTS Product Documentation for release WBTS3.2.

Main functionality of BTS Channel Element Capacity Measuring

Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power Control feature descriptionRNC counter documentation in WCDMA RAN RNC Product Documentation for release RN2.2.

Main functionality of Radio Connection Performance Measurements for RLC TM and UM and Outer Loop Power Control

Downlink Packet Data Throughput for Subscriber and Equipment Trace feature descriptionMain functionality of Downlink Packet Data Throughput for Subscriber and Equipment Trace

CPICH Ec/No Coverage Measurements and Optimisation feature descriptionRNC counter documentation in WCDMA RAN RNC Product Documentation for release RN2.2.

Main functionality of CPICH Ec/No Coverage Measurements and Optimisation

Automatic Definition of Neighbouring Cells feature descriptionNokia NetAct Optimizer documentation in in Nokia NetAct Product Documentation for release OSS4.1.

RNC counter documentation in WCDMA RAN RNC Product Documentation for release RN2.2.

Main functionality of Automatic Definition of Neighbouring Cells






306 DN0934844Issue 01


Id:

Related information


Concepts

ReferencesFeature RAN2.0060: IMSI-based Handover, Feature Activation Manual in WCDMA RNC Product Documentation

Automatic Definition of Neighbouring Cells feature descriptionNokia NetAct Optimizer documentation in in Nokia NetAct Product Documentation for release OSS4.1.

RNC counter documentation in WCDMA RAN RNC Product Documentation for release RN2.2.

Main functionality of Automatic Definition of Neighbouring Cells







Documents

Feature Ru51