Ras06 Feature Descriptions 2e4z41

WCDMA RAN and I-HSPA, Rel. RU30, Operating Documentation, Issue 09

WCDMA RAN, Rel. RAS06, Feature Descriptions DN70296245 Issue 01L Approval Date 2012-08-24

Confidential

WCDMA RAN, Rel. RAS06, Feature Descriptions

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 DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, 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 ed trademark of Nokia Corporation. Siemens is a ed 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 2012. All rights reserved

f

Important Notice on Product Safety This product may present safety risks due to laser, electricity, heat, and other sources of danger. Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having carefully read the safety information applicable to this product. The safety information is provided in the Safety Information section in the “Legal, Safety and Environmental Information” part of this document or documentation set.

The same text in German:

f

Wichtiger Hinweis zur Produktsicherheit Von diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oder andere Gefahrenquellen ausgehen. Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheitsanforderungen erfolgen. Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal, Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentationssatzes.

2

Id:0900d8058095a98a Confidential

DN70296245 Issue 01L


Table of contents This document has 276 pages. Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1 1.1 1.1.1 1.2 1.2.1 1.2.2 1.2.3 1.2.3.1 1.2.3.2 1.2.3.3 1.2.3.4 1.2.3.5 1.3 1.3.1 1.3.2 1.3.3 1.3.3.1 1.3.3.2 1.3.3.3 1.3.3.4 1.4 1.4.1 1.4.2 1.4.3 1.4.3.1 1.4.3.2 1.4.3.3 1.4.3.4 1.4.3.5 1.4.3.6 1.5 1.5.1 1.5.2 1.5.3 1.5.3.1 1.5.3.2 1.5.3.3 1.5.3.4 1.5.3.5 1.6 1.6.1 1.6.2

DN70296245

Radio resource management and telecom features . . . . . . . . . . . . . . . 25 RAS06 documentation for radio resource management and telecom features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Reference documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 RAN853: HSDPA Code Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 RAN1177: Emergency Call Redirect to GSM . . . . . . . . . . . . . . . . . . . . 30 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 RAN834: Flexible Iu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 RAN968: HSUPA BTS Packet Scheduler . . . . . . . . . . . . . . . . . . . . . . . 35 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 RAN312: HSDPA Dynamic Resource Allocation . . . . . . . . . . . . . . . . . . 37 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37


3


1.6.3 1.6.3.1 1.6.3.2 1.6.3.3 1.6.3.4 1.6.3.5 1.7 1.7.1 1.7.2 1.7.3 1.7.3.1 1.7.3.2 1.7.3.3 1.7.3.4 1.7.3.5 1.8 1.8.1 1.8.2 1.8.3 1.8.3.1 1.8.3.2 1.8.3.3 1.8.3.4 1.8.3.5 1.8.3.6 1.9 1.9.1 1.9.2 1.9.3 1.9.3.1 1.9.3.2 1.9.3.3 1.9.3.4 1.10 1.10.1 1.10.2 1.10.3 1.10.3.1 1.10.3.2 1.10.3.3 1.10.3.4 1.10.3.5 1.11 1.11.1 1.11.2 1.11.3 1.11.3.1

4

System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 RAN1011: HSPA Layering for UEs in Common Channels . . . . . . . . . . . 41 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 RAN1452: MORAN for up to 4 Operators . . . . . . . . . . . . . . . . . . . . . . . . 43 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 RAN1219: Latency Statistics for UE Positioning. . . . . . . . . . . . . . . . . . . 46 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 RAN1305: HSDPA 14.4 Mbps per Cell. . . . . . . . . . . . . . . . . . . . . . . . . . 48 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 RAN1034: Shared HSDPA Scheduler for Baseband Efficiency . . . . . . . 50 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51


DN70296245


1.11.3.2 1.11.3.3 1.11.3.4 1.11.3.5 1.12 1.12.1 1.12.2 1.12.3 1.12.3.1 1.12.3.2 1.12.3.3 1.12.3.4 1.12.3.5 1.12.3.6 1.13 1.13.1 1.13.2 1.13.3 1.13.3.1 1.13.3.2 1.13.3.3 1.13.3.4 1.13.3.5 1.13.3.6 1.14 1.14.1 1.14.2 1.14.3 1.14.3.1 1.14.3.2 1.14.3.3 1.14.3.4 1.15 1.15.1 1.15.2 1.15.3 1.15.3.1 1.15.3.2 1.15.3.3 1.15.3.4 1.15.3.5 1.15.3.6 1.16 1.16.1 1.16.2 1.16.3 1.16.3.1

DN70296245

Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN1249: HSDPA 10 Mbps per . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN826: Basic HSUPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN973: HSUPA Basic RRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN1602: Flexible Iu with Multi-Operator RAN . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . . Operational aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN928: Directed Retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


52 52 52 52 54 54 54 54 54 54 54 54 54 54 56 56 56 57 57 57 58 58 58 58 62 62 62 62 62 62 62 63 67 67 67 68 68 68 68 68 68 68 69 69 69 69 69

5


1.16.3.2 1.16.3.3 1.16.3.4 1.17 1.17.1 1.17.2 1.17.3 1.17.3.1 1.17.3.2 1.17.3.3 1.17.3.4 1.17.3.5 1.17.3.6 1.17.3.7 1.17.3.8 1.18 1.18.1 1.18.2 1.18.3 1.18.3.1 1.18.3.2 1.18.3.3 1.18.3.4 1.18.3.5 1.18.3.6 1.19 1.19.1 1.19.2 1.19.3 1.19.3.1 1.19.3.2 1.19.3.3 1.19.3.4 1.19.3.5 1.19.3.6 1.20 1.20.1 1.20.2 1.20.3 1.20.3.1 1.20.3.2 1.20.3.3 1.20.3.4 1.20.3.5 1.20.3.6 1.21

6

Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 RAN992: HSUPA Congestion Control . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . . 79 RAN1033: HSDPA 48 s per Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 RAN1727: Enhancement to HSDPA with Simultaneous AMR Voice Call . 82 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Operational aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 RAN1515: HSPA Inter-RNC Cell Change. . . . . . . . . . . . . . . . . . . . . . . . 84 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 RAN852: HSDPA 15 Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86


DN70296245


1.21.1 1.21.2 1.21.3 1.21.3.1 1.21.3.2 1.21.3.3 1.21.3.4 1.21.3.5 1.22 1.22.1 1.22.2 1.22.3 1.22.3.1 1.22.3.2 1.22.3.3 1.22.3.4 1.22.3.5 1.23 1.23.1 1.23.2 1.23.3 1.23.3.1 1.23.3.2 1.23.3.3 1.23.3.4 1.23.3.5 1.23.3.6 1.24 1.24.1 1.24.2 1.24.3 1.24.3.1 1.24.3.2 1.24.3.3 1.24.3.4 1.24.3.5 1.25 1.25.1 1.25.2 1.25.3 1.25.3.1 1.25.3.2 1.25.3.3 1.25.3.4 1.26 1.26.1

DN70296245

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 RAN1013: 16 kbit/s Return Channel DCH Data Rate for HSDPA 91 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 RAN979: HSUPA 2.0 Mbps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 RAN970: HSUPA Handovers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 RAN974: HSUPA with Simultaneous AMR Voice Call. . . . . . . . . . . . . . 97 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 RAN831: Wideband AMR Codec Set (12.65, 8.85, 6.6) . . . . . . . . . . . . 99 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99


7


1.26.2 1.26.3 1.26.3.1 1.26.3.2 1.26.3.3 1.26.3.4

Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

2 2.1 2.1.1 2.2 2.2.1 2.2.2 2.2.3 2.2.3.1 2.2.3.2 2.2.3.3 2.2.3.4 2.2.3.5 2.2.3.6 2.2.3.7 2.2.3.8 2.2.3.9 2.3

Transmission and transport features . . . . . . . . . . . . . . . . . . . . . . . . . . 102 RAS06 Transmission and Transport features. . . . . . . . . . . . . . . . . . . . 102 Reference documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 RAN1097: Ethernet Interface Unit IFUH (Iub Plane) for AXC . . . 104 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 108 Impact on mobile terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 RAN1064: Ethernet+E1/T1/JT1 Interface Unit (Iub Plane) for Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 113 Impact on mobile terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 RAN1099: Dynamic Scheduling for HSDPA with Path Selection . . . . . 114 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

2.3.1 2.3.2 2.3.3 2.3.3.1 2.3.3.2 2.3.3.3 2.3.3.4 2.3.3.5 2.3.3.6 2.3.3.7 2.3.3.8 2.3.3.9 2.4 2.4.1 2.4.2 2.4.3 2.4.3.1 2.4.3.2 2.4.3.3 2.4.3.4 2.4.3.5 2.4.3.6 2.4.3.7

8


DN70296245


2.4.3.8 2.4.3.9 2.4.3.10 2.5 2.5.1 2.5.2 2.5.2.1 2.5.2.2 2.5.2.3 2.5.2.4 2.5.2.5 2.5.2.6 2.5.2.7 2.5.2.8 2.5.2.9 2.5.3 2.6 2.6.1 2.6.2 2.6.3 2.6.3.1 2.6.3.2 2.6.3.3 2.6.3.4 2.6.3.5 2.6.3.6 2.6.3.7 2.6.3.8 2.6.3.9 2.6.3.10 2.7 2.7.1 2.7.2 2.7.3 2.7.3.1 2.7.3.2 2.7.3.3 2.7.3.4 2.7.3.5 2.7.3.6 2.7.3.7 2.7.3.8 2.7.3.9 2.7.3.10 2.8 2.8.1

DN70296245

Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . 120 Impact on mobile terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 RAN1100: Dynamic Scheduling for NRT DCH with Path Selection. . . 121 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 System impact of RAN1100: Dynamic Scheduling for NRT DCH with Path Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . 126 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . 128 Impact on mobile terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 RAN759: Path Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . 135 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . 138 Impact on mobile terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 RAN1096: Transport Bearer Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . 140 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . 146 Impact on mobile terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 RAN1095: UBR+ for Iub Plane . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148


9


2.8.2 2.8.3 2.8.3.1 2.8.3.2 2.8.3.3 2.8.3.4 2.8.3.5 2.8.3.6 2.8.3.7 2.8.3.8 2.8.3.9 2.8.3.10 2.9 2.9.1 2.9.2 2.9.3 2.9.3.1 2.9.3.2 2.9.3.3 2.9.3.4 2.9.3.5 2.9.3.6 2.10 2.10.1 2.10.2 2.10.3 2.10.3.1 2.10.3.2 2.10.3.3 2.10.3.4 2.10.3.5 2.10.3.6 2.10.3.7 2.10.3.8 2.10.3.9 2.10.3.10 2.11 2.11.1 2.11.2 2.11.3 2.11.3.1 2.11.3.2 2.11.3.3 2.11.3.4 2.11.3.5 2.11.3.6 2.11.3.7

10

Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 154 Impact on mobile terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 RAN1319: Flexi WCDMA BTS IMA Based AAL2 Uplink CAC . . . . . . . 155 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 RAN1063: Hybrid Backhaul with Pseudo Wires . . . . . . . . . . . . . . . . . . 157 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 167 Impact on mobile terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Limitations and restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 RAN1142: ATM over Ethernet for BTS . . . . . . . . . . . . . . . . . . . . . . . . . 168 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171


DN70296245


DN70296245

2.11.3.8 2.11.3.9

Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . 175 Impact on mobile terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

3 3.1 3.2 3.2.1 3.2.2 3.2.3 3.2.3.1 3.2.3.2 3.2.3.3 3.2.3.4 3.2.3.5 3.2.3.6 3.2.3.7 3.3 3.3.1 3.3.2 3.3.3 3.3.3.1 3.3.3.2 3.3.3.3 3.3.3.4 3.3.3.5 3.3.3.6 3.3.3.7 3.3.3.8 3.3.3.9 3.4 3.4.1 3.4.2 3.4.3 3.4.3.1 3.4.3.2 3.4.3.3 3.4.3.4 3.4.3.5 3.4.3.6 3.4.3.7 3.4.3.8 3.4.3.9 3.5 3.5.1 3.5.2 3.5.3 3.5.3.1 3.5.3.2

Operability features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAS06 documentation for operability features . . . . . . . . . . . . . . . . . . RAN1199: RNC GUI for BTS Connection Resources . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . RAN1160: Collection of Key Counters. . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . Other impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN1161: Alarms for PM Measurement Data Transfer Failures. . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . Other impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN1150: RNC for Traffica . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


176 176 177 177 177 178 178 178 178 178 179 179 179 180 180 180 180 180 180 180 181 181 181 181 181 181 182 182 182 182 182 182 183 183 183 183 183 184 184 185 185 185 186 186 186

11


3.5.3.3 3.5.3.4 3.5.3.5 3.6 3.6.1 3.6.2 3.6.2.1 3.6.2.2 3.6.3 3.6.3.1 3.6.3.2 3.6.3.3 3.6.3.4 3.6.3.5 3.6.3.6 3.6.3.7 3.7 3.7.1 3.7.2 3.7.3 3.7.3.1 3.7.3.2 3.7.3.3 3.7.3.4 3.7.3.5 3.7.3.6 3.8 3.8.1 3.8.2 3.8.3 3.8.3.1 3.8.3.2 3.8.3.3 3.8.3.4 3.8.3.5 3.8.3.6 3.8.3.7 3.8.3.8 3.8.3.9 3.9 3.9.1 3.9.2 3.9.3 3.9.3.1 3.9.3.2 3.9.3.3 3.9.3.4

12

Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 RAN1810: Sleeping Cell Improvement . . . . . . . . . . . . . . . . . . . . . . . . . 188 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Activating and deactivating the feature . . . . . . . . . . . . . . . . . . . . . . . . . 188 Printing out RAN1810: Sleeping Cell Improvement statistics logs . . . . 190 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 196 RAN1823: Recovery Logging Improvement . . . . . . . . . . . . . . . . . . . . . 197 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 199 RAN1128: Dynamic Access Class Restriction . . . . . . . . . . . . . . . . . . . 200 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 201 Other impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 RAN212: Selectable RNW Plan Activation Mechanism . . . . . . . . . . . . 203 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203


DN70296245


3.9.3.5 3.9.3.6 3.9.3.7 3.9.3.8 3.9.3.9 3.10 3.10.1 3.10.2 3.10.3 3.10.3.1 3.10.3.2 3.10.3.3 3.10.3.4 3.10.3.5 3.10.3.6 3.10.3.7 3.10.3.8 3.10.3.9 3.11 3.11.1 3.11.2 3.11.3 3.11.3.1 3.11.3.2 3.11.3.3 3.11.3.4 3.11.3.5 3.11.3.6 3.11.3.7 3.11.3.8 3.12 3.12.1 3.12.2 3.12.3 3.12.3.1 3.12.3.2 3.12.3.3 3.12.3.4 3.12.3.5 3.13 3.13.1 3.13.2 3.13.3 3.13.3.1 3.13.3.2 3.13.3.3 3.13.3.4

DN70296245

Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . Other impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN1059: Flexi WCDMA BTS for RNS Split . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . Other impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN1084: Direct Activation of RNW Changes Using NWI3 . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . RAN1809: AAL2 multiplexing COCO modification. . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN618: Centralised Information Management for BTS . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


204 204 204 204 204 205 205 205 206 206 206 206 206 206 206 206 207 207 208 208 208 208 208 209 209 209 209 209 209 209 211 211 211 211 211 211 211 211 211 212 212 212 212 212 212 212 212

13


14

3.13.3.5 3.13.3.6 3.13.3.7 3.13.3.8 3.14 3.14.1 3.14.2 3.14.3 3.14.3.1 3.14.3.2 3.14.3.3 3.14.3.4 3.14.3.5 3.14.3.6 3.15 3.15.1 3.15.2 3.15.3 3.15.3.1 3.15.3.2 3.15.3.3 3.15.3.4 3.15.3.5 3.15.3.6 3.16 3.16.1 3.16.2 3.16.3 3.16.3.1 3.16.3.2 3.16.3.3 3.16.3.4 3.16.3.5 3.16.3.6

Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 213 RAN1159: IP Address & Port based Filtering for BTS LMPs . . . . . . . . 214 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 RAN33: IP Security for O&M Traffic between RNC and NetAct . . . . . . 216 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 RAN1451: Mass Change of Local BTS s . . . . . . . . . . . . . . . 218 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

4 4.1 4.1.1 4.2 4.2.1 4.2.2 4.2.3 4.2.3.1 4.2.3.2 4.2.3.3 4.2.3.4 4.2.3.5 4.2.3.6

Performance monitoring features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 RAS06 documentation for performance monitoring features . . . . . . . . 220 Information on Parameters, Counters, and Alarms. . . . . . . . . . . . . . . . 220 RAN1068: 3GPP TS 32.403 Related Counter Additions for RAN . . . . 222 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224


DN70296245


4.2.3.7 4.2.3.8 4.3 4.3.1 4.3.2 4.3.3 4.3.3.1 4.3.3.2 4.3.3.3 4.3.3.4 4.3.3.5 4.3.3.6 4.3.3.7 4.3.3.8 4.4 4.4.1 4.4.2 4.4.3 4.4.3.1 4.4.3.2 4.4.3.3 4.4.3.4 4.4.3.5 4.4.3.6 4.4.3.7 4.4.3.8 4.5 4.5.1 4.5.2 4.5.3 4.5.3.1 4.5.3.2 4.5.3.3 4.5.3.4 4.5.3.5 4.5.3.6 4.5.3.7 4.5.3.8 4.6 4.6.1 4.6.2 4.6.3 4.6.3.1 4.6.3.2 4.6.3.3 4.6.3.4 4.6.3.5

DN70296245

Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . RAN868: ATM Transport Statistics Reporting in RAN . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . RAN86: Cell Throughput Measurements in Serving RNC . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . RAN234: HSDPA Subscriber Trace. . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . RAN1052: HSUPA Subscriber Trace. . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


224 225 226 226 226 227 227 227 227 228 228 228 228 228 229 229 229 230 230 230 230 230 230 230 230 231 232 232 232 233 233 233 233 234 234 234 234 234 235 235 235 236 236 236 236 237 237

15


16

4.6.3.6 4.6.3.7 4.6.3.8

Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 237

5 5.1 5.1.1 5.2 5.2.1 5.2.2 5.2.3 5.2.3.1 5.2.3.2 5.2.3.3 5.2.3.4 5.2.3.5 5.2.3.6 5.2.3.7 5.2.3.8 5.2.3.9 5.3 5.3.1 5.3.2 5.3.3 5.3.3.1 5.3.3.2 5.3.3.3 5.3.3.4 5.3.3.5 5.3.3.6 5.3.3.7 5.3.3.8 5.4 5.4.1 5.4.2 5.4.3 5.4.3.1 5.4.3.2 5.4.3.3 5.4.3.4 5.4.3.5 5.5 5.5.1 5.5.2 5.5.3 5.5.3.1 5.5.3.2 5.5.3.3

RNC solution features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 RAS06 documentation for RNC solution features. . . . . . . . . . . . . . . . . 238 Information on parameters, counters, and alarms . . . . . . . . . . . . . . . . 238 RAN1151: Linux Based OMS Replacing NEMU . . . . . . . . . . . . . . . . . . 240 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 241 Other impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 RAN1623: Carrier Connectivity Optimised RNC450 . . . . . . . . . . . . . . . 242 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 244 RAN1739: HSUPA Amount Increase in RNC. . . . . . . . . . . . . . . . 245 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 RAN1754: HSPA Optimized Configuration . . . . . . . . . . . . . . . . . . . . . . 247 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248


DN70296245


DN70296245

5.5.3.4 5.5.3.5

Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

6 6.1 6.1.1 6.2 6.2.1 6.2.2 6.2.3 6.2.3.1 6.2.3.2 6.2.3.3 6.2.3.4 6.2.3.5 6.3 6.3.1 6.3.2 6.3.3 6.3.3.1 6.3.3.2 6.3.3.3 6.3.3.4 6.3.3.5 6.4 6.4.1 6.4.2 6.4.3 6.4.3.1 6.4.3.2 6.4.3.3 6.4.3.4 6.4.3.5 6.5 6.5.1 6.5.2 6.5.3 6.5.3.1 6.5.3.2 6.5.3.3 6.5.3.4 6.6 6.6.1 6.6.2 6.6.3 6.6.3.1 6.6.3.2 6.6.3.3

BTS solution features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAS06 documentation for BTS solution features . . . . . . . . . . . . . . . . Information on parameters, counters, and alarms . . . . . . . . . . . . . . . . RAN1733: Flexi WCDMA BTS 2100 High Gain. . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN1734: Flexi WCDMA BTS 2100 New Variants . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN1736: Flexi WCDMA BTS AISG 1.1 SW . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN906: Flexi WCDMA BTS 3GPP Antenna Tilt . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RAN908: Flexi WCDMA BTS AISG MHA . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . .


249 249 250 251 251 251 251 251 251 251 251 252 253 253 253 253 253 253 253 253 253 254 254 254 254 254 254 254 254 255 256 256 256 256 256 256 256 256 257 257 257 257 257 257 257

17


6.6.3.4 6.6.3.5 6.6.3.6 6.6.3.7 6.6.3.8 6.7 6.7.1 6.7.2 6.7.3 6.7.3.1 6.7.3.2 6.7.3.3 6.7.3.4 6.7.3.5 6.7.3.6 6.7.3.7 6.7.3.8 6.8 6.8.1 6.8.2 6.8.3 6.8.3.1 6.8.3.2 6.8.3.3 6.8.3.4 6.8.3.5 6.8.3.6 6.8.3.7 6.8.3.8 6.8.3.9 6.9 6.9.1 6.9.2 6.9.3 6.9.3.1 6.9.3.2 6.9.3.3 6.9.3.4 6.9.3.5 6.9.3.6 6.9.3.7 6.9.3.8 6.10 6.10.1 6.10.2 6.10.3

18

Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 258 RAN1222: External GPS Synchronisation for Flexi BTS System Module Rel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 259 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 260 RAN1463: for FPRA in Flexi WCDMA BTS. . . . . . . . . . . . . . . 261 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 262 Other impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 RAN1139: FADB Flexi Multiradio Combiner for 900MHz . . . . . . . . . . . 263 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 264 Other impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 RAN1079: FACB Flexi Multiradio Combiner for 850MHz . . . . . . . . . . . 265 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265


DN70296245


6.10.3.1 6.10.3.2 6.10.3.3 6.10.3.4 6.10.3.5 6.10.3.6 6.10.3.7 6.10.3.8 6.11 6.11.1 6.11.2 6.11.3 6.11.3.1 6.11.3.2 6.11.3.3 6.11.3.4 6.11.3.5 6.12 6.12.1 6.12.2 6.12.3 6.12.3.1 6.12.3.2 6.12.3.3 6.12.3.4 6.12.3.5 6.13 6.13.1 6.13.2 6.13.3 6.13.3.1 6.13.3.2 6.13.3.3 6.13.3.4 6.13.3.5 6.13.3.6 6.13.3.7 6.13.3.8 6.14 6.14.1 6.14.2 6.14.3 6.14.3.1 6.14.3.2 6.14.3.3

DN70296245

Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . 265 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . 266 Other impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 RAN1670: UltraSite EDGE Wideband Combiner for WCDMA Refarming. 267 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . 267 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 RAN1808: BTS Receiver Optimisations for High Speed Train Scenarios . 269 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . 269 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 RAN1462: FAGB Flexi Multiradio combiner for 2100MHz . . . . . . . . . . 271 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . 271 Software requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Software sales information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . 272 Other impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 RAN1127: Extended Cell (180km). . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Current implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Interdependencies between features. . . . . . . . . . . . . . . . . . . . . . . . . . 273


19


6.14.3.4 6.14.3.5 6.14.3.6 6.14.3.7 6.15 6.15.1 6.15.2 6.15.3 6.15.3.1 6.15.3.2 6.15.3.3 6.15.3.4 6.15.3.5 6.15.3.6 6.15.3.7 6.15.3.8 6.15.3.9

20

Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 RAN1309: WMHD Mast Head Amplifier . . . . . . . . . . . . . . . . . . . . . . . . 275 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 System impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Current implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Interdependencies between features . . . . . . . . . . . . . . . . . . . . . . . . . . 275 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Software sales information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Control and plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Management plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 Impact on system performance and capacity . . . . . . . . . . . . . . . . . . . . 276 Other impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276


DN70296245


List of figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Figure 14 Figure 15 Figure 16 Figure 17 Figure 18 Figure 19 Figure 20 Figure 21 Figure 22 Figure 23 Figure 24 Figure 25 Figure 26 Figure 27 Figure 28 Figure 29 Figure 30 Figure 31 Figure 32 Figure 33 Figure 34 Figure 35 Figure 36 Figure 37 Figure 38 Figure 39

DN70296245

Pool area example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 HSUPA CC system level architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Probability functions of MECN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 HSUPA Congestion Control signalling. . . . . . . . . . . . . . . . . . . . . . . . . . 78 AXC IFUH Pseudo Wire terminating function . . . . . . . . . . . . . . . . . . . 105 IFUH alternative operating scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 106 FTM FTIA/FTJA Pseudo Wire terminating function . . . . . . . . . . . . . . . 110 FTIA/FTJA alternative operating scenario . . . . . . . . . . . . . . . . . . . . . . 111 Example of VCC bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Example of VCC bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Path Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Flexi WCDMA BTS IMA Based AAL2 Uplink CAC . . . . . . . . . . . . . . . 155 ATM service emulation architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Example of tunnel topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Hybrid Pseudo Wire Backhaul mode . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Full Pseudo Wire Backhaul mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 BTS Pseudo Wire terminating function (Ethernet and TDM interfaces) 160 BTS Pseudo Wire terminating function (E1/T1/JT1) . . . . . . . . . . . . . . 161 Format of the Pseudo Wire associated channel header . . . . . . . . . . . 162 RAS06 settings for Pseudo Wire associated channel header . . . . . . . 162 Transport network protocol stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Format of the control word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 RAS06 settings for the control word . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Format of the MPLS shim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Format of the MPLS shim (Pseudo Wire application) . . . . . . . . . . . . . 165 Structure of the Ethernet carrying a Pseudo Wire packet . . . . . . . . . . 165 BTS Pseudo Wire terminating function (Ethernet and TDM interfaces) 169 BTS Pseudo Wire terminating function (Ethernet interface) . . . . . . . . 169 Recovery logging improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Flexi WCDMA BTS for RNS Split . . . . . . . . . . . . . . . . . . . . . . 205 Direct Activation of RNW Changes Using NWI3 . . . . . . . . . . . . . . . . . 208 3GPP TS 32.403 Related Counter Additions for RAN . . . . . . . . . . . . . 223 ATM Transport Statistics Reporting in RAN. . . . . . . . . . . . . . . . . . . . . 227 Cell Throughput Measurements in Serving RNC. . . . . . . . . . . . . . . . . 229 HSDPA Subscriber Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 HSDPA Subscriber Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 Capacities of the coverage solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 The maximum number of HSPA s with different UL channels for both RNC196 and RNC450. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 The number of HSPA s and the max R99 data throughputs. . . . . 247


21


List of tables Table 1 Table 2 Table 3 Table 4 Table 5 Table 6 Table 7 Table 8 Table 9 Table 10 Table 11 Table 12 Table 13 Table 14 Table 15 Table 16 Table 17 Table 18 Table 19 Table 20 Table 21 Table 22 Table 23 Table 24 Table 25 Table 26 Table 27 Table 28 Table 29 Table 30 Table 31 Table 32 Table 33 Table 34 Table 35 Table 36

22

Radio resource management and telecom features . . . . . . . . . . . . . . . 25 Parameters, counters, alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Parameters, counters, alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Value ranges of MECN parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Parameters, counter, alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Transmission and transport features . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Ethernet Interface Unit IFUH (Iub Plane) for AXC files impacts . 107 Ethernet Interface Unit IFUH (Iub Plane) for AXC impact on parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Ethernet Interface Unit IFUH (Iub Plane) for AXC impact on alarms 108 Ethernet+E1/T1/JT1 Interface Unit (IUB Plane) for Flexi WCDMA BTS file impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Ethernet+E1/T1/JT1 Interface Unit (IUB Plane) for Flexi WCDMA BTS impact on parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Ethernet+E1/T1/JT1 Interface Unit (IUB Plane) for Flexi WCDMA BTSimpact on alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Allowed configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Allowed configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Dynamic Scheduling for NRT DCH with Path Selection impact on parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Dynamic Scheduling for NRT DCH with Path Selection impact on BTS parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Allowed VCC configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 RAN759: Path Selection statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 RAN759: Path Selection impact on parameters . . . . . . . . . . . . . . . . . 137 AF and SCCH relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 RAN1096: Transport Bearer Tuning impact on parameters . . . . . . . . 144 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 UBR+ for Iub plane impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 UBR+ for Iub plane impact on parameters . . . . . . . . . . . . . . . . . . 153 Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 ATM over Ethernet for BTS file impacts . . . . . . . . . . . . . . . . . . . . . . . . 172 ATM over Ethernet for BTS statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 173 ATM over Ethernet for BTS impact on parameters . . . . . . . . . . . . . . . 173 ATM over Ethernet for BTS impact on alarms . . . . . . . . . . . . . . . . . . . 174 Operability features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Software requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Allowed configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Performance monitoring features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 RNC solution features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 Different configuration options for RNC450/150 . . . . . . . . . . . . . . . . . 243 BTS solution features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249


DN70296245


Summary of changes

Summary of changes Changes between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues. Note that the issue numbering system is changing. For more information, see Guide to WCDMA RAN operating documentation. Changes between issues 01K and 01L •

The following feature description has been updated: • RAN1150: RNC for Traffica

Changes between issues 01J and 01K •

The following feature description has been updated: • RAN1463: for FPRA in Flexi WCDMA BTS

Changes between issues 01I and 01J •

DN70296245

The following feature description has been updated: • RAN1034: Shared HSDPA Scheduler for Baseband Efficiency

Id:0900d8058095a990 Confidential

23

Summary of changes

24



DN70296245


Radio resource management and telecom features

1 Radio resource management and telecom features 1.1

RAS06 documentation for radio resource management and telecom features See the following table for more detailed information on WCDMA RAN functionality and feature activation:

Feature ID: Name

Functional area descriptions and other related documents

Feature implementation

RAN928: Directed Retry *

There are no related documents.

This feature does not require activation.

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

ission control overview in ission Control

Activating Wideband AMR Codec

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

Radio Resource Management overview


RAN852: HSDPA 15 Codes


Activating HSDPA 15 Codes

Radio Resource Management of HSDPA HSDPA in BTS RAN853: HSDPA Code Multiplexing


Activating HSDPA Code Multiplexing

Radio Resource Management of HSDPA RAN1033: HSDPA 48 s per Cell


Activating HSDPA 48 s per Cell

Radio Resource Management of HSDPA RAN1034: Shared HSDPA Scheduler for Baseband Efficiency

Radio Resource Management of HSDPA

Activating Shared HSDPA Scheduler for Baseband Efficiency

RAN312: HSDPA Dynamic Resource Allocation


Activating HSDPA Dynamic Resource Allocation

Radio Resource Management of HSDPA Handover Control Packet Scheduler ission Control RAN826: Basic HSUPA


Activating Basic HSUPA

Radio Resource Management of HSUPA

Table 1


DN70296245

Id:0900d8058095891d Confidential

25


Feature ID: Name


Functional area descriptions and other related documents

RAN973: HSUPA Basic RRM


Feature implementation Activating HSUPA Basic RRM

Radio Resource Management of HSUPA Radio Resource Management of HSDPA RAN968: HSUPA BTS Packet Scheduler RAN970: HSUPA Handovers



Radio Resource Management


Radio Resource Management of HSUPA RAN992: HSUPA Congestion Control

HSUPA in BTS


RAN974: HSUPA with Simultaneous AMR Voice Call

Radio Resource Management

Activating HSUPA with Simultaneous AMR Voice Call

RAN1515: HSPA Inter-RNC Cell Change



RAN1011: HSPA Layering for UEs in Common Channels

Radio Resource Management Handover Control

Activating HSPA Layering for UEs in Common Channel

RAN1249: HSDPA 10 Mbps per


Activating HSDPA 10 Mbps per

RAN1305: HSDPA 14.4 Mbps per Cell



RAN979: HSUPA 2.0 Mbps



RAN1727: Enhancement to HSDPA with Simultaneous AMR Voice Call



RAN834: Flexible Iu

Call Setup and Release

Activating Flexible Iu

RAN1177: Emergency Call Redirect to GSM

WCDMA RAN Location Services

Activating Emergency Call Redirect to GSM


Call Setup and Release RAN1219: Latency Statistics for UE Positioning



RAN1452: MORAN for up to 4 Operators



RAN1602: Flexible Iu with MultiOperator RAN



Table 1

Radio resource management and telecom features (Cont.) *) Delivered on top of RAS06.

26


DN70296245


1.1.1


Reference documentation For information on the parameters, counters and alarms related to each feature, see the Management data section of the feature descriptions. For parameter descriptions, see: • • • • • • • •

WCDMA Radio Network Configuration Parameters IP Configuration Plan Interface Parameters for Multicontroller RNC OMS LDAP parameters AXC Parameters Flexi Transport Module Parameters Flexi WCDMA BTS Parameters UltraSite WCDMA BTS Parameters Reference Information Service in NOLS for RNC parameters

For counter descriptions, see: • • • • •

RNC counters - RNW part RNC counters – transport and HW part WBTS counters AXC counters Reference Information Service in NOLS

For alarm descriptions, see: • • • • • • • • • • • •

Multicontroller RNC Notices (0-999) Multicontroller RNC Disturbances (1000-1999) Multicontroller RNC Failure Printouts (2000-3999) RNC Notices (0-999) IPA-RNC Disturbances (1000-1999) IPA-RNC Failure Printouts (2000-3999) IPA-RNC Diagnosis Reports (3700-3999) Multicontroller RNC and IPA-RNC Base Station Alarms (7000-9000) Troubleshooting Flexi WCDMA Base Station Flexi WCDMA Base Station faults Troubleshooting UltraSite and MetroSite WCDMA Base Station UltraSite and MetroSite WCDMA Base Station faults

For information on license management, see Nokia Siemens Networks license management concept and its implementation in WCDMA RAN in License management in WCDMA RAN.

DN70296245


27


1.2 1.2.1

RAN853: HSDPA Code Multiplexing Introduction RAN853: HSDPA code multiplexing enables simultaneous transmission of a maximum of three HSDPA s within a single cell during a single Transmission Time Interval (TTI). HSDPA code multiplexing improves the code resource utilisation and subsequently, improves the cell throughtput by 30 to 50% and beyond. Benefits for the operator Improved end- experience is acquired thanks to better cell throughput in the case of simultaneous s ing a maximum of 5 codes. CAPEX and OPEX savings result from increased cell capacity.

1.2.2

Functional description This feature allows sending data packets to more than one HSDPA simultaneously in each 2ms TTI. Code multiplexing can be used when at least two high-speed secondary control channel (HS-SCCH) codes are allocated by the RNC. With this feature 2-3 s can be code-multiplexed on HS-PDSCH depending on HS-PDSCH and HSSCCH allocation. The available code and power resources are evenly shared between the scheduled s. The decision on how many s are scheduled per cell is done independently on each TTI. The general rule is that when the UE category with the highest scheduling metric from proportional fair scheduling algorithm is ing less codes than the cell has available, then potentially (in case the first cannot use all the available power) a second UE is scheduled as well. The second UE to be scheduled is the one with the second highest scheduling metric. If the two scheduled UEs are both ing a maximum of 5 codes each, then a third is potentially scheduled as well. Note that code multiplexing does not provide any throughput gains in a case where the UEs as many codes as the NW. In such a scenario, the optimal strategy from spectral efficiency point of view is to schedule a single at a time. This decreases the power spent for control channels (only one HS-SCCH needed instead of several) and increases the gain from proportional scheduling. With code multiplexing it is possible to use a code space that is larger than five codes also with UEs that only five codes. The NW capacity gain from code multiplexing is similar to the gain from 15 codes in the case where most of the s are ing a maximum of 5 codes.

1.2.3 1.2.3.1

System impact Current implementation Without code multiplexing a single is scheduled in a cell per TTI.

1.2.3.2

Hardware requirements This feature does not require any new or additional HW.

28

Id:0900d805809588d5 Confidential

DN70296245


1.2.3.3

Software requirements

Relea se

1.2.3.4

1.2.3.5

RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAc MSC t

SGSN

MGW

UE

RAS0 6

RN3.0

WBTS 4.0

WBTS 4.0

-

OSS4. 2

-

-

3GPP Rel-5

Software sales information OSW/ASW

RAS SW component

Licence control in network element

Licence control attributes

ASW

HSPA

RNC LK

Long-term ON/OFF licence

Management plane NMS interfaces Reporting Tools: •

New KPIs for TTI s

Network element interfaces BTS Element Manager: • •

The TTI amount counters are added to the HSPA in WBTS Measurement. The counters produced by BTS are also viewable via OMS Element Manager.

Management data Parameters

Counters

Alarms

Maximum number of HS-SCCH codes

HSDPA S 0 IN TARGET CELL 1 IN OTHER CELL

No alarms related to this feature

HSDPA S 0 IN TARGET CELL 2 IN OTHER CELL HSDPA S 0 IN TARGET CELL 3 IN OTHER CELL HSDPA S 1 IN TARGET CELL 0 IN OTHER CELL HSDPA S 1 IN TARGET CELL 1 IN OTHER CELL HSDPA S 1 IN TARGET CELL 2 IN OTHER CELL HSDPA S 2 IN TARGET CELL 0 IN OTHER CELL HSDPA S 2 IN TARGET CELL 1 IN OTHER CELL HSDPA S 3 IN TARGET CELL 0 IN OTHER CELL HSDPA BUFFERS WITH DATA IN THE BUFFER FOR EACH TTI RECEIVED DATA IN MAC-D PDUS DISCARDED DATA IN MAC-D PDUS

DN70296245


29


1.3 1.3.1

RAN1177: Emergency Call Redirect to GSM Introduction 3G emergency call is directed to 2G NW as the latter one is assumed to provide a better location service. If there is another call attempt within 60 seconds, the call is established in 3G NW. Benefits for the operator CAPEX and OPEX savings can be achieved if the operator can utilise the existing 2G positioning system for emergency calls.

1.3.2

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

1.3.3 1.3.3.1

System impact Hardware requirements This feature does not require any new or additional HW.

1.3.3.2

Release

RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

-

-

-

-

1.3.3.3

30



RAS SW component



ASW

RAN

RNC LK


Id:0900d80580608f9f Confidential

DN70296245


1.3.3.4

Management plane Management data Parameters

Counters

Alarms

Emergency Call Redirect

RRC SETUP REJECT DUE TO EMERGENCY CALL REDIRECTION


Emergency Call Redirect Timer

DN70296245


31


1.4 1.4.1

RAN834: Flexible Iu Introduction RAN834: Flexible Iu provides a standardised mechanism for connecting multiple MSCs and SGSNs to an RNC. Flexible Iu is also known as 'Iu Flex' and 3GPP uses the names 'Intra Domain Connection of RAN Nodes to Multiple CN Nodes' and 'Multipoint Iu/Gb/A'. Benefits for the operator Flexible Iu provides CAPEX and OPEX savings resulting from efficient CNs resource utilisation and load balancing. Increased service availability and better NW resilience improve the end- experience.

1.4.2

Functional description This feature introduces the concept of Pool Areas. A UE may roam freely within a Pool Area (in either connected or idle mode) without the need to change the CN serving node. The following figure shows an example of the Pool Area configurations in the NW. Pool Area configurations are done in the CN nodes. Pool Areas themselves are not visible to the RAN but the RNC configuration has to be done according to the CN Pool Area configurations so that the RNC is able to route signalling messages to any CN node within a Pool Area. The NAS Node Selector function (NNSF) is a mechanism used for selecting the CN node for the UE. The UE derives the value of the parameter NRI from the (P)-TMSI or IMSI and sends the NRI to the RNC in the Initial Direct Transfer message. The RNC selects the CN node corresponding the NRI value configured in its database. The NNSF in the RNC also contains the CN node recovery functionality, which balances the load between the CN nodes of a pool in different cases, for example, with CN node failure, SW/HW update or adding or removing a CN node to/from the pool.

32

Id:0900d80580608fc6 Confidential

DN70296245


MSC 3 MSC 2 MSC 1

MSC 6 MSC 5 MSC 4

MSC 7

RAN node

RAN node

RAN node

RAN node

Area 1

Area 2

Area 3

Area 4

RAN node

RAN node

RAN node

RAN node

Area 5

Area 6

Area 7

Area 8

PS poolarea 2

CS poolarea 1 PS poolarea 1

PS poolarea 2 SGSN 1 SGSN 2

Figure 1

1.4.3 1.4.3.1

SGSN 6

SGSN 3 SGSN 4 SGSN 5

Pool area example

System impact Current implementation This is a new feature.

1.4.3.2


1.4.3.3

Interdependencies between features This feature has no related or interworking features.

1.4.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

M13.0

SG6.0

U2

-

DN70296245


33


1.4.3.5

1.4.3.6


RAS SW component



ASW

RAN

RNC LK



CN ID is already visible.

Network element interfaces RNC Element Manager: •

CN ID is already visible in the relevant measurements.


Counters

Alarms

NRI list for CS Core routing

No counters related to this feature


Maximum value of NRI range for CS Core routing Minimum value of NRI range for CS Core routing State of Iu interface NRI list for PS Core routing Maximum value of NRI range for PS Core routing Minimum value of NRI range for PS Core routing NRI length for CS Core Networks NRI length for PS Core Networks Null NRI value for CS Pool Null NRI value for PS Pool

34


DN70296245


1.5 1.5.1

RAN968: HSUPA BTS Packet Scheduler Introduction RAN968: HSUPA BTS Packet Scheduler is a fast BTS-based scheduler determining the bit rates to be used on E-DCH. Moving packet scheduling from the RNC to BTS is the key change in HSUPA compared to Rel. 5. The BTS is able to make much faster decisions when the RNC does not have to be consulted. This increases the efficiency at which especially bursty data can be treated by the packet scheduler. Benefits for the operator Increased UL data throughput improves the end- experience. In addition, increased cell UL capacity results in CAPEX and OPEX savings.

1.5.2

Functional description HSUPA BTS Packet Scheduler (PS) is a cell-specific scheduler using 10 ms scheduling periods with both Absolute Grants (AG) and Relative Grants (RG). The scheduling decisions are based on the maximum allowed noise rise, minimum throughput and the physical layer from the UEs in a cell. The HSUPA BTS PS also takes into the available baseband resources not needed for R99 DCHs. In a case where air interface and NW resources are not limiting the data rates, each UE is given as much bit rate as they request, up to a maximum of 1.44 Mbps, and if feature RAN979: HSUPA 2.0 Mbps is activated then up to 2.0 Mbps. The scheduling grant determined by the PS is applicable to all HARQ processes of the UE. (See RAN992: HSUPA Congestion Control.)

1.5.3 1.5.3.1

System impact Current implementation Without HSUPA, the RNC determines UL bit rates. This happens on a relatively slow cycle compared to the BTS-based HSUPA scheduling.

1.5.3.2


1.5.3.3

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

-

-

-

-

-

3GPP Rel-6

DN70296245


35


1.5.3.4

1.5.3.5


RAS SW component



OSW

HSPA

-

-

Management plane NMS interfaces Reporting Tools: • • •

New RAN_KPI_0075 for HSUPA Average MAC-es Throughput. New RAN_KPI_0080 for HSUPA MAC-es Data Volumes. New RAN_KPI_0062 for HSUPA BLER.

Network element interfaces OMS Element Manager: •

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

BTS Element Manager: • •

The HARQ retransmission counters are added to the HSPA in WBTS Measurement. The counters produced by BTS are also viewable via OMS Element Manager.


Counters

No parameters MAC-E PDU RETRANSMISSIONS 0 COUNTER related to this feature MAC-E PDU RETRANSMISSIONS 1 COUNTER MAC-E PDU RETRANSMISSIONS 2 COUNTER

Alarms No alarms related to this feature

MAC-E PDU RETRANSMISSIONS 3 COUNTER MAC-E PDU RETRANSMISSIONS 4 COUNTER MAC-E PDU RETRANSMISSIONS 5 COUNTER MAC-E PDU RETRANSMISSIONS 6 COUNTER MAC-E PDU RETRANSMISSIONS 7 COUNTER MAC-E PDU RETRANSMISSIONS 8 COUNTER MAC-E PDU RETRANSMISSIONS 9 COUNTER MAC-E PDU RETRANSMISSIONS 10 COUNTER MAC-E PDU RETRANSMISSIONS 11 COUNTER MAC-E PDU RETRANSMISSIONS 12 COUNTER MAC-E PDU DTX COUNTER MAC-E PDU HARQ FAILURE COUNTER MAC-E PDU LOST COUNTER MAC-E PDU RETRANSMISSIONS UNKNOWN COUNTER

36


DN70296245


1.6 1.6.1

RAN312: HSDPA Dynamic Resource Allocation Introduction Dynamic HSDPA channelisation codes allocation enables full cell resource utilisation, better end- experience and increased NW capacity. Benefits for the operator The gain in cell throughput is achieved as the cell resources are better utilised for a varying traffic mix. Operator control on resource division between NRT DCH and HSDPA allows flexible of different pricing strategies for DCH and HSDPA data.

1.6.2

Functional description NodeB dynamically controls the amount of power used for HSDPA. The HSDPA power can be controlled by each TTI, that is, in intervals of 2 ms. All the power left after DCH traffic, HSUPA control channels and common channels is used for HSDPA. This means that as long as there is HSDPA traffic in the cell, all the available PA power can be efficiently utilised. RNC will still schedule the NRT DCH bit rates. The higher bit rates the RNC allocates for NRT DCHs, the less there is "spare" power that the NodeB can use for HSDPA. To avoid situations where very unfair distribution of power is created between HSDPA and NRT DCH s, the RNC takes into both the current number of NRT DCH and HSDPA s in the cell when allocating NRT DCH bit rates. By default, the RNC will treat NRT DCH and HSDPA s equal in the sense that NRT DCH bit rates are allocated in such way that roughly equal amount of tx power per is available to both NRT DCH s and HSDPA s. This does not mean that each would have equal bit rates. It simply means that if in a 20 W cell there happens to be 8 W of RT and common channel load, then about 12 W is available for NRT traffic. This 12 W is then divided so that in case of 2 NRT DCH s and 10 HSDPA s, about 2 W would be given to the DCH side and 10 W to HSDPA side. The RNC does not directly guide the NodeB in allocating the power for HSDPA, but the RNC does affect this implicitly by a decision of NRT DCH bit rates. On an operator choice, the priority between NRT DCH and HSDPA can be weighed so that power is aimed to be spent in relation p1 : p2, where p1 represents the target tx power per available for NRT DCH and p2 the target tx power per available for HSDPA. In addition, s with higher Traffic Handling Priority (THP) can be counted more important when deciding the division between power for NRT DCH side and HSDPA side. THP is not taken into in actual HSDPA scheduling, but all HSDPA s are given roughly equal resources according to proportional fair scheduling principle. The code allocation is dynamically following the power allocation. In practice this means that once the NRT DCH bit rates have been decided, based on equal power criterion, the code requirements for the DCH side have been fixed. All other codes are then given to the HSDPA (operator may leave some margin to allow fast voice call allocation). In case of new DCH connections (for which the bit rate is again determined based on power criteria), the required amount of HSDPA codes are given back to the DCH.

DN70296245


37


1.6.3 1.6.3.1

System impact Current implementation The RNC allocates fixed codes. In RAS05.1, the power is allocated dynamically by the BTS by HSDPA Dynamic Power Allocation. The minimum adjustment period of HSDPA power is 100 ms in RAS05.1 and 2 ms in RAS06.

1.6.3.2


1.6.3.3

Release


RAS

RNC

BTS Ultra

BTS Flexi AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

OSS4.2

-

-

-

-

1.6.3.4

1.6.3.5

-


RAS SW component



ASW

HSPA

RNC LK


Management plane NMS interfaces Reporting Tools: • • • • • •

New RAN_KPI_0069 for HSPA power level New RAN_KPI_0059 for SF blocking KPIs for HS-DSCH related SF allocation distribution (6-15) KPIs for HS_DSCH <> DCH switches KPIs for HSDPA power targets KPIs for HS-DSCH related state transition

Network element interfaces OMS Element Manager: • • •

38

The new HSPA/HSDPA power and HS-PDSCH SF counters will be added to the Cell Resource Measurement. The new channel switching counters will be added to the new Packet Call Measurement. The new HS-DSCH state transition counters will be added to the RRC Signaling Measurement.


DN70296245


Management data

DN70296245

Parameters

Counters

Alarms

Weight of NRT DCH UE

MINIMUM PTXTARGETPS

Weight of NRT DCH UE BG RAB

MAXIMUM PTXTARGETPS


Weight of NRT DCH UE THP1 RAB

AVERAGE PTXTARGETPS


PTXTARGETPS DENOM


MIN HSPA DL POWER

Weight of HSPA UE

MAX HSPA DL POWER

Weight of HSPA UE BG RAB

AVE HSPA DL POWER

Weight of HSPA UE THP1 RAB

HSPA DL POWER SAMPLES


DURATION OF HSDPA 5 CODES RESERVATION



Retry time for u-plane resource allocation in Cell_DCH


High threshold of PtxTotal for dynamic HSDPA pwr alloc


DCH PS target adjust period for dyn HSDPA pwr alloc


Max DCH PS target for dynamic HSDPA pwr allocation


Min DCH PS target for dynamic HSDPA pwr allocation


DCH PS target step down for dynamic HSDPA pwr alloc


DCH PS target step up for dynamic HSDPA pwr alloc


HS-PDSCH code adjustment period


Bit rate threshold for RLC PDU size 656 with HS-DSCH


Usage of RLC PDU size 656 with HS-DSCH

CHANNELIZATION CODE SF4 REQUESTED

Number of HS-PDSCH codes for greater RLC PDU size


SIR threshold for RLC PDU size 656 with HS-DSCH



39


Parameters

Counters

PtxnonHSPA averaging window size for LC


NRT DPCH over HS-PDSCH code offset


HS-PDSCH code upgrade margin for SF128 codes


HSDPA Dynamic Resource Allocation


Alarms

HSDPA CH CODE DOWNGRADE DUE TO RT HSDPA CH CODE DOWNGRADE DUE TO NRT DCH CHANNEL TYPE SWITCH FROM DCH TO HS-DSCH FOR INTERACTIVE CHANNEL TYPE SWITCH FROM DCH TO HS-DSCH FOR BACKGROUND CELL FACH STATE TO HSDSCH SWI HS-DSCH/E-DCH TO HS-DSCH/DCH FOR INTERACTIVE SWI HS-DSCH/E-DCH TO HS-DSCH/DCH FOR BACKGROUND SWI HS-DSCH/E-DCH TO DCH/DCH FOR INTERACTIVE SWI HS-DSCH/E-DCH TO DCH/DCH FOR BACKGROUND SWI HS-DSCH/DCH TO HSDSCH/E-DCH FOR INTERACTIVE SWI HS-DCSH/DCH TO HSDSCH/E-DCH FOR BACKGROUND SWI DCH/DCH TO HSDSCH/E-DCH FOR INTERACTIVE SWI DCH/DCH TO HSDSCH/E-DCH FOR BACKGROUND

40


DN70296245


1.7 1.7.1

RAN1011: HSPA Layering for UEs in Common Channels Introduction UEs are directed to the correct layer according to their HSDPA and high-speed uplink packet access (HSUPA) capability in state transition from Cell_FACH to Cell_DCH. Benefits for the operator CAPEX savings can be achieved as the HSPA capability can be implemented using the HSPA layering. Choosing the correct layer for the UE on each transition to cell_DCH guarantees correct layer based on the UE capability on all practical mobility scenarios. When several layers HSPA, the feature chooses the layer in an optimal manner based on the expected DL throughput on each HSPA layer.

1.7.2

Functional description This feature transfers UEs to the correct layer based on their HSDPA and HSUPA capability. The transfer occurs in connection with the state transition from Cell_FACH to Cell_DCH. Non-HSDPA UEs are transferred to the non-HSDPA layer. The HSDPA capable UEs are transferred to the layer that s HSDPA. The HSUPA capable UEs are transferred to the layer that s HSUPA. If there are several HSDPA or HSDPA and HSUPA layers, load sharing is utilised. On HSPA layers, the selection criterion is the highest DL throughput (most power per available for HSDPA). In addition, this feature covers some enhancements to the Directed RRC Connection Setup for HSDPA Layer feature. The requested service in the radio resource control (RRC) Connection Setup Request is taken into in decision making so that only HSDPA UEs requesting interactive and background services are transferred to the HSDPA layer. Also, HSUPA capability is taken into when selecting the layer. The interworking with the directed RRC connection setup feature enables the non-HSDPA load sharing between all the layers. The UE that cannot manage with frequency change in the RRC connection setup phase or in the state transition phase is detected and the feature is not used for that specific connection.

1.7.3 1.7.3.1

System impact Current implementation Without the feature, the layer selection is only done at the RRC connection setup.

1.7.3.2


DN70296245

Id:0900d805809588db Confidential

41


1.7.3.3

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

-

-

-

3GPP Rel-5

1.7.3.4

1.7.3.5


RAS SW component



ASW

HSPA

RNC LK



New KPIs for HSDPA layering.


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


Counters

Alarms

Services for DRRC connection setup for HSDPA layer

DCH ALLO FOR SIG LINK FROM NON-HSPA TO HSPA LAYER


DRRC connection setup for HSDPA layer enhancements Disable power in decision making for HSDPA layering HSDPA layers load sharing threshold Cell weight for HSDPA layering

DCH ALLO FOR SIG LINK FROM HSPA TO NON-HSPA LAYER DCH ALLO FOR SIG LINK FROM HSPA TO HSPA LAYER FACH TO DCH FROM NONHSPA TO HSPA LAYER FACH TO DCH FROM HSPA TO NON-HSPA LAYER FACH TO DCH FROM HSPA TO HSPA LAYER

42

Id:0900d805809588db Confidential

DN70296245


1.8 1.8.1

RAN1452: MORAN for up to 4 Operators Introduction Multi-Operator RAN allows two to four operators to share radio access network. Operators' own end- services are available in the shared network area services. Sharing operators use their own frequencies and their own PLMN IDs. The solution is standardscompatible (3GPP) and it is ed with all 3G terminals. The MORAN solution allows independent control of traffic for each operator; they have dedicated cell-level parameters. Benefits for the operator Using MORAN for radio network sharing can help operators to reduce CAPEX/OPEX and bring 3G services to the mass market quickly. Although the radio network is shared, the operators still maintain perfromance and service differentiation capabilities as MORAN allows the use of operator-specific cell-level parameters.

1.8.2

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

Enables the operators to reduce the costs of their networks by sharing BTS and RNC hardware without losing control over operator-specific radio cells. Operators can tune their cell Radio Resource Management parameters and monitor their traffic individually on a cell basis. Neighbouring cell lists are operator-specific, which enables, for example, own intersystem handover decisions. Operators are free to add additional BTSs in locations where they want to provide better coverage or more capacity. Operators can use their own licensed frequencies and PLMN ID. UEs show the appropriate operator logo. Global roaming is easy. No extra features from the UEs are needed. The feature works with 3GPP Rel. 99 WCDMA UEs.

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

Initial coverage when the service demand is still low Low traffic areas, for example rural and suburban areas Places where it is hard to find BTS spots, for example subways

Cost savings are achieved by sharing the RAN capital and operating expenditure: • •

DN70296245

RNCs BTSs

Id:0900d80580608f97 Confidential

43


• • • • •

Site investments Transmission and Transport Installation and commissioning Operations system Radio network planning

The described approach provides a technical solution for allowing operators to share the Radio Access Network. It is required that the shared RAN is operated in a co-operation mode so that: • • • • •

Network Operation and Maintenance Network Dimensioning Transport Network Planning and Synchronisation (Iu-interface)

are based on mutual co-operation. The solution allows operators to individually plan and optimise their own cell parameters, whereas planning and dimensioning of global RNC parameters and BTS, RNC and transmission capacity need to be handled in co-operation. Sharing the RAN offers the operators a lot of freedom in of deciding the scope of their co-operation as well as when and where they want to provide additional capacity or coverage of their own.

1.8.3 1.8.3.1

System impact Current implementation MORAN originally s radio network sharing between two operators.

1.8.3.2


1.8.3.3

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

1.8.3.4

Release

44


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

-

-

-

-


DN70296245


1.8.3.5

1.8.3.6


RAS SW component



ASW

RAN

RNC parame- Long-term ter file ON/OFF licence


PLMN ID already visible.


CN ID already visible in relevant measurements

Management data

DN70296245

Parameters

Counters

Alarms

No parameters related to this feature




45


1.9 1.9.1

RAN1219: Latency Statistics for UE Positioning Introduction Statistics of location system's latencies are collected for further analysis. Benefits for the operator Better end- experience can be achieved as the operator has possibilities to monitor and the improved location system performance.

1.9.2

Functional description Latency statistics for UE Positioning present new statistical latency information concerning the UE positioning. The latency statistics present overall locationing service latencies, and detailed latency statistics for cell-based and A-GPS positioning methods. In addition, the feature presents the latency statistics of emergency call-related (intersystem handover) ISHO features.

1.9.3 1.9.3.1


1.9.3.2

Release


RAS

RNC

BTS Ultra

BTS Flexi AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

OSS4.2

-

-

-

-

1.9.3.3

1.9.3.4

-


RAS SW component



OSW

RAN

-

-


New KPIs for UE positioning delay.


46

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


DN70296245



Counters

No parameters SUM OF CIRTT LATENCY related to this feature DENOM CIRTT METHOD


CIRTT LATENCY LESS THAN 2 SECONDS CIRTT LATENCY BETWEEN 2 TO 5 SECONDS CIRTT LATENCY OVER 5 SECONDS SUM OF GPS LATENCY DENOM GPS METHOD GPS LATENCY LESS THAN 5 SECONDS GPS LATENCY BETWEEN 5 TO 15 SECONDS GPS LATENCY OVER 15 SECONDS SUM OF LCS TOTAL LATENCY SQUARED SUM OF LCS TOTAL LATENCY DENOM LCS TOTAL LATENCY SUM OF EMISHO LATENCY DENOM EMISHO LATENCY EMISHO LATENCY LESS THAN 2 SECONDS EMISHO LATENCY BETWEEN 2 TO 5 SECONDS EMISHO LATENCY OVER 5 SECONDS SUM OF EMERGENCY CIRTT LATENCY DENOM EMERGENCY CIRTT METHOD EMERGENCY CIRTT LATENCY LESS THAN 2 SEC EMERGENCY CIRTT LATENCY BETWEEN 2 to 5 SEC EMERGENCY CIRTT LATENCY OVER 5 SEC SUM OF EMERGENCY GPS LATENCY DENOM EMERGENCY GPS METHOD EMERGENCY GPS LATENCY LESS THAN 5 SECONDS EMERGENCY GPS LATENCY BETWEEN 5 to 15 SECONDS EMERGENCY GPS LATENCY OVER 15 SECONDS SUM OF EMERGENCY LCS TOTAL LATENCY SQUARED SUM OF EMERGENCY LCS TOTAL LATENCY DENOM EMERGENCY LCS TOTAL LATENCY

DN70296245


47


1.10 1.10.1

RAN1305: HSDPA 14.4 Mbps per Cell Introduction Cell maximum throughput is increased to 14.4 Mbps with a cell-dedicated scheduler. Benefits for the operator There are CAPEX savings in the BTS baseband thanks to the increased average cell throughput with a dedicated scheduler.

1.10.2

Functional description If HSDPA code multiplexing is used, the maximum theoretical cell-level throughput for simultaneously scheduled HSDPA s is 14.4 Mbps. With the Rel-6 HSDPA UE categories, the maximum theoretical cell-level throughput as defined by 3GPP is 13.9 Mbps with two cat 9 or cat10 terminals. Practical throughput achievable with this feature is limited by radio reception. Maximum theoretical throughput would require the use of coding rate close to 1, meaning that it would require error-free reception. Targeting to error-free reception reduces the system efficiency and capacity. In all practical conditions, the throughput is degraded if using coding rates close to 1, that is, having effectively no error correction. Quality of radio reception depends on aspects such as received signal strength, radio channel and interference, transmitter and receiver imperfections.

1.10.3 1.10.3.1

System impact Hardware requirements Dedicated UltraSite WSPC/Flexi WCDMA BTS sub-module per cell for HSDPA is needed in the BTS.

1.10.3.2

Interdependencies between features Dedicated UltraSite WSPC/Flexi BTS sub-module per cell for HSDPA is needed in the BTS.

1.10.3.3

Release

RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

-

-

-

-

-

-

1.10.3.4

48



RAS SW component



OSW

HSPA

-

-

Id:0900d805809588dd Confidential

DN70296245


1.10.3.5

Management plane NMS interfaces Reporting Tools: • •

The existing RAN_KPI_0044 follows the average HSDPA cell throughput. The new RAN_KPI_0055 follows the HSDPA cell throughput data volume.


There are already existing HS-DSCH (MAC-d) throughput counters in the HSPA in WBTS Measurement The counters produced by BTS are also viewable via OMS Element Manager.

Management data

DN70296245

Parameters

Counters

Alarms




Id:0900d805809588dd Confidential

49


1.11

1.11.1

RAN1034: Shared HSDPA Scheduler for Baseband Efficiency Introduction This feature enables simultaneous HSDPA transmission to a maximum of three HSDPA-capable cells by using a single UltraSite WSPC card or one sub-module in Flexi WCDMA BTS. Shared HSDPA Scheduler s 15 codes per cell and 48, or 64 HSDPA s per cellgroup. 10.8 Mbps, or 14.4 Mbps overall throughput per cell group is provided depending on system release and BTS HW version. Benefits for the operator Statistical multiplexing gain and superior baseband efficiency result in CAPEX and OPEX savings. HSDPA throughput and s from up to three cells can be multiplexed in a single Shared HSDPA Scheduler requiring only one UltraSite WSPC card/Flexi WCDMA BTS sub-module. Superior performance is gained with a minimum number of CEs. Increased HSDPA capacity means increased revenue and better end- experience. HSDPA capacity is increased both in of a number of s ed and cell throughput. The increased capacity improves end- performance with higher average bit rates.

1.11.2

Functional description The Shared HSDPA Scheduler for Baseband Efficiency allows a single UltraSite WSPC card, or Flexi WCDMA BTS system module to handle the processing of HSDPA for 1, 2, or 3 cells simultaneously. With RAN1034: Shared HSDPA Scheduler for Baseband Efficiency feature it is possible to use all 15 HSDPA codes simultaneously in up to three cells that belong to the same cell group. However, on each TTI the total throughput over all cells of the cell group is limited to 10.8 Mbps, or 14.4 Mbps, depending on the BTS baseband HW version. The Shared HSDPA Scheduler is capable of ing up to 64 s in the cell group. By default, 16 s per cell are ed. To increase the number of s per cell to 48, or 64, a separate licence in the RNC is required. The use of 15 codes simultaneously in each cell is beneficial even with the total bit rate limitation, because in the optimal link adaptation the number of codes is increased prior to increasing coding rate or modulation. For example, the maximum number of available codes is taken into use already at 2.4 Mbps because of more efficient use of spectrum and possibility for more robust error protection coding. The Shared HSDPA Scheduler for Baseband Efficiency for BTS feature requires a whole WC card (sub-module in case of FlexiBTS) of processing capacity to be enabled for two to three cells in the BTS. In normal case, the best option is to allow single WSPC/Flexi BTS sub-module to handle three cells. A second WSPC can be added so that cell A is handled by the first WSPC, and cells B and C are handled by the second WSPC. This will increase the total maximum number of simultaneous HSDPA s to 96 and the total maximum bit rate to 21.6 Mbps. Note that in the vast majority of cases only one WSPC is sufficient for HSDPA, and only on the busiest sites a second WSPC could be added.

50

Id:0900d805809588df Confidential

DN70296245


To utilize the whole WSPC capacity, the following RAS level features are recommended to be used together with the Shared HSDPA Scheduler for Baseband Efficiency for BTS: •

•

•

•

•

HSDPA Code multiplexing: If there are s in all three sectors of the BTS, the Shared HSDPA Scheduler for Baseband Efficiency for BTS will schedule one per cell in the BTS on each TTI. This will use the available power in the most efficient manner. In case some sector(s) do not have UEs for which there would be data in the BTS buffer, the code multiplexing will take care that all three s will be simultaneously scheduled in the BTS. This will occur only if it is beneficial from the spectral efficiency point of view. In practice, this means that in some sector the primarily scheduled is not able to use all the available power and codes. Thus it is beneficial to schedule a second (or even third) in that particular sector. HSDPA 48 s per Cell: This feature allows 48 simultaneous HSDPA s per cell. However, in case the WSPC card is handling several cells, the total number of s in those cells can be 48 at maximum. Without this feature the maximum number of s in single cell is 16 even with the shared scheduler feature. The Iub and BTS baseband dimensioning is advisable only if the 16 kbit/s Return Channel DCH Data Rate for HSDPA is deployed together with this feature. Otherwise the UL DCHs require too high capacity. HSDPA 15 (or 10) codes: The HSDPA 15 codes feature allows 15 HS-PDSCH codes to be used from single cell, corresponding to maximum 45 HS-PDSCH codes per WSPC with BTS level code multiplexing feature. HSDPA Dynamic Resource Allocation feature operates for dynamic adjustment of the cell resources.

The operator can follow up through new counters the consumption of HSUPA related Channel Elements per LCG. There are already counters for total CE consumption for all services per LCG. The congestion related to CE shortage - when RNC requests a RL setup or RL reconfiguration - can be followed up via existing counters.

1.11.3 1.11.3.1

System impact Current implementation Currently there are two options for baseband allocation of HSDPA s in the BTS: •

•

DN70296245

Option one (minimum baseband allocation): Single UltraSite WSPC card/Flexi WCDMA BTS sub-module serves three HSDPA-capable cells and the HS-DSCH transmission is time-multiplexed between the cells (only one HSDPA cell can be transmitted to at each TTI). The maximum air interface peak rate is 3.6 Mbps and a maximum of 16 simultaneous HSDPA s per BTS can be served. 32 CE from UltraSite WSPC card/Flexi WCDMA BTS sub-module is consumed for HSDPA. Option two (dedicated baseband allocation): Single UltraSite WSPC card/Flexi WCDMA BTS sub-module is dedicated for each HSDPA cell (all HSDPA cells can transmit simultaneously). 32 CE from each UltraSite WSPC card/Flexi WCMDA BTS sub-module is consumed for HSDPA, and the remaining 32 CE are used for DCH traffic (or common channels). The maximum air interface peak rate is 3.6 Mbps per cell and 16 simultaneous HSDPA s per cell can be served.


51


1.11.3.2

Hardware requirements This feature requires a whole Ultra WSPC card, or Flexi sub-module of processing capacity to be enabled for two to three cells in the BTS. In normal case, the best option is to allow single WSPC/Flexi BTS sub-module to handle three cells.

1.11.3.3


Relea se

1.11.3.4

1.11.3.5

RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAc MSC t

SGSN

MGW

UE

RAS0 6

RN3.0

WBTS 4.0

WBTS 4.0

-

-

-

-

3GPP Rel-5

-


RAS SW component



ASW

HSPA

BTS LK



New RAN_KPI_0063 and RAN_KPI_0064 for BTS Baseband use effiency for HSUPA BTS CEs. Existing RAN_KPI_0046 and RAN_KPI_0047 for BTS Baseband use effiency for all BTS CEs.

Network element interfaces BTS Element Manager: • • •

52

The new HSUPA CE counters are added to the WBTS HW Resource Measurement. The existing CE counters are found in the WBTS HW Resource Measurement. The counters produced by the BTS are also viewable via OMS Element Manager.


DN70296245



Counters

Alarms


HSDPA S 0 IN TARGET CELL 1 IN OTHER CELL No alarms HSDPA S 0 IN TARGET CELL 2 IN OTHER CELL related to this feature HSDPA S 0 IN TARGET CELL 3 IN OTHER CELL HSDPA S 1 IN TARGET CELL 0 IN OTHER CELL HSDPA S 1 IN TARGET CELL 1 IN OTHER CELL HSDPA S 1 IN TARGET CELL 2 IN OTHER CELL HSDPA S 2 IN TARGET CELL 0 IN OTHER CELL HSDPA S 2 IN TARGET CELL 1 IN OTHER CELL HSDPA S 3 IN TARGET CELL 0 IN OTHER CELL

DN70296245


53


1.12 1.12.1

RAN1249: HSDPA 10 Mbps per Introduction The peak bit rate on HSDPA for single is increased to 10 Mbps. Benefits for the operator RAN1249: HSDPA 10 Mbps per allows higher peak bit rates for a single .

1.12.2

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

1.12.3 1.12.3.1

System impact Current implementation Currently the peak bit rate for a single is 3.6 Mbps.

1.12.3.2

Hardware requirements CDSP-C interchangability D required in RNC

1.12.3.3

Interdependencies between features RAN852: HSDPA 15 Codes is needed for this feature.

1.12.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

-

OSS4.2

-

SG6.0

-

3GPP Rel-5

1.12.3.5

1.12.3.6


RAS SW component



ASW

HSPA

RNC LK


Management plane NMS interfaces Reporting tools:

54


DN70296245


•

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

Network element interfaces OMS Element Manager: • •

There will be new extended RLC Throughput Distribution counters added to the RM RLC AM Measurement. There are already existing basic RLC Throughput (PDU) counters in the RM RLC AM Measurement.


Counters

Alarms


DL THROUGHPUT DISTRIBUTION - CLASS 11


DL THROUGHPUT DISTRIBUTION - CLASS 12 DL THROUGHPUT DISTRIBUTION - CLASS 13

DN70296245


55


1.13 1.13.1

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

BTS-controlled scheduling of the E-DCH within the limits set by the RNC Physical layer retransmission handling in the BTS

Benefits for the operator Increased UL average and peak data rates improve the end- experience. CAPEX and OPEX savings result from increased cell UL capacity and increased Iub and BTS HW efficiency. New data service availability increases revenue.

1.13.2

Functional description The basic characteristics of the feature are listed below: • • •

• • • •

•

56

HSUPA is ed only with co-existence of HSDPA. All cells in the BTS can be enabled for HSUPA. The maximum number of HSUPA s per BTS is 24 (in larger than 6-cell configurations two local cell groups have to be used, and then HSUPA is handled independently on both local cell groups). The maximum number of HSUPA s in a cell is 20, limited by available signatures in E-RGCH/E-HICH channels. One E-AGCH and one E-RGCH/E-HICH code channels are configured to each serving E-DCH cell. The maximum number of simultaneous HSUPA serving s is 19 in a cell, and one signature is reserved for non-serving HSUPA s. The operator can choose to set a lower threshold for the maximum number of s per cell and per BTS. TTI of 10 ms is used for maximizing the resulting UL range. The largest ed E-DCH category is 3 (1.44 Mbps), corresponding to two parallel codes of spreading factor four (2xSF4). HSUPA activation requires a static reservation of UltraSite WSPC card/Flexi WCDMA BTS sub-module) capacity. Rest of the HSUPA baseband capacity is fully pooled across cells, and also dynamically shared with R99 traffic. Up to two UltraSite WSPC cards/Flexi WCDMA BTS sub-modules can be in HSUPA use, R99 traffic allowing. For Ultrasite WCDMA BTS it is possible to enable HSDPA and HSUPA in three sectors on a single shared WSPC card, using RAS05 HSDPA 16 s per BTS scheduler. This allows operators to roll out a fast and cost-efficient HSUPA service. In case of high capacity UltraSite WCDMA BTS HSPA sites, the operator can select an alternative HSUPA activation on separated WSPC cards. WSPC (64 CE) per BTS or WSPC per cell for HSDPA can be used to increase HSDPA capacity. These together provide a high-capacity HSPA solution: The maximum peak data rate per is 1.44 Mbps as coded L1 bit rate (error protection coding is not counted into bit rate but L1 retransmissions are). If feature RAN979: HSUPA 2.0 Mbps is activated, then the peak data rate per is 2.0 Mbps.


DN70296245


• • •

• •

One UltraSite WSPC card/Flexi WCDMA BTS sub-module s up to 24 HSUPA s. The minimum combined L1 baseband throughput of all s per UltraSite WSPC card/Flexi WCDMA BTS sub-module is 4.2 Mbps. HSUPA channel coding functionality includes E-DCH Absolute Grant Channel (EAGCH), E-DCH Relative Grant Channel (E-RGCH) and E-DCH Hybrid Automatic Repeat Request (ARQ) Indicator Channel (E-HICH) encoding in DL and E-DCH Dedicated Physical Data Channel (E-DPDCH) and E-DCH Dedicated Physical Control Channel (E-DPCCH) decoding in UL. HSUPA Hybrid Automatic Repeat Request (H-ARQ) operation handling per UE in E-DCH Medium Access Control (MAC-e) entity within a BTS. HSUPA Service Indicator is ed.

The total cell data rate for HSUPA s is scheduled between the HSUPA-capable UEs in a cell. Scheduling is performed by the NodeB in a fast cycle by using mainly relative grants. All UEs get as much bit rate as they can send in a non-congested case. In case of congestion, roughly equal noise rise contribution is allowed for each . For facilitating smooth mobility operations with non-HSUPA capable BTSs, Signaling Radio Bearer (SRB) is mapped on DCH. HSUPA traffic is mapped on a dedicated Iub virtual channel connection (VCC), allowing Iub capacity consumption to be optimised for NRT HSUPA traffic, while preserving the QoS of real-time services, which are mapped on another VCC. The operator may also configure a minimum service level for HSUPA by dedicating a minimum amount of baseband channel elements (CEs) for HSUPA. HSUPA improves the UL packet data performance by providing higher data rates over the whole cell area, increasing the peak data rate and reducing delay. HSUPA also increases the system capacity by improving the cell throughput and the efficiency of the transport and BTS hardware resources. HSUPA benefits are especially significant for bursty high bit rate applications. In a non-congested, single case the maximum bit rates are greatly improved, since instead of practical maximum of 384 kbps with R99, 1.4 Mbps can be reached with HSUPA. In a loaded NW with congestion, the capacity gain from HSUPA is expected to be on the order of 20%-50%. HSUPA Service Indicator indicates the HSUPA capability to the UEs. HSUPA-capable cell means that the UE may consider this cell/any cell in the same sector as part of the HSUPA coverage area to display HSUPA service indication.

1.13.3 1.13.3.1

System impact Current implementation Prior to HSUPA, the maximum practical peak bit rate is 384 kbps, UL packet scheduling is handled by the RNC and retransmissions are handled by the RLC (as opposed to L1 HARQ retransmissions in HSUPA).

1.13.3.2


DN70296245


57


Release

1.13.3.3

Interdependencies between features

1.13.3.4


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

-

OSS4.2

-

SGN3

-

3GPP Rel-6

1.13.3.5

1.13.3.6


RAS SW component



ASW

HSPA

RNC LK

Long-term capacity licence

Management plane NMS interfaces Reporting Tools: • • • • •

New RAN_KPI_0063 and RAN_KPI_0064 for HSUPA CE UL vs. DL consumption New RAN_KPI_0065 for HSUPA UL Power levels in BTS New KPI for HSUPA DL power levels in BTS New KPIs for HSUPA UE Capability New KPIs for HSUPA s per cell


The HSUPA capability counters are added to the Service Level Measurement. The HSUPA counters are added to the Cell resource Measurement.

BTS Element Manager: • • •

The HSUPA CE counters are added to the WBTS HW Resource Measurement. The HSUPA Power level counters are added to the HSPA in WBTS Measurement. The counters produced by BTS are also viewable via OMS Element Manager.

Management data Parameters Maximum Reordering Wait Time for MAC-es Table 2

58

Counters BTS HSUPA NOT HW LIMITED DURATION

Alarms 7780 HSUPA DISABLED IN WCEL

Parameters, counters, alarms


DN70296245


Parameters

Counters

E-DCH Capability

BTS HSUPA HW LIMITED DURATION

Operational E-DCH state

BTS HSUPA HW NO CAPACITY DURATION

Alarms 7782 HSUPA CONFIGURATION FAILED

DURATION OF NO ACTIVE HSUPA S DURATION OF ACTIVE HSUPA S - 1 OR 2 SIMULTANEOUS S DURATION OF ACTIVE HSUPA S - 3 OR 4 SIMULTANEOUS S DURATION OF ACTIVE HSUPA S - 5 OR 6 SIMULTANEOUS S DURATION OF ACTIVE HSUPA S - 7 OR 8 SIMULTANEOUS S DURATION OF ACTIVE HSUPA S - 9 OR 10 SIMULTANEOUS S DURATION OF ACTIVE HSUPA S - 11 OR 12 SIMULTANEOUS S DURATION OF ACTIVE HSUPA S - 13 OR 14 SIMULTANEOUS S DURATION OF ACTIVE HSUPA S - 15 OR 16 SIMULTANEOUS S DURATION OF ACTIVE HSUPA S - 17 OR 18 SIMULTANEOUS S DURATION OF ACTIVE HSUPA S - 19 OR 20 SIMULTANEOUS S UE FOR E-DCH CATEGORY 1 UE FOR E-DCH CATEGORY 2 UE FOR E-DCH CATEGORY 3 UE FOR E-DCH CATEGORY 4 UE FOR E-DCH CATEGORY 5 UE FOR E-DCH CATEGORY 6 UL E-DCH HARQ RETRANSMISSIONS TRANSFERRED DATA FOR NRT E-DCH HSUPA DL PHYSICAL CHANNEL POWER DISTRIBUTION - CLASS 01 HSUPA DL PHYSICAL CHANNEL POWER DISTRIBUTION - CLASS 02 HSUPA DL PHYSICAL CHANNEL POWER DISTRIBUTION - CLASS 03 Table 2

Parameters, counters, alarms (Cont.)

DN70296245


59


Parameters

Counters

Alarms

HSUPA DL PHYSICAL CHANNEL POWER DISTRIBUTION - CLASS 04 HSUPA DL PHYSICAL CHANNEL POWER DISTRIBUTION - CLASS 05 HSUPA DL PHYSICAL CHANNEL POWER DISTRIBUTION - CLASS 06 HSUPA MINIMUM MAC-D THROUGHPUT HSUPA MAXIMUM MAC-D THROUGHPUT HSUPA AVERAGE MAC-D THROUGHPUT HSUPA UL MINIMUM PHYSICAL CHANNEL POWER HSUPA UL MAXIMUM PHYSICAL CHANNEL POWER HSUPA UL AVERAGE PHYSICAL CHANNEL POWER HSUPA UL PHYSICAL CHANNEL POWER SAMPLE COUNTER MAXIMUM NUMBER OF USED CE FOR HSUPA UL MINIMUM NUMBER OF USED CE FOR HSUPA UL AVERAGE NUMBER OF USED CE FOR HSUPA UL MAXIMUM NUMBER OF USED CE FOR HSUPA DL MINIMUM NUMBER OF USED CE FOR HSUPA DL AVERAGE NUMBER OF USED CE FOR HSUPA DL HS-DSCH/E-DCH PACKET CALL ATT FOR INTERACTIVE HS-DSCH/E-DCH PACKET CALL ATT FOR BACKGROUND HS-DSCH/E-DCH ALLO AFTER HS-DSCH/EDCH REQ FOR INTERACTIVE HS-DSCH/E-DCH ALLO AFTER HS-DSCH/EDCH REQ FOR BACKGROUND HS-DSCH/DCH ALLO AFTER HS-DSCH/EDCH REQ FOR INTERACTIVE Table 2

60



DN70296245


Parameters

Counters

Alarms

HS-DSCH/DCH ALLO AFTER HS-DSCH/EDCH REQ FOR BACKGROUND DCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FOR INTERACTIVE DCH/DCH ALLO AFTER HS-DSCH/E-DCH REQ FOR BACKGROUND SWI HS-DSCH/E-DCH TO HS-DSCH/DCH FOR INTERACTIVE SWI HS-DSCH/E-DCH TO HS-DSCH/DCH FOR BACKGROUND SWI HS-DSCH/E-DCH TO DCH/DCH FOR INTERACTIVE SWI HS-DSCH/E-DCH TO DCH/DCH FOR BACKGROUND SWI HS-DSCH/DCH TO HS-DSCH/E-DCH FOR INTERACTIVE SWI HS-DCSH/DCH TO HS-DSCH/E-DCH FOR BACKGROUND SWI DCH/DCH TO HS-DSCH/E-DCH FOR INTERACTIVE SWI DCH/DCH TO HS-DSCH/E-DCH FOR BACKGROUND HS-DSCH/E-DCH PACKET CALL NORM REL FOR INTERACTIVE HS-DSCH/E-DCH PACKET CALL NORM REL FOR BACKGROUND HS-DSCH/E-DCH PACKET CALL REL DUE TO PRE-EMP FOR INTERACTIVE HS-DSCH/E-DCH PACKET CALL REL DUE TO PRE-EMP FOR BACKGROUND HS-DSCH/E-DCH PACKET CALL REL DUE TO RL FAIL FOR INTERACTIVE HS-DSCH/E-DCH PACKET CALL REL DUE TO RL FAIL FOR BACKGROUND HS-DSCH/E-DCH PACKET CALL REL DUE TO OTHER FAIL FOR INTERACTIVE HS-DSCH/E-DCH PACKET CALL REL DUE TO OTHER FAIL FOR BACKGROUND Table 2


DN70296245


61


1.14 1.14.1

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

1.14.2

Functional description HSUPA RRM in the RNC algorithm reserves the required codes and power for the EAGCH, E-RGCH and E-HICH physical channels in DL. In UL, a certain noise rise is reserved for the BTS packet scheduler. This allows itting the DCH s according to the normal ission control procedure in the RNC while the remaining noise rise margin is efficiently utilised for the HSUPA. HSUPA RRM algorithm in the RNC also makes the E-DCH allocation decisions. The decision between DCH and E-DCH allocation for a UE is based on the service (RAB parameters), resource availability, multi-RAB combination and UE capability. HSUPA is ed only with co-existence of HSDPA per UE. HSUPA RRM algorithm in the RNC also configures the RLC layer, radio bearer, transport channel and physical channel configuration for an E-DCH based on RAB parameters. This feature introduces operator-controllable RLC parameters for RB mapped on DCH, E-DCH or HS-DSCH. E-DCH is released based on low throughput detection in both UL and DL. Furthermore, HSUPA RRM algorithm in the RNC performs combined power and throughput-based (hybrid) ission decision and packet scheduling for R99 DCH and/or E-DCH s in the cell. HSUPA RRM algorithm in the RNC performs HSUPA outer loop power control.

1.14.3 1.14.3.1


1.14.3.2

Release

RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

-

OSS4.2

-

-

-

3GPP Rel-6

1.14.3.3

62



RAS SW component



OSW

HSPA

-

-

Id:0900d80580958903 Confidential

DN70296245


1.14.3.4

Management plane NMS interfaces Reporting Tools: • • • • • • • • • • • •

New RAN_KPI_SSSR_PACKET_SESSION for Packet Session setup success rates. New RAN_KPI_SSR_PACKET_SESSION for Packet Session success rates. New RAN_KPI_0072 for E-DCH session allocation success. New RAN_KPI_0074 for E-DCH session release success. New RAN_KPI_0071 for HS-DSCH session allocation success. New RAN_KPI_0073 for HS-DSCH session release success. New RAN_KPI_0076 for DCH session allocation success. New RAN_KPI_0077 for DCH session release success. New RAN_KPI_0060 for E-DCH resource allocation success. New RAN_KPI_0061 for E-DCH resource release success. New KPI for RLC throughput amounts on E-DCH transport channel. New KPI for RLC throughput distribution on E-DCH transport channel.


The Packet Session/HS-DSCH/E-DCH/DCH request, reservation, setup failure and release counters will be added to the new Packet Call Measurement. The E-DCH request and allocation counters will be added to the Traffic Measurement. The RLC throughput counters are automatically added to RM RLC AM Measurement (via measurement object, that is, transport channel object covers also E-DCH).


Counters

AM RLC maximum buffer allocation for UE

MIN HSPA DL POWER

AM RLC maximum buffer allocation for UE capability 100

MAX HSPA DL POWER


AVE HSPA DL POWER


HSPA DL POWER SAMPLES


UL DCH SELECTED FOR INTERACTIVE DUE TO MAX HSUPA S

AM RLC configuration for PS NRT with E-DCH

UL DCH SELECTED FOR BACKGROUND DUE TO MAX HSUPA S

AM RLC status reports count for PS NRT with E-DCH

UL DCH SELECTED FOR INTERACTIVE DUE TO BTS HW LIMIT

Table 3


Parameters, counters, alarms

DN70296245


63


Parameters

Counters

AM RLC MaxDAT transmissions for PS NRT with E-DCH

Alarms

UL DCH SELECTED FOR BACKGROUND DUE TO BTS HW LIMIT

AM RLC MaxMRW transmissions for PS E-DCH ALLO CANCEL FOR INTERACNRT with E-DCH TIVE DUE TO NON ACCEPTABLE AS AM RLC maxRST transmissions for PS NRT with E-DCH

E-DCH ALLO CANCEL FOR BACKGROUND DUE TO NON ACCEPTABLE AS

AM RLC status period max for PS NRT with E-DCH

DL DCH SELECTED FOR INTERACTIVE DUE TO HSDPA POWER

AM RLC status period min for PS NRT with E-DCH

DL DCH SELECTED FOR BACKGROUND DUE TO HSDPA POWER

AM RLC period Poll_PDU for PS NRT with E-DCH

E-DCH SETUP FAILURE DUE TO UE FOR INTERACTIVE

AM RLC period Poll_SDU for PS NRT with E-DCH

E-DCH SETUP FAILURE DUE TO UE FOR BACKGROUND

AM RLC period Poll_Window for PS NRT with E-DCH

E-DCH SETUP FAILURE DUE TO BTS FOR INTERACTIVE

AM RLC status report triggers for PS NRT with E-DCH

E-DCH SETUP FAILURE DUE TO BTS FOR BACKGROUND

AM RLC round trip time with E-DCH

E-DCH SETUP FAILURE DUE TO TRANSPORT FOR INTERACTIVE

DCH slope of the curve

E-DCH SETUP FAILURE DUE TO TRANSPORT FOR BACKGROUND

Window size of E-DCH MAC-d flow throughput measurement

E-DCH SETUP FAILURE DUE TO OTHER REASONS FOR INTERACTIVE

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

E-DCH SETUP FAILURE DUE TO OTHER REASONS FOR BACKGROUND

Low throughput time to trigger of the EDCH MAC-d flow

E-DCH ALLOCATIONS FOR INTERACTIVE

E-DCH maximum number of HARQ retransmissions

E-DCH ALLOCATIONS FOR BACKGROUND

E-DCH QoS classes

E-DCH ALLOCATION DURATION FOR FOR INTERACTIVE

EDCH slope of the curve

E-DCH ALLOCATION DURATION FOR FOR BACKGROUND

Factor to calculate EDCH maximum bit rate

E-DCH NORMAL RELEASE FOR INTERACTIVE

Happy bit delay condition for E-DCH

E-DCH NORMAL RELEASE FOR BACKGROUND

Table 3

64



DN70296245


Parameters

Counters

Periodicity for scheduling info

E-DCH RELEASE DUE HS-DSCH SERVING CELL CHANGE FOR INTERACTIVE

Power Offset for Scheduling Info

E-DCH RELEASE DUE HS-DSCH SERVING CELL CHANGE FOR BACKGROUND

Step Size for DCH BLER calculation

E-DCH RELEASE DUE TO RL FAILURE FOR INTERACTIVE

Step Size for EDCH BLER calculation

E-DCH RELEASE DUE TO RL FAILURE FOR BACKGROUND

Threshold to define maximum EDPDCH SR

E-DCH RELEASE DUE TO OTHER FAILURE FOR INTERACTIVE

Threshold to define maximum EDPDCH SR 1920 kbps

E-DCH RELEASE DUE TO OTHER FAILURE FOR BACKGROUND

Threshold to define maximum EDPDCH SR 960 kbps

E-DCH ALLO FOR INTER RNC HHO INTERACTIVE

HARQ RV Configuration

E-DCH ALLO FOR INTER RNC HHO BACKGROUND

Maximum number of E-DCHs in the local cell group

E-DCH SETUP FAIL FOR INTER RNC HHO INTERACTIVE

PS target tune period in HSPA-DCH interference sharing

E-DCH SETUP FAIL FOR INTER RNC HHO BACKGROUND

Non-EDPCH interference averaging window size for LC

CELL FACH STATE TO HS-DSCH

E-DCH minimum set E-TFCI

UL E-DCH HARQ RETRANSMISSIONS

Alarms

HSUPA enabled Maximum number of E-DCHs in the cell Maximum total uplink symbol rate Number of E-DCHs reserved for SHO branch additions DCH time limit for UL NRT DCH overload in E-DCH cell Interference margin for the minimum EDCH load Maximum target received wide band power for BTS Max PS target in HSPA-DCH interference sharing Table 3


DN70296245


65


Parameters

Counters

Alarms

Min PS target in HSPA-DCH interference sharing PS target step down in HSPA-DCH interference sharing Maximum E-DCH Downlink Power The transmission power offset of the EAGCH The transmission power offset of the EHICH The transmission power offset of the ERGCH SIR target offset for DPCCH with EDPCH Target non-serving E-DCH to total EDCH power ratio AAL2 UP Usage Table 3

66



DN70296245


1.15 1.15.1

g

RAN1602: Flexible Iu with Multi-Operator RAN Introduction This feature is delivered on top of RAS06. This feature enables operators using a shared RAN to connect multiple MSCs and SGSNs to an RNC and thus utilize the pool area configurations in their CN nodes. RAN sharing is implemented with the Multi-Operator RAN feature where the subscribers of different operators use cells in different carrier layers. Benefits for the operator This feature enables the benefits of Flexible Iu in a shared RAN. Flexible Iu provides CAPEX and OPEX savings resulting from efficient CN resource utilization and load balancing. Increased service availability and better network resilience improve the end experience.

1.15.2

Functional description Multi-Operator RAN allows two operators to share physical RNCs and BTSs. The operators have their own CN nodes, which are connected to the shared RNC. The subscribers of different operators use cells in different carrier layers (frequencies). The differentiation is based on the Mobile Country Code (MCC) and Mobile Network Code (MNC) of the cell. Each cell has MCC and MNC corresponding to the operator. The Flexible Iu feature provides a standardised mechanism for connecting multiple CN nodes to an RNC within a single operator network. The feature s the use of pool areas where a UE may roam freely within a pool area (in either connected or idle mode) without the need to change the CN serving node. The pool area configurations are done in the CN nodes. Flexible Iu is based on the NAS Node Selector function (NNSF), which is used for selecting the CN node for the UE. The UE derives the value of the parameter NRI from the (P)-TMSI or IMSI and sends the NRI to the RNC in the Initial Direct Transfer message. The RNC selects the CN node corresponding to the NRI value configured in its database. When Multi-Operator RAN and Flexible Iu are used simultaneously, the RNC first selects the subscriber's operator from the MCC and MNC of the cell where the Initial Direct Transfer message was received. The RNC then selects the CN node, which corresponds to the NRI value included in the Initial Direct Transfer message. The CN node is selected only among the ones belonging to the subscriber's operator. This feature also s CN node recovery functionality, which balances the load between the CN nodes of a pool in different cases, for example, with CN node failure, SW/HW update or adding or removing a CN node to/from the pool. The load balancing is carried out between the CN nodes of each operator separately.

DN70296245

Id:0900d80580608fae Confidential

67


1.15.3 1.15.3.1

System impact Current implementation This is a new feature enabling simultaneous use of Multi-Operator RAN and Flexible Iu features.

1.15.3.2

Interdependencies between features Multi-Operator RAN and Flexible Iu features are needed for this feature.

1.15.3.3

Operational aspects In total, 16 CS and 16 PS interfaces per RNC are ed. Each operator can configure the NRI values in their network independently. Each operator can monitor their own part of MORAN via PLMN (MCC+MNC) information in PM measurement objects.

1.15.3.4


1.15.3.5


Relea se

1.15.3.6

68

RAS

RNC

BTS Ultra

RAS0 6 On top1

RN3.0 On top

BTS Flexi

AXC

NetAc MSC t

SGSN

MGW

UE

-

-

-

-

-

-

-


RAS SW component



OSW

RAN

-

-

Id:0900d80580608fae Confidential

DN70296245


1.16 1.16.1

g

RAN928: Directed Retry Introduction This feature is delivered on top of RAS06. RAN928: Directed Retry initiates a handover to the GSM network in case congestion is met in WCDMA RAN. It is performed i if a UE is trying to establish a voice call in a WCDMA cell which is fully loaded. Benefits for the operator This improves KPIs concerning call setup success rate. The connections that would face congestion in the AMR call RAB setup phase are directed to the GSM system to continue the connection setup.

1.16.2

Functional description The RAN928: Directed Retry feature makes an inter-system handover to the GSM system in case congestion is met in the source cell of RAN. It is done for NB-AMR and WB-AMR calls. If a connection includes other RABs in addition to the AMR RAB no directed retry is made. The directed retry takes place when the AMR RAB is set up. The RNC indicates an attempt to GSM by sending a RAB ASSIGNMENT RESPONSE message with a RAB ID included in the list of RABs failed to set up and a cause value of "Directed Retry". After that the RNC begins a relocation by sending a RELOCATION REQUIRED message to the Core Network with the cause value "Directed Retry" and Cell Global ID to indicate the target cell. The handover is blind because no inter-RAT measurements are performed for the connection in question before the handover. The target cell is always the first GSM cell in the neighbour list of the source cell.

1.16.3 1.16.3.1


1.16.3.2 RAS Release

Software requirements RNC

RAS06 ED1 RN3.0

DN70296245

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

-

-

-

-

-

-

-

-


69


1.16.3.3

1.16.3.4


RAS SW component



ASW

RAN

-

-

Management plane Management data

70

Parameters

Counters

Alarms





DN70296245


1.17 1.17.1

RAN992: HSUPA Congestion Control Introduction The HSUPA Congestion Control was originally introduced in 3GPP Technical Report to handle Iub transport related congestions. The standards provide means of congestion detection and indication but they leave the actual mechanism for the vendors to decide. The tools that the standards provide can detect delay originated congestion and transport-integrity originated congestion. The HSUPA Congestion Control also aims to balance the workload of the RNC introduced by processing of the uplink traffic coming from the UEs. Congestion control for high speed uplink is a critical feature in the sense that a situation where RNC can’t handle all the traffic generated by all the s is avoided. Congestion can occur on the transport path to the RNC or inside the RNC. In both cases it is the responsibility of the RNC to take action to reduce the congestion. Whatever the source of congestion is, the RNC must send indication to the originator of the excess traffic. Benefits for the operator This feature prevents packet losses because of congestion in the Iub or RNC and allows sensible Iub and RNC dimensioning. Lower rush hour E-DCH transmission delay as well as higher rush hour per throughput is expected because of congestion control (in comparison to a non-congestion control enabled network). E-DCH s are expected to have fair share of Iub transport resources and thus higher multiplexing ratios can be applied. The solution also protects the RNC HW from getting into an undesired level of load to guarantee the optimum usage of resources. The operator can monitor the frequency of congestion indications to decide whether the capacity of Iub interface is on an adequate level. This helps to decide when it is time to upgrade the transport capacity of Iub. The operator knows when the RNC processing resources are getting loaded according to the related counters. Based on this information the operator can upgrade the RNC capacity to increase service availability to the customers.

1.17.2

Functional description Architecture The feature HSUPA Congestion Control consists of multiple detection entities separated into different parts of the system. Intention is to provide full coverage of congestion prevention over the system. The main entities of interest are Iub in of transport capabilities and the RNC in of processing resources. For Iub the congestion detection is based on delay related measurements and data loss measurements. For RNC processing resource related detection the measurements are based on the ability of RNC HW to handle the processing load. The RNC HW load can be divided into buffer filling degree based detection, load level based detection and into data turnaround time based detection mechanisms. The HSUPA CC system level architecture is depicted in Figure HSUPA CC system level architecture. The Iub transport originated congestion is detected according to delay variation measurements taken form each E-DCH frame. Also data loss detection is implemented to

DN70296245


71


control situations where transport is already too congested to take care of the entire injected load. These detection mechanisms work on FP bearer basis. This means that for a single HSUPA there can be multiple (one for each soft handover branch of the ) detection entities working to prevent transport-originated congestion. The actual control of the congestion is applied on Iub basis in a sense since each FP bearer on the Iub is equally likely to get controlled (presuming that these bearers share the same level of priority, e.g. QoS). HSUPA Congestion Control is described in detail in Section Algorithms. Core Network

RNC PPC HW CC DSP HW CC Iub

Data

FP CC

FP CC

Node B

Iub

Congestion Control Information

Figure 2

Iub FP CC

Node B

Node B

HSUPA CC system level architecture

Note that FP branches are Iub specific which means that softer branches are always combined in Node B. The HW overload CC part of the HSUPA CC is logically implemented inside RNC L2 plane processing unit. Two processors are involved in plane processing on this level and these are the units to get overloaded when excess data are injected into the RNC. For each of these processors, namely DSP and PPC, there is a mechanism to detect and control the load level. The function of these HW CC entities is to proactively control the rate of incoming data to prevent load levels where data would be lost. However, in this case the control is mostly restricted to HSUPA data only. The actual control of congestion state is handled for each Iub separately and the entity in charge is the RNC E-DCH FP. This entity decides what type of indication is sent and when this indication should be sent. In this architecture the RNC is the master of the procedure and the Node B acts as an executor of the congestion control. When the Node B receives congestion indication, it starts the procedure of reducing the resources allocated for the given UE. This procedure is handled by the E-DCH packet scheduler. The resources are kept reserved during the congestion situation so that resources are not given to other UEs. The resources are released and reallocated when RNC indicates that the congestion is over. Algorithms Transport delay variation based algorithm:

72


DN70296245


The algorithm is based on well-known probability-based MECN. The probabilities of basic MECN are adapted to meet the target level of delay variation on the Iub. Figure Probability functions of MECN shows the probability functions used in MECN algorithm as well as how the evaluated probabilities are used to select the Congestion Indication (CI) type to be sent to Node B. CIs are studied more in Section Congestion indicators. MECN involves two probability functions P1 and P2 (functions of delay variation). P1 is used to send an indication with lesser effect on the bit rate reduction and P2 is used to send the indication with greater effect on the bit rate. On the delay variation range from Thmin to Thmid only indication according to P1 are sent. However, on the delay variation range from Thmid to Thmax, the probability is first evaluated for the P2 function and in a case of failed probability check, the P1 probability is evaluated consequently. The target delay variation level is set to just a bit above the Thmin threshold parameter. This delay variation level is set to guarantee optimal usage of the Iub transport in load situations. P (t) 1

P max

Th min No congestion

Figure 3

Th mid

Th max

Send CI according to

Send CI according to

probability P1 (t) with delay buildup status

P 2 (t) (frame loss) or

Delay (t)

Send CI with frame loss status

P 1 (t) (delay buildup)

Probability functions of MECN

The delay variation, which is the quantity of interest here, is defined as follows: Δd(n) = RNC_t(n) - RNC_t(n-1) - (NB_t(n) - NB_t(n-1)) where RNC_t(n) equals the arriving time of a frame and NB_t(n) equals the sending time from Node B (contained in the E-DCH data frame). This delay variation, Δd(n), is then averaged with a suitable filter to discard outlier measurements. Table Interpretation of delay variation amount with respect to MECN threshold parameters describes how the amount of delay variation should be understood with respect to the MECN algorithm threshold parameters.

DN70296245

Delay variation range

Interpretation

Δd < Thmin

The system operates at low workload.


73


Delay variation range

Interpretation

Thmin ≤ Δd ≤ Thmid

The system operates at typical load level where the operation is close to optimal workload. The target level of delay variation lies here. Somewhat congested state can be seen close to Thmid.

Thmind ≤ Δd ≤ Thmax

The system becomes heavily congested and more forceful actions are needed to protect the system from losing integrity.

Thmax ≤ Δd

The system is severely congested and cannot operate as intended.

The benefits of the algorithm, described here, are the following: 1. Global flow synchronizsation is avoided (all flows do not react at the same time to congestion which could be harmful in of stability). 2. Fairness is guaranteed among the connections sharing the physical transport (the same rules are applied for each connection). 3. Distributed decision making (no information needs to be transmitted between decision entities) Transport integrity based detection: Transport integrity is measured by detecting whether the frames arriving in sequence (in-sequence delivery is guaranteed) are all received in the RNC. The E-DCH FP frame includes a sequence number which is maintained for each branch separately. Gaps can be easily detected from this sequence number. A frame loss is considered a severe overload on the Iub transport and thus the heavier bit rate reduction principles are used in this context. For information on the indication types, see Section actions. HW overload detection: HW overloads can occur in many forms but the common factor for all such cases is that eventually data is going to be lost if no actions are taken to handle the situation. To make the system to work in a sophisticated way and to make use of all the processing capacity, some proactive operations are needed to control the congestion. The principles applied for HW overload detection are the following: 1. Processing of a frame should take less time than it takes a new frame to arrive into the processing unit. 2. If the previous case does not happen, the buffers storing the data should not overflow. 3. If any of the previous cases can not be guaranteed, the sender of the data (Node B) should stop sending for a while to let the processing unit solve the congestion situation. The mechanism applied for processing delay based detection are similar to the one described for transport delay variation based detection in Section Transport delay variation based algorithm. Buffer filling degree-based detection is applied to avoid buffer overflow situations.

74


DN70296245


Algorithm parameters Table Value ranges of MECN parameters describes the usage and value ranges of different MECN algorithm parameters. Parameter

Typical value range

Description

Thmin

[1ms, 3ms]

Minimum threshold for MECN algorithm to become operational.

Thmid

[2ms, 6ms]

Middle threshold for MECN algorithm.

Thmax

[3ms, 10ms]

Maximum threshold for MECN algorithm.

Pmax

[0.01, 0.50]

Maximum probability of CI sending in the operational range.

Table 4

Value ranges of MECN parameters

There are few restrictions on how the parameters should be set so that the algorithm functions as intended. These are Thmin < Thmid < Thmax and 0.01< Pmax < 0.50. Typically some kind of relation is used between the delay variation parameters. A default setting for this relation is defined as 3 ⋅ Thmin = 3/2 ⋅ Thmid = Thmax but it should be varied according to the case. Congestion indicators The Congestion Indication is a 3GPP frame protocol control frame with ability to indicate two levels of congestion. The CI frame is also capable of indicating resolved congestion situation. In general the first level of indicated congestion is used for proactive operation of the algorithms and the second level is used to take more control of the bit rate reduction. However, the first level indication is called ‘delay buildup’ CI and the second level indication is called ‘frame loss’ CI. The use of these indications is not tied to their names. The CI sending frequency of the algorithm is proportional to the delay variation amount as indicated by the probabilities (see Section Algorithms). However, the maximum per connection CI sending frequency is limited to keep the system stable. The HW overload detection can trigger additional CI sending events. This mechanism can trigger also both types of indications to be sent. These indications are used in the same way as in the delay variation based detection. The first level of indication is used for proactive operation and the second level indication is used in a more serious situation. It must be noted that during normal operation the algorithm sends CIs with some low frequency and only when the CI sending frequency increases significantly from the typical, the system can be considered congested.

DN70296245


75


actions HSUPA Congestion Control does not require any actions in the typical meaning of the word. However, the algorithm parameters need to be configured to reflect the transport characteristics. Typically these characteristics do not vary a lot among different transport types or topologies but for optimal functioning of the algorithm some tuning might be required. See Section Algorithm Parameters for hints on parameter setting. Statistics Section Management data introduced the feature related statistics counters. Some information is given in Table Statistics usage and interpretation on how to use and interpret the gathered data. For correct interpretation it must be noted that these statistics are cell level accumulations over the measurement interval whose typical length is 60 minutes.

76

Counter

Linked algorithm/parameters

Interpretation

M1022C69IUB_DELAY_CC_ DELAY_IND

MECN/Thmin, Thmid, Thmax

Iub delay variation based algorithm operates at the typical (proactive) working range under load. Iub usage is close to optimal when this counter contains a non-zero (but not large) value. However, large value in this counter is expected coincidently with the ‘Frame loss’ CI counter.

M1022C72IUB_DELAY_CC_ FRAME_LOSS_IND

MECN/Thmid, Thmax

Iub delay variation based algorithm operates at the high Iub load range. Low value is expected in load situation. High value represents overloaded Iub transport and this could be an indication of under-dimensioned transport.

M1022C71IUB_LOSS_CC_F RAME_LOSS_IND

Iub integrity/No parameters

Frames are lost in Iub transport. There is probably something wrong in resource allocation or dimensioning of Iub if this counter contains high values report after report. It could also be that there exists some physical problem in Iub.

M1022C70HW_OVERL_CC_ DELAY_IND

RNC HSUPA HW overload CC/No parameters

plane processing HW is acting proactively to control increasing load. Increase in this counter is typical when system is loaded. However, larger increase in counter value is an indication of becoming HW overload.


DN70296245


Counter

Linked algorithm/parameters

Interpretation

M1022C73HW_OVERL_CC_ FRAME_LOSS_IND

RNC HSUPA HW overload CC/No parameters

plane processing HW is heavily overloaded. There is probably something wrong in resource allocation or dimensioning of RNC if this counter contains high values report after report.

M1022C77SUCC_REC_EDC H_FRAMES

None

This counter contains the exact number of successively received data.

M1022C76DELAYED_EDCH _FRAMES

MECN/Thmin

Interpretation is similar to the explanations above (including both delay variation cases) of MECN based algorithm. This counter contains the exact number of all the delayed frames.

M1022C75MISSED_EDCH_F Iub integrity RAMES

Interpretation is similar to the explanation above about Iub integrity CI counter. This counter contains the exact amount of lost frames.

Feature activation HSUPA Congestion Control is part of the HSUPA solution and thus no activation procedure is required. However, the parameter setting requires some actions (see Section actions). For more information, see Activating Basic HSUPA and HSUPA Basic RRM.

1.17.3 1.17.3.1

System impact Current implementation This feature is implemented in RAS06.

1.17.3.2

Hardware requirements This feature requires RN3.0 RNC and WBTS4.0 Node B hardware deliveries.

1.17.3.3

Interdependencies between features This feature is part of HSUPA implementation and it is going to be implemented with RAN826 Basic HSUPA and RAN968 HSUPA BTS Packet Scheduler.

1.17.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

RAS06

RN3.0

WBTS4.0

WBTS4.0

-

-

-

-

-

DN70296245


UE

77


1.17.3.5

1.17.3.6


RAS SW component



OSW

HSPA

-

-

Control and plane HSUPA Congestion Control performs 3GPP Release 6 compliant signalling using FP control frames during and at the end of the congestion situation. This signalling is unidirectional – from SRNC to Node B without acknowledgements. For more information, see Figure HSUPA Congestion Control signalling for signalling scenario.

Node B

SRNC

TNL CONGESTION INDICATION

Figure 4

HSUPA Congestion Control signalling

Node B uses the standard 3GPP Release 6 E-DCH data frame header fields to include HSUPA Congestion Control related information. Without these information elements congestion control cannot be performed. The RNC can perform HSUPA Congestion Control with other vendors’ Node Bs if these Node Bs use the standard interfaces for implementing the feature.

1.17.3.7

Management plane NMS interfaces Impact on planning tool: No impact. Impact on management tools: No impact. Impact on radio network configuration management tool: Iub transport delay variation-based algorithm parameters are configured in the management tool. Impact on transport network configuration management tool: No impact. Impact on reporting tools: New counters are added into NetAct for HSUPA Congestion Control. Impact on monitoring tools: No impacts on real time monitoring tools. Impact on optimising tools:

78


DN70296245


No impact. Network element interfaces HSUPA Congestion Control related counters are added to the OMS Element Manager and NetAct interfaces. Also configuration management interface is updated to handle the new parameters (see Section Management data for available counters and parameters). See Nokia NetAct Product Documentation for more detailed information on interface impacts. Management data Parameters

Counters

Alarms

Maximum Threshold for HSUPA congestion handling delay

DELAY BUILDUP INDICATIONS SENT DUE TO IUB DELAY


Middle Threshold value for HSUPA congestion delay

DELAY BUILDUP INDICATIONS SENT DUE TO HW OVERLOAD

Minimum Threshold value for HSUPA congestion - delay ProbabilityFactor for Congestion Indication sending

FRAME LOSS INDICATIONS SENT DUE TO TRAFFIC LOSS FRAME LOSS INDICATIONS SENT DUE TO IUB DELAY FRAME LOSS INDICATIONS SENT DUE TO HW OVERLOAD MISSED E-DCH FP FRAMES DELAYED E-DCH FP FRAMES SUCCESSFULLY RECEIVED E-DCH FP FRAMES SUCCESSFUL E-DCH FP BRANCH SETUP

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

1.17.3.8

Impact on system performance and capacity This feature has no impacts to existing functionality but the impacts to HSUPA performance are greatly positive. HSUPA delays, average data rates and data integrity figures are positively affected in a loaded system. HSUPA s are expected to have fair share of transport resources and thus higher multiplexing ratios can be applied.

DN70296245


79


1.18 1.18.1

RAN1033: HSDPA 48 s per Cell Introduction The maximum number of simultaneous HSDPA s in a cell is increased to 48. Benefits for the operator CAPEX and OPEX savings are achieved by increasing the number of simultaneous HSDPA end s in a cell. Instant access to data services after momentary inactivity periods improves the end- experience.

1.18.2

Functional description This feature allows 48 simultaneous HSDPA s per cell. This consumes the whole UltraSite WSPC card/Flexi WCDMA BTS submodule per cell. A higher number of s allows higher volumes to be served. The end- experience is improved in any ON/OFF type of service, that is, a service with momentary inactivity periods, since a higher number of s can be kept on cell_DCH state for longer periods. Such services are, for example, web or WAP browsing and gaming.

1.18.3 1.18.3.1

System impact Current implementation Currently, the maximum number of simultaneous HSDPA s per cell is 16. This is achieved by dedicating 32 Channel Elements (CE) from one UltraSite WSPC card/Flexi WCDMA BTS sub-module for each HSDPA capable cell.

1.18.3.2

Hardware requirements WSPC card per HSDPA scheduler is required in UltraSite WCDMA BTS.

1.18.3.3

Interdependencies between features WSPC card per HSDPA scheduler is required in UltraSite BTS.

1.18.3.4


Relea se

80

RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAc MSC t

SGSN

MGW

UE

RAS0 6

RN3.0

WBTS 4.0

WBTS 4.0

-

OSS4. 2

-

-

3GPP Rel-5


DN70296245


1.18.3.5

1.18.3.6


RAS SW component



ASW

HSPA

RNC LK



New KPIs for average number of HSDPA s New KPIs for peak number of HSDPA s


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


Counters

Alarms

HSDPA 48 s enabled

DURATION OF ACTIVE HSDPA S - 17 TO 20 SIMULTANEOUS S


DURATION OF ACTIVE HSDPA S - 21 TO 24 SIMULTANEOUS S DURATION OF ACTIVE HSDPA S - 25 TO 28 SIMULTANEOUS S DURATION OF ACTIVE HSDPA S - 29 TO 32 SIMULTANEOUS S DURATION OF ACTIVE HSDPA S - 33 TO 36 SIMULTANEOUS S DURATION OF ACTIVE HSDPA S - 37 TO 40 SIMULTANEOUS S DURATION OF ACTIVE HSDPA S - 41 TO 44 SIMULTANEOUS S DURATION OF ACTIVE HSDPA S - 45 TO 48 SIMULTANEOUS S

DN70296245


81


1.19

1.19.1

g

RAN1727: Enhancement to HSDPA with Simultaneous AMR Voice Call Introduction This feature is delivered on top of RAS06. This feature adds 128 and 384 kbps UL DCH bit rate for HSDPA return channel with simultaneous AMR call. Benefits for the operator Better end experience for HSDPA s due to higher throughputs with AMR voice calls.

1.19.2

Functional description All the HSDPA return channel UL DCH data rates: 16, 64, 128 and 384 kbps are also ed with simultaneous AMR call.

1.19.3 1.19.3.1

System impact Current implementation Currently the ed data rates in UL are 16 and 64 kbit/s for HSDPA return channel if AMR call is on.

1.19.3.2

Interdependencies between features This feature requires HSDPA with Simultaneous AMR Voice call feature RAN827.

1.19.3.3

Operational aspects Counters already exist for monitoring the setup and allocations of AMR DCH + DCH/HSDSCH.

1.19.3.4


1.19.3.5


Relea se

82

RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAc MSC t

SGSN

MGW

UE

RAS0 6 On top

RN3.0 WBT On top S4.5

WBT S4.5

-

OSS 4.2

-

-

3GPP Rel-5

Id:0900d80580608fb7 Confidential

-

DN70296245


1.19.3.6

DN70296245


RAS SW component



OSW

RAN

-

-

Id:0900d80580608fb7 Confidential

83


1.20 1.20.1

RAN1515: HSPA Inter-RNC Cell Change Introduction HSPA inter-RNC cell change introduces seamless HSPA mobility between RNCs. HSPA serving cell is directly changed from source RNC to target RNC. Benefits for the operator Improved end- experience is achieved. HSPA high data rates can be maintained in RNC border areas. HSPA capacity gains can be achieved also in RNC border areas, reducing CAPEX.

1.20.2

Functional description When intra-frequency measurements indicate that the strongest cell in the active set is located under the DRNC, HSPA intra-frequency inter-RNC cell change is executed. Triggering point for inter-RNC cell change can be specifically defined by the operator by management parameters. Functionality applies both to HSDPA and HSUPA. HSPA intra-frequency inter-RNC cell change utilises SRNS relocation with UE involvement, meaning that UE is reconfigured according to the target RNC resources during SRNS relocation. Source RNC deletes the old configuration after succesful SRNS relocation. HSPA serving cell change (serving HS-DSHC/E-DCH cell change) is combined with SRNS relocation. HSPA data flow is not established over Iur-interface but HSPA resources are reserved and allocated under DRNC in conjunction of the SRNS relocation. DCHs for SRBs and UL return channel can be set up over Iur interface, whereas HS-DSCH and E-DCH are not used over Iur interface. HSPA inter-RNC cell change is ed also when Iur interface is disabled, congested or does not exist.

1.20.3 1.20.3.1

System impact Current implementation HSPA service is switched to DCH at the RNC border area.

1.20.3.2


1.20.3.3

Interdependencies between features Features RAN828: HSDPA Serving Cell Change and RAN829: HSDPA Soft/softer Handover for Associated DPCH are required.

1.20.3.4

Release

84


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

-

-

-

-

-

3GPP Rel-6

Id:0900d80580608fd2 Confidential

DN70296245


1.20.3.5

1.20.3.6


RAS SW component



ASW

HSPA

RNC LK



DN70296245

Parameters

Counters

Alarms


There are counters related to resource reservations, interRNC HHOs, and Packet Session allocations


Id:0900d80580608fd2 Confidential

85


1.21 1.21.1

RAN852: HSDPA 15 Codes Introduction RAN852: HSDPA 15 Codes allows higher peak rates as well as larger capacity. The average cell throughput is increased by about 50% in a macro cell environment compared to having 5 codes. The peak bit rate for single is 7.2 Mbps. Peak cell level total throughput is 10.8 Mbps (with code multiplexing). If features RAN1249: HSDPA 10 Mbps per and RAN1305: HSDPA 14.4 Mbps per Cell are activated then the figures are 10 Mbps per and 14.4 Mbps per Cell. Benefits for the operator Higher data rates improve the end- experience. HSDPA 15 codes provides more cell capacity compared to HSDPA 10 codes solution. New data service availability results in increased revenue. Increased cell capacity means savings in CAPEX and OPEX.

1.21.2

Functional description RAN852: HSDPA 15 Codes feature is a further evolution of features RAN763: Basic HSDPA with QPSK and 5 Codes and RAN764: HSDPA 16 QAM allowing higher peak data rates and increased average cell throughput. The peak bit rate for single is 7.2 Mbps. The peak cell level total throughput is 10.8 Mbps (with code multiplexing). If features RAN1249: HSDPA 10 Mbps per and RAN1305: HSDPA 14.4 Mbps per Cell are activated then the figures are 10 Mbps per and 14.4 Mbps per Cell. Depending on the UE category, the RLC payload size of 640 bits may be used when RAN852: HSDPA 15 Codes is enabled. RAN852: HSDPA 15 Codes allows higher peak rates as well as larger capacity. The average HSDPA cell throughput depends on the maximum number of allocated HSPDSCH codes. When allocating the maximum of 10 HS-PDSCH codes, the average cell throughput is increased by about 30% in a macro cell environment compared to having only 5 HS-PDSCH codes. Allocating the maximum of 15 HS-PDSCH codes increases the average cell throughput by about 50% compared to the same 5-code reference scenario. In a frequency layer dedicated for HSDPA, the gains are significantly higher, as well as in micro cells.

1.21.3 1.21.3.1

System impact Current implementation HSDPA with 5 codes and 16QAM modulation allow 3.6 Mbps air interface peak rate.

1.21.3.2


86


DN70296245


1.21.3.3

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

-

OSS4.2

-

SGN3

-

3GPP Rel-5

1.21.3.4

1.21.3.5


RAS SW component



ASW

HSPA

RNC LK



Current RAN_KPI_0042 for HSDPA effiency is updated with the new counters. New RAN_KPI_0059 for SF code blocking rate. New KPI for HS-PDSCH code allocations.


The new HARQ transmission vs. retransmission (per increased HS-PDSCH code amounts) counters are added to the HSPA in WBTS Measurement. The counters produced by BTS are also viewable via OMS Element Manager.

OMS Element Manager: • •

DN70296245

The HS-PDSCH code reservation counters are added to the Cell Resource Measurement. The new SF request counters are added to the Cell Resource Measurement.


87


Management data Parameters Maximum number of HSSCCH codes


HS-PDSCH code adjustment period


Bit rate threshold for RLC PDU size 656 with HSDSCH


Number of HS-PDSCH codes for greater RLC PDU size


Table 5

88

Counters


Parameters, counter, alarms


DN70296245


Parameters

Counters

SIR threshold for RLC PDU size 656 with HSDSCH


Usage of RLC PDU size 656 with HS-DSCH

ORIGINAL MAC-HS PDU TRANSMISSION WITH 11 CODE BY QPSK

NRT DPCH over HSPDSCH code offset


HS-PDSCH code upgrade margin for SF128 codes


Maximum bit rate of NRT MAC-d flow


Alarms

ORIGINAL MAC-HS PDU TRANSMISSION WITH 15 CODE BY QPSK ORIGINAL MAC-HS PDU TRANSMISSION WITH 11 CODE BY 16QAM ORIGINAL MAC-HS PDU TRANSMISSION WITH 12 CODE BY 16QAM ORIGINAL MAC-HS PDU TRANSMISSION WITH 13 CODE BY 16QAM ORIGINAL MAC-HS PDU TRANSMISSION WITH 14 CODE BY 16QAM ORIGINAL MAC-HS PDU TRANSMISSION WITH 15 CODE BY 16QAM MAC-HS PDU RETRANSMISSION WITH 11 CODE BY QPSK MAC-HS PDU RETRANSMISSION WITH 12 CODE BY QPSK MAC-HS PDU RETRANSMISSION WITH 13 CODE BY QPSK MAC-HS PDU RETRANSMISSION WITH 14 CODE BY QPSK Table 5

DN70296245

Parameters, counter, alarms (Cont.)


89


Parameters

Counters

Alarms

MAC-HS PDU RETRANSMISSION WITH 15 CODE BY QPSK MAC-HS PDU RETRANSMISSION WITH 11 CODE BY 16QAM MAC-HS PDU RETRANSMISSION WITH 12 CODE BY 16QAM MAC-HS PDU RETRANSMISSION WITH 13 CODE BY 16QAM MAC-HS PDU RETRANSMISSION WITH 14 CODE BY 16QAM MAC-HS PDU RETRANSMISSION WITH 15 CODE BY 16QAM Table 5

90

Parameters, counter, alarms (Cont.)


DN70296245


1.22

1.22.1

RAN1013: 16 kbit/s Return Channel DCH Data Rate for HSDPA Introduction The uplink (UL) dedicated channel (DCH) data rate of 16 kbit/s for high-speed downlink packet access (HSDPA) return channel is ed. Benefits for the operator OPEX and CAPEX savings can be achieved by more flexible resource allocations for HSDPA.

1.22.2

Functional description This feature adds 16 kbps data rate to the set of data rates available for an HSDPA ULassociated DCH. As a result, the enabled data rates are 16 kbps, 64 kbps, 128 kbps and 384 kbps. Radio resource management (RRM) features RAN242: Flexible Upgrade of NRT DCH Data Rate and RAN409: Throughput-based Optimisation of the Packet Scheduler Algorithm control the dynamic selection of HSDPA UL-associated DCH data rate according to actual utilisation of the channel. The utilisation thresholds controlling the bit rate upgrades and downgrades are operator-configurable. In case of baseband congestion, feature RAN395: Enhanced Priority Based Scheduling and Overload control for NRT Traffic downgrades the existing DCH(s) to a lower data rate. With growing traffic, the existing DCHs are downgraded from higher data rates eventually down to 16 kbit/s until the maximum number of s in the BTS is achieved. This feature provides flexibility for using HSDPA resources. High bit rates can still be achieved with a low number of WSPs either with low load or by adjusting the minimum allowed bit rate of the UL DCH to 64 kbit/s (less s). By having 16 kbit/s data rate ed for HSDPA return channel, the operator can optimise the BTS WSP resource consumption. Similarly, transport resources are saved, as overbooking functions more efficiently when there is more granularity on the nominal bit rates. 16 kbps UL-associated DCH is ed also together with AMR/WB-AMR voice call.

1.22.3 1.22.3.1

System impact Current implementation Prior to this feature, the ed data rates for HSDPA UL-associated DCH are 64 kbps, 128 kbps and 384 kbps.

1.22.3.2


DN70296245

Id:0900d8058095890b Confidential

91


1.22.3.3

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

-

OSS4.2

-

-

-

3GPP Rel-5

1.22.3.4

1.22.3.5


RAS SW component



ASW

HSPA

RNC LK



New RAN_KPI_0071 for HS-DSCH Session Setup Success Existing RAN_KPI_0038 for HS-DSCH Resource Setup Success New KPIs for 16 kbit/s return channel usage


The new 16 kbit/s return channel counters will be added to the Traffic Measurement. The HS-DSCH resource reservation counters are already existing in Traffic Measurement. The new HS-DSCH session counters are found in the new Packet Call Measurement.


Counters

Alarms

HSDPA 16 kbps UL DCH return channel on/off switch

HS-DSCH 16 KBPS RETURN CH ALLOCATIONS FOR INTERACTIVE


HSDPAminAllowedBitrateUL HSDPAinitialBitrateUL

HS-DSCH 16 KBPS RETURN CH ALLOCATIONS FOR BACKGROUND HS-DSCH 16 KBPS RETURN CH DURATION FOR INTERACTIVE HS-DSCH 16 KBPS RETURN CH DURATION FOR BACKGROUND HS-DSCH 16 KBPS RETURN CH IUB TRANSPORT SETUP FAILURE FOR INTERACTIVE HS-DSCH 16 KBPS RETURN CH IUB TRANSPORT SETUP FAILURE FOR BACKGROUND

92


DN70296245


1.23 1.23.1

RAN979: HSUPA 2.0 Mbps Introduction The highest ed peak rate on E-DCH is 2.0 Mbps, corresponding to two parallel codes of spreading factor two (2xSF2) and 10 ms TTI. Benefits for the operator HSUPA peak rate is increased to up to 2.0 Mbps per .

1.23.2

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

1.23.3 1.23.3.1

System impact Current implementation The highest ed peak rate on E-DCH is 1.44 Mbps, corresponding to two parallel codes of spreading factor four (2xSF4) and 10 ms TTI.

1.23.3.2


Release

1.23.3.3


1.23.3.4


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

-

OSS4.2

-

SGN3

-

3GPP Rel-6

1.23.3.5

DN70296245


RAS SW component



ASW

HSPA

RNC LK



93


1.23.3.6


The new RAN_KPI_0075 follows the average HSUPA cell throughput. The new RAN_KPI_0080 follows the HSUPA cell throughput data volume. New KPIs for E-DCH RLC Throughput data volumes and data distribution.


There will be new extended RLC Throughput Distribution counters added to the RM RLC AM Measurement. There are already existing basic RLC Throughput (PDU) counters in the RM RLC AM Measurement. There will be new E-DCH (MAC-es) throughput counters in the new Cell Throughput Measurement.

Management data

94

Parameters

Counters

Alarms





DN70296245


1.24 1.24.1

RAN970: HSUPA Handovers Introduction This feature brings soft/softer handovers and serving cell changes for HSUPA s allowing HSUPA in the whole cell coverage area and between the cells. Benefits for the operator This feature enables full mobility for the HSUPA s and widens the coverage area of a given bit rate. The gain is significant especially with high bit rates. Soft handover (SHO) gain for E-DCH is similar in magnitude to traditional R99 DCH SHO.

1.24.2

Functional description The following intra-frequency soft/softer handovers are ed for E-DCH: • •

Intra-BTS intra-RNC softer handover Inter-BTS intra-RNC soft handover

In case of SHO, the active set for DCH can be different from the active set for E-DCH. This allows adding a cell not ing E-DCH into the active set. In addition, in case of inter-BTS inter-RNC soft handover, the E-DCH will not be configured to a SHO branch under the drift RNC. The serving E-DCH cell follows the serving cell for HS-DSCH of the UE. Thus, the algorithms of HSDPA are followed. The HS-DSCH and E-DCH serving cell is always the same cell. DCH to E-DCH channel switching is carried out if there is a need to change the serving DCH cell into a cell ing E-DCH. E-DCH to DCH channel switching is carried out if there is a need to change the serving E-DCH cell into a cell not ing E-DCH or a cell under the drift RNC. E-DCH to DCH channel switching is also needed before compressed mode is activated for inter-frequency or inter-system measurements. E-DCH to DCH channel switching is carried out if there is a need to change the serving E-DCH cell into a cell not ing E-DCH or a cell under the drift RNC. E-DCH to DCH channel switching is also needed before compressed mode is activated for inter-frequency or inter-system measurements.

1.24.3

Release

System impact

1.24.3.1

Hardware requirements

1.24.3.2


1.24.3.3


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

-

OSS4.2

-

-

-

3GPP Rel-6

DN70296245

Id:0900d8058095890f Confidential

95


1.24.3.4

1.24.3.5


RAS SW component



OSW

HSPA

-

-


New RAN_KPI_0066 for HSUPA Serving Cell change. New KPIs for HSUPA AS followup.


The new E-DCH Serving Cell Change counters will be added to the Intra System Hard Handover Measurement. The new HSUPA AS counters will be added to the Soft Handover Measurement.


Counters

Alarms

Allow E-DCH usage EcNo offset

ONE CELL IN E-DCH ACTIVE SET DURATION


ICH EcNo offset EDCH usage removal

TWO CELLS IN E-DCH ACTIVE SET DURATION

E-DCH channel type switch guard timer

THREE CELLS IN E-DCH ACTIVE SET DURATION

HSPA FMCS identifier

SOFTER HANDOVER DURATION ON THE SRNC SIDE FOR HSUPA MOBILITY CELL ADDITION ATTEMPT REQ BY UE TO E-DCH AS CELL ADDITION SUCCESS TO E-DCH ACTIVE SET CELL NOT ADDED TO E-DCH ACTIVE SET BUT ADDED TO DCH AS CELL ADDITION ATTEMPT RETRY TO EDCH AS E-DCH SERVING CELL CHANGES STARTED E-DCH INTRA BTS SERVING CELL CHANGES SUCCESSFUL E-DCH INTER BTS SERVING CELL CHANGES SUCCESSFUL E-DCH DOWNGRADED TO DCH IN SCC

96

Id:0900d8058095890f Confidential

DN70296245


1.25 1.25.1

RAN974: HSUPA with Simultaneous AMR Voice Call Introduction This feature provides both HSUPA services and AMR voice calls simultaneously. Benefits for the operator Simultaneous high speed data services and AMR voice calls in UL improve the end- experience.

1.25.2

Functional description PS data connection over E-DCH is ed simultaneously with AMR voice call over DCH. This ensures that an AMR voice call initiation does not influence the NRT service data flow.

1.25.3 1.25.3.1


1.25.3.2

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

-

OSS4.2

-

-

-

3GPP Rel-6

1.25.3.3

1.25.3.4


RAS SW component



ASW

HSPA

RNC LK



KPIs for multi-RAB usage related to E-DCH


DN70296245

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


97



Counters

Usage of AMR service with E- AMR + E-DCH ALLOCATIONS DCH HSPA FMCS identifier for AMR multi-service

98


AMR + E-DCH NORMAL RELEASE


DN70296245


1.26 1.26.1

RAN831: Wideband AMR Codec Set (12.65, 8.85, 6.6) Introduction Wideband AMR speech codec enhances audio bandwidth from 300Hz - 3.4 KHz to 50Hz - 7kHz, which improves the transparency of calls. Enhanced lower frequency response makes voice warmer whilst enhanced higher frequency response improves the intimacy of voice. Benefits for the operator Wideband AMR provides step-like improvement on voice quality over current telephony solutions without RAN capacity trade-offs since the bit rates are similar to AMR. The TrFO/TFO needed due to wideband AMR (WB-AMR) reduces the need of CN investments.

1.26.2

Functional description This feature s a set of WB-AMR codec modes 12.65, 8.85 and 6.6 kbps. WBAMR provides better speech quality than narrowband AMR (NB-AMR) and fixed lines (G.711 PCM) between WB AMR capable UEs. To avoid downsampling from 16kHz to 8kHz, yielding to quality degradation, either TFO or TrFO is needed. The RNC handles the WB-AMR modes as well as multi-RABs similarly to NB-AMR. The codec modes 12.65, 8.85 and 6.6 kbps form a set of bit rates (TFS) that is assigned to every WB-AMR call. The limited TFCS in multi-RAB cases, the functionality of TFO/TrFO and managing the Iu Mode are similar to the feature AMR Codec Sets (12.2, 7.95, 5.90, 4.75) and (5.90, 4.75).

1.26.3 1.26.3.1


1.26.3.2


Relea se

DN70296245

RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAc MSC t

SGSN

MGW

UE

RAS0 6

RN3.0

WBTS 4.0

WBTS 4.0

-

OSS4. M13.6 2

-

U3C

3GPP Rel-5

Id:0900d80580608fcf Confidential

99


1.26.3.3

1.26.3.4


RAS SW component



ASW

RAN



Existing RAN_KPI_0002 for AMR Service Setup Success includes automatically WAMR service setups Existing RAN_KPI_0006 for AMR Service Success includes automatically W-AMR service releases New KPIs for W-AMR usage


100

The counters are added to the Traffic Measurement.


DN70296245



Counters

Alarms

Configured CS WAMR mode sets

DCH ALLO FOR WAMR 12.65 KBPS IN SRNC


DCH ALLO FOR WAMR 6.6 KBPS IN SRNC DCH ALLO DURA FOR WAMR 12.65 KBPS IN SRNC DCH ALLO DURA FOR WAMR 6.6 KBPS IN SRNC DCH ALLO FOR WAMR 12.65 KBPS IN DRNC DCH ALLO FOR WAMR 8.85 KBPS IN DRNC DCH ALLO FOR WAMR 6.6 KBPS IN DRNC DCH ALLO DURA FOR WAMR 12.65 KBPS IN DRNC DCH ALLO DURA FOR WAMR 8.85 KBPS IN DRNC DCH ALLO DURA FOR WAMR 6.6 KBPS IN DRNC DCH MOD DUE TO SWITCHING FROM WAMR TO NAMR IN SRNC DCH MOD DUE TO SWITCHING FROM NAMR TO WAMR IN SRNC DCH MOD DUE TO SWITCHING FROM WAMR TO NAMR IN DRNC DCH MOD DUE TO SWITCHING FROM NAMR TO WAMR IN DRNC

DN70296245


101

Transmission and transport features


2 Transmission and transport features 2.1

RAS06 Transmission and Transport features See the following table for more detailed information on WCDMA RAN functionality and feature activation:

Feature

Other related descriptions

Related instructions

RAN1097: Ethernet Interface Unit IFUH (Iub Plane) for AXC

-

-

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

-

-

RAN1099: Dynamic Scheduling for HSDPA with Path Selection

Activating Dynamic Scheduling for HSDPA with Path Selection

RAN1100: Dynamic Scheduling for NRT DCH with Path Selection

RAN1100: Dynamic Scheduling for NRT DCH with Path Selection, Feature Activation Manual

RAN759: Path Selection

WCDMA RAN ATM Transport

Feature RAN759: Path Selection, Feature Activation Manual

RAN1096: Transport Bearer Tuning

Feature RAN1096: Transport Bearer Tuning, Feature Activation Manual

RAN1095: UBR+ for Iub Plane

Feature RAN1095: UBR+ for Iub Plane, Feature Activation Manual

RAN1319: Flexi WCDMA BTS IMA Based AAL2 Uplink CAC

-

-

RAN1063: Hybrid Backhaul with Pseudo Wires

-

-

RAN1142: ATM over Ethernet for BTS

-

-

Table 6


2.1.1

Reference documentation For information on the parameters, counters and alarms related to each feature, see the Management data section of the feature descriptions. For parameter descriptions, see: • • • • • • • • • •

102

WCDMA Radio Network Configuration Parameters IP Configuration Plan Interface Parameters for Multicontroller RNC OMS LDAP parameters AXC Parameters Flexi Transport Module Parameters Flexi Multiradio BTS WCDMA Parameters UltraSite BTS WCDMA Parameters Multicontroller Radio Network Configuration Parameters ATM Configuration Plan Interface Parameters Frequently Used Parameters of SS7 signalling over IP

Id:0900d805808f1cd8 Confidential

DN70296245


• • • • •


IP Configuration Plan Interface Parameters PRFILE Descriptions Radio Network Parameters in I-HSPA I-HSPA Adapter Signaling Plan Parameters Reference Information Service in NOLS for RNC parameters

For counter descriptions, see: • • • • • •

RNC Counters - RNW Part RNC Counters – Transport and HW Part WBTS Counters AXC Counters I-HSPA Adapter Measurements and Counters Reference Information Service in NOLS

For alarm descriptions, see: • • • • • • • • • • • • • • • • • • •

Multicontroller RNC Notices (0-999) Multicontroller RNC Disturbances (1000-1999) Multicontroller RNC Failure Printouts (2000-3999) Multicontroller RNC Alarms (70000-72000) IPA-RNC Notices (0-999) IPA-RNC Disturbances (1000-1999) IPA-RNC Failure Printouts (2000-3999) IPA-RNC Diagnosis Reports (3700-3999) Multicontroller RNC, IPA-RNC and I-HSPA Adapter Base Station Alarms (70009000) Troubleshooting Flexi WCDMA Base Station Flexi WCDMA Base Station Faults Troubleshooting UltraSite and MetroSite WCDMA Base Station UltraSite and MetroSite WCDMA Base Station Faults I-HSPA Adapter Notices (0-999) I-HSPA Adapter Disturbances (1000-1999) I-HSPA Adapter Failure Printouts (2000-3999) I-HSPA Adapter Alarms (70000-72000) OMS Alarms AXC Alarms

For information on license management, see Nokia Siemens Networks license management concept and its implementation in WCDMA RAN in License management in WCDMA RAN.

DN70296245

Id:0900d805808f1cd8 Confidential

103


2.2

2.2.1

RAN1097: Ethernet Interface Unit IFUH (Iub Plane) for AXC Introduction This feature belongs to AXC hardware and software. It implements the Ethernet interface unit (IFUH) for AXC, to connect the BTS to a packetswitched network. The IFUH is one of the building blocks of RAN1063: Hybrid Backhaul with Pseudo Wires. RAN1142: ATM over Ethernet for BTS is required to operate the Ethernet interfaces in order to convey Iub ATM traffic over a packet switched network. For RAN06 the IFUH will allow to transport up to 60 Mbit/s of ATM traffic encapsulated in Ethernet frames of up to 100 Mbit/s. The IFUH provides 2 Fast Ethernet (100Base-TX) interfaces and one optionally pluggable Gigabit Ethernet interface to connect the BTS to a packet-switched network. The interfaces operate in full duplex mode and have a LED connected each to display the connectivity status. Auto negotiation for the duplex mode is ed by default, but can be switched off too. All 3 Ethernet interfaces featured by the IFUH are based on the IEEE 802.3–2002 standard using the Ethernet II/DIX frame (i.e. interpretation of the type length field). In RAN06 the first of the fast Ethernet interfaces or the optical gigabit interface can be used to connect an IFUH to a packet switched network. The two remaining interfaces are intended for future extensions. The used interface s Ethernet VLAN according to IEEE 802.1Q. The VLAN IDs is configurable and programmable priority bits are ed. IPv4 according to is used for IP packets on the IFUH. The Ethernet MTU is fixed to 1500 octets which leads to a maximum Ethernet frame length of 1518 octets for plain Ethernet or 1522 octets for Ethernet using VLAN respectively. The 2 Fast Ethernet interfaces have RJ-45 connectors, operate via Category 5 (or better) twisted pair cables and Tx/Rx auto-detection. The optional optical Gigabit Ethernet interface comes as pluggable SFP module (SFP: Small Formfactor Pluggable Transceiver acc. to INF-8074i) equipped with an LC-connector. The SFP module has a class 1 laser. For safety reasons modules deploying different laser classes are prevented from being operated. The SFP module can be of two different flavours, which are either: • •

Long haul: 1000 Base-LX, typically up to 5000m distance achievable with SMF (single mode fibre), wavelength around 1300nm, or Short haul: 1000 Base-SX, typically up to 550m distance achievable; wavelength around 800nm.

The IFUH can be added to any AXC configuration in UltraSite Supreme and Optima cabinets, including the AXC Compact. In a system equipped with an AXUA/B the IFUH can be operated in any slot. In RAN06 only one IFUH per system is foreseen. In systems with an AXCC the IFUH has to be in the rightmost slot. The MetroSite and UltraSite GSM/EDGE BTS offer two AXC slots, one for an AXU, the second for an IFU. IFUH can also be used with these cabinets. This implies that syn-

104


DN70296245


chronization is provided through other means, for example, a 2MHz signal fed from a neighbouring GSM/EDGE BTS or a GPS receiver. Naturally this cannot be used for an AXCC IFUH combination as it would require three slots. The IFUH should not be used in stand-alone AXC configurations. Benefits for the operator UltraSite WCDMA BTS can be backhauled over packet-switched technologies, IP and Ethernet in particular. Operators can select from the full variety of IP and Ethernet services. As the current backhaul networks are ill-suited to backhaul the large bandwidths and high peak rates generated by HSPA Ethernet-based technologies have the potential to separate cost from capacity, particularly for higher bandwidths.

2.2.2

Functional description When an IFUH is installed in an AXC it can be configured to convey ATM cells encapsulated in IPv4 packets using either a Fast Ethernet or a Gigabit Ethernet interface. The configuration possibilities are described in RAN1142: ATM over Ethernet for BTS. The customer has to adapt the parameters listed in the Management data section to match the network setup of the customer. Activating the feature The IFUH will transport any data only after ing a license. The configuration, as described in RAN1142: ATM over Ethernet for BTS and in Management data can be done without license. Architecture Ethernet Interface Unit IFUH (Iub Plane) for AXC is one of the building blocks of the RAN1063: Hybrid Backhaul with Pseudo Wires. BTS is equipped with Ethernet and TDM interfaces. For more information, see RAN1063: Hybrid Backhaul with Pseudo Wires. The Pseudo Wire termination function is carried out by the AXC IFUH inside the BTS. The following figure depicts this configuration.

TDM Network

TDM I/F

ATM

TDM I/F ATM termination

PWE3 Gateway Ethernet I/F AXC

Tunnel

Packet Switched Network

nxSTM1 ATM

IFUH

BTS

Figure 5

TDM I/F

RNC

AXC IFUH Pseudo Wire terminating function

The IFUH actually is the PWE3 gateway inside the BTS.

DN70296245


105


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



Tunnel


2.2.3 2.2.3.1

TDM I/F

IFUH

BTS

Figure 6

nxSTM1 ATM

RNC

IFUH alternative operating scenario

System impact Current implementation This feature is implemented in AXC C3.0, which belongs to RAS06. Without this feature all data is carried via ATM over TDM based technologies (SDH/PDH).

2.2.3.2

Hardware requirements The IFUH hardware will be implemented to the functionality described in RAN1063: Hybrid Backhaul with Pseudo Wires and RAN1142: ATM over Ethernet for BTS. Requirements to IFUH HW AXC Sub rack RNC PWE3 site solution

2.2.3.3

Interdependencies between features This feature is needed to RAN1142: ATM over Ethernet for BTS and RAN1063: Hybrid Backhaul with Pseudo Wires. A similar feature for another NE (FTM) is RAN1064: Ethernet+E1/T1/JT1 Interface Unit (Iub Plane) for Flexi WCDMA BTS.

2.2.3.4

Software requirements This feature requires the AXC software to handle the new Ethernet Interface Unit (IFUH). The AXC software will furthermore all configuration management, fault management and performance monitoring data described in RAN1142: ATM over Ethernet for BTS and in the Management data section. Other Network elements will implement accordingly in releases:

106


DN70296245


• •

Release

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

RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

-

WBTS4.0

-

C3.0

OSS4.2

-

-

-

-

2.2.3.5

2.2.3.6


RAS SW component



OSW

RAN

-

-

Control and plane This feature has no impact on signalling interfaces.

2.2.3.7

Management plane NMS interfaces This feature requires the NMS to manage all data described in RAN1142: ATM over Ethernet for BTS plus the data listed in the Management data section. It does not change the behaviour of the interface itself. Network element interfaces The AXC Element Manager will the handling of the new Ethernet interface unit (IFUH) and all data described in RAN1142: ATM over Ethernet for BTS plus the data listed in the Management data section. Management data This feature itself adds a new unit type to the AXC management data. The AXC software additionally implements all data described in RAN1142: ATM over Ethernet for BTS. Additionally the AXC has to implement the following management data. Files File

Impact

*.aml

Parameters are ed in AXC configuration files (AML).

Table 7

Ethernet Interface Unit IFUH (Iub Plane) for AXC files impacts

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

DN70296245


107


File

Use

AcceptableFrameTypes

Controls if the VLAN Tag for the Ethernet interface is enabled or not.

VLAN_ID

Configures the used VLAN IDs used for the Ethernet interface.

Duplex Mode

Switches autonegotiation for the duplex mode on or off.

Table 8

Ethernet Interface Unit IFUH (Iub Plane) for AXC impact on parameters

Alarms The IFUH will detect and report the trouble condition described in the following table. Alarm

Description

LOS

Loss of signal.

Table 9

Ethernet Interface Unit IFUH (Iub Plane) for AXC impact on alarms

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

Counters

Alarms


EthIfInOcts_15


EthIfOutOcts_15 EthIfInPkt_15 EthIfOutPkt_15 EthIfInPktErr_15 EthIfInUnknownProtos_15 EthIfOutDiscShaping_15 EthIfInUnknownVLAN_15 EthUnknownPSNHdr_15

Signalling This feature has no impact on signalling.

2.2.3.8

Impact on system performance and capacity This feature has no impact on system performance or capacity.

2.2.3.9

Impact on mobile terminals This feature has no end- requirements.

108


DN70296245


2.3

2.3.1

RAN1064: Ethernet+E1/T1/JT1 Interface Unit (Iub Plane) for Flexi WCDMA BTS Introduction This feature belongs to FTM hardware and software. It implements the Ethernet + PDH interface unit (FTIA/FTJA) for FTM, to connect the BTS to a packet-switched network. These interface units combine four PDH interfaces and interfaces to connect to a packet-switched network. There are two types of interface units, as described below. • •

FTIA: Interface unit needed to the Ethernet interface in Flexi WCDMA BTS. E1/T1/JT1 interface with a symmetrical line is also provided. FTJA: Interface unit needed to the Ethernet interface in Flexi WCDMA BTS. E1 interface with a coaxial line is also provided.

The PDH part of these units is built similarly to the existing PDH interface units FTEB and FTPB. The rest of this document focuses on the Ethernet extensions of these units. The FTIA/FTJA is one of the building blocks of the RAN1063: Hybrid Backhaul with Pseudo Wires. RAN1142: ATM over Ethernet Application Software is required to operate the Ethernet interfaces in order to convey Iub ATM traffic over a packetswitched network. For RAS06 the FTIA/FTJA allows to transport up to 30,74 Mbit/s of ATM traffic via the Ethernet interface in uplink direction. In the downlink direction the overall capacity of the FTIA/FTJA is 70 Mbit/s of ATM. This is the sum of the Ethernet interface and the used Pdh interfaces. The resulting data rate on the Ethernet level is dependent on configuration, but up to 100Mbit/s. The FTIA/FTJA provides 2 Fast Ethernet (100Base-TX) interfaces and one optionally pluggable Gigabit Ethernet interface to connect the BTS to a packet-switched network. The interfaces operate in full duplex mode and have a LED connected each to display the connectivity status. Auto negotiation for the duplex mode is ed by default, but can be switched off too. All 3 Ethernet interfaces featured by the FTIA/FTJA are based on the IEEE 802.3–2002 standard ) using the Ethernet II/DIX frame (that is, interpretation of the type length field). In RAS06 one out of the three interfaces can be used to connect an FTIA/FTJA to a packet-switched network. The two remaining interfaces are intended for future extensions. The interfaces Ethernet VLAN according to IEEE 802.1Q. The VLAN IDs are configurable and programmable priority bits are ed. IPv4 is used for IP packets on the FTIA/FTJA. The Ethernet MTU is fixed to 1500 octets which leads to a maximum Ethernet frame length of 1518 octets for plain Ethernet or 1522 octets for Ethernet using VLAN respectively. The 2 Fast Ethernet interfaces have RJ-45 connectors, operate via Category 5 (or better) twisted pair cables and Tx/Rx auto-detection. The optional optical Gigabit Ethernet interface comes as pluggable SFP module (SFP: Small Formfactor Pluggable Transceiver according to INF-8074i) equipped with an LCconnector. The SFP module has a class 1 laser. For safety reasons modules deploying different laser classes are prevented from being operated. The SFP module can be of two different flavours, which are either:

DN70296245


109


• •

Long haul: 1000 Base-LX, typically up to 5000m distance achievable with SMF (single mode fiber), wavelength around 1300nm, or Short haul: 1000 Base-SX, typically up to 550m distance achievable; wavelength around 800nm.

Benefits for the operator Flexi WCDMA BTS can be backhauled over packet-switched technologies, IP and Ethernet in particular. Operators can select from the full variety of IP and Ethernet services. As the current backhaul networks are ill-suited to backhaul the large bandwidths and high peak rates generated by HSPA Ethernet-based technologies have the potential to separate cost from capacity, particularly for higher bandwidths.

2.3.2

Functional description When an FTIA/FTJA is powered up can be configured to convey ATM cells encapsulated in IPv4 packets using either a Fast Ethernet or a Gigabit Ethernet interface. For information on the configuration possibilities, see RAN1142: ATM over Ethernet for BTS. The parameter settings have to match the customers’ network setup. For information on the parameters, see Management data. Activating the feature The FTIA/FTJA will transport any data only after activating a license. Configuration, as described in RAN1142: ATM over Ethernet for BTS and in Management data, can be done without a license. Architecture Ethernet+E1/T1/JT1 Interface Unit (IUB Plane) for Flexi WCDMA BTS is one of the building blocks of RAN1063: Hybrid Backhaul with Pseudo Wires. As described in RAN1063: Hybrid Backhaul with Pseudo Wires, the BTS is equipped with Ethernet and TDM interfaces. The Pseudo Wire termination function is carried out by the FTM FTIA/FTJA inside the BTS. The following figure depicts this configuration:

TDM Network

4*TDM I/F

PWE3 Gateway Ethernet I/F

Tunnel


TDM I/F

ATM

ATM termination nxSTM1 ATM

TDM I/F

FTM Flexi WCDMA BTS

Figure 7

RNC

FTM FTIA/FTJA Pseudo Wire terminating function

The FTIA/FTJA actually is the PWE3 gateway inside the BTS. The FTIA/FTJA can also be operated in a scenario as shown in the following figure.

110


DN70296245




Tunnel


nxSTM1 ATM

IFUH

BTS

Figure 8

2.3.3 2.3.3.1

TDM I/F

RNC

FTIA/FTJA alternative operating scenario

System impact Current implementation This feature is implemented in FTM C3.0, which belongs to RAS06. Without this feature all data is carried via ATM over TDM based technologies.

2.3.3.2

Hardware requirements The FTIA/FTJA hardware will be implemented to the functionality described in RAN1063: Hybrid Backhaul with Pseudo Wires and RAN1142: ATM over Ethernet for BTS. Requirement FTM Unit (FTIA/FTJA) RNC PWE3 site solution

2.3.3.3

Interdependencies between features This feature is needed to RAN1142: ATM over Ethernet for BTS and RAN1063: Hybrid Backhaul with Pseudo Wires. A similar feature for another NE (AXC) is RAN1097: Ethernet Interface Unit IFUH (Iub Plane) for AXC.

2.3.3.4

Software requirements This feature requires the FTM software to handle the new Ethernet Interface Unit (FTIA/FTJA). The FTM software will furthermore all configuration management, fault management and performance monitoring data described in RAN1142: ATM over Ethernet for BTS and in Management data. Other Network elements will implement accordingly in releases: • •

DN70296245

Flexi WCDMA BTS 4.0 (containing FTM C3.0) OSS: OSS4.2


111


Release

RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

-

-

WBTS4. 0

-

OSS4.2

-

-

-

-

2.3.3.5

2.3.3.6


RAS SW component



OSW

RAN

-

-


2.3.3.7

Management plane NMS interfaces This feature requires NMS to manage all data described in RAN1142: ATM over Ethernet for BTS and in the Management data section. It does not change the behaviour of the interface itself. Network element interfaces The FTM Element Manager will the handling of the new Ethernet interface unit (FTIA/FTJA) and all data described in RAN1142: ATM over Ethernet for BTS and the data listed in the Management data section. Management data This feature itself adds a new unit type to the FTM management data. The FTM software additionally implements all data described in RAN1142: ATM over Ethernet for BTS. Additionally the FTM has to implement the following management data. Files File

Impact

*.tml

Parameters are ed in FTM configuration files (TML) too.

Table 10

Ethernet+E1/T1/JT1 Interface Unit (IUB Plane) for Flexi WCDMA BTS file impacts

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

112


DN70296245


File

Use

AcceptableFrameTypes

Controls if the VLAN Tag for the Ethernet interface is enabled or not.

VLAN_ID

Configures the used VLAN IDs used for the Ethernet interface.

Duplex mode

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

Table 11

Ethernet+E1/T1/JT1 Interface Unit (IUB Plane) for Flexi WCDMA BTS impact on parameters

Alarms The FTIA/FTJA will detect and report the trouble condition described in the following table. Alarm

Description

LOS

Loss of signal.

Table 12

Ethernet+E1/T1/JT1 Interface Unit (IUB Plane) for Flexi WCDMA BTSimpact on alarms

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

Counters

Alarms


EthIfInOcts_15


EthIfOutOcts_15 EthIfInPkt_15 EthIfOutPkt_15 EthIfInPktErr_15 EthIfOutDiscShaping_15 EthIfInUnknownVLAN_15 EthUnknownPSNHdr_15


2.3.3.8


2.3.3.9


DN70296245


113


2.4

2.4.1

g

RAN1099: Dynamic Scheduling for HSDPA with Path Selection Introduction The feature description of RAN1099: Dynamic Scheduling for HSDPA with Path Selection describes the functionality introduced in RAS06 release. In RU10 release, the functionality of this feature changed. For more information, see Traffic control functions and ATM description in WCDMA RAN ATM transport. This feature belongs to transmission and transport. The Dynamic Scheduling for HSDPA with Path Selection feature contains two functionalities. First, it introduces an enhanced internal flow control for HSDPA data and secondly it introduces a VCC bundling concept for the last mile protection in transport network. The dynamic flow control for HSDPA traffic operates between the AAL2 and MAC layers in the RNC. It prevents packet loss in RNC’s AAL2 buffers and thus increases system performance and the end-s’ QoS. In addition, the feature makes the operating of the RNC and dimensioning the network easier from the transport point of view. The feature also increases Iub efficiency. The feature is used only on Iub. An AAL2 buffer handled by the flow control mechanism contains one operator-configurable threshold ‘Low’ which triggers the ‘full rate’ sending when the buffer is getting emptier. There are also other dynamically adjustable thresholds that affect the flow control message sending by reducing and increasing the incoming rate to the buffer. If the upper-most threshold is crossed the ‘full stop’ message is triggered. The Low threshold is used to define how ‘aggressive’ the flow control is. 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 for too long and thus reduces the performance. On the other hand, 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, which then makes the flow control functionality operate as if having only an ON / OFF mode. In addition, the internal RNC load increases due to the increase of flow control messages. The flow control functionality is also aware of the available bandwidth which can change (when the VCC bundling is used) and based on the bandwidth and queue situation a new set of queue thresholds are calculated in short intervals and taken into use in order not to exceed 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 less than the defined value, the flow control does not tend to increase it. The VCC bundling means that a common peak cell rate (PCR) can be set to a group of VCCs. This means that the total traffic amount of the bundled VCCs does not exceed the PCR set. The functionality is aimed for the last mile or any other bottleneck in the system protection. If air interface is the bottleneck then VCC bundling isn’t any use. If dedicated VCCs are used to carry different traffic types the total traffic amount will not exceed the PCR thus preventing congestion and traffic loss in the transmission network.

114

Id:0900d80580899be3 Confidential

DN70296245


On the other hand it is possible that the unused capacity of a VCC can be used for other VCCs. In a bundle there can be VCCs towards only one BTS. There can be two VCC bundles defined for a BTS. Two bundles are useful if HSDPA traffic uses different physical path than the DCH traffic, for example, with BTS Hybrid backhaul. Rules for configuring the bundles when only RAN1099 feature is enabled Enabling the VCC bundle with the RAN1099 feature, allows using the flow control only for HSDPA traffic, not for the NRT DCH traffic. This means that that the DCH traffic needs to be carried in DCH VCC where the NRT DCH flow control is not enabled. When VCCs are included in VCC bundle enabling only RAN1099 feature the following rules apply. • • • •

When feature RAN1099: Dynamic Scheduling for HSDPA with Path Selection is enabled for a BTS, a VCC must be dedicated for HSDPA or HSPA traffic. The HSPA, HSDPA or HSUPA VCC must be UBR+ type. If the VCC bundle is used then all R99 VCCs of the same type must be in the same VCC bundle. It is recommended that HSDPA VCC or HSPA VCC is equal to bundle PCR. This way the HSDPA traffic can use the all the bundle bandwidth if no other traffic.

The allowed configurations are given in the following table. RT DCH

DCH

HSDPA

1.

X

X

2.

X

X

3.

X

Table 13

NRT DCH

HSUPA

HSPA

X X

Allowed configurations

There can be one or more of each VCC type in bundle. Enabling the bundle with RAN1100 contains different configuration rules and enabling both RAN1100: Dynamic Scheduling for NRT DCH with Path Selection and RAN1099: Dynamic Scheduling for HSDPA with Path Selection for a BTS gives the most free configuration possibilities. For more information about the RAN1100: Dynamic Scheduling for NRT DCH with Path Selection and RAN1099: Dynamic Scheduling for HSDPA with Path Selection co-working, see ATM description in WCDMA RAN ATM Transport. It should be noted that the RAS05.1 features RAN1020: Route Selection and RAN324: Dynamic HSDPA Transport Scheduling are not ed with VCC bundling.

DN70296245


115


HSDPA

RT and NRT DCH

Scheduler Flow control

RLC MAC

AAL2 Queue

VCC BUNDLE

A2SU

Line Card

Figure 9

Example of VCC bundle

In the example VCC bundle the DCH VCC is scheduled first because of the tightest QoS requirements. The DCH VCC must be CBR and HSDPA / HSPA UBR+. If the HSDPA / HSPA VCC PCR is set equal to VCC bundle PCR, the HSDPA traffic can use all bandwidth if there is no other traffic. A VCC bundle has a configuration parameter which defines how much of the VCC bundle bandwidth will be granted by the AAL2 CAC for NRT DCH trafficHowever it is applied only when both HSDPA and NRT DCH are run on dedicated VCCs. Benefits for the operator The feature improves the HSDPA throughput in the following ways: • • • •

No AAL2 queue drops Less RLC Retransmissions Better throughput figures Smooth throughput graphs.

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

2.4.2

Functional description Activating the feature RAN1099: Dynamic Scheduling for HSDPA with Path Selection activation requires an RNC-specific capacity license. This means that the feature can be activated according

116


DN70296245


to purchased capacity. If a license exists, the feature can be turned on with the ‘Internal HSDPA flow control method for BTS’ parameter. For more information on feature activation, see Activating Dynamic scheduling for HSDPA with path selection.

2.4.3 2.4.3.1

System impact Current implementation In RAS05.1, RAN324 Dynamic HSDPA Transport Scheduling is included as an optional feature. The feature works only with CBR VCCs. Also RAN324 Dynamic HSDPA Transport Scheduling works with both SHARED and HSDPA dedicated VCCs. Both RAS06 and RAS05.1 features are enabled using the same BTS specific parameter, which means that the RAS05.1 RNC-specific parameter disappears. Since both features are enabled with same parameter and both features have separate licenses, the system decides automatically which license is charged. If the HSDPA VCC or HSPA is included in the VCC bundle the RAN1099 license is charged. The RAN324 Dynamic HSDPA Transport Scheduling license can be charged only if CBR HSDPA VCC is configured outside the VCC bundle. If neither of RAN1099: Dynamic Scheduling for HSDPA with Path Selection or RAN324 Dynamic HSDPA Transport Scheduling are activated, only static rate control or ‘no control’ are available.

2.4.3.2

Hardware requirements This feature has no hardware requirements.

2.4.3.3

Interdependencies between features This feature requires the RAN759: Path Selection feature. A VCC must be dedicated to HSDPA traffic (HSDPA or HSPA VCC) in order to use the flow control. VCC bundling functionality is enabled also with dynamic scheduling for NRT DCH with path selection.

2.4.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

-

-

-

-

DN70296245


117


2.4.3.5

2.4.3.6


RAS SW component



ASW

RAN

RNC LK



2.4.3.7

Management plane NMS interfaces Impact on planning tool: No effects. Impact on management tools: No effects. Impact on radio network configuration management tool: The operator can configure the new parameters via NetAct or via RNC RNW Object Browser GUI. For information on the operator configurable parameters, see Management data. Impact on transport network configuration management tool: No effects. Impact on reporting tools: No effects. Impact on monitoring tools: No effects. Impact on optimising tools: No effects. Network element interfaces The MML interface should not be used in configuring this feature. Management data Statistics: There are no new counters related to this feature. The feature performance can be monitored with the existing AAL2 scheduling performance measurement which measures the following: • • •

118

The AAL2 queue service rate in DL The estimated AAL2 layer buffering delay Flow control performance


DN70296245


•

AAL2 traffic loss due to congestion

The counters in the measurement are: Abbreviation BE_QUE_PEAK BE_QUE_SUM BE_QUE_SAMPLES BE_QUE_DELAY_PEAK BE_QUE_DELAY_SUM BE_QUE_DELAY_SAMPLES BE_QUE_DOWN_MSGS BE_QUE_UP_MSGS BE_QUE_STOP_MSGS BE_QUE_DRP_EVENTS

Also the RM Measurement (Radio Connection Performance Management) is very useful to see the benefits of the feature, that is, reduced amount of RLC retransmission. In addition IP network protocol analyzers can be used to see the increased T throughput figures. Parameters: Because two features are controlled with partially the same parameter set, the following table shows how parameters are related to features. Parameter

Use

VCC Bundle Peak Cell Rate (RAN1099)

The maximum Peak Cell Rate the bundle allows to transmit

VCC Bundle Excess Bandwidth Share (RAN1099)

Defines how the excess bandwidth is shared

VCC in Bundle (RAN1099)

Defines whether VCC is included in bundle or not

VCC Bundle identifier (RAN1099)

Identifies the bundle

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

Defines the used internal flow control method for the HSDPA traffic.

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

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

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

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

HSDPA flow control AAL2 queue low threshold for shared VCC (RAN324)

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

HSDPA flow control AAL2 queue target delay for shared VCC (RAN324)

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

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

DN70296245


119


Parameters

Counters

No counters VCC Bundle Excess Band- related to this feature width Share


VCC Bundle Peak Cell Rate VCC In Bundle VCC Bundle List Internal HSDPA Flow Control Method for BTS


2.4.3.8

Impact on system performance and capacity The feature prevents packet loss in RNC AAL2 buffers and thus increases system performance and the end-s’ QoS. The bundling functionality increases the bandwidth usage and makes the dimensioning easier when several VCCs are used.

2.4.3.9


2.4.3.10

Limitations and restrictions RAN1099: Dynamic Scheduling for HSDPA with Path Selection can be used only if a VCC is dedicated to HSDPA traffic. This feature is used on Iub only.

120


DN70296245


2.5

2.5.1

g

RAN1100: Dynamic Scheduling for NRT DCH with Path Selection Introduction The feature description of RAN1100: Dynamic Scheduling for NRT DCH with Path Selection describes the functionality introduced in RAS06 release. In RU10 release, the functionality of this feature changed. For more information, see Traffic control functions and ATM description in WCDMA RAN ATM transport. This feature belongs to Transmission and transport. The Dynamic Scheduling for NRT DCH with Path Selection feature contains three functionalities. First, it introduces an RNC internal flow control for NRT DCH downlink traffic. Secondly, it introduces a VCC bundling concept for NRT DCH traffic. Thirdly, it sets the activity factor of NRT DCH bearers to 0.75 for both uplink and downlink. Setting the activity factor of NRT DCH bearers to smaller than 1 makes it possible to establish more AAL2 connections and as result increasing the capacity. The feature is used only on Iub interface. The dynamic flow control for NRT DCH traffic operates between the AAL2 and MAC layers in the RNC. It prevents packet loss in RNC AAL2 buffers in temporary congestion situation when activity factor is set below 1. There are two thresholds in the AAL2 buffer, low and high. When the AAL2 buffer is getting fuller the AAL2 buffering delay is increasing. When the high threshold is crossed upwards the flow control functionality sends messages to upper layer to reduce the speed the data is coming in. The bearer speed is halved. In case of 384kbps bearer, the speed is downgraded to 128kbps. When the buffer is getting emptier and the low threshold is crossed downwards the speed is increased back to original. The thresholds are set on the basis of the configuration parameter ‘NRTDCH Flow Control AAL2 Queue Target Delay’. The parameter sets the target delay which the flow control tries not to exceed. If the delay is less than the parameter value the delay of traffic is not increased. When the NRT DCH traffic is carried in a UBR+ VCC inside the VCC bundle, the flow control algorithm can take the varying amount of free bandwidth into when calculating the thresholds. The flow control is not used for all the NRT DCH bearers that have peak bit rate more than 8kbps. Also, if the activity factor is set too low with RAN1096: Transport Bearer Tuning, the flow control uses the built-in minimum value of 0.1. However it is highly recommended that the lowest AF used for 384kbps bearers is 0.38 and for other traffic 0.5. If AF is set lower the possibility of loosing packets increases in high load situations. When AF is set smaller than 1 the AAL2 delay increases in congestion. If delay increases too much normally it means that data arrives too late to hit the receiving window in BTS. For that reason the ToAW is set larger with this feature in order to prevent transport channel synchronization procedure and this way RLC retransmission. The parameter ‘ToAWS Offset for overbooked NRT DCH AAL2 connection defines how much the ToAW is increased when bearer is set up. When ever the offset value is changed, changing the value of ‘NRTDCH Flow Control AAL2 Queue Target Delay’ should be considered also.

DN70296245

Id:0900d805807524bb Confidential

121


The NRT DCH flow control can be enabled only in dedicated NRT DCH VCC. The VCC can be inside or outside the bundle. Outside the bundle the CBR must be used but inside the bundle UBR+ must be used if the flow control needs to be enabled. The VCC bundling means that a common peak cell rate (PCR) can be set to a group of plane VCCs in RNC for downlink. This means that the total traffic amount of the bundled VCCs do not exceed the PCR set. The functionality is aimed for preventing overflow in the last mile or any other bottleneck in the system. If air interface is the bottleneck then VCC bundling does not bring any benefit. If dedicated VCCs are used to carry different traffic types, the total traffic amount does not exceed the PCR thus preventing congestion and traffic loss in the transmission network. On the other hand it is possible that the unused capacity of a VCC can be used for other VCC if UBR+ is used. In a bundle there can be VCCs towards only one BTS. Two VCC bundles per BTS can be defined. If RAN1099: Dynamic Scheduling for HSDPA with Path Selection is not enabled, only one bundle can be used with RAN1100: Dynamic Scheduling for NRT DCH with Path Selection. If the VCC bundle is used for DL in RNC, it is recommended to be used for UL in BTS also. It is recommended that when the flow control is enabled the available bandwidth for NRT DCH to be more than 1100s. If no MDCR is defined to guarantee the bandwidth, that during high load, when available bandwidth for NRT DCH is reduced to less than 1100s, the flow control may not work optimally in all cases. Non optimal working means that sometimes the flow control may reduce the sending rate of the connections earlier than high bandwidth cases when trying to prevent the traffic loss, and guarantee the QoS for itted connections. Early reduction of sending rate means that some bandwidth may be left unused. In such a case no new connections are itted, even though some bandwidth is available. The recommendation applies to VCCs ing NRT DCH flow control no matter if they are bundled or not. Rules for configuring the bundle when only RAN1100: Dynamic Scheduling for NRT DCH with Path Selection is enabled Enabling the VCC bundle only with the RAN1100: Dynamic Scheduling for NRT DCH with Path Selection feature allows only bundling the DCH traffic, meaning that it is not possible to include VCCs carrying HSDPA traffic. When RTDCH and NRTDCH VCCs are included in VCC bundle enabling only RAN1100: Dynamic Scheduling for NRT DCH with Path Selection feature the following rules must be followed. • • • •

When RAN1100: Dynamic Scheduling for NRT DCH with Path Selection is enabled for a BTS, a VCC must be dedicated for NRT DCH traffic. The NRT DCH VCC must be UBR+ type. All VCCs of the same type that are carrying DCH traffic must be either inside one bundle or outside both bundles. It is recommended that PCR of NRT DCH VCC is equal to bundle PCR. This way the NRT DCH traffic can use all the bundle bandwidth if there is no other traffic.

Enabling the bundle with RAN1099: Dynamic Scheduling for HSDPA with Path Selection contains different configuration rules and enabling both RAN1100: Dynamic Scheduling for NRT DCH with Path Selection and RAN1099: Dynamic Scheduling for HSDPA with Path Selection for a BTS gives the most configuration possibilities. For more information about RAN1100: Dynamic Scheduling for NRT DCH with Path Selection and RAN1099: Dynamic Scheduling for HSDPA with Path Selection co-working, see ATM description in WCDMA RAN ATM Transport.

122


DN70296245


The allowed VCC bundle configuration with RAN1100: Dynamic Scheduling for NRT DCH with Path Selection is given in the following table.

1.

RTDCH

NRTDCH

X

X

2.

Table 14

DCH

HSDPA

HSUPA

HSPA

X


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

HSDPA

NRT DCH (PS)

Scheduler

Scheduler

RT DCH (Voice)

Flow control

AAL2 queues

UBR + VCC

UBR +

Rate limited VCC bundle

RLC MAC

CBR

A2SU

Line VPC

Figure 10

Example of VCC bundle

In a bundle the RT DCH VCC is scheduled first because of the tightest QoS requirements. The RT DCH VCC must be CBR type and the NRT DCH VCC UBR+. If the NRT DCH VCC PCR is set equal to bundle PCR the NRT DCH traffic can use all the bandwidth if there is no other traffic. A bundle has a configuration parameter which defines how excess bandwidth is shared between NRT DCH and HSDPA traffic in a congestion situation. However the parameter is applied only when both HSDPA and NRT DCH are run on dedicated VCCs in the .same VCC bundle. For more details see RAS06 and RAS05.1 Transport Overview, Feature Description.

DN70296245


123


The AAL2 CAC in the VCC bundle The VCC bundle introduces a new way of doing the AAL2 CAC for NRT DCH downlink connections in RNC. If RAN1100: Dynamic Scheduling for NRT DCH with Path Selection is not enabled, then the AAL2 CAC is done on the guaranteed bandwidth a VCC connection provides; that is, PCR in case of a CBR VCC and MDCR in case of a UBR+ VCC. The actual available bandwith changes dynamically based on the total load of the VCC bundle. If there is no RT DCH traffic in the VCC bundle then the NRT can get all the bandwidth reserved for the RT DCH traffic. When RT connections get itted they get the required bandwidth because of higher priority which then reduces the amount of bandwidth available for NRT connections. And vice versa, when RT connections end, the amount of bandwidth available for NRT connections increases. Note that if some bandwidth is reserved for HSPA traffic ( that is MDCR of UBR+ VCC) the NRT DCH is not able to use that. The MDCR of HSDPA, HSUPA and HSPA are hard guaranteed and the NRT DCH traffic cannot use that share of bandwidth either in AAL2 CAC or from a scheduling point of view. If no other traffic exists in bundle the VCC PCR can be up to bundle PCR if defined so. When RT DCH connections get itted or HSDPA s appear (if configured in same bundle with RAN1099: Dynamic Scheduling for HSDPA with Path Selection) they get their designated share of the bandwidth which decreases the NRT DCH PCR. The NRT DCH PCR can never be less than the MDCR defined for the NRT DCH VCC which is used as bandwidth reference without bundle. If in RNC feature RAN1100: Dynamic Scheduling for NRT DCH with Path Selection is enabled then the VCC bundle mode for the AAL2 CAC in the BTS for uplink must be enabled, too. This mode performs the same AAL2 CAC rules in the BTS for uplink. The following rules apply for the BTS: • • • •

• •

RAN1095: UBR+ for Iub Plane must be licensed and enabled in the BTS. There is no additional BTS license required for RAN1100: Dynamic Scheduling for NRT DCH with Path Selection. The BTS autonomously puts all the plane VCC in the same ATM interface into a VCC bundle. The BTS calculates the uplink VCC Bundle rate autonomously by ATM interface bandwidth minus all non AAL2 plane VCC guaranteed bandwidth (that is, sum of CBR PCR and UBR+ MDCR of all VCC carrying non plane traffic such as control plane or management plane). For UltraSite WCDMA BTS, feature RAN1.5057: BTS AAL2 Multiplexing must be enabled. UltraSite WCDMA BTS must be a leaf node (on ATM interfaces with terminated plane VCC there must not be any other traffic cross-connected from other BTSs)

With the new bundle CAC algorithm the system performance is increased (that is, more calls get itted) because the bandwidth reference of AAL2 CAC for NRT DCH traffic inside bundle is between MDCR of the NRT DCH VCC and PCR of the bundle (not the MDCR as without bundle). If the NRT DCH DL traffic consumes more bandwidth than UL more calls get itted. Note that when ever bundles are used they have to be used for both UL and DL.

124


DN70296245


The Path type in the VCC bundle Outside the VCC bundle the path type can be set freely. However, when VCC is included in the VCC bundle, the allowed values for path type are limited. For the RT DCH VCC and NRT DCH VCC the path type has to be set to “stringent” or “stringent bi-level”. The reason for prohibiting the “tolerant” for RT DCH and NRT DCH VCCs is that there is no way to limit the amount of connections in the bundle in congestion situation and as a result decrease the possibilities for proper function. Benefits for the operator The feature increases the Iub efficiency in the following ways: • • • • •

more connections can be established due to lower AF, no AAL2 queue drops, less RLC Retransmissions, better throughput figures, smooth throughput graphics.

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

2.5.2

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

DN70296245

Target / scope of impact

Degree of impact

Current implementation

Major

Interdependencies with other features

Major


Major

Hardware requirements

Ultrasite AXU-B or AXC-C

Control and plane

No impact

Management plane

Minor

NMS interfaces

Minor

Network element interfaces

Minor

Management data

No impact

System performance and capacity

Major

Mobile terminals

No impact

3 G system requirements

No impact

Limitations and restrictions

Minor

Compliance

No impact


125


2.5.2.1

Current implementation This feature is implemented in RAS06. There are no interdependencies to earlier releases.

2.5.2.2

Interdependencies between features This feature requires the RAN759 Path Selection feature. A VCC must be dedicated to NRT DCH bearers. RAN1100: Dynamic Scheduling for NRT DCH with Path Selection affects the NRT DCH bearers’ activity factors (AF) similar to RAN1096: Transport Bearer Tuning. If the AF is set too low with RAN1096: Transport Bearer Tuning, the flow control built-in minimum value 0.1 is used for CAC. VCC bundling functionality is enabled also with the RAN1099: Dynamic Scheduling for HSDPA with Path Selection feature but the configuration rules differ. If NRT DCH VCC is included in the VCC bundle it must be configured to be UBR+ type. For UltraSite WCDMA BTS, feature RAN1.5057: BTS AAL2 Multiplexing must be enabled and licensed. RAN1095: UBR+ for Iub Plane must be enabled and licensed.

2.5.2.3

Software requirements The feature sets the following requirements: • • • • •

2.5.2.4

RAS06 RNC: RN3.0 OSS4.2 AXC C3.0 WBTS 4.0

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

2.5.2.5


2.5.2.6

Management plane NMS interfaces Impact on planning tool: This feature has no effects on planning tool Impact on management tools: This feature has no effects on management tools

126


DN70296245


Impact on radio network configuration management tool: The operator can configure the new parameters via NetAct or via RNC RNW Object Browser GUI. For information on operator-configurable parameters, see Section Management data. Impact on transport network configuration management tool: The operator can configure the new parameters via NetAct or via RNC RNW Object Browser GUI. For information on operator-configurable parameters, see Section Management data. Impact on transport network configuration management tool This feature has no effects on transport network configuration management tool. Impact on reporting tools: This feature has no effects on reporting tools. Impact on monitoring tools: This feature has no effects on monitoring tools. Impact on optimising tools: This feature has no effects on optimising tools. Network element interfaces See Nokia Siemens Networks WCDMA RNC Product Documentation for more detailed information. Management data Statistics: There are no new counters related to this feature. The feature performance can be monitored with the existing AAL2 scheduling performance measurement which measures the following: • • • •

The AAL2 queue service rate in DL The estimated AAL2 layer buffering delay Flow control performance AAL2 traffic loss due to congestion

The counters in the measurement are: Abbreviation BE_QUE_PEAK BE_QUE_SUM BE_QUE_SAMPLES BE_QUE_DELAY_PEAK BE_QUE_DELAY_SUM BE_QUE_DELAY_SAMPLES BE_QUE_DOWN_MSGS BE_QUE_UP_MSGS BE_QUE_STOP_MSGS BE_QUE_DRP_EVENTS

DN70296245


127


Also the RM Measurement (Radio Connection Performance Management) is very useful to see the benefits of the feature, that is, reduced amount of RLC retransmission. In addition IP network protocol analyzers can be used to see the increased T throughput figures. Parameters: Parameter

Use

VCC Bundle Peak Cell Rate

Defines the peak traffic amount that can be sent

VCC Bundle Excess Bandwidth Share

Defines how the excess bandwidth is shared

VCC in Bundle

Defines whether VCC is included in bundle or not

VCC Bundle identifier

Identifies the bundle

Target AAL2 delay for NRT DCH

The maximum AAL2 delay

Dynamic NRT DCH Scheduling with path selection switch

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

ToAWS Offset for overbooked NRT DCH AAL2 connection

Defines the offset value to be added to the corresponding ToAWS_NRT_DCH_ttiXX parameter value whenever the overbooking mode is used for NRT DCH in the Iub interface.

Table 15

Dynamic Scheduling for NRT DCH with Path Selection impact on parameters

BTS parameters

Use

TRDE label

If any TRDE has a label with string “VCC_BUNDLE” then the VCC Bundle mode for the AAL2 CAC is enabled. Note, the correct spelling is important. The functionality is disabled in BTS by deleting or misspelling the string

Table 16

Dynamic Scheduling for NRT DCH with Path Selection impact on BTS parameters


2.5.2.7

Impact on system performance and capacity The feature itself improves the Iub capacity with the lower activity factor because it allows more AAL2 connections to be established. The flow control functionality prevents packet loss and poor QoS in temporary congestion situations. Also the feature helps if even lower AFs are set with RAN1096: Transport Bearer Tuning. The bundling functionality increases the bandwidth usage and makes the dimensioning easier when several VCCs are used.

2.5.2.8


128


DN70296245


2.5.2.9

Limitations and restrictions The NRT DCH flow control can be used only if a VCC is dedicated to NRT DCH traffic. If the AF of a bearer is changed with other features, the AF must be at least 0.1 though it is recommended to use higher values. This feature is used on Iub only.

2.5.3

Functional description Activating the feature RAN1100: Dynamic Scheduling for NRT DCH with Path Selection activation requires an RNC-specific capacity license. This means that the feature can be activated only according to purchased capacity. For more information on activating the feature, see Activating Dynamic scheduling for NRT DCH with path selection in Feature RAN1100: Dynamic Scheduling for NRT DCH with Path Selection, Feature Activation Manual . The activation of the VCC Bundle mode for AAL2 CAC is BTS is by setting a string as described in this document.

DN70296245


129


2.6 2.6.1

g

RAN759: Path Selection Introduction The feature description of RAN759: Path Selection describes the functionality introduced in RAS06 release. In RU10 release, the functionality of this feature changed. For more information, see ATM Adaptation Layers in WCDMA RAN ATM Transport. This feature belongs to Transmission and Transport. RAN759: Path Selection is an optional feature and it can be enabled per BTS in the RNC. The feature contains the following main functionalities: • • • • •

plane traffic can be divided into different dedicated VCCs. Path type can be defined for a VCC. Each path type has an own AAL2 CAC algorithm. The ITU-T Q.2630.2 CS2 path type is included in an ERQ message. Interactive class NRT bearers can be treated according to Traffic Handling Priority (THP) as delay-sensitive or non-delay-sensitive traffic The length of AAL2 buffer can be modified based on the VCC type.

RAN759: Path Selection allows dedicating VCCs for RT DCH, NRT DCH and HSDPA traffic. When dividing the traffic into different VCCs the transport network will be able to the overbooking or statistical multiplexing of different traffic types without affecting other traffic types. The overbooking and statistical multiplexing allow bandwidth savings in the transport network. If wanted, the DCH VCC can be defined to carry both RT and NRT DCH traffic on a same VCC. VCC can also be used as SHARED when DCH and HSDPA traffic types are carried in it. The HSUPA traffic will require an own dedicated HSUPA VCC or it can be carried together with HSDPA in HSPA VCC. The dedicated VCCs (RT DCH, NRT DCH, HSDPA and HSUPA) contain only one AAL2 priority queue per VCC in the RNC but the DCH VCC contains 2 and SHARED VCC 3 AAL2 priority queues. The common channels, control and SRB traffic are always using the same highest priority queue as the RT DCH traffic. In DCH VCC the NRT DCH traffic is mapped to low priority queue. In SHARED VCC the NRT DCH traffic is using the middle priority queue and the HSDPA traffic the low priority queue. The HSPA VCC contains also 2 AAL2 priorities in RNC. The HSUPA control traffic will use the high priority queue and the HSDPA traffic will use the low priority queue. This way the HSUPA congestion control DL messages get priority over HSDPA traffic. A strict priority scheduler is used when scheduling traffic from the AAL2 queues. The reason for multiple AAL2 priorities in RNC is to better the NRT DCH overbooking. With one AAL2 queue for R99 traffic overbooking of a traffic type affects the others traffic types as well which leads easily to increased AAL2 delays and in worst case loss of cell synchronization and cell restart. With several AAL2 priorities for R99 traffic the NRT DCH traffic can be overbooked without affecting the other traffic types. With overbooking, more connections get itted thus increasing the system performance. The two-priority DCH VCC is used regardless of the license charged (that is, RAN1020: Route Selection or RAN759: Path Selection). Also the 3 priority SHARED VCC is used as default.

130

Id:0900d80580863e2b Confidential

DN70296245


In Ultrasite WCDMA BTS and Flexi WCDMA BTS, there are no AAL2 level priorities for UL traffic inside a VCC. When a VCC is created, a path type needs to be defined for it. Each path type has a different AAL2 ission control (CAC) algorithm in DL and UL. The AAL2 CAC algorithms used in RNC for DL are described in more detail in chapter 3. The path type can be set freely but it is recommended that the path type for RT DCH is stringent, for NRT DCH stringent bi-level and for HSDPA it should be tolerant. When the VCC Bundle functionality is used there are limitations in choosing the path type. For more details see the RAN1099 and RAN1100 feature documents. The selected path type is signaled to BTS in an establish request (ERQ) message as defined in ITU-T Q.2630.2 specification when as AAL2 connection is established using the VCC in concern. The functionality is 3GPP-compliant. With Path Selection it is possible to define whether interactive class NRT bearer is treated as delay-sensitive or delay-tolerant based on its traffic handling priority (THP). THP values 1, 2 or 3 can be defined as delay-sensitive or delay-tolerant. If bearer’s THP has some other value it is treated as delay-tolerant. When an AAL2 connection is established over the Iur interface, the THP is not delivered and the THP is considered to have value 1. If there are different VCCs configured to RT DCH and NRT DCH traffic, the delay-sensitive NRT traffic (for example,. some game related traffic or streaming service) is carried in RT DCH VCC due to less AAL2 delay in RNC: The activity factor for delaysensitive NRT DCH traffic is 1 regardless of how the activity factor is set with other features in order not to ruin the QoS of RT traffic carried in the same VCC. If RT DCH and NRT DCH are carried in the same VCC this traffic handling priority does not matter i.e. in DCH VCC and SHARED VCC the NRT DCH traffic will always use the low or middle priority queue regardless of the THP values. For more information on THP, see 3GPP TS 23.107 Quality of Service (QoS) concept and architecture. The AAL2 queue lengths according to the VCC type can also be modified with this feature. If RAN 1100: Dynamic Scheduling for HSDPA with Path Selection or RAN1099: Dynamic Scheduling for NRT DCH with Path Selection is used, the AAL2 queue length affects the dynamic scheduling performance. The queue length should correspond to the VCC bandwidth: the larger the bandwidth the longer the queue. If no dynamic scheduling is enabled, the longer buffer causes longer AAL2 delay in congestion situation. The delay may also affect upper layer performance. Benefits for the operator RAN759: Path Selection allows specifying dedicated VCCs for certain traffic types. Those VCCs can use different transmission paths according to the specific QoS requirements, which can result in cost savings. Most useful the feature is when used with other new RAS06 transport features. Path Selection is a mandatory feature for RAN 1100: Dynamic Scheduling for HSDPA with Path Selection and RAN1099: Dynamic Scheduling for NRT DCH with Path Selection features.

DN70296245


131


2.6.2

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

The VCC type is set to something else than SHARED. The path type is set to any other value than ‘stringent’. UBR+ is used as ATM service category for a VCC. That is, RAN1020: Route Selection cannot be used with UBR+.

The RAS05.1 feature RAN1020 Route Selection allows dedicating VCCs for DCH and HSDPA traffics. If both free RAN1020: Route Selection and RAN759: Path Selection licenses are in system, and created configuration is such that both could be charged (that is, DCH+HSDPA with both having CBR as ATM service category), then RAN1020: Route Selection is charged. The UBR+ limitation with RAN1020: Route Selection applies only to DCH and HSDPA VCCs. If HSUPA is added on top route selection, the ATM service category can be selected freely. • •

DCH (CBR) + HSDPA (CBR) + HSUPA (UBR+) is allowed with RAN1020: Route Selection license. DCH (CBR) + HSDPA (UBR+) +HSUPA (UBR+) requires RAN759: Path Selection license.

The following table illustrates what VCC combinations are allowed when features are enabled. VCC type / Licence

SHARED

None

X

RT DCH

NRT DCH

RAN1020

DCH

X RAN759

X

X

X

X

X

X X

X

X X

X

X

X

RAN759 + HSUPA

Table 17

HSPA

X

X

RAN1020 + HSUPA

HSUPA

X X

HSUPA

HSDPA

X

X X

X

X

X X

X

X

X

X X

X X

Allowed VCC configurations

In addition to the table the following rules apply:

132


DN70296245


• • • •

•

If more than 2 plane VCC are configured on a route, RAN1.5057: BTS AAL2 multiplexing must be enabled. The RT DCH + NRT DCH configuration on a route is a special case. It requires also AAL2 MUX even though only 2 VCCs are configured. If several routes are configured to BTS (i.e. AAL2 MUX is not used) at least one route must contain a VCC for the HSDPA traffic (i.e. HSDPA or HSPA VCC). If several routes are configured, the HSPA VCC cannot be mixed with HSDPA and HSUPA VCCs to same BTS. That is, if HSPA VCC is used on a route, there cannot be HSDPA or HSUPA VCCs on other routes to the same BTS. On the other hand if HSPA VCC is not used the HSDPA and HSUPA VCCs can freely selected as long as the rule above is obeyed. · DCH + SHARED configuration is exception which is ed only with RAN1020: Route Selection.

RAN1020: Route Selection and RAN759: Path Selection do not have any restriction how different VCCs are configured to VPCs. The ATM service categories for the VCCs can be CBR or UBR+ when RAN759: Path Selection is used. The feature can be verified by monitoring the ATM Virtual Channel connection PM data and the reserved transport capacity of the AAL2 connection. For more information on feature activation, see Activating path selection in Feature RAN759: Path Selection, Feature Activation Manual. Hub Point WCDMA BTS

1...n rt VCC

RNC

ATM SWITCH

ATM SWITCH

nrt VCC WCDMA BTS

HSPA VCC

I ub Transport Capacity Aggregate rt VCC = S1..n rt VCC Aggregate rt VCC

Figure 11

S1..n rt VCC

Path Selection

The AAL2 CAC

ATM service category and AAL2 CAC bandwidth referense In order to serve its purpose the AAL2 CAC is done using the guaranteed bandwidth as reference. When CBR is used as ATM service category, the PCR of the VCC is used as reference. This has been used also in earlier releases. However, when UBR+ is used outside the VCC bundle as ATM service category, the MDCR is used as bandwidth reference for AAL2 CAC and not the PCR as in CBR case. This behavior should be noted especially when UBR+ is used for NRT DCH traffic. Typ-

DN70296245


133


ically AAL2 CAC needs to be performed for NRT DCH traffic and thus setting the value to 0 or other small value might not be a good idea. For HSPA traffic, setting the MDCR does not matter from AAL2 CAC point of view because all HSPA connections are best effort by nature and no bandwidth is reserved for individual connections. Of course, for HSPA traffic also the MDCR needs to have a proper value if bandwidth guarantee is required. Path type and AAL2 CAC algorithm The RNC has several AAL2 CAC algorithms in use. The used algorithm depends on the used VCC type and the path type. If path type is set to “stringent bi-level” or “tolerant” the algorithms are simple. •

• •

•

In AAL2 CAC point of view the path type does not matter much for VCCs carrying HSPA traffic. For HSPA traffic no AAL2 connection specific bandwidth reservations are done. Since the reservation is close to zero the algorithm does not matter much. The HSPA traffic is best effort in nature. If path type is set to “tolerant” no AAL2 CAC is done. This applies to all VCC and traffic types. It is recommended that tolerant is used only for HSPA traffic. If path type is set to “stringent bi-level” the AAL2 CAC algorithm is: 0,05 * connection peak bit rate + 0,95 * connection average bit rate. It is recommended that the stringent bi-level path type is used for NRT DCH VCCs. If path type is set to “stringent” the used CAC algorithm depends on the traffic type. For traffic which is the most delay sensitive (that is, using the highest AAL2 priority in RNC when in SHARED and DCH VCCs) uses QT algorithm which is based on the queue theorem. The algorithm output is not linear so the reserved bandwidth depends on the amount of connections itted. With small number of connections the reserved bandwidth is closer to connection’s peak rate. With dozens of connections itted the good approximation for the algorithm is: 0,2 * connection peak bit rate + 0,8 * connection average bit rate.

For other R99 connections which are using lower AAL2 priorities in RNC (I.e. for NRT DCH connections) QT is not used but the 20 / 80 algorithm described above. Generally for UL the AAL2 CAC is the same path type dependent algorithms are used with the exception that QT is not used but the 20 / 80 is used instead for all R99 connections. If the UL VCC bundle is enabled the AAL2 CAC behaves differently. For more details see RAN1100: Dynamic Scheduling for NRT DCH with Path Selection and ATM description in WCDMA RAN ATM Transport. Also see Dimensioning WCDMA RAN.

2.6.3 2.6.3.1

System impact Current implementation In RAS05 release, only the SHARED VCC is available. In RAS06 release the SHARED VCC is still for carrying all plane traffic except HSUPA even though feature is enabled. In RAS05.1, an optional RAN1020: Route Selection feature was introduced. It allowed dedicating different VCCs for HSDPA and DCH traffic types. In RAS05.1 and earlier releases, there was no for CS2 path type. Also the AAL2 buffers had fixed lengths. The THP value of a bearer was not taken into .

134


DN70296245


2.6.3.2

Hardware requirements If AXU-A is used (no BTS AAL2 multiplexing capability) in UltraSite WCDMA BTS, only two plane VCCs can be configured to a WAM unit in BTS. If it is necessary to separate plane traffic to three different VCCs (RT DCH, NRT DCH and HSDPA) an AXU-B (or later) unit with BTS AAL2 multiplexing capability is required in UltraSite WCDMA BTS. The AAL2 multiplexing is required also if only RT DCH and NRT DCH VCCs are configured. For Flexi WCDMA BTS there are no additional hardware requirements.

2.6.3.3

Requirement

Reason

UltraSite WCDMA BTS: AXU-B unit or later

AAL2 multiplexing capability is required if RT DCH + NRT DCH configuration is used or three or more plane VCCs are used on a route.

Interdependencies between features RAN759: Path Selection does not require any other feature to function. RAN759: Path Selection is mandatory for the following RAS06 transport features • •

RAN1099: Dynamic Scheduling for NRT DCH with Path Selection RAN 1100: Dynamic Scheduling for HSDPA with Path Selection

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

2.6.3.4

Release


RAS

RNC

BTS Ultra BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

C3.0

OSS4.2

-

-

-

-

2.6.3.5

2.6.3.6

WBTS4.0


RAS SW component



ASW

RAN

RNC LK


Control and plane This feature adds the path type parameter in an ERQ message in Iub as defined in ITUT specification Q.2630.2. If CS2 is not ed in the other end the path type is just ignored.

DN70296245


135


2.6.3.7

Management plane NMS interfaces Impact on planning tool: There are new AAL2 CAC algorithms. Impact on management tools: No effects. Impact on radio network configuration management tool: The operator can configure the new parameters via NetAct or via RNC RNW Object Browser GUI. For information on operator configurable parameters, see Management data. Impact on transport network configuration management tool: No effects. Impact on reporting tools: No effects. Impact on monitoring tools: This feature adds four new counters in ‘ATM Virtual Channel Connection’ measurement. They can be used to scale the measured traffic load to available bandwidth. In addition to the new counters, the existing counters and measurements can be used to follow the functionality. For more information, see Measuring ATM virtual channel connection in RNC Measurement Management and ATM/IP transport measurements in RNC Counters – Transport and HW Part. Impact on optimising tools: No effects. Network element interfaces See WCDMA RNC Product Documentation for more detailed information. Management data Statistics: There are the following new counters related to the RAN759: Path Selection feature. Statistics

Use

IN_CAP_VC

Configured ingress bandwidth for the virtual channel connection

EG_CAP_VC

Configured egress bandwidth for the virtual channel connection

IN_CAP_VP

Configured ingress bandwidth for the virtual path connection

EG_CAP_VP

Configured egress bandwidth for the virtual path connection

Table 18

136

RAN759: Path Selection statistics


DN70296245


Parameters: Parameter

Use

AAL2 UP Usage

Defines what traffic type the VCC is for

BTS AAL2 UP Usage

Defines what traffic type the VCC is for in UltraSite WCDMA BTS

Path Type

Defines the path type for the VCC

THP1 Delay Sensitivity Switch

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





AAL2 queue length for HSDPA without Flow Control

Defines the length of AAL2 queue for HSDPA VCC when dynamic scheduling is not used.

AAL2 queue length for HSDPA with Flow Control

Defines the length of AAL2 queue for HSDPA VCC when dynamic scheduling is used.

AAL2 queue length for NRT DCH without Flow Control

Defines the length of AAL2 queue for NRT DCH VCC when dynamic scheduling is not used.

AAL2 queue length for NRT DCH with Flow Control

Defines the length of AAL2 queue for NRT DCH VCC when dynamic scheduling is used.

AAL2 queue length for RT DCH

Defines the length of AAL2 queue for RT DCH VCC.

AAL2 queue length for HSUPA

Defines the length of AAL2 queue for HSUPA VCC.

Table 19

RAN759: Path Selection impact on parameters

The queue lengths for SHARED, DCH and HSPA VCC are defined with these parameters. See parameter definitions for more detail. The management data of this feature is listed in the following table. Parameters

Counters

Alarms

AAL2 Queue Length for NRT DCH With Flow Control

IN_CAP_VC

AAL2 Queue Length for NRT DCH Without Flow Control

EG_CAP_VC


AAL2 Queue Length for RT DCH

IN_CAP_VP

AAL2 Path Type

EG_CAP_VP

THP 1 Delay Sensitivity Switch THP 2 Delay Sensitivity Switch THP 3 Delay Sensitivity Switch AAL2 UP Usage AAL2 Queue Length for HSUPA AAL2 Queue Length for HSDPA With Flow Control

DN70296245


137


The queue lengths for SHARED, DCH and HSPA VCC are defined with the above parameters. See parameter definitions for more details. Signalling The path type is included in an ERQ message as specified in ITU-T Q.2630.2.

2.6.3.8

Impact on system performance and capacity RAN759: Path Selection increases transport performance and capacity. In addition, when used together with other new features the efficiency increases. For example, with feature RAN1096: Transport Bearer Tuning, the RAN759: Path Selection feature makes it possible to use lower activity factors when RT DCH and NRT DCH traffic is carried in different VCCs. For more information, see Dimensioning WCDMA RAN.

2.6.3.9


2.6.3.10

Limitations and restrictions When VCCs are configured to a BTS, a VCC for DCH traffic must always be configured. On a route there has to be ‘RTDCH and NRTDCH’ or DCH or SHARED VCC configured. Configuring VCC for HSDPA is not mandatory if only one route exists. If there are several routes at least one route need to have VCC for HSDPA traffic. (that is, SHARED or HSPA or HSDPA VCC). Path Selection is only available for plane in the Iub interface.

138


DN70296245


2.7 2.7.1

g

RAN1096: Transport Bearer Tuning Introduction The feature description of RAN1096: Transport Bearer Tuning describes the functionality introduced in RAS06 release. In RU10 release, the functionality of this feature changed. For more information, see Traffic control functions in WCDMA RAN ATM Transport. With Transport Bearer Tuning, the operator can overbook DL and UL traffic and allow more AAL2 connections on the Iub interface. Traffic overbooking is based on statistical average, so that average rate of AAL2 connections allocated on the Iub, is less than the sum of all AAL2 connection’s peak rate. Traffic overbooking is done by setting RNC specific activity factors of Iub transport bearers lower than default value. The activity factor is defined as the relation between average cell rate and peak cell rate of an AAL2 connection. Average cell rate and peak cell rate are part of the transport bearer specific AAL2 Link characteristics (ALC). ALC parameters are used by AAL2 CAC, when estimating whether an AAL2 connection can be established on VCC or not. Tuning the activity factors is recommended to be done by the operator, based on the information of the actual activity of the bearers. In case the actual activity exceeds the configured activity factor, there is a risk of traffic loss on Iub and consequently, the performance of the system as a whole is degraded. The right activity factor, which suits all cases, is difficult to determine because activity depends on the traffic mix in the network. The activity of a single bearer depends on e.g. the service used. If bearer is used for ing on FTP, the activity is considerable higher when compared to e.g. web browsing. With FTP service the activity can be close to 1 when with web browsing it can be 20%. Usually the higher the peak rate of the connection is the lower is the activity. If correct activity factor can’t be determined reliably it is recommended that the activity factors are reduced gradually and the effects on traffic quality are monitored using performance counters. Risk related to traffic loss can be reduced by utilising this feature with RAN759: Path Selection and RAN1100: Dynamic Scheduling for NRT DCH with Path Selection. The operator is able to follow through new and old counters the RNC AAL2 scheduling performance, dropped AAL2 packets, amount of allocated AAL2 connections to the system and throughput of PS (RLC AM) connections. The counters are found in the related transport measurement documents. Transport Bearer Tuning feature is compliant with ITU-T specification Q.2630.x ALCAP signalling [1] that is used to carry ALC parameters to the BTS/AXC CAC. Benefits for the operator Activity factor tuning allows more efficient transport resource usage and thus it decreases operator’s costs. Reducing activity factor allows more DCH, DCCH signalling and common channel connections on the Iub.

DN70296245

Id:0900d805807524bf Confidential

139


2.7.2

Functional description Activating the feature Transport Bearer Tuning activation requires RNC specific license. If the license is acquired, BTS specific Overbooking Switch is on as a default. This means that operator configured activity factors are used for all BTSs under the RNC. The operator can the feature by monitoring reserved transport capacity of AAL2 connection. Fore more information, see Activating Transport Bearer Tuning in Feature RAN1096: Transport Bearer Tuning, Feature Activation Manual.

2.7.3 2.7.3.1

System impact Current implementation Currently activity factor is not available in the interface but instead predefined values are used. An activity factor of 60% is assumed for voice bearers and an activity factor of 100% for NRT data bearers. For signalling radio bearers (SRBs) three predefined Af sets has been defined from RAN04 onwards. The activity factor set of SRBs is operator selectable. RAN1096: Transport Bearer Tuning is implemented in RAS06.

2.7.3.2


2.7.3.3

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

RAN759: Path Selection RAN1100: Dynamic Scheduling for NRT DCH with Path Selection

RAN1096: Transport Bearer Tuning can also be used with all VCCs, also with SHARED and DCH VCCs because the NRT DCH traffic has different AAL2 priority (different AAL2 queue in RNC) than RT DCH and CCCHs and thus increased AAL2 delay does not affect other traffic. However, it is highly recommended that RAN1096: Transport Bearer Tuning is used with the RAN759: Path Selection feature because it allows to dedicate an own VCC for delay tolerant DCH traffic. Using own dedicated VCC for NRT DCH traffic allows much heavier overbooking for NRT DCH traffic for several reasons. First, RAN1100: Dynamic Scheduling for NRT DCH with Path Selection can be used only with dedicated VCC which enables RNC internal flow control for NRT DCH bearers to prevent AAL2 queue over flows in case of heavy congestion. Second, the AAL2 queue is longer in dedicated VCC thus decreasing the probability for queue over flow. Third, when dedicated VCC is used also the ToAW is enlarged to handle the increased AAL2 delay. Larger ToAW decreases the probability of Transport Channel Synchronization procedure to take place thus increasing the throughput due to less of RLC retransmissions

140


DN70296245


Optimized Iub AAL2 Reservation for SRBs in RAN04 introduced default activity factor sets for SRB bearers. When RAN1096: Transport Bearer Tuning is used, operator can define used activity factors for SRBs freely, so operator is not tied to Optimized Iub AAL2 Reservation default values anymore. The RAN1096: Transport Bearer Tuning default parameters for SRBs are, however, the same as a default set in feature Optimized Iub AAL2 Reservation for SRBs. Transport bearer tuning and Optimized Iub AAL2 reservations for Common Channels If AFs for common DL transport channels are tuned the used physical channel (SCCH) configuration should be taken into . There can be one to three common channels in one SCCH if RAN2.0094: Optimized Iub AAL2 reservations for Common Channels is used. If a common channel is in a dedicated SCCH the common channel’s AF affects the AAL2 bandwidth reservation as any other AF If several common channels use same SCCH the AAL2 resources are reserved based on the largest channel. For example, if all common channels are using same SCCH modifying the AFs of FACH-C or PCH don’t have any effect on the AAL2 reservation. The following table shows the relation of SCCH configuration and the activity factor used for the reservation. Parameter

Definition

1 SCCH

2 SCCH

3 SCCH

AfPCHDL

This parameter defines the activity factor for PCH DL bearer.

Not used

AF USED

AF USED

AfFACHSDL

This parameter defines the activity factor for FACH-S DL bearer.

Not used

Not used

*)

AfFACHUDL

This parameter defines the activity factor for FACH-U DL bearer.

AF USED

AF USED

AF USED

AfFACHCIDL

This parameter defines the activity factor for FACH-C/I DL bearer.

Not used

Not used

*)

AfFACHCCDL

This parameter defines the activity factor for FACH-C/C DL bearer.

Not used

Not used

Not used

Table 20

DN70296245

AF and SCCH relationship


141


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

2.7.3.4

Release


RAS

RNC

BTS Ultra BTS Flexi AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

OSS4.2

-

-

-

-

2.7.3.5

2.7.3.6

WBTS4.0

-


RAS SW component



ASW

RAN

RNC LK



2.7.3.7

Management plane NMS interfaces Impact on planning tool: No effects. Impact on management tools: No effects. Impact on radio network configuration management tool: The operator can configure via NetAct or via RNC RNW Object Browser GUI, the new RNC object parameters. For information on operator configurable parameters, see Management data. Impact on transport network configuration management tool: No effects. Impact on reporting tools: No effects. Impact on monitoring tools: This feature introduces some new counters . By using the new and existing measurements the operator can follow functionality of RAN1096: Transport Bearer Tuning. Performance monitoring areas that are useful to follow are: • • •

142

Amount of succeeded transport resource request for DCH connections AAL2 scheduling delay and amount of AAL2 packets in AAL2 buffers Amount of AAL2 packet drop events


DN70296245


•

Throughput of RLC AM connections

For more information on counters, see RNC counters - Transport and HW part and RNC counters – RNW part. Amount of succeeded transport resource request for DCH connections: The following counters enable the operator to follow the effects of RAN1096: Transport Bearer Tuning on the amounts of allocation AAL2 connections: • • • • • •

SUM_RESERVED_CELL_RATE MIN_RESERVED_CELL_RATE MAX_RESERVED_CELL_RATE SUM_AAL2_CONNECTIONS MIN_AAL2_CONNECTIONS MAX_AAL2_CONNECTIONS

AAL2 scheduling delay and amount of AAL2 packets in AAL2 buffers: The following counters enable the operator to follow how much RAN1096: Transport Bearer Tuning causes AAL2 delay and how many packets are queued in AAL2 buffers. • • • • • •

BE_QUE_PEAK BE_QUE_SUM BE_QUE_SAMPLES BE_QUE_DELAY_PEAK BE_QUE_DELAY_SUM BE_QUE_DELAY_SAMPLES

Amount of lost AAL2 packets in IPA2800 platform: The following counter enables the operator to follow the amount of AAL2 packet drop events: •

BE_QUE_DRP_EVENTS

Throughput of PS (RLC AM) connections: The following measurement enables the operator to follow the throughput of RLC AM connections on RLC layer. This kind of information helps to adjust Af correctly. •

RM RLC (includes multiple counters)

Impact on optimising tools: No effects. Network element interfaces No effects Management data Parameters: The RAN1096: Transport Bearer Tuning feature enables the operator to adjust an activity factor for all traffic types and for all speeds that are used in the Nokia transport solution. The following table lists the parameter structures that contain individual Activity Factor parameters. These parameters, and additional information, can be found in Parameter Dictionary Database.

DN70296245


143


Activity factor parameters can be set separately in DL and UL direction. Parameters can be set online and a new parameter value is taken into use when new AAL2 connection is setup. Af for a specific speed that is stored in PDDB is applicable to all different TTI and S packet size combinations of that speed. Parameter

Use

Activity factor for NRT DCH traffic bearers

This parameter structure defines Activity Factors for NRT DCH traffic types

Activity factor for CS DCH traffic bearers

This parameter structure defines Activity Factors for CS DCH traffic types

Activity factor for AMR DCH traffic bearers

This parameter structure defines Activity Factors for CS DCH traffic types

Activity factor for RT PS traffic bearers

This parameter structure defines Activity Factors for RT PS traffic types

Activity factor for DCCH traffic bearers

This parameter structure defines Activity Factors for DCCH traffic types

Activity factor for FACH and RACH traffic bearers

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

Activity factor for PCH traffic bearers

This parameter structure defines Activity Factors for PCH traffic types

Overbooking Switch

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

Table 21

RAN1096: Transport Bearer Tuning impact on parameters

The management data of this feature is listed in Table Parameters. No counters and alarms are related to this feature. Parameters Activity factor for AMR DCH traffic bearers Activity factor for 12.2 / 12.65 AMR DCH DL bearer Activity factor for 12.2 / 12.65 AMR DCH UL bearer Activity factor for 5.9 AMR DCH DL bearer Activity factor for 5.9 AMR DCH UL bearer Activity factor for CS DCH traffic bearers Activity factor for 14.4 CS streaming DL bearer Activity factor for 14.4 CS streaming UL bearer Activity factor for 57.6 CS streaming DL bearer Activity factor for 57.6 CS streaming UL bearer Activity factor for 64 CS conversational DL bearer Activity factor for 64 CS conversational UL bearer

Table 22

144

Parameters


DN70296245


Parameters Activity factor for DCCH traffic bearers Activity factor for 12.8/13.6 DCCH DL bearer Activity factor for 12.8/13.6 DCCH UL bearer Activity factor for 1.6/1.7 DCCH DL bearer Activity factor for 1.6/1.7 DCCH UL bearer Activity factor for 3.2/3.4 DCCH DL bearer Activity factor for 3.2/3.4 DCCH UL bearer Activity factor for FACH and RACH traffic bearers Activity factor for FACH-C/C DL bearer Activity factor for FACH-C/I DL bearer Activity factor for FACH control UL bearer Activity factor for FACH-S DL bearer Activity factor for FACH-U DL bearer Activity factor for RACH 20.8 UL bearer Activity factor for RACH control DL bearer Activity factor for NRT DCH traffic bearers Activity factor for 128 NRT DCH DL bearer Activity factor for 128 NRT DCH UL bearer Activity factor for 16 NRT DCH DL bearer Activity factor for 16 NRT DCH UL bearer Activity factor for 256 NRT DCH DL bearer Activity factor for 256 NRT DCH UL bearer Activity factor for 32 NRT DCH DL bearer Activity factor for 32 NRT DCH UL bearer Activity factor for 384 NRT DCH DL bearer Activity factor for 384 NRT DCH UL bearer Activity factor for 64 NRT DCH DL bearer Activity factor for 64 NRT DCH UL bearer Activity factor for 8 NRT DCH DL bearer Activity factor for 8 NRT DCH UL bearer Activity factor for PCH traffic bearers Activity factor for PCH control UL bearer Activity factor for PCH DL bearer Activity factor for RT PS traffic bearers Activity factor for 128 RT PS AM DL bearer Activity factor for 128 RT PS AM UL bearer

Table 22

DN70296245

Parameters (Cont.)


145


Parameters Activity factor for 128 RT PS UM DL bearer Activity factor for 128 RT PS UM UL bearer Activity factor for 16 RT PS AM DL bearer Activity factor for 16 RT PS AM UL bearer Activity factor for 16 RT PS UM DL bearer Activity factor for 16 RT PS UM UL bearer Activity factor for 256 RT PS AM DL bearer Activity factor for 256 RT PS UM DL bearer Activity factor for 32 RT PS AM DL bearer Activity factor for 32 RT PS AM UL bearer Activity factor for 32 RT PS UM DL bearer Activity factor for 32 RT PS UM UL bearer Activity factor for 64 RT PS AM DL bearer Activity factor for 64 RT PS AM UL bearer Activity factor for 64 RT PS UM DL bearer Activity factor for 64 RT PS UM UL bearer Activity factor for 8 RT PS AM DL bearer Activity factor for 8 RT PS AM UL bearer Activity factor for 8 RT PS UM DL bearer Activity factor for 8 RT PS UM UL bearer Overbooking Switch

Table 22

Parameters (Cont.)


2.7.3.8

Impact on system performance and capacity Transport Bearer Tuning affects transport performance and capacity requirements. This is due to that RAN1096:Transport Bearer Tuning allows operator to adjust the activity factors of AAL2 connections and hence more AAL2 connections fits into the system. Af parameter modification affects only new AAL2 connections, so an old (existing) AAL2 connections are not modified according to the new AAL2 reservation size. Setting the activity factors too low, additional delay and packet losses can occur in the system. In the worst case situation (heavy Iub congestion) it could be possible that some calls are dropped. For more information, see Dimensioning WCDMA RAN.

2.7.3.9


146


DN70296245


2.7.3.10

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

DN70296245


147


2.8 2.8.1

RAN1095: UBR+ for Iub Plane Introduction This feature belongs to Transmission and Transport feature group and it is an optional feature. The ATM Forum has specified several ATM service categories to provide differentiated quality of service for traffic. An ATM service category considers both, the traffic characteristics and the quality of service. • • • • •

Constant Bit Rate (CBR) Real-time Variable Bit Rate (rt-VBR) Non real-time Variable Bit Rate (nrt-VBR) Available Bit Rate (ABR) Unspecified Bit Rate (UBR)

The UBR service category provides best effort service without any throughput guarantee. UBR has the least priority compared with the other ATM service categories. Therefore, the ATM Forum has specified an optional traffic parameter as an extension of the UBR ATM service category denoted as Minimum Desired Cell Rate (MDCR). A UBR implementation that s the MDCR parameter is commonly called UBR+. An UBR+ (Virtual Channel or Virtual Path) connection is defined by its Minimum Desired Cell Rate (MDCR) and Peak Cell Rate (PCR). The ATM Connection ission Control reserves the MDCR for each UBR+ connection (and the PCR for CBR connections) in order to guarantee the throughput, so that the network elements do not allow the sum of the guaranteed bandwidth of the ATM connections to exceed the ATM interface bandwidth. Under high traffic load condition an UBR+ connection supplies the traffic with a throughput of at least the MDCR. The UBR+ connections compete among each other for the bandwidth left from other ATM connections with higher priorities if it exceeds their MDCR. The UBR+ connections share this bandwidth equally among each other by default. However, the Nokia UBR+ implementation provides the network operator an additional configuration parameter called UBRshare to favour individual connections. How much bandwidth an UBR+ connection will get above its MDCR depends on the current traffic conditions and the proportion of its individual UBRshare to the sum of UBRshare of all UBR+ connections on the same ATM interface. If the sum of all the guaranteed bandwidth is equal to the ATM interface bandwidth then the UBRshare parameter does not have any impact on the traffic scheduling (RNC and UltraSite). In this case the bandwidth left over from the other ATM connections is shared proportional to the fraction of its MDCR to the sum of MDCRs of all UBR+ connections. Flexi WCDMA BTS does not have this limitation for traffic scheduling. The RT VBR and NRT VBR service categories are often considered best for variable traffic bit rates especially for bursty traffic. VBR service category is characterized by the traffic parameters PCR, Sustainable Cell Rate (SCR) and Maximum Burst Size (MBS).VBR provides quality of service with respect to delay or ATM cell loss ratio. While UBR+ may transfer traffic up to the PCR for a long time period (if the traffic load conditions allow), VBR service category transfers traffic at the PCR only for a short time period (expressed by the MBS), however in average the maximum service

148


DN70296245


rate is equal to the SCR and it is not allowed to exceed the SCR in order not to harm the Quality of Service requirements of other CBR and VBR connections. On the other hand, the VBR service category makes sure that a burst is sent at PCR until MBS is transferred while UBR+ cannot give this guarantee. The ATM Connection ission Control typically reserves at least the SCR for VBR connections. Benefits for the operator UBR+ allows the efficient usage of the Iub capacity because: • • •

UBR+ connections share the available bandwidth, UBR+ service category does not limit the traffic on individual connections, the UBRshare parameter allows to set priorities among the UBR+ connections.

On the other hand, the application using UBR+ is itself responsible for any Quality of Service requirement because UBR+ does not give any guarantees for delay or cell loss ratio. UBR+ only gives a throughput guarantee. Therefore the AAL2 Connection ission Control checks the bandwidth requirements of AAL2 connections. There are two modes for the AAL2 Connection ission Control: • •

VCC mode VCC bundle mode

In the VCC mode the upper bandwidth limit is given by the guaranteed rates of the individual VCCs, namely PCR for CBR and MDCR for UBR+ ATM service category. Thus setting the MDCR to 0 or some other small value when used with NRT DCH traffic is not in most cases a good idea due to AAL2 CAC restriction. For HSPA traffic, setting the MDCR is not that critical because the HSPA traffic is best effort in nature and no bandwidth is reserved for individual connections. In the VCC mode the UBR+ is mainly useful for HSPA in connection with RAN1099: Dynamic scheduling of HSDPA with Path Selection. In the VCC bundle mode the upper bandwidth limit for the AAL2 CAC is determined by a VCC bundle rate and the check is done across more than one ATM VCC. The VCC bundle mode is included in the feature RAN1100: Dynamic Scheduling for NRT DCH with Path Selection. The modes for the AAL2 CAC shall be equal in BTS and RNC, while RNC autonomously applies the VCC bundle mode for the AAL2 CAC, the operator must enable it explicitly in the BTS. UBR+ for Iub plane complements other features as described in Interdependencies between features.

2.8.2

Functional description UBR+ for Iub plane is a network wide feature and has to be enabled via according license keys in Flexi WCDMA BTS and AXC. If the license is present then the AXC and Flexi WCDMA BTS require an explicit confirmation to take UBR+ into use. More information on configuring the network elements will be provided by relevant network element specific documents. For more information on feature activation, see Activating UBR+ for Iub Plane in Feature RAN1095: UBR+ for Iub Plane, Feature Activation Manual.

DN70296245


149


2.8.3 2.8.3.1

System impact Current implementation The previous RAN releases the UBR ATM service category only for O&M traffic. MDCR is not ed. The CBR ATM service category is applied for all other traffic; plane and control plane.

2.8.3.2


2.8.3.3

Interdependencies between features RAN759: Path Selection The UBR+ service category complements RAN759:Path Selection. RAN759: Path Selection provides the means for traffic differentiation by different AAL2 path types: stringent, bi-level stringent and tolerant. In connection with RAN759: Path Selection, it is recommended to use a UBR+ VCC as bi-level stringent path for NRT-DCH traffic, and another UBR+ VCC as tolerant path for HSPA traffic. Further, it is recommended to use a CBR VCC as stringent path for realtime traffic in order to maintain the QoS. Since NRT traffic carried over the DCH tolerates less transfer delay than HSPA in the Iub interface, the UBR+ parameters need to be set accordingly: • •

MDCR value for NRT-DCH UBR+ VCC shall be set high enough for the guaranteed throughput. UBRshare value for NRT-DCH shall be set higher to get a higher priority over HSDPA.

The AAL2 CAC for bi-level stringent path reserves a little bit more bandwidth than the specified average rate of an AAL2 connection, while the AAL2 CAC for tolerant path does not reserve any bandwidth for an AAL2 connection. Such Path Selection allows the efficient usage of UBR+ for HSPA traffic. Feature RAN1096 Transport Bearer Tuning is recommended in connection with NRT DCH to be used in connection with UBR+, because the activity factor of NRT DCH is by default 1 and the AAL2 CAC will limit the NRT DCH traffic to the MDCR. This should be noted when UBR+ is used with NRT DCH traffic. It is also worth noting, that the Uplink HSDPA control channel is established in the NRTDCH VCC. RAN1099: Dynamic scheduling for HSDPA with Path Selection and RAN1100: Dynamic scheduling for NRT DCH with Path Selection The dynamic scheduling mechanism for HSDPA provides an RNC internal flow control mechanisms to proactively react on traffic congestion inside RNC and a traffic rate shaping mechanism in the Iub interface to prevent ATM cell losses in capacity bottlenecks in the ATM network. Normally, the last mile link to the node B will be the capacity bottleneck. With this feature RNC schedules Rel.99 traffic and HSDPA together such that Rel.99 traffic has a high priority and HSDPA traffic is filled up to the VCC bundle

150


DN70296245


rate if the Rel.99 traffic leaves bandwidth. UBR+ provides here the required flexibility for HSDPA, but UBR+ has not any quality of service guarantee i.e. to adjust the traffic load in case of congestion. RAN1100: Dynamic scheduling for NRT DCH with Path Selection RAN1100: Dynamic scheduling for NRT DCH with Path Selection provides the operator to combine the capacity of ATM VCCs going to one Node B, such that the NRT-DCH can make use of leftover (i.e. not reserved) bandwidth of CBR VCC. RNC applies the VCC bundle mode for the AAL2 CAC implicitly while the operator must enable the VCC bundle mode for the AAL2 CAC explicitly in the BTS. RAN1096: Transport Bearer Tuning RAN1096 Transport Bearer Tuning allows the operator to configure the activity factors of Iub transport bearers. The smaller the activity factor of a transport bearer is the better is the UBR+ service category capabilities used. RAN1096 Transport Bearer Tuning is especially useful for NRT DCH traffic to use leftover bandwidth of CBR VCC in uplink in connection with feature RAN1100: Dynamic scheduling for NRT DCH with Path Selection.

2.8.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

C3.0

OSS4.2

-

-

-

-

2.8.3.5

2.8.3.6


RAS SW component



ASW

RAN

FTM LK



2.8.3.7

Management plane NMS interfaces Impact on planning tool (Planner): The dimensioning of the UBR+ parameters depends on the expected end- traffic profile of the BTS location and on the combination of RAN features. The MDCR and UBRshare should be aligned accordingly. In case RAN1100 Dynamic Scheduling for NRT DCH with Path Selection is not used, the VCC mode of AAL2 CAC is used then the general recommendation is to set the values of the MDCR and UBRshare for NRT DCH greater than for HSPA. It is not rec-

DN70296245


151


ommended to use UBR+ for RT DCH but it is not prohibited either. If an operator uses UBR+ also for RT DCH then the corresponding UBR+ connection shall have the greatest UBRshare value. If the UBRshare is used to differentiate traffic, then the ATM configuration should not reserve all the ATM interface capacity in Ultrasite/AXC and RNC, because of some internal HW constraints of the ATM scheduler. FlexiBTS does not have this HW constraint. In case RAN1100 Dynamic Scheduling for NRT DCH with Path Selection is used then the VCC bundle mode for AAL2 CAC shall be enabled in the BTS. It is recommended to set: • •

the MDCR parameter of the NRT-DCH UBR+ VCC to 0, and the UBRshare parameter of the NRT VCC to a much greater value than the UBRshare parameter of the HSPA VCC.

Note, the VCC bundle mode for AAL2 CAC in the BTS is only applicable to leaf nodes. UBR+ does not give any quality of service guarantee and also no service rate guarantee for rates greater than MDCR. If ATM traffic load counters indicate significant ATM cell losses then a bandwidth bottleneck is very likely. The end- quality of service may also suffer in such a case. The following actions may help to remove the bottleneck: • • • •

Increase MDCR for individual services Increase transmission bandwidth Re-planning of the network topology Increase activity factor of NRT DCH

Impact on transport network configuration management tool: UBR+ introduces new configuration parameters. Impact on reporting tools (Reporter): There are no new feature-specific counters or Key Performance Indicators. ATM interface are able to provide counters per service categories: CBR and UBR/UBR+. Network element interfaces See WCDMA RNC Product Documentation for more information. Management data Files File

Impact

AML

New configuration parameters

FML


Table 23

UBR+ for Iub plane impacts

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

152


DN70296245


File

Impact

PCR

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

MDCR

For the reservation to get a minimum ATM cell throughput for a UBR+ connection.

UBRshare

Determines the weight among UBR+ connections.

Traffic description label (in UltraSite WCDMA BTS and Flexi WCDMA BTS)

String “VCC_BUNDLE” in the traffic descriptor label to activate the VCC bundle mode for AAL2 CAC in the BTS for UL. This string is case sensitive! The feature is disabled if the string is deleted or is misspelled.

Table 24

UBR+ for Iub plane impact on parameters

The additional management data of this feature is listed in Table Counters. No parameters or alarms are related to this feature. Counters IN_REC_CELLS_VP IN_QUEUED_CELLS_VP EG_REC_CELLS_VP EG_QUEUED_CELLS_VP IN_REC_CELLS_VC IN_QUEUED_CELLS_VC EG_REC_CELLS_VC EG_QUEUED_CELLS_VC IN_CBR_REC_CELL IN_CBR_TRANS_CELL IN_CBR_QUEUED_CELL EG_CBR_REC_CELL EG_CBR_TR_CELL EG_CBR_QUEUED_CELL IN_UBR_PLUS_REC_CELL IN_UBR_PLUS_TR_CELL IN_UBR_PLUS_QUEUED_CELL EG_UBR_PLUS_REC_CELL EG_UBR_PLUS_TRANS_CELL EG_UBR_PLUS_QUEUED_CELL Table 25

DN70296245

Counters


153


Counters IN_UBR_REC_CELL IN_UBR_TR_CELL IN_UBR_QUEUED_CELL EG_UBR_REC_CELL EG_UBR_TR_CELL EG_UBR_QUEUED_CELL IN_TOT_REC_CELL IN_TOT_TR_CELL IN_TOT_QUEUED_CELL EG_TOT_REC_CELL EG_TOT_TR_CELL EG_TOT_QUEUED_CELL IN_CAP EG_CAP DISC_HEC ERR_HEC Table 25

Counters (Cont.)


2.8.3.8

Impact on system performance and capacity UBR+ provides a more flexible usage of the available bandwidth compared to CBR.

2.8.3.9


2.8.3.10

Limitations and restrictions UBR+ is only available in the Iub interface. RNC does not UBR+ for Virtual Path. The VCC bundle mode for AAL2 CAC is only applicable if UltraSite WCDMA BTS is a leaf node and in connection with BTS AAL2 multiplexing.

154


DN70296245


2.9 2.9.1

RAN1319: Flexi WCDMA BTS IMA Based AAL2 Uplink CAC Introduction Available capacity for Flexi WCDMA BTS AAL2 uplink AAL2 ission control is modified in case of a link failure in a terminating IMA group. Benefits for the operator In case of a E1/T1 link failure in an IMA group, ission control limits traffic to the value corresponding to the number of operational links in an IMA group. This results in a high quality of service for the itted connections, even in case of a link failure.

2.9.2

Functional description When an individual E1/T1 connection in an IMA group fails, Flexi WCDMA BTS notices this through a physical layer alarm (Loss of signal), and associates this with a particular IMA link. IMA group will reconfigure itself to a lower number of links available. Consequently, Flexi WCDMA BTS modifies the capacity available to equal the number of links available in the IMA group New calls are now itted only up to the actual capacity available. When the link is corrected, or when the adds a new link to the group, the IMA group reconfigures to the full number of links, and the CAC will resume full capacity. BTS

IMA n*E1/T1

RNC

IMA transmission link

Figure 12

2.9.3 2.9.3.1

Flexi WCDMA BTS IMA Based AAL2 Uplink CAC

System impact Current implementation In the current release, Flexi WCDMA BTS Uplink ission control available capacity is not modified by IMA link failures.

2.9.3.2


2.9.3.3


DN70296245


155


2.9.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

-

-

WBTS4.0

-

-

-

-

-

-

2.9.3.5

2.9.3.6


RAS SW component



OSW

RAN

-

-

Management plane Management data No management data are related to this feature.

156


DN70296245


2.10 2.10.1

RAN1063: Hybrid Backhaul with Pseudo Wires Introduction RAN1063:Hybrid Backhaul with Pseudo Wires allows backhauling the BTS over packet-switched technologies, IP and Ethernet in particular. Operators can select from the full variety of IP and Ethernet services, ranging from low-cost to quality offerings. In the first case only HSPA traffic is offloaded to the packet-switched network; an existing path, based on ATM over TDM technologies, is used for all other traffic. In the latter case all traffic can be conveyed over the packet-switched network. This is not a sellable item and not a feature on its own rights, but a solution, which consists of several individual features. Ethernet L2 networks and IP L3 networks can be ed. The feature comprises two operating modes: • •

Hybrid Pseudo Wire Backhaul Full Pseudo Wire Backhaul

The Hybrid Pseudo Wire Backhaul operating mode is based on the RAN05.1 RAN1020: Route Selection feature or the RAS06 RAN759: Path Selection feature. They are needed in order to separate the HSPA traffic from the R99 traffic. In this way it is possible to route the traffic over different interfaces and via a gateway even over a packet network. In the Full Pseudo Wire Backhaul operating mode, all the Iub traffic is carried over the packet-switched network, when a high quality connection is available, avoiding the need for two transport networks. The RAN05.1 RAN1020: Route Selection feature or the RAS06 RAN759: Path Selection feature is also needed in order to provide different Quality of Service to each of the traffic types. The backhauling over the packet-switched network is based on the emulation of the ATM service according to the PWE3 standard of IETF. The ed encapsulation is ATM/MPLS/IP/Ethernet. The Pseudo Wire extends between two PWE3 gateways, one inside the BTS and another stand-alone in the RNC site. The BTS gateway provides a Fast Ethernet or Gigabit Ethernet interface towards the network. On the RNC site the corresponding gateway provides STM-1 interfaces towards the RNC and a Gigabit Ethernet interface towards the network. Stand-alone gateways are supplied by a Nokia Siemens Networks partner and can be purchased as an integral part of the solution. Integrated BTS gateways are Nokia Siemens Networks' own development (IFUH for AXC, and FTIA/FTJA for FTM and the application software). VCCV-BFD is ed for Pseudo Wire OAM. It provides a light weight mechanism which enables to monitor the continuity of the service over the Ethernet connection based on the periodic transmission of control packets. When the control packets are not received within a period of time, an alarm is raised in the BTS, and for stand-alone gateways, the alarm is raised in the stand-alone gateway management system. Benefits for the operator Ethernet is introduced as a BTS backhaul technology. Compared to traditional ATM over TDM technologies Ethernet can substantially reduce transport OPEX. To let operators select from the full variety of IP and Ethernet services RAN1063: Hybrid Backhaul with Pseudo Wires s both of the following applications:

DN70296245

Id:0900d805805dc1dd Confidential

157


•

•

2.10.2

All traffic is conveyed over a packet-switched network. The QoS requirements are set by the most sensitive traffic type (voice). Suitable services are predominantly available in metropolitan areas (Metro Ethernet), where data traffic is also highest. HSPA traffic is offloaded to a packet-switched network, while all other traffic remains to be conveyed over TDM. HSPA traffic is less sensitive to delay and delay variation, and the QoS requirements to the packet-switched network can be relaxed accordingly.

Functional description RAN1063: Hybrid Backhaul with Pseudo Wires is based on Iub ATM service emulation over a packet-switched network. The emulation is performed in accordance with the PWE3 (Pseudo Wire Emulation Edge to Edge) specification of IETF, meaning that ATM cells are encapsulated and tunnelled through the packet-switched network. Architecture According to Pseudo Wire Emulation Edge to Edge Architecture, the ATM service emulation should offer a service equivalent to the native service. For the Customer Edge 1 to Customer Edge 2 direction, native ATM traffic from the Customer Edge 1 is received at the ingress port at Provider Edge 1. Provider Edge 1 encapsulates the traffic over PSN frames, and forwards the frames to Provider Edge 3 across PSN tunnels. Provider Edge 2 de-encapsulates the traffic and forwards it as native ATM traffic to Customer Edge 2. For the Customer Edge 2 to Customer Edge 1 direction it operates in the same way. The following figure depicts the ATM service emulation architecture.

PSN CE1

native service

PE1

PW 1 PW n

PE2

native service

CE2

tunnel Customer Edge 1

Provider Edge 1

Pseudo wire

Provider Edge 2

Customer Edge 2

Emulated Service

Figure 13

ATM service emulation architecture

In RAN1063: Hybrid Backhaul with Pseudo Wires, the RNC and the BTS shall be an instance of the Customer Edge. The RNC PWE3 gateway shall be an instance of the Provider Edge. IP tunnels are established across the packet-switched network between the RNC site and each of the BTS. Each tunnel is identified by the IP addresses of the end points. Inside each tunnel, a variable number of Pseudo Wires are created in order to carry the emulated service. Tunnels and Pseudo Wires are statically created using management procedures since LDP is not ed. The following figure depicts an example of the tunnel topology.

158


DN70296245


PWE3 Gateway

PWs BTS IP Address IP/Ethernet Network

PSN tunnel

RNC

BTS IP Address

IP Address PWs

Figure 14

Example of tunnel topology

In a properly engineered network, the encapsulation and tunnelling do not affect the service offered to the Radio Network Layer, which is completely unaware of the emulation. This feature s two modes of operation: • •

Hybrid Pseudo Wire Backhaul Full Pseudo Wire Backhaul

In the Hybrid Pseudo Wire Backhaul mode there are two paths between the RNC and the BTS. One of the paths is based on traditional TDM technology, which is used to carry delay sensitive traffic and clock reference. The other path is over the packet-switched network using ATM service emulation over Pseudo Wire which is used to carry HSDPA/HSUPA traffic. One sample configuration for this operation mode is depicted in the following figure. Clock recovery RT NRT Control Plane O&M

Clock reference ATM Switch

CBR VCC's UBR + VCC's CBR CBR VCC's VPC

nxE1 PHY

TDM Network

UBR VCC

CBR VCC's CBR UBR VCC's PHY VPC CBR VCC's nxSTM1 UBR + VCC

ATM port rate limiting HSDPA AAL2 UBR + CID's VCC's CBR AAL2 UBR + VPC

Figure 15

NRT Control Plane O&M

Optional VCC bundle

PWE3 Gateway


HSUPA CID's VCC's

Node B Transmission

RT

PWE3 nxUBR + Gateway STM1 CBR VCC's PHY VPC UBR + VCC's

Ethernet port rate Tunnel limiting

AAL2 HSDPA CID's AAL2 CID's HSUPA

1 unshaped CBR VPC per Node B

RNC

Hybrid Pseudo Wire Backhaul mode

In the Full Pseudo Wire Backhaul mode only path over the packet-switched network is provisioned, which carries all the traffic between the RNC and the BTS. One sample configuration for this operation mode is depicted in the following figure.

DN70296245


159


Ethernet port rate limiting ATM port rate shaping Control Plane CBR VCC's O&M UBR VCC RT CBR VCC's

CBR VPC

NRT UBR + VCC

PWE3 Gateway

Clock reference (GPS, 2G, TDM, etc)


nxSTM1

VPC's for other Node B's

PHY

CBR VPC Shaped

CBR VPC

PHY

HSDPA

UBR + VCC's CBR HSUPA UBR + VCC's VPC

Tunnel

PWE3 Gateway

Node B Transmission Figure 16

Control Plane

CBR VCC's

O&M

CBR VCC's

RT

UBR + VCC

NRT

UBR + VCC's HSDPA UBR + VCC's HSUPA

CBR VPC

PHY

CBR VCC's

Unshaped

RNC

Optional VCC bundle

Full Pseudo Wire Backhaul mode

In case the BTS is not connected to a TDM network, synchronization has to be provided through other means, for example, a 2MHz signal fed from a neighbouring GSM/EDGE BTS or a GPS receiver. There are two possible configurations for the BTS site: • •

Integrated Stand-alone

In the integrated configuration the BTS is equipped with Ethernet and TDM interfaces. The Pseudo Wire termination function is carried out by the BTS. The following figure depicts this configuration (Hybrid PW Backhaul mode shown).

TDM Network


ATM


Tunnel



nxSTM1 ATM

TDM I/F

PWE3 Gateway BTS

RNC

Figure 17

BTS Pseudo Wire terminating function (Ethernet and TDM interfaces)

For trial purposes, a stand-alone configuration is ed, where there is an external gateway in the BTS site that terminates the Pseudo Wire. The connection between the gateway and the BTS is based on E1/T1/JT1. The following figure depicts this configuration (Hybrid PW Backhaul mode shown):

160


DN70296245


TDM Network


ATM


PWE3 Gateway TDM I/F

Ethernet Tunnel I/F


nxSTM1 ATM

PWE3 Gateway

BTS

Figure 18

TDM I/F

RNC

BTS Pseudo Wire terminating function (E1/T1/JT1)

Quality of Service In order to ensure that the different types of traffic receive appropriate quality of service, this feature implements Differentiated Services. The following mechanisms are provided: •

•

•

Traffic Management The PWE3 gateways provide Pseudo Wire traffic prioritisation. For the BTS solution, prioritization is based on the ATM service class. Traffic Shaping The Pseudo Wire traffic towards the packet-switched network is shaped in order to conform to the network SLA. Traffic Marking For L3 networks, IP packets are marked with a configurable DS value. The DS is freely defined for each Pseudo Wire. For L2 networks, Ethernet frames carry a VLAN tag with configurable priority bits. The priority bits are freely defined for each Pseudo Wire.

Activating the feature This feature does not require activation. However, it is required to activate the features ing RAN1063: Hybrid Backhaul with Pseudo Wires. See the documentation of the ing features for further details. PSN Fault Management Usually PSNs do not any end-to-end OAM functions. The solution for RAN1063: Hybrid Backhaul with Pseudo Wires is based on VCCV-BFD, which monitors the status of the Pseudo Wire. It is according to the IETF standards. It performs the continuity check of each individual Pseudo Wire, and if a failure is detected, it is reported by the PWE3 gateways to the management system. VCCV-BFD control packets are sent over an associated control channel, which share the Pseudo Wire with the data traffic. The separation of the control channel from the data traffic is done by using a Pseudo Wire associated channel header instead of the control word. The format is depicted in the following figure.

DN70296245


161


0

3 4 0001

7 8 Version

Figure 19

15 16 Reserved

31 Channel Type

Format of the Pseudo Wire associated channel header

For RAS06, the values used are depicted in the following figure. 0

3 4 0001

Figure 20

7 8 0000

15 16 00000000

31 0x0007

RAS06 settings for Pseudo Wire associated channel header

In order to enable the HSDPA service protection, it is necessary to forward the status of the PSN to the RNC. This is accomplished by the alarm forwarding function in the RNC PWE3 gateway. The following procedures are ed: • • • •

On PW On PW On PW On PW

forward defect state entry, ATM F5 AIS is forwarded to the RNC. forward defect state exit, ATM F5 AIS forwarding is stopped. reverse defect state entry, ATM F5 RDI is forwarded to the RNC. reverse defect state exit, ATM F5 RDI forwarding is stopped.

Additional PSN fault management can be performed by using Ping or Traceroute tools from the RNC PWE3 gateway towards the BTS and vice versa. Protection Two different protection strategies are used for RAN1063: Hybrid Backhaul with Pseudo Wires: • •

Link protection HSPA service protection

Link protection is based on the redundancy of the physical links. The protection is applied to the following links: • • •

ATM link, over the TDM network, between RNC and BTS Protection is based on the existing SDH and PDH protection features. ATM link, between RNC and RNC PWE3 gateway Protection is based on SDH MSP 1+1. Ethernet link between the PWE3 gateway and the packet switched network Refer to the external equipment documentation.

HSPA service protection refers to the RAN capability to change the channel type for the HSDPA and HSUPA traffic based on the availability transport resource for the packet switched network path. On detection of the unavailability of the PSN path (Ethernet link, ATM link, RNC PWE3 gateway or internal in RNC) the RNC will switch the HSDPA and HSUPA calls to Release 99 calls over the TDM path.

2.10.3 2.10.3.1

System impact Current implementation Without RAN1063: Hybrid Backhaul with Pseudo Wires, all data is carried over ATM over TDM-based technologies. This feature is implemented in RAS06.

162


DN70296245


2.10.3.2

2.10.3.3

Hardware requirements Requirement

Reason

IFUH

This interface unit is needed to Ethernet interface in AXC.

FTIA

Interface unit needed to Ethernet interface in Flexi WCDMA BTS. E1/T1/JT1 interface with symmetrical line is also provided.

FTJA

Interface unit needed to Ethernet interface in Flexi WCDMA BTS. E1 interface with coaxial line is also provided.

RNC PWE3 GW

External equipment used to Pseudo Wire termination at the RNC side.

Interdependencies between features In order to separate the UMTS traffic into multiple VCCs, this feature requires one of the two following optional features: • •

RAN759: Path Selection RAN1020: Route Selection

Additionally, the following optional feature enables a more flexible configuration in the RNC allowing multiple VCCs in more than one VPC: •

RAN619: Flexible Connection of VPCs for WBTS Object in RNC

For the SW in the BTS, the following application software feature is required: •

RAN1142: ATM over Ethernet for BTS

For the HW in the BTS, the following hardware features are also required: • •

2.10.3.4

Release

RAN1064: Ethernet+E1/T1/JT1 Interface Unit (Iub Plane) for Flexi WCDMA BTS (for Flexi WCDMA BTS) RAN1097: Ethernet Interface Unit IFUH (Iub Plane) for AXC (for UltraSite WCDMA BTS)


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

-

WBTS4.0

WBTS4.0

C3.0

OSS4.2

-

-

-

-

2.10.3.5

DN70296245


RAS SW component



ASW

RAN

-

-


163


2.10.3.6

Control and plane RAN1063: Hybrid Backhaul with Pseudo Wires is based on the emulation of Iub ATM service by encapsulating ATM cells over IP according to the IETF draft Encapsulation Methods for Transport of ATM Over MPLS Networks and Encapsulating MPLS in IP or Generic Routing Encapsulation. The transport network protocol stack is depicted in the following figure. Upper layer protocols

Upper layer protocols

ATM

ATM

RNC

ATM

Control word

Control word

PW header (MPLS)

PW header (MPLS)

IPv4

IPv4

Ethernet-Mac

Ethernet-Mac

Ethernet-Phy

Ethernet-Phy

PWE gateway

Figure 21

Air interface

BTS

Transport network protocol stack

A variable number of ATM cells belonging to a single VCC or to multiple VCCs are concatenated, according to the N to 1 encapsulation mode. The cell encapsulation is controlled by two parameters: •

•

Concatenation factor It defines the maximum number of cells which can be concatenated in one single packet. By adjusting the concatenation factor, the system can ensure that the MTU of the path is not exceeded. A high concatenation factor will lead to efficient Pseudo Wire due to the low relative overhead. A small concatenation factor will reduce the packetisation time. Packetisation timer It defines the maximum packetisation time for a packet that is creating by encapsulating cells before it is scheduled for forwarding. A small packetisation timer will introduce little delay in the packetisation. A large packetisation timer will ensure that packets are large, minimizing the overhead and increasing the efficiency.

Actual packet size depends on the concatenation factor, the packetisation timer and the load of the tributary VCCs. After concatenation, a control word is optionally appended. If VCCV-BFD is used, the control word is required. The format of the control word is depicted in the following figure: 0

3 4 0000

Figure 22

7 8 Flags

9 10 RES

15 16 Length

31 Sequence Number

Format of the control word

For RAS06, all the fields are set to 0.

164


DN70296245


0

3 4 0000

Figure 23

7 8 0000

9 10 00

15 16

31

000000

All 0's

RAS06 settings for the control word

Each Pseudo Wire is identified by a label carried inside an MPLS shim. The format of the MPLS shim is depicted in the following figure. 0

19 20 Label

Figure 24

22 23

EXP

24

S

31 TTL

Format of the MPLS shim

For the Pseudo Wire application, the following format of the MPLS shim is used. 0

19 20 PW

Figure 25

22 23 000

24

1

31 All 1's

Format of the MPLS shim (Pseudo Wire application)

The concatenated ATM cells, together with the control word and the MPLS shim are encapsulated inside IP packets. IP version 4 is used. The IP packets are further encapsulated inside Ethernet frames. Ethernet frames can have optionally VLAN format. The following figure depicts the structure of the Ethernet carrying a Pseudo Wire packet. Transmission order 0

31 Ethernet trailer Cell Payload (48 bytes) VPI

VCI

PTI

C

PTI

C

PTI

C

VPI

VCI Cell Payload (48 bytes)

VPI

VCI Control Word (optional) Pseudo Wire Header

Transmission order

Cell Payload (48 bytes)

IP header Ethernet header

Figure 26

2.10.3.7

Structure of the Ethernet carrying a Pseudo Wire packet

Management plane NMS interfaces Impact on planning tool:

DN70296245


165


No effects. Impact on management tools: For information on Flexi WCDMA BTS and UltraSite WCDMA BTS, see RAN1142: ATM over Ethernet for BTS. Impact on radio network configuration management tool: No effects. Impact on transport network configuration management tool: No effects. Impact on reporting tools: For information on Flexi WCDMA BTS and UltraSite WCDMA BTS, see RAN1142: ATM over Ethernet for BTS. Impact on monitoring tools: No effects. Impact on optimising tools: No effects. Network element interfaces The configuration of the parameters defined in the Management data section is performed by using the following tools: • • •

For Flexi WCDMA BTS: BTS Element Manager. For UltraSite WCDMA BTS: AXC Element Manager For external equipment: vendor specific Element Manager

See the product documentation for more detailed information. Management data Files: For the Flexi WCDMA BTS and UltraSite WCDMA BTS, see RAN1142: ATM over Ethernet for BTS. For the RNC PWE3 gateway, refer to the external equipment documentation. Statistics: For the Flexi WCDMA BTS and UltraSite WCDMA BTS, see RAN1142: ATM over Ethernet for BTS. For the RNC PWE3 gateway, refer to the external equipment documentation. Parameters: For the Flexi WCDMA BTS and UltraSite WCDMA BTS, see RAN1142: ATM over Ethernet for BTS. For the RNC PWE3 gateway, refer to the external equipment documentation. Alarms: For the Flexi WCDMA BTS and UltraSite WCDMA BTS, see RAN1142: ATM over Ethernet for BTS. For the RNC PWE3 gateway, refer to the external equipment documentation. The management data of this feature is listed in the following table.

166


DN70296245


Parameters

Counters

Alarms


PwUas_15


PwSes_15 PwtUnknown PWHdr_15 PwtPktRecv_ 15 PwtPktTrans m_15


2.10.3.8


2.10.3.9


2.10.3.10

Limitations and restrictions In the Full PW Backhaul mode, Radio network synchronisation is not ed by the Iub. Thus, it is required to provide another reference for the clock: GPS, TDM link, GSM BTS, and so on.

DN70296245


167


2.11 2.11.1

RAN1142: ATM over Ethernet for BTS Introduction This feature consists of the BTS software to in the emulation of one or multiple ATM VCCs over a packet-switched network. The emulation is performed in accordance with the PWE3 (Pseudo Wire Emulation Edge to Edge) specification of IETF, meaning that ATM cell flows are tunnelled through the packet-switched network. ATM cells are concatenated inside IP packets. This feature is one of the building blocks of RAN1063: Hybrid Backhaul with Pseudo Wires. ATM over Packet is ed for Ethernet interfaces on IFUH (UltraSite WCDMA BTS) and FTIA / FTJA (Flexi WCDMA BTS). Benefits for the operator The BTS can be backhauled over packet-switched technologies, IP and Ethernet in particular. Operators can select from the full variety of IP and Ethernet services, ranging from low cost to quality offerings.

2.11.2

Functional description Activating the feature This is an optional feature that requires a license in the BTS. The following steps are required in order to configure the feature: PWE3 node configuration • • • • • • •

Local IP address configuration (Note: this IP address is different to the management IP address) Network mask configuration Default route configuration Remote IP address configuration Control word usage configuration Optional VLAN activation Optional VLAN id configuration (required if VLAN is enabled)

Port rate limiting configuration • •

Ethernet Bandwidth configuration BTS ATM PW Port Bandwidth configuration

PW setup • • • • • • •

168

VCC to PW configuration Packetisation timer configuration UL cell concatenation factors configuration DL cell concatenation factors configuration PW labels configuration PHB Differentiated Services configuration Optional VCCV-BFD activation

Id:0900d805805dc1da Confidential

DN70296245


VCCV-BFD configuration • •

BFD Desired Minimum Transmission Interval configuration BFD Required Minimum Reception Interval configuration

PW Differentiated Services configuration • • • •

PHB configuration DS configuration Optional VLAN priority configuration ATM traffic management configuration

Architecture ATM over Ethernet BTS is one of the building blocks of RAN1063: Hybrid Backhaul with Pseudo Wires. As described in RAN1063: Hybrid Backhaul with Pseudo Wires, for Hybrid PW Backhaul mode the BTS is equipped with Ethernet and TDM interfaces. The Pseudo Wire termination function is carried out by the BTS. The following figure depicts the configuration.

TDM Network


ATM


Tunnel



nxSTM1 ATM

TDM I/F

PWE3 Gateway BTS

RNC

Figure 27

BTS Pseudo Wire terminating function (Ethernet and TDM interfaces)

For Full PW Backhaul mode the BTS is equipped only with Ethernet interfaces. The Pseudo Wire termination function is also carried out by the BTS. The following figure depicts the configuration.

ATM termination


Tunnel


ATM termination nxSTM1 ATM

TDM I/F

PWE3 Gateway Node B

Figure 28

DN70296245

RNC

BTS Pseudo Wire terminating function (Ethernet interface)


169


VCCV-BFD functionality VCCV-BFD provides a light weight mechanism which enables to monitor the continuity of the service over the Ethernet connection based on the periodic transmission of control packets. Control packets are sent by the BTS and by the RNC PWE3 gateway to each other. When the control packets are not received within a period of time, an alarm is raised in the BTS, and for stand-alone gateway, the alarm is raised in the gateway management system. When a BFD session is started, the BTS and the RNC PWE3 gateway will exchange the BFD parameters which determine the transmission interval of the control packets in each direction, and the detection time. The parameters are: • • •

DetectMult: number of BFD Control packets that have to be lost before declaring that the session is down. RequiredMinRxInterval: minimum interval between received BFD Control packets that the local system is capable of ing. DesiredMinTXInterval: minimum interval that the local system would like to use when transmitting BFD Control packets.

The detection time is calculated with the following formula: Detection time = DetectMult (received from the peer) x MAX[RequiredMinRxInterval, DesiredMinTXInterval (received from the peer)] The detection timer is reloaded every time a valid BFD control packet is received. If packets are not received before the timer expires, the link in ingress direction is declared down. In order to limit excessive detection times, the following upper limits are also set: • •

UltraSite WCDMA BTS: • maximum detection time = 30s Flexi WCDMA BTS • maximum detection time = 120s

If the calculated detection time exceeds these limits, the limit is used instead.

2.11.3 2.11.3.1

System impact Current implementation Without ATM over Ethernet for BTS, all data is carried over ATM over TDM-based technologies. This feature is implemented in RAS06.

2.11.3.2

170

Hardware requirements Requirement

Reason

IFUH

This interface unit is needed to Ethernet interface in AXC.


DN70296245


2.11.3.3

Requirement

Reason

FTIA

Interface unit needed to Ethernet interface in Flexi WCDMA BTS. E1/T1/JT1 interface with symmetrical line is also provided.

FTJA

Interface unit needed to Ethernet interface in Flexi WCDMA BTS. E1 interface with coaxial line is also provided.

Interdependencies between features This feature is needed for the following feature: •

RAN1063: Hybrid Backhaul with Pseudo Wires

The following hardware features are also required: • •

2.11.3.4

Release

RAN1064: Ethernet+E1/T1/JT1 Interface Unit (Iub Plane) for Flexi WCDMA BTS (for Flexi WCDMA BTS) (FTIA and FTJA units) RAN1097: Ethernet Interface Unit IFUH (Iub Plane) for AXC (for UltraSite WCDMA BTS)


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

-

-

WBTS4.0

C3.0

OSS4.2

-

-

-

-

2.11.3.5

2.11.3.6


RAS SW component



ASW

RAN

FTM LK


Control and plane For details on the effect over the control and plane, see RAN1063: Hybrid Backhaul with Pseudo Wires.

2.11.3.7

Management plane NMS interfaces Impact on planning tool: No effects. Impact on management tools: The configuration of the parameters is performed by the NetAct. Additionally, the license can be managed by the NetAct.

DN70296245


171


Impact on radio network configuration management tool: No effects. Impact on transport network configuration management tool: No effects. Impact on reporting tools: The counters for this feature are collected to NetAct from AXC or Flexi WCDMA BTS, depending on the used BTS type. The AXC counters are transferred directly to NetAct and Flexi WCDMA BTS counters are collected through RNC NEMU to NetAct. The PM data is saved to the NetAct database and it can be analysed using NetAct reporting applications. The measurement data cannot be analysed in NEMU, since it is not saved to the NEMU database. Impact on monitoring tools: No effects. Impact on optimising tools: No effects. Network element interfaces The configuration of the parameters defined in Management data is performed by using the following tools: • •

For Flexi WCDMA BTS: BTS Element Manager. For UltraSite WCDMA BTS: AXC Element Manager

See the product documentation for more detailed information. Additionally, the Element Manager can manage the license. The Element Manager also allows viewing the recent counter history (last 24 hours). Management data Files: File

Impact

AML


TML


Table 26

ATM over Ethernet for BTS file impacts

AML belongs to the site configuration files for AXC/ UltraSite WCDMA BTS. TML belongs to site configuration files of Flexi WCDMA BTS. Network Management tools such as RAC online provides those site configuration files. Statistics:

172


DN70296245


Statistics

Use

PwUas_15

Unavailable Seconds (UAS): Counts the number of seconds for which the PW interface is unavailable. The interface is defined unavailable from either the beginning of 10 contiguous SES and/or a defect. An interface is available again after a 10-second absence of all defects and SES. While the interface is unavailable, the only count that is incremented is UAS. Defect: BFD down in the ingress or egress direction only.

PwSes_15

Severely Errored Seconds (SES): Counts the number of seconds that contain a defect. Defect: BFD down in the ingress or egress direction. SES are not incremented during Unavailable Seconds (UAS).

PwtUnknownPWHdr_15

The number of received Ethernet frames whose pseudowire header is not configured or has a reserved value.

PwtPktRecv_15

Number of received packets on a tunnel.

PwtPktTransm_15

Number of transmitted packets on a tunnel.

EthIfInOcts_15

Number of octets in valid frames received on the interface.

EthIfOutOcts_15

Number of octets in valid frames transmitted on the interface.

EthIfInPkt_15

Number of Ethernet packets received on the interface (errored and non-errored).

EthIfOutPkt_15

Number of transmitted Ethernet packets on the interface.

EthIfInPktErr_15

Number of Ethernet packets received with FCS errors.

EthIfInUnknownProtos_15

The number of packets received via the interface which were discarded because of an unknown or uned protocol. (This counter not ed by Flexi WCDMA BTS).

EthIfOutDiscShaping_15

Number of Ethernet TX packets discarded due to rate shaping.

EthUnknownPSNHdr_15

The number of Ethernet frames received whose PSN header is not configured or has a reserved value.

EthIfInUnknownVLAN_15

Number of received Ethernet packets with an unknown VLAN ID.

Table 27

ATM over Ethernet for BTS statistics

Parameters: Parameter

Use

Set of ed vcCTPs

List of VCC which are mapped to one PW.

Uplink MPLS Header

Uplink MPLS Header (inner label)

Downlink MPLS Header

Downlink MPLS Header (inner label)

Shaped Ethernet Bandwidth

Shaped Ethernet bandwidth in kbps. Maximum is the capacity of the Ethernet port 10, 100 or 1000 Mbps.

Control Word Enable

Enables the use of the PW control word for all the PWs.

Packetization Timer

Defines for each PW the maximum time allowed to create a PW frame.

Table 28

DN70296245

ATM over Ethernet for BTS impact on parameters


173


Parameter

Use

Uplink Concatenation Factor

Defines for each PW the maximum number of cells that can be encapsulated into a PW frame in the uplink direction. This parameter is used to the control the encapsulation.

Local IPv4 Address

Defines the local IPv4 address of the BTS where the PW is terminated.

Subnet Mask

Defines the subnet mask for Iub the BTS.

Next Hop IP Address

Defines the IPv4 address of the default gateway for the BTS.

PSN priority map

Mapping the Pseudo Wire Per-Hop-Behaviour priorities to values for DS (TOS).

VLAN priority map

Mapping the Pseudo Wire Per-Hop-Behaviour priorities to VLAN priorities

Per Hop Behaviour DiffServ

Defines the PHB for each PW or for the IP host traffic.

Bidirectional Forwarding Enable

This parameter switches the BFD session on or off for each PW.

Desired Minimum Transmit Interval

Defines the minimum transmission interval for the BFD control packets.

Required Minimum Receive Interval

Defines the minimum reception interval for the BFD control packets that the BTS s.

Remote IPv4 Address

Defines the IPv4 address of the remote PWE3 GW (RNC GW) where the PW is terminated.

VLAN Tag List

VLAN IDs allocated to one tunnel.

Table 28

ATM over Ethernet for BTS impact on parameters (Cont.)

Alarms: Alarm

Description

PW status alarm in the egress direction

The alarm is set when the BFD message from the far end contains the diagnostic code = 'Control Detection Time Expired' AND no ingress alarm is present. The alarm is cleared when the BFD message from the far end contains a status different from 'Down' or when the BFD function is disabled.

PW status alarm in the ingress direction

The alarm is set when no BFD message is received at the local end during the detection time. The alarm is cleared once a BFD message is received at the local end or when the BFD function is disable. This alarm is independent from the alarm in egress direction.

Table 29

ATM over Ethernet for BTS impact on alarms

No management date is related to this feature.

174


DN70296245



2.11.3.8


2.11.3.9


DN70296245


175

Operability features


3 Operability features 3.1

RAS06 documentation for operability features See the following table for more detailed information on WCDMA RAN functionality and feature activation:

Feature ID: Name

Functional Area Description

Feature Activation Manual

RAN1199: RNC GUI for BTS Connection Resources

WCDMA RAN and I-HSPA Network Element Management


RAN1160: Collection of Key Counters

WCDMA RAN and I-HSPA Performance Management


RAN1161: Alarms for PM Measure- WCDMA RAN and I-HSPA Performent Data Transfer Failures mance Management


RAN1150: RNC for Traffica

WCDMA RAN and I-HSPA Performance Management

Feature RAN1150: RNC for Traffica, Feature Activation Manual

RAN1810: Sleeping Cell improvement

This feature has no related documents.


RAN1823: Recovery Logging Improvement



RAN1128: Dynamic Access Class Restriction

WCDMA RAN and I-HSPA Access Regulation


RAN212: Selectable RNW Plan Activation Mechanism

WCDMA RAN and I-HSPA Configuration Management


RAN1059: Flexi WCDMA BTS for RNS Split



RAN1084: Direct Activation of RNW Changes Using NWI3



RAN1809: AAL2 multiplexing COCO modification



RAN618: Centralised Information Management for BTS

WCDMA RAN and I-HSPA O&M Security


RAN1159: IP Address & Port based Filtering for BTS LMPs



RAN33: IP Security for O&M Traffic between RNC and NetAct


Feature RAN33: IP Security for O&M Traffic between RNC and NetAct, Feature Activation Manual

RAN1451: Mass Change of Local BTS s



Table 30

176

Operability features

Id:0900d8058095a98e Confidential

DN70296245


3.2 3.2.1

RAN1199: RNC GUI for BTS Connection Resources Introduction This feature introduces new functionality to view RNC connection recources for BTS in the RNC GUI object browser application. Benefits for the operator There are OPEX savings because of easier and faster troubleshooting capabilitites in RNC.

3.2.2

Functional description The feature improves troubleshooting with RNC element manager by introducing a new RNC GUI solution for tracking the operational status of different BTS connections and involved RNC HW units with their operating statuses. The BTS Connection Resource information includes the following information: • •

•

•

DN70296245

RNC • RNC identification WBTS • WBTS name (RNW parameter WBTSName) • WBTS additional information (RNW parameter BTSAdditionalInfo) • Related Connection Configuration Identifier WCELs • WCEL state • HS-DSCH operative state • LcrId • LAC • Cid • SAC • RAC • UARFCN • PriScrCode • UE count • Operational states of Common channels (FACH, PCH, RACH, FACH-C/Connect, FACH-C/Idle, FACH-U and FACH-S) • Related DMCU units for Common channels • Snapshot of the amount of calls: emergency, signalling link, AMR, RT CS, NRT CS, RT PS, NRT PS, HSDPA and HSUPA. (Note: In case of a HSUPA call, the HSDPA direction is not shown separately.) Iub link configuration • C-NBAP link • External TPI (ATM interface, VPI, VCI) • ATM interface status • Operational state • Related ICSU index • D-NBAP links (1-6)


177


• • • • • • • • • • • • • • • • • • • • •

3.2.3 3.2.3.1

External TPI (ATM interface, VPI, VCI) ATM interface status Operational state Related ICSU index AAL2 signalling links (1-6) ATM interface status External TPI (ATM interface, VPI, VCI) Operational state Related ICSU index AAL2 plane links (1-18) ATM interface status External TPI (ATM interface, VPI, VCI) Operational state Related A2SU AAL2 path ID A2EA Route ID AAL2 path bandwidth (UL / DL) Average total load of AAL2 path (UL / DL) Number of unsuccessful resource reservations Number of successful resource reservations

System impact Current implementation The data related to a WBTS connection can be seen in the RNW Object Browser (for example, NBAP link states) and by using MMLs (for example: ATM link status). The information is scattered into different interfaces.

3.2.3.2


3.2.3.3


3.2.3.4

Release

178


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

-

-

-

-

-


DN70296245


3.2.3.5

3.2.3.6


RAS SW component



ASW

RAN

RNC LK


Management plane Network element interfaces Feature is available as RNC EM application in RNC OMS. Application provides interface to browse through WBTS connection data. Application provides topology tree from which WBTS's can be browsed one by one. Management data

3.2.3.7

Parameters

Counters

Alarms




Impact on system performance and capacity This feature has no special capacity requirements or effect.

DN70296245


179


3.3 3.3.1

RAN1160: Collection of Key Counters Introduction The feature enables NetAct to provide a set of Key Counters in short intervals in a single new measurement. The key counters are collected from the existing cell-level measurements produced by RNC. Benefits for the operator CAPEX savings are achieved when accurate measurements are required. OPEX savings result from a possibility to improve measurement utilisation.

3.3.2

Functional description NetAct provides a new Key Counter measurement, which can include a collection of priority counters from the cell-level measurements produced by the RNC. The data is accessible the same way as any other PM data via NetAct tools and interfaces. Key Counter measurement provides an opportunity for capacity savings in the NW management systems. The source measurements can be collected in parallel with the Key Counter measurement, but the measurement interval for the new measurement can be set to be different. This enables using the Key Counter measurement to collect some of the data more frequently, without compromising too much on the system capacity by collecting everything at the finest granularity. The new measurement can be collected for example at 15min interval while keeping the source measurements on 60 minutes. There will be more flexibility on configuring the contents of the new measurement in OSS5, but this requires manual commissioning tasks, and there are restrictions also on, for example, retaining data over changes in the measurement definition. The measurement ID for Key Counter measurement is M1050. This is just for the istrative purposes of the measurement itself. The counters in the key counter measurement will have the same Mxxxx Id and abbreviation as used in the "originating" measurement.

3.3.3 3.3.3.1

System impact Current implementation Currently, the whole measurement with all the counters needs to be collected if any of the included counters is needed. The interval of the whole measurement has to be set according to the finest time granularity needed for any of its counters.

3.3.3.2


3.3.3.3

Interdependencies between features There are no dependencies with other RAN features, but the basic PM data collection system has to be in place before the feature can be utilised.

180


DN70296245


3.3.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

-

-

-

-

3.3.3.5

3.3.3.6


RAS SW component



ASW

RAN

RNC LK


Control and plane No effect.

3.3.3.7

Management plane NMS interfaces The feature adds one new measurement, which is handled in a similar way as the other existing radio network performance measurements generated by RNC. Network element interfaces No changes in RAN NE UIs. Management data

3.3.3.8

Parameters

Counters

Alarms




Impact on system performance and capacity The feature adds one new measurement, which will require some processing and storing capacity from OMS and NetAct. Properly used it allows reducing the total measurement load by offering a way to collect the key counters as one entity with common interval settings instead of activating everything with for example 15 minutes interval.

3.3.3.9

Other impacts The schedule of the source measurements will be adjusted to 24 hours, 7 days a week.

DN70296245


181


3.4

3.4.1

RAN1161: Alarms for PM Measurement Data Transfer Failures Introduction The feature introduces new alarms for noticing problems in the PM data collection. Benefits for the operator OPEX savings result from faster discovery of problems in the measurement collection mechanism.

3.4.2

Functional description This feature introduces new alarms for ensuring correct information about the problems in the PM data transfer. New alarms are introduced for the following failure situations: • • •

OMS is not able to retrieve Measurement data from RNC OMU or BTS NetAct is not able to retrieve Measurement data from OMS. There are problems in measurement data processing.

Alarms are cancelled when the situation is recovered. There are various in-built mechanisms for recovering from problems, so the alarms are only generated for situations that: • • •

Result in loss of data Require explicit action for resolution Indicate a problem in performance of measurement data processing or transfer

The new PM alarms are only intended to cover the PM-specific aspect of the data pipe. There are separate mechanisms to notice, for example, general problems with DCN or RNC - BTS connections. New group for OMS alarms is added (71000-72000). New alarms introduced by this feature are: • • • •

3.4.3 3.4.3.1

71000 PM FTP CONNECTION FAILED 71001 MEASUREMENT DATA NOT TRANSFERRED 71002 MEASUREMENT DATA ERROR 71003 OMS MEASUREMENT DATA PROCESSING OVERLOAD

System impact Current implementation There are mechanisms for noticing generic O&M-related failures, for example, DCN breaks, but mostly no indicators for the PM-specific problems.

3.4.3.2


182

Id:0900d805807f712c Confidential

DN70296245


3.4.3.3

Interdependencies between features There are no dependencies to other RAN features as such, but the basic FM and PM functionality has to be available.

3.4.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

-

-

-

-

3.4.3.5

3.4.3.6


RAS SW component



OSW

RAN

-

-


3.4.3.7

Management plane NMS interfaces No effect. Network element interfaces No changes in RAN NE UIs.

DN70296245


183



Counters

Alarms



71000 PM FTP CONNECTION FAILED 71001 MEASUREMENT DATA NOT TRANSFERRED 71002 MEASUREMENT DATA ERROR 71003 OMS MEASUREMENT DATA PROCESSING OVERLOAD

3.4.3.8


3.4.3.9

Other impacts No effect.

184


DN70296245


3.5 3.5.1

RAN1150: RNC for Traffica Introduction The Traffica tool s real-time monitoring of RNC measurements. The real-time information is available on both the transport and radio layers. Benefits for the operator Statistical data is available in real time.

3.5.2

Functional description Both the IPA-RNC and the multicontroller RNC (mcRNC) Traffica. The tool is also used for RNC measurements. Traffica s real-time monitoring, which can be used, for example, for troubleshooting purposes. The information is provided on both the transport and radio layers, for example: • •

transport layer: ATM VC counter, AAL2 path CAC statistics, and Internal CAC statistics radio layer: Call handling counters

The Traffica tool gets the data from up to three RNCs by pre-defined, event-based realtime traffic (RTT) reports. The following event-triggered reports are equipment (UE) specific, that is, they also include the international mobile subscriber identity (IMSI) of the . This enables the operator to monitor events related to a specific subscriber: •

• •

Radio resource control/radio access bearer (RRC/RAB) report for Service use cases This report provides detailed information on each RRC connection and RAB that is established or released in the RNC. Soft Handover Failure event-triggered report for Mobility use cases Packet call failure report

Periodic reports produced with a 60-second interval are ed by the IPA-RNC, not by the mcRNC, with one exception occurring at the very end of the list: • •

•

•

•

DN70296245

External AAL2 transport resource report for Resource use cases Internal AAL2 transport resource report for Resource use cases This report shows, for example, the number of high-speed packet access (HSPA) s per data and macro diversity processor group (DMPG). ATM VC Traffic report This report provides information on the transferred data on RNC external ATM interfaces. This is related to Throughput use cases. Call resource handling report This report can be used, for example, to view the number of services—signaling radio bearer (SRB), real time (RT), non-real time (NRT), and HSPA—in each initial call segment unit (ICSU). Call resource error code report This report shows the number of the most common error codes related to call resource allocations. Reasons for errors can be, for example, a DMPG resource shortage or Iub congestion.

Id:0900d80580956e54 Confidential

185


•

Packet call statistics report This report is ed both in the IPA-RNC and the mcRNC.

The listed use cases are documented in Monitoring WCDMA RAN. The RNC sends each RTT report to the Primary Traffica Network Server using a dedicated interface. There is always one Primary Traffica Network Server for each RTT; thus, only one Traffica server can receive a particular RTT at a time. Traffica analyzes the data and creates key performance indicators (KPIs) based on the data. These KPIs can be visualized in Traffica real-time graphs. Event data is also stored in the Traffica database for short periods of time for troubleshooting purposes. Optionally, both KPIs and RTTs can be exported from the Traffica system to long-term storage for long-term reporting purposes.

3.5.3 3.5.3.1

System impact Current implementation This can be done by basic counters, but the time to obtain the information is tied to the measurement intervals. These intervals, which are usually 1 hour long and 15 minutes at the shortest, are too long for this kind of troubleshooting.

3.5.3.2

Hardware requirements This feature requires the Traffica server hardware.

3.5.3.3

Release


RAS

RNC

mcRNC

RAS06

RN3.0

mcRNC2.0

Table 31

3.5.3.4

186

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

-

-

-

OSS4.2

-

-

-

-



RAS SW component

License control in network element

License control attributes

ASW NetAct

RAN

-

-


DN70296245


3.5.3.5


DN70296245

Parameters

Counters

Alarms

009:130 IP_MSG_MON




187


3.6 3.6.1

g

RAN1810: Sleeping Cell Improvement Introduction This feature is delivered on top of RAS06. This feature provides a new RNC alarm created for unsuccesful auto-recovery attempts and a new criteria added to identify non-performing cells. Benefits for the operator This feature offers better for identifying sleeping cells

3.6.2

Functional description RNC sets a new WBTS alarm (7784 RECOVERY ACTION FAILURE): •

•

in case a non-performing cell cannot be restarted anymore by the non-performing cell recovery procedure, because the maximum amount of the BTS restarts/day has been reached already in case the BTS restart as a non-performing cell recovery action has failed because of, for example, O&M link failure or because BTS rejects the BTS restart request.

Also, a new criteria has been added to identify non-performing cells in the RRC connection setup phase and to start recovery action. In case of link failure, RNC updates a cellspecific counter. When the counter limit (set by the ) for consecutive RRC connection setup failures for the cell is exceeded, the recovery action is started. Alarm 7779 RECOVERY ACTIONS ONGOING is raised only when a BTS is successfully reset. This means that in the normal mode of operation it is enough to follow the alarms and alarm history.

3.6.2.1

Activating and deactivating the feature Activating RAN1810: Sleeping Cell Improvement Feature RAN1810: Sleeping Cell Improvement is controlled by PRFILE parameter RN22_FEATURE_OPT_009(CLASS:02, NUMBER:1296). The parameter can be used to set the maximum amount of BTS restarts performed as sleeping cell recovery action since the previous midnight. The value range for the parameter is 0 – 10. Value 0 means that the feature is not activated. Any value above 10 (0xA) is considered to mean the maximum value (10). To activate the feature, set the value to something other than 0. To modify the value, enter the following MML command: ZWOC:2,1296, XXX; where XXX stands for the value set by the (greater than 0). The default value is 2 meaning that by default two BTS restarts per day as a recovery action are allowed. Feature RAN1810: Sleeping Cell Improvement needs an O&M link to Node-B. Ensure that the O&M link has been configured and is functional. You can check the O&M link status with the RNW Object Browser.

188


DN70296245


The feature is not used on the WBTSs where the operational state of WCEL is BL(U). The Sleeping Cell Improvement statistics logs are activated together with the activation of the feature. Blocking RAN1810: Sleeping Cell Improvement for a period after RNC restarts Feature RAN1810: Sleeping Cell Improvement can be blocked for a certain period after RNC restart. The length of the blocking period is controlled by PRFILE parameter RN30_MAINT_020 (CLASS:07, NUMBER:243). The value range for the parameter is 0 – 720 in hours. The default value is 0. To inquire the value of the parameter, enter the following MML command: ZWOI:7, 243 If necessary, change the value of the parameter using the ZWOC command. Deactivating RAN1810: Sleeping Cell Improvement To deactivate RAN1810: Sleeping Cell Improvement, enter the following MML command: ZWOC:2,1296, 0; This sets the value of the parameter that controls the activation status of the feature to zero. The Sleeping Cell Improvement statistics logs are deactivated together with the deactivation of the feature. Activating trace logs The trace logs contain feature-specific data among other data. Trace logging is controlled by PRFILE parameter RN30_MAINT_018 (CLASS:07, NUMBER:241). To activate trace logging, enter the following MML command: ZWOC:7,241 , 1; The logging is activated by default. When trace logging is activated, it is enabled for all features that use trace logging. Deactivating trace logging To deactivate the trace logs, enter the following MML command: ZWOC:7,241 , 0; Trigger criteria for RAN1810: Sleeping Cell Improvement The following table lists the triggering criteria for RAN1810: Sleeping Cell Improvement along with the parameters related to each case. Triggering criteria

Configurable parameters

The initialization of the common (PtxTotal, PrxTotal, RachLoad) measurements fails too many times

None

Table 32

DN70296245



189


Triggering criteria

Configurable parameters

The measurement information of the cell is missing from PtxTotal, PrxTotal, RachLoad measurements and re-initialization of measurement fails even after several retries.

None

Either the cell or the measurement information of the cell is missing from PtxTotal, PrxTotal, RachLoad measurements and there is no improvement after re-initialization.

None

Common channel creation fails too many times. None The cell-specific HO-RL recovery counter for the sent radio link setup messages exceeds the recovery limit in cases where RRC connection requests have not been received.

The recovery limit is specified by PRFILE parameter RNC_MAINT_001 (CLASS:07, NUMBER:208). Value range is 1...1000. The given value is multiplied by 10 meaning that the effective values are 10...10000. The default value is 0 (disabled).

The ratio of the completed RRC setup procedures compared to the started RRC setup procedures in the recovery window is below the defined ratio threshold.

FACH RRC connection setup ratio is specified by PRFILE parameter RN30_MAINT_016 (CLASS:07 , NUMBER:239). Value range is 1...10. The given value is multiplied by 10 meaning that the effective values are 10...100. The default value is 0 (disabled). FACH RRC setup supervision ratio window is specified by PRFILE parameter RN30_MAINT_019 (CLASS:07 , NUMBER:242). Value range is 1... 1000. The given value is multiplied by 10 meaning that the effective values are 10...10000. The default value is 0 (disabled).

The counter of radio link failure acknowledged by Node B during RRC connection setup for a specific cell exceeds the recovery limit.

The recovery limit is specified by PRFILE parameter RN30_MAINT_017 (CLASS:07 , NUMBER:240). The default value is 0 (disabled).

The base station resource manager process family (BRM) hand crashes in RNC.

Table 32

3.6.2.2

None

Allowed configurations (Cont.)

Printing out RAN1810: Sleeping Cell Improvement statistics logs To print out RAN1810: Sleeping Cell Improvement statistics logs, enter the following command in the service terminal of the working OMU unit:

ZOS:*,*,50B,0,,,,6034,,,06,XX, YY,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ZGSC:,50B;

190


DN70296245


In this command: • • •

XX = 00 when printing counters for cause of non-performance cell recovery XX = 01 when printing counters for non-performance cell recovery of a specific WBTS YY = the WBTS ID as a hexadecimal word (preceeded by XW). For example, if WBTS ID value in hexadecimal format is 3412, the value for this field is given as XW3412.

There are three ways to print out counters: • • •

for a specified WBTS for all causes of non-performance cell recovery for all causes of non-performance cell recovery for every WBTS.

Example: To print out counters for a specified WBTS, enter, for example, the following command: ZOS:*,*,50B,0,,,,6034,,,06,01, XW3412,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ZGSC:,50B; The following is an example output: CALLER : WRITE TIME: PARAMETERS: TEXT : DATA :

050B 0000 00 RETURN ADDRESS: 0940 (G0296).00000219 2007-07-17 10:04:09.72 T-08 0938.00000033 0000013C 0938.00000004 REK(M): Non-performing cell recovery statisti cs wbts_id: 13330 Statistics (total / this period) total recovery count: 6 / 1 separate causes: common meas fail: 1 / 0 common meas int fail: 1 / 1 CCH creation fail: 1 / 0 Poor HO related RL setup ratio: 1 / 0 Poor FACH RRC conn setup ratio: 1 / 0 Poor RL setup ratio due to NodeB: 0 / 0 BS resource manager hand crash: 1 / 0 Successful BTS restarts: 1 / 0 Failed BTS restarts: 5 / 1

Here is an interpretation of the example output: •

DN70296245

The criteria for non-performing cell recovery for the WBTS (wbts_id=13330 corresponds to the hexadecimal parameter value 3412) has been met six times since the last RNC reset. • Once because of common meas fail (common measurement failure) • Once because of common meas int fail (common measurement initialization failure)


191


•

• Once because of CCH creation fail (common channel creation failure) • Once because of poor HO related RL setup ratio • Once because of poor FACH RRC conn setup ratio • Zero times because of poor RL setup ratio due to NodeB • Once because of BS resource manager hand crash There has been only one successful BTS restart. All others attempts failed.

Example: To print out counters for all causes of non-performing cell recovery, enter, for example, the following command: ZOS:*,*,50B,0,,,,6034,,,06,00, XW0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ZGSC:,50B;

The following is an example output: CALLER : WRITE TIME: PARAMETERS: TEXT : DATA :

050B 0000 00 RETURN ADDRESS: 0940 (G0296).00000219 2007-07-17 10:04:08.97 T-08 0938.00000033 0000011C 0938.00000004 REK(M): none performance cell recovery statisti cs-cause counter Statistics (total / this period) common meas fail: 5 / 0 common meas int fail: 6 / 0 CCH creation fail: 7 / 0 Poor HO related RL setup ratio: 8 / 0 Poor FACH RRC conn setup ratio: 9 / 0 Poor RL setup ratio due to NodeB: 10 / 0 BS resource manager hand crash: 11 / 0 Successful BTS restarts: 40 / 0 Failed BTS restarts: 4 / 0 Here is an interpretation of the example output: • • • • • • • •

192

The criteria for non-performing cell recovery for common meas fail (common measurement failure) has been met five times. The criteria for non-performing cell recovery for common meas int fail (common measurement initialization failure) has been met six times. The criteria for non-performing cell recovery for CCH creation fail (common channel creation failure) has been met seven times. The criteria for non-performing cell recovery for poor HO related RL setup ratio has been met eight times. The criteria for non-performing cell recovery for poor FACH RRC conn setup ratio has been met nine times. The criteria for non-performing cell recovery for poor RL setup ratio due to NodeB has been met ten times. The criteria for non-performing cell recovery for BS resource manager hand crash has been met eleven times. There have been 40 successful BTS restarts. There have been four failed BTS restarts.


DN70296245


Example: To print out counters for all causes of non-performing cell recovery for each WBTS, enter, for example, the following command: ZOS:*,*,50B,0,,,,6034,,,06,01, XW0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ZGSC:,50B;

The following is an example output: CALLER : WRITE TIME: PARAMETERS: TEXT : DATA :

CALLER : WRITE TIME: PARAMETERS: TEXT : DATA :

050B 0000 00 RETURN ADDRESS: 0940 (G0296).00000219 2007-07-17 10:04:09.72 T-08 0938.00000033 0000013C 0938.00000004 REK(M): Non-performing cell recovery statisti cs wbts_id: 256 Statistics (total / this period) total recovery count: 6 / 1 separate causes: common meas fail: 1 / 0 common meas int fail: 1 / 1 CCH creation fail: 1 / 0 Poor HO related RL setup ratio: 1 / 0 Poor FACH RRC conn setup ratio: 1 / 0 Poor RL setup ratio due to NodeB: 0 / 0 BS resource manager hand crash: 1 / 0 Successful BTS restarts: 1 / 0 Failed BTS restarts: 5 / 1 050B 0000 00 RETURN ADDRESS: 0000 (G0000).00401CE1 2008-02-18 13:55:46.35 T-08 0000.02B171D0 0000004A 0000.02B171A0 REK(M): time stamp for none performance cell re covery causes: wbts_id: 256 cause:common meas fail 01. 2008-02-17 19:02:59


050B 0000 00 RETURN ADDRESS: 0000 (G0000).00401CE1 2008-02-18 13:55:46.35 T-08 0000.02B171D0 0000004A 0000.02B171A0 REK(M): time stamp for none performance cell re covery causes: wbts_id: 256 cause: common meas int fail 02. 2008-02-17 19:02:59 CALLER : WRITE TIME: PARAMETERS: TEXT :

DN70296245

050B 0000 00 RETURN ADDRESS: 0000 (G0000).00401CE1 2008-02-18 13:55:46.35 T-08 0000.02B171D0 0000004A 0000.02B171A0 REK(M): time stamp for none performance cell re


193


DATA : covery causes: wbts_id: 256 cause: Poor HO related RL setup ratio 01. 2008-02-17 19:02:59 CALLER : WRITE TIME: PARAMETERS: TEXT : DATA :

050B 0000 00 RETURN ADDRESS: 0000 (G0000).00401CE1 2008-02-18 13:55:46.35 T-08 0000.02B171D0 0000004A 0000.02B171A0 REK(M): time stamp for none performance cell re covery causes: wbts_id: 256 cause: Poor FACH RRC conn setup ratio 01. 2008-02-17 19:02:59


050B 0000 00 RETURN ADDRESS: 0000 (G0000).00401CE1 2008-02-18 13:55:46.35 T-08 0000.02B171D0 0000004A 0000.02B171A0 REK(M): time stamp for none performance cell re covery causes: wbts_id: 256 cause: BS resource manager hand crash 01. 2008-02-20 19:02:59 CALLER : WRITE TIME: PARAMETERS: TEXT : DATA :


CALLER

194

050B 0000 00 RETURN ADDRESS: 0940 (G0296).00000219 2007-07-17 10:04:09.72 T-08 0938.00000033 0000013C 0938.00000004 REK(M): Non-performing cell recovery statisti cs wbts_id: 257 Statistics (total / this period) total recovery count: 6 / 1 separate causes: common meas fail: 1 / 0 common meas int fail: 1 / 1 CCH creation fail: 1 / 0 Poor HO related RL setup ratio: 1 / 0 Poor FACH RRC conn setup ratio: 1 / 0 Poor RL setup ratio due to NodeB: 0 / 0 BS resource manager hand crash: 1 / 0 Successful BTS restarts: 1 / 0 Failed BTS restarts: 5 / 1 050B 0000 00 RETURN ADDRESS: 0000 (G0000).00401CE1 2008-02-18 13:55:46.35 T-08 0000.02B171D0 0000004A 0000.02B171A0 REK(M): time stamp for none performance cell re covery causes: wbts_id: 257 cause:common meas fail 01. 2008-02-17 19:02:59

: 050B 0000 00

RETURN ADDRESS: 0000 (G0000).00401CE1


DN70296245


WRITE TIME: PARAMETERS: TEXT : DATA :

2008-02-18 13:55:46.35 T-08 0000.02B171D0 0000004A 0000.02B171A0 REK(M): time stamp for none performance cell re covery causes: wbts_id: 257 cause: common meas int fail 03. 2008-02-17 19:02:59 CALLER : WRITE TIME: PARAMETERS: TEXT : DATA :

050B 0000 00 RETURN ADDRESS: 0000 (G0000).00401CE1 2008-02-18 13:55:46.35 T-08 0000.02B171D0 0000004A 0000.02B171A0 REK(M): time stamp for none performance cell re covery causes: wbts_id: 257 cause: Poor HO related RL setup ratio 01. 2008-02-17 19:02:59


050B 0000 00 RETURN ADDRESS: 0000 (G0000).00401CE1 2008-02-18 13:55:46.35 T-08 0000.02B171D0 0000004A 0000.02B171A0 REK(M): time stamp for none performance cell re covery causes: wbts_id: 257 cause: Poor FACH RRC conn setup ratio 01. 2008-02-17 19:02:59 See the previous examples for some guidelines to interpret the output.

3.6.3 3.6.3.1

System impact Current implementation In case of unsuccessful auto-recovery action, no alarm is set.

3.6.3.2

Interdependencies between features This feature is an improvement over an already existing RAS05.1 feature RAN1302: Non-Performing Cell Recovery. Additionally, feature RAN1823: Recovery Logging Improvement provides Iu-PS and IuCS logging improvements that are enabled when the trace logging for this feature is activated.

3.6.3.3


DN70296245


195


3.6.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06 On top

RN3.0 CD3.0

-

-

-

X

-

-

-

-

3.6.3.5

3.6.3.6


RAS SW component



BSW

RAN

Not defined

Not defined


Counters

Alarms

RNC_MAINT_001 (CLASS:07, NUMBER:208)


7784 RECOVERY ACTION FAILURE

RN30_MAINT_016 (CLASS:07 , NUMBER:239)

7779 RECOVERY ACTIONS ONGOING

RN30_MAINT_017 (CLASS:07 , NUMBER:240) RN30_MAINT_018 (CLASS:07, NUMBER:241) RN30_MAINT_019 (CLASS:07 , NUMBER:242) RN30_MAINT_020 RN22_FEATURE_OPT_009

3.6.3.7


196


DN70296245


3.7 3.7.1

g

RAN1823: Recovery Logging Improvement Introduction This feature is delivered on top of RAS06. This feature provides improvements to logging non-performing cell recovery issues as well as Iu-CS and Iu-PS link state changes. Benefits for the operator This feature provides OPEX savings with faster troubleshooting of recovery actions.

3.7.2

Functional description This feature brings improvements to monitoring and logging area. New logs are added for CN/PS interface to see a connection break in the links with direction, link ID and index. Also information about started recovery actions and processor loads during these recovery actions are added.

Log file transfer initiated by operator

NetAct

Figure 29

RNC OMS

Log file data collection

OMU

Ultrasite WCDMA BTS or Flexi WCDMA BTS

Recovery logging improvement

The following information is written to trace log about Iu-CS and Iu-PS link state changes: • •

• •

Core network link state change information with CN link ID and status information All failures in the RNC recovery functionality that cause the link change-related operation to be aborted. These are also known as RNC recovery functionality internal failures (for example, DB read failed, specified Iu item was not found). Status of successful link state change handling operations and actions that were taken because of link status changes (for example, Iu barring timer setting) Iu link timer handling events and actions (for example, SIB sending start or cancel).

The following information is written to trace log by REKOVE and REZINI about non-performing cell recovery: • • • • • • • •

DN70296245

Recovery input receiving with counter values for received cause Adding of a recovery task or ignoring a task if such is already buffered Starting of a new BTS recovery task Sending of a BTS restart request to REZINI Creation of REZINI hand process for BTS restart Cell deletion start and finish BTS restart request sending to BOIMED BTS restart result (for example, OK, NOK, timeout, BTS busy, no BTS O&M connection) received from BOIMED with received error code in case of failure


197


• •

Response received from REZINI to BTS restart request Status (task completed, task re-issued, task not found, timeout) and BTS restart counter values

Each entry in the log contains at least the following information: • • •

Timestamp Target object of the action (WBTS, WBTS and WCEL, Iu link type (PS or CS) and link index) PID of the process that created the entry

These log files are collected via OMU to the OMS disk and are available with an FTP connection from NetAct. The logs include data from the last 14 days. The common logging on/off status for these recovery-related features is controlled with a PRFILE parameter. Activating trace logging The trace logs contain feature-specific data among other data. Trace logging is controlled by PRFILE parameter RN30_MAINT_018 (CLASS:07, NUMBER:241). To activate trace logging, enter the following MML command: ZWOC:7,241 , 1; The logging is activated by default. When trace logging is activated, it is enabled for all features that use trace logging. Deactivating trace logging To deactivate the trace logs for the feature, enter the following MML command: ZWOC:7,241 , 0;

3.7.3 3.7.3.1

System impact Interdependencies between features This feature is related to features RAN1302: Non-Performing Cell Recovery and RAN1810: Sleeping Cell Improvement providing trace logging needed in case of nonperforming cells.

3.7.3.2


3.7.3.3

Release

198


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06 On top

RN3.0 CD3.0

-

-

-

X

-

-

-

-


DN70296245


3.7.3.4

3.7.3.5


RAS SW component



BSW

RAN

Not defined

Not defined


Counters

Alarms

RN30_MAINT No counters related to this _018 feature (CLASS:07, NUMBER:241)

3.7.3.6



DN70296245


199


3.8 3.8.1

RAN1128: Dynamic Access Class Restriction Introduction This feature introduces more flexible ways of controlling Radio Network Access and Domain Specific Access Class (DSAC) restriction. The operator can specify the Radio Network Access Restriction (RNAR) level separately in two different location areas and the DSAC restriction level in four different location areas for both core types. Benefits for the operator The feature makes it possible to control and restrict the traffic in emergency situations.

3.8.2

Functional description This feature brings enhancements to the current RNAR and the DSAC restriction features by adding the usage of the cell groups. The can define 10 traffic restriction groups. Each group has the type of restriction defined: 'RNAR' or 'CS-DSAC' or 'PS-DSAC'. Each group has its own ID, restriction level definition and the functionality can be activated independently for each group. Each cell can be connected to a 'Radio Network Access Regulation function' or 'Domain Specific Access Restriction' group by selecting the group ID for the cell. In addition, it is possible to activate the RNAR functionality and DSAC restriction for all cells in the RNC with one selection. Compliance: 3GPP Rel.6 TS 25.331 v6.5.0

3.8.3 3.8.3.1

System impact Current implementation n the RNAR function, one cell group is ed and cells are selected to the group one by one. The DSAC restriction can be set separately to both CN domains, but the access class restriction level is the same for both core types. The restriction interval is common for the RNAR function and DSAC restriction cell groups.

3.8.3.2


3.8.3.3

Interdependencies between features Both 'Radio Network Access Function' and 'Domain Specific Access Class Restriction' are paused when RNW plan activation using fast mode is initiated. If the traffic restriction period ends (timer set for Restriction Interval expires) during plan activation, then the new restriction information is not sent to cells. New restriction information (updated Access Class barred list) is sent to the cells after RNW plan activation is complete.

200


DN70296245


3.8.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

-

-

-

3GPP Rel-6

3.8.3.5

3.8.3.6


RAS SW component



ASW

RAN


Control and plane Both 'Radio Network Access Regulation Function' and 'Domain Specific Access Class Restriction' have the traffic restriction information included in System Information Block 3 message which is broadcasted in the cell.

3.8.3.7

Management plane NMS interfaces This feature is configured by using RNC RNW plan management interface or RNC element manager. Network element interfaces Both 'Radio Network Access Regulation Function' and 'Domain Specific Access Class Restriction' can be enabled by using RNW Object Browser of the RNC Element Manager. Feature status can also be followed in RNC EM. Management data

3.8.3.8

Parameters

Counters

Alarms

Access Class Barred list


2868 LIMITED UE ACCESS TO RADIO NETWORK

Impact on system performance and capacity None.

DN70296245


201


3.8.3.9

Other impacts None.

202


DN70296245


3.9 3.9.1

RAN212: Selectable RNW Plan Activation Mechanism Introduction This feature introduces a control mechanism for activation speed and NW availability in the RNW configuration plan activation operation. Three alternative modes are ed. Benefits for the operator OPEX saving are acquired thanks to the possibility of faster RNW configuration.

3.9.2

Functional description The operator can select which way the plan will be activated. The safe activation mode is the slowest and has less influence on the traffic while the fast activation method may have influence on the existing traffic. • •

•

Safe activation mode (existing method): The plan is activated with the current method: one object at the time. This method has a minimal effect on the traffic. Normal activation mode: The existing NW is taken into so that simultaneous operations are not done to adjacent WCELs. This method has a moderate effect on the traffic. Fast activation mode: The object dependencies are ignored. Operations are done parallel as a mass operation. This method has the largest effect on the traffic.

The purpose of the feature is to enable faster activation time for the RNW plan.

3.9.3 3.9.3.1

System impact Current implementation In the current implementation, the safe activation mode (mode 1) is available.

3.9.3.2


3.9.3.3

Interdependencies between features 'Radio Network Access Regulation Function' (RNAR) and 'Domain Specific Access Class Restriction' (DSAC) are paused when RNW plan activation using 'fast' mode is started. The existing traffic restriction applied in the cells by using RNAR and DSAC remains same until RNW plan activation is complete.

3.9.3.4

Software requirements RAS

RNC

Release RAS06 RN3.0

DN70296245

BTS Ultra BTS Flexi AXC NetAct -

-


-

MSC SGSN MGW UE

OSS4.2 -

-

-

-

203


3.9.3.5

3.9.3.6


RAS SW component



ASW NetAct

RAN

NetAct

-


3.9.3.7

Management plane NMS interfaces RNW plan activation mode is sent to RNC in the RNW plan activation command from NetAct. Network element interfaces There are no effects to RAN NE UIs. Management data

3.9.3.8

Parameters

Counters

Alarms




Impact on system performance and capacity Selection of RNW plan activation is a choice between speed of operation and the possible interruption in service level in RAN. Selecting 'safe' mode shall make the operation last longer with minor or no effect to the service level in RAN. 'fast' mode will shorten operation time but can cause severe effect to RAN service level during plan activation.

3.9.3.9

Other impacts None.

204


DN70296245


3.10 3.10.1

RAN1059: Flexi WCDMA BTS for RNS Split Introduction The feature enables RNS Split plan management concept for the Flexi WCDMA BTS. The execution of RNS split operation for the Flexi WCDMA BTS can be planned in advance and the BTS outage due to operation is decreased. Benefits for the operator OPEX savings are achieved due to the reduced time of Flexi WCDMA BTS configuration and the reduced amount of possible human errors during configuration process.

3.10.2

Functional description With this feature the configuration of the Flexi WCDMA BTS transport module is included in the RNS Split concept. The Flexi WCDMA BTS transport configuration , and activation operations can be triggered from the NetAct RNS split application. The configuration data is transferred from the NetAct to the NE using the NWI3 interface in XML format. The RNC mediates the NWI3 plan management interface to the BTS O&M interface for the Flexi WCDMA BTS. Flexi WCDMA BTS forwards the configuration file information to the FTM. The operator can also schedule the configuration , and activation operations. NetAct

Radio Access Configurator/ RNS split application

UI

NWI3 Management interface RNC mediator

BTS O&M Management interface Flexi BTS/ Next Generation WCDMA BTS

Figure 30

DN70296245

UI

BTS O&M

FTM

Flexi WCDMA BTS for RNS Split


205


3.10.3 3.10.3.1

System impact Current implementation Currently, the RNS Split operations can be executed only with UltraSite WCDMA BTSs. All RNS configuration actions for a Flexi WCDMA BTSs must be done manually.

3.10.3.2


3.10.3.3

Interdependencies between features This feature requires activation of the following licensed feature: •

3.10.3.4

RAN96: Automated RNS split


RNC

BTS Ultra BTS Flexi AXC NetAct

Release RAS06 RN3.0

3.10.3.5

3.10.3.6

-

WBTS4.0

-

MSC SGSN MGW UE

OSS4.2 -

-

-

-


RAS SW component



ASW NetAct

RAN

NetAct

-


3.10.3.7

Management plane NMS interfaces Feature can be used by activating the NetAct RNS split application and by using the NetAct RNS split application for the ing, planning, ing and activation of the FlexiBTS transport configuration files. Network element interfaces No changes in RAN NE UIs.

206


DN70296245


Management data

3.10.3.8

Parameters

Counters

Alarms




Impact on system performance and capacity NetAct can send one , or activation request per RNC for a group of maximum 100 FlexiBTSs at a time. However, it is possible to send simultaneous , and activation requests.

3.10.3.9

Other impacts None

DN70296245


207


3.11 3.11.1

RAN1084: Direct Activation of RNW Changes Using NWI3 Introduction This feature provides a mechanism for making direct parameter changes in the RNW configuration from the NetAct. Benefits for the operator OPEX savings are achieved because of faster RNW parameter changes from NetAct.

3.11.2

Functional description With this feature, the NetAct Radio Access Configurator is able to perform direct operations to individual parameters in the RNW configuration. The changes are distributed to the NW online without separate activation procedures. The following operations are ed: • • • •

Create Modify Delete Lock / Unlock (WCEL) NetAct Radio Access Configurator

UI

NWI3 Management interface RNC RNC RNW database

RNW management

3GPP Iub & BTS O&M Management interface WCDMA BTS BTS configuration management

Figure 31

3.11.3 3.11.3.1

Direct Activation of RNW Changes Using NWI3

System impact Current implementation In the current implementation, the RNW configuration changes are distributed to the NW as plan files with separate and activation procedures. The plans are a good alternative for mass operations, but for small operations the plans are too tedious to create, pre-activate and activate.

208


DN70296245


3.11.3.2


3.11.3.3

Interdependencies between features Direct activation request can not be executed during RNW plan operation (plan , rollback, or activation). In case there are both Direct Activation and RNW plan operations to be done for same RNC then NetAct does Direct Activation operations first.

3.11.3.4


RNC


Release RAS06 RN3.0

3.11.3.5

3.11.3.6

-

-

-

MSC SGSN MGW UE

OSS4.2 -

-

-

-


RAS SW component



ASW NetAct

RAN

NetAct

-


3.11.3.7

Management plane NMS interfaces NetAct sends a 'Direct Activation' operation request to the RNC containing the data to be changed in network. Network element interfaces No changes in RAN NE UIs. Management data

3.11.3.8

Parameters

Counters

Alarms




Impact on system performance and capacity Limitations and restrictions: This feature allows the following operations to the following objects: •

DN70296245

WCEL: lock, unlock, create, modify and delete


209


• • • •

WBTS: create, modify and delete COCO: create, modify and delete WLCSE: create, modify and delete Adjacencies (ADJI, ADJS.ADJG): create, modify and delete

A NetAct can give one direct activation request per RNC at a time. The request can include one object and one operation. A direct activation request cannot be executed during plan operations (plan , rollback, or activation).

210


DN70296245


3.12 3.12.1

g

RAN1809: AAL2 multiplexing COCO modification Introduction This feature is delivered on top of RAS06. Modify possibility to COCO object Benefits for the operator OPEX saving via simplified re-configuration action.

3.12.2

Functional description COCO object has been changed from a non-modifiable to modifiable parameter. When there has been for reconfigration, the COCO object has first been deleted and then reseated. Now modification action is possible.

3.12.3 3.12.3.1

System impact Current implementation Modification of object is not ed.

3.12.3.2

Interdependencies between features None.

3.12.3.3


3.12.3.4


RNC

Release RAS06 RN3.0 On top On top

3.12.3.5

DN70296245


MSC SGSN MGW UE

-

-

-

-

OSS 5.1

-

-

-


RAS SW component



BSW

RAN

Not defined

Not defined


211


3.13

3.13.1

RAN618: Centralised Information Management for BTS Introduction This feature enables a centralised management for BTS from NetAct. Benefits for the operator The centralised RAN system security results in enhanced risk management and OPEX savings.

3.13.2

Functional description Both BTS element manager and BTS host are identified to fulfill the security requirements. This feature enables new creation, change and deletion. The is able to manage the access to the O&M NW separately for each group or individual of the maintenance personnel on a BTS access level. BTS s have one type of authorisation access profile in use. In the phase, the network entity checks the access right from the authentication server located in the NetAct. With this feature the can access different network systems with the same name and .

3.13.3 3.13.3.1

System impact Current implementation In previous releases, the centralised information management has been implemented for the RNC and AXC.

3.13.3.2


3.13.3.3

Interdependencies between features This feature interacts with the Centralized Event Log Management for BTS feature which has been planned to an release.

3.13.3.4


RNC


Release RAS06 RN3.0 WBTS4.0

212


WBTS4.0

MSC SGSN MGW UE

C3.0 OSS4.2 -

-

-

-

DN70296245


3.13.3.5

3.13.3.6


RAS SW component



ASW NetAct

RAN

NetAct

-

Control and plane No effect

3.13.3.7

Management plane NMS interfaces BTS O&M interface is used through a mediator to set up initialisation parameters and to update the NE . Network element interfaces Commissioning of the initialisation parameters are added into the BTS Site Element Manager GUI. Management data

3.13.3.8

Parameters

Counters

Alarms




Impact on system performance and capacity Authentication response time depends on different factors such as the overall authentication request density and connection speed.

DN70296245


213


3.14 3.14.1

RAN1159: IP Address & Port based Filtering for BTS LMPs Introduction This feature allows selectively defining the access to/from IP DCN from/to all entry points at a NodeB site. Filtering is based on source and destination IP address and port information. This feature improves the protection of: • •

IP DCN from harmful IP traffic originated from NodeB NodeB from harmful IP traffic arriving from IP DCN

Benefits for the operator Enhanced risk management is achieved because of improved RAN system security.

3.14.2

Functional description The feature implements the means of access protection to the transmission (AXC) of UltraSite WCDMA BTS and the transmission of Flexi WCDMA BTS. It is possible to filter IP traffic based on source and destination IP address and T/UDP port number. This IP traffic supervision is covering all packet flows in WCDMA BTS. The feature introduces a new mode to more selectively define the access to/from IP DCN. Since WAM offers also an LMP, this feature increases security with respect to all NodeB LMPs. The operator can select between the following modes, independently for each of the three packet flows: • •

•

In an unrestricted mode, all IP traffic is allowed to through. In a restricted mode, no IP traffic is allowed to through. (Only available for AXC LMP <> IP DCN packet flow because WAM/AXC needs at least IP connectivity towards Netact/NEMU.) In a restricted mode with exceptions, the AXC IP routing function validates the source and destination information of each incoming IP packet against the configuration in the related table. IP packets that do not match the criteria are discarded.

Whether only IP addresses or IP addresses and ports need to match is a matter of configuration. It is possible to configure IP filter rules for AXC/ Flexi WCDMA BTS locally or remotely with site configuration files or element manager.

3.14.3 3.14.3.1

System impact Current implementation Until now the operator could only select to either block all or transparently through all IP traffic between the AXC LMP and IP DCN, by switching the restricted mode on/off. With the IP traffic between the WAM/AXC and IP DCN there was no possibility for any control at all.

3.14.3.2


214


DN70296245


3.14.3.3

Interdependencies between features The feature improves the restricted mode feature in AXC.

3.14.3.4


RNC BTS Ultra BTS Flexi AXC NetAct

Release RAS06

3.14.3.5

3.14.3.6

-

WBTS4.0

WBTS4.0

MSC SGSN MGW UE

C3.0 OSS4.2 -

-

-

-


RAS SW component



OSW

RAN

-

-


Counters

Alarms

IP filter rule



• •

•

•

DN70296245

Unique rule name Source and destination IP address definitions Ranges or wildcards can be used Source and destination port definitions


215


3.15

3.15.1

RAN33: IP Security for O&M Traffic between RNC and NetAct Introduction This feature enables secure transmission of O&M traffic in the O&M DCN for the connection between the RNC and NetAct. Benefits for the operator Enhanced risk management is gained because of improved RAN system security. This feature strengthens the protection against both internal and external hostile attacks.

3.15.2

Functional description Virtual Private Networks (VPN) are defined for the O&M traffic between the RNC and NetAct. IPSec is used to encrypt the data. The most important part of the O&M traffic to be encrypted is naturally the information related to management. IPSec configuration can be done based on source and destination IP addresses and port numbers.

3.15.3 3.15.3.1

System impact Current implementation Currently no encryption is used for the O&M data in WCDMA RAN.

3.15.3.2


3.15.3.3


3.15.3.4


RNC


Release RAS06 RN3.0

3.15.3.5

216

-

-

-

MSC SGSN MGW UE

OSS4.2 -

-

-

-


RAS SW component


ASW

RAN


Id:0900d805807f712e Confidential


DN70296245


3.15.3.6

Management plane Network element interfaces The feature is managed via MML and Windows interface. IPSec rules need to be configured to the element. Management data

DN70296245

Parameters

Counters

Alarms




Id:0900d805807f712e Confidential

217


3.16 3.16.1

RAN1451: Mass Change of Local BTS s Introduction This feature introduces new functionality for performing a mass change of local BTS s remotely. Benefits for the operator This feature improves system security and redcues the effort needed for maintenance.

3.16.2

Functional description New element management functionality is introduced to make remote changes for Flexi WCDMA BTS possible. With this functionality, an operator can remotely change several BTS s. New functionality is introduced in WN4.0 for Flexi WCDMA BTS element manager release.

3.16.3 3.16.3.1

System impact Current implementation Local s are managed one by one with the BTS element manager.

3.16.3.2


3.16.3.3


3.16.3.4


RNC BTS Ultra BTS Flexi AXC NetAct MSC SGSN MGW UE

Release RAS06

3.16.3.5

218

-

-

WBTS4.0

-

-

-

-

-

-


RAS SW component



OSW

RAN

-

-


DN70296245


3.16.3.6


DN70296245

Parameters

Counters

Alarms





219

Performance monitoring features


4 Performance monitoring features 4.1

RAS06 documentation for performance monitoring features See the following table for more detailed information on WCDMA RAN functionality and feature activation:

Feature ID: Name

Functional area description and other related documents

RAN1068: 3GPP TS 32.403 Call setup and release in Call Related Counter Additions for RAN Setup and Release

Feature implementation This feature does not require activation.

Handover control in Handover Control Measuring WCDMA RAN in Measuring WCDMA RAN RAN868: ATM Transport Statistics Reporting in RAN

This feature does not have related documents.


RAN86: Cell Throughput Measurements in Serving RNC

Introduction to the packet scheduler functionality in Packet Scheduler


RAN234: HSDPA Subscriber Trace WCDMA RAN subscriber and equipment trace


RAN1052: HSUPA Subscriber Trace


Table 33

WCDMA RAN subscriber and equipment trace


4.1.1

Information on Parameters, Counters, and Alarms For information on the parameters, counters and alarms related to each feature, see the System impact section of the feature descriptions. For parameter descriptions, see: • • • • • • •

WCDMA radio network configuration parameters RNC OMS LDAP parameters Plan Editor AXC Parameters Plan Editor Flexi Transport Module Parameters Plan Editor Flexi WCDMA BTS Parameters Plan Editor UltraSite WCDMA BTS Parameters Reference Information Service in NOLS for RNC parameters



For alarm descriptions, see:

220


DN70296245


• • • • • • • • •


RNC Notices (0-999) RNC Disturbances (1000-1999) RNC Failure Printouts (2000-3999) RNC Diagnosis Reports (3700-3999) RNC Base Station Alarms (7000-7900) Troubleshooting Flexi WCDMA Base Station Flexi WCDMA Base Station faults Troubleshooting UltraSite and MetroSite WCDMA Base Station UltraSite and MetroSite WCDMA Base Station faults

For information on licence management, see Nokia Siemens Networks license management concept and its implementation in WCDMA RAN in License management in WCDMA RAN.

DN70296245


221


4.2

4.2.1

RAN1068: 3GPP TS 32.403 Related Counter Additions for RAN Introduction This feature adds new 3GPP-specified counters to Nokia Siemens Networks Measure Solution. Benefits for the operator OPEX savings result from easier operation of multi-vendor NWs.

4.2.2

Functional description This feature adds the following new 3GPP counters to RAN: • • • • • • • • • • •

RAB CS connection set-up time (Maximum) RAB PS connection set-up time (Maximum) RRC connection set-up time (Maximum) Failed RRC re-establishments Successful RRC re-establishments Not replied RRC re-establishments by the UE Attempted radio link additions to active link set (UE side) Successful radio link additions to active link set (UE side) Attempted radio link additions to active link set not replied by the UE (UE side) Attempted radio link deletions from active link set (UE side) Successful radio link deletions from active link set (UE side)

Nokia Siemens Networks specific names of the counters are used in the interface between the RNC and NetAct. The 3GPP name is used in the NetAct Northbound (= 3GPP Itf-N) interface.

222


DN70296245


3GPP Type Network Manager NetAct Northbound interface 3GPP named counters

3GPP Itf-N interface

Nokia NetAct

Counters with proprietary names

Report generation Reporter

RNC - NetAct proprietary interface PM: Measurement activation Iub

PM: Data Transfer RAS06: Adding missing counters according to TS.32.403

Local Measurement Management

RNC

lub

Counters with proprietary names

RNC Element Manager

lu-CS

Core Network

Figure 32

4.2.3 4.2.3.1

3GPP TS 32.403 Related Counter Additions for RAN

System impact Current implementation 3GPP has specified the RNC-based counters for WCDMA RAN into 32-series specifications. TS 32.642 specifies the UTRAN Network Resource Model (NRM), which links all counters to a specific resource to enable counter utilisation in operating the NW. TS32.403 specifies the actual counters. Currently a subset of the counters specified in TS32.403 is available in Nokia Siemens Networks RAN.

4.2.3.2


4.2.3.3


DN70296245


223


4.2.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

-

-

-

-

4.2.3.5

4.2.3.6


RAS SW component



OSW

RAN

-

-


4.2.3.7

Management plane NMS interfaces Generic impacts: •

NetAct and RNC are using Nokia Siemens Networks naming that is consistent with the other RNC statistics. 3GPP naming is applied in NetAct 3GPP Itf-N PM interface.

Reporting Tools: • • •

new KPIs for RRC and RAB maximum setup times new KPIs for RRC re-establishment rates new KPIs for SHO rates

Network element interfaces RNC Element Manager: • • •

224

New RRC and RAB setup max time counters added to Service Level Measurement. New RRC re-establishment counters added to RRC Signaling Measurement. New radio link addition and deletion counters added to RRC Signaling Measurement.


DN70296245



Counters

Alarms


RRC SETUP TIME MAX


RAB SETUP TIME MAX CS VOICE RAB SETUP TIME MAX CS DATA CONVERSATIONAL RAB SETUP TIME MAX CS STREAMING RAB SETUP TIME MAX PS STREAMING RAB SETUP TIME MAX PS INTERACTIVE RAB SETUP TIME MAX PS BACKGROUND RRC RE-ESTABLISH SUCCESS NRT RRC RE-ESTABLISH FAIL UE NRT RRC RE-ESTABLISH FAIL NO REPLY NRT ACTIVE SET UPDATE RL ADD ATTEMPTS ACTIVE SET UPDATE RL ADD SUCCESS ACTIVE SET UPDATE RL ADD FAILURE UE ACTIVE SET UPDATE RL ADD FAIL NO REPLY ACTIVE SET UPDATE RL DEL ATTEMPTS ACTIVE SET UPDATE RL DEL SUCCESS

4.2.3.8


DN70296245


225


4.3 4.3.1

RAN868: ATM Transport Statistics Reporting in RAN Introduction This feature provides visibility to information from separate NW layers for building an effective ATM transport NW performance reporting to the NetAct. Benefits for the operator An efficient tool for ATM transport optimization means OPEX savings.

4.3.2

Functional description This feature provides linking between RNW and transport NW topology for performance statistics. The linking enables the building of WBTS-specific transport NW performance reports in the NetAct Reporter and it is possible to combine all transport resources related to a certain BTS into a single report. In addition, the mapping is done for the ATM connection type, which means that plane and control plane connections can be separated for reporting. The current reporting in the NetAct is not affected, that is, reports based on ATM layer connection identifiers are still possible. The object information in the ATM Measurements provided by the PM function will contain both the radio and transport topology information. The feature does not provide any new counters.

226


DN70296245


NetAct Northbound interface 3GPP named counters

3GPP Itf-N interface

Nokia NetAct

Reports for ATM Total throughput per BTS

Report generation Reporter

RNC - NetAct proprietary interface PM: Measurement activation Iub

PM: Data Transfer RAS06: Adding missing counters according to TS.32.403

Local Measurement Management

lub

RNC

ATM based counters for troughput measuring

RNC Element Manager

lu-CS

Core Network

Figure 33

4.3.3 4.3.3.1

ATM Transport Statistics Reporting in RAN

System impact Current implementation Performance statistics for ATM layer connections are identified using the ATM connection identifiers. Because there is no linking available between the ATM connections and the related RNW elements (for example, BTS), the operator needs to maintain some mapping tables to find out the ATM layer connection identifiers for different RNW elements.

4.3.3.2


4.3.3.3


DN70296245


227


4.3.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

-

-

-

-

4.3.3.5

4.3.3.6


RAS SW component



OSW

RAN

-

-


4.3.3.7

Management plane NMS interfaces Reporting tools: •

combined radio and transport layer reports

Network element interfaces This feature has no impact on Network Element interfaces. Management data

4.3.3.8

Parameters

Counters

Alarms





228


DN70296245


4.4 4.4.1

RAN86: Cell Throughput Measurements in Serving RNC Introduction This feature allows network-wide monitoring of the plane data throughput on SRNC level towards Iub. As an example, this feature enables easy monitoring of the distribution of HSDPA and DCH throughput and provides statistics for HSDPA and DCH capacity optimization. Benefits for the operator OPEX savings are gained because of optimized Iub throughput and transport resource utilisation. Increased revenue results from improved NW data throughput.

4.4.2

Functional description This feature introduces measurements to follow the plane throughput of MAC-d layer for HSDPA (HS-DSCH), HSUPA (E-DCH), NRT(DCH) and RT (DCH) traffic. (Note that E-DCH throughput counters are part of feature RAN973: HSUPA Basic RRM. Counters are provided on cell-level for SRNC-related traffic. The new counters in SRNC: • • • • •

Signaling RB DCH MAC-d throughput RT CS (AMR, Conversational and Streaming) DCH MAC-d throughput RT PS (Streaming) DCH MAC-d throughput NRT (Interactive and Background) DCH MAC-d throughput NRT (Interactive and Background) HS-DSCH/E-DCH MAC-d throughput

UL/DL separation is provided, Traffic Class separation is not provided. The new counters are provided by the MAC plane functionality in RNC. The new cell counters will be added to new Cell Throughput Measurement in RNC. This feature does not bring any new alarms. Iu

A2SU/GTPU

DMCU

PD/IUUP

Note: SFU and MXU units have been neglected in this picture

RLC-U MAC-d FP

Iub

Figure 34

DN70296245

MAC-d PDU throughput is measured here

A2SU

Cell Throughput Measurements in Serving RNC


229


4.4.3 4.4.3.1

System impact Current implementation There are common channel (RACH, FACH, PCH) MAC-c throughput counters per cell. There are also HS-DSCH MAC-d throughput counters at BTS per cell.

4.4.3.2


4.4.3.3

Interdependencies between features E-DCH-related cell throughput counters are a part of feature RAN973: HSUPA Basic RRM.

4.4.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

-

-

-

-

4.4.3.5

4.4.3.6


RAS SW component



ASW

RAN

RNC LK



4.4.3.7

Management plane NMS interfaces Reporting Tools: • • • • •

The new RAN_KPI_0075 follows the average HSUPA cell throughput. The new RAN_KPI_0080 follows the HSUPA cell throughput data volume. The existing RAN_KPI_0044 follows already the average HSDPA cell throughput. The new RAN_KPI_0055 follows the HSDPA cell throughput data volume. RAN KPIs for Iub Throughput (RAN_KPI_0067 and RAN_KPI_0068) available but will be based on ATM VP based counters.

Optimizing Tools: •

230

The counters can be used for Capacity Optimization in NetAct Optimizer.


DN70296245



The new MAC-d and MAC-es throughput counters (in SRNC) will be added to the new Cell Throughput Measurement.


Counters

Alarms


TRANSFERRED DATA FOR SIGNALLING RB DCH UL No alarms TRANSFERRED DATA FOR SIGNALLING RB DCH DL related to this feature TRANSFERRED DATA FOR CS CALL DCH UL TRANSFERRED DATA FOR CS CALL DCH DL TRANSFERRED DATA FOR PS RT DCH UL TRANSFERRED DATA FOR PS RT DCH DL TRANSFERRED DATA FOR NRT DCH UL TRANSFERRED DATA FOR NRT DCH DL TRANSFERRED DATA FOR HS-DSCH TRANSFERRED DATA FOR NRT DCH FOR HSDPA RETURN CHANNEL UL TRANSFERRED DATA FOR NRT E-DCH

4.4.3.8


DN70296245


231


4.5 4.5.1

RAN234: HSDPA Subscriber Trace Introduction This feature introduces HSDPA reporting for Subscriber and Equipment Trace functionality. Benefits for the operator OPEX savings are acquired because of reduced time to troubleshoot the NEs and UE. Possible troubles can be detected and relevant measurement data can be presented simultaneously.

4.5.2

Functional description New HSDPA-related counters to be reported: • •

•

Basic Trace Type/UE Capability Trace record additions: • UE HSDPA capability Basic Trace Type/Active set cell record additions: • HSDSCH Usage • Target cell of HSDPA Serving Cell Change • Failure cause and aimed Target Cell(s) if Serving Cell Change fails Basic Trace Type/Dedicated Transport Channel record additions: • HS-DSCH release and related cause

The current Trace counters can be used to see non-HSDPA-specific issues, such as, the related CN(s), used RAB(s), DL RLC data, state transition and so on. HSDPA Tracing will be an extension to the previously released Trace features. All previous Trace features are simultaneously available with RAN234: HSDPA Subscriber Trace to enable, for example, simultaneous voice connection tracing.

232


DN70296245


3GPP Itf-N interface NetAct Northbound interface 3GPP named counters

Report generation NetAct Reporter

RNC - NetAct proprietary interface

HSDPA Trace Data - UE capability - HS-DSCH HOs - HS-DSCH <-> DCH HSUPA Trace Data - UE capability - E-DCH HOs - E-DCH <-> DCH

NWI3: Trace_Report HSDPA Data and HSUPA Data Iub MML: Local Trace Activation

RNC

lub

Core Network

Figure 35

4.5.3 4.5.3.1

RNC Element Manager

Activate Trace

HSDPA Subscriber Trace

System impact Current implementation The current implementation enables Trace to be used in a HSDPA-capable NW without disturbance in normal Tracing, but no HSDPA-specific reporting is available.

4.5.3.2


4.5.3.3

Interdependencies between features The HSDPA features must be active in order to get HSDPA-related data to trace records.

DN70296245


233


4.5.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

-

-

-

-

4.5.3.5

4.5.3.6


RAS SW component



ASW

RAN

RNC LK


Control and plane Signalling-based activation of Subscriber and Equipment Trace in the RNC uses a dedicated Core NW message to the RNC.

4.5.3.7

Management plane NMS interfaces Monitoring tools: • •

No changes to trace activation, that is, no separate activation for HSUPA tracing in the NetAct TraceViewer is possible. The HSDPA-related data will be visible in the NetAct TraceViewer.

Network element interfaces Subscriber Trace may be locally activated in the RNC using RNC Element Manager. Management data

4.5.3.8

Parameters

Counters

Alarms





234


DN70296245


4.6 4.6.1

RAN1052: HSUPA Subscriber Trace Introduction This feature introduces HSUPA reporting for Subscriber and Equipment Trace functionality. Benefits for the operator OPEX savings result from reduced time to troubleshoot the NEs and UE. Possible troubles can be detected and relevant measurement data can be presented simultaneously.

4.6.2

Functional description New HSDPA-related counters to be reported: • •

• •

•

Basic Trace Type/UE Capability Trace record additions: • UE HSUPA capability Basic Trace Type/Active set cell record additions: • EdchUsage (to indicate use of E_DCH) • Target cell of HSUPA Serving Cell Change • Failure cause and aimed Target Cell(s) if the Serving Cell Change fails Basic Trace Type/Dedicated Transport Channel record additions: • E-DCH release and related cause Radio Trace Type/Downlink AM RLC record additions: • E-DCH UL RLC SDU data amounts • Active transmission time Radio Trace Type/Uplink Performance • UL BLER for E-DCH

The current Trace counters can be used to see non-HSUPA-specific issues, such as, the related CN(s), used RAB(s), DL RLC data, state transition and so on. HSUPA Tracing will be an extension to the previously released Trace features. All previous Trace features are simultaneously available with RAN1052: HSUPA Subscriber Trace to enable, for example, simultaneous voice connection tracing.

DN70296245

Id:0900d8058075093a Confidential

235


3GPP Itf-N interface NetAct Northbound interface 3GPP named counters

Report generation NetAct Reporter

RNC - NetAct proprietary interface

HSDPA Trace Data - UE capability - HS-DSCH HOs - HS-DSCH <-> DCH HSUPA Trace Data - UE capability - E-DCH HOs - E-DCH <-> DCH

NWI3: Trace_Report HSDPA Data and HSUPA Data Iub MML: Local Trace Activation

RNC

lub

Core Network

Figure 36

4.6.3 4.6.3.1

RNC Element Manager

Activate Trace

HSDPA Subscriber Trace

System impact Current implementation The current implementation enables Trace to be used in a HSUPA-capable network without disturbance in normal Tracing. This new feature introduces HSUPA-specific reporting.

4.6.3.2


4.6.3.3

Interdependencies between features The HSUPA features must be active in order to get HSUPA-related data to trace records.

236


DN70296245


4.6.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

-

-

-

-

4.6.3.5

4.6.3.6


RAS SW component



ASW

RAN

RNC LK


Control and plane Signaling based activation of Subscriber and Equipment Trace in RNC uses dedicated Core NW message to RNC.

4.6.3.7

Management plane NMS interfaces Monitoring tools: • •

No changes to trace activation, that is, no separate activation for HSUPA tracing in the NetAct TraceViewer is possible. The HSUPA-related data will be visible in NetAct TraceViewer.

Network element interfaces Subscriber Trace may be locally activated in the RNC using RNC Element Manager. Management data

4.6.3.8

Parameters

Counters

Alarms




Impact on system performance and capacity This feature has no impact on system performance or capacity

DN70296245


237

RNC solution features


5 RNC solution features 5.1

RAS06 documentation for RNC solution features See the following table for more detailed information on WCDMA RAN functionality:

Feature ID: Name

Functional Area Description

Feature Activation Manual

RAN1151: Linux Based OMS Replacing NEMU RAN1623: Carrier Connectivity Optimised RNC450 RAN1739: HSUPA Amount Increase in RNC RAN1754: HSPA Optimized Configuration

Table 34


5.1.1

Information on parameters, counters, and alarms For information on the parameters, counters and alarms related to each feature, see the System impact section of the feature descriptions. For parameter descriptions, see: • • • • • • •




For alarm descriptions, see: • • • • • • • • •

238


Id:0900d8058074cc09 Confidential

DN70296245




DN70296245

Id:0900d8058074cc09 Confidential

239


5.2 5.2.1

RAN1151: Linux Based OMS Replacing NEMU Introduction Linux-based OMS replaces Windows-based NEMU. Benefits for the operator New performance management and operability features can be used without restrictions on performance and capacity.

5.2.2

Functional description Linux (RedHat Enterprise 4 update 3) replaces the Windows platform used in NEMU (Network Management Unit) in the earlier releases. The name OMS (O&M Server) will be used instead of NEMU. Windows-based NEMU is not ed in RAS06/RN3.0 any longer. The OMS functionality does not differ from NEMU. It is responsible for the same tasks as NEMU but with higher performance and capacity. The Linux operating system also provides high stability for this type of application. OMS is responsible for the following tasks: • • • •

5.2.3 5.2.3.1

interface, both GUI NEMU functionalities and MMI for MML sessions NetAct interface O&M functions in the RNC post-processing for measurement and statistics tasks

System impact Current implementation In earlier releases Windows-based NEMU is used.

5.2.3.2

Hardware requirements M18-B is required for OMS.

5.2.3.3

Interdependencies between features RAN1181: RNC NEMU Firewall feature is not used in OMS any longer.

5.2.3.4

Release

240


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

OSS4.2

-

-

-

-


DN70296245


5.2.3.5

5.2.3.6


RAS SW component



OSW

RAN

-

-

Control and plane This feature has no effect on control and plane.

5.2.3.7

Management plane NMS interfaces This feature has no effect on NMS interfaces. Network element interfaces Due to the operating system change the Graphical Interface is visually slightly changed but the usability principles are unchanged. Management data Parameters

Counters

Alarms



71050 OMS EMT CONNECTION COULD NOT BE OPENED 71051 OMS EMT CONTROL CONNECTION FAILURE 71052 OMS FTP CONNECTION COULD NOT BE OPENED 71053 O&M FOR INTEGRATED 3RD PARTY DEVICES 71054 WCDMA BTS O&M MEDIATION FAILURE 71055 NETWORK ELEMENT RESTARTED 71056 OMS TELNET CONNECTION COULD NOT BE OPENED 71057 RNW NOTIFICATION MISSING

5.2.3.8

Impact on system performance and capacity This feature has no effect on capacity and performance.

5.2.3.9

Other impacts None.

DN70296245


241


5.3 5.3.1

RAN1623: Carrier Connectivity Optimised RNC450 Introduction The operator can select either the standard original capacity-optimised steps of RNC450 or the coverage-optimised solution with high carriers/cell connectivity and lower maximum PS data throughput. Benefits for the operator Wide network coverage can be built under RNC when the PS data capacities are low. This is beneficial, for example, in case of network rollout phase or in the markets where the AMR traffic is dominant. The operator can optimise the number of needed RNCs in the network by selecting the right configuration that best s their traffic profile.

5.3.2

Functional description The carrier connectivity solution is ed by each RNC450 configuration. More carriers/cells and NodeBs can be configured under the RNC having lower PS data throughput. With RNC450/step2-300, AMR capacity is increased to 6800. With RNC450/step3450 carrier-optimised configuration, AMR capacity is increased to 10 000 Erl. The RNC HW configuration is always the same between the capacity and coverage solution. Selection of the configuration mode is done by using SW license keys. HSPA activation is made by using different parameters for each mode. For RNC450/step1-150 there are four different alternatives for the coverage solution. Step1 solution is already available in RAS05.1 without a license key. RNC450/step2300 and RNC450/step3-450 s one carrier-optimised configuration for each step. License keys for all steps are introduced in RAS06. Capacities of the coverage solution are presented in the following figure. For information on the numbers of ed HSPA s for different RNC configurations, see RNC450 capacity in WCDMA RNC Product Description for RNC450. RNC 450/150 1 cabinet

RNC 450/300 1,5 cabinets

RNC 450/450 2 cabinets

150 Mbps DL 4000 Erl 200 BTSs (1+1+1) 600 Cells



RAS05.1 50 Mbps DL 4000 Erl 280 BTSs (1+1+1) 840 Cells

Figure 37

242

RAS06 180 Mbps DL 6800 Erl 400 BTSs (1+1+1) 1200 Cells

RAS06 250 Mbps DL 10000 Erl 600 BTSs (1+1+1) 1800 Cells

Capacities of the coverage solution

Id:0900d805806090ad Confidential

DN70296245


Default capacity

Coverage optimised

Coverage optimised

Coverage optimised

Coverage optimised

Iub throughput Mbps

150

135

105

80

50

AMR Erlang

4000

4000

4000

4000

4000

Number of carriers

600

660

720

780

840

Number of 200 BTSs (1+1+1)

220

240

260

280

Table 35

5.3.3 5.3.3.1

Different configuration options for RNC450/150

System impact Current implementation In RAS05.1 carrier optimised configurations are ed for RNC450/step1-150 without license control. Coverage-optimized configurations are not ed for RNC450/step2-300 or RNC450/step3-450 in RAS05.1.

5.3.3.2


5.3.3.3


5.3.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

-

-

-

-

-

-

-

-

5.3.3.5

5.3.3.6


RAS SW component



OSW

RAN

RNC LK


Control and plane plane capacity is decreased for Iub PS data.

DN70296245


243


5.3.3.7

Management plane NMS interfaces This feature has no effect on NMS interfaces. Network element interfaces Different parameter values are used in HSPA activation phase for carrier-optimised configurations. Management data

5.3.3.8

Parameters

Counters

Alarms




Impact on system performance and capacity Cell/carrier connectivity under RNC can be increased with lower PS data throughput capacity.

244


DN70296245


5.4 5.4.1

g

RAN1739: HSUPA Amount Increase in RNC Introduction This feature is delivered on top of RAS06. The number of HSUPA s ed at the RNC level is increased and the resource allocations are changed as dynamic. Benefits for the operator Better experience for HSPA s.

5.4.2

Functional description The number of HSUPA s ed at the RNC level is increased. All HSDPA s can have HSUPA in UL. The resource allocation for HSUPA s is dynamic so that all s are capable of achieving the maximum peak rate 2.0 Mbit/s when RNC or cell throughput is available. The maximum number of HSPA s with different UL channels is defined in the attached table for both RNC196 and RNC450. The new feature is planned for RN3.0 CD1.0 content. Number of HSDPA s Associated UL Channel RNC196 configuration

384 kbit/s

128 kbit/s

64 kbit/s

16 kbit/s

HSUPA

48

216

504

792

792

792

85

432

1008

1584

1584

1584

122

648

1512

2376

2376

2376

159

864

2016

3168

3168

3168

196

1116

2604

4092

4092

4092

300

1116

2604

4092

4092

4092

450

1116

2604

4092

4092

4092

Number of HSDPA s Associated UL Channel RNC450 configuration

384 kbit/s

128 kbit/s

64 kbit/s

16 kbit/s

HSUPA

150 Standard

378

882

1386

1386

1386

150 Carrier optimised 1

342

798

1254

1254

1254


270

630

990

990

990


216

504

792

792

792


114

336

528

528

528

300 Standard

738

1722

2706

2706

2706

300 Carrier optimised

468

1092

1716

1716

1716

450 Standard

1116

2604

4092

4092

4092

450 Carrier optimised

630

1470

2310

2310

2310

Figure 38

DN70296245

The maximum number of HSPA s with different UL channels for both RNC196 and RNC450.

Id:0900d805806090b0 Confidential

245


5.4.3 5.4.3.1

System impact Current implementation Not all HSDPA s can have HSUPA in UL. HSUPA gets resource reservation that enables the full peak rate (2.0 Mbit/s) or half (711 kbit/s) peak rate.

5.4.3.2


5.4.3.3


5.4.3.4


Relea se

5.4.3.5

246

RAS

RNC

BTS Ultra

RAS0 6 On top

RN3.0 On top

BTS Flexi

AXC

NetAc MSC t

SGSN

MGW

UE

-

-

-1

-

-

-

-


RAS SW component



OSW

RAN

-

-


DN70296245


5.5 5.5.1

g

RAN1754: HSPA Optimized Configuration Introduction This feature is delivered on top of RAS06. HSPA optimized configuration provides more HSPA s in RNC with decreased R99 data throughput capacity. The AMR capacity is the same as in the default configuration. Benefits for the operator More HSPA s in Cell_DCH state can be simultaneously ed.

5.5.2

Functional description New HSPA configuration is introduced for RNC196 and RNC450. The HW configuration is the same as currently. The configuration is changed in SW, by changing the HSPA activation parameters that will have an affect on the RNC internal resource management. Or: The configuration is changed in SW, by changing the HSPA activation parameters that affect RNC internal resource management. The number of simultaneous HSPA s in RNC is increased. At the same time the maximum throughput for R99 data connections is limited to about 50 % from the current maximum. The AMR capacity is the same as earlier. The new configuration is alternative to the existing HSPA configuration that is also still ed. The number of HSPA s and the max R99 data throughputs are defined in the figure below. Number of HSDPA s Associated UL Channel 128 kbit/s

64 kbit/s

16 kbit/s

HSUPA

288

672

1056

1056

1056

612

1428

2244

2244

2244

122

954

2226

3498

3498

3498

159

1278

2982

4686

4686

4686

196

1602

3738

5874

5874

5874

300

1602

3738

5874

5874

5874

450

1602

3738

5874

5874

5874

RNC196 configuration

384 kbit/s

48 85

Number of HSDPA s Associated UL Channel RNC450 configuration

384 kbit/s

128 kbit/s

64 kbit/s

16 kbit/s

HSUPA

150

450

1050

1650

1650

1650

300

918

2142

3366

3366

3366

450

1602

3738

5874

5874

5874

Figure 39

DN70296245

The number of HSPA s and the max R99 data throughputs.


247


5.5.3 5.5.3.1

System impact Current implementation : In the current implementation the total maximum RNC level throughput can also be achieved with R99 data connections.

5.5.3.2


5.5.3.3

Hardware requirements CDSP-C interchangeability D is required for DMCU. AL2S-D is required for A2SU.

5.5.3.4

Release

RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06 On top

RN3.0 On top

-

-

-

-1

-

-

-

-

5.5.3.5

248



RAS SW component



OSW

RAN

-

-


DN70296245


BTS solution features

6 BTS solution features 6.1

RAS06 documentation for BTS solution features See the following table for a list of BTS solution features for RAS06.

Feature ID: Name

Descriptions

Instructions

RAN1733: Flexi WCDMA BTS 2100 High Gain

Flexi WCDMA BTS RF Module and Remote Radio Head description


RAN1734: Flexi WCDMA BTS 2100 New Variants

Flexi WCDMA BTS RF Module and Remote Radio Head description


RAN1736: Flexi WCDMA BTS AISG 1.1 SW

This feature does not have related documents


RAN906: Flexi WCDMA BTS 3GPP Antenna Tilt

Flexi WCDMA BTS product description


RAN908: Flexi WCDMA BTS AISG MHA



RAN1222: External GPS Synchronisation for Flexi BTS System Module Rel 1



RAN1463: for FPRA in Flexi WCDMA BTS

Installing Flexi Cabinet for Outdoor (FCOA)


Commissioning Flexi WCDMA BTS

Commissioning Flexi WCDMA BTS Commissioning Flexi WCDMA BTS

Cabling Flexi WCDMA BTS and creating configurations RAN1139: FADB Flexi Multiradio Combiner for 900MHz

For more information see: Nokia Siemens Networks Antenna Systems, Operating Documentation available in NOLS


RAN1079: FACB Flexi Multiradio Combiner for 850MHz



RAN1462: FAGB Flexi Multiradio combiner for 2100MHz



RAN1127: Extended Cell (180km)



RAN1309: WMHD Mast Head Amplifier



RAN1670: UltraSite EDGE Wideband Combiner for WCDMA Refarming



RAN1808: BTS Receiver Optimisations for High Speed Train Scenarios



Table 36


DN70296245

Id:0900d80580926bdc Confidential

249


6.1.1


Information on parameters, counters, and alarms For information on the parameters, counters and alarms related to each feature, see the System impact section of the feature descriptions. For parameter descriptions, see: • • • • • • •




For alarm descriptions, see: • • • • • • • • •



250

Id:0900d80580926bdc Confidential

DN70296245


6.2

RAN1733: Flexi WCDMA BTS 2100 High Gain

6.2.1

Introduction

g

This feature is delivered on top of RAS06. New Flexi WCDMA BTS RF Module versions (FRGJ/K) will be developed to 2100 MHz band with high gain MHA that utilizes ex-Siemens TMA proprietary interface. Benefits for the operator FRGJ/K RF Modules can be used with ex-Siemens Node-B replacements having 24 dB TMA installations, thus existing TMAs can be utilized.

6.2.2

Functional description FRGJ is Flexi WCDMA RF Module 2100 MHz version with dual sector . WN4.0 CD1 SW is needed. FRGK is Flexi WCDMA RF Module 2100 MHz version with single sector . WN4.0 CD1 SW is needed. • •

6.2.3

Uplink: 1920 - 1980 MHz Downlink: 2110 - 2170 MHz

System impact

6.2.3.1

Current implementation Currently Flexi WCDMA BTS 2100 RF Modules s fixed 12 dB MHAs.

6.2.3.2


6.2.3.3

Hardware requirements Flexi WCDMA BTS FRGJ/K RF Module required.

6.2.3.4

Release

DN70296245


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06 On top

-

-

WBTS 4.5

-

-1

-

-

-

-


251


6.2.3.5

252


RAS SW component



OSW

RAN

-

-


DN70296245


6.3

RAN1734: Flexi WCDMA BTS 2100 New Variants

6.3.1

Introduction

g

This feature is delivered on top of RAS06. New Flexi WCDMA BTS 2100 MHz RF Module (FRGL/M) variants. Benefits for the operator This is to secure Flexi WCDMA BTS delivery volumes.

6.3.2

Functional description FRGL/M will new filters available on top of RAS06. The functionality of FRGL/M is equal to existing 2100 MHz RF Modules (FRGC/D).

6.3.3

System impact

6.3.3.1

Current implementation Current 2100 MHz implementation is with FRGC/D Flexi WCDMA BTS RF Modules. The functionality of FRGL/M is equal to FRGC/D.

6.3.3.2


6.3.3.3

Hardware requirements Flexi WCDMA BTS FRGL/M RF Module required.

6.3.3.4

Release

RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06 On top

-

-

WBTS 4.5

-

-1

-

-

-

-

6.3.3.5

DN70296245



RAS SW component



OSW

RAN

-

-


253


6.4

RAN1736: Flexi WCDMA BTS AISG 1.1 SW

6.4.1

Introduction

g

This feature is delivered on top of RAS06. AISG 1.1 SW is needed for ex-Siemens antenna line products (TMA/RET). The FRGJ/K RF modules these antenna line products from HW point of view. Benefits for the operator With AISG 1.1 SW operator can use ex-Siemens Node-B replacements having installed AISG 1.1 compatible antenna line products.

6.4.2

Functional description The AISG 1.1 SW includes: • •

AISG 1.1 MHA (similar functionality as ex-Siemens node B for DTMARETFVx, SDTMARETFVx) AISG 1.1 RET

This feature will be ed in WN4.0 CD2.

6.4.3

System impact

6.4.3.1

Current implementation AISG 1.1 SW is not currently ed.

6.4.3.2

Interdependencies between features Flexi WCDMA BTS RF Module versions FRGJ/K.

6.4.3.3

Hardware requirements Flexi WCDMA BTS RF Module versions FRGJ/K.

6.4.3.4

Release

254


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06 On top

-

-

WBTS 4.5

-

-1

-

-

-

-


DN70296245


6.4.3.5

DN70296245


RAS SW component



OSW

RAN

-

-


255


6.5 6.5.1

RAN906: Flexi WCDMA BTS 3GPP Antenna Tilt Introduction Flexi WCDMA BTS has integrated Antenna Tilt control HW in Radio module to control the 3GPP Tilt Antennas. This integrated Antenna tilt HW is enabled by a specific SW licence. Nokia Siemens Networks officially s only the following antennas: Kathrein, Powerwave, Andrew.

6.5.2

Functional description Antenna Tilt is integrated to the RF module of Flexi WCDMA BTS. It feeds DC power to the antenna and controls the antenna tilting. In Flexi WCDMA BTS this 3GPP specified antenna tilting functionality must be enabled by a SW licence because the HW is integrated to all RF Modules.

6.5.3 6.5.3.1


6.5.3.2

Release


RAS

RNC

BTS Ultra

BTS Flexi AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

-

-

WBTS4.0

-

-

-

-

-

6.5.3.3

6.5.3.4

-

Software sales information BSW/ASW

RAS SW component



ASW

RAN

BTS LK

-

Management plane Network element interfaces The antenna tilt for detected devices can be changed via BTS element manager. Management data

256

Parameters

Counters

Alarms




Id:0900d805808eea73 Confidential

DN70296245


6.6 6.6.1

RAN908: Flexi WCDMA BTS AISG MHA Introduction Flexi WCDMA BTS has integrated Bias-T HW in Radio module to control Nokia Siemens Networks AISG 2.0 MHA's. This integrated HW based SW functionality is to be enabled by a specific SW licence.

6.6.2

Functional description Bias-T is integrated to the RF module of Flexi BTS. It feeds DC power to the MHA and controls the MHA DC power current consumption. If the current consumption is out of a specified window, an alarm is generated. AISG has specified additional control functionality for MHA. This control is done over OOK modulation using the antenna feeder. In UltraSite, the Bias-Ts have been separate HW units installed to the BTS antenna connectors and customer has paid the functionality in the Bias-T HW price, typically 6 pieces for a 3 sector BTS. In Flexi WCDMA BTS, this AISG 2.0 MHA power feeding and enhanced MHA alarm control must be enabled by a SW licence because the HW is integrated to all RF Modules. Nokia Siemens Networks s only MHAs coded with AISG vendor code 'NK'. For 3rd party MHAs there will be special licence key and ed MHAs need to be decided case by case.

6.6.3 6.6.3.1

System impact Current implementation Used MHA parameters will be entered during commissioning.

6.6.3.2

Hardware requirements Nokia Siemens Networks only s its own AISG-compatible MHS with AISG vendor code ‘NK’.

6.6.3.3

Interdependencies between features RAN905 license is not needed if AISG interface activated (with license).

6.6.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

-

-

WBTS4.0

-

-

-

-

-

-

DN70296245

Id:0900d805808eeaa1 Confidential

257


6.6.3.5

6.6.3.6


RAS SW component



ASW

RAN

BTS LK

-

Control and plane This feature has no impact on control and plane

6.6.3.7

Management plane NMS interfaces This feature has no impact on Management plane. Network element interfaces The can confirm (or change) the proposed values that have automatically been detected by Flexi BTS. Management data

6.6.3.8

Parameters

Counters

Alarms




Impact on system performance and capacity This feature has no impact on system performance and capacity.

258

Id:0900d805808eeaa1 Confidential

DN70296245


6.7

6.7.1

RAN1222: External GPS Synchronisation for Flexi BTS System Module Rel 1 Introduction External GPS syncronisation is needed for the WCDMA BTSs with I-HSPA and also for other customers that have an Ethernet transport solution. Benefits for the operator The operators that utilise I-HSPA or Ethernet transport need GPS synchronisation.

6.7.2

Functional description The BTS will get sync signal (pps) from external GPS device. GPS signal is needed together with I-HSPA module or when the Ethernet transport is in use. The GPS device is overvoltage-protected by a mediator box (FSEG) that includes the following functionalities and parts: • • • • • • •

6.7.3 6.7.3.1

Power output (12VDC) to the GPS receiver. GPS signal transfer from GPS receiver to MDR26 connector in System Module Overvoltage protection (4KV) must be guaranteed according to standard for mast devices which prevents System Module failures. IP55 protection. Two cables are in use (Sync in from mediator box to Rel1 System Module and 48V from system Module to Mediator box voltage conversion to GPS receiver (+ 12V)). In addition to the Mediator box, integrated GPS receiver and antenna kit(FYGA) is needed. A separate mounting kit (FYMA) can be used for installation. Optionally 30m (FYHA) or 100m (FYHB) cables can be used between the GPS receiver and the Mediator box.

System impact Current implementation There has been no GPS sync available earlier.

6.7.3.2

Hardware requirements This solution is needed together with Rel1 system module.

6.7.3.3


DN70296245


259


6.7.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

-

-

WBTS4.0

-

-

-

-

-

-

6.7.3.5

6.7.3.6


RAS SW component



OSW

RAN

-

-


6.7.3.7

Management plane NMS interfaces No impact. Network element interfaces WN3.2 and WN3.3 had to select the correct sync source via Flexi Transport Module. If GPS sync is in use , it will be automatically used as a sync source. Management data

6.7.3.8

Parameters

Counters

Alarms




Impact on system performance and capacity This feature has no impact on signalling interfaces.

260


DN70296245


6.8 6.8.1

g

RAN1463: for FPRA in Flexi WCDMA BTS Introduction This feature is delivered on top of RAS06. FPRA Flexi Rectifier Module is an OEM-based rectifier solution for all Flexi WCDMA BTS-based applications. FPRA is equal to Flexi WCDMA BTS module in of dimensions, weight, fixing points and outlook. FPRA will be available in indoor IP20 and outdoor IP55 versions. FPRA maximum output power is 6kW providing DC connection point to maximum 2 BTSs and 3 external battery strings. Benefits for the operator: FPRA allows to supply multiple BTSs or different BTS generations from a single unit still providing sufficient charging capacity for bigger battery banks.

6.8.2

Functional description FPRA consist of a maximum of three 2kW rectifier modules inside 3U high casing. The amount of rectifier units is configurable on a need basis. The same 3U high casing also includes the DC-distribution (BTS and battery breakers), controller unit with display, LMP port and space for optional overvoltage protector.

6.8.3 6.8.3.1

System impact Current implementation This feature is a more powerful alternative for FPAA.

6.8.3.2


6.8.3.3


6.8.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06 ED1

-

WBTS4.0 ED1

WBTS4.0 ED1

-

-

-

-

-

-

DN70296245

Id:0900d80580926bd8 Confidential

261


6.8.3.5

6.8.3.6


RAS SW component



OSW

RAN

-

-

Control and plane No impact.

6.8.3.7

Management plane NMS interfaces No impact. Network element interfaces No impact. Management data

6.8.3.8

Parameters

Counters

Alarms




Impact on system performance and capacity No impact.

6.8.3.9

Other impacts No other impacts.

262

Id:0900d80580926bd8 Confidential

DN70296245


6.9 6.9.1

g

RAN1139: FADB Flexi Multiradio Combiner for 900MHz Introduction This feature is delivered on top of RAS06. This feature provides a Multiradio Combiner for 900MHz. Benefits for the operator Enables sharing of one antenna system with two BTSs operating on the frequency band.

6.9.2

Functional description Multiradio combiner (MRC) makes it possible to use common feeders and antennas for GSM and WCDMA systems operating on the same frequency band. This solution provides a cost-efficient way to add a WDCMA BTS to an existing GSM site by combining signals of the two BTSs into one antenna system. Using of MRC has minimal performance impact on WCDMA BTS. Low DL insertion loss of 0.5dB means only minor performance impact in transmit power. MRC losses in UL path are compensated with an MHA and if the BTS s an adjustable front end gain (Flexi WCDMA BTS and UltraSite/Flexi EDGE BTS), impact on sensitivity is marginal. The MRC concept requires all TX signals of one BTS to be combined in one antenna feeder. Therefore, the dual duplex setup in GSM BTS, which is typically used when having more than one TRX per sector, has to be removed and an additional wideband combining stage needs to added (not applicable with cavity combining). UL performance is maintained with an MHA in a similar way as with WCDMA BTS.

6.9.3 6.9.3.1

System impact Current implementation Both BTSs need their own antennas, MHAs and feeders.

6.9.3.2

Hardware requirements The MRC unit can be installed to a standard 19" mechanics or inside a Flexi 2U casing (FTMA). When MRC is installed outside the 2G BTS, the cabling between the MRC and the two BTSs is done using cable kits found from the current jumper cable portfolio. In case of installing the MRC inside the UltraSite EDGE or CityTalk BTSs, the needed installation kits include required jumper cables for MRC. When using an MRC and having Flexi WCDMA modules placed inside the UltraSite EDGE BTS using the horizontal installation kit (FMUB), a special wideband combiner must be used to perform the additional combining of GSM TX signals - this combiner also includes the additonal interconnecting cables needed with it.

6.9.3.3


DN70296245

Id:0900d805808054fc Confidential

263


6.9.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06 ED1

-

-

WBTS4.0 ED1

-

-

-

-

-

-

6.9.3.5

6.9.3.6


RAS SW component



OSW

RAN

-

-

Management plane Network element interfaces Multiradio Combiner is activated with BTS Site EM check box during commissioning. Management data

6.9.3.7

Parameters

Counters

Alarms




Impact on system performance and capacity This feature has no impact

6.9.3.8

Other impacts This feature has no impact

264

Id:0900d805808054fc Confidential

DN70296245


6.10 6.10.1

g

RAN1079: FACB Flexi Multiradio Combiner for 850MHz Introduction This feature is delivered on top of RAS06. This feature provides a Multiradio Combiner for 850MHz. Benefits for the operator Enables sharing of one antenna system with two BTSs operating on the frequency band.

6.10.2

Functional description Multiradio combiner (MRC) makes it possible to use common feeders and antennas for GSM and WCDMA systems operating on the same frequency band. This solution provides a cost-efficient way to add a WDCMA BTS to an existing GSM site by combining signals of the two BTSs into one antenna system. Using of MRC has minimal performance impact on WCDMA BTS. Low DL insertion loss of 0.5dB means only minor performance impact in transmit power. MRC losses in UL path are compensated with an MHA and if the BTS s an adjustable front end gain (Flexi WCDMA BTS and UltraSite/Flexi EDGE BTS), impact on sensitivity is marginal. The MRC concept requires all TX signals of one BTS to be combined in one antenna feeder. Therefore, the dual duplex setup in GSM BTS, which is typically used when having more than one TRX per sector, has to be removed and an additional wideband combining stage needs to added (not applicable with cavity combining). UL performance is maintained with an MHA in a similar way as with WCDMA BTS.

6.10.3 6.10.3.1

System impact Current implementation Both BTSs needs their own antennas, MHAs and feeders.

6.10.3.2

Hardware requirements The MRC unit can be installed to a standard 19" mechanics or inside a Flexi 2U casing (FTMA). When MRC is installed outside the 2G BTS, the cabling between MRC and the two BTSs is done using cable kits found from current jumper cable portfolio. In case of installing the MRC inside the UltraSite EDGE or CityTalk BTSs, the needed installation kits include required jumper cables for MRC. When using MRC and having Flexi WCDMA modules placed inside the UltraSite EDGE BTS using the horizontal installation kit (FMUB), a special wideband combiner must be used to perform the additional combining of GSM TX signals - this combiner also includes the additonal interconnecting cables needed with it.

6.10.3.3


DN70296245


265


6.10.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06 ED1

-

-

WBTS4.0 ED1

-

-

-

-

-

-

6.10.3.5

6.10.3.6


RAS SW component



OSW

RAN

-

-

Management plane Network element interfaces Multiradio Combiner is activated with BTS Site EM check box during commissioning. Management data

6.10.3.7

Parameters

Counters

Alarms





6.10.3.8

Other impacts This feature has no other impact

266


DN70296245


6.11

6.11.1

g

RAN1670: UltraSite EDGE Wideband Combiner for WCDMA Refarming Introduction This feature is delivered on top of RAS06. The special UltraSite EDGE wideband combiner is a unit needed for additional TX combining in 2G BTS when common antenna line sharing is done using Multiradio combiner (MRC). This special WBC unit is only needed when MRC is used and Flexi WCDMA modules are placed inside the UltraSite EDGE cabinet using horisontal installation kit (FMUB). Benefits for the operator UltraSite EDGE multimode BTS solution can fully be exploited in a WCDMA refarming application when MRC is used for common antenna line sharing - all needed Flexi WCDMA modules and additional WBC required by MRC can be fitted inside Ultrasite EDGE cabinet (new IDCA/ODCA versions). This leads not only to excellent cost and space efficiency, but also prevents risk for increased site lease cost since no new cabinet is needed with WCDMA introduction.

6.11.2

Functional description Multiradio combiner (MRC) makes it possible to use common feeders and antennas for GSM and WCDMA systems operating on the same frequency band. This solution provides a cost efficient way to add a WDCMA BTS to an existing GSM site by combining signals of the two BTSs into one antenna system. MRC concept requires all TX signals of one BTS to be combined in one antenna feeder. Therefore the dual duplex setup in GSM BTS, which is typically used when having more than one TRX per sector, has to be removed and an additional wideband combining stage needs to be added (not applicable with cavity combining). When using MRC and having Flexi WCDMA modules placed inside the UltraSite EDGE BTS using the horisontal installation kit (FMUB), the special wideband combiner must be used to perform the additional combining of GSM TX signals. The new WBC is placed in the baseband unit rack of the BTS.

6.11.3 6.11.3.1

System impact Current implementation Existing UltraSite EDGE wide combiners do not the additional TX combining required by MRC when Flexi WCDMA modules are placed inside the UltraSite EDGE cabinet using the horisontal installation kit (FMUB).

6.11.3.2

Interdependencies between features The special UltraSite EDGE WBC is only applicable when MRC is used and Flexi WCDMA modules are placed inside the UltraSite EDGE BTS using the horisontal installation kit (FMUB).

DN70296245


267


6.11.3.3

Hardware requirements The special UltraSite EDGE WBC is only applicable when MRC is used and Flexi WCDMA modules are placed inside the UltraSite EDGE BTS using the horisontal installation kit (FMUB). FMUB is only ed by the new version of IDCA/ODCA cabinets (ver.2xx onwards). The special WBC unit contains the additional interconnecting cables needed.

6.11.3.4

Release

RAS

RNC

BTS Ultra BTS Flexi AXC

NetAct

MSC

SGSN

MGW

UE

RAS06 On top

-

-

-

-

-

-

-

6.11.3.5

268


WBT S4.0 On top

-


RAS SW component



OSW

RAN

-

-


DN70296245


6.12

6.12.1

RAN1808: BTS Receiver Optimisations for High Speed Train Scenarios Introduction New high speed train solution improves setting up phone calls and maintaining phone calls for train engers travelling up to 350 km/h. Benefits for the operator Significant improvement in network performance for end in high speed train solution.

6.12.2

Functional description In high speed trains, when UE is moving very quickly, doppler effect is seen resulting a frequency shift. If the Doppler shift is higher than ed, the BTS have difficulties to detect uplink signal properly bacause of significant additional BER. It may be difficult to set up phone calls or existing phone calls are disconnected. Also problems with handovers and voice quality can be noticed. BTS SW in WSPA & WSPC for Ultrasitre and Flexi BTS System Module is modified for RACH and DCH to tolerate higher Doppler frequency. This solution improve speed up to 350 km/h what is confirmed by field test result. Solution is ed for both Ultrasite and Flexi BTS. High speed train requires also larger handover distance between the cells. This has to be taken into in the network planning.

6.12.3 6.12.3.1

System impact Current implementation The Current WCDMA BTS Implementation s up to +/-560 Hz Doppler shift (Fdoppler_DL + Fdoppler_UL). It means about 150 km/h speed if the angle (α) is zero when BTS is located next to railway. The current limitation is in WSPA, WSPC and Flexi BTS System Module units.

6.12.3.2


6.12.3.3


6.12.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06 On Top

-

WBTS 4.0

WBTS 4.0

-

-

-

-

-

-

DN70296245


269


6.12.3.5

270


RAS SW component Licence control in network element


BSW

RAN

Not defined


Not defined

DN70296245


6.13

RAN1462: FAGB Flexi Multiradio combiner for 2100MHz

6.13.1

Introduction This feature provides a MultiRadio Combiner for 2100MHz. Benefits for the operator Enables sharing of one antenna system with two BTSs operating on the frequency band.

6.13.2

Functional description Multiradio combiner (MRC) makes it possible to use common feeders and antennas for two WCDMA systems operating on the same frequency band. This solution provides a cost-efficient way to add new WDCMA BTS to an existing site by combining signals of the two BTSs into one antenna system. Using of MRC has a minimal performance impact on WCDMA BTS. Low DL insertion loss of 0.5dB means only minor performance degradation in transmit power. The MRC losses in the UL path are compensated with an MHA and if the BTS s an adjustable front end gain (Flexi WCDMA BTS and UltraSite WCDMA BTS), the degradation of original sensitivity is marginal.

6.13.3

System impact

6.13.3.1

Current implementation Both BTSs need their own antennas, MHAs and feeders.

6.13.3.2

Hardware requirements This feature does not require any new or additional HW. New cable kits are not needed. All required jumper cables can be found from the current portfolio.

6.13.3.3


6.13.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

-

WBTS4.0

WBTS4.0

-

-

-

-

-

-

6.13.3.5

DN70296245


RAS SW component



OSW

RAN

-

-


271


6.13.3.6

Management plane Network element interfaces Multi Radio Combiner is activated via BTS Site EM check box during commsioning. Management data

6.13.3.7

Parameters

Counters

Alarms





6.13.3.8

Other impacts This feature has no impact

272


DN70296245


6.14 6.14.1

RAN1127: Extended Cell (180km) Introduction The cell radius is extended up to 180 km. Benefits for the operator This feature provides an economical method to build WCDMA coverage in rural areas.

6.14.2

Functional description 3G extended cell feature can be used to efficiently provide coverage in coastal and rural areas, where big capacity or high data rates are not needed. Furthermore, new lower WCDMA frequency bands 850 MHz and 900 MHz make it possible to achieve larger cell sizes and also utilise the existing GSM cell raster. The feature is also needed with optical repeater cases (train tunnels, Flexi WCDMA BTS remote RF heads) to overcome the decreased cell radius caused by the delay of optical cables. BTS has the main functionality of this feature. The feature is activated from the RNC/NetAct with the Cell Range parameter. The operator has a possibility to modify the Cell Range Parameter up to 180 km. In 3GPP, RACH/AICH detection & transmit power control delays define the cell range. SW implementation up to 180 km cell range. The Extended Cell is verified up to 150 km in RAS06 case of 2-port receiver diversity. The feature activation is based on SW licences.

6.14.3 6.14.3.1

System impact Current implementation The maximum cell range is 20 km.

6.14.3.2

Hardware requirements For UltraSite WCDMA BTS, it is advisable to have at least one WSPC for each Extended cell (+WSP for normal CCCH) for optimal CE consumption.

6.14.3.3


6.14.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

RN3.0

WBTS4.0

WBTS4.0

-

OSS4.2

-

-

-

-

DN70296245


273


6.14.3.5

6.14.3.6


RAS SW component



ASW

RAN

RNC LK


Control and plane This feature has no impact on Control and plane.

6.14.3.7

Management plane NMS interfaces Maximum value for cell range extended to 180km. Network element interfaces Maximum value for cell range extended to 180km. Management data Parameters

Counters

Alarms

Cell range

PRACH PROPAGATION DELAY CLASS 0


PRACH PROPAGATION DELAY CLASS 1 PRACH PROPAGATION DELAY CLASS 2 PRACH PROPAGATION DELAY CLASS 3 PRACH PROPAGATION DELAY CLASS 4 PRACH PROPAGATION DELAY CLASS 5 PRACH PROPAGATION DELAY CLASS 6 PRACH PROPAGATION DELAY CLASS 7 PRACH PROPAGATION DELAY CLASS 8 PRACH PROPAGATION DELAY CLASS 9 PRACH PROPAGATION DELAY CLASS 10 PRACH PROPAGATION DELAY CLASS 11 PRACH PROPAGATION DELAY CLASS 12 PRACH PROPAGATION DELAY CLASS 13 PRACH PROPAGATION DELAY CLASS 14 PRACH PROPAGATION DELAY CLASS 15 PRACH PROPAGATION DELAY CLASS 16 PRACH PROPAGATION DELAY CLASS 17 PRACH PROPAGATION DELAY CLASS 18 PRACH PROPAGATION DELAY CLASS 19 PRACH PROPAGATION DELAY CLASS 20

274


DN70296245


6.15 6.15.1

RAN1309: WMHD Mast Head Amplifier Introduction WMHD Mast Head Amplifier is an upgrade on WMHC Benefits for the operator WMHD adds the RET output connector and AISG controlling to WMHC. Remote antenna tilt s save RET bias-t and installing time. RF performance, outlook and price are the same as with WMHC.

6.15.2

Functional description The WMHD is a dual amplifier, referred to as a UNIT, which comprises two identical amplifiers, referred to as LNA1 and LNA2. A general reference for either LNA1 or LNA2 is MHA. Physically this means that there is one enclosure with two BTS and ANT ports and one MHA for both branches. The purpose of the WMHD Standard Gain Dual Masthead Amplifier is to compensate feeder losses with minimum over gain, and lowest possible noise contribution, The net effect is to optimise WCDMA BTS receive path sensitivity. This product has a fixed 12dB gain for both branches. The unit is designed for duplex operation. This requires the use of duplex filters or a filter system within the unit to provide a transmit only path and receive only path through the LNA components. The WMHD is capable of operating in AISG mode and current alarm mode. Failure by is provided in case of LNA failure. The purpose of the failure by mode is for the MHA to maintain an RF signal even when an MHA alarm occurs or no DC power is present. On power up or power recycle of the MHA, alarms reset and the unit attempts a normal operation. WMHD also provides output to the antenna tilt motor or another device through the RET connector and additionally through the ANT1 port.

6.15.3 6.15.3.1

System impact Current implementation WMHC is outdated. There is no AISG and no RET connector.

6.15.3.2


6.15.3.3

Interdependencies between features This feature has an interdependency with feature RAN908: Flexi WCDMA BTS AISG MHA .

DN70296245


275


6.15.3.4

Release


RAS

RNC

BTS Ultra

BTS Flexi

AXC

NetAct

MSC

SGSN

MGW

UE

RAS06

-

WBTS4.0

WBTS4.0

-

-

-

-

-

-

6.15.3.5

6.15.3.6


RAS SW component



OSW

RAN

-

-

Control and plane This feature has no impact on signalling interfaces

6.15.3.7

Management plane NMS interfaces No impact. Network element interfaces No impact. Management data

6.15.3.8

Parameters

Counters

Alarms




Impact on system performance and capacity 12dB RX gain is achieved. Failure by is provided in case of LNA failure or power brake, on by mode. There is 3dB of RX Insertion Loss. TX Insertion Loss is 0,5 dB.

6.15.3.9

Other impacts No other impacts

276


DN70296245

Ras06 Feature Descriptions 2e4z41

Overview 5o1f4z

More details 6z3438

Related Documents c2h70

Ras06 Feature Descriptions 2e4z41

Flexi Multiradio 10 Bts Edge Feature Descriptions 412x45

Ranop1 Ras06 Changes 3u4o3f

Personal Descriptions 3t4w6k

Descriptions 05 g4235

Contoh Feature 3m1v58

More Documents from "Semprul Tenan" 3v5a6j

Huawei-singleran 6k5u1l

Ras06 Feature Descriptions 2e4z41

Lirik Lagu Didi Kempot - Layang Kangen 2826d

Kalender 2017.pdf 3l1u20

Tempat Duduk Prioritas 41i1t

Analisa Hambatan Komunikasi Terapeutik Antara Perawat Dan Pasien 566d2b