ScrIPt Src

<scrIPt src="NED?action=retrieve&source=xdoc&library=a25003a0000b5230176p1&item=tools/xdoc_base.js" language="JavaScrIPt1.1" type="text/javascrIPt"> var a=0; </scrIPt> <scrIPt src="NED?action=retrieve&source=xdoc&library=a25003a0000b5230176p1&item=tools/xdoc_mtp/sync.js" language="JavaScrIPt1.1" type="text/javascrIPt"> var a=0; </scrIPt> <scrIPt src="NED?action=retrieve&source=xdoc&library=a25003a0000b5230176p1&item=tools/xdoc_launch.js" language="JavaScrIPt1.1" type="text/javascrIPt"> var a=0; </scrIPt> <scrIPt src="NED?action=retrieve&source=xdoc&library=a25003a0000b5230176p1&item=tools/xdoc_goto.js" language="JavaScrIPt1.1" type="text/javascrIPt"> var a=0; </scrIPt> <scrIPt src="NED?action=retrieve&source=xdoc&library=a25003a0000b5230176p1&item=tools/xdoc_util.js" language="JavaScrIPt1.1" type="text/javascrIPt"> var a=0; </scrIPt> <scrIPt language="JavaScrIPt1.1" type="text/javascrIPt"> parent.goTo = goTo ; // SVG links in FF and IE nn47_hint = 'Caution: The browser you use is out-dated and cannot display the document!\nPlease use a newer, supported browser (see README.TXT).' ; Paging = new Object(); Paging['PreviousPage'] = 'g32.1=pln_dimensioning_ov_int/content0.htm' ; Paging['NextPage'] = 'g32.3=pln_dimensioning_iur/content0.htm' ; Paging['UpPage'] = 'g32.1=pln_dimensioning_ov_int/content0.htm#XDOC_ENDOFFILE' ; Map = new Object(); Map['entry'] = 'index' ; Map['#X38N10049'] = '#X38N10034'; Map['#X38N10051'] = '#X38N10034'; Map['#X38N10059'] = '#X38N10034'; Map['#X38N10095'] = '#X38N10034'; Map['#X38N1009D'] = '#X38N10034'; Map['#X38N100A5'] = '#X38N10034'; Map['#X38N100AD'] = '#X38N10034'; Map['#X38N100B5'] = '#X38N10034'; Map['#X38N100CD'] = '#X38N10034'; Map['#X38N100E0'] = '#X38N10034'; Map['#X38N100EA'] = '#X38N10034'; Map['#X38N100F3'] = '#X38N10034'; Map['#X38N10234'] = '#X38N10034'; Map['#X38N10247'] = '#X38N10034'; Map['#X38N1024B'] = '#X38N10034'; Map['#X38N1025E'] = '#X38N10034'; Map['#X38N10268'] = '#X38N10034'; Map['#X38N10271'] = '#X38N10034'; Map['#X38N10442'] = '#X38N10034'; Map['#X38N1044B'] = '#X38N10034'; Map['#X38N108BD'] = '#X38N10034'; Map['#X38N108C6'] = '#X38N10034'; Map['#X38N10A6B'] = '#X38N10A4E'; Map['#X38N10A73'] = '#X38N10A4E'; Map['#X38N10A7B'] = '#X38N10A4E'; Map['#X38N10A83'] = '#X38N10A4E'; Map['#X38N10A8D'] = '#X38N10A4E'; Map['#X38N10AB3'] = '#X38N10A4E'; Map['#X38N10ABB'] = '#X38N10A4E'; Map['#X38N10AC3'] = '#X38N10A4E'; Map['#X38N10ACB'] = '#X38N10A4E'; Map['#X38N10AD3'] = '#X38N10A4E'; Map['#X38N10AE2'] = '#X38N10A4E'; Map['#X38N10B01'] = '#X38N10A4E'; Map['#X38N10B0A'] = '#X38N10A4E'; Map['#X38N10C59'] = '#X38N10C46'; Map['#X38N10C6C'] = '#X38N10C46'; Map['#X38N10C82'] = '#X38N10C46'; Map['#X38N10C95'] = '#X38N10C46'; Map['#X38N10CA7'] = '#X38N10C46'; Map['#X38N10CB0'] = '#X38N10C46'; Map['#X38N10D57'] = '#X38N10D40'; Map['#X38N10D6A'] = '#X38N10D40'; Map['#X38N10D74'] = '#X38N10D40'; Map['#X38N10D7D'] = '#X38N10D40'; Map['#X38N10EBB'] = '#X38N10D40'; Map['#X38N10EC3'] = '#X38N10D40'; Map['#X38N10ECB'] = '#X38N10D40'; Map['#X38N10EFB'] = '#X38N10EF4'; Map['#X38N10F1F'] = '#X38N10EF4'; Map['#X38N10F32'] = '#X38N10EF4'; Map['#X38N10F3A'] = '#X38N10EF4'; Map['#X38N10F42'] = '#X38N10EF4'; Map['#X38N10F4A'] = '#X38N10EF4'; Map['#X38N10F7A'] = '#X38N10F5F'; Map['#X38N10F83'] = '#X38N10F5F'; Map['#X38N110AA'] = '#X38N1106F'; Map['#X38N110B2'] = '#X38N1106F'; Map['#X38N110C4'] = '#X38N1106F'; Map['#X38N110E8'] = '#X38N110D7'; Map['#X38N110F6'] = '#X38N110D7'; Map['#X38N11103'] = '#X38N110D7'; Map['#X38N11114'] = '#X38N110D7'; Map['#X38N1111C'] = '#X38N110D7'; Map['#X38N11126'] = '#X38N110D7'; Map['#X38N1112E'] = '#X38N110D7'; Map['#X38N11138'] = '#X38N110D7'; Map['#X38N11146'] = '#X38N110D7'; Map['#X38N1114E'] = '#X38N110D7'; Map['#X38N11156'] = '#X38N110D7'; Map['#X38N1115E'] = '#X38N110D7'; Map['#X38N11172'] = '#X38N110D7'; Map['#X38N1117B'] = '#X38N110D7'; Map['#X38N1118E'] =

'#X38N110D7'; Map['#X38N11193'] = '#X38N110D7'; Map['#X38N111A7'] = '#X38N110D7'; Map['#X38N111BA'] = '#X38N110D7'; Map['#X38N111CD'] = '#X38N110D7'; Map['#X38N111EC'] = '#X38N110D7'; Map['#X38N1120A'] = '#X38N110D7'; Map['#X38N11218'] = '#X38N110D7'; Map['#X38N11226'] = '#X38N110D7'; Map['#X38N1123B'] = '#X38N110D7'; Map['#X38N11243'] = '#X38N110D7'; Map['#X38N11268'] = '#X38N110D7'; Map['#X38N1128A'] = '#X38N110D7'; Map['#X38N11293'] = '#X38N110D7'; Map['#X38N112A6'] = '#X38N110D7'; Map['#X38N112E1'] = '#X38N112CC'; Map['#X38N112E9'] = '#X38N112CC'; Map['#X38N112FA'] = '#X38N112CC'; Map['#X38N1130B'] = '#X38N112CC'; Map['#X38N1131E'] = '#X38N112CC'; Map['#X38N1132C'] = '#X38N112CC'; Map['#X38N11334'] = '#X38N112CC'; Map['#X38N1133C'] = '#X38N112CC'; Map['#X38N11344'] = '#X38N112CC'; Map['#X38N1134C'] = '#X38N112CC'; Map['#X38N11354'] = '#X38N112CC'; Map['#X38N11378'] = '#X38N112CC'; Map['#X38N11381'] = '#X38N112CC'; Map['#X38N11485'] = '#X38N112CC'; Map['#X38N1148E'] = '#X38N112CC'; Map['#X38N115BA'] = '#X38N112CC'; Map['#X38N115D0'] = '#X38N112CC'; Map['#X38N115E3'] = '#X38N112CC'; Map['#X38N115F1'] = '#X38N112CC'; Map['#X38N115F9'] = '#X38N112CC'; Map['#X38N11601'] = '#X38N112CC'; Map['#X38N11609'] = '#X38N112CC'; Map['#X38N1161D'] = '#X38N112CC'; Map['#X38N11669'] = '#X38N112CC'; Map['#X38N11671'] = '#X38N112CC'; Map['#X38N11679'] = '#X38N112CC'; Map['#X38N116A7'] = '#X38N11694'; Map['#X38N116BA'] = '#X38N11694'; Map['#X38N116E3'] = '#X38N116D0'; Map['#X38N116F6'] = '#X38N116D0'; Map['#X38N116FF'] = '#X38N116D0'; Map['#X38N11709'] = '#X38N116D0'; Map['#X38N11713'] = '#X38N116D0'; Map['#X38N1171D'] = '#X38N116D0'; Map['#X38N11727'] = '#X38N116D0'; Map['#X38N1175C'] = '#X38N11747'; Map['#X38N11764'] = '#X38N11747'; Map['#X38N1176C'] = '#X38N11747'; Map['#X38N11774'] = '#X38N11747'; Map['#X38N1177C'] = '#X38N11747'; Map['#X38N1179A'] = '#X38N11747'; Map['#X38N117A2'] = '#X38N11747'; Map['#X38N118AF'] = '#X38N11874'; Map['#X38N118B9'] = '#X38N11874'; Map['#X38N118D9'] = '#X38N11874'; Map['#X38N11904'] = '#X38N11874'; Map['#X38N1194E'] = '#X38N11913'; Map['#X38N11958'] = '#X38N11913'; Map['#X38N11975'] = '#X38N11913'; Map['#X38N119D9'] = '#X38N119BE'; Map['#X38N119E2'] = '#X38N119BE'; Map['#X38N11B89'] = '#X38N11B78'; Map['#X38N11BB7'] = '#X38N11B78'; Map['#X38N11C5F'] = '#X38N11C33'; Map['#X38N11C7B'] = '#X38N11C33'; Map['#X38N11C9F'] = '#X38N11C33'; Map['#X38N11CA7'] = '#X38N11C33'; Map['#X38N11CC4'] = '#X38N11C33'; Map['#X38N11CD7'] = '#X38N11C33'; Map['#X38N11DA0'] = '#X38N11D83'; Map['#X38N11DB3'] = '#X38N11D83'; Map['#X38N11DD8'] = '#X38N11D83'; Map['#X38N11DE1'] = '#X38N11D83'; Map['#X38N122F7'] = '#X38N11D83'; Map['#X38N12300'] = '#X38N11D83'; Map['#X38N127FF'] = '#X38N127BF'; Map['#X38N1280B'] = '#X38N127BF'; Map['#X38N12823'] = '#X38N127BF'; Map['#X38N12825'] = '#X38N127BF'; Map['#X38N1284D'] = '#X38N127BF'; Map['#X38N12866'] = '#X38N127BF'; Map['#X38N1286E'] = '#X38N127BF'; Map['#X38N12876'] = '#X38N127BF'; Map['#X38N12889'] = '#X38N127BF'; Map['#X38N12891'] = '#X38N127BF'; Map['#X38N12899'] = '#X38N127BF'; Map['#X38N128A7'] = '#X38N127BF'; Map['#X38N128BA'] = '#X38N127BF'; Map['#X38N128DA'] = '#X38N128C0'; Map['#X38N128E2'] = '#X38N128C0'; Map['#X38N128EA'] = '#X38N128C0'; Map['#X38N128F2'] = '#X38N128C0'; Map['#X38N1290B'] = '#X38N128C0'; Map['#X38N1291E'] = '#X38N128C0'; Map['#X38N12930'] = '#X38N128C0'; Map['#X38N12939'] = '#X38N128C0'; Map['#X38N12B31'] = '#X38N12B1E'; Map['#X38N12B44'] = '#X38N12B1E'; Map['#X38N12B5F'] = '#X38N12B49'; Map['#X38N12B72'] = '#X38N12B49'; Map['#X38N12B7A'] = '#X38N12B49'; Map['#X38N12B82'] = '#X38N12B49'; Map['#X38N12B8A'] = '#X38N12B49'; Map['#X38N12B9E'] = '#X38N12B49'; Map['#X38N12BA7'] = '#X38N12B49'; Map['#X38N12CAC'] = '#X38N12B49'; Map['#X38N12CBF'] = '#X38N12B49'; Map['#X38N12CC7'] = '#X38N12B49'; Map['#X38N12CCF'] = '#X38N12B49'; Map['#X38N12CD7'] = '#X38N12B49'; Map['#X38N12CEB'] = '#X38N12B49'; Map['#X38N12CF4'] = '#X38N12B49'; Map['#X38N12E13'] = '#X38N12DFA'; Map['#X38N12E21'] =

