Wran Dim Access Net

WCDMA RAN, Rel.RU30, Operating Documentation

Dimensioning WCDMA RAN: Access Network

(RNC and Transport)

DN0980058 Issue 01G Approval date: 2012-10-22

Confidential

Dimensioning WCDMA RAN: Access Network (RNC and Transport)

2 (154) © Nokia Siemens Networks

Confidential DN0980058

Issue 01G

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is not an official customer document and Nokia Siemens Networks does not take responsibility for any errors or omissions in this document. This document is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted. No part of this documentation 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.

IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA, that might arise from the use of this document or the information in it.

THE CONTENTS OF THIS DOCUMENT ARE PROVIDED "AS IS". EXCEPT AS REQUIRED BY APPLICABLE MANDATORY LAW, NO WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT, ARE MADE IN RELATION TO THE ACCURACY, RELIABILITY OR CONTENTS OF THIS DOCUMENT. NOKIA SIEMENS NETWORKS RESERVES THE RIGHT TO REVISE THIS DOCUMENT OR WITHDRAW IT AT ANY TIME WITHOUT PRIOR NOTICE.

This document 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 2012. All rights reserved.

3/


DN0980058

Issue 01G

© Nokia Siemens Networks

Confidential 3 (154)

Table of contents

1 Dimensioning RNC ............................................................ 11

1.1 Dimensioning process ............................................................................. 11

1.2 Dimensioning based on RNC throughput limitations ............................ 12

1.3 RNC Dimensioning based on BTS connectivity limits ........................... 16

1.4 RNC Dimensioning based on AAL2 connectivity ................................... 17

1.5 Physical interface capacity ...................................................................... 18

1.6 RNC SW licenses Keys ............................................................................ 21

1.7 BTS load distribution factor (Uneven load factor) .................................. 23

1.8 BTS load distribution factor definition .................................................... 24

1.9 RNC Dimensioning Example .................................................................... 27

2 Dimensioning Interfaces .................................................... 34

3 Dimensioning Iub .............................................................. 35

3.1 Iub user plane dimensioning ................................................................... 35

3.2 Physical interface capacity ...................................................................... 39

4 ATM-based Iub ................................................................. 41

4.1 Iub VCC configuration .............................................................................. 41

4.2 Iub VCC configuration dimensioning ...................................................... 48

4.3 Iub VPC configuration .............................................................................. 51

4.4 ATM-based Iub dimensioning .................................................................. 53

4.5 ATM-based Iub dimensioning methods .................................................. 54

5 IP-based Iub ...................................................................... 67

5.1 IP-based Iub dimensioning ...................................................................... 67

5.2 IP-based Iub dimensioning methods....................................................... 74

5.3 IP-based transport network layer configuration ..................................... 84

5.4 IP-based Iub dimensioning example ....................................................... 90

6 RAS06 features impacting dimensioning process ............. 98




Issue 01G

6.1 RAN1063: Hybrid Backhaul with Pseudo Wires ..................................... 98

6.2 RAN1096: Transport Bearer Tuning ...................................................... 100

6.3 RAN1100: Dynamic Scheduling for NRT DCH with Path Selection..... 100

RAN1254: Timing over Packet for BTS SW .......................................... 100

6.4 100

7 RU20 features impacting dimensioning process ............. 101

7.1 RAN 1202: 24 kbps Paging Channel ..................................................... 101

7.2 RAN1578: HSPA Transport Fallback ..................................................... 101

7.3 Iub fallback VCC configuration and dimensioning .............................. 102

7.4 RAN1689: CS Voice over HSPA (On Top) ............................................. 105

7.5 RAN1707: Flexi WCDMA integrated CESoPSN (On Top) ..................... 110

7.6 CESoPSN traffic bandwidth calculation ............................................... 110

7.7 RAN1707 requirements .......................................................................... 112

7.8 RAN1709: VLAN Traffic Differentiation (On Top) ................................. 112

7.9 Dimensioning aspects ........................................................................... 112

7.10 Dimensioning example .......................................................................... 113

8 RU30 features impacting dimensioning process ............. 115

8.1 RAN1637: High Speed Cell_FACH (DL) ................................................ 115

8.2 RAN1769: QoS Aware Ethernet Switching ........................................... 115

8.3 RAN1878: IP over ML-PPP on E1/T1 Interfaces .................................... 117

8.4 RAN1879: Dynamic Routing by OSPF and RAN2359: OSPF Enhancements in BTS .......................................................................................................... 122

8.5 RAN1880: Ethernet OAM in BTS ........................................................... 125

8.6 RAN1886: Efficient Transport for Small IP Packets ............................. 127

8.7 RAN1900: IP Transport Network Measurement .................................... 129

9 Dimensioning Iur .................................................................................... 131

9.1 Iur dimensioning method for user plane .............................................. 131

9.1 HSPA traffic on Iur ................................................................................. 131

9.2 IP transport on Iur .................................................................................. 132

9.3 IP-based Iur transport network layer configuration ............................. 132

10 Dimensioning Iu-CS ........................................................ 134

10.1 u-CS dimensioning method for user plane........................................... 134

5/


DN0980058

Issue 01G



10.2 Iu-CS overhead calculation in ATM transport ....................................... 135

10.3 Dimensioning IP-based Iu-CS ................................................................ 135

11 Dimensioning Iu-PS ........................................................ 137

11.1 Iu-PS dimensioning method for user plane .......................................... 137

11.2 Iu-PS overhead calculation in ATM transport ....................................... 139

11.3 Dimensioning IP-based Iu-PS ................................................................ 141

12 Dimensioning Iu-BC ........................................................ 143

13 Dimensioning signaling traffic .......................................... 144

13.1 Iub signaling links .................................................................................. 144

13.2 Iu/Iur MTP3/M3UA links .......................................................................... 151

Abbreviations ................................................................................ 154




Issue 01G

List of Figures Figure 1: Overview RNC Dimensioning Process ........................................... 12 Figure 2: Dimensioning RNC- Throughput Limitations Check ........................ 13 Figure 3: AMR Capacity License principle ..................................................... 22 Figure 4: PS Throughput License principle .................................................... 23 Figure 5: Even Load Calculation ................................................................... 24 Figure 6: Uneven load calculation ................................................................. 25 Figure 7: BTS load distribution factor ............................................................ 25 Figure 8: Traffic parameter modeling ............................................................. 35 Figure 9: BTS AAL2 multiplexing ................................................................... 43 Figure 10: Iub VCC configuration with path selection and native ATM transport 45 Figure 11: Iub VCC configuration with path selection and hybrid transport .. 46 Figure 12: VPC configuration with CBR VCC based user and control plane 52 Figure 13: VPC layer configuration option for RU10 path selection configuration with CBR/UBR+ VCC based user plane (UBR O&M) .................................... 52 Figure 14: Iub dimensioning option 1 ........................................................... 56 Figure 15: Iub dimensioning option 2 ........................................................... 58 Figure 16: HSDPA protocol stack ................................................................ 60 Figure 17: HSUPA protocol stack ................................................................ 61 Figure 18: Iub bandwidth demand ............................................................... 66 Figure 19: IP-based Iub dimensioning components ....................................... 67 Figure 20: Possible transport QoS mapping schemes on IP-based Iub ....... 69 Figure 21: DiffServ scheduler implementation at RNC/BTS. Scheduler is implemented on each logical Iub. .................................................................. 70 Figure 22: IP bandwidth components on Iub ............................................... 71 Figure 23: Calculating IP_Route_Bandwidth for DL ....................................... 82 Figure 24: U-plane and c-plane protocol stacks on the IP-based Iub ............. 84 Figure 25: IP-based Iub transport flow configuration in DL. VLAN option: 1 VLAN per logical Iub ...................................................................................................... 89 Figure 26: Logical Iub connectivity ................................................................ 96 Figure 27: Protocol stack for hybrid transport over Iub .................................. 98 Figure 28: Dual Iub configuration for BTS...................................................... 102 Figure 29: VCC configuration of hybrid Iub with dedicated fallback VCC ....... 104 Figure 30: VCC configuration of hybrid Iub with dedicated and shared fallback VCC ...................................................................................................................... 105 Figure 31: CS Voice over HSPA – impact on the transport network. ............. 106 Figure 32: Packetization latency and CESoPSN bandwidth .......................... 111 Figure 33: QoS-aware Ethernet Switching dimensioning process ................. 117 Figure 34: ML-PPP minimum and maximum overhead cases ....................... 119 Figure 35: Iur bandwidth demand .................................................................. 132 Figure 36: Iu-CS dimensioning ...................................................................... 134 Figure 37: Classical IP over ATM .................................................................. 140 Figure 38: Approximation curve for Iu-PS overhead factor ............................ 141

7/


DN0980058

Issue 01G



List of Tables

Table 1: Frame Protocol bit rates .................................................................................... 15 Table 2: Performance limitations for NPS1 and NPGE in various scenarios .................... 19 Table 3: Example: BTS BH distribution ............................................................................ 26 Table 4: Example: Calculated BH traffic at the RNC level ................................................ 27 Table 5: RU20 Standard traffic model .............................................................................. 27 Table 6: Network traffic summation ................................................................................. 29 Table 7: Basic traffic model parameter set for access dimensioning ................................ 36 Table 8: CCHs input to CAC algorithm-relation to Optimized CCH Reservation feature 38 Table 9: Common Control Channel reservation ............................................................. 39 Table 10: Iub interface types ......................................................................................... 40 Table 11: Number of VCCs with path selection configuration and HSUPA, ................... 44 Table 12: Number of VCC with path selection configuration and HSUPA, dedicated VCC for both RT DCH and NRT DCH traffic.................................................... 47 Table 13: Parameter value selection with Path Selection and HSUPA .......................... 51 Table 14: Parameter value selection for VP layer ............................................................ 53 Table 15: HSDPA protocol overheads (RU10, 10% BLER) ........................................... 60 Table 16: HSDPA protocol overheads (RU20/RU30, Flexible RLC, 10% BLER) ........... 61 Table 17: Table CID demand for a certain call types ..................................................... 64 Table 18: Example of IP transport QoS mapping on Iub ................................................. 70 Table 19: The IP traffic descriptors and Ethernet overheads for u-plane CCH traffic. ..... 78 Table 20: CAC traffic descriptors and bit rates for selected Release 99 and DCCH-over-HSPA bearers. ........................................................................................................................... 86 Table 21: CAC traffic descriptors and bitrates for selected HSPA flows. .......................... 86 Table 22: Reference traffic model. ................................................................................... 90 Table 23: Offered CCH non-user traffic per BTS (assuming three cells per BTS). ........... 90 Table 24: CAC-guaranteed bit rates for different RAB services ....................................... 91 Table 25: Mapping of UMTS service classes to DiffServ PHBs. ...................................... 91 Table 26: Bandwidth demand of RT u-plane traffic. ......................................................... 92 Table Table 27: Bandwidth demand of non RT u-plane traffic. ........................................ 93 Table 28: IP bandwidth per service type .......................................................................... 94 Table 29: Weighted Ethernet overhead for the CAC admitted traffic. ............................... 95 Table 30: Ethernet overhead for the non-user plane traffic .............................................. 95 Table 31: Ethernet overhead for the non CAC admitted traffic ......................................... 96 Table 32: Example calculation for hybrid transport overheads on top of ATM layer ......... 99 Table 33: CS Voice over HSPA – ALC parameters ......................................................... 107 Table 34: CS Voice over HSPA – IPTD parameters ........................................................ 107 Table 35: CS Voice over HSPA – QoS priority and VCC selection in ATM transport ....... 109 Table 36: CS Voice over HSPA – QoS Priority selection in IP Transport ......................... 109 Table 37: Example of bandwidth estimations per PHB class with RAN1709 activated ..... 114 Table 38: Offered user traffic per BTS ............................................................................. 119 Table 39: CAC-guaranteed bit rates for different RAB services ....................................... 120 Table 40: Bandwidth demand of RT u-plane traffic .......................................................... 120 Table 41: Bandwidth demand of non RT u-plane traffic .................................................. 120 Table 42: IP bandwidth per service type .......................................................................... 121 Table 43: Weighted ML-PPP overhead. .......................................................................... 122 Table 44: OSPF Hello only and BFD+OSPF failure detection options bandwidth consumption comparison ...................................................................................................................... 125 Table 45: Header length for Iu-PS data (IP over ATM) .................................................... 140




Issue 01G

Table 46: Iu-CS MTP3/M3UA dimensioning .................................................................... 151 Table 47: Iu-PS MTP3/M3UA dimensioning .................................................................... 152 Table 48: Iur MTP3/M3UA dimensioning ......................................................................... 152

9/


DN0980058

Issue 01G



Summary of changes

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

Changes between issues 01G (2012-10-22, RU30) and 01F (2011-06-26, RU30)

IP-based dimensioning rules have been changed in the following chapters: - 5.2.4 Dimensioning I/B HSPA traffic (non CAC-guaranteed) - 5.2.10 Calculating total Iub bandwidth (IP_Route_Bandwidth) - 8.6 RAN1886: Efficient Transport for Small IP Packets

9.1 HSPA traffic on Iur has been updated Changes between issues 01F (2012-06-26, RU30) and 01E (2011-11-30, RU30)

Chapter 2.6.1 Activation of new features having impact into Iub signaling example has been modified.

Chapter 2.6.1.2 HSPA QoS features title has changed to Provided Bit Rate measurements and content has been updated.

Chapter 2.6.1.4 HSPA QoS features title has changed to Provided Bit Rate measurements AND BTS site capacity.

Chapter 2.6.1.5 Rule application examples have been modified.

Chapter 2.6.1.5 Rule Application Example - One equation has been removed and one equation has been added.

Changes between issues 01E (2011-11- 30, RU30) and 01D (2011-09-30, RU30)

ATM/IP Traffic Descriptors have been updated in the following tables: Table 22: CAC traffic descriptors and bit rates for selected Release 99 and DCCH-over-HSPA bearers, Table 23: CAC traffic descriptors and bitrates for selected HSPA flows, Table 42: CAC-guaranteed bit rates for different RAB services, Table 34: CS Voice over HSPA – ALC parameters, Table 35: CS Voice over HSPA – IPTD parameters.

Chapters 2.1.16.1 CAC algorithm for multiplexing on Iub/Iur and 2.1.16.2 Multiplexing factor on Iub/Iur have been updated.

Changes between issues 01D (2011-09-30, RU30) and 01C (2011-06-30, RU30)

Chapter Dimensioning signaling traffic, in section Iub signaling links, the dimensioning rule has been extended with HSPA QoS feature impact and extended site count at BTS.




Issue 01G

11/


DN0980058

Issue 01G



1 Dimensioning RNC

1.1 Dimensioning process

The RNC dimensioning requires that the preliminary dimensioning of BTSs, Uu, Iub, Iur and Iu interfaces has been done or 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 RNC control plane capacity requirement number of BTSs and cells to be connected with the RNC total sum of AAL2 connectivity for Iub, Iur and Iu-CS interfaces in Mbps (if

relevant) physical interface capacity, connectivity and performance limitations

The hardware limits are essential for the RNC dimensioning process. Some of the hardware limits can be additional limited by software licenses. The RNC limits are defined by the concrete hardware configuration.




Issue 01G

Figure 1: Overview RNC Dimensioning Process

1.2 Dimensioning based on RNC throughput limitations

Figure Dimensioning RNC describes the generic method for calculating the total number of RNCs in the network. This method gives an overall understanding of the needed RNC numbers in relation to subscribers, and with a distinction between the voice, CS, PS and HSPA traffic. The UL dimensioning includes DCH and HSUPA.

13/


DN0980058

Issue 01G



Figure 2: Dimensioning RNC- Throughput Limitations Check

On base of traffic, the values for the offered traffic on the Iub can be calculated. During calculation please follow 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. Furthermore, 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) with 100% activity. The following should be taken into consideration:

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:

FactorActivityNRTrateiBearer

kbpsiBearerTrafficNRTSiteiBeareronIntensityNRT

____

)(________

The number of simultaneous connections at RNC in CS and PS data can be calculated by ErlangB with small blocking (0.1% commonly used)




Issue 01G

2. Include the SHO overhead for R99 PS data, CS data, and HSUPA. Unless otherwise specified, 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 in the RNC product descriptions.

4. Uplink dimensioning

Verify the uplink traffic amounts, including the HSUPA traffic according to RNC capacities. 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 R99. If the PS UL share is more than 30 %, then the max Iub PS DL throughput used in the traffic mix calculation needs to be modified according to the following rule:

throughputDLPSIubMaxoriginalshareUL

throughoutDLPSIubMax ______1

3.1____

UL share can be simply calculated by dividing user traffic in UL direction by user traffic in DL direction:

throughputDLIuPS

throughoutULIuPSsharethroughputULPS

__

_____

Note: throughputs are on Iu-PS- without FP and SHO overheads.

5. HSPA dimensioning

Verify the active HSPA subscriber amounts to fit within the selected RNC capacity. HSDPA load can be calculated with the equation below:

teUsersPerSiSites

UserPerTrafficHSDPAOverheadFPTrafficHSDPA ___)_1(_

6. Verify the number of subscribers per RNC using the following formula:

The final output should be the number and configuration of RNCs for the planned area.

BHCACSMaxRNC

HourBusyUserPerBHCACS

BHCAPSMaxRNC

HourBusyUserPerBHCAPS

ErlangsCSMaxRNC

HourBusyUserPerErlCS

MbpsMaxnetRRNC

HourBusyUserPerMbpsnetR

MbpsMaxnetHSPARNC

HourBusyUserperMbpsnetHSPA

MIN

sSubscriberOf

___

_____

___

_____

1

,

___

_____

___99_

______99

____

______

1

__#

15/


DN0980058

Issue 01G



Service (TTI) FP bit rate

AMR 12.2 16 400

CS 64 (20 ms) 66 100

PS 64 (20 ms) 69 500

PS 128 (20 ms) 136 700

PS 256 (10 ms) 273 300

PS 384 (10 ms) 408 000 Table 1: Frame Protocol bit rates

As the HSDPA air interface data rates may change with 2 ms period, and FP overheads change roughly between 3–19% as well, it is recommended to use a 11% overhead over the payload rates for HSDPA to include the RLC and FP overheads.

1.2.1 Calculating RNC throughput based on Traffic Mix Rule

If 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 means dividing the offered traffic by the max allowed traffic value. Therefore, if the result of following formulas is higher than 1, then the number of needed RNCs has to be increased. The higher relative load from throughput or user amount formula has to be taken into account.

1)(max

)(

)(max

)(

)(max

)(

)(max

)(

MbpsthroughputIub

MbpsdataCS

MbpsthroughputIub

MbpsdataPS

ErlHSPAoverCS

ErlHSPAoverCS

ErlAMR

ErlAMR

NOTE:

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 real traffic in DL direction.

Additionally 30 % of DL traffic is supported in uplink UL direction (UL Iub=0.3* DL Iu_troughput*fp overheads*SHO)

For the size of the Iur capacity please see Dimensioning Iur interface chapter. The packet data throughput (Mbit/s) is considered for non-realtime traffic

In addition to throughput limitation check, the maximum RNC level active user amounts, which are limited by L2 call resources, should be checked. Max active user amounts used in following formula are given by L2 resource point of view and contain a load caused by NAS signaling also. NAS load is based on NSN




Issue 01G

traffic mix. Max L2 RAB amount is based on L2 capacity and does not take into account control plane caused load.

The active user amount load can be checked with following formula:

1)(#384max

)(#384

)(#256max

)(#256

)(#128max

)(#128

)(#64max

)(#64

)(max

)()(

ratioRABHSDPARABPS

RABPS

RABPS

RABPS

RABPS

RABPS

RABPS

RABPS

ErlAMR

ErldataCSErlAMR

Where HSDPA RAB ratio is:

)(#max

)(#

)(#384max

)(#384

)(#128max

)(#128

)(#64max

)(#64

)(#16max

)(#16

RABHSUPA

RABHSUPA

RABkULHSDPA

RABkULHSDPA

RABkULHSDPA

RABkULHSDPA

RABkULHSDPA

RABkULHSDPA

RABkULHSDPA

RABkULHSDPAratioRABHSDPA

PS Rel.99 and HS(D)PA user amounts can be found from RNC196, RNC450 and RNC2600 product descriptions. The user amount traffic mix rule can be used for all configurations RNC196, RNC450 and RNC2600. It has to be noted that these formulas are valid when control plane load is equal or less compared to NSN traffic mix model.

1.3 RNC Dimensioning based on BTS connectivity limits

For information on the RNC BTS connectivity limits, see RNC196, RNC450 and RNC2600 product descriptions. Dimensioning process for carriers and NodeBs is based on the following principles:

Get the amount of sites and carriers- normally available from radio network planning

Retrieve the relevant limit from the RNC capacity tables

Define the filling ratio for the limit

Calculate number of RNC based on the following equations:

17/


DN0980058

Issue 01G



ratioFillCarrieritCarrierRNC

carriersofNumberCarrierRNCNeeded

__lim__

__)(_

ratioFillBTSitBTSRNC

BTSsofNumberBTSRNCNeeded

__lim__

__)(_

1.4 RNC Dimensioning based on AAL2 connectivity

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 a RNC is the sum of AAL2 Path VCCs for Iub, Iur and Iu-CS interfaces. Thus, RNC dimensioning requires that preliminary dimensioning of BTSs, Iub, Iur and Iu interfaces have been done or is done besides RNC dimensioning. The same formulas shall be used regardless 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 information, 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 Dimensioning Iub interface chapter) 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 dimensioning for roll-out. For IuCS and Iur interface dimensioning principles, please see Dimensioning Iu-CS and Dimensioning Iur chapters. A set of configuration examples including dimensioned VP/VC capacities can be found in Configuring WCDMA RAN document. 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.




Issue 01G

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 the RNC Product Description. In RNC2600 and RNC196/step8 the AAL2 connectivity is not needed separately as a dimensioning parameter as there are no A2SU units anymore. Only the number of physical interface units needs to be dimensioned.

1.5 Physical interface capacity

Note: Capacity statements for NPS1 and NPGE units are not verified, therefore, some changes in those values are possible. For the number and type of interfaces that are supported by different configurations of each RNC, please see 2.1.7 chapter or RNC product descriptions. 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 is limited by either

The maximum throughput

Number of ATM / IP objects or

Call processing capacity

1.5.1 Maximum throughput and number if ATM / IP objects supported

NPS1 The maximum throughput of NPS1(P) is 1200 Mbit/s 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 Mbit/s. If ATM policing is used, AAL2 switching capacity throughput is decreased to 890 Mbit/s. Number of ATM objects supported per NPS1(P):

User plane VCs: 3800 (total number per RNC is 24 000) One NPS1(P) can support 2000 VCs for other purpose the same time, that is signaling links, semi-permanent VCs, etc. Total number per RNC is 31 800 for all type of VCs, 14 000 for UP VCs(AAL2 paths).

VPs: 1744

https://www.online.nokia.com/nols/doccenter/ned/docsets/ned/NED?action=retrieve&library=ran_rnc_maint_rel_06_3_0_v1_2008_08_27&identifier=dn0634862&edition=314&language=en&coverage=global&encoding=xhtml_1_0&component=data&item=data&pointer=ned_top#ned_top

19/


DN0980058

Issue 01G



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. NPGE Each GE port in NPGE(P) supports 1000 Mbps throughput symmetrically at Ethernet level. With 2 GE ports, NPGE(P) supports the maximum of 1.65 Gbit/s symmetrical traffic because of switching fabric (SFU) port rate limitation. The small packet size decreases achieved throughput. E.g in Iu-CS AMR call 75 bytes IP level -> 39 bytes at application level. The NPGE packet forwarding capacity is 2.6 Mpps total in both directions, including signaling. In the Iu-CS interface the one NPGE can support about 32 000 Erlang traffic with NSN traffic mix due to CS-call small packet size. Number of IP objects supported in NPGE(P):

