Dimension Ing WCDMA RAN

Nokia Siemens Networks WCDMA RAN, Rel. RU20, Operating Documentation, Issue 03

Dimensioning WCDMA RAN

DN70118376

Issue 04EApproval Date 2010-06-11

2 DN70118376Issue 04E


Id:0900d80580785cde

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

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

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

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

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

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

Copyright © Nokia Siemens Networks 2010. All rights reserved

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

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

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

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

The same text in German:

Wichtiger Hinweis zur Produktsicherheit

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

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

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

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

DN70118376Issue 04E

3


Id:0900d80580785cde

Table of ContentsThis document has 303 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1 General network planning aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.2 General network dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.3 Required input data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.3.1 Traffic model and capacity requirements . . . . . . . . . . . . . . . . . . . . . . . . 251.3.2 Coverage requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.3.3 Quality requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.4 Radio network - cell planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.4.1 Cell coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.4.2 Cell capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.4.3 Node B hardware and software aspects . . . . . . . . . . . . . . . . . . . . . . . . 321.5 Fixed network – UTRA network plan . . . . . . . . . . . . . . . . . . . . . . . . . . . 331.5.1 Overview of fixed network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331.5.2 Traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331.5.3 Initial cell plan and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331.5.4 Topology aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341.5.5 Hardware aspects – WCDMA BTS and RNC . . . . . . . . . . . . . . . . . . . . 35

2 Traffic modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.1.1 UMTS QoS classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.1.2 QoS parameters for traffic modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.2 Traffic modeling steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.2.1 Mapping of services and applications to QoS classes. . . . . . . . . . . . . . 402.2.2 Mapping of services to radio access bearers (RAB) . . . . . . . . . . . . . . . 422.2.2.1 Support of streaming QoS for HSPA (RU10). . . . . . . . . . . . . . . . . . . . . 432.2.2.2 I-HSPA and VoIP aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.2.2.3 Support of CS voice over HSPA - CSoHS (RU20) . . . . . . . . . . . . . . . . 432.2.3 Definition of quality of service (QoS) and grade of service targets (GoS) .

442.2.4 Traffic demand calculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.2.4.1 Speech, video telephony, and PS RT services . . . . . . . . . . . . . . . . . . . 452.2.4.2 PS data services (Release 99) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.2.4.3 PS data services (Release 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.2.4.4 PS data services (Release 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.3 Standard traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.4 UMTS traffic evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.4.1 Speech service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.4.2 Video telephony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.4.3 SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.4.4 Data services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3 Dimensioning air interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4 DN70118376Issue 04E


Id:0900d80580785cde

3.1.1 RU20 On Top highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.1.1.1 RAN1906 Dual-Cell HSDPA 42Mbps . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.1.1.2 RAN1689 CS Voice over HSPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.1.1.3 RAN2046 Flexi 3-sector RF Module 850 . . . . . . . . . . . . . . . . . . . . . . . . 553.1.1.4 RAN1768 Flexi 3-sector RF Module 900 . . . . . . . . . . . . . . . . . . . . . . . . 553.1.1.5 RAN1871 Flexi 3-sector RF Module 1.7/2.1 . . . . . . . . . . . . . . . . . . . . . . 563.1.1.6 RAN2062 Flexi 3-sector RF Module 2100 . . . . . . . . . . . . . . . . . . . . . . . 563.1.2 RU20 highlights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.1.2.1 RAN1643 HSDPA 64QAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.1.2.2 RAN981 and RAN 1470 HSUPA 5.8 Mbps and HSUPA 2 ms TTI . . . . . 563.1.2.3 RAN1202 24 kbps Paging Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.1.2.4 RAN1201 Fractional DPCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.1.2.5 RAN 1870 Flexi 3-sector RF Module 1500 . . . . . . . . . . . . . . . . . . . . . . . 573.1.2.6 RAN1642 MIMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.1.3 RU10 highlights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.1.3.1 Flexi BTS Multimode System Module . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.1.3.2 Support for Large BTS Configurations up to 12 Cells (FlexiBTS). . . . . . 593.1.3.3 Flexi RF Module Triple 70 W 2100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.1.3.4 OBSAI 60 W remote radio head 2100 for the Flexi product line . . . . . . . 603.1.4 Feature interdependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.2 Common input. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.2.1 Bearers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.2.1.1 R99 bearers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.2.1.2 HSDPA bearers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.2.1.3 HSUPA bearers and UE categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.2.2 Clutter types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.2.3 Cell types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.2.4 Environment Type (Channel Model, Velocity, Indoor/Outdoor User) . . . 693.3 Link budget calculation, macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.3.1 Link Budget Formula (Maximum Allowable Path Loss) R99 bearers . . . 713.3.1.1 Explanation of the used parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.3.1.2 Indoor coverage location probability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773.3.2 Link Budget Formula (Maximum Allowable Path Loss) HSDPA . . . . . . . 773.3.2.1 Explanation of the used parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783.3.2.2 Explanation of the other relevant HSDPA parameters . . . . . . . . . . . . . . 843.3.3 Link Budget Formula (Maximum Allowable Path Loss) HSUPA . . . . . . . 843.3.3.1 Explanation of the parameters used . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853.3.4 Propagation models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853.3.4.1 One slope model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853.3.4.2 General two slope model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873.3.4.3 Hata – Davidson model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883.3.5 Cell range calculation, balancing UL with DL . . . . . . . . . . . . . . . . . . . . . 883.3.6 Calculation of cell area (site area) and site-to-site distance . . . . . . . . . . 893.3.7 Results of link budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903.3.8 Link budget for common pilot channel signal . . . . . . . . . . . . . . . . . . . . . 903.3.9 Link budget calculation of cells equipped with RRH . . . . . . . . . . . . . . . . 913.3.10 Link budget calculation for six sectors . . . . . . . . . . . . . . . . . . . . . . . . . . 92

DN70118376Issue 04E

5


Id:0900d80580785cde

3.3.11 Link budget calculation for HSDPA - interference limited case . . . . . . . 943.3.12 Link budget calculation for the shared Release 99 and HSDPA carriers 953.3.13 Link budget calculation for load based AMR codec selection feature . . 983.3.14 Link budget calculation for MIMO case . . . . . . . . . . . . . . . . . . . . . . . . . 983.3.15 Link budget calculation for DC HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . 993.4 Traffic dimensioning - macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Introduction to traffic dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . 1003.4.1 Input parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013.4.1.1 General parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013.4.1.2 Network description per area and per phase . . . . . . . . . . . . . . . . . . . . 1013.4.2 Pole capacity pol_capbearer i, UL, pol_capbearer i, DL [kb/s/site]. . . . . . . . . 1043.4.2.1 Basic channels BCbearer CS i, UL/DL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1053.4.3 Dimensioning calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063.4.3.1 Traffic demand per site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063.4.3.2 Required bandwidth and load of individual bearer with GoS consideration

1063.4.3.3 Required bandwidth and load for multiple bearers with GoS considerations

1073.4.3.4 Comparison of loads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1093.4.4 Where and why an optimisation should be performed. . . . . . . . . . . . . 1103.4.4.1 Capacity limited case (very high load) . . . . . . . . . . . . . . . . . . . . . . . . . 1103.4.4.2 Coverage limited case (very low load) . . . . . . . . . . . . . . . . . . . . . . . . . 1103.4.5 HSPA traffic calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1113.4.5.1 RAN1689 CS voice over HSPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133.4.5.2 RAN1643 HSDPA 64QAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1133.4.5.3 RAN1642 MIMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1153.4.5.4 RAN1906 Dual-Cell HSDPA 42Mbps . . . . . . . . . . . . . . . . . . . . . . . . . 1183.4.6 Load-based AMR codec selection feature . . . . . . . . . . . . . . . . . . . . . . 1193.5 Results of the air interface dimensioning . . . . . . . . . . . . . . . . . . . . . . . 1213.5.1 Example results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1213.6 UMTS 900 - collocation scenarios with GSM 900 . . . . . . . . . . . . . . . . 1253.6.1 Network scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1253.6.2 Network scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

4 BTS baseband dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1284.1 Baseband Dimensioning in this release. . . . . . . . . . . . . . . . . . . . . . . . 1284.2 RU20/RU20 On Top feature highlight and HW dependence . . . . . . . . 1294.3 Dimensioning Flexi WCDMA BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1324.3.1 Flexi WCDMA BTS capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354.3.2 Common control channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1364.3.2.1 CCCH requirements for Multimode System Modules . . . . . . . . . . . . . 1374.3.2.2 CCCH requirements for System Module Rel1 . . . . . . . . . . . . . . . . . . . 1384.3.2.3 CCCH resources allocation details . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384.3.2.4 Local cell grouping for Flexi BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1404.3.2.5 Capacity licenses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444.3.3 Dedicated channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444.4 Dimensioning UltraSite WCDMA BTS . . . . . . . . . . . . . . . . . . . . . . . . . 1474.4.1 Local cell grouping for UltraSite BTS . . . . . . . . . . . . . . . . . . . . . . . . . . 149

6 DN70118376Issue 04E


Id:0900d80580785cde

4.4.2 WSPA/C/F processing capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1504.4.3 Dimensioning steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1534.5 HSDPA and BTS dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1574.5.1 Scheduler types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1574.5.2 Tcell grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1614.6 HSUPA and BTS dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634.6.1 HSUPA CE allocation principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644.7 Extended cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1824.8 WCDMA BTS capacity allocation principles . . . . . . . . . . . . . . . . . . . . . 1854.8.1 Capacity allocation principles for Flexi WCDMA BTS. . . . . . . . . . . . . . 1854.8.2 Capacity allocation principles for UltraSite WCDMA BTS. . . . . . . . . . . 1894.8.2.1 Primary/Secondary WAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1894.8.2.2 Master/Slave WAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1904.8.2.3 WSP and WAM allocation within a subrack . . . . . . . . . . . . . . . . . . . . . 1914.8.2.4 Capacity allocation principles for UltraSite WCDMA BTS. . . . . . . . . . . 1924.8.2.5 Common control channel (CCCH) allocation . . . . . . . . . . . . . . . . . . . . 1924.8.2.6 Dedicated channel (DCH) allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . 1954.8.2.7 Recovery actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

5 Dimensioning transport network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

6 Dimensioning interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2046.1 Overview of dimensioning interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 2046.2 Dimensioning Iub interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2056.2.1 Iub VCC configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2056.2.2 Iub VCC configuration dimensioning. . . . . . . . . . . . . . . . . . . . . . . . . . . 2126.2.3 Iub VPC configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2156.2.4 ATM-based Iub dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2166.2.4.1 User traffic demand modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2166.2.4.2 Dedicated Control Channels (DCCH) . . . . . . . . . . . . . . . . . . . . . . . . . . 2186.2.4.3 Common control channels (CCCH) . . . . . . . . . . . . . . . . . . . . . . . . . . . 2196.2.4.4 Connection Admission Control for R99 traffic . . . . . . . . . . . . . . . . . . . . 2196.2.4.5 Iub dimensioning methods for user plane . . . . . . . . . . . . . . . . . . . . . . . 2206.2.4.6 HSPA and Iub dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2246.2.4.7 Calculation of total Iub bandwidth demand . . . . . . . . . . . . . . . . . . . . . . 2276.2.5 IP-based Iub dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2286.2.5.1 IP Connection Admission Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2296.2.5.2 Dimensioning the CAC-guaranteed U-plane RT traffic . . . . . . . . . . . . . 2316.2.5.3 Dimensioning the CAC-guaranteed U-plane NRT traffic . . . . . . . . . . . 2316.2.5.4 Dimensioning the other CAC-guaranteed traffic components. . . . . . . . 2326.2.5.5 Dimensioning the non CAC-guaranteed I/B HSPA traffic . . . . . . . . . . . 2326.2.5.6 Dimensioning synchronization traffic . . . . . . . . . . . . . . . . . . . . . . . . . . 2336.2.5.7 Calculating the Iub IP bandwidth for the CAC-guaranteed traffic

(IP_Route_commited_BW) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2346.2.5.8 Calculating the Iub IP bandwidth for the non CAC-guaranteed traffic

(Shared_BestEffort_IP_Allocation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2346.2.5.9 Calculating the total IP Iub bandwidth (IP_Route_Bandwidth) . . . . . . . 2346.2.5.10 Calculating the total Iub transport capacity . . . . . . . . . . . . . . . . . . . . . . 2356.2.6 IP-based Transport Network Layer configuration . . . . . . . . . . . . . . . . . 236

DN70118376Issue 04E

7


Id:0900d80580785cde

6.2.6.1 IP Iub Protocol Stack and Protocol Overheads . . . . . . . . . . . . . . . . . . 2366.2.6.2 Mapping U-plane, C-plane Transport Bearers to IP/Ethernet Flows . . 2396.2.6.3 IP Transport QoS on Iub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2416.2.7 CS voice over HSPA (RU20 On Top) – transport network impacts . . . 2446.2.7.1 Call Admission Control aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2456.2.7.2 Iub interface dimensioning impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . 2476.2.7.3 Configuration and traffic mapping aspects. . . . . . . . . . . . . . . . . . . . . . 2476.2.8 Hybrid transport and Iub dimensioning . . . . . . . . . . . . . . . . . . . . . . . . 2486.2.9 Iub Transport Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2506.2.9.1 Iub Fallback VCC configuration and dimensioning . . . . . . . . . . . . . . . 2516.2.10 RAN1707: Flexi WCDMA Integrated CESoPSN (RU20 On Top) . . . . 2536.2.10.1 CESoPSN packet format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2546.2.10.2 CESoPSN traffic bandwidth calculation . . . . . . . . . . . . . . . . . . . . . . . . 2556.2.11 RAN1709 VLAN Traffic Differentiation (RU20 On Top) . . . . . . . . . . . . 2586.2.11.1 Traffic processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2606.2.11.2 User plane VLAN mapping options . . . . . . . . . . . . . . . . . . . . . . . . . . . 2626.2.11.3 Feature related parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2626.2.11.4 Dimensioning aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2636.2.11.5 Dimensioning example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2636.2.12 Physical interface capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2646.3 Dimensioning Iur interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2656.3.1 Iur dimensioning method for user plane. . . . . . . . . . . . . . . . . . . . . . . . 2656.3.2 HSPA traffic on Iur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2656.3.3 IP-based Iur Transport Network Layer configuration . . . . . . . . . . . . . . 2666.3.3.1 IP Iur Protocol Stack and Protocol Overheads . . . . . . . . . . . . . . . . . . 2666.3.3.2 Mapping U-plane and C-plane Logical Channels to IP/Ethernet flows 2666.3.3.3 IP Transport QoS on Iur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2666.4 Dimensioning Iu-CS interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2676.4.1 Iu-CS dimensioning method for user plane . . . . . . . . . . . . . . . . . . . . . 2676.4.2 Dimensioning IP-based Iu-CS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2676.5 Dimensioning Iu-PS interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2696.5.1 Iu-PS dimensioning method for user plane . . . . . . . . . . . . . . . . . . . . . 2696.5.2 Iu-PS overhead calculation in ATM transport . . . . . . . . . . . . . . . . . . . 2706.5.3 Dimensioning IP-based Iu-PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2726.6 Dimensioning Iu-BC interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2736.7 Dimensioning signaling traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2746.7.1 Iub signaling links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2746.7.2 Iu/Iur MTP3/M3UA links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2776.8 Dimensioning examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2796.8.1 Parallel connections calculation in Option 1 (ATM) . . . . . . . . . . . . . . . 2796.8.2 IP-based Iub dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

7 Dimensioning RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2867.1 RNC capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2867.2 Dimensioning RNC overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2867.3 Dimensioning based on RNC throughput limitations . . . . . . . . . . . . . . 2877.4 RNC dimensioning based on BTS connectivity limits . . . . . . . . . . . . . 2947.5 RNC dimensioning based on AAL2 connectivity . . . . . . . . . . . . . . . . . 295

8 DN70118376Issue 04E


Id:0900d80580785cde

7.6 Physical interface capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2967.7 RNC software license keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2997.8 BTS load distribution factor (Uneven load factor) . . . . . . . . . . . . . . . . . 3007.8.1 Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3007.8.2 BTS load distribution factor definition . . . . . . . . . . . . . . . . . . . . . . . . . . 301

DN70118376Issue 04E

9


Id:0900d80580785cde

List of FiguresFigure 1 Overview of general planning steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Figure 2 Input data for the generation of the traffic model . . . . . . . . . . . . . . . . . . 25Figure 3 Input data for link budget calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figure 4 Data flow of packet oriented (blue) and the CS (red) applications (y-axis:

data volume over x-axis: time) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figure 5 Overview of the cell planning procedure . . . . . . . . . . . . . . . . . . . . . . . . 28Figure 6 Inference margin versus cell load for the uplink. . . . . . . . . . . . . . . . . . . 29Figure 7 Capacity dimensioning for the different carrier types including the coverage

dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figure 8 Procedure of the fixed network planning for the UTRAN. . . . . . . . . . . . 33Figure 9 Network with site candidates (green dots) and chosen site location . . . 34Figure 10 Node B configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figure 11 Workflow: radio, access and core network planning . . . . . . . . . . . . . . . 36Figure 12 Network dimensioning workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figure 13 Notation of DCH session, RAB session, session in the CN, and PDP con-

text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Figure 14 Steps in traffic modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Figure 15 R99 PS session overview (DL and UL) . . . . . . . . . . . . . . . . . . . . . . . . . 46Figure 16 HSDPA session overview (focus on DL) . . . . . . . . . . . . . . . . . . . . . . . . 47Figure 17 HSxPA session overview (focus on UL E-DCH) . . . . . . . . . . . . . . . . . . 48Figure 18 Speech traffic evolution (2006 – 2011) . . . . . . . . . . . . . . . . . . . . . . . . . 52Figure 19 Cell range vs. area location probability for different bearers (example for

UMTS2000). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Figure 20 Single-cell and multi-cell coverage model . . . . . . . . . . . . . . . . . . . . . . . 75Figure 21 Calculation of the fade margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Figure 22 Radio bearer mapping for HSDPA traffic . . . . . . . . . . . . . . . . . . . . . . . . 80Figure 23 Power split in HSDPA cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Figure 24 Other-to-own cell interference factor . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Figure 25 Hexagonal three-sector site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Figure 26 Cell range and site-to-site distance for hexagonal cells. . . . . . . . . . . . . 89Figure 27 Deformed site (rhomboidal cells) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Figure 28 Cell range and site-to-site distance for rhomboidal cells . . . . . . . . . . . . 90Figure 29 Distributed configuration example of network densification with RRH sites

92Figure 30 Deformed site (rhomboidal cells) of the six-sector site . . . . . . . . . . . . . 92Figure 31 Antenna Diagram of K742219 (45°/ 21.5 dBi) . . . . . . . . . . . . . . . . . . . . 93Figure 32 Three-sector and six-sector network layouts . . . . . . . . . . . . . . . . . . . . . 94Figure 33 Example of maximum HSDPA user data rate evaluation – one transmission

95Figure 34 Exemplary WCDMA BTS power assignment. . . . . . . . . . . . . . . . . . . . . 96Figure 35 Changes in the WCDMA BTS power assignment . . . . . . . . . . . . . . . . . 96Figure 36 GoS handling in the traffic calculation . . . . . . . . . . . . . . . . . . . . . . . . . 108Figure 37 Traffic dimensioning process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Figure 38 Spectrum efficiency (system load) of a mix of HSDPA and Release 99 ser-

vices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Figure 39 Cell throughput of Mix HSUPA and Rel99 services (source: Nokia Siemens

Networks simulation results) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

10 DN70118376Issue 04E


Id:0900d80580785cde

Figure 40 Probability of 64QAM usage in macro and micro cell with 6 UE in the cell. (source: Nokia Siemens Networks simulation) . . . . . . . . . . . . . . . . . . . 114

Figure 41 Average cell throughput (a) and peak UE throughput (b) with respect to the number of users in the cell for Pedestrian A 3km/h, 1RxDiv, PF scheduler, UE Cat 10 capable on 16 QAM, UE Cat 14 capable of 64QAM (source: Nokia Siemens Networks simulation) . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Figure 42 Mean cell throughput gain of MIMO 2x2 (Dual Stream) over SISO in micro cell and macro cells (PF scheduler) . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Figure 43 Minimum penetration of MIMO UEs in micro cell and macro cells for non - Tx diversity cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Figure 44 Mean cell throughput gain and peak UE throughput gain of MIMO 2x2 (Du-al Stream) over SISO in macro cell (PedA3, ISD = 1000m) . . . . . . . . . 116

Figure 45 Probability of usage of Dual and Single Stream transmission . . . . . . . 117Figure 46 Frequency assignment to UMTS and GSM for Network Scenario 1. . . 125Figure 47 900MHz band sharing between WCDMA and GSM in Network Scenario 2.

Planned max. configuration in RU20 On Top and RG10 On Top . . . . . 126Figure 48 Frequency assignment to UMTS and GSM for network scenario 2 . . . 127Figure 49 Flexi WCDMA BTS modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Figure 50 FSMB System Module structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Figure 51 FSMC System Module structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Figure 52 FSMD System Module structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Figure 53 FSME System Module structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Figure 54 Frequency layers mapping to system modules. . . . . . . . . . . . . . . . . . . 139Figure 55 Dual radio module, sector configuration type B . . . . . . . . . . . . . . . . . . 140Figure 56 Example of MORAN case – Flexi FSMB+FSMD . . . . . . . . . . . . . . . . . 142Figure 57 Example of MORAN case – Flexi FSMD+FSMD . . . . . . . . . . . . . . . . . 143Figure 58 Example of MORAN case – Flexi FSMD . . . . . . . . . . . . . . . . . . . . . . . 143Figure 59 Example of CE allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Figure 60 UltraSite WCDMA BTS architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Figure 61 Dual-Cell HSDPA feature and Shared HSDPA scheduler for baseband ef-

ficiency, 3 sector site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Figure 62 Tcell grouping example, 1+1+1: 2 x 36 CE (System Module Rel2) . . . 162Figure 63 Tcell grouping example, 2+2+2: 4 x 36 CE (System Module Rel2) . . . 162Figure 64 FSMB submodule / WSPC card with CCCH and 1st HSUPA resource step

166Figure 65 HSUPA resource steps with CCCH (2nd FSMB submodule/WSPC card). .

167Figure 66 HSUPA resource steps with CCCH (3rd FSMB submodule/WSPC card) . .

168Figure 67 HSUPA resource steps with HSDPA (WSPC card) . . . . . . . . . . . . . . . 169Figure 68 CCCH allocation in Flexi WCDMA BTS in a 2+2+2 configuration . . . . 186Figure 69 CCCH allocation in Flexi WCDMA BTS in a 3+3+3 configuration . . . . 186Figure 70 BTS TCOM RM overall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Figure 71 Primary/Secondary WAMs in a subrack . . . . . . . . . . . . . . . . . . . . . . . . 190Figure 72 WSP and WAM allocation within a subrack . . . . . . . . . . . . . . . . . . . . . 191Figure 73 WSP to WAM allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Figure 74 Common control channel allocation example for 1+1+1 configuration with

two WSPAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Figure 75 Common control channel allocation example for 1+1+1 configuration with

DN70118376Issue 04E

11


Id:0900d80580785cde

two WSPCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Figure 76 Common control channel allocation example for 2+2+2 configuration with

two WSPCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195Figure 77 CCCHs with eight AMR calls in WSPA . . . . . . . . . . . . . . . . . . . . . . . . 197Figure 78 CCHCs with 16 AMR calls in WSPCs . . . . . . . . . . . . . . . . . . . . . . . . . 197Figure 79 CCCH allocation in a mixed WSPA/C case . . . . . . . . . . . . . . . . . . . . . 197Figure 80 Resource allocation until equal amount of free resources . . . . . . . . . . 198Figure 81 Dimensioning transport network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Figure 82 BTS AAL2 multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Figure 83 Iub VCC configuration with path selection and native ATM transport . 209Figure 84 Iub VCC configuration with path selection and hybrid transport . . . . . 209Figure 85 VPC configuration with CBR VCC based user and control plane . . . . 215Figure 86 VPC layer configuration option for RU10 path selection configuration with

CBR/UBR+ VCC based user plane (UBR O&M) . . . . . . . . . . . . . . . . . 216Figure 87 Traffic parameter modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Figure 88 Iub dimensioning, option 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Figure 89 Iub dimensioning, option 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Figure 90 HSDPA protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224Figure 91 HSUPA protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Figure 92 Iub bandwidth demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Figure 93 IP-based Iub dimensioning components . . . . . . . . . . . . . . . . . . . . . . . 229Figure 94 Calculating IP_Route_Bandwidth for DL . . . . . . . . . . . . . . . . . . . . . . . 235Figure 95 U-plane and C-plane protocol stacks on the IP-based Iub . . . . . . . . . 237Figure 96 IP-based Iub Transport flow configuration in DL. VLAN option: 1 VLAN per

logical Iub. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Figure 97 Possible Transport QoS mapping scheme with IP based Iub . . . . . . . 243Figure 98 CS voice over HSPA – impact on the transport network . . . . . . . . . . . 245Figure 99 Protocol stack for hybrid transport over Iub . . . . . . . . . . . . . . . . . . . . . 248Figure 100 Dual Iub configuration for BTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Figure 101 VCC configuration of hybrid Iub with dedicated fallback VCC . . . . . . . 252Figure 102 VCC configuration of hybrid Iub with dedicated and shared fallback VCC

253Figure 103 Basic configuration for RAN1707 feature. . . . . . . . . . . . . . . . . . . . . . . 254Figure 104 CESoPSN protocol stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Figure 105 CESoPSN Control Word field details . . . . . . . . . . . . . . . . . . . . . . . . . 254Figure 106 CESoPSN TDM payload format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Figure 107 Packetization latency and CESoPSN bandwidth . . . . . . . . . . . . . . . . . 257Figure 108 Synchronization options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Figure 109 Basic RAN1709 configuration for L2 backhaul with L3 RNC site router sce-

nario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Figure 110 RAN1709 RNC traffic management. . . . . . . . . . . . . . . . . . . . . . . . . . . 261Figure 111 RAN1709 BTS traffic management . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Figure 112 Iur bandwidth demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Figure 113 Iu-CS dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Figure 114 Classical IP over ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270Figure 115 Approximation curve for Iu-PS overhead factor . . . . . . . . . . . . . . . . . . 271Figure 116 Logical Iub connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285Figure 117 Overview of RNC dimensioning process . . . . . . . . . . . . . . . . . . . . . . . 287

12 DN70118376Issue 04E


Id:0900d80580785cde

Figure 118 Dimensioning RNC (throughput limitations check) . . . . . . . . . . . . . . . . 288Figure 119 AMR Capacity license principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299Figure 120 PS throughput license principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300Figure 121 Even load calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301Figure 122 Uneven load calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302Figure 123 BTS load distribution factor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

DN70118376Issue 04E

13


Id:0900d80580785cde

List of TablesTable 1 Quality of service classes in UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Table 2 Mapping of applications/services into QoS class (examples) . . . . . . . . 41Table 3 Mapping of services to RAB (examples) . . . . . . . . . . . . . . . . . . . . . . . . 42Table 4 Quality requirements for application-to-bearer mapping . . . . . . . . . . . . 44Table 5 Standard traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Table 6 Mapping of Minutes-Of-Use to Traffic Demand (mErl) (Speech) . . . . . 51Table 7 Mapping of Minutes-Of-Use to Traffic Demand (mErl) (Video telephony)

52Table 8 Mapping of overall PS data traffic demand to traffic demand per BH . . 53Table 9 Feature dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Table 10 Examples of Single Radio Access Bearers . . . . . . . . . . . . . . . . . . . . . . 62Table 11 Supported HSDPA RAB combinations (single RABs only) . . . . . . . . . . 63Table 12 UE Capabilities, Source 3GPP (TS 25.306) . . . . . . . . . . . . . . . . . . . . . 65Table 13 E-DCH UE categories (Source 3GPP TS 25.306) . . . . . . . . . . . . . . . . 67Table 14 E-DPDCH slot formats (Source 3GPP TS 25.211) . . . . . . . . . . . . . . . . 67Table 15 Possible environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Table 16 Values of maximum Doppler frequency in [Hz] calculated for different mo-

bile velocities at all available UMTS frequency bands . . . . . . . . . . . . . 73Table 17 Examples of the shadowing margin . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Table 18 Examples of the combined slow fading and penetration loss margin (Urban

clutter; one slope model, antenna height 30m) . . . . . . . . . . . . . . . . . . . 77Table 19 HSDPA MCS exemplary for UE Cat 14 (Source 3GPP TS 25.214) . . . 78Table 20 HS-SCCH and associated DCH (F-DPCH) power per user assignment 80Table 21 Frequency related path loss co-efficients . . . . . . . . . . . . . . . . . . . . . . . 86Table 22 Antenna height related path loss co-efficient . . . . . . . . . . . . . . . . . . . . 86Table 23 Clutter type related path loss co-efficient . . . . . . . . . . . . . . . . . . . . . . . 86Table 24 One slope propagation model example (intercept) . . . . . . . . . . . . . . . . 87Table 25 Two slope propagation model example (slope) . . . . . . . . . . . . . . . . . . 87Table 26 Distance correction factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Table 27 Example of different power assignment scenarios of one cell . . . . . . . 97Table 28 Example of achieved HSDPA max data rate at the cell border and the Re-

lease 99 load for different power assignment scenarios . . . . . . . . . . . 98Table 29 Example of the basic channel calculation for a selection of bearers and ve-

hicular A 50 km/h environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Table 30 Example of HSDPA capacity achieved for different power assignment

scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Table 31 General results summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Table 32 Pole capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Table 33 Traffic per site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Table 34 Air Interface bandwidth per site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Table 35 RU20/RU20 On Top Features and HW dependence . . . . . . . . . . . . . 130Table 36 CCCH CE for FSMB+FSMC/D/E configuration and cell range <10 km 138Table 37 CCCH CE for FSMB+ FSMC/D/E configuration and cell range <10km using

Mapping HSPA cell to HW commissioning parameter . . . . . . . . . . . . 140Table 38 Baseband resources required per one Rel99 traffic channel in RU20 and

RU20 On Top (System Module Rel1) . . . . . . . . . . . . . . . . . . . . . . . . . 144Table 39 Baseband resources required per one Rel99 traffic channel in RU20 (Sys-

14 DN70118376Issue 04E


Id:0900d80580785cde

tem Module Rel2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Table 40 Baseband resources required per one Rel99 traffic channel in RU20 On

Top (System Module Rel2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Table 41 Description of Ultra Site BTS units . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Table 42 Processing capacity of WSPA for users with various data rates . . . . . 150Table 43 Processing capacity of WSPC for users with various data rates . . . . . 150Table 44 Processing capacity of EUBB subrack (1 WSPF) for users of various data

rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Table 45 Processing capacity of EUBB subrack (2 WSPF) for users of various data

rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Table 46 Processing capacity of EUBB subrack (3 WSPF) for users of various data

rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Table 47 Required CE per each active DCH user of the listed bearers . . . . . . . 154Table 48 RU20/RU20 On Top Shared HSDPA scheduler for baseband efficiency .

159Table 49 RU20 On Top Full baseband scheduler . . . . . . . . . . . . . . . . . . . . . . . 159Table 50 RU20 On Top Shared HSDPA Scheduler for baseband efficiency schedul-

er with MIMO feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Table 51 RU20 Full baseband scheduler with MIMO . . . . . . . . . . . . . . . . . . . . . 160Table 52 RU20 On Top Shared HSDPA scheduler for baseband efficiency with Dual-

Cell HSDPA feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Table 53 Associated DCH rates and CE usage . . . . . . . . . . . . . . . . . . . . . . . . . 161Table 54 Max number of HSUPA users per cell/LCG . . . . . . . . . . . . . . . . . . . . . 163Table 55 HSUPA resource steps for System Module Rel1 / WSPC . . . . . . . . . . 165Table 56 HSUPA resource steps with CCCH (1st FSMB submodule/WSPC) . . 165Table 57 HSUPA resource steps with CCCH (2nd/3rd FSMB submodule/WSPC) . .

166Table 58 HSUPA resource steps with HSDPA (WSPC) . . . . . . . . . . . . . . . . . . . 168Table 59 Flexi WCDMA BTS System Module Rel1 and UltraSite WCDMA BTS re-

quired number of HSUPA resource steps . . . . . . . . . . . . . . . . . . . . . . 169Table 60 Flexi WCDMA BTS System Module Rel1 combined minimum baseband L1

throughput of all users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Table 61 UltraSite WCDMA BTS, combined minimum base band L1 throughput of all

users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Table 62 HSUPA resource steps for System Module Rel2 / WSPF . . . . . . . . . . 171Table 63 Flexi WCDMA BTS System Module Rel2/UltraSite WCDMA BTS EUBB

(WSPF) required number of HSUPA resource steps for 10ms TTI UEs (part 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Table 64 Flexi WCDMA BTS System Module Rel2/UltraSite WCDMA BTS EUBB (WSPF) required number of HSUPA resource steps for 10ms TTI UEs (part 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173



Table 67 Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB (WSPF) combined minimum base band L1 throughput of all users for 10ms TTI UEs (part 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

DN70118376Issue 04E

15


Id:0900d80580785cde

Table 68 Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB (WSPF) combined minimum base band L1 throughput of all users for 10ms TTI UEs (part 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Table 69 Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB combined minimum base band L1 throughput of all users for 2ms TTI UEs (part 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Table 70 Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB combined minimum baseband L1 throughput of all users for 2ms TTI UEs (part 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Table 71 Peak throughput for HSUPA Flexi WCDMA BTS System Module Rel1 and UltraSite WCDMA BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Table 72 UE peak throughput for HSUPA Flexi WCDMA BTS System Module Rel2, resource step 1, 3, 5, 7, 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Table 73 Peak throughput for HSUPA Flexi WCDMA BTS System Module Rel2 / Ul-traSite WCDMA BTS EUBB, pair of resource steps 1 and 2, 3 and 4, 5 and 6, 7 and 8, 9 and 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Table 74 UltraSite WBTS CCCH CE for HW release mix case and cell range < 10 km using Mapping HSPA cell to HW commissioning parameter . . . . 193

Table 75 Use of CEs with different data rate calls (WSPA/WSPC) . . . . . . . . . . 196Table 76 RU10 Transport dimensioning relevant features . . . . . . . . . . . . . . . . 204Table 77 RU20 Transport dimensioning relevant features . . . . . . . . . . . . . . . . 204Table 78 Number of VCCs with route selection configuration . . . . . . . . . . . . . . 208Table 79 Number of VCC with path selection configuration and HSUPA . . . . . 210Table 80 RU10 Traffic separation using different VCC types and AAL2 PT

combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210Table 81 VCC labels for VCC selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Table 82 Parameter value selection with path selection and HSUPA . . . . . . . . 214Table 83 Parameter value selection for VP layer . . . . . . . . . . . . . . . . . . . . . . . . 216Table 84 Basic traffic model parameter set for Access dimensioning . . . . . . . . 217Table 85 Common Control Channel reservation . . . . . . . . . . . . . . . . . . . . . . . 219Table 86 HSDPA protocol overheads (RU10, 10% BLER) . . . . . . . . . . . . . . . . 225Table 87 HSDPA protocol overheads (RU20, Flexible RLC, 10% BLER) . . . . . 225Table 88 IP traffic descriptors and Ethernet overheads for U-plane CCH traffic 232Table 89 CAC traffic descriptors and bit rates for selected Release 99 and DCCH-

over-HSPA bearers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Table 90 CAC traffic descriptors and bitrates for selected HSPA flows . . . . . . . 238Table 91 Example of IP Transport QoS mapping on Iub . . . . . . . . . . . . . . . . . . 243Table 92 CS voice over HSPA – ALC parameters . . . . . . . . . . . . . . . . . . . . . . 246Table 93 CS voice over HSPA – IPTD parameters . . . . . . . . . . . . . . . . . . . . . . 246Table 94 CS voice over HSPA – QoS Priority and VCC selection in ATM Transport

247Table 95 CS voice over HSPA – QoS Priority selection in IP Transport . . . . . . 248Table 96 Example calculation for hybrid transport overheads on top of ATM layer

249Table 97 Iub interface types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Table 98 Header length for Iu-PS data (IP over ATM) . . . . . . . . . . . . . . . . . . . . 270Table 99 Iu-CS MTP3/M3UA dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277Table 100 Iu-PS MTP3/M3UA dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277Table 101 Iur MTP3/M3UA dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

16 DN70118376Issue 04E


Id:0900d80580785cde

Table 102 Offered user traffic per BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281Table 103 Offered non-user traffic per BTS (assuming 3 cells per BTS) . . . . . . . 281Table 104 CAC-guaranteed bit rates for different RAB services . . . . . . . . . . . . . 282Table 105 Mapping of UMTS Service Classes to DiffServ PHBs . . . . . . . . . . . . . 282Table 106 Bandwidth demand of real time U-plane traffic . . . . . . . . . . . . . . . . . . 283Table 107 IP bandwidth per service type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284Table 108 Weighted Ethernet overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284Table 109 Frame protocol bit rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289Table 110 Standard traffic model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Table 111 Network traffic summation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Table 112 Performance limitations for NPS1 and NPGE in various scenarios . . . 297Table 113 BTS busy hour load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303Table 114 Area busy hour load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

DN70118376Issue 04E

17

Dimensioning WCDMA RAN Summary of changes

Id:0900d80580785caa

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

Note that issue numbering system is changing. For more information, see Guide to WCDMA RAN operating documentation.

Changes between issues 04D (2010-04-20, WCDMA RAN RU20) and 04E (2010-06-11, WCDMA RAN RU20)

Introduction (3.1)

– Section RAN1881 RF Chaining has been removed.– RF Chaining has been removed from Table 9 Feature dependencies.– Section RAN2159 Flexi 1-sector RF Module 2100 has been removed.

Link budget calculation, macro (3.3)

– Section Link Budget Calculation for RF Chaining has been removed.

RU20/RU20 On Top feature highlight and HW dependence (4.2)

– Section RAN1881 RF Chaining (RU20 On Top) has been removed.– RAN1881 RF Chaining has been removed from Table 35 RU20/RU20 On Top

Features and HW dependence.

Dimensioning Flexi WCDMA BTS (4.3)

– Release2 Single RF Module (70W - FRGR – supporting one sector) has been removed.

HSDPA and BTS dimensioning (4.5)

– Table RU20 Shared HSDPA scheduler for baseband efficiency maximum through-put per TTI has been removed.

– Table RU20 On Top Shared HSDPA Scheduler for BaseBand Efficiency maximum throughput per TTI has been removed.

– Table RU20 On Top Full baseband scheduler maximum throughput per TTI has been removed.

– Table RU20 On Top Shared HSDPA scheduler for baseband efficiency scheduler with MIMO, maximum throughput per TTI has been removed.

– Table RU20 On Top Shared HSDPA scheduler for baseband efficiency scheduler with Dual-Cell HSDPA, maximum throughput per TTI has been removed.

– Table RU20 On Top Full baseband scheduler with MIMO, maximum throughput per TTI has been removed.

– 16QAM or 64QAM modulation instead of 64QAM modulation only are available for Shared HSDPA scheduler for baseband efficiency and Flexi System Module Rel2 (FSMC/D/E).

Dimensioning RNC (7)

– Values used in example of calculating number of subscribers (user traffic profile point of view) have been updated in Rule example.

Changes between issues 04C and 04DThe following chapters have been updated:

18 DN70118376Issue 04E


Id:0900d80580785caa

Summary of changes

– 3 Dimensioning air interface– 3.1 Introduction

The section has been reorganized. New section 3.1.1 RU20 On Top highlights has been added.RU20 On Top features have been added to Table 9 Feature dependencies.

– 3.2 Common input– 3.2.1.2 HSDPA bearers

UE categories 21-24 have been added to the content and to Table 12 UE Capabilities, Source 3GPP (TS 25.306).

– 3.2.1.3 HSUPA bearers and UE categoriesInformation on RAB combinations which can be configured with Dual-Cell HSDPA 42Mbps feature has been added.Notes on RAS06, UMR6.5, and UMR7.0 have been removed.

– 3.3 Link budget calculation, macro– 3.3.1 Link Budget Formula (Maximum Allowable Path Loss) R99 bearers

Explanation of PNB_per_user [dBm] and Mfastfading [dB] have been extended.

– 3.3.2 Link Budget Formula (Maximum Allowable Path Loss) HSDPASection HSDPA bearers has been reedited and renamed to HSDPA modu-lation and coding schemes.MIMO (w/o F-DPCH) and DC-HSDPA have been added to Table 20 HS-SCCH and associated DCH (F-DPCH) power per user assignment.Information on increased overhead in DC HSDPA case has been added to MHS-DPCCH – HS-DPCCH Overhead[dB].Mfastfading – fast fading margin [dB] has been updated.

– 3.3.4 Propagation modelsThe UMTS 1500 band has been added to Table 24 One slope propagation model example (intercept) and Table 25 Two slope propagation model example (slope).

– 3.3.9 Link budget calculation of cells equipped with RRHSection has been reedited, Figure 29 Distributed configuration example of network densification with RRH sites has been updated.

– New section 3.3.15 Link budget calculation for DC HSDPA has been added.– New section 1.16 Link Budget Calculation for RF Chaining has been added.

– 3.4 Traffic dimensioning - macro– Grade of service (GoS) criteria

Note on HSDPA services being always considered as best effort services in UMR and RAS06 has been removed.

– 3.4.5.1 RAN1689 CS voice over HSPASection has been reedited.

– New section 3.4.5.4 RAN1906 Dual-Cell HSDPA 42Mbps has been added.– 3.6 UMTS 900 - collocation scenarios with GSM 900

Information on using 900 Mhz band for UMTS has been updated.– 3.6.2 Network scenario 2

The whole section has been updated, Figure 47 900MHz band sharing between WCDMA and GSM in Network Scenario 2. Planned max. configu-ration in RU20 On Top and RG10 On Top has been added. Figure 48 Frequency assignment to UMTS and GSM for network scenario 2 has been updated.

DN70118376Issue 04E

19


Id:0900d80580785caa

– 4 BTS baseband dimensioning– New section 4.2 RU20/RU20 On Top feature highlight and HW dependence

based on removed RU20 feature highlight and HW dependence has been added. The content has been expanded with RU20 On Top features. RAN1906 Dual-Cell HSDPA 42Mbps and RAN1881 RF Chaining have been added to Table 35 RU20/RU20 On Top Features and HW dependence.

– 4.3 Dimensioning Flexi WCDMA BTS– 4.3.1 Flexi WCDMA BTS capacity

The FRGR has been added to the list of available RF modules.– 4.3.2 Common control channels

Figure 55 Dual radio module, sector configuration type B has been added to 4.3.2.4 Local cell grouping for Flexi BTS.Content of 4.3.2.4 Local cell grouping for Flexi BTS has been reedited, example of a site with three carriers (3+3+3) has been added.

– 4.3.3 Dedicated channelsNew Table 40 Baseband resources required per one Rel99 traffic channel in RU20 On Top (System Module Rel2) has been added.New section Asymmetric UL/DL CE Allocation has been added.

– 4.4 Dimensioning UltraSite WCDMA BTS– 4.4.2 WSPA/C/F processing capacity

Numbers of active users (UL/DL) for Interactive/Background traffic class have been updated in:Table 44 Processing capacity of EUBB subrack (1 WSPF) for users of various data rates,Table 45 Processing capacity of EUBB subrack (2 WSPF) for users of various data rates, andTable 46 Processing capacity of EUBB subrack (3 WSPF) for users of various data rates.

– 4.4.3 Dimensioning stepsNumber of UL/DL CE for PS256 and PS384 has been changed in Table 47 Required CE per each active DCH user of the listed bearers.

– 4.5 HSDPA and BTS dimensioning– 4.5.1 Scheduler types

Information that in RU20 On Top release HSDPA 16 Users per Cell is not available with System Module Rel2 has been added to HSDPA 16 users per cell.Description of MIMO and Dual-Cell HSDPA usage with Shared HSDPA Scheduler for BaseBand Efficiency in RU20 On Top has been added to Shared HSDPA scheduler for baseband efficiency. Figure 61 Dual-Cell HSDPA feature and Shared HSDPA scheduler for baseband efficiency, 3 sector site has been added.Table 3 RU20 On Top Shared HSDPA Scheduler for BaseBand Efficiency maximum throughput per TTI has been added.Information that MIMO users can be simultaneously served in one TTI with HSDPA legacy users has been added to Full baseband.Table 4 RU20 On Top Full baseband scheduler has been added.New paragraph MIMO feature containing Table 50 RU20 On Top Shared HSDPA Scheduler for baseband efficiency scheduler with MIMO feature, Table 6 RU20 On Top Shared HSDPA scheduler for baseband efficiency scheduler with MIMO, maximum throughput per TTI, Table 51 RU20 Full

20 DN70118376Issue 04E


Id:0900d80580785caa

Summary of changes

baseband scheduler with MIMO, and Table 8 RU20 On Top Full baseband scheduler with MIMO, maximum throughput per TTI has been added.New paragraph Dual-Cell HSDPA feature containing Table 52 RU20 On Top Shared HSDPA scheduler for baseband efficiency with Dual-Cell HSDPA feature and Table 10 RU20 On Top Shared HSDPA scheduler for baseband efficiency scheduler with Dual-Cell HSDPA, maximum throughput per TTI has been added.Table 53 Associated DCH rates and CE usage has been updated to RU20 On Top level.

– 4.5.2 Tcell groupingInformation on Dual-Cell HSDPA has been added.

– 4.6 HSUPA and BTS dimensioningInformation on maximum number of supported users and schedulers has been updated.Information on mapping HSPA frequencies to different system modules/sub-racks has been added.– 4.6.1 HSUPA CE allocation principles

Information on locating resource steps has been updated in HSUPA resource allocation System Module Rel1 / WSPC.Information that in RU20 one WSPF card can be used for HSUPA (per LCG) has been removed.Column 2xSF4 + 2xSF2 has been updated in Table 72 UE peak throughput for HSUPA Flexi WCDMA BTS System Module Rel2, resource step 1, 3, 5, 7, 9.

– 4.7 Extended cell– Extended cell in Flexi WCDMA BTS

Information on required CEs in case of Flexi System Module Rel2 UL/DL and relevant example have been added.No additional HSUPA resource steps needed. Note on unusual cases has been removed.

– Extended cell in UltraSite WCDMA BTSInformation on required CEs in case of Flexi System Module Rel2 UL/DL and relevant example have been removed.No additional HSUPA resource steps needed in unusual cases. Note on unusual cases has been removed.

– 4.8 WCDMA BTS capacity allocation principles– 4.8.1 Capacity allocation principles for Flexi WCDMA BTS

HSDPA 16 Users per cell has been removed from HSDPA allocation prin-ciples for System Module Rel2. Priorities for submodule selection have been updated.

– 4.8.2 Capacity allocation principles for UltraSite WCDMA BTSHSDPA 16 Users per Cell has been removed from HSDPA allocation details for EUBB subrack (WSPF). Priorities for WSPF card selection in case of “Shared HSDPA Scheduler for Baseband Efficiency” or “Full Baseband” have been updated.

– 6 Dimensioning interfaces– 6.1 Overview of dimensioning interfaces

RAN1231: HSPA over Iur has been added to Table 77 RU20 Transport dimen-sioning relevant features.

– 6.2 Dimensioning Iub interface

DN70118376Issue 04E

21


Id:0900d80580785caa

– 6.2.4.6 HSPA and Iub dimensioningAir interface rate 42.2 (DC-HSDPA/64QAM) has been added to Table 87 HSDPA protocol overheads (RU20, Flexible RLC, 10% BLER).

– 6.2.6.1 IP Iub Protocol Stack and Protocol OverheadsTable 89 CAC traffic descriptors and bit rates for selected Release 99 and DCCH-over-HSPA bearers has replaced Table IP traffic descriptors and Ethernet overheads for Release 99 and DCCH over HSPA traffic.Table 90 CAC traffic descriptors and bitrates for selected HSPA flows has replaced Table IP traffic descriptors and Ethernet overheads for CAC-guar-anteed HSPA traffic.

– 6.2.9.1 Iub Fallback VCC configuration and dimensioningInformation on traffic classes selection has been edited. Requirement of using AAL2 Fallback VCC attribute has been added. Dual Iub scenario has been added.

– New section 6.2.10 RAN1707: Flexi WCDMA Integrated CESoPSN (RU20 On Top) has been added.

– New section 6.2.11 RAN1709 VLAN Traffic Differentiation (RU20 On Top) has been added.

– 6.3 Dimensioning Iur interfaceSection 6.3.2 HSPA traffic on Iur has been added.

– 6.7.2 Iu/Iur MTP3/M3UA linksThe whole section has been updated.

– 7 Dimensioning RNC– 7.1 RNC capacity

Number of needed CDSP-DH units has been updated– 7.2 Dimensioning RNC overview

Key input requirements have been updated. Figure 117 Overview of RNC dimensioning process has been updated.

– 7.3 Dimensioning based on RNC throughput limitationsFigure 118 Dimensioning RNC (throughput limitations check) has been updated.4. Uplink dimensioning, 5. HSPA dimensioning, and 6. Verify the number of sub-scribers per RNC using the formula: calculation principles have been updated.Description of calculating the maximum RNC net throughputs calculation has been added.Information on checking maximum RNC level user amounts limited by L2 call resources and formula for calculating HSDPA RAB ratio have been added to Calculating RNC throughput based on Traffic Mix rule.Rule example has been updated and now contain example values based on

assumption on SHO of 40%. BHCA value for PS Rel99 has been updated in Table 110 Standard traffic model.

22 DN70118376Issue 04E


Id:0900d80580785caa

Summary of changes

– 7.6 Physical interface capacityNumber of ATM objects supported per NPS1(P) has been updated.Information on NPGE throughput has been updated.Three typical configurations for defining BHCA capacity per NPDS1 and NPGE have been added to Call processing capacity.Table 112 Performance limitations for NPS1 and NPGE in various scenarios has been added.Number of possible connected BTSs has been updated in NPS1/NPGE units call processing load in Iub.

Changes between issues 04B and 04CThe following chapters have been updated:

– 4 BTS baseband dimensioning– 4.6 HSUPA and BTS dimensioning

Column “0” has been updated in Table Flexi WCDMA BTS System Module Rel2/UltraSite WCDMA BTS EUBB (WSPF) required number of HSUPA resource steps for 2ms TTI UEs (part 1).

DN70118376Issue 04E

23

Dimensioning WCDMA RAN General network planning aspects

Id:0900d80580681ee7

1 General network planning aspects

1.1 IntroductionTypically the network planning procedure can be divided into two major parts:

• UTRAN planning • Core Network planning

The planning process for the UTRAN comprises mainly two major parts. The first one, dimensioning, is the deriving of a nominal cell plan with the corresponding fixed network, all based on a few standard hardware configurations. The second one has to come up with a final network deployment plan and configuration.

In General network dimensioning, the UTRAN dimensioning steps are briefly described.

24 DN70118376Issue 04E


Id:0900d805806487d3

1.2 General network dimensioningThe general overall planning process for WCDMA networks is shown in figure Overview of general planning steps.

Figure 1 Overview of general planning steps

The required input is the base for the development of the cell plan that is mainly driven by radio aspects. The fixed network plan is based on the cell plan, the relevant input data, and the object to derive a cost optimised topology plan. The following sections provide a short overview of the necessary sub-procedures:

• Required input data • Radio network - cell planning

Input Data Cell PlanFixed NetworkPlan - UTRAN

Final NetworkUTRAN

DN70118376Issue 04E

25


Id:0900d805806487f9

1.3 Required input dataThe design and dimensioning of 3G networks depend significantly on the offered traffic and its mix. Besides the voice application, the main applications of 3G networks require high data rate bearers with symmetric and asymmetric data flow.

The grade of service required for all these services has to be considered during the coverage and capacity planning phase.

1.3.1 Traffic model and capacity requirementsIn 3G mobile networks, a mixed of different traffic types and user profiles have to be taken into account. Because of the close relation between offered traffic and its profile and the provided coverage via the interference situation, an exact knowledge of the expected traffic is mandatory for any accurate planning. Therefore the traffic modeling is a sensitive activity.

The sketch in Input data for the generation of the traffic model gives a rough overview on required information for the modeling of the traffic.

Figure 2 Input data for the generation of the traffic model

Two main traffic types can be identified. The traffic flow characteristic is defined by the application and this can be divided basically into Circuit Switched (CS) data flow such as voice and video conferencing and Packet Switched (PS) data flow such as www and browsing. The CS traffic shows a Poisson process like shape whereas the PS traffic shows a bursty traffic flow nature (Data flow of packet oriented (blue) and the CS (red) applications). The blue curve shows a typical data application such as web browsing which could be transmitted over an HSXPA channel and has a very bursty nature with high peaks. The red trace shows the traffic flow for a Poisson process like voice which could be transmitted on a Release 99 channel and is in comparison to the PS data curve much more smother over the time.

Additionally to the traffic mixture, the amount of traffic per subscriber, number of sub-scribers and its traffic evolution is important information. Based on this the HW configu-ration of the sites and the interfaces is done and the necessary SW licenses are calculated.

1.3.2 Coverage requirementsThe figure Input data for link budget calculation presents an overview of all input param-eter necessary for the evaluation of the cell range.

Input Data

- bearer type- BHCA- call duration- mean data rate- peak data rate

Traffic Model

26 DN70118376Issue 04E


Id:0900d805806487f9

Figure 3 Input data for link budget calculation

Because of the close interconnection of the interference situation, bearer type and cell coverage, the required coverage for the different data rates including the one for the required HSXPA throughput is mandatory for the cell range evaluation.

The provision of certain coverage for a certain data rate is measured in terms of location probability at the cell edge or in the cell area. The value of the derived shadowing margin depends also on the standard deviation assumed for the considered clutter type.

User speed and environment (channel profile) determines the required Eb/No value for the considered bearer.

Body loss and penetration loss are taken into account for margin to be considered because of the location of the subscriber (outdoor or indoor) and type of UE and its appli-cation.

The clutter type determines the selection of an appropriate propagation model.

The cell range is strongly related to the cell load via an interference margin, which has to be derived according to the assumed cell load. Hence the cell coverage estimation is closely related with the capacity estimation via the cell load and interference situation in the network.

Cell Range

Cell Load

Input Data

- bearer type- user speed- environment- clutter type- penetration margin- location probability- body loss

DN70118376Issue 04E

27


Id:0900d805806487f9

Figure 4 Data flow of packet oriented (blue) and the CS (red) applications (y-axis: data volume over x-axis: time)

1.3.3 Quality requirementsThe quality requirements for the network comprise firstly the coverage requirements (already mentioned) and the quality of service aspects. There are four main QoS classes described in the 3GPP standard – conversational, streaming, interactive, and back-ground.

Currently the network design and dimensioning are mainly based on the best effort approach for the PS applications and on the commonly known blocking requirement for the CS applications.

28 DN70118376Issue 04E


Id:0900d805806487bf

1.4 Radio network - cell planningThe cell planning procedure depends on four major input data or dimensioning condi-tions:

• offered traffic and its distribution • link budget • maximum air interface capacity • Node B hardware configuration

The flow chart shows the cell planning procedure.

Figure 5 Overview of the cell planning procedure

The cell dimensioning for the WCDMA technology requires the knowledge of a reliable traffic model and distribution in the service area, because the cell range of an WCDMA cell is mainly interference-limited and the provided cell capacity is also interference limited. If the cell load increases, the cell range shrinks – well known under cell breath-ing. The cell coverage and the cell capacity are interconnected via the cell load. The cell load in percent is defined as the ratio of the currently carried traffic in kbps and the pole capacity in kbps of the cell.

Traffic Modeland Distribution

Cell Coverage

Cell Load

Cell Capacity

Initial CellPlan and

Configuration

Input Data

- # subscriber- bearer type- BHCH- call duration- mean data rate- peak data rate

Input Data

- Eb/No (UEmobility, environment,cell type)

- antenna configuration- interference situation

Input Data

- traffic model- UE mobility- environment- cell type- interferencesituation

Site / NodeBConfiguration

- antenna conf.- # sectors- # carriers andtype

- # channel cards- # licences- power setting

Link Budget

Spectrum Efficiency

DN70118376Issue 04E

29


Id:0900d805806487bf

The cell capacity can be estimated with an analytical formula or the spectrum efficiency that is derived out of system level simulation. The cell capacity is different for the differ-ent bearer types, cell types, UE mobility, environments (radio channel profile) and inter-ference situations that are based on the cell layout and therefore the cell coverage.

The cell coverage can be estimated based on the antenna configuration, Node B output power, UE output power, required Eb/No, and interference situation.

1.4.1 Cell coverageThe cell coverage is calculated with an appropriate propagation model from the maximum allowed path loss. The path loss consists of two parts – the system path loss and the path loss because of the coverage requirements.

The system path loss is basically the difference of the minimum receiving level at the UE respectively at the Node B receiver and the transmitting power (EIRP) at the corre-sponding nodes. The EIRP comprises already the antenna gains and feeder/combiner losses. The minimum receiving level takes into account the thermal noise, the carrier bandwidth, the bearer data rate, noise figure of the receivers, the required Eb/No values (derived from link level simulations), interference situation (cell load), diversity gains, and correction margins (caused by the considered environment). The cell load results in an additional noise rise/interference margin in the system. In figure Inference margin versus cell load for the uplink, the interference margin versus cell load is shown for the uplink.

Figure 6 Inference margin versus cell load for the uplink

The coverage requirements are considered by a shadowing margin and penetration loss. The required location probability (cell area or edge) and the assumed standard deviation of the slow fading define the shadowing margin. The clutter type of the service area defines the penetration margin.

The propagation model depends on the clutter type and the cell chosen cell type to be planed. Typically three major cell types are assumed – macro cells, micro cells, and pico cells. The macro cell is characterized by an antenna height of more than 3m above the average building height in the surrounding area. The micro cell is deployed in street canyons and the antenna height is about 3m to 6m and therefore significantly lowers than the roof top height. The pico cell is deployed in the building and provides mainly indoor coverage.

30 DN70118376Issue 04E


Id:0900d805806487bf

Additionally, the coverage is mainly influenced via the receiver sensitivity of the Node B and the UE as well as the required bearer types (DCH and HSPA) and its data rate at the cell border.

1.4.2 Cell capacityThe cell capacity estimation is based on the traffic model, the traffic amount and its dis-tribution, the cell range, and the spectrum efficiency.

A reliable traffic model and traffic distribution in the service area is the most important prerequisite for the calculation of the offered traffic for the corresponding area. WCDMA provides a soft capacity that is closely related to the traffic type or mixture, user profile or distribution, and interference situation in the radio cells.

The cell range is limited by the network noise and interference. The interference situa-tion is considered via an interference margin depending on the cell load for the Release 99 traffic and on the calculation of received power for HSPA traffic. The actual cell load is the ratio of absolute carried traffic in the cell and the pole capacity. The absolute cell traffic is calculated out of the cell coverage and the traffic distribution. The pole capacity can be estimated with an analytical formula or out of system level simulations results. It can be increased by different feature (that is load based AMR codec selection).

At a given traffic distribution (kbps/sqkm), the offered traffic for the system and cell can be derived. Typically, the cell coverage is estimated for a predefined cell load of about 50%...60%. With these two values the actual cell load can be derived. If the two values – predefined cell load and actual calculated cell load – differ significantly, a balancing of load versus cell range can be considered. This approach may be applicable for low traffic density areas where the predicted traffic (because of marketing studies) does not achieve such a value that loads the cell with 50% within the mid term of the network rollout.

If the actual cell load is higher than the specified maximum allowed cell load, additional radio carriers, sectors or features have to be introduced. The number of carriers and its types (shared carrier for DCH or HSDPA and/or dedicated carrier for HSxPA or DCH) have to be decided.

If no additional measures are available and the traffic is still too large or has grown over the phases, cell splitting or the introduction of new coverage layers like micro cells or pico cells has to be considered.

DN70118376Issue 04E

31


Id:0900d805806487bf

Figure 7 Capacity dimensioning for the different carrier types including the coverage dimensioning

The site configuration (sectors and carriers) should be done in the most cost efficient way for the total network. So it can be worthwhile to have a larger configuration for each site (more costs per site), but to have with this a higher coverage and a lower number of sites so that the total costs are minimized.

Additionalcapacity Node Bs

HSDPA capacitydimensioning

UL DPCHcapacity

Dimensioning

HSUPAcapacity

dimensioning

Resultevaluation

Input:availablecapacity

Input: capacityfor HSUPA

Output:HSUPAthroughput

Not OK

OK

Output:HSDPA

throughput

Input:availablecapacity

Coverage dimensioning Capacity dimensioning

Additionalcapacity Node Bs

Resultevaluation

Output:HSUPAthroughput

Not OK

OK

Output:HSDPAthrough-put

Coverage dimensioning Capacity dimensioning

Input:availableHSUPAcapacity

Input: availableHSDPA capacity

Input: available HSDPA capacity

R99 capacitydimensioning

UL/DL Load,Node B DL power

Coverage dimensioningselection:- Link Budget R99(based on service)- Link Budget HSDPA(based on cell edgethroughput)- Link Budget HSUPA(based on cell edgethroughput)Output # of coveragesites

Dimensioning inputs and requirements

Dimensioning inputs and requirements

UL DPCHcapacity

Dimensioning

HSUPAcapacity

dimensioning

Air interface dimensioning, shared carrier DCH + HSPA

Air interface dimensioning, dedicated carrier HSPA

# ofNode Bs

(coverage +capacity)

# ofNode Bs

(coverage +capacity)

Coverage dimensioningselection:- Link Budget UL R99(based on HSDPAassociated UL DPCHservice)- Link Budget HSDPA(based on cell edgethroughput)- Link Budget HSUPA(based on cell edgethroughput)Output # of coveragesites

32 DN70118376Issue 04E


Id:0900d805806487bf

1.4.3 Node B hardware and software aspectsNode B hardware aspects comprise the possible hardware configuration in terms of available channel cards or system modules and channel elements for signaling and user traffic. The evaluation of the necessary channel elements is based on the number of simultaneous users and the used bearer types under consideration of required Grade of Service (GoS) and Quality of Service (QoS).

Additionally, the knowledge of simultaneous users and the used bearers allows the cal-culation of the output power of the Node B per traffic channel. The maximum provided output power of different RF modules has to fit into the cell range for certain traffic models and interference situations. Also the number of carriers and sectors has to fit into the chosen system, RF modules, and antenna configuration.

Partly the hardware capacity can be licensed (that is, CEs for signaling in extra large cells). Software features (that is, increase of the air interface) capacity can also be licensed.

DN70118376Issue 04E

33


Id:0900d805806487cf

1.5 Fixed network – UTRA network plan

1.5.1 Overview of fixed networkThe planning of the fixed network for the UTRAN requires a procedure shown in figure Procedure of the fixed network planning for the UTRAN.

Figure 8 Procedure of the fixed network planning for the UTRAN

The fixed network planning procedure requires knowledge of the cell plan and the con-figuration of the Node Bs and the traffic model as input. Additionally, the possible topology aspects such as star, chain, hub, and leased line or microwave aspects have to be considered.

Based on this data, the required Iub and Iur capacity for the individual links can be cal-culated. According to the hardware aspects of the Node B and RNC related to the fixed network, a final plan for UTRA network can be derived.

1.5.2 Traffic modelThe basic information about the traffic model is described in Traffic model and capacity requirements in Required input data.

1.5.3 Initial cell plan and configurationThe initial cell plan is derived from the radio network dimensioning procedure as described in Radio Network - cell planning. There are possibilities for the description of the initial cell plan.

• Node B locations without geographic information (coordinates)If there is no geographic information, the network is only described by the number of required Node B and its configuration per clutter type. This homogeneous cell layout approach delivers a mean site-to-site distance of the Node B. This information can be used for dimensioning of the fixed network for the UTRAN via a mean link length between the network elements.

Traffic Modeland Distribution

Initial Cell Planand Configuration

Topology Aspects

NodeB and RNCConfiguration

Initial FixedNetwork Plan

Required lub capacity

SHO

Required lur capacity

34 DN70118376Issue 04E


Id:0900d805806487cf

Figure 9 Network with site candidates (green dots) and chosen site location

• Node B locations with geographic informationIf geographic information is available, the network can be described by the number of Node Bs, its configuration, and location. Typically this cell layout represents an inhomogeneous network structure. The link length can be determined by the site location information. This procedure has to be supported by an appropriate tooling.

1.5.4 Topology aspectsThe topology aspects determine the network structure that finally shows the links between the different network elements.

The following configurations are possible:

• Star configuration • Hub configuration • Loop configuration • Cascade configuration

Figure 10 Node B configurations

The chosen configuration depends on several aspects such as redundancy, link costs, link availability, and optimisation aspects.

nodeB RNC

nodeB

nodeB

Star configuration

nodeB nodeB

nodeB

nodeB

RNC

Hub configuration

nodeB RNC

nodeB

nodeB

Loop configuration

nodeB RNC

nodeB

nodeB

Cascade configuration

DN70118376Issue 04E

35


Id:0900d805806487cf

Combinations of the above configurations are possible with certain hardware limits, for instance, maximum chain length and capacity limits such as traffic constraints and maximum number of interface connections.

1.5.5 Hardware aspects – WCDMA BTS and RNCEach network element has certain capacity limitations in accordance with their hardware configuration. For each type of WCDMA BTS (Flexi, Ultra Site), the number of supported interfaces, the possibility of applying CES or fractional ATM in case of co-location with a GSM BTS and the possible network configurations (chain, cascade, hub, and loop) is given. These and other parameters limit the feasible network configurations available for network planning.

Similar parameter constraints are valid for RNC. Besides upper bounds for CS and PS traffic limits for the number of interfaces and constraints, the interface configurations are also applied. These constraints strongly depend on the RNC configuration.

36 DN70118376Issue 04E


Id:0900d80580681eeb

Traffic modeling

2 Traffic modeling

2.1 IntroductionTraffic modeling is the first step in network dimensioning. Figure Workflow: radio, access and core network planning illustrates typical WCDMA radio and access network dimen-sioning.

Figure 11 Workflow: radio, access and core network planning

In chapter Traffic modeling, modeling of the traffic demand per subscriber is described.

A subscriber is an average mobile network subscriber who is using, during the busy hour, with a specified intensity, all described services , such as voice telephony, video telephony, and other packet data services. This includes also the possible use of differ-ent types of user equipment (UE), such as handsets and data cards as well as Release 99, Release 5, and Release 6 compliant UE.

In the scope of WCDMA radio (and) access network dimensioning, the overall workflow looks as described in Figure Network dimensioning workflow.

Radio network planning Access network planning

Core network planning

- Air interface dimensioning

- Channel card dimensioning

- RNC dimensioning

- UTRAN interface dimensioning

align

Tra

ffic

model

DN70118376Issue 04E

37

Dimensioning WCDMA RAN Traffic modeling

Id:0900d80580681eeb

Figure 12 Network dimensioning workflow

Although traffic modeling is here included in the radio network dimensioning, it has a direct impact on the access and transport network dimensioning.

2.1.1 UMTS QoS classesWhen RAB is being setup, the core network (CN) provides to RNC bearer attributes like: Traffic QoS class, Maximum bit rate, Guaranteed bit rate, Residual BER, Transfer delay and so on.

There are four different QoS classes defined for UMTS [TS 23.107]:

• conversational class • streaming class • interactive class • background class

RNC Dimensioning

lu InterfaceDimensioning

lur InterfaceDimensioning

Network Topology Subscribers Basic Traffic Model

Air InterfaceDimensioning

BTS Dimensioning

lub InterfaceDimensioning

Core networkdimensioning

Radio network dimensioning

Access network dimensioning

38 DN70118376Issue 04E


Id:0900d80580681eeb

Traffic modeling

The main distinguishing factor between these QoS classes is how delay sensitive the traffic is.

The classical split of QoS classes between CS domain and PS domain is no longer valid. Streaming services may be mapped either to CS Streaming or PS Streaming. With the introduction of the Conversational PS services, the Conversational QoS class also applies to the PS domain. Interactive and Background are typically PS traffic. Real-time traffic (PS Conversational and PS Streaming) is usually served using UDP, whereas non-real-time traffic (PS Interactive or Background) is usually transmitted using TCP. However, also UDP traffic can be served using a PS Interactive or Background service depending on the application mapped to the respective PS Interactive or Background RAB.

2.1.2 QoS parameters for traffic modelingImportant QoS parameters for traffic modeling in the scope of UTRAN are:

• Radio access bearer rate (peak rate, maximum bit rate, and information rate)In UTRAN, the radio access bearer (RAB) defines the maximum data rate (maximum bit rate attribute allocated during RAB setup) accessible for each connec-tion. In ideal situations, where no transmission errors occur, this data rate can be achieved. This rate is denoted as the information rate for CS services and as the peak rate for PS services.

• Mean rateThis term is mainly used for PS services. It denotes the mean data rate averaged over the session (or RAB life), taking into account possible inactive periods where there is no data transmission.

Traffic class Conversational class (Conversational RT)

Streaming class (Streaming RT)

Interactive class (Inter-active best effort)

Background (Back-ground best effort)

Fundamental characteristics

Preserving time relation (variation) between infor-mation entities of the stream

Conversational pattern (stringent and low delay)

Symmetric traffic

Maximum time variation determined by human perception of video and audio conversation.

Preserving time relation (variation) between infor-mation entities of the stream

No stringent require-ments on low delay

One-way data transport

Delay variation (jitter) possible to be compen-sated by buffering or caching performed by the application or user equipment (thus accept-able variation is greater than the one determined by the limits of human perception).

Request- response pattern

Preserving payload content

End entity expects the message (response) within a certain time.

Round trip delay is one of the key attributes.

End user sends and receives data files in the background.

Destination does not expect the data within a certain time (delivery time insensitive).

Network resources utilized when available

Preserving pay-load content

Example of the application

Speech and video con-ferencing

Streaming video and audio

Web browsing, data base retrieval, and server access

Background download of e-mails and databases

Table 1 Quality of service classes in UMTS

DN70118376Issue 04E

39

Dimensioning WCDMA RAN Traffic modeling

Id:0900d80580681eeb

• Traffic demand per subscriberThe traffic demand per subscriber is often given as mean throughput per subscriber in the busy hour, typically in [bps] or as traffic volume per busy hour, in [bits] or [Bytes].

• Blocking probabilityThe blocking probability defines the probability of a non-successful setup of a RAB because of non-availability of resources. It is mainly used for CS services. It occurs because of insufficient resources on the respective links (for example air interface, Iub interface) or/and in UTRAN and core network elements (for example RNC, MSC). The end-to-end blocking is influenced by all the factors introduced by certain sections of the network. PS services are assumed to be always accepted – however with reduced data rate in terms of lack of resources.

• Delay (in terms of a time offset to the perfect transmission time)A delay requirement is defined for PS services. This delay denotes the time offset in data transmission, taking into account the RAB rate and the packet or file sizes to be transmitted. Overall end-to-end delay includes the propagation delay on the links, processing delay within network elements (UTRAN and CN), and buffering delay because of insufficient resources on the respective links.

• RAB life and sessionIt is distinguished between RAB life and DCH session in UTRAN (denoted by RAB session) and the session in the core network. A session in SGSN and GGSN refers to “attach” and “primary/secondary” PDP context. In addition, sessions are distin-guished for each application. Note that there may be an interrupt in RAB sessions because of time-outs. During the RAB Life (continuously, if RAB is mapped on R99 RT radio bearer or discontinuously if NRT R99), the user might have dedicated resources or shares common resources (for example, traffic inactivity of NRT R99).

Figure 13 Notation of DCH session, RAB session, session in the CN, and PDP context

40 DN70118376Issue 04E


Id:0900d80580648805

2.2 Traffic modeling stepsFor the purpose of network dimensioning, the following steps in traffic modelling and radio bearer selection apply:

1. Definition of deployment scenario (area and clutter), subscriber mix, and number of subscribers

2. Identification of services and applications to be offered3. Mapping of applications to domains (CS and PS)4. Mapping of applications to QoS classes, that is Conversational, Streaming, Interac-

tive or Background5. Mapping of applications to radio (access) bearers6. Definition of QoS or GoS targets, for example, blocking, delay, or throughput7. Assumptions on traffic characteristics (BHCA, call or session duration, and call or

session activity)8. Assumption on the number of subscribers per application, identification of traffic

demand per application, and radio (access) bearer9. Calculation of traffic demand10. Forecast of traffic evolution over time (if different phases are to be planned)11. Adaptation of assumptions, if needed

Figure 14 Steps in traffic modeling

2.2.1 Mapping of services and applications to QoS classesAn appropriate bearer for these applications has to be chosen in accordance with the demanded peak rate of these applications.

A more detailed mapping of applications into QoS classes is given in Table Mapping of applications/services into QoS class (examples).

Deployment environment:area & clutters#subscribers

Definition of applicationsoffered/used

in the scenario

Mapping of applications toCS/PS domain

Mapping of applications toQoS classes

Mapping of applications toRABs

Definition of QoS/GoStargets

Estimation of BHCA andsession activations in BH

Assumption on thenumber of subscribers

per application

Calculation of trafficdemand

Traffic evolution over timeestimated growth rates

Adaptation of assumptions

a b c

d e f

g h i

j k

DN70118376Issue 04E

41


Id:0900d80580648805

Service Traffic Class Service Traffic Class

Multi-media Services Security

Video streaming Streaming Camera surveillance of rooms

Streaming

Picture transmission Interactive Stolen vehicle tracking Interactive

Video telephony Conversational Detection of burglary Interactive

Video conference Conversational Emergency alarm notifica-tion

Conversational

Music on demand Streaming Household device control Interactive

E-postcard Background

Information Services Public Information

Search engines Interactive Elections/voting Interactive

Online translation Interactive Yellow Pages Interactive

Booking and reservation news

Interactive Help and guidance Interactive

E-mail Background Property information Interactive

Push and pull services (stock price)

Interactive Leisure

Financial information analysis

Interactive Horse racing betting Interactive

E-Commerce Mark Six Interactive

Online Bank transaction Interactive Jokes Interactive

Micropayments Interactive Chatroom Interactive

Online stock trading Interactive Real-time Interactive game

Conversational

Online shopping Interactive Intra/Internet

Download ringing tones Background Access to Internet Interactive / Background

Online Auction Interactive Access to Intranet Interactive / Background

Online ticketing Interactive Access to Extranet Interactive / Background

Advertising Background Mobile Office

Telematic Scheduler Background

Fleet Management Interactive

Location based tracking Interactive

Information on traffic con-ditions

Interactive

Remote surveillance Interactive

Table 2 Mapping of applications/services into QoS class (examples)

42 DN70118376Issue 04E


Id:0900d80580648805

2.2.2 Mapping of services to radio access bearers (RAB)Table Mapping of services to RAB (examples) describes the bearers with their typical applications. The figure in the bearer name represents the data rate.

Note that for voice telephony additional RAB services are available, such as NB-AMR 5.9 and WB-AMR services, as well as the feature Load Based AMR Codec Mode Selec-tion in RU10. AMR codec type selections should be done on the basis of the require-ments.

For Release 5, UE accessing a PS service, HSDPA service apply in DL and a corre-sponding Release 99 DCH is used in UL.

For Release 6, UE accessing a PS service, HSDPA service apply in DL and HSUPA service in UL.

Dispatcher service Interactive

Service Traffic Class Service Traffic Class

Table 2 Mapping of applications/services into QoS class (examples) (Cont.)

Applications Domain Traffic Class RAB (UL/DL)

Speech CS Conversational CS AMR 12.2/12.2 or HSPA1)

1) Note that from RU20 onward, the voice call with conversational traffic class might be mapped to HSPA radio bearer. This requires mobile device support-ing CS voice over HSPA (CSoHS). For more information on CSoHS see RAN1689: CS voice over HSPA feature description.

Speech (VoIP) PS Interactive / Background or Streaming

R99/HSDPA or HSxPA

Video telephony CS Conversational CS UDI 64/64

Remote Modem Access

CS Streaming CS Streaming 57.6/57.6

Audio Streaming / Music on demand

PS Streaming PS S 16/64 + PS I/B 8/8

Mobile TV PS Streaming PS S 16/128 + PS I/B 8/8

PS Interactive / Background PS I/B 64/128

Web Browsing PS Interactive / Background PS I/B 64/384 or 128/384 or mapping to HSxPA

File Download PS Interactive / Background PS I/B 64/384 or 128/384 or mapping to HSxPA

Email PS Interactive / Background PS I/B 64/384 or 128/384 or mapping to HSxPA

Online ticketing PS Interactive PS I/B 64/64

Table 3 Mapping of services to RAB (examples)

DN70118376Issue 04E

43


Id:0900d80580648805

2.2.2.1 Support of streaming QoS for HSPA (RU10)RU10 release brings in a support of streaming QoS class RABs on HSPA. In general, streaming RAB is originated by the PS domain, and the corresponding streaming radio bearer is created by RAN. The feature enables streaming class mapping on DCH/HS-DSCH and E-DCH/HS-DSCH RBs.

Introduced streaming HSPA class is characterized by the following:

• prioritisation performed by RNC, on the basis of allocation retention priority (ARP) received from CN,

• support of guaranteed bit rate (GBR), which influences admission of new user (admission may fail, if the GBR cannot be provided to the user) and determines scheduling in BTS,

• new streaming user is able to occupy resources from HSPA NRT or DCH NRT users,

• support of nominal bit rate (NBR) for NRT services mapped to HS transport chan-nels, defined as a targeted minimum bitrate.

2.2.2.2 I-HSPA and VoIP aspectsFor the needs of traffic modeling, the following I-HSPA facts are relevant:

Speech services

• VoIP is the only speech service in I-HSPA. • It is mapped to one of the available PS/HS bearers. • Traffic generated by speech services and the split into CS and VoIP depends on the

availability of VoIP capable UEs and network capabilities (for example, I-HSPA or “normal” UMTS network) to treat speech service either as former CS or as VoIP.

• In I-HSPA Release 1, it is recommended that speech calls are treated as CS and redirected to WCDMA/GSM network.

Data services

• In I-HSPA Release 1, it is assumed that whole HSDPA (DCH/HS-DSCH) and HSPA (E-DCH/HS-DSCH) traffic is handled by I-HSPA.

• In I-HSPA Release 2, because of resource sharing, HSPA traffic is split among WCDMA and I-HSPA architecture.

It is expected that I-HSPA network in Release 1 and 2 is always accompanied by the underlying traditional WCDMA network, as I-HSPA is realized by the additional adapter to Flexi BTS.

Note that speech service via VoIP might be also realized by traditional 3G networks. It is recommended then to be mapped to HS bearers using Streaming QoS for HSPA feature to guarantee a certain level of QoS.

2.2.2.3 Support of CS voice over HSPA - CSoHS (RU20)CSoHS, introduced in RU20, is a UTRAN feature enabling mapping of voice conversa-tional class on E-DCH/HS-DSCH RB. It is seen as efficient alternative to VoIP.

For traffic modeling, the following aspects are meaningful:

– Voice calls terminated or initiated by non CSoHS capable UE are setup on DCH bearer.

44 DN70118376Issue 04E


Id:0900d80580648805

– Voice calls terminated or initiated by CSoHS capable UE in non CSoHS capable cell are setup on DCH bearer.

– Voice calls terminated or initiated by CSoHS capable UE in CSoHS capable cell can be setup on HSPA bearer in UTRAN. The CS core network domain serves the call, unlike in VoIP which involves PS domain.

Thus, CSoHS traffic is considered as subset of assumed conversational voice traffic, with share depending on penetration of CSoHS capable terminals (3GPP Rel8 compat-ible) and percentage of subscribers covered by cells supporting CSoHS.

2.2.3 Definition of quality of service (QoS) and grade of service targets (GoS)QoS and GoS targets can be defined as follows:

Application QoS class RAB 3GPP delay requirement

GOS target

blocking delay

Speech Conversational CS AMR 12.2 ~ 80 ms 2.0% N. A.

Speech VoIP Interactive/

background

Streaming

HSUPA / HSDPA

PS16 / HSDPA

PS64 / HSDPA

PS16 / HSDPA

PS64 / HSDPA

HSUPA / HSDPA

< 150ms N. A.

2.0%

0.5 s

N. A.

Video Telephony Conversational CS UDI 64 ~ 80 ms 5.0% N. A.

Remote Modem Access Streaming CS Streaming 57.6 250 ms 5.0% N. A.

Music on demand Streaming PS Streaming 16/64 + PS I/B 8/8 ~ 250 ms 5.0% N. A.

Mobile TV Streaming PS Streaming 16/128 + PS I/B 8/8 ~ 250 ms 5.0% N. A.

Access to the Internet / web browsing

Interactive Release 99:

PS 32/64, …, PS 128/384

Release 5:

UL PS 32/0, …, PS 384/0

DL HS-DSCH

Release 6:

UL: E-DCH

DL: HS-DSCH

N. A. N. A. 5 s

Online ticketingMobile TV

Interactive N. A. N. A. 3 s

Location-based service Interactive N.A. N. A. 3 s

Email Background N. A. N. A. 5 s

File Download Background N. A. N. A. 5 s

Online Gaming Conversational PS Conversational16/16 + PS I/B 8/8

~ 80 ms 5.0% N. A.

Table 4 Quality requirements for application-to-bearer mapping

DN70118376Issue 04E

45


Id:0900d80580648805

2.2.4 Traffic demand calculation

2.2.4.1 Speech, video telephony, and PS RT servicesSpeech, voice telephony, and PS RT services are characterized by:

• Busy-hour-call-attempts (BHCA) [ ] • Call duration [s] • Bearer rate (Information rate) [kbit/s] • Activity (DCH-activity) [ ]

The traffic demand is calculated using these formulas:

Note that for voice services the DCH activity depends on the interface in the UTRAN to be considered. Typical assumptions on the activity on the air interface are 0.5 (optimis-tic) – 0.67 (conservative).

Note that for PS RT services served by a multi-RAB the traffic demand for the supporting PS interactive/background RAB needs to be additionally calculated.

2.2.4.2 PS data services (Release 99)Relevant parameters for calculating the traffic demand for PS I/B R99 services are:

• Busy-hour-call-attempts (BHCA) [ ] • DCH (session) duration [s] • Bearer rate (Information rate) [kbit/s] • Activity (DCH-activity) [ ]

The traffic demand is calculated using these formulas:

Note that one DCH session per BHCA without channel type switching is assumed. In case of channel type switching, the DCH session is interrupted. All parts of the DCH session can be added to a single DCH duration.

Channel type switching is included in the signaling traffic demand by the number of CTS events assumed per (PS) subscriber.

Throughput[kbps] =Traffic_Volume[kb]

3600s

Traffic_Demand[mErl] =no_subscribers * BHCA * Call_Duration * 1000

3600

Traffic_Volume[kb] = no_subscribers * BHCA * DCH_Duration * Bearer_Rate * DCH_activity


3600s

Traffic_Demand[mErl] =no_subscribers * BHCA * DCH_Duration * 1000

3600

46 DN70118376Issue 04E


Id:0900d80580648805

Figure 15 R99 PS session overview (DL and UL)

For more information regarding relevant signaling procedures (in particular Channel Type Switching, Bit Rate Adaptation, and Soft or Softer Handover), see Dimensioning signaling traffic in Dimensioning interfaces.

2.2.4.3 PS data services (Release 5)Relevant parameters for calculating the traffic demand for PS I/B Release 5 - HSDPA services are:

• Busy-hour-call-attempts (BHCA)] • HS-DSCH (session) duration [s] • HS-DSCH nominal peak rate [kbit/s] • HS-DSCH activity [ ]

The UL traffic demand is calculated as described in the previous section for R99 DCH sessions. The DL traffic demand is calculated using these formulas:

The parameters above are alternatively expressed by:

FACH * SHO in DLDL

datarate

DL bearer (peak) rate

DL mean rate duringDCH session

DL mean rateover RAB life

DCHDCH

t

RACH * SHO in ULUL

datarate UL bearer (peak) rate

UL mean rate duringDCH session

UL mean rateover RAB life

DCHDCH

ttime to switch fromDCH to FACH

DCH session duration (excl. RACH/FACH periods)

RAB life duration (incl. RACH/FACH periods)

Traffic_Volume[kb] =no_subscribers * BHCA * HS_DSCH_Duration * Nominal_Peak_Rate * HS_DSCH_activity


3600s

Traffic_Demand[mErl] =no_subscribers * BHCA * HS_DSCH_Duration * 1000

3600

MeanThroughputPerUser_during_HS_DSCH_session[kbps] = Nominal_Peak_Rate * HS_DSCH_activity

DN70118376Issue 04E

47


Id:0900d80580648805

Note that one HS-DSCH session per BHCA without channel type switching is assumed. In case of channel type switching, the HS-DSCH session is interrupted. All parts of the HS-DSCH session can be added up to a single HS-DSCH duration.


Figure 16 HSDPA session overview (focus on DL)

For more information regarding relevant signaling procedures (in particular HS Channel Type Switching), see Dimensioning signaling traffic in Dimensioning interfaces.

2.2.4.4 PS data services (Release 6)Relevant parameters for calculating the traffic demand for PS I/B Release 6 - HSPA services are:

• Busy-hour-call-attempts (BHCA) • E-DCH (session) duration [s] • E-DCH nominal peak rate [kbit/s] • E-DCH activity [ ]

The DL traffic demand is calculated in the same way as for Release 5 HS-DSCH ses-sions. The UL traffic demand calculates as follows:

The parameters are alternatively expressed by:

FACH

* SHO in UL

DL

datarate HS-DSCH (nominal) peak rate

mean rate duringHS-DSCH session

mean rateover RAB life

HS-DSCHHS-DSCH

t

time to switch fromHS-DSCH to FACH

HS-DSCH session duration (excl. RACH/FACH periods)


RACHUL DCHDCH

Traffic_Volume[kb] =no_subscribers * BHCA * E_DCH_Duration * Nominal_Peak_Rate * E_DCH_activity


3600s

Traffic_Demand[mErl] =no_subscribers * BHCA * E_DCH_Duration * 1000

3600

MeanThroughputPerUser_during_E_DCH_session[kbps] = Nominal_Peak_Rate * E_DCH_activity

48 DN70118376Issue 04E


Id:0900d80580648805

Note that one E-DCH session per BHCA without channel type switching is assumed. In case of channel type switching, the E-DCH session is interrupted. All parts of the E-DCH session can be added to a single E-DCH duration.


Note that because the HS-DSCH duration and E-DCH duration are identical, UL E-DCH is always accompanied by DL HS-DSCH.

Figure 17 HSxPA session overview (focus on UL E-DCH)

For more information on relevant signaling procedures (in particular HS Channel Type Switching and HSUPA Soft/Softer Handover), see Dimensioning signaling traffic in Dimensioning interfaces.

FACHDL HS-DCHHS-DCH

RACH * SHO in UUL

datarate E-DCH (nominal) peak rate

mean rate duringE-DCH session

mean rateover RAB life

E-DCHE-DCH

ttime to switch fromHS-DSCH/E-DCH to FACH

HS-DSCH/E-DCH session duration (excl. RACH/FACH periods)


DN70118376Issue 04E

49


Id:0900d80580648801

2.3 Standard traffic modelThe purpose of a standard traffic model is to have information about the traffic demand available if no detailed traffic model is provided for network dimensioning.

Standard traffic model is defined assuming a “standard” subscriber, using all accounted services in parallel – the service split is applied on the traffic demand basis (no split on the subscriber basis).

Selected default services are:

• Speech with 0.6 BHCA and a traffic demand of 24.5 mErlang per subscriber in the busy hour, which corresponds to call duration of 147 s, mapped to CS Cenversa-tional AMR 12.2 and CS voice over HSPA.

• Video telephony mapped to CS Conversational UDI 64 with 0.05 BHCA and a traffic demand of 3.2 mErlang per subscriber in the busy hour, which corresponds to call duration of 230s.

• Data services mapped to PS Interactive/Background RAB services, differentiated between R99 and HSxPA with 0.34 BHCA, and a traffic demand (in DL) of: 1430 bps per subscriber in the busy hour. This traffic demand is split into: • R99 traffic demand per subscriber: 480 bps • HSxPA traffic demand per subscriber: 950 bps

These are applicable assumptions:

• BHCA split between R99 – HSxPA (Release 5/6) of 60% : 40% • BHCA split between Release 5 UE and Release 6 UE of 25% : 15% • asymmetry:

• overall (UL:DL): 1:4.54 • R99 (UL:DL): 1:5.1 • HSDPA Release 5 (UL R99 : DL HSDPA): 1:4.3 • HSxPA Release 6 (UL HSUPA : DL HSDPA): 1:4.3

BHCA Traffic demand per subs. in BH

Split

Speech (AMR Voice, CSoHS, …) 0.60 24.5 mErl

CS (UDI Video) 0.05 3.2 mErl

PS traffic demand

Downlink BHCA Throughput per subs. in BH

PS - Rel. 99 0.34 480 bps 60%

PS - HSDPA 950 bps 40%

PS – Rel.99 (UL) / HSDPA (DL) 594 bps 25%

PS – HSUPA (UL) / HSDPA (DL) 356 bps 15%

PS - Rel.99+HSDPA 1430 bps 100%

Uplink BHCA Throughput per subs. in BH

Table 5 Standard traffic model

50 DN70118376Issue 04E


Id:0900d80580648801

PS - Rel. 99 0.34 233 bps 85%

PS - Rel. 99 (UL) / Rel. 99 (DL) 95 bps 60%

PS – Rel. 99 (UL) / HSDPA (DL) 138 bps 25%

PS – HSUPA (UL) / HSDPA (DL) 82 bps 15%

PS - Rel.99+HSxPA 315 bps 100%

BHCA Traffic demand per subs. in BH

Split

Table 5 Standard traffic model (Cont.)

DN70118376Issue 04E

51


Id:0900d805805d8ea8

2.4 UMTS traffic evolutionIn this section the current view on the evolution of traffic demand for a set of identified key applications in UMTS is summarised. These key applications considered in the traffic model are:

• Speech service • Video telephony • SMS • Data services such as web browsing, email, or file download

Basis for this evolution is marketing forecasts for the traffic demand evolution for Western Europe.

2.4.1 Speech serviceFor speech service, an average call duration, which is usually exponentially distributed, is assumed for each active user. This average call duration depends on different factors, for example, country-specific factors.

Table Mapping of Minutes-Of-Use to Traffic Demand (mErl) (Speech) contains mapping of traffic demand in terms of minutes of use (MoU) to Erlang per subscriber and corre-sponding call duration for three different scenarios: high, medium, and low traffic. For the high traffic scenario, 22 days per months and a busy hour concentration ratio of 15% of the daily traffic is assumed. For the medium scenario, 30 days per month and a busy hour concentration ratio of 15%, whereas for the low scenario - ratio of 10%.

Traffic demand per subscriber is calculated using the formula:

Note: The busy hour concentration ratio defines fraction of subscriber daily traffic demand which is observed during busy hour.

2008 2009 2010 2011

Minutes of use per Subscriber/Month

(min) 241.2 269.2 293.6 313.5

Erlang per sub-scriber

High (mErl)

27.41 30.60 33.37 35.62

Medium (mErl)

20.10 22.44 24.47 26.12

Low (mErl)

13.40 14.96 16.31 17.41

Table 6 Mapping of Minutes-Of-Use to Traffic Demand (mErl) (Speech)

Traffic_demand mErl[ ] Minutes_of_use_per_SubscriberMonth BH_concentration_ratio×---------------------------------------------------------------------------------------- 60 1000×

Days 3600×----------------------------------×=

52 DN70118376Issue 04E


Id:0900d805805d8ea8

Figure 18 Speech traffic evolution (2006 – 2011)

2.4.2 Video telephonyFor the mapping of minutes of use per month to Erlang per subscriber, 22 days per month and a busy hour concentration ratio of 15% of the daily traffic is assumed.

2.4.3 SMSFor SMS, it is assumed that the usage in GERAN and UTRAN is the same, that is the SMS BHCA value, the split between CS, PS domain, and the average SMS size is equal in both domains.

The number of SMS events per subscriber is assumed to be constant at a level of 0.3 events per subscriber in the busy hour for each domain.

Traffic model parameters for SMS are:

BHCA per subscriber:

• CS: 0.3 • PS: 0.3

Average size: 65 bytes

Split: Originating / Terminating SMS: 25% : 75%

2.4.4 Data servicesFor estimation of the evolution of traffic demand for data services, expected demand for data services is accumulated and split among 2G and 3G.

Table Mapping of overall PS data traffic demand to traffic demand per BH shows the average traffic demand based on global figures for Western Europe. For single network

40,00

35,00

30,00

25,00

20,00

15,00

10,00

5,00

0,002006 2007 2008 2009 2010 2011

High traffic customer

Medium traffic customer

Low traffic customer

year

mE

rl

2008 2009 2010 2011

Minutes of use per Sub-scriber/Month

(min) 24.8 26.6 28.5 30.5

Erlang per sub-scriber

(mErl) 2.82 3.02 3.24 3.47

Table 7 Mapping of Minutes-Of-Use to Traffic Demand (mErl) (Video telephony)

DN70118376Issue 04E

53


Id:0900d805805d8ea8

element configuration, higher values can be taken into consideration because of statis-tical and spatial variations of traffic demand.

The mapping of cumulated monthly 3G data traffic demand to subscriber demand is provided for different scenarios: high, medium, and low traffic scenario. Assumptions regarding number of service days per month or busy hour concentration ratio are same as used for speech service

Year Overall traffic demand (GB per month)

Traffic demand 3G (GB per month)

(Attached) Subscribers 3G

Traffic demand in (bps per subscriber in BH)

High Medium Low

2008 5 170 077 3 877 558 74 649 419 787.02 577.15 384.77

2009 11 376 509 9 328 738 110 786 482 1275.83 935.61 623.74

2010 21 065 712 19 169 798 148 592 121 1954.69 1433.44 955.63

2011 34 081 471 32 718 212 183 598 063 2700.09 1980.06 1320.04

Table 8 Mapping of overall PS data traffic demand to traffic demand per BH

54 DN70118376Issue 04E


Id:0900d8058078744e

Dimensioning air interface

3 Dimensioning air interface

3.1 IntroductionAir interface dimensioning contains the dimensioning methods and parameters used to calculate dimensioning for the Flexi product line. This information applies to the RU20 and RU20 On Top releases.

For an introduction to the dimensioning process, see the General network planning aspects chapter.

3.1.1 RU20 On Top highlights

3.1.1.1 RAN1906 Dual-Cell HSDPA 42MbpsThe goal of the Dual Cell (DC) HSDPA 42Mbps feature is to increase the average user throughput in HSDPA DL by pooling the shared channels of two cells.

The DL transmit block predestined for a UE within a single TTI is split across two cells adjacent in frequency and pertaining to the same sector and frequency band. One cell is configured as the primary/anchor HS serving cell, and the other is set up as secondary serving HS cell (SSHSC). The primary serving HS cell provides UE with:

– HS-DSCH/SCCH and E-DCH (HSDPA + HSUPA) – Fractional DPCH (RAN1201 requirement)– full/legacy set of control and grant channels,

while only HS-DSCH/SCCH with common control and grant channels are set up in the SSHSC to maximize the UEs HS-DSCH throughput. Both DC HSDPA serving cells adapt Tcell time shift to ensure simultaneous reception at the UE within a single TTI.

The UE categories that have the DC HSDPA feature capability are introduced in Rel8 (categories 21-24, 16QAM-64QAM modulations, 5/6-1 code rates, 23.4-42.2 Mbps peak rates).

The split of UE data takes place within the MAC-ehs layer from:

– RAN1638 Flexible RLC (DL),

where it is scheduled by

– RAN1034 Shared HSDPA Scheduler for Baseband Efficiency

on HS-DSCH/SCCH channels of the primary serving HS cell and SSHSC. The HS-DSCH/SCCH in both cells are associated separate HARQ entities, while the CQI and ACK/NACK reporting is done for both cells via the common HS-DPCCH of the primary serving HS cell according to a MIMO-similar coding and mapping scheme. This enforces a code redundancy loss and thus a required power overhead for HS-DPCCH in primary serving HS cell relative to legacy CQI and legacy ACK/NACK reporting.

For a single UE, the average DL throughput gain relative to legacy HSDPA is a result of the possibility of statistical multiplexing and frequency selective scheduling of UE data on two carriers. On the sector level, the DC HSDPA feature provides sector DL through-put increase because of multi-user diversity within the two jointly scheduled cells. The nominal UE throughput is doubled with DC HSDPA, while the average/real throughput gain from the feature is highly dependent on cell loads (the higher cell load, the lower throughput) and frequency correlation within the band (the higher correlation, the lower

DN70118376Issue 04E

55

Dimensioning WCDMA RAN Dimensioning air interface

Id:0900d8058078744e

throughput). The DL coverage gain for DC HSDPA UEs is proportional to the provided UE throughput gain, but in the case of coexistence with non-DC HSDPA UEs the latter ones represent the limiting factor in terms of radio network planning and dimensioning. As the UL under the DC HSDPA feature carries a slight HS-DPCCH overhead related to legacy HSUPA, a slight decrease in UE throughput and sector UL throughput is per-ceivable. Correspondingly, the UL coverage of DC HSDPA UEs diminishes slightly com-paring to legacy HSDPA UEs.

3.1.1.2 RAN1689 CS Voice over HSPAThe aim of this feature is to increase number of speech subscribers served per cell simultaneously and to reduce UE battery consumption.

Battery consumption reduction comes from using the continuous packet connectivity (CPC) feature as part of CS Voice over HSPA. The CPC feature introduces discontinu-ous uplink DPCCH transmission and discontinuous downlink reception with HSPA. CPC has also such sub-features as:

– DPCCH Gating (UL DTX)– CQI Reporting reduction

By using discontinuous uplink DPCCH transmission and discontinuous downlink recep-tion, battery life time can be increased up to 50% for Voice over HSPA, and even more for web browsing.

CS voice over HSPA introduces the possibility of using shared HSPA transport channels for carrying AMR voice frames instead of dedicated R99 DCH transport channels. Com-paring to VoIP, this feature does not need the robust header compression algorithm (RoHC), and it does not contain IP header overhead. CS Voice over HSPA is activated only for full HSPA configuration (SRB carried on HS-DSCH in DL and E-DCH in UL). From planning point of view, CS Voice over HSPA is treated as HSPA service with a fixed data rate. Data rate depends on the AMR codec and TTI used. Using CS Voice over HSPA implies capacity gain comparing to Voice over DCH.

3.1.1.3 RAN2046 Flexi 3-sector RF Module 850The new Flexi Multiradio RF Module provides new RF capabilities in the traditional GSM bands. GSM, WCDMA, and LTE operations are SW defined.

The Flexi Multiradio RF Module HW supports GSM, WCDMA and LTE in dedicated or concurrent mode. The Flexi Multiradio RF Module design includes 3 x 70W Multi Carrier Power Amplifiers (MCPAs). The Maximum capacity of one Flexi Multiradio RF Module sector for GSM/EDGE is up to 6 TRXs, for WCDMA up to 3 carriers and up to 15 MHZ LTE carrier.

RAN2046 Flexi 3-sector RF module 850 supports up to 60W per carrier.

3.1.1.4 RAN1768 Flexi 3-sector RF Module 900The new Flexi Multiradio RF Module (FXDA) provides new RF capabilities in the tradi-tional GSM bands. GSM, WCDMA and LTE operations are SW defined.

The Flexi Multiradio RF Module HW supports GSM, WCDMA, and LTE in dedicated or concurrent mode. The Flexi Multiradio RF Module design includes 3 x 70W Multi Carrier Power Amplifiers (MCPAs). The maximum capacity of one Flexi Multiradio RF Module

56 DN70118376Issue 04E


Id:0900d8058078744e


sector for GSM/EDGE is up to 6 TRXs, for WCDMA up to 3 carriers and up to 15 MHZ LTE carrier.

RAN1768 Flexi 3-sector RF module 900 supports up to 60W per carrier.

3.1.1.5 RAN1871 Flexi 3-sector RF Module 1.7/2.1The Flexi Multiradio RF Module HW supports WCDMA and LTE in dedicated or concur-rent mode. The Flexi Multiradio RF Module design includes 3 x 70W Multi Carrier Power Amplifiers (MCPAs). The maximum capacity of one Flexi Multiradio RF Module for WCDMA 1.7/2.1 GHz is up to 4 carriers and up to 20 MHZ LTE carrier.

RAN1871 Flexi 3-sector RF module 1.7/2.1 supports up to 60W per carrier.

3.1.1.6 RAN2062 Flexi 3-sector RF Module 2100The Flexi Multiradio RF Module HW supports WCDMA and LTE in dedicated or concur-rent mode. The Flexi Multiradio RF Module design includes 3 x 70W Multi Carrier Power Amplifiers (MCPAs). The maximum capacity of one Flexi Multiradio RF Module for WCDMA 2100 MHz is up to 4 carriers and up to 20 MHZ LTE carrier.

RAN2062 Flexi 3-sector RF module 2100 supports up to 60 W per carrier.

3.1.2 RU20 highlights

3.1.2.1 RAN1643 HSDPA 64QAMThis feature introduces the possibility of using modulation of higher order. Using the 64 QAM, 6 bits can be sent per one symbol. This applies to the maximal UE throughput that can be achieved. Theoretically, for perfect radio conditions, throughput up to 21.1 Mbps per user is possible at the physical layer. Higher throughputs can be achieved by the users closer to the BTS. This is not possible at the cell edge.

3.1.2.2 RAN981 and RAN 1470 HSUPA 5.8 Mbps and HSUPA 2 ms TTIThis feature increases the HSUPA Data Rate. This feature requires the 2ms TTI HSUPA feature activation. Using 2ms TTI and 2*SF2 + 2*SF4 codes, it is possible to achieve up to 5.8 Mbps for ideal radio conditions.

3.1.2.3 RAN1202 24 kbps Paging ChannelThis feature is introduced to reduce congestion in RAN when the number of subscribers and call attempts is increasing. It is achieved by increasing Data Rate of Paging Channel to 24 kbps. When the 24kbps Paging Channel is activated, it is mapped on a dedicated SCCPCH. Previously it was mapped together with FACH on one SCCPCH. At least 2 SCCPCH must be configured for this feature. Depending on operator's needs, it is possible to switch between 8 and 24 kbps Paging Channel Data Rate. From the planning point of view, it is important to note that enabling 24 kbps PCH increases the power needed for signaling at the BTS since a second SCCPCH is needed.

DN70118376Issue 04E

57


Id:0900d8058078744e

3.1.2.4 RAN1201 Fractional DPCHFractional DPCH introduces new DL channel type that carries power control information for HSDPA users. The information is time multiplexed, therefore up to 10 users can be served using one code with SF 256. DL and UL SRBs are mapped on HS-DSCH and E-DCH (2 and 10 ms TTI users). F-DPCH requires UE Category Rel7 and HW Flexi Module Rel2 or EUBB. F-DPCH is required by CS voice over HSPA. It also reduces power needed in BTS per one HSDPA user.

3.1.2.5 RAN 1870 Flexi 3-sector RF Module 1500This feature introduces support for new UTRA FDD frequency band (Japan) with Flexi Triple Module. WCDMA 1500 (band XI) is standardized by 3GPP in Rel8.

3.1.2.6 RAN1642 MIMOMIMO enables instantaneously higher data rates (on both sides: UE and cell) and greater robustness against fading in time varying channels. The maximum theoretical UE peak throughput that can be achieved by incorporating MIMO is 28 Mbps per single user. Before operators benefit from introducing MIMO in their networks, certain invest-ments are required in terms of:

– Second antenna at BTS and MIMO capable UEs since MIMO uses concept of multiple antennas at BTS and UE sides

– Additional (second) CPICH channel per cell that is necessary for MIMO capable UEs to estimate the air interface channel quality

– Higher overhead for HS-DPCCH since more ACK/NACKs and Precoder Control information have to be send

Enabling of MIMO in the network raises always a question how to configure a cell for non-MIMO UEs.

There are the following possibilities:

– Transmit diversity cellThis solution requires implementation of STTD (space time Tx diversity - open loop) and CLM1 (closed loop mode1 Tx diversity) at BTS side and support at UE. Also non - MIMO UEs benefit from reception of the second transmit chain. The same CPICH coverage as in non - MIMO cells (2W per CPICH per cell) can be assured in MIMO cells with for example 1W per CPICH per transmit antenna (non - MIMO UEs combine CPICH power received from both transmit antennas). CLM1 becomes not applicable for higher speeds of UE because of unreliable feedback (that is, antenna beam forming weights are not available or are outdated) and poor channel estima-tion, therefore UE fallback to STTD might be required.

– Non - transmit diversity cellThis solution is the simplest one since any transmit diversity scheme is required neither at BTS side nor at UE. Depending on UE capability, non -MIMO UEs can use SISO (single antenna transmission and reception) or Rx Div mode (single antenna transmission and receive diversity reception). In this case, only MIMO UEs benefit from the second transmit chain and use the second CPICH (additional 1-2 W pilot) which is the source of additional interference for non - MIMO UEs. The other drawback is that certain minimum number of MIMO users is required to compensate the increased power overhead (see RAN1642 MIMO).

58 DN70118376Issue 04E


Id:0900d8058078744e


Although Tx diversity should be mandatory supported at Rel99 UEs, there are major concerns that many UEs available on the market are not 3GPP compliant. Therefore, the most probable deployment of MIMO cells is non - transmit diversity cell in respect to non - MIMO UEs. This is the reason for assuming that such a solution is a default here.

General architecture to support MIMO assumes a double transmit antenna array (DTxAA) at the BTS and also 2 receive antennas at UE with single or dual stream. Single stream (SS-MIMO) and dual stream (DS-MIMO) are two types of MIMO depending on whether same or different TBSs are being transmitted over both antennas respectively. Switching between single stream and dual stream is performed adaptively depending on CQIs, radio link conditions, and so on.

In RU20, SU - MIMO (Single User) transition per TTI is supported.

MIMO is expected to give considerable gain in terms of throughput for dense urban and urban scenarios, where high number of scatterers is available.

On the other hand, for rural and road clutters higher gain in terms of cell range can be expected.

For coverage dimensioning, single stream is assumed at cell edge. Therefore, for all clutters gain in terms of coverage is expected by using MIMO.

3.1.3 RU10 highlights

3.1.3.1 Flexi BTS Multimode System ModuleFlexi BTS Multimode System Module is a new high capacity system module (baseband processing) for high capacity sites that can also be used as capacity expansion for Rel1 HW System Module (FSMB). There are three versions of the Rel2 HW system module:

• FSMC: supports up to 180 channel elements for traffic use (CEs for common control channels for basic configuration are already included in system module, and in addition to this, the module can serve 64 HSDPA users per scheduler.

• FSMD: supports up to 396 channel elements for traffic use (CEs for common control channels for basic configuration are already included in system module, and in addition to this, the module can serve 64 HSDPA users per scheduler.

• FSME: supports up to 612 channel elements for traffic use (CEs for common control channels for basic configuration are already included in system module, and in addition to this, the module can serve 64 HSDPA users per scheduler.

Common channels do not consume the total CE capacity, which is dedicated to traffic use in most cases. The common channels are included in Release 2 HW System Modules in accordance with the following:

• 1 * Rel2 System Module: 3 cells/20 km (for example 1+1+1 with 20 km cells). • 1 * Rel2 System Module: 6 cells/10 km (for example 2+2+2 with 10 km cells). • 2 * Rel2 System Module: 6 cells/20 km (for example 2+2+2 with 20 km cells). • 2 * Rel2 System Module: 9 cells/10 km (for example 3+3+3 with 10 km cells). • 2 * Rel2 System Module: 12 cells/10 km (for example 4+4+4 with 10 km cells).

In cases where a larger cell radius has to be maintained, some additional traffic CE capacity is necessary for the common channels. These additional resources must be licensed as follows:

• 1 * Rel2 System Module and 6 cells/20 km: 36 CE license keys.

DN70118376Issue 04E

59


Id:0900d8058078744e

• 1 * Rel2 System Module and 9 cells/20 km: 36 CE license keys. • 1 * Rel2 System Module and 12 cells/20 km: 72 CE license keys.

The new release 2 HW System Modules (FSMC, FSMD or FSME) can also be used as capacity expansion for a Flexi BTS with a Rel1 HW System Module (FSMB).

The maximum capacities for traffic used when using two system modules in the same BTS are as follows:

• FSMB + FSMC: max. Site capacity 420 CE (= 240 CE + 180 CE) minus CE for CCCH

• FSMB + FSMD: max. Site capacity 636 CE (= 240 CE + 396 CE) minus CE for CCCH

• FSMB + FSME: max. Site capacity 852 CE (= 240 CE + 612 CE) minus CE for CCCH

• FSMC + FSMC: max. Site capacity 360 CE (= 180 CE + 180 CE) • FSMC + FSMD: max. Site capacity 576 CE (= 180 CE + 396 CE) • FSMD + FSMD: max. Site capacity 792 CE (= 396 CE + 396 CE) • FSMC + FSME: max. Site capacity 792 CE (= 180 CE + 612 CE) • FSMD + FSME: max. Site capacity 1008 CE (= 396 CE + 612 CE) • FSME + FSME: max. Site capacity 1224 CE (=612 CE + 612 CE)

A maximum of 3 RF modules are supported per system module.

3.1.3.2 Support for Large BTS Configurations up to 12 Cells (FlexiBTS)With this feature, it is possible to extend the BTS capacity by adding up to four carriers per sector in a three sector BTS and also the amount of baseband channel capacity required.

The carriers can also be in a six sector configuration 2+2+2+2+2+2.

3.1.3.3 Flexi RF Module Triple 70 W 2100New Flexi BTS RF module version Flexi RF Module Triple 70 W 2100 is introduced. The output power at the antenna connector is 60 W with 70 W Power Amplifier. The visual outlook is similar to the existing Flexi Single 50 W and Flexi Dual 50 W RF modules with the exception that the module includes the third dual carrier transceiver functionality.

New, more integrated Triple RF module makes it possible to build several existing con-figurations with only one RF module. One Flexi RF Module Triple 70 W HW supports the following configurations:

– Up to 1+1+1 @60 W– Up to 2+2+2 @30 W

All the existing licenses are in use with the Triple RF Module. In addition to the existing licenses, two new licenses are available. Branch activation in Triple RF Module acti-vates one sector. One to three Branch activation licenses are needed per Triple RF Module depending on the configuration. Flexi WCDMA BTS 60 W Carrier Power license is needed when the user needs 60 W o/p power per sector. One to three Flexi WCDMA BTS 60W Carrier Power licenses are needed per Triple RF Module depending on the configurations.

60 DN70118376Issue 04E


Id:0900d8058078744e


3.1.3.4 OBSAI 60 W remote radio head 2100 for the Flexi product lineThe 60 W RRH provides up to 60 W of output power at the antenna connector. Using the 60 W RRH it is possible to serve up to four carriers with one remote radio head (RRH) and support RAN sharing scenarios.

3.1.4 Feature interdependenciesThe table below presents RU20 On Top and RU20 features dependencies with other RU20 features. The table contains only the coverage, capacity, and baseband related features.

* RU20 On Top feature

Feature

Required features

CPC

CS

voic

e ov

er H

SPA

*

HSU

PA 2

ms

TTI (

SRB

on

HS

UPA

)

F-D

PCH

HSD

PA 6

4QA

M

Flex

ible

RLC

HSU

PA 5

.8 M

bps

24 k

bps

Pagi

ng C

hann

el

MIM

O

EUB

B (W

SPF)

/SM

Rel

2 (F

SMC

, D, E

)

HSP

A 7

2 us

ers

per c

ell

Dua

l-Cel

l HSD

PA 4

2Mbp

s*

Flexi MultiRadio BTS

CPC x

CS voice over HSPA*

HSUPA 2ms TTI (SRB on HSUPA)

x x**

F-DPCH x x x** x

HSDPA 64QAM

Flexible RLC x x x x

HSUPA 5.8 Mbps

EUBB (WSPF)/SM Rel2 (FSMC, D, E)

x x x x x x x x x x

HSUPA x x x x x

HSDPA dynamic resource allo-cation

x x x

QoS aware HSPA scheduling x x

HSDPA 14 Mbps per User x x x

HSDPA 16QAM x

Shared HSDPA Scheduler for Baseband efficiency

x

HSDPA 15 codes x x

Table 9 Feature dependencies

DN70118376Issue 04E

61


Id:0900d8058078744e

** In RU20, F-DPCH is not required for MIMO. This enables MIMO service also for MIMO-capable UEs that are not F-DPCH capable. Since UL SRB mapping to E-DCH is required, HSUPA 2ms TTI feature has to be used.

62 DN70118376Issue 04E


Id:0900d8058074be0a

3.2 Common input

3.2.1 BearersThe link budget calculation is performed differently for R99 users than for HSDPA or HSUPA users. For this reason, three groups of RABs are distinguished: R99, HSDPA and HSUPA.

3.2.1.1 R99 bearers

Single RABsThere are many R99 RABs (single RABs and multiRABs) supported. Examples of RABs that are usually used in dimensioning (single RABs) are shown in the table Examples of Single Radio Access Bearers.

All bearers can be offered in the whole of the cell area. However, the probability of bearer availability decreases with the distance from the base station (see the example in Figure Cell range vs. area location probability for different bearers). The planner must decide for which bearer and with what probability the coverage should be ensured. Usually, the higher the data rate of the bearer offered, the smaller the cell range and vice

RAB Traffic Class CS/PS Max Rates, kbps

UL DL

NB-AMR Speech Conversational CS 12.2 12.2

7.95 7.95

5.9 5.9

4.75 4.75

WB-AMR Speech

Conversational CS 12.65 12.65

8.85 8.85

6.65 6.65

Streaming Streaming CS 14.4 14.4

57.6 57.6

UDI Conversational CS 64 64

Packet Interactive/Background PS any combination of:

0 0

8 8

16 16

32 32

64 64

128 128

256 256

384 384

Table 10 Examples of Single Radio Access Bearers

DN70118376Issue 04E

63


Id:0900d8058074be0a

versa. The cell ranges for circuit switched services are also usually smaller than the ones for packet switched bearers at the same data rate.

Note that for the first offer planning a subset of bearers is usually sufficient and not every bearer listed above must be considered. Check the Core and UE capabilities also.

Figure 19 Cell range vs. area location probability for different bearers (example for UMTS2000).

3.2.1.2 HSDPA bearersIn RU20, HSDPA applies to PS Interactive/Background calls and streaming QoS class. HSDPA traffic can be held on the shared HSDPA channel using UEs of the Releases 5 and 6. The Table Supported HSDPA RAB combinations (single RABs only) shows the single HSDPA RABs supported in RU20.

0

1

2

3

4

5

6

7

8

9

10

70 75 80 85 90 95 100

Area Location Probability [%]

Cell

range

[km

]

UL Outoor Dense Urban AMR12,2

DL Outoor Dense Urban AMR12,2

UL Outoor Dense Urban PS 256/64

DL Outoor Dense Urban PS 256/64

UL Outdoor Dense Urban HSDPA 384/64

DL Outdoor Dense Urban HSDPA 384/64

UL Outdoor Dense Urban HSUPA 384/128

DL Outdoor Dense Urban HSUPA 384/128


UL DL

Packet Interactive/Background PS 16 HSDPA




Packet Interactive/Background PS HSUPA HSDPA

Packet PS Streaming PS 16 HSDPA

Table 11 Supported HSDPA RAB combinations (single RABs only)

64 DN70118376Issue 04E


Id:0900d8058074be0a

In RU20 it is possible to provide multiple RT RABs and NRT RABs over HSPA, either alone, or in combination with AMR and PS streaming services. This includes configura-tions with UL: DCH/DL: HS-DSCH and UL: E-DCH/DL: HS-DSCH.

HSDPA data rateThe HSDPA data rate depends on the UE capability, the current interference situation in the cell, and the available resources.

In RU20 On Top release, for HSDPA there are 24 different UE categories supported. Remember to take note of the categories supported in previous releases and refer to the appropriate version of the document. The qualities that differentiate the UE categories from each other are, for example, the supported modulations (QPSK, 16QAM and 64QAM) or the maximum number of HS-DSCH codes received (5, 10 or 15). See Table UE Capabilities, Source 3GPP (TS 25.306) for full details. In RU20, categories 13-20 are introduced. In RU20 On Top categories 21-24 are introduced.



Packet PS Streaming PS HSUPA HSDPA


UL DL

Table 11 Supported HSDPA RAB combinations (single RABs only) (Cont.)

DN70118376Issue 04E

65


Id:0900d8058074be0a

Depending on the current situation in the cell (for example: interference level, power available, UE category, traffic demand), the scheduler decides the number of HS-PDSCH codes sent to the particular user, as well as the modulation and coding rate used, and the number of transmissions that are required.

Unlike in Rel99, there are many different coding rates possible for bearers in HSDPA: as example, for Category 14 from 0.142 up to 0.893 resulting in data rates of 68kbps up to 19288kbps per code. The example coding combinations can be found in Table HSDPA MCS exemplary for UE Cat 14 (Source 3GPP TS 25.214).

HS-DSCH category

Maximum number of HS-DSCH codes received

Minimum inter-TTI interval

Max. no. of bit per trans-port block received within an HS-DSCH TTI

Total number of soft channel bits

Supported modulations

MIMO capable

DC capable

1 5 3 7298 19200

QPSK, 16QAM

No

No

2 5 3 7298 28800

3 5 2 7298 28800

4 5 2 7298 38400

5 5 1 7298 57600

6 5 1 7298 67200

7 10 1 14411 115200

8 10 1 14411 134400

9 15 1 20251 172800

10 15 1 27952 172800

11 5 2 3630 14400QPSK

12 5 1 3630 28800

13 15 1 35280 259200 QPSK, 16QAM, 64QAM14 15 1 42192 259200

15 15 1 23370 345600 QPSK, 16QAM

Yes

16 15 1 27952 345600

17 15 1 35280 259200QPSK, 16QAM, 64QAM

18 15 1 42192 259200

19 15 1 35280 518400

20 15 1 42192 518400

21 15 1 23370 345600 QPSK, 16QAM

No Yes22 15 1 27952 345600

23 15 1 35280 518400 QPSK, 16QAM, 64QAM24 15 1 42192 518400

Table 12 UE Capabilities, Source 3GPP (TS 25.306)

66 DN70118376Issue 04E


Id:0900d8058074be0a

When the streaming class for HSPA is enabled, HSPA RT services are prioritized over HSPA NRT on the basis of RAB parameters (configured in the RNC) during the load control phase.

If DC HSDPA is not configured:

– UEs of Cat. 21 shall act like Cat. 9,10,13,14,15,16,17 or 18– UEs of Cat. 22 shall act like Cat. 10,14,16 or 18,– UEs of Cat. 23 shall act like Cat. 13,14,17,18,19 or 20– UEs of Cat. 24 shall act like Cat. 14,18 or 20.

3.2.1.3 HSUPA bearers and UE categoriesIn RU20, service class Interactive/Background (I/B) is supported via E-DCH. The uplink E-DCH is always combined with HSDPA in downlink. Therefore, for multi-call cases the same RAB combinations as for HSDPA in the previous release are applicable.

• PS Interactive/Background (UL:E-DCH/DL:HS-DSCH) • AMR + PS Interactive/Background (AMR + UL:E-DCH/DL: HS-DSCH) • CS Conversational UL64/DL64 + PS I/B (CS + UL:E-DCH/DL: HS-DSCH)

Streaming QoS for HSPA is introduced as an optional feature in RU10 and therefore the following new RAB combinations are possible:

• PS Str. (UL:E-DCH/DL:HS-DSCH). • PS Str. + PS I/B (UL:E-DCH/DL:HS-DSCH + UL:E-DCH/DL:HS-DSCH). • AMR + PS Str. (AMR + UL:E-DCH/DL:HS-DSCH). • AMR + PS Str. + PS I/B (AMR + UL:E-DCH/DL:HS-DSCH + UL:E-DCH/DL:HS-

DSCH).

Since RU20, CS voice over HSPA bearer is introduced. The following RAB (with speech CS RAB) combinations, where SRBs and all RBs are mapped to E-DCH/HS-DSCH transport channels, are supported:

• Speech CS RAB • Speech CS RAB + PS streaming PS RAB • Speech CS RAB + 1...3 Interactive/Background PS RABs • Speech CS RAB + PS Streaming PS RAB + 1...3 Interactive/Background PS RABs

For MIMO case, only following RAB combinations are supported:

– PS Interactive/Background (UL:E-DCH/DL:HS-DSCH)– AMR + PS Interactive/Background (AMR + UL:E-DCH/DL: HS-DSCH)– CS Conversational UL64/DL64 + PS I/B (CS + UL:E-DCH/DL: HS-DSCH)

In RU20 On Top, it is also possible to use the Dual Cell HSDPA feature. However, the DC HSDPA feature is not available for the PS Streaming traffic class. Furthermore, the use of DC HSDPA feature is prevented if multiple PS NRT RABs (UL: E-DCH/DL: HS-DSCH) are configured together with CS RAB or RT PS RAB. Consequently, the only RAB combinations where DC HSDPA feature can be configured with are:

– PS I/B (UL: E-DCH/DL: HS-DSCH),– AMR + only 1 PS I/B (AMR + UL: E-DCH/DL: HS-DSCH),– CS Conversational UL64/DL64 + only 1 PS I/B (CS + UL: E-DCH/DL: HS-DSCH).

In accordance with 3GPP, there are seven different categories of user equipment with different capabilities regarding the maximum numbers of parallel codes, the minimum

DN70118376Issue 04E

67


Id:0900d8058074be0a

spreading factor, and the minimum TTI. According to this standard, a spreading factor SF4 alone or both SF4 and SF2 may be used by certain mobiles. UEs may only support a 10 ms TTI or both 10ms and 2ms. The combination of these capabilities results in a maximum number of bits per transport block and TTI, and therefore in a maximum bit rate supported.

Up to RU10 (inclusively), only 2 Mbps were supported for HSUPA. Using 5.8 Mbps feature and 2ms TTI, it is possible to achieve throughput of 5.76 Mbps. RU20 introduces Category 7. It supports 16QAM, which is not supported in RU20; however, it acts as Category 6 if 16QAM is not active.

Note:

Additionally a maximum of four parallel codes can be assigned to the E-DCH.

Depending on the UE category, the number of assigned parallel codes, the assigned spreading factor, the coding rate, and the actual BLER operating point depending on HARQ parameters, a huge combination of different parameter sets are possible. Each of these parameter combinations accordingly result in a maximum user bit rate.

In principle, the UE can also transmit using higher spreading factors than the minimum ones shown in the previous tables. An overview of possible slot formats with different supported spreading factors for E-DPDCH is given in Table E-DPDCH slot formats (Source 3GPP TS 25.211).

In the first column, there are numbers of slot format, for example slot format 0 uses SF=256 and is able to deliver 30 channel bits in a 2ms sub-frame. It is designed to deliver 10 bits of information for each E-DPDCH TTI transmitted. This means that the 10 information bits result in 30 bits to be transmitted in the physical channel. If the TTI length of the E-DPDCH is 10ms, then the 30-bit E-DPCCH sub-frame is repeated five times, allowing a reduced power level.

E-DCH category

Maximum number of E-DCH codes transmitted

Minimum spreading factor

Support for 10 and 2 ms TTI EDCH

Maximum number of bits of an E-DCH transport block transmitted within a 10 ms E-DCH TTI

Maximum number of bits of an E-DCH transport block transmitted within a 2 ms E-DCH TTI

Category 1 1 SF4 10 ms TTI only 7110 (0.73 Mbps) -

Category 2 2 SF4 10 ms and 2 ms TTI 14484 (1.45 Mbps) 2798 (1.45 Mbps)

Category 3 2 SF4 10 ms TTI only 14484 (1.45 Mbps) -

Category 4 2 SF2 10 ms and 2 ms TTI 20000 (2 Mbps) 5772 (2.91 Mbps)

Category 5 2 SF2 10 ms TTI only 20000 (2 Mbps) -



NOTE: When 4 codes are transmitted in parallel, two codes are transmitted with SF2 and two with SF4

Table 13 E-DCH UE categories (Source 3GPP TS 25.306)

Slot format #i

Channel bit rate (kbps)

Bits/symbol M

SF Bits/frame

Bits/subframe

Bits/slot Ndata

0 15 1 256 150 30 10

1 30 1 128 300 60 20

Table 14 E-DPDCH slot formats (Source 3GPP TS 25.211)

68 DN70118376Issue 04E


Id:0900d8058074be0a

The performance requirement of the E-DPDCH in the multi-path fading condition is determined by the minimum throughput R.

3.2.2 Clutter typesSeveral clutters or morphological types of areas can be defined. In detailed network planning, for example implementation, the number of clutter types used can be 15 and more. Detailed data/maps that are beneficial in the tool planning phase can, however, become a problem during the early dimensioning phase. This is why the number of clutters considered is reduced to dense urban, urban, suburban, rural, and road.

Choosing a clutter has an impact on the propagation model used but also on other parameters, such as penetration loss and shadowing margin; these can be different for different bearers.

The following are short descriptions of the clutter types in use.

UrbanAreas with a high building density, as found mostly in urban environments consisting of large buildings, offices, shops and so on, with adjacent buildings clearly distanced from each other. The typical urban scenario should have a mean amount of streets with no distinct street orientation pattern and major streets that are visible on satellite maps. The buildings appear distinct from each other. Some small vegetation can be included. The average height of the buildings is below 40m.

Dense UrbanThese are areas within the urban environment with a highly concentrated building density. Single features do not clearly appear distinct from each other for example on a satellite map. The height of the buildings can be well above 40m.

SuburbanAreas of housing that include some vegetation, as found mostly bordering the urban areas, spreading outwards from the city centre. The average height is below 15m.

RoadThis clutter type corresponds to regions (or rural areas) outside city areas without large development - villages, smaller vegetation, roads.

2 60 1 64 600 120 40

3 120 1 32 1200 240 80

4 240 1 16 2400 480 160

5 480 1 8 4800 960 320

6 960 1 4 9600 1920 640

7 1920 1 2 19200 3840 1280

8 1920 2 4 19200 3840 1280

9 3840 2 2 38400 7680 2560

Slot format #i

Channel bit rate (kbps)

Bits/symbol M

SF Bits/frame

Bits/subframe

Bits/slot Ndata

Table 14 E-DPDCH slot formats (Source 3GPP TS 25.211) (Cont.)

DN70118376Issue 04E

69


Id:0900d8058074be0a

RuralThe rural clutter corresponds to areas without buildings, water, trees etc. This is modelled as an open area explicitly, so check whether Road may in fact be more suitable for some areas described as “rural” in the requirements.

The correct estimation of the clutter area is very important. A bad estimation can lead to big discrepancies in the number of sites calculation required.

3.2.3 Cell typesIn general, we can distinguish between macro, micro, and pico sites. Macro sites are those where the WCDMA BTS antennas are located above the rooftop level. Micro sites are outdoor sites with antennas located below roof level. Pico sites the indoor sites. This document focuses on macro sites.

Macro sites can be further divided into omni-directional and sectored sites. This document focuses on omni-directional, two-sector, three-sector, and six-sector sites.

The three-sector case is the standard and most common case. Micro sites are omni-directional or one-sector sites.

3.2.4 Environment Type (Channel Model, Velocity, Indoor/Outdoor User)Selection of the environment has a big impact on the link budget calculation. A change in this parameter leads to automatic changes in several other parameters, for example Eb/No values, hand-off gain, and Tx power increase.

The environment is a combination of cell type (macro, micro or pico), channel model (Vehicular A, Outdoor to Indoor and Pedestrian A and Indoor Office A), and velocity (120km/h, 50km/h and 3km/h). Refer to 3GPP TR101.112 (UMTS30.03) for a more detailed description.

For indoor users served from an Outdoor WCDMA BTS, a penetration margin is usually taken into account to model the loss of, for example, the building wall. For outdoor users this penetration margin is not taken into account.

For the Macro cell link budget the following environments are supported:

• Vehicular A at 120km/h. • Vehicular A at 50km/h. • Vehicular A at 30km/h. • Vehicular A at 3km/h (marked with “X” in Table Possible environments below.).

HSPA is usually associated with the lower velocities of the UEs. Therefore, the following channel models and velocities are selected for the macro environment for HSDPA:

• Vehicular A at 30km/h. • Vehicular A at 3km/h. • Pedestrian A at 3km/h. • Pedestrian A at 50km/h.

The system level simulation environment with the Vehicular A channel model is always matched to macro cells. The Outdoor to Indoor and Pedestrian A channel model is usually matched to a micro (but sometimes also macro) cell environment.

70 DN70118376Issue 04E


Id:0900d8058074be0a

The Outdoor to Indoor and Pedestrian A channel model is sometimes used in simula-tions of HSDPA. HSDPA is related to low speed, and for low speeds the Vehicular A and Outdoor to Indoor and Pedestrian A channel models simulations give similar results.

For Release 99 bearers, the assignment recommended is as follows:

• Macro Cell Dense Urban, Urban, Suburban: Vehicular A 50km/h. • Macro Cell Road, Rural: Vehicular A 120km/h. • Micro cells: Outdoor to Indoor and Pedestrian 3 km/h.

For HSPA bearers, the assignment recommended is as follows:

• All clutters: Vehicular A 3km/h.

Macro Micro Pico

Vehicular A at 120 km/h X - -




Outdoor to Indoor and Pedes-trian A at 50 km/h

- X -

Outdoor to Indoor and Pedes-trian A at 3 km/h

- X -

Indoor Office A at 3 km/h - - X

Table 15 Possible environments

DN70118376Issue 04E

71


Id:0900d80580787443

3.3 Link budget calculation, macroLink budget calculation, macro describes the link budget calculation as it applies to macro sites.

The dimensioning process starts with an estimation of the number of sites required using the link budget calculation. This must be done per area and per phase of the planned radio network.

The first step of the link budget calculation is to identify the product line, frequency band, clutter, channel model, site layout, user equipment type, BS RF part and bearer type for which the calculation should be done in a certain area and for a certain phase of the network. Common input dimensioning settings are described in section Common input. The traffic model used here provides information on the bearers that should be taken into consideration. In case of any doubt concerning the scenario that could give the worst results (biggest number of sites), all potential worst cases should be checked.

The setting of the “common input” parameters determines further link budget parame-ters (or their ranges) that are used in the calculation of maximum path loss allowable. See Link Budget Formula (Maximum Allowable Path Loss) R99 bearers for more details.

A comparison of maximum path loss allowable with the propagation model equation (see Link Budget Formula (Maximum Allowable Path Loss) HSUPA) results in the cell range estimation. The site area and the number of sites required can be calculated from the cell range (Calculation of cell area (site area) and site-to-site distance).

The results of the link budget calculation are used in the traffic calculation step of the dimensioning process.

3.3.1 Link Budget Formula (Maximum Allowable Path Loss) R99 bearersThe following equation is the link budget formula, a calculation of the maximum path loss allowable (Lmax). The formula is given in the logarithmic scale, so all values are in dBm, dBi or dB. The formulae are valid for all frequency bands.

Uplink

Downlink

All parameters used in these equations are explained in section Explanation of the used parameters.

3.3.1.1 Explanation of the used parametersThis section provides an explanation of the parameters used in the link budget calcula-tion.

PUE [dBm] maximum output power of the user equipment.

Lmax_UL = PUE + Gant,UE - Lfeeder,UE + Gant,NB - Lfeeder,NB - Information_Rate

- Thermal_Noise_Density - NFNB -Eb

N0

- MInterference + GSHO + GASH

- Mfastfading - Lbody - Mshadowing - Lpenetration

Lmax_DL = PNB_per_user + Gant,NB + Lfeeder,NB + Gant,UE - Lfeeder,UE - LInsertion

- Information_Rate - Thermal_Noise_Density - NFUE -Eb

N0

- MInterference + GSHO + GASH - Mfastfading - Lbody - Mshadowing - Lpenetration

72 DN70118376Issue 04E


Id:0900d80580787443

Signaling [%] amount of WCDMA BTS output power that is transmitted for the common pilot channel (CPICH) and other broadcast signaling channels:

• P-SCH (Primary Synchronization Channel) • S-SCH (Secondary Synchronization Channel) • P-CCPCH (Primary Common Control Physical Channel) • S-CCPCH (Secondary Common Control Physical Channel) • PICH (Paging Indicator Channel) • AICH (Acquisition Indication Channel)

PNB_per_user [dBm] power of the WCDMA BTS dedicated to one user.

In CDMA, the base station serves all active users simultaneously. As a result, the total power of the WCDMA BTS must be divided into the power reserved for the signaling and the users served N.

where N:

The power that is assigned to a single user (Pmax) cannot exceed a certain limit set by the RNC. The formula that represents this limit is implemented inside RNC procedures.

WPAPower [dBm] Total TxPower.

PtxDPCHmax [dB] determines the maximum power that can be assigned to a DPCH channel as a reference to Total Tx Power.

CPICHTxPower [dBm] Power of the CPICH given in dBm.

CPICHToRefRABOffset [dB] defines the maximum link transmission power for a selected reference RAB. If this parameter is set to a value that is too low, the DL power resources assigned are not fully utilized and system congestion is more likely. In the opposite case, the quality of calls in the system may be bad due to insufficient power.

SRB Bit Rate [kbit/s] Throughput value for signaling RAB bearer.

SRB EbNo [dB] EbNo value for signaling RAB bearer.

PtxDLabsMax [dBm] defines the absolute maximum link power for any service.

Gant, NB [dBi] antenna gain of the WCDMA BTS antenna

OutputpowerNodeB

PICHAICHCCPCHSCCPCHPSCHSSCHPCPICHSignalling

WWWWWWW

_

++-+-+-+-+=

PNB_per_user = minPNB_total + 10 log (1 - signalling) - 10log (N)

Pmax

N Pole_capacity Cell_load Sectorization_Gain⋅ ⋅Data_Rate No_of_sectors⋅

--------------------------------------------------------------------------------------------------------------------------=

= min CPICHTxPower - CPICHToRefRABOffset + 10* logBitRate*10

EbNo

10+ SRBBitRate*10

EbNo

10

RefBitRate*10

EbNo

10

WPA Power - PtxDPCHmax

PtxDLabsMax

MaxTransitPower =

DN70118376Issue 04E

73


Id:0900d80580787443

Each UMTS band enforces the implementation of antenna types designed to cover the frequency range desired. Most of the single-band and multi-band equipment offered for UMTS 2000, GSM 1800, and GSM 900 suit these two UMTS bands that are foreseen for the US market.

In general, antenna transmitting signals of lower frequencies are char-acterized by lower antenna gain.

Gant, UE [dBi] antenna gain of the user equipment antenna

Lfeeder, NB and Lfeeder, UE [dB] feeder loss between the WCDMA BTS and the antenna connector, and respectively the loss between the user equipment and the antenna connector

In terms of improvement for uplink coverage, a tower mounted amplifier (TMA) is proposed that will compensate for the feeder loss between the receiver antenna and the WCDMA BTS. Employment of tower-mounted amplifiers is mostly useful in configurations with high feeder losses, that is when the WCDMA BTS and the antenna are quite far apart (usually in rural/suburban areas or in cases where the WCDMA BTS is, for example, placed in the basement and the antenna on the rooftop of high buildings).

Linsertion - TMA Insertion Loss [dB] additional loss that is assumed only in the DL direc-tion that has to be taken into account when the TMA is mounted.

Information_Rate = 10 log (Rb) [dB/Hz] The information rate is the channel bit rate. Rb is the bit rate in [bps] of the considered bearer.

Thermal_Noise_Density = kT [dBm/Hz]

• k = Boltzmann constant = 1.38 10-23 J/K. • T = temperature in Kelvin (0 °C = 273 K).

The thermal noise density is at room temperature (20 C = 293 K) about –174 dBm/Hz.

NFNB and NFUE [dB] Noise figure of WCDMA BTS and user equipment.

A receiver’s noise figure is the amount of noise (in dB) caused by, for example, the signal processing in active electronic components in addition to the thermal noise density within the receiver’s noise bandwidth.

The noise figure of the user equipment of the new 850/900 MHz band is estimated to be equal to the value that is valid for the 2 GHz band.

Eb/N0 [dB] Eb/N0 is the minimum value of energy received per bit to the noise plus the interference (Eb/(N0+I0)) ratio where the receiver is still able to

f [MHz]

VMS [km/h] 2000 1900 1700 1500 850/900

3 5.6 5.3 4.7 4.2 2.4

50 93 88 79 69 39

120 222 211 189 167 94

Table 16 Values of maximum Doppler frequency in [Hz] calculated for different mobile velocities at all available UMTS frequency bands

74 DN70118376Issue 04E


Id:0900d80580787443

decode the signal received at the BER required. The noise level is a combination of background noise and interference created by the other users in the system. In CDMA systems, all other users are considered as a source of interference. Therefore, the number of active users per sector or cell is limited in order to keep a suitable Eb/(No+Io) ratio.

In the case of the UMTS 850 band, the required Eb/N0 decreases in pro-portion to Eb/N0 for 2 GHz band for the corresponding mobile channels.

The value of this parameter is a result of Link Level Simulation (see UMTS30.03), it changes depending on the bearer, link (uplink, down-link), cell type, and coding scheme. In the downlink direction, the diver-sity received at the user equipment depends on the UE capabilities.

Interference Margin M [dB] The interference margin takes into account the noise rise due to intra-cell and inter-cell interference. The total noise increases with the increase in the number of users in the system. This negative effect of a higher loading in the CDMA system is usually calculated and translated into [dB]. With this margin, the dependency of the cell range on the traffic load in the cell is considered (cell breathing).

The impact on the uplink in the link budget, which represents the rise above thermal noise, is equal to:

On the downlink, intra-cell Iic and inter-cell Ioc interference levels are related to the total thermal noise level Nthermal in the interference margin calculation. The loss of orthogonality on the downlink due to the propa-gation environment characteristics generates intra-cell interference at the receiver of the UE. This margin can be expressed in analogy to the uplink formula as a function of the load Cell_LoadDL. However, due to the different orthogonality conditions, the calculation of the cell load differs between UL and DL. Therefore, the interference margin values for same cell load values differ slightly between UL and DL.

GSHO [dB] soft handover gain

This gain is considered at the cell edge. It is achieved as a result of macro diversity. This phenomenon reduces the negative effect of small scale fast fading. It allows the lowering of the transmit power or Eb/No requirements. This parameter covers gain connected with both soft and softer handover.

GASH [dB] gain against shadowing

This gain is considered at the cell edge. It is approximately the gain of a handover algorithm, in which the best BTS can always be chosen (based on minimal transmission power of MS) against a hard handover algorithm based on the geometrical distance. Gain against shadowing can be also calculated as the difference between the shadowing margin calculated for the multi-cell coverage and single-cell coverage model.

MInterference_uplink = -10*log(1 - Cell_LoadUL)

MInterference_downlink = 10log ((Iic + Ioc + Nthermal) / Nthermal) = -10*log(1 - Cell_LoadDL)

DN70118376Issue 04E

75


Id:0900d80580787443

Figure 20 Single-cell and multi-cell coverage model

Mfastfading [dB] Fast fading margin

The fast fading margin (Tx power increase) corresponds to a power backup at the transmitting end. This margin reflects the amount of power of the closed loop fast power control algorithm to follow the steep fluctuations of the link loss caused by the fast fading channel, that is sta-tistical effects. In the UMTS 2000 band, this particularly applies to slow moving mobiles (Pedestrian, In-/Outdoor at 3km/h users) where closed loop fast power control is not always able to keep track of the fast fadings in radio signal. It is especially important to consider this effect in the uplink direction, whereas in downlink one can assume that the effect is averaged over multiple users.

In the case of lower frequency band, for example 850 MHz band, the fast fading effect is seen as being ‘slower’ than in the case of 2 GHz and 1900 MHz bands (see the table above for an explanation of this effect). Thus, in the case of lower frequency, the fast power control can be more effective at higher velocities of the mobile unit, even up to 50 km/h. This estimation is based on values of the fast fading margin for the UMTS 850/900 band in the UL direction.

Lbody [dB] body loss

The user’s body affects the radiation and the receiving performance of the radio waves while the user is talking on the phone. When the antenna is positioned at shoulder level, the receiving signal level decreases by around 3 dB. On the other hand, when the user is using the portable hand-held phone for data communication, a body loss of 0 dB can be assumed.

MShadowing [dB] shadowing margin (Slow Fade Margin or Log Normal Fade Margin)

The path loss that is calculated with the propagation model gives the average loss. This value may vary due to slow fading effects. These variations are lognormal distributed, so with a certain probability the loss is higher (or lower) than the average value. The shadowing margin is defined to maintain coverage with a certain location probability in

single - cell coverage

multi - cell coverage Gain against

shadowing

Area location probability

Area location probability

76 DN70118376Issue 04E


Id:0900d80580787443

these cases as well. In other words, the shadowing margin is the amount by which a received signal level may be reduced without causing system performance to fall below a specified threshold value.

Figure 21 Calculation of the fade margin

There are two different ways to describe the outage probability. One is the probability related to the cell edge and the other one is related to the cell area. The dependency between the two probabilities is a function of the propagation exponent and the standard deviation.

Lpenetration [dB] penetration loss

When the user equipment is operating inside a building, vehicle or within a forest area, the user equipment suffers increased propagation loss as the signal penetrates the objects to reach the WCDMA BTS. This kind of loss is known as penetration loss. The penetration loss is a function of the carrier frequency and the nature of the obstacles.

The report on the COST Action 231 (ISBN 92-828-5416-7) shows that building penetration loss decreases, on average, by 2 dB at 900 MHz, compared to 1800 MHz. This is taken into account while setting values of Lpenetration for the UMTS 850.

Location Probability Standard Deviation of the signal level

Log-normal Fade MarginIn whole cell on cell edge

95%

86,9% 9 dB 10,1 dB

86,0% 8 dB 8,6 dB

84,9% 7 dB 7,2 dB

78,7% 4 dB 3,2 dB

Table 17 Examples of the shadowing margin

Allowable Outage in Whole Cell

(for example 10%)

Take into account

Path loss Exponent

(Propagation model)

Allowable Outage on Cell Edge (?%)

Standard Deviation

S d [dB]

Log - normal Fade Margin

= Sd x Confidence Factor

DN70118376Issue 04E

77


Id:0900d80580787443

3.3.1.2 Indoor coverage location probabilityCalculating the indoor coverage requires consideration of a penetration loss, as described previously. In some cases, instead of one value for penetration loss (mean penetration loss), its distribution is defined as a lognormal process with a certain mean value and standard deviation. The reason for this is the fact that buildings are not the same and differ one from another with regard to the value of penetration loss parameter. Signal propagates differently inside of the different buildings. At the end, apart from outdoor log-normal fading, indoor signal is subject to fluctuation coming from log-normally distributed penetration losses. In order to take into account both effects joint standard deviation has to be calculated.

One can assume that the two lognormal processes are statistically independent, so instead of considering each of the processes separately, one process can be consid-ered as being a sum of the two. Standard deviation of the combined processes would be calculated as follows:

Usual values of the penetration loss standard deviation are 4dB – 8dB.

3.3.2 Link Budget Formula (Maximum Allowable Path Loss) HSDPAThe following equation is the link budget formula, calculation of the maximum path loss allowable (Lmax). The formula is given in the logarithmic scale, so all values are in dBm, dBi or dB.

HSDPA/Rel99 and HDPA/HSUPA downlink

HSDPA/Rel99 uplink

Area Location Probability

Outdoor St. Dev.

Indoor St. Dev.

Combined St. Dev.

Shadowing Margin based on Combined St. Deviation

93% 8 4 8.94 8.4

93% 8 6 10.00 9.8

93% 8 8 11.31 11.5

Table 18 Examples of the combined slow fading and penetration loss margin (Urban clutter; one slope model, antenna height 30m)

2

_

2

log_ losspennorcomb+=

Lmax_DL = PNB_per_user_per_TTI + Gant,NB - Lfeeder,NB + Gant,UE - Lfeeder,UE - LInsertion

- Information_Rate - Thermal_Noise_Density - NFUE -Eb

N0

- MInterference + GASH - Mfastfading - Lbody - Mshadowing - Lpenetration

Lmax_UL = PUE + Gant,UE - Lfeeder,UE + Gant,NB - Lfeeder,NB - Information_Rate

- Thermal_Noise_Density - NFNB -Eb

N0

- MInterference + GSHO + GASH

- Mfastfading - Lbody - Mshadowing - Lpenetration - MHS-DPCCH

78 DN70118376Issue 04E


Id:0900d80580787443

3.3.2.1 Explanation of the used parameters This section describes further the parameters used in the HSDPA Link Budget calcula-tion, as well as the parameters that are calculated in a different way in the case of HSDPA.

HSDPA modulation and coding schemesAccording to 3GPP recommendations, multiple possibilities of coding rates and modu-lations are defined. Depending on the UE category, modulation, and coding schemes differ with different CQI values. As example, MCS values for Category 14 are listed in Table HSDPA MCS exemplary for UE Cat 14 (Source 3GPP TS 25.214).

MSC = CQI Values

TBS (bits) Number of HS-PDSCH

Modulation Bearer Data Rate (kbps)

Code Rate

0 N/A Out of range

1 136 1 QPSK 68 0.142

2 176 1 QPSK 88 0.183

3 232 1 QPSK 116 0.242

4 320 1 QPSK 160 0.333

5 376 1 QPSK 188 0.392

6 464 1 QPSK 232 0.483

7 648 2 QPSK 324 0.338

8 792 2 QPSK 396 0.413

9 928 2 QPSK 464 0.483

10 1264 3 QPSK 632 0.439

11 1488 3 QPSK 744 0.517

12 1744 3 QPSK 872 0.606

13 2288 4 QPSK 1144 0.596

14 2592 4 QPSK 1296 0.675

15 3328 5 QPSK 1664 0.693

16 3576 5 16-QAM 1788 0.373

17 4200 5 16-QAM 2100 0.438

18 4672 5 16-QAM 2336 0.487

19 5296 5 16-QAM 2648 0.552

20 5896 5 16-QAM 2948 0.614

21 6568 5 16-QAM 3284 0.684

22 7184 5 16-QAM 3592 0.748

23 9736 7 16-QAM 4868 0.724

24 11432 8 16-QAM 5716 0.744

25 14424 10 16-QAM 7212 0.751

26 15776 10 64-QAM 7888 0.548

Table 19 HSDPA MCS exemplary for UE Cat 14 (Source 3GPP TS 25.214)

DN70118376Issue 04E

79


Id:0900d80580787443

The CQI (channel quality information) table shows the combination of modulation, the number of codes, coding and transport block sizes (TBS). Link adaptation is based on the physical layer CQI provided by the terminal. If conditions are good, UE sends high CQI, so bigger transport blocks are sent and higher throughput is achieved. When radio conditions deteriorate, the UE sends CQIs with lower number. Smaller transport blocks are sent and lower throughput is achieved.

Data rate at cell border [kbps]Data Rate at cell border is the total data rate that can be achieved by a user at the cell border. This takes into account the CQI selected (bearer), the number of transmissions assumed and the number of parallel HS-PDSCH sent to the user (assuming that all codes in this TTI are sent to one user). It has an impact on the C/I value selected, which comes from simulation. Using HSDPA 64QAM and HSUPA 5.8Mbps, it is possible to achieve higher data rates respectively in DL and UL. However, it is possible only inside the cell, since poor signal conditions are experienced on the cell border and achieving high throughputs is difficult.

HSDPA power (per user in one TTI) [%]This is the part of the Tx power dedicated to one HSDPA user. The maximum amount of power that can be dedicated to one HSDPA user is determined by the setting of RNC data base parameter (HS-DSCH Power Offset). The default value of the parameter is set by default to 6dB over the CPICH power level. By CPICH power of 33dBm (usually 10% of the total Tx power), the maximum HSDPA power per user is 39dBm (40% of the total Tx power).

Power per HSDPA user can be used by one or multiple HS-PDSCH codes assigned to this one user.

The total power per cell dedicated to HSDPA is normally at the maximum of 60% of the total Tx power. The other 40% of the power is reserved for common control channels, HS-SCCH channels, and associated DCH channels in the cell. The 60% limitation is also used in system level simulations.

Power per user per TTI is calculated as follows:

Associated DCH channel power [%]The power that can be assigned to HSDPA is the power remaining after the assignment of common control and dedicated channels. In the case of HSDPA-only carriers, a certain amount of power must be reserved for the dedicated channels, as each HSDPA user requires one dedicated control channel (DCCH) in DL (associated DCH). HSDPA users require the associated DCH channels when they are connected, even if they are not currently receiving any data on the shared HS-DSCH channel.

27 21768 12 64-QAM 10884 0.630

28 26504 13 64-QAM 13252 0.708

29 32264 14 64-QAM 16132 0.800

30 38576 15 64-QAM 19288 0.893

MSC = CQI Values

TBS (bits) Number of HS-PDSCH

Modulation Bearer Data Rate (kbps)

Code Rate

Table 19 HSDPA MCS exemplary for UE Cat 14 (Source 3GPP TS 25.214) (Cont.)

PNB_per_user_TTI = PNB_total + 10log(PNB_per_user_per_TTI [%])

80 DN70118376Issue 04E


Id:0900d80580787443

Figure 22 Radio bearer mapping for HSDPA traffic

Signaling power [%]For MIMO case, two CPICHs are required. Therefore, additional power is needed.

HS-SCCH and associated DCH channel power [%]HS-SCCH channel (HS Shared Control channel) is the DL control channel required to communicate to the HSDPA users in the cell which of them will have HS-PDSCH channels assigned in the next TTI (that is how many HS-PDSCH channels, in which modulation and coding).

One up to four HS-SCCH channels can be active in the cell, depending on the number of UEs that are simultaneously active in one TTI. The maximum number of HS-SCCH channels that can be activated in the cell is set by a database parameter.

For F-DPCH case associated DCH channel is replaced by F-DPCH. Power needed for HS-SCCH and F-DPCH is decreased.

For MIMO case HS-SCCH up to 30% more of power consumption is noticed. HS-SCCH and the associated DCH parameter value is higher.

For the DC-HSDPA case, power needed for HS-SCCH and associated DCH (or F-DPCH) is same as in F-DCPH case. See Table HS-SCCH and associated DCH (F-DPCH) power per user assignment.

Simulations show that for each HSDPA user active in the cell, 0.8% of the total Tx power per cell is needed for the associated DCH channel and HS-SCCH channel (8% for ten users as a default dimensioning).

HS-SCCH and ass. DCH power per user

legacy HSDPA 0.80%

F-DPCH 0.44%

MIMO 0.56%

MIMO (w/o F-DPCH) 0.92%

Table 20 HS-SCCH and associated DCH (F-DPCH) power per user assignment

DL UL

DCCH DTCH

DCH

0 kbps

DPCH

DCH HS-DSCH

DCCH DTCH

DCH

0 kbps

DPCH

DCH

DN70118376Issue 04E

81


Id:0900d80580787443

Figure 23 Power split in HSDPA cell

MHS-DPCCH – HS-DPCCH Overhead[dB]In the UL direction of HSDPA/Rel99 Link Budget, an additional margin for the HS-DPCCH channel is considered. HS-DPCCH channel includes the ACK/NACK and CQI. HS-DPCCH Overhead is depends on the associated DCH (16/64/128/384) selected.

For the MIMO case, overhead is greater because of more ACK/NACKs and PCI (pre-coder control information) needed to be sent.

For the DC HSDPA case, overhead is greater because of the required power increase caused by increased ACK/NACK codewords to be sent.

Average orthogonality factorThe orthogonality factor describes the orthogonality of the cell's own channels. The factor changes with the environment (Channel Model) and typical values are 0,4 – 0,9.

The orthogonality factor is used for the intracell interference calculation:

Iintracell = (1- α ) * (C – S)

where

α – orthogonality factor

C – total signal power received from own cell (excluding thermal noise)

S – received power of a single (own) HS-PDSCH code

Other-to-own cell interference factorThis parameter indicates the magnitude of interference from other cells. On the cell edge, values from 1.3 to 1.8 can be found. Closer to the antenna location, lower values can be found since the impact of the other cells interference is lower.

DC_HSDPA 0.44%

HS-SCCH and ass. DCH power per user

Table 20 HS-SCCH and associated DCH (F-DPCH) power per user assignment

P(HS-PDSCH)

P(ass.DCH)

P(CPICH)

5 15 25 35 45 55 65 75 85 95

Number of users per cell

Tx power Profile

%ofm

ax.N

ode

BT

xpow

er

0%

10%

20%

40%

30%

50%

60%

70%

80%

90%

100%

82 DN70118376Issue 04E


Id:0900d80580787443

The following figure shows an example behavior of the other-to-own cell interference factor as a function of the distance from the antenna, where cell edge is at distance 1 from the antenna. The simulation was performed for a three-sector site. Closer to the antenna the impact of the other antennas on the same location can be seen (the curve goes slightly up).

Other-to-own cell interference factor is used to calculate other cell interference:

Iintercell = f * C

where:

f – other-to-own cell interference factor

C – total signal power received of own cell (excluding thermal noise)

Figure 24 Other-to-own cell interference factor

Interference margin [dB]Interference margin (M) describes the impact of intra- and intercell interference on the receiver sensitivity.

M = S0 - Smin

where:

S0 – receiver sensitivity in the ideal conditions (no intracell and no intercell interference: α = 1 and f = 0)

Smin – minimum receiver sensitivity (also see below)

Information rate [dB/Hz]Information rate is the channel data rate.

Information Rate = 10 log (R) [dB/Hz]

DN70118376Issue 04E

83


Id:0900d80580787443

where:

R – is the bearer data rate in [bps]

Eb/N0 [dB] The definition of the Eb/N0 parameter is the same as for Rel99 bearers.

Rx sensitivity at antenna connector [dBm]Rx sensitivity is the minimum signal power received of a single HS-PDSCH required to achieve the target Eb/N0.

where:

N – effective noise (thermal noise + noise figure)

W – Chip rate

E – effective data rate

α – orthogonality factor

f – other-to-own cell interference factor

γ - part of the Tx power of the own WCDMA BTS dedicated to the single user in TTI.

GASH [dB] – gain against shadowingOnly gain against shadowing can be considered in HSDPA (no soft handover of the DL shared channel exists). This gain takes into account the reduction of the lognormal fading margin, since the slow fading is partly uncorrelated between the base stations. A certain probability exists that on the cell border, the signal from multiple cells can be received; this is seen as gain against the lognormal fading margin. Gain against shad-owing can be also calculated as a difference between the shadowing margin calculated for multicell coverage and the single-cell coverage model. See Figure Single-Cell and Multi-Cell coverage model.

Mfastfading – fast fading margin [dB]In HSDPA, fading environment can be considered as beneficial, since transmission per TTI can be scheduled to the user with favorable radio channel conditions. This implies that the overall system capacity is increased and thus certain gain should be included in radio link budget calculations. This gain is commonly known as multi-user diversity.

In UL, the Fast Fading Margin has a different meaning, as it is considered as power backup for compensation of the fades in the radio link channel. For a description of the Mfastfading parameter in the case of UL, see Explanation of the used parameters.

EbNo--------

WE----- Smin×

N Iintracell Iintercel l+ +----------------------------------------------------------= Smin

NWE-----

EbNo---------------- 1 α–( ) 1

γ--- 1–⎝ ⎠⎛ ⎞ f

γ--–×–

-----------------------------------------------------------------=

84 DN70118376Issue 04E


Id:0900d80580787443

3.3.2.2 Explanation of the other relevant HSDPA parameters

Number of HARQ transmissions This is the number of times that the transmission to the UE is repeated. A maximum of four transmissions is possible. The user data rate changes, as well as the Eb/No required with the number of HARQ transmissions.

User data rate [kbps] During the multiple HARQ transmissions the same data is sent to the user. This implies that only a fraction of the bits can be received correctly during each transmission. The effective mean data rate of one transmission can be therefore defined as:

User Data Rate = Bearer Data Rate / Number of HARQ Transmissions

Number of (HS-PDSCH) codesThis is the number of parallel HS-PDSCH codes active in one TTI. These can be codes of one or multiple users.

HSDPA SchedulerIn general, schedulers are used to share the available capacity of the air interface between packet users. Different implemented algorithms are described below.

Proportional fair scheduler The proportional fair scheduler transmits data even to the users that are experiencing higher interference. It takes into account the amount of data waiting to be sent to each user as well as the amount of data that was recently send to each user and tries to assign resources in a fair way. Level of interference users pays a secondary role in resources assignment.

This scheduler is supported by Flexi and Ultra Site

Round robin scheduler This scheduler is implemented only in Flexi and Ultra Site BTS line equipments. With this scheduler, each user is scheduled with equal probability. The radio channel conditions in this scheduler are not taken into consideration, therefore, it can be said that Round Robin is not channel aware.

3.3.3 Link Budget Formula (Maximum Allowable Path Loss) HSUPAFor HSDPA/HSUPA scenario:

For a description of the single parameters, see Explanation of the parameters used in Link budget calculation, macro and Link Budget Formula (Maximum Allowable Path Loss) HSDPA.

Lmax_UL = PUE + Gant,UE - Lfeeder,UE + Gant,NB - Lfeeder,NB

- Thermal_Noise_Density - NFNB -EB

N0

- MInterference + GSHO

+ GASH - Mfastfading - Mshadowing - MOCI - Lpenetration - MHS-DPCCH

DN70118376Issue 04E

85


Id:0900d80580787443

3.3.3.1 Explanation of the parameters used

MOCI [dB] – Own connection interference margin The own connection interference factor reduces the uplink interference floor by the UEs own contribution to the uplink interference, that is by the desired uplink signal power. This factor is included in the HSUPA link budget because the uplink bit rates can be greater and the uplink interference contribution from each UE can be more significant.

3.3.4 Propagation modelsThe propagation model should be adjusted to the environment in which the sites are built up. This means that propagation measurements and tuning of the model are recom-mended for deployment in the real network. For the dimensioning phase, however, standard models can be used by default.

In accordance with the 3GPP TR101.112 (UMTS 30.03) recommendation, COST 231-Hata Model with small modifications is used for the cell range calculation in all offered frequency bands (UMTS2000/1900 and UMTS900/850). For UMTS2000/1900/1700 it is an extended version of the Hata Model for the frequency range 1500-2000 MHz, whereas for UMTS900/850 it is an extension of the Hata Model for the range 150-1500 MHz.

The default propagation model for Macro cells is the so-called one slope model, which is applicable to cells whose range is larger than 1 km (see One slope model). For small cells, the so-called two slope model should be taken into account (see section General two slope model). In small cells, the antenna height is slightly below or at the mean roof top level and, therefore, path loss depends mainly on diffraction and scattering at the rooftops. The small cell typically has a range from 100m up to around 2 km.

For bigger cells, the so-called Extended cells Hata - Davidson Model can be applied. This model is an extension of the Hata Model for distances greater than 20 km. This model applies only to lower bands 900 and 850 MHz.

3.3.4.1 One slope modelThe one slope model can be used for both large and small cells where the base station antenna height is above the rooftop levels of buildings adjacent to the base station.

The path loss L (given in dB) depends on the distance d between the base station antenna and the mobile station, the carrier frequency f, the heights of the base station antenna hBS and the mobile station hMS, and the clutter type.

The formula below are valid for the following ranges of parameters:

• Frequency f: 150 – 2000 MHz. • Base Station height hBS: 30 – 200m. • Mobile height hMS: 1 – 10m. • Distance d: 1 – 20 km.

The path loss formula is of the form:

where

L=A + Blog - 13.82logf

MHz

hBS

m- a

hMS

m+ slog

d

km+ Lclutter

86 DN70118376Issue 04E


Id:0900d80580787443

and the remaining co-efficients are defined in the tables below.

An overview of the latter propagation model is translated to the form:

L(d)=slogd+intercept

where some of the terms in the formulae have been pre-calculated for typical parameter values hBS =30m and hMS = 1.5m. Then the slope=35.22, whereas the intercept takes values listed in the following table.

Frequency A B

150-1500 MHz 69.55 26.16

1500-2000 MHz 46.30 33.90

Table 21 Frequency related path loss co-efficients

Clutter Type

dense urban

urban

suburban

road

rural

Table 22 Antenna height related path loss co-efficient

Clutter Type Lclutter

dense urban 3

urban 0

suburban

road

rural

Table 23 Clutter type related path loss co-efficient

ahMS

m

3.2log2hMS

m11.75* - 4.97

3.2log2hMS

m11.75* - 4.97

hMS

m* 1.1log

f

MHz- 0.7 - 1.56log

f

MHz- 0.8

hMS

m* 1.1log

f

MHz- 0.7 - 1.56log

f

MHz- 0.8

hMS

m* 1.1log

f

MHz- 0.7 - 1.56log

f

MHz- 0.8

-2.0log2 - 5.4f

28*MHz

-4.78log2 + 18.33logf

MHz

f

MHz- 35.94

-4.78log2 + 18.33logf

MHz

f

MHz- 40.94

DN70118376Issue 04E

87


Id:0900d80580787443

3.3.4.2 General two slope modelThe general two slope path loss model is a straightforward extension of the one slope model. The path loss formula (L) introduced in the preceding section still holds, but the slope parameter s is re-defined to cover all possible distances d in the following way:

The following table contains values of the slope parameter calculated for hBS=30m and the considered frequencies.

The intercept is the same as in Table One slope propagation model example (intercept).

Clutter type

Intercept

UMTS 850 UMTS 900 UMTS 1500 UMTS 1700/2000

UMTS 1900 UMTS 2000

UL DL UL DL UL DL UL DL UL DL UL DL

836 881 897 942 1440 1488 1732 2132 1880 1960 1950 2140

MHz MHz MHz MHz MHz MHz MHz MHz MHz MHz MHz MHz

DU 128.58 129.18 129.38 129.94 134.76 135.13 138.67 141.73 139.88 140.49 140.42 141.79

U 125.58 126.18 126.38 126.94 131.76 132.13 135.67 138.73 136.88 137.49 137.42 138.79

SU 115.82 116.27 116.43 116.86 120.47 120.74 123.81 126.20 124.76 125.24 125.18 126.24

Ro 102.37 102.75 102.87 103.22 106.00 106.20 108.92 110.79 109.67 110.04 110.00 110.83

Ru 97.37 97.75 97.87 98.22 101.00 101.20 103.92 105.79 104.67 105.04 105.00 105.83

Table 24 One slope propagation model example (intercept)

47.88 + 13.9log - 13.82logf

MHz

hBS

m

1

log50*

44.9 - 6.55loghBS

m

s =

d 1km

f 1500 MHz

,

, d 1km

71.13 + 6.16log - 13.82logf

MHz

hBS

m

1

log50* f 1500 MHz, d 1km

Distance

Slope s

UMTS 850 UMTS 900 UMTS 1500 UMTS 1700/2000

UMTS 1900 UMTS 2000

UL DL UL DL UL DL UL DL UL DL UL DL

836 881 897 942 1440 1488 1732 2132 1880 1960 1950 2140

MHz MHz MHz MHz MHz MHz MHz MHz MHz MHz MHz MHz

d < 1km 40.45 40.53 40.56 40.63 41.35 41.30 42.66 43.40 42.95 43.10 43.08 43.41

d ≥ 1km 35.22 35.22 35.22 35.22 35.22 35.22 35.22 35.22 35.22 35.22 35.22 35.22

Table 25 Two slope propagation model example (slope)

88 DN70118376Issue 04E


Id:0900d80580787443

3.3.4.3 Hata – Davidson modelFor extended cells, it is recommended not to use Hata model since it is suitable for ranges up to 20 km and may give too optimistic path loss values. Therefore, Hata – Davidson model is recommended for such cases. On the other hand, it is not recom-mended to use this model for ranges below 20 km since it gives lower path loss value than Hata model. Hata - Davidson adds additional correction factors to path loss calcu-lated from Hata model. This model should be considered in clutters such as road and rural. Path loss formula is of the form:

LHD=LHata+A(h1, dkm) - S1(dkm) - S2(h1,dkm) - S3(fMHz) - S4(fMHz, dkm)

where:

LHata – path loss calculated from Hata Model,

A and S1 – distance correction factors extending the range to 300 km,

S2 – base station antenna height correction factor extending the h1 range to 2500m

S3 and S4 – frequency correction factors

S2(h1,dkm)=0.00784|log10(9.98/dkm)|(h1-300) for h1>300

S3(fMHz)=fMHzlog10(1500/fMHz)/250

S4(fMHz,dkm)=[0.112log10(1500/fMHz)](dkm-64.38) for dkm>64.38

3.3.5 Cell range calculation, balancing UL with DL Cell range d is calculated from solving the propagation equation for the maximum allow-able path loss Lmax.

Lmax=L(d)

As the links are usually not balanced, the cell ranges calculated for downlink and uplink are different. For further calculation, the worst (smaller) result should always be taken.

In general, there is no need to balance the links.

Perform the following steps to balance the links:

• Identify the limiting bearer in UL: bearer_UL (Rel99 or HSUPA). • Identify the limiting bearer in DL: bearer_DL (Rel99 or HSDPA). • Identify the limiting link: for example, UL. • Balance the other link for example, DL with bearer_DL by changing the load (or Data

Rate at cell Border) in the link budget DL to match the UL cell range of the bearer_UL.

• The result is the balanced load (or Data Rate at cell Border) in DL.

distance [km] A (h1,dkm) S1(dkm)

dkm ≤ 20 0 0

20 < dkm ≤ 64.38 0.62137(dkm-20)[0.5+0.15log10(h1/121.92)] 0

64.38 < dkm ≤ 300 0.62137(dkm-20)[0.5+0.15log10(h1/121.92)] 0.174(dkm-64.38)

Table 26 Distance correction factors

DN70118376Issue 04E

89


Id:0900d80580787443

3.3.6 Calculation of cell area (site area) and site-to-site distanceThe manner in which the cell area is calculated depends on the cell-type chosen.

For three-sector sites with a main antenna beam of less than 90°, hexagonal cells are assumed. See Hexagonal three-sector site for more details.

Figure 25 Hexagonal three-sector site

In this case, the cell area Acell is calculated as:

where:

Rmax is the cell range d.

The site-to-site distance for three sector sites is calculated as D = 1.5 * R, as in Figure Cell range and site-to-site distance for hexagonal cells.

Figure 26 Cell range and site-to-site distance for hexagonal cells

This approach is used for three-sector sites as well as two-sector sites along the road.

The following site shape is appropriate for three-sector sites with antennae of the main beam 120°, as well as for omni-directional sites and six-sector sites:

Figure 27 Deformed site (rhomboidal cells)

Acell3 3⋅

8--------------- Rmax( )2⋅=

90 DN70118376Issue 04E


Id:0900d80580787443

In this case, the cell area is calculated as:

where

Rmax is the cell range and S indicates the number of sectors per site (1 for omni-direc-tional site, 3 for three-sector site).

The site-to-site distance is calculated as D =2*R*cos(30°) = 1.732 * R, see Figure Cell range and site-to-site distance for rhomboidal cells.

Figure 28 Cell range and site-to-site distance for rhomboidal cells

The site area is thus the number of sectors (cells) per (WCDMA BTS) site S, multiplied by the cell area.

The number of WCDMA BTSs required to cover a given area can be easily calculated with the following equation:

3.3.7 Results of link budgetThe main result of the link budget calculation is the estimation of the cell range for dif-ferent area types and environment types. This cell range changes with the bearer type, as well as with the link-type (uplink or downlink). With this result it is possible to deter-mine the limiting link and estimate the number of sites required in the area analyzed.

The result of the link budget calculation can be used as input for the next step of dimen-sioning – traffic calculation.

3.3.8 Link budget for common pilot channel signalThe coverage of the pilot signal should be at least as good as the coverage of the traffic channels. To check this, calculate a link budget for the pilot. All parameters used for the pilot calculation should correspond to those used for the former link budget of the bearers.

Acell32---

3Rmax2

S----------------------=

Asite = Acell * S

Number_of_NodeB =Aarea

Acell * S

DN70118376Issue 04E

91


Id:0900d80580787443

The way the Interference Margin is calculated in CPICH channel link budget is the same as of the HSDPA DL channel.

The pilot range calculated should be greater than or equal to the cell range. The Tx power for the common pilot channel is given as a percentage of the total transmit power of a WCDMA BTS. This is usually equal to around 10% (CPICH power is a part of the overall signaling power where the other signaling channels are taken into account with power values relative to the CPICH power).

3.3.9 Link budget calculation of cells equipped with RRHRF part type RRH (remote radio heads) requires special consideration in the link budget calculation. Multiple types of RRH exist with different parameters and application areas (supporting different frequency bands, different Tx powers, there are special macro and micro/pico RRH).

From the radio planning point of view, the most important difference of RRH solution comparing to usual RF parts is that the RRH has an optical fiber connection to its base station. One consequence of it is no feeder loss to be considered in the link budget cal-culation; another is the potential spatial separation of the base station from its cells. Together with the RF equipment, RRH can be placed in a certain distance away from the base station.

For Flexi BTS, the distance between the RF and Flexi SM Module is up to 15 km.

The link budget calculation of cells equipped with RRH is the same as in the case of standard solutions, however, values of some parameters are different:

– Feeder loss value includes only the connector loss (fiber optic used instead of normal feeder)

– Usually no need to use TMA - because of the low feeder loss value– Different values of noise figure and max. Tx power (specific for each RF part)

The soft handover gain parameter is assumed to be the same as for the non RRH dimensioning calculation.

Scenarios in which RRH can be used in offer planning

– Standard 3 sector planning: RRH or feederless sites can be used for a standard sites deployment.

– Planning of sites with RRH in the network extension phase (no new BTSs are required),– densification of the network - new sites placed between the existing sites to

improve the coverage quality and capacity of the network,– extension of the coverage area - new sites built up on the edge of the coverage

area of the previous phase.

92 DN70118376Issue 04E


Id:0900d80580787443

Figure 29 Distributed configuration example of network densification with RRH sites

3.3.10 Link budget calculation for six sectorsFigure Changes in the WCDMA BTS power assignment shows the rhomboidal shape of the 6 sector site. Antennas of 45° beamwidth are recommended instead of 60° for a better interference situation. Due to the cell layout, the cell range in the main antenna direction (0°) is higher than the cell range at the sector border (30°). In detail, the cell range in the main direction is factor (1/cos (30°)) ≈ 1.15 higher than at the sector border.

During the link budget calculation, check that the required coverage (range) in the main antenna direction (0°) and at the sector border (30°) can be achieved.

Figure 30 Deformed site (rhomboidal cells) of the six-sector site

While selecting the 6 Sector Site Layout, the following calculations are performed to avoid the inaccuracies mentioned at the sector border.

Let us assume the link budget example for the six-sector configuration. Calculation in the main antenna direction is a standard one. In the calculation for the sector border, the following additional aspect should be considered:

• Antenna Gain at 30° for the used 21,5dBi antenna is 15.6dBi. This can be checked in the antenna diagram, see Figure Antenna Diagram of K742219 (45°/ 21.5 dBi).

Main Antenna Direction Sector Border

DN70118376Issue 04E

93


Id:0900d80580787443

Figure 31 Antenna Diagram of K742219 (45°/ 21.5 dBi) • In UL the 3 dB gain due to 4Rx MRC (Maximum Ratio Combining) can be seen in

simulations.Simulations of 4Rx Diversity configurations show gains that are strongly dependant on the Channel Models. Diversity gains of 2.5dB up to 5dB are observed. For the 6 sector calculation 3 dB gain is used. The value of 3dB gain for 4 Rx antennas covers the effect of the power received doubling comparing the to 2 Rx antennas case.

• In DL a UE at the sector border receives signals of 4 neighbor cells instead of 3 (like in the main antenna direction), which can be translated into an additional soft handover gain and gain against shadowing of 1.3 dB, see Figure Three-sector and six-sector network layouts.

5.9 dB difference to themain direction antenna gain

330

300

270

240

210

180

150

120

90

60

30

360

94 DN70118376Issue 04E


Id:0900d80580787443

Figure 32 Three-sector and six-sector network layouts

During the calculation, the load on the side lobe and main lobe direction is adjusted in such a way that the required range (range in the main direction /1.15) is reached.

The DL power is shared between all users in the cell, users in the main antenna direction (0°) as well as the users in the 30° direction. However, due to the unequal path losses of the users in the two directions, the power of users at cell edge in 0° antenna direction is lower than the power of users at the cell edge in 30° direction. The lower power of users in 0° direction results in the lower interference and at the end lower load calculated in the link budget. However, the higher power of the users in 30° and the additional inter-ference is not directly considered in this calculation. In order to minimize this inaccuracy the average load (from 0° direction load and 30° direction load) is assumed as the DL load in the cell.

In Rel99 UL, HSDPA and HSUPA the minimum value of two ranges is selected: main direction or sector border direction times 1.15. This approach ensures that no coverage holes will exist.

All these calculations are performed inside the Link Budget algorithm after choosing the 6 Sectors Site Layout option without the interaction with user (except correct antenna parameters).

Note that there are no coverage problems with 3 sector sites in a cell edge direction (60deg from the main beam direction). The gain of antenna 60deg bandwidth is enough to provide coverage there. Therefore there is no need to calculate a separate link budget for in the cell edge direction.

6 sectors configuration is not supported in MIMO case.

3.3.11 Link budget calculation for HSDPA - interference limited caseThe standard link budget calculation is performed for the user at the cell border.

Close to the cell border the interference from other cells is very high. If additionally the power of own signal is small comparing to the total transmitted power and/or the required C/I for the chosen bit rate to high, the Interference Margin can not be calcu-lated: the required C/I level can not be reached, it is not possible to calculate the Minimum Rx Sensitivity.

On a cell border there is the main reason why the Min. Rx Sensitivity can not be calcu-lated: Not enough power for HSDPA channel.

3 neighbor cells

3 sector network layout 6 sector network layout

nb_7

nb_26

nb_3

4 neighbor cells

nb_1

nb_6 nb_7

nb_4 nb_5

nb_3nb_2

DN70118376Issue 04E

95


Id:0900d80580787443

As mentioned above interference level close to the cell border is high. Closer to own cell antenna interference from other cells is getting smaller. The effect is visible in Figure Other-to-own cell interference factor, where the other–to–own cell interference factor changes with the distance to the antenna are shown. It can be assumed that the orthog-onality factor from which the own cell interference is calculated is not changing with the distance to the antenna.

If the total level of interference is lower closer to the antenna, bearers with higher Eb/No requirements (having higher data rates) can be calculated. It is possible to calculate link budgets for the points closer to the antenna by reducing the other-to-own cell interfer-ence factor. However, when doing that one more effect must be considered: further away from the cell border (when coming closer to the antenna), handover gain is lower or there is no handover gain.

Figure Example of maximum HSDPA user data rate evaluation – one transmission shows how the Maximum HSDPA User Data Rate changes with the distance to antenna location. Points on the graph are possible link budget calculations with variable Data Rate At Cell Border. Other link budget parameters required for the calculation are the same for all points. Cell range is limited by one selected DL or UL calculation.

The green line connects the highest achieved data rates.

Note that there can be many points on cell edge, as they are the points not limiting the coverage.

Figure 33 Example of maximum HSDPA user data rate evaluation – one transmission

3.3.12 Link budget calculation for the shared Release 99 and HSDPA carriersIn the previous chapters, the link budget calculations were considered for the case when only R99 or only HSDPA users were present in the cell. In the system also a mix of R99 and HSDPA users in the same cell is possible.

1800

1700

1600

1400

1500

1300

1200

1100

1000

900

800

700

600

500

0,00 0,05 0,10 0,15 0,20 0,25 0,30 0,35 0,40 0,45 0,50 0,55 0,60 0,65 0,70 0,75

Max HSDPA User Data Rate Evaluation inside the cell

Distance from NodeB [km]

Use

rD

ata

Ra

te[k

bit/s

]

96 DN70118376Issue 04E


Id:0900d80580787443

There is no difference in the UL Link Budget calculation. Therefore the following infor-mation concentrates on DL Link Budget calculation.

In a shared scenario the power of the WCDMA BTS is shared among the common control channels, shared control channels (HS-SCCH), R99 users (DCH channels) and different simultaneously served HSDPA users (shared channels and DCCH channels) as shown in figure Exemplary WCDMA BTS power assignment.

Figure 34 Exemplary WCDMA BTS power assignment

In the real system, HSDPA channels can only use the power left after the common control and R99 channels are assigned. Power assigned to HSDPA is not constant but changes, depending on the demand from R99 users. As illustrated in Figure Changes in the WCDMA BTS power assignment, it is possible that in an extreme case there will be no power left for HSDPA. On the other hand, it is possible that for some time there will be no R99 users in the cell and the whole power remaining after the common control channels are served can be assigned to HSDPA.

Figure 35 Changes in the WCDMA BTS power assignment

Looking at the Link Budget, the worst case scenario (smaller cell range) will be calcu-lated for the case when only R99 users are adding to the maximum allowable load and

DN70118376Issue 04E

97


Id:0900d80580787443

use the whole available power. Such a scenario will happen in the network, therefore calculation of this link budget will limit the calculated cell range.

In table Example of different power assignment scenarios of one cell, some exemplary cell power assignments are calculated.

Note that % of the power refers to the total Tx Power (1).

The first and the last case in this table are the R99 only and HSDPA only cases. In the other cases a mix of R99 and HSDPA is shown.

In all cases the limiting cell range must always be checked.

From the link budget point of view, the best situation is when only one user is active per TTI:

• HSDPA Power per user is the part of HS-PDSCH channels power received by one user considered in this link budget calculation.

• Other HSDPA Power is the part of HS-PDSCH channels power received by other users not considered in this calculation. This power is set to 0 in the example since assuming only one HSDPA user served in this TTI.

The lowering of power required for R99 also lowers the number of R99 users per cell. The power per R99 users does not change as the user at the cell border will always require the same power. Also the interference experienced by the R99 user in DL does not change as it depends on the DL Tx power and not on the type of channel the power is used for. The lower the power available for R99, the lower the R99 load becomes. At the same time, if the HSDPA power increases, HSDPA coverage and maximum achiev-able HDSPA data rate at the cell border can be higher. HSDPA power per user can not be increased over a certain level defined in the database (for example 20% of the total power in the example). However, if the R99 power is lower, the actual total Tx power of the cell lower. This changes the interference situation seen from the considered HSDPA channel perspective. Therefore, in scenarios 3, 4 and 5 higher HSDPA data rates at cell border can be achieved.

Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5

W % W % W % W % W %

(1) Total Tx power per cell 20 100% 20 100% 20 100% 20 100% 20 100%

(2) Power for common control channels 4 20% 4 20% 4 20% 4 20% 4 20%

(3) Rel99 power 16 80% 12 60% 8 40% 4 20% 0 %

(11) Rel99 load 50% 38% 25% 13% 0%

(12) Relative Rel99 capacity (3)/(1)-(2) 100% 75% 50% 25% 0%

(4) Power for associated DCCH + HS-SCCH 0 0% 1.6 8% 1.6 8% 1.6 8% 1.6 8%

Max power for Shared Data Channels per user (HS-PDSCH)

20%

(5) Power for Shared Data Channels per user (HS-PDSCH)

0 0% 2.4 12% 4 20% 4 20% 4 20%

(6) Other power for HSDPA (%) 0 0% 0 0% 0 0% 0 0% 0 0%

(7) Total HSDPA power (4)+(5)+(6) 0 0% 4 20% 5.6 28% 5.6 28% 5.6 28%

(8) Actual total Tx power (2)+(3)+(7) 20 100% 20 100% 17.6 88% 13.6 68% 9.6 48%

Table 27 Example of different power assignment scenarios of one cell

98 DN70118376Issue 04E


Id:0900d80580787443

3.3.13 Link budget calculation for load based AMR codec selection featureThis algorithm was introduced in RU10. If the load in the cell is too high, the incoming and ongoing voice calls are switched to a lower bit rate, so that they consume less power and a higher spreading factor (less code tree consumption). If the load situation is again relaxed, the calls are switched back to the higher bit rate with better quality. The algo-rithm in the RNC switches between 2 NB-AMR speech codecs depending on the cell load (DL transmit power, code tree usage or Iub/Iur load). For the dimensioning, it is rec-ommended to use 12.2 kbit/s and 5.9 kbit/s NB-AMR codes, and as the trigger the total transmit power per cell.

The feature should be used as a capacity enhancing feature, if needed.

The only change in the link budget calculation is the choice of the bearers for the voice service. The link budget should be done for voice with 12.2 kbit/s and 5.9 kbit/s NB-AMR. With these bearers and the other bearers of the traffic model the cell range calcu-lation is done like described in this section.

The main change is the air interface capacity dimensioning, see section Load based AMR codec selection feature.

3.3.14 Link budget calculation for MIMO caseMIMO feature is introduced to increase the user peak rate up to 28 Mbps. For coverage dimensioning process, improvement in terms of cell range is expected. A single stream MIMO is expected on the cell edge. On the other hand, doubled power for CPICH has to be considered. Assuming 10% for CPICH power, the overall power for signaling increases from ~20% to ~30%.

Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5

% % % % %

Total Tx power per cell

100% 100% 100% 100% 100%

Power for Common Control Channel

20% 20% 20% 20% 20%

Rel99 power 80% 60% 40% 20% 0%

Rel99 load 50% 38% 25% 13% 0%

Relative Rel99 capacity

100% 75% 50% 25% 0%

Power for Shared Data Channels per user (HS-PDSCH)

0% 12% 20% 20% 20%

Actual Total Tx power

100% 100% 88% 68% 48%

Max data rate at cell border - HSDPA (kbps)

0 86 172 187 250

Table 28 Example of achieved HSDPA max data rate at the cell border and the Release 99 load for different power assignment scenarios

DN70118376Issue 04E

99


Id:0900d80580787443

Introducing MIMO has impact on UL maximum allowable path loss because of HS-DPCCH overhead. This slightly decreases a cell range in UL.

The expected gain from MIMO is a higher cell range in DL - fewer number of sites.

3.3.15 Link budget calculation for DC HSDPAIn theory, Dual-Cell HSDPA 42Mbps feature increases data rate up to 42 Mbps when used with 64QAM, and up to 28 Mbps when used with 16QAM. From the coverage point of view, cell range increase is expected from using DC HSDPA. This is because when a signal is being received from two cells simultaneously, we can observe multiplexing gain (frequency diversity).

For link budget calculations, it is assumed that power set by the user is split equally between two cells. User data is sent on both cells, therefore, halved data rate is used for calculations.

The introduction of DC-HSDPA has impact on the UL maximum allowable pathloss because of the HS-DPCCH overhead. It slightly decreases the cell range in UL.

The expected gain from DC-HSDPA is a higher cell range in DL - fewer number of sites.

100 DN70118376Issue 04E


Id:0900d80580743032

3.4 Traffic dimensioning - macro

Introduction to traffic dimensioningTraffic dimensioning (capacity planning), after the Link budget calculation, is the second step of the dimensioning process.

The site area and number of sites is calculated in the Link Budget to maintain coverage with certain assumptions on the traffic load (%) in uplink and downlink directions. In the Traffic Dimensioning these assumptions are checked against the traffic demand per phase and area. It is checked if the number of sites calculated by the Link Budget is suf-ficient to handle the traffic demand.

A UMTS radio network can consist of different network layers (for example Macro, Micro). The traffic dimensioning described in this document is based on one network layer: Macro.

DN70118376Issue 04E

101


Id:0900d805806f6d33

3.4.1 Input parametersIn the dimensioning phase, traffic calculation is based on the assumption that its distri-bution is flat within a certain defined environment. In this way, all sites of a particular environment carry the same load.

3.4.1.1 General parameters

PhasesA calculation is usually done for a network that lasts for a number of years. During this time, the network is built up, the number of sites increases and the traffic demand grows and changes (for example higher data rates, different bearers etc.). The stages in which a certain status is reached are called Phases. Dimensioning is usually done for each of these phases.

AreaThe planner usually plans the network for different areas.

One area is assumed to have only one clutter type (see Clutter types for a description of clutter types) and a homogenous traffic demand (volume, bearers) within the area.

The parameters in the following sections must be set per area and per phase.

3.4.1.2 Network description per area and per phaseParameters that describe the network can be divided into four groups:

• Common parameters • Link budget results • Traffic demand • QoS criteria

Common parameters

Area size Aarea [sqkm] and required coverage req_cov [%]For one area, the area size and its required coverage per phase must be known. The coverage required may change over time; it can be low at the start of the network (phase 1) and increase in the later phases.

Number of available carriers Ncarrier

The number of frequency carriers that can be used in a particular area and phase.

Features used for capacity enhancementsThe introduction of new features like Tx diversity, 64QAM, or smart antennas has an impact on the system capacity. It should be clear which features will be implemented where and for which phase of the network.

Link budget results

Site Area Asite [sqkm]This is the area of the site calculated from the link budget for the area and phase in ques-tion.

102 DN70118376Issue 04E


Id:0900d805806f6d33

Cell load uplink and downlink loadlink_Budget,UL, Loadlink_Budget,DL [%]This is the load that was assumed in the link budget calculation in Rel99 /Rel99 or HSDPA/HSUPA scenario, per cell and per carrier. It is the maximum load that is allowed in this particular area.

Traffic demandThe traffic demand can be given in different formats:

• Data volume per area [kbit] – the traffic that is generated by all subscribers in the area of a certain bearer in specific area and phase in BH.

• Data volume per subscriber [kbit] – the traffic that is generated by a single subscriber of a certain bearer in a specific area and phase in BH.

• BHCA, duration of call or session and activity, or on/off ratio per subscriber for each bearer, phase, and area.

• Throughput per area, PS traffic [kbit/s], CS traffic [kbit/s] or [Erl] – the throughput that is generated by all subscribers of a certain bearer in each area and phase in BH.

• Throughput per subscriber, PS traffic [kbit/s], CS traffic [kbit/s] or [Erl] - the through-put that is generated by a single subscriber of a certain bearer in each area and phase in BH.

• Number of Active Users per site – the number of active users of certain bearer including soft and softer handover users in each area and phase in BH.

There are different possibilities as to what the input parameter can look like to calculate the format required. A simple one is:

Number of subscribersGiven per phase and area.

Subscriber traffic model Busy hour “traffic volume” (or average throughput) per subscriber, bearer, link, phase and area.

This busy hour “traffic volume per subscriber” multiplied by the “number of subscribers” results in the required format.

If the traffic data is given per day, it is usually assumed that the busy hour is equal to 10% of it.

If the traffic data is given per month, it is usually assumed that one month has 20 to 22 days.

For the available services and more details on calculation of the traffic demand, see Traffic modelling and General network planning aspects.

Grade of service (GoS) criteriaThe grade of service requirement must be set for each bearer.

It is referred to as GoS and not quality of service (QoS), since QoS usually refers to end-to-end quality. The GoS in this document relates to the air interface only.

The type of GoS criteria depends on the traffic class of the bearer.

For the conversational and streaming class (circuit switched traffic and packet switched traffic) the criteria are as follows:

DN70118376Issue 04E

103


Id:0900d805806f6d33

Blocking probability (%)The values of the traffic demand results in an average number of simultaneous users that make a call during the busy hour. The real number of simultaneous users at a certain time varies over the busy hour. To guarantee that a call is only blocked with an upper threshold probability, the required bandwidth on air normally has to be larger than the one that is able to satisfy the average requirement.

Since RU10, streaming QoS class is introduced for HSPA services. Therefore, in addition to the best effort, the blocking probability will also be allowed for these services.

Blocking not considered If the blocking does not have to be considered, the required bandwidth on air is set to the average number of simultaneous users.

For the interactive or background class (packet oriented traffic), the criteria are as follows:

Best effortThis criterion can be assumed for all PS bearer types. No guarantee is given regarding any delay. The user will be served in the best actual possible way.

Delay [sec] A maximum delay of 95% of the packets or the mean delay of the packets regarding the air interface. The minimum value for the mean delay is 0.5 s and for the 95 percentile delay, 2 s. This delay is only related to the queuing delay on the air interface (GoS) and lower delay values should not be considered for PS services in the calculation. If the planner needs a lower delay, a circuit switched bearer should be chosen with consider-ation of 2% blocking.

104 DN70118376Issue 04E


Id:0900d805806487f7

3.4.2 Pole capacity pol_capbearer i, UL, pol_capbearer i, DL [kb/s/site]In this document, pole capacity is defined as the maximum capacity of a site for user traffic in the network per bearer.

There are two ways to find the values of pole capacity:

• Analytical calculation. • System level simulation.

Analytical approachFor the analytical approach, the dynamic and statistical processes are modelled by static and simplified parameters. Simplifications and assumptions, for example homog-enous traffic distribution, no slow fading, no mobility, no RRM algorithms, are made to provide an analytical solution. Since the coverage and the air interface dimensioning are based on homogenous network and traffic assumptions, the maximum capacity provided by analytical solution can therefore be used in the dimensioning. It also gives an indication about the capacity in the real system.

The maximum theoretical pole capacity can be calculated as follows:

NBearer,Link * RBearer * ActivityBearer

where:

RBearer – bearer data rate.

ActivityBearer – channel activity for a bearer.

NBearer,Link – maximum number of traffic channels (users) for a bearer.

The formula that describes the maximum number of traffic channels differs for UL and DL. In UL, the following parameters must be taken into account: Eb/N0, chip rate, bearer data rate, soft handover factor, channel activity, other to own interference factor and UL power rise. In DL, the following parameters must be taken into account: Eb/N0, chip rate, bearer data rate, soft handover factor, channel activity, other to own cell interference factor and orthogonality factor. For CS bearers, a blocking probability is also taken into account.

The pole capacity for Flexi and Ultra products in this document is based on the analytical approach since system level simulations are not yet available in this case.

Note that the same spectrum efficiency values that are required for the purpose of the traffic dimensioning for UMTS 2000 are assumed for the UMTS 1900, UMTS 850, and UMTS 900 bands.

Sectorization gain: pole capacity for other macro sites configurationsSpectrum efficiency values are available (simulated and calculated) in a 3 sector network deployment. In order to be able to use these values for other types of sites (omnidirectional and six sector sites), a factor called sectorization gain was introduced. The value of the sectorization gain states how much bigger the capacity of the sector-ized site is compared to the capacity of an omnidirectional site. Normally this sectoriza-tion gain is smaller than the number of sectors. Hence, the Spectrum Efficiency (value per cell) is normally highest for an omnidirectional cell and decreases with an increasing number of sectors.

Values of the sectorization gain are as follows:

spec_effomni = spec_eff3sector * 3 / Sectorisation_gain3sector

spec_eff6sector = spec_effomni * Sectorisation_gain6sector / 6

DN70118376Issue 04E

105


Id:0900d805806487f7

• for three-sector site: UL:2,78; DL:2.70 • for six-sector site: UL:4.86; DL:4.50 • for two-sector site: UL:1.93; DL:1.90

3.4.2.1 Basic channels BCbearer CS i, UL/DL

When using the Multidimensional Erlang formula (MDE), it is necessary to introduce a reference channel with a nominative bandwidth B0, since MDE delivers the result in terms of multiples of this reference channel in the trunk. In order to apply MDE, it is required to express bandwidth of each service Bi in terms of bandwidth of the reference service B0. In other words, it must be stated how many channels of the reference type are occupied per call of each service. The single channel of the reference bearer is called a basic channel (BC0). Therefore, it can be said that one basic channel represents the air interface capacity required by one user of a reference bearer.

The proper choice of the reference bandwidth B0 is a very important matter. The target is to reduce the bandwidth multiples to a minimum in order to reduce calculation load and time. The best case is to set B0 equal to the bandwidth of the bearer with the smallest bandwidth. This condition is fulfilled by the bearer that has the maximum number of users in the air interface, hence the reference channel/bearer is the bearer for which the maximum Number of Users calculated with the formula given below is the highest for particular link (uplink or downlink). The maximum Number of Users is the pole capacity of the bearer divided by the information rate of the bearer.

The number of basic channels for all other bearers in a particular link (uplink or downlink) is calculated from the ratio between the maximum Number of Users of the target bearer and the maximum Number of Users of the other bearer.

In order to improve the accuracy of the basic channels calculation and therefore the MDE calculation, and taking into account the fact that the basic channels must have an integer format, multiplication by 100 is present in the above described calculation.

Target bearer and basic channels should be identified per link for each area and phase on the basis of declared CS services.

Number_of_UsersbearerCS_i =Pole_CapacityBearerCS_i

Data_RatebearerCS_i

BCbearerCSi = roundup(Number_of_UsersTarget_bearer

Number_of_Usersbearer_i

*100)

Bearer AMR 12.2 NB-AMR 7.95 NB-AMR 5.9 NB-AMR 4.75 CS 64

Link UL DL UL DL UL DL UL DL UL DL

Pole Capacity [kbps/carrier/site] 1757 1537 1471 1487 1257 1322 1104 1259 3904 2752

Data Rate 12.2 12.2 7.95 7.95 5.9 5.9 4.75 4.75 64 64

Number of Users 144.02 126.1 185.03 187.0 213.05 224.1 232.42 265,1 61 43

Basic Channels 162 211 126 142 110 119 100 100 383 617

Table 29 Example of the basic channel calculation for a selection of bearers and vehicular A 50 km/h environment.

106 DN70118376Issue 04E


Id:0900d805807430a6

3.4.3 Dimensioning calculationIn the following sections the calculation steps for the traffic dimensioning are described. This calculation has to be done for each area and phase.

3.4.3.1 Traffic demand per siteThe number of sites Nsite in the particular area and phase is:

Nsite=Aarea/Asite*req_cov/100

The traffic demand per site, bearer, and link (throughputsite, Bearer i, UL, throughputsite, Bearer

i, D) [kbit/s/site] is:

throughputsite, Bearer_i, UL/DL=data_volarea, Bearer_i, UL/DL/3600 s/Nsite

3.4.3.2 Required bandwidth and load of individual bearer with GoS consid-erationAs mentioned in section GoS criteria, in calculations, the planner can take the “best effort”/ “blocking not considered” approach (no consideration of the GoS) or take some GoS parameters into account in the calculations.

The first approach is the easiest one: The required bandwidth of CS or PS services, in case of “best efort” or “blocking not considered”, BWsite, Bearer i, UL, BWsite, Bearer i, DL per bearer is equal to the traffic demand per site and per bearer datasite, Bearer i, UL, datasite,

Bearer i, DL.

BWsite, Bearer_i, UL/DL= throughputsite, Bearer_i, UL/DL [kbps]

For the latter approach (when the GoS parameters are considered) the required band-width is a little bit more difficult to calculate.

The Erlang B formula has to be taken for the circuit switched services.

where: throughputsite, BearerCS_i, UL/DL is expressed in [kbps]RateBearerCS_i, UL/DL is expressed in [kbps]

For packet oriented traffic dimensioning with consideration of GoS requirements (delay), the required overhead has to be determined from simulation results. A set of look up tables has been derived from numerous simulations checking the required bandwidth when transmitting different amounts of data, different bearers and considering different delay requirements.

BWsite, Bearer_i, UL/DL= throughputaite, Bearer_i, UL/DL*overhead [kbps]

The required bandwidth per bearer, calculated as shown above, should be used as input for the interface dimensioning.

In order to relate these bandwidths to the assumed traffic load in the Link Budget, they have to be transformed to load per bearer (Loadsite, Bearer_i, UL/DL ) and can be then summed up to a total load per site Loadsite, UL/DL:

BWsite, BearerCS_i, UL/DL

ERLANG_Bthroughputsite, BearerCS_i, UL/DL

RateBearerCS_i, UL/DL------------------------------------------------------------------------------- blocking_prob,⎝ ⎠⎛ ⎞ RateBearerCS_i, UL/DL⋅

=

kbps[ ]

DN70118376Issue 04E

107


Id:0900d805807430a6

Loadsite, Bearer_i, UL/DL[%]=BWsite, Bearer_i, UL/DL[kbps]/PoleCapacityBearer_i,

UL/DL[kbps/cell/Mhz]*100

Loadsite, UL/DL[%]= Σ i loadsite, Bearer_i, UL/DL[%]

3.4.3.3 Required bandwidth and load for multiple bearers with GoS consid-erationsIn Traffic dimensioning, macro, the required bandwidth is calculated individually per bearer. If GoS requirements are given per bearer, a certain multiplexing gain can be achieved as all bearers share the same resource: the air interface.

Figure GoS handling in the traffic calculation summarizes the way the GoS and the mul-tiplexing can be applied to the calculation.

For the circuit switched service the Multidimensional Erlang (MDE) formula is used. Therefore the traffic demand per site, bearer and link must be transformed in terms of number of basic channels (in subsection Basic Channels BCbearer CS i, UL/DL). These values and the necessary number of basic channels BCBearer CS i, UL/DL per bearer are the input for the MDE formula to calculate the needed number of channels (MDE_CH) with bandwidth equal to the bandwidth of reference bearer each. See Basic channels BCbearer CS i, UL/DL for reference bearer definition.

Normal MDE usage leads to a common bandwidth for all circuit switched services in terms of basic channel. However, it is required to know the bandwidth and the load per each CS bearer separately since they can be allocated on different carrier types. For example Rel99 CS bearers can be allocated on Rel99 only or Rel99/HSPA shared car-riers. Whereas, for example HSPA streaming can be allocated on HSPA only or Rel99/HSPA shared carriers. For this purpose the contribution of each bearer to MDE channels (MDE_CH) can be noticed by means of MDE factor (fMDE). MDE factor is defined as follows:

The required bandwidth and load per circuit switched services can be calculated as follows:

][_:

)_,...,_

;_

,...,_(_

_

/,_

/,_,

/,_,

_1_

/,_/,_,

/,1_/,1_,

/,,

ErlRate

throughputthroughputERLwhere

probblockingprobblocking

BCthroughputERL

BCthroughputERLERLANGMULTI

CHMDE

DLULkBearerCS

DLULkBearerCSsite

DLULkBearerCSsite

kBearerCSBearerCS

DLULkBearerCSDLULkBearerCSsite

DLULbearerCSDLULBearerCSsite

DLULCSsite

=

=

=

k

DLULkBearerCSDLULkBearerCSsite

DLULsite

DLULsiteMDE BCthroughputERL

CHMDE

/,_/,_,

/,

/,, _

_

100_/]/[[%]

_]/[

/,_/,_,/,_,

/,,/,_,/,_,/,_,

=

=

DLULiBearerDLULiBearersiteDLULiBearersite

DLULsiteMDEDLULiBearersiteDLULiBearersiteDLULiBearersite

cappolskbBWLoad

RatethroughputERLskbBW

108 DN70118376Issue 04E


Id:0900d805807430a6

Figure 36 GoS handling in the traffic calculation

If all packet oriented bearers are sharing the same resource, there is a multiplexing gain, if certain GoS requirements (delays) per bearer are assumed. This multiplexing gain is determined by an approximation. It is possible to make several worst case estimations and choose then the lowest needed resource ('best of worst').

The procedure leads to a common bandwidth for all packet switched services. However, it is required to know the bandwidth and the load per each PS bearer separately since they can be allocated on different carrier types. For example Rel99 PS bearers can be allocated on Rel99 only or Rel99/HSPA shared carriers, whereas for example HSPA can be allocated on HSPA only or Rel99/HSPA shared carriers. For this purpose the contribution of each bearer to common BW can be noticed by means of BW fraction (fBW). BW fraction is defined as follows:

where: BWmaxGoSBearerPS_i – bandwidth per bearer is calculated with assumption of the max GoS of all PS bearers.

Afterwards bandwidth and load per site per bearer can be calculated as follows:

BWsiteUL/DL, BearerPS_i = fBW, UL/DL. BearerPS_i*BWsite, PO, UL/DL

Loadsite, PO, UL/DL = BW siteUL/DL, BearerPS_i / pol_capUL/DL*100

When calculating circuit switched and packet switched bearers at the same time, the simple sum of the required bandwidths and loads is assumed for a moment. Such an approach is a bit pessimistic – no multiplexing gain considered – but at the same time, a certain safety margin is left in the calculation.

Figure Traffic dimensioning process shows the whole dimensioning process in general.

Numbers ofcarriers

Offered LoadBearer 1, CS

Offered LoadBearer i, CS

Offered LoadBearer i+1, PO

Offered LoadBearer l, PO

Mu

lti-d

ime

nsio

na

lE

rla

ng

Fo

rmu

laG

oS

:B

lockin

g

Mu

ltip

lexin

g"B

estofw

ors

t"G

oS

:D

ela

y

Required Linksor kbps

Required Linksor kbps

),...,

,,...,("__"

_1_

/,_,/,1_,

/,,

kBearerPOBearerPO

DLULkBearerPOsiteDLULBearerPOsite

DLULPOsite

delaydelay

throughputthroughputworstofbest

BW =

fBW, UL/DL, BearerPS_iBWmaxGoSUL/DL, BearerPS_i

BWmaxGosSUL/DL, BearerPS_ii∑-----------------------------------------------------------------------------------=

Loadsite, UL / DL = Loadsite,CS,UL / DL + Loadsite,PO,UL / DL

DN70118376Issue 04E

109


Id:0900d805807430a6

Figure 37 Traffic dimensioning process

3.4.3.4 Comparison of loadsThe total load per site calculated in section Required bandwidth and load of individual bearer with GoS consideration or Required bandwidth for multiple bearers with GoS considerations now has to be compared to the input parameter load (in Explanation of the used parameters) of the link budget and number of carriers (in General parameters) in the uplink and downlink direction. This has to be done in order to check if the assumed number of sites can satisfy the traffic in the particular area and phase.

If this equation is fulfilled, the air interface dimensioning is acceptable. If the equation is not fulfilled, the number of carriers has to be increased or the site area has to be reduced (see Capacity limited case (very high load) in section Where and why an optimization should be performed ) or other means for load reduction have to be taken into account.

If the calculated load per site is much smaller than the right side of the equation, then the number of carriers can be reduced in this particular area and phase or (only in special cases: very low load and Ncarrier = 1) the site area can be increased (see Coverage limited case (very low load) in Where and why an optimization should be per-formed ).

Input-common input-LiBu results-traffic model

Traffic-per bearer,phase layer, link-in kb

Traffic withGoS requirementsapplied totraffic per site

SpectrumEfficiencyValues

Pole Capacitymaximum trafficper carrier

Comparison

Results-number of sites-number of carriers-load

Loadsite, UL/DL LoadLink_Budget, UL/DL Ncarrier⋅≤

110 DN70118376Issue 04E


Id:0900d80580648811

3.4.4 Where and why an optimisation should be performed Optimization should be performed only in the following two cases:

• When capacity is limited due to a very high load. • When coverage is limited due to a very low load.

In each case, the whole link budget calculation must be redone with the new load and the results must be transferred to the new traffic dimensioning calculation.

3.4.4.1 Capacity limited case (very high load)This occurs when the number of carriers required is larger than the number of carriers available. This is the case, when the traffic taken for the calculation is very high (check that there are no mistakes in previous steps of the calculation, for both link budget and traffic). If such a situation occurs in the late phase of the network, it is possible to assume new features that increase the capacity of the air interface.

The actual load is higher than the assumed one. Such situations can happen and only a change in the number of sites will improve the situation.

The new load for the link budget has to be set higher than the previous one.

3.4.4.2 Coverage limited case (very low load)This occurs when the actual load is much smaller than the one previously assumed. This can happen if the assumed traffic is very low or the site area is very small. Check that the previous steps of calculation are correct. If they are then the overall number of sites can be reduced.

The traffic increase of the subsequent phases should be taken into account to avoid capacity limitations in later phases.

The new load for the link budget has to be set smaller than the previous one.

DN70118376Issue 04E

111


Id:0900d8058074be0c

3.4.5 HSPA traffic calculationThe traffic calculation of the HSUPA and HSDPA services is similar to the PS traffic cal-culation of the Rel99 bearers.

The difference can be seen in terms of the Load parameter for DL where, in the case of HSDPA, it should be understood as a HSDPA used capacity measure rather than an indication of the interference situation in a cell. Therefore, there is no need to limit the Load to the 50% (the usual for Rel99) but values like 100% are more likely to be used.

The HSDPA capacity used is 100% when all of the power available in the cell is used for HSDPA, that is there is no Rel99 traffic in the cell and the power available (total Tx Power minus the power required for common control channels) is used for HSDPA. The HSDPA capacity used is lower if the power for HSDPA in the cell is lower.

The following HSPA deployment scenarios can be distinguished:

• HSPA deployed on a separate carrier, • HSPA deployed on a shared carrier together with Rel99 services.

Simulations show that superposition of the relative capacities of particular services is linear in the latter scenario also. This means that there is no difference in the traffic cal-culation of mix HSPA and Rel99 services compared to the mix of Rel99 services. The load in these kinds of scenarios will vary depending on the Rel99 and HSDPA traffic share.

Loadsite,UL/DL[%] = ∑ iLoadsite, Rel99_Bearer_i, UL/DL[%] + ∑ jLoadsite,HS_Bearer_jUL/DL[%]

Loadsite, UL/DL - shared carrier load

Loadsite, HS_Bearer_jDL- used HSDPA capacity

Loadsite, HS_Bearer_jDL- used HSUPA load

The following figures come from the SL simulations in which different mixes of HSDPA and Rel99 traffic, and HSUPA and Rel99 traffic were investigated. It was checked how much of the HSDPA or HSUPA traffic can be supported by the cell by a different number of Rel99 users already present in the cell. Relation of the system load (spectrum effi-ciency) with respected percentage of AMR users, in case of HSDPA and Rel99 traffic mix, is presented in Figure Spectrum efficiency (system load) of a mix of HSDPA and Release 99 services. The resulting Spectrum Efficiency changes with the changing traffic mixes in the linear way, which proves the correctness of the equation above. Similar linear behavior of L2 cell throughput can be observed in case of HSUPA and Rel99 traffic mix.

Figure 38 Spectrum efficiency (system load) of a mix of HSDPA and Release 99 ser-vices.

200

150

100

50

0

200

kb

ps/C

ell/

MH

z

percent of AMR User

0 25 50 75

112 DN70118376Issue 04E


Id:0900d8058074be0c

Figure 39 Cell throughput of Mix HSUPA and Rel99 services (source: Nokia Siemens Networks simulation results)

Table Example of HSDPA capacity achieved for different power assignment scenarios shows how the HSDPA capacity used and the load on shared carriers is calculated based on the example from Link budget calculation for HSDPA – interference limited case.

Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5 Scenario 6

% % % % % %

(1) Total Tx power per cell

100% 100% 100% 100% 100% 100%

(2) Power for Common Control Channels

20% 20% 20% 20% 20% 20%

(3) Rel99 Power 80% 60% 40% 20% 0% 0%

(11) Rel99 load 50% 38% 25% 13% 0% 0%

(12) Relative Rel99 capacity (3)/(1)-(2)

100% 75% 50% 25% 0% 0%

(4) Power for associ-ated DCCH + HS-SCCH

0% 8% 8% 8% 8% 8%

(5) Power for Shared Data Channels per user (HS-PDSCH)

0% 12% 20% 20% 20% 20%

(6) Other power for HSDPA (%)

0% 0% 0% 0% 0% 52%

(7) Total HSDPA Power (4)+(5)+(6)

0% 20% 28% 28% 28% 80%

Table 30 Example of HSDPA capacity achieved for different power assignment scenarios.

DN70118376Issue 04E

113


Id:0900d8058074be0c

3.4.5.1 RAN1689 CS voice over HSPACS voice over HSPA is RU20 On Top release feature.

The aim of this feature is to increase the number of speech subscribers served per cell simultaneously and reduce UE battery consumption. To achieve gain from using CS voice over HSPA, compared to DCH, every HSUPA feature like gating, HARQ process restriction needs to be utilized. System level simulations show that CS voice over HSUPA UL cell capacity decreases with codec rate increase. The UL gain for AMR 12.2.over HSPA is about 45% and for AMR 5.9.over HSPA is 50% (Nokia Siemens Networks internal simulations). Since there is small difference in capacity for both codecs 12.2 and 5.9 the gains for other codes are evaluated in linear manner.

3.4.5.2 RAN1643 HSDPA 64QAM64QAM modulation enables high UE throughputs. However, it is very sensitive to radio conditions. It is granted to the users that report good CQIs (greater or equal than 26) and, most probably, takes place close to the antenna. See Table HSDPA MCS exem-plary for UE Cat 14 (Source 3GPP TS 25.214). The fact that UE experiences such a good CQIs depends on propagation environment (channel fading interference and so on). Hence the probability of 64QAM modulation usage is observed better in micro cells than in macro cells. See Figure Probability of 64 QAM usage in macro and micro cell with 6 UE in the cell. (source: Nokia Siemens Networks simulation).

(8) Actual Total Tx Power (2)+(3)+(7)

Used HSDPA capacity

100% 100% 88% 68% 48% 100%

(9) Used HSDPA capacity (7)/[(1)-(2)]

0% 25% 35% 35% 35% 100%

(10) Shared carrier load (9)+(11)

50% 63% 60% 48% 35% 100%

Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5 Scenario 6

% % % % % %

Table 30 Example of HSDPA capacity achieved for different power assignment scenarios. (Cont.)

114 DN70118376Issue 04E


Id:0900d8058074be0c

Figure 40 Probability of 64QAM usage in macro and micro cell with 6 UE in the cell. (source: Nokia Siemens Networks simulation)

Since the cell throughput in SL simulations is a statistic which is collected on a TTI basis (2ms), therewith it increases together with the growth of UEs amount. The simulation campaign shows almost no gain in mean cell throughput for macro site ~0.6%. See the following figure (a) - continuous lines. This is related to low probability of 64QAM granting fort the UE. For micro site, 64QAM modulation is more frequently sent to the UE, therefore higher gain in cell throughput can be observed ~7%. See the following figure (b) – dashed lines.

Figure 41 Average cell throughput (a) and peak UE throughput (b) with respect to the number of users in the cell for Pedestrian A 3km/h, 1RxDiv, PF scheduler, UE Cat 10 capable on 16 QAM, UE Cat 14 capable of 64QAM (source: Nokia Siemens Networks simulation)

The SL simulator collects UE throughput per UE session. If the number of UEs grows, more users share the resources, which lead to a longer session length and lower UE throughput values. See Figure Average cell throughput (a) and peak UE throughput (b) with respect to the number of users in the cell for Pedestrian A 3km/h, 1RxDiv, PF scheduler, UE Cat 10 capable of 16 QAM, UE Cat 14 capable of 64QAM (source: Nokia Siemens Networks simulation). The initial simulation campaign shows ~26% of gain in peak UE throughput in macro cells and ~32% of gain in micro cells for Pedestrian A 3km/h. The gains for higher velocities should decrease due to worse channel conditions.

Pro

babili

tyof64

QA

Musage

[%]

0

5

10

15

20

25

macro micro

DN70118376Issue 04E

115


Id:0900d8058074be0c

3.4.5.3 RAN1642 MIMOComparing to HSPA Rel6, MIMO Rel7 improves instantaneous UE throughputs (up to 28 Mbps) that results in enhancement of mean cell throughput. However, to benefit from MIMO, a good radio conditions are needed which are more likely to be achieved in low speed scenarios in micro/pico and macro cells. Also cell load, scheduling strategy, and Tx diversity approach with respect to non - MIMO UEs have a great impact on possible gains of this feature.

In section RAN1642 MIMO there are two deployment scenarios of MIMO mentioned with respect to cell configuration for non - MIMO UEs: non - Tx diversity cell and Tx diver-sity cell. For default cell configuration for the dimensioning non -Tx diversity cell is used since there are concerns that many UEs available on the market do not support Tx diver-sity scheme.

Figure Mean cell throughput gain of MIMO 2x2 (Dual Stream) over SISO in micro cell and macro cells (PF scheduler) (internal Nokia Siemens Networks simulation) shows mean cell throughput gains of MIMO 2x2 (dual stream) over SISO in Tx and non - Tx diversity cells for various cell configurations like:

– micro (Manhattan Grid, PedA3), – macro (PedA3, inter site distance (ISD) = 1000m) and – macro (VehA3, inter site distance (ISD) = 1500m).

It can be seen for both Tx diversity cell deployments for non - MIMO UEs that propaga-tion environment (for example site layout, mobile velocity) influences cell capacity. MIMO 2x2 (dual stream) brings higher cell capacity gains in micro and small macro (PedA3, ISD=1000m) cases than for macro (VehA3, ISD = 1500m) where UEs more seldom experience good radio conditions. In cells configured as Tx diversity cells, the situation improves only with respect to relative cell capacity gains.

Figure 42 Mean cell throughput gain of MIMO 2x2 (Dual Stream) over SISO in micro cell and macro cells (PF scheduler)

116 DN70118376Issue 04E


Id:0900d8058074be0c

Figure 43 Minimum penetration of MIMO UEs in micro cell and macro cells for non - Tx diversity cell

In order to ensure the same coverage for cells with and without MIMO, additional power consumption for second pilot channel (1-2 W in macro case and ~0.1 W in micro) is required in case of non - Tx diversity cell configuration. The second pilot, which cannot be used by UEs incapable of Tx diversity, causes additional interference for them and causes loss of ~8% in mean cell throughput in all considered propagation environ-ments.Taking into consideration economical purposes, non - Tx diversity cell configura-tion requires minimum number of MIMO UEs (which determines the percentage of total number of UEs in a cell) in order to compensate costs of CPICH power overhead. This relationship is different for different environments, what is shown on Figure Minimum penetration of MIMO UEs in micro cell and macro cells for non - Tx diversity cell (internal Nokia Siemens Networks simulation). The largest number of MIMO UEs is required in macro (VehA3, ISD = 1500m) case - 20% of total number of UEs. In small macro (PedA3, ISD = 1000m) and micro (PedA3) only 12%.

Figure 44 Mean cell throughput gain and peak UE throughput gain of MIMO 2x2 (Dual Stream) over SISO in macro cell (PedA3, ISD = 1000m)

Figure Mean cell throughput gain and peak UE throughput gain of MIMO 2x2 (Dual Stream) over SISO in macro cell (PedA3, ISD = 1000m) (internal Nokia Siemens

DN70118376Issue 04E

117


Id:0900d8058074be0c

Networks simulation) presents gains of mean cell throughput and peak UE throughput of MIMO 2x2 (dual stream) for macro cell with ISD = 1000m and PedA3 channel model. These gains are related to 1x1 transmitting/reception antenna schema called SISO. The mean cell throughput gain (dual stream) for non - Tx cell configuration for round robin scheduler is 94% and in case of proportional fair scheduler the gain is 56.5%. In case of Tx cell configuration these gains can be improved about 13-16% since less power can be spent on both pilot channels and there is more power available for users. Dual stream transmission brings ~8% gain for round robin and ~12% gain for proportional fair with respect to single stream transmission for both Tx diversity deployment strategies regarding non - MIMO UEs. Since the offer dimensioning is done in busy hour mainly single stream transmission is expected. Therefore, for offer dimensioning single stream gains with respect to SISO are assumed as a default MIMO gains that are in non - Tx diversity cells case as follows: 79,2% (round robin) and 40,1% (proportional fair).For both types of Tx cell configurations round robin scheduler benefits more from MIMO than proportional fair scheduler. Both more advanced scheduling type like proportional fair (channel aware scheduling) as well as MIMO (that is a combination of transmit and receive diversity techniques with/without spatial multiplexing) work to avoid conse-quences of poor radio conditions:

– proportional fair schedules on top of fades, – Tx/Rx diversity (no spatial multiplexing in case of single stream) reduces fluctuations

of fading process, whereas spatial multiplexing (brings main gains in case of dual stream) benefits from using the spectrum twice by streams separation and codes reuse.Therefore the mean cell throughput gain from any diversity technique in case of round robin scheduling is significantly higher than for proportional fair schedul-ing.Channel aware scheduling (like proportional fair) acts to UE throughput advan-tage therefore peak throughput UE gains for round robin scheduling gives smaller peak UE throughputs.

Figure 45 Probability of usage of Dual and Single Stream transmission

Figure Probability of usage of Dual and Single Stream transmission (internal Nokia Siemens Networks simulation) shows the probability of utilization of single stream and dual stream techniques during the transmission. The largest probability of use of dual stream, which allows achieving higher throughputs, appears in micro case (up to 41%) whereas in small macro case the probability is only up to 13%. The assignment of dual

118 DN70118376Issue 04E


Id:0900d8058074be0c

stream mode depends strongly on current radio conditions, which are more favorable in smaller cells - in larger cells the probability of utilization of dual stream will be smaller.The probability of use of dual stream also depends on type of scheduler. For proportional fair scheduler the probability is 41% in micro case and 13% in small macro case, for round robin scheduler adequately 32% and 7%. This situation results from use of various algorithms. Channel aware scheduling is conductive to dual stream transmis-sion therefore the probability of utilization of dual stream mode is expected to be larger for this type of scheduler.

3.4.5.4 RAN1906 Dual-Cell HSDPA 42MbpsDual-Cell HSDPA 42Mbps is RU20 On Top release feature.

DC HSDPA increases the DL UE throughput of DC-capable UEs by scheduling a transmit block for a DC HSDPA capable UE (Categories 21-24) within a single TTI on two HS-DSCHs/SCCHs of two cells. As multi-user diversity among both cells is offered because of such joint scheduling, there is also a gain in the sector pole capacity in DL (recalculated as gain in pole capacity per cell in DL) provided by the DC HSDPA feature. The average DL pole capacity gain due to DC HSDPA is mainly dependent on:

– loads in the primary serving HS cell and secondary serving HS cell (SSHSC) (the higher load, the lower DL pole capacity),

– frequency correlation within the band which includes the primary serving HS cell and SSHSC (the higher correlation the lower DL pole capacity),

– scheduling policy applied in primary serving HS cell and SSHSC (slight variations with scheduling policy),

and some other factors like receiver types (slight variations with the receiver type).

Accounting for these variations, the system level simulations indicate a gain in DL pole capacity of about 17-24% for a typical realistic interval of 15-25 users per cell. A gain factor of this order is applied to the calculation of DL pole capacity of bearers for which the DC HSDPA feature is enabled.

It has to be noted that the following restrictions apply for the configuration of the RAN1906 Dual-Cell HSDPA 42Mbps feature depending on the operator setup. The fol-lowing restrictions are applicable in RU20 On Top and may be removed in upcoming releases.

– A 4+4+4 operator can enable DC HSDPA only on two separate pairs of cells (2 times primary serving HS cell + SSHSC) within each sector. That is no overlap between different DC HSDPA cell pairs (primary serving HS cell + SSHSC) is allowed.

– A 3+3+3 operator can enable DC HSDPA only on a single pair of cells (primary serving HS cell + SSHSC) within each sector. The 3rd cell in each sector is then a legacy/non-DC HSDPA cell.

These configuration restrictions are accounted for in the computation of carrier numbers assigned to bearers with configured DC HSDPA feature (UE Categories 21-24).

DN70118376Issue 04E

119


Id:0900d805806f9ddb

3.4.6 Load-based AMR codec selection featureThe aim of this feature is to increase capacity when the load becomes too high by down-grading the bit rate of the NB-AMR voice calls. The goal of dimensioning is to provide a network with the lowest number of BTSs and the lowest configuration, which still meets the requirements in terms of, for example, performance. Thus, one topic for dimension-ing is to have a lowest number of carriers per cell, which means all carriers are fully occupied. In the busy hour the carriers are fully occupied.

The following is a description of the process for dividing the voice traffic among the 2 bit rates (12.2 and 5.9 kbit/s) for the traffic demand. This is the only change in the air inter-face traffic dimensioning.

It is assumed that the voice traffic is switched to the lower bit rate (5.9 kbit/s) from the beginning. The load conditions are then checked in the traffic dimensioning and, depending on the load of the operator's chosen trigger type (DL transmit power, code usage or Iub/Iur load) the bit rate can be adapted. As default trigger for dimensioning, it is recommended as default to use the total DL transmit power load as a trigger. This is also the assumption in the following dimensioning steps:

1. Set all voice calls to the lower bit rate (5.9 kbit/s) in the traffic demand.2. Perform the standard dimensioning process as described in the previous chapters.3. One outcome of this dimensioning is the BTS capacity per site required for the Rel99

carriers and the Rel99/HSDPA shared carriers (ReqNBCapacitysite, DL).

The HSDPA-only carriers are excluded. 4. Calculate the BTS capacity required per carrier:

5. Transfer this mean load into the mean DL Tx power load:

Note that the load of the total DL transmit power (Load DLTxpwr) due to actual traffic demand differs from the DL load (Load Link BudgetDL ) which is used in the link budget calculation. The first one is the part of the DL power which is used for all of the traffic. In the link budget, it is normally assumed that 100% is used to get the maximum cell range. The latter one DL load is used to calculate the interference in DL and is meant in terms of how much traffic is in the cell (part of pole capacity).

6. The load of the total DL transmit power ( ) also reflects the amount of actual traffic demand that fills up the carriers (that is 100%: Fully occupied). For the feature 'load-based AMR codec selection', there are three trigger points in the RNC database: one for incoming calls and two for ongoing calls (with hystersis). It is expected that the first point is between the two latter ones to avoid to much switching (signaling overhead) between the bit rates. The first one (incoming calls) can be used also in dimensioning as threshold (THNB,AMR). For the time being the default value of the first threshold is 90%.

7. If than the dimensioning is finished. All voice calls keep the lower bit rate (5.9 kbit/s)

ReqNBCapacitysite / DL

ReqNBCapacitymeancell / DL = ReqNBCapacitysite / DL / Nrel:99andshared

LoadDLTxpwr =

ReqNBCapacitymeancell/DL * (PowermaxNB - Powercontrolchannels)

PowermaxNB

Powercontrolchannels

PowermaxNB

+

LoadDLTxpwr

Loadmeancell/DL = 100%( 5%)+-

Loadmeancell_without_voice/ DL

120 DN70118376Issue 04E


Id:0900d805806f9ddb

8. If then the load part of the voice traffic and the load without voice are to be estimated.

9. If than The number of users with 12.2 kbit NB-AMR is then: (delta*polecapacity12.2kbit/s)/(12.2kbit/s*voice_activity) The rest of the users remain with the 5.9 kbit/s NB-AMR bearer: voice_user-(delta*polecapacity12.2kbit/s)/(12.2kbit/s*voice_activity)

Expected outcome:The ratio of voice users on 12.2 and 5.9 kbit/s is clarified in the traffic demand. And, if necessary, the air interface dimensioning can be repeated.

Loadmeancell/DL<100%(-5%)

delta = LoadLink_Budget/DL * ThNB_AMR - Loadmeancell_without_voice/DL

Loadmeancell_without_voice/DL < LoadLink_Budget/DL * ThNB_AMR

DN70118376Issue 04E

121


Id:0900d805806f9de4

3.5 Results of the air interface dimensioningThe following results are per area and per phase:

• number of sites • number of carriers per site • site area and cell range • cell load in uplink and downlink • bandwidth per individual bearer per site and per base station • number of base stations • site configuration:

• number of sectors per sites • number of sites served by one base station • use of RRH / feederless sites • use of TMA • antenna types

These results can be used in the dimensioning of the base station equipment (BB cal-culation – proof of the suggested site configurations), the interfaces, and the RNC.

3.5.1 Example resultsCapacity demands per bearer and site (kbps) are summarized in the following tables.

Network Layout Macro

Sites calculation

Operating band UMTS2000

Channel model Vehicular A at 3km/h

Area size (sqkm) 100

Calculation method used Standard

Number of subscribers per area 90000

Number of sites 177

Number of subscribers per site 508

Total number of cells per site 3

Total number of HSPA only carriers per site 0

Sum of cell load (%), UL 0

Sum of cell load (%), DL 0

Number of shared Rel99/HSPA carriers per site 1

Sum of cell load (%), UL 17.58

Sum of cell load (%), DL 27.04

Number of Rel99 only carriers per site 0

Sum of cell load (%), UL 0

Sum of cell load (%), DL 0

Table 31 General results summary

122 DN70118376Issue 04E


Id:0900d805806f9de4

The number of carriers of three types is calculated: number of Release 99 only, HSPA only, and shared Release 99/HSPA. In addition, the load is listed per each of the carrier types.

Pole capacity [kbps]

Service Link Bearer

Speech (1) UL AMR 12.2 1805.60

Speech (1) DL AMR 12.2 1720.20

Speech (2) UL AMR 12.2 over HSPA UL 2343.95

Speech (2) DL AMR 12.2 over HSPA DL 1682.10

VoIP (1) UL HSUPA I/B VoIP 6811.50

VoIP (1) DL HSDPA I/B VoIP 6843.00

Video telephony (1) UL CS 64 3904.00

Video telephony (1) DL CS 64 3584.00

E-mail (1) UL PS I/B 64 4102.50

E-mail (1) DL PS I/B 64 4638.00

Simple messaging (1) UL PS I/B 64 4102.50

Simple messaging (1) DL PS I/B 128 5575.50

Medium multimedia (2) UL PS I/B 64 4102.50

Medium multimedia (2) DL PS I/B 384 WWW 4857.00

File download (1) UL PS I/B 128 4833.00

File download (1) DL PS I/B 384 WWW 4857.00

High interactive MM (1) UL PS I/B 64 4102.50

High interactive MM (1) DL HSDPA I/B 6843.00

Internet access High (1) UL PS I/B 128 4833.00

Internet access High (1) DL HSDPA I/B 6843.00

Location based services (1) UL PS I/B 128 4833.00

Location based services (1) DL HSDPA I/B 6843.00

Remote modem access (1) UL PS I/B 384 WWW 4917.00

Remote modem access (1) DL HSDPA I/B 6843.00

Interactive games (1) UL HSUPA I/B 6811.50

Interactive games (1) DL HSDPA I/B 6843.00

Unspecified data (1) UL HSUPA I/B 6811.50

Unspecified data (1) DL HSDPA I/B 6843.00

Unspecified data (2) UL HSDPA I/B 6811.50

Unspecified data (2) DL HSDPA I/B 6843.00

Table 32 Pole capacity

DN70118376Issue 04E

123


Id:0900d805806f9de4

Ordered traffic per site

Service Link Bearer Unit

Speech (1) UL AMR 12.2 Erlang 5.91

Speech (1) DL AMR 12.2 Erlang 5.91

Speech (2) UL AMR 12.2 over HSPA UL Erlang 0.30

Speech (2) DL AMR 12.2 over HSPA DL Erlang 0.30

VoIP (1) UL HSUPA I/B VoIP kbps 3.85

VoIP (1) DL HSDPA I/B VoIP kbps 3.85

Video telephony (1) UL CS 64 Erlang 1.63

Video telephony (1) DL CS 64 Erlang 1.63

E-mail (1) UL PS I/B 64 kbps 24.71

E-mail (1) DL PS I/B 64 kbps 59.31

Simple messaging (1) UL PS I/B 64 kbps 10.46

Simple messaging (1) DL PS I/B 128 kbps 50.23

Medium multimedia (2) UL PS I/B 64 kbps 5.67

Medium multimedia (2) DL PS I/B 384 WWW kbps 81.66

File download (1) UL PS I/B 128 kbps 7.34

File download (1) DL PS I/B 384 WWW kbps 52.84

High interactive MM (1) UL PS I/B 64 kbps 13.98

High interactive MM (1) DL HSDPA I/B kbps 196.99

Internet access High (1) UL PS I/B 128 kbps 13.98

Internet access High (1) DL HSDPA I/B kbps 30.31

Location based services (1) UL PS I/B 128 kbps 13.98

Location based services (1) DL HSDPA I/B kbps 60.61

Remote modem access (1) UL PS I/B 384 WWW kbps 41.95

Remote modem access (1) DL HSDPA I/B kbps 15.15

Interactive games (1) UL HSUPA I/B kbps 19.99

Interactive games (1) DL HSDPA I/B kbps 18.18

Unspecified data (1) UL HSUPA I/B kbps 7.08

Unspecified data (1) DL HSDPA I/B kbps 127.29

Unspecified data (2) UL HSDPA I/B kbps 14.92

Unspecified data (2) DL HSDPA I/B kbps 36.37

Table 33 Traffic per site

124 DN70118376Issue 04E


Id:0900d805806f9de4

Capacity demand per site [kbps]

Service Link Bearer GoS

Speech (1) UL AMR 12.2 Blocking 2.0% 148.85

Speech (1) DL AMR 12.2 Blocking 2.0% 148.52

Speech (2) UL AMR 12.2 over HSPA UL Blocking 2.0% 5.65

Speech (2) DL AMR 12.2 over HSPA DL Blocking 2.0% 5.50

VoIP (1) UL HSUPA I/B VoIP Best effort 3.85

VoIP (1) DL HSDPA I/B VoIP Best effort 3.85

Video telephony (1) UL CS 64 Blocking 2.0% 214.95

Video telephony (1) DL CS 64 Blocking 2.0% 214.47

E-mail (1) UL PS I/B 64 Best effort 24.71

E-mail (1) DL PS I/B 64 Best effort 59.31

Simple messaging (1) UL PS I/B 64 Best effort 10.46

Simple messaging (1) DL PS I/B 128 Best effort 50.23

Medium multimedia (2) UL PS I/B 64 Best effort 5.67

Medium multimedia (2) DL PS I/B 384 WWW Best effort 81.66

File download (1) UL PS I/B 128 Best effort 7.34

File download (1) DL PS I/B 384 WWW Best effort 52.84

High interactive MM (1) UL PS I/B 64 Best effort 13.98

High interactive MM (1) DL HSDPA I/B Best effort 196.99

Internet access High (1) UL PS I/B 128 Best effort 13.98

Internet access High (1) DL HSDPA I/B Best effort 30.31

Location based services (1) UL PS I/B 128 Best effort 13.98

Location based services (1) DL HSDPA I/B Best effort 60.61

Remote modem access (1) UL PS I/B 384 WWW Best effort 41.95

Remote modem access (1) DL HSDPA I/B Best effort 15.15

Interactive games (1) UL HSUPA I/B Best effort 19.99

Interactive games (1) DL HSDPA I/B Best effort 18.18

Unspecified data (1) UL HSUPA I/B Best effort 7.08

Unspecified data (1) DL HSDPA I/B Best effort 127.29

Unspecified data (2) UL HSDPA I/B Best effort 14.92

Unspecified data (2) DL HSDPA I/B Best effort 36.37

Table 34 Air Interface bandwidth per site

DN70118376Issue 04E

125


Id:0900d805806f6fca

3.6 UMTS 900 - collocation scenarios with GSM 900900 MHz band (UL: 880-915 MHz, DL: 925-960 MHz) is currently used for GSM. From Flexi Multiradio BTS product in RU20 On Top and RG10 On Top releases onwards, it is possible to use 900 MHz band also for UMTS technology.

In general, UMTS 900 similar to UMTS 850, can be very attractive for operators due to better coverage possibilities comparing to UMTS 2000 (the lower wave frequency, the better propagation and penetration conditions, and thus bigger cells).

The main application of UMTS 900 brings frequency range that fits tight in frequency range used also by GSM and hence UMTS 900 can be used for collocation issues in the already existing GSM 900 networks without significant coverage mismatch and with better performance for packet services.

The main idea is that one 5 MHz band will be reserved for both technologies. Hence, the two following scenarios can be considered for neighboring cells of certain areas e.g. GSM and UMTS operate in this band or UMTS occupies this band for its purposes and GSM operates in other 5MHz band. Both possibilities are described in the two network scenarios.

3.6.1 Network scenario 1In network scenario 1, the same 5 MHz band is shared by GSM and UMTS. In urban clutter it is occupied by GSM, and in rural clutter it is used by UMTS. Such approach requires that at least one ‘guard’ site will be applied to separate regions in which both technologies use the same 5MHz band. In the ‘guard’ site this 5MHZ band cannot be used. Such approach is presented in the Figure Frequency assignment to UMTS and GSM for Network Scenario 1 and minimizes interference caused mutually by both tech-nologies. Interferences can be minimized additionally by proper antennas tilting. The planner has to pay attention if the maximum allowed signal level of GSM in UMTS sites is not exceeded and vice versa.

Figure 46 Frequency assignment to UMTS and GSM for Network Scenario 1

BandUrban

High TrafficRural

Low Traffic

2 GHZ5 MHz

900 MHz5 MHz 1

900 MHz5 MHz 2

GSM and UMTS co-located Sites

UMTS optional

GuardSite

GSM

126 DN70118376Issue 04E


Id:0900d805806f6fca

The advantage for presented deployment is that UMTS 900 offers coverage enhance-ment around 7-8 dB with respect to UMTS 2000 and offers high data rates (HSPA) com-paring to EGPRS.

3.6.2 Network scenario 2In network scenario 2, one or more 5 MHz band is reserved only for UMTS. This solution can be utilized to deliver high data rate services with WCDMA 900 to indoor users basing on GSM 900 coverage for voice service. In clutter types as urban/dense urban and rural, UMTS 900 operates in one or more 5MHz band and GSM operates on the other part of the 900 MHz band (see Figure 900MHz band sharing between WCDMA and GSM in Network Scenario 2. Planned max. configuration in RU20 On Top and RG10 On Top).

Figure 47 900MHz band sharing between WCDMA and GSM in Network Scenario 2. Planned max. configuration in RU20 On Top and RG10 On Top

In such a case “guard” sites are not required any more (see Figure Frequency assign-ment to UMTS and GSM for network scenario 2). Sharing the same frequency band among GSM and WCDMA introduces another restriction - carriers separation to prevent interference problem (3GPP recommends 5.4MHz spacing between WCDMA and GSM). Carriers separation implies WCDMA bandwidth reduction to 4.2MHz - it requires use of advanced WCMDA filters and coordinated GSM-WCDMA planning.

For such network deployment the following impact on both networks can be expected:

– Weaker GSM signal strength for co-located network; but it is still sufficient to ensure coverage for GSM and very good quality of voice service.

– Small performance decrease for data services in GSM can be expected, whereas UMTS shows higher UE throughputs

– UE throughputs for UMTS can be increased by optimization of antenna system. Unfortunately such treatment does not improve performance of data serviced in GSM.

GSM capacity in presented scenario can be boosted by the following:

– Frequency hopping techniques– Discontinuous transmission– Adaptive multi-rate (AMR) speech– Coding and dynamic frequency channel allocation (DFCA)

DN70118376Issue 04E

127


Id:0900d805806f6fca

Figure 48 Frequency assignment to UMTS and GSM for network scenario 2

The presented scenario can bring such advantages for the operators as: better coverage probability, deeper indoor coverage, and higher data rates for indoor user. Additional benefit of this solution is the Flexi Multiradio BTS use, which contains WCDMA and GSM/EDGE System Modules - utilization of the same radio modules, antennas, antenna lines, and power systems implies lower costs due to energy saving, site rental, and transmission (separate logical backhaul connections like Abis, Iu, and S can be carried through the same physical link to radio controllers and servers).

128 DN70118376Issue 04E


Id:0900d80580785e8c

BTS baseband dimensioning

4 BTS baseband dimensioning

4.1 Baseband Dimensioning in this releaseThe dimensioning guidelines presented in this chapter are related to Flexi WCDMA BTS and UltraSite WCDMA BTS dimensioning in the RU20 and RU20 On Top system release covering WBTS6.0 releases.

DN70118376Issue 04E

129


Id:0900d80580787483

4.2 RU20/RU20 On Top feature highlight and HW dependenceThe RU20 and RU20 On Top bring a lot of new features which improving network quality and the end user experience. Most of the new features influence HSPA performance, significantly increasing user throughput and improving baseband allocation.

RAN1643 HSDPA 64QAMThis feature introduces the possibility of using 64QAM modulation for HSDPA. In 64 QAM modulation 6 bits are sent per one symbol and, therefore, in very good radio con-ditions, throughput up to 21.1 Mbps per user is possible at the physical layer.

RAN981 HSUPA 5.8Mbps and RAN 1470 2ms TTIThese features increase the HSUPA data rate. Using 2ms TTI and 2*SF2 + 2*SF4 codes, it is possible to achieve up to 5.8 Mbps. RAN 1470 2ms TTI introduces mapping of SRB on E-DCH.

RAN1202 24kbps paging channelThis features increases the paging channel data rate to 24kbps. When the 24kbps paging channel is activated, it is mapped onto its own SCCPCH (previously it was mapped together with FACH on one SCCPCH). At least 2 SCCPCH must be configured for this feature. Depending on operators needs, it is possible to switch between 8 and 24 kbps paging channel data rate.

RAN1689 CS voice over HSPA (RU20 On Top)CS voice over HSPA introduces the possibility of using shared HSPA transport channels for carrying AMR voice frames instead of dedicated R99 DCH transport channels. Com-paring to VoIP, this feature does not need the robust header compression algorithm (ROHC), and it does not contain IP header overhead. CS voice over HSPA is activated only with SRB carried on HS-DSCH in DL and E-DCH in UL. The aim of this feature is to increase the number of speech subscribers served simultaneously per cell and to reduce the UE battery consumption.

RAN1644 Continuous packet connectivityThe CPC feature introduces discontinuous uplink DPCCH transmission and discontinu-ous downlink reception with HSPA. CPC has also two sub-features - DPCCH gating (UL DTX) and CQI reporting reduction.

RAN1638 Flexible RLCWith this feature, it is possible to achieve high data rates while reducing protocol overhead and padding by applying flexible RLC PDU sizes in the downlink.

RAN1201 F-DPCHThis feature allows putting all DL traffic on HS-DSCH in a code-efficient way by replacing the dedicated DL DPCCH (one SF256 code for each UE) with a 2-bit slot carrying TPC on a shared code (one SF256 code for 10 UEs). F-DPCH is only supported with SRBs on HSPA.

RAN1686 72 HSPA users per CellThe simultaneous number of HSPA (HSDPA and HSUPA) users is increased to 72 users per cell. In order to be able to schedule and control an increased number of HSPA users in a cell, the number of HSPA control channels has been increased (4 HS-SCCHs and 4 E-RGCH/E-HICH).

130 DN70118376Issue 04E


Id:0900d80580787483

RAN1642 HSDPA MIMOBecause of the 2x2 MIMO system (two transmit antennas at BTS and two receive antennas at the UE side) 28 Mbps peak HSDPA data rate with 16QAM can be achieved for UE cat. 16 (23,4 Mbps UE cat. 15) with very good radio conditions (dual stream trans-mission). Because of the single stream transmission, MIMO can enable increased throughput at the cell edge or an increased cell range. In RU20 main release, the MIMO feature is supported only with the Full baseband scheduler (a cell dedicated scheduler). In RU20 On Top release, the cell-dedicated (Full baseband) as well as shared scheduler (Shared HSDPA scheduler for baseband efficiency) support the MIMO feature.

Note that HSDPA MIMO can be used only with HSUPA service (UL: HSUPA bearer, DL: HSDPA bearer).

RAN1906 Dual-Cell HSDPA 42Mbps (RU20 On Top)The purpose of Dual-Cell HSDPA feature is to increase the average HSDPA throughput by pooling the shared channels of two cells. The HSDPA DL transmit block predestined for a UE within a single TTI is split across two adjacent in frequency cells form the same sector and frequency band. To properly split UE transmit block and control data trans-mission across two cells, a shared scheduler is required (Shared HSDPA Scheduler for Baseband Efficiency).

Dual-Cell HSDPA can be used together with 64QAM, enabling the peak data rate of 42 Mbps.

Most of presented RU20/RU20 On Top features require Rel2 HW (multimode system modules / EUBB). For HW requirements, see Table RU20/RU20 On Top Features and HW dependence.

Feature Flexi Rel1 HW (FSMB)

Flexi Rel2 HW (FSMC/FSMD/

FSME)WSPC

Enhanced Ultra Site BaseBand

(WSPF)

RAN1643 HSDPA 64QAM - x - x

RAN1689 CS voice over HSPA - x - x

RAN1470 HSUPA 2ms TTI - x - x

RAN1644 continuous packet connectivity - x - x

RAN1202 24kbps paging channel x x x x

RAN981 HSUPA 5.8 Mbps - x - x

RAN1638 flexible RLC - x - x

RAN1201 F-DPCH - x - x

RAN1686 HSPA 72 users percell - x - x

RAN1642 MIMO - x - x

RAN1906 Dual-Cell HSDPA 42Mbps

- x - x

Table 35 RU20/RU20 On Top Features and HW dependence

DN70118376Issue 04E

131


Id:0900d80580787483

x applicable to a given HW

132 DN70118376Issue 04E


Id:0900d8058079ccef

4.3 Dimensioning Flexi WCDMA BTSA new Base Transceiver Station (BTS) type, Flexi WCDMA BTS has been available since RAS05.1. Flexi Wideband Code Division Multiple Access (WCDMA) BTS is a new, truly modular, very compact, and high capacity wide-area WCDMA BTS that can be used in various indoor and outdoor installation options (such as floor, wall, stand, pole, mast, cabinet, 19" rack) and site applications (mini, macro, and distributed site solution).

This solution can also be used as a multimode upgrade to existing UltraSite EDGE BTS with WCDMA carriers.

Flexi WCDMA BTS consists of the following self-supporting BTS modules:

• Radio module: provides the radio frequency (RF) functionality. Maximum 3 RF modules can be directly connected to the Basic System Module.

• System module: provides the baseband processing as well as the control and trans-mission functionality. System module capacity depends on system module type, for details, see Flexi WCDMA BTS capacity. The number of CE activated can be increased by license control.

• Baseband extension module: where two system modules in one BTS Flexi System Extension Kit cable set (FSKA) are required.

Figure 49 Flexi WCDMA BTS modules

Flexi Rel1 System Module (FSMB) has three submodules, each having a capacity of 80 CE as described in the following figure:

ExtensionSystem Module

BTS SystemModule

RF Module

RF Module

RF Module

AC(Optional)

AC > DC BBU

DN70118376Issue 04E

133


Id:0900d8058079ccef

Figure 50 FSMB System Module structure

Figure 51 FSMC System Module structure

Flexi Rel2 Multimode System Module FSMC has one submodule, which has 180 CE capacity for traffic use (Figure FSMC System Module structure).

134 DN70118376Issue 04E


Id:0900d8058079ccef

Figure 52 FSMD System Module structure

Flexi Rel2 Multimode System Module FSMD has two submodules and 396CE capacity for traffic use (Figure FSMD System Module structure).

DN70118376Issue 04E

135


Id:0900d8058079ccef

Figure 53 FSME System Module structure

Flexi Rel2 Multimode System Module FSME has three submodules and 612CE capacity for traffic use (Figure FSME System Module structure).

4.3.1 Flexi WCDMA BTS capacityThere are four types of RF Modules available:

• Release1 Single RF Module (50W – FRxB, FRGD, FRGK, FRGM – supporting one sector)

• Release1 Dual RF Module (50W – FRxA, FRGC, FRGJ, FRGL – supporting one or two sectors)

• Release2 Triple RF Module (70W - FRGF – supporting one, two, or three sectors) • Release2 RRH Module (70W - FRGG - supporting 1 sector)

Flexi WCDMA BTS provides 12-cell capacity. Up to six sectors two carriers and up to three sectors and four carriers per configuration are supported by the hardware. The output power options minimum 8/15/20/30/40W or 60W (depending on the RF module) are available.

For more specific information related to RU20/RU20 On Top supported configurations, see Cabling the Flexi WCDMA BTS and Creating Configurations and Commissioning Flexi WCDMA BTS documents.

In RU20/RU20 On Top release (WBTS6.0), the following Flexi System Modules are available:

• FSMB System Module (Rel1 HW) • FSMC Flexi Multimode BTS System Module (Rel2 HW) • FSMD Flexi Multimode BTS System Module (Rel2 HW)

136 DN70118376Issue 04E


Id:0900d8058079ccef

• FSME Flexi Multimode BTS System Module (Rel2 HW)

The SW capacity of Flexi Multimode BTS System Modules (FSMC, FSMD and FSME) for 3 * 20km cells or 6*10km cells is as follows:

• FSMC - 180 CE for traffic use • FSMD - 396 CE for traffic use • FSME – 612 CE for traffic use

CE for common control channels for 3 * 20km cells or 6*10km cells per system module are included in System Module Rel2.

Rel1 HW System Module FSMB is also available in the RU20/RU20 On Top release with the same SW capacity as in RAS06/RU10 (240CE).

If a higher CE capacity is required, it is possible to have another Flexi WCDMA BTS System Module as an extension in one Flexi BTS.

Rel2 HW system modules (FSMC, FSMD and FSME) can be offered as a capacity extension for Rel1 HW System Module (FSMB).

In RU20 On Top release HW release mix case (one LCG), System Module Rel2 is selected for CCCH CE allocation, unless a frequency layer mapping to HW is used. For details, see section Common control channels. Therefore, the following maximum CE capacities are available for traffic use with 2 System Modules in one BTS:

• FSMB + FSMC: max. Site capacity 420 CE (= 240 CE + 180 CE)* • FSMB + FSMD: max. Site capacity 636 CE (= 240 CE + 396 CE)* • FSMB + FSME: max. Site capacity 852 CE (= 240 CE + 612 CE)* • FSMC + FSMC: max. Site capacity 360 CE (= 180 CE + 180 CE) • FSMC + FSMD: max. Site capacity 576 CE (= 180 CE + 396 CE) • FSMD + FSMD: max. Site capacity 792 CE (= 396 CE + 396 CE) • FSMC + FSME: max. Site capacity 792 CE (= 180 CE + 612 CE) • FSMD + FSME: max. Site capacity 1008 CE (= 396 CE + 612 CE) • FSME + FSME: max. Site capacity 1224 CE (= 612 CE + 612 CE)

* CCCH CE allocated at System Module Rel2 (FSMC/D/E)

Rel1 System Module (FSMB) cannot be used as a capacity expansion of Rel2 System Modules (FSMC, FSMD, and FSME).

The software uses the whole CE capacity (from the basic and extension System Modules) up to the license capacity. There is no need to dedicate any CE to the Basic System Module and Extension Module.

For commissioning purposes, all licenses (including CE licenses) are activated for a 14 days’ period.

4.3.2 Common control channelsThe following DL common control channels are supported per each cell in BTS:

• 1 x P-SCH • 1 x S-SCH • 1 x P-CCPCH • 1 x P-CPICH • 1 x PICH • 1 x AICH

DN70118376Issue 04E

137


Id:0900d8058079ccef

• 3x S-SCCPCH

In UL, resources for processing of PRACH channel per each cell are required.

The cells with ranges bigger than 20 km are called extended cells. Required baseband resources for common control channels for extended cells are described in section Extended cell in Flexi WCDMA BTS.

4.3.2.1 CCCH requirements for Multimode System ModulesBasic Operating SW (OSW) of the Flexi Multimode System Module FSMC/FSMD/FSME covers common control channels according to the following information.

Rel2 HW System Modules (FSMC, FSMD and FSME) provide processing resources for common control channels for basic configurations.

This is the list of typical configurations covered by CE resources included in System Modules Rel2.

• 1 * System Module: 3 cells/20 km (for example 1+1+1 with 20 km cells) • 1 * System Module: 6 cells/10 km (for example 2+2+2 with 10 km cells) • 2 * System Module: 6 cells/20 km (for example 2+2+2 with 20 km cells) • 2 * System Module: 9 cells/10 km (for example 3+3+3 with 10 km cells) • 2 * System Module: 12 cells/10 km (for example 4+4+4 with 10 km cells)

Other basic configurations that can be served only with CE resources included in Rel2 HW System Modules can be determined with the formula:

where:

i number of cells (1 =< i =< 6)

Cell range user cell radius in kilometers

# of Signatures the maximum number of preamble signatures 1 =< z =< 4

where:

0 km < r < 60 km # of Signatures = 4

60 km < r <= 120km #_of Signatures = 2

120 km < r < 180km #_of Signatures = 1

If the condition is fulfilled, then common control channels included in Release 2 HW System Modules are able to serve investigated configuration and there is no need to license additional CE.

In certain cases where a longer cell radius is required, more CE capacity might need to be licensed as follows:

• 6 cells/20 km cell radius with 1*Rel2 System Module: 36 CE license key needed • 9 cells/20km with 1*Rel2 System Module: 72 CE license key needed • 12 cells/20 km with 1*Rel2 System Module: 108 CE license key needed • 9 cells/20 km cell radius with 2*Rel2 System Modules: 36 CE license key needed • 12 cells/20 km cell radius with 2*Rel2 System Modules: 72 CE license key needed

138 DN70118376Issue 04E


Id:0900d8058079ccef

4.3.2.2 CCCH requirements for System Module Rel1In case of System Module Rel1 (FSMB), depending on the cell number, the following quantity of CEs for CCCH is needed:

– 1 - 3 cells - 26CE– 4 - 6 cells - 52 CE– 7 - 9 cells - 78 CE

Basic Operating SW (OSW) of the Flexi WCDMA BTS System Module FSMB includes 32 CE which can be activated without a license. This offers 26 CE capacity for common control channels + 6 CE for traffic channels.

4.3.2.3 CCCH resources allocation detailsCCCH baseband requirements depend on the system module release used for CCCH processing. The details presenting CE consumptions for CCCH processing are pre-sented in section CCCH requirements for Multimode System Modules and CCCH requirements for System Module Rel1.

In RU20/RU20 On Top release, for system module release mix case (FSMB + FSMC/D/E), System Module Rel2 is selected for CCCH processing (unless the fre-quency layer mapping to HW or local cell grouping (LCG) is used - see Local cell grouping for Flexi BTS).

Table CCCH CE for FSMB+FSMC/D/E configuration and cell range <10 km presents the required CCCH CE capacity that needs to be licensed for the FSMB+FSMC/D/E configuration and cell range up to 10km.

When a local cell grouping is used, each LCG has to provide CCCH processing resources for cells that are dedicated to a particular LCG. Note that in the case of a mixed system module release scenario (FSMB + FSMC/D/E), a maximum of two LCGs can be created. For more information on local cell grouping for Flexi BTS, see section Local cell grouping for Flexi BTS.

Table CCCH CE for FSMB+FSMC/D/E configuration and cell range <10 km presents CCCH processing resources that need to be licensed in a system module release mix case.

* CEs for common control channels for 3*20 km cells or 6*10 km cells per system module are included into the module.

Number of cells Number of LCGs

CCCH CEs allocated at FSMB

CCCH CEs allocated at FSM/D/E

1...3 (for example 1+1+1) 1 0 0* (1+1+1)

4...6 (for example 2+2+2) 1 0 0* (2+2+2)

4...6 (for example 2+2+2) 2 26 (1+1+1) 0* (1+1+1)

7...9 (for example 3+3+3) 2 26 (1+1+1) 0* (2+2+2)

7...9 (for example 3+3+3) 2 52 (2+2+2) 0* (1+1+1)

10..12 (for example 4+4+4) 2 52 (2+2+2) 0* (2+2+2)

Table 36 CCCH CE for FSMB+FSMC/D/E configuration and cell range <10 km

DN70118376Issue 04E

139


Id:0900d8058079ccef

Baseband resources allocation for CCCH processing can depend on frequency layers mapping to system modules. Note that the frequency layer mapping to system module is not mandatory.

In RU20/RU20 On Top release, with a commissioning parameter Mapping HSPA cell to HW, operator can map HSPA frequencies to different system modules (at least one System Module Rel2 is required). Some frequencies can be mapped to one system module and other frequencies to another system module.

If some frequency layer is mapped to a system module, the selected system module has to provide common control channels, HSUPA, and HSDPA processing resources for cells from assigned frequency layer. In this case, DCH users from assigned frequency layer are also allocated at a selected system module. However, when the full system module capacity is occupied, new DCH users can be allocated at the second system module.

Figure 54 Frequency layers mapping to system modules

If the frequency mapping is used, selected system module has to provide baseband resources for CCCH processing according to a number of cells mapped to the system module.

For example:

1. Site with two carriers (for example 2+2+2 /10km) and Flexi WBTS FSMB+FSMD Frequency layer #1 is mapped to FSMB (1+1+1) - 26 CE UL/DL for CCCH process-ing requiredFrequency layer #2 is mapped to FSMD (1+1+1) - 0 CE UL/DL for CCCH processing required

2. Site with two carriers (for example 2+2+2 /10km) and Flexi WBTS FSMB+FSMD Frequency layer #1 and layer #2 are mapped to FSMD (2+2+2) - 0 CE UL/DL for CCCH processing required

Table CCCH CE for FSMB+ FSMC/D/E configuration and cell range <10km using Mapping HSPA cell to HW commissioning parameter presents required CE capacity for CCCH processing that needs to be licensed for FSMB+FSMC/D/E configuration and cell range up to 10km when the frequency layer mapping is used.

140 DN70118376Issue 04E


Id:0900d8058079ccef

* CEs for common control channels for 3*20 km cells or 6*10 km cells per system module are included into module.

4.3.2.4 Local cell grouping for Flexi BTSLocal cell grouping is needed in large configurations and can be used in multi-operator RAN (MORAN) cases to divide Local cell groups (LCGs) baseband (BB) capacity. It is possible to use MORAN without Local cell grouping and dedicated baseband allocation.

In release WBTS6.0, Local cell grouping for Flexi BTS is needed in a case of more than 6 cells per BTS are configured or if more than two cells are configured using Antenna 1 and Antenna 3 for cell from same Rel1 dual radio module (see Figure Dual radio module, sector configuration type B). It is possible to allocate baseband capacity for LCGs also in the case where same site is divided between several operators (MORAN) and operator want to reserve some dedicated BB capacity for own use.

Figure 55 Dual radio module, sector configuration type B

Number of cells Number of LCGs

CCCH CEs allocated at FSMB

CCCH CEs allocated at FSMC/D/E

1…3 (for example 1+1+1) 1 0 0* CE (1+1+1, carrier 1 mapped to Extension Module or frequency layer mapping not used)

1…3 (for example 1+1+1) 1 26 (1+1+1, carrier 1 mapped to Master Module)

0

4…6 (for example 2+2+2) 1 0 0* CE (2+2+2, carrier 1 and 2 mapped to Extension Module or frequency layer mapping not used)

4…6 (for example 2+2+2) 1 26 (1+1+1, carrier 1 mapped to Master Module)

0* CE (1+1+1, carrier 2 mapped to Extension Module)

Table 37 CCCH CE for FSMB+ FSMC/D/E configuration and cell range <10km using Mapping HSPA cell to HW commissioning parameter

DN70118376Issue 04E

141


Id:0900d8058079ccef

In Local cell grouping, some of the cells are dedicated to Master System Module and some of the cells to Extension System Module depending on the HW that is used. For more information see the following paragraphs and Commissioning WCDMA BTS. One frequency layer cells must be dedicated to same (LCG) local cell group.

Each LCG covers certain baseband capacity which is used to serve CCCH and traffic requirements from dedicated cells. In the case where one of the system modules is Rel1 (FSMB) or at least one RF Module is Rel1, the available baseband capacity is shared between LCGs according to the system module capacity, that is in MORAN case operator #1 (LCG#1) has the capacity of the 1st system module and operator #2 (LCG#2) has the capacity of the 2nd system module. In the case where a single operator creates 2 LCGs (for example more than 6 cells required) first LCG covers the capacity of the 1st system module and second LCG covers the capacity of the 2nd system module.

In the case where both system modules are Rel2 (FSMC/FSMD/FSME) and all RF modules are Rel2 or Multi Carrier RRHs, the BB capacity can be freely dedicated among the LCGs (operators), by defining in commissioning the LCG access to baseband through Access baseband capacity commissioning parameter. The Access baseband capacity commissioning parameter is used to divide the baseband HW for LCGs from 1% to 99%. Actual allocation is done according the rule that at least one subunit (36CE) is allocated to each LCG. The percentage division is rounded to the nearest subunit amount.

For example:A site with three carriers (3+3+3) is used by one operator. The site configuration is:

FSME (612CE) + FSMD (396CE) and all RF modules are Rel2.

Since only HW Rel2 is used, the BB capacity can be freely dedicated among LCGs by defining in commissioning the percent-based division of available BB capacity.

The operator decides to dedicate 16% of BB capacity to LCG1 and 84% to LCG2.

LCG1 BB capacity = round(1008CE *16% / 36CE(subunit capacity)) * 36CE(subunit capacity) = round(161CE/36CE) * 36CE = round(4.48)*36CE = 4*36CE = 144 CE

LCG2 BB capacity = round(1008CE *84% / 36CE(subunit capacity)) * 36CE(subunit capacity) = round(846CE/36CE) * 36CE = round(23.52)*36CE = 24*36CE = 864 CE

In case of pure Rel2 HW (system modules and RF modules), up to 4 LCGs (in MORAN case, 4 operators) can share the baseband capacity.

In case of Rel1 HW (system modules and RF modules), up to 2 LCGs (in MORAN case, 2 operators) can share the baseband capacity.

For dedicating the CE license capacity usage between the operators, in MORAN case, it is possible to define in commissioning the dedicated license capacity (Dedicated baseband capacity parameter) which is optional. With this allocation, operator can allocate to LCG guaranteed amount of CE licenses. It is possible to guarantee for example 20% of licenses to operator #1 (LCG#1) and operator #2 (LCG#2) and then 60% of licenses are in use of both operators (common CE license pool).

It is also possible to use dedicated CE license capacity in single operator case (if more than one LCG is available) for example if operator wants to prioritize traffic from certain carrier(s) (LCG).

142 DN70118376Issue 04E


Id:0900d8058079ccef

For example:Site with two carriers (2+2+2) is shared by two operators. Site configuration is:

a) FSMB + FSMD (2 LCG), 400 CE licenses

b) FSMD + FSMD (2 LCG), 500 CE licenses

Site with three carriers (3+3+3) is shared by two operators (operator #1 - 1+1+1, operator #2 - 2+2+2):

c) FSME (2 LCG) 500 CE licenses

For all cases, both operators agreed to share CE licenses 20% to 40% as the dedicated capacity and the rest as a common capacity.

In the result in case a: 80 CE licenses (20%) are dedicated to operator #1 and 160 CE licenses (40%) are dedicated to operator #2. The rest of available CE licenses – 160 (40%) can be shared by both operators (accessed by both operators by first come – first served principle).

Because System Module Rel1 is used in case a, LCG#1 (operator #1) has the capacity of the first system module (FSMB – 240CE) and LCG#2 (operator #2) has the capacity of the second system module (FSMD – 396CE).

Figure 56 Example of MORAN case – Flexi FSMB+FSMD

In case b: 100 CE licenses (20%) are dedicated to LCG#1 (operator #1) and 200 CE licenses (40%)are dedicated to LCG#2 (operator #2). The rest of available CE licenses – 200 (40%) can be shared by both LCGs (accessed by both operators by first come – first served principle). Because both system module are Rel2 (as well as RF modules), the BB capacity can be freely divided between the LCGs. In this example, the LCG#1 (operator #1) has the capacity of 324CE and the LCG#2 (operator #2) has the capacity of 468 CE.

DN70118376Issue 04E

143


Id:0900d8058079ccef

Figure 57 Example of MORAN case – Flexi FSMD+FSMD

In case c: 100 CE licenses (20%) are dedicated to LCG#1 (operator #1) and 200 CE licenses (40%) are dedicated to LCG#2 (operator #2). The rest of available CE licenses – 200 (40%) can be shared by both LCGs (accessed by both operators by first come – first served principle). Because System Module Rel2 is used (as well as RF modules), the BB capacity can be freely divided between the operators. In this example the LCG#1 (operator #1) has the capacity of 180CE and the LCG#2 (operator #2) has the capacity 432 CE.

Figure 58 Example of MORAN case – Flexi FSMD

For more detailed information related to Local cell grouping see Commissioning Flexi WCDMA BTS.

144 DN70118376Issue 04E


Id:0900d8058079ccef

4.3.2.5 Capacity licensesThe Flexi WCDMA BTS licensed capacity defines the capacity that the operator has pur-chased. The licensed capacity can be less than the maximum hardware capacity.

The Flexi WCDMA BTS baseband capacities are allocated according to the capacity license file. Since the ATM Cross-Connection (AXC) and the BTS exist in high volumes in the network, Nokia Siemens Networks does not generate licenses for these network elements directly (NE licenses), but uses pool licenses. This means that the user gets the license to use a dedicated amount of features or capacity (pool license) and it is up to the user to determine how these NE licenses are distributed towards the network ele-ments.

As an example, operator buys a pool license for 10000 CE for BTSs. The operator gets a pool license file that allows using this capacity. With this pool license and the help of the license management tools in NetAct, one can distribute the capacity according to the capacity needs, for example, 120 CE for BTS-1, 70 CE for BTS-2, and so on. For this purpose, NetAct generates the appropriate license files and downloads them to the network elements.

Note that BTS software allocates the resources for the whole BTS capacity and the amount of licenses does not limit that.

4.3.3 Dedicated channelsFor baseband dimensioning purposes, a certain number of CE per each active DCH user is required. Baseband resources are required for each DCH active user in a “no handover” state and for each DCH user in a “soft handover” state. Any additional baseband resources are required neither for users in softer handover state nor com-pressed mode.

The number of CE depends on the RB type and the minimum SF. Tables Baseband resources required per one Rel99 traffic channel in RU20 and RU20 On Top (System Module Rel1), Baseband resources required per one Rel99 traffic channel in RU20 (System Module Rel2), and Baseband resources required per one Rel99 traffic channel in RU20 On Top (System Module Rel2) list the required number of CE per each active connection in the RU20 and RU20 On Top release for a basic set of RABs.

RAB Traffic class CS /PS Max rates for each RAB, kbps

Min. SF Required CE per connection

UL DL UL DL

AMR Speech Conversational CS 12.2 64 128 1 1







Table 38 Baseband resources required per one Rel99 traffic channel in RU20 and RU20 On Top (System Module Rel1)

DN70118376Issue 04E

145


Id:0900d8058079ccef

Packet Interactive/Background PS 16 64 128 1 1






UDI Conversational CS 64 16 32 4 4

Streaming Streaming CS 57.6 16 32 4 4




UL DL UL DL

Table 38 Baseband resources required per one Rel99 traffic channel in RU20 and RU20 On Top (System Module Rel1) (Cont.)



UL DL UL DL

















Table 39 Baseband resources required per one Rel99 traffic channel in RU20 (System Module Rel2)

146 DN70118376Issue 04E


Id:0900d8058079ccef

Asymmetric UL/DL CE AllocationAsymmetric UL/DL allocation means that the UL and DL directions have different bit rate requirements. The rule for allocating Submodule resources for asymmetric bit rates is based on a higher data rate requirement, but CE reservations are done separately for UL and DL. For example, if the UL bearer is 64 kbps and DL bearer is 384 kbps, the CE reservation is four CE in UL and twelve CE in DL (FSMC/D/E).

The UL and DL resources have to be allocated inside one submodule, but there is no direct connection between UL and DL resources allocation. In other words, UL and DL resources do not have to be allocated symmetrically across the submodule UL and DL capacity (see Figure Example of CE allocation)

Figure 59 Example of CE allocation

RAB Traffic class CS /PS Max Rates for each RAB, kbps


UL DL UL DL

















Table 40 Baseband resources required per one Rel99 traffic channel in RU20 On Top (System Module Rel2)

DN70118376Issue 04E

147


Id:0900d8058073d75a

4.4 Dimensioning UltraSite WCDMA BTSThe RU20 introduces new Enhanced UltraSite Baseband (EUBB) which enables high capacity upgrade for UltraSite WCDMA BTS and ensures evolution towards HSPA+ fea-tures.

EUBB consists of the following high capacity plug-in units:

• WSPF - a new baseband processing unit • WSMF - a new routing, summing and multiplexing unit • AXCF - a new transmission unit

In RU20/RU20 On Top, one EUBB subrack per UltraSite WCDMA BTS is allowed. EUBB subrack can contain up to 3 WSPF cards. For more detailed information concern-ing EUBB see UltraSite EUBB WCDMA BTS product description.

The RU20 provides significant improvement in UltraSite baseband capacity because of EUBB.

The traffic capacity for EUBB subrack is:

– 1 WSPF card - 180 CE for traffic use– 2 WSPF cards - 396 CE for traffic use– 3 WSPF cards - 612 CE for traffic use

EUBB subrack provides CE resources for common control channels for:

• 3 cells/20 km (for example 1+1+1 with 20 km cells) • 6 cells/10 km (for example 2+2+2 with 10 km cells)

In addition to WSPF (EUBB subrack), two other types of WSP cards (WSPA/WSPC) introduced in the past are available in RU20/RU20 On Top release with the same capacity as in RAS06/RU10 releases.

Figure UltraSite WCDMA BTS architecture shows exemplary UltraSite WCDMA BTS with EUBB subrack.

Wideband signal processor A (WSPA) and wideband signal processor C (WSPC) capacities are presented in section WSPA/C/F processing capacity.

148 DN70118376Issue 04E


Id:0900d8058073d75a

Figure 60 UltraSite WCDMA BTS architecture

UltraSite WCDMA BTS units are explained in the following table.

WSMB WSP WSPWSPWSPWSPWSP

WAM WAM

R-bus

DSC-bus

WSMB WSP WSPWSPWSPWSPWSP

WAM WAM

AXU

IFUIFUIFU Iub

AXCF

WAF

WPA

WTR

WSMF

WAF

WPA

WTR

RR-bus

WSPF WSPFWSPF

WAMA

SR-bus ST-bus

Eth

ern

et

Iub

WSCREDU

WSCMAIN

WSC

GPS

RRH/RFM R P3R P3-01

R P1 R P2

R P 1 R P2R P1

EUBBR P3-01

R P3-01RRH/RFM

RRH/RFM

RT-bus

RR-bus

RT-bus

RR-bus

RT-bus

RR-bus

RT-bus

WAF

WPA

WTR

WAF

WPA

WTR

WAF

WPA

WTR

WAF

WPA

WTR

R-bus

DSC-bus

RR-bus

RT-bus

RR-bus

RT-bus

SR-bus ST-bus

SR-bus ST-bus

Unit Description

WAF Wideband Antenna Filter. Combines and isolates Tx/Rx signals and amplifies the signals received. One WAF is required per sector.

WPA Power Amplifier. A multi-carrier amplifier with an operating band-width of any 20 MHz section on the whole 60 MHz WCDMA alloca-tion (WPAC/D), on a 10 MHz section of two neighbor carriers (WPAI/J) or on a 15 MHz section of two neighbor carriers (WPAK). The number of WPAs depends on the number of sectors, carriers, Rollout Optimized Configuration (ROC) utilization, and the required output power per carrier.

WTR WCDMA Transmitter and Receiver unit. One Wideband Transmitter and Receiver version B or D (WTRB/D) can serve two cells of two way uplink diversity, WTRA can serve one cell.

WSM Summing and multiplexing unit. Sums Tx signals from the signal pro-cessing units or other WSMs.

WSMF New summing and multiplexing unit. Sums of Tx signals from the signal processing units or other WSMs (part of EUBB). WSMF enables the connection of Flexi RF Modules and Remote Radio Heads to UltraSite WCDMA BTS in later SW releases.

Table 41 Description of Ultra Site BTS units

DN70118376Issue 04E

149


Id:0900d8058073d75a

4.4.1 Local cell grouping for UltraSite BTSLocal cell grouping is needed in large configurations and can be used in multi-operator RAN (MORAN) cases to divide local cell groups (LCGs) baseband capacity. It is possible to use MORAN without local cell grouping and dedicated baseband allocation.

In release WBTS6.0, local cell grouping for UltraSite BTS is needed in a case of more than 6 cells per BTS. Up to two LCGs can be created for UltraSite BTS.

It is possible to allocate baseband capacity for LCGs also in the case where same site is divided between two operators (MORAN) and one operator wants to reserve some dedicated BB capacity for own use.

The LCG baseband capacity can consist of EUBB (WSPF) and non-EUBB subrack (WSPA/C) capacity. WSPA/C card capacity cannot be shared between two LCGs, while EUBB baseband capacity can be freely dedicated between the LCGs by defining in Access baseband capacity commissioning parameter. The Access baseband capacity commissioning parameter is used to divide the baseband HW for LCGs from 1 to 99%. Actual allocation is done according the rule that at least one Subunit (36CE) is allocated to each LCG. The percent-based division is rounded to the nearest subunit amount.

WSP Signal processing unit. Performs Rx and Tx code channel process-ing, coding, and decoding functions. The number of WSPs is planned according to the expected traffic on the BTS. WSP capaci-ties are presented in Tables WSPA processing capacity and WSPC processing capacity.

WSPF New baseband processing unit. (part of EUBB)

WAM Application Manager. There can be up to six WAM units installed in the BTS - three act as primary WAMs (WAM in slots No. 0) and three act as secondary WAMs (WAMs in slots No. 1).

One primary WAM at a time is selected as a Telecom and O&M master unit (master WAM) by the system. The master WAM unit takes care of the control functions on the BTS cabinet level. This includes BTS start-up, temperature control, configuration and O&M processing.

All WAM units perform telecom control functions, logical resource management, ATM processing and transport channel frame protocol processing.

AXU Each UltraSite WCDMA and MetroSite WCDMA/50 base station has an integrated ATM switch called the ATM Cross-connect (AXC) Node for communication between the sectors inside the BTS towards the RNC and towards other BTSs. The AXU unit performs the main ATM functionality for the communication within the BTS and provides the connections to other network elements.

AXCF New transmission unit (part of EUBB).

IFU The IFUs provide the physical connection to the network. They support the following transmission interfaces: E1/JT1, STM-0/STM-1, E1, Flexbus.

Unit Description

Table 41 Description of Ultra Site BTS units (Cont.)

150 DN70118376Issue 04E


Id:0900d8058073d75a

4.4.2 WSPA/C/F processing capacityThe maximum processing capacity of one WSP card is as follows:

• 32 CE in UL and DL in case of WSPA • 64 CE in UL and DL in case of WSPC

WSPA processing capacity can be also expressed in terms of the active users of various RABs depending on the RAB data rate (see Table Processing capacity of WSPA for users with various data rates and Processing capacity of WSPC for users with various data rates).

WSPC processing capacity can be also expressed in terms of active users of various RABs depending on RAB data rate.

RAB Traffic class User data rate/kbps

Active users (UL)

Min. UL SF

Active users (DL)

Min. DL SF

AMR Speech Conversational 12.2 32 64 32 128







Packet Interactive /Background

16 32 64 32 128


32 16 32 16 64


64 8 16 16 32


128 8 8 8 16


256 4 4 4 8


384 2 4 2 8

Table 42 Processing capacity of WSPA for users with various data rates


Active users (UL)

Min. UL SF

Active users (DL)

Min. DL SF






Table 43 Processing capacity of WSPC for users with various data rates

DN70118376Issue 04E

151


Id:0900d8058073d75a

Support for mixed WSPA and WSPC configurations has been available from RAN04 onwards.

The maximum processing capacity of EUBB subrack for traffic use is as follows:

– 1 WSPF card: 180 CE in UL and DL– 2 WSPF cards: 396 CE in UL and DL– 3 WSPF cards: 612 CE in UL and DL

The EUBB subrack processing capacity can be also expressed in terms of active users of various RABs depending on RAB data rate. See Tables: Processing capacity of EUBB subrack (1 WSPF) for users of various data rates, Processing capacity of EUBB subrack (2 WSPF) for users of various data rates, and Processing capacity of EUBB subrack (3 WSPF) for users of various data rates.




16 64 64 64 128


32 32 32 32 64


64 16 16 16 32


128 16 8 16 16


256 8 4 8 8


384 4 4 4 8

RAB Traffic class User data rate/ kbps

Active users (UL)

Min. UL SF

Active users (DL)

Min. DL SF








PacketInteractive /Background 16 180 64 180 128

Table 44 Processing capacity of EUBB subrack (1 WSPF) for users of various data rates


Active users (UL)

Min. UL SF

Active users (DL)

Min. DL SF

Table 43 Processing capacity of WSPC for users with various data rates (Cont.)

152 DN70118376Issue 04E


Id:0900d8058073d75a




PacketInteractive /Background 256

20 (RU20)/ 30 (RU20 On Top) 4

20 (RU20)/ 30 (RU20 On Top) 8


15 (RU20)/ 22 (RU20 On Top) 4

15 (RU20)/ 22 (RU20 On Top) 8


Active users (UL)

Min. UL SF

Active users (UL)

Min. DL SF













44 (RU20) / 66 (RU20 On Top) 4

44 (RU20) / 66 (RU20 On Top 8


33 (RU20) / 49 (RU20 On Top) 4

33 (RU20) / 49 (RU20 On Top) 8



Active users (UL)

Min. UL SF

Active users (DL)

Min. DL SF

Table 44 Processing capacity of EUBB subrack (1 WSPF) for users of various data rates (Cont.)

DN70118376Issue 04E

153


Id:0900d8058073d75a

4.4.3 Dimensioning steps1. Dimension the WSP.

The required number of WSPs per BTS is determined by the expected traffic types, amounts, and the number of HW channels required for the common control channels (CCCH). The basic capacity unit is CE, corresponding to the processing requirement for one AMR call. The CE consumption is calculated separately for UL and DL DCH traffic according to DCH rates. Table Required CE per each active DCH user of the listed bearers is applicable for WSP card types A/C/F.


Active users (UL)

Min. UL SF

Active users (UL)

Min. DL SF








Packet Interactive /Background 16 612 64 612 128





256

68 (RU20) / 102 (RU20 On Top) 4

68 (RU20) / 102 (RU20 On Top) 8


384

51 (RU20) / 76 (RU20 On Top) 4

51 (RU20) / 76 (RU20 On Top) 8


154 DN70118376Issue 04E


Id:0900d8058073d75a

Multi-RAB configurations are supported. One MS can simultaneously have, for example, AMR call + 2 PS calls (with WSPA MultiRAB up to 256kbps + AMR common control channel, with WSPC MultiRAB up to 384kbps + AMR are sup-ported).

2. Dimension the WSP common control channel.The physical common control channels supported are: • Physical random access Channel (PRACH) • Common pilot channel (CPICH) • Primary common control physical channel (Primary CCPCH) • Synchronization channel (SCH) • Secondary common control physical channel (Secondary CCPCH) • Acquisition indicator channel (AICH) • Page indicator channel (PICH)These physical channels are created in the BTS and require certain hardware pro-cessing capacities at the BTS. • WSPA an common control channels

WSPA can simultaneously support the common control channels for up to four cells. Each cell reserved deducts the capacity available for dedicated usage by

WSP type WSPA WSPC WSPF

User data rate/kbps

UL CE DL CE UL CE DL CE UL CE DL CE

AMR 12.2 1 1 1 1 1 1

AMR 7.95 1 1 1 1 1 1

AMR 5.9 1 1 1 1 1 1

AMR 4.75 1 1 1 1 1 1

AMR 12.65 1 1 1 1 1 1

AMR 8.85 1 1 1 1 1 1

AMR 6.65 1 1 1 1 1 1

PS 16 1 1 1 1 1 1

PS 32 2 2 2 2 2 2

PS 64 4 4 4 4 4 4

PS 128 4 4 4 4 4 4

PS 256 8 8 8 8 9 (RU20)/ 6 (RU20 On Top)

9 (RU20)/ 6 (RU20 On Top)

PS 384 16 16 16 16 12 (RU20)/ 8 (RU20 On Top)

12 (RU20)/ 8 (RU20 On Top)

Table 47 Required CE per each active DCH user of the listed bearers

DN70118376Issue 04E

155


Id:0900d8058073d75a

the eight channels. In 1+1+1 ROC configurations, 24 CE for CCCHs processing is required.The WCDMA test loop reserves eight CE when the WCDMA test loop is per-formed.

• WSPC and common control channelsOne WSPC is capable of handling one to three cells.The WCDMA test loop (test of BB and RF functionalities) reserves one CE when the WCDMA test loop is performed.

• WSPF and common control channelsCEs required for CCCH – up to 6 cells/10km or 3cells/20km are included in EUBB subrack capacity.In certain cases if more cell or radius is required, more CE capacity might need to be allocated: • In case of 6 cells/20 km - 36 CE are needed. • In case of 9 cells/20km - 72 CE are needed. • In case of 12 cells/20 km -108 CE are needed.

• Mixed configuration (WSPA/C)If both different WSP types exist in the same BTS, CCCH baseband resources are allocated according to the priorities: • Assign all of the signaling resources required on the WSPA • A WSPC card is used for signaling if WSPA is already loaded or does not

exist. • Mixed configuration (WSPA/C/F)

If WSPF card (EUBB subrack) and other WSP types (WSPA/C) exist in the same BTS (LCG), CCCH baseband resources are allocated at WSPF card (EUBB subrack). In this case WSPA/C resources can be allocated for CCCH processing when mapping of frequency layer to non-EUBB subrack is used.With Mapping HSPA cell to HW commissioning parameter operator can map frequency layers to EUBB or non-EUBB subrack. Selected subrack type has to provide baseband resources for traffic from mapped frequency layer.If frequency layer is mapped to non-EUBB subrack(s), it has to provide baseband resources for common control channels for cells from assigned fre-quency.Note that the frequency layer mapping influences baseband allocation of all services (DCH, HSDPA, and HSUPA). If frequency mapping to subrack type (EUBB or non-EUBB subrack) is used, then selected subrack type has to provide CE for common control channels, but also baseband resources for HSUPA and HSDPA users from assigned frequency layer. DCH users from assigned frequency layer are also allocated at selected type of subrack (EUBB or non-EUBB subrack). However, if selected subrack type is not able to allocate all DCH users from assigned frequency layer, DCH users can be allocated at dif-ferent subrack type.

3. Dimension the WSP DCH.A single call needs to be processed on a single WSP unit. If the resource is not avail-able on a single WSP card in the BTS, the system rejects the setup if a lower bit rate is not suitable for the connection.For example, a WSPA with 16 channels reserved for signaling has the capacity of 16 channels for user traffic. These channels are allocated to the incoming traffic requests until the sum of the CE used reaches 16. Requests exceeding the number of available channels on that WSP (see Table Processing capacity of WSPA for

156 DN70118376Issue 04E


Id:0900d8058073d75a

users with various data rates) are rejected by the BTS if there is no free capacity on any other WSP unit in the BTS. In the case of real time (RT) over RT (priority) and RT over non-real time (NRT), however, the RNC can perform preemption type pro-cedures.For example, for accepting a PS 128 kbps call, the BTS requires four free CEs on a single WSP card. If these resources are not available, the call is rejected.If EUBB subrack and non-EUBB subrack are located in the same BTS (LCG), the EUBB resources are prioritized for DCH traffic. When EUBB subrack capacity has no free resources to allocate new DCH/A-DCH connection, non-EUBB resources are used for DCH allocation.If the frequency layer mapping to HW is used (with Mapping HSPA cell to HW commissioning parameter), selected subrack type (EUBB or non-EUBB) has to provide baseband resources for DCH/A-DCH traffic from mapped frequency layer. If the selected subrack type is not able to provide baseband resources for all DCH/A-DCH connections, baseband resources for DCH/A-DCH can be taken from different subrack type.

4. Dimension the HSDPA and HSUPA WSP.For detailed information concerning HSDPA and HSUPA baseband requirements see section HSDPA and BTS dimensioning and HSUPA and BTS dimensioning.If a EUBB subrack and non-EUBB subrack are located in the same BTS(LCG), the EUBB resources are utilized for HSDPA and HSUPA processing. unless frequency mapping to non-EUBB subrack is used.If the frequency layer mapping to HW is used (with Mapping HSPA cell to HW commissioning parameter), selected subrack type (EUBB or non-EUBB) has to provide baseband resources for HSDPA/HSUPA traffic from mapped frequency layer.When HSDPA resources are allocated at WSPC card, each HSDPA scheduler needs to be processed on single WSPC card.In the case where WSPC is used for HSUPA allocation, all WSPC cards (which are used for HSUPA (per LCG)) have to be located under the same WAM subrack.

DN70118376Issue 04E

157


Id:0900d80580785c84

4.5 HSDPA and BTS dimensioningSome of the supported capacities mentioned in this document might require separate licenses in the RAN before they can be activated. For more detailed information, see License Management in WCDMA RAN.

4.5.1 Scheduler typesIn the RU20/RU20 On Top release, one of the following baseband configurations can be selected:

1. Minimum baseband allocationThis scheduler supports one to three HSDPA cells and a maximum of 16 HSDPA users per scheduler. HSDPA users can be divided freely between three cells. Up to 3.6 Mbps is supported per scheduler with 5 codes and 16QAM (from the practical point of view, 64QAM modulation is not available).

Flexi System Module Rel1 (FSMB) / WSPC– 32CE are reserved from WSPC or Flexi System Module Rel1 capacity.

Flexi System Module Rel2 (FSMC/D/E) / EUBB (WSPF)– 36CE are reserved from WSPF or Flexi System Module Rel2 capacity.

2. HSDPA 16 users per cellWith this scheduler, a maximum of 16 HSDPA users per cell can be supported. Up to 3.6 Mbps with 16QAM is supported per cell (from the practical point of view, 64QAM modulation is not available).

Flexi System Module Rel1 (FSMB) / WSPC– 32CE are reserved from WSPC or Flexi System Module rel.1 capacity.

Flexi System Module Rel2 (FSMC/D/E) / EUBB (WSPF)– In RU20 main release, 36CE are reserved from WSPF or Flexi System Module

Rel2 capacity. In RU20 On Top release, the scheduler is not available with System Module Rel2 / WSPF.

3. Shared HSDPA scheduler for baseband efficiencyFlexi System Module Rel1(FSMB) / WSPC

– The maximum of 48 HSDPA users per scheduler are supported. HSDPA users can be divided freely among three cells. Up to 10.8 Mbps are supported with 45 codes (15 codes per cell) and 16QAM modulation. 64 CE are reserved from WSPC card and 80 CE from Flexi System Module Rel1 submodule per sched-uler. Up to 6 UEs per TTI (maximum 3 UEs per cell) can be served by scheduler. Up to 12 HSDPA cells can be served with 4 WSPC for HSDPA.

Flexi System Module Rel2 (FSMC/D/E) / EUBB (WSPF)

– The maximum of 72 HSDPA users per scheduler are supported. HSDPA users can be divided freely among three cells. Up to 42.2 Mbps (RU20 On Top) are supported per HSDPA scheduler with 45 codes (15 codes per cell) and 16QAM or 64QAM modulation. 72 CE are reserved per scheduler. Up to 9 UEs can be served in one TTI (max 4 UEs per cell).

In RU20 On Top release, MIMO feature is also available with Shared HSDPA scheduler for baseband efficiency (In RU20 main release, MIMO is supported only with Full baseband scheduler). With MIMO feature, scheduler is able to

158 DN70118376Issue 04E


Id:0900d80580785c84

serve 72 MIMO HSDPA users freely distributed between 2 cells with 30 codes, 16QAM modulation, and data rate up to 42Mbps (28Mbps per cell). Up to 4 MIMO user can be served per TTI per cell and 8 MIMO users per TTI per sched-uler. MIMO users can be simultaneously served in one TTI with HSDPA legacy users.

In RU20 On Top release, Dual-Cell HSDPA feature is available with Shared HSDPA scheduler for baseband efficiency. With Dual-Cell HSDPA feature, scheduler is able to serve 72 Dual-Cell HSDPA users with 30 codes, 16QAM or 64QAM modulation and data rate up to 42Mbps. Dual-Cell HSDPA users can be simultaneously served in one TTI with HSDPA legacy users.

Note that if Dual-Cell HSDPA feature is activated then HSDPA scheduler for baseband efficiency supports 2 cells from the same sector and the same band.

Figure 61 Dual-Cell HSDPA feature and Shared HSDPA scheduler for baseband efficiency, 3 sector site

4. Full basebandFlexi System Module Rel1 (FSMB) / WSPC– A maximum of 64 HSDPA users per scheduler are supported. Up to 14.4 Mbps

are supported with 15 codes and 16QAM modulation. 64 CE are reserved from WSPC card and 80 CE from Flexi System Module Rel1 submodule per sched-uler. Up to 3 UEs per TTI can be served by scheduler

Flexi System Module Rel2 (FSMC/D/E) / EUBB (WSPF)– The maximum of 72 HSDPA users per scheduler are supported. Up to 21.1

Mbps are supported per HSDPA scheduler with 15 codes and 64QAM modula-tion. 72 CE are reserved per scheduler. Up to 4 UEs per TTI can be served by the scheduler.With MIMO feature, scheduler is able to serve 72 MIMO HSDPA users with 15 codes, 16QAM modulation and data rate up to 28 Mbps. In RU20 On Top release, up to 4 MIMO user can be served per TTI. MIMO users can be simulta-neously served in one TTI with HSDPA legacy users.

Detailed description of HSDPA schedulersFor detailed information on Shared HSDPA scheduler for baseband efficiency without MIMO and Dual-Cell HSDPA feature activated, see Table RU20/RU20 On Top Shared HSDPA scheduler for baseband efficiency.

DN70118376Issue 04E

159


Id:0900d80580785c84

Tables RU20 On Top Full baseband scheduler shows detailed information on the Full baseband scheduler without MIMO and Dual-Cell HSDPA feature activated.

MIMO featureIn RU20 On Top, MIMO feature is supported with Shared HSDPA scheduler for baseband efficiency and Full baseband scheduler

Table RU20 On Top Shared HSDPA Scheduler for baseband efficiency scheduler with MIMO feature presents detailed information related to Shared HSDPA scheduler for baseband efficiency scheduler with MIMO feature.

Shared HSDPA scheduler for baseband efficiency WSPC WSPF FSMB FSMC/D/E

Scheduler peak throughput 10.8 Mbps 21.1 Mbps 16QAM/64QAM (RU20) /42.2 Mbps 16QAM/64QAM(RU20 On Top)

10.8 Mbps 21.1 Mbps 16QAM/64QAM (RU20) /42.2 Mbps 16QAM/64QAM(RU20 On Top)

Max number of simultaneous users

48 72 48 72

CE required by scheduler 64 72 80 72

Max number of scheduled UEs per TTI

6 9 6 9

Max number of scheduled UEs per cell

3 4 3 4

16QAM/64QAM modulation support

16QAM/- 16QAM/64QAM 16QAM/- 16QAM/64QAM

Table 48 RU20/RU20 On Top Shared HSDPA scheduler for baseband efficiency

Full baseband WSPC WSPF FSMB FSMC/D/E

Scheduler peak throughput 14.4 Mbps 21.1 Mbps 14.4 Mbps 21.1 Mbps

Max number of simultaneous users 64 72 64 72

CE required by scheduler 64 72 80 72

Max number of scheduled UEs per TTI 3 4 3 4

16QAM/64QAM modulationsupport 16QAM/- 16QAM/64QAM 16QAM/- 16QAM/64QAM

Table 49 RU20 On Top Full baseband scheduler

160 DN70118376Issue 04E


Id:0900d80580785c84

Detailed information on Full baseband scheduler with MIMO feature is shown in Table RU20 Full baseband scheduler with MIMO.

Dual-Cell HSDPA featureIn RU20 On Top, Dual-Cell HSDPA feature is supported with Shared HSDPA scheduler for baseband efficiency.

Table RU20 On Top Shared HSDPA scheduler for baseband efficiency with Dual-Cell HSDPA feature shows detailed information on Shared HSDPA scheduler for baseband efficiency with Dual-Cell feature.

Shared HSDPA scheduler for baseband efficiency

WSPF(MIMO) FSMC/D/E(MIMO)

Scheduler peak throughput 42.2Mbps 42.2Mbps

Max. number of simultaneous users 72 72

CE required by scheduler 72 72

Max. number of scheduled UEs per TTI 8 8

Max. number of scheduled UEs per cell 4 4

16QAM/64QAM modulation support 16QAM/- 16QAM/-

Table 50 RU20 On Top Shared HSDPA Scheduler for baseband efficiency sched-uler with MIMO feature

Full baseband WSPF(MIMO)

FSMC/D/E(MIMO)

Scheduler peak throughput 28 Mbps 28 Mbps

Max number of simultaneous users 72 72


Max number of scheduled UEs per TTI 4 4

16QAM/64QAM modulation support 16QAM/- 16QAM/-

Table 51 RU20 Full baseband scheduler with MIMO

Shared HSDPA Scheduler for baseband efficiency

WSPF(Dual-Cell HSDPA)

FSMC/D/E(Dual-Cell HSDPA)

Scheduler peak throughput 42.2 Mbps 42.2 Mbps

Max number of simultaneous users 72 72


Max. number of scheduled UEs per TTI 8 8

Max. number of scheduled UEs per cell 4 4

16QAM/64QAM modulation support 16QAM/64QAM 16QAM/64QAM

Table 52 RU20 On Top Shared HSDPA scheduler for baseband efficiency with Dual-Cell HSDPA feature

DN70118376Issue 04E

161


Id:0900d80580785c84

Note that Dual-Cell HSDPA and MIMO features can be used in the same cell, but not simultaneously for a single UE.

Associated UL/DL DCHThe streaming services are not supported by MIMO and Dual-Cell HSDPA features.

The associated UL/DL DCH of the HSDPA user requires the capacity in the same way as in normal DCH. The associated UL/DL DCH channels can be allocated to all WSPs/Flexi submodules. For details, see Table Associated DCH rates and CE usage.

*) If SF is 32, 2 CEs are required in UL.

**) 1 CE for DL signaling is required per HSDPA user.

***) System Module Rel2 (FSMC/D/E) / EUBB(WSPF) - RU20

****) System Module Rel2 (FSMC/D/E) / EUBB (WSPF) - RU20 On Top

Capacity is reserved for HSDPA when needed, according to HSDPA-related commis-sioning parameters. For more detailed information, see WCDMA RAN HSDPA in BTS.

4.5.2 Tcell groupingThe RNC parameter Tcell (Frame timing offset of a cell) can be used for grouping sched-ulers to cells if Minimum baseband allocation or Shared HSDPA scheduler for baseband efficiency scheduler are used. For example, the Minimum baseband allocation feature requires a processing capacity of 36 CE (System Module Rel2/WSPF) to be enabled for one to three cells in the BTS. Another 36 CEs can be added so that cells in A are handled by the first 36 CEs and cells in B by another 36 CEs. See figure Tcell grouping example, 1+1+1: 2 x 36 CE (System Module Rel2) as an example with a 1+1+1 config-uration.

User data CE required in UL / Min. SF

CE required in DL / Min. SF

PS 16 kbps 1/SF64* 1/SF128**

PS 64 kbps 4/SF16 1/SF128**

PS 128 kbps 4/SF8 1/SF128**

PS 384 kbps 16/12***/8****/SF4 1/SF128**

Table 53 Associated DCH rates and CE usage

162 DN70118376Issue 04E


Id:0900d80580785c84

Figure 62 Tcell grouping example, 1+1+1: 2 x 36 CE (System Module Rel2)

Figure Tcell grouping example, 2+2+2: 4 x 36 CE (System Module Rel2) shows an example with a 2+2+2 configuration.

Figure 63 Tcell grouping example, 2+2+2: 4 x 36 CE (System Module Rel2)

The principles of grouping (maximum 4 TCell groups per LCG are possible) are as follows:

• Group 1: Tcell values 0, 1 and 2 • Group 2: Tcell values 3, 4 and 5 • Group 3: Tcell values 6, 7 and 8 • Group 4: Tcell value 9

The same TCell values can be used by different cells, if those are allocated to different LCGs or Dual-Cell HSDPA feature is configured. With Dual-Cell HSDPA feature, both cells from one sector should have the same Tcell value (see Figure Dual-Cell HSDPA feature and Shared HSDPA scheduler for baseband efficiency, 3 sector site).

16 usersTcell = 0

A

B

11 usersTcell = 4

5 usersTcell = 3

Example 1:1+1+1: 2x36 CE

16 usersTcell = 3

16 usersTcell = 6

16 usersTcell = 9

Example 2:2+2+2: 4x36 CE

Tcell = 0 Tcell = 1

Tcell = 2

16 users

f1

f2

DN70118376Issue 04E

163


Id:0900d805806f89a2

4.6 HSUPA and BTS dimensioning Capacity is reserved for HSUPA on need basis. The capacity reservation might be changed dynamically between DCH and HSUPA use. In the CE allocation, DCH has a higher priority than HSUPA. The operator might commission a minimum fixed reserva-tion for HSUPA, but the rest of the capacity is dynamically allocated to HSUPA when DCH does not need it.

HSUPA reserves baseband resources in uplink and downlink. In addition, SRB for HSPA needs one extra CE per HSUPA user in uplink and downlink. Using F-DPCH feature (HSUPA and HSDPA allocated at System Module Rel2 or WSPF (EUBB sub-rack)), no additional uplink and downlink CE is required to support SRB for F-DPCH capable UEs (UE Rel7).

If F-DPCH feature is not activated or HSPA resources are allocated at System Module Rel.1 or WSPC card, each F-DPCH capable UE requires one CE in uplink and downlink.

In RU20/RU20 On Top release, HSUPA 2ms TTI is supported with System Module Rel2/WSPF (EUBB subrack). HSUPA 2ms TTI feature requires SRB mapping on E-DCH.

HSUPA is supported only with co-existence of HSDPA.

In RU20 On Top release, one HSUPA scheduler supports the maximum of 80 HSUPA users and 72 HSUPA users per cell (System Module Rel2/EUBB). Only one HSUPA scheduler can be allocated per LCG, unless two System Modules/subrack types are available and frequency mapping to both System Modules/subrack types is used. In this case, up to 2 HSUPA schedulers can be allocated per one LCG (first HSUPA scheduler located at first System Module/subrack type and second HSUPA scheduler allocated at another System Module/subrack type).

Therefore, with some configurations - more than one carrier and 2 Flexi System Modules Rel2 (for example FSMD + FSMD) using Mapping HSPA cell to HW commissioning parameter, it is possible to achieve 160 HSUPA users per one LCG (2 HSUPA sched-ulers - mapping frequency layers to both system modules used).

Mapping HSPA cell to HW commissioning parameter can be used by the operator for mapping HSPA frequencies to different system modules/subracks. Some frequen-cies can be mapped to one system module/subrack and other frequencies to another system module/subrack, so that both modules are utilized for HSPA.

The number of HSUPA users with streaming QoS is limited to 19 per cell.

Starting from RU10, the minimum capacity reserved for HSUPA is 0 CE (8 CE in RAS06). In this case, only HSUPA MAC-e is active. The operator can follow the capacity need from the counter indicating the number of HSUPA-capable UEs in the cell.

The operator can define the minimum HSUPA-reserved capacity to have the guaran-teed service level.

The BTS reserves the minimum capacity for HSUPA based on commissioning parame-ters Minimum Baseband decoding capability Mbps and minimum number of HSUPA UE

Max number of HSUPA users FSMB FSMC/D/E WSPC WSPF (EUBB)

Max number of HSUPA users per cell 20 72 20 72

Max number of HSUPA users per LCG 60 80 (160) 60 80

Table 54 Max number of HSUPA users per cell/LCG

164 DN70118376Issue 04E


Id:0900d805806f89a2

per BTS. The value for Minimum Baseband decoding capability Mbps refers to the static commissioned minimum reservation for baseband L1 throughput. The HSUPA through-put can be bigger if there is more capacity available in the BTS.

If the operator maps HSPA frequencies to different System modules/Subracks (EUBB or non-EUBB subrack), the BTS reserves a minimum capacity for HSUPA only for a one System module/Subrack type based on commissioning parameters.

The BTS checks in background whether the first HSUPA resource step is in optimal place with maximal achievable HSUPA resource steps (see Resource steps descrip-tion). If there is another resource pool with more potential HSUPA resource steps, an alarm HSUPA capacity decreased is raised. The throughput of current HSUPA users is not affected, but the alarm notifies that even better resource pool can be avail-able. The alarm can be ignored in case that if there is no decrease seen neither in HSUPA counters nor in HSUPA KPIs. If counters or KPIs indicates also HSUPA capacity decrease, then instructions of the alarm HSUPA capacity decreased could be followed to maximize HSUPA capacity. The reason for such an alarm might be any event that releases resources from the other resource pools, such as cell recovery. In this case, all cells belonging to the same LCG should be locked and then unlocked by the operator, to make HSUPA resource moving to optimal resource pool. Note that this might also limit the HSUPA features, for example, if HSUPA is in Flexi Rel1/WSPC, this means that 2 ms TTI and 5.8 Mbps are not in use.

4.6.1 HSUPA CE allocation principles

Resource stepsHSUPA CE allocation is done with specific sizes of resource steps. The amount of the needed resources depends on the required throughput and the number of HSUPA users.

HSUPA resource step 1 is pre-allocated by the HSUPA resource manager, enabling fast HSUPA call setup. The preallocation is not visible in CE counters. RU20 HSUPA activa-tion does not require a fixed pool of CE when the feature is being activated.

To allocate the next HSUPA resource step, an additional free capacity of 6 CE is needed. This 6 CE can be any licensed CE in any system module, (any WSPx CE in UltraSite WBTS). The required 6 CE free on top of the HSUPA resource step are to avoid a ”ping-pong” effect in reserving and freeing HSUPA resource steps; the HSUPA resource step is not requested back immediately after its allocation.

When free channel capacity drops below four CE, the resource manager starts to free resources used by HSUPA.

HSUPA resource allocation System Module Rel1 / WSPCIn RU20/RU20 On Top, up to three WSPC cards/Flexi System Module Rel1 Submod-ules can be used for HSUPA (per LCG). In Flexi WBTS, HSUPA resource steps have to be located within one system module. In UltraSite WBTS, all WSPC cards used for HSUPA resource steps (per LCG) have to be located under the same WAM subrack

Table HSUPA resource steps for System Module Rel1 / WSPC presents HSUPA resource steps for System Module rel.1 and WSPC card.

DN70118376Issue 04E

165


Id:0900d805806f89a2

In case of System Module Rel1, if the first HSUPA resource step is forced to be allocated by SW in non-optimal place - same submodule with CCCHs, all HSUPA resource steps (per LCG) have to be allocated only within the same submodule.

If the first HSUPA resource step is forced to be allocated by SW in non-optimal place, the same card with CCCHs or HSDPA, all HSUPA resource steps (per LCG) have to be allocated only within the same WSPC card.

If HSPA sharing is in use, it takes the capacity of one resource step.

If HSUPA resource steps are allocated together with CCCH at FSMB submodule or WSPC card, the HSUPA resource step size differs from the values presented in Table HSUPA resource steps for System Module Rel1 / WSPC. If the first and second HSUPA step is allocated at FSMB submodule / WSPC card which contains CE for CCCH pro-cessing, then both steps requirements are specified in Table HSUPA resource steps with CCCH (1st FSMB submodule/WSPC).

HSUPA resource step

Flexi BTS SM Rel1

UltraSite WCDMA BTS

1 32 CE 32 CE

2 24 CE 16 CE

3 24 CE 16 CE

4 32 CE 24 CE

5 24 CE 20 CE

6 24 CE 20 CE

7 32 CE 24 CE

8 24 CE 20 CE

9 24 EC 20 CE

Table 55 HSUPA resource steps for System Module Rel1 / WSPC

HSUPA resource step Flexi BTS SM Rel1 UltraSite WCDMA BTS

1 32 CE 32 CE

2 22 CE 16 CE

Table 56 HSUPA resource steps with CCCH (1st FSMB submodule/WSPC)

166 DN70118376Issue 04E


Id:0900d805806f89a2

Figure 64 FSMB submodule / WSPC card with CCCH and 1st HSUPA resource step

If the first HSUPA step is allocated at FSMB submodule / WSPC card which does not contain CE for CCCH processing, then the rest of HSUPA resource steps can be allo-cated at different FSMB submodules / WSPC cards. In this case, if the second/third FSMB submodule / WSPC card contains CE for CCCH processing, then only two HSUPA resource steps can be taken from FSMB submodule / WSPC with size as in Table HSUPA resource steps with CCCH (2nd/3rd FSMB submodule/WSPC).

* 1, 2 and 3 HSUPA resource step at 1st FSMB submodule/WSPC card, 4 and 5 HSUPA resource step at 2nd FSMB submodule together with CCCH

** 1, 2 and 3 HSUPA resource step at 1st FSMB submodule/WSPC card, 4, 5 HSUPA resource step at 2nd FSMB submodule/WSPC together with CCCH, 6 and 7 HSUPA resource step at 3rd FSMB submodule/WSPC together with CCCH

*** 1, 2 and 3 HSUPA resource step at 1st FSMB submodule/WSPC card, 4, 5 and 6 HSUPA resource step at 2nd FSMB submodule/WSPC, 7 and 8 HSUPA resource step at 3rd FSMB submodule/WSPC together with CCCH

HSUPA resource step Flexi BTS SM Rel1 UltraSite WCDMA BTS

4* or 6** or 7*** 27 CE 24 CE

5* or 7** or 8*** 27 CE 24 CE

Table 57 HSUPA resource steps with CCCH (2nd/3rd FSMB submodule/WSPC)

DN70118376Issue 04E

167


Id:0900d805806f89a2

Figure 65 HSUPA resource steps with CCCH (2nd FSMB submodule/WSPC card)

168 DN70118376Issue 04E


Id:0900d805806f89a2

Figure 66 HSUPA resource steps with CCCH (3rd FSMB submodule/WSPC card)

In case that HSUPA resource step is allocated together with HSDPA at the same WSPC card, only one HSUPA resource step can be allocated at WSPC card with size as in the table HSUPA resource steps with HSDPA (WSPC).

* 1, 2 and 3 HSUPA resource step at 1st WSPC card, 4 HSUPA resource step at 2nd WSPC card together with HSDPA (see figure HSUPA resource steps with HSDPA (WSPC card))

HSUPA resource step UltraSite WCDMA BTS

4* 32 CE

7** 32 CE

Table 58 HSUPA resource steps with HSDPA (WSPC)

DN70118376Issue 04E

169


Id:0900d805806f89a2

** 1, 2 and 3 HSUPA resource step at 1st WSPC card, 4,5 and 6 HSUPA resource step at 2nd WSPC card, 7 HSUPA resource step at 3rd WSPC card together with HSDPA

Figure 67 HSUPA resource steps with HSDPA (WSPC card)

Table Flexi WCDMA BTS System Module Rel1 and UltraSite WCDMA BTS required number of HSUPA resource steps lists the number of HSUPA resource steps allocated to get a certain combined BTS baseband L1 throughput with a certain number of UEs.

Number of HSUPA UEs per LCG

0 <1.4 Mbps

1.4 Mbps

2.8 Mbps

4.2 Mbps

5.6 Mbps

7 Mbps

8.4 Mbps

9.8 Mbps

11.2 Mbps

12.6 Mbps

1-4 0 1 1 2 3 4 N/A N/A N/A N/A N/A

5-8 0 1 2 2 3 4 5 6 7 8 N/A

9-12 0 2 2 3 3 4 5 6 7 8 9

13-16 0 2 3 4 4 4 5 6 7 8 9

17-20 0 3 3 4 5 5 5 6 7 8 9

21-24 0 3 3 4 5 6 6 6 7 8 9

25-28 0 4 4 5 6 7 7 7 7 8 9

29-32 0 4 4 5 6 7 8 8 8 8 9

33-36 0 5 5 6 6 8 9 9 9 9 9

37-40 0 5 5 6 7 8 9 N/A N/A N/A N/A

41-44 0 6 6 6 8 8 9 N/A N/A N/A N/A

Table 59 Flexi WCDMA BTS System Module Rel1 and UltraSite WCDMA BTS required number of HSUPA resource steps

170 DN70118376Issue 04E


Id:0900d805806f89a2

Table UltraSite WCDMA BTS, combined minimum base band L1 throughput of all users-describes the amount of CE allocated to get certain combined (of all UEs) BTS baseband L1 throughput against a certain number of UEs for UltraSite WCDMA BTS.

45-48 0 6 6 6 8 8 N/A N/A N/A N/A N/A

49-52 0 7 7 7 9 9 N/A N/A N/A N/A N/A

53-56 0 7 7 7 9 N/A N/A N/A N/A N/A N/A

57-60 0 8 8 8 9 N/A N/A N/A N/A N/A N/A


0 <1.4 Mbps

1.4 Mbps

2.8 Mbps

4.2 Mbps

5.6 Mbps

7 Mbps

8.4 Mbps

9.8 Mbps

11.2 Mbps

12.6 Mbps

Table 59 Flexi WCDMA BTS System Module Rel1 and UltraSite WCDMA BTS required number of HSUPA resource steps (Cont.)


0 < 1.4 Mbps

1.4 Mbps

2.8 Mbps

4.2 Mbps

5.6 Mbps

7 Mbps

8.4 Mbps

9.8 Mbps

11.2 Mbps

12.6 Mbps

1-4 0 32 32 56 80 112 N/A N/A N/A N/A N/A

5-8 0 32 56 56 80 112 136 160 192 216 N/A

9-12 0 56 56 80 80 112 136 160 192 216 240

13-16 0 56 80 112 112 112 136 160 192 216 240

17-20 0 80 80 112 136 136 136 160 192 216 240

21-24 0 80 80 112 136 160 160 160 192 216 240

25-28 0 112 112 136 160 192 192 192 192 216 240

29-32 0 112 112 136 160 192 216 216 216 216 240

33-36 0 136 136 160 160 216 240 240 240 240 240

37-40 0 136 136 160 192 216 240 N/A N/A N/A N/A

41-44 0 160 160 160 216 216 240 N/A N/A N/A N/A

45-48 0 160 160 160 216 216 N/A N/A N/A N/A N/A

49-52 0 192 192 192 240 240 N/A N/A N/A N/A N/A

53-56 0 192 192 192 240 N/A N/A N/A N/A N/A N/A

57-60 0 216 216 216 240 N/A N/A N/A N/A N/A N/A

Table 60 Flexi WCDMA BTS System Module Rel1 combined minimum baseband L1 throughput of all users

DN70118376Issue 04E

171


Id:0900d805806f89a2

Note that the minimum baseband decoding capability “<1,4 Mbps” cannot be used for commissioning purpose.

HSUPA resource allocation System Module Rel2 / WSPFTable HSUPA resource steps for System Module Rel2 / WSPF presents HSUPA resource steps for System Module Rel2 and WSPF card

Number of HSUPA UEs per

LCG

0 < 1.4 Mbps

1.4 Mbps

2.8 Mbps

4.2 Mbps

5.6 Mbps

7 Mbps

8.4 Mbps

9.8 Mbps

11.2 Mbps

12.6 Mbps

1-4 0 32 32 48 64 88 N/A N/A N/A N/A N/A

5-8 0 32 48 48 64 88 108 128 152 172 N/A

9-12 0 48 48 64 64 88 108 128 152 172 192

13-16 0 48 64 88 88 88 108 128 152 172 192

17-20 0 64 64 88 108 108 108 128 152 172 192

21-24 0 64 64 88 108 128 128 128 152 172 192

25-28 0 88 88 108 128 152 152 152 152 172 192

29-32 0 88 88 108 128 152 172 172 172 172 192

33-36 0 108 108 128 128 172 192 192 192 192 192

37-40 0 108 108 128 152 172 192 N/A N/A N/A N/A

41-44 0 128 128 128 172 172 192 N/A N/A N/A N/A

45-48 0 128 128 128 172 172 N/A N/A N/A N/A N/A

49-52 0 152 152 152 192 192 N/A N/A N/A N/A N/A

53-56 0 152 152 152 192 N/A N/A N/A N/A N/A N/A

57-60 0 172 172 172 192 N/A N/A N/A N/A N/A N/A

Table 61 UltraSite WCDMA BTS, combined minimum base band L1 throughput of all users

HSUPA resource step

Flexi BTS SM Rel2

UltraSite WCDMA BTS (EUBB)

1 18 CE 18 CE

2 18 CE 18 CE

3 18 CE 18 CE

4 18 CE 18 CE

5 18 CE 18 CE

6 18 CE 18 CE

7 18 CE 18 CE

8 18 CE 18 CE

Table 62 HSUPA resource steps for System Module Rel2 / WSPF

172 DN70118376Issue 04E


Id:0900d805806f89a2

For System Module Rel2, HSUPA resource steps belonging to one HSUPA scheduler have to be located under the same submodule (per HSUPA scheduler).

For EUBB, HSUPA resource steps belonging to one HSUPA scheduler have to be located under the same WSPF card.

9 18 CE 18 CE

10 18 CE 18 CE

HSUPA resource step

Flexi BTS SM Rel2

UltraSite WCDMA BTS (EUBB)

Table 62 HSUPA resource steps for System Module Rel2 / WSPF (Cont.)

Number of HSUPA UEs per scheduler

0 <1.4 Mbps

1.4 Mbps

2.8 Mbps

4.2 Mbps

5.6 Mbps

7 Mbps

8.4 Mbps

9.8 Mbps

1-3 0 1 1 1 2 2 N/A N/A N/A

4-6 0 1 1 2 2 2 3 3 4

7-9 0 2 2 2 2 3 3 3 4

10-12 0 2 2 2 3 4 4 4 4

13-15 0 2 2 3 3 4 5 5 5

16-18 0 3 3 3 3 4 5 6 6

19-21 0 3 3 4 4 4 5 6 7

22-24 0 4 4 4 4 4 5 6 7

25-27 0 4 4 4 5 5 5 6 7

28-30 0 4 4 4 5 5 5 6 7

31-33 0 5 5 5 6 6 6 6 7

34-36 0 5 5 6 6 6 6 6 7

37-39 0 6 6 6 6 7 7 7 7

40-42 0 6 6 6 6 7 7 7 7

43-45 0 6 6 7 7 8 8 8 8

46-51 0 7 7 7 8 8 9 9 9

51-60 0 8 8 8 8 8 9 10 10

61-72 0 9 9 9 9 9 10 N/A N/A

73-80 0 10 10 10 10 10 10 N/A N/A

Table 63 Flexi WCDMA BTS System Module Rel2/UltraSite WCDMA BTS EUBB (WSPF) required number of HSUPA resource steps for 10ms TTI UEs (part 1)

DN70118376Issue 04E

173


Id:0900d805806f89a2

Tables Flexi WCDMA BTS System Module Rel2/UltraSite WCDMA BTS EUBB (WSPF) required number of HSUPA resource steps for 10ms TTI UEs (part 1) and Flexi WCDMA BTS System Module Rel2/UltraSite WCDMA BTS EUBB (WSPF) required number of HSUPA resource steps for 10ms TTI UEs (part 2) present required number of HSUPA resource steps for 10ms TTI UEs. Tables Flexi WCDMA BTS System Module Rel2/UltraSite WCDMA BTS EUBB (WSPF) required number of HSUPA resource steps for 2ms TTI UEs (part 1) and Flexi WCDMA BTS System Module Rel2/UltraSite WCDMA BTS EUBB (WSPF) required number of HSUPA resource steps for 2ms TTI UEs (part 2) present required HSUPA resource steps for 2ms TTI UEs.


11.2 Mbps

12.6 Mbps

14Mbps

15.4 Mbps

16.8Mbps

18.2Mbps

19.6Mbps

21Mbps

1-3 N/A N/A N/A N/A N/A N/A N/A N/A

4-6 4 N/A N/A N/A N/A N/A N/A N/A

7-9 4 5 6 6 7 N/A N/A N/A

10-12 5 6 6 7 8 8 9 9

13-15 5 6 6 7 8 8 9 9

16-18 6 6 7 8 8 9 10 10

19-21 7 7 8 8 9 10 10 N/A

22-24 8 8 9 9 10 10 N/A N/A

25-27 8 9 9 10 10 N/A N/A N/A

28-30 8 9 10 10 N/A N/A N/A N/A

31-33 8 9 10 N/A N/A N/A N/A N/A

34-36 8 9 10 N/A N/A N/A N/A N/A

37-39 8 9 10 N/A N/A N/A N/A N/A

40-42 8 9 10 N/A N/A N/A N/A N/A

43-45 8 9 10 N/A N/A N/A N/A N/A

46-51 9 10 10 N/A N/A N/A N/A N/A

51-60 10 N/A N/A N/A N/A N/A N/A N/A





0 <1 Mbps 1.0 Mbps

2.8 Mbps

4.2 Mps

5.6Mbps

7Mbps

8.4 Mbps

9.8 Mbps

1-3 0 1 1 1 2 2 3 3 4

4-6 0 1 1 2 2 2 3 3 4


174 DN70118376Issue 04E


Id:0900d805806f89a2

7-9 0 2 2 2 2 3 3 4 4

10-12 0 2 2 2 3 4 4 4 4

13-15 0 2 2 3 3 4 5 5 5

16-18 0 3 3 3 3 4 5 6 6

19-21 0 3 3 4 4 4 5 6 7

22-24 0 3 3 4 4 4 5 6 7

25-27 0 4 4 4 5 5 5 6 7

28-30 0 4 4 4 5 5 5 6 7

31-33 0 5 5 5 6 6 6 6 7

34-36 0 5 5 6 6 6 6 6 7

37-39 0 5 5 6 6 7 7 7 7

40-42 0 6 6 6 6 7 7 7 7

43-45 0 6 6 7 7 8 8 8 8

46-51 0 7 7 7 8 8 9 9 9

51-60 0 8 8 8 8 9 10 10 10

61-72 0 9 9 9 9 10 N/A N/A N/A

73-80 0 10 10 10 10 N/A N/A N/A N/A


0 <1 Mbps 1.0 Mbps

2.8 Mbps

4.2 Mps

5.6Mbps

7Mbps

8.4 Mbps

9.8 Mbps

Table 65 Flexi WCDMA BTS System Module Rel2/UltraSite WCDMA BTS EUBB (WSPF) required number of HSUPA resource steps for 2ms TTI UEs (part 1) (Cont.)


11.2Mbps

12.6 Mbps

14Mbps

15.4Mbps

16.8Mbps

18.2Mbps

19.6Mbps

21Mbps

1-3 4 5 5 6 6 N/A N/A N/A

4-6 4 5 6 7 7 8 9 10

7-9 4 5 6 7 8 9 9 10

10-12 5 5 6 7 8 9 9 10

13-15 5 5 6 7 8 9 10 N/A

16-18 6 6 7 8 9 10 N/A N/A

19-21 7 7 8 9 10 N/A N/A N/A

22-24 8 8 9 10 N/A N/A N/A N/A

25-27 8 9 10 N/A N/A N/A N/A N/A

28-30 8 9 10 N/A N/A N/A N/A N/A

31-33 8 9 10 N/A N/A N/A N/A N/A

34-36 8 9 10 N/A N/A N/A N/A N/A


DN70118376Issue 04E

175


Id:0900d805806f89a2

Tables Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB (WSPF) combined minimum base band L1 throughput of all users for 10ms TTI UEs (part 1), Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB (WSPF) combined minimum base band L1 throughput of all users for 10ms TTI UEs (part 2), Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB combined minimum base band L1 throughput of all users for 2ms TTI UEs (part 1), and Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB combined minimum baseband L1 throughput of all users for 2ms TTI UEs (part 2) show the amount of channel elements (CEs) allocated to get a certain combined (of all UEs) BTS baseband L1 throughput versus a certain number of UEs for Flexi WCDMA BTS.

The tables assume a typical use case when the majority of the users are downlink data dominated and the remaining users are UL data dominated.

37-39 8 9 10 N/A N/A N/A N/A N/A

40-42 8 9 10 N/A N/A N/A N/A N/A

43-45 8 9 10 N/A N/A N/A N/A N/A

46-51 9 10 N/A N/A N/A N/A N/A N/A

51-60 10 N/A N/A N/A N/A N/A N/A N/A




11.2Mbps

12.6 Mbps

14Mbps

15.4Mbps

16.8Mbps

18.2Mbps

19.6Mbps

21Mbps

Table 66 Flexi WCDMA BTS System Module Rel2/UltraSite WCDMA BTS EUBB (WSPF) required number of HSUPA resource steps for 2ms TTI UEs (part 2) (Cont.)


0 <1.4 Mbps

1.4 Mbps

2.8 Mbps

4.2 Mbps

5.6Mbps

7Mbps

8.4Mbps

9.8 Mbps

1-3 0 18 18 18 36 36 N/A N/A N/A

4-6 0 18 18 36 36 36 54 54 72

7-9 0 36 36 36 36 54 54 54 72

10-12 0 36 36 36 54 72 72 72 72

13-15 0 36 36 54 54 72 90 90 90

16-18 0 54 54 54 54 72 90 108 108

19-21 0 54 54 72 72 72 90 108 126

22-24 0 72 72 72 72 72 90 108 126

25-27 0 72 72 72 90 90 90 108 126

28-30 0 72 72 72 90 90 90 108 126

31-33 0 90 90 90 108 108 108 108 126

34-36 0 90 90 108 108 108 108 108 126

37-39 0 108 108 108 108 126 126 126 126

Table 67 Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB (WSPF) combined minimum base band L1 throughput of all users for 10ms TTI UEs (part 1)

176 DN70118376Issue 04E


Id:0900d805806f89a2

40-42 0 108 108 108 108 126 126 126 126

43-45 0 108 108 126 126 144 144 144 144

46-51 0 126 126 126 144 144 162 162 162

51-60 0 144 144 144 144 144 162 180 180

61-72 0 162 162 162 162 162 180 N/A N/A

73-80 0 180 180 180 180 180 180 N/A N/A


0 <1.4 Mbps

1.4 Mbps

2.8 Mbps

4.2 Mbps

5.6Mbps

7Mbps

8.4Mbps

9.8 Mbps

Table 67 Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB (WSPF) combined minimum base band L1 throughput of all users for 10ms TTI UEs (part 1) (Cont.)


11.2Mbps

12.6 Mbps

14Mbps

15.4Mbps

16.8Mbps

18.2Mbps

19.6Mbps

21Mbps


4-6 72 N/A N/A N/A N/A N/A N/A N/A

7-9 72 90 108 108 126 N/A N/A N/A

10-12 90 108 108 126 144 144 162 162

13-15 90 108 108 126 144 144 162 162

16-18 108 108 126 144 144 162 180 180

19-21 126 126 144 144 162 180 180 N/A

22-24 144 144 162 162 180 180 N/A N/A

25-27 144 162 162 180 180 N/A N/A N/A

28-30 144 162 180 180 N/A N/A N/A N/A

31-33 144 162 180 N/A N/A N/A N/A N/A

34-36 144 162 180 N/A N/A N/A N/A N/A

37-39 144 162 180 N/A N/A N/A N/A N/A

40-42 144 162 180 N/A N/A N/A N/A N/A

43-45 144 162 180 N/A N/A N/A N/A N/A

46-51 162 180 180 N/A N/A N/A N/A N/A

51-60 180 N/A N/A N/A N/A N/A N/A N/A



Table 68 Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB (WSPF) combined minimum base band L1 throughput of all users for 10ms TTI UEs (part 2)

DN70118376Issue 04E

177


Id:0900d805806f89a2


0 <1 Mbps

1.0Mbps

2.8 Mbps

4.2 Mbps

5.6Mbps

7Mbps

8.4 Mbps

9.8 Mbps

1-3 0 18 18 18 36 36 54 54 72

4-6 0 18 18 36 36 36 54 54 72

7-9 0 36 36 36 36 54 54 72 72

10-12 0 36 36 36 54 72 72 72 72

13-15 0 36 36 54 54 72 90 90 90

16-18 0 54 54 54 54 72 90 108 108

19-21 0 54 54 72 72 72 90 108 126

22-24 0 54 54 72 72 72 90 108 126

25-27 0 72 72 72 90 90 90 108 126

28-30 0 72 72 72 90 90 90 108 126

31-33 0 90 90 90 108 108 108 108 126

34-36 0 90 90 108 108 108 108 108 126

37-39 0 90 90 108 108 126 126 126 126

40-42 0 108 108 108 108 126 126 126 126

43-45 0 108 108 126 126 144 144 144 144

46-51 0 126 126 126 144 144 162 162 162

51-60 0 144 144 144 144 162 180 180 180

61-72 0 162 162 162 162 180 N/A N/A N/A

73-80 0 180 180 180 180 N/A N/A N/A N/A

Table 69 Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB combined minimum base band L1 throughput of all users for 2ms TTI UEs (part 1)


11.2Mbps

12.6 Mbps

14Mbps

15.4Mbps

16.8Mbps

18.2Mbps

19.6Mbps

21Mbps

1-3 72 90 90 108 108 N/A N/A N/A

4-6 72 90 108 126 126 144 162 180

7-9 72 90 108 126 144 162 162 180

10-12 90 90 108 126 144 162 162 180

13-15 90 90 108 126 144 162 180 N/A

16-18 108 108 126 144 162 180 N/A N/A

19-21 126 126 144 162 180 N/A N/A N/A

22-24 144 144 162 180 N/A N/A N/A N/A

25-27 144 162 180 N/A N/A N/A N/A N/A

28-30 144 162 180 N/A N/A N/A N/A N/A

Table 70 Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB combined minimum baseband L1 throughput of all users for 2ms TTI UEs (part 2)

178 DN70118376Issue 04E


Id:0900d805806f89a2

Note that the minimum baseband decoding capability “<1.4 Mbps” and “<1 Mbps” cannot be used for commissioning purpose.

2ms TTI HSUPA users require more processing than 10ms TTI HSUPA users, there-fore, combined BTS L1 throughput in second column for 2ms TTI UEs equals 1.0Mbps (1.4 Mbps for 10ms TTI UEs). If both 2ms TTI and 10ms TTI users are in the same HSUPA resource step, then Tables Flexi WCDMA BTS System Module Rel2/UltraSite WCDMA BTS EUBB (WSPF) required number of HSUPA resource steps for 10ms TTI UEs (part 1) and Flexi WCDMA BTS System Module Rel2/UltraSite WCDMA BTS EUBB (WSPF) required number of HSUPA resource steps for 10ms TTI UEs (part 2) should be used for determining the required number of HSUPA resource steps. The combined BTS L1 throughput from the second column is in this case between 1.4Mbps and 1.0Mbps, depending on ratio of 2ms TTI UEs and 10ms TTI UEs.

Dynamic baseband utilizationDepending on the total amount of free CE available, that is, the licenses, installed hardware capacity, and the traffic load, the BTS resource manager can dynamically allocate the additional baseband resources for HSUPA. A maximum of 240 CE in Flexi WCDMA BTS System Module Rel1 (60 HSUPA users) / 180 CE in Flexi WCDMA BTS System Module Rel2 (80 HSUPA users) can be used by HSUPA. If there is a conflict with R99 RT or NRT traffic needs, the BTS resource manager reduces the amount of baseband resources available for HSUPA.

HSUPA requires HSDPA for downlink. In addition to the CE consumption for HSDPA and HSUPA activation, one CE for signaling radio bearer is required per user if System Module Rel1/WSPC card is used for HSPA, or if F-DPCH feature is disabled. If F-DPCH feature is enabled, all F-DPCH capable users do not require any CE in UL and DL for signaling but only CE for HSDPA and HSUPA activation (HSUPA and HSDPA resources allocated at System Module Rel2/EUBB).

UE peak throughputThe peak UE throughput that one HSUPA user can achieve depends on the number of HSUPA users per HSUPA resource step and the spreading factor used.

31-33 144 162 180 N/A N/A N/A N/A N/A

34-36 144 162 180 N/A N/A N/A N/A N/A

37-39 144 162 180 N/A N/A N/A N/A N/A

40-42 144 162 180 N/A N/A N/A N/A N/A

43-45 144 162 180 N/A N/A N/A N/A N/A

46-51 162 180 N/A N/A N/A N/A N/A N/A

51-60 180 N/A N/A N/A N/A N/A N/A N/A




11.2Mbps

12.6 Mbps

14Mbps

15.4Mbps

16.8Mbps

18.2Mbps

19.6Mbps

21Mbps

Table 70 Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB combined minimum baseband L1 throughput of all users for 2ms TTI UEs (part 2) (Cont.)

DN70118376Issue 04E

179


Id:0900d805806f89a2

Tables UE peak throughput for HSUPA Flexi WCDMA BTS System Module Rel2, resource step 1, 3, 5, 7, 9 and Peak throughput for HSUPA Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB, pair of resource steps 1 and 2, 3 and 4, 5 and 6, 7 and 8, 9 and 10 show the UE HSUPA peak throughput for System Module Rel2. This depends on the user occupation of two consecutive HSUPA resource steps (1 and 2, 3 and 4, 5 and 6, 7 and 8).

When only the first HSUPA resource step (from the given resource pair) is occupied by HSUPA users, the following table should be used to estimate the UE peak rate through-put.

If the second HSUPA resource step from the resource step pair is used, the UE peak rate can be estimated according to the table below:

Number of HSUPA UEs in HSUPA resource step

SF4 (960kbps) 2xSF4 (1920kbps) 2xSF2 (3840kbps)

L1 (kbps) RLC (kbps) L1 (kbps) RLC (kbps) L1 (kbps) RLC (kbps)

1 711 672 1448 1376 2000 1888

2 711 672 1448 1376 2000 1888

3 711 672 1448 1376 910 864

4 711 672 1448 1376 910 864

5 711 672 711 672 711 672

6 711 672 408 384 408 384

7 408 384 408 384 408 384

8 408 384 408 384 408 384

Table 71 Peak throughput for HSUPA Flexi WCDMA BTS System Module Rel1 and UltraSite WCDMA BTS

Number of HSUPA UEs in HSUPA resource step (1, 3, 5, 7, 9)

SF4 2xSF4 2xSF4 + 2xSF2

L1 (kbps) L1 (kbps) L1 (kbps)

1 700 1300 2700

2 700 1300 2700

3 700 1300 2700

4 700 1300 1300

5 700 1300 1300

6 700 1300 1300

7 700 1300 1300

Table 72 UE peak throughput for HSUPA Flexi WCDMA BTS System Module Rel2, resource step 1, 3, 5, 7, 9

180 DN70118376Issue 04E


Id:0900d805806f89a2

The peak throughput that a UE might achieve depends on:

– spreading factor used– number of other users in the resource step– activity of the other users. When other users are not transmitting, one UE can

achieve the peak throughput specified in Tables Peak throughput for HSUPA Flexi WCDMA BTS System Module Rel1 and UltraSite WCDMA BTS, UE peak through-put for HSUPA Flexi WCDMA BTS System Module Rel2, resource step 1, 3, 5, 7, 9, and Peak throughput for HSUPA Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB, pair of resource steps 1 and 2, 3 and 4, 5 and 6, 7 and 8, 9 and 10.

For example, when calculated according to 3- 4 UEs per resource step and spreading factor 2*SF4 is used, the peak throughput of a UE is 1.4 Mbps (1448kbps), assuming that other UEs are not transmitting simultaneously.

When calculated from 1-2 UEs per resource step and spreading factor 2*SF2 is used, the peak throughput of a UE is 2.0 Mbps, assuming that other UEs are not transmitting simultaneously.

The peak throughput from one submodule / WSPC card is 3*2 Mbps = 6 Mbps. This is achieved when one or two users are in each HSUPA resource step.

Number of HSUPA UEs in two consecutive HSUPA resource steps (1 and 2, 3 and 4, 5 and 6, 7 and 8, 9 and 10)

SF4 2xSF4 2xSF2 + 2xSF4

L1 (kbps) L1 (kbps) L1(kbps)

1 700 1300 5700

2 700 1300 5700

3 700 1300 5700

4 700 1300 5700

5 700 1300 5700

6 700 1300 5700

7 700 1300 5700

8 700 1300 5700

9 700 1300 5700

10 700 1300 5700

11 700 1300 5700

12 700 1300 4300

13 700 1300 4300

14 700 1300 4300

15 700 1300 4300

Table 73 Peak throughput for HSUPA Flexi WCDMA BTS System Module Rel2 / UltraSite WCDMA BTS EUBB, pair of resource steps 1 and 2, 3 and 4, 5 and 6, 7 and 8, 9 and 10

DN70118376Issue 04E

181


Id:0900d805806f89a2

Example 1: Commissioning Flexi WCDMA BTS

• Minimum baseband decoding capability is 2.8Mbps, 2ms TTI users • Minimum number of HSUPA UEs per BTS = 6 users • System Module Rel2 – FSMD • 36 CE reserved statically for HSUPA (not to be taken for R99 traffic)

Example 2: Commissioning Flexi WCDMA BTSTo dimension 4.2 Mbps combined L1 throughput (of all 2ms TTI and 10ms TTI UEs) with 12 users and System Module Rel2 (FSMC, FSMD or FSME), three HSUPA resource steps are needed, that is, resource steps 1-3 (18 CE + 18 CE + 18 CE = 54CE).

Example 3: HSUPA resources reduced because of increasing DCH trafficThis example describes how the HSUPA resources of a Flexi WCDMA BTS are reduced because of the increasing DCH traffic.

As a starting point, there are nine HSUPA users (2ms TTI and 10ms TTI UEs) with three allocated HSUPA resource steps (18 CE + 18 CE + 18 CE = 54 CE in use (System Module Rel2)). The combined baseband L1 throughput of all users is 5.6 Mbps.

When the amount of DCH traffic (for example, AMR calls) increases, HSUPA resources are needed to reduce from three HSUPA resource steps to two HSUPA resource steps.

When two HSUPA resource steps are used (18 CE + 18 CE = 36 CE), the combined baseband L1 throughput of all users is dropped to 4.2 Mbps.

Example 3: More HSUPA UEs added (limited CE resources)This example describes the addition of more HSUPA UEs to a Flexi WCDMA BTS with limited CE resources.

As a starting point, there are ten HSUPA users with four allocated HSUPA resource steps (18 CE + 18CE + 18 CE +18 CE = 72 CE in use (System Module Rel2)). The combined baseband L1 throughput of all users is 5.6 Mbps.

When ten more HSUPA UEs are added (a total of 20 HSUPA UEs), there are still four HSUPA resource steps in use (18 CE + 18 CE + 18 CE + 18CE = 72 CE). The combined baseband L1 throughput of all users is still 5.6 Mbps.

When five more HSUPA UEs are coming in (=> total 25 HSUPA UEs), five HSUPA resource steps are in use (18 CE + 18 CE + 18 CE + 18CE + 18CE = 90 CE). The combined baseband L1 throughput of all users is still 5.6 Mbps.

When again six more HSUPA UEs are added (a total of 31 HSUPA UEs), it is not possible to add more HSUPA resources since the remaining resources are used by DCH traffic. The new HSUPA UEs will use the same five HSUPA resource steps as the existing HSUPA UEs.

As a result, five HSUPA resource steps are still in use (18 CE + 18 CE + 18 CE + 18 CE + 18 CE = 90 CE). The combined baseband L1 throughput of all users has now dropped to 2.8 Mbps.

HSPA sharingIn case of limited WSPC capacity (typically one WSPC and several WSPAs in the BTS), HSUPA and HSDPA minimum baseband allocation scheduler or HSDPA 16 users per cell can be allocated to the same WSPC.

182 DN70118376Issue 04E


Id:0900d8058073f437

4.7 Extended cellThe basic principles for extended cell in WCDMA BTS are as follows:

• An extended cell is the one with a radius that is greater than 20km. • Cells with a radius of 20km or less are handled according to the usual baseband

dimensioning rules. • CE dimensioning must be calculated separately for each extended cell. For

example, if there is a 1+1+1 configuration with 1 * 20 km cell and 2 * 100 km cell, you need to calculate 1* 20 km cell according to the normal common channel dimen-sioning rules and 2 *100 km cells according to the extended cell dimensioning rules.

• Extended cell CE dimensioning rules are the same for all WCDMA frequencies. • One or several of the cells in the BTS (supported configurations) can be configured

as extended cells.

In RU20 On Top, extended cell is tested up to 150 km.

Extended cell in Flexi WCDMA BTSExtended cell common control channel dimensioning rules for Flexi WCDMA BTS are as follows.

Required CE in case of Flexi System Module Rel1:

• Up to 60 km cell: 27 UL / 27 DL CE • Up to 120 km cell: 54 UL/ 54 DL CE • Up to 180 km cell: 80 UL / 80 DL CE

Note that this is the worst assumed case consumption (E-Cell with other cells in the same Flexi submodule). When only extended cell is located in the Flexi submodule, the following CE resources are required:


Example: For 2+1+1 configuration (3 cells/20 km +1 cell/80 km) with Flexi FSMB, the following CCCH CEs resources are required:

3 cells/20 km – 26 CE/26 CE UL/DL (1st submodule)

1 cell/80 km – 53 CE/26 CE UL/DL (2nd submodule)

Required CEs in case of Flexi System Module Rel2 UL/DL:

The number of CE required for extended cell depends on a cell range and site configu-ration. One extended cell with range up to 180km can be served with 36CE (UL/DL) However, in case when a lower cell radius is required, more than one extended cell can be served with 36CE, or the extended cell can be served together with normal cells, using CE included into System Module Rel2 capacity.

For example:1+1/10km + 1/40km - 0CE required for CCCH2+2/10km + 2/40km - 36CE (UL/DL) required for CCCH

DN70118376Issue 04E

183


Id:0900d8058073f437

Other site configurations that can be served with pool of 36CE can be determined with the following formula:


Cell Range user cell radius in km

# of Signatures maximum number of preamble signatures 1 =< z =< 4

where:

0km < cell radius =< 60km # of signatures=4



Extended cell in UltraSite WCDMA BTSFor UltraSite WCDMA BTS, it is advisable to have at least one WSPC per extended cell (+WSP for normal CCCH) for optimal CE consumption.

Provided that every extended cell has its own WSPC (WSP capacity for normal CCCH), Extended cell common control CE dimensioning rules for UltraSite WCDMA BTS are as follows:


Required CE for extended cell in case of EUBB subrack:

The number of CE required for extended cell depends on a cell range and site configu-ration. One extended cell with range up to 180km can be served with 36CE (UL/DL) However, in case when a lower cell radius is required, more than one extended cell can be served with 36CE, or the extended cell can be served together with normal cells, using CE included into EUBB subrack capacity.

For example:1+1/10km + 1/40km - 0CE required for CCCH2+2/10km + 2/40km - 36CE (UL/DL) required for CCCH

Other site configurations that can be served with pool of 36CE can be determined with the following formula:


Cell Range user cell radius in km

# of Signatures maximum number of preamble signatures 1 =< z =< 4

where:



Cell Rangei # of Signaturesi 2⋅ ⋅( ) 480≤

i 1=

#_of_cells

∑

Cell Rangei # of Signaturesi 2⋅ ⋅( ) 480≤

i 1=

#_of_cells

∑

184 DN70118376Issue 04E


Id:0900d8058073f437


DN70118376Issue 04E

185


Id:0900d805806f8af1

4.8 WCDMA BTS capacity allocation principles

4.8.1 Capacity allocation principles for Flexi WCDMA BTSNote that the baseband allocation principles, which are presented here, are valid for one LCG.

In RU20/RU20 On Top release, ”soft prereservation” is used during BTS startup for HW Rel1 (if System Module Rel1 is used for HSPA). The main target of soft prereservation is to assure baseband resources for HSUPA by allocating CCCH and HSDPA in optimal place from HSUPA resource point of view. Soft prereservations force TCOM to allocate CCCH and HSDPA baseband resources assuming that HSUPA resources (up to the maximum HSUPA scheduler capacity) are prereserved. If available BB resources are not enough to allocate CCCH, HSDPA and HSUPA baseband resources, soft prereser-vation is not taken into consideration.

Note that because of soft prereservation, soft prereserved resources (System Module Rel1 - 9 HSUPA resource steps) are considered during CCCH and HSDPA allocation procedure as occupied until there is enough space for CCCH and HSDPA resources.

Allocation of common control channelsIn RU20/RU20 On Top, in HW release mix case (over one LCG), System Module Rel2 is selected for CCCH CE allocation, unless frequency layer mapping to HW is used. Therefore, if System Module Rel2 is available, then baseband resources for CCCH are allocated at System Module Rel2. This rule can be changed with Mapping HSPA cell to HW commissioning parameter, which can be used by the operator for mapping HSPA frequencies to different system modules. If some frequency layer is mapped to the given system module, the selected system module has to provide CE for common control channels for cells from the assigned frequency layer.

CCCH allocation rules for Flexi System Module Rel1:The first to third cell common control channels (CCCH) are allocated to the least loaded submodule in the system module. The fourth to sixth cells CCCHs are allocated to another least loaded submodule in the system module. Each system module can support 6 cells. Therefore, if more cells are available, then the second LCG has to be created. In this case, seventh to ninth cells are allocated on the extension module.

For example, in a 2+2+2 configuration (2* 26 CE = 52 CE for common control channels) the capacity is allocated as described in the figure CCCH allocation in Flexi WCDMA BTS in a 2+2+2 configuration:

186 DN70118376Issue 04E


Id:0900d805806f8af1

Figure 68 CCCH allocation in Flexi WCDMA BTS in a 2+2+2 configuration

For example, in a 3+3+3 configuration (3* 26 CE = 78 CE for common control channels) the capacity is allocated as described in the following figure:

Figure 69 CCCH allocation in Flexi WCDMA BTS in a 3+3+3 configuration

For CCCH allocation (also extended cells) the following priorities are considered during FSMB Submodule selection:

1. FSMB submodule which has already allocated resources for less than 3 CCCH cells and those resources are able to handle a new cell

2. non-HSUPA FSMB submodule without CE for CCCH processing in same mas-ter/extension system module and has enough capacity to handle a whole cell

3. non-HSUPA FSMB submodule without CE for CCCH and has enough capacity to handle a whole cell

4. non-HSUPA FSMB submodule which has allocated resources for less than 3 CCCH cells and has enough capacity to handle a whole cell

5. HSUPA FSMB submodule which has allocated resources for less than 3 CCCH cells and has enough capacity to handle a whole new cell

DN70118376Issue 04E

187


Id:0900d805806f8af1

CCCH allocation rules for Flexi System Module Rel2:The CEs required for the common control channels for 3 * 20km cells or 6*10km cells per System Module Rel2 are included in the system module. If there is more than 3*20km or 6*10km cells required, additional CE must be allocated from the system module capacity that is provided for traffic use.

If there is more than one LCG created on the system module, only one LCG can use the CCCH CEs included in the module, even if the number of cells is low, for example 3*10km. The CEs required for other LCGs are taken from the system module capacity that is provided for traffic use and belongs to the given LCG space.

Mixed system module release scenarios:In case of mixed system module release scenario, CCCH are allocated by default at System Module Rel2. Operator can change the allocation rule using Mapping HSPA cell to HW commissioning parameter.

Note that this parameter impacts allocation rules for all services (DCH, HSDPA and HSUPA).

If two LCGs are created, the first LCG cells are allocated at FSMB module according to rules presented for System Module Rel1, while the second LCG cells are allocated according to a description presented in System Module Rel2.

Allocation of dedicated channelsIn case of DCH allocation, the following priorities are considered during submodule selection:

1. FSMC/D/E least loaded non-HSUPA submodule which is capable of allocating the users with maximum bit rate

2. FSMC/D/E least loaded HSUPA submodule which is capable of allocating the user with maximum bit rate

3. FSMB submodule that is capable of allocating the user with the maximum bit rate4. FSMC/D/E least loaded submodule5. FSMB least loaded submodule

RU20 introduces Mapping HSPA cell to HW commissioning parameter which can be used by the operator for mapping HSPA frequencies layers to different system modules. Note that mapping of frequency layers to HW is not mandatory.

If some frequency layer is mapped to a given system module, the selected system module has to provide CE for common control channels (as well as HSPA resources) for cells from the assigned frequency layer. In this case, DCH users from the assigned frequency layer are allocated at the selected system module. If the selected system module cannot allocate more DCH users from the assigned frequency layer, new DCH users can be allocated at a different system module. For example: frequency layer 1 is assigned to the FSMB System Module, while frequency layer 2 is assigned to FSMD System Module. If FSMB System Module is fully occupied while FSMD has free resources for a few DCH users, new DCH users from frequency layer 1 are allocated at FSMD System Module.

HSDPA allocation principlesIn RU20/RU20 On Top release, in HW release mix case (over one LCG) System Module Rel2 is selected for HSPA (HSDPA and HSUPA) allocation. Therefore, if System Module Rel2 is available, then HSDPA resources are only allocated at System Module Rel2. In this case, System Module Rel1 (FSMB) is not considered for HSDPA allocation.

188 DN70118376Issue 04E


Id:0900d805806f8af1

This rule can be changed with the Mapping HSPA cell to HW commissioning parameter, which can be used by the operator for mapping HSPA frequencies to differ-ent system modules. Some frequencies can be mapped to one system module and other frequencies to another system module. If some frequency layer is mapped to a given system module, then it has to provide HSPA (HSDPA and HSUPA) resources for cells from assigned frequency layer (A-DCH resources can be allocated similar as DCH at a different system module if the selected system module is fully occupied).

In case of HSDPA allocation, the following priorities are considered during submodule selection:

1. System Module Rel2In case of “Minimum baseband allocation” scheduler allocation, the following priori-ties are considered during submodule selection: • FSMC/D/E non-HUSPA and non-CCCH submodule • FSMC/D/E non-HUSPA submodule • FSMC/D/E submoduleIn case of “Shared HSDPA scheduler for baseband efficiency” or “Full baseband” scheduler allocation the following priorities are taken into consideration during sub-module selection: • FSMC/D/E HSUPA submodule which is non-HSDPA and non-CCCH

(RU20 main release) • FSMC/D/E non-HSUPA and non-CCCH submodule • FSMC/D/E non-HSUPA submodule • FSMC/D/E submodule

2. System Module Rel1In case of “Minimum baseband allocation” or “HSDPA 16 users per cell” scheduler allocation, the following priorities are considered during submodule selection: • FSMB non-HSUPA system module • FSMB submoduleIn case of “Shared HSDPA Scheduler for baseband Efficiency” or “Full baseband” or “48 users per cell” scheduler allocation the following priorities are considered during submodule selection: • FSMB non-HSUPA system module • FSMB submodule

HSUPA allocation principlesIn RU20/RU20 On Top release, in HW release mix case (over one LCG) System Module Rel2 is selected for HSPA (HSDPA and HSUPA) allocation. Therefore, if System Module Rel2 is available, then HSUPA resources are only allocated at System Module Rel2. This rule can be changed with Mapping HSPA cell to HW commissioning parameter, which can be used by the operator for mapping HSPA frequencies to differ-ent system modules. Some frequencies can be mapped to one system module and other frequencies to another system module. If some frequency layer is mapped to a given system module, then it has to provide HSPA (HSDPA and HSUPA) resources for cells from assigned frequency layer (SRB for HSPA resources can be allocated similar as DCH at a different system module if the selected system module is fully occupied).

In case of HSUPA, the following priorities are considered during selection of the sub-module:

1. System Module Rel2

DN70118376Issue 04E

189


Id:0900d805806f8af1

• FSMC/D/E CCCH submodule • FSMC/D/E HSDPA submodule • FSMC/E/D submodule

2. System Module Rel1 • FSMB non-HSDPA and non CCCH submodule • FSMB CCCH submodule.

4.8.2 Capacity allocation principles for UltraSite WCDMA BTSCapacity allocation principles for UltraSite WCDMA BTS provides an overview of managing the digital signal processor (DSP) and asynchronous transfer mode (ATM) resources that are required for the common and dedicated channels in the wideband code division multiple access (WCDMA) base transceiver station (BTS). In the WCDMA, the number of users in the air interface can be relatively large and, therefore, the alloca-tion and efficient use of the resources are important. The reason for functioning is that the DSP processing and ATM transmission capacity have been distributed inside the BTS. The number of mobile users the BTS can carry depends on the services that the users have. For example, a video call takes much more resources than a traditional speech call.

In the BTS, the telecom (TCOM) software (SW) runs resource management (RM)-related tasks. In practice, the BTS TCOM RM software receives resource requests for different channel allocations from the radio network controller (RNC). The BTS TCOM calculates the resource need for the channel based on the parameters received in the resource request and selects the appropriate resources for the requests. If a WSP unit does not have enough resources, the call can be allocated to another wideband signal processor (WSP) unit under a specific Wideband Application Manager (WAM) unit. Another important feature in the TCOM RM software is the load balancing between the BTS subracks and units. The BTS TCOM RM software has been divided into global and local RMs.

Figure BTS TCOM RM overall presents the overall RM software within the BTS. Basi-cally, the global RM takes care of the WAM and the local RM of the WSP selection.

Figure 70 BTS TCOM RM overall

4.8.2.1 Primary/Secondary WAMIn the UltraSite WCDMA BTS, each non EUBB subrack has two slots for the WAM units, that is, the Primary and Secondary slots. The exception to this is the MetroSite 50/WCDMA BTSs, which have only one Primary WAM slot available. The first WAM in the subrack is always installed in the Primary unit slot that has access to every control bus and can thus start and drive the subrack. The Secondary WAM is required when

WSPs WSP WSP WSP WSP WSP WSP

On each WAM Local RM Local RM

Master WAM Global RM

190 DN70118376Issue 04E


Id:0900d805806f8af1

there are more than three WSPs installed in a subrack. It provides ATM/ATM adaptation layer type 2 (AAL2) capacity and telecom functions for the allocated WSPs. However, it does not have access to all control and data buses and, therefore, cannot drive the subrack in the case of a Primary WAM failure.

Figure 71 Primary/Secondary WAMs in a subrack

4.8.2.2 Master/Slave WAMOne of the Primary WAMs in a cabinet is the master WAM. This WAM is the master con-troller for the whole BTS and performs common O&M and telecom functions such as local storing and distributing of operational software, configuration management, alarm collection, handling and cabinet level telecom resource management. Other Primary WAMs, that are not in a master mode are called slave WAMs. A slave WAM can be allo-cated to be a master WAM in cases where the current master WAM fails. Selection of a new master WAM requires a BTS site reset.

R-busWAF

WT

R

WA

M

RR-bus

RT-bus

T-bus

WPA

WAF

WPA

WT

R

WA

M

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

DSC-bus

SecondaryWAM

PrimaryWAM

RR-bus

RT-bus

WSM

DN70118376Issue 04E

191


Id:0900d805806f8af1

Figure 72 WSP and WAM allocation within a subrack

When EUBB hardware is available, WSMF is used as a master TCOM for the whole UltraSite BTS while WAM is responsible for O&M functions.

4.8.2.3 WSP and WAM allocation within a subrackWhen a call setup procedure is started and a request is sent to the BTS, several deci-sions are required relating to resource allocations and their management. A basic guide-line for a subrack/WAM selection is that the load is shared equally between the subracks and WAMs. This can be based on WSP load, ATM load and AAL2 capacity. When a subrack/WAM (or the ATM termination point) is selected, it cannot be changed. A call can be moved within the WSPs under the selected WAM.

A WAM can handle up to three WSPs. The served WSPs are allocated to WAMs based on a unit slot number and WSP type. The first three WSPC units found in the lowest slots are allocated to the Secondary WAM. If less than three WSPC units are found, then WSPA units, starting from the lowest slot, are allocated to the Secondary WAM. The last found 1-3 WSP units are allocated for the Primary WAM. This kind of allocation is called a WAM pool, that is WAM + 1...3*WSP.

R-busWAF

WT

R RR-bus

RT-bus

T-bus

WPA

WAF

WPA

WT

R

DSC-bus

RR-bus

RT-bus

Secondary WAMs,always in Slave

WAM mode

Primary WAMs caneither be in Master orSlave WAM mode

R-busWAF

WT

R RR-bus

RT-bus

T-bus

WPA

WAF

WPA

WT

R

DSC-bus

RR-bus

RT-bus

R-busWAF

WT

R RR-bus

RT-bus

T-bus

WPA

WAF

WPA

WT

R

DSC-bus

RR-bus

RT-bus

IFU

WSC

AXU

lub

CarrierInterface

WSCMAIN

WSCREDU

WA

M

WA

M

WA

M

WA

M

WA

M

WA

M

ST-busSR-bus

ST-busSR-bus

ST-busSR-bus

ST-busSR-bus

WSM

WSM

WSM

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

WS

P

192 DN70118376Issue 04E


Id:0900d805806f8af1

Example: Four WSPs (3 WSPC and 1 WSPA) installed in bb-subrack slots 1, 3, 5, and 6, two WAMsTwo WAMs are needed and the WAM pools are created as follows:

Pool1: The Secondary WAM handles the WSPC cards in slot 1, 3 and 6.

Pool2: The Primary WAM handles the WSPA in slot 5.

Figure 73 WSP to WAM allocation

4.8.2.4 Capacity allocation principles for UltraSite WCDMA BTSIn RU20/RU20 On Top release, “soft prereservation” is used during BTS startup for HW Rel1 (if HW Rel1 used for HSPA allocation). The main order of soft prereservation is to assure baseband resources for HSUPA by allocating CCCH and HSDPA in an optimal place from HSUPA resource point of view. Soft prereservations force TCOM to allocate CCCH and HSDPA baseband resources, assuming that HSUPA resources (up to the maximum HSUPA scheduler capacity) are pre-reserved. If there is not enough available baseband resources to allocate required CCCH, HSDPA and HSUPA baseband resources, then soft prereservation is not considered. Note that soft prereservation effects can be observed only with some WAMs/WSPs configurations.

Note that because of soft prereservation, the soft prereserved resources (WSPC) is con-sidered during CCCH and HSDPA allocation procedure as occupied until there is enough space for CCCH and HSDPA resources.

4.8.2.5 Common control channel (CCCH) allocationIn RU20/RU20 On Top release, CCCH CE resources allocation depends on the avail-able HW. If EUBB subrack is available, then CE for CCCH are only allocated at WSPF cards (EUBB subrack). In this case (EUBB and non-EUBB subrack - over one LCG), non-EUBB subrack (WSPA/WSPC) is not considered during CCCH allocation. However, this rule can be changed with Mapping HSPA cell to HW commissioning parameter. With this parameter the operator can map HSPA frequencies to a different subrack releases (EUBB and non-EUBB subrack). Some frequencies can be mapped to non-EUBB (WSPA/WSPC) and other frequencies to another EUBB subrack (WSPF). If some frequency layer is mapped to the given release type subrack (EUBB or non-EUBB), selected release type subrack has to provide baseband resources for common control channels for the cells from assigned frequency layer.

DSC-BUS

WS

PC

6

WS

PA

5

WS

PC

3

WS

PC

1

WPA

WPA

WTR

WTR

WSM

Primary

WAM WAM

WAF

WAF

Secondary

DN70118376Issue 04E

193


Id:0900d805806f8af1

The EUBB subrack contains the included CE for basic CCCH configuration (up to 6 cells/10km or 3cells/20km). If EUBB subrack is used as CCCH favor, then CE included in EUBB subrack capacity is used. In certain cases, if more cell or radius is required, more CE capacity needs to be allocated:

• In case of 6 cells/20 km - 36 CE are needed • In case of 9 cells/20km - 72 CE are needed • In case of 12 cells/20 km -108 CE are needed

Table UltraSite WBTS CCCH CE for HW release mix case and cell range < 10 km using Mapping HSPA cell to HW commissioning parameter presents required CCCH baseband resources for HW release mix case (EUBB and non-EUBB subrack) and cell range up to 10km when frequency layer mapping is used

* CEs for common control channels for 3 * 20 km cells or 6 * 10 km cells per system module are included in the module.

If EUBB subrack is split between 2 LCGs, only one LCG can use CCCH CE included in EUBB subrack (even if the number of cells and cell range is low, for example 3*10km). CCCH CE capacity, which is required for cells from the second LCG CCCH, is taken from EUBB subrack capacity which belongs to the second LCG.

Common control channel allocation rules for Ultra Subrack (WSPA/C) The following list summarizes the different WSP units and their capacity alternatives in an Adaptive Multi-Rate speech codec (AMR)/CCCH mode.

WSPA:

• 32 AMR users: no common control channels • 24 AMR users: common control channels for one cell • 16 AMR users: common control channels for two cells • 8 AMR users: common control channels for three cells

Number of cells Number of LCG

CCCH CE allocated at non-EUBB subrack

CCCH CE allocated at EUBB subrack

1…3 (for example 1+1+1) 1 LCG 0 0* CE (1+1+1, carrier 1 mapped to EUBB subrack or frequency layer mapping not used)

1…3 (for example 1+1+1) 1 LCG 24 CE (1+1+1, carrier 1 mapped to non-EUBB subrack)

0

4…6 (for example 2+2+2) 1 LCG 0 0* CE (2+2+2, carrier 1 and 2 mapped to EUBB subrack or frequency layer mapping not used)

4…6 (for example 2+2+2) 1 LCG 24 CE (1+1+1, carrier 1 mapped to non-EUBB subrack)

0* CE (1+1+1, carrier 2 mapped to EUBB subrack)

Table 74 UltraSite WBTS CCCH CE for HW release mix case and cell range < 10 km using Mapping HSPA cell to HW commissioning parameter

194 DN70118376Issue 04E


Id:0900d805806f8af1

WSPC:

• 64 AMR users: no common control channels • 48 AMR users: common control channels for one - three cells

The CCCH baseband resources allocation order is:

1. WSPA2. WSPC

The CCCHs are allocated between the subracks to different WSP units for redundancy and load balancing reasons. The basic principles for CCCH allocation are as follows:

• Common control channels are primarily allocated to WSPA units if available. • Select a WAM that does not yet handle any common control channels and has a

WSPA. • If such a WAM is not available, select a WAM that handles the smallest amount of

common control channels and has a WSPA. • If there is no WAM with a WSPA, select a WAM with a WSPC. The same WAM is

also selected to handle the common control channels of one to three cells.

When the CCCHs are allocated, they can be located in any subrack within a cabinet. The WSPC is depicted as a one-DSP environment having 64 CE. In the following figures, one slot depicts one CE.

Example: 1+1+1 configuration with two WSPA units in different subracksThe CCCHs are allocated so that subrack 1 has 2-cell CCCHs and subrack 2 has 1-cell CCCH as shown in Figure Common control channel allocation example for 1+1+1 con-figuration with two WSPAs.

Figure 74 Common control channel allocation example for 1+1+1 configuration with two WSPAs

Example: 1+1+1 configuration with two WSPC units in different subracksThe CCCHs are allocated so that subrack 1 has all 3-cell CCCHs as shown in figure Common control channel allocation example for 1+1+1 configuration with two WSPCss.

Figure 75 Common control channel allocation example for 1+1+1 configuration with two WSPCs

DN70118376Issue 04E

195


Id:0900d805806f8af1

Example: 2+2+2 configuration with two WSPC units in different subracksThe CCCH are allocated so that subrack 1 has all 3-cell CCCH and subrack 2 has 3-cell CCCH as shown in figure Common control channel allocation example for 2+2+2 con-figuration with two WSPCs.

Figure 76 Common control channel allocation example for 2+2+2 configuration with two WSPCs

CCCH allocation with single WPA and several TRXsA special case is when a WPA is divided between, for example, two TRXs. In this case, the CCCHs are allocated to WSPs that are allocated to the same WAM unit because of WPA unit power control functions.

4.8.2.6 Dedicated channel (DCH) allocationIn RU20/RU20 On Top release, WSPF (EUBB) is favored in HW release mix scenario (EUBB and non-EUBB subrack) for DCH allocation. During DCH allocation, the follow-ing priorities are considered for WSP selection:

1. least loaded non-HSUPA WSPF which is capable of allocating users with maximum bit rate

2. least loaded HSUPA WSPF which is capable of allocating users with maximum bit rate

3. WSPA/C which is capable of allocating users with maximum bit rate4. least loaded WSPF5. least loaded WSPA/C

RU20 introduces Mapping HSPA cell to HW commissioning parameter which can be used by the operator to map HSPA frequencies layers to EUBB or non-EUBB subrack (WSPA/C). Note that mapping of frequency layers to HW is not mandatory. Some frequencies can be mapped to non-EUBB subracks (WSPC/A) and other frequen-cies to EUBB subrack, so both subrack types are utilized for HSPA. If some frequency layer is mapped to a given subrack (EUBB or non-EUBB subrack), it has to provide CE for common control channels for cells from the assigned frequency layer. In this case, DCH users from assigned frequency layer are allocated at the selected subrack type (EUBB or non-EUBB subrack). If the selected subrack type is not able to allocate more DCH users from the assigned frequency layer, DCH users can be allocated at a different subrack type. For example, frequency layer 1 is assigned to non-EUBB subrack (WSPA/WSPC) while frequency layer 2 is assigned to EUBB subrack. Non-EUBB subracks capacity becomes fully occupied while EUBB subrack has free processing resources. Since there are new DCH users from frequency layer 1 but there is not enough free place at any of non-EUBB subracks, new DCH users from frequency layer 1 are allocated at EUBB subrack.

196 DN70118376Issue 04E


Id:0900d805806f8af1

Load sharing principles between WSP, WAM, and subrackWhen a new radio access bearer (RAB) service or a call setup is requested, the follow-ing selections are done:

• Subrack/WAM selection, ATM termination • WSP selection • DSP environment selection

A basic rule for the subrack/WAM selection is that the load is shared equally between the subracks and WAMs. The criteria for this are the WSP load, ATM load, AAL2 capacity and CTRL MCU load on the WAM. Based on a reference value calculated for each WAM, the subrack and WAM that has the most capacity available are selected. The EUBB subrack is prioritized for traffic allocation, therefore, load sharing between EUBB and non-EUBB subrack is not available. With the WSP/DSP selection for a new RAB request, the RRM primarily allocates the RAB to the most fully loaded WSP/DSP environment possible within the WAM pool WSPs. In other words, the RRM keeps a maximum number of resources free to enable high data rate calls. From RAN04 onwards, the RRM favors the WSPC units for a new AMR call because of a possible reconfiguration or a new RAB request, until the free capacity between the subracks or units is equal. The following table shows the use of the CEs for different calls and data rates.

Example: Load sharing principles between the WSP, WAM and a subrack with 1+1+1 configuration with two WSPA units in different subracksThe CCCHs are allocated so that subrack 1 gets two-cell CCCHs and subrack 2 gets one-cell CCCH. The AMR calls 1-8 are allocated to subrack 2 because of load balancing as presented in Figure CCCHs with eight AMR calls in WSPA. The additional AMR calls are allocated one by one between the subracks until the full capacity is used.

User data rate required Number of CEs

AMR 12.2 1

AMR 7.95 1

AMR 5.9 1

AMR 4.75 1

AMR 12.65 1

AMR 8.85 1

AMR 6.65 1

PS 16 1

PS 32 2

PS 64/128 4

PS 256 8

PS 384 16

CS 14.4 1

CS 57.7 4

CS 64 4

Table 75 Use of CEs with different data rate calls (WSPA/WSPC)

DN70118376Issue 04E

197


Id:0900d805806f8af1

Figure 77 CCCHs with eight AMR calls in WSPA

In case of higher data rate calls, the RRM checks the possibility to allocate a call to any existing eight-call environment if there are enough free resources available. If not, the allocation is done to another subrack WSPA unit, and a new eight-call environment is used.

Example: Load sharing principles between the WSP, WAM and a subrack with 1+1+1 configuration with two WSPC units in different subracksThe CCCHs are allocated so that subrack 1 gets all of the 3-cell CCCHs. The AMR calls 1-16 are allocated to subrack 2. After this, each new call is allocated one-by-one equally between the subracks as presented in Figure CCHCs with 16 AMR calls in WSPCs.

Figure 78 CCHCs with 16 AMR calls in WSPCs

In case of higher data rate calls that request more capacity, the next new AMR call is allocated to the other subrack for load balancing.

Example: Load sharing principles between the WSP, WAM, and a subrack with 1+1+1 configuration with WSPA and WSPC units in different subracksIn case of a mixed WSPx configuration, all CCCHs are allocated to a WSPA unit, as pre-sented in Figure CCCH allocation in a mixed WSPA/C case. After this, all resource requests are allocated to a WSPC until there is space for eight AMR calls in both units, as presented in Figure Resource allocation until equal amount of free resources.

Figure 79 CCCH allocation in a mixed WSPA/C case

198 DN70118376Issue 04E


Id:0900d805806f8af1

Figure 80 Resource allocation until equal amount of free resources

In figure Resource allocation until equal amount of free resources, the WSPC capacity is reserved for one 384 kbit/s, one 128 kbit/s, and two 64 kbit/s PS data calls and 28 AMR calls.

RAB reconfigurationIn case of a RAB reconfiguration, for example, 64 kbit/s to 384 kbit/s, a call can be re-allocated to another WSP unit under the same WAM pool, provided that there are not enough free resources in the original WSP unit. If there is a lack of resources under the specific WAM pool WSPs, the RAB reconfiguration requested is rejected and the original 64 kbit/s service is maintained. In RAN1.5 with only the WSPA supported, the allocation is done so that the WSP unit that is most full (and in the case of a WSPA, the most full 8-call environment also) that has enough capacity to handle the call is selected. From RAN04 onwards, WSPC is supported and the same principles apply as in RAN1.5.

Multi-RAB supportIn Multi-RAB configurations, the RAB requests more resources than an AMR call. The principle is the same as in other cases, so that the total RAB-requested resource amount is compared to the existing free environment, the most unrestricted WAM environment is selected based on principles of the load balancing.

Asymmetric uplink/downlink (UL/DL) bit rateAsymmetric UL/DL means that the UL and DL directions have different bit rate require-ments. The rule for allocating WSP/submodule resources for asymmetric bit rates is based on a higher data rate requirement, but CE reservations are made separately for UL/DL. For example, if the UL bearer on 16 kbps and DL bearer on 384 kbps, the CE reservation is 1 CE in UL and 16 CE in DL (WSPA/WSPC).

4.8.2.7 Recovery actions

WSP failureIn case of a WSP failure with common channels, the cell is temporarily put out of service while the CCCHs are reallocated. If there are no free resources available during the CCCH reallocation, the cell stays down and this is indicated by an alarm (from RAN04 onwards). In case of an allocated WSP failure for active calls, the calls are lost and must be redialled.

WAM failureIn case of slave or Secondary WAM failure, the specific WSPs controlled by the failed WAM are lost and the calls are dropped. Recovery is done through a site reset and the RF network is maintained only with less WAM/WSP capacity. In case of master WAM failure, a new master WAM is selected if there are other working Primary WAM units in

DN70118376Issue 04E

199


Id:0900d805806f8af1

the cabinet. The new master WAM used through BTS reset. After an unwanted slave WAM reset, for example by power reset, the specific WTRs stay in a disabled state. Recovery is done through a site reset. The master WAM is switched over to another master WAM (=Primary WAM) candidate through the site reset. The failed master WAM and the associated Secondary WAM are lost, as is the associated WSP capacity. The cell behind the master WAM is also lost.

In case of an EUBB subrack failure (WAMA/WSMF), the BTS cannot operate without subrack replacement.

HSDPA allocationIn RU20/RU20 On Top release, WSPF card (EUBB) is used for HSPA (HSUPA and HSDPA) allocation in case of HW mix scenario (EUBB subrack and non-EUBB subrack (WSPC/A) - one LCG). In HW release mix case, only EUBB subrack is considered for HSPA allocation. In HW mix scenario, non-EUBB subrack (WSPA/C) can be used for HSDPA allocation only if frequency layer mapping to non-EUBB subrack is used through Mapping HSPA cell to HW commissioning parameter. Non-EUBB subrack (WSPC/A) in case of HW mix scenario if frequency layer mapping to non-EUBB subrack is used with Mapping HSPA cell to HW commissioning parameter. With this param-eter, the operator can map HSPA frequencies layers to different EUBB and non-EUBB subrack (WSPA/C). Some frequencies can be mapped to non-EUBB subrack (WSPC/A) and other frequencies to another EUBB subrack, so that both subrack release types are utilized for HSPA. If some frequency layer is mapped to the given type of subrack (EUBB or non-EUBB subrack), then it has to provide HSPA resources for cells from the assigned frequency layer. A-DCH resources can be placed similar to DCH at different subrack type, if selected subrack (EUBB or non-EUBB subrack) is fully occupied.

Note that in case of frequency layer mapping, the selected HW has to provide CCCH resources for cells from the assigned frequency layer. The second way of using non-EUBB subracks (WSPC/A) for HSPA traffic in HW release mix scenario is Local cell grouping. In this case, one LCG should cover UltraSite subrack(s) and the second LCG EUBB subrack.

Note that HSDPA scheduler cannot be allocated at WSPA card.

HSDPA allocation details for EUBB subrack (WSPF)In case of HSDPA resource allocation, the following priorities are considered during WSPF card selection (if more than one WSPF card is available in EUBB subrack).

In case of “Minimum baseband allocation” scheduler allocation, the following priorities are considered during WSPF card selection:

a) non-HUSPA and non-CCCH WSPF cardb) non-HUSPA WSPF cardc) WSPF card

In case of ''Shared HSDPA scheduler for baseband efficiency” or “Full baseband” sched-uler allocation the following priorities are considered during Submodule selection

a) non-HSUPA and non-CCCH WSPF cardb) non-HSUPA WSPF cardc) WSPF card

200 DN70118376Issue 04E


Id:0900d805806f8af1

HSDPA allocation details for non-EUBB subrack (WSPA/C)When a high-speed downlink packet access (HSDPA) call is established, the necessary capacity allocations and reservations are on the virtual channel connection (VCC), WAM, and WSP level.

The VCC selection is done by the RNC, and either a HSDPA dedicated VCC or a shared VCC is used.

With BTS AAL2 multiplexing, the WAM and WSP selection is done by the BTS. In prin-ciple, the HSDPA scheduler is allocated to the WAM with the highest AAL2 bit rate avail-able. One exception is the first HSDPA scheduler, which is allocated in the master WAM if it has WSPC cards and WSPC resources are not prereserved for HSUPA.

The first HSDPA scheduler is allocated in the WSPC under the master WAM unit. The second HSDPA scheduler is then allocated in the WSPC under the next WAM with the biggest AAL2 bit rate and enough CE capacity (WSPC). If the AAL2 bit rates are the same and there is enough WSPC capacity, the next WAM slot is selected. The third HSDPA scheduler is allocated in the WSPC under the next WAM with the biggest AAL2 bit rate with enough CE capacity (WSPC). If the AAL2 bit rates are the same and there is enough WSPC capacity, the next WAM slot is selected.

With basic AAL2 multiplexing, the WAM selection is done by the VCC selection.

Note that HSDPA scheduler cannot be allocated at WSPA card.

For more information on WAM allocation, see Introduction in HSDPA in BTS.

HSUPA allocation In RU20/RU20 on Top release, WSPF card (EUBB) is used for HSPA (HSUPA and HSDPA) in case of HW mix scenario (EUBB subrack and non-EUBB subrack (WSPC/A) - over one LCG). In HW release mix case, only EUBB subrack is considered for HSPA allocation. Non-EUBB subrack (WSPC/A), in case of HW mix scenario, only if frequency layer mapping to non-EUBB subrack is used with Mapping HSPA cell to HW com-missioning parameter. With this parameter the operator can map HSPA frequencies layers to different EUBB and non-EUBB subrack (WSPA/C). Some frequencies can be mapped to non-EUBB subrack (WSPC/A) and other frequencies to EUBB subrack, so that both subrack release types are utilized for HSPA. If some frequency layer is mapped to a given subrack (EUBB or non-EUBB subrack), then it has to provide HSPA resources for cells from the assigned frequency layer (SRB resources can be placed similar as DCH at a different subrack type if the selected subrack (EUBB or non-EUBB subrack) is fully occupied.

Note that in case of frequency layer mapping, the selected HW has to provide CCCH resources for cells from the assigned frequency layer.

The second way of using non-EUBB subracks (WSPC/A) for HSPA traffic in HW release mix scenario is Local cell grouping. In this case, one LCG should cover UltraSite sub-rack(s) and the second LCG EUBB subrack.

Note that HSUPA scheduler cannot be allocated at WSPA card.

HSUPA allocation details for EUBB subrack (WSPF)In case of HSUPA resource allocation, the following priorities are considered during WSPF card selection (if more than one WSPF card is available in EUBB subrack):

a) WSPF card with CCCHb) WSPF card with HSDPA

DN70118376Issue 04E

201


Id:0900d805806f8af1

c) WSPF card

HSUPA allocation details for non-EUBB subrack (WSPC/A)In RU20/RU20 On Top release, “soft prereservation” is used during BTS startup for HW Rel1 (if HW Rel1 is used for HSPA allocation). The main order of soft prereservation is to assure the optimal baseband resources allocation for HSUPA. Soft prereservations force TCOM to allocate CCCH and HSDPA baseband resources assuming that HSUPA resources (up to max. HSUPA scheduler capacity) are prereserved. If the available BB resources are not enough to allocate required CCCH, HSDPA and HSUPA baseband resources, soft prereservation is not considered.

Note that because of soft prereservation - soft prereserved resources (WSPC) are con-sidered during CCCH and HSDPA allocation procedure as occupied, until there is enough space for CCCH and HSDPA resources.

From available WAMs, the WAMs with virtual channel connection (VCC) most prefera-ble for HSUPA, are selected based on a VCC type. Priority order for VCC types is:

1. “HSUPA VCC”2. “HSPA VCC”3. “Any VCC”

Among selected WAMs, TCOM selects a WAM with the maximum number of HSUPA resource steps. Note that only WSPC card can be allocated for HSUPA.

202 DN70118376Issue 04E


Id:0900d80580648809

Dimensioning transport network

5 Dimensioning transport networkPurposeThe most critical task in dimensioning a transport network is to find a transmission solution for the connection between the transmission network and the base station site. The network rollout can depend on how fast this connection can be built. Leasing a Time Division Multiplexing (TDM) or Asynchronous Transfer Mode (ATM) line can be very expensive and time-consuming. Microwave radio links can be more efficient if you build your own network and copper or fibre-based options are not available. The radio links can be either point-to-point or point-to-multipoint solutions.

Before you startNote that the introduction of HSDPA means initially a moderate capacity increase on each HSDPA-enabled base station. Iub efficiency features such as BTS AAL2 Multiplex-ing help operators to more efficiently implement HSDPA if more than one active WAM is utilised. If an own microwave radio network is chosen, environmental factors such as line of sight, restrictions in building permissions or access to microwave radio frequency licences may have an impact.

For more information on BTS AAL2 Multiplexing, see RAS05.1 Transmission and Trans-port Features.

Check:

• the number of subscribers • the number of services per subscriber.

Summary

Figure 81 Dimensioning transport network

Services persubscriber

Requiredtransmissioncapacity/RNC

Requiredtransmissioncapacity/core NW

Transmission network planning(capacity, media, topology, protection...)

QoS requirementsfor the traffic

Radio networkplanning

Number ofsubscribers

DN70118376Issue 04E

203

Dimensioning WCDMA RAN Dimensioning transport network

Id:0900d80580648809

Steps

1 Calculate the required transport network capacity.Calculate the required transmission capacity for the Base Transceiver Station (BTS) and Radio Network Controller (RNC).

The needed transport network capacity depends on the radio network configuration, which again is based on the estimated number of the subscribers and services that the subscribers use.

2 Select transport network media.Depending on the environment and network configuration, you can choose from cables, radios, and leased lines. Check the granularities and capacities offered in radio links, fibre, and leased lines.

3 Plan transport network topology.Topology options are:

• point-to-point • chain • loop • tree • mesh

4 Plan transport network protection.Transport network protection can be achieved by:

• securing the connections, so that information is transferred via two different routes (requires loop or mesh topology)

• equipment redundancy, which means that if the equipment fails, the broken equip-ment is switched off and a new equipment is taken into use.

Expected outcome

• transmission topology • capacity of the transmission connections between the nodes in the transmission

network

Further informationYou can purchase Nokia Siemens Networks planning services for dimensioning the transport network.

See also section Planning capacity in WCDMA RAN in Planning WCDMA RAN.

204 DN70118376Issue 04E


Id:0900d80580785f28

Dimensioning interfaces

6 Dimensioning interfaces

6.1 Overview of dimensioning interfacesRU10 introduced several transport related features that might affect interface dimen-sioning. Table RU10 Transport dimensioning relevant features lists all relevant features.

Table RU20 Transport dimensioning relevant features lists RU20 features which are identified to impact interface dimensioning process:

* RU20 On Top release feature

In the following sections proposed dimensioning methods are described, split into Iub, Iur and Iu part. All the general subchapters are mainly focused on ATM transport. For IP/Ethernet separate interface specific content is given, highlighting required changes in the methodology.

Feature Name

RAN1004 Streaming QoS for HSPA

RAN1253 Iub transport QoS

RAN1192 UBR+ for Control Plane and Iu/Iur User Plane

RAN75 IP based Iu-CS

RAN750 IP based Iu-PS

RAN76 IP based Iur

RAN74 IP based Iub for Flexi WCDMA BTS

RAN1449 Dual Iub for Flexi WCDMA BTS

RAN1254 Timing over Packet for BTS Application SW

Table 76 RU10 Transport dimensioning relevant features

Feature Name

RAN1201 Fractional DPCH (by means of SRB over HSPA)

RAN1202 24 kbps Paging Channel

RAN1231 HSPA over Iur*

RAN1578 HSPA Transport Fallback

RAN1633 Dual Iub for Ultrasite WCDMA BTS

RAN1638 Flexible RLC (DL)

RAN1689 CS voice over HSPA*

RAN1708 BTS Synchronous Ethernet

RAN1749 BTS Firewall

RAN1470 HSUPA 2 ms TTI

RAN1643 HSDPA 64QAM

RAN981 HSUPA 5.8 Mbps

Table 77 RU20 Transport dimensioning relevant features

DN70118376Issue 04E

205


Id:0900d80580736fc8

6.2 Dimensioning Iub interfaceThe following sections deal with Iub dimensioning related topics.

6.2.1 Iub VCC configurationThe Iub bandwidth is divided between:

• signaling links carried on AAL5 (Common Node B Application Protocol (CNBAP), Dedicated Node B Application Protocol (DNBAP), Asynchronous Transfer Mode (ATM) Adaptation Layer 2 Signaling (AAL2Sig)

• Operation and Maintenance (O&M) on AAL5 • User plane (U-plane) Virtual Channel Connections (VCCs) carried on AAL2

User plane VCCs are further classified into different types, depending on the traffic they include. RAS05.1 provides “route selection” function which allows assigning HSDPA AAL2 connections to separate AAL2 VCs. With RAS06 “path selection” and HSUPA features further distinction of user VCCs is enabled. The possible user plane VCC types are: Shared, RT DCH, NRT DCH, DCH, HSDPA, HSUPA, HSPA.

User plane VCCs also transport Common Control Channels (CCCHs), Dedicated Control Channels (DCCHs), and Dedicated Traffic Channels (DTCHs). Therefore, the capacity for Iub is as follows:

Iub capacity = U-plane + CNBAP + DNBAP + AAL2sig + O&M

For O&M, 150 cps (~64 kbps) is recommended per BTS.

In addition to the user plane VCC distinction RAS06 path selection feature introduces finer distinction of VCCs on the basis of AAL2 path types. Three AAL2 Path types: strin-gent, stringent bi-level and tolerant can be configured according to the traffic class carried over user plane VCC. To ensure reliable QoS it is recommended to use stringent AAL2 path with CBR service category for RT DCH, DCH or SHARED VCC, stringent bi-level AAL2 path with UBR+ for NRT DCH and tolerant AAL2 path with UBR+ service category for HSPA.

THP can be used for interactive NRT traffic to distinguish delay-sensitive or non-sensi-tive traffic. Sensitive NRT traffic is then assigned to "stringent" AAL2 path type (and might use paths intended for RT traffic), whereas non-delay sensitive NRT traffic is assigned to “stringent bi-level” AAL2 paths. THP is not relevant in case of shared VCC and is not considered for Iub scheduling.

The maximum number of the AAL2 connections per VCC is 248. The CCCHs of one cell require four to six AAL2 connections, depending on the Secondary Common Control Physical Channel (S-CCPCH) usage. Each Adaptive Multirate (AMR)/packet-switched (PS)/circuit-switched (CS) call requires two AAL2 connections (DTCH + DCCH). For both HSDPA/PS R99 UL and HSDPA/HSUPA calls three AAL2 connections are needed (DCCH+HSDPA+HSUPA/PS R99 UL).

The maximum size of AAL2 Path (AAL2UP VCC) in RAS06 RNC is 114600 cps, which equals 48.6 Mbps.

The following Iub VCC configurations using two, three or four VCCs are available according to RAN759 Path Selection:

1. Shared VCC for RTDCH, NRTDCH and HSDPA traffic. If the HSUPA is enabled it requires other dedicated VCC: 1 or 2 VCCs.

206 DN70118376Issue 04E


Id:0900d80580736fc8

2. Dedicated VCCs for DCH (for both RTDCH and NRTDCH), for HSDPA and for HSUPA: 3 VCCs

3. Dedicated VCCs for DCH (carrying both RTDCH and NRTDCH traffic) and for HSPA (for both HSDPA and HSUPA traffic): 2 VCCs

4. Dedicated VCCs for RTDCH and for NRTDCH, common VCC for HSPA (for both HSDPA and HSUPA): 3VCCs

5. Dedicated VCCs for RTDCH and for NRTDCH, other dedicated VCCs for HSDPA and for HSUPA: 4 VCCs

One or more VCCs of each type can be configured on a route between BTS and RNC. VCC for real-time and non real-time user traffic has to be always configured on a route (either RT and NRT DCH VCCs or DCH VCC) whereas the user plane VCCs for HSDPA and HSUPA traffic are necessary only if required.

The Iub configuration principles for route selection configuration are shown in Figure BTS AAL2 multiplexing (VCC configurations 1-2). In this case DCH and HSDPA traffic has dedicated VCCs to carry user traffic. As an alternative solution it is also possible that the HSDPA and Dedicated Channel (DCH) traffic share the same VCC. For configura-tions when HSUPA traffic is enabled it is recommended to use a dedicated VCC. If Iub interface is not bandwidth restricted in both downlink and uplink (for example, when using symmetric VDSL line) the HSDPA and HSUPA can also share the same VCC, but that requires the Path Selection feature (VCC configurations 3-5).

Note that from RAS05.1 onwards, the AXC ATM layer configuration management for BTS function makes the BTS internal VCC configuration between the Wideband Appli-cation Manager (WAM) and the ATM Cross-Connect Unit (AXU) automatic. Therefore, you do not see WAM-AXU commissioning at all. Only Iub VCCs need to be commis-sioned.

DN70118376Issue 04E

207


Id:0900d80580736fc8

Figure 82 BTS AAL2 multiplexing

WAM2

WAM1

AXC(AXUA,AXUC,AXUD)

RNC

VC1-UPLANE (DCH)

VC2-AAL2 SIG

VC3-DNBAP

VC4-CNBAP

VC5-O&M

VC6-UPLANE (DCH)

VC7-AAL2 SIG

VC8-DNBAP

1 WSPC:64 CE

lub

WAM2

WAM1

RNC

lub

VC1-UPLANE (DCH)

VC2-AAL2 SIG

VC3-DNBAP

VC4-CNBAP

VC5-O&M

VC6-DNBAP

BTS with basic AAL2 multiplexing

1 WSPC:64 CE

1 WSPC:64 CE

1 WSPC:64 CE

1 WSPC:64 CE

1 WSPC:64 CE

AXC(AXUB,AXCC,AXCD)

BTSAAL2Multi-

plexing

BTS with BTS AAL2 multiplexing

VC7-UPLANE (HSDPA)

VC9-UPLANE (HSDPA)

BTS internalVCCs configuredautomatically by

the RNS Splitfeature

208 DN70118376Issue 04E


Id:0900d80580736fc8

* One VCC can contain up to 248 AAL2 connections. In cases where the BTS capacity exceeds 248 AAL2 connections, more user plane VCCs per WAM or per BTS can be required.

** Used with the RAS05.1 Route Selection function. Alternatively, multiple VCCs can be configured for HSDPA.

With the path selection feature, using native ATM transport or hybrid transport over PWE the basic principles for separating the control plane and user plane connections are similar to those given earlier in this chapter. The Iub configuration examples are given in Figure Iub VCC configuration with path selection and native ATM transport and Figure Iub VCC configuration with path selection and hybrid transport. The use of UBR+ service class for non delay-sensitive user plane VCCs is also illustrated in the figure. For both HSPA and NRT DCH traffic UBR+ service category is recommended and CBR ATM service for RT DCH traffic class.

The given below configurations are for UltraSite WCDMA BTS with AAL2 multiplexing. If Flexi WCDMA BTS is used instead, the same VCC configuration is used between RNC and BTS, with the exception that one DNBAP VCC per BTS is enough.

VCC BTS with basic AAL2 multiplex-ing

BTS with BTS AAL2 multiplexing

Flexi WCDMA BTS

ATM adaptation layer

U-plane One per WAM (DCH) *

One per BTS (HSDPA) **

One per BTS (DCH) *

One per BTS (HSDPA)

One per BTS (DCH) *

One per BTS (HSDPA)

AAL2

CNBAP One per BTS One per BTS One per BTS AAL5

DNBAP One per WAM One per WAM One per BTS AAL5

AAL2sig One per WAM One per BTS One per BTS AAL5

O&M One per BTS One per BTS One per BTS AAL5

Table 78 Number of VCCs with route selection configuration

DN70118376Issue 04E

209


Id:0900d80580736fc8

Figure 83 Iub VCC configuration with path selection and native ATM transport

Figure 84 Iub VCC configuration with path selection and hybrid transport

RNC

BTSAAL2Multi-

plexing

VC-1-UPLANE (RT-DCH)

VC-5-AAL2 SIG

VC-6-DNBAP

VC-7-DNBAP

VC-9-CNBAP

VC-10-O&M

VC-2-UPLANE (NRT-DCH)

VC-3-UPLANE (HSDPA)

VC-4-UPLANE (HSUPA)

CBRVCCs

UBR +VCCs

WAM1

WAM2

1 WSPC:64 CE

1 WSPC:64 CE

1 WSPC:64 CE

BTS internalVCCs configuredautomatically by

the RNS splitfeature

Iub

1 WSPC:64 CE

1 WSPC:64 CE

RNC

BTSAAL2Multi-

plexing

VC-3-UPLANE (HSDPA)

VC-4-UPLANE (HSUPA)

VC-2-UPLANE (NRT-DCH)

VC-1-UPLANE (RT-DCH)

VC-5-AAL2 SIG

VC-6-DNBAP

VC-7-DNBAP

VC-9-CNBAP

VC-10-O&M

CBRVCCs

UBR +VCCsWAM1

WAM2

BTS internalVCCs

configuredautomatically

by the AutomatedRNS Split feature

Iub

1 WSPC:64 CE

Control planeand R99 userplane throughATM transport

HSPA trafficthroughEthernetbackhaul

PWEgateway

Eth

210 DN70118376Issue 04E


Id:0900d80580736fc8

* With basic AAL2 multiplexing one of the VCCs per WAM must be capable of carrying RT traffic.

The RAN759 Path Selection feature, originally introduced in RAS06, was developed further in RU10 release. In RU10, the AAL2UPUsage (AAL2 User Plane VCC Usage) and AAL2 Path type combination are used to define the type of the traffic carried on the given AAL2 VCC (AAL2 Path). The AAL2UPUsage specifies the air interface channel type (DCH/HSxPA) carried over the AAL2 VCC while the AAL2 Path Type defines the transport priority.

VCC BTS with basic AAL2 multiplexing BTS with AAL2 multiplexing

Flexi WCDMA BTS ATM adapta-tion layer

U-plane

RT-DCH, NRT-DCH and HSDPA VCC

Not possible to divide DCH traffic to RT-DCH and NRT- DCH VCCs

1 - 7 per BTS 1 - 16 per BTS AAL2

U-plane HSUPA One per BTS One per BTS At least one per BTS AAL2

U-plane DCH 1-2 per WAM *

U-plane DCH+HSPA 1-2 per WAM

Examples of two-WAM configurations:

WAM1: DCH VCC

WAM2: DCH VCC + HSPA VCC

WAM1: DCH VCC + HSDPA VCC

WAM2: DCH VCC+ HSUPA VCC

CNBAP One per BTS One per BTS One per BTS AAL5

DNBAP One per WAM One per WAM One per BTS AAL5

AAL2sig One per WAM One per BTS One per BTS AAL5

O&M One per BTS One per BTS One per BTS AAL5

Table 79 Number of VCC with path selection configuration and HSUPA

AAL2UPUsage (RU10/RN4.0)

AAL2PT combinations No opt. feature

Route selection*

Path selection RAS06 SW

Path selection RU10 SW

DCH & HSDPA (former Shared)

None x

DCH None x

DCH & HSDPA None x

HSDPA None x

DCH Stringent x x

DCH Stringent & Stringent Bi-level x x

DCH Stringent Bi-level x x

DCH & HSPA Stringent x

DCH & HSPA Stringent & Stringent Bi-level x

Table 80 RU10 Traffic separation using different VCC types and AAL2 PT combinations

DN70118376Issue 04E

211


Id:0900d80580736fc8

* Note that RAN1020 Route selection (RAN05.1) is assumed not to be in use anymore in RU20.

** HSUPA with any AAL2 PT combination is applicable if HSUPA is enabled.

The AAL2 VCC selection mechanism for admitted user calls in RU10 takes into account the air interface channel type and the AAL2 path type combinations configured for given AAL2 user plane VCC. For example, if the channel type is set to DCH, then VCC will be taken as a candidate to carry the transport bearers for the common transport channels, R99 DCHs, and SRBs (DCCH on DCH). Also for HSPA UP VCC Stringent & Stringent bi-level & Tolerant all HSPA traffic is routed to the HSPA VCC.

According to new RU10 naming, the RAS06 DCH/RT/NRT traffic VCCs need to be replaced by DCH Stringent & Bi-level Stringent/DCH Stringent/DCH Bi-level Stringent AAL2 UP VCCs accordingly.

Each path type has a different AAL2 admission control (CAC) algorithm in DL and UL. In RAS06 there was only one path type value for a VCC which defined the used AAL2 CAC algorithm. In RU10, configured path type combination might contain several various AAL2 PT values. This means that the used algorithm is call specific and depends on the path type associated to the traffic type.

The following table presents default air channel type and AAL2 path types needed for a transport bearers.

DCH & HSPA Stringent Bi-level x

DCH & HSDPA Stringent & Stringent Bi-level & Tolerant

x x

HSPA Stringent x

HSPA Stringent & Stringent Bi-level x

HSPA Stringent Bi-level x

HSPA Stringent Bi-level & Tolerant x

HSPA Stringent & Stringent Bi-level & Tolerant

x

HSPA Tolerant x x

HSDPA Stringent & Stringent bi-level x x

HSDPA Stringent & Stringent bi-level & Tolerant

x x

HSDPA Tolerant x x

HSUPA** Stringent & Stringent bi-level x x

HSUPA** Stringent & Stringent bi-level & Tolerant

x x

HSUPA** Tolerant x x

AAL2UPUsage (RU10/RN4.0)

AAL2PT combinations No opt. feature

Route selection*

Path selection RAS06 SW

Path selection RU10 SW

Table 80 RU10 Traffic separation using different VCC types and AAL2 PT combinations (Cont.)

212 DN70118376Issue 04E


Id:0900d80580736fc8

Introduced in RU10, RAN1253 Iub Transport QoS feature allows aligning QoS transport strategy with radio layer classification based on UMTS traffic classes, THP and ARP pri-orities. Thus, transport bearers of various connection types are freely mapped to AAL2 priorities (AAL2 path type and AAL2 priority queue) at ATM transport. Same AAL2 priority mappings are used in uplink (FlexiBTS) and downlink (new NPS1 HW) direction. The default AAL2 Path Types should be applied for the VCC selection if RAN1253 Iub Transport QoS feature is not configured for the given BTS in the RNC configuration.

6.2.2 Iub VCC configuration dimensioningIf CBR VCC is used for user plane traffic, the VCC size (peak cell rate PCR) is selected based on the calls mix to be supported. The calculations can be made with RAN Capacity Planner. The dimensioning of HSDPA/HSUPA VCC is based on the data rates to be supported, see HSPA and Iub dimensioning.

VCC dimensioning is different in the case of UBR+ VCC. The following rules apply for UBR+ VCCs:

• The CAC is done against the UBR+ VCC MDCR value. The VCC bundle is an exception, discussed later.

• The traffic is scheduled in the RNC to the VCC with UBR+ PCR value at maximum. RNC shapes the user plane VCCs according to PCR value, except for RNC2600 platform where shaping is done with VCC bundle only. Also with the new NPS1 HW (RNC2600), when VCC bundle is in use, CBR VP must be set unshaped. In the BTS there is no traffic shaping to UBR+ PCR, except UltraSite BTS for user plane VCCs with AAL2 multiplexing disabled and for the control and O&M VCCs.

• The MDCR value is the amount of capacity reserved for a specific connection by ATM CAC.

Connection type Channel type in VCC selection

AAL2 path type in VCC Selection

CTrCH (PCH, FACH, RACH) DCH Stringent

SRB (DCCH on DCH) DCH Stringent

SRB on HSPA HSDPA/HSUPA/HSPA Stringent

R99 DCH AMR DCH Stringent

R99 DCH CS data DCH Stringent

Streaming DCH PS data DCH Stringent

NRT DCH PS data (Interactive, Background) DCH Stringent bi-level

NRT HSDPA (Interactive, Background) HSDPA / HSPA Tolerant

NRT HSUPA (Interactive, Background) HSUPA / HSPA Tolerant

Conversational HSDPA HSDPA / HSPA Stringent

Streaming HSDPA HSDPA / HSPA Stringent bi-level

Conversational HSUPA HSUPA / HSPA Stringent

Streaming HSUPA HSUPA / HSPA Stringent bi-level

Table 81 VCC labels for VCC selection

DN70118376Issue 04E

213


Id:0900d80580736fc8

• The bandwidth sharing between UBR+ connections using the same ATM link can be tuned with the weight and MDCR values.

Downlink VCC bundleThe VCC bundle functionality in downlink is provided as a part of features RAN1100: Dynamic Scheduling for NRT DCH with Path Selection and RAN1099: Dynamic Sched-uling for HSDPA with Path Selection. VCC bundling is allowed if either one of above or both features are enabled. The VCC bundle allocates downlink capacity dynamically between different VCC connections sharing the same Iub link and belonging to the VCC bundle. The VCC bundle PCR should be configured to be equal to the minimum link size of the route from the RNC to the BTS to avoid traffic loss between RNC and BTS. Maximum two VCC bundles can be configured. The main use of the second bundle is the hybrid BTS backhaul feature.

In case of VCC bundle, the UBR+ VCC CAC in RNC (downlink) is done against the dynamically adjusted value, based on the other traffic volume sharing the same VCC bundle. Note that RNC shapes UBR+ VCs according to the PCR value or to lower value if in VC bundle. Thus if UBR+ VCC PCR is equal to bundle PCR the VCC can use all the capacity if there is no other traffic. In congestion situation the maximum available band-width for UBR+ VCCs is the MDCR value or share of the excess bandwidth defined by EBS parameter. In addition, all CBR VCs in VC bundle are shaped according to their PCR values. For details, see the feature description for RAN1100: Dynamic Scheduling for NRT DCH with Path Selection.

For the exemplary scenario where both NRT DCH and HSDPA VCCs are included in the same VCC bundle the following ATM traffic parameters of the VCC bundle can be configured:

• VCC bundle PCR=5.0 Mbps • RT DCH: VCC PCR (CBR) = 2 Mbps • NRT DCH: VCC MDCR (UBR+) =1 Mbps, and VCC PCR (UBR+) =5 Mbps • HSDPA: VCC MDCR (UBR+) =2 Mbps, and VCC PCR (UBR+) =5 Mbps • VCCBundleEBS = 50%; The share given in this parameter is for NRT DCH VCCs

and the rest for NRT HSDPA VCCs in a bundle 100%-NRT DCH_value)

In this case there is no unallocated bandwidth in the bundle, the remaining free capacity in the bundle, at the given time stamp, is shared among NRT DCH and HSDPA traffic according to the EBS parameter. Simultaneously, the MDCR parameter assures the minimum bandwidth for UBR+ VCCs.

Uplink VCC bundleThere is a capacity bundling functionality available also for uplink ATM resources. The usage of the uplink VCC bundle requires that the feature RAN1095: UBR+ for Iub User Plane is activated in the BTS. In case the VCC bundle is active, the BTS handles the available uplink capacity for NRT DCH and RT DCH VCC as a bundle in AAL2 CAC operations. If there are some MDCR reservations for any of the UBR+ VCCs, those are subtracted from the total available link capacity. This means that MDCR parameter can be used to reserve some capacity for HSUPA traffic in uplink. Therefore, the MDCR of UBR+ VCC for NRT DCH traffic should be set to 0 to not reserve additional capacity, and the UBR share parameter to a much greater value than for HSPA/HSUPA VCCs (for example, 1000:50).

Uplink AAL2 CAC overbooking is possible with RAN1096: Transport Bearer Tuning, similarly as in downlink, but too heavy overbooking might lead to traffic loss, because

214 DN70118376Issue 04E


Id:0900d80580736fc8

there is no flow control mechanism in uplink to limit the throughput in congestion situa-tion.

* In case of VCC with AAL2 PT combinations (for example, Stringent & Stringent Bi-level, Stringent Bi-level & Tolerant or Stringent & Stringent Bi-level & Tolerant) the required bandwidth has to be calculated separately according to the rules given in ATM-based Iub dimensioning and the total VCC bandwidth is the sum of calculated traffic.

** The MDCR value is used to reserve certain capacity from ATM layer CAC, similarly as CBR VCC PCR. The MDCR values for HSPA VCCs should be selected based on the estimated average throughput during busy hour plus some safety margin to allow bursts. The HSDPA uplink traffic volume is expected to be low if compared to downlink, because there are only the HS-DSCH capacity allocations transported. The same applies for HSUPA and downlink traffic.

If the MDCR value is set too low, the ATM layer congestion may take place in hub sec-tions, where several BTSs share the same link and use shared resources. The exact

Parameter (ATM EP, AAL2 PT) RNC egress / ingress BTS egress / ingress

CBR VCC PCR for DCH/HSPA* VCC (stringent)

Calculate according to rules given in ATM-based Iub dimensioning based on the call mix to be supported.

Calculate according to rules given in ATM-based Iub dimensioning based on the call mix to be supported.

UBR/UBR+ PCR for DCH/HSPA* VCC (stringent bi-level)

Equal to VCC bundle PCR *** Equal to maximum capacity for user traffic according to uplink bottleneck.

UBR+ MDCR for DCH/HSPA* VCC (stringent bi-level)

Capacity that is guaranteed for stringent bi-level DCH/HSPA traffic in downlink. ** Calculate according to rules given in ATM-based Iub dimensioning

0, if uplink VCC bundle is active. If no VCC bundle is used, calculate the value according to rules given in ATM-based Iub dimensioning.

UBR/UBR+ PCR for HSPA/HSDPA/HSUPA* (tolerant) VCC

Equal to VCC bundle PCR *** Equal to maximum capacity for user according to uplink bottleneck.

UBR+ MDCR for HSPA/HSDPA/HSUPA* (tolerant) VCC

Capacity guaranteed for HSPA traffic in downlink. ** Calculate according to rules given in ATM-based Iub dimensioning

Capacity that is guaranteed for HSUPA traffic in uplink. ** Calculate according to the rules given in ATM-based Iub dimensioning

UBR+ UBRShare for NRT DCH and NRT HSDPA VCCs

Weight that is used to share the band-width between UBR+ connections.

Set higher for NRT DCH VCC to give priority over HSPA.

Set higher for NRT DCH VCC to give priority over NRT HSPA.

VCC bundle PCR The total available Iub user plane capacity in downlink (assuming all user plane VCCs are located in the same bundle).

For two VCC bundles calculate capacity separately according to the traffic types assigned to the different VCC bundles,

Automatically defined by the BTS if VCC bundle is enabled in uplink.

VCCBundleEBS

(Excess Bandwidth Share)

With this parameter the NRT DCH can be favored over NRT HSDPA (located in the same VCC bundle) in a congestion situation, or vice versa.

RT traffic type gets always guaranteed bandwidth.

Not available

Table 82 Parameter value selection with path selection and HSUPA

DN70118376Issue 04E

215


Id:0900d80580736fc8

numbers depend on the number of BTSs sharing the common link, burstiness of the traffic among other things, and should be verified through network monitoring.

*** Peak capacity can be used only if there is no other traffic present in the same VCC bundle, that is, the HSDPA traffic uses peak rate if no RT or NRT traffic is present. If there is other traffic, the VCC bundle functionality adjusts dynamically the peak rates allowed in downlink for different traffic types.

6.2.3 Iub VPC configurationThe VP layer configuration can be based on one VP for user and control plane and one VP for O&M between the RNC and the BTS as illustrated in Figure VPC configuration with CBR VCC based user and control plane.

Figure 85 VPC configuration with CBR VCC based user and control plane

From RAS05.1 onwards it is also possible to have two VPCs for user plane per BTS. In that case the R99 traffic is transported over one VPC and HSDPA traffic over another VPC (Route Selection feature).

In RAS06, the introduction of UBR+ VCC for user plane requires some changes in the configuration. It is possible to have different priority traffic dedicated VPCs between the RNC and the BTS or alternatively to group, for example, all HSDPA VCCs to the same VPC and separate those in the hub point to different BTS sites. These alternatives are described in Figure VPC layer configuration option for RU10 path selection configuration with CBR/UBR+ VCC based user plane (UBR O&M), where the hub switch is used also to change the service category of VP connections. In addition the route/path selection does not have any restriction how different VCCs are configured to VPCs.

In RU10, it is possible to configure UBR+ VPCs. UBR+ VCCs can be configured in both UBR VPs and CBR VPs. In the case where any VP contains both CBR VCCs and UBR+ VCCs, it must be set up to CBR VP, that is, CBR VCC are not allowed within UBR VPs. There is no UBR+ shaping applied for any BTS and RNC hardware variants.

BTS

RNCBTS

VP-1-UPLANE and CPLANE (CBR)

VP-2-O&M (UBR)

VP-1-UPLANE and CPLANE (CBR)

VP-2-O&M (UBR)3rd

pa

rty

AT

Msw

itch

3rd

pa

rty

AT

Msw

itch

RNC

216 DN70118376Issue 04E


Id:0900d80580736fc8

Figure 86 VPC layer configuration option for RU10 path selection configuration with CBR/UBR+ VCC based user plane (UBR O&M)

The guidelines for defining the parameter values for VP layer are given in Table Param-eter value selection for VP layer.

6.2.4 ATM-based Iub dimensioning

6.2.4.1 User traffic demand modelingFor detailed information regarding traffic modeling see Traffic modeling. The basic traffic model related parameter set used in interface dimensioning process is given below. It is focused on subscriber oriented values, basing on which all the input data to the dimen-sioning process is evaluated.

Parameter Downlink Uplink

CBR VPC PCR Sum of the VCC PCR values included in the VPC

Sum of the VCC PCR values included in the VPC

UBR+ VPC MDCR Sum of the VCC MDCR values included in the VPC

Sum of the VCC MDCR values included in the VPC

UBR+ VPC PCR Equal to ATM link capacity Equal to ATM link capacity

Table 83 Parameter value selection for VP layer

3rd partyATM

switch

UBR (DCN)

UBR + (HSPA)

UBR (DCN)

UBR (DCN)

RNC

3rd partyATM

switch

CBR VP

CBR VPCBR (rt)

CBR (rt)

UBR + (HSPA)

UBR + (HSPA)

UBR + (nrt)

UBR + (nrt)

UBR VP

CBR VP

CBR VP

CBR VP

rt-VBR VP

nrt-VBR VP

CBR VP

CBR (rt)

UBR (DCN)

UBR + (HSPA)

UBR + (nrt)

CBR (rt)

UBR + (nrt)

BTS

BTS

UBR VP

DN70118376Issue 04E

217


Id:0900d80580736fc8

Figure 87 Traffic parameter modeling

Parameter / [unit] Description / Formula

PeakRate Max. data rate of the DTCH bearer (RAB)

BHCA

[#]

Busy Hour Call Attempts is defined as Busy Hour DCH Attempts;

DCH can be DTCH (R99); HS-DSCH or E-DCH

DCHduration

[s]Sum of all DCH durations of a RAB live = ∑ all DCHdu-rations of RABlive

DCHactivity

[abs] or [%]

Average activity over all DCH sessions of a RAB live

= Avarage of MeanRateDCHsession’s / PeakRate

or

= MeanRateBH / ( PeakRate * DCHduration * BHCA / 3600s)

or

= MeanRateBH / (PeakRate * ErlangDCHsession’s)

ErlangDCHsession’s

[#]

Basic traffic demands for CS traffic; in case of PS and HS traffic it can be calculate as follows:

= DCHduration * BHCA / 3600s

or

= MeanRateBH / (PeakRate * DCHactivity)

MeanRateBH

[bps]

Basic traffic demands for PS and HS traffic; in case of CS traffic it can be calculate as follows:

= DCHactivity * PeakRate * DCHduration * BHCA / 3600s

or

= DCHactivity * PeakRate * ErlangDCHsession’s

Table 84 Basic traffic model parameter set for Access dimensioning

Data rate

DCHsessionDuration

RABliveDuration

Inactivity beforeChannel type switching

FACH/PCH session-> DCH in-activity periods

MeanRateDCHsessions

Average ofMeanRateDCHsessions

MeanRateRABlive

MeanRateBH

t

218 DN70118376Issue 04E


Id:0900d80580736fc8

The formulas above are valid for both net and gross traffic demands (calculation of gross traffic requires to include appropriate protocol overheads).

DL and UL calculations of that formula set are coupled by the fact that

• BHCA • DCHduration • ErlangDCHsession’s

must be the same for UL and DL.

MeanRateBH and DCHactivity must be separately calculated for UL and DL.

Amount of traffic demand per busy hour must be provided for a specific BTS site. If amount of traffic demand is given per subscriber, additional assumption for the number of subscribers per site is required.

Additionally, assumption on the soft handover overhead is needed. The default value for inter-BTS soft handover factor is 30%.

Softer handover does not influence Iub U-plane and is not relevant for RNC static capac-ity. From interface point of view, it loads only Iu and Iur C-plane.

6.2.4.2 Dedicated Control Channels (DCCH)

SRBs over DCHFor signaling, the SRB with 13.6kbps (ALC set 3 with lowest activity factor of 3 options per SRB type) is used during dimensioning of the Iub interface via CAC (see Iub dimen-sioning methods for user plane) and estimation of additional mean user traffic.

DCCH Mean Traffic per DCH session

= Peak Rate * Activity * Overhead = 13.6kbps * 7.5% * 1.791 = 1.82682 kbps

Note that the considered connection rate on Iub is not updated when changed from 13.6kbps towards 3.4kbps, but current rate is used in case of incoming handover.

SRBs over HSPARU20 RAN1201 Fractional DPCH brings in a support for SRBs carried over HSPA, required in relation to the following RU20 features:

• RAN1689 CS voice over HSPA (RU20 On Top) • RAN1201 Fractional DPCH • RAN1638 Flexible RLC • RAN981 HSUPA 5.8 and RAN1470 HSUPA 2ms TTI.

ParallelConnectionsDCH

[#]

Input value for CAC; in case of PS nonRT dimensioning as best effort without QoS it can be calculate as follows:

= round-up [ ErlangDCHsession’s ]

or

= round-up [ DCHduration * BHCA / 3600s ]

or

= round-up [ meanRateBH / (DCHactivity * PeakRate) ]

Parameter / [unit] Description / Formula

Table 84 Basic traffic model parameter set for Access dimensioning (Cont.)

DN70118376Issue 04E

219


Id:0900d80580736fc8

Because of a different overhead introduced by SRBs over HSPA bearers, a separate set of ALC and IPTD CAC parameters is defined. Therefore, the CAC algorithm is fed with a modified input comparing to DCH mapped SRBs.

E-DCH/HS-DSCH SRB connection requires 2 CIDs / UDP ports instead of one consumed by DCH mapped control channels.

6.2.4.3 Common control channels (CCCH)The following assumptions are taken during dimensioning of the Iub interface via Call Admission Control algorithm. Because of the fact that CCCH set is established for each radio cell, depending on the number of cells different number of common channels (RACH, FACHs and PCH) is used as an input to the CAC functionality. The same assumption on Activity is used to estimate the CCCH part of mean user traffic.

Optional RU20 feature RAN1202 24 kbps Paging Channel brings in a possibility to enhance the paging channel throughput to 24 kbps, reducing congestion probability under BTSs serving high number of subscribers.

6.2.4.4 Connection Admission Control for R99 trafficThe AAL2 Connection Admission Control (CAC) in RNC evaluates whether there is enough bandwidth in downlink direction for every new requested bearer. The AAL2 CAC Iub capacity requirement depends on, for example, the service mix, average and peak service data rate, Transmission Time Interval (TTI), allowed delays, and cell losses.

RAS06 feature Transport Bearer Tuning (RAN1096) affects Iub dimensioning. For instance, instead of 100% activity for PS DCHs, lower activity factors (AF) may be applied. Transport Bearer Tuning enables optimization of resources on Iub or allows more services to be admitted simultaneously compared to previous releases. The feature influences Iub dimensioning in a way that ‘real’ activity of the bearers, estimated on the basis of input Traffic Model are provided to the CAC algorithm.

Further optimization of AF values for different bearer types should be done carefully based on testing or measurement data from the network to avoid congestion and decreased service quality.

RAS06 feature RAN1100: Dynamic Scheduling for NRT DCH with Path Selection provides a back-pressure mechanism to slow down user data rates in a controlled way

Type of CCCH Description Max. Data rate on FP level

Default Activity

FACH-C Forward Access Channel for control plane

DL: 38400 bps 10%

FACH-U Forward Access Channel for user plane

DL: 40800 bps 10%

RACH Random Access Channel in UL

UL: 20800 bps 10%

PCH 8 kbps (<RU20) Paging Channel 8 kbps DL: 27200 bps 10%

PCH 24 kbps (RU20) Paging Channel 24 kbps (optional feature)

DL: 36000 bps 10%

Table 85 Common Control Channel reservation

220 DN70118376Issue 04E


Id:0900d80580736fc8

in the congestion situation. It is recommended to use this optional feature together with Transport Bearer Tuning.

The default values for the AF, when feature Dynamic Scheduling for NRT DCH with Path Selection is enabled, are as follows:

NRT DCH bearers' AF is set to 0.75.

Further optimization is possible by performing AF tuning for each NRT DCH bearer type.

The following limitations apply to AF factor selection of different bearer types:

• For NRT DCH bearers the AF value cannot be set below 0.1. • For AMR calls the AF value cannot be set below 0.6.

Note that the feature Dynamic Scheduling for NRT DCH with Path Selection does not provide optimal throughput if the capacity available for NRT DCH traffic is small (< 1000 cps).

Connection Admission Control and traffic separationIn case of Path Selection feature, AAL2 CAC selection bases on AAL2 Path Type (chosen for each VCC) and with the introduction of RAN1253: Iub Transport QoS feature, different AAL2 CAC algorithms can be used for the same AAL2 path.

6.2.4.5 Iub dimensioning methods for user planeIn Iub dimensioning two main options are distinguished depending on available set of input parameters and considered QoS demands. The CAC algorithm is used for both options as provided in the dimensioning tool RCP.

Option 1

• RT services dimensioned using Multi-Dimensional-Erlang approach (related to CS and PS real-time RABs, includes CS over HSPA and HSPA Streaming services).Multi-Dimensional-Erlang is an extended Erlang B algorithm which allows to calcu-late the probability of call loss on a group of circuits in multi-dimensional environ-ment (more services sharing the same transport resource). For details, refer to teletraffic engineering theory.

• PS NRT dimensioned with QoS leveling by means of M/G/R-PS model.M/G/R-PS is a queuing model used in dimensioning of Internet Traffic residing on top of TCP/IP protocol suite. For details, refer to teletraffic engineering theory. • Dimensioning independent of the bearer’s activity (TBT) • For CAC 100% AFs are accounted

• HSPA NRT traffic is dimensioned separately. • Option seen as preferred - especially helpful in the cases where no detailed infor-

mation on bearer’s activity is available.

Option 2

• Based on direct definition of Parallel Connections without QoS consideration during dimensioning

• Although the lack of explicit QoS targets is a shortcoming it ensures the availability of sufficient resources in an intuitive manner throughout all elements for e2e con-nections.

• HSPA NRT traffic is dimensioned separately. • Recommended for the cases where direct Parallel Connection is preferred as input

DN70118376Issue 04E

221


Id:0900d80580736fc8

The option should be chosen depending on the QoS requirements and availability of the input parameters.

Note that the methods described here should be treated as proposals. Operators can apply their own calculation process if required.

Option 1: MD-Erlang for real time; QoS by M/G/R-PS for best effort PS R99 and HSPA NBR

Figure 88 Iub dimensioning, option 1

Real-time trafficThe following steps are needed in the calculation.

1. Calculate MD-Erlang bandwidth.Multi-Dimensioning-Erlang approach is used for real time services (using CS, PS real-time and HSPA Streaming RABs). The Gross Peak Rate is defined on ATM

Input 1:

RealTime with QoS

CS, PS RT, HSPA GBR- Traffic Model input- QoS via blockingpercentage

Bandwidthdemand

DCCHs

Seperate Dim. with min QoS

Input 2:

NonRealTime w/o QoS

PS NRT, HSPA NBR- Traffic Model input- QoS via delay

percentage- effective Peak

HSPA NRT- Traffic Model input- QoS global for HSDPA HSPA NRT Bandwidth

demand (cps or kbps)

bandwidth/Linkbandwidth

Max over loopresults

Bandwidth demand(cps or kbps)

Resulting numberof physical lines

of Gross mean rates

MGR-PS(Total Mean on single RAB)



"worst case"M/G/R-PS

New function

Loop

CACalgorithm

ParaCon=BW /

effectivePeak

Repeated for each RAB

Common CH

Loop

Weightingover RABmean rate

MD-Erlang

Parallel Connections incl.SHO on service level(whenever applicable)

Weighting and rounding rules

Access Dimensioning Option 1:

RealTime with QoS, R99 NonRealTime with QoS (MGR-PS)

222 DN70118376Issue 04E


Id:0900d80580736fc8

level including AAL2/ATM overhead and accompanying DCCH. Offered Traffic [Erl] should also include SHO factor, as soon as HSDPA is not concerned.Bandwidth MD-Erlang = MD-Erlang [ErlangDCH; GrossPeakRate; Blocking-per-centage]

2. Weighting over mean rates.After the total required rate is determined by MDE, each RT bearer is assigned a certain portion of that total rate weighted according to the mean rate contributed by each bearer. Then, an average number of connections is derived (based on the peak rate used for MDE) for each bearer. Usually the outcome is not an integer, so it has to be rounded up to the next greater integer.ParallelConnectionsDCH = round-up [Gross meanRateBHinclQoS / Gross PeakRate]

3. Check against MDE bandwidth.Afterwards, the number of connections for the bearer with the lowest rate is decreased as long as such a decrease does not result into a total rate below the one determined by MDE before. Bandwidth = ∑ [ParallelConnectionsDCH * PeakRate] =< Bandwidth via MD-ErlangNote that it can happen that all connections of the lowest bearer rate are eliminated (so connection number is 0), then the “new” lowest (non-zero connection count) bearer is used for further iterations. (This rule is needed because of high rounding error for bearers with high peak rate).

Afterwards, the set of parallel connections is used to feed CAC (in combination with the outcome of NRT dimensioning). From CAC result point of view this is the worst case concerning requested Bandwidth.

Non real-time trafficIn NRT dimensioning M/G/R-PS with combination for several bearers as a mix is used (considering a delay factor). In case of multiple bearers, M/G/R-PS provides a total demand for each bearer class. Each of those demands has to be fulfilled, therefore the CAC is fed with several (potential) sets of parallel bearers. Afterwards, the maximum demand is used.

Note that M/G/R-PS assumes a full utilization of bearers whenever data is transferred, thus 100% activity has to be used for CAC.

Way of calculation and formulas:

1. Calculate a sum of mean rate over all NRT services.Total Gross mean rate = ∑ [Gross mean rate(service)]

2. Apply MGR-PS with this sum together with peak rate, file size, delay of each service.Bandwidth MGR-PS (Service) = M/G/R-PS [Total Gross mean rate; Gross peak rate (service); Gross file size (service); delay (service)]

3. Calculate parallel connections for each service.ParallelConnectionsDCH NRT (Service) = round-up [Bandwidth MGR-PS (Service) / Gross peak rate(Service)]

4. Repeat steps 1-3 for all NRT services.

DN70118376Issue 04E

223


Id:0900d80580736fc8

5. Call CAC including Real time part for each NRT services case separately.CAC(service)= CAC[ real-time part; CCCH; ParallelConnectionsDCH NRT (Service) ; CACval-ues(service) ]whereCACvalues(service) = CACvalues(related RAB) = vector [ max size(RAB); max rate(RAB), average size(RAB), average rate(RAB) ]

6. Take the maximum over all CAC result case as a final result (the worst case). Total BW result = max [ CAC (service) ]

TotalCACresultDemand is used to calculate Iub bandwidth demand together with HSPA bandwidth demand, as described in Calculation of total Iub bandwidth demand.

For exemplary Parallel Connections calculation in Option 1, see Dimensioning exam-ples.

Option 2: CAC directly via "parallel connections"

Figure 89 Iub dimensioning, option 2

This option allows to choose CAC input independent of the dimensioning rules.

However, it is recommended to check if the number of Parallel Connections defined in the traffic model is compliant with the Traffic Demand requirements (Erlangs).

ParallelConnectionsDCH >= round-up [ ErlangDCHsessions (at BTS) ]

Meaning: used number of ParallelConnectionsDCH must be greater or equal then up-rounded Erlang value from Traffic model (see User traffic demand modeling) expected at a specific BTS.

CS, PS RT, HSPA GBR- Traffic Model input- QoS via parallelConnections

PS NRT- Traffic Model input- QoS via ParallelConnections

DCCHs

Seperate Dim. with min QoS

HSDPA NRT- Traffic Model input- QoS global for HSDPA HSPA NRT Bandwidth

demand (cps or kbps)

bandwidth/Linkbandwidth

R99 Bandwidthdemand (cps or kbps)

Resulting numberof physical lines

CACalgorithm

Common CH

Parallel Connections incl.SHO on service level(whenever applicable)

Access Dimensioning Option 2:No QoS consideration, direct input of Parallel Connections

Direct ParallelConnectionsdirectly

Bandwidthdemand(cps or kbps)

224 DN70118376Issue 04E


Id:0900d80580736fc8

6.2.4.6 HSPA and Iub dimensioningThe Iub dimensioning for HSDPA and HSUPA differs from Iub dimensioning for R99 DCH traffic, because there are no dedicated capacity reservations per connection over Iub. The dimensioning of the HSDPA/HSUPA is based on the throughput that needs to be provided over the air interface for HSPA users connected to a specific BTS. In the current approach two parallel options are foreseen:

• dimensioning based on the HSPA mean rate with additional consideration of the protocol overhead

• HSPA peak rate demand, which is checked against available Iub bandwidth, as shown in Figure HSDPA protocol stackOptionally, on top of the mean rate based option, some percentage QoS overhead can be added to account for instantaneous I/B HSPA bursts above the average value. Typical QoS_Factor values are around 20%.

HSDPA and protocol overheadsHSDPA protocol stack is presented in Figure HSDPA protocol stack.

Figure 90 HSDPA protocol stack

The following overheads are present below the PDCP level:

• RLC (RU10): SDU size fixed to 320 or 640 bits payload + 16 bits header = 336 or 656 bits

• RLC (RU20: Flexible RLC): flexible SDU size up to 1400 bytes + 16 bits header • MAC-d: No header • MAC-hs (RU10): 24 bits header • MAC-ehs (RU20, Flexible RLC): 21 bits header • FP: 88 bits header, relative FP overhead varies depending on the number and size

of carried RLC PDUs

ATM User Data Rates on Iub generated by different UE Categories are presented in tables HSDPA protocol overheads (RU10, 10% BLER) and HSDPA protocol overheads (RU20, Flexible RLC, 10% BLER). Target BLER of 10% has been assumed.

Application

PDCP

RLC

MAC-d

MAC-hs/ MAC-ehs

PHY

UEUu

DL

BTSIub

RNCIuPS

Application

PHY

TransportPHY

PDCP

RLC

MAC-d

Frame Protocol

PHY

Transport

Frame Protocol

MAC-hs/ MAC-ehs

DN70118376Issue 04E

225


Id:0900d80580736fc8

Note that to calculate total Iub capacity required to serve the HSDPA Data Rates listed in the tables, additional assumptions on Iub signaling, Control Channels and O&M band-width demands are needed.

Average RLC – ATM overhead for HSDPA User Plane varies in a range of 25 – 35 % in RU10 case and 20 – 30% in RU20 (Flexible RLC) case, depending on the actual rate utilized by the application layer.

HSUPA and protocol overheadsHSUPA protocol stack is presented in Figure HSUPA protocol stack.

Air interface L1 rate [Mbps]

RLC SDU peak rate [Mbps]

FP rate (Iub) [Mbps]

ATM User Data Rate (Iub) [Mbps]

1.8 1.46 1.54 1.86

3.6 3.06 3.24 3.90

7.2 6.11 6.47 7.78

10.1 8.73 9.24 11.11

14.0 12.22 12.63 15.20

Table 86 HSDPA protocol overheads (RU10, 10% BLER)

Air interface L1 rate [Mbps]

RLC SDU peak rate [Mbps]

FP rate (Iub) [Mbps]

ATM User Data Rate (Iub) [Mbps]

7.2 6.52 6.59 7.93

10.1 9.17 9.26 11.14

14.4 12.66 12.78 15.38

21.1 (64QAM) 19.11 19.29 23.21

28.0 (MIMO 16QAM) 25.31 25.56 30.74

42.2 (DC-HSDPA/64QAM)

38.22 38.58 46.41

Table 87 HSDPA protocol overheads (RU20, Flexible RLC, 10% BLER)

226 DN70118376Issue 04E


Id:0900d80580736fc8

Figure 91 HSUPA protocol stack

The following overheads are present below the PDCP layer:

• RLC: PDU size 320 bits payload + 16 bits header = 336 bits, overhead is 16/320 = 5%

• Dedicated Medium Access Control (MAC-d): No header • MAC-es payload 5040 bit (assuming 15 MAC-d PDUs) + 6 bits header = 5046,

overhead is 6/5040 = 0.1% • Frame protocol: HS-DSCH data frame’s FP-header and tail produces nine bytes

overhead for each MAC-es data unit. With the assumption 15 MAC-d PDUs per HS-DSCH frame the FP layer overhead is 1.4%.

The total Iub overhead requirements for HSUPA are 6% overhead from RLC rate to FP rate, or 33-27% overhead from RLC rate to ATM rate. The variation of the overhead per-centage depends on the number of MAC-d PDUs included in single FP frame.

n case of HSUPA, additional 30% overhead needs to be added on top of the user plane traffic per cell/BTS to support HSUPA soft handover traffic.

HSPA QoS streamingRU10 allows serving streaming QoS class RAB on HSPA. In previous releases such streaming traffic was only possible using R99 DCH. New feature enables streaming traffic class RAB to be mapped on DCH/HS-DSCH and E-DCH/HS-DSCH transport channels. Streaming RABs conveyed on HSPA are thus prioritized internally by RNC and by BTS HSUPA and HSDPA packet schedulers, which take Scheduling Priority Indi-cator (SPI) value into account. Different weights are defined per priority queues on the basis of SPI class and within a class of common SPI flows proportional fair scheduler is used.

Streaming traffic is usually characterized by sensitive time relations (delay variation) between information entities (for example, PDUs) of a stream and is not very sensitive in terms of requirements on low transfer delay. For RT HSPA traffic admission control is supported within the transport network basing on Guaranteed Bit Rate (GBR). In addition the feature enables in RNC configurable Nominal Bit Rate (NBR) for NRT traffic classes, which can be used as targeted minimum bit rate, for example, based on sub-scription. In the scheduler, NBR has higher priority than best effort traffic but lower

Application

PDCP

RLC

MAC-d

MAC-es

MAC-e

PHY

UEUu

UL

BTSIub

RNCIuPS

Application

PHY

Transport

MAC-e

PHY

PDCP

RLC

MAC-d

MAC-es

Frame Protocol

PHY

Transport

Frame Protocol

DN70118376Issue 04E

227


Id:0900d80580736fc8

priority than GBR of real time users. Typical applications which can be characterized as streaming are real time video download or video sharing.

For the new service or subscriber connection CAC is performed using downlink and uplink GBR or NBR requirements respectively over both IP and ATM transport networks. In addition QoS Aware HSPA Scheduling feature includes prioritization in Iub frame protocol (FP) layer and adds QoS awareness to HSUPA Congestion Control and HSDPA Congestion Control features. For more information, see features: RAN1004: Streaming QoS for HSPA and RAN1262: QoS Aware HSPA Scheduling.

Dimensioning method for streaming traffic on HSPA over Iub interface is based on pro-cedure for real time CS services described in section Iub dimensioning methods for user plane (real-time traffic). Likewise for CS services QoS parameters for HSPA streaming traffic class are defined on call level as a call-blocking rate (for example, Blocking-per-centage) per service class i. If not specified by the operator, call blocking probability for RT HSPA services are same as for R99 streaming services. Traffic intensity ErlangRT_HSPA needs to be evaluated on the basis of the input traffic model. Appro-priate dimensioning for streaming services requires the definition of the corresponding application type to be used by the end users. Therefore, Gross EffectiveBW value needs to be calculated on the basis of effective codec bit rate for dedicated streaming service and corresponding transport overhead.

Note that effective codec bit rate (for example, for VoIP services) might change depend-ing whether the header compression is used or not.

Bandwidth MD-Erlang = MD-Erlang [ ErlangRT_HSPA; Gross EffectiveBW; Blocking-percentage ]

For the exemplary VoIP service (with AMR codec 12.2):

• Effective peak rate is 29.4kbit/s (calculated as a sum of the VoIP bit-rate 12.2kbit/s and the header overhead 17.2kbit/s); no RTP/UDP/IP header compression.

• Activity factor (AF) = 60% • HSDPA overhead (RLC/FP/AAL2/ATM OH): ~60%, therefore:

Gross EffectiveBW = Effective BW * AF*HSDPA_OH= 29,4kbit/s*0,6*1,6=28,2kbit/s

For scenarios where RT CS traffic and RT HSPA traffic share the same transport resources, calculation of the required bandwidth is done with Multidimensional Erlang method for all RT services together.

With the assumptions of different transport resources for R99 RT and for RT HSPA traffic the MDE algorithm has to be applied separately for streaming QoS services mapped on HSPA and separately for RT CS services. The example is the usage of hybrid transport when different transport media are used for transmission and thus transport resources are not commonly shared by all RT services. Similarly when single transmission media is used for transmission (for example, ATM network), but RT HSPA traffic and CS traffic are VCC separated. In this case estimation of the number of simul-taneous connection has to be done separately for RT CS and RT HSPA services.

6.2.4.7 Calculation of total Iub bandwidth demandBased on the results achieved using one of the options described above and HSDPA demand, the total Iub bandwidth demand is estimated as shown in Figure Iub bandwidth demand.

228 DN70118376Issue 04E


Id:0900d80580736fc8

Figure 92 Iub bandwidth demand

Proposed evaluation, in addition to calculated bandwidth demands (Term 1), takes into account possible requirement related to maximum achievable HSDPA peak rate per given BTS.

Note that there might be a different requirements regarding Iub bandwidth demand cal-culation (for example, HSDPA peak throughput per cell might be demanded, instead of “per BTS”).

RU20 HSPA+ features increase HSPA Peak Rate Demand per BTS, according to new UE Categories supported.

6.2.5 IP-based Iub dimensioningIP-based Iub dimensioning allows determining the following capacity-related compo-nents, as presented in Figure IP-based Iub dimensioning components.

R99 secureHSDPA w/o QoS

HSDPAIub add overhead

margin

HSDPAGross UserMean rate

HSDPAcontrol rate

in DL

R99 QoS andCAC delta

R99 DTCHmean rate CSPS realtime

PS nonRealtime

CCH mean rate(average rate)

CCH CAC delta

HSxPATotal BWdemand

Total CACBW

result

HSUPAcontrol rate

in DL

HSDPAOverhead

30

HSDPANet peakrate pernodeB

Non User VC's (signalling...)

UserVCs

Non UserVCs

Line RateNodeB DL

Min guaranteedHSDPA peak rate

Term 1 Term 2

DN70118376Issue 04E

229


Id:0900d80580736fc8

Figure 93 IP-based Iub dimensioning components

• IP_Route_Commited_Bandwidth: CAC-guaranteed IP bandwidth per logical Iub. This parameter is configured in RNC and BTS to set the available bandwidth for high priority connections.

• Shared_BE_IP_Allocation: non CAC-guaranteed IP bandwidth per logical Iub for low-priority BE traffic

• IP_Route_Bandwitdh: Total IP bandwidth per Iub. Against this parameter a traffic shaping is done in order not to exceed the configured IP link capacity on Iub.

• Iub_Ethernet_Capacity: Total bandwidth per Iub on the Transport level (incl. Ethernet OH). This parameter specifies the actual Ethernet capacity to be installed on Iub at the BTS side.

• RNC_Ethernet_Capacity: Total bandwidth per RNC Ethernet port grouping multiple logical Iubs. This parameter specifies the Ethernet capacity to be installed on Iub at the RNC side. Against this parameter traffic shaping is done in order to not exceed the configured Ethernet link capacity for a given port.

Note that IP_Route_Commited_Bandwidth, IP_Route_Bandwitdh, Iub_Ethernet_Capacity, and RNC_Ethernet_Capacity are formal parameters to be con-figured in the RNC and BTS. Shared_BE_IP_Allocation is not a configurable parameter, but it needs to be known in order to determine the non CAC-guaranteed bandwidth and, indirectly, the total bandwidth per Iub.

6.2.5.1 IP Connection Admission ControlIP-based Iub dimensioning is impacted by the IP CAC procedure. IP CAC decides whether to admit an incoming RAB connection depending on the available Iub band-width. It is performed in RNC in DL, separately for each logical Iub, and in BTS in UL. Subject to IP CAC are the following RABs:

• R99 RT DCHs (CS/PS) • CS voice over HSPA • R99 NRT DCHs (PS) • DCCHs (over DCH and HSPA) • CCHs

CAC guaranteed traffic

Non-guaranteed traffic

CAC guaranteed traffic

Non-guaranteed traffic

RNC

IP_Route 1

IP_Route 2

BTS 1

CACguaranteed

traffic

Non-guaranteed

traffic

BTS 2

CACguaranteed

traffic

Non-guaranteed

traffic

Iub_Eth

_Cap

Iub_Eth_Cap

IP_R

oute

1_B

W

IP_RouteCommited_BW

Shared_BEIP_Allocation

IP_R

oute

2_B

W

IP_RouteCommited_BW

Shared_BEIP_Allocation

Rn

c_

Eth

ern

et_

Ca

p

230 DN70118376Issue 04E


Id:0900d80580736fc8

HSPA can be subject to CAC if the RAN1004: Streaming QoS for HSPA feature is acti-vated. In case feature RAN1004: Streaming QoS for HSPA is not activated, HSPA is not subject to CAC.

The IP CAC-guaranteed capacity per single RAB service is calculated by applying to each bearer a set of traffic descriptors:

• Maximum bitrate in IP payload layer • Average bitrate in IP payload layer

Each bearer type should have its own set of traffic descriptors for DL and UL separately.

The IP CAC-guaranteed capacity per single RAB is calculated from the traffic descrip-tors:

CAC_Guaranteed_Bitrate RAB = 0.2 × MAX_Bitrate RAB + 0.8 × AVE_Bitrate RAB

The values of IP CAC traffic descriptors for some selected R99 RABs are presented in Table CAC traffic descriptors and bit rates for selected Release 99 and DCCH-over-HSPA bearers over HSPA traffic.

The total CAC-guaranteed bandwidth for a user service is a sum of the CACguaranteed bit rates of DTCH and DCCH channels.

For R99 services:

CAC_Guaranteed_BR Service = CAC_Guaranteed_BR Service_DTCH + CAC_Guaranteed_BR Service_DCCH

For HSPA services admitted with CAC and DCCH over DCH:

CAC_Guaranteed_BR Service = CAC_Guaranteed_BR Service_HS-DSCH + CAC_Guaranteed_BR Service_DCCH_over_DCH

For HSPA services admitted with CAC and DCCH over HS-DSCH:

CAC_Guaranteed_BR Service = CAC_Guaranteed_BR Service_HS-DSCH + CAC_Guaranteed_BR Service_DCCH_over_HS-DSCH

An incoming service connection on Iub is admitted by CAC provided that the residual Iub bandwidth is more than or equal to CAC_Guaranteed_Bitrate Service.

Note that RU20 RAN1201: Fractional DPCH brings in a support for DCCHs carried over HS-DSCH. IP Traffic descriptors for DCCHs vary depending on whether a DCCH is carried over a DCH or HS-DSCH – see Table CAC traffic descriptors and bit rates for selected Release 99 and DCCH-over-HSPA bearers over HSPA traffic.

Note that recommended DCCH over DCH type for Iub dimensioning is DCCH 13.6 SET 3.

IP CAC traffic descriptors for HSPA are defined for HSPA bit rates in steps of 8 kbps between 0 - 512 kbps and with steps of 32 kbps between 512 - 2048 kbps, as shown in Table IP traffic descriptors and Ethernet overheads for HSPA traffic. They are used in the following way to calculate CAC_Guar_Bitrate HSPA:

For RT HSPA MAX_Bitrate and AVE_Bitrate are selected based on the max and guar-anteed bit rate requirement specified by the operator. For NRT HSPA MAX_Bitrate = AVE_Bitrate = Nominal Bit Rate, as specified by the operator. The operator-specified values are rounded up to the next applicable HSPA bit rate and the corresponding traffic descriptor is picked up. For example, a HSPA Streaming RAB carrying VoIP with max and guaranteed bit rates set respectively to 30 and 15 kbps is rounded up to 32 and 16 kbps. The corresponding traffic descriptors in DL are (Table IP traffic descriptors and

DN70118376Issue 04E

231


Id:0900d80580736fc8

Ethernet overheads for HSPA traffic): Max = 65.6 kbps and Ave = 32.8 kbps. The CAC guaranteed bandwidth in DL is equal to:

CAC_Guaranteed_Bitrate HSPA (DL) = 0.2 × 65.6 + 0.8 × 32.8 = 39.4 kbps

For a NRT HSPA RAB with the nominal bit rate set to 128 kbps, the CAC-guaranteed bandwidth DL is equal to:

CAC_Guaranteed_Bitrate HSPA = 0.2 × 166.4 + 0.8 × 166.4 = 166.4 kbps

Note that in case feature RAN1096: Transport Bearer Tuning is activated, the AVE_Bitrate parameter is calculated as MAX_Bitrate × Activity Factor instead of being picked up from traffic descriptors.

6.2.5.2 Dimensioning the CAC-guaranteed U-plane RT trafficU-plane CAC-guaranteed bandwidth is calculated separately for RT and NRT U-plane traffic, using different dimensioning methods. It is recommended to dimension the RT traffic (that is Conversational and Streaming R99 DCHs and Streaming HSPA) with MD-Erlang formula, separately for each DiffServ PHB class grouping this type of traffic:

RT_U-Plane_commited_BW PHB = MD-Erlang [Gross_peak_rate RAB 1,

Offered_traffic RAB 1, Bl_Pr RAB 1 ; … ; Gross_peak_rate RAB n, Offered_traffic RAB n, Bl_Pr RAB n]

where:

• n is the number of RT services (RABs) within a given PHB class. • Gross peak rate RAB, is a sum of CAC_Guaranteed_Bitrate RAB for RT DTCH and

DCCH bearers:Gross peak rate RAB = CAC_Guaranteed_BW RAB_DTCH + CAC_Guaranteed_BW RAB_DCCH

• Offered_traffic RAB is the mean traffic per service (RAB) in [erlang] extended with SHO_factor:Offered_traffic RAB = Mean_traffic RAB × (1+ SHO_Factor) The value of Mean_traffic RAB is defined by the operator. Alternatively it can be taken from the traffic model. Assumed SHO_Factor value is 30%. Note that for HSPA in DL the soft handover is not considered (SHO_Factor = 0).

• Bl_Pr RAB is the service blocking probability. Usually assumed values are 0.1% – 1%.

6.2.5.3 Dimensioning the CAC-guaranteed U-plane NRT trafficCAC-guaranteed bandwidth for the NRT traffic (that is Interactive/Background R99 DCHs and I/B HSPA, if subject to CAC) can be calculated using M/G/R-PS formula, sep-arately for each DiffServ PHB class grouping this type of traffic:

nRT_U-Plane_com_BW PHB = M/G/R-PS [Total_offered_traffic;

Gross_peak_rate RAB 1, Transfer_delay RAB 1 ; … ; Gross_peak_rate RAB n,

Delay_factor RAB n ]

where:

• n is the number of NRT services (RABs) within a given PHB class

232 DN70118376Issue 04E


Id:0900d80580736fc8

• Total_offered_traffic is the total mean traffic summed over all nRT services (RABs):

• Gross peak rate RAB, is a sum of CAC_Guaranteed_Bitrate RAB for NRT DTCH and DCCH bearers:Gross peak rate RAB = CAC_Guaranteed_Bitrate RAB_DTCH + CAC_Guaranteed_Bitrate RAB_DCCH For I/B HSPA, if subject to CAC, DCCHs are not considered.

Delay_factor RAB reduces the effective bit rate perceived by the end-user of an NRT application as compared with the nominal CAC_Guaranteed_Bitrate. Suggested values of Delay_factor RAB on Iub are 5-10%.

With this set of inputs, M/G/R-PS is repeated n times, separately for each NRT RAB service, and the max value over all calculations is picked-up.

The use of M/G/R-PS is recommended when the QoS measures in terms of transfer delay on Iub must be explicitly taken into account. On the other hand, the formula does not take into account the service activity factor.

6.2.5.4 Dimensioning the other CAC-guaranteed traffic componentsBesides RT and NRT U-plane traffic (R99 + HSPA), the other traffic subject to CAC includes U-plane CCHs, C-plane and O&M.

The CCH bandwidth per BTS is equal to the CAC-guaranteed bandwidth of the highest bit-rate CCH, which is FACH-U in DL and RACH in UL, multiplied by the number of cells per BTS. The CAC-guaranteed bandwidth is calculated on the basis of the traffic descriptors, by default: 0.2 × Max + 0.8 × Ave. IP traffic descriptors for CCHs is summa-rized in the following table:

* Note that optional RU20 feature RAN1202: 24 kbps Paging Channel brings in a possi-bility to enhance the paging channel throughput to 24 kbps.

For the O&M traffic a 64 kbps IP transport channel is assumed.

6.2.5.5 Dimensioning the non CAC-guaranteed I/B HSPA trafficIn addition, the capacity needed on Iub for non CAC-guaranteed Best Effort traffic must be assured. Currently only I/B HSPA can fall under non-CAC guaranteed traffic. The

Total_offered_traffic Mean_trafficRAB[kbps] 1 SHO_Factor+( )×RAB∑=

Bearer type MAX rate [kbps]

AVE rate [kbps]

MAX Packet Size [Byte]

AVE Packet Size [Byte]

Ethernet OH [%]

CCH bearers

FACH-C – DL 66.2 6.1 76 34 55

FACH-U – DL 68.7 6.3 79 34 53

RACH – UL 14.3 1.1 29 0 53

PCH – DL 55.2 5.0 62 34 68

PCH 24k* - DL 64 5.8 73 43 98

Table 88 IP traffic descriptors and Ethernet overheads for U-plane CCH traffic

DN70118376Issue 04E

233


Id:0900d80580736fc8

non-CAC guaranteed HSPA capacity is calculated based on the mean traffic of I/B HSPA users extended with the Frame Protocol and IP transport overheads. Optionally, some additional QoS overhead can be added to account for instantaneous I/B HSPA bursts above the average value:

BE_HSPA_BW = #_of_Subs I/B HSPA × Mean_traffic_per_subs I/B HSPA × (1 + IP_Transport_OH) × (1 + QoS_Factor)

IP_Transport_OH average values are 18% DL and 20% UL.

Typical QoS_Factor values are around 25%.

6.2.5.6 Dimensioning synchronization trafficFinally, the last traffic component to be accommodated on Iub is the synchronization traffic. In RU20, it is possible to use two types of synchronization for IP-based Iub: either Timing over Packet (ToP), defined in the IEEE 1588 standard, or Synchronous Ethernet (SyncE), defined in the ITU-T spec G.8261. The synchronization option is user configu-rable. In particular no synchronization is also possible.

Guidelines for the ToP bandwidthToP traffic comprises Precise Time Protocol (PTP) synchronization messages being sent between Timing Master Server and Timing Slave located in BTS, thus in the DL only.

The bandwidth requirement of the ToP stream depends on the frequency of the Sync Msg exchange and the Sync Msg length.

ToP_BW [kbps] = (Eth/IP/UDP_Hdr_length + PTP_Sync_Msg_size [bits] / 1000) × PTP_Sync_Msg_rate [1/s]

PTP_Sync_Msg_rate is configurable in range of 0.5/s to 128/s. Default value is 16/s. The PTP_Sync_Msg_size is 44 bytes.

The ToP bandwidth for the default value of the Sync Msg rate is ~ 16 kbps.

Note that it is recommended to map the ToP traffic to the highest priority EF PHB.

Guidelines for the SyncE bandwidthThe SyncE bandwidth is due to a periodical sending of synchronization status messages (SSM) between two SyncE-capable network node elements. The bandwidth require-ment of the SSM stream depends on the frequency of the SSM exchange and the SSM size:

SSM_BW [kbps] = (SSM_Hdr_size [bits] + SSM_PDU_size [bits]) / 1000 × SSM_rate [1/s]

SSM_Hdr_size is fixed to 224 bits, SSM_PDU_size is variable, with the mean value of 6104 bits. SSM_rate is 1/s. The mean SSM bandwidth is thus equal to 6.4 kbps.

Note that this bandwidth is to be considered only in the DL direction, at the BTS side (that is Iub last mile).

Note that the SyncE bandwidth is specified in the Ethernet layer and it is not to be con-sidered in the higher layers. In particular, it does not affect the CAC in the IP layer.

234 DN70118376Issue 04E


Id:0900d80580736fc8

6.2.5.7 Calculating the Iub IP bandwidth for the CAC-guaranteed traffic (IP_Route_commited_BW)Iub IP bandwidth for the CAC-guaranteed traffic refers to IP_Route_commited_BW in Figure IP-based Iub dimensioning components. It is calculated as a sum of bandwidths of all CAC-admitted services:

IP_ Route_commited_Bandwidth = RT_U-Plane_commited_BW +

nRT_U-Plane_commited_BW + CCH_U-Plane_commited_BW +

IP_Route_C-Plane_commited_BW +IP_Route_O&M_commited_BW

6.2.5.8 Calculating the Iub IP bandwidth for the non CAC-guaranteed traffic (Shared_BestEffort_IP_Allocation)Iub capacity for the non CAC-guaranteed traffic refers to Shared_BestEffort_IP_Allocation in Figure IP-based Iub dimensioning components. Currently the CAC-guaranteed traffic groups only the I/B HSPA traffic:

Shared_BestEffort_IP_Allocation = BE_HSPA_BW

6.2.5.9 Calculating the total IP Iub bandwidth (IP_Route_Bandwidth)The total IP Iub bandwidth on Iub refers to IP_Route_Bandwidth in Figure Dual Iub con-figuration for BTS. It is calculated It is calculated separately for UL and DL.

For UL it is calculated as a sum of bandwidths for CAC-guaranteed and non-CAC guar-anteed traffic, including additional Transport Layer overhead:

IP_Route_BW (UL) = (IP_ Route_commited_BW (UL) + Shared_BestEffort_IP_Allocation (UL)) × (1 + Weighted_Ethernet_OH (UL))

where Weighted_Ethernet_OH is the mean Ethernet transport overhead weighted over the services supported on Iub. It is calculated as:

Ethernet overhead for single RAB is calculated out of the traffic descriptors (Table Header length for Iu-PS data (IP over ATM)) in the following way:

Length of Ethernet frame header is assumed 38 bytes w/o VLAN and 42 bytes with VLAN.

For DL, it is calculated as maximum of two components:

1. the U-plane bandwidth calculated based on the mean user traffic: RT_U-Plane (R99 and Streaming HSPA), NRT-U-plane (R99 and I/B HSPA) and CCH_U-Plan

2. the specified HSPA Peak Rate per cell/WCDMA BTS, extended with the respective Eth OH.IP_Route_BW (DL) = Max {(RT_U-Plane_commited_BW (DL) + NRT_U-Plane_commited_BW (DL) + CCH_U-Plane_commited_BW (DL) + Shared_BestEffort_IP_Allocation (DL)) × (1 + Weighted_Ethernet_OH (DL); U-

Weighted_Ethernet_OH =Mean_trafficRAB

RAB

Mean_trafficRAB × Eth_OHRAB

RAB

Eth_OHRAB

[%] =Average_IP_packet_size

RAB[byte]

Eth_frame_header_length[byte]x 100%

DN70118376Issue 04E

235


Id:0900d80580736fc8

Plane_Bw (HSDPA_Peak_Rate)} + C-Plane_commited_BW (DL) + O&M_commited_BW (DL) + Sync_commited_BWWhere U-Plane_Bw (HSDPA_Peak_Rate) is the specified HSPA Peak Rate per cell/WCDMA BTS, extended with the respective Eth OH.Calculating the total Iub bandwidth for DL (IP_Route_Bandwidth (DL)) is graphically presented in the following figure.

Figure 94 Calculating IP_Route_Bandwidth for DL

6.2.5.10 Calculating the total Iub transport capacityThe effective Iub capacity on the transport level (denoted as Iub_Ethernet_Capacity in Figure IP-based Iub dimensioning components) can be derived directly out of IP_Route_Bandwidth by applying an additional transport link utilization factor Iub_Utilization [%]:

Iub_Ethernet_Capacity = (1 / Iub_Utilization) × IP_Route_Bandwidth

Iub_Utilization parameter (< 100%) accounts for the situations where the transport link is not fully loaded to retain some spare capacity.

C Plane, O&M and Synch bandwith

HSDPA Peak Rate/ NodeB

HSUPA Ctrl

Bandwidth calculatedbased on the mean user

traffic

Bandwidth calculatedbased on the HSDPA

Peak Rate

Eth_OH(HSDPA Peak Rate)

Weighted _Eth_OH

RT_U-Plane_comm_BW

nRT_U Plane_comm_BW

Shared_BestEffort_IP_Allocation

CCH_U-Plane_comm_BW

Use

rtr

affic

non

Use

rtr

affic

IP_

Ro

ute

_B

W(D

L)

236 DN70118376Issue 04E


Id:0900d80580736fc8

In addition, the total capacity per physical RNC interface IP_Port is defined as a sum of the capacities of all Iubs terminated at this physical port reduced with the overbooking factor:

where

denotes logical Iubs terminated at the physical interface IP_Port.

The overbooking factor Overbooking IP_Port accounts for the multiplexing gain from grouping multiple Iubs on a single physical port. It depends on the number of Iubs grouped on a port and statistical multiplexing characteristics of the traffic carried on indi-vidual Iubs. It can be expressed as:

where IP_Route_Bandwidth (Traffic_of_multiple_Iubs) IP_Port denotes the capacity of the aggregated traffic of all Iubs terminated on IP_Port.

RNC in DL and BTS in UL perform traffic shaping. In RNC traffic shaping is done per Iub, against IP_Route_BW and per IP port, against RNC_Ethernet_Capacity. At BTS traffic shaping is done per IP port against IP_ Route_BW.

6.2.6 IP-based Transport Network Layer configuration

6.2.6.1 IP Iub Protocol Stack and Protocol OverheadsFor the IP-based transport on Iub interface, U-plane transport bearers (DCH, DCCH, CCCH and HSPA) are mapped onto UDP/IP flows encapsulated into Ethernet frames for transport. For the C-plane (C-NBAP and D-NBAP), the SCTP/IP encapsulation is used.

The protocol stack for the U-plane and C-plane traffic on the IP-based Iub is as pre-sented in Figure U-plane and C-plane protocol stacks on the IP-based Iub.

RNC_Ethernet_CapacityIP_Port 1/ Iub_UtilizationIP_Port( ) OverbookingIP_Port×

IP_Route_Bandwidth ical_Iubloglogical_Iub IP_Port∈

∑

×=

logical_Iub IP_Port∈

OverbookingIP_PortIP_Route_Bandwidth(Traffic_of_multiple_Iubs)IP_Port

IP_Route_Bandwidth(Traffic_of_single_Iub)Logical_IubLogical_Iub IP_Port∈

∑------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------=

DN70118376Issue 04E

237


Id:0900d80580736fc8

Figure 95 U-plane and C-plane protocol stacks on the IP-based Iub

The Iub protocol stack and the exact format of Iub Frame Protocol (FP) frames used to carry individual radio access bearers (RABs) determine the IP traffic descriptors used with CAC and the transport overhead (that is the amount of additional bandwidth needed to accommodate the Iub traffic on Ethernet links).

The IP CAC traffic descriptors (defined on the IP level) and the additional Ethernet overhead for some selected R99 and HSPA RABs are summarized in Tables CAC traffic descriptors and bit rates for selected Release 99 and DCCH-over-HSPA bearers and CAC traffic descriptors and bitrates for selected HSPA flows.

Ethernet-Phy

ARP

ICMPv4SCTP

IPv4

Ethernet-Mac

NBAP

Ethernet-Phy

ARP

ICMPv4

BFD

UDP

IPv4

Ethernet-Mac

Iub User Plane protocol


AVE rate [kbps]

Ethernet OH [%]

IP CAC bit rate[kbps]

Ethernet bit rate [kbps]

CS bearers

CS AMR 12.2 – UL 30.8 16.6 61 19.4 31.2

CS AMR 12.2 – DL 29.8 16.1 61 18.8 30.3

CS 64 – UL 97.5 92.0 37 93.1 127.1

CS 64 – DL 95.9 90.4 37 91.5 125.5

Real time (RT) PS bearers

RT PS 16/64 – UL 50.6 44.8 75 46.0 80.4

RT PS 16/64 – DL 97.5 92.0 37 93.1 127.1

RT PS 16/128 – UL 50.6 44.8 75 46.0 80.4

RT PS 16/128 – DL 163.1 157.6 21 158.7 192.5

Non-real time (NRT) PS bearers

NRT PS 64/64 – UL 101.0 95.2 35 96.4 130.4

NRT PS 64/64 – DL 99.1 93.6 36 94.7 128.7

NRT PS 64/128 – UL 101.0 95.2 35 96.4 130.4

NRT PS 64/128 – DL 166.3 160.8 21 161.9 195.7

NRT PS 64/384 – UL 101.0 95.2 35 96.4 130.4

Table 89 CAC traffic descriptors and bit rates for selected Release 99 and DCCH-over-HSPA bearers

238 DN70118376Issue 04E


Id:0900d80580736fc8

NRT PS 64/384 – DL 435.1 429.6 8 430.7 464.4

DCCH bearers (SET 3) over DCH

DCCH 1.6 – UL 6.5 3.2 78 3.9 6.9

DCCH 1.7 – DL 8.8 3.1 81 4.3 7.7

DCCH 3.2 – UL 12.5 3.2 78 5.1 9.1

DCCH 3.4 – DL 14.6 3.1 81 5.4 9.8

DCCH 12.8 – UL 48.7 3.2 78 12.3 21.9

DCCH 13.6 – DL 49.5 3.1 81 12.4 22.4

DCCH bearers (SET 3) over HSPA

DCCH on HSPA – UL 32.2 3.2 70 9.0 15.3

DCCH on HSPA – DL 30.8 3.1 72 8.6 14.9


AVE rate [kbps]

Ethernet OH [%]

IP CAC bit rate[kbps]


Table 89 CAC traffic descriptors and bit rates for selected Release 99 and DCCH-over-HSPA bearers (Cont.)

RLC SDU rate

[kbps]

Remark IP Traffic Descriptor

(MAX = AVE) [kbps]

Ethernet OH [%]


HSDPA

CAC

adm

itted

bit

rate

s

16 32.8 51 49.5

32 65.6 51 99.1

64 99.2 34 132.9

128 166.4 20 199.7

512 569.6 18 603.8

800 Peak rate of UE Cat 11 1040.0 17 1216.8

1120 Peak rate of UE Cat 1 / 2 1340.8 13 1515.1

1600 Peak rate of UE Cat 3 / 4 / 12 1744.0 10 1918.4

1920 2080.1 2 2121.6

2048 2214.4 2 2258.7

Table 90 CAC traffic descriptors and bitrates for selected HSPA flows

DN70118376Issue 04E

239


Id:0900d80580736fc8

Note that IP traffic descriptors and Ethernet overheads depend on the actual data rates of MAC-d flows that can vary. Here these are shown for selected values of MAC-d flow rates.

RU20 RAN1638: Flexible RLC further decreases HSDPA overhead for UE categories supporting the feature (depends on the actual bit rate).

6.2.6.2 Mapping U-plane, C-plane Transport Bearers to IP/Ethernet FlowsAt Layer 4 UMTS transport bearers are identified by UDP/SCTP ports.

At Layer 3 transport flows are allocated IP addresses. In BTS one IP address is allo-cated commonly for the U-plane and C-plane traffic. In addition, two IP addresses are allocated to the O&M flows. In RNC there are two separate addresses for the U-plane and C-plane traffic.

As it should be possible to support up to 2800 instances of the logical Iub interface, the max number of IP addresses required at the BTS side would be 2800 × 3 = 8400 and at the RNC side: 2800 × 2 = 5600.

Non

CAC

adm

itted

bit

rate

s (1

0% B

LER

) 3055 Peak rate of UE Cat 5 / 6 - 4 3442.9

6109 Peak rate of UE Cat 7 / 8 - 3 6826.9

8727 Peak rate of UE Cat 9 - 3 9693.8

12218 Peak rate of UE Cat 10 - 3 13289.5

19111 Peak rate of UE Cat 14 (64QAM; Flexible RLC)

- 3 20261.1

25310 Peak rate of UE Cat 16 (MIMO; 64QAM; Flexible RLC)

- 3 26829.1

38222 Peak rate of UE Cat 24 (DC-HSDPA; 64QAM; Flexible RLC)

- 3 40518.5

HSUPA

CA

C a

dmitt

ed b

itrat

es

32 64 53 97.9

64 97.6 34 130.8

128 164.8 20 197.8

512 568 6 602.1

768 Peak rate of UE Cat 1 769.6 4 870.3



2048 2211.2 1 2255.4

RLC SDU rate

[kbps]

Remark IP Traffic Descriptor

(MAX = AVE) [kbps]

Ethernet OH [%]


Table 90 CAC traffic descriptors and bitrates for selected HSPA flows (Cont.)

240 DN70118376Issue 04E


Id:0900d80580736fc8

Further differentiation in the IP layer is made based on the QoS level allocated to the U-plane and C-plane traffic. Traffic is classified as belonging to a number of different traffic classes corresponding to different DiffServ Code Point (DSCP) values. Different traffic classes have different Per Hop Behavior (PHB) in the IP routed network between RNC and BTS, in terms of allocated bandwidth and forwarding policy. For the DiffServ QoS classification and handling rules, see IP transport QoS Iub.

QoS classes and treatment from the IP layer are maintained within the Ethernet-based transport network between RNC and BTS. QoS information from the IP layer is mapped to the Ethernet Class of Service (CoS) using Ethernet priority code point (PCP) corre-sponding to the IP DSCP value. Also the scheduling scheme on the Ethernet layer cor-responds to the scheduling scheme specified for the IP layer.

Mapping of U-plane and C-plane Logical Channels to IP/Ethernet flows is presented in Figure IP-based Iub Transport flow configuration in DL. VLAN option: 1 VLAN per logical Iub. The assumed values of DSCP, PHB and VLAN p-bits are as specified in Table Example of IP Transport QoS mapping on Iub. In one exemplary option of the VLAN usage is shown, allocating a single VLAN per logical Iub (the Eth QoS differentiation is done with VLAN 802.1 priority bits).

To meet the Iub capacity requirements defined in Iub dimensioning methods for user plane, the allocated Ethernet bandwidth per VLAN for this option should be (CIR: Commited information Rate, EIR: Excessive Information Rate):

1. CIR Iub = IP_based_Route_commited_Bw × (1 + Weighted_Ethernet_OH)2. EIR Iub = Iub_Ethernet_Capacity

In case no VLANs are used or a VLAN is allocated per physical Ethernet interface at RNC, the capacity parameters should be:

1.

where denotes logical Iubs terminated at the physical interface IP_Port.

2. EIR IP_Port = RNC_Ethernet_Capacity

Note that:

• CAC at the physical interface level is not performed. • A VLAN tagging option allocating separate VLANs per traffic classes (for example,

U-plane RT vs. non-RT) is currently not supported for RU10. • Presented options of VLAN assignment are only exemplary. VLAN assignment is

much more flexible and can be configured in arbitrary way. In particular, no VLAN can also be used.

Ethernet frames are handled in the following way at Ethernet switches:

• If Traffic Rate <= CIR, both CAC-guaranteed and non CAC-guaranteed frames are forwarded.

• If EIR >= Traffic Rate > CIR, CAC-guaranteed frames are forwarded, non CAC-guar-anteed frames is marked as discard eligible (DE). Non CAC-guaranteed frames pass through the network if there is no congestion.

• If Traffic Rate > EIR, both CAC-guaranteed and non CAC-guaranteed frames are dropped.

CIRIP_Port

= IP_based_Route_commited_BWlogical_Iub

Weighted_Eth_OHlogical_Iub

logical_Iub IP_Port

logical_Iub IP_Port

DN70118376Issue 04E

241


Id:0900d80580736fc8

Differentiation between CAC-guaranteed and non CAC-guaranteed frames is done based on VLAN p-bits.

Figure 96 IP-based Iub Transport flow configuration in DL. VLAN option: 1 VLAN per logical Iub

6.2.6.3 IP Transport QoS on IubQoS differentiation in the IP transport layer is implemented with the differentiated services (DiffServ) concept (RFC2574).

The configurable QoS differentiation applies to the following transport bearers:

UTRANTransport Bearer

TC

PP

ort

#1

TC

PP

ort

#2

UD

PP

ort

#11

UD

PP

ort

#12

UD

PP

ort

#3

UD

PP

ort

#4

UD

PP

ort

#5

UD

PP

ort

#6

UD

PP

ort

#7

UD

PP

ort

#8

UD

PP

ort

#9

UD

PP

ort

#1

0

SC

TP

Port

#1

SC

TP

Port

#2

0b001010

(26)

0b001010

(26)

0b010010

(34)

0b000000

(0)

0b001010

(46)

0b001010

(46)

0b001010

(46)

0b101110

(46)

0b010010

(46)

0b010010

(46)

0b011010

(46)

0b101110

(18)

0b001010

(46)

0b001010

(46)

IPA

dd

ress

#1

IPA

ddre

ss

#2

IPA

ddre

ss

#3

IPA

ddre

ss

#3

IPA

ddre

ss

#3

IPA

ddre

ss

#3

IPA

ddre

ss

#3

IPA

ddre

ss

#3

IPA

ddre

ss

#3

IPA

ddre

ss

#3

IPA

ddre

ss

#3

IPA

ddre

ss

#3

IPA

ddre

ss

#3

IPA

ddre

ss

#3

O&

M#1

O&

M#2

HS

-DS

CH

#1

HS

-DS

CH

#2

RT

HS

DP

AS

NR

TH

SD

PA

I/B

RA

CH

FA

CH

PC

H

DC

H#1

RT

CS

C

DC

H#2

DC

H#

3

RT

CS

C

RT

PS

C

DC

H#

4

DC

CH

RT

PS

S

NR

TP

SI/

B

C-N

BA

P

D-N

BA

P

AF4 EF AF4AF2 BE

4 4 6 6 3 3 3 6 4 6 4 2 4 0

VLAN ID #1

CIR = IP_based_Route_commited_BW x Weighted_Eth_OHEIR = IP_based_Route_BW x Weighted_Eth_OH

UTRANService

Layer 4

IP Layer

DSCPmarking

EthernetTransport Network

p-bitmarking

VLAN tagging

PHBallocationAF3 EF AF4 EF AF4

242 DN70118376Issue 04E


Id:0900d80580736fc8

• Common channels (FACH, RACH, PCH) • Signaling Radio Bearer (SRB / DCCH over DCH, E-DCH and HS-DSCH) • CS traffic (AMR, CS-RT, CS-NRT R99 DCH) • Packet data connections with the R99 DCH, E-DCH and HS-DSCH

RABs with specific QoS parameters from the Radio Network Layer (Traffic Class –TC, Traffic Handling Priority – THP, Allocation and Retention Priority – ARP) are allocated different DiffServ Code Point (DSCP) values. These are then mapped to respective PHBs in the IP transport layer to obtain the adequate scheduling and forwarding priority. The IP QoS differentiation is maintained further in the Ethernet layer by mapping the IP DSCP values to the Ethernet Class of Service (CoS) using respective Ethernet priority code points (PCP). Also the scheduling scheme on the Ethernet layer corresponds to the scheduling scheme specified for the IP layer.

With basic IP Based Iub the traffic differentiation is based on the air interface channel type and the UMTS traffic class. Separate RT and NRT DSCP values can be configured for both R99 DCH and HSPA channels. The additional DSCP configuration granularity requires RAN1253: Iub Transport QoS feature. The basic DSCP mapping possibilities are depicted in Figure Possible Transport QoS mapping scheme with IP based Iub.

DN70118376Issue 04E

243


Id:0900d80580736fc8

Figure 97 Possible Transport QoS mapping scheme with IP based Iub

An example of how UMTS transport bearers can be mapped to DiffServ PHBs is shown in Table Example of IP Transport QoS mapping on Iub. Note that UMTS traffic class to PHB mapping is operator configurable. The Table shows only one example of such mapping.

Radio NetworkLayer

Conversational

Streaming

Interactive

Background

Transport NetworkLayer

HS-DSCH

E-DCH

PCH, FACH,RACH

R99 DCHCS

Domain

DSCP

DSCP

DSCP

DSCP

DSCP

DSCP

DSCP

EF

AF 4

AF 3

AF 2

AF 1

BE

If EthernetVLAN in

use:- VLAN tag /

userpriority (0 -

7)

IP Transport

6 Default PHBscorresponding to

the IP egressscheduling queues

Operatorconfigurable

mapping

HS-DSCH FP

SRB

R99 DCHPS

Domain

E-DCH FP

Common channels

Conversational

Streaming

Interactive

Background

CS AMR SpeechCS-T dataCS-NT data

RT HSPA DSCP*

NRT HSPADSCP

HSDPA FPDSCP

HSUPA FPDSCP

RT DCHDSCP

NRT DCH DSCP

* RAN1004: Streaming QoS for HSPAlicense needed

UMTS transport bearer

UMTS Service class

DSCP Value (default)

PHB to be used VLAN p-priority (default)

CS C, PS C incl. DCCHs

Conversa-tional

0b101110 (46)

EF 6 “Voice”

Timing over Packet - 0b101110 (46)

EF 6 “Voice”

Table 91 Example of IP Transport QoS mapping on Iub

244 DN70118376Issue 04E


Id:0900d80580736fc8

6.2.7 CS voice over HSPA (RU20 On Top) – transport network impactsFrom Transport Network point of view, RAN1689: CS voice over HSPA affects the traffic only on Iub and Iur interface. Iu-CS is not influenced. Similar C-plane and U-plane behavior is observed as comparing to the “plain” AMR/DCH calls.

C-plane (C-NBAP, D-NBAP)

- 0b101110 (46)

EF 6 “Voice”

PS S, CS S incl. DCCHs,

HSPA Streaming

Streaming 0b100010 (34)

AF4 4 “Controlled load”

O&M - 0b100010 (34)

AF4 4 “Controlled load”

FACH, RACH, PCH - 0b011010 (26)

AF3 3

PS I/B Prio 1 Interactive THP 1

0b011010 (26)

AF3 3


0b010010 (18)

AF2 2


0b001010 (10)

AF1 1

HSPA I/B Background 0b000000 (0) BE 0 “Best Effort”


UMTS Service class

DSCP Value (default)

PHB to be used VLAN p-priority (default)

Table 91 Example of IP Transport QoS mapping on Iub (Cont.)

DN70118376Issue 04E

245


Id:0900d80580736fc8

Figure 98 CS voice over HSPA – impact on the transport network

6.2.7.1 Call Admission Control aspectsDue to the fact that current dimensioning methods rely on CAC implementation, it is crucial to analyze CAC algorithm applied for CS voice over HSPA calls.

Similarly to AMR/DCH calls, CAC for AMR/HSPA calls is performed on the basis of transport specific Traffic Descriptors fixed in the RNC and operator configurable trans-port independent Activity Factor parameters.

246 DN70118376Issue 04E


Id:0900d80580736fc8

ATM Transport CAC for CS voice over HSPASimilarly to AMR/DCH, CAC for CS voice over HSPA calls relies on a set of UL/DL specific ALC parameters:

• MAX CPS-SDU bit rate • AVE CPS-SDU bit rate • MAX CPS-SDU size • AVE CPS-SDU size

The following table lists the current set of ALC parameters related to CS voice over HSPA calls:

IP Transport CAC for CS voice over HSPASimilarly to AMR/DCH, CAC for CS voice over HSPA calls relies on a set of UL/DL specific IP Traffic Descriptors:

• Maximum bit rate in IP layer • Average bit rate in IP layer • Maximum size of one IP packet • Average size of one IP packet

The following table lists the current set of ALC parameters related to CS voice over HSPA calls:

Bearer type MAX CPS-SDU bit rate [kbps]

AVE CPS-SDU bit rate [kbps]

MAX CPS-SDU size [Byte]

AVE CPS-SDU size [Byte]

AMR/HSPA 12.2 – UL

17.280 10.112 42 42

AMR/HSPA 12.2 – DL

17.728 10.496 44 43

AMR/HSPA 5.9 – UL

10.496 6.016 25 25

AMR/HSPA 5.9 - DL

10.944 6.400 27 26

Table 92 CS voice over HSPA – ALC parameters


AVE rate [kbps]

MAX packet size [Byte]

AVE packet size [Byte]

AMR/HSPA 12.2 – UL

31.168 16.800 70 70

AMR/HSPA 12.2 – DL

31.576 17.160 71.5 71.5

AMR/HSPA 5.9 – UL

24.368 12.720 53 53

AMR/HSPA 5.9 - DL

24.776 13.080 54.5 54.5

Table 93 CS voice over HSPA – IPTD parameters

DN70118376Issue 04E

247


Id:0900d80580736fc8

6.2.7.2 Iub interface dimensioning impactsSimilar dimensioning rules should apply to CS voice over HSPA calls as used for AMR/DCH. For detailed description, see section ATM-based Iub dimensioning. Changed frame structure and different HSPA SHO behavior impacts the following dimensioning steps:

ATM Dimensioning:

• Dimensioning Option 1: calculation of parallel connections is affected by changed overhead and lack of HS-DSCH DL Soft Handover.

• Dimensioning Option 1 and 2: CAC QT (DL) and AVE (UL) algorithm operates on new ALC parameters.

• DCCH over HSPA SRBs are used as accompanying AAL2 C-plane.

IP/Eth Dimensioning:

• Dimensioning Option 1: Offered Traffic provided to MD Erlang is affected by the lack of HS-DSCH DL Soft Handover.

• Dimensioning Option 1 and 2: CAC AVE80 calculation operates on increased IP Traffic Descriptors resulting in increased output.

• DCCH over HSPA SRBs are used as accompanying AAL2 C-plane.

Meaningful configuration impact of CS voice over HSPA should be expected due to increased CID/UDP ports demand. AMR/HSPA call occupies 4 CIDs/UDP ports (AMR/HSDPA, AMR/HSUPA, SRB/HSDPA, SRB/HSUPA) comparing to 2 CID /UDP ports reserved for AMR/DCH call (DTCH and DCCH). Mentioned increase impacts especially the ATM transport, where the expected CID demand directly impacts required number of VCCs, potentially causing heavy increase in blocking ratio of AMR calls.

6.2.7.3 Configuration and traffic mapping aspectsCS voice over HSPA is activated on cell level using HSPAQoSEnabled parameter (depends on the license availability).

In RAN1449: Dual Iub, CS voice over HSPA calls are always established over the ATM path.

QoS Priority and VCC selection in ATM TransportThe VCC and QoS priority (AAL2 priority) selection for AMR/HSPA and corresponding DCCH/HSPA connection depends on the Iub VCC configuration, RAN759: Path Selec-tion, and RAN1253: Iub Transport QoS features availability.

Feature availability AAL2 queue VCC selection

RAN759 not activatedRAN1253 not activated

Highest priority queue (same as AMR/DCH)

Same VCC as AMD/DCH

RAN759 activatedRAN1253 not activated

Highest priority queue HSPA/HSDPA/HSUPA Strin-gent

RAN759 activatedRAN1253 activated

According to AAL2 queue assigned to SPI

Defined in RNC/TQM/QosPriToAAL2PT

According to AAL2PT assigned to SPI

Defined in RNC/TQM/QosPriToAAL2PT

Table 94 CS voice over HSPA – QoS Priority and VCC selection in ATM Transport

248 DN70118376Issue 04E


Id:0900d80580736fc8

QoS Priority in IP TransportThe QoS priority (DSCP) selection for AMR/HSPA connection depends on RAN1253: Iub Transport QoS feature availability.

6.2.8 Hybrid transport and Iub dimensioning In Hybrid BTS backhaul operating mode Iub traffic is carried over two separate net-works: ATM over TDM network (ATM based network) and ATM over Packet switched network (PSN). In this mode HSDPA and HSUPA user data and control frames are sup-ported by the Pseudowire Emulation service and R99 Iub traffic is transmitted over the TDM network (according to existing RAS06 transport solution). Synchronization should also be provided by the TDM network. In order to separate HSDPA and HSUPA traffic from other user plane traffic, RAN05.1 Route Selection feature or the RAS06 Path Selection feature are needed.

The hybrid transport dimensioning in ATM layer is similar to other user plane traffic dimensioning, but for the Ethernet layer the overheads caused by Pseudowire Emula-tion (PWE) need to be taken into account. The protocol stack for hybrid transport is pre-sented in Figure Protocol stack for hybrid transport over Iub.

Figure 99 Protocol stack for hybrid transport over Iub

The overhead calculation can be based on following header sizes per Ethernet frame:

• control word (optional) 4 bytes • PW header 4 bytes • IPv4 header 20 bytes • Ethernet Mac header 14 bytes + optional VLAN ID 4 bytes • Interframe gap, Preamble and FCS, total 24 bytes

This leads to 70 bytes overhead per Ethernet frame, if the optional VLAN ID and control word are used. The efficiency of hybrid transport depends on how many ATM cells are concatenated to a single frame, which is defined by parameters 'concatenation factor'

Feature availability AAL2 queue

RAN1253 not activated Same as RT DCH

Defined in RNC/WBTS/RTDCHToDSCP

RAN1253 activated According to DSCP assigned to SPI

Defined in RNC/TQM/QosPriToDSCP

Table 95 CS voice over HSPA – QoS Priority selection in IP Transport

RNC

ATM

Control word

PW header (MPLS)

IPv4

Ethernet-Mac

Ethernet-Phy

Upper layerprotocols

ATM

PWE GW BTS

Upper layerprotocols

ATM

Control word

PW header (MPLS)

IPv4

Ethernet-Mac

Ethernet-Phy

Air interface

DN70118376Issue 04E

249


Id:0900d80580736fc8

and 'packetization timer'. Concatenation factor is the maximum number of ATM cells that are allowed to a single frame and packetization timer is the maximum delay that can be used to fill up the frame. When the maximum amount of ATM cells per packet has been reached (according to ‘concatenation factor’ settings), the packet should be scheduled for forwarding regardless of the status of the “packetization timer”.

The following formula should be used to calculate the Ethernet bandwidth:

(i) Ethernet_Bandwidth = Packet_size * Packet_rate

Where:

Packet_size [bit]= (Cells_per_packet * 52 + PWE_Header)*8

Packet rate = PCRVP/VC / Cells_per_packet

and:

PCRVC/VP is the sum of VC peak rate assigned to given pseudo wire (PW).

Since single IP tunnel between BTS and RNC PWE gateway may consist of number of pseudo wires thus overall Ethernet bandwidth is the sum of the bandwidth required for each single PW.

Table Example calculation for hybrid transport overheads on top of ATM layer gives examples of the capacity needed in Ethernet layer if parameter 'concatenation factor is given value 28, and 'packetization timer' is given value 5 ms.

Only one tunnel is required to connect BTS PWE GW and RNC PWE GW and each BTS may configure up to 6 PWs in total.

To map VCC into PWs N-to-one mode mod is supported where one or more ATM VCC or ATM VPC are encapsulated into one Pseudo Wire (PW). Having for each VPC more VCCs of the same type (for example, HSDPA), all the VCCs with the same type of traffic have to be multiplexed into same PW. For the scenarios when HSDPA VCCs and the HSUPA VCCs are encapsulated in different PW it is possible to apply different handling of traffic in uplink and downlink direction (that is to provide prioritization for control frames over user traffic). This is mainly relevant provided that both types of channels are strongly asymmetric.

Note that when sharing PWs, only VCCs of the same ATM service category must be allowed configured into single PW.

With hybrid backhaul solution it is possible to create two VCC bundles: one for ATM transmission path and second for Ethernet transmission path.

ATM capacity[cps]

ATM capacity[Mbps]

Ethernet capacity[Mbps]

Hybrid transport overhead [%]

4720 2.0 2.16 8.0

9430 4.0 4.2 5.0

37740 16 16.5 3.1

Table 96 Example calculation for hybrid transport overheads on top of ATM layer

Cells_per_packet PCRVC/VP MIN(timerpk× ncells 1–( ) PCRVC/VP( )⁄,( ) 1+[ ]=

250 DN70118376Issue 04E


Id:0900d80580736fc8

6.2.9 Iub Transport FallbackApplying Hybrid transport configuration on Iub interface the operator is able to separate delay sensitive CS traffic from bandwidth demanding HSPA data and simultaneously employ lower cost PSN transmission for NRT DCH or HSPA connections. It is expected also that such IP/Ethernet based transmission is offering lower reliability than ATM/SDH transport network, especially when considering low quality last mile technologies like xDSL.

Introduced in RU20, RAN1578: HSPA Transport Fallback feature provides protection mechanism of the Iub transport for HSDPA/HSUPA (and potentially for NRT DCH) calls by using the ATM/TDM path as a backup in the case where the PSN transmission path fails.

Basic function of RAN1578: HSPA Transport Fallback, called also IP to ATM fallback scenario, provides a protection mechanism for HSDPA, HSUPA and NRT DCH user traffic in hybrid Iub configurations, where HSDPA/HSUPA (and optionally also NRT DCH) traffic is carried over PSN network while other RT traffic is carried over ATM/TDM. Hybrid Iub configuration in this context relates to the usage of either Hybrid BTS Backhaul transmission with emulated IP via PWE function or Dual Iub for Flexi-BTS/UltraBTS with native IP transmission.

Figure Dual Iub configuration for BTS shows simple hybrid network scenario (Dual Iub for BTS) with two different transmission paths between BTS and RNC, where:

• CCH, RT DCH, CS over HSPA, signaling and O&M data assumed to be carried over ATM/TDM network (ATM Iub)

• and HSPA (and optionally also NRT DCH) carried over IP/Ethernet (PSN) network (IP Iub)

Figure 100 Dual Iub configuration for BTS

In the case where RNC detects fault in native or emulated IP transport, the protection ATM Iub path is used to carry the traffic classes configured previously over IP Iub trans-port. Notice that even the feature is intended to protect against malfunctions of low reliable last mile xDSL lines, the system moves traffic to the working ATM path, also after the defects in other parts of the IP transmission path between RNC and BTS. For more information about the feature, see respective feature area description.

ATM(TDM Network)

PocketNetwork

STM-1/ OC3

Ethernet

E1/T1

RNC

3G BTS

DSLModem

xDSL

DSLAM

DN70118376Issue 04E

251


Id:0900d80580736fc8

6.2.9.1 Iub Fallback VCC configuration and dimensioningThe main asset of HSPA transport fallback feature is the enhanced service availability for HSPA (NRT DCH) traffic. This high reliable transport solution is reached through:

• selection of traffic classes intended for protection • correct pre-configuration of fallback (backup) VCCs over ATM network • proper dimensioning of fallback VCC - extra bandwidth potentially required on ATM

Iub interface to protect the data of the failed IP path

The selection of the traffic classes intended to be saved in HSPA fallback scenario is operator configurable. Basic traffic classes that can be protected are: NRT DCH, RT HSPA and NRT HSPA. Additionally, enabling of RAN1253: Iub Transport QoS feature, the classification is extended towards higher traffic class granularity taking into account SPI values for HSPA traffic (that is FallbackForHSPAQoSPriXX) and QoS for DCH traffic (that is FallbackForDCHQoSPriXX). For proper VCC selection in hybrid BTS backhaul scenario, a newly introduced AAL2 Fallback VCC attribute is required to dis-tinguish between VCCs intended to be used for protection and default Iub/ATM VCCs.

Note that traffic classes, originally configured over IP network, which are not part of the protected traffic, are not established by the RNC towards the considered BTS as long as IP link is failed.

Configured VCCs used as a fallback can be dedicated for the traffic moved to ATM path in case it fails or same VCC can be used both as default VCC for DCH traffic and as fallback VCC for HSPA data after IP network outage. Thus, two types of fallback VCCs can be distinguished as follows:

• Shared fallback VCC, which is applicable in particular for traffic types with similar QoS requirements. Moreover, enabling RAN1253 feature, the fallback traffic could be additionally configured with low AAL2 queue priority to preserve suitable QoS for original traffic.

• Dedicated fallback VCC, where fallback VCCs are not operational in “normal” network conditions but is used only in case the default IP path is faulty.

Note that combination of both shared and dedicated VCCs on single Iub interface is also possible. For hybrid BTS backhaul scenario, the AAL2 Fallback attribute is used to indicate whether the given AAL2 VCC should be used as fallback VCC for HSPA (NRT DCH) traffic when default Iub/ATM VCC is not available.

For Dual Iub scenario (native IP transport at RNC side), the usage of fallback VCC label is not recommended because the RNC establishes over ATM only new transport bearers that are configured to be protected.

In order to provide efficient bandwidth for the ATM network after the IP path failure, one need to consider both the traffic classes intended for protection and corresponding fallback VCC combinations. In this context, the operator should take into account several possibilities how to dimension the Iub interface capacity:

• Consider extra capacity on ATM Iub to protect complete traffic intended to run over IP network - this requires high capacity resources available on Iub.

• Assume that no additional bandwidth is reserved on ATM Iub for moved HSPA traffic, simultaneously accepting temporally service degradation over the ATM path during failure period.

• As a third alternative, enough spare capacity on ATM path can be ensured for high revenue data services only, whereas low revenue services can suffer after packet network outage due to the lack of network resources.

252 DN70118376Issue 04E


Id:0900d80580736fc8

In the first case, to calculate capacity of the fallback VCCs, same dimensioning methods as described in section ATM-based Iub dimensioning can be applied. Configuring the shared fallback VCC, the dimensioning is done when both the traffic classes configured over ATM during normal operation and traffic classes intended for protection are taken into account. In case of dedicated fallback VCC, only traffic classes selected for protec-tion need to be considered to dimension the bandwidth of pre-arranged VCC. Such approach allows for the additional traffic sent over ATM network, guaranteeing the original quality of service level for all traffic data sent after IP path failure.

The following figure presents exemplary transport fallback configuration with dedicated fallback VCC. Both RT/NRT HSPA traffic classes are intended for protection and the fallback VCC is dimensioned in a way that it carries complete HSPA traffic after packet network unavailability. For better clarification only the user plane VCCs are presented. Note that for the fallback VCC dimensioning, it is advised to not consider HSPA peak rate requirements.

Figure 101 VCC configuration of hybrid Iub with dedicated fallback VCC

Within the mentioned approach, the spare Iub bandwidth reserved for HSPA traffic is not used during normal operation and might be wasted. Thus, the alternative way to handle relocated IP traffic is to add extra capacity, either for high revenue services only or consider that no extra bandwidth is needed on Iub interface at all. The former case is relevant for the scenarios when failures in the network are expected very sporadically for a short period of time. In both cases, the shortage of capacity resources after the IP path failure phase can lead to the service degradation on Iub.

In the following example, two fallback VCCs are configured, having RT/NRT HSPA traffic classes intended for protection. VCC2, which is normally working for stringent bi-level DCH traffic, is used also as fallback VCC for stringent bi-level HSPA calls, originally carried over IP. Bandwidth of VCC2 is assumed to be increased to handle complete traffic after failure. VCC3 is a fallback VCC only and is suitable for HSPA tolerant traffic. In this case, UBR ATM service category is set for this fallback VCC, which means that no capacity can be guaranteed for NRT HSPA traffic. Consequently, the ATM Iub band-width is not wasted during normal operation.

BTS RNC

VCC 1 (RT DCH )

ATM Service Category: CBR

AAL2 UP Usage:DCH

AAL2 PTs:Stringent

No Fallback

VCC 2 (NRT DCH )

ATM Service Category: UBR+

AAL2 UP Usage:DCH

AAL2 PTs:Stringent bi-level

No Fallback

Hybrid scenario : VCC 4 (RT/NRT HSPA )


AAL2 UP Usage:HSPAAAL2 PTs:Stringent+Stringent bi-level+Tolerant

No Fallback

VCC 3 (RT /NRT HSPA )


AAL2 UP Usage:HSPAAAL2 PTs:Stringent+Stringent bi-level+TolerantFallback

VCC is used during standard operation for RT

DCH traffic.

RNC/BTS egress/ingress traffic: Calculateaccording to rules given in3.1 .4.

VCC is used during standard operation for NRT

DCH traffic.

RNC/BTS egress/ingress traffic: Calculate

according to rules given in3.1 .4.

Dedicated Falback VCC 3 is used after IP path

failure to allocate all HSPA traffic.


according to rules given in3.1 .4.

Dual Iub

IubTransportMediaSelection

(RT HSUPA, RT HSDPA, NRT HSUPA, NRTHSDPA)

DN70118376Issue 04E

253


Id:0900d80580736fc8

Figure 102 VCC configuration of hybrid Iub with dedicated and shared fallback VCC

Note that Conversational HSPA traffic is always mapped over ATM transport in case of Dual Iub feature and, therefore, there is no need to save these traffic types.

6.2.10 RAN1707: Flexi WCDMA Integrated CESoPSN (RU20 On Top)There are several standards describing how to encapsulate TDM frames into IP data-grams and to tunnel this traffic over packet-switched network (PSN). One of the options is described in RFC5086 Structure-Aware Time Division Multiplexed (TDM) Circuit Emu-lation Service over Packet Switched Network (CESoPSN). For tunneling TDM traffic over PSN domain, PW (pseudowire) gateways are required to terminate TDM links and encapsulate TDM frames into IP datagrams at the edges of PSN domain.

To allow tunneling TDM traffic (PDH E1/T1 links) over PSN backhaul network, pseudowire gateway is introduced to Flexi WCDMA BTS with RAN1707. The actual implementation is based on RFC5086. This functionality can be enabled in the following FTM modules equipped with both PDH (E1/T1) and Ethernet interfaces:

– FTIB (up to 4xE1/T1 for CESoPSN tunneling)– FTLB (up to 4xE1/T1 for CESoPSN tunneling)– FTFB (up to 16xE1 for CESoPSN tunneling)

RAN1707 Flexi WCDMA BTS Integrated CESoPSN feature is designed to connect legacy 2G BTS (or any other equipment using PDH E1/T1 interfaces) to PSN based backhaul network through collocated Flexi WCDMA BTS. This feature eliminates a need to install TDM equipment and to provide expensive E1/T1 links to legacy BTSs collo-cated with Flexi WCDMA BTS connected to PSN backhaul.Typical configuration using RAN1707 feature is presented in Figure Basic configuration for RAN1707 feature.

BTS RNC

VCC 1 (RT DCH + Conver . HSPA )

ATM Service Category: CBR

AAL2 UP Usage:DCH&HSPAAAL2 PTs:Stringent

No Fallback

VCC 2 (RT HSPA + Stream . HSPA )


AAL2 UP Usage:DCH&HSPAAAL2 PTs:Stringent bi-level

Fallback

Hybrid scenario : VCC 4 (RT /NRT HSPA )


AAL2 UP Usage:HSPAAAL2 PTs:Stringent bi-level+Tolerant

No Fallback

VCC 3 (NRT HSPA )

ATM Service Category: UBR

AAL2 UP Usage:HSPAAAL2 PTs:Tolerant

Fallback

VCC is used during standard operation for RT

DCH traffic.

RNC/BTS egress/ingress traffic: Calculateaccording to rules given in 3. 1 .4.

Shared fallback VCC is used during standard

operation for NRT DCH traffic and after IP pathfailure to allocate in addition RT HSPA calls .


according to rules given in 3. 1 .4.Dedicated Falback VCC 3 is used after IP path

failure to allocate RT HSPA calls.

UBR ATM service category is used to carry

NRT HSPA fallback traffic without anybandwidth guarantees.Dual Iub

IubTransportMediaSelection

(RT HSUPA, RT HSDPA, NRT HSUPA, NRTHSDPA)

254 DN70118376Issue 04E


Id:0900d80580736fc8

Figure 103 Basic configuration for RAN1707 feature

This feature introduces constant CES traffic, which is transmitted through PW tunnel between 2G BTS collocated Flexi WCDMA BTS on one side, and external PW gateway on the other side. Constant CES traffic has to be considered while dimensioning and cal-culated.

6.2.10.1 CESoPSN packet formatAccording to RFC5086, TDM frames have to be encapsulated into IP datagrams using protocol stack presented in Figure CESoPSN protocol stack.

Figure 104 CESoPSN protocol stack

UDP port number is used to distinguish different pseudowires within the same pseudowire tunnel. Each E1/T1 link is encapsulated in dedicated pseudowire.

Pseudowire tunnel is identified by IP addresses at both ends.

CESoPSN Control Word field is used for maintenance and alarm handling. Detailed structure of CESoPSN Control Word is shown in Figure CESoPSN Control Word field details.

Figure 105 CESoPSN Control Word field details

DN70118376Issue 04E

255


Id:0900d80580736fc8

– L, R, M bits are used for alarm indication.– FRG bits are cleared for most services.– LEN bits may be used to carry length of the CESoPSN packet (defined as a size of

the CESoPSN header + a payload size) if it is less than 64 bytes, and must be set to zero otherwise.

– Sequence number is used to provide the common PW sequencing function, as well as detection of lost packets.

CESoPSN packet TDM payload carries E1/T1 timeslot bytes which are specified to be transferred over PW tunnel. TDM payload format is shown in Figure CESoPSN TDM payload format.

Figure 106 CESoPSN TDM payload format

TS 1, TS 2, ..., TS N are the timeslot octets from tunneled E1/T1 frame. Up to 31 timeslots can be encapsulated per E1 frame and up to 24 timeslots per T1 frame. The operator can configure the timeslots that are tunneled. The E1/T1 timeslots specified for encapsulation do not have to be consecutive.

6.2.10.2 CESoPSN traffic bandwidth calculationBandwidth required for CESoPSN traffic stream depends on the following parameters:

L - CESoPSN payload size [bytes]

D - packetization latency [ms]

N - number of encapsulated timeslots per TDM frame

256 DN70118376Issue 04E


Id:0900d80580736fc8

M - number of TDM frames to be encapsulated in one CESoPSN packet

TDM_frame_duration - E1/T1 frame duration is constant, equal to 0,125 ms

Relation between packetization latency, number of time slots, and resulting payload for a given CESoPSN packet is described with the formula:

L = 8 * N * D

Packetization latency is given by the equation:

D = M * TDM_frame_duration

For total bandwidth calculation, the following protocol overheads have to be considered:

ETH_OH = 38 bytes (including preamble and interframe gap)

VLAN_OH = 4 bytes

IPv4_OH = 20 bytes

UDP_OH = 8 bytes

CESoPSN_Control_Word = 4 bytes

Resulting constant bandwidth consumption on IP level (without Ethernet overhead) is:

CESoPSN@IPv4_BW = (IPv4_OH + UDP_OH + CESoPSN_Control_Word + L)

*8 / D= (IPv4_OH + UDP_OH + CESoPSN_Control_Word + M * N) * 64 / M =

= (32 + M * N) * 64 / M [kbps]

By adding Ethernet overhead, we can calculate constant bandwidth consumption on Ethernet level:

CESoPSN@ETH_BW =

= (ETH_OH + IPv4_OH + UDP_OH + CESoPSN_Control_Word + L) *8 / D =

= (ETH_OH + IPv4_OH + UDP_OH + CESoPSN_Control_Word + M * N) * 64 / M =

= (70 + M * N) * 64 / M [kbps]

Additionally, if optional VLAN tag is added, constant bandwidth consumption on Ethernet level is given by the formula:

CESoPSN@ETH_BW = (ETH_OH + VLAN_OH + IPv4_OH + UDP_OH ++ CESoPSN_Control_Word + L) *8 / D = (ETH_OH + VLAN_OH + IPv4_OH ++ UDP_OH + CESoPSN_Control_Word + M * N) * 64 / M = (74 + M * N) * 64 / M [kbps]

Exemplary bandwidth consumption on Ethernet level (VLAN configured) for given number of timeslots, depending on packetization delay, is shown in Figure Packetization latency and CESoPSN bandwidth.

DN70118376Issue 04E

257


Id:0900d80580736fc8

Figure 107 Packetization latency and CESoPSN bandwidth

RAN1707 requirementsThe following requirements are valid for RAN1707. Most of the requirements come from RFC5086, but some of them are additional, valid for RAN1707 implementation only.

– Every TDM frame must consist of constant number of timeslots to be encapsulated (operator configurable).

– Every CESoPSN packet must consist of constant number of TDM frames (operator configurable).

– Up to 16 pseudowires can be configured in one PW tunnel.– Up to 1 pseudowire tunnel can be configured per Flexi WCDMA BTS.– Maximum payload for CESoPSN packet is 992 bytes (32 TDM frames with 31

timeslots in each frame, encapsulated in one CESoPSN packet).– Maximum packetization latency for CESoPSN packet is 4 ms (32 TDM frames).– It is recommended to map CESoPSN to EF (expedited forwarding) traffic class, but

it can also be mapped to any other traffic class.– It is recommended for CESoPSN traffic to use a dedicated VLAN. If not possible,

CESoPSN traffic can also share already existing VLAN.

Synchronization optionsSeveral synchronization options can be used when RAN1707 is enabled.

258 DN70118376Issue 04E


Id:0900d80580736fc8

Figure 108 Synchronization options

6.2.11 RAN1709 VLAN Traffic Differentiation (RU20 On Top)RAN1709 VLAN Traffic Differentiation feature introduces a possibility to configure up to two IP based routes per BTS and to terminate Iub traffic on different logical IP interfaces, each one within separate subnet/VLAN.

DN70118376Issue 04E

259


Id:0900d80580736fc8

This feature allows to group traffic classes within transport network according to IP address/VLAN assigned and apply different QoS policies (priorities) per each group. Furthermore, it allows to aggregate the traffic to be handled with similar SLA parameters for many BTS nodes. Also load balancing scenario (two same priority paths configured with equal load distribution between them) can be applied.

Up to 5 IP interfaces (logical VLAN interfaces) can be configured on BTS side and up to 4 IP interfaces (logical VLAN interfaces) per Iub on RNC side (ToP traffic can use ded-icated VLAN/subnet and is not terminated in the RNC).

Exemplary basic configuration using RAN1709 is shown in Figure Basic RAN1709 con-figuration for L2 backhaul with L3 RNC site router scenario. In this scenario, L2 backhaul network is assumed with L3 RNC site router assigning VLANs towards BTSs. In this case, 2 UP VLANs are configured and 3 dedicated VLANs for CP, O&M and ToP traffic respectively.

Figure 109 Basic RAN1709 configuration for L2 backhaul with L3 RNC site router scenario

Up to 4 VLANs can be configured in one IP based route between the RNC and the BTS.

– Up to 2 VLANs for User Plane traffic– Control Plane traffic (NBAP) can use a separate VLAN or existing VLAN– BTS O&M traffic can use a separate VLAN or existing VLAN– Timing over packet traffic (ToP) can use a separate VLAN at the BTS or existing

VLAN

If VLANs are not configured in the RNC or in the BTS, then the mapping of bearers to IP Destination Address, DSCP (in consequence to PHB), and p-bits needs to be sup-ported by UTRAN NEs and VLAN tagging needs to be supported by external switch/router on behalf of the RNC or the BTS (VLAN tagging is based on subnets IP addresses belong to).

260 DN70118376Issue 04E


Id:0900d80580736fc8

6.2.11.1 Traffic processingThe following traffic processing steps are applied in the RNC and the BTS respectively when RAN1709 feature is enabled.

VLAN traffic processing in the RNC:

1. Before U-plane transport bearer setup, the traffic needs to be mapped to the Ipbase-dRoute, matching BTS id and DSCP. If more than one IPbasedRoute fits these cri-teria, a load sharing (round robin) decision is taken. The RNC determines its local IP address to be used for the specific bearer and sends this IP address to the BTS through NBAP.The BTS then selects a corresponding local IP address, which allows the usage of the same VLAN associated with the RNC IP address, and returns its local IP address to the RNC via NBAP.All traffic belonging to a certain U-plane bearer is “marked” with the proper BTS des-tination IP address, the RNC source IP address, and the DSCP.

2. All traffic going to the same IPbasedRoute is shaped (rate limited) to the IPbase-dRoute bandwidth in IFC virtual scheduler/shaper, where the IPbasedRoute is iden-tified by one or several source IP addresses.

3. U-plane traffic is forwarded to PHB queue at physical port level which corresponds to the DSCP.C-plane and M-plane traffic is forwarded directly to the same set of PHB queues at physical port level, without IPbasedRoute level shaping.Scheduling and shaping at the physical port level is unchanged, compared to RU10. VLAN tagging of the egress traffic is performed based on the destination IP address (and the related routing information).

DN70118376Issue 04E

261


Id:0900d80580736fc8

Figure 110 RAN1709 RNC traffic management

VLAN traffic processing in the BTS:

1. BTS traffic classification is performed:– Bearer to DSCP (in consequence also to PHB), p-bits (if tagging enabled), traffic

priority configurable mapping– CAC check at bearer setup– Bearer's IP address (subnet), assigned basing on the RNC local IP address

signaled by the RNC in NBAP message, defines VLAN to be used.2. All traffic is queued in the VLAN schedulers. Per VLAN shaping is also performed

here.3. WFQ scheduler is used as the physical interface scheduler, combining the traffic of

several VLANs. Corresponding weights (W1-W5) are derived from the VLAN CIR values (Wx=10*CIRx). If for a given UP VLAN CIR=0 is configured, meaning that only non-CAC guaranteed BE UP traffic is mapped to this VLAN, a corresponding weight value in the interface WFQ scheduler is set to 1.

262 DN70118376Issue 04E


Id:0900d80580736fc8

Figure 111 RAN1709 BTS traffic management

Shaping in the BTS can be applied:

– per IP interface level to IP interface SIR (SIR=CIR+EIR) and SBS (Shaper Burst Size) parameters

– per VLAN to VLAN specific SIR and SBS parameters

VLAN shaping can be enabled or disabled per VLAN. If VLAN shaping is enabled for any VLAN within the IP based route, then CAC should be done at VLAN level, otherwise the BTS should perform CAC at the IP based route level. Note, that in RNC shaping could be done only per IP based route.

6.2.11.2 User plane VLAN mapping optionsUP traffic classes assignment to UP VLANs is based on UP bearer to DSCP and then DSCP to PHB mappings. For each UP VLAN, a PHB class is assigned to be carried within this VLAN, except for load sharing case, where both UP VLANs carry traffic belonging to all PHB classes.

UP bearers sharing the same PHB class can only be mapped to the same UP VLAN.

Even if DSCP to PHB mapping is different on the RNC and the BTS side, UP VLAN assignment is based on the RNC configuration (the RNC sends its local IP address through NBAP and basing on this the BTS assigns its local IP address and VLAN accordingly).

6.2.11.3 Feature related parametersThe following parameters can be configured:

DN70118376Issue 04E

263


Id:0900d80580736fc8

– In RNC (per BTS, for each VLAN instance)– related IP subnet– related IPbasedRoute– VLAN tagging enabled/disabled

– In BTS (for each VLAN instance)– related IP subnet– VLAN tagging enabled/disabled– CIR (committed information rate) - average rate up to which traffic is delivered

by one VLAN. It defines the guaranteed transport capacity for the VLAN– SIR (shaper information rate), SIR=CIR+EIR– VLAN shaper burst size (SBS) - maximum burst size applied by the shaper

6.2.11.4 Dimensioning aspectsThe same general dimensioning methods as presented in section IP-based Iub dimen-sioning should be applied when using RAN1709 feature. Since UP traffic to UP VLAN mapping is PHB based, dimensioning should be done per PHB class. For each VLAN, aggregated values for CAC-guaranteed and/or non CAC-guaranteed traffic (depending on bearers assigned to relevant PHB classes) have to be computed.

To apply CIR and SIR parameters per VLAN, a relevant aggregated CAC-guaranteed (for CIR) and non CAC-guaranteed (for EIR) values can be used. SIR is then calculated as CIR+EIR. Note, that both CIR and SIR parameters are given on Ethernet level (so CAC-guaranteed and non CAC-guaranteed values should include Ethernet overhead).

It is possible on BTS side to shape egress (UL) traffic per VLAN. VLAN shaping is applied to the configured SIR value. It is recommended to apply per VLAN shaping in case traffic is routed via different paths (each VLAN should be shaped to SIR value, according to dimensioning calculation), in other cases (same path for all traffic) per IP based Route shaping only should be applied

6.2.11.5 Dimensioning exampleAll traffic mappings and bandwidth calculations are presented for exemplary purposes (these are not Nokia Siemens Networks recommendations). Presented example is applicable mainly for BTS side (where CIR, SIR parameters are required).

1. The following bearers/services to PHB classes mapping is assumed (RAN1253 not enabled):ToP -> EFC-Plane -> AF4O&M -> AF1

RT_DCH -> EFNRT_DCH -> AF4RT_HSPA -> AF4NRT_HSPA -> BE

2. The following PHB classes to VLANs mapping is assumed:UP VLAN 1: EF, AF4, AF3, AF2UP VLAN 2: BEVLAN 3: ToP, C-Plane, O&M

264 DN70118376Issue 04E


Id:0900d80580736fc8

3. Basing on dimensioning rules presented in chapter IP-based Iub dimensioning, the following bandwidth estimations per PHB class are calculated (all values on Ethernet level):ToP_BW = 15 kbpsC-Plane_BW = 150 kbpsO&M_BW = 100 kbps

RT_U-Plane_committed_BWEF = 300 kbpsRT_U-Plane_committed_BWAF4 = 200 kbpsNRT_U-Plane_committed_BWAF4 = 500 kbpsBE_HSPA_BW = 1500 kbps

4. Bandwidth demand per VLAN, according to mapping assumed in (3): UP_VLAN_1_CIR = 300 + 200 + 500 = 1000 kbpsUP_VLAN_1_EIR = 0 kbpsUP_VLAN_1_SIR = 1000 + 0 = 1000 kbps

UP_VLAN_2_CIR = 0 kbpsUP_VLAN_2_EIR = 1500 kbpsUP_VLAN_2_SIR = 0 + 1500 = 1500 kbps

VLAN_3_CIR = 15 + 150 + 100 = 265 kbpsVLAN_3_EIR = 0 kbpsVLAN_3_SIR = 265 + 0 = 265 kbps

6.2.12 Physical interface capacity The following table presents the Iub physical interface types. Cell rate means the avail-able VCC size of the interface expressed as ATM cells/second. With n*E1, n* VC-12, and n*JT1, the Inverse Multiplexing ATM (IMA) parameter has an effect on the transfer bit rates. The cell rates correspond to the default IMA parameter value 128.

Iub interface type Nominal bit rateMbit/s

Transfer bit rateMbit/s

Cell rate cps

JT1, T1 1.544 1.536 3622

E1, ATM VC 2.048 1.920 4528

n*JT1, n*T1 n*1,544 n*1,487274 n*3592

n * E1 IMA, ATM VC n*2,048 n*1,904070 n*4490

STM1, ATM VC4, OC3

155.52 149.76 353207

STM1, ATM n*VC12 155.52 n*1.920 n*4528

STM1, ATM n*VC12 IMA

155.52 n*1.904070 n* 4490

Fast Ethernet 100 100 -

Gigabit Ethernet 1000 1000 -

Table 97 Iub interface types

DN70118376Issue 04E

265


Id:0900d80580712f79

6.3 Dimensioning Iur interface

6.3.1 Iur dimensioning method for user planeIur traffic amounts between RNCs depend on the network configuration and topology. Typically, Iur traffic amounts can be in the range of 4 – 9% of Iu traffic, but the actual values should be checked according to the radio network plan. The recommendation is applied to the total Iu bandwidth demand obtained with the Iu dimensioning rules, as described in the next chapters.

Iur traffic demand calculation additionally takes into account the number of neighbour-hoods. The resulting bandwidth is split among available relations.

6.3.2 HSPA traffic on IurPrior to RU20, Inter-RNC HSPA Mobility was handled using fallback to DCH (Re99) also called HSPA Outward Mobility (Channel Type Switching E-DCH/HS-DSCH to DCH/DCH).

RU20 RAN1231 feature brings in support for E-DCH/HS-DSCH Serving Cell Change over Iur, after which HSUPA and HSDPA data is transmitted over Iur.

Current assumption is that the impact of HSPA over Iur feature into overall Iur traffic demand does not change significantly as compared with the previous releases. HSPA UEs traffic demand was already realized over Iur prior to RU20, although mapped to R99 bearers after Outward Mobility switch mentioned above. The only potential impact is expected from the increased peak rate demand perspective, which on the other hand, is seen as limited at cell edge drift handover area.

As a summary, it is proposed to maintain 4 – 9 % recommendation also in the context of HSPA over Iur feature. It is proposed to use the additional cross check against the expected HSPA peak rate demand over Iur, which is set up on the basis of requirements given by the customer.

The following figure gives an overview on the proposed Iur bandwidth demand estima-tion in RU20.

266 DN70118376Issue 04E


Id:0900d80580712f79

Figure 112 Iur bandwidth demand

6.3.3 IP-based Iur Transport Network Layer configuration

6.3.3.1 IP Iur Protocol Stack and Protocol OverheadsThe same protocol stack and Transport Channel format applies as on IP-based Iub. This implies the same traffic descriptor values and Ethernet overhead as for Iub.

6.3.3.2 Mapping U-plane and C-plane Logical Channels to IP/Ethernet flowsAt Layer 3 a logical instance of the Iu-x interface is referred to as an IP based route. It is possible to support 32 IP based routes for Iur interface per RNC, but only one IP based Iur route between two RNCs. There are two separate addresses per IP based route, one for the U-plane and one for the C-plane traffic. It is recommended to use different IP addresses for different Iur.

Within an IP based route UMTS transport bearers are identified by UDP/SCTP ports (at Layer 4).

Possible options of VLAN assignment are the same as for Iub. In particular a VLAN per logical Iur or per Eth interface can be assigned. No VLAN can also be used.

Each IP port at RNC can support Iur together with Iu-PS or Iu-CS interfaces. This allows the Iur to be realized together with Iu-PS and or Iu-CS over the same transport link(s).

6.3.3.3 IP Transport QoS on IurIP DiffServ on Iur can be configured to the same extent as on Iub. The actual UMTS class to PHB mapping should comply with the configuration on Iub.

Max

Iur percentagerecommendation

Iur specificHSPA overhead

Iur HSPA PeakRate demand

Resulting IurTraffic Demand

Iur C-Plane

DN70118376Issue 04E

267


Id:0900d805806487e5

6.4 Dimensioning Iu-CS interface

6.4.1 Iu-CS dimensioning method for user planeFor the purpose of Iu-CS dimensioning, similar method as described in Iub is proposed (Iub dimensioning methods for user plane), adapted to the specifics of the Iu interface.

Figure 113 Iu-CS dimensioning

In ATM transport, CAC algorithm implemented on Iu-CS is similar to Iub, however, a dif-ferent set of ALC parameters is used as an input.

The following steps are needed in Iu-CS dimensioning:

1. Calculate the input parameters to MD-Erlang algorithm:Bandwidth MD-Erlang = MD-Erlang [ Offered traffic, Gross PeakRate, Blocking per-centage; …] • Total offered traffic per RAB/service (no SHO considered on Iu-CS)

Total_offered_trafficservice =# subscribers_perRNC·offered_traffic_perSubscriber

• Gross peak rate per RAB/service (considering Iu-CS related protocol over-heads; no DCCH traffic exists on Iu-CS)Gross_peak_rateservice = Peak_rateservice·DCHactivity·OHservice,Iu-CS

• Assumption on the blocking probabilityFor the voice service feasible blocking values are between 0.01% and 0.1%. Nevertheless, the requirements need to be aligned with the operator.

2. Weight the MD-Erlang resulting bandwidth, in order to achieve bandwidth portion related to each service (similar weighting over mean rates as described in Iub part).

3. Calculate the number of parallel connections per RAB/service, taking into account weighted bandwidth portion and gross peak rate (similar algorithm as described in Iub).

4. Calculate CAC algorithm.

NOTE: When configuring AAL2 U-Plane UBR+ VCCs, the limitation of 124 KCPS PCR should be obeyed (valid only in case of A2SU hardware).

6.4.2 Dimensioning IP-based Iu-CSIu-CS groups the CS traffic from RNC towards MGW.

R99 Bandwidthdemand

(cps or kbps)

Weightingover RABmean rate

MD-Erlang

CACalgorithm

Weighting and Rounding rules

Bandwidthdemand

Input parameters:- Total Erlangs per RAB- Peak Rate per RAB(incl. Iu-CS specific OH)

- Activity- Blocking probability

268 DN70118376Issue 04E


Id:0900d805806487e5

The calculation method is the same as in Iub RT U-plane traffic (Dimensioning the CAC-guaranteed U-plane RT traffic), which is MD-Erlang:

Iu-CS_BW PHB = MD-Erlang [Gross_peak_rate RAB 1, Off_traffic RAB 1, Bl_Pr RAB 1 ; … ; Gross_peak_rate RAB n, Off_traffic RAB n, Bl_Pr RAB n]

where:

• Gross peak rate RAB is a sum of CAC-guaranteed bit rates for RT RABs:Gross peak rate RAB = CAC_Guaranteed_BW RAB

• Offered_traffic RAB is the mean traffic per RAB per RNC in [erlang] (w/o SHO_factor) • Bl_Pr RAB is the service blocking probability. Usually assumed values are 0.1% –

1%.

Note that due to a different data structure on Iu-CS, CAC traffic descriptors and Ethernet OHs on Iu-CS are different that the ones on Iub.

DN70118376Issue 04E

269


Id:0900d80580713365

6.5 Dimensioning Iu-PS interface

6.5.1 Iu-PS dimensioning method for user planeTo get the amount of bandwidth for the packet switched traffic needed on Iu-PS for PS NRT RABs, weighted M/G/R-PS approach is used. For the PS RT traffic MD-Erlang B formula is used.

The following input parameters are required for the weighted M/G/R-PS:

1. Mean_data_rateFor the Mean data rate the sum over all used services is calculated:

Mean data rate per service concerns the traffic rate on IuPS interface and need to be increased by service specific OH factor.

2. Peak_rateWeighted peak rate has to be calculated considering all services as follows:

ŕ - weighted peak rate for all servicesrpeak¡ - Peak rate for the corresponding service (including OH)rmean¡ - Mean data rate of the corresponding service (incl. OH)rmean - Sum of all mean data

For next parameter File Size and Max. Mean Transfer Time the following weighting factor is needed:

3. File size

where:Gross_File_sizeBackground.Interactive_service = Netto_File_sizeB / I service * OH_factorB / I

service

4. Max Mean Transfer Time

Mean_data_rateweighted Mean_data_rateservice i i∑=

r̂rmeanrmeanirpeak i

---------------i∑----------------------=

rmean rmeanii∑=

Weighting_factorirmeani

rmeanjj∑----------------------=

Gross_File_Sizeweighted Weighting_factori Gross_File_sizei⋅i∑=

Max_Mean_Transfer_Timeweighted

Weighting_factori Max_Mean_Transfer_Timei⋅i∑

=

270 DN70118376Issue 04E


Id:0900d80580713365

For dimensioning HSDPA/HSUPA services on Iu-PS interface the application of weighted M/G/R-PS algorithm traffic is proposed as for the PS traffic. For the QoS requirements (delay and file size) the same input values as used for PS applications via R99 (for example, Web access, FTP, etc.) have to be applied. The calculation input values for the peak rate should base on the UE max data rates.In case of MD-Erlang, used for streaming/conversational PS RABs, the following set of parameters is needed per each related RAB/service: • Total offered traffic per RAB/service

Total offered trafficservice =#subscribes · offered traffic perSubscriber • Gross peak rate per RAB/service (considering Iu-PS related protocol overhead

and relevant activity factor; no DCCH traffic exists on Iu-PS)Gross peak rateservice =Peak rateservice · OHservice Iu-PS · activity factorservice

• Assumption on the blocking probabilityAt the end, bandwidth demand for PS NRT and PS RT services is summed up.

6.5.2 Iu-PS overhead calculation in ATM transportTransmission of the IP user packets over the Iu-PS interface is based on the GTP tun-nelling mechanism. Each PS RAB is carried over a single GTP tunnel and uniquely iden-tified by pair of source and destination GTP-U Tunnel Endpoint Identifiers (TEID) and by the pair of source and destination IP addresses. Tunnelled IP user packets are then transmitted over the ATM network using classical IP over ATM protocol mechanism. Employed the LLC/SNAP encapsulation concept allows IP protocol to be carried across a single ATM connection. The LLC/SNAP encapsulated IP packets identified by a standard 8 bytes LLC/SNAP header are transmitted in ATM cells using the AAL5 adap-tation layer (which adds extra 8 header bytes and 0-47 bytes of padding).

Figure 114 Classical IP over ATM

The header length for the transmission of IP user packets over ATM (classical IP over ATM) is summarized in Table Header length for Iu-PS data (IP over ATM).

Protocol header Header length (bytes)

GTP-U header max. 12

UDP header 8

IP header 20

Table 98 Header length for Iu-PS data (IP over ATM)

IP User Packet

ATM Cells

AAL5Encapsulation

IP User DataIP

ATMheader

ATM cell informationATM

headerATM cell information

AAL5 LLC/SNAP IP UDP GTP-U IP User Packet

8B+PAD 8B 20B 8B 12B

5B 48B 5B 48B

DN70118376Issue 04E

271


Id:0900d80580713365

The overhead for different packet sizes depends on the size of the PAD (AAL5 padding) field and the IP user packet length. The overhead can be calculated with the following formula:

For dimensioning purposes it is recommended to use the numerically stable approxima-tion (right site of equation above) that uses an average 27 bytes overhead for the last ATM cell. This means that for each packet data 27 bytes of AAL5 padding is assumed.

Figure Approximation curve for Iu-PS overhead factor presents the approximation curve for IuPS overhead factor for PS data for the packet size in the range of 50 to 1500 bytes. Assuming average packet sizes of 500 Bytes (DL) these results with an overhead factor of 1.27. With an average of 100 Byte (UL) the overhead calculation leads to an overhead factor of 2.12.

Figure 115 Approximation curve for Iu-PS overhead factor

LLC/SNAP encapsulation 8

AAL5 trailer 8

AAL5 padding 0-47 (default 27)

ATM header 5

Total 88

Protocol header Header length (bytes)

Table 98 Header length for Iu-PS data (IP over ATM) (Cont.)

OH_factor(IuPS)

n 8 8 40+ + +48

----------------------------------- 53⋅

n----------------------------------------------------=

5348------ 1 8 8 40 27+ + +

n---------------------------------------+⎝ ⎠

⎛ ⎞⋅≈

2.2

1

2

1.9

1.8

1.7

1.6

1.5

1.4

1.3

1.2

1.1

2.1

0 1500100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400

IuPSoverhead factor

Approximation curve for IuPS overhead factor

IP user packet size in bytes

Total overhead including ATM/AAL5/IP/UDP/GTP-U

Approximation with 27 bytes of AAL5 padding

272 DN70118376Issue 04E


Id:0900d80580713365

6.5.3 Dimensioning IP-based Iu-PSIu-PS groups R99 PS and HSPA traffic from RNC towards 3G-SGSN.

The calculation method depends on the supported traffic types and mixes:

• Streaming HSPA should be dimensioned as RT CS (that is with MD-Erlang, cf., see Dimensioning the CAC-guaranteed U-plane RT traffic).

• Rel99 PS + I/B HSPA should be dimensioned using one of the options for dimen-sioning NRT U-plane traffic on Iub (Dimensioning the CAC-guaranteed U-plane NRT traffic): • with parallel connections with IP CAC traffic descriptors • with M/G/R-PS

• If there is a large share of PS Streaming, it should be dimensioned as RT CS (that is with MD-Erlang).

Iu-PS transmission overhead depends on the packet size that has to be transmitted from RNC to 3G-SGSN. Subscriber data packet can vary from 64 Bytes to 64 kBytes. There-fore IP traffic descriptors and Eth overhead vary depending on the data packet size). A possible option is to assume an average packet size of 512 bytes.

DN70118376Issue 04E

273


Id:0900d805806487e1

6.6 Dimensioning Iu-BC interfaceIu-BC interface recommendation is 64 kbps for each Iu-BC link between the Cell Broad-cast Centre and the RNC.

274 DN70118376Issue 04E


Id:0900d80580785f2e

6.7 Dimensioning signaling traffic

6.7.1 Iub signaling linksNote that the presented dimensioning recommendation is based on the Nokia Siemens Networks internal assumptions on traffic mixes and analysis of real network behavior on the basis of PM counters results. The traffic in operating networks can have different characteristics causing different signaling loads.

From control plane point of view the following protocols appear on the Iub interface:

Common NBAP (CNBAP)It is used for all procedures that are not related to specific UE context that already exists in BTS.

The main CNBAP functions are:

– setting up the first radio link of a user equipment and selecting the traffic termination point

– configuring cells– common transport channels' management (set up and parametrization of RACH,

FACH and PCH)– initializing and reporting cell or BTS specific measurements– reporting of general NBAP-related error situations– handling HS-DSCH-related resources– handling E-DCH-related resources

The main loading components of the CNBAP links are:

– radio link setup requests/responses– common measurement initiation/reports (3GPP COMMON MEASUREMENT

REPORT or PRIVATE Radio Resource Indication messages)

Therefore, the CNBAP bandwidth requirement depends on the call setup and radio link addition (soft handover) numbers, as well as common measurements reporting periods.

Dedicated NBAP (DNBAP)After first radio link setup performed by C-NBAP, every subsequent signaling, related to the UE, is exchanged with dedicated NBAP (D-NBAP) procedures.

The main DNBAP functions are:

– adding, releasing, and reconfiguring radio links– handling dedicated channels– initializing radio link specific measurements– reporting radio link specific measurements– handling softer combining– managing radio link faults– handling HS-DSCH related resources– handling E-DCH related resources

The main loading components of the DNBAP links are:

– radio link reconfiguration procedures– radio link deletion procedures– radio link addition procedures (related to softer handovers)

DN70118376Issue 04E

275


Id:0900d80580785f2e

– dedicated measurement initiation messages– dedicated measurement reports

Therefore, the DNBAP capacity requirement depends, for example, on the number of calls, call lengths, number of softer handovers, as well as dedicated measurements reporting periods.

ALCAP (AAL2SIG)In the transport network control plane, Q.2630.1 signaling is used for the dynamic man-agement of the AAL2 connections, in particular:

– establishment– release– maintenance (for example transport bearer modification)

The main loading components of the ALCAP links are:

– establish request/confirm (ERQ/ECF)– release request/confirm (REL/RLC)

ALCAP is not used in IP transport option.

During normal operation, the signaling link load should not exceed 80%.

In general, Iub signaling depends on the number of subscribers served by a certain BTS, its configuration (number of cells, common and dedicated measurement reporting peri-ods), and the intensity of signaling-related traffic model generated by one subscriber, for example:

– BHCA (for CS, PS and HSPA calls, SMSs), influencing the number of call set-ups/releases

– call durations, influencing the amount of dedicated measurement reports,– amount of handovers, channel type switches,– amount of serving HSPA cell changes (for HSPA calls),– amount of location/routing area updates,– Non-C-plane related traffic (for example SSCOP POLL-STAT mechanism in ATM

transport and SCTP Heartbeat messages in IP transport).

a) Iub signaling link dimensioning recommendations (ATM Transport)The estimated signaling bandwidth requirement for Iub is that 4% of the Iub U-plane capacity calculated without HSPA peak rate consideration has to be reserved for CNBAP, DNBAP and AAL2SIG signaling. For the methodology of calculating U-plane capacity without HSPA peak rate consideration in ATM transport, see Figure Iub band-width demand. Left portion of U-plane bandwidth shows value against which new per-centage rule is applied in the dimensioning process. According to the current dimensioning rules, this portion corresponds to the sum: PCR of CBR U-plane VCCs + MDCR of UBR+ U-plane VCCs.

For Iub U-plane capacity less that 1 Mbps, C-plane requirements should be increased to 6%.

The signaling bandwidth should be divided into the signaling links according to the fol-lowing ratio: CNBAP (25%), DNBAP (50%) and AAL2SIG (25%).

For UBR+ C-plane the recommendation might be lowered by 25% (basic recommenda-tion: 3%; for U-plane capacity less than 1Mbps: 4.5%).

276 DN70118376Issue 04E


Id:0900d80580785f2e

With multiple WAM sites, the DNBAP bandwidth is divided according to the WSP unit capacities configured behind each WAM.

Without advanced AAL2 multiplexing (AXUA) and multiple WAM sites, the AAL2SIG bandwidth is divided according to the wideband signaling process (WSP) unit capacities configured behind each WAM. The minimum link size for the CNBAP, DNBAP, and AAL2SIG is 39 cps. The maximum size is 2100 cps per WAM. C-plane bandwidth obtained by using mentioned rule is used to configure PCR of CBR C-plane VCCs or MDCR of C-plane UBR+ VCCs and to calculate total ATM bandwidth demand per BTS.

b) Iub signaling link dimensioning recommendations (IP transport)The estimated Ethernet/IP signaling bandwidth requirement for Iub is that 6% of the Iub U-plane capacity calculated without HSPA peak rate consideration has to be reserved for CNBAP and DNBAP. For the methodology of calculating U-plane capacity without HSPA peak rate consideration in IP transport, see Figure Calculating IP_Route_Bandwidth for DL. Left portion of U-plane bandwidth shows value against which new percentage rule is applied in the dimensioning process. Consideration of Weighted_Eth_OH portion depends on the calculated signaling level (IP or Ethernet). For Iub U-plane capacity less that 1 Mbps, C-plane requirements should be increased to 8%.The signaling bandwidth should be divided into the signaling links according to the following ratio: CNBAP (30%), DNBAP (70%). The split is not relevant from config-uration perspective. IP level C-plane bandwidth obtained by using mentioned rule directly implies IP_Route_C-Plane_commited_BW parameter referred in IP-based Iub dimensioning, used in the following way for the configuration purposes:

– on IP level - relates to committed_signal_bandwidth RNC parameter and signalingCommittedBitRate BTS/AXC parameter and is used to calculate committed and total IP level bandwidth demand per BTS,

– on Ethernet level - is used to calculate total Ethernet level bandwidth demand per BTS (IP based route bandwidth).

NOTE: IP signaling bandwidth setting IP_Route_C-Plane_commited_BW (committed_signal_bandwidth RNC parameter and signalingCommittedBitRate BTS/AXC parameter) does not limit the actual rate of the signaling connection - that is, it is not as critical as in case of shaped CBR ATM connections. It has a meaning from call admission control point of view (scaling the remaining bandwidth resource for U-plane CAC-admitted traffic) and from virtual scheduling rate of remaining U-plane traffic. Scheduling of the actual signaling bitrate is performed according to the PHB weights setting - here Configuring WCDMA RAN rules should apply.

c) Iub signaling link dimensioning recommendations (Dual Iub transport)In dual Iub case, ATM percentage recommendation (a) should be applied to the sum of Iub U-plane capacity for ATM and IP transport (on Ethernet level) calculated without HSPA peak rate consideration. Similar split applies to CNBAP, DNBAP and AAL2SIG. NOTE: for the traffic models significantly deviating from Nokia Siemens Networks default assumptions, it is always recommended to contact Nokia Siemens Networks service with respect to C-plane dimensioning results.

DN70118376Issue 04E

277


Id:0900d80580785cac

6.7.2 Iu/Iur MTP3/M3UA linksDepending on the number of subscribers served by the RNC, the following Iu-CS/Iu-PS signaling bandwidth is recommended in RU20 (calculation assumes default Traffic Model, as described Traffic modeling):

Assuming 5% of the subscribers moving in RNC drift handover area, the following Iur signaling bandwidth is recommended in RU10:

Number of RNC subscribers Recommended ATM bandwidth (ATM trans-port) [cps]

Recommended Ethernet bandwidth (IP Transport) [kbps]

50 000 660 660

150 000 1980 1980

300 000 4000 3960

600 000 7910 7930

900 000 11870 11890

1 500 000 19770 19820

2 000 000 26370 26430

Table 99 Iu-CS MTP3/M3UA dimensioning



50 000 420 440

150 000 1270 1320

300 000 2540 2640

600 000 5080 5280

900 000 7620 7920

1 500 000 12700 13200

2 000 000 16930 17590

Table 100 Iu-PS MTP3/M3UA dimensioning



50 000 110 70

150 000 320 210

300 000 640 420

600 000 1280 840

900 000 1920 1260

Table 101 Iur MTP3/M3UA dimensioning

278 DN70118376Issue 04E


Id:0900d80580785cac

Recommended signaling bandwidth should be distributed evenly over the available number of SS7 signaling links. Due to load sharing concept of MTP3/M3UA layer, the most equal distribution of signaling load over the link set is achieved with 2, 4, 8 or 16 links (usage of only 1 link is not recommended from redundancy point of view).

On Iur, in addition to the distribution over the available number of SS7 signaling links, load should be distributed over the number of Iur relations.

Note: values recommended in Table 99 Iu-CS MTP3/M3UA dimensioning, Table 100 Iu-PS MTP3/M3UA dimensioning, and Table 101 Iur MTP3/M3UA dimensioning provide pure average signaling bandwidth demand on the transport layer. To calculate the resulting capacity needed to be reserved/configured on the transport layer, the link load factor has to be taken into account (20% by default). The example estimation of the SS7 bandwidth required on ATM Iu-CS to serve RNC loaded with 900 000 subscribers; default traffic model; 2 SS7 links; link load of 20%:

– average signaling capacity 11870cps– consideration of 20% link load 11870 / 0.2 = 59350cps– minimum bandwidth to be reserved per SS7 link 59350 / 2 = 29675cps

1 500 000 3200 2100

2 000 000 4270 2790



Table 101 Iur MTP3/M3UA dimensioning (Cont.)

DN70118376Issue 04E

279


Id:0900d80580749d4c

6.8 Dimensioning examples

6.8.1 Parallel connections calculation in Option 1 (ATM)The following example shows the methodology of parallel connection calculation in Dimensioning Option 1.

Assumptions:

• 1000 subscribers • SHO factor 30% • CS services:

• AMR12.2, 22mErl per subscriber, activity 0.6, blocking 1% • CS64, 2.5mErl per subscriber, blocking 1%

• PS services: • PS NRT32, Throughput = 50bps per subscriber, DCHactivity = 80% • PS NRT64, Throughput = 100bps per subscriber, DCHactivity = 80%

Calculation of parallel connections:

CS

• MD Erlang computation:Bandwidth MD-Erlang = MD-Erlang [28.6Erl, 11.4kbps, 1%; 3.25Erl, 79,85kbps, 1%] = 1039kbpsOffered traffic [Erl] – includes SHO factorPeak rate [kbps] – includes protocol overhead and activity

• Gross Mean rate calculation:Gross_Mean_Rate_AMR = 1000 * 0.022 * 12,2 * 1.3 * 0.6 * 1.5528 = 325.1kbps Gross_Mean_Rate_CS64 = 259.5kbps Gross Mean Rates include SHO factor, activity and protocol overhead

• Parallel connections calculation:

After rounding and elimination of AMR connections: Parallel_connections_AMR = 50Parallel_connections_CS64 = 6

PS

• Total Gross Mean Rate calculation:Total_Gross_Mean_Rate=Gross_Mean_Rate(PS32)+Gross_Mean_Rate(PS64)=84.8+169.5=253.1kbpsGross_Mean_Rate_PS32 = 1000 * 0.05 * 1.3 * 1.3039 = 84.8kbpsGross Mean Rates include protocol overhead and SHO factor

Parallel_connections_AMR Bandwidth_MD_Erlang

Mean_Rate_AMRMean_Rate_AMR Mean_Rate_CS64+------------------------------------------------------------------------------------------------------- 1

Peak_Rate_AMR Activity⋅--------------------------------------------------------------------- 50.8=

⋅

⋅

=

Parallel_Connections_CS64 Bandwidth_MD_Erlang

Mean_Rate_CS64Mean_Rate_AMR Mean_Rate_CS64+------------------------------------------------------------------------------------------------------- 1

Peak_Rate_CS64------------------------------------------------ 5.8=

⋅

⋅

=

280 DN70118376Issue 04E


Id:0900d80580749d4c

• MGR-PS computation:Bandwidth MGR-PS (PS32) = M/G/R-PS [254.3kbps; 41.7; 125.2kb; 3.3s]= 375.5kbpsBandwidth MGR-PS (PS64) = M/G/R-PS [254.3kbps; 83.45; 125.2kb; 1.65s]= 500.7kbps

• Parallel Connections calculation:Parallel_connections_PS32 = 375.5 / 41.7 = 9Parallel_connections_PS64 = 500.7 / 83.45 = 6

CAC computationCalculated number of parallel connections for PS32 and PS64 is used as a separate input to CAC algorithm run twice, with additional consideration of RT bearers, common channels and DCCH traffic.

CAC(32) [ realtime traffic part; DCCH; CCCH; 9; (CACvalues(32) ]

CAC(64) [ realtime traffic part; DCCH; CCCH; 6; (CACvalues(64) ]

TotalCACresultDemand = max [CAC(32); CAC(64) ]

DN70118376Issue 04E

281


Id:0900d805806f3e45

6.8.2 IP-based Iub dimensioningThe following example describes the IP-based Iub dimensioning in DL.

Let us assume the following exemplary user traffic demand specified in BH per BTS:

In addition to the user services, the offered traffic for the non-user services is the follow-ing:

The offered traffic values are given assuming 1800 users per BTS and the Mean Traffic per single user for individual services as defined in the Reference Traffic Model, see BTS baseband dimensioning.

The VoIP traffic is assumed to be carried over Streaming HSPA with the configurable values of Max and Guaranteed Bit Rate (MBR/GBR) set to 30 and 15 kbps, respectively. The assumed split between traditional CS Voice users and VoIP users is 1:1.

For the user CCHs a 10% activity factor is used.

For the user signaling a 3.4 kbps DCCH is used with 30% activity factor.

It is assumed I/B HSPA traffic to be carried as low-priority best-effort traffic not subject to CAC.

The CAC-guaranteed bitrates for the CAC-admitted services are as follows:

Service Type Service bit rate on Iub [kbps]

Traffic Demand per BTS site

CS AMR 12.2 Voice 12.2 16.2 erl

VoIP (Streaming HSPA) GBR: 15

MBR: 30

16.2 erl

CS 64 UDI Video 64 4.5 erl

PS I/B64 – DL 64 115.2 kbps

PS I/B 128 – DL 128 100.8 kbps

PS I/B 384 – DL 384 7.74 kbps

I/B HSDPA UE Cat. 6 Max: 3360 1949.9 kbps

Total U-plane R99 + HSPA (DL): 36.9 erl

2173.6 kbps

Table 102 Offered user traffic per BTS

Service Type Service bit rate on Iub [kbps] Mean traffic per BTS site

U-plane CCH: FACH-C 38.4 11.5 kbps

U-plane CCH: FACH-U 40.8 12.2 kbps

U-plane CCH: PCH 27.2 8.2 kbps

U-plane DCCH 3.4 89.2 kbps

O&M 64 64 kbps

Total non-User traffic (DL): 160.6 kbps

Table 103 Offered non-user traffic per BTS (assuming 3 cells per BTS)

282 DN70118376Issue 04E


Id:0900d805806f3e45

The assumed UMTS Service Class to DiffServ PHB mapping is as follows:

In the first step we calculate the required IP bandwidth for individual services.

To get the IP bandwidth demand for the RT U-plane traffic including CS AMR 12.2, CS UDI 64 and Streaming HSPA we use the MD-Erlang formula. The needed MD_Erlang

UMTS Service IP Traffic Descriptors CAC-guaranteed Bit Rate [kbps](0.2 × Max + 0.8 × Ave)Max Bit Rate

[kbps]Average Bit Rate [kbps]

CS AMR 12.2 29.0 15.6 18.3

Streaming HSPA (MBR: 30, GBR: 15)

65.6 32.8 39.4

CS 64 UDI 94.3 88.8 89.9

PS I/B 64 – DL 99.1 93.6 94.7

PS I/B 128 – DL 166.3 160.8 161.9

PS I/B 384 – DL 435.1 430.0 431.0

DCCH 3.4 – DL 14.6 10.4 11.2

U-plane CCH: FACH-C 66.3 6.1 18.1

U-plane CCH: FACH-U 66.7 6.3 18.8

U-plane CCH: PCH 55.2 5.0 15

Table 104 CAC-guaranteed bit rates for different RAB services


UMTS Service class DSCP Value (default)

PHB Assumed WFQ Weight

CS AMR 12.2 incl. DCCHs

Conversational 0b101110 (46) EF -

CS UDI 64 incl. DCCH

Conversational 0b101110 (46) EF -

C-plane - 0b101110 (46) EF -

HSPA Streaming Streaming 0b100010 (34) AF4 50

O&M - 0b011010 (26) AF3 40

FACH, RACH, PCH

- 0b101110 (18) AF2 30

PS I/B 64 incl. DCCH

Interactive 0b001010 (10) AF1 20





HSPA I/B incl. DCCH

Background 0b000000 (0) BE 10

Table 105 Mapping of UMTS Service Classes to DiffServ PHBs

DN70118376Issue 04E

283


Id:0900d805806f3e45

inputs and the resulting bandwidth demand per different PHBs are summarized in Table Bandwidth demand of real time U-plane traffic:

To get the needed bandwidth for NRT U-plane traffic including R99 PS I/B bearers we use the MR-PS formula presented in Dimensioning the CAC-guaranteed U-plane NRT traffic. Here only one PHB is involved (that is AF1) that groups the NRT U-plane R99 services. The needed inputs and the resulting bandwidth demand are summarized in Table Bandwidth demand of non real time U-plane traffic.

Note that for all R99 PS I/B bearers an 80% activity factor is assumed.

The last user traffic component is the best-effort I/B HSPA. The required I/B HSPA band-width is calculated as a sum of the mean traffic generated by HSPA users per Iub and applying an additional overbooking factor of 20%:

BE_HSPA_Bw = 1949.9 kbps × 1.2 = 2339.9 kbps

The required IP bandwidth per service type and per PHB, including the non-user traffic is summarized in the Table IP bandwidth per service type.

MD-Erlang Input Parameter Value

EF PHB

Offered Traffic for CS AMR 12.2, incl. 30% SHO Factor 21.2 erl

Offered Traffic for CS UDI 64, incl. 30% SHO Factor 5.85 erl

Gross peak rate for CS AMR 12.2, incl. DCCH 29.5 kbps

Gross peak rate for CS UDI 64, incl. DCCH 101.1 kbps

Blocking probability for CS AMR 12.2 0.1%

Blocking probability for CS UDI 64 0.1%

MD_Erlang Output: Needed RT U-plane Bw for EF PHB 2235 kbps

AF4 PHB

Offered Traffic for HSPA Streaming, incl. 30% SHO Factor 21.2 erl

Gross peak rate for HSPA Streaming 39.4 kbps

Blocking probability for HSPA Streaming 0.1%

MD_Erlang Output: Needed RT U-plane Bw for AF4 PHB 1170 kbps

Table 106 Bandwidth demand of real time U-plane traffic

Parameter ValueAF1 PHB

290.9 kbpsTotal Offered Traffic, incl. 30 SHO Factor

105.9 kbpsGross peak rate - PS I/B 64

Transfer delay - PS I/B 64



862.0 kbpsM/G/R-PS/ Output: Total nRT U-Plane Bandwidth



10

10

10

284 DN70118376Issue 04E


Id:0900d805806f3e45

Note that:

The CCH bandwidth was calculated assuming 3 cells per BTS.

The C-plane bandwidth was calculated assuming 3 cells per BTS according to the rules described in Dimensioning signaling traffic.

The next step is to calculate the CAC-guaranteed Iub bandwidth (to admit the CAC-guaranteed traffic) and the non-CAC guaranteed Iub bandwidth, for admitting the best effort traffic. The first one is calculated using the formula:

IP_ Route_commited_Bandwidth = RT_U-Plane_commited_BW + nRT_U-Plane_commited_BW + CCH_U-Plane_commited_BW + IP_Route_C-Plane_commited_BW +IP_Route_O&M_commited_BW

Having the bandwidth demand per Iub defined on the IP level, the next step is to calcu-late the needed capacities on the L2 transpor level. For this we apply the weighted Ethernet overhead per Iub calculated as:

Ethernet overhead and the mean traffic for individual UMTS bearers are summarized in the following table. For HSPA we use the average Ethernet OH averaged over all possible HSPA bit rates and equal to 31%.

RT_U-Plane_commited_BWEF 2235 kbps

RT_U-Plane_commited_BW AF4 1170 kbps

NRT_U-Plane_commited_BW 862 kbps

BE_HSPA_Bw 2339.9 kbps

CCH_U-Plane_commited_BW 56.4 kbps

C-Plane_commited_BW 346.2 kbps

O&M_commited_BW 64 kbps

Table 107 IP bandwidth per service type

UMTS Service Mean traffic Ethernet OH

CS AMR 12.2 154.2 kbps 58%

Streaming HSPA (MBR: 30, GBR: 15)

242.6 kbps 51%

CS 64 UDI 374.4 kbps 34%

PS I/B 64 – DL 149.8kbps 32%

PS I/B 128 – DL 131.0 kbps 19%

PS I/B 384 – DL 10.1 kbps 7%

DCCH 3.4 – DL 89.2 kbps 80%

I/B HSPA (BE) 1949 kbps 16%

Table 108 Weighted Ethernet overhead

Weighted_Eth_OUU-Plane

Mean_trafficRAB_U-Plane Eth_OHRAB_U-Plane×RAB_U-Plane

∑

Mean_trafficRAB_U-PlaneRAB∑

----------------------------------------------------------------------------------------------------------------------------------------------------=

DN70118376Issue 04E

285


Id:0900d805806f3e45

The transport capacity per Iub is then equal to:

Iub_Eth_Capacity =(1 / Iub_Utilization) × (IP_Route_commited_Bw + Shared_BE_IP_Allocation) × (1 + Weighted_Ethernet_OH)

To estimate the Iub capacity at the RNC, let us assume the RAN configuration with 33 BTSs per RNC, connected to RNC as shown in Figure Logical Iub connectivity.

Figure 116 Logical Iub connectivity

The capacity to be allocated to RNC ports is then equal to:

RNC_Ethernet_Capacity (IP_Port_1) = 22 × Iub_Eth_Capacity × OverbookingIP_Port_1

RNC_Ethernet_Capacity (IP_Port_2) = 11 × Iub_Eth_Capacity × OverbookingIP_Port_2

The calculated overbooking values for the two ports are:

Overbooking IP_Port_1 = 85%

Overbooking IP_Port_2 = 89%

The resulting RNC port capacities are equal to:

RNC_Ethernet_Capacity (IP_Port_1) = 22 × Iub_Eth_Capacity × 85% = 166 665.8 kbps

RNC_Ethernet_Capacity (IP_Port_2) = 11 × Iub_Eth_Capacity × 89% = 87 254.5 kbps

CCH U-plane 31.9 kbps 80%

Weighted Ethernet OH: 26%

UMTS Service Mean traffic Ethernet OH

Table 108 Weighted Ethernet overhead (Cont.)

BTS 1

BTS 22

BTS 23

BTS 33

Ph_port 1

Ph_port 2

RNC

286 DN70118376Issue 04E


Id:0900d80580787c2a

Dimensioning RNC

7 Dimensioning RNC

7.1 RNC capacityFor information on the maximum traffic amounts served by different RNC configurations, see RNC196 product description, RNC450 product description, and RNC2600 product description.

RU20 (RN5.0) introduces a new capacity step:

• RNC196 Capacity Step 8

The new configuration takes benefit from the CDSP-DH and interface unit upgrades that are done in RNC196 step 7.

CDSP-DH upgrade in RNC196 step 7 provides HSPA peak rate increase capability. It is introduced in RU10 release (RAN1226). Eight CDSP-DH units are needed in this upgrade.

RNC196 step 8 requires the upgrade of the IP interface or the new STM-1 interface to all RAN interfaces as well as the CDSP-DH upgrade for HSPA peak rate increase. Addi-tionally, 10 CDSP-DH units are needed and all CDSP-C cards are removed. After the upgrade, there are 18 of CDSP-DH units in total in the RNC.

In RU20, the capacity of RNC 2600 is increased by SW improvements (RAN1793). Addi-tionally, Coverage Optimized solution is possible (RAN1795). This feature increases RNC connectivity limits at the cost of capacity.

7.2 Dimensioning RNC overviewThe RNC dimensioning requires that the preliminary dimensioning of BTSs, Uu, Iub, Iur, and Iu interfaces is done besides RNC dimensioning.

The RNC dimensioning is mainly based on the following key input requirements:

• RNC capacity requirement for data throughput in Iub (Mbps), AMR and CS voice over HSPA capacity (Erlangs)

• RNC requirement for simultaneous PS NRT data users • number of BTSs and cells to be connected to the RNC • a total sum of AAL2UP connectivity for Iub, Iur, and Iu-CS interfaces in Mbps (if rel-

evant) • physical interface capacity and performance limitations

The hardware limits are essential for the RNC dimensioning process. Some of the hardware limits can be additionally limited by software licenses. The RNC limits are defined by the specified hardware configuration.

DN70118376Issue 04E

287

Dimensioning WCDMA RAN Dimensioning RNC

Id:0900d80580787c2a

Figure 117 Overview of RNC dimensioning process

7.3 Dimensioning based on RNC throughput limitationsUser Plane dimensioningFigure Dimensioning RNC (throughput limitations check) describes the generic method for calculating the total number of RNCs in the network. This method gives an overall understanding of the RNC numbers needed in relation to subscribers, and with a distinc-tion between the voice, CS, PS and HSPA traffic. The UL dimensioning includes DCH and HSUPA.

288 DN70118376Issue 04E


Id:0900d80580787c2a

Dimensioning RNC

Figure 118 Dimensioning RNC (throughput limitations check)

On the basis of traffic, the values for the offered traffic on the Iub can be calculated. During the calculation, adhere to the following principles:

1. Calculate the user traffic from the BTSs, as the expected number of users of each service type: AMR, CS voice over HSPA, CS data, PS data and HSPA traffic. Fur-thermore, define the expected data rates of CS/PS data and HSPA traffic. The data rates used are the FP bit rates (see Table Frame protocol bit rates).Note that: • AMR traffic is treated independently from the other load as far as the Iub

throughput limit is concerned. • PS NRT Data amount is summed over sites per traffic type:

• The number of simultaneous connections at RNC in CS and PS data can be cal-culated by ErlangB with small blocking (0.1% commonly used).

2. Include the SHO overhead for Rel99 PS data, CS data, and HSUPA. Unless speci-fied in a different way, SHO overhead of 40% is used in the dimensioning phase.

3. Select the RNC Capacity Step and calculate the RNC load according to the rules described in Calculating RNC throughput based on Traffic Mix rule. The rules are also described in the RNC product descriptions.

4. Uplink dimensioningVerify the uplink traffic amounts, including the HSUPA traffic, according to the capacities stated in the RNC product description. In UL direction, 30% of DL traffic is supported and is dimensioned similarly. For Rel99, throughput is calculated in the Iub interface and the soft handover (SHO) (40%) is included. With HSUPA, the 30% share is calculated without SHO and thus, the total amount of traffic is more than with Rel99. If the PS UL share is more than 30%, then the maximum Iub PS DL

NRT_Intensity_on_Bearer_i =Site_NRT_Traffic_Bearer_i (kbps)

Bearer_i_rate NRT_Activity_Factor

DN70118376Issue 04E

289


Id:0900d80580787c2a

throughput used in the traffic mix calculation needs to be modified according to the following rule:

UL share can be simply calculated by dividing user traffic in UL direction by user traffic in DL direction:

Note: The throughputs are on Iu-PS without FP and SHO overheads.5. HSPA dimensioning

The HSDPA load can be calculated with the equation:

6. Verify the number of subscribers per RNC using the formula:

where:

The maximum RNC net throughputs can be calculated by excluding from RNC Iub DL throughput:

• 11% of FP overhead in case of HSPA traffic:RNC_HSPA_net_Max_Mbps = RNC Iub DL throughput / 1.11

• 11% of FP overhead and 1.4 SHO factor in case of PS Rel99 traffic:RNC_99_net_Max_Mbps = RNC Iub DL throughput / 1.11 / 1.4

The final output should be the number and the configuration of RNCs for the planned area.

Max Iub PS DL throughput 1.· 31 ULshare+----------------------------------original Max Iub PS DL throughput =

PS UL throughput share Iups PS UL throughputIups PS DL throughput--------------------------------------------------------------=

HSDPA_Traffic 1 FP_Overhead+( ) HSDPA_Traffic_Per_UserUsersPerSite

∑Sites∑⋅=

#_of_Subscribers MIN

1A B C+ +-------------------------

1PS_BHCA_Per_User_Busy_Hour

RNC_Max_PS_BHCA----------------------------------------------------------------------------------------- CS_BHCA_Per_User_Busy_Hour

RNC_Max_CS_BHCA------------------------------------------------------------------------------------------+

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------=

Service (TTI) FP bit rate

AMR 12.2 16 400

CS 64 (20 ms) 66 100

Table 109 Frame protocol bit rates

A HSPA_net_Mbps_per_User_Busy_HourRNC_HSPA_net_Max_Mbps

-----------------------------------------------------------------------------------------------------------=

B R99_net_Mbps_Per_User_Busy_HourRNC_99_net_Max_Mbps

------------------------------------------------------------------------------------------------------=

C CS_Erl_Per_User_Busy_HourRNC_Max_CS_Erlangs

--------------------------------------------------------------------------------=

290 DN70118376Issue 04E


Id:0900d80580787c2a

Dimensioning RNC

As the HSDPA air interface data rates may change every 2 ms period, and FP over-heads change roughly between 3–19% as well, it is recommended to use a 10% overhead over the payload rates for HSDPA to include the RLC and FP overheads.

Control plane dimensioningRNC control plane capacity strongly depends on the number of subscribers, related traffic model and traffic profile (that is BHCA, burstiness). If the expected control plane-related traffic (for example, NAS signaling amounts and handover amounts) is to be used to exceed the product description statement, contact the Nokia Siemens Networks RNC Customer Support for RNC control plane dimensioning.

The RNC reference traffic model is defined in RNC196 product description, RNC450 product description and RNC2600 product description.

RNC traffic mix ruleThe traffic mix rule is used to calculate the maximum traffic amounts that one RNC or certain number of RNCs can support when both AMR and PS data traffic are taken into account.

When the traffic mix rule gives 100%, the RNC capacity is utilized to its maximum. RNC capacities are defined so that certain internal dimensioning target processor loads are used. For example, in RNC2600 the dimensioning target for the processors load in internal units are less than 100%. This means that the maximum capacities are defined so that with the Nokia Siemens Networks traffic profile defined in RNC product descrip-tions, the unit processor loads do not exceed some target values (for example, for DMCU, ICSU target processor load is 80%). This assures that RNC is fully operational with good KPI performance with the capacity load where the traffic mix rule gives 100%.

For example, if the RNC dimensioning is requested based on 70% of DMCU and ICSU processor load, then the dimensioning should be made in a way that the traffic mix rule gives a result of 88% (processor load target / dimensioning target processor load).

When a new RNC is installed normally, the operator expects growth in the network and thus the RNC is not dimensioned to its 100% capacity from the start. There is no standard fill rate recommendation, but it depends on the growth rate and how often capacity extensions are accepted to be done.

Moreover, the recommendation that an RNC capacity extension is needed depends on the capacity growth rate. In general, when the capacity utilization calculated by the traffic mix rule constantly exceeds 80%, then capacity extension planning should be started.

Calculating RNC throughput based on Traffic Mix ruleIf the complete traffic demand from the BTSs is known, traffic mix rule can be applied. In the mixed traffic, the sum of relative loads of the four traffic types (AMR, CS voice over HSPA, CS and PS) over the Iub-interface has to be less than or equal to 1. Relative load

PS 64 (20 ms) 69 500

PS 128 (20 ms) 136 700

PS 256 (10 ms) 273 300

PS 384 (10 ms) 408 000

Service (TTI) FP bit rate

Table 109 Frame protocol bit rates (Cont.)

DN70118376Issue 04E

291


Id:0900d80580787c2a

means dividing the offered traffic by the max allowed traffic value. Therefore, if the result of the following formulas is higher than 1, then the number of the needed RNCs has to be increased. The higher relative load from throughput or user amount formula has to be taken into account.

It has to be noted that:

1. RNC Iub throughput (Mbps) is the traffic in downlink DL direction defined in FP level and it includes 40% of SHO. The throughput is assumed to be a real traffic in DL direction.

2. Additionally 30% of DL traffic is supported in uplink UL direction (UL Iub=0.3* DL Iu_troughput*fp overheads*SHO).

3. For the size of the Iur capacity, see Dimensioning Iur interface chapter.4. The packet data throughput (Mbps) is considered for non-real time traffic.

In addition to throughput limitation check, the maximum RNC level user amounts, which are limited by L2 call resources, should be checked. The maximum user amounts used in the following formula are given by L2 resource point of view and contain also a load caused by the NAS signaling. NAS load is based on the Nokia Siemens Networks traffic mix. The maximum L2 RAB amount is based on L2 capacity and does not take into account control plane caused load.

The user amount load can be checked with following formula:

Where HSDPA RAB ratio is:

PS Rel99 and HS(D)PA user amounts can be found in RNC196, RNC450 and RNC2600 product description.

The user amount traffic mix rule can be used for all configurations: RNC196, RNC450, and RNC2600.

Note that these formulas are valid when control plane load is equal or less comparing to Nokia Siemens Networks traffic mix model.

Rule exampleNote that the purpose of this example is only to describe the dimensioning method. The actual RNC capacity figures and formulas must be verified from the RNC product descriptions. The assumption is that, based on the radio network plan, there are 4000 BTSs and 1000 subscribers per BTS. The number of subscribers per BTS is an average value in the network during the busy hour. The traffic mix and mean HSPA rate per sub-scriber are assumed to be similar to those given in Standard traffic model. SHO is assumed to be 40%.

AMR(Erl) CS over HSPA(Erl)

max AMR(Erl) max CS over HSPA(Erl)

PS data(Mbps) CS data(Mbps)< 1

max Iub throughput(Mbps) max Iub throughput(Mbps)+ + +

AMR(Erl) CSdata(Erl)+max AMR(Erl)

-------------------------------------------------------------- PS64 RAB(#)max PS64 RAB(#)------------------------------------------------- PS128 RAB(#)

max PS128 RAB(#)----------------------------------------------------

PS256 RAB(#)max PS256 RAB(#)---------------------------------------------------- PS384 RAB(#)

max PS384 RAB(#)---------------------------------------------------- HSDPA RAB ratio 1≤

+ + +

+ +

HSDPA RAB ratio HSDPAUL16k RAB(#)max HSDPAUL16k RAB(#)------------------------------------------------------------------------ HSDPAUL64k RAB(#)

max HSDPAUL64k RAB(#)------------------------------------------------------------------------

HSDPAUL128k RAB(#)max HSDPAUL128k RAB(#)--------------------------------------------------------------------------- HSDPAUL384k RAB(#)

max HSDPAUL384k RAB(#)--------------------------------------------------------------------------- HSUPA RAB(#)

max HSUPA RAB(#)-------------------------------------------------------

+ +

+ +

=

292 DN70118376Issue 04E


Id:0900d80580787c2a

Dimensioning RNC

• Total AMR load can be calculated as follows:AMR Load = 4000 BTSs * 1000 subscribers * 0.025 Erl= 100 000 Erl

• CS data Erlangs are summed in the same manner:CS data load = 4000 BTSs * 1000 subscribers * 0.0032 Erl= 12 800 Erl

The number of simultaneous connections at RNC can be calculated by ErlangB with small blocking:

ErlB(12800, 0.1) = 12 984 channels

Adding 40% SHO we get 18 178 channels.

The load for RNC throughput is calculated with the overhead down to FP layer (see Table Frame protocol bit rates):

CS data load = 18 178* 66.1 kbps = 1202 Mbps

• PS Rel99 data traffic is summed over sites per traffic type. In the example, the mean PS Rel99 traffic split from Standard Traffic Model is used:NRT64 – 25%NRT128 – 20%NRT384 – 55%.

According to this split and adding 80% of NRT activity factor, traffic intensities are cal-culated as follows:

Simultaneous bearers with 0.1% blocking probability:

NRT64: ErlB(9375, 0.1%) = 9541 bearers

NRT128: ErlB(3750, 0.1%) = 3870 bearers

NRT384: ErlB(3438, 0.1%) = 3554 bearers

Next, 40% SHO is added:

NRT64: 9541 * 1.4 = 13357 bearers

NRT128: 3870 * 1.4 = 5418 bearers

NRT384: 3554 * 1.4 = 4975 bearers

User plane capacities BHCA Traffic per subs

AMR 0.6 25 mErl

CS data 0.05 3.2 mErl

PS Rel99 0.3 480 bps

HSDPA 950 bps

Total PS data 1430 bps

Table 110 Standard traffic model

NRT64 =4000 480kbps 25%

64kbps 80%= 9375 bearers

NRT128 =4000 480kbps 20%


NRT384 =4000 480kbps 55%


DN70118376Issue 04E

293


Id:0900d80580787c2a

RNC throughput load is calculated by multiplying the number of bearers by FP bit rate for each traffic type (see: Table Frame protocol bit rates). Dimensioning is based on the actual throughput, therefore, activity factor should be applied:

NRT64: 13357 * 69.5 kbps * 0.8 = 743 Mbps

NRT128: 5418 * 136.7 kbps * 0.8 = 593 Mbps

NRT384: 4975 * 408 kbps * 0.8 = 1624 Mbps

• HSDPA load:

Calculated throughputs are summarized in the following table.

The UL share of the traffic in Standard traffic model is less than 30% so the UL traffic needs not to be taken into account separately in the RNC dimensioning.

The maximum capacity of RNC2600 step 3 is 50 000 Erlangs, or 2500 Mbps DL data throughput on Iub. For more information, see RNC2600 product description. In this example, CS voice over HSPA is not used. The number of RNC2600 network elements with, for example, 85% filling ratio can be calculated by putting those values in the equation of traffic mix rule.

• Load:

The calculated value is 6.27, therefore seven RNCs are needed from throughput point of view.

Next, the user amount load should be checked. For PS Rel99, the amount of simultane-ous bearers is already calculated:

NRT64: 9541

NRT128: 3870

NRT384: 3554

To simplify the example, it is assumed that the average throughput per HSDPA user is 100 kb/s and the UL channel split is as follows:

HSDPA/UL64: 10%

HSDPA/UL128: 10%

HSDPA/UL384: 15%

HSDPA/HSUPA: 65%

User plane capacities BHCA Traffic per subs Traffic per BTS Network traffic

AMR 0.6 25 mErl 25 Erl 100000 Erl

CS data 0.05 3.2 mErl 3.2 Erl 1202 Mbps

PS Rel99 0.3 480 bps 0.480 Mbps 2960 Mbps

HSDPA 950 bps 0.950 Mbps 4180Mbps

Total PS data 1430 bps 1.430 Mbps 7140 Mbps

Table 111 Network traffic summation

HSPA_Traffic= 1.10i=4000 j=1000

0.950 = 4180Mbps

100000 Erl50000 Erl 85%⋅------------------------------------------ 7140 Mbps

2500 Mbps 85%⋅---------------------------------------------- 1202 Mbps

2500 Mbps 85%⋅---------------------------------------------- 6.27=+ +

294 DN70118376Issue 04E


Id:0900d80580787c2a

Dimensioning RNC

The amount of HS(D)PA active users:

HSDPA/ UL64: 4180 Mbps *10% * 1000 / 100 kbps= 4180

HSDPA/UL128: 4180 Mbps *10% * 1000 / 100 kbps= 4180

HSDPA/UL384: 4180 Mbps *15% * 1000 / 100 kbps= 6270

HSDPA/HSUPA: 4180 Mbps *65% * 1000 / 100 kbps= 27170

Calculation of “HS(D)PA RAB ratio” factor with RNC2600/step 3 user amount limits:

User amount check:

The calculated values are 6.27 from the capacity point of view and 4.48 from user amount point of view, therefore, seven RNCs are needed.

Finally, subscriber amount verification has to be done. Assuming 4 000 000 subscribers and 7 RNC2600s/step3, the number of subscribers per RNC is calculated as follows:

From the user traffic profile point of view, the number of subscribers is calculated as follows:

In the example shown, the RNC can serve even more subscribers with a given traffic profile than required.

Note that in customer networks, the number of subscribers is not distributed evenly over RNCs. Therefore, real life values need to be used.

7.4 RNC dimensioning based on BTS connectivity limitsFor information on the RNC BTS connectivity limits, see RNC196 product description, RNC450 product description and RNC2600 product description.

Dimensioning process for carriers and WBTSs is based on the following principles:

• Get the amount of sites and carriers - normally available from radio network plan-ning.

• Retrieve the relevant limit from the RNC capacity tables. • Define the filling ratio for the limit.

HSDPA RAB ratio 418031956---------------- 4180

25930---------------- 6270

13856---------------- 27170

53706----------------+ + + 1.25= =

100000 12800+50000

------------------------------------------- 954123580---------------- 3870

18424---------------- 3554

9956------------- 1.25 4.48≈+ + + +

4000000 / 7 RNCs 571429 subscribers per RNC=

#_Of_Subscribers MIN

1950 bps

2250 Mbps----------------------------- 450 bps

1609 Mbps----------------------------- 28.2 mErl

50000 Erl-------------------------+ +

--------------------------------------------------------------------------------------------------

10.3

2000000----------------------- 0.65

1600000-----------------------+

-----------------------------------------------------MIN

7784871797753

778487= = =

DN70118376Issue 04E

295


Id:0900d80580787c2a

• Calculate number of RNC based on the following equations:

Rule exampleContinuing the previous example, there are 4000 BTSs. With three carriers assigned to one BTS, 12 000 carriers are needed. The number of RNC2600 step3 (Capacity Opti-mized) with 85% filling ratio is calculated using the following equation:

From the BTS connectivity point of view, six RNC2600 are needed.

7.5 RNC dimensioning based on AAL2 connectivityBefore you startNote that in RNC2600 and RNC196 / step8, the AAL2 connectivity is not needed sepa-rately as a dimensioning parameter as there are no A2SU units anymore. Only the number of physical interface units need to be dimensioned.

The AAL2 connectivity limit determines the maximum capacity for the AAL2 adapted ATM VCC that can be configured to the RNC. The total AAL2 capacity resource usage of an RNC is the sum of configured capacity of AAL2 Path VCCs for Iub, Iur, and Iu-CS interfaces. Thus, RNC dimensioning requires preliminary dimensioning of BTSs, Iub, Iur and Iu interfaces besides RNC dimensioning. The same formulas are used whether the AAL2 paths belong to VCC bundles or not.

The AAL2UP connectivity is consumed as follows:

• CBR AAL2 Path VCC: PCR • UBR+ AAL2 Path VCC: max(0.1 * PCR, MDCR)

The AAL2 connectivity capacity increases with the configuration step. For more informa-tion, see Capacity and reference call mix model or RNC product descriptions.

The Iub User Plane capacity can be taken directly from Iub dimensioning calculation (see section Dimensioning Iub interface) or by deciding the physical layer capacity based on the Iub dimensioning and then looking the maximum User Plane size for that physical layer configuration. The first choice is valid for theoretical calculations, for example comparing solutions. The second approach should be followed when dimen-sioning for roll-out.

For IuCS and Iur interface dimensioning principles, see Dimensioning Iu-CS interface and Dimensioning Iur interface sections.

Needed_RNC(Carrier) Number_of_carriersRNC_Carrier_limit Carrier_Fill_ratio⋅-------------------------------------------------------------------------------------------------=

Needed_RNC(BTS) Number_of_BTSsRNC_BTS_limit BTS_Fill_ratio⋅------------------------------------------------------------------------------------=

Needed_RNC(Carrier) 120002800 85%⋅----------------------------- 5.04= =

Needed_RNC(BTS) 40002800 85%⋅----------------------------- 1.68= =

296 DN70118376Issue 04E


Id:0900d80580787c2a

Dimensioning RNC

A set of configuration examples including dimensioned VP/VC capacities can be found in Configuring WCDMA RAN transport.

Steps

1. Calculate the Iub bandwidth available for the BTSs.2. Calculate Iu-CS and Iur traffic and VCC sizes.3. Calculate the number of BTSs to be connected to the RNC.4. Calculate the total consumed AAL2UP connectivity for ATM based Iu-CS, Iur and

Iub interfaces, and compare it to the value supported by the capacity step as described in RNC196 product description, RNC450 product description and RNC2600 product description.

Rule exampleContinuing with 4 000 BTSs and 4 000 000 subscribers, it is possible to calculate from the Traffic Mix rule that 38 RNC450s (step 3) are needed - that gives 105 BTSs per RNC. Calculating User Plane bandwidth on interfaces (see Section: Dimensioning Interfaces), the following values are received:

• 5.7 Mbps per single Iub, • 70 Mbps for Iu-CS, • 19 Mbps for Iur (assuming 3 Iur per RNC).

Average RNC AAL2 connectivity consumption is:

105*5.7+70+19= 687.5 Mbps.

Maximum RNC450 step 3 AAL2 connectivity is 3594 Mbps, therefore the connectivity filling ratio is:

687.5 Mbps /3594 Mbps = 19.13%.

7.6 Physical interface capacityFor the number and type of interfaces that are supported by different configurations of each RNC, see RNC196 product description, RNC450 product description and RNC2600 product description. The interfaces can be configured flexibly according to the operator's requests and capacity needs.

Note that both STM-1 and Gigabit Ethernet interfaces are mutually exclusive. Both can also be present in the same RNC. NPS1(P) and NPGE(P) dimensioning are limited by either:

• the maximum throughput, • number of ATM / IP objects or • call processing capacity.

Maximum throughput and number if ATM / IP objects supported

NPS1The maximum throughput of NPS1(P) is 1200 Mbps symmetrical traffic at ATM level. This means that the maximum bandwidth of eight STM-1 interfaces is fully utilized. The maximum throughput with AAL2 traffic is 1000 Mbps. If ATM policing is used, it decreases the AAL2 switching capacity throughput to 890 Mbps.

The number of ATM objects supported per NPS1(P):

DN70118376Issue 04E

297


Id:0900d80580787c2a

• User plane VCs: 3800One NPS1(P) can support 2000 VCs for other purpose the same time that is signal-ing links, semi-permanent VCs, and so on. Total number per RNC is 31800 for all type of VCs, 14000 for UP VCs(AAL2 paths).

• VPs: 1744 • Shaped VPs: 768 • VC bundles: 1440

If VC bundles are used with shaped VPs, the overall capacity is 768 together.

VC bundles + shaped VPs =< 768.

NPGEEach GE port in NPGE(P) supports 1000Mbit/s throughput symmetrically on Ethernet level. With 2 GE ports, NPGE(P) supports the maximum of 1650 Mbit/s because of SFU port rate limitation. The small packet size decreases the achieved throughput. For example, in Iu-CS AMR call 75 bytes IP level -> 39 bytes at application level.

The NPGE packet forwarding capacity is 2.6 Mbps total in both directions, including sig-naling. In the Iu-CS interface, one NPGE can support about 32000 Erlang traffic with Nokia Siemens Networks traffic mix due to CS-call small packet size.

Number of IP objects supported in NPGE(P):

• static routes: 3000 • IP based route: 600 • VLAN: 600 • BFD session: 600

Call processing capacityAlso the call processing affects the load of NPS1(P) / NPGE(P) unit. This can be pre-sented in terms of BHCA capacity per unit. The BHCA capacity per NPS1 and NPGE is defined according to the following three typical configurations:

– Iu-CS and Iu-PS on the same unit– Iub dedicated unit– Iub, Iu-CS and Iu-PS on the same unit

* On Iu-CS interface, packet forwarding capacity or ATM/IP object limitations are more restrict than BHCA.

Note: These values are given with Nokia Siemens Networks traffic mix.

In the NPS1 or NPGE unit there is basically traffic handling and call processing resources. ATM or IP packets consume traffic handling capacity and, for example the

NPS1(P) CSBHCA

NPS1(P) PSBHCA

NPGE(P) CSBHCA

NPGE(P) PSBHCA

Iu-CS/Iu-PS 1280000 (32000 Erl*)

618600 1280000 (32000 Erl*)

850590

Iub 751640 512330 626370 512160

Iub/Iu-CS/Iu-PS 691480 410370 583960 386950

Table 112 Performance limitations for NPS1 and NPGE in various scenarios

298 DN70118376Issue 04E


Id:0900d80580787c2a

Dimensioning RNC

number of radio link activations consume the call processing resources. When calculat-ing the needed unit amount, those should be calculated separately.

NPS1/NPGE units call processing load in IubCalculation of NPS1 units in Iub should be done from:

• throughput • BTS connectivity • traffic profile point of view

NPS1:

The maximum number of BTSs connected to one NPS1 depends on the number of user plane VCs configured to BTS. When using average 3 user plane VCs per BTS, there can be connected up to 3800/3 =1267 BTSs per NPS unit.

If shaped VPs and/or VC bundles are used, then, depending on configured amount of bundles and shaped VPs per BTS, it would limit the connected BTSs per NPS.

NPGE:

For IP/Ethernet, the connectivity limitation is the number of VLAN and BFC sessions. Normally, one VLAN and BFD session is used per BTS.

NPGE capacity is then 600 BTS. Static routes do not limit BTS values because there is one route used per BTS.

The traffic profile would limit the traffic amount through one NPS1/NPGE unit (that is CP events are also relevant, in addition to UP traffic). The traffic concentration to one NPS1/NPGE unit would be hard to predict. Because of this unbalance, some margin is needed when calculating the needed NPS1/NPGE units (unit level load = 1.2 * average load, also unit-level fill factor is to be taken into account).

• Number of ATM / IP objects - static, limited configuration unbalance: 95% • The maximum throughput and Call processing capacity - dynamic, unbalance factor

1.2 • Mixed configurations: unbalance is more complicated.

Because the BHCA per NPS1/NPGE is given with Nokia Siemens Networks traffic mix, the fill rate is only indicative if the traffic mix differs from Nokia Siemens Networks one.

Rule exampleTraffic Mix Rule gave seven RNC2600s step3. With 4000 BTSs, it gives 572 BTSs per RNC. The number of VCCs can be assumed as follows:

• 2 AAL2 VCCs per BTS • 6 AAL VCCs on Iu-CS • 2 VCC on Iur per one neighboring RNC

Total RNC AAL2 VC consumption is:

Number VCs= (572*2)+6+(3*2)= 1156 VCs

In this example, NPS1 unit has 3800 AAL2 VC Limit, so the limit is not reached even for one unit.

DN70118376Issue 04E

299


Id:0900d80580787c2a

7.7 RNC software license keysRNC2600 introduced in RU10 gives a possibility to license capacity based on the actual traffic needs. This allows a cost efficient use of RNC in all different kinds of networks. Capacity extensions are easy to be executed even without any site visits.

Capacity is licensed with the following three capacity parameters:

• AMR capacity (Erl) • Iub PS data throughput (Mbps) • number of carriers

Capacity upgrades are possible only with an upgrade of SW license, therefore, by ordering new capacity license files and activating capacity upgrades from NetAct or with the local element manager, as long as the capacity is below the limits of the HW of the configuration step.

AMR capacity licensingThe AMR Erlangs license gives the maximum number of the simultaneous AMR RABs. RNC counts the number of the simultaneous AMR RABs periodically. When the amount is greater than the licensed capacity, RNC does not accept new AMR RABs as long as the amount decreases below licensed limit. In practice, some overcapacity is allowed and hysteresis is used between starting and stopping the AMR limiting. Pre-emption is used so that higher priority AMR RABs might pre-empt lower priority AMR RABs when the licensed capacity is exceeded.

Figure 119 AMR Capacity license principle

PS throughput licensingThe PS throughput license gives the maximum RNC downlink PS throughput in Mbps. RNC counts the PS throughput received on each Iu-PS interface periodically. PS throughput on Iub is factored by adding the FP header overhead factor (11%) to the measured GTP throughput. Iu-CS traffic, Iur traffic or soft handover overhead are not counted into the PS data throughput.

When the throughput is higher than the licensed capacity, RNC starts to limit the downlink PS throughput on each Iu-PS interface. Throughput is limited in small steps,

HW max AMR capacity

Licenced AMRcapacity

time

Stop AMR RABBlocking

Number ofAMR RABs

Start AMR RABBlocking

300 DN70118376Issue 04E


Id:0900d80580787c2a

Dimensioning RNC

taking into account TCP behavior on packet dropping. When throughput is limited, packet dropping cannot be avoided. When the RNC level PS throughput decreases, the throughput limiting is first decreased and eventually stopped. In practice, some overca-pacity is allowed and hysteresis is used between starting, decreasing, and stopping the throughput limiting.

Figure 120 PS throughput license principle

Number of carriersThe number of carriers capacity license gives the O&M limit for the maximum number of unlocked cells to be connected to the RNC element. The OMU is involved in this licensing process.

Rule exampleCalculation of the required SW licences is equal to calculation of AMR capacity, PS data throughput and the number of carriers per each RNC element in the network.

• AMR Capacity: 100 000 Erl / 7 RNC = 14 286Erl • Iub PS data throughput: 7625 / 7 RNC= 1090 Mbps • Number of carriers: 12000 / 7 RNC = 1715 carriers

It has to be mentioned that this example is valid only if the traffic and the number of BTSs are evenly distributed. In calculations, real-life traffic and BTSs distribution needs to be considered.

7.8 BTS load distribution factor (Uneven load factor)

7.8.1 BackgroundIn real-life networks, daily traffic in certain BTSs is distributed differently over time. In BTSs placed in urban areas, the highest traffic is during working hours, that is between 7 a.m. - 5 p.m., while in BTSs placed in rural areas, the highest traffic is in the after-noons or in the evenings. In many cases BTSs with different traffic profiles and traffic distribution in space and time work under one radio network controller. Therefore, BTS load distribution needs to be taken into account during the RNC and Iub dimensioning

HW max Iub PS datathroughput capacity

Licenced Iub PS datathroughput

time

Decrease packetdropping

Iub PS DataThroughput

Start packetdropping

Stop packetdropping

DN70118376Issue 04E

301


Id:0900d80580787c2a

process in order to decrease the number of RNCs needed in the network, and also to prepare cost efficient offers for the customers.

7.8.2 BTS load distribution factor definition

Even load calculationCurrently, in the RNC and interfaces dimensioning process, a traffic profile is defined per user and per BTS area in the busy hour, but it is not defined when this BH happens in each BTS. It is assumed that BH in all BTSs is at the same time, so the worst case is considered. At the RNC level, traffic demand is simply calculated by summing BH traffic over all BTSs.

Figure 121 Even load calculation

Uneven load calculationIn real-life networks, high traffic in BTSs is only for 2-3 hours per day and it is distributed unevenly in time across the network. The result is that, at the RNC level, traffic is quite evenly spread out in most of the day, but it is much lower than indicated by the “even load calculation” method.

302 DN70118376Issue 04E


Id:0900d80580787c2a

Dimensioning RNC

Figure 122 Uneven load calculation

The difference between the RNC traffic demand calculated by “even load calculations” and “uneven load calculations” is called the BTS load distribution factor (LDF).

Figure 123 BTS load distribution factor

To calculate the BTS load distribution factor (LDF), adhere to the following principles:

– Identify the busiest hour for each cell, the volume of data carried in that hour, and work out each BTS “personal” BH throughput.

– Sum the results to give an equivalent throughput value (see: Even load calculation)– Identify the traffic in each BTS in every hour.– Sum the results for every hour and choose the highest result to give an aggregated

BH throughput value (see: Uneven load calculation).– Divide an equivalent throughput value by an aggregated BH throughput value to

receive BTS load distribution factor.

When LDF is calculated, it is possible to estimate how the RNC load, calculated by the tools, can be decreased according to traffic distribution over time. The following through-put parameters are decreased:

– AMR calls [Erl]– CS data [Mbps]– PS data [Mbps]

DN70118376Issue 04E

303


Id:0900d80580787c2a

Rule exampleThere are 300 BTSs connected to one RNC, each with 5 Mbps traffic demand in busy hour. Most of the tools assume that BTS busy hours happen at the same time in all the BTSs, therefore, the needed RNC data throughput is:

300 BTS x 5 Mbps per BTS = 1500 Mbps

Because of the geographical distribution, BTSs under one RNC have their busy hours at different time. Therefore, the needed RNC level throughput seems to be much less. To simplify the example, there are five BTS areas defined, depending on traffic distribu-tion on time:

After adding up the traffic per each area, the traffic demand at the RNC level at defined hours is as follows:

Taking into account BTS BH distribution in time, the maximum load at the RNC level is 695 Mbps and it is at 6 p.m.. With this data, it is possible to calculate the BTS load dis-tribution factor (LDF):

LDF = 1500 Mbps / 935 Mbps = 1.6

Once you have calculated the LDF, it is possible to decrease the needed RNC through-put which is calculated by the tools by dividing them by 1.6. The values received reflect required throughput with respect to traffic distribution over time.

In real-life networks, traffic at the RNC level is quite even between 10 a.m. - 1 a.m., that is for ~15 hours.

BST area No. of BTSs BTS busy hour load at:

9 p.m. [Mbps] 12 pm [Mbps] 6 p.m. [Mbps]

Area 1 40 1.5 5 1

Area 2 70 0.5 5 3

Area 3 120 0.5 1 5

Area 4 50 5 2.5 1.5

Area 5 20 3 5 0.5

Table 113 BTS busy hour load

BST area No. of BTSs Area busy hour load at:

9 p.m. [Mbps] 12 pm [Mbps] 6 p.m. [Mbps]

Area 1 40 60 200 40

Area 2 70 35 350 210

Area 3 120 60 120 600

Area 4 50 250 125 75

Area 5 20 60 100 10

RNC level 300 456 895 935

Table 114 Area busy hour load

Dimension Ing WCDMA RAN

Documents

Transcript of Dimension Ing WCDMA RAN