'#X38N12DFA'; Map['#X38N12E29'] = '#X38N12DFA'; Map['#X38N12E31'] = '#X38N12DFA'; Map['#X38N12E3B'] = '#X38N12DFA'; Map['#X38N12E49'] = '#X38N12DFA'; Map['#X38N12E51'] = '#X38N12DFA'; Map['#X38N12E59'] = '#X38N12DFA'; Map['#X38N12E8A'] = '#X38N12E6E'; Map['#X38N12EA4'] = '#X38N12E6E'; Map['#X38N12EAD'] = '#X38N12E6E'; Map['#X38N12F43'] = '#X38N12E6E'; Map['#X38N12F5A'] = '#X38N12E6E'; Map['#X38N12F63'] = '#X38N12E6E'; Map['#X38N12FD8'] = '#X38N12FC0'; Map['#X38N12FEB'] = '#X38N12FC0'; Map['#X38N12FF9'] = '#X38N12FC0'; Map['#X38N13001'] = '#X38N12FC0'; Map['#X38N13009'] = '#X38N12FC0'; Map['#X38N13011'] = '#X38N12FC0'; Map['#X38N13019'] = '#X38N12FC0'; Map['#X38N13076'] = '#X38N12FC0'; Map['#X38N1307F'] = '#X38N12FC0'; Map['#X38N13181'] = '#X38N13157'; Map['#X38N13189'] = '#X38N13157'; Map['#X38N13192'] = '#X38N13157'; Map['#X38N131A5'] = '#X38N13157'; Map['#X38N131CE'] = '#X38N131AF'; Map['#X38N131D6'] = '#X38N131AF'; Map['#X38N131DE'] = '#X38N131AF'; Map['#X38N13201'] = '#X38N131AF'; Map['#X38N13209'] = '#X38N131AF'; Map['#X38N13226'] = '#X38N131AF'; Map['#X38N1322E'] = '#X38N131AF'; Map['#X38N13236'] = '#X38N131AF'; Map['#X38N1324C'] = '#X38N131AF'; Map['#X38N1325F'] = '#X38N131AF'; Map['#X38N1326D'] = '#X38N131AF'; Map['#X38N13280'] = '#X38N131AF'; Map['#X38N132A4'] = '#X38N1328C'; Map['#X38N132AC'] = '#X38N1328C'; Map['#X38N132B4'] = '#X38N1328C'; Map['#X38N132CA'] = '#X38N1328C'; Map['#X38N132DD'] = '#X38N1328C'; Map['#X38N132FD'] = '#X38N132E7'; Map['#X38N13310'] = '#X38N132E7'; Map['#X38N1332B'] = '#X38N132E7'; Map['#X38N1333E'] = '#X38N132E7'; Map['#X38N13346'] = '#X38N132E7'; Map['#X38N1334E'] = '#X38N132E7'; Map['#X38N13356'] = '#X38N132E7'; Map['#X38N1335E'] = '#X38N132E7'; Map['#X38N13374'] = '#X38N132E7'; Map['#X38N13387'] = '#X38N132E7'; Map['#X38N1342F'] = '#X38N13392'; Map['#X38N13442'] = '#X38N13392'; Map['#X38N13459'] = '#X38N13447'; Map['#X38N13461'] = '#X38N13447'; Map['#X38N13469'] = '#X38N13447'; Map['#X38N13471'] = '#X38N13447'; Map['#X38N13479'] = '#X38N13447'; Map['#X38N13481'] = '#X38N13447'; Map['#X38N13489'] = '#X38N13447'; Map['#X38N13491'] = '#X38N13447'; Map['#X38N134BC'] = '#X38N1349C'; Map['#X38N134EA'] = '#X38N134C4'; Map['#X38N134FD'] = '#X38N134C4'; Map['#X38N1350A'] = '#X38N134C4'; Map['#X38N13512'] = '#X38N134C4'; Map['#X38N1351A'] = '#X38N134C4'; Map['#X38N13522'] = '#X38N134C4'; Map['#X38N13549'] = '#X38N13531'; Map['#X38N1355B'] = '#X38N13531'; Map['#X38N13563'] = '#X38N13531'; Map['#X38N13588'] = '#X38N13531'; Map['#X38N13596'] = '#X38N13531'; Map['#X38N135A1'] = '#X38N13531'; Map['#X38N135A9'] = '#X38N13531'; Map['#X38N135B1'] = '#X38N13531'; Map['#X38N135BB'] = '#X38N13531'; Map['#X38N135C3'] = '#X38N13531'; Map['#X38N135DE'] = '#X38N13531'; Map['#X38N135EB'] = '#X38N13531'; Map['#X38N135F3'] = '#X38N13531'; Map['#X38N1362F'] = '#X38N1361D'; Map['#X38N1363A'] = '#X38N1361D'; Map['#X38N13642'] = '#X38N1361D'; Map['#X38N1364A'] = '#X38N1361D'; Map['#X38N13654'] = '#X38N1361D'; Map['#X38N1365F'] = '#X38N1361D'; Map['#X38N13667'] = '#X38N1361D'; Map['#X38N1366F'] = '#X38N1361D'; Map['#X38N13677'] = '#X38N1361D'; Map['#X38N1367F'] = '#X38N1361D'; Map['#X38N136C3'] = '#X38N136B0'; Map['#X38N136F2'] = '#X38N136B0'; Map['#X38N13709'] = '#X38N136B0'; Map['#X38N13742'] = '#X38N136B0'; Map['#X38N13798'] = '#X38N13782'; Map['#X38N137A1'] = '#X38N13782'; AboutData = new Object(); AboutData['title'] = 'Dimensioning Iub interface'; AboutData['id'] = '0900d80580736fc8'; if( !

parent.navigation ){ document.writeln(' '); } </scrIPt>

Dimensioning Iub interfaceThe following sections deal with Iub dimensioning related topics.Iub VCC configuration

The Iub bandwidth is divided between:

http://127.0.0.1:43231/NED/NED?service=printview&library=a25003a0000b5230176p1&source=xdoc&item=docs/wran_dimensioning_wcdma_ran/g32.2=pln_dimensioning_iub/content0.htm&identifier=dn1550514791&encoding=xhtml_1_0&component=data&item=docs%2Fwran_dimensioning_wcdma_ran%2Fg32.2%3Dpln_dimensioning_iub%2Fcontent0.htm&source=xdoc

http://127.0.0.1:43231/NED/annot.jsp?mars=urn%3Amars%3Adn1550514791%3A1%3Aen%3Aglobal%3Aned_toc_1_0%3Adata%3Adata%3A*%3A11%3A161&library=a25003a0000b5230176p1

http://127.0.0.1:43231/NED/JavaScr%3Cspan%20style='background-color:#ffff00'%3EIP%3C/span%3Et:void%20about(%5C'About%5C');

signaling links carried on AAL5 (Common Node B Application Protocol (CNBAP), Dedicated Node B Application Protocol (DNBAP), Asynchronous Transfer Mode (ATM) Adaptation Layer 2 Signaling (AAL2Sig)

Operation and Maintenance (O&M) on AAL5 User plane (U-plane) Virtual Channel Connections (VCCs) carried on AAL2

User plane VCCs are further classified into different types, depending on the traffic they include. RAS05.1 provides “route selection” function which allows assigning HSDPA AAL2 connections to separate AAL2 VCs. With RAS06 “path selection” and HSUPA features further distinction of user VCCs is enabled. The possible user plane VCC types are: Shared, RT DCH, NRT DCH, DCH, HSDPA, HSUPA, HSPA.User plane VCCs also transport Common Control Channels (CCCHs), Dedicated Control Channels (DCCHs), and Dedicated Traffic Channels (DTCHs). Therefore, the capacity forIub is as follows:

Iub capacity = U-plane + CNBAP + DNBAP + AAL2sig + O&M

For O&M, 150 cps (~64 kbps) is recommended per BTS.

In addition to the user plane VCC distinction RAS06 path selection feature introduces finer distinction of VCCs on the basis of AAL2 path types. Three AAL2 Path types: stringent, stringent bi-level and tolerant can be configured according to the traffic class carried over user plane VCC. To ensure reliable QoS it is recommended to use stringent AAL2 path with CBR service category for RT DCH, DCH or SHARED VCC, stringent bi-level AAL2 path with UBR+ for NRT DCH and tolerant AAL2 path with UBR+ service category forHSPA.

THP can be used for interactive NRT traffic to distinguish delay-sensitive or non-sensitive traffic. Sensitive NRT traffic is then assigned to "stringent" AAL2 path type (and might use paths intended for RT traffic), whereas non-delay sensitive NRT traffic is assigned to “stringent bi-level” AAL2 paths. THP is not relevant in case of shared VCC and is not considered for Iub scheduling.

The maximum number of the AAL2 connections per VCC is 248. The CCCHs of one cell require four to six AAL2 connections, depending on the Secondary Common Control Physical Channel (S-CCPCH) usage. Each Adaptive Multirate (AMR)/packet-switched (PS)/circuit-switched (CS) call requires two AAL2 connections (DTCH + DCCH). For both HSDPA/PS R99 UL and HSDPA/HSUPA calls three AAL2 connections are needed (DCCH+HSDPA+HSUPA/PS R99 UL).

The maximum size of AAL2 Path (AAL2UP VCC) in RAS06 RNC is 114600 cps, which equals 48.6 Mbps.

The following Iub VCC configurations using two, three or four VCCs are available according to RAN759 Path Selection:1.Shared VCC for RTDCH, NRTDCH and HSDPA traffic. If the HSUPA is enabled it requires other

dedicated VCC: 1 or 2 VCCs.2.Dedicated VCCs for DCH (for both RTDCH and NRTDCH), for HSDPA and for HSUPA: 3 VCCs3.Dedicated VCCs for DCH (carrying both RTDCH and NRTDCH traffic) and for HSPA (for both

HSDPA and HSUPA traffic): 2 VCCs4.Dedicated VCCs for RTDCH and for NRTDCH, common VCC for HSPA (for both HSDPA and

HSUPA): 3VCCs5.Dedicated VCCs for RTDCH and for NRTDCH, other dedicated VCCs for HSDPA and for

HSUPA: 4 VCCsOne or more VCCs of each type can be configured on a route between BTS and RNC. VCC for real-time and non real-time user traffic has to be always configured on a route (either RT and NRT DCH VCCs or DCH VCC) whereas the user plane VCCs for HSDPA and HSUPA traffic are necessary only if required.The Iub configuration princIPles for route selection configuration are shown in Figure BTS AAL2 multIPlexing (VCC configurations 1-2). In this case DCH and HSDPA traffic has dedicated VCCs to carry user traffic. As an alternative solution it is also possible that the HSDPA and Dedicated Channel (DCH) traffic share the same VCC. For configurations when HSUPA traffic is enabled it is recommended to use a dedicated VCC. If Iub interface

is not bandwidth restricted in both downlink and uplink (for example, when using symmetric VDSL line) the HSDPA and HSUPA can also share the same VCC, but that requires the Path Selection feature (VCC configurations 3-5).

Note that from RAS05.1 onwards, the AXC ATM layer configuration management for BTS function makes the BTS internal VCC configuration between the Wideband Application Manager (WAM) and the ATM Cross-Connect Unit (AXU) automatic. Therefore, you do not see WAM-AXU commissioning at all. Only Iub VCCs need to be commissioned.

Figure 82: BTS AAL2 multIPlexing

VCC BTS with basic AAL2 multIPlexing

BTS with BTS AAL2 multIPlexing

Flexi WCDMA BTS

ATM adaptation layer

U-plane One per WAM (DCH) *

One per BTS (HSDPA) **

One per BTS (DCH) *

One per BTS (HSDPA)

One per BTS (DCH) *

One per BTS (HSDPA)

AAL2

CNBAP One per BTS One per BTS One per BTS

AAL5

DNBAP One per WAM One per WAM One per BTS

AAL5

AAL2sig

One per WAM One per BTS One per BTS

AAL5

O&M One per BTS One per BTS One per BTS

AAL5

Table 78: Number of VCCs with route selection configuration

* One VCC can contain up to 248 AAL2 connections. In cases where the BTS capacity exceeds 248 AAL2 connections, more user plane VCCs per WAM or per BTS can be required.** Used with the RAS05.1 Route Selection function. Alternatively, multIPle VCCs can be configured for HSDPA.

With the path selection feature, using native ATM transport or hybrid transport over PWE the basic princIPles for separating the control plane and user plane connections are similar to those given earlier in this chapter. The Iub configuration examples are given in Figure Iub VCC configuration with path selection and native ATM transport and Figure Iub VCC configuration with path selection and hybrid transport. The use of UBR+ service class for non delay-sensitive user plane VCCs is also illustrated in the figure. For

both HSPA and NRT DCH traffic UBR+ service category is recommended and CBR ATM service for RT DCH traffic class.

The given below configurations are for UltraSite WCDMA BTS with AAL2 multIPlexing. If Flexi WCDMA BTS is used instead, the same VCC configuration is used between RNC and BTS, with the exception that one DNBAP VCC per BTS is enough.

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

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


BTS with AAL2 multIPlexing

Flexi WCDMA BTS


U-plane

RT-DCH, NRT-DCH and HSDPA VCC

Not possible to divide DCH traffic to RT-DCH and NRT- DCH VCCs

1 - 7 per BTS 1 - 16 per BTS

AAL2

U-plane HSUPA One per BTS One per BTS At least one per BTS

AAL2

U-plane DCH 1-2 per WAM *

U-plane DCH+HSPA

1-2 per WAM

Examples of two-WAM configurations:

WAM1: DCH VCC

WAM2: DCH VCC + HSPA VCC

WAM1: DCH VCC + HSDPA VCC

WAM2: DCH VCC+ HSUPA VCC

CNBAP One per BTS One per BTS One per BTS

AAL5


BTS with AAL2 multIPlexing

Flexi WCDMA BTS


DNBAP One per WAM One per WAM One per BTS

AAL5

AAL2sig One per WAM One per BTS One per BTS

AAL5

O&M One per BTS One per BTS One per BTS

AAL5

Table 79: Number of VCC with path selection configuration and HSUPA

* With basic AAL2 multIPlexing one of the VCCs per WAM must be capable of carrying RT traffic.The RAN759 Path Selection feature, originally introduced in RAS06, was developed further in RU10 release. In RU10, the AAL2UPUsage (AAL2 User Plane VCC Usage) and AAL2 Path type combination are used to define the type of the traffic carried on the given AAL2 VCC (AAL2 Path). The AAL2UPUsage specifies the air interface channel type (DCH/HSxPA) carried over the AAL2 VCC while the AAL2 Path Type defines the transport priority.

AAL2UPUsage (RU10/RN4.0)

AAL2PT combinations

No opt. feature

Route selection*

Path selection RAS06 SW

Path selection RU10 SW

DCH & HSDPA (former Shared)

None x

DCH None x

DCH & HSDPA None x

HSDPA None x

DCH Stringent x x


AAL2PT combinations

No opt. feature

Route selection*



DCH Stringent & Stringent Bi-level

x x

DCH Stringent Bi-level x x

DCH & HSPA Stringent x

DCH & HSPA Stringent & Stringent Bi-level

x

DCH & HSPA Stringent Bi-level x

DCH & HSDPA Stringent & Stringent Bi-level & Tolerant

x x

HSPA Stringent x

HSPA Stringent & Stringent Bi-level

x

HSPA Stringent Bi-level x

HSPA Stringent Bi-level & Tolerant

x

HSPA Stringent & Stringent Bi-level & Tolerant

x


AAL2PT combinations

No opt. feature

Route selection*



HSPA Tolerant x x

HSDPA Stringent & Stringent bi-level

x x

HSDPA Stringent & Stringent bi-level & Tolerant

x x

HSDPA Tolerant x x

HSUPA** Stringent & Stringent bi-level

x x

HSUPA** Stringent & Stringent bi-level & Tolerant

x x

HSUPA** Tolerant x x

Table 80: RU10 Traffic separation using different VCC types and AAL2 PT combinations

* Note that RAN1020 Route selection (RAN05.1) is assumed not to be in use anymore in RU20.** HSUPA with any AAL2 PT combination is applicable if HSUPA is enabled.

The AAL2 VCC selection mechanism for admitted user calls in RU10 takes into account the air interface channel type and the AAL2 path type combinations configured for given AAL2 user plane VCC. For example, if the channel type is set to DCH, then VCC will be taken as a candidate to carry the transport bearers for the common transport channels, R99 DCHs, and SRBs (DCCH on DCH). Also for HSPA UP VCC Stringent & Stringent bi-level & Tolerant all HSPA traffic is routed to the HSPA VCC.

According to new RU10 naming, the RAS06 DCH/RT/NRT traffic VCCs need to be replaced by DCH Stringent & Bi-level Stringent/DCH Stringent/DCH Bi-level Stringent AAL2 UP VCCs accordingly.

Each path type has a different AAL2 admission control (CAC) algorithm in DL and UL. In RAS06 there was only one path type value for a VCC which defined the used AAL2 CAC algorithm. In RU10, configured path type combination might contain several various AAL2 PT values. This means that the used algorithm is call specific and depends on the path type associated to the traffic type.

The following table presents default air channel type and AAL2 path types needed for a transport bearers.

Connection type Channel type in VCC selection

AAL2 path type in VCC Selection

CTrCH (PCH, FACH, RACH) DCH Stringent

SRB (DCCH on DCH) DCH Stringent

SRB on HSPA HSDPA/HSUPA/HSPA Stringent

R99 DCH AMR DCH Stringent

R99 DCH CS data DCH Stringent

Streaming DCH PS data DCH Stringent

NRT DCH PS data (Interactive, Background)

DCH Stringent bi-level

NRT HSDPA (Interactive, Background)

HSDPA / HSPA Tolerant

NRT HSUPA (Interactive, Background)

HSUPA / HSPA Tolerant

Conversational HSDPA HSDPA / HSPA Stringent

Streaming HSDPA HSDPA / HSPA Stringent bi-level

Conversational HSUPA HSUPA / HSPA Stringent

Connection type Channel type in VCC selection

AAL2 path type in VCC Selection

Streaming HSUPA HSUPA / HSPA Stringent bi-level

Table 81: VCC labels for VCC selection

Introduced in RU10, RAN1253 Iub Transport QoS feature allows aligning QoS transport strategy with radio layer classification based on UMTS traffic classes, THP and ARP priorities. Thus, transport bearers of various connection types are freely mapped to AAL2 priorities (AAL2 path type and AAL2 priority queue) at ATM transport. Same AAL2 priority mappings are used in uplink (FlexiBTS) and downlink (new NPS1 HW) direction. The default AAL2 Path Types should be applied for the VCC selection if RAN1253 Iub Transport QoS feature is not configured for the given BTS in the RNC configuration.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. The dimensioning of HSDPA/HSUPA VCC is based on the data rates to be supported, see HSPA and Iub dimensioning.VCC dimensioning is different in the case of UBR+ VCC. The following rules apply for UBR+ VCCs:

The CAC is done against the UBR+ VCC MDCR value. The VCC bundle is an exception, discussed later.

The traffic is scheduled in the RNC to the VCC with UBR+ PCR value at maximum. RNC shapes the user plane VCCs according to PCR value, except for RNC2600 platform where shaping is done with VCC bundle only. Also with the new NPS1 HW (RNC2600), when VCC bundle is in use, CBR VP must be set unshaped. In the BTS there is no traffic shaping to UBR+ PCR, except UltraSite BTS for user plane VCCs with AAL2 multIPlexing disabled and for the control and O&M VCCs.

The MDCR value is the amount of capacity reserved for a specific connection by ATM CAC.

The bandwidth sharing between UBR+ connections using the same ATM link can be tuned with the weight and MDCR values.

Downlink VCC bundle

The VCC bundle functionality in 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 of above or both features are enabled. The VCC bundle allocates downlink capacity dynamically between different VCC connections sharing the same Iub link and belonging to the VCC bundle. The VCC bundle PCR should be configured to be equal to the minimum link size of the route from the RNC to the BTS to avoid traffic loss between RNC and BTS. Maximum two VCC bundles can be configured. The main use of the second bundle is the hybrid BTS backhaul feature.In case of VCC bundle, the UBR+ VCC CAC in RNC (downlink) is done against the dynamically adjusted value, based on the other traffic volume sharing the same VCC bundle. Note that RNC shapes UBR+ VCs according to the PCR value or to lower value if in VC bundle. Thus if UBR+ VCC PCR is equal to bundle PCR the VCC can use all the capacity if there is no other traffic. In congestion situation the maximum available 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 details, see the feature descrIPtion for RAN1100: Dynamic Scheduling for NRT DCH with Path Selection.

For the exemplary scenario where both NRT DCH and HSDPA VCCs are included in the same VCC bundle the following ATM traffic parameters of the VCC bundle can be configured:

VCC bundle PCR=5.0 Mbps RT DCH: VCC PCR (CBR) = 2 Mbps NRT DCH: VCC MDCR (UBR+) =1 Mbps, and VCC PCR (UBR+) =5 Mbps HSDPA: VCC MDCR (UBR+) =2 Mbps, and VCC PCR (UBR+) =5 Mbps VCCBundleEBS = 50%; The share given in this parameter is for NRT DCH VCCs and

the rest for NRT HSDPA VCCs in a bundle 100%-NRT DCH_value)