static route: 3000 IP based route: 1024 VLAN: 600 BFD session: 600

1.5.2 Call processing capacity

Also the call processing affects on the load of NPS1(P) / NPGE(P) unit. This can be presented 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

NPS1(P) CS BHCA

NPS1(P) PS BHCA

NPGE(P) CS BHCA

NPGE(P) PS BHCA

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 2: Performance limitations for NPS1 and NPGE in various scenarios




Issue 01G

*) On Iu-CS interface, packet forwarding capacity or IP/ATM object limitation are more restrict than BHCA NOTE:

These values are given with NSN traffic mix In the NPS1 or NPGE unit there are basically traffic handling and call processing resources. ATM or IP packets consume traffic handling capacity and for example number of radio link activations consumes the call processing resources. When calculating needed unit amount those shall be calculated separately. NPS1/NPGE units call processing load in Iub Calculation of NPS1 units in Iub shall be done from:

Throughput

BTS connectivity

Traffic profile point of view. NPS1: Maximum number of BTSes connected to one NPS1 depend on nbr of user plane VCs configured to BTS. When using average 3 user plane VC per BTS there can be connected up to 3800/3 = 1267 BTS per NPS unit.

If shaped VPs and/or VC bundles are used then depend on configured amount of bundles and shaped VPs per BTS it would limit the connected BTS per NPS1. NPGE: For IP/Ethernet connectivity limitation is the number of VLAN and BFD sessions. Normally, one VLAN and BFD session is used per BTS. NPGE capacity is then 600 BTS. Static routes are not limiting BTS values because there is used one route 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 calculate 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.

21/


DN0980058

Issue 01G



Because the BHCA per NPS1/NPGE is given with NSN traffic mix the fill rate is only indicative if the traffic mix differs from NSN one.

1.6 RNC SW licenses Keys

High capacity RNC2600 enables capacity licensing. Capacity upgrades are possible only with an upgrade of a SW license. No HW changes are required in the capacity upgrade when the capacity fits limits of the HW capability. Capacity can be freely SW configured for

Data (PS throughput)

Voice (AMR Erlangs)

Number of unlocked Cells By this way the RNC is a flexible product for small as well as big operators. Operators may first buy only limited Operating SW (OSW) capacity, but maximum HW in order to have installation and commissioning costs only once. To be able to use any of the licensed features, the license must be installed in RNC and the state of the feature must be ON. For capacity type features the capacity limit must be defined.

1.6.1 AMR Erlangs license

AMR Erlangs license gives the maximum number of simultaneous AMR RABs. RNC counts the number of simultaneous AMR RABs periodically. When the amount is greater than the licensed capacity, RNC does not admit 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 - higher priority AMR RABs may pre-empt lower priority AMR RABs when the licensed capacity is exceeded.




Issue 01G

Figure 3: AMR Capacity License principle

1.6.2 PS Throughput capacity license

PS Throughput license gives the maximum RNC downlink PS throughput in Mbit/s. RNC counts the PS throughput received on each Iu-PS interface periodically. PS throughput on Iub is factored by adding 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 downlink PS throughput on each Iu-PS interface. Throughput is limited on small steps, taking into account TCP behavior on packet dropping. When throughput is limited, packet dropping cannot be avoided. When RNC level PS throughput decreases, the throughput limiting is first decreased and eventually stopped. In practice some overcapacity is allowed and hysteresis is used between starting, decreasing and stopping the throughput limiting.

23/


DN0980058

Issue 01G



Figure 4: PS Throughput License principle

1.6.3 Number of unlocked carriers

Number of carriers capacity license gives O&M limit for maximum number of unlocked cells to be connected to RNC element. The OMU is involved in this licensing process.

1.7 BTS load distribution factor (Uneven load factor)

1.7.1 Background

In 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 am- 5 pm, while in BTSs placed in rural areas the highest traffic is in the afternoons 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 process in order to decrease number of RNCs needed in the network and also to prepare cost efficient offers for the customers.




Issue 01G

1.8 BTS load distribution factor definition

1.8.1 Even load calculation

Currently in the RNC and Interfaces dimensioning process, a traffic profile is defined per user and per BTS area in 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 5: Even Load Calculation

1.8.2 Uneven load calculation

In real-life networks, high traffic in BTSs is only for 2-3 hours per day and it’s 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.

25/


DN0980058

Issue 01G



Figure 6: 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 7: BTS load distribution factor

To calculate the BTS load distribution factor (LDF), please adhere to the following principles:

Identify the busiest hour for each cell and the volume of data carried in that hour and work out each BTS ‘personal’ BH throughput




Issue 01G

Sum these to give to an equivalent throughput value (see: Even load calculation)

Identify the traffic in each BTS in every hour of the day

Sum these for every hour and choose the highest result to give a aggregated BH throughput value (see: Uneven load calculation)

Divide an equivalent throughput value by aggregated BH throughput value to receive BTS load distribution factor.

Having LDF calculated gives a possibility to estimate, how the RNC load calculated by the tools can be decreased according to traffic distribution over time. The following throughput parameters are decreased:

AMR calls [Erl] CS data [Mbps] PS data [Mbps]

1.8.3 Rule example

Let’s assume 300 BTSs connected to one RNC, each with 5Mbps 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 would be: 300 BTS * 5 Mbps per BTS = 1500 Mbps Because of the geographical distribution, BTSs under one RNC have their Busy Hours at different time of the day. Therefore the needed RNC level throughput seems to be much less. To simplify the example, there are five BTS areas, depending on traffic distribution in time:

BTS Area No. of BTSs BTS Busy Hour load at :

9 pm [Mbps] 12 pm [Mbps] 6 pm [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 3: Example: BTS BH distribution

After adding up the traffic per each area, the traffic demand at the RNC level, at defined hours is as follows:

BTS Area No. of BTSs Area Busy Hour load at :

9 pm [Mbps] 12 pm [Mbps] 6 pm [Mbps]

Area 1 40 60 200 40

Area 2 70 35 350 210

Area 3 120 60 120 600

27/


DN0980058

Issue 01G



Area 4 50 250 125 75

Area 5 20 60 100 10

RNC level 300 465 895 935

Table 4: Example: Calculated BH traffic at the RNC level

Taking into account BTS BH distribution in time, the maximum load at the RNC level is 695 Mbps and it is at 6 pm. With this data it is possible to calculate the BTS load distribution factor (LDF): LDF = 1500 Mbps / 935 Mbps = 1.6 Once you have calculated the LDF, it is possible to decrease the needed RNC throughputs, which are 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 am – 1 am, that is for ~15 hours.

1.9 RNC Dimensioning Example

Note 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 subscriber are assumed to be similar to those given in Standard traffic model. SHO is assumed to be 40%.

Table: 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 5: RU20 Standard traffic model




Issue 01G

1.9.1 RNC throughput limitation check

1.9.1.1 Total AMR load

Total AMR load can be calculated as follows: AMR Load = 4000 BTS’s * 1000 subscribers * 0.025 Erl= 100 000 Erl

1.9.1.2 CS data load

CS data Erlangs can be calculated as follows: CS data load = 4000 BTS’s * 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. Load for RNC throughput is calculated with the overhead down to FP layer (see FP bit rates table): CS data load = 18 178 * 66,1 kbps = 1202 Mbps

1.9.1.3 PS Rel99 data load

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 calculated as follows:

bearerskbps

kbpsNRT 9375

%8064

%25480400064

bearerskbps

kbpsNRT 3750

%80128

%204804000128

29/


DN0980058

Issue 01G



bearerskbps

kbpsNRT 3438

%80384

%554804000384

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 RNC throughput load is calculated by multiplying number of bearers by FP bit rate for each traffic type (see: Frame Protocol bit rates table). Dimensioning is based on 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

1.9.1.4 HSDPA data load

HSDPA data load can be calculated as follows:

MbpsTrafficHSPAji

4218950.011.1_10004000

Calculated throughputs are summarized in the following table:

Table: 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.2 480 bps 0.480 Mbps 2960 Mbps

HSDPA 0.1 950 bps 0.950 Mbps 4218 Mbps

Total PS data 0.3 1430 bps 1.430 Mbps 7178 Mbps

Table 6: Network traffic summation

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

https://www.online.nokia.com/nols/doccenter/ned/docsets/ned/NED?action=retrieve&library=ran_rnc_maint_rel_06_3_0_v1_2008_08_27&identifier=dn0634862&edition=314&language=en&coverage=global&encoding=xhtml_1_0&component=data&item=data&pointer=ned_top#ned_top




Issue 01G

network elements with 85% filling ratio can be calculated by putting those values in the equation of traffic mix rule: Load:

29.6%852500

1202

%852500

7178

%8550000

100000

Mbps

Mbps

Mbps

Mbps

Erl

Erl

The calculated value is 6.29, therefore 7 Radio Network Controllers are needed from throughput point of view. Next, the user amount load should be checked. For PS Rel.99, the amount of simultaneous bearers is already calculated:

NRT64: 9541 NRT128: 3870 NRT384: 3554

To simplify the example, let’s assume the average throughput per HSDPA user is 100 kb/s and the following UL channel split:

HSDPA/UL64: 10%

HSDPA/UL128: 10%

HSDPA/UL384: 15%

HSDPA/HSUPA: 65% The amount of HS(D)PA active users:

HSDPA/ UL64: 4218 Mbps *10% * 1000 / 100 kbps= 4218

HSDPA/UL128: 4218 Mbps *10% * 1000 / 100 kbps= 4218

HSDPA/UL384: 4218 Mbps *15% * 1000 / 100 kbps= 6327

HSDPA/HSUPA: 4218 Mbps *65% * 1000 / 100 kbps= 27417 Calculation of “HS(D)PA RAB ratio” factor with RNC2600/ step 3 user amount limits:

28,153706

27417

13856

6327

25930

4218

31956

4218ratioRABHSDPA

User amount check:

51.428.19956

3554

18424

3870

23580

9541

50000

12800100000

The calculated values are 6.14 from capacity point of view and 4.51 from user amount point of view, therefore 7 Radio Network Controllers are needed.

31/


DN0980058

Issue 01G



Finally, subscriber amount verification has to be done. Assuming 4 000 000 subscribers and 7 RNC2600s/step3, the average number of subscribers per RNC is calculated as follows: 4 000 000 subscribers / 7 RNCs = 571 429 subscribers per RNC From user traffic profile point of view, the number of subscribers is calculated as follows:

7784871951219

778487

2000000

65.0

1600000

3.0

1

,

50000

2.28

1609

480

2250

950

1

__#

MINErl

mErl

Mbps

bps

Mbps

bps

MINsSubscriberOf

It can be concluded, that in discussed example RNC is able to serve even more subscribers with given traffic profile, than required. It has to be noted, that in customer networks, the number of subscribers is not distributed evenly over RNCs, therefore real life values has to be used.

1.9.2 BTS/Carrier connectivity check

Continuing 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 Optimized) with 85% filling ratio is calculated using above equation:

04.5%852800

12000)(_

CarrierRNCNeeded

68.1%852800

4000)(_

BTSRNCNeeded

From BTS connectivity point of view, 6 RNC2600 are needed.

1.9.3 AAL2 connectivity check

In this example RNC450 is used, because AAL2 connectivity based dimensioning is not relevant in RNC2600 used in other examples. Continuing with with 4 000 BTSs and 4 000 000 subscribers, from Traffic Mix rule can be calculated, that 38 RNC450s (step 3) are needed- it gives 105 BTSs per RNC.




Issue 01G

Calculating User Plane bandwidth on interfaces (see: Dimensioning Interfaces chapter), 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 connectivity filling ratio would be: 687.5 Mbps /3594 Mbps = 19.13% Please note, that in real-life networks, exact number of BTSs connected to concrete RNC should be used, as well as real traffic in each interface.

1.9.4 Physical interface capacity/ connectivity check

With 4000 BTSs, 1000 subscribers per BTS with NSN default traffic profile, 7 RNC2600s step 3 is needed. In the example it is supposed that Iub traffic is separated from Iu and Iur and STM1 is chosen as an network interface unit. Total calculated interface average loads at ATM level (please see Dimensioning Interfaces chapter for details):

22,616 Gbps at Iub

10,387 Gbps at Iu/Iur what gives per RNC:

3,231 Gbps at Iub

1,484 Gbps at Iu/Iur

571 BTSs

1.9.5 Throughput limitation check

Iub: 3,231 * 1000 Mbps *1,2 / 1200 Mbps = ~2,7 3 NPS1 cards are required Iu/Iur: 1,484 *1000 Mbps *1,2 / 1200 Mbps = ~1,24 2 NPS1 cards are required If protected interfaces have to be used, all received values have to be multiplied by 2.

33/


DN0980058

Issue 01G



1.9.6 Amount of ATM objects check

Number of UP VC’s can be assumed as follows:

2 AAL2 VCC’s per BTS

6 AAL2 VCC’s on Iu-CS

2 VCC on Iur per one neighboring RNC Total RNC AAL2 VC consumption is: Number VCs= (572*2)+6+(3*2)= 1154 VC’s In example, NPS1 unit has 3800 AAL2 VC Limit, so the limit is not reached even for one unit.




Issue 01G

2 Dimensioning Interfaces In the following chapters, proposed dimensioning methods are described, split into Iub, Iur and Iu part. All the general sub-chapters are mainly focused on ATM transport. For IP/Ethernet separate interface specific content is given, highlighting required changes in the methodology.

35/


DN0980058

Issue 01G



3 Dimensioning Iub The following sub-chapters deal with Iub dimensioning related topics.

3.1 Iub user plane dimensioning

The following sub-chapters deal with Iub dimensioning related topics.

3.1.1 User traffic demand modeling

For detailed information regarding Traffic Modeling, see Dimensioning WCDMA RAN: Traffic Modeling. The following is the basic traffic model related to the parameter set used in the interface dimensioning process. It focuses on subscriber oriented values, based on which all the input data to the dimensioning process is evaluated.

RABliveDuration

DCHsessionDuration

MeanRateBH

MeanRateRABlive

Avarage of

MeanRateDCHsession’s

FACH/PCH session

-> DCH in-activity period’s

Inactivity before

Channel type switching

t

Da

ta R

ate

MeanRateDCHsession’s

Figure 8: Traffic parameter modeling




Issue 01G

Parameter / [unit] Description / Formula

Peak Rate Max. data rate of the DTCH bearer (RAB)

BHCA

[#]

Busy Hour Call Attempts is defined as Busy Hour RAB Attempts;

DCH can be DTCH (R99); HS-DSCH or E-DCH

DCH duration

[s]

Sum of all DCH durations of a RAB live

= ∑ all DCH durations of RAB live

DCH activity

[abs] or [%]

Average activity over all DCH sessions of a RAB live

= Average of Mean Rate DCH session’s / Peak Rate or

= Mean Rate BH / ( Peak Rate × DCH duration × BHCA / 3600s ) or

= Mean Rate BH / (Peak Rate × Erlang DCH session’s)

Erlang DCH session’s

[#]

Basic traffic demands for CS traffic:

= DCH duration × BHCA / 3600s

Basic traffic demands for PS and HS traffic:

= Mean Rate BH / (Peak Rate × DCH activity)

Mean Rate BH

[bps]

Basic traffic demands for PS and HS traffic:

= DCH activity × Peak Rate × DCH duration × BHCA / 3600s

Basic traffic demands for CS traffic:

= DCH activity × Peak Rate × Erlang DCH session’s

Parallel Connections

DCH

[#]

Input value for CAC; in case of PS non-RT dimensioning as best effort

without QoS it can be calculated as follows:

= round-up [ Erlang DCH session’s ] or

= round-up [ DCH duration × BHCA / 3600s ] or

= round-up [ mean Rate BH / (DCH activity × Peak Rate) ]

Table 7: Basic traffic model parameter set for access dimensioning

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 the following must be the same for UL and DL.

BHCA

DCH duration

Erlang DCH session’s

Mean Rate BH and DCH activity must be separately calculated for UL and DL.

The amount of traffic demand per busy hour must be provided for a specific BTS site.

If the amount of traffic demand is given per subscriber, additional assumption for the number of subscribers per site is required.

37/


DN0980058

Issue 01G



Additionally, assumption on the soft handover overhead is needed.

NOTE: The default value for inter-NodeB soft handover factor is 30%.

Softer handover does not influence Iub u-plane, and is not relevant for RNC static capacity either. From the interface point of view, it loads only Iu and Iur c-plane, considered in chapter 13 Dimensioning signaling traffic.

3.1.1.1 Dedicated Control Channels - DCCH

SRBs over DCH For signaling, the SRB with 13.6kbps (ALC set 3 with the lowest activity factor of three options per SRB type) is proposed when dimensioning of the Iub interface via CAC algorithm (see 4.4 ATM-based Iub dimensioning) 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: Given overhead is related to ATM transport. 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 HSPA

RAN1201 Fractional DPCH brings in a support for SRBs carried over HSPA, required in relation with the following features:

RAN1689 CS Voice over HSPA

RAN1201 Fractional DPCH

RAN1638 Flexible RLC

RAN981 HSUPA 5.8 and RAN1470 HSUPA 2ms TTI

Due to 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.




Issue 01G

E-DCH/HS-DSCH SRB connection requires two CIDs / UDP ports instead of one consumed by DCH mapped control channels.

3.1.1.2 Common Control Channels - CCCH

The following assumptions are made for dimensioning of the Iub interface via Call Admission Control algorithm. Since 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 algorithm. As a result of Optimized CCH reservations feature, subset of CCH accounted by CAC depends on the Physical Channel configuration (defined by RNC -> WCEL ->

NbrOfSCCPCHs parameter). The table summarizes CCH Call Admission Control

and its relation to Optimized CCH Reservation feature.

1 SCCPCH 2 SCCPCH

2 SCCPCH (RAN1202

24kbps PCH)

3 SCCPCH

FACH-C - - -

Possible only in case of Service

Area Broadcast

feature

FACH-U X X X

RACH** X X X

PCH 8kbps

X -

PCH 24kbps - - X

Enhanced FACH X* X* X*

Table 8: CCHs input to CAC algorithm-relation to Optimized CCH Reservation feature

* Feature RAN1637 High Speed Cell_FACH (DL) must be activated.

** CAC reservation for RACH channel depends on availability of RACH-capacity-based transport reservation functionality. For more information, see WCDMA RAN ATM Transport or WCDMA RAN and I-HSPA IP Transport.

Feature RAN1202: 24 kbps Paging Channel brings in a possibility to enhance the Paging Channel’s throughput to 24 kbps. As a result, the probability of congestion of BTSs serving high number of subscribers is reduced. Enhanced PCH always requires a separate SCCPCH configuration. Therefore, CAC takes it into account separately.

39/


DN0980058

Issue 01G



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 8kbps Paging Channel 8kbps DL: 27200 bps

10%

PCH 24kbps (RAN1202)

Paging Channel 24kbps DL: 36000 bps

10%

Enhanced FACH (RAN1637

Enhanced (High Speed) Forward Access Channel

- -

Table 9: Common Control Channel reservation

Enhanced FACH is separated into signaling part and user part - 2 CIDs (ATM) / UPD ports (IP) are required. CAC reservation includes:

DL: CAC traffic descriptors for HS FACH signaling part

UL: doubled HSDPA control reservation

NOTE: Information provided in this chapter does not cover the Service Area Broadcast feature.

3.2 Physical interface capacity

The following table presents the Iub physical interface types. Cell rate means the available 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 rate

Mbit/s Transfer bit rate

Mbit/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




Issue 01G

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 10: Iub interface types

41/


DN0980058

Issue 01G



4 ATM-based Iub The following sub-chapters deal with Iub dimensioning related topics.

4.1 Iub VCC configuration

The 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. ATM layer differentiation with the AAL2 VCC combinations is possible with the Path Selection license. 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.

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 R’99 UL and HSDPA/HSUPA calls three AAL2 connections are needed (DCCH+HSDPA+HSUPA/PS R’99 UL). The Path Selection feature enables ATM layer VCC separation based on the combination of AAL2 VCC types with AAL2 path type (ITU-T Q.2630.2) and air interface channel type differentiation (DCH/HSxPA). The AAL2 User Plane VCC Usage parameter specifies the air interface channel type (DCH/HSxPA) carried over the AAL2 VCC, while the AAL2 Path Type parameter defines the transport




Issue 01G

priority. Both attributes configured for the ATM End Point are used to control the AAL2 VCC selection at the RNC.

Without the Path Selection license, all DCH and HSDPA traffic is carried over DCH&HSDPA + Stringent & Stringent Bi-level & Tolerant VCC, whereas optional HSUPA traffic is mapped to separate HSUPA VCC. In case of a Dual Iub configuration without Path Selection, the DCH + Stringent & Stringent Bi-level VCC carries all traffic routed over ATM transport network.

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 is taken as a candidate to carry the transport bearers for the Common Transport Channels, R99 DCHs, and SRBs (DCCH on DCH). With configured HSPA UP VCC Stringent & Stringent Bi-level & Tolerant all HSPA traffic is routed to the HSPA VCC.

The Iub configuration principles for simple DCH and HSDPA traffic differentiation

are shown in Figure 9: BTS AAL2 multiplexing. In this case DCH and HSDPA traffic has dedicated VCCs to carry user traffic. For configurations when HSUPA traffic is enabled, it is possible to use also a dedicated VCC for HSDPA and dedicated VCC for HSUPA. Such configuration is the only one possible with Ultra WCDMA BTS when AAL2 multiplexing is enabled. In addition, if Iub interface is not bandwidth restricted in both the downlink and uplink (for example when using symmetric VDSL line), the HSDPA and HSUPA can also share the same VCC; no AAL2 multiplexing is required at UltraSite WCDMA BTS for this configuration.

43/


DN0980058

Issue 01G



Figure 9: BTS AAL2 multiplexing

VCC ATM Service Category/ (AAL2 path type)

BTS with basic AAL2 multiplexing

BTS with AAL2 multiplexing*

Flexi WCDMA BTS**

Configuration 1

AAL2 user plane for rt-DCH, nrt-DCH and HSDPA

CBR (stringent) 1 or 2 per WAM

only 1 if the WAM is used for HSUPA

At least 1 VCC per BTS





Issue 01G


BTS with basic AAL2 multiplexing


Flexi WCDMA BTS**

AAL2 user plane for HSUPA traffic.

UBR+ (tolerant) 1 for a dedicated WAM

1 per BTS At least 1 VCC per BTS

Configuration 2

AAL2 user plane for rt-DCH and nrt-DCH traffic

CBR (stringent) At least 1 VCC per WAM



AAL2 user plane for HSDPA/HSUPA traffic

(option1)

UBR+ (tolerant) At most 1 VCC per WAM



AAL2 user plane for HSDPA traffic.

(option2)

UBR+ (tolerant) At most 1 VCC per WAM (if HSDPA available only)




(option2)

UBR+ (tolerant) Configuration not applicable if HSDPA in dedicated VCCs



CNBAP UBR+ One per BTS One per BTS One per BTS

DNBAP UBR+ One per WAM One per WAM One per BTS

AAL2sig UBR+ One per WAM One per BTS One per BTS

O&M UBR+ One per BTS One per BTS One per BTS

Table 11: Number of VCCs with path selection configuration and HSUPA,

Configuration1: RT-DCH, NRT-DCH and HSDPA share the same VCC, HSUPA traffic in separate

VCC

Configuration2: RT-DCH and NRT-DCH traffic share the same VCC, HSDPA and HSUPA traffic

share the same VCC (AUXA) or have separate VCCs (AUXB)

*) The maximum number of AAL2 user plane VCCs is seven if BTS AAL2 multiplexing is enabled.

**) The maximum number of AAL2 user plane VCCs is 16.

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

45/


DN0980058

Issue 01G



Figure 10: Iub VCC configuration with path selection and native ATM transport and Figure 11: 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 following 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. This configuration is only applicable if BTS AAL2 multiplexing is enabled.

Figure 10: Iub VCC configuration with path selection and native ATM transport




Issue 01G

Figure 11: Iub VCC configuration with path selection and hybrid transport



Flexi WCDMA BTS**

AAL2 user plane for RT-DCH traffic

CBR (Stringent) At least 1 VCC per BTS


AAL2 user plane for NRT-DCH traffic

UBR+ (Stringent Bi-level) At least 1 VCC per BTS


AAL2 user plane for HSDPA/HSUPA traffic

(option 1)

UBR+ (Tolerant) At least 1 VCC per BTS


AAL2 user plane for HSDPA traffic.

(option 2)



47/


DN0980058

Issue 01G





Flexi WCDMA BTS**


(option 2)



CNBAP UBR+ One per BTS One per BTS

DNBAP UBR+ One per WAM One per BTS

AAL2sig UBR+ One per BTS One per BTS

O&M UBR+ One per BTS One per BTS

Table 12: Number of VCC with path selection configuration and HSUPA,

dedicated VCC for both RT DCH and NRT DCH traffic

*) The maximum number of AAL2 user plane VCCs is seven

**) The maximum number of AAL2 user plane VCCs is 16

For more information on ATM Iub configurations for UltraSite and Flexi

WCDMA BTS, see Configuring WCDMA RAN and I-HSPA Transport.

On enabling Path Selection and HSUPA features, further combinations of user VCCs become available. The AAL2 path types: Stringent, Stringent Bi-level, tolerant and all their combinations need to be configured according to the traffic class carried over user plane VCC. To ensure reliable QoS, it is recommended to use the stringent AAL2 path with CBR service category for RT DCH, SRB on HSPA and CS voice on HSPA traffic types. Stringent Bi-level AAL2 path with UBR+ is recommended for NRT DCH and Streaming HSPA traffic and tolerant AAL2 path with UBR+ service category for HSPA services.

THP can be used for interactive NRT traffic, to distinguish delay-sensitive or non-sensitive traffic. Sensitive NRT traffic is assigned then 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.

VCC for real-time and non-real time user traffic has to be always configured on a route, using either both DCH Stringent and DCH Stringent Bi-level VCCs or DCH Stringent & Stringent Bi-level VCC type. The user plane VCCs for HSDPA and HSUPA traffic are necessary only if required. In case of RT type of services on HSPA (for example SRB on HSPA, Streaming HSPA or CS over HSPA) both DCH & HSPA Stringent and DCH & HSPA Stringent Bi-level VCCs are required or DCH & HSPA Stringent & Stringent Bi-level. These combinations may be used interchangeably. One or more VCCs of each type can be configured on a route between BTS and RNC.




Issue 01G

For more information on Iub VCC combinations supported in RAS06 (NRT HSPA), RU10 (streaming HSPA), RU20 (SRB on HSPA) and RU20 On Top (CS voice over HSPA), see WCDMA RAN ATM Transport.

For each path type separate AAL2 admission control (CAC) algorithm is applied in the DL and UL. Since each AAL2 path may contain several various AAL2 PT values, AAL2 CAC algorithm associated with the traffic type is call-specific.

Introduced in RU10, the RAN1253 Iub Transport QoS feature allows aligning QoS transport strategy with radio layer classification based on UMTS traffic classes, THP and ARP priorities. Thus, transport bearers of various connection types may be freely mapped to AAL2 priorities (AAL2 path type and AAL2 priority queue) at ATM transport. The same AAL2 priority mappings are used in the UL (Flexi BTS) and the DL (new NPS1 HW) direction. The default AAL2 path types are applied for the VCC selection if the RAN1253 Iub Transport QoS feature is not configured for the given BTS in the RNC configuration.

4.2 Iub VCC configuration dimensioning

If 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 and ANT_3G tool. The dimensioning of HSDPA/HSUPA VCC is based on the data rates to be supported. See section 4.5.7 HSPA traffic 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 the PCR value, except for RNC2600 platform, where shaping is done with VCC bundle only. Also, with new NPS1 HW (RNC2600) when VCC bundle is in use, CBR VP must be set to unshaped. In the BTS, traffic shaping to UBR+ PCR is performed, only in 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. The bandwidth sharing between UBR+ connections using the same ATM link can be tuned with the weight and MDCR values.

49/


DN0980058

Issue 01G



4.2.1 Downlink VCC bundle

The VCC bundle functionality in the downlink is provided as a part of features RAN1100: Dynamic Scheduling for NRT DCH with Path Selection and RAN1099: Dynamic Scheduling for HSDPA with Path Selection. VCC bundling is allowed if either one or both of the above 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 has to be configured to be equal with the minimum link size of the route from the RNC to the BTS, to avoid traffic loss between the RNC and BTS. At maximum two VCC bundles can be configured. The main use of the second bundle is the hybrid BTS backhaul feature. In case of the 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:

RNC shapes UBR+ VCs according to the PCR value or to a 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 bandwidth 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 more information on VC bundle configurations supported, see WCDMA RAN ATM Transport document.

For example, in a 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 VCC Bundle EBS = 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) Even though there is no unallocated bandwidth in the bundle, unused capacity in the bundle at a given time stamp is shared among NRT DCH and HSDPA traffic according to the EBS parameter. Simultaneously, the MDCR parameter guarantees minimum bandwidth for UBR+ VCCs.

