Node B and RNC Interface Dimensioning Procedures

This document explains the high level dimensioning procedure for the UTRAN interfaces of Motorola’s Node B and RNC5000 equipment. This includes calculations of the numbers of links required at each interface and also the hardware cards within the Node B and RNC5000.

Certain overheads must be included in the bandwidth calculations to determine the available bandwidth on the E1 or STM-1 links for user data. This document explains the dimensioning assumptions for each of the applicable overheads and demonstrates user traffic model is then used to calculate the links required for the Iub interface between the Node B and RNC5000 for a given level of user traffic. Additional assumptions for the RNC design are also discussed in order to demonstrate the Iu-CS, Iu-PS and Iur interface dimensioning.

Dimensioning of E1 links on Iub interface

The network consists of 100 Node B sites and two RNC5000 locations. The Iub interface between the Node B and RNC is supported on E1 links over using ATM protocol. . A single E1 Iub link supports a transmission rate of 1920 kbit/s or 4528 ATM cells/sec after removal of E1 signalling frames. Typically, the average user traffic at the site is provided but Tthe E1 bandwidth at each site must be capable of supporting the peak busy hour traffic including all associated overheads. The bandwidth requirements for this proposal were calculated by proposing a peak site traffic as an example and including all the associated overheads.

A single E1 Iub link supports a transmission rate of 4528 ATM cells/sec after removal of E1 signalling frames. Certain overheads must be included in the bandwidth calculations to determine the available bandwidth on the E1 link for user data. This document explains the dimensioning assumptions supporting the requirements for an average of two E1 links per Node B site. Additional assumptions for the RNC design and other transmission interfaces are also discussed later in the document.

UTRAN Signalling overheadsMotorola currently recommends the ATM QoS parameters specified in the table below. Node B Application Part (NBAP) is the application protocol between the RNC and Node B and is used to configure and manage the Node B and set up channels on the Iub and Uu interfaces.Access Link Control Application Part (ALCAP) is the transport signalling protocol used to setup and tear down transport bearers. In UMTS the main ALCAP protocol is the AAL2 signalling protocol. The O&M overhead supports the signalling between the OMC-U and Node B. All these overheads are subtracted from the initial value [1] to produce a remaining value [2] below.

DL (cells/s) UL (cells/s)

Total E1 bandwidth [1] 4528 4528

NBAP (common) 250 350

NBAP (dedicated) 300 800

ALCAP 250 250

O&M 2050 250

Remaining AAL2 bandwidth [2] 352478 292878

These overheads and the common control channel overheads are required only on the first E1 link at each site. Additional E1 links will therefore provide greater user bandwidth than the first link.

Common Control Channel OverheadsThe following table shows the additional AAL2 bandwidth reserved by the RNC for the cell common control channels and required on a per site basis, assuming 1/1/1 site configuration. These additional overheads are subtracted from the above total [2] to produce remaining value [3].

ChannelDL (ATM cells/s) per Node B site

UL (ATM cells/s) per Node B site

RACH --- 342 (3 * 114)

FACH 342 (3 * 114) ---

PCH 228 (3 * 76) ---

Remaining AAL2 bandwidth [3] 29508 25836

Capacity of E1 link for User Data after accounting for Overheads including ATMAn ATM cell consists of 53 bytes of data comprising of 48 bytes of user data and 5 bytes of ATM header information.

Therefore, the initial E1 bandwidth [1] of 4528 cells/s is equivalent to (4528*53*8) 1920 kbit/s from the total E1 maximum capacity of 2048kbit/s, with the remaining frames used for E1 signalling.

Accounting for all the above Signalling and CCCH overheads, the following section shows the user bandwidth available after convertinged to kbit/s, using the following formula;

, { ATM Cell = 8 * 53 = 424 bits }

Downlink = 29508 cells/s [3] = 29508 * 53 * 8 = 125433 kbit/s Uplink = 25836 cells/s [3] = 25836 *53 * 8 = 109675 kbit/s

Capacity of E1 link for User Data after accounting for ATM OverheadsAn ATM cell consists of 48 bytes of user data and 5 bytes of ATM header information. Therefore, after removing ATM header, the useful user bandwidth available on the first E1 link is:

Downlink = 125433 * 48 / 53 = 113617 kbit/s Uplink = 109675 * 48 / 53 = 99374 kbit/s

The useful user bandwidth available on subsequent additional E1 links is calculated from the initial ATM capacity of 4528 ATM cells/s, but accounting only for the ATM header overheads of 5 out of 53 bytes. Therefore, additional E1 links have the following capacity for user data.

Downlink = 4528 cell/s = 4528 * ( 8 * 53 ) * ( 48 / 53 ) = 1738 kbit/s Uplink = 4528 cell/s = 4528 * ( 8 * 53 ) * ( 48 / 53 ) = 1738 kbit/s