In this case there is no unallocated bandwidth in the bundle, the remaining free capacity in the bundle, at the given time stamp, is shared among NRT DCH and HSDPA traffic according to the EBS parameter. Simultaneously, the MDCR parameter assures the minimum bandwidth for UBR+ VCCs.Uplink VCC bundle

There is a capacity bundling functionality available also for uplink ATM resources. The usage of the uplink VCC bundle requires that the feature RAN1095: UBR+ for Iub User Planeis activated in the BTS. In case the VCC bundle is active, the BTS handles the available uplink capacity for NRT DCH and RT DCH VCC as a bundle in AAL2 CAC operations. If there are some MDCR reservations for any of the UBR+ VCCs, those are subtracted from the total available link capacity. This means that MDCR parameter can be used to reserve some capacity for HSUPA traffic in uplink. Therefore, the MDCR of UBR+ VCC for NRT DCH traffic should be set to 0 to not reserve additional capacity, and the UBR share parameter to a much greater value than for HSPA/HSUPA VCCs (for example, 1000:50).Uplink AAL2 CAC overbooking is possible with RAN1096: Transport Bearer Tuning, similarly as in downlink, but too heavy overbooking might lead to traffic loss, because there is no flow control mechanism in 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 ATM-based Iubdimensioning based on the call mix to be supported.

Calculate according to rules given in ATM-based Iubdimensioning 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/HSPAtraffic in downlink. ** Calculate according to rules given inATM-based Iub dimensioning

0, if uplink VCC bundle is active. If no VCC bundle is used, calculate the value according to rules given in ATM-basedIub dimensioning.

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

Equal to VCC bundle PCR *** Equal to maximum capacity for user according to uplink bottleneck.

Parameter (ATM EP, AAL2 PT)

RNC egress / ingress BTS egress / ingress

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

Capacity guaranteed for HSPA traffic in downlink. ** Calculate according to rules given in ATM-based Iubdimensioning

Capacity that is guaranteed for HSUPA traffic in uplink. ** Calculate according to the rules given in ATM-based Iubdimensioning

UBR+ UBRShare 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 NRTHSPA.

VCC bundle PCR The total available Iub user plane capacity in downlink (assuming all user plane VCCs are located in the same bundle).

For two VCC bundles calculate capacity separately according to the traffic types assigned to the different VCC bundles,

Automatically defined by the BTS if VCC bundle is enabled in uplink.

VCCBundleEBS

(Excess bandwidth Share)

With this parameter the NRT DCH can be favored over NRT HSDPA (located in the same VCC bundle) in a congestion situation, or vice versa.

RT traffic type gets always guaranteed bandwidth.

Not available

Table 82: Parameter value selection with path selection and HSUPA

* In case of VCC with AAL2 PT combinations (for example, Stringent & Stringent Bi-level, Stringent Bi-level & Tolerant or Stringent & Stringent Bi-level & Tolerant) the requiredbandwidth has to be calculated separately according to the rules given in ATM-based Iub dimensioning and the total VCC bandwidth is the sum of calculated traffic.** The MDCR value is used to reserve certain capacity from ATM layer CAC, similarly as CBR VCC PCR. The MDCR values for HSPA VCCs should be selected based on the estimated average throughput during busy hour plus some safety margin to allow bursts. The HSDPA uplink traffic volume is expected to be low if compared to downlink, because there are only the HS-DSCH capacity allocations transported. The same applies for HSUPA and downlink traffic.

If the MDCR value is set too low, the ATM layer congestion may take place in hub 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, burstiness of the traffic among other things, and should be verified through network monitoring.

*** Peak capacity can be used only if there is no other traffic present in the same VCC bundle, that is, the HSDPA traffic uses peak rate if no RT or NRT traffic is present. If there

is other traffic, the VCC bundle functionality adjusts dynamically the peak rates allowed in downlink for different traffic types.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 Figure VPC configuration with CBR VCC based user and control plane.

Figure 85: VPC configuration with CBR VCC based user and control plane

From RAS05.1 onwards it is also possible to have two VPCs for user plane per BTS. In that case the R99 traffic is transported over one VPC and HSDPA traffic over another VPC (Route Selection feature).In RAS06, the introduction of UBR+ VCC for user plane requires some changes in the configuration. It is possible to have different priority traffic dedicated VPCs between the RNC and the BTS or alternatively to group, for example, all HSDPA VCCs to the same VPC and separate those in the hub point to different BTS sites. These alternatives are described in Figure VPC layer configuration option for RU10 path selection configuration with CBR/UBR+ VCC based user plane (UBR O&M), where the hub switch is used also to change the service category of VP connections. In addition the route/path selection does not have any restriction how different VCCs are configured to VPCs.

In RU10, it is possible to configure UBR+ VPCs. UBR+ VCCs can be configured in both UBR VPs and CBR VPs. In the case where any VP contains both CBR VCCs and UBR+ VCCs, it must be set up to CBR VP, that is, CBR VCC are not allowed within UBR VPs. There is no UBR+ shaping applied for any BTS and RNC hardware variants.

Figure 86: VPC layer configuration option for RU10 path selection configuration with CBR/UBR+ VCC based user plane (UBR O&M)

The guidelines for defining the parameter values for VP layer are given in Table Parameter value selection for VP layer.

Parameter Downlink Uplink

CBR VPC PCR

Sum of the VCC PCR values included in the VPC

Sum of the VCC PCR values included in the VPC

UBR+ VPC MDCR

Sum of the VCC MDCR values included in the VPC

Sum of the VCC MDCR values included in the VPC

UBR+ VPC PCR

Equal to ATM link capacity Equal to ATM link capacity

Table 83: Parameter value selection for VP layer

ATM-based Iub dimensioning

User traffic demand modeling

For detailed information regarding traffic modeling see Traffic modeling. The basic traffic model related parameter set used in interface dimensioning process is given below. It is

focused on subscriber oriented values, basing on which all the input data to the dimensioning process is evaluated.

Figure 87: Traffic parameter modeling

Parameter / [unit] DescrIPtion / Formula

PeakRate Max. data rate of the DTCH bearer (RAB)

BHCA