4.2.2 Uplink VCC bundle

There is 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. If the VCC bundle is active, the BTS




Issue 01G

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, these MDCR reservations are subtracted from the total available link capacity. This means that MDCR parameter can be used to reserve some capacity for HSUPA traffic in the uplink. Therefore, the MDCR of UBR+ VCC for NRT DCH traffic has to be set to zero, so that no additional capacity is reserved. The UBR share parameter has to be set 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 the downlink. However, too heavy overbooking may lead to traffic loss, because there is no flow control mechanism in the uplink to limit the throughput in congestion situation.

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 4.2 Iub VCC configuration dimensioning based on the call mix to be supported.

Calculate according to rules given in 4.2 Iub VCC configuration 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 4.2 Iub VCC configuration dimensioning

zero, if uplink VCC bundle is active. If no VCC bundle is used, calculate the value according to the rules given in 4.2 Iub VCC configuration dimensioning

UBR/UBR+ PCR for HSPA/HSDPA/HSUPA* (tolerant) VCC

Equal to VCC bundle PCR*** Equal to maximum capacity for user traffic 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 4.2 Iub VCC configuration dimensioning

Capacity that is guaranteed for HSUPA traffic in the uplink. **

UBR+ UBR Share for NRT DCH and NRT HSDPA VCCs

Weight that is used to share the bandwidth 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 the 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 the uplink.

51/


DN0980058

Issue 01G



Parameter (ATM EP, AAL2 PT)

RNC egress / ingress BTS egress / ingress

VCC Bundle EBS

(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 13: Parameter value selection with Path Selection and HSUPA

* Example description DCH/HSPA* VCC (stringent) is equivalent either to DCH VCC (stringent) or HSPA VCC (stringent) or DCH & HSPA VCC (stringent). In case of VCC with AAL2 PT combinations (for example Stringent & Stringent Bi-level, Stringent Bi-level & Tolerant, Stringent & Stringent Bi-level & Tolerant) needed traffic bandwidth have to be calculated separately according to the rules given in 4.2 Iub VCC configuration dimensioning and the total VCC bandwidth is the sum of calculated traffic. **The MDCR value is used to reserve certain capacity from the ATM layer CAC, similarly as CBR VCC PCR. The MDCR values for HSPA VCCs should be selected based on the estimated average throughput during the busy hour plus some safety margin to allow for bursts. The HSDPA uplink traffic volume is expected to be low if compared to the downlink, because there are only the HS-DSCH capacity allocations transported. The same applies to HSUPA and downlink traffic. If the MDCR value is set too low, the ATM layer congestion may take place in hub sections, where several BTSs share the same link and use shared resources. The exact numbers depend on the number of BTSs sharing the common link and 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. In other words, 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.

4.3 Iub VPC configuration

The 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 the following figure.




Issue 01G

Figure 12: 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 (Path 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. Alternatively, one can group, for example, all HSDPA VCCs into the same VPC and separate those in the hub point to different BTS sites. In addition, the Path Selection does not have any restriction of 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 case when any VP contains both CBR VCCs and UBR+ VCCs, it must be set up to CBR VP, that is CBR VCCs are not allowed within UBR VPs.

Figure 13: 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 the table below.

53/


DN0980058

Issue 01G



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 14: Parameter value selection for VP layer

4.4 ATM-based Iub dimensioning

4.4.1 AAL2 Connection Admission Control

The AAL2 Connection Admission Control (CAC) in the 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. CAC algorithm for R99 RT and conversational HSPA services differs among RNC hardware used: A2SU units implement QT algorithm and NPS1 units – RT_AVE. Detailed mapping between services path types and CAC algorithm used are available in RNC AAL2 CAC: Path type and AAL2 CAC algorithm, in WCDMA RAN ATM Transport Customer Documentation. A detailed evaluation of both CAC algorithms for a given call mix can be made using ANT_3G dimensioning tool starting with v3.0.2. The 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, comparing 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. To avoid congestion and decreased service quality, further optimization of AF values for different bearer types has to be done carefully, based on testing or measurement data from the network. The RAS06 feature Dynamic Scheduling for NRT DCH with Path Selection (RAN1100) provides a back-pressure mechanism to slow down user data rates in




Issue 01G

a controlled way in the congestion situation. It is recommended to use this optional feature together with Transport Bearer Tuning. The default values of the AF for NRT DCH bearers, when feature Dynamic Scheduling for NRT DCH with Path Selection is enabled, is 0.75. Further optimization is possible by performing AF tuning for each NRT DCH bearer type. The following limitations apply for 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: 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).

4.5 ATM-based Iub dimensioning methods

In 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.

4.5.1 Option 1

RT services dimensioned using the Multi-Dimensional-Erlang approach (services carried by CS and PS real-time RAB’s, includes CS over HSPA and HSPA Streaming services).

Multi-Dimensional-Erlang is an extended Erlang B algorithm. It allows to calculate the probability of call loss on a group of circuits in a multi-dimensional environment (more services sharing the same transport resource). For details, see the 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, see the teletraffic engineering theory.

- Dimensioning independent of the bearer’s activity (TBT)

-For CAC 100% AFs are accounted

55/


DN0980058

Issue 01G



HSPA NRT traffic is dimensioned separately.

This option is a preferred one. It is especially helpful in cases where no detailed information on bearer’s activity is available.

4.5.2 Option 2

Based on direct definition of Parallel Connections without considering QoS when 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 connections.

HSPA NRT traffic is dimensioned separately. This option is recommended for cases where direct Parallel Connection is preferred as input.

Which option to choose depends on the QoS requirements and availability of the input parameters. NOTE:

The methods described here are only proposals. Operators can apply their own calculation process if required.




Issue 01G

4.5.3 Option 1: MD-Erlang for real time; QoS by M/G/R-PS for best effort PS R99 and HSPA NBR

CAC

algorithm

Weighting and Rounding rules

MGR-PS(Total Mean on single RAB)

Repeated for each RAB

MD-

Erlang

Seperate Dim. with min QoS

Bandwith

demand Weighting

over RAB

mean rate

HSPA NRT

- Traffic Model input

- QoS global for HSDPA

„worst case“ M/G/R-PS

New function

PS NRT, HSPA NBR


- QoS via Delay percentage

- CommonCH

Max over loop results

∑Input 1:

RealTime with QoS

Access Dimensioning Option 1:

RealTime with QoS , R99 NonRealTime with QoS (MGR-PS)

DCCHs

Loop Loop

ParaCon =

BW /

effectivePeak

- effective Peak

HSPA NRT Bandwidth demand

(cps or kbps)

∑ bandwidth / Linkbandwidth

Bandwidth demand

(cps or kbps)

∑ of Gross mean rates



Input 2:

NonRealTime w/o QoS

CS, PS RT, HSPA GBR


- QoS via blocking percentage

Parallel Connections incl.

SHO on service level

(whenever applicable)

Resulting number of

physical lines

Figure 14: Iub dimensioning option 1

4.5.4 Real-time traffic

The following steps are needed for the calculation 1. MD-Erlang bandwidth calculation Multi-Dimensioning-Erlang approach is used for real time services (using CS, PS real-time and HSPA Streaming RAB’s). The Gross Peak Rate is defined on ATM level including AAL2/ATM overhead and accompanying DCCH. Apart from HSDPA services, the Offered Traffic [Erlang] should also include SHO factor.

Bandwidth MD-Erlang = MD-Erlang [ Erlang DCH; Gross Peak Rate; Blocking-percentage ]

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, that outcome is not an integer, so it has to be rounded up to the next greater integer.

Parallel Connections DCH = round-up [ Gross mean Rate B Hincl QoS / Gross Peak Rate ]

57/


DN0980058

Issue 01G



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 in the total rate going below the one determined by MDE before. Bandwidth = ∑ [ Parallel Connections DCH × Peak Rate ] =< Bandwidth via MD-Erlang

NOTE:

It might happen that all connections of the lowest bearer rate are eliminated (so connection number is zero), 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 the CAC result point of view this is the worst case concerning requested bandwidth.

4.5.5 Non-real time traffic

Dimensioning of PS NRT and NBR HSPA services is modified. For this purpose, M/G/R-PS with a 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:

M/G/R-PS assumes a full utilization of bearers whenever data is transferred, thus 100% activity has to be used for CAC.

Even though CAC is not performed during establishment of HSPA NBR services, the throughput offered by these services is taken into account in Iub dimensioning to reserve appropriate amount of bandwidth on Iub interface.

Ways of calculating formulas: 1. Calculate the 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 Parallel Connections DCH NRT (Service) = round-up [Bandwidth MGR-PS

(Service) / Gross peak rate(Service) ]




Issue 01G

4. Repeat for all NRT services 5. Call CAC including real-time part for each NRT services case separately CAC(service) = CAC[ real-time part; CCCH; Parallel Connections DCH NRT

(Service) ; CAC values(service) ]

where: CAC values(service) = CAC values(related RAB)

= vector [ max size(RAB); max rate(RAB), average size(RAB), average

rate(RAB) ]

6. Take the maximum of all CAC results as the final result (the worst case). Total BW result = max [ CAC (service) ] Total CAC result demand is used to calculate Iub bandwidth demand together with HSPA bandwidth demand, as described in 0 Calculation of total Iub bandwidth demand

4.5.6 Option 2: CAC directly via “parallel connections”

CAC

algorithm

Parallel Connections incl.

SHO on service level

(whenever applicable)

Direct Parallel

Connections

inputCS, PS RT, HSPA GBR


- QoS via Parallel Connections

PS NRT


- QoS via Parallel Connections

Option 2:

No QoS consideration, direct input of Parallel Connections

Bandwidth

demand

(cps or kbps)

- CommonCH

∑ DCCH’s

Seperate Dim. with min QoS

HSDAP nonRT


- QoS global for HSDPAHSPA NRT Bandwidth

demand

(cps or kbps)

∑ bandwidth /

Linkbandwidth

Resulting number of

physical lines

Figure 15: Iub dimensioning option 2

This option allows choosing CAC input independently of the dimensioning rules.

59/


DN0980058

Issue 01G



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):

Parallel Connections DCH >= round-up [ Erlang DCH session’s (at BTS) ]

Meaning, used number of Parallel Connections DCH must be greater or equal to

the up-rounded Erlang value from the traffic model (see User traffic demand modeling) expected at a specific BTS.

4.5.7 HSPA traffic dimensioning

The 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 18.

Optionally, on top of the mean rate based option, some percentage of QoS overhead can be added to account for instantaneous I/B HSPA bursts above the average value. Typical QoS factor values are around 20%.

4.5.7.1 HSDPA and protocol overheads

HSDPA protocol stack is presented in the following figure.




Issue 01G

PDCP

RLC

Frame Protocol

Transport

MAC-d

MAC-hs /

MAC-ehs

PHY

MAC-hs /

MAC-ehs

PHY

PDCP

RLC

MAC-d

Transport

PHY PHY

Frame Protocol

UE BTS RNCUu Iub IuPS

DL

Application Application

Figure 16: HSDPA protocol stack

ATM User Data Rates on Iub generated by different UE categories are presented in the following tables. Target BLER of 10% has been assumed.

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 15: HSDPA protocol overheads (RU10, 10% BLER)





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 (MIMO 64QAM) 38.22 42.44 46.41

61/


DN0980058

Issue 01G







42.2 (DC-HSDPA / 64QAM)

38.22 38.58 46.41

84.4 (DC-HSDPA with MIMO)

76.44 77.30 92.94

Table 16: HSDPA protocol overheads (RU20/RU30, Flexible RLC, 10% BLER)

NOTE: In order to calculate the total Iub capacity required to serve the HSDPA Data Rates listed in the tables, additional assumptions on Iub signaling, Control Channels and O&M bandwidth demands are needed.

Average RLC – ATM overhead for HSDPA user plane varies within the range of 25 – 35 % in the case of RU10 and 20 – 30% in the case of Flexible RLC. The overhead depends on the actual rate utilized by the application layer.

4.5.7.2 HSUPA and protocol overheads

HSUPA protocol stack is presented in the following figure.

PDCP

RLC

Frame Protocol

Transport

MAC-d

MAC-es

MAC-e

PHY

MAC-e

PHY

PDCP

RLC

MAC-d

MAC-es

Transport

PHY PHY

Frame Protocol

UE BTS RNCUu Iub IuPS

UL

Application Application

Figure 17: HSUPA protocol stack

In 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.




Issue 01G

4.5.7.3 HSUPA QoS streaming

The RU10 RAN1004: Streaming QoS for HSPA feature allows serving streaming QoS class RAB on HSPA. In previous releases such streaming traffic was only possible using R99 DCH. The 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 the RNC and by BTS HSUPA and HSDPA packet schedulers. The schedulers take the Scheduling Priority Indicator (SPI) value into account. Different weights are defined per priority queues based on SPI class. Within a class of common SPI flows proportional fair scheduler is used.

Streaming traffic usually is characterized by sensitive time relations (delay variation) between information entities (for example PDUs) of a stream. The streaming traffic is not very sensitive in terms of requirements for low transfer delay. For RT HSPA traffic admission control is supported within the transport network based on the guaranteed bit rate (GBR). Additionally, the RAN1004: Streaming QoS for HSPA feature enables in the RNC configurable Nominal Bit Rate (NBR) for NRT traffic classes, which can be used as the targeted minimum bit rate on the air interface, for example based on subscription. In the scheduler, NBR has a higher priority than best effort traffic, but a lower priority than GBR of real time users. Typical applications which can be characterized as streaming are real time video download or video sharing.

For a new service or subscriber connection, CAC is performed using downlink and uplink GBR or NBR requirements respectively over both IP and ATM transport networks. Additionally, the QoS Aware HSPA Scheduling feature includes prioritization in the Iub frame protocol (FP) layer. It also adds QoS awareness to HSUPA Congestion Control and HSDPA Congestion Control features. For more information see features: RAN 1004 Streaming QoS for HSPA and RAN1262 QoS Aware HSPA Scheduling.

The dimensioning method for streaming traffic on HSPA over Iub interface is based on the procedure for real time CS services described in 4.4 ATM-based Iub dimensioning(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-percentage) per service class I. If not specified by the operator, call blocking probability for RT HSPA services are the same as for R’99 streaming services. Traffic intensity ErlangRT_HSPA needs to be evaluated on the basis of input traffic model. Appropriate dimensioning for streaming services requires defining of the corresponding application type to be used by the end users. Therefore, Gross Effective BW value needs to be calculated on the basis of the effective codec bit rate for a dedicated streaming service and corresponding transport overhead.

NOTE: The effective codec bit rate (for example for VoIP services) might change, depending on whether header compression is used or not.

Bandwidth MD-Erlang = MD-Erlang [ Erlang RT HSPA; Gross Effective BW; Blocking-percentage ]

63/


DN0980058

Issue 01G



Example of VoIP service with AMR codec 12.2:

Effective peak rate is 29,4kbit/s (calculated as the 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 Effective BW = 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, the resources calculation of the required bandwidth is done with the MD-Erlang method for all RT services together.

With the assumptions of different transport resources for R’99 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, in case when a single transmission media is used for transmission (for example an ATM network), but RT HSPA traffic and CS traffic are VCC separated. In this case, estimation of the number of simultaneous connections has to be done separately for RT CS and RT HSPA services.

4.5.8 AAL2 channels limitation check

As a result of Dimensioning Option 1 or 2 described in 4.4 ATM-based Iub dimensioning a number of parallel connections for a certain service are available. Additionally, the number of parallel connections for NRT HSPA services is estimated with the use of its round-up Erlang value with SHO consideration for non-HSDPA bearers (UL HSUPA, DL/UL SRB, UL SRB on HSPA). The resulting number of parallel connections should be checked against AAL2 Channels (CID) requirements per certain service ATM configuration, which is assumed for the dimensioning in the context of mapping between bearers and VCC types.

The resulting number of VCCs of certain type can be estimated with the following formula:

248/_2## ___ typeVCCtomappedType channelsAALroundupVCCs

where:




Issue 01G

TypeVCCs# - provides a number of VCCs of a certain type (for example

DCH(Stringent))

typeVCCtomappedchannelsAAL ____2# - total number of CIDs, which occupy

certain VCC Type for a given call mix

Every time the number of VCCs of a certain type exceeds one, CAC bandwidth calculation should be performed for each VCC, that is for the number of parallel connections distributed over the VCCs.

The following table provides an overview of AAL2 channels (CIDs) occupied by the respective call type:

Service CID demand

Common Channels 4 per cell (without SAB feature)

HS Common Channels 2 (HS FACH) + 2 (HS RACH) per cell

CS R99 (AMR or data) 2

AMR on HSPA 4

PS R99 (NRT or streaming) 2

HSPA (SRB on DCH) 3

HSPA (SRB on HSPA) 4

Table 17: Table CID demand for a certain call types

NOTE:

In most cases CID demand is distributed among different VCC types, for example in case of HSPA NRT call with SRB on DCH:

HSDPA u-plane is mapped to HSDPA (Tolerant) or HSPA (Tolerant) type

HSUPA u-plane is mapped to HSUPA (Tolerant) or HSPA (Tolerant)

SRB on DCH is mapped to DCH (Stringent) Type

For more information on mapping services to path types, see chapter RNC AAL2 CAC: Path type and AAL2 CAC algorithm in WCDMA RAN ATM Transport Customer Documentation.

Example calculation

Assumptions:

3 cells

call mix:

-80 parallel AMR calls,

-50 parallel active PS NRT calls

-10 parallel active HSPA NRT calls,

65/


DN0980058

Issue 01G



VCC configuration:

-DCH (Stringent & Stringent Bi-level)

-HSPA (Tolerant)

Calculation of CID demand:

a) DCH (Stringent & Stringent Bi-level) VCC:

)_&(_2# levelbiStringentStringentDCHchannelsAAL 3 · 4 (CCHs) + 2 ·80 (AMR)

+ 2 · 50 (PS NRT) + 10 (SRB from HSPA NRT calls) = 282

2 VCCs required (CAC applied for each VCC separately)

b) HSPA (Tolerant) VCC:

)(_2# TolerantHSPAchannelsAAL 10 (u-plane from HSPA NRT calls)

1 VCC required

4.5.9 Calculation of total Iub bandwidth demand

Based on the results achieved after using one of the options described above and the defined HSDPA demand for mean and peak rate level, the total Iub bandwidth demand is estimated as shown in the figure:




Issue 01G

Non user data traffic demand:

- CNBAP

- DNBAP

- ALCAP (ATM Transport only)

- O&M

U-Plane R99 data traffic demand, incl.:

- R99 U-Plane traffic demand,

- DCCH traffic (including HSPA related),

- CCH,

Dimensioning methods described in

Dimensioning WCDMA RAN document.

HSDPA mean rate

HSDPA transport OH

QoS overhead

HSPA Control Traffic

HS

PA

avera

ge tra

ffic

ap

pro

ach

(Poin

t 1)

HSDPA transport OH

(peak rate specific)

HSDPA Peak

Rate demand

(RLC SDU level)*

HSPA Control Traffic

HS

PA

peak r

ate

ap

pro

ach

(Poin

t 2)

max

Total Iub last

mile’s

bandwidth

* RLC SDU HSDPA peak rate is separately defined in ANT_3G tool (BTS Configuration editor)

Figure 18: Iub bandwidth demand

In addition to calculated bandwidth demands based on HSDPA mean rate (left portion of the bandwidth), the described evaluation takes into account possible requirement related to maximum achievable HSDPA peak rate per given BTS. NOTE:

Customers might have different requirements regarding Iub bandwidth demand calculation. For example HSDPA peak throughput per cell might be demanded, instead of the ‘per BTS’ requirement.

RU20 main, RU20 On Top and RU30 HSPA+ features increase HSPA Peak Rate Demand per BTS. For updated calculation of RLC SDU peak rate figures and corresponding transport overhead for various UE Categories, see next chapter.

67/


DN0980058

Issue 01G



5 IP-based Iub

5.1 IP-based Iub dimensioning

IP-based Iub dimensioning allows determining the capacity-related components presented in the figure below.

Figure 19: IP-based Iub dimensioning components

IP_Route_Committed_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 (cf. Sec. 0).

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. Traffic shaping is done against this parameter 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.

RNCBTS 1

Non CAC-

guaranteed traffic

CAC

guaranteed

traffic

Non-guaranteed

traffic

BTS 2

CAC

guaranteed

traffic

Non-guaranteed

traffic

Shared_BE

IP_AllocationIPR

ou

te1

_B

w

Non CAC-

guaranteed traffic

Shared_BE

IP_Allocation

CAC guaranteed

traffic

IP_Route

Commited_BW

IPR

ou

te2

_B

w

Rn

c_E

the

rne

t_C

ap

CAC guaranteed

traffic

IP_Route

Commited_BW

IP_Route 1

IP_Route 2

Iub_Eth_Cap

Iub_Eth

_Cap

RNCBTS 1

Non CAC-

guaranteed traffic

CAC

guaranteed

traffic

Non-guaranteed

traffic

BTS 2

CAC

guaranteed

traffic

Non-guaranteed

traffic

Shared_BE

IP_AllocationIPR

ou

te1

_B

w

Non CAC-

guaranteed traffic

Shared_BE

IP_Allocation

CAC guaranteed

traffic

IP_Route

Commited_BWCAC guaranteed

traffic

IP_Route

Commited_BW

IPR

ou

te2

_B

w

Rn

c_E

the

rne

t_C

ap

CAC guaranteed

traffic

IP_Route

Commited_BWCAC guaranteed

traffic

IP_Route

Commited_BW

IP_Route 1

IP_Route 2

Iub_Eth_Cap

Iub_Eth

_Cap




Issue 01G

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. Traffic shaping is done against this parameter in order to not exceed the configured Ethernet link capacity for a given port.

IP-based Iub dimensioning is impacted by the following functional components:

IP DiffServ, including the implementation of the IP DiffServ scheduler in RNC and BTS

IP Connection Admission Control (CAC) function

They are briefly summarized in the following sections.

5.1.1 IP Differentiated Services (DiffServ)

QoS 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: 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. The values of these parameters 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). For the mapping process, respective Ethernet priority code points (PCP) are used. Also, the scheduling scheme on the Ethernet layer corresponds to the scheduling scheme specified for the IP layer. Possible UMTS service class to DiffServ PHB mapping schemes are illustrated in the following figure:

69/


DN0980058

Issue 01G



Figure 20: Possible transport QoS mapping schemes on IP-based Iub

An example of how UMTS transport bearers can be mapped to DiffServ PHBs is shown in Table 18: Example of IP transport QoS mapping on Iub. NOTE:

UMTS traffic class to PHB mapping is operator configurable. The table shows only one example of such mapping.




Issue 01G

Table 18: Example of IP transport QoS mapping on Iub

The assumed mapping of UMTS class to PHB and the DiffServ scheduler implementation in RNC and BTS determine the actual dimensioning process. With the current implementation of the DiffServ scheduler the traffic within each PHB is served by a separate queue to access the link resources, as shown in Figure 21: DiffServ scheduler implementation at RNC/BTS. Scheduler is implemented on each logical Iub.

IP Link

(IP_Bw Total) Q1

Q2

Q3

Q4

EF

AF4

AF3

AF2

W1

W2

W3

SP

WFQ

Q5

Q6

W4

AF1

BE

W5

Interface

Shaping

Figure 21: DiffServ scheduler implementation at RNC/BTS. Scheduler is implemented on each logical Iub.

UMTS transport bearer

UMTS Service class

DSCP Value

(default) PHB to be used

VLAN p-priority

(default)

CS C, PS C incl. DCCHs

Conversational 0b101110 (46) EF 6 “Voice”

Timing over Packet - 0b101110 (46) EF 6 “Voice”

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



HSPA I/B Background 0b000000 (0) BE 0 “Best Effort”

71/


DN0980058

Issue 01G



Expedited Forwarding (EF) PHB of the highest priority is served with a strict priority (SP) queue. In other words, the lower priority PHBs can be served only if the EF queue is empty. The lower priority PHBs: Assured Forwarding 4 -1 and Best Effort are controlled with a Weighted Fair Queue (WFQ) scheduler, which means their access to the link resources is proportional to the assigned WFQ weights (w1-5). It is assumed that PHB classes with a higher forwarding priority are assigned higher WFQ weights. If one of the queues for AF4-1 and BE PHB is empty, the spare capacity of this queue is shared among the other PHBs. Before accessing the IP link, the total traffic from all PHBs is shaped against the configured IP link bandwidth on Iub.

Assume the following notation, as shown in Figure 22: IP bandwidth components on Iub:

IP_Bw – IP bandwidth allocated on Iub.

Offered_traffic k – Mean offered traffic within k-th PHB class.

IP_Bw k – IP bandwith on Iub for k-th PHB class.

w k – WFQ scheduler weight for k-th PHB class.

IP_Bw EF

IP_Bw AF4

IP_Bw AF3

IP_Bw AF2

IP_Bw AF1

IP_Bw BE

Offered_Traffic EF

Offered_Traffic AF4

Offered_Traffic AF3

Offered_Traffic AF2

Offered_Traffic AF1

Offered_Traffic BE

WFQ

SP

IP_Bw

Figure 22: IP bandwidth components on Iub

IP bandwidth available to AF 4-1 and BE PHB classes is limited by their assigned WFQ weights, according to the following formula:

EFk

k

kEFk

w

wBwIPBwIPBwIP )__(_ (1)

where:

IP_Bw is the total IP bandwidth on Iub.




Issue 01G

5.1.2 IP Connection Admission Control

IP CAC algorithm decides whether to admit an incoming RAB connection on the basis of the available Iub bandwidth. It is performed in RNC in the DL, separately for each logical Iub, and in BTS in the UL. Subject to IP CAC are the following RABs:

Rel’99 RT DCHs (CS/PS) CS Voice over HSPA Rel’99 NRT DCHs (PS) DCCHs (over DCH and HSPA), CCHs RT HSPA (RT HSPA is subject to CAC only when features RAN1004 Streaming

QoS for HSPA and RAN 1262 QoS Aware HSPA Scheduling are activated)

NRT HSPA is not subject to CAC. IP CAC-guaranteed capacity (CAC_Guaranteed_BW) per single transport bearer is calculated by applying to each bearer a set of traffic descriptors:

MAX_Bitrate – maximum bitrate in IP payload layer AVE_Bitrate – average bitrate in IP payload layer

IP CAC-guaranteed capacity is calculated in the following way: CAC_Guaranteed_BW Service = 0.2 × MAX_Bitrate Service + 0.8 × AVE_Bitrate Service

Each bearer type has its own set of traffic descriptors for the DL and the UL separately. The values of IP CAC traffic descriptors for some selected Rel’99 RABs are presented in Table 20: CAC traffic descriptors and bit rates for selected Release 99 and DCCH-over-HSPA bearers. The total CAC-guaranteed bandwidth for a user service is a sum of the CAC-guaranteed bit rates of DTCH and DCCH channels: For Rel’99 services:

CAC_Guaranteed_BW Service = CAC_Guaranteed_BW Service_DTCH + CAC_Guaranteed_BW Service_DCCH

For HSPA services admitted with CAC and DCCH over DCH:

CAC_Guaranteed_BWService=CAC_Guaranteed_BWService_HS-DSCH + CAC_Guaranteed_BW Service_DCCH_over_DCH

For HSPA services admitted with CAC and DCCH over HS-DSCH: CAC_Guaranteed_BW Service = CAC_Guaranteed_BW Service_HS-DSCH + CAC_Guaranteed_BW Service_DCCH_over_HS-DSCH

73/


DN0980058

Issue 01G



An incoming service connection on Iub is admitted by CAC, provided that the residual Iub bandwidth is more than or equal to CAC_Guaranteed_BW Service.

NOTE:

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 20: CAC traffic descriptors and bit rates for selected Release 99 and DCCH-over-HSPA bearers.

Recommended DCCH type for Iub dimensioning is DCCH 13.6 SET 3 for DCCH over DCH

IP CAC traffic descriptors for HSPA are defined for HSPA bit rates in steps of 8 kbps between 0 and 512 kbps, and with steps of 32 kbps between 512 and 2048 kbps. They are used in the following way to calculate CAC_Guar_Bitrate HSPA:

For RT HSPA, MAX_Bitrate and AVE_Bitrate are selected on the basis of the Guaranteed Bit Rate (GBR) requirement received from the Core Network.

For RT HSPA, the GBR is scaled by 1.25 for DL, 1.1 for UL and next rounded up to the next applicable HSPA bit rate, and the corresponding Max_Bitrate traffic descriptor is picked up. Ave_Bitarte is selected in the same way but without scaling GBR value. For example, in case of an HSPA Streaming RAB carrying VoIP with GBR rate set to 30 kbps, the selection for Max_Bitrate is rounded up to 38 kbps and the selection for Ave_Bitrate is rounded up to 30 kbps for DL. Thus, the corresponding traffic descriptors in DL are as follows:

Max_Bitrate = 55.6 kbps, Ave_Bitrate = 47.6 kbps. The CAC guaranteed bandwidth in DL is equal to:

CAC_Guaranteed_BW HSPA (DL) = 0.2 × 55.6+ 0.8 × 47.6 = 50.4 kbps

Bandwidth reservation for Nominal Bit Rate (NBR) HSPA RABs, even though CAC is not performed in the RNC, is taken into account in DL Iub dimensioning process and calculated in the same manner as for RT HSPA RABs. The bandwidth reserved for a HSPA RAB with the NBR set to 128 kbps equals to: CAC_Guaranteed_BW HSPA = 0.2 × 177.6 + 0.8 × 145.6 = 152 kbps The RNC sends the NBR value configured by the operator to the WBTS, which is responsible for allocation of the respective bandwidth on the air-interface. NOTE:

If the feature RAN1096 Transport Bearer Tuning is activated, the AVE_Bitrate parameter is scaled by Activity Factor and the scaled value is used instead of plain AVE_Bitrate value.




Issue 01G

5.2 IP-based Iub dimensioning methods

U-plane CAC-guaranteed bandwidth is calculated separately for RT and NRT u-plane traffic. Various dimensioning methods are used for the bandwidth calculation. The following sections present the appropriate dimensioning methods.

5.2.1 Dimensioning CAC-guaranteed u-plane RT traffic

It is recommended to dimension the RT traffic (Conversational and Streaming Rel’99 DCHs, Streaming HSPA, CS Voice over HSPA) with MD-Erlang formula. Dimensioning is carried separately for each DiffServ PHB class grouping this type of traffic. The input parameters for MD-Erlang formula are:

CAC Guaranteed Bandwidth

Offered Traffic

Blocking probability

5.2.1.1 CAC Guaranteed Bandwidth

CAC Guaranteed Bandwidth is the sum of CAC_Guaranteed_BWService for RT DTCH and DCCH bearers:

CAC_Guaranteed_BWService = CAC_Guaranteed_BW DTCH +

CAC_Guaranteed_BW DCCH

5.2.1.2 Offered Traffic

Offered_trafficService is the mean traffic per service in [Erlang] extended with SHO_factor:

Offered_trafficService = Mean_traffic Service × (1+ SHO_Factor)

The value of Mean_traffic Service is defined by the operator. Alternatively, it can be taken from the traffic model. Assumed SHO_Factor value is 30%. NOTE:

For HSPA in DL the soft handover is not considered (SHO_Factor = 0).

75/


DN0980058

Issue 01G



5.2.1.3 Blocking probability

Blocking probability (Bl_Pr Service) is the service blocking probability. Usually assumed values are 0.1% – 1%. NOTE:

Having the RT traffic in many PHBs overdimensions the link capacity demand when compared with the case where the RT traffic is distributed among fewer PHBs. Therefore, from the dimensioning viewpoint, the RT traffic should be distributed among as few PHBs as possible.

5.2.2 Dimensioning CAC-guaranteed u-plane NRT traffic

CAC-guaranteed bandwidth for the NRT traffic (Interactive/Background Rel’99 DCHs and I/B HSPA with NBR configured) can be calculated with the use of one of the two options described further in this section. In each case the needed bandwidth has to be calculated separately for each DiffServ PHB class grouping this type of traffic.

5.2.2.1 Option 1

With this option the CAC-guaranteed bandwidth for NRT traffic is calculated by estimating the number of parallel connections in Busy Hour for NRT services and applying the corresponding traffic descriptors to them. The number of parallel connections for a given NRT service is calculated as follows:

Parallel connections Service= round-up [Offered_trafficService / (Service_bitrate ×

Activity_factor Service)]

where:

Offered Traffic Offered_traffic Service is the mean traffic per service in [kbps] extended with

SHO_factor:

Offered_traffic Service = Mean_traffic Service × (1+ SHO_Factor)

Service_bitrate Service_bitrate is the nominal service bit rate in [kbps] above the Frame Protocol level. In the case of HSPA, this is the nominal bit rate, as specified by the operator.

The CAC-guaranteed bandwidth for a given NRT service is calculated as follows:




Issue 01G

NRT_U-Plane_committed_BW Service = Parallel connections Service ×

(CAC_Guaranteed_BW DTCH + CAC_Guaranteed_BW DCCH )

The total NRT u-plane bandwidth per PHB is calculated as the sum of bandwidths needed for individual services:

NRT_U-Plane_committed_BW PHB = PHB Service

NRT_U-Plane_committed_BW

Service

NOTE: This option does not explicitly take into account any QoS parameters for example in terms of blocking or transfer delay assurances in dimensioning of NRT traffic. Instead, it is assumed that the effective bandwidth demand for individual services is tuned via the activity factor with the transport bearer tuning feature.

5.2.2.2 Option 2

Alternatively, the CAC-guaranteed bandwidth for NRT traffic can be calculated with M/G/R/N-PS formula. The input parameters for MD-Erlang formula are:

Total Offered Traffic

Gross Peak Rate

CAC Guaranteed Bandwidth

Mean File Size

Transfer Delay

5.2.2.3 Total Offered Traffic

Total_offered_traffic is mean traffic summed over all NRT services:

Total_gross_offered_traffic = Service

Mean_trafficService × (1+

SHO_Factor)

5.2.2.4 Gross Peak Rate

Gross peak rate Service, is the sum of MAX_Bitrate Service for NRT DTCH and DCCH bearers:

Gross_peak_rate Service = MAX_Bitrate DTCH + MAX_Bitrate DCCH

77/


DN0980058

Issue 01G



5.2.2.5 CAC Guaranteed Bandwidth

CAC_Guaranteed_BW Service, is a sum of the CAC guaranteed bandwidths for NRT DTCH and DCCH bearers: CAC_Guaranteed_BW Service = CAC_Guaranteed_BW DTCH +

CAC_Guaranteed_BW RAB_DCCH For I/B HSPA, if subject to CAC, DCCHs are not considered.

5.2.2.6 Transfer delay

Transfer delay Service is the maximum tolerable transport delay of IP packets on the last mile link. It reduces the effective bit rate perceived by the end-user of an NRT application, as compared with the nominal CAC_Guaranteed_BW. Suggested values of Transfer delay Service on Iub are 5-10%.

5.2.2.7 Mean File Size

Mean_file_size Service [kb] - average size of a TCP file per service,

With this set of inputs, M/G/R-PS is repeated separately for each NRT service, and the maximum value over all calculations is selected.

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.

NOTE: Having the NRT traffic in many PHBs results in overdimensioning the link capacity demand when compared to the case where NRT traffic is distributed among fewer PHBs. Therefore, from the dimensioning viewpoint, the NRT traffic should be distributed among as few PHBs as possible.

5.2.3 Dimensioning other CAC-guaranteed traffic components

Besides RT and NRT u-plane traffic (Rel’99 + 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 the DL and RACH in the UL, multiplied by the number of cells per BTS. The CAC-guaranteed bandwidth is calculated based on the traffic descriptors, by default: 0.2 × Max + 0.8 × Ave.




Issue 01G

Table 19: The IP traffic descriptors and Ethernet overheads for u-plane CCH traffic.

(*) Listed RACH IPTD values refer to the case where RACH-capacity-based transport reservation functionality is disabled. For more information, see RACH Transport Capacity Reservation Dependent on Air-interface Capacity in WCDMA RAN and I-HSPA IP Transport.

(**) Feature RAN1202 24 kbps Paging Channel brings in a possibility to enhance the Paging Channel’s throughput to 24 kbps.

(***) Feature RAN1637 High Speed Cell_FACH (DL) must be activated.

For the c-plane traffic dimensioning, see 13 Dimensioning signaling traffic

.

For the O&M traffic a 64 kbps IP transport channel is assumed.

5.2.4 Dimensioning I/B HSPA traffic (non CAC-guaranteed)

Bandwidth needed on Iub interface for non CAC-guaranteed Best Effort traffic must also be assured. Currently only I/B HSPA falls under non-CAC guaranteed traffic. The non-CAC guaranteed HSPA capacity is calculated based on Extended M/G/R-PS function separately for each service. The algorithm takes into account input value generated from modeling the radio interface (r_peak parameter). The input parameters for Extended-M/G/R-PS formula are:

r_peak parameter

Mean File Size

Transfer Delay

Bearer type MAX rate

[kbps]

AVE rate

[kbps]

MAX Packet

Size

[Byte]

AVE Packet

Size

[Byte]

Ethernet OH

[%]

CCH bearers

FACH-C – DL 66.25 6.08 76 34 55

FACH-U – DL 68.67 6.32 79 34 53

RACH (*) – UL 35.17 3.2 80 35 53

PCH – DL 55.23 4.96 62 34 68

PCH 24k (**) - DL 64 5.8 73 43 58

HS_FACH (***)- DL 66.25 6.08 76 34 55

79/


DN0980058

Issue 01G



PHB weight

Offered Traffic

Iub_OH

r_peak r_peak [kbps] - a service radio peak rate is calculated as follows:

Service

Service

Service

Service

OHUu

OHIP

Uuf

Uupeakpeakr

_1

_1

_

__

where:

o peak_UuService [kbps] – value reflecting maximum achievable throughput by the specific UE terminal

o f_UuService[s] – radio delay calculated with the M/G/R-PS function. As inputs to the algorithm are used:

average cell throughput, peak_Uu[kbps] UU_loadSector, which is Offered traffic divided by number of

cells for one eNodeB:

o IP_OHService[%] - transport overhead on IP layer o Uu_OHService [%] - transport overhead on the radio interface (including

RLC and PDCP layers)

Mean file size Mean_file_size Service [kb] - average size of a TCP file per service,

Transfer Delay Transfer delay Service - the maximum tolerable transport delay of IP packets on the last mile link.

PHB weight PHB_weight- weight of the DiffServ scheduler queue that serves the QoS class of the service; it determines the bandwidth available to that QoS class during the congestion (i.e. all queues fully occupied with traffic).

Offered Traffic Offered_traffic Service is the mean traffic per service in [kbps]

Iub_OHService Iub_OHService[%] – the overall Iub transport overhead per service




Issue 01G

5.2.5 Dimensioning synchronization traffic

The last traffic component to be accommodated on Iub is 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 dependent; in particular no synchronization is also possible.

5.2.6 Guidelines for the ToP bandwidth

ToP 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.

ToP bandwith for the default value of Sync Msg rate is ~ 16 kbps.

NOTE: It is recommended to map ToP traffic to the highest priority EF PHB.

5.2.7 Guidelines for the SyncE bandwidth

SyncE bandwidth is due to a periodical sending of synchronization status messages (SSM) between two SyncE-capable network node elements.

Bandwidth requirement of SSM stream depends on the frequency of 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.

81/


DN0980058

Issue 01G



NOTE: This bandwidth is to be considered only in the DL direction, at the BTS side

(Iub last mile). The SyncE bandwidth is specified in the Ethernet layer and is not to be

considered in the higher layers. In particular it does not affect the CAC in the IP layer.

5.2.8 Calculating Iub IP bandwidth for the CAC-guaranteed traffic (IP_Route_committed_BW)

Iub IP bandwidth for the CAC-guaranteed traffic refers to IP_Route_commited_BW in Figure 19: IP-based Iub dimensioning components. It is calculated as the sum of bandwidths of all CAC-admitted services:

IP_ Route_committed_BandwidthPHB =

PHBService

PHB

PHBPHB

PHBPHB

_BWM_commited&IP_Route_O

ited_BWPlane_comm-IP_Route_C ited_BWPlane_comm-CCH_U

ited_BWPlane_comm-nRT_U ited_BWPlane_comm-(RT_U

)

5.2.9 Calculating 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 19. Currently non CAC-guaranteed traffic groups only the I/B HSPA traffic:

Shared_BestEffort_IP_Allocation = PHBService

PHBBE_HSPA_BW

5.2.10 Calculating total Iub bandwidth (IP_Route_Bandwidth)

The total bandwidth on Iub refers to IP_Route_Bandwidth in Figure 19: IP-based Iub dimensioning components. It is calculated separately for the UL and the DL.




Issue 01G

Both for the DL and UL, the total Iub bandwidth is calculated separately for IP and Ethernet layer as a sum of bandwidths for CAC-guaranteed and non-CAC guaranteed traffic, including additional Transport Layer overhead:

BWcommitedSyncBWcommitedMOBWcommittedPlaneC

BWHSPABEBandwidthcommitedRouteIPlayerdirectionBWRouteIPPHBService

PHB

PHBService

PHBPHB

____&__

_____;__

Additionally the total Iub bandwidth should be cross-checked with peak cell throughput extended with the respective Eth OH (also for both directions).

Cross-checking of the total Iub bandwidth is graphically presented in the following figure.

C-Plane, O&M and Synch bandwith

HSDPA Peak Rate / NodeB

HSUPA Ctrl

Bandwidth calculated based on the mean user

traffic

Bandwidth calculated based 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

Us

er

tra

ffic

n

on

Us

er

tra

ffic

IP_R

ou

te_

BW

(DL

)

Figure 23: Calculating IP_Route_Bandwidth for DL

83/


DN0980058

Issue 01G



The above example shows that the Iub bandwidth is a resultant of two components:

1) bandwidth calculated on the basis of the user traffic demand 2) bandwidth calculated on the basis of the HSDPA peak cell rate