AAL2 Bandwidth required per User Connection

All dedicated channel and associated signalling bearers must beare allocated a reserved bandwidth on the E1 link as shown below. In order to utilize the available bandwidth more efficiently Aa variable called AALFACTOR is may be used within the channel setup procedure. AALFACTOR defines the percentage of the value in the table below being reserved during the call setup procedure. For example, in the case of AALFACTOR = 70% for PS services the reserved bandwidth for 64k / 64k call is 57k / 58k. the Iub call capacity therefore increases with decreasing AALFACTOR values. This factor is used within the admission control algorithms to account for the fact, that on average, most PS Data channels, once allocated, will be utilised by much less than 100%.

Service type DL kbit/s UL kbit/sSRB 5.9 6.4

Voice 18.5 18.564 / 64 81.4 82.2

128 / 64 160.6 82.2384 / 64 479.6 82.2

Applying the Dimensioning rules to a User Traffic ModelAlthough the average traffic in the network may be initially low, the transmission to the Node B must be able to support the peak expected traffic at the site to avoid call blocking.

The table below shows the Downlink traffic model used in the original proposalfor this example, with:

traffic per subscriber total network traffic based upon 1030k subscribers total average traffic per UMTS cell based upon 100 tri-sector sites (300 UMTS cells) 10% retransmission overhead factored in for packet data

Per Sub.DL Total

TrafficDL Traffic

per cellNumber of 3G subscribers 1230,000 1230,000 4100

Voice 25.0 mErl.300750 Erlangs

102.5 Erlangs

CS Data 0.06 kbit/s7.21800 Mkbit/s

246 kbit/s

R99 PS Data 0.13 kbit/s15.64290

Mkbit/s5215 kbit/s

HSDPA Data 0.45 kbit/s5,4014850

kMbit/s1850 kbit/s

It can be seen that the average traffic per cell is relatively low, but the transmission will need to account for peak traffic at each site. This must be done on a site by site basis dependant upon the distribution of subscribers and traffic through the network. However, for this case it is assumed that the average peak traffic must support the following traffic at each UMTS cell. the table below shows the average traffic per cell calculated for the traffic model and also the required peak capacity.

The peak is considered to be 5 voice connections, one CS 64k and one 384k connection in every cell.For the CS services, the Erlang B equations are used to calculate the peak number of connections assuming a 2% blocking rate;

30 voice connections per 1/1/1 site is increased up to 39.

72kbit/s (3*24kbit/s) of CS data is rounded up to 2 * 64k connections per site, which is increased to 6 connections per site using Erlang B.

For simplicity in this example, the R99 PS Data is assumed to be at an average bearer rate of 64 kbit/s with an average activity factor of 30%. Retransmission factor of 10% is also added. The average cell throughput of 52kbit/s can then be converted into a number of PS connections as follows;

Average throughput per site = 3 * 52 *1.1 = 172 kbit/s Average 64k connections = 156 / 64 / 0.3 = 8.9 Connections increased by 50% to a total of 14 per site, to account for peak traffic.

The average HSDPA traffic is calculated to be 180kbit/s. However, each site is set up initially to support 5 HSDPA codes per cell, which can provide peak traffic of 2.4Mbit/s per cell assuming 2/3 coding rate. Further assumptions must be made regarding the peak HSDPA traffic per site that is to be supported in order to make a realistic trade-off as to the number of E1 links to be provided at each Node B site. For this example, it is assumed that a peak HSDPA traffic of 1Mbit/s will be supported in all 3 sectors of each site simultaneously. It is also assumed that there are 30 HSDPA users per site supported, for the purpose of calculating the number of simultaneous connections required.

Average DL Traffic per cell

Peak Connections / Traffic / traffic

supported at each cellper 1/1/1 Site

Voice 102.5 Erlangs 539CS Data 246 kbit/s 16

R99 PS Data 5215 kbit/s 141HSDPA Data 180 kbit/s 30 / 3 Mbit/s

The user bandwidth required on the E1 link can then be calculated for the site and compared to the capacity of the initial E1 link to make the decision as to the number of additional transmission links required. The table below shows the initial downlink site throughput capacity not accounting for the HSDPA traffic.

The calculations are made for the downlink only as this will be the limiting link.

Assume that Ttotal SHOSoft Handover Overhead is=4 40%. However, only 25% SOFT handover overhead is factored in to the Iub the calculations as. T the additional 15% SOFTER handover overhead is not included in the Iub transmission requirements.

An AALFACTOR of 70% is also included in the PS data capacity requirements.

Service type Downlink E1 User BW (kbit/s)

R99 SRB (597 per cellsite) ( 597 * 3 * 5.9 * 1.25) 436155