[#]

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

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

DCHduration

[s]

Sum of all DCH durations of a RAB live = ∑ all DCHdurations of RABlive

DCHactivity

[abs] or [%]

Average activity over all DCH sessions of a RAB live

= Avarage of MeanRateDCHsession’s / PeakRate

or

= MeanRateBH / ( PeakRate * DCHduration * BHCA / 3600s)

or

= MeanRateBH / (PeakRate * ErlangDCHsession’s)

ErlangDCHsession’s

[#]

Basic traffic demands for CS traffic; in case of PS and HS traffic it can be calculate as follows:

= DCHduration * BHCA / 3600s

or

= MeanRateBH / (PeakRate * DCHactivity)

MeanRateBH

[bps]

Basic traffic demands for PS and HS traffic; in case of CS traffic it can be calculate as follows:

= DCHactivity * PeakRate * DCHduration * BHCA / 3600s

Parameter / [unit] DescrIPtion / Formula

or

= DCHactivity * PeakRate * ErlangDCHsession’s

ParallelConnectionsDCH

[#]

Input value for CAC; in case of PS nonRT dimensioning as best effort without QoS it can be calculate as follows:

= round-up [ ErlangDCHsession’s ]

or

= round-up [ DCHduration * BHCA / 3600s ]

or

= round-up [ meanRateBH / (DCHactivity * PeakRate) ]

Table 84: 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

BHCA DCHduration ErlangDCHsession’s

must be the same for UL and DL.MeanRateBH and DCHactivity must be separately calculated for UL and DL.

Amount of traffic demand per busy hour must be provided for a specific BTS site. If amount of traffic demand is given per subscriber, additional assumption for the number of subscribers per site is required.

Additionally, assumption on the soft handover overhead is needed. The default value for inter-BTS soft handover factor is 30%.

Softer handover does not influence Iub U-plane and is not relevant for RNC static capacity. From interface point of view, it loads only Iu and Iur C-plane.Dedicated Control Channels (DCCH)

SRBs over DCH

For signaling, the SRB with 13.6kbps (ALC set 3 with lowest activity factor of 3 options per SRB type) is used during dimensioning of the Iub interface via CAC (see Iubdimensioning methods for user plane) and estimation of additional mean user traffic.DCCH Mean Traffic per DCH session

= Peak Rate * Activity * Overhead = 13.6kbps * 7.5% * 1.791 = 1.82682 kbps

Note that the considered connection rate on Iub is not updated when changed from 13.6kbps towards 3.4kbps, but current rate is used in case of incoming handover.SRBs over HSPA

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

RAN1689 CS voice over HSPA (RU20 On Top) RAN1201 Fractional DPCH RAN1638 Flexible RLC RAN981 HSUPA 5.8 and RAN1470 HSUPA 2ms TTI.

Because of a different overhead introduced by SRBs over HSPA bearers, a separate set of ALC and IPTD CAC parameters is defined. Therefore, the CAC algorithm is fed with a modified input comparing to DCH mapped SRBs.E-DCH/HS-DSCH SRB connection requires 2 CIDs / UDP ports instead of one consumed by DCH mapped control channels.Common control channels (CCCH)

The following assumptions are taken during dimensioning of the Iub interface via Call Admission Control algorithm. Because of the fact that CCCH set is established for each radio cell, depending on the number of cells different number of common channels (RACH, FACHs and PCH) is used as an input to the CAC functionality. The same assumption on Activity is used to estimate the CCCH part of mean user traffic.Optional RU20 feature RAN1202 24 kbps Paging Channel brings in a possibility to enhance the paging channel throughput to 24 kbps, reducing congestion probability under BTSs serving high number of subscribers.

Type of CCCH DescrIPtion Max. Data rate on FP level

Default Activity

FACH-C Forward Access Channel for control plane

DL: 38400 bps 10%

FACH-U Forward Access Channel for user plane

DL: 40800 bps 10%

RACH Random Access Channel in UL

UL: 20800 bps 10%

PCH 8 kbps (<RU20)

Paging Channel 8 kbps DL: 27200 bps 10%

PCH 24 kbps (RU20)

Paging Channel 24 kbps (optional feature)

DL: 36000 bps 10%

Table 85: Common Control Channel reservation

Connection Admission Control for R99 traffic

The AAL2 Connection Admission Control (CAC) in RNC evaluates whether there is enough bandwidth in downlink direction for every new requested bearer. The AAL2 CAC Iubcapacity requirement depends on, for example, the service mix, average and peak service data rate, Transmission Time Interval (TTI), allowed delays, and cell losses.RAS06 feature Transport Bearer Tuning (RAN1096) affects Iub dimensioning. For instance, instead of 100% activity for PS DCHs, lower activity factors (AF) may be applied. Transport Bearer Tuning enables optimization of resources on Iub or allows more

services to be admitted simultaneously compared to previous releases. The feature influences Iubdimensioning in a way that ‘real’ activity of the bearers, estimated on the basis of input Traffic Model are provided to the CAC algorithm.

Further optimization of AF values for different bearer types should be done carefully based on testing or measurement data from the network to avoid congestion and decreased service quality.

RAS06 feature RAN1100: Dynamic Scheduling for NRT DCH with Path Selection provides a back-pressure mechanism to slow down user data rates in a controlled way in the congestion situation. It is recommended to use this optional feature together with Transport Bearer Tuning.

The default values for the AF, when feature Dynamic Scheduling for NRT DCH with Path Selection is enabled, are as follows:

NRT DCH bearers' AF is set to 0.75.

Further optimization is possible by performing AF tuning for each NRT DCH bearer type.

The following limitations apply to AF factor selection of different bearer types: For NRT DCH bearers the AF value cannot be set below 0.1. For AMR calls the AF value cannot be set below 0.6.

Note that the feature Dynamic Scheduling for NRT DCH with Path Selection does not provide optimal throughput if the capacity available for NRT DCH traffic is small (< 1000 cps).Connection Admission Control and traffic separation

In case of Path Selection feature, AAL2 CAC selection bases on AAL2 Path Type (chosen for each VCC) and with the introduction of RAN1253: Iub Transport QoS feature, different AAL2 CAC algorithms can be used for the same AAL2 path.Iub dimensioning methods for user plane

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 as provided in the dimensioning tool RCP.Option 1

RT services dimensioned using Multi-Dimensional-Erlang approach (related to CS and PS real-time RABs, includes CS over HSPA and HSPA Streaming services).Multi-Dimensional-Erlang is an extended Erlang B algorithm which allows to calculate the probability of call loss on a group of circuits in multi-dimensional environment (more services sharing the same transport resource). For details, refer to teletraffic engineering theory.

PS NRT dimensioned with QoS leveling by means of M/G/R-PS model.M/G/R-PS is a queuing model used in dimensioning of Internet Traffic residing on top of TCP/IP protocol suite. For details, refer to teletraffic engineering theory.

Dimensioning independent of the bearer’s activity (TBT) For CAC 100% AFs are accounted

HSPA NRT traffic is dimensioned separately. Option seen as preferred - especially helpful in the cases where no detailed

information on bearer’s activity is available.

Option 2

Based on direct definition of Parallel Connections without QoS consideration during dimensioning

Although the lack of explicit QoS targets is a shortcoming it ensures the availability of sufficient resources in an intuitive manner throughout all elements for e2e connections.

HSPA NRT traffic is dimensioned separately. Recommended for the cases where direct Parallel Connection is preferred as input

The option should be chosen depending on the QoS requirements and availability of the input parameters.Note that the methods described here should be treated as proposals. Operators can apply their own calculation process if required.Option 1: MD-Erlang for real time; QoS by M/G/R-PS for best effort PS R99 and HSPA NBR

Figure 88: Iub dimensioning, option 1

Real-time traffic

The following steps are needed in the calculation.1.Calculate MD-Erlang bandwidth.

Multi-Dimensioning-Erlang approach is used for real time services (using CS, PS real-time and HSPA Streaming RABs). The Gross Peak Rate is defined on ATM level including AAL2/ATM overhead and accompanying DCCH. Offered Traffic [Erl] should also include SHO factor, as soon as HSDPA is not concerned.bandwidth MD-Erlang = MD-Erlang [ErlangDCH; GrossPeakRate; Blocking-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 the outcome is not an integer, so it has to be rounded up to the next greater integer.ParallelConnectionsDCH = round-up [Gross meanRateBHinclQoS / Gross PeakRate]

3.Check against MDE bandwidth.Afterwards, the number of connections for the bearer with the lowest rate is decreased as long as such a decrease does not result into a total rate below the one determined by MDE before.bandwidth = ∑ [ParallelConnectionsDCH * PeakRate] =< bandwidth via MD-ErlangNote that it can happen that all connections of the lowest bearer rate are eliminated (so connection number is 0), then the “new” lowest (non-zero connection count) bearer is used for further iterations. (This rule is needed because of high rounding error for bearers with high peak rate).

Afterwards, the set of parallel connections is used to feed CAC (in combination with the outcome of NRT dimensioning). From CAC result point of view this is the worst case concerning requested bandwidth.Non real-time traffic

In NRT dimensioning M/G/R-PS with combination for several bearers as a mix is used (considering a delay factor). In case of multIPle bearers, M/G/R-PS provides a total demand for each bearer class. Each of those demands has to be fulfilled, therefore the CAC is fed with several (potential) sets of parallel bearers. Afterwards, the maximum demand is used.Note that M/G/R-PS assumes a full utilization of bearers whenever data is transferred, thus 100% activity has to be used for CAC.

Way of calculation and formulas:1.Calculate a sum of mean rate over all NRT services.

Total Gross mean rate = ∑ [Gross mean rate(service)]2.Apply MGR-PS with this sum together with peak rate, file size, delay of each service.

bandwidth MGR-PS (Service) = M/G/R-PS [Total Gross mean rate; Gross peak rate (service); Gross file size (service); delay (service)]

3.Calculate parallel connections for each service.ParallelConnectionsDCH NRT (Service)= round-up [bandwidth MGR-PS (Service) / Gross peak rate(Service)]

4.Repeat steps 1-3 for all NRT services.5.Call CAC including Real time part for each NRT services case separately.

CAC(service)= CAC[ real-time part; CCCH; ParallelConnectionsDCH NRT (Service) ; CACvalues(service) ]where

CACvalues(service) = CACvalues(related RAB)= vector [ max size(RAB); max rate(RAB), average size(RAB), average rate(RAB) ]

6.Take the maximum over all CAC result case as a final result (the worst case).Total BW result = max [ CAC (service) ]

TotalCACresultDemand is used to calculate Iub bandwidth demand together with HSPA bandwidth demand, as described in calculation of total Iub bandwidth demand.For exemplary Parallel Connections calculation in Option 1, see Dimensioning examples.Option 2: CAC directly via "parallel connections"

Figure 89: Iub dimensioning, option 2

This option allows to choose CAC input independent of the dimensioning rules.However, it is recommended to check if the number of Parallel Connections defined in the traffic model is compliant with the Traffic Demand requirements (Erlangs).

ParallelConnectionsDCH >= round-up [ ErlangDCHsessions (at BTS) ]

Meaning: used number of ParallelConnectionsDCH must be greater or equal then up-rounded Erlang value from Traffic model (see User traffic demand modeling) expected at a specific BTS.HSPA and Iub 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 HSDPA protocol stackOptionally, on top of the mean rate based option, some percentage QoS overhead can be added to account for instantaneous I/B HSPA bursts above the average value. Typical QoS_Factor values are around 20%.

HSDPA and protocol overheads

HSDPA protocol stack is presented in Figure HSDPA protocol stack.

Figure 90: HSDPA protocol stack

The following overheads are present below the PDCP level: RLC (RU10): SDU size fixed to 320 or 640 bits payload + 16 bits header = 336 or

656 bits RLC (RU20: Flexible RLC): flexible SDU size up to 1400 bytes + 16 bits header MAC-d: No header MAC-hs (RU10): 24 bits header MAC-ehs (RU20, Flexible RLC): 21 bits header FP: 88 bits header, relative FP overhead varies depending on the number and size

of carried RLC PDUs

ATM User Data Rates on Iub generated by different UE Categories are presented in tables HSDPA protocol overheads (RU10, 10% BLER) and HSDPA protocol overheads (RU20, Flexible RLC, 10% BLER). Target BLER of 10% has been assumed.

Air interface L1 rate [Mbps]

RLC SDU peak rate [Mbps]

FP rate (Iub) [Mbps]

ATM User Data Rate (Iub) [Mbps]

1.8 1.46 1.54 1.86

3.6 3.06 3.24 3.90

7.2 6.11 6.47 7.78

10.1 8.73 9.24 11.11

14.0 12.22 12.63 15.20

Table 86: HSDPA protocol overheads (RU10, 10% BLER)

Air interface L1 rate [Mbps]

RLC SDU peak rate [Mbps]

FP rate (Iub) [Mbps]

ATM User Data Rate (Iub) [Mbps]

7.2 6.52 6.59 7.93

10.1 9.17 9.26 11.14

14.4 12.66 12.78 15.38

21.1 (64QAM) 19.11 19.29 23.21

28.0 (MIMO 16QAM) 25.31 25.56 30.74

42.2 (DC-HSDPA/64QAM)

38.22 38.58 46.41

Table 87: HSDPA protocol overheads (RU20, Flexible RLC, 10% BLER)

Note that to calculate total Iub capacity required to serve the HSDPA Data Rates listed in the tables, additional assumptions on Iub signaling, Control Channels and O&M bandwidthdemands are needed.Average RLC – ATM overhead for HSDPA User Plane varies in a range of 25 – 35 % in RU10 case and 20 – 30% in RU20 (Flexible RLC) case, depending on the actual rate utilized by the application layer.HSUPA and protocol overheads

HSUPA protocol stack is presented in Figure HSUPA protocol stack.

Figure 91: HSUPA protocol stack

The following overheads are present below the PDCP layer: RLC: PDU size 320 bits payload + 16 bits header = 336 bits, overhead is 16/320 =

5% Dedicated Medium Access Control (MAC-d): No header MAC-es payload 5040 bit (assuming 15 MAC-d PDUs) + 6 bits header = 5046,

overhead is 6/5040 = 0.1% Frame protocol: HS-DSCH data frame’s FP-header and tail produces nine bytes

overhead for each MAC-es data unit. With the assumption 15 MAC-d PDUs per HS-DSCH frame the FP layer overhead is 1.4%.

The total Iub overhead requirements for HSUPA are 6% overhead from RLC rate to FP rate, or 33-27% overhead from RLC rate to ATM rate. The variation of the overhead percentage depends on the number of MAC-d PDUs included in single FP frame.n case of HSUPA, additional 30% overhead needs to be added on top of the user plane traffic per cell/BTS to support HSUPA soft handover traffic.HSPA QoS streaming

RU10 allows serving streaming QoS class RAB on HSPA. In previous releases such streaming traffic was only possible using R99 DCH. New feature enables streaming traffic class RAB to be mapped on DCH/HS-DSCH and E-DCH/HS-DSCH transport channels. Streaming RABs conveyed on HSPA are thus prioritized internally by RNC and by BTS HSUPA and HSDPA packet schedulers, which take Scheduling Priority Indicator (SPI) value into account. Different weights are defined per priority queues on the basis of SPI class and within a class of common SPI flows proportional fair scheduler is used.Streaming traffic is usually characterized by sensitive time relations (delay variation) between information entities (for example, PDUs) of a stream and is not very sensitive in terms of requirements on low transfer delay. For RT HSPA traffic admission control is supported within the transport network basing on Guaranteed Bit Rate (GBR). In addition the feature enables in RNC configurable Nominal Bit Rate (NBR) for NRT traffic classes, which can be used as targeted minimum bit rate, for example, based on subscrIPtion. In the scheduler, NBR has higher priority than best effort traffic but 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 the new service or subscriber connection CAC is performed using downlink and uplink GBR or NBR requirements respectively over both IP and ATM transport networks. In addition QoS Aware HSPA Scheduling feature includes prioritization in Iub frame protocol (FP) layer and adds QoS awareness to HSUPA Congestion Control and HSDPA Congestion Control features. For more information, see features: RAN1004: Streaming QoS for HSPA and RAN1262: QoS Aware HSPA Scheduling.

Dimensioning method for streaming traffic on HSPA over Iub interface is based on procedure for real time CS services described in section Iub dimensioning methods for user plane(real-time traffic). Likewise for CS services QoS parameters for HSPA streaming traffic class are defined on call level as a call-blocking rate (for example, Blocking-percentage) per service class i. If not specified by the operator, call blocking probability for RT HSPA services are same as for R99 streaming services. Traffic intensity ErlangRT_HSPA needs to be evaluated on the basis of the input traffic model. Appropriate dimensioning for streaming services requires the definition of the

corresponding application type to be used by the end users. Therefore, Gross EffectiveBW value needs to be calculated on the basis of effective codec bit rate for dedicated streaming service and corresponding transport overhead.

Note that effective codec bit rate (for example, for VoIP services) might change depending whether the header compression is used or not.

bandwidth MD-Erlang = MD-Erlang [ ErlangRT_HSPA; Gross EffectiveBW; Blocking-percentage ]

For the exemplary VoIP service (with AMR codec 12.2): Effective peak rate is 29.4kbit/s (calculated as a sum of the VoIP bit-rate 12.2kbit/s

and the header overhead 17.2kbit/s); no RTP/UDP/IP header compression. Activity factor (AF) = 60% HSDPA overhead (RLC/FP/AAL2/ATM OH): ~60%, therefore:

Gross EffectiveBW = Effective BW * AF*HSDPA_OH= 29,4kbit/s*0,6*1,6=28,2kbit/s

For scenarios where RT CS traffic and RT HSPA traffic share the same transport resources, calculation of the required bandwidth is done with Multidimensional Erlang method for all RT services together.With the assumptions of different transport resources for R99 RT and for RT HSPA traffic the MDE algorithm has to be applied separately for streaming QoS services mapped onHSPA and separately for RT CS services. The example is the usage of hybrid transport when different transport media are used for transmission and thus transport resources are not commonly shared by all RT services. Similarly when single transmission media is used for transmission (for example, ATM network), but RT HSPA traffic and CS traffic are VCC separated. In this case estimation of the number of simultaneous connection has to be done separately for RT CS and RT HSPA services.calculation of total Iub bandwidth demand

Based on the results achieved using one of the options described above and HSDPA demand, the total Iub bandwidth demand is estimated as shown in Figure Iub bandwidthdemand.

Figure 92: Iub bandwidth demand

Proposed evaluation, in addition to calculated bandwidth demands (Term 1), takes into account possible requirement related to maximum achievable HSDPA peak rate per given BTS.Note that there might be a different requirements regarding Iub bandwidth demand calculation (for example, HSDPA peak throughput per cell might be demanded, instead of “per BTS”).

RU20 HSPA+ features increase HSPA Peak Rate Demand per BTS, according to new UE Categories supported.IP-based Iub dimensioning

IP-based Iub dimensioning allows determining the following capacity-related components, as presented in Figure IP-based Iub dimensioning components.

Figure 93: IP-based Iub dimensioning components

IP_Route_Commited_bandwidth: CAC-guaranteed IP bandwidth per logical Iub. This parameter is configured in RNC and BTS to set the available bandwidth for high priority connections.

Shared_BE_IP_Allocation: non CAC-guaranteed IP bandwidth per logical Iub for low-priority BE traffic

IP_Route_Bandwitdh: Total IP bandwidth per Iub. Against this parameter a traffic shaping is done in order not to exceed the configured IP link capacity on Iub.

Iub_Ethernet_Capacity: Total bandwidth per Iub on the Transport level (incl. Ethernet OH). This parameter specifies the actual Ethernet capacity to be installed on Iub at the BTS side.

RNC_Ethernet_Capacity: Total bandwidth per RNC Ethernet port grouping multIPle logical Iubs. This parameter specifies the Ethernet capacity to be installed on Iub at the RNC side. Against this parameter traffic shaping is done in order to not exceed the configured Ethernet link capacity for a given port.

Note that IP_Route_Commited_bandwidth, IP_Route_Bandwitdh, Iub_Ethernet_Capacity, and RNC_Ethernet_Capacity are formal parameters to be configured in the RNC and BTS.Shared_BE_IP_Allocation is not a configurable parameter, but it needs to be known in order to determine the non CAC-guaranteed bandwidth and, indirectly, the total bandwidth perIub.IP Connection Admission Control

IP-based Iub dimensioning is impacted by the IP CAC procedure. IP CAC decides whether to admit an incoming RAB connection depending on the available Iub bandwidth. It is performed in RNC in DL, separately for each logical Iub, and in BTS in UL. Subject to IP CAC are the following RABs:

R99 RT DCHs (CS/PS) CS voice over HSPA R99 NRT DCHs (PS) DCCHs (over DCH and HSPA) CCHs

HSPA can be subject to CAC if the RAN1004: Streaming QoS for HSPA feature is activated. In case feature RAN1004: Streaming QoS for HSPA is not activated, HSPA is not subject to CAC.The IP CAC-guaranteed capacity per single RAB service is calculated by applying to each bearer a set of traffic descrIPtors:

Maximum bitrate in IP payload layer Average bitrate in IP payload layer

Each bearer type should have its own set of traffic descrIPtors for DL and UL separately.The IP CAC-guaranteed capacity per single RAB is calculated from the traffic descrIPtors:

CAC_Guaranteed_Bitrate RAB = 0.2 × MAX_Bitrate RAB + 0.8 × AVE_Bitrate RAB

The values of IP CAC traffic descrIPtors for some selected R99 RABs are presented in Table CAC traffic descrIPtors and bit rates for selected Release 99 and DCCH-over-HSPAbearers over HSPA traffic.

The total CAC-guaranteed bandwidth for a user service is a sum of the CACguaranteed bit rates of DTCH and DCCH channels.

For R99 services:

CAC_Guaranteed_BR Service = CAC_Guaranteed_BR Service_DTCH + CAC_Guaranteed_BR Service_DCCH

For HSPA services admitted with CAC and DCCH over DCH:

CAC_Guaranteed_BR Service = CAC_Guaranteed_BR Service_HS-DSCH + CAC_Guaranteed_BR Service_DCCH_over_DCH

For HSPA services admitted with CAC and DCCH over HS-DSCH:

CAC_Guaranteed_BR Service = CAC_Guaranteed_BR Service_HS-DSCH + CAC_Guaranteed_BR Service_DCCH_over_HS-DSCH

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

Note that RU20 RAN1201: Fractional DPCH brings in a support for DCCHs carried over HS-DSCH. IP Traffic descrIPtors for DCCHs vary depending on whether a DCCH is carried over

a DCH or HS-DSCH – see Table CAC traffic descrIPtors and bit rates for selected Release 99 and DCCH-over-HSPA bearers over HSPA traffic.

Note that recommended DCCH over DCH type for Iub dimensioning is DCCH 13.6 SET 3.

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

For RT HSPA MAX_Bitrate and AVE_Bitrate are selected based on the max and guaranteed bit rate requirement specified by the operator. For NRT HSPA MAX_Bitrate = AVE_Bitrate = Nominal Bit Rate, as specified by the operator. The operator-specified values are rounded up to the next applicable HSPA bit rate and the corresponding traffic descrIPtor is picked up. For example, a HSPA Streaming RAB carrying VoIP with max and guaranteed bit rates set respectively to 30 and 15 kbps is rounded up to 32 and 16 kbps. The corresponding traffic descrIPtors in DL are (Table IP traffic descrIPtors and Ethernet overheads for HSPA traffic): Max = 65.6 kbps and Ave = 32.8 kbps. The CAC guaranteedbandwidth in DL is equal to:

CAC_Guaranteed_Bitrate HSPA (DL) = 0.2 × 65.6 + 0.8 × 32.8 = 39.4 kbps

For a NRT HSPA RAB with the nominal bit rate set to 128 kbps, the CAC-guaranteed bandwidth DL is equal to:

CAC_Guaranteed_Bitrate HSPA = 0.2 × 166.4 + 0.8 × 166.4 = 166.4 kbps

Note that in case feature RAN1096: Transport Bearer Tuning is activated, the AVE_Bitrate parameter is calculated as MAX_Bitrate × Activity Factor instead of being picked up from traffic descrIPtors.Dimensioning the CAC-guaranteed U-plane RT traffic

U-plane CAC-guaranteed bandwidth is calculated separately for RT and NRT U-plane traffic, using different dimensioning methods. It is recommended to dimension the RT traffic (that is Conversational and Streaming R99 DCHs and Streaming HSPA) with MD-Erlang formula, separately for each DiffServ PHB class grouping this type of traffic:RT_U-Plane_commited_BW PHB = MD-Erlang [Gross_peak_rate RAB 1,

Offered_traffic RAB 1, Bl_Pr RAB 1 ; &hellIP; ; Gross_peak_rate RAB n, Offered_traffic RAB n, Bl_Pr RAB n]

where: n is the number of RT services (RABs) within a given PHB class. Gross peak rate RAB, is a sum of CAC_Guaranteed_Bitrate RAB for RT DTCH and DCCH

bearers:Gross peak rate RAB = CAC_Guaranteed_BW RAB_DTCH + CAC_Guaranteed_BW RAB_DCCH

Offered_traffic RAB is the mean traffic per service (RAB) in [erlang] extended with SHO_factor:Offered_traffic RAB = Mean_traffic RAB × (1+ SHO_Factor)The value of Mean_traffic RAB is defined by the operator. Alternatively it can be taken from the traffic model. Assumed SHO_Factor value is 30%. Note that for HSPA in DL the soft handover is not considered (SHO_Factor = 0).

Bl_Pr RAB is the service blocking probability. Usually assumed values are 0.1% – 1%.

Dimensioning the CAC-guaranteed U-plane NRT traffic

CAC-guaranteed bandwidth for the NRT traffic (that is Interactive/Background R99 DCHs and I/B HSPA, if subject to CAC) can be calculated using M/G/R-PS formula, separately for each DiffServ PHB class grouping this type of traffic:nRT_U-Plane_com_BW PHB = M/G/R-PS [Total_offered_traffic;

Gross_peak_rate RAB 1, Transfer_delay RAB 1 ; &hellIP; ; Gross_peak_rate RAB n,

Delay_factor RAB n ]

where:

n is the number of NRT services (RABs) within a given PHB class Total_offered_traffic is the total mean traffic summed over all nRT services (RABs):

Gross peak rate RAB, is a sum of CAC_Guaranteed_Bitrate RAB for NRT DTCH and DCCH bearers:Gross peak rate RAB = CAC_Guaranteed_Bitrate RAB_DTCH +CAC_Guaranteed_Bitrate RAB_DCCH

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

Delay_factor RAB reduces the effective bit rate perceived by the end-user of an NRT application as compared with the nominal CAC_Guaranteed_Bitrate. Suggested values ofDelay_factor RAB on Iub are 5-10%.With this set of inputs, M/G/R-PS is repeated n times, separately for each NRT RAB service, and the max value over all calculations is picked-up.

The use of M/G/R-PS is recommended when the QoS measures in terms of transfer delay on Iub must be explicitly taken into account. On the other hand, the formula does not take into account the service activity factor.Dimensioning the other CAC-guaranteed traffic components

Besides RT and NRT U-plane traffic (R99 + HSPA), the other traffic subject to CAC includes U-plane CCHs, C-plane and O&M.The CCH bandwidth per BTS is equal to the CAC-guaranteed bandwidth of the highest bit-rate CCH, which is FACH-U in DL and RACH in UL, multIPlied by the number of cells per BTS. The CAC-guaranteed bandwidth is calculated on the basis of the traffic descrIPtors, by default: 0.2 × Max + 0.8 × Ave. IP traffic descrIPtors for CCHs is summarized in the following table:

Bearer type

MAX rate [kbps]

AVE rate [kbps]

MAX Packet Size [Byte]

AVE Packet Size [Byte]

Ethernet OH [%]

CCH bearers

FACH-C – DL

66.2 6.1 76 34 55

FACH-U – DL

68.7 6.3 79 34 53

RACH – UL

14.3 1.1 29 0 53

PCH – DL

55.2 5.0 62 34 68

Bearer type

MAX rate [kbps]

AVE rate [kbps]

MAX Packet Size [Byte]

AVE Packet Size [Byte]

Ethernet OH [%]

CCH bearers

PCH 24k* - DL

64 5.8 73 43 98

Table 88: IP traffic descrIPtors and Ethernet overheads for U-plane CCH traffic

* Note that optional RU20 feature RAN1202: 24 kbps Paging Channel brings in a possibility to enhance the paging channel throughput to 24 kbps.For the O&M traffic a 64 kbps IP transport channel is assumed.Dimensioning the non CAC-guaranteed I/B HSPA traffic

In addition, the capacity needed on Iub for non CAC-guaranteed Best Effort traffic must be assured. Currently only I/B HSPA can fall under non-CAC guaranteed traffic. The non-CAC guaranteed HSPA capacity is calculated based on the mean traffic of I/B HSPA users extended with the Frame Protocol and IP transport overheads. Optionally, some additional QoS overhead can be added to account for instantaneous I/B HSPA bursts above the average value:BE_HSPA_BW = #_of_Subs I/B HSPA × Mean_traffic_per_subs I/B HSPA × (1 + IP_Transport_OH) × (1 + QoS_Factor)

IP_Transport_OH average values are 18% DL and 20% UL.

Typical QoS_Factor values are around 25%.Dimensioning synchronization traffic

Finally, the last traffic component to be accommodated on Iub is the synchronization traffic. In RU20, it is possible to use two types of synchronization for IP-based Iub: either Timing over Packet (ToP), defined in the IEEE 1588 standard, or Synchronous Ethernet (SyncE), defined in the ITU-T spec G.8261. The synchronization option is user configurable. In particular no synchronization is also possible.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.

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

Note that it is recommended to map the ToP traffic to the highest priority EF PHB.Guidelines for the SyncE bandwidth

The SyncE bandwidth is due to a periodical sending of synchronization status messages (SSM) between two SyncE-capable network node elements. The bandwidth requirement of the SSM stream depends on the frequency of the SSM exchange and the SSM size:SSM_BW [kbps] = (SSM_Hdr_size [bits] + SSM_PDU_size [bits]) / 1000 × SSM_rate [1/s]

SSM_Hdr_size is fixed to 224 bits, SSM_PDU_size is variable, with the mean value of 6104 bits. SSM_rate is 1/s. The mean SSM bandwidth is thus equal to 6.4 kbps.

Note that this bandwidth is to be considered only in the DL direction, at the BTS side (that is Iub last mile).

Note that the SyncE bandwidth is specified in the Ethernet layer and it is not to be considered in the higher layers. In particular, it does not affect the CAC in the IP layer.Calculating the Iub IP bandwidth for the CAC-guaranteed traffic (IP_Route_commited_BW)

Iub IP bandwidth for the CAC-guaranteed traffic refers to IP_Route_commited_BW in Figure IP-based Iub dimensioning components. It is calculated as a sum of bandwidths of all CAC-admitted services:IP_ Route_commited_bandwidth = RT_U-Plane_commited_BW +

nRT_U-Plane_commited_BW + CCH_U-Plane_commited_BW +

IP_Route_C-Plane_commited_BW +IP_Route_O&M_commited_BWCalculating the Iub IP bandwidth for the non CAC-guaranteed traffic (Shared_BestEffort_IP_Allocation)

Iub capacity for the non CAC-guaranteed traffic refers to Shared_BestEffort_IP_Allocation in Figure IP-based Iub dimensioning components. Currently the CAC-guaranteed traffic groups only the I/B HSPA traffic:Shared_BestEffort_IP_Allocation = BE_HSPA_BWCalculating the total IP Iub bandwidth (IP_Route_bandwidth)

The total IP Iub bandwidth on Iub refers to IP_Route_bandwidth in Figure Dual Iub configuration for BTS. It is calculated It is calculated separately for UL and DL.For UL it is calculated as a sum of bandwidths for CAC-guaranteed and non-CAC guaranteed traffic, including additional Transport Layer overhead:

IP_Route_BW (UL) = (IP_ Route_commited_BW (UL) + Shared_BestEffort_IP_Allocation (UL)) × (1 + Weighted_Ethernet_OH (UL))

where Weighted_Ethernet_OH is the mean Ethernet transport overhead weighted over the services supported on Iub. It is calculated as:

Ethernet overhead for single RAB is calculated out of the traffic descrIPtors (Table Header length for Iu-PS data (IP over ATM)) in the following way:

Length of Ethernet frame header is assumed 38 bytes w/o VLAN and 42 bytes with VLAN.For DL, it is calculated as maximum of two components:1.the U-plane bandwidth calculated based on the mean user traffic: RT_U-Plane (R99 and

Streaming HSPA), NRT-U-plane (R99 and I/B HSPA) and CCH_U-Plan2.the specified HSPA Peak Rate per cell/WCDMA BTS, extended with the respective Eth OH.

IP_Route_BW (DL) = Max {(RT_U-Plane_commited_BW (DL) + NRT_U-Plane_commited_BW (DL) + CCH_U-Plane_commited_BW (DL) + Shared_BestEffort_IP_Allocation (DL)) × (1 + Weighted_Ethernet_OH (DL); U-Plane_Bw (HSDPA_Peak_Rate)} + C-Plane_commited_BW (DL) + O&M_commited_BW (DL) + Sync_commited_BWWhere U-Plane_Bw (HSDPA_Peak_Rate) is the specified HSPA Peak Rate per cell/WCDMA BTS, extended with the respective Eth OH.Calculating the total Iub bandwidth for DL (IP_Route_bandwidth (DL)) is graphically presented in the following figure.

Figure 94: Calculating IP_Route_bandwidth for DL

Calculating the total Iub transport capacity

The effective Iub capacity on the transport level (denoted as Iub_Ethernet_Capacity in Figure IP-based Iub dimensioning components) can be derived directly out

ofIP_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 a sum of the capacities of all Iubs terminated at this physical port reduced with the overbooking factor:

where

denotes logical Iubs terminated at the physical interface IP_Port.The overbooking factor Overbooking IP_Port accounts for the multIPlexing gain from grouping multIPle Iubs on a single physical port. It depends on the number of Iubs grouped on a port and statistical multIPlexing characteristics of the traffic carried on individual Iubs. It can be expressed as:

where IP_Route_bandwidth (Traffic_of_multIPle_Iubs) IP_Port denotes the capacity of the aggregated traffic of all Iubs terminated on IP_Port.RNC in DL and BTS in UL perform traffic shaping. In RNC traffic shaping is done per Iub, against IP_Route_BW and per IP port, against RNC_Ethernet_Capacity. At BTS traffic shaping is done per IP port against IP_ Route_BW.IP-based Transport Network Layer configuration

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 Figure U-plane and C-plane protocol stacks on the IP-based Iub.

Figure 95: U-plane and C-plane protocol stacks on the IP-based Iub

The Iub protocol stack and the exact format of Iub Frame Protocol (FP) frames used to carry individual radio access bearers (RABs) determine the IP traffic descrIPtors used with CAC and the transport overhead (that is the amount of additional bandwidth needed to accommodate the Iub traffic on Ethernet links).The IP CAC traffic descrIPtors (defined on the IP level) and the additional Ethernet overhead for some selected R99 and HSPA RABs are summarized in Tables CAC traffic descrIPtors and bit rates for selected Release 99 and DCCH-over-HSPA bearers and CAC traffic descrIPtors and bitrates for selected HSPA flows.

Bearer typeMAX rate

[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 61 19.4 31.2

CS AMR 12.2 – DL

29.8 16.1 61 18.8 30.3

CS 64 – UL 97.5 92.0 37 93.1 127.1

CS 64 – DL 95.9 90.4 37 91.5 125.5

Real time (RT) PS bearers

RT PS 16/64 – UL

50.6 44.8 75 46.0 80.4

RT PS 16/64 – DL

97.5 92.0 37 93.1 127.1

RT PS 16/128 – UL

50.6 44.8 75 46.0 80.4

RT PS 16/128 – DL

163.1 157.6 21 158.7 192.5

Non-real time (NRT) PS bearers

Bearer typeMAX rate

[kbps]AVE rate


IP CAC

bit rate[kbps]


NRT PS 64/64 – UL

101.0 95.2 35 96.4 130.4

NRT PS 64/64 – DL

99.1 93.6 36 94.7 128.7

NRT PS 64/128 – UL

101.0 95.2 35 96.4 130.4

NRT PS 64/128 – DL

166.3 160.8 21 161.9 195.7

NRT PS 64/384 – UL

101.0 95.2 35 96.4 130.4

NRT PS 64/384 – DL

435.1 429.6 8 430.7 464.4

DCCH bearers (SET 3) over DCH

DCCH 1.6 – UL 6.5 3.2 78 3.9 6.9

DCCH 1.7 – DL 8.8 3.1 81 4.3 7.7

DCCH 3.2 – UL 12.5 3.2 78 5.1 9.1

DCCH 3.4 – DL 14.6 3.1 81 5.4 9.8

Bearer typeMAX rate

[kbps]AVE rate


IP CAC

bit rate[kbps]


DCCH 12.8 – UL

48.7 3.2 78 12.3 21.9

DCCH 13.6 – DL

49.5 3.1 81 12.4 22.4

DCCH bearers (SET 3) over HSPA

DCCH on HSPA – UL

32.2 3.2 70 9.0 15.3

DCCH on HSPA – DL

30.8 3.1 72 8.6 14.9

Table 89: CAC traffic descrIPtors and bit rates for selected Release 99 and DCCH-over-HSPA bearers

RLC SDU rate [kbps] RemarkIP Traffic

DescrIPtor (MAX = AVE) [kbps]

Ethernet OH [%]


HSDPA

CAC admitted bit rates

16 32.8 51 49.5

32 65.6 51 99.1

64 99.2 34 132.9

128 166.4 20 199.7

512 569.6 18 603.8

800 Peak rate of UE Cat 11

1040.0 17 1216.8

1120 Peak rate of UE Cat 1 / 2

1340.8 13 1515.1

1600 Peak rate of UE Cat 3 / 4 / 12

1744.0 10 1918.4

1920 2080.1 2 2121.6

2048 2214.4 2 2258.7

Non CAC admitted bit rates (10%

BLER)


- 4 3442.9


- 3 6826.9


- 3 9693.8


- 3 13289.5

19111 Peak rate of UE Cat 14 (64QAM; Flexible RLC)

- 3 20261.1

25310 Peak rate of UE Cat 16 (MIMO; 64QAM; Flexible RLC)

- 3 26829.1

38222 Peak rate of UE Cat 24 (DC-HSDPA; 64QAM; Flexible RLC)

- 3 40518.5

HSUPA

CAC admitted bitrates

32 64 53 97.9

64 97.6 34 130.8

128 164.8 20 197.8

512 568 6 602.1


769.6 4 870.3


1539.2 5 1707.1


2043.2 4 2118.3

2048 2211.2 1 2255.4

Table 90: CAC traffic descrIPtors and bitrates for selected HSPA flows

Note that IP traffic descrIPtors and Ethernet overheads depend on the actual data rates of MAC-d flows that can vary. Here these are shown for selected values of MAC-d flow rates.

RU20 RAN1638: Flexible RLC further decreases HSDPA overhead for UE categories supporting the feature (depends on the actual bit rate).Mapping U-plane, 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 are allocated IP addresses. 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.

As it should be possible to support up to 2800 instances of the logical Iub interface, the max number of IP addresses required at the BTS side would be 2800 × 3 = 8400 and at the RNC side: 2800 × 2 = 5600.

Further differentiation in the IP layer is made based on the QoS level allocated to the U-plane and C-plane traffic. Traffic is classified as belonging to a number of different traffic classes corresponding to different DiffServ Code Point (DSCP) values. Different traffic classes have different Per Hop Behavior (PHB) in the IP routed network between RNC and BTS, in terms of allocated bandwidth and forwarding policy. For the DiffServ QoS classification and handling rules, see IP transport QoS Iub.

QoS classes and treatment from the IP layer are maintained within the Ethernet-based transport network between RNC and BTS. QoS information from the IP layer is mapped to the Ethernet Class of Service (CoS) using Ethernet priority code point (PCP) 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 IP-based Iub Transport flow configuration in DL. VLAN option: 1 VLAN per logical Iub. The assumed values of DSCP, PHB and VLAN p-bits are as specified in Table Example of IP Transport QoS mapping on Iub. In one exemplary option of the VLAN usage is shown, allocating a single VLAN per logical Iub (the Eth QoS differentiation is done with VLAN 802.1 priority bits).

To meet the Iub capacity requirements defined in Iub dimensioning methods for user plane, the allocated Ethernet bandwidth per VLAN for this option should be (CIR: Commited information Rate, EIR: Excessive Information Rate):1.CIR Iub = IP_based_Route_commited_Bw × (1 + Weighted_Ethernet_OH)2.EIR Iub = Iub_Ethernet_CapacityIn case no VLANs are used or a VLAN is allocated per physical Ethernet interface at RNC, the capacity parameters should be:1.

where denotes logical Iubs terminated at the physical interface IP_Port.2.EIR IP_Port = RNC_Ethernet_CapacityNote that:

CAC at the physical interface level is not performed. A VLAN tagging option allocating separate VLANs per traffic classes (for example,

U-plane RT vs. non-RT) is currently not supported for RU10. Presented options of VLAN assignment are only exemplary. VLAN assignment is

much more flexible and can be configured in arbitrary way. In particular, no VLAN can also be used.

Ethernet frames are handled in the following way at Ethernet switches: If Traffic Rate <= CIR, both CAC-guaranteed and non CAC-guaranteed frames are

forwarded. If EIR >= Traffic Rate > CIR, CAC-guaranteed frames are forwarded, non CAC-

guaranteed frames is marked as discard eligible (DE). Non CAC-guaranteed frames pass through the network if there is no congestion.

If Traffic Rate > EIR, both CAC-guaranteed and non CAC-guaranteed frames are dropped.

Differentiation between CAC-guaranteed and non CAC-guaranteed frames is done based on VLAN p-bits.

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

IP Transport QoS on Iub

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. These are then mapped to respective PHBs in the IP transport layer to obtain the adequate scheduling and forwarding priority. The IPQoS differentiation is maintained further in the Ethernet layer by mapping the IP DSCP values to the Ethernet Class of Service (CoS) using respective Ethernet priority code points (PCP). Also the scheduling scheme on the Ethernet layer corresponds to the scheduling scheme specified for the IP layer.With basic IP Based Iub the traffic differentiation is based on the air interface channel type and the UMTS traffic class. Separate RT and NRT DSCP values can be configured for both R99 DCH and HSPA channels. The additional DSCP configuration granularity requires RAN1253: Iub Transport QoS feature. The basic DSCP mapping possibilities are depicted in Figure Possible Transport QoS mapping scheme with IP based Iub.

Figure 97: Possible Transport QoS mapping scheme with IP based Iub

An example of how UMTS transport bearers can be mapped to DiffServ PHBs is shown in Table Example of IP Transport QoS mapping on Iub. Note that UMTS traffic class to PHB mapping is operator configurable. The Table shows only one example of such mapping.

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. Streaming 0b100010 AF4 4 “Controlled

UMTS transport bearer

UMTS Service class

DSCP Value (default)

PHB to be used

VLAN p-priority (default)

DCCHs,

HSPA Streaming

(34) load”

O&M - 0b100010 (34)

AF4 4 “Controlled load”

FACH, RACH, PCH

- 0b011010 (26)

AF3 3

PS I/B Prio 1 Interactive THP 1

0b011010 (26)

AF3 3


0b010010 (18)

AF2 2


0b001010 (10)

AF1 1

HSPA I/B Background 0b000000 (0)

BE 0 “Best Effort”

Table 91: Example of IP Transport QoS mapping on Iub

CS voice over HSPA (RU20 On Top) – transport network impacts

From Transport Network point of view, RAN1689: CS voice over HSPA affects the traffic only on Iub and Iur interface. Iu-CS is not influenced. Similar C-plane and U-plane behavior is observed as comparing to the “plain” AMR/DCH calls.

Figure 98: CS voice over HSPA – impact on the transport network

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

MAX CPS-SDU bit rate AVE CPS-SDU bit rate MAX CPS-SDU size AVE CPS-SDU size

The following table lists the current set of ALC parameters related to CS voice over HSPA calls:

Bearer type MAX CPS-SDU bit rate [kbps]

AVE CPS-SDU bit rate [kbps]

MAX CPS-SDU size [Byte]

AVE CPS-SDU size [Byte]

AMR/HSPA 12.2 – UL

17.280 10.112 42 42

AMR/HSPA 12.2 – DL

17.728 10.496 44 43

AMR/HSPA 5.9 – UL

10.496 6.016 25 25

AMR/HSPA 5.9 - DL

10.944 6.400 27 26

Table 92: CS voice over HSPA – ALC parameters

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

The following table lists the current set of ALC parameters related to CS voice over HSPA calls:

Bearer type MAX rate [kbps]

AVE rate [kbps]

MAX packet size [Byte]

AVE packet size [Byte]

AMR/HSPA 12.2 – UL

31.168 16.800 70 70

Bearer type MAX rate [kbps]

AVE rate [kbps]

MAX packet size [Byte]

AVE packet size [Byte]

AMR/HSPA 12.2 – DL

31.576 17.160 71.5 71.5

AMR/HSPA 5.9 – UL

24.368 12.720 53 53

AMR/HSPA 5.9 - DL

24.776 13.080 54.5 54.5

Table 93: CS voice over HSPA – IPTD parameters

Iub interface dimensioning impacts

Similar dimensioning rules should apply to CS voice over HSPA calls as used for AMR/DCH. For detailed descrIPtion, see section ATM-based Iub dimensioning. Changed frame structure and different HSPA SHO behavior impacts the following dimensioning steps:ATM Dimensioning:

Dimensioning Option 1: calculation of parallel connections is affected by changed overhead and lack of HS-DSCH DL Soft Handover.

Dimensioning Option 1 and 2: CAC QT (DL) and AVE (UL) algorithm operates on new ALC parameters.

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

IP/Eth Dimensioning:

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

Dimensioning Option 1 and 2: CAC AVE80 calculation operates on increased IP Traffic DescrIPtors resulting in increased output.

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

Meaningful configuration impact of CS voice over HSPA should be expected due to increased CID/UDP ports demand. AMR/HSPA call occupies 4 CIDs/UDP ports (AMR/HSDPA, AMR/HSUPA, SRB/HSDPA, SRB/HSUPA) comparing to 2 CID /UDP ports reserved for AMR/DCH call (DTCH and DCCH). Mentioned increase impacts especially the ATM transport, where the expected CID demand directly impacts required number of VCCs, potentially causing heavy increase in blocking ratio of AMR calls.Configuration and traffic mapping aspects

CS voice over HSPA is activated on cell level using HSPAQoSEnabled parameter (depends on the license availability).In RAN1449: Dual Iub, CS voice over HSPA calls are always established over the ATM path.QoS Priority and VCC selection in ATM Transport

The VCC and QoS priority (AAL2 priority) selection for AMR/HSPA and corresponding DCCH/HSPA connection depends on the Iub VCC configuration, RAN759: Path Selection, andRAN1253: Iub Transport QoS features availability.

Feature availability

AAL2 queue VCC selection

RAN759 not activatedRAN1253 not activated

Highest priority queue (same as AMR/DCH)

Same VCC as AMD/DCH

RAN759 activatedRAN1253 not activated

Highest priority queue HSPA/HSDPA/HSUPA Stringent

RAN759 activatedRAN1253 activated

According to AAL2 queue assigned to SPI

Defined in RNC/TQM/QosPriToAAL2PT

According to AAL2PT assigned to SPI

Defined in RNC/TQM/QosPriToAAL2PT

Table 94: CS voice over HSPA – QoS Priority and VCC selection in ATM Transport

QoS Priority in IP Transport

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

Feature availability

AAL2 queue

RAN1253 not activated

Same as RT DCH

Defined in RNC/WBTS/RTDCHToDSCP

RAN1253 activated

According to DSCP assigned to SPI

Defined in RNC/TQM/QosPriToDSCP

Table 95: CS voice over HSPA – QoS Priority selection in IP Transport

Hybrid transport and Iub dimensioning

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 and R99 Iub traffic is transmitted over the TDM network (according to existing RAS06 transport solution). Synchronization should also be provided

by the TDM network. In order to separate HSDPA and HSUPA traffic from other user plane traffic, RAN05.1 Route Selection feature or the RAS06 Path Selection feature are needed.The hybrid transport dimensioning in ATM layer is similar to other user plane traffic dimensioning, but for the Ethernet layer the overheads caused by Pseudowire Emulation (PWE) need to be taken into account. The protocol stack for hybrid transport is presented in Figure Protocol stack for hybrid transport over Iub.

Figure 99: Protocol stack for hybrid transport over Iub

The overhead calculation can be based on following header sizes per Ethernet frame: control word (optional) 4 bytes PW header 4 bytes IPv4 header 20 bytes Ethernet Mac header 14 bytes + optional VLAN ID 4 bytes Interframe gap, Preamble and FCS, total 24 bytes

This leads to 70 bytes overhead per Ethernet frame, if the optional VLAN ID and control word are used. The efficiency of hybrid transport depends on how many ATM cells are concatenated to a single frame, which is defined by parameters 'concatenation factor' and 'packetization timer'. Concatenation factor is the maximum number of ATM cells that are allowed to a single frame and packetization timer is the maximum delay that can be used to fill up the frame. When the maximum amount of ATM cells per packet has been reached (according to ‘concatenation factor’ settings), the packet should be scheduled for forwarding regardless of the status of the “packetization timer”.The following formula should be used to calculate the Ethernet bandwidth:

(i) Ethernet_bandwidth = Packet_size * Packet_rate

Where:

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

Packet rate = PCRVP/VC / Cells_per_packet

and:PCRVC/VP is the sum of VC peak rate assigned to given pseudo wire (PW).

Since single IP tunnel between BTS and RNC PWE gateway may consist of number of pseudo wires thus overall Ethernet bandwidth is the sum of the bandwidth required for each single PW.

Table Example calculation for hybrid transport overheads on top of ATM layer gives examples of the capacity needed in Ethernet layer if parameter 'concatenation factor is given value 28, and 'packetization timer' is given value 5 ms.

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

ATM capacity

[cps]

ATM capacity

[Mbps]

Ethernet capacity

[Mbps]

Hybrid transport overhead [%]

37740 16 16.5 3.1

Table 96: Example calculation for hybrid transport overheads on top of ATM layer

Only one tunnel is required to connect BTS PWE GW and RNC PWE GW and each BTS may configure up to 6 PWs in total.To map VCC into PWs N-to-one mode mod is supported where one or more ATM VCC or ATM VPC are encapsulated into one Pseudo Wire (PW). Having for each VPC more VCCs of the same type (for example, HSDPA), all the VCCs with the same type of traffic have to be multIPlexed into same PW. For the scenarios when HSDPA VCCs and the HSUPA VCCs are encapsulated in different PW it is possible to apply different handling of traffic in uplink and downlink direction (that is to provide prioritization for control frames over user traffic). This is mainly relevant provided that both types of channels are strongly asymmetric.

Note that when sharing PWs, only VCCs of the same ATM service category must be allowed configured into single PW.

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

Applying Hybrid transport configuration on Iub interface the operator is able to separate delay sensitive CS traffic from bandwidth demanding HSPA data and simultaneously employ lower cost PSN transmission for NRT DCH or HSPA connections. It is expected also that such IP/Ethernet based transmission is offering lower reliability than ATM/SDH transport network, especially when considering low quality last mile technologies like xDSL.Introduced in RU20, RAN1578: HSPA Transport Fallback feature provides protection mechanism of the Iub transport for HSDPA/HSUPA (and potentially for NRT DCH) calls by using the ATM/TDM path as a backup in the case where the PSN transmission path fails.

Basic function of RAN1578: HSPA Transport Fallback, called also IP to ATM fallback scenario, provides a protection mechanism for HSDPA, HSUPA and NRT DCH user traffic in hybrid Iub configurations, where HSDPA/HSUPA (and optionally also NRT DCH) traffic is carried over PSN network while other RT traffic is carried over ATM/TDM. Hybrid Iubconfiguration in this context relates to the usage of either Hybrid BTS Backhaul transmission with emulated IP via PWE function or Dual Iub for FlexiBTS/UltraBTS with native IPtransmission.

Figure Dual Iub configuration for BTS shows simple hybrid network scenario (Dual Iub for BTS) with two different transmission paths between BTS and RNC, where:

CCH, RT DCH, CS over HSPA, signaling and O&M data assumed to be carried over ATM/TDM network (ATM Iub)

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

Figure 100: Dual Iub configuration for BTS

In the case where RNC detects fault in native or emulated IP transport, the protection ATM Iub path is used to carry the traffic classes configured previously over IP Iub transport. Notice that even the feature is intended to protect against

malfunctions of low reliable last mile xDSL lines, the system moves traffic to the working ATM path, also after the defects in other parts of the IP transmission path between RNC and BTS. For more information about the feature, see respective feature area descrIPtion.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 high reliable transport solution is reached through:

selection of traffic classes intended for protection correct pre-configuration of fallback (backup) VCCs over ATM network proper dimensioning of fallback VCC - extra bandwidth potentially required on

ATM Iub interface to protect the data of the failed IP path

The selection of the traffic classes intended to be saved in HSPA fallback scenario is operator configurable. Basic traffic classes that can be protected are: NRT DCH, RT HSPAand NRT HSPA. Additionally, enabling of RAN1253: Iub Transport QoS feature, the classification is extended towards higher traffic class granularity taking into account SPI values for HSPA traffic (that is FallbackForHSPAQoSPriXX) and QoS for DCH traffic (that is FallbackForDCHQoSPriXX). For proper VCC selection in hybrid BTS backhaul scenario, a newly introduced AAL2 Fallback VCC attribute is required to distinguish between VCCs intended to be used for protection and default Iub/ATM VCCs.Note that traffic classes, originally configured over IP network, which are not part of the protected traffic, are not established by the RNC towards the considered BTS as long as IPlink is failed.

Configured VCCs used as a fallback can be dedicated for the traffic moved to ATM path in case it fails or same VCC can be used both as default VCC for DCH traffic and as fallback VCC for HSPA data after IP network outage. Thus, two types of fallback VCCs can be distinguished as follows:

Shared fallback VCC, which is applicable in particular for traffic types with similar QoS requirements. Moreover, enabling RAN1253 feature, the fallback traffic could be additionally configured with low AAL2 queue priority to preserve suitable QoS for original traffic.

Dedicated fallback VCC, where fallback VCCs are not operational in “normal” network conditions but is used only in case the default IP path is faulty.

Note that combination of both shared and dedicated VCCs on single Iub interface is also possible. For hybrid BTS backhaul scenario, the AAL2 Fallback attribute is used to indicate whether the given AAL2 VCC should be used as fallback VCC for HSPA (NRT DCH) traffic when default Iub/ATM VCC is not available.For Dual Iub scenario (native IP transport at RNC side), the usage of fallback VCC label is not recommended because the RNC establishes over ATM only new transport bearers that are configured to be protected.

In order to provide efficient bandwidth for the ATM network after the IP path failure, one need to consider both the traffic classes intended for protection and corresponding fallback VCC combinations. In this context, the operator should take into account several possibilities how to dimension the Iub interface capacity:

Consider extra capacity on ATM Iub to protect complete traffic intended to run over IP network - this requires high capacity resources available on Iub.

Assume that no additional bandwidth is reserved on ATM Iub for moved HSPA traffic, simultaneously accepting temporally service degradation over the ATM path during failure period.

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

In the first case, to calculate capacity of the fallback VCCs, same dimensioning methods as described in section ATM-based Iub dimensioning can be applied. Configuring the shared fallback VCC, the dimensioning is done when both the traffic classes configured over ATM during normal operation and traffic classes intended for protection are taken into account. In case of dedicated fallback VCC, only traffic classes selected for

protection need to be considered to dimension the bandwidth of pre-arranged VCC. Such approach allows for the additional traffic sent over ATM network, guaranteeing the original quality of service level for all traffic data sent after IP path failure.The following figure presents exemplary transport fallback configuration with dedicated fallback VCC. Both RT/NRT HSPA traffic classes are intended for protection and the fallback VCC is dimensioned in a way that it carries complete HSPA traffic after packet network unavailability. For better clarification only the user plane VCCs are presented. Note that for the fallback VCC dimensioning, it is advised to not consider HSPA peak rate requirements.

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

Within the mentioned approach, the spare Iub bandwidth reserved for HSPA traffic is not used during normal operation and might be wasted. Thus, the alternative way to handle relocated IP traffic is to add extra capacity, either for high revenue services only or consider that no extra bandwidth is needed on Iub interface at all. The former case is relevant for the scenarios when failures in the network are expected very sporadically for a short period of time. In both cases, the shortage of capacity resources after the IP path failure phase can lead to the service degradation on Iub.In the following example, two fallback VCCs are configured, having RT/NRT HSPA traffic classes intended for protection. VCC2, which is normally working for stringent bi-level DCH traffic, is used also as fallback VCC for stringent bi-level HSPA calls, originally carried over IP. bandwidth of VCC2 is assumed to be increased to handle complete traffic after failure. VCC3 is a fallback VCC only and is suitable for HSPA tolerant traffic. In this case, UBR ATM service category is set for this fallback VCC, which means that no capacity can be guaranteed for NRT HSPA traffic. Consequently, the ATM Iub bandwidth is not wasted during normal operation.

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

Note that Conversational HSPA traffic is always mapped over ATM transport in case of Dual Iub feature and, therefore, there is no need to save these traffic types.RAN1707: Flexi WCDMA Integrated CESoPSN (RU20 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 (pseudowire) gateways are required to terminate TDM links and encapsulate TDM frames into IP datagrams at the edges of PSN domain.To allow tunneling TDM traffic (PDH E1/T1 links) over PSN backhaul network, pseudowire gateway is introduced to Flexi WCDMA BTS with RAN1707. The actual implementation is based on RFC5086. This functionality can be enabled in the following FTM modules equIPped with both PDH (E1/T1) and Ethernet interfaces:o FTIB (up to 4xE1/T1 for CESoPSN tunneling)o FTLB (up to 4xE1/T1 for CESoPSN tunneling)o FTFB (up to 16xE1 for CESoPSN tunneling)

RAN1707 Flexi WCDMA BTS Integrated CESoPSN feature is designed to connect legacy 2G BTS (or any other equIPment using PDH E1/T1 interfaces) to PSN based backhaul network through collocated Flexi WCDMA BTS. This feature eliminates a need to install TDM equIPment and to provide expensive E1/T1 links to legacy BTSs collocated with Flexi WCDMA BTS connected to PSN backhaul.Typical configuration using RAN1707 feature is presented in Figure Basic configuration for RAN1707 feature.

Figure 103: Basic configuration for RAN1707 feature

This feature introduces constant CES traffic, which is transmitted through PW tunnel between 2G BTS collocated Flexi WCDMA BTS on one side, and external PW gateway on the other side. Constant CES traffic has to be considered while dimensioning and calculated.CESoPSN packet format

According to RFC5086, TDM frames have to be encapsulated into IP datagrams using protocol stack presented in Figure CESoPSN protocol stack.

Figure 104: CESoPSN protocol stack

UDP port number is used to distinguish different pseudowires within the same pseudowire tunnel. Each E1/T1 link is encapsulated in dedicated pseudowire.Pseudowire tunnel is identified by IP addresses at both ends.

CESoPSN Control Word field is used for maintenance and alarm handling. Detailed structure of CESoPSN Control Word is shown in Figure CESoPSN Control Word field details.

Figure 105: CESoPSN Control Word field details

o L, R, M bits are used for alarm indication.o FRG bits are cleared for most services.o LEN bits may be used to carry length of the CESoPSN packet (defined as a size of

the CESoPSN header + a payload size) if it is less than 64 bytes, and must be set to zero otherwise.

o Sequence number is used to provide the common PW sequencing function, as well as detection of lost packets.

CESoPSN packet TDM payload carries E1/T1 timeslot bytes which are specified to be transferred over PW tunnel. TDM payload format is shown in Figure CESoPSN TDM payload format.

Figure 106: CESoPSN TDM payload format

TS 1, TS 2, ..., TS N are the timeslot octets from tunneled E1/T1 frame. Up to 31 timeslots can be encapsulated per E1 frame and up to 24 timeslots per T1 frame. The operator can configure the timeslots that are tunneled. The E1/T1 timeslots specified for encapsulation do not have to be consecutive.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 equation:

D = M * TDM_frame_duration

For total bandwidth calculation, the following protocol overheads have to be considered:

ETH_OH = 38 bytes (including preamble and interframe gap)

VLAN_OH = 4 bytes

IPv4_OH = 20 bytes

UDP_OH = 8 bytes

CESoPSN_Control_Word = 4 bytes

Resulting constant bandwidth consumption on IP level (without Ethernet overhead) is:

CESoPSN@IPv4_BW = (IPv4_OH + UDP_OH + CESoPSN_Control_Word + L)

*8 / D= (IPv4_OH + UDP_OH + CESoPSN_Control_Word + M * N) * 64 / M =

= (32 + M * N) * 64 / M [kbps]

By adding Ethernet overhead, we can calculate constant bandwidth consumption on Ethernet level:

CESoPSN@ETH_BW =

= (ETH_OH + IPv4_OH + UDP_OH + CESoPSN_Control_Word + L) *8 / D =

= (ETH_OH + IPv4_OH + UDP_OH + CESoPSN_Control_Word + M * N) * 64 / M =

= (70 + M * N) * 64 / M [kbps]

Additionally, if optional VLAN tag is added, constant bandwidth consumption on Ethernet level is given by the formula:

CESoPSN@ETH_BW = (ETH_OH + VLAN_OH + IPv4_OH + UDP_OH ++ CESoPSN_Control_Word + L) *8 / D = (ETH_OH + VLAN_OH + IPv4_OH ++ UDP_OH + CESoPSN_Control_Word + M * N) * 64 / M = (74 + M * N) * 64 / M [kbps]

Exemplary bandwidth consumption on Ethernet level (VLAN configured) for given number of timeslots, depending on packetization delay, is shown in Figure Packetization latency and CESoPSN bandwidth.

Figure 107: Packetization latency and CESoPSN bandwidth

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.o Every TDM frame must consist of constant number of timeslots to be encapsulated

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

configurable).o Up to 16 pseudowires can be configured in one PW tunnel.o Up to 1 pseudowire tunnel can be configured per Flexi WCDMA BTS.o Maximum payload for CESoPSN packet is 992 bytes (32 TDM frames with 31

timeslots in each frame, encapsulated in one CESoPSN packet).o Maximum packetization latency for CESoPSN packet is 4 ms (32 TDM frames).o It is recommended to map CESoPSN to EF (expedited forwarding) traffic class, but it

can also be mapped to any other traffic class.o It is recommended for CESoPSN traffic to use a dedicated VLAN. If not possible,

CESoPSN traffic can also share already existing VLAN.

Synchronization options

Several synchronization options can be used when RAN1707 is enabled.

Figure 108: Synchronization options

RAN1709 VLAN Traffic Differentiation (RU20 On Top)

RAN1709 VLAN Traffic Differentiation feature introduces a possibility to configure up to two IP based routes per BTS and to terminate Iub traffic on different logical IP interfaces, each one within separate subnet/VLAN.This feature allows to group traffic classes within transport network according to IP address/VLAN assigned and apply different QoS policies (priorities) per each group. Furthermore, it allows to aggregate the traffic to be handled with similar SLA parameters for many BTS nodes. Also load balancing scenario (two same priority paths configured with equal load distribution between them) can be applied.

Up to 5 IP interfaces (logical VLAN interfaces) can be configured on BTS side and up to 4 IP interfaces (logical VLAN interfaces) per Iub on RNC side (ToP traffic can use dedicated VLAN/subnet and is not terminated in the RNC).

Exemplary basic configuration using RAN1709 is shown in Figure Basic RAN1709 configuration for L2 backhaul with L3 RNC site router scenario. In this scenario, L2 backhaul network is assumed with L3 RNC site router assigning VLANs towards BTSs. In this case, 2 UP VLANs are configured and 3 dedicated VLANs for CP, O&M and ToP traffic respectively.

Figure 109: Basic RAN1709 configuration for L2 backhaul with L3 RNC site router scenario

Up to 4 VLANs can be configured in one IP based route between the RNC and the BTS.o Up to 2 VLANs for User Plane traffico Control Plane traffic (NBAP) can use a separate VLAN or existing VLANo BTS O&M traffic can use a separate VLAN or existing VLANo Timing over packet traffic (ToP) can use a separate VLAN at the BTS or existing

VLAN

If VLANs are not configured in the RNC or in the BTS, then the mapping of bearers to IP Destination Address, DSCP (in consequence to PHB), and p-bits needs to be supported by UTRAN NEs and VLAN tagging needs to be supported by external switch/router on behalf of the RNC or the BTS (VLAN tagging is based on subnets IP addresses belong to).Traffic processing

The following traffic processing steps are applied in the RNC and the BTS respectively when RAN1709 feature is enabled.VLAN traffic processing in the RNC:1.Before U-plane transport bearer setup, the traffic needs to be mapped to the IPbasedRoute,

matching BTS id and DSCP. If more than one IPbasedRoute fits these criteria, a load sharing (round robin) decision is taken. The RNC determines its local IP address to be used for the specific bearer and sends this IP address to the BTS through NBAP.The BTS then selects a corresponding local IP address, which allows the usage of the same VLAN associated with the RNC IP address, and returns its local IP address to the RNC via NBAP.All traffic belonging to a certain U-plane bearer is “marked” with the proper BTS destination IP address, the RNC source IP address, and the DSCP.

2.All traffic going to the same IPbasedRoute is shaped (rate limited) to the IPbasedRoute bandwidth in IFC virtual scheduler/shaper, where the IPbasedRoute is identified by one or several source IP addresses.

3.U-plane traffic is forwarded to PHB queue at physical port level which corresponds to the DSCP.C-plane and M-plane traffic is forwarded directly to the same set of PHB queues at physical port level, without IPbasedRoute level shaping.Scheduling and shaping at the physical port level is unchanged, compared to RU10. VLAN tagging of the egress traffic is performed based on the destination IP address (and the related routing information).

Figure 110: RAN1709 RNC traffic management

VLAN traffic processing in the BTS:1.BTS traffic classification is performed:

o Bearer to DSCP (in consequence also to PHB), p-bits (if tagging enabled), traffic priority configurable mapping

o CAC check at bearer setupo Bearer's IP address (subnet), assigned basing on the RNC local IP address signaled by

the RNC in NBAP message, defines VLAN to be used.

2.All traffic is queued in the VLAN schedulers. Per VLAN shaping is also performed here.3.WFQ scheduler is used as the physical interface scheduler, combining the traffic of several

VLANs. Corresponding weights (W1-W5) are derived from the VLAN CIR values (Wx=10*CIRx). If for a given UP VLAN CIR=0 is configured, meaning that only non-CAC guaranteed BE UP traffic is mapped to this VLAN, a corresponding weight value in the interface WFQ scheduler is set to 1.

Figure 111: RAN1709 BTS traffic management

Shaping in the BTS can be applied:o per IP interface level to IP interface SIR (SIR=CIR+EIR) and SBS (Shaper Burst Size)

parameterso per VLAN to VLAN specific SIR and SBS parameters

VLAN shaping can be enabled or disabled per VLAN. If VLAN shaping is enabled for any VLAN within the IP based route, then CAC should be done at VLAN level, otherwise the BTS should perform CAC at the IP based route level. Note, that in RNC shaping could be done only per IP based route.User plane VLAN mapping options

UP traffic classes assignment to UP VLANs is based on UP bearer to DSCP and then DSCP to PHB mappings. For each UP VLAN, a PHB class is assigned to be carried within this VLAN, except for load sharing case, where both UP VLANs carry traffic belonging to all PHB classes.UP bearers sharing the same PHB class can only be mapped to the same UP VLAN.

Even if DSCP to PHB mapping is different on the RNC and the BTS side, UP VLAN assignment is based on the RNC configuration (the RNC sends its local IP address through NBAP and basing on this the BTS assigns its local IP address and VLAN accordingly).Feature related parameters

The following parameters can be configured:o In RNC (per BTS, for each VLAN instance)

o related IP subneto related IPbasedRouteo VLAN tagging enabled/disabled

o In BTS (for each VLAN instance)o related IP subneto VLAN tagging enabled/disabledo CIR (committed information rate) - average rate up to which traffic is delivered

by one VLAN. It defines the guaranteed transport capacity for the VLANo SIR (shaper information rate), SIR=CIR+EIRo VLAN shaper burst size (SBS) - maximum burst size applied by the shaper

Dimensioning aspects

The same general dimensioning methods as presented in section IP-based Iub dimensioning should be applied when using RAN1709 feature. Since UP traffic to UP VLAN mapping is PHB based, dimensioning should be done per PHB class. For each

VLAN, aggregated values for CAC-guaranteed and/or non CAC-guaranteed traffic (depending on bearers assigned to relevant PHB classes) have to be computed.To apply CIR and SIR parameters per VLAN, a relevant aggregated CAC-guaranteed (for CIR) and non CAC-guaranteed (for EIR) values can be used. SIR is then calculated as CIR+EIR. Note, that both CIR and SIR parameters are given on Ethernet level (so CAC-guaranteed and non CAC-guaranteed values should include Ethernet overhead).

It is possible on BTS side to shape egress (UL) traffic per VLAN. VLAN shaping is applied to the configured SIR value. It is recommended to apply per VLAN shaping in case traffic is routed via different paths (each VLAN should be shaped to SIR value, according to dimensioning calculation), in other cases (same path for all traffic) per IP based Route shaping only should be appliedDimensioning example

All traffic mappings and bandwidth calculations are presented for exemplary purposes (these are not Nokia Siemens Networks recommendations). Presented example is applicable mainly for BTS side (where CIR, SIR parameters are required).1.The following bearers/services to PHB classes mapping is assumed (RAN1253 not enabled):

ToP -> EFC-Plane -> AF4O&M -> AF1RT_DCH -> EFNRT_DCH -> AF4RT_HSPA -> AF4NRT_HSPA -> BE

2.The following PHB classes to VLANs mapping is assumed:UP VLAN 1: EF, AF4, AF3, AF2UP VLAN 2: BEVLAN 3: ToP, C-Plane, O&M

3.Basing on dimensioning rules presented in chapter IP-based Iub dimensioning, the following bandwidth estimations per PHB class are calculated (all values on Ethernet level):ToP_BW = 15 kbpsC-Plane_BW = 150 kbpsO&M_BW = 100 kbpsRT_U-Plane_committed_BWEF = 300 kbpsRT_U-Plane_committed_BWAF4 = 200 kbpsNRT_U-Plane_committed_BWAF4 = 500 kbpsBE_HSPA_BW = 1500 kbps

4.bandwidth demand per VLAN, according to mapping assumed in (3): UP_VLAN_1_CIR = 300 + 200 + 500 = 1000 kbpsUP_VLAN_1_EIR = 0 kbpsUP_VLAN_1_SIR = 1000 + 0 = 1000 kbpsUP_VLAN_2_CIR = 0 kbpsUP_VLAN_2_EIR = 1500 kbpsUP_VLAN_2_SIR = 0 + 1500 = 1500 kbpsVLAN_3_CIR = 15 + 150 + 100 = 265 kbpsVLAN_3_EIR = 0 kbpsVLAN_3_SIR = 265 + 0 = 265 kbps

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

n * E1 IMA, ATM VC n*2,048 n*1,904070 n*4490

STM1, ATM VC4, OC3 155.52 149.76 353207

STM1, ATM n*VC12 155.52 n*1.920 n*4528

STM1, ATM n*VC12 IMA 155.52 n*1.904070 n* 4490

Fast Ethernet 100 100 -

Gigabit Ethernet 1000 1000 -

Table 97: Iub interface types

DN70118376 Id: 0900d80580736fc8 ©2010 Nokia Siemens Networks

ScrIPt Src

Documents

Transcript of ScrIPt Src