5.2.11 Calculating total Iub transport capacity

The effective Iub capacity on the transport level (denoted as Iub_Ethernet_Capacity in Figure 19: 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. In addition, the total capacity per physical RNC interface IP_Port is defined as the sum of the capacities of all Iubs terminated at this physical port, reduced with the overbooking factor: RNC_Ethernet_Capacity IP_Port = (1 / Iub_Utilization IP_Port) × Overbooking IP_Port ×

PortIPIubical

IubicalBandwidthRouteIP

__log

_log__

where:

logical_IubIP_Port 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 Iub interfaces grouped on a port and statistical multiplexing characteristics of the traffic carried on individual Iubs. It can be expressed as: Overbooking IP_Port =

PortIPIubLogical

IubLogical

PortIP

IublesingofTraficBandwidthRouteIP

IubsmultipleofTrafficBandwithRouteIP

__

_

_

)___(__

)___(__

where: IP_Route_Bandwidth (Traffic_of_multiple_Iubs) IP_Port denotes capacity of the aggregated traffic of all Iubs terminated on IP_Port.




Issue 01G

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.

5.3 IP-based transport network layer configuration

5.3.1 IP Iub protocol stack and protocol overheads

For 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 presented in the figure:

Figure 24: 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 Release 99 and HSPA RABs are summarized in the Table 20: CAC traffic descriptors and bit rates for selected Release 99 and DCCH-over-HSPA bearers. and

IPv4

UDP

Iub User Plane Protocol

Ethernet-MAC

Ethernet-Phy

ICMPv4

ARP

BFD

IPv4

SCTP

NBAP

Ethernet-MAC

Ethernet-Phy

ICMPv4

ARP

85/


DN0980058

Issue 01G




[kbps]

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 60.9% 19.4 31.2

CS AMR 12.2 – DL 29.8 16.1 62.7% 18.8 30.6

CS 64 – UL 81.0 78.0 21.5% 78.6 95.5

CS 64 – DL 80.2 77.2 21.8% 77.8 94.7

Real time (rt) PS bearers

rt PS 16/64 – UL 34.00 30.8 54.5% 31.4 48.6

rt PS 16/64 – DL 73.9 72.2 11.6% 72.5 81.0

rt PS 16/128 – UL 34.0 30.8 54.5% 31.4 48.6

rt PS 16/128 – DL 147.4 144.4 11.6% 145.0 161.9


[kbps]

AVE rate

[kbps]

Ethernet

OH[%]

IP CAC

bit rate

[kbps]

Ethernet

bit rate

[kbps]

Non-real time (nrt) PS bearers

nrt PS 64/64 – UL 84.4 81.2 20.7% 81.8 98.8

nrt PS 64/64 – DL 83.4 80.4 20.9% 81.0 97.9

nrt PS 64/128 – UL 84.4 81.2 20.7% 81.8 98.8

nrt PS 64/128 – DL 150.6 147.6 11.4% 148.2 165.1

nrt PS 64/384 – UL 84.4 81.2 20.7% 81.8 9.8

nrt PS 64/384 – DL 435.1 429.6 7.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 27% 9.0 15.3

DCCH on HSPA – DL 30.8 3.1 30% 8.6 14.9




Issue 01G

Table 20: CAC traffic descriptors and bit rates for selected Release 99 and DCCH-over-

HSPA bearers.

RLC SDU rate

[kbps]

IP Traffic

Descriptor

(MAX = AVE)

[kbps]

Ethernet

OH

[%]

Ethernet

bit rate

[kbps]

HSDPA

Exam

ple

s o

f C

AC

adm

itte

d b

it

rate

s

16 24,8 33,9% 33,2

32 49,6 33,9% 66,4

40 62,0 33,9% 83,0

64 99,2 33,9% 132,8

128 166,4 20,2% 200,0

512 569,6 5,9% 603,2

1024 1107,2 3,0% 1140,8

2048 2214,4 1,5% 2248,0

Non C

AC

adm

itte

d b

it

rate

s (

10%

BL

ER

)

3055 - 4% 3442.9

6109 - 3% 6826.9

8727 - 3% 9693.8

12218 - 3% 13289.5

19111 - 3% 20261.1

25310 - 3% 26829.1

76436 - 3% 80970.9

HSUPA

Exam

ple

s o

f C

AC

adm

itte

d b

itra

tes 32 48,8 34,4% 65,6

64 97,6 34,4% 131,2

128 164,8 20,4% 198,4

256 299,2 11,2% 332,8

512 568,0 5,9% 601,6

Table 21: CAC traffic descriptors and bitrates for selected HSPA flows.

87/


DN0980058

Issue 01G



NOTE: IP traffic descriptors and Ethernet overheads depend on the actual data rates of MAC-d flows that might vary. Here, these are shown for selected values of MAC-d flow rates.

Average RLC-IP (Ethernet) overhead for HSDPA user plane varies in a range of 6-10% (9-15%) in RU10 case, and oscillates around 3% (6%) in Flexible RLC case, depending on the actual rate utilized by the application layer.

5.3.2 Mapping u-plane and c-plane transport bearers to IP/Ethernet flows

At Layer 4, UMTS transport bearers are identified by UDP/SCTP ports. At Layer 3, transport flows have IP addresses allocated. In BTS, one IP address is allocated 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.

Up to 2800 instances of the logical Iub interface are supported. The maximum number of IP addresses required at the BTS site is 2800 × 3 = 8400. At the RNC site: 2800 × 2 = 5600.

Further differentiation in the IP layer is made based on the QoS level allocated to the u-plane and c-plane traffic. The 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 5.1.1 IP Differentiated Services (DiffServ).

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) corresponding to the IP DSCP value. Also, the scheduling scheme on the Ethernet layer corresponds 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 25: 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 18: Example of IP transport QoS mapping on Iub. In Figure 25: IP-

based Iub transport flow configuration in DL. VLAN option: 1 VLAN per logical Iub, one example 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 5 IP-based Iub allocated Ethernet bandwidth per VLAN for this option is as follows:




Issue 01G

1) CIR Iub = IP_based_Route_commited_BW × 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 are as follows:

1) CIR IP_Port =

PortIPIubical

IubicalIubical OHEthWeightedBwcommitedRoutebasedIP__log

_log_log ______

where:

logical_IubIP_Port denotes logical Iubs terminated at the physical interface IP_Port.

2) EIR IP_Port = RNC_Ethernet_Capacity

NOTE: 1. CAC at the physical interface level is not performed. 2. A VLAN tagging option allocating separate VLANs per traffic classes (for

example RT and NRT u-plane) is currently not supported for RU10. 3. Presented options of VLAN assignment are only examples. VLAN

assignment is much more flexible, and can be configured in an arbitrary way. It is possible to use no VLAN as well.

Ethernet frames are handled at Ethernet switches in the following ways:

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-guaranteed frames are 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.

Differentiation between CAC-guaranteed and non-CACguaranteed frames is based on VLAN p-bits (see Table 18: Example of IP transport QoS mapping on Iub).

89/


DN0980058

Issue 01G



Figure 25: IP-based Iub transport flow configuration in DL. VLAN option: 1 VLAN per logical Iub

UTRAN Service

UTRAN Transport Bearer

Layer 4

IP Layer

DSCP marking

PHB allocation

Ethernet Transport Network

p-bit marking

VLAN tagging

RT

CS

C

RT

CS

S

RT

PS

C

RT

PS

S

RT

HS

DP

A S

NR

T H

SD

PA

I/B

NR

T P

S I

/B

C-N

BA

P

D-N

BA

P

RA

CH

FA

CH

O&

M #

2

O&

M #

1

PC

H

UD

P P

ort

#4

IP

Addre

ss #

3

0b001010 (

10)

3

DC

H #

1

DC

H #

2

DC

H #

3

DC

H #

4

DC

CH

HS

-DS

CH

#1

HS

-DS

CH

#2

UD

P P

ort

#5

IP

Addre

ss #

3

0b001010 (

10)

3

UD

P P

ort

#3

IP

Addre

ss #

3

0b001010 (

10)

3

TC

P P

ort

#1

IP A

ddre

ss #

1

0b

001010 (

10)

4

SC

TP

Port

#2

IP

Addre

ss #

3

0b001010 (

10)

6

SC

TP

Port

#1

IP

Addre

ss #

3

0b001010 (

10)

6

TC

P P

ort

#2

IP A

ddre

ss #

2

0b001010 (

10)

4

UD

P P

ort

#6

IP

Addre

ss #

3

0b101110 (

46)

6

UD

P P

ort

#7

IP

Addre

ss #

3

0b010010 (

18)

4

UD

P P

ort

#8

IP

Addre

ss #

3

0b010010 (

18)

6

UD

P P

ort

#9

IP

Addre

ss #

3

0b011010 (

26)

4

UD

P P

ort

#10

IP

Addre

ss #

3

0b101110 (

46)

2

UD

P P

ort

#11

IP

Addre

ss #

3

0b010010 (

18)

4

UD

P P

ort

#12

IP

Addre

ss #

3

0b000000 (

0)

0

AF4 AF4 EF AF4 BE AF4 AF2 EF AF3 EF

VLAN ID #1

CIR = IP_based_Route_commited_Bw × Weighted_Eth_OH

EIR = IP_based_Route_BW × Weighted_Eth_OH




Issue 01G

5.4 IP-based Iub dimensioning example

The following example describes the IP-based Iub dimensioning in the DL. The following information is a reference traffic model for the particular services specified in BH per subscriber. 1. General input:

Numbers of subscribers per BTS (3 cells) - 1800

Soft Handover factor – 30 %

DCCH – 3.4 Kbps with 30% activity factor

Service Type Traffic demand per subscriber in BH [mErl]

BHCA DCH Activity Blocking [%]

AMR 12.2 22 0.92 0.5 1 CS 64 UDI Video 0.2 0.005 1.0 1

Service Type Traffic demand per subscriber in BH [bps]

BHCA DCH Activity Delay [%]

PS I/B 64 – DL 154.1 0.098 0.8 10 PS I/B 128 – DL 18.6 0.007 0.8 10 PS I/B 384 – DL 122.5 0.028 0.8 10 I/B HSDPA UE Cat.6 1305 0.56 0.8 10

Table 22: Reference traffic model.

In addition to the User services, the offered traffic for the non-User services is as follows:

Service Type Service CAC

Guaranteed bit rate on Iub [kbps]

Mean traffic per BTS site

U-Plane CCH: FACH-U 18.78 56.34

U-Plane CCH: RACH 0.83 2.49

Total non-user traffic (DL): 58.83 kbps

Table 23: Offered CCH non-user traffic per BTS (assuming three cells per BTS).

For the O&M traffic, 56 kb/s is assumed per BTS.

I/B HSPA traffic is assumed to be carried as low-priority best-effort traffic not subject to CAC.

91/


DN0980058

Issue 01G



The CAC-guaranteed bitrates for the CAC-admitted services are as follows:

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.8 16.1 18.8

CS 64 UDI 95.9 80.4 91.5

PS I/B 64 – DL 83.4 80.4 81.0

PS I/B 128 – DL 150.58 147.6 148.2

PS I/B 384 – DL 84.37 81.2 81.8

DCCH 3.4 – DL 14.6 3.1 5.4

U-Plane CCH: FACH-C 66.3 6.1 18.1

U-Plane CCH: FACH-U 68.7 5.0 18.8

U-Plane CCH: PCH 55.2 5.0 15.1

U-Plane CCH: RACH 2.977 0.298 0.83

Table 24: CAC-guaranteed bit rates for different RAB services

The assumed UMTS Service Class to DiffServ PHB mapping is as follows:

Table 25: Mapping of UMTS service classes to DiffServ PHBs.

UMTS transport bearer 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 -

O&M - 0b011010 (26) AF3 40

FACH,

RACH,

PCH

- 0b010010 (18) AF2 30

PS I/B 64 incl. DCCH Interactive 0b001010 (10) AF1 20



HSPA I/B incl. DCCH Background 0b000000 (0) BE 10




Issue 01G

2. Calculation sub-results

First 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 and CS UDI 64, use the MD-Erlang formula. The needed MD-Erlang inputs and the resulting bandwidth demand per different PHBs are summarized in the following table:

Table 26: Bandwidth demand of RT u-plane traffic.

To get the needed bandwidth for NRT u-plane traffic including Rel’99 PS I/B bearers, use the two options presented in section 5.2.2 Dimensioning CAC-guaranteed u-plane NRT traffic. Here only one PHB is involved (AF1) that groups the NRT u-plane R’99 services. The needed inputs and the resulting bandwidth demands obtained with both options are summarized in the following table. NOTE:

For all R’99 PS I/B bearers an 80% activity factor is assumed.

EF PHB

MD-Erlang Input: Parameter Value

Offered Traffic for CS AMR 12.2, incl. 30% SHO Factor 51.48 erl

Offered Traffic for CS UDI 64, incl. 30% SHO Factor 0.47 erl

Gross peak rate for CS AMR 12.2, incl. DCCH 25.3 kbps

Gross peak rate for CS UDI 64, incl. DCCH 98 kbps

Blocking probability for CS AMR 12.2 1%

Blocking probability for CS UDI 64 1%

MD-Erlang Output: Needed RT U-Plane Bw for EF PHB 1891.1 kbps

93/


DN0980058

Issue 01G



Table

Table 27: Bandwidth demand of non RT u-plane traffic.

The last user traffic component is the best-effort I/B HSPA. The required I/B HSPA bandwidth is calculated as the sum of the mean traffic generated by HSPA users per Iub and applying an additional overbooking factor of 20% and 15% of IP overhead:

BE_HSPA_Bw = 1800 × 1,305 kbps × 1.2 × 1.15 = 3241,62 kbps

AF1 PHB

Option 1: via Parallel Connections

Input: Parameter Value

Offered traffic – I/B 64 360.59 kbps

Gross peak rate – I/B 64 86.41 kbps

NRT U-Plane Bw – I/B 64 691.32 kbps


Gross peak rate – I/B 128 153.61 kbps



Gross peak rate – I/B 384 436.11kbps


Output: Total NRT U-Plane Bw 1281.04 kbps

Option 2: via M/G/R/N-PS

M/G/R/N-PS Input: Parameter Value

Total Offered Traffic, incl. 30% SHO Factor [kbps] 844.84

PS I/B 64

Gross peak rate [kbps] 97.99

Service CAC Guaranteed BW [kbps] 86.41

MGRNPS [kbps] 881.93

PS I/B 128 -




PS I/B 384 -




M/G/R/N-PS Output: Total NRT U-Plane Bw 1156.34 kbps




Issue 01G

The required IP bandwidth per service type and per PHB, including also the non-user traffic, is summarized in the following table:

RT_U-Plane_committed_BW EF 1891.1 kbps

NRT_U-Plane_committed_BW 1156.34 kbps

BE_HSPA_Bw 3241.62 kbps

CCH_U-Plane_committed_BW 58.83 kbps

C-Plane_committed_BW 388.7 kbps

O&M_committed_BW 56 kbps

Table 28: IP bandwidth per service type

NOTE:

1) The CCH bandwidth was calculated assuming three cells per BTS. 2) The c-plane bandwidth was calculated assuming three cells per BTS,

according to the rules described in 13 Dimensioning signaling traffic

The next step is to calculate the CAC-guaranteed Iub bandwidth for admitting the CAC-guaranteed traffic and the non-CAC guaranteed Iub bandwidth for admitting the best effort traffic. The first one is calculated with the use of the following formula:

IP_ Route_committed_Bandwidth = RT_U-Plane_committed_BW + NRT_U-Plane_committed_BW + CCH_U-Plane_committed_BW + IP_Route_C-Plane_committed_BW +IP_Route_O&M_committed_BW

IP_Route_committed_Bw = 3551 kbps

The second one is calculated as:

Shared_BE_IP_Allocation = BE_HSPA_Bw

Shared_BE_IP_Allocation = 3241.62 kbps

With the bandwidth demand per Iub defined on the IP level, calculate the needed capacities on the L2 transport level. For this, apply the weighted Ethernet overhead per Iub calculated as:

For CAC guaranteed traffic the Ethernet OH is calculated as follows:

Weighted_Ethernet_OH_of_CAC_Guara_traffic(PHB) =

95/


DN0980058

Issue 01G



PHBRAB

RABRAB

PHBRAB

RABRABRAB

SHOErltrafficMeanCAC