Voice (39 per site)(5 per cell) ( 395 * 3 * 18.5 * 1.25) 902347

CS 64k / 64 (6 per site)(1 per cell) ( 61 * 3 * 821.4 * 1.25) 615306

PS 6384k / 64 (14 per site)(1 per cell)( 141 * 3 * 479.6 * 82 * 0.70.7 *

1.25) 1005259Total Bandwidth Bandwidth

Required (excluding HSDPA)29582067

HSDPA user data 3000

DCH for HSDPA users (30 per site) (30 * 16 ) 480

Total Bandwidth Required (including HSDPA)

6078

Therefore, TWO FOUR E1 links will support both the Uplink and Downlink peak traffic requirements including the HSDPA traffic.based upon 5 voice and 2 data connections per cell. These links provide a user data capacity of:

Downlink = 113617 + 3 * 1738 = 28556350 kbit/s Uplink = = 99374 + 3 * 1738 kbit/s = 276207 12kbit/s

The uplink requirements have not been calculated in this example, but is can be seen that there is significant bandwidth available to support HSUPA when required.

The R99 data alone requires just over two E1 links, with two additional links required for the HSDPA data. Applying very slightly less conservative peak traffic assumptions on the R99 data would maintain the bandwidth requirements below the capacity of 2 E1 links.Therefore, in the Downlink, approximately 800kbit/s bandwidth minimum is available for HSDPA traffic based upon this calculations of peak R99 traffic. However, on average the traffic model indicates that there is only one R99 data user per site rather than the peak that was used to dimension the E1 links. Therefore, on average there will be over 2Mbit/s of transmission bandwidth available at each site to support HSDPA traffic.

The calculations show that two four E1 links on average at every site will provide support for R99 and HSDPA traffic. In the actual network E1 link dimensioning will be required on an individual site by site basis dependant upon the actual distribution of UMTS and HSDPA traffic through the network.

RNC OverviewTwo RNC locations were assumed due to geographical considerations. Each RNC5000 requires only a single cabinet with an average of 50 sites connected to each cabinet. Each single cabinet will provide a capacity of up to 2500 Erlangs, which is purchased in blocks of 250 Erlangs as required. Based upon the traffic model applied with 30k subscribers, a total of seven 250 Erlang licences are required initially.

RNC500 interfacesThe RNC5000 interface on the Iub has optional interfaces for E1 links or STM-1. Based upon the total aggregate traffic, each RNC requires one STM-1 interface for the Iub.

Per SubDL Total Traffic

DL Traffic per cell

Number of 3G subscribers 30,000 30,000 100Voice 25.0 mErl. 750 Erlangs 2.5 ErlangsCS Data 0.06 kbit/s 1800 kbit/s 6 kbit/sR99 PS Data 0.13 kbit/s 4290 kbit/s 15 kbit/sHSDPA Data 0.45 kbit/s 14850 kbit/s 50 kbit/s

Node B EquipmentAt USR3, the only option available for interfacing to the Node B is via E1 / T1 links. This is done via the Span I/O interface board, which provides 8 E1 / T1 link connections.

In USR4, an IP transport feature will be available enabling the connection of an ethernet interface to the Node B in order to carry high bandwidth PS data such as HSDPA. In the above example this option would enable the number of E1 links at each site to be reduced from 4 to 2. RNC5000 Interface Dimensioning

Iub InterfaceAt the RNC, the Iub interface may be connected directly via E1 links from the Node Bs or on STM-1 after aggregation of E1 links at external equipment such as an ATM switch.

In the example previously discussed, 100 Node Bs were connected into two RNCs with an average of 4 E1 links per Node B, therefore a total of 400 E1 links are required

It is assumed for VC12 interface that 63 E1 links aggregate onto one STM-1, and therefore a total of 7 STM-1 links are required in at the RNC5000 Iub interface.

Iu-CS InterfaceEach STM-1 link supports an overall gross throughput of 155Mbit/s.

The STM-1 frame consists of a block of bytes having 270 columns and 9 rows. There are 8000 frames/s. Total capacity is 155.52 Mbps ( 270 x 9 x 8 x 8000 ). 9 columns per frame are required for STM-1 related signalling, and a further 1 column is utilised during encapsulation of the ATM cells within the STM-1 frame. Therefore, the useful capacity of the STM-1 link is 149.76 Mbit/s (260 x 9 x 8 x 8000 ). Within each ATM cell of 53 bytes, 5 bytes are used for ATM header and further 3 bytes for AAL2 signalling, therefore the effective payload for user data is 127.155 Mbps (149.76 x 45 / 53 ).

Assuming the same bandwidth requirement for each bearer as was used in the E1 link calculations, the following table can be used to estimate the number of connections of each CS bearer type that the STM-1 link can support.

Service typeConnection BW (kbit/s)

Connections per STM-1 link

Voice (incl. SRB) 24 5295CS 64k (incl. SRB) 88 1444

However, typically a design margin is included within the transmission design, for example such that 70% maximum loading is considered for STM-1 links. The table below, shows the voice and CS64k bearers supported per STM-1 for a variety of different loading points.

Service typeConnections

per STM-1 link at 80% load

Connections per STM-1 link

at 70% load

Connections per STM-1 link

at 60% load Voice (incl. SRB) 4236 3706 3177

CS 64k (incl. SRB) 1155 1010 866

Whereas the Node B capacity is dimensioned to account for peak traffic at the site, there will be averaging of traffic levels at the RNC. Therefore, it is more realistic to dimension the Iu interfaces at the RNC based upon the average Node B traffic for the 100 sites.

The following table shows the average CS traffic per site and the total network traffic for the 100 Node B sites in the example.

Average DL Traffic per cell

Average DL Traffic per site

Average DL Network Traffic

Voice 10 Erlangs 30 Erlangs 3000 ErlangsCS 64k Data 24 kbit/s 72 kbit/s 7.2 Mbit/s

CS 64k connections

< 1 1 – 2 113

It can be seen that if the STM-1 links are designed at an average maximum loading of 70%, then the voice and CS data traffic is supported by a single STM-1 link on the Iu-CS interface at the RNC. However, since the example assumed two RNCs in the network then each RNC requires one STM-1 at the Iu-CS interface, with loading of much less than 50%.

Iu-PS InterfaceSTM-1 transmission links on the Iu-PS are calculated using the same overheads as described for the Iu-CS, with a net user bandwidth of 127Mbit/s per link. The table below summarizes the bandwidth required for each user connection and the number of connections supported for each bearer type per STM-1.

Service typeConnection BW (kbit/s)

Connections per STM-1 link

at 100% load

Connections per STM-1 link

at 80% load

Connections per STM-1 link

at 60% load PS 64k / 64k 88 1444 1155 866

PS 128k / 64k 167 760 608 456PS 384k / 64k 440 288 230 172

The following table shows the average PS traffic per site and the total network traffic for the 100 Node B sites in the example.

Average DL Traffic per cell

Average DL Traffic per site

Average DL Network Traffic

R99 PS Data 52 kbit/s 156 kbit/s 15.6 Mbit/sHSDPA Data 180 kbit/s 540 kbit/s 54 Mbit/s

It can be seen that the average PS traffic in the network is 70 Mbit/s. This level of traffic is supported by a single STM-1 link and therefore, one STM-1 link is required at each of the two RNCs for the Iu-PS interface.

Iur InterfaceThe traffic on the Iur interface is a function of the number of sites on the boundary between the two RNCs. Of the 100 sites in the network assume that 20% of all sites are on the RNC boundary and thus may generate traffic that is put onto the Iur interface during a cell handover. Since a soft handover overhead of 25% is assumed it can then be calculated that approximately 5% of all network traffic needs to be supported on the Iur.

Therefore one STM-1 link is required for the Iur interface between the two RNCs. The loading on this link is less than 10% and therefore a large increase in network capacity would be required before a second STM-1 link is needed.

RNC5000 Interface Hardware RequirementsAt the RNC5000, the Iub may interface either via the System Units or into the Switch Unit.

The standard connection, recommended to customers, is to connect the Iub to the System Units, which provide the option for two types of interface board;

the WINT Board, which interfaces directly to the E1 links from the Node Bs. the WOSE Board, which provides STM-1 interfaces for the RNC System Units.

Each System Unit supports carries two WINT boards supporting a total of 64 E1 interfaces, or two WOSE boards supporting two STM-1 per system unit.

The Switch Unit provides a total of 96 STM-1 interfaces. This provides the interface for Iu-CS, Iu-PS, Iur, internal connections to the System Units and if required, an alternative connection for the Iub.

Each System Unit requires two STM-1 connections to the Switch Unit. Therefore, a maximum configuration RNC containing 16 System Units would require 32 STM-1 interfaces at the Switch Unit. The remaining 64 STM-1 interfaces at the Switch Unit are then typically available for the Iu-CS and PS, with a small number required for Iur.The total network CS traffic is approximately 11 Mbit/s, and total PS traffic is 20Mbit/s. The overall throughput of the STM-1 link is 155Mbit/s. Allowing for 100% overhead and design margin on these links, for each RNC, the Iu-CS and Iu-PS interfaces are also supported by a single STM-1 interface each. N+1 redundancy is supported within the RNC for all STM-1 interfaces. Therefore, with redundancy, each RNC requires two STM-1 transmission links to the GSN complex and two STM-1 links to the Circuit Switch.