OHEthSHOErltrafficMeanCAC

)*][_*(

)_*][_*(

For the non-CAC guaranteed traffic the calculation of weighted Ethernet overhead is based on mean rate traffic being in the same PHB class.

Weighted_Ethernet_OH_of_nonCAC_Guara_Traffic(PHB)

=

PHBRAB

RAB

PHBRAB

RABRAB

trafficMean

OHEthtrafficMean

_

__

Ethernet overhead for single RAB is calculated from the traffic descriptors (compare Table 20) in the following way:

Eth_OH RAB [%] = %100][___

][___

bytesizepacketIPAverage

bytelengthheaderframeEth

RAB

Ethernet overhead and the mean traffic for CAC admitted bearers are summarized in the following table:

Service type RAB AVE packet size [Bytes]

CACRAB×Mean trafficRAB ×SHO

Ethernet OH

CS AMR 12.2 67 942 kbps 63%

CS 64 UDI 113 42.82 kbps 37%

DCCH 3.4 52 280.52 kbps 81 %

Weighted Ethernet OH for EF class 66 %

PS I/B 64 – DL 52 280.52 kbps 21%

PS I/B 128 – DL 201 570.47 kbps 11%

PS I/B 384 – DL 369 62.99 kbps 8%

DCCH 3.4 – DL 52 45.37 kbps 81%

Weighted Ethernet OH for AF1 class 19%

Table 29: Weighted Ethernet overhead for the CAC admitted traffic.

Calculating the Ethernet OH for the CCH, c-plane and O&M traffic:


Mean trafficRAB per BTS [kbps]

Ethernet OH

CCH U-Plane (AF2) 34 58.83 124%

C-Plane (EF) 175 388.7 24%

O&M (AF3) 280 64 15%

Table 30: Ethernet overhead for the non-user plane traffic




Issue 01G

Here is the calculation of the Ethernet overhead for the non CAC admitted traffic. For HSPA, the average Ethernet OH equals 8%, with average assumed HSDPA packet size equal 500 bytes.


Mean trafficRAB per BTS [kbps]

Ethernet OH

I/B HSPA (BE) 500 3241.62 8%

Table 31: Ethernet overhead for the non CAC admitted traffic

The transport capacity per Iub is then equal to:

Iub_Eth_Capacity =(1 / Iub_Utilization) × [(IP_Route BwPHB ) × (1 + Weighted_Ethernet_OH PHB ) ]

Assuming that Iub_Utilization equals to 100%, the outcome is:

Iub_Eth_Capacity = 1891.1 kbps × 1.66 + 1156.34 kbps × 1.19 + 3241.62 kbps × 1.08 + 58.83 kbps × 2.24 + 388.7 kbps × 1.24 + 56 kbps × 1.15 = 8699.95 kbps

To estimate the capacity needed per physical port at RNC, assume the RAN configuration with 33 BTSs per RNC, connected to RNC as shown in the following figure.

NOTE: That exact BTS allocation for RNC’s physical cards (NPGE cards) is the outcome of the RNC dimensioning.

NodeB 1

NodeB 22

NodeB 23

NodeB 33

RNC

Ph_port 1

Ph_port 2

Figure 26: Logical Iub connectivity

97/


DN0980058

Issue 01G



The capacity to be allocated to RNC ports is then equal to:

RNC_Ethernet_Capacity (IP_Port_1) = 22 × Iub_Eth_Capacity × Overbooking

IP_Port_1

RNC_Ethernet_Capacity (IP_Port_2) = 11 × Iub_Eth_Capacity × Overbooking

IP_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% = 162689 . kbps

RNC_Ethernet_Capacity (IP_Port_2) = 11 × Iub_Eth_Capacity × 89% = 85172.5 kbps




Issue 01G

6 RAS06 features impacting dimensioning process

6.1 RAN1063: Hybrid Backhaul with Pseudo Wires In Hybrid BTS, backhaul operating mode Iub traffic is carried over two separate networks: 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 supported by the Pseudowire Emulation service. The R’99 Iub traffic is transmitted over the TDM network, according to the existing RAS06 transport solution. Synchronization is also provided by the TDM network. In order to separate HSDPA and HSUPA traffic from other user plane traffic, the RAS06 Path Selection feature is 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 Emulation (PWE) need to be taken into account. The protocol stack for hybrid transport is presented in the figure below.

Figure 27: Protocol stack for hybrid transport over Iub

99/


DN0980058

Issue 01G



The overhead calculation can be based on the 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' and 'packetization timer'. Concatenation factor is the maximum number of ATM cells that are allowed to a single frame. 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 is scheduled for forwarding, regardless of the status of the “packetization timer”.

The following formula is used to calculate the Ethernet bandwidth:

Ethernet_Bandwidth = Packet_size × Packet_rate

where:

Packet_size [bit]= (Cells_per_packet × 52 + PWE_Header)×8

Packet_rate = PCRVP/VC/Cells_per_packet

1/PCR1n,timerMINPCRpacketCells_per_ VC/cellspkVC/ VPVP

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 a number of pseudo wires, the overall Ethernet bandwidth is the sum of the bandwidth required for each single PW. The following table gives examples of the capacity needed in Ethernet layer if the parameter 'concatenation factor’ is given value 28 and 'packetization timer' is given value 5 mSec.

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 32: Example calculation for hybrid transport overheads on top of ATM layer




Issue 01G

Only one tunnel is required to connect BTS PWE GW and RNC PWE GW. Each BTS might configure up to six PWs in total.

To map VCC into PWs, N-to-one mode is supported, where one or more ATM VCCs or ATM VPCs are encapsulated into one Pseudo Wire (PW). Having more VCCs of the same type (for example HSDPA) for each VPC, 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 a different PW, it is possible to apply different handling of traffic in the uplink and downlink direction. This is to provide prioritization for control frames over user traffic. This is mainly relevant, provided that both types of channels are strongly asymmetric.

NOTE: When sharing PWs, only VCCs of the same ATM service category should be configured into a single PW.

With hybrid backhaul solution it is possible to create two VCC bundles: one for ATM transmission path and another for Ethernet transmission path.

6.2 RAN1096: Transport Bearer Tuning For more information, see chapter 4.4.1 AAL2 Connection Admission Control and 5.1.2 IP Connection Admission Control

6.3 RAN1100: Dynamic Scheduling for NRT DCH with Path Selection For more information, see chapter 4.4.1 AAL2 Connection Admission Control. RU10 features impacting dimensioning process

6.4 RAN1254: Timing over Packet for BTS SW For more information, see 5.2.5 Dimensioning synchronization traffic .

101/


DN0980058

Issue 01G



7 RU20 features impacting dimensioning process

7.1 RAN 1202: 24 kbps Paging Channel For more information, see chapter 3.1.1.2 Common Control Channels - CCCH and chapter5.2.3 Dimensioning other CAC-guaranteed traffic components.

7.2 RAN1578: HSPA Transport Fallback Applying the hybrid transport configuration on Iub interface, the operator is able to separate delay-sensitive CS traffic from bandwidth demanding HSPA data. Simultaneously, the operator can employ lower cost PSN transmission for NRT DCH or HSPA connections. It is also expected 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. RAN1578: HSPA Transport Fallback feature provides a 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 case the PSN transmission path fails. Basic functionality of RAN1578: HSPA Transport Fallback, also called 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. In this context, hybrid Iub configuration relates to the usage of either hybrid BTS backhaul transmission with emulated IP via PWE function or Dual Iub for Flexi BTS/Ultra BTS with native IP transmission. Figure 28: Dual Iub configuration for BTS shows a 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 are assumed to be carried over ATM/TDM network (ATM Iub).

HSPA (and optionally also NRT DCH) is carried over IP/Ethernet (PSN) network (IP Iub).




Issue 01G

Figure 28: Dual Iub configuration for BTS

If the RNC detects a fault in native or emulated IP transport, the protection ATM Iub path is used to carry the traffic classes previously configured over IP Iub transport. Notice that even though the feature is intended to protect against malfunctions of low reliable last mile xDSL lines, the system moves traffic to working ATM path also due to defects in other parts of the IP transmission path between the RNC and BTS. For more information about the feature, see the respective feature area description.

7.3 Iub fallback VCC configuration and dimensioning The main asset of HSPA Transport Fallback feature is the enhanced service availability for HSPA (NRT DCH) traffic. This highly reliable transport solution is reached via:

selection of traffic classes intended for protection

correct pre-configuration of fallback (backup) VCCs over ATM network Proper dimensioning of fallback VCC – extra bandwidth may be 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. It requires proper configuration of the corresponding fallback VCC/VCCs with respective AAL2 path types. Basic traffic classes that can be protected are: NRT DCH, RT HSPA, and NRT HSPA. Additionally, if RAN1253 Iub Transport QoS feature is activated, the selection of transport bearers to be protected is extended on the basis of SPI values for HSPA traffic (FallbackForHSPAQoSPriXX) and QoS for DCH traffic (FallbackForDCHQoSPriXX). NOTE:

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.

103/


DN0980058

Issue 01G



Configured VCCs used as a fallback may be dedicated for the traffic moved to ATM path in the case of failure. Alternatively, the same VCC can be used as default VCC for DCH traffic as fallback VCC for HSPA data after IP network outage. Thus, two types of fallback VCCs might be distinguished:

Shared fallback VCC, which is applicable in particular for traffic types with similar QoS requirements. Additionally, if RAN1253 is activated, the fallback traffic can be configured with a low AAL2 queue priority to preserve suitable QoS for original traffic

Dedicated fallback VCC, which is not operational in “normal” network conditions, but is used only if the default IP path is faulty

NOTE: Combination of both shared and dedicated VCCs on a single Iub interface is also possible. The AAL2 Fallback Attribute is used to indicate whether a given AAL2 VCC should be used as fallback VCC for HSPA (NRT DCH) traffic when default VCC is not available.

To provide efficient bandwidth for the ATM network after the IP path failure, one needs to consider both the traffic classes intended for protection and corresponding fallback VCC combinations. In this context the operator may take into account several possibilities of 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 temporary service degradation over the ATM path during the failure period.

As a third alternative, enough spare capacity on ATM path may be ensured for high revenue data services only, whereas low revenue services may suffer after packet network outage due to the lack of network resources.

In the first case, to calculate capacity of the fallback VCCs, apply the same dimensioning methods as described in chapter 3.1 Iub user plane dimensioning. When configuring the shared fallback VCC, both the traffic classes configured over ATM during normal operation and traffic classes intended for protection are taken into account in the dimensioning process. In case of the dedicated fallback VCC, only traffic classes selected for protection need to be considered to dimension the bandwidth of pre-arranged VCC. Such an approach makes allowance for the additional traffic sent over ATM network. Also, it guarantees the original quality of service level for all traffic data sent after IP path failure. The following figure presents an example transport fallback configuration with dedicated fallback VCC. Both RT/NRT HSPA traffic classes are intended for protection, and the fallback VCC is dimensioned in such a way to carry complete HSPA traffic after packet network unavailability. For better clarity, user plane VCCs are only presented in the pictures. NOTE:

For the fallback VCC dimensioning, it is advised to ignore HSPA peak rate requirements.




Issue 01G

BTS RNC

VCC1 (RT DCH)

ATM Service Category: CBR

AAL2 UP Usage:DCH

AAL2 PTs:Stringent

No Fallback

VCC2 (NRT DCH)ATM Service Category: UBR+

AAL2 UP Usage:DCH

AAL2 PTs:Stringent bi-level

No Fallback

Hybrid scenario: VCC4 (RT/NRT HSPA) ATM Service Category: UBR+

AAL2 UP Usage:HSPA

AAL2 PTs:Stringent+Stringent bi-level+Tolerant

No Fallback

VCC3 (RT/NRT HSPA)ATM Service Category: UBR+

AAL2 UP Usage:HSPA

AAL2 PTs:Stringent+Stringent bi-level+Tolerant

Fallback

VCC is used during standard operation for RT

DCH traffic.

RNC/BTS egress/ingress traffic: Calculate

according to rules given in 3.1.4.

VCC is used during standard operation for NRT

DCH traffic.



Dedicated Falback VCC 3 is used after IP path

failure to allocate all HSPA traffic.



Dual IubIubTransportMediaSelection

(RT HSUPA, RT HSDPA, NRT HSUPA, NRT

HSDPA)

Figure 29: VCC configuration of hybrid Iub with dedicated fallback VCC

Within the above approach, the spare Iub bandwidth reserved for HSPA traffic might not be used during normal operation, and therefore may be wasted. Thus, an alternative way to handle relocated IP traffic would be to add extra capacity either for high-revenue services only, or to assume that no extra bandwidth is needed on Iub interface at all. The first mentioned case might be relevant for the scenarios, when failures in the network are expected very sporadically for a short period of time. Anyway, in both cases the shortage of capacity resources after the IP path failure phase might lead to the service degradation on Iub. In the following example, two fallback VCCs are configured where RT/NRT HSPA traffic classes are intended for protection. VCC2, which normally works for Stringent Bi-level DCH traffic, is also used 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. It 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 bandwidth is not wasted during normal operation.

105/


DN0980058

Issue 01G



BTS RNC

VCC1 (RT DCH + Conver. HSPA)

ATM Service Category: CBR

AAL2 UP Usage:DCH&HSPA

AAL2 PTs:Stringent

No Fallback

VCC2 (RT HSPA + Stream. HSPA)ATM Service Category: UBR+

AAL2 UP Usage:DCH&HSPA

AAL2 PTs:Stringent bi-level

Fallback

Hybrid scenario: VCC4 (RT/NRT HSPA)ATM Service Category: UBR+

AAL2 UP Usage:HSPA

AAL2 PTs:Stringent bi-level+Tolerant

No Fallback

VCC3 (NRT HSPA)ATM Service Category: UBR

AAL2 UP Usage:HSPA

AAL2 PTs:Tolerant

Fallback

VCC is used during standard operation for RT

DCH traffic.



Shared fallback VCC is used during standard

operation for NRT DCH traffic and after IP path

failure 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 any

bandwidth guarantees.

Dual IubIubTransportMediaSelection

(RT HSUPA, RT HSDPA, NRT HSUPA, NRT

HSDPA)

Figure 30: VCC configuration of hybrid Iub with dedicated and shared fallback VCC

NOTE:

Conversational HSPA traffic is always mapped over ATM transport in case of Dual Iub feature. Therefore, there is no need to save these traffic types.

7.4 RAN1689: CS Voice over HSPA (On Top) From the transport network point of view, RAN1689 CS Voice over HSPA affects the traffic only on Iub and Iur interface. Iu-CS is not impacted – similar c-plane and u-plane behavior is observed, as comparing to the ‘plain’ AMR/DCH calls.




Issue 01G

Figure 31: CS Voice over HSPA – impact on the transport network.

7.4.1 Call Admission Control aspects

Due 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 transport independent Activity Factor parameters.

7.4.1.1 ATM Transport CAC for CS Voice over HSPA

Similarly to AMR/DCH, CAC for CS Voice over HSPA calls relies on a set of UL/DL specific ALC parameters:

CS Voice over HSPA impact on Transport Network

107/


DN0980058

Issue 01G



MAX CPS-SDU bit rate

AVE CPS-SDU bit rate

MAX CPS-SDU size

AVE CPS-SDU size Table 33: CS Voice over HSPA – ALC parameters 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 18.1 10.6 45 44

AMR/HSPA 12.2 – DL 17.9 10.6 45 44

AMR/HSPA 5.9 – UL 11.3 6.5 45 27

AMR/HSPA 5.9 - DL 11.1 6.5 45 27

Table 33: CS Voice over HSPA – ALC parameters

7.4.1.2 IP Transport CAC for CS Voice over HSPA

Similarly 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

Table 34: CS Voice over HSPA – IPTD parameters lists the current set of ALC parameters related to CS Voice over HSPA calls:


[kbps]

AVE rate [kbps]

MAX packet size

[Byte]

AVE packet size

[Byte]

AMR/HSPA 12.2 – UL 32.0 17.3 108 108

AMR/HSPA 12.2 – DL 31.8 17.3 108 108

AMR/HSPA 5.9 – UL 25.2 13.2 74 74

AMR/HSPA 5.9 - DL 25.0 13.2 74 74

Table 34: CS Voice over HSPA – IPTD parameters




Issue 01G

7.4.2 Iub interface dimensioning impacts

Similar dimensioning rules to those used for AMR/DCH apply to CS Voice over HSPA calls. For detailed description, see chapters from 3.1 Iub user plane dimensioning to 5.4 IP-based Iub dimensioning example. Changed frame structure and different HSPA SHO behavior impacts the following dimensioning steps:

7.4.2.1 ATM dimensioning

Calculation of parallel connections is affected by changed overhead and lack of HS-DSCH DL Soft Handover.

CAC QT (DL) and AVE (UL) algorithm operate on new ALC parameters.

DCCH over HSPA SRBs are used as accompanying AAL2 c-plane.

7.4.2.2 IP/Eth dimensioning

Offered Traffic provided to MD-Erlang is affected by the lack of HS-DSCH DL Soft Handover.

CAC AVE80 calculation operates on increased IP Traffic Descriptors resulting in increased output.

DCCH over HSPA SRBs are used as accompanying AAL2 c-plane.

A meaningful configuration impact of CS Voice over HSPA is 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 CIDs/UDP ports reserved for AMR/DCH call (DTCH and DCCH). The increase mentioned above affects especially the ATM transport, where the expected CID demand has a direct impact on the required number of VCCs, potentially causing heavy increase in blocking ratio of AMR calls.

7.4.3 Configuration and traffic mapping aspects

CS Voice over HSPA is activated on the cell level with the use of

HSPAQoSEnabled parameter, depending on the license availability.

In the RAN1449 Dual Iub, CS Voice over HSPA calls are always established over the ATM path.

7.4.3.1 QoS priority and VCC selection in ATM transport

The VCC and QoS priority (AAL2 priority) selection for AMR/HSPA and corresponding DCCH/HSPA connection depends on the Iub VCC configuration

109/


DN0980058

Issue 01G



and the availability of RAN759 Path Selection and RAN1253 Iub Transport QoS features.

Feature availability AAL2 queue VCC selection

RAN759 not activated


Highest priority queue (same as AMR/DCH)

Same VCC as AMD/DCH

RAN759 activated


Highest priority queue HSPA/HSDPA/HSUPA Stringent

RAN759 activated

RAN1253 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 35: CS Voice over HSPA – QoS priority and VCC selection in ATM transport

* SPI for AMR/HSPA and DCCH/HSPA bearers is assigned via RNC parameters

PriForConvOnHSPA and PriForSRBsOnHSPA.

7.4.3.2 QoS priority in transport

The QoS priority (DSCP) selection for AMR/HSPA and corresponding DCCH/HSPA connection depends on the RAN1253 Iub Transport QoS feature availability.

Feature availability AAL2 queue


Same as RT DCH

Defined in RNC/WBTS/RTDCHToDSCP

RAN1253 activated According to DSCP assigned to SPI

Defined in RNC/TQM/QosPriToDSCP

Table 36: CS Voice over HSPA – QoS Priority selection in IP Transport




Issue 01G

* SPI for AMR/HSPA and DCCH/HSPA bearers is assigned via RNC parameters

PriForConvOnHSPA and PriForSRBsOnHSPA.

7.5 RAN1707: Flexi WCDMA integrated CESoPSN (On Top) There are several standards describing how to encapsulate TDM frames into IP datagrams 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 Emulation Service over Packet Switched Network (CESoPSN). For tunneling TDM traffic over PSN domain, PW (pseudo wire) gateways are required to terminate TDM links and to encapsulate TDM frames into IP datagrams at the edges of PSN domain. For more information, see Feature Descriptions in WCDMA RAN, Rel. RU30 Operating Documentation.

7.6 CESoPSN traffic bandwidth calculation Bandwidth 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 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 following 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

111/


DN0980058

Issue 01G



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 the 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 an optional VLAN tag is added, constant bandwidth consumption on the 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] Example bandwidth consumption on the Ethernet level (VLAN configured) for a given number of timeslots, and depending on packetization delay, is presented in the following figure.

Packetization latency and CESoPSN bandwidth

0

500

1 000

1 500

2 000

2 500

3 000

3 500

4 000

4 500

5 000

5 500

6 000

6 500

7 000

0,0 0,5 1,0 1,5 2,0 2,5 3,0 3,5 4,0 4,5

Packetization latency [ms]

Ba

nd

wid

th c

on

su

mp

tio

n o

n E

the

rne

t la

yer

[kb

ps

]

#TS=31, TDM BW=1984kbps #TS=16, TDM BW=1024kbps #TS=8, TDM BW=512kbps #TS=4, TDM BW=256kbps

Figure 32: Packetization latency and CESoPSN bandwidth




Issue 01G

7.7 RAN1707 requirements The 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 a constant number of timeslots to be encapsulated (operator configurable).

Every CESoPSN packet must consist of a constant number of TDM frames (operator configurable).

Up to 16 pseudo wires can be configured in the PW tunnel.

One pseudo wire 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).

CESoPSN traffic should only be mapped to EF (expedited forwarding) traffic class.

It is recommended for CESoPSN traffic to use a dedicated VLAN. If not possible, CESoPSN traffic can also share already existing VLAN.

7.8 RAN1709: VLAN Traffic Differentiation (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 a separate subnet/VLAN. For more information, see RAN1709: VLAN Traffic Differentiation, Feature Descriptions in WCDMA RAN, Rel. RU20 documentation.

7.9 Dimensioning aspects The same general dimensioning methods as presented in section 5.1 IP-based Iub dimensioning apply when using RAN1709 feature. Since the UP traffic to UP VLAN mapping is applied with PHB class granularity, dimensioning is 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, relevant aggregated CAC-guaranteed values (for CIR) and sum of CAC-guaranteed and non CAC-guaranteed values (for SIR) should be used. Note that CIR parameter is given on

113/


DN0980058

Issue 01G



the IP level (not including Eth overhead), and SIR parameter is given on the Ethernet level (including Ethernet overhead). It is possible to shape the egress (UL) traffic per VLAN at the BTS site. 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 is shaped to SIR value, according to dimensioning calculation. In other cases (same path for all traffic) only per IP based route shaping only should be applied. NOTE:

1) In RU20 On Top, in case of multiple VLAN interfaces, the Signaling Committed Bit Rate and DCN Committed Bit Rate parameters are only considered when CP and MP have VLAN mapping configured. The mapping must be configured according to the routing configuration so that CP and MP traffic is transmitted over the proper interface. If CP and MP do not have VLAN mapping configured, the sum of interface Committed Information Rates (CIR) should be configured below the available capacity, to ensure the correct functioning of the system.

2) In RU30 and later, the Signaling Committed Bit Rate and DCN Committed Bit Rate parameters are not considered when CP and MP are configured with a virtual address. In that case, the sum of interface Committed Information Rates (CIR) should be configured below the available capacity, to ensure the correct functioning of the system.

7.10 Dimensioning example A basic dimensioning example is presented later in this section. All traffic mappings and bandwidth calculations are shown for example purposes – these are not Nokia Siemens Networks recommendations. The presented example is applicable mainly for the BTS site, where CIR and SIR parameters are required. The following bearers/services to PHB classes mapping is assumed (RAN1253 not enabled):

ToP -> EF

C-Plane -> AF4

O&M -> AF1

RT_DCH -> EF

NRT_DCH -> AF4

RT_HSPA -> AF4

NRT_HSPA -> BE

The following PHB classes to VLANs’ mapping are assumed:

UP VLAN 1: EF, AF4, AF3, AF2

UP VLAN 2: BE

VLAN 3: ToP, C-Plane, O&M




Issue 01G

Based on the dimensioning methods presented in section 5.1 IP-based Iub dimensioning, the bandwidth demands calculated for the uplink per PHB class

are listed in the following table.

Traffic type IP layer (L3)

[kbps] Eth layer (L2)

[kbps]

ToP_BW 10 15

C-Plane_BW 120 150

O&M_BW 70 100

RT_U-Plane_committed_BWEF 250 300

RT_U-Plane_committed_BWAF4 170 200

NRT_U-Plane_committed_BWAF4 420 500

BE_HSPA_BW BE 1250 1500

Table 37: Example of bandwidth estimations per PHB class with RAN1709 activated

Bandwidth demand per VLAN,(in accordance with the traffic type mapping assumed) is as follows:

UP_VLAN_1_CIR (L3) = 250 + 170 + 420 = 840 kbps

UP_VLAN_1_SIR (L2) = 300 + 200 + 500 + 0 = 1000 kbps

UP_VLAN_2_CIR (L3) = 0 kbps

UP_VLAN_2_SIR (L2) = 0 + 1500 = 1500 kbps

VLAN_3_CIR (L3) = 10 + 120 + 70 = 200 kbps

VLAN_3_SIR (L2) = 15 + 150 + 100 + 0 = 256 kbps

115/


DN0980058

Issue 01G



8 RU30 features impacting dimensioning process

8.1 RAN1637: High Speed Cell_FACH (DL) For more information, see chapter 3.1.1.2 Common Control Channels - CCCH and chapter5.2.3 Dimensioning other CAC-guaranteed traffic components.

8.2 RAN1769: QoS Aware Ethernet Switching Feature RAN 1769 introduces QoS-aware Ethernet switching in Flexi WCDMA BTS. For more information, see RAN1769 QoS aware Ethernet Switching feature description in WCDMA RAN, Rel. RU30 documentation. With the enabled QoS aware Ethernet Switching, the ‘chaining’ BTS aggregates the traffic from its connected ‘chained BTSs’ upwards to PSN backhaul. QoS criteria are considered for queuing and scheduling the aggregation towards common backhaul. Aggregated traffic from BTSs is shaped on the uplink bandwidth according to the configured egress limit. Chaining BTS in the egress port aggregates traffic from local port and chained BTSs on the basis of priority. The shaper at the egress port ensures that the configured maximum transmission rate for this port is not exceeded. Each port handles four queues with different QoS priorities and weighted for queuing scheduler algorithm with four different weights. The mapping of Diffserv PHBs to the queues and weights are as follows: EF Queue 1 [weight = 8] (high priority) AF4, AF3 Queue 2 [weight = 4] AF2, AF1 Queue 3 [weight = 2] BE Queue 4 [weight = 1] (low priority)

The following are example bandwidth calculations for specified queues:




Issue 01G

Assumptions: 1. Chaining BTS egress Ethernet port is shaped to 100 Mb/s. 2. Queue weights and QoS mapping are fixed and are as pointed above. Given this information, the bandwidth reservation for each queue is calculated as follows:

n

n

n

nweightQueue

weightQueueBWPBREthBWQueue

_

_*___

where: Eth_PBR_BW = Ethernet Port Bit Rate Bandwidth [b/s]

Calculations:

sMbsMbBWQueue /3.531248

8*/100_ 1


4*/100_ 2


2*/100_ 3


1*/100_ 4

8.2.1 Dimensioning process

Iub interface dimensioning is performed in accordance with access network dimensioning rules as described in 5.1 IP-based Iub dimensioning, where:

IP_Route_Committed_BW relates to calculated CAC-guaranteed IP bandwidth per logical Iub interface in uplink (for high-priority connections) – according to traffic model requirements.

IP_HSPA_BE_BW denotes calculated non CAC-guaranteed IP bandwidth per logical Iub interface in the uplink (for low-priority BE HSPA traffic), according to traffic model requirements.

Ethernet BW BTS specifies the actual Ethernet capacity required on Iub at each BTS in uplink (incl. Eth. OH).

Overall Ethernet capacity on Iub interface is calculated according to the formula:

Ethernet_BW_BTS = (IP_Route_Committed_BW + IP_HSPA_BE_BW) × Ethernet_OH_factor

117/


DN0980058

Issue 01G



Figure 33: QoS-aware Ethernet Switching dimensioning process

The Iub interface between “chain” BTS2 and the Operator’s network is the sum of all aggregated BTSs’ traffic:

n

nBTSBWEthBWChainedEthTotal _____

This feature introduces two parameters to be configured on switch ports:

Ingres bandwidth limit parameter

Egress Ethernet Port Committed Bit Rate

Both parameters can limit the external Ethernet ports with the limit of LINE-SPEED, which is 100MBps or 1 Gbps with the following granularity:

1 Mbps steps up to 10 Mbps

5 Mbps steps from 10 Mbps up to 100 Mbps

50 Mbps steps from 100 Mbps up to 1 Gbps

8.3 RAN1878: IP over ML-PPP on E1/T1 Interfaces IP over ML-PPP on E1/T1 feature allows using legacy PDH interfaces on BTS to carry IP packets. There are still a lot of customers with huge PDH infrastructure. They want to build their network based on IP, and simultaneously keep using their E1/T1 links. The feature presented in this document offers this possibility. For more information, see Feature Descriptions in WCDMA RAN, Rel. RU30 documentation.




Issue 01G

8.3.1 Dimensioning process

IP over ML-PPP on E1/T1 feature concerns only BTS and next hop gateway which is situated close to RNC. Next hop gateway is a concentrator of E1s/T1s. According to SFS, this could be Cisco 7600, MWR2941, Tellabs 86x0 and Tellabs 8605. This feature has no impact on IP layer dimensioning. Changes are only in transport layer, where ML-PPP is employed instead of Ethernet. Similarly to Ethernet transport calculations, weighted ML-PPP overhead factor is calculated. The total bandwidth per Iub refers to IP_route_BW. It is calculated as the sum of bandwidths for CAC-guaranteed and non-CAC guaranteed traffic, including additional Transport Layer overhead. In simple ML-PPP scenario, where the BTS has only E1 interfaces, all traffic, CAC-guaranteed and non-CAC guaranteed type, goes through it. As regards hybrid scenario, where the BTS does not only have E1/T1 interface, but an Ethernet interface too, the traffic can be differentiated between them.

8.3.2 Calculating the ML-PPP traffic capacity at the BTS site

BTS_Iub_ML-PPP_Capacity = (IP_route_BW) × (1 + Weighted_ML-PPP_OH) IP_Route_Bw = (IP_Route_committed_BW + Shared_BestEffort_IP_Allocation) Weighted_ML-PPP_OH is the mean ML-PPP transport overhead weighted over the services supported on Iub. It is calculated as:

Weighted_ML-PPP_OH =

RAB

RAB

RAB

RABRAB

trafficMean

OHPPPMLtrafficMean

_

__

Mean traffic per service is given in [kbps]. In case of RT services, where the mean traffic is given in [Erlang], the units require converting as follows: Mean_traffic RAB [kbps] = Mean_tarffic RAB [Erlang] × Service_bitrate RAB × Activity_factor RAB

See 5 IP-based Iub for detailed explanation on how to calculate the IP_Route_Bw. PPP encapsulation adds four to nine bytes overhead to the original IP packet. ML-PPP includes two to four additional bytes overhead in relation to plain PPP. In the worst-case scenario, it gives 13 bytes of overhead altogether. It is still much less than Ethernet overhead, which gives 38 bytes. See the figure below for ML-PPP header overview in two cases: minimum and maximum ML-PPP header:

119/


DN0980058

Issue 01G



Protocol

16 bits

Fragment

0-… bits

Padding

0-…bits

Flag

0x7E

8bits

FCS

16/32 bits

Address

0xFF

8bits 8 bits 8bits

Flag

0x7E

Could be 2 octets

Protocol

8 bits

Fragment

0-… bits

Padding

0-…bits

Flag

0x7E FCS

16 bits8bits 8bits

Flag

0x7E

Maximum of 13 bytes overhead

Minimum of 6 bytes overhead

Control

0x03Header

8 bits

Seq Number

24 bits

MP header

16 bits

Figure 34: ML-PPP minimum and maximum overhead cases

ML-PPP overhead for single RAB is calculated out of the traffic descriptors in the following way:

ML-PPP_OH RAB [%] = %100][___

][___


bytelengthheaderframePPPML

RAB

ML-PPP_frame_header_length differs from six to 13 bytes, depending on configuration options of the ML-PPP frame structure supported by next hop router. In dimensioning, it is important to determine the constant ML-PPP frame header length that suits every kind of hardware and scenario solution. For that reason the maximum value of 13 bytes is taken into account.

8.3.3 Dimensioning example

Let us assume the following example of user traffic demand specified in BH per BTS. All traffic goes through the BTS E1 interface.

Service Type Service bit rate on Iub [kbps]

Traffic Demand per BTS site

CS AMR 12.2 Voice 12.2 16.2 erl

PS I/B 64 – DL 64 115.2 kbps

PS I/B 384 – DL 384 7.74 kbps

I/B HSDPA UE Cat. 6 Max: 3360 1949.9 kbps

Total U-Plane Rel’99 + HSPA (DL): 16.2 Erl

2072.8 kbps

Table 38: Offered user traffic per BTS




Issue 01G

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.

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.8 16.1 18.8

PS I/B 64 – DL 99.1 93.6 94.7

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 39: CAC-guaranteed bit rates for different RAB services

To get the IP bandwidth demand for the RT u-plane traffic, we use the MD-Erlang formula. The needed MD Erlang inputs and the resulting bandwidth are summarized in the table:

MD-Erlang Input: Parameter Value

Offered Traffic for CS AMR 12.2, incl. 30% SHO Factor 21.2 erl

Gross peak rate for CS AMR 12.2, incl. DCCH 29.5 kbps

Blocking probability for CS AMR 12.2 0.1%

MD-Erlang Output: Needed RT U-Plane Bw 1062 kbps

Table 40: Bandwidth demand of RT u-plane traffic

To get the needed bandwidth for non-RT u-plane traffic including Rel’99 PS I/B bearers, the M/G/R-PS method is employed. The needed inputs and the resulting bandwidth demands obtained are summarized in the following table.

M/G/R-PS

M/G/R-PS Input: Parameter Value

Total Offered Traffic, incl. 30% SHO Factor 159.82 kbps

Gross peak rate – PS I/B 64 105.9 kbps

Transfer delay – PS I/B 64 10%

Gross peak rate – PS I/B 384 442.2 kbps

Transfer delay – PS I/B 384 10%

M/G/R-PS Output: Total NRT U-Plane Bw 548.1 kbps

Table 41: Bandwidth demand of non RT u-plane traffic

121/


DN0980058

Issue 01G



As the last user traffic component is the best-effort I/B HSPA, the required I/B HSPA bandwidth is calculated as the sum of the mean traffic generated by HSPA users per Iub with an additional overbooking factor of 20%: BE_HSPA_Bw = 1949.9 kbps × 1.2 = 2339.9 kbps The desired level of IP traffic bandwidth per service type, including also the non-user traffic, is summarized in the table:

Table 42: IP bandwidth per service type

NOTE: See chapter 5.4 IP-based Iub dimensioning example for explanation of how the CCH_U-Plane_committed_BW and C-Plane_committed_BW values are derived.

IP_ Route_committed_BW = RT_U-Plane_committed_BW + NRT_U- Plane_committed_BW + CCH_U-Plane_committed_BW + IP_Route_C- Plane_committed_BW +IP_Route_O&M_committed_BW IP_Route_committed_BW = 2076.7 kbps Shared_BE_IP_Allocation = BE_HSPA_BW Shared_BE_IP_Allocation = 2339.9 kbps Having the bandwidth demand per Iub defined on the IP level, the next step is to calculate the needed capacities on the L2 transport level, in this case the ML-PPP level. For this, we apply the weighted ML-PPP overhead per Iub, calculated as:

Weighted_ML-PPP_OH =

RAB

RAB

RAB

RABRAB

trafficMean

OHPPPMLtrafficMean

_

__

ML-PPP_OH RAB[%] = %100][___

][___


bytelengthheaderframePPPML

RAB

RT_U-Plane_committed_BW 1062 kbps

NRT_U-Plane_committed_BW 548.1 kbps

BE_HSPA_Bw 2339.9 kbps

CCH_U-Plane_committed_BW 56.4 kbps

C-Plane_committed_BW 346.2 kbps

O&M_committed_BW 64 kbps




Issue 01G

ML-PPP overhead and the mean traffic for individual UMTS bearers are summarized in the following table. We assume 800 bytes average packet size for HSPA traffic.

UMTS Service Mean traffic Ave_packet_size

[Bytes]

ML-PPP header [Bytes]

ML_PPP OH

CS AMR 12.2 118.6 kbps 67 13 19.4 %

PS I/B 64 – DL 115.2 kbps 117 13 11.1 %

PS I/B 384 – DL 7.74 kbps 537 13 2.4 %

DCCH 3.4 – DL 89.2 kbps 52 13 25 %

I/B HSPA (BE) 1949 kbps 800 13 1.6 %

DCCH U-Plane 31.9 kbps 52 13 25 %

Weighted ML-PPP OH: 4.2 %

Table 43: Weighted ML-PPP overhead.

The transport capacity per Iub is then equal to: Iub_ML-PPP_Capacity = (IP_Route_committed_Bw + Shared_BE_IP_Allocation) × (1 + ML-PPP_OH) Iub_ML-PPP_Capacity = (2076.7 kbps + 2339.9 kbps) × 1.042 = 4602.1 kbps

8.4 RAN1879: Dynamic Routing by OSPF and RAN2359: OSPF Enhancements in BTS For more information on the feature, see Feature Descriptions in WCDMA RAN, Rel. RU30 Operating Documentation.

8.4.1 Bandwidth estimation

For each multi-access network segment (for example Ethernet broadcast domain), Designated Router (DR) and Backup Designated Router (BDR) are additionally selected to limit the OSPF traffic exchanged between routers. DR maintains a complete topology table of the area, and sends updates to other routers via multicast. All routers in the area form a slave–master relationship with the DR. They are adjacent to the DR and BDR only. According to RAN1879 requirements, BTS is never elected as DR or BDR (OSPF router priority set to zero).

123/


DN0980058

Issue 01G



Each OSPF router monitors its neighbor’s availability, by exchanging OSPF Hello packets. In multi-access network segment, direct relation is established between each OSPF router and DR/BDR, but since OSPF Hello packets are sent with the use of multicast address, they consume bandwidth within whole L2 broadcast domain. The following protocol headers (overheads) are assumed for this estimation:

ETH_OH = 42 bytes (including VLAN tag, preamble and inter-frame gap)

IP_OH = 20 bytes

OSPF_OH = 24 bytes

OSPF_Hello_OH = 20 bytes

OSPF_Neighbor_ID = 4 bytes

UDP_OH = 8 bytes

BFD_packet = 28 bytes

The number of the following nodes have an impact on the dimensioning:

#BTS – number of BTS nodes (supporting OSPF) on shared L2 broadcast domain (Ethernet segment)

#routers - number of other OSPF routers on shared L2 broadcast domain (Ethernet segment). DR and BDR are not included here

#DR/BDR_routers – number of DR/BDR routers on shared L2 broadcast domain (Ethernet segment), this value is 2 in most cases

Bandwidth consumption for OSPF Hello packets depends on OSPF timers (configurable), as well as the number of BTS nodes and other OSPF routers within the same broadcast domain. Configurable OSPF timers that have an impact on dimensioning:

HelloInterval – interval for sending Hello packets

DeadInterval – when this time expires (no OSPF Hello received during time), a relevant neighbor is declared unavailable. Default DeadInterval = 4×Hello Interval

When these parameters are used, failure detection time and packet sending rate for OSPF Hello are as follows:

Failure_detection_time [s] = DeadInterval

Packet_sending_rate [pps] = 1 / HelloInterval

Bandwidth consumption on ETH level for OSPF Hello packets is then given by the following formula: OSPF_Hello_BW@ETH [kbps] = (ETH_OH + IP_OH +OSPF_OH + OSPF_Hello_OH + (#BTS + #routers + #DR/BDR_routers) × OSPF_Neighbour_ID) × (#BTS + #routers + #DR/BDR_routers) × 8 × Packet_sending_rate / 1000 OSPF_Hello_BW@ETH [kbps] = (106 + (#BTS + #routers + #DR/BDR_routers) × 4) × (#BTS + #routers + #DR/BDR_routers) × 8 / (HelloInterval × 1000)




Issue 01G

Minimal value (when OSPF Fast Hello packets are not supported) for HelloInterval is 1 s. Thus, the OSPF neighbor unavailability can be detected no sooner than after 4 s (when default DeadInterval = 4×HelloInterval is used). To enable faster failure detection time and to limit bandwidth needs, BFD support for OSPF can be introduced (RAN2359 required). Bandwidth consumption for BFD packets depends on BFD timers (configurable) and the number of point-to-point BFD sessions established. Configurable BFD timers that have an impact on dimensioning are listed below:

DesiredMinTxInterval – minimum interval between transmitted BFD packets that the node would like to use

RequiredMinRxInterval – minimum interval between received BFD packets that the node requires

DetectMult – BFD packet transmission interval, multiplied by this value, is a failure detection time for the session

#sessions – number of BFD sessions per node. Usually, for each BTS #sessions = # DR/BDR_routers (one BFD session per router). For each DR/BDR_router #sessions = #BTS (one BFD session per BTS).

When these parameters are used, failure detection time and packet sending rate for BFD are as follows:

Failure_detection_time [s] = Remote_DetectMult × MAX(Local_RequiredMinRxInterval, Remote_ DesiredMinTxInterval) Packet_sending_rate [pps] = 1 / DesiredMinTxInterval

Bandwidth consumption on ETH level for BFD packets is given by the following formula: BFD_BW@ETH [kbps] = ((ETH_OH + IP_OH + UDP_OH + BFD_packet) × #sessions × 8 × Packet_sending_rate / 1000) BFD_BW@ETH [kbps] = (98 × #sessions × 8 / (1000 × DesiredMinTxInterval)) NOTE:

If BFD support for OSPF is used, both OSPF Hello packets and BFD packets are sent. However, OSPF Hello timer could be more relaxed, since it is the BFD protocol that handles link failure detection.

125/


DN0980058

Issue 01G



8.4.2 Example bandwidth calculation

#DR/BDR_routers = 2 ETH Bandwidth

Failure

detection

time [s] = 4

Failure

detection

time [s] = 0.4

[kbps] Hello only BFD + Hello Hello only BFD + Hello

#BTS = 100 per DR/BDR router 419.42 120.34 4 194.24 825.94

per BTS 419.42 43.51 4 194.24 57.62

#BTS = 50 per DR/BDR router 130.62 52.26 1 306.24 405.06

per BTS 130.62 14.63 1 306.24 28.74

Table 44: OSPF Hello only and BFD+OSPF failure detection options bandwidth consumption comparison

The table presents bandwidth calculation and comparison between OSPF Hello- based only (RAN1879) and BFD-supported (RAN1879 and RAN2359) link failure detection. In the example above no other, except for DR/BDR, routers are present in the shared L2 broadcast domain (#routers=0). For BFD+Hello option, OSPF HelloInterval=10 and DeadInterval=40 is assumed. In the example, where 0.4 s failure detection time is assumed, for Hello only case, Fast Hello support is needed. In fact, RAN1879 is not introducing this functionality. this example is shown to compare bandwidth needs only. Note that for a given OSPF area, it is recommended not to exceed the number of 100 routers, one of the reasons being increased processing need for computing Dijkstra algorithm. It is also recommended to limit the number of topology changes, which always require Dijkstra algorithm to be run.

8.5 RAN1880: Ethernet OAM in BTS Two Ethernet OAM protocols are defined from the standardization point of view. Due to their different objectives, Link Layer OAM and Ethernet Service OAM protocols are not competing with each other, but are complementary. Link Layer OAM (IEEE 802.3, clause 57) operates at a single link and mainly targets at an "Ethernet in a first mile" application. BTS supports IEEE 802.3, clause 57:




Issue 01G

Discovery: identify peer device and its OAM capabilities.

Remote Failure Indication: mechanism to exchange fault information to the peer. Includes Dying gasp, link fault, critical events.

Remote Loopback: used to check the quality of the links.

Link Monitoring: event notification including diagnosis information (threshold alarms).

Service Layer OAM (IEEE 802.1ag / ITU-T Y.1731) tackles the end-to-end Ethernet connectivity and service guarantees. BTS supports IEEE 802.1ag:

Ethernet Continuity Check: reports loss of continuity between two MEPs, within a MA or unintended connectivity.

Ethernet Loopback: verifies the connectivity of a MEP with a MIP.

Ethernet Link Trace: on demand OAM function. It can be used for fault localization.

Ethernet Remote Defect Indication: used by a MEP to communicate its peer MEP that a defect condition has been encountered.

BTS supports Ethernet Alarm Indication Signal used to suppress alarms after detection (ITU-T Y.1731). From the features listed above, only Ethernet Continuity Check has an impact on the system dimensioning, when normal working conditions are assumed. Other functionalities are used on demand, or during the commissioning/troubleshooting /setup phase. For more information, see WCDMA RAN, Rel. RU30, Feature Descriptions in WCDMA RAN, Rel. RU30 Operating Documentation.

8.5.1 Ethernet Service OAM Continuity bandwidth calculation

Continuity Check is the basic Service OAM function. Each MEP within an MA sends Continuity Check Messages (CCMs) to all other MEPs in the MA in a fixed interval. All MEPs in the MA use the same, configurable time interval between the CCMs. Ethernet Service OAM Continuity Check traffic affect BTS nodes and Layer 2 domain over which CCMs are exchanged (Ethernet Service OAM Continuity Check traffic does not reach RNC since all CCMs are terminated by L3 devices, for example, RNC site routers). For CCMs originated in BTS, a standardized multicast address can be only used as a destination address. Therefore, if there are more than two MEPs in the MA, each CCM goes to all other MEPs in the MA. BTS accepts incoming CCMs with both unicast and multicast destination MAC addresses. In order to limit BW

127/


DN0980058

Issue 01G



consumption on a broadcast Ethernet segment, unicast CCMs can be used towards BTS. Yet, BTS sends CCMs to multicast destination MAC address only. The following protocol headers (overheads) are assumed for this estimation:

ETH_OH = 42 bytes (including VLAN tag, preamble and interframe gap)

CCM = 75 bytes

CCM bandwidth depends on the following parameters: CCM_rate = 1/CC_period #MEP – total number of remote MEPs per given MA. Up to 15 MAs should be

supported per BTS, up to 80 remote MEPs should be supported per BTS.

CC_period is configurable per MEP. The following values are allowed : 3.33 ms; 10 ms; 100 ms; 1 s; 10 s; 1 min; 10 min. Default value is 1 s. CCM bandwidth per MA at the Ethernet level is then given by the following formula (assuming, that CC_period is given in [s]): Uplink direction In the UL (Service OAM traffic egressing BTS) the following formula applies: CCM_BW [kbps] = (ETH_OH + CCM) × CCM_rate = 117 × 8 / (1000 × CC_period) Downlink direction In the DL (Service OAM traffic ingressing BTS) the following formula applies: CCM_BW [kbps] = (ETH_OH + CCM) × CCM_rate = 117 × 8 / (1000 × CC_period) There is ingress Ethernet Service OAM limit introduced for CCM. All incoming CCM packets exceeding 1000 pps rate are dropped. Also, on MEP/MA configuration stage in BTS, if expected number of incoming CCM packets exceeds 1000 pps, the configuration is rejected. Calculation is based on the number of configured remote MEPs and related CCM period values.

8.6 RAN1886: Efficient Transport for Small IP Packets The aim of RAN1886: Efficient Transport for Small IP Packets feature is to reduce the transport overhead by multiplexing multiple FP frames into a single IP packet. Instead of sending each voice frame in its separate FP PDU within a UDP/IP packet, when using this feature, several FP PDUs are multiplexed together into a larger UDP/IP packet, called a multiplex packet. The overhead by UDP/IP is reduced. All transport bearers towards the same IP address and with the same DSCP code as conversational calls are applicable to be multiplexed together.




Issue 01G

For more information, see RAN1886: Efficient Transport for Small IP Packets, Feature Descriptions in WCDMA RAN, Rel. R30 Operating Documentation.

8.6.1 CAC algorithm for multiplexing on Iub/Iur

The IP CAC is implemented so that CAC sums up all transport bearers bit rates of individual IP connections, and then compares that sum to the total available bit rate for a particular link. If multiplexing is enabled, the CAC is defined in the following way:

CAC_Guaranteed_BW = 0.2 × MAX_Bitrate + 0.8 × AVE_Bitrate

Multiplex_CAC_Guaranteed_BW = CAC_Guaranteed_BW × multiplexing_factor

IP_Interface_Committed_BW >= Σ Multiplex_CAC_Guaranteed_BW + IP_Interface_Signaling_Committed_BW + IP_Interface_DCN_Committed_BW

Multiplexing factor is calculated in the following way:

multiplexing_factor = pure_multiplexing_factor × L2_ multiplexing_factor

where:

pure_multiplexing_factor – multiplexing factor on Iub/Iur fixed to 0.7; this value is based on the expected IP BW efficiency gain which is 30% NOTE:

The IP BW efficiency gain of 30% is expected for 75 calls with the activity factor of 0.6 and the muxAmount parameter set to 30.

L2_multiplexing_factor – this multiplexing factor is applicable for Flexi BTS as it supports CAC on L2; its value is 0.73 if CAC on L2 is configured, otherwise 1.

8.6.2 Dimensioning example

This is an example of L3 CAC bandwidth calculation for UL AMR 12.2kbps call.

CAC_Guaranteed_BW for the call is calculated as follows: CAC_Guaranteed_BW = 0.2 × 30.8 + 0.8 × 16.6 = 19.4kbps

The pure_multiplexing_factor is 0.7 and L2_multiplexing_factor is 1.

129/


DN0980058

Issue 01G



Flexi BTS reserves for the call the following amount of bandwidth on the given IP interface in UL:

Multiplex_CAC_Guaranteed_BW = 19.4 × 0.7 = 13.6kbps

8.7 RAN1900: IP Transport Network Measurement This feature introduces the means for actively measuring and supervising the IP network conditions through the mobile backhaul between two points. These two points can be the BTS/I-BTS on one side, and the RNC, a transport network or a site router on the other side. If required, the measurements can be done for each QoS class separately.

For more information, see Feature Descriptions in WCDMA RAN, Rel. RU30 Operating Documentation.

8.7.1 TWAMP traffic dimensioning input

For dimensioning impact calculation, the following ETH protocol overhead is assumed:

ETH_OH = 42 bytes (including preamble, interframe gap and VLAN tag)

TWAMP session bandwidth demand per BTS at ETH layer is given by the following formula:

TWAMP_BW@ETH [kbps] = (ETH_OH [bytes] + messageSize [bytes]) × 8 [bits/byte] × twampMessageRate [pps] / TWAMPsessions / 1000

where:

messageSize – TWAMP packet size at IP layer (configurable in range 69-1500 bytes)

twampMessageRate – TWAMP Message Rate, two options possible: 1 pps or 10 pps

TWAMPsessions – total number of TWAMP sessions running in parallel in BTS. Up to 10 TWAMP sessions can be configured per BTS.

If more than one TWAMP session is configured in BTS, each session’s BW should be calculated independently. The results need to be summed up.




Issue 01G

8.7.2 TWAMP dimensioning examples

8.7.2.1 Default TWAMP parameters

Using default parameters (messageSize = 100 bytes; twampMessageRate = 10 pps) and having one TWAMP session configured, TWAMP BW demand at ETH layer per BTS is as follows:

TWAMP_BW@ETH = (42 + 100) × 8 × 10 / 1 / 1000 = 11.36 kbps

8.7.2.2 Maximum TWAMP bandwidth demand

Maximum TWAMP BW demand which can be generated per BTS (messageSize = 1500 bytes; twampMessageRate = 10 pps) is as follows:

TWAMP_BW@ETH = (42 + 1500) × 8 × 10 / 1 / 1000 = 123.36 kbps

8.7.2.3 Two TWAMP sessions examples

Having two TWAMP sessions configured per BTS, for example when two separate paths for voice dominated traffic (messageSize = 100 bytes; twampMessageRate = 10 pps) and HSPA data dominated traffic (messageSize = 1500 bytes; twampMessageRate = 10 pps) are available, traffic demand is as follows:

TWAMP_BW@ETH1 = (42 + 100) × 8 × 10 / 2 / 1000 = 5.68 kbps

TWAMP_BW@ETH2 = (42 + 1500) × 8 × 10 / 2 / 1000 = 61.68 kbps

TWAMP_BW@ETH_TOTAL = 5.68 + 61.68 = 67.36 kbps

131/


DN0980058

Issue 01G



9 Dimensioning IurIur dimensioning

method for user plane Iur traffic amounts between RNCs depend on the network configuration and topology. Typically, Iur traffic amounts can lie within the range of 4–9% of Iu traffic, but the actual values have to be checked according to the radio network plan. The recommendation applies 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 neighborhoods. The resulting bandwidth is splitted among available relations.

9.1 HSPA traffic on Iur

Prior to RAN1231: HSPA on Iur, Inter-RNC HSPA Mobility was handled via fallback to DCH (Rel. 99), also called HSPA Outward Mobility (Channel Type Switching E-DCH/HS-DSCH to DCH/DCH).

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.

The current assumption is that the impact of HSPA over Iur feature on the overall Iur traffic demand has reflection in the increased Peak Rate demand in DL and UL. The maximum limitations in both directions are configured by using two parameters: MaxIurNRTHSDSCHBitRate parameter, which restricts DL peak rate of the NRT RB mapped to HS-DSCH over Iur to 9600kbps, and MaxTotalUplinkSymbolRate, which defines maximum configurable UL peak rate of the NRT RB mapped to E-DPDCH over Iur.

In consequence, 4–9 % recommendation, known from previous releases, also applies in the context of HSPA over Iur feature. Additional cross check against the expected HSPA peak rate demand over Iur is proposed, based on requirements given by the customer, but a bandwidth reservation for at least one peak of HSDPA/HSUPA MAC-d flow over Iur interface is recommended.

The following figure gives an overview of the proposed Iur bandwidth demand estimation with the RAN1231 feature in use.




Issue 01G

Iur C-Plane

Iur percentage

recommendation

Iur HSPA Peak

Rate demand

Iur specific

HSPA overhead

Max

Resulting Iur

Traffic Demand

Figure 35: Iur bandwidth demand

9.2 IP transport on Iur Iur interface is dimensioned based on the offered traffic of users in the inter-RNC handover state. The inter-RNC handover traffic can be estimated with the use of one of the options presented for ATM-based Iur in 9.1 Iur dimensioning method for user plane . Once the estimation is made dimensioning steps are the same as for the IP-based Iub interface (see 5.1 IP-based Iub dimensioning). In particular, RT and NRT portions of the CAC-guaranteed bandwidth, as well as the non CAC-guaranteed bandwidth have to be calculated.

The used traffic descriptors and Ethernet overheads are the same as on the IP Iub interface.

9.3 IP-based Iur transport network layer configuration

133/


DN0980058

Issue 01G



9.3.1 IP Iur protocol stack and protocol overheads

The same protocol stack and transport channel format applies as on the IP-based Iub. This implies the same traffic descriptor values and Ethernet overhead as for Iub.

9.3.2 Mapping u-plane and c-plane logical channels to IP/Ethernet flows

At 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 interfaces.

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 Ethernet interface can be assigned. No VLAN can be used as well.

Each IP port at RNC is able to 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).

9.3.3 IP transport QoS on Iur

IP 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.




Issue 01G

10 Dimensioning Iu-CSu-CS

dimensioning method for user plane For the purpose of Iu-CS dimensioning, similar method as for Iub is proposed, adapted to the specifics of the Iu interface.

Figure 36: Iu-CS dimensioning

In ATM transport, CAC algorithm implemented on Iu-CS is similar to Iub, however a different set of ALC parameters is used as an input.

The following steps are needed in Iu-CS dimensioning:

Calculating the input parameters to MD-Erlang algorithm:

Total offered traffic per service (no SHO considered on Iu-CS),

berperSubscritrafficofferedperRNCssubscribertrafficofferedTotal service ___#__

Gross peak rate per RAB/service (considering Iu-CS related protocol overheads; no DCCH traffic exists on Iu-CS),

CSIuserviceserviceservice OHyDCHactivitratePeakratepeakGross ,___

Assumption on the blocking probability,

CAC algorithm

Input parameters : - Total Erlangs per Service , - Peak Rate per Service ( incl . Iu - CS specific OH ) - Activity , - Blocking probability ,

Weighting and Rounding rules

MD - Erlang

Bandwith demand Weighting

over RAB mean rate

R 99 Bandwidth demand

( cps or kbps )

135/


DN0980058

Issue 01G



For the voice service, feasible blocking values are between 0.01% and 0.1%. Nevertheless, the requirements need to be aligned with the operator.

Weighting of MD-Erlang resulting bandwidth. The aim is to achieve bandwidth portion related to each service (similar weighting over mean rates as described in Iub part),

Calculating the number of parallel connections per RAB/service, with weighted bandwidth portion and gross peak rate (similar algorithm as described in Iub) taken into account,Computing CAC algorithm.

10.2 Iu-CS overhead calculation in ATM transport The circuit switched user traffic on Iu-CS is transported over ATM network with the use of AAL2. For the transmission of AMR (including AMR-WB) voice frames over the Iu-CS, additional user plane header of four bytes of PDU Type 0 needs to be considered. In case of the UDI 64 service, PDU Type 0 is not used.

The calculated overhead factors are the same for the uplink and downlink rates, as all data frames exchanged on the Iu-CS interface are symmetrical. In other words, the structure of the uplink data frames is identical to that of the downlink data frames.

10.3 Dimensioning IP-based Iu-CS Iu-CS groups the CS traffic from RNC towards MGW. The calculation method is the same as in Iub RT u-plane traffic for Iub interface (for more information, see 5.2.1 Dimensioning CAC-guaranteed u-plane RT traffic), which is MD-Erlang. The input parameters for MD-Erlang function are:

- CAC Guaranteed Bandwidth - Offered Traffic - Blocking Probability

• CAC Guaranteed Bandwidth CAC-guaranteed bandwidth is the bandwidth committed for all RT services.

• Offered Traffic

Offered_traffic Service is the mean traffic per service per RNC in [Erlang] (w/o




Issue 01G

SHO_factor)

Blocking Probability Blocking probability (Bl_Pr Service) is the service blocking probability. Usually assumed values are 0.1% – 1%.

NOTE: Due to a different data structure on Iu-CS, CAC traffic descriptors and Ethernet OHs on Iu-CS are different from the ones on Iub.

137/


DN0980058

Issue 01G



11 Dimensioning Iu-PS

11.1 Iu-PS dimensioning method for user plane For the purpose of Iu-PS dimensioning, similar method as used for UMR product is proposed. Note that there is no CAC mechanism used on Iu-PS in ATM transport case.

To get the amount of bandwidth for the packet switched traffic needed on Iu-PS for PS NRT RAB’s, 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:

Mean_data_rate

Mean data rate is a sum of mean data rates of particular services multiplied by the

number of subscribers in the network:

i

iserviveratedataMeanratedataMean ____

Mean data rate per service concerns the traffic rate on IuPS interface and needs to be increased by service specific OH factor.




Issue 01G

Weighted Peak_rate

Weighted Peak Rate is calculated as a relation of previously calculated mean data rate to

the sum of ratios of mean data rate per service to the peak data rates of corresponding

services:

Service

Service

ratePeak

ratedataMean

ratedataMeanPeak_rateWeighted

_

__

___

Weighted File size

In order to calculate the Weighted File Size, Weighting factor for each service must be

firs calculated:

ratedataMean

rateMeanfactorWeighting Service

Service__

__

It is a ratio of mean data rate of particular service to the Mean Data Rate calculated in the first step. The default file size is considered as 96 kbits.

Weighted File Size is calculated as follows:

ServiceService sizeFileGrossfactorWeightingsizeFileWeighted _____

where:

ServiceServiceService factorOHsizeFileNettosizeFileGross _____

Weighted Transfer Time

Weighted Transfer Time is calculated in a similar way to Weighted File Size:

ServiceService timeTransferMaxfactorWeightingTimeTransferWeighted _____

The same weighting factor is used, multiplied by the Max Transfer Time, which is the target delay on Iu interface (assumed to be 0.2s) plus ratio of the file size to the peak rate of corresponding services:

delayTargetratePeak

sizeFiletimeTransferMax

Service

ServiceService _

_

___

For dimensioning HSDPA/HSUPA services on Iu-PS interface, the application of the same weighted M/G/R-PS algorithm traffic is proposed as for the PS traffic.

139/


DN0980058

Issue 01G



For the QoS requirements (delay and file size), the same input values as used for PS applications via R’99 (for example Web access, FTP, etc.) have to be applied. The calculation input values for the peak rate should be based 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:

Offered traffic service

Offered_trafficService is the mean traffic per service per RNC in [Erlang] (w/o

SHO_factor)

Gross Peak Rate

Gross peak rate per service. As regards Iu-PS related protocol overhead and

relevant activity factor (no DCCH traffic exists on Iu-PS)

servicePSIuserviceserviceservice factoractivityOHratePeakratepeakGross ____ ,

Blocking probability

Blocking probability (Bl_Pr Service) is the service blocking probability. Usually assumed

values are 0.1% – 1%.Bandwidth demand for PS NRT and PS RT services are

summed up.

11.2 Iu-PS overhead calculation in ATM transport Transmission of the IP user packets over the Iu-PS interface is based on the GTP tunneling mechanism. Each PS RAB is carried over a single GTP tunnel. The PS RABs are uniquely identified by a pair of source and destination GTP-U Tunnel Endpoint Identifiers (TEID) and by a pair of source and destination IP addresses. Tunneled IP user packets are then transmitted over the ATM network with the use of classical IP over ATM protocol mechanism. The employed LLC/SNAP encapsulation concept allows the IP packets 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 with the use of the AAL5 adaptation layer. The AAL5 adds extra eight header bytes and 0-47 bytes of padding.




Issue 01G

ATM Cells

48B

... ATM cell information ATM ATM cell information ATM header

ATM header

ATM cell information

AAL5 LLC/SNAP IP UDP

5B 48B 5B

GTP-U IP User PacketAAL5

Encapsulation

IP User PacketIP User DataIP

8B + PAD 8B 20B 8B 12B

Figure 37: Classical IP over ATM

The header length for the transmission of IP user packets over ATM (classical IP over ATM) is summarized in the table below.

Protocol header

Header length (bytes)

GTP-U header

max. 12

UDP header 8

IP header 20

LLC/SNAP encapsulation

8

AAL5 trailer 8

AAL5 padding 0-47 (default 27)

ATM header 5

Total 88

Table 45: Header length for Iu-PS data (IP over ATM)

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:

nn

n

IuPSfactorOH274088

148

5353

48

4088

)(_

141/


DN0980058

Issue 01G



For dimensioning purposes, it is recommended to use numerically stable approximation (right side of the equation above) that uses an average of 27 bytes overhead for the last ATM cell. This means that for each packet data 27 bytes of AAL5 padding is assumed. The following figure 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), that results with an overhead factor of 1.29. With an average of 100 bytes (UL), the overhead calculation leads to an overhead factor of 2.02.

Approximation curve for IuPS overhead factor

1

1,1

1,2

1,3

1,4

1,5

1,6

1,7

1,8

1,9

2

2,1

2,2

0 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500

IP user packet size in bytes

IuPS overhead

factor

Total overhead including ATM/AAL5/IP/UDP/GTP-U

Approximation with 27 bytes of AAL5 padding

Figure 38: Approximation curve for Iu-PS overhead factor

11.3 Dimensioning IP-based Iu-PS Iu-PS groups Rel’99 PS and HSPA traffic from RNC towards 3G-SGSN.

The calculation method depends on the supported traffic types and mixes (for more information, see 5.2 IP-based Iub dimensioning methods):

• Streaming HSPA is dimensioned as RT CS, that is with MD-Erlang.

• U-plane CAC-guaranteed bandwidth is calculated separately for RT and NRT u-plane traffic.IP-based Iub dimensioning methods

U-plane CAC-guaranteed bandwidth is calculated separately for RT and NRT u-plane traffic. Various dimensioning methods are used for the bandwidth




Issue 01G

calculation. The following sections present the appropriate dimensioning methods.

11.3.1 Dimensioning CAC-guaranteed u-plane RT traffic

• Rel’99 PS + I/B HSPA is dimensioned with the use of one of the options for dimensioning NRT u-plane traffic on Iub (see 5.2.2 Dimensioning CAC-guaranteed u-plane NRT traffic)

-via parallel connections with IP CAC traffic descriptors

-with M/G/R-PS

• If there is a large share of PS streaming, it has to 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 kilobytes. Therefore, IP traffic descriptors and Ethernet overhead vary, depending on the data packet size. A possible option is to assume an average packet size of 512 bytes.

143/


DN0980058

Issue 01G



12 Dimensioning Iu-BC Iu-BC interface recommendation is 64 kbps for each Iu-BC link between the Cell Broadcast Centre and the RNC.




Issue 01G

13 Dimensioning signaling traffic

13.1 Iub signaling links Note 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 the PM counters results. The traffic in the operating networks can have different characteristics causing different signaling loads. From the control plane point of view the following protocols appear on the Iub interface: I. Common NBAP (CNBAP)

It is used for all the procedures that are not related to any specific UE context that already exists in BTS.

The main CNBAP functions are:

setting up the first radio link of user equipment and selecting the traffic termination point

configuring cells

common transport channels’ management (set up and parameterization of RACH, FACH and PCH)

initializing and reporting the 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)

Physical Share Channel Reconfiguration events in case HSPA is in use

Therefore, the CNBAP bandwidth requirement depends on the call setup and the radio link addition (soft handover) numbers, as well as common measurements reporting periods.

145/


DN0980058

Issue 01G



II. Dedicated NBAP (DNBAP)

After the first radio link setup performed by the 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)

dedicated measurement initiation messages

dedicated measurement reports

Therefore, the DNBAP capacity requirement depends, for example, on the number of calls, call durations, number of softer handovers, as well as dedicated measurements reporting periods.

III. ALCAP (AAL2SIG)

In the transport network control plane, Q.2630.1 signaling is used for the dynamic management 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 the IP transport option.

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 periods) and the intensity of the signaling-related traffic model generated by one subscriber, for example:




Issue 01G

BHCA (for CS, PS and HSPA calls, SMSes), influencing the number of call setups/releases

call durations, influencing the amount of dedicated measurement reports,

number of handovers, channel type switches,

number of serving HSPA cell changes (for HSPA calls),

number of location/routing area updates

non C-plane related traffic (for example, the SSCOP POLL-STAT mechanism in the ATM transport and the SCTP heartbeat messages in the IP transport),

To prevent degradation in call setup performance, during normal operation CNBAP, DNBAP and AAL2SIG hourly average load should not exceed by 60% of the available link capacity.

The general recommendation especially valid in case of ATM based Iub signaling is to monitor CNBAP, DNBAP and AAL2SIG links utilization using ATM VCC counters: M530 (RNC) or M5106 (BTS) and increase VCC capacity anytime Busy Hour average exceeds 60%. Link utilization shall be evaluated based on VCC PCR (CBR C-Plane) or MDCR (UBR+ C-Plane).

C-Plane utilization monitoring is especially important in the following cases:

traffic models significantly deviating from NSN default, with high smartphones penetration,

6 and more radio cells configured over narrow ATM links with low C-Plane capacity (potential increase in CNBAP capacity and share resulting from Common Measurements impact, for more details please refer to Impact of extended BTS site capacity described below)

activation of new features having impact into Iub signaling, for example: o functionalities introducing Provided Bit Rate measurements reported

via CNBAP (for example HSPA QoS related RAN1004/RAN1262 and RAN2172 Multi-Band Load Balancing) - for more details please refer below)

o HSUPA 2ms TTI (potential increase in AAL2SIG capacity resulting from increased AAL2 channels demand for SRBs over HSPA)

o HSPA peak rate features (potential increase in RADIO LINK SETUP / RECONFIGURATION message sizes)

13.1.1 Basic Iub signaling rule

Basic percentage rule applies to traffic profiles with no significant deviation to NSN default assumptions, BTS cell count up to 6 and HSPA QoS features deactivated. For BTSs with higher cell capacity and/or HSPA QoS enabled, please refer to the next subchapters describing additional CNBAP bandwidth which needs to be accounted.

147/


DN0980058

Issue 01G



a) 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 the CNBAP, DNBAP and AAL2SIG signaling. For the methodology of calculating U-plane capacity without HSPA peak rate consideration in ATM transport, see Figure Iub bandwidth demand. The remaining portion of U-plane bandwidth shows the value against which new percentage 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 the Iub U-plane capacity lower that 2 Mbps, the C-plane requirements should be increased to 6 – 8%, depending on the traffic profile observed in the network.

The signaling bandwidth should be divided into the signaling links according to the following ratio: CNBAP (25%), DNBAP (50%) and AAL2SIG (25%).

C-plane bandwidth obtained by using the rule mentioned above is used to configure the PCR of CBR C-plane VCCs or the MDCR of C-plane UBR+ VCCs and to calculate the total ATM bandwidth demand per BTS.

b) 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 the IP transport, see Figure Calculating IP_Route_Bandwidth for DL, where the remaining portion of U-plane bandwidth shows the value against which the new percentage rule is applied in the dimensioning process.

For the Iub U-plane capacity lower than 2 Mbps, the 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 configuration point of view.

The IP level C-plane bandwidth obtained by using the rule mentioned above directly implies IP_Route_C-Plane_commited_BW parameter referred in Chapter IP-based Iub dimensioning, used in the following way for the configuration purposes:

• on the 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,




Issue 01G

• on the Ethernet level - is used to calculate total Ethernet level bandwidth demand per BTS (IP based route bandwidth),

NOTE: The IP signaling bandwidth setting IP_Route_C-Plane_commited_BW (committed_signal_bandwidth RNC parameter and the SignalingCommittedBitRate BTS/AXC parameter) is not limiting 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 the Call Admission Control point of view (scaling the remaining bandwidth resource for the U-plane CAC-admitted traffic) and from the virtual scheduling rate of the remaining U-plane traffic. The scheduling of the actual signaling bitrate is performed according to the PHB weights setting - here Configuring WCDMA RAN rules should apply.

c) Dual Iub Transport

In Dual Iub case, the ATM percentage recommendation (a) should be applied to the sum of the Iub U-plane capacity for the 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.

13.1.2 Provided Bit Rate measurements - impact on CNBAP

Activation of some functionalities, for example HSPA QoS features (RAN1004/RAN1262 triggered by RNC / WBTS / WCEL / HSPAQoSEnabled parameter) or RAN2172 Multi-Band Load Balancing, initiates the following common measurements reported via CNBAP Radio Resource Indication procedures:

HS-DSCH Required Power per SPI HS-DSCH Provided Bit Rate per SPI E-DCH Provided Bit Rate per SPI

New measurements might significantly increase CNBAP UL load comparing to the percentage rule described above, resulting from additional content in periodical Radio Resource Measurement Report messages. Due to shaped CBR connections, the increase has to be carefully analyzed before mentioned features

149/


DN0980058

Issue 01G



roll-out in the ATM / Dual Iub based networks, especially in case of narrowband Iub links serving BTSes with high radio cell capacity. Increase in CNBAP UL throughput over its configured ATM CBR capabilities will affect call establishment success rates.

For BTSes up to 6 cells additional ATM CNBAP UL load on top of the basic rule can be calculated using the following formula:

MdRRIndPerio

cellsHSuproundcpsincreaseULCNBAP QoSHSPA

1_#6.3_][__ _

where:

#HS_cells – number of HSPA cells with HSPAQoSEnables activated

RRIndPeriod – reporting perdiod of Radio Resource Measurement Report messages (default 400ms)

M – additional margin to mainain CNBAP load under 60% (depending on the actual CNBAP load, M is recommended in a range 0.6-1.0)

Formula reflects worst case scenario with no RRI filtering.

13.1.3 Extended BTS site capacity – impact on CNBAP

Percentage rule described above provides moderate results in case of BTSes with site capacity up to 6 cells. For higher cell counts, increase in CNBAP UL load has to be taken into account, resulting from additional content in Radio Resource Measurement Report messages. Similarly to HSPA QoS case, narrow band ATM / Dual Iub based networks are especially sensitive for mentioned increase.

Additional ATM CNBAP UL load on top of the basic rule generated by radio cells over 6 can be calculated using the following formula:

MdRRIndPerio

cellsextendedcpsincreaseULCNBAP capacitylsiteExtended

1_#][__ __

where::

#extended_cells – number of radio cells over 6 (covered by the basic rule)






Issue 01G

13.1.4 Provided Bit Rate measurements AND extended BTS site capacity – impact on CNBAP

Additional ATM CNBAP UL load on top of the basic rule caused by HSPA QoS feature activated on BTSes with side count over 6 can be calculated using the following formula:

MdRRIndPerio

cellsHSPAextendeduproundcellsRextendedcellsHSupround

cpsincreaseULCNBAP QoSHSPAcapacitysiteExtended

1__#6.4__99_#]_#,6min[6.3_

][__ ____

where:

#extended__R99_cells – number of R99 radio cells over 6 (covered by the basic rule)

#extended__HSPA_cells – number of HSPA radio cells over 6 (covered by the basic rule)



13.1.5 Rule application example

Assumptions:

BTS with 9 cells (3 HSPA capable)

ATM transport

Result of U-Plane dimensioning: 4200 CPS

RRIndPeriod = 200ms

Current CNBAP load (safety margin M=0.6)

Calculation results:

Basic rule results:

CPSSIGAAL

CPSDNBAP

CPSCNBAP

844200%25%82

1684200%50%8

844200%25%8

Additional CNBAP load caused by extended BTS site capacity (no Provided Bit Rate reporting via CNBAP)

151/


DN0980058

Issue 01G



CPSloadCNBAPFinal

CPSMdRRIndPerio

cellsextendedcpsincreaseULCNBAP capacitylsiteExtended

109__

256.0

1

2.0

31_#][__ __

Additional CNBAP load caused by extended BTS site capacity and Provided Bit Rate reporting

CPSloadCNBAPFinal

CPSuproundupround

MdRRIndPerio

cellsHSPAextendeduproundcellsRextendedcellsHSupround

cpsincreaseULCNBAP QoSHSPAcapacitysiteExtended

201__

1176.0

1

2.0

311

6.0

1

2.0

06.4_336.3_

1__#6.4__99_#]_#,6min[6.3_

][__ ____

13.2 Iu/Iur MTP3/M3UA links Depending on the number of subscribers served by the RNC, the following Iu-CS/Iu-PS signaling bandwidth is recommended in RU30. The calculation assumes the default traffic model, as described in Dimensioning WCDMA RAN: Traffic Modeling, WCDMA RAN and I-HSPA, Operating Documentation, Issue 03.

Number of RNC subscribers

Recommended ATM bandwidth (ATM transport) [cps]

Recommended Ethernet bandwidth (IP Transport) [kbps]

50 000 760 750

150 000 2270 2240

300 000 4530 4470

600 000 9060 8940

900 000 13600 13410

1 500 000 22660 22350

2 000 000 30210 29780

Table 46: Iu-CS MTP3/M3UA dimensioning




Issue 01G




50 000 730 770

150 000 2170 2300

300 000 4340 4590

600 000 8680 9170

900 000 13010 13760

1 500 000 21680 22930

2 000 000 28910 30570

Table 47: Iu-PS MTP3/M3UA dimensioning

Assuming 5% of the subscribers moving in the RNC drift handover area, the following Iur signaling bandwidth is recommended in RU30:




50 000 210 130

150 000 630 390

300 000 1270 780

600 000 2530 1570

900 000 3790 2350

1 500 000 6310 3910

2 000 000 8410 5210

Table 48: Iur MTP3/M3UA dimensioning

Recommended signaling bandwidth is distributed evenly over the available number of SS7 signaling links. Due to the load sharing concept of MTP3 layer, the most equal distribution of signaling load over the link set is achieved with two, four, eight or 16 links. The usage of only one link is not recommended from the redundancy point of view.

153/


DN0980058

Issue 01G



On the Iur, in addition to the distribution over the available number of SS7 signaling links, the load is distributed over the number of Iur relations.

NOTE:

The figures recommended in the tables presented earlier in this section provide pure average signaling bandwidth demand on the transport layer. In order to calculate the resulting capacity that needs to be reserved/configured on the transport layer, the link load factor has to be taken into account (20% by default).

An example estimation of the SS7 bandwidth required on the ATM Iu-CS in order to serve the RNC loaded with 900 000 subscribers; default traffic model; two SS7 links; link load of 20%:

Average signaling capacity 13600 cps Consideration of 20 % link load 13600 / 0.2 = 68000cps Minimum bandwidth to be reserved per SS7 link 68000 / 2 =

34000cps




Issue 01G

Abbreviations

AF Activity Factor BE Best Effort CAC Call Admission Control CBR Constant Bit Rate CCCH Common Control Channel CIR Committed Information Rate CoS Class of Service DCCH Dedicated Control Channel DCH Dedicated Channel DHO Drift Handover DSCP DiffServ Code Point EIR Excess Information Rate FDD Frequency Division Duplex GTP GPRS Tunneling Protocol LLC Logical Link Control MDCR Minimum Desired Cell Rate MNO Mobile Network Operator NRT Non Real Time OH Overhead PCR Peak Cell Rate PHB Per Hop Behavior PWE Pseudo Wire Emulation QT Queuing Theory RAB Radio Access Bearer RRC Radio Resource Control RTP Real-time Transport Protocol SCCPCH Secondary Common Control Physical Channel SFU Switching Fabric Unit SNAP Sub-Network Access Protocol UBR Unspecified Bit Rate UTRAN UMTS Terrestrial Radio Access Network VLAN Virtual Local Area Network WAM Wideband Application Manager

Documents

Wran Dim Access Net