HSDPA Dimensioning

1 © NOKIA FILENAMs.PPT/ DATE / NN

HSDPA Transmission Dimensioning Info Session

21.6. And 22.6.2005


HSDPA – High Speed Downlink Packet Access

• Specified by 3GPP Release 5 onwards• Nokia RAN05 feature• Improvements and new functionalities coming in RAN05.1 and in RAN06

(RAN06.1)

• Currently all performance figures are based on simulated or calculated results.• Field measurements in NTN start 07/2005• Customer trials start 09/2005

Improved• cell throughput• maximum user throughput• round trip time• spectral efficiency

• Meant for NRT services (background and interactive classes supported first).• Later releases also RT services (streaming class, VoIP).


RAN releases: HSDPA roadmap RAN releases: HSDPA roadmap

2H032H03 2005200520042004 20062006

HSDPA trialsHSDPA trials3/05

RAN05 RAN05 2/04

E1

For information, roadmap reference always from RAN marketing Strictly internal

RAN05.1 RAN05.1

E1

4/05

Note: Performance Verification related milestone criteria are part of RAN051 SP milestone criteria

E4

11/05

E5

2/06

E4

5/06

HSDPA early (lab) trials with selected customers


HSDPA – General principle

Terminal 1 (UE)

Terminal 2

L1 Feedback

L1 Feedback

Data

Data

•Shared DL data channel

•Fast link adaptation, scheduling and L-1 error correction done in BTS

•1-5 codes in RAN05 (max.15 codes RAN06)

•QPSK (RAN05) or 16QAM modulation

•User may be time and/or code multiplexed.

• Channel quality information

• Error correction Ack/Nack

•UL Channel is a R99 DCH

•No SHO on downlink


HSDPA Peak Bit Rates

Coding rateCoding rate

QPSKQPSK

Coding rateCoding rate

1/41/4

2/42/4

3/43/4

5 codes5 codes 10 codes10 codes 15 codes15 codes

600 kbps600 kbps 1.2 Mbps1.2 Mbps 1.8 Mbps1.8 Mbps

1.2 Mbps1.2 Mbps 2.4 Mbps2.4 Mbps 3.6 Mbps3.6 Mbps


16QAM16QAM

2/42/4

3/43/4

4/44/4




RAN05

RAN05.1


UE categories• 12 different UE categories

• Possible receiver types Rake, Equalizer, 2-Equalizer

• Theoretical peak bit rate up to 14 Mbps

• 1.8 Mbps and 3.6 Mbps capability expected initially

10

9

7/8

5/6

3/4

1/2

12

11

HSDPACategory

-

-

-

3.6 Mbps

1.8 Mbps

1.2 Mbps

1.8 Mbps

0.9 Mbps

5 Codes

--36302QPSK only

--36301QPSK only

QPSK/16QAM

QPSK/16QAM

QPSK/16QAM

QPSK/16QAM

QPSK/16QAM

QPSK/16QAM

Modulation

14.0 Mbps

10.1 Mbps

-

-

-

-

15 Codes

-279521

-202511

7.2 Mbps144111

-72981

-72982

-72983

10 CodesTransportBlock sizeInter-TTI

(First one has smaller HARQ memory.)


HSDPA Cell throughput

780 kbps

DCH: 410 kbps

1090 kbps

HSDPA: 670 kbps

DCH: 410 kbps

1320 kbps

HSDPA: 910 kbps

DCH: 780 kbps

HSDPA: N.A.

HSDPA 16QAMRR scheduling

HSDPA 16QAMPF scheduling

No HSDPA

43% Gain

21% Gain

Simulated cell throughput with mixed HSDPA and Rel.99 traffic.

5 codes assumed.

Pedestrian propagation channel.


Main HSDPA features

RAN05

• PS interactive and background traffic classes

• QPSK modulation

• Max. 5 HS-PDSCH codes

• No code multiplexing on HS-PDSCH

• Round robin scheduling

• Channel type switching to DCH on SHO areas

• Max. 1 WSPC/BTS for HSDPA

• Theoretical max. throughput 1.8Mbit/s per BTS

RAN05.1

• PS interactive and background traffic classes

• 16QAM modulation

• Max. 5 HS-PDSCH codes

• No code multiplexing on HS-PDSCH

• Proportional fair scheduling

• HS-DSCH serving cell change

• Associated DCH SHO

• AMR + HSDPA calls

• Max. 1 WSPC/cell (3 WSPC/BTS)

• Theoretical max. throughput 3.6Mbit/s per cell

Node B requires WN3.0


HSDPA BTS Configuration in RAN05

4 users

4 users8 users

Note 1: The actual amount of supported HSDPA users per WSPC depends heavily on used Uplink DCH channel speed associated with HSDPA user, see dimensioning rules

• WSPC with HSDPA SW card required

• All BTS models/configurations, that can accommodate at least one WSPC, support HSDPA.

• One WSPC unit supports max. 3 HSDPA cells.

• One WSPC unit supports max. 16 HSDPA users. 1)

• Those 16 HSDPA users can be divided freely between three cells.

• Packet Scheduler in MAC-hs schedules all users equally regardless of their cell.-> Cells get resources depending on the amount of users and traffic in each.

• Max. one HSDPA WSPC in BTS-> Max. three HSDPA cells in BTS.

• RAN05.1: max. 3 HSDPA WSPCs in BTS


HSDPA on UltraSite WCDMA BTS Platform

WSPC Allocation

• HSDPA not supported on WSPA, WSPD nor WSPE.

• When HSDPA is enabled in a cell, WSPC is allocated dynamically.

• All HSDPA channels of a cell processed on the same WSPC.

• One to three HSDPA cells supported on one WSPC, capacity shared between cells within the WSPC.

• HSDPA WSPC can also handle DCHs of any cell but with reduced capacity.

• HSDPA WSPC can also handle common channels, but that will further reduce DCH capacity.

WSPC Capacity• Without HSDPA:

• 64 DCHs at 16 kbit/s OR• 48 DCHs + common channels

• With HSDPA:• 3.6 Mbit HSDPA downlink

(= 5 HS-PDSCH codes) AND• 16 uplink HS-DPCCHs AND• 30 DCHs at 16 kbit/s or• 14 DCHs + common channels

• Associated DCHs of the HSDPA users will consume the DCH capacity.

• The WSPC for the associated DCH is selected as for any DCH (Node B sees no difference).

• MAC-d flow and DCH of the same UE can be under different WSPC and/or WAM.


HSDPA solution in RNC (RN2.1 configuration)

• RNC with HSDPA will composed of two resource pools (user plane)1. RNC rel99/04/(05) pool2. HSDPA resource pool

• RNC rel99/04/(05) pool supports all features and interfaces that has been define in RN2.1 solution Full RN2.1 feature content but limited capacity

compared to RN2.1

• If split user plane architecture is selected the HSDPA resource pool supports only HSDPA user plane traffic on RNC with limited features and HSDPA capabilities. Otherwise also AMR is supported with pooled DMCU in case of Multi RABs.

• The pooling is carried out by allocating some UP processing resources (I.e. DMCU/DMPGs) for HSDPA traffic.

• Rest of the UP processing resources are used to support non HSDPA traffic

• Control Plane procedures required by HSDPA (RRM, RRC, etc) are provided with same unit as for non HSDPA services I.e. only DMCUs are pooled


HSDPA & Iub• HSDPA improves Iub efficiency compared to Release’99 packet data

since HSDPA is a time shared channel with a flow control in Iub

• Release’99 requires dedicated resources from RNC to UE. Those resources are not fully utilized during TCP slow start, during data rate variations or during inactivity timer

• Additionally, HSDPA does not use soft handover no need for soft handover overhead in Iub

• Still a DCCH is needed downlink and a DCH+DCCH for the uplink return channel

= User 1= User 2= User 3

Iub link 1

Iub link 2

HSDPA Iubcapacity

1 2

1 = TCP slow start2 = Inactivity timer

Iub efficiently utilized by HSDPA

21


Retransmissions in HSDPA

Server RNC Node-B

UE

RLC retransmissions

TCP retransmissions

MAC-hs Layer-1

retransmissions


MAC-d and MAC-hs• Mac-d remains in RNC in the same way as for Release 99

• Mac-hs is located in the Node B to allow rapid re-transmission of NRT data

• Mac-d is responsible for:• mapping between logical channels and transport channels;• selection of appropriate Transport Format• priority handling• identification of UEs on common transport channels• multiplexing/demultiplexing of upper layer PDUs• traffic volume measurement;• transport Channel type switching;• ciphering for transparent mode RLC

• Mac-hs is responsible for:• Packet scheduling• Link adaptation • L1 error correction and retransmissions (H-ARQ)• Flow control between RNC and BTS

• This does not take AAL2 congestion into account

MAC-hs

PHY PHY TNL

MAC-d

MAC-hs

HS-DSCH

FP

HS-DSCH

FP

MAC-d

TNL

UE Uu BTS Iub RNC

RLC RLCMAC-d flow

HS-DSCH

HS-PDSCH


HSDPA Protocol Model and Iub Overheads

MAC-hs

PHY

MAC-d

MAC-hsHS-

DSCH FP

HS-DSCH

FP

MAC-d

UE Uu BTS Iub RNC

RLC RLCMAC-d flow

HS-DSCH

HS-PDSCH

PDH/SDH

ATM

AAL2

PDH/SDH

ATM

AAL2

PHY

HS-DSCH FP Overhead: For N x 42 bytes payload

7 byte header + 2 byte CRC

MAC-d N/A

RLC Overhead 2 bytes added to 40 bytes segment

PDH Overhead 2/32

ATM Overhead 5/53 (6/53 for AAL2)

AAL2 Overhead 3 bytes /packet (max 45 bytes)

• The number of MAC-d PDUs transferred within one FP frame depends on the credits allocated by the HSDPA flow control algorithm and the Data or Status PDUs waiting for transmission in the RLC buffers.

• The mean HSDPA-FP overhead depends on the number of MAC-d PDUs sent in the same frame and on the amount of FP control messages.

• In the transport simulations the FP Overhead for HSDPA has been 2-3%


Transport network with HSDPA

CPS-Packets

ATM cells

Source

DestinationCPS-

Packets

Segmentation&

encapsulation

CBR VCC

CID=z

CID=x

CID=y

CID=w

MAC-d flows

RT/NRT DCH

connections

SPS

Assembly & transmission

High priority buffer: 256 CPS-Packets

Low priority buffer: maximum

7000CPS-Packetsdefault 2048

AAL2 DEMUX

CID=z

CID=x

CID=y

CID=w

AAL2 SDUs

ReassemblyAAL2 SDUs

- MAC-d schedules the number of RLC PDUs according to the credits granted by MAC-hs at each Interval=10ms.- The aggregated rate of the HSDPA connections is controlled by the rate control implemented in MAC-sh - MAC-d PDUs are framed into FP-HSDSCH frames.- The maximum number of MAC-d flows/BTS is 16.- AAL2 multiplexes the MAC-d flows and RT/NRT DCH connections into a CBR VCC.


Definition of the HSDPA parameters

MinimumRequiredSharedHSDPAallocation (suggested to RAN05.1)Defines the minimum shared HSDPA AAL2 Allocation in kilobits/s. If the granted capacity is smaller than the value of this parameter the CAC will restrict the number of the HSDPA users on that route to a number defined by the NbrOfOverbookedHSDPAUsers parameter. By setting this parameter value to be zero, would switch this restriction off

SharedHSDPAallocation Defines the size of the shared HSDPA AAL2 Allocation in kilobits/s. This should be equal or greater than the MinimumRequiredSharedHSDPAallocation

NbrOfOverbookedHSDPAUsersDefines the allowed number of MAC-d flows on a N_CID if the Shared HSDPA AAL2 Allocation has failed. if the granted capacity is smaller than defined by the MinimumRequiredSharedHSDPAallocation parameter. (In RAN05, If SharedHSDPAallocation fails this parameter defines allowed number of MAC-d flows)

Shared HSDPA AAL2 VCC selection methodDefines how the VCC selection will be done for the shared HSDPA allocation if a route includes more than one VCC. If a single VCC is selected by value zero (0), then the dummy reservation will be done to the least loaded VCC. If multiple VCC is selected by value one (1), then the allocation will be done to all existing VCC’s under a route. SharedHSDPAFlowControlAllocation This parameter is used for RNC internal flow control overbooking purposes by the MAC-sh and for HSDPA code allocation purposes. SharedHSDPAFlowControlAllocation should be greater or equal compared to the value of the SharedHSDPAallocation in the same WBTS.

ReleaseTimerForSharedHSDPAallocation Defines the release timer for shared HSDPA allocation in minutes. This timer is started when the last MAC-d flow from a certain route is removed. If no transport is set up for new MAC-d users on that route before the timer expires the allocation will be released. (Range: 0… 2880 minutes)


R99 DCH rate

Time

VCC capacityPeak R99 DCH rate

Available bandwidth

forHSDPA

VCC Capacity- R99 DCH peak rate

VCC capacity

Peak R99 DCH rate < VCC capacity

Available bandwidth for the HSDPA traffic SharedHSDPAallocation

SharedHSDPAallocation

• The bandwidth available for the low priority traffic is variable. • The minimum bandwidth is equal to SharedHSDPAallocation (If

reservation has succeeded)• The mean bandwidth is equal to VCC capacity minus the average R99

rate• This is flow level capacity, on packet level each packet gets transmitted

with the full capacity of the virtual connection• SharedHSDPAallocation a.k.a “Dummy reservation” as this is capacity

hidden from the CAC


Time

VCC capacity

R99 DCH rate

Available bandwidth for the HSDPA traffic

MinimumRequiredSharedHSDPAallocation

Shared HSDPAallocation

• Initially, before the first HSDPA user, the R99 traffic can use the whole VCC

• If the HSDPA user enters at t1 then the Iub reservation for HSDPA fails.

• At t2 another user tries and now the capacity allocation fails again at t2.

• At t3 a third user tries to enter and the capacity allocation is the SharedHSDPAallocation

• Before t3 the number of admitted DCH flows is restricted by parameter NbrOfOverbookedHSDPAUsers.

• Note NbrOfOverbookedHSDPAUsers=0 means that no HSDPA users are admitted

t1 t2 t3

RAN05


Time

VCC capacity R99 DCH

rate

Available bandwidth for the HSDPA traffic



• Initially, before the first HSDPA user, the R99 traffic can use the whole VCC

• If the HSDPA user enters at t1 then the Iub reservation gives to HSDPA all what is available at t1 even though the capacity is less than MinimumRequiredSharedHSDPAallocation.

• The RNC CAC is trying to complete the SharedHSDPAallocation every time there is capacity available

• As long as the reserved capacity is less than MinimumRequiredSharedHSDPAallocation the number of admitted MAC-d flows is limited by the parameter NbrOfOverbookedHSDPAUsers

• At t2 the reservation is increased beyond MinimumRequiredSharedHSDPAallocation and NbrOfOverbookedHSDPAUsers is no longer considered.

• At t3 the reservation reaches SharedHSDPAallocation and is no longer increased


t1 t2

RAN5.1

t3


Time

VCC capacity

R99 DCH rate

Maximum bandwidth for the HSDPA traffic

SharedHSDPAFlowControlAllocation


• It is possible to send MAC-d flow data over Iub faster than what is reserved for HSDPA.

• SharedHSDPAFlowControlAllocation – Controls the maximum share of Iub that HSDPA is allowed to use.

• Range 500 kbps … 7.2 MBps in 100 k steps (CR#642: lower limit from 0 to 500kbps)

• Should be bigger than SharedHSDPAallocation • Should be smaller or equal than VCC size • Optimal value depends on the traffic load and degree of

congestion

SharedHSDPAFlowControlAllocation


Simulation results

BTS

HSDPA sources (TCP)

RNC

RT sources (AMR 12.2 + DCCH)

CBR VCC

Destination (sink)

Air interface

•Static scenario•16 HSDPA sources:

-4 x ftp-12 x www (100 kbyte, 15s reading time)-TCP/IP packet size 1500 byte-advertised window: 32-TCP Vegas-no delayed ACK

•50 x AMR 12.2, AF=0.6•66 x DCCH 3.4•CBR VCC: 1.5 ÷ 3.5 Mbps•One cell


Simulation: Air interface model• User profile: ITU-T Pedestrian A, velocity 3 km/h• Base station antenna height: 30m• Mobile antenna height: 1.5 m• Carrier frequency: 1950 Mhz• BTS antenna gain: 17 dBi• Inter-cell interference: -70dBm• Intra-cell interference: 30dBm• User distance from the BTS: randomly generated between 200 and 600 m• CQI: values between 0 and 22• CQI: reporting delay 3 TTI• BLER is generated with uniform distribution• SNR is calculated from:

– Distance loss: Okumara-Hata propagation model, urban cell– Multipath (fast) fading: Rake receiver, channel estimation is assumed to be ideal– Shadow (slow) fading: time correlated log-normal distribution with stdDev: 8 dB,

correlation distance 40 m– BTS antenna gain– Inter-cell interference– Intra-cell interference


Simulation1: Performance in function of VCC capacity & AAL2

low priority buffer size Traffic mix is static:

1. 12 www (HSDPA) low priority AAL2 buffer2. 4 ftp (HSDPA) low priority AAL2 buffer3. 50 AMR 12.2 kbps high priority AAL2 buffer4. 66 DCCH high priority AAL2 buffer

Low priority AAL2 buffer: 2048, 4096 CPS Packets

•50 x 12.2 AMR (AF =0.6) & 66 DCCH requires 1.277 Mbps according to CAC (10ms, 0.001)•Mean AAL2 CPS Packet rate ~ 0.860 kbps

SharedHSDPAallocation [Mbps]

Required for the high priority traffic [Mbps]

VCC Capacity [Mbps]

0.223 1.277 1.5000.500 0.500 1.7770.723 0.723 2.0001.223 1.223 2.5001.723 1.723 3.0002.223 2.223 3.500


Simulation1: Bandwidth share

0

500

1000

1500

2000

2500

3000

3500

1 1.5 2 2.5 3 3.5

VCC Capacity [Mbps]

Ban

dw

idth

[kb

ps]

Average bandwidth used by the high priority traffic (AMR&DCCH)

Average bandwidth used by the HSDPA traffic

Available bandwidth (VCC capacity)


Simulation1: Drop probability at the low priority AAL2 buffer

0

5

10

15

20

25

30

35

40

1.5 1.7 1.9 2.1 2.3 2.5 2.7 2.9 3.1 3.3 3.5

VCC Capacity [Mbps]

Dro

p p

rob

abili

ty [

%]

Buffer=2048Buffer=4096


Simulation1: RLC retransmissions

0

10

20

30

40

50

60

1.5 1.7 1.9 2.1 2.3 2.5 2.7 2.9 3.1 3.3 3.5

VCC Capacity [Mbps]

Ret

ran

smit

ted

RL

C-P

DU

s [%

]

Buffer = 2048Buffer = 4096


Simulation1: Mean TCP throughput

200

300

400

500

600

700

800

900

1000

1100

1,5 1,7 1,9 2,1 2,3 2,5 2,7 2,9 3,1 3,3 3,5

VCC Capacity [Mbps]

TC

P t

hro

ug

hp

ut

[kb

ps

]

Buffer = 2048

Buffer = 4096


Simulation1: Air interface throughput

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 200 400 600 800 1000 1200 1400 1600 1800

Air interface throughput [kbps]

Pro

bab

ilit

y

VCC Capacity=1.5 Mbps


VCC Capacity=2 Mbps


VCC Capacity=3 Mbps



Simulation2: Performance in function of rate control & low

VCC capacity Traffic mix is static:

1. 12 www (HSDPA) low priority AAL2 buffer2. 4 ftp (HSDPA) low priority AAL2 buffer3. 50 AMR 12.2 kbps high priority AAL2 buffer4. 66 DCCH high priority AAL2 buffer

Low priority AAL2 buffer: 2048 CPS PacketsVCC capacity: 2 Mbps (SharedHSDPAallocation: 0.723 Mbps)Four simulations by setting SharedHSDPAFlowControlAllocation:

1. Based on the SharedHSDPAallocation parameter (Dummy rate): 588 kbps

2. Based on the mean rate of the high priority traffic (Mean rate): 842 kbps

3. Based on the VCC capacity (VCC rate): 1628 kbps4. No rate control


Simulation2: TCP performanceDummy rate Mean rate VCC rate No rate control

TCP throughput (total) [kbps] 402.860 691.440 574.956 582.322Mean TCP connection setup time [s] 0.2399 0.1145 0.9345 0.8303Mean page download rate [kbps] 37.512 85.099 48.782 67.045

0

10

20

30

40

50

60

70

80

90

0 100 200 300 400 500 600

Time [s]

cw

nd

Dummy rateMean rateVCC rateNo rate control


Simulation2: Air interface throughput

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 200 400 600 800 1000 1200 1400 1600 1800

Air interface throughput [kbps]

Pro

bab

ility

Dummy rateMean rateVCC rateNo rate control

Dummy rate Mean rate VCC rate No rate controlAir interface throughput (total) [kbps] 418.952 723.652 813.822 808.720


Simulations: Conclusions

• When dimensioning transport network for HSDPA, the R99 traffic should be taken into consideration (HSDPA can not be dimensioned in separation).

• The VCC capacity should be dimensioned so that the R99 DCH QoS requirements are met.

• The VCC capacity and the relevant parameters should be dimensioned so that:

- the AAL2 delays are low in order to avoid RLC timeouts- the AAL2 drop rates are low in order to decrease the amount of RLC retransmissions

• The VCC capacity should be dimensioned so that the air interface is the bottleneck. In this way the HSDPA performance can be increased and the AAL2 delays and packet drops can be kept at low level.

• If VCC size is limited for other reasons (such as $) then the task is to find a suitable value for the SharedHSDPAFlowControlAllocation.

• Tools and/or simulations are needed for reliable results.• Uplink channel for HSDPA needs to be considered in

dimensioning as well. The needed Iub capacity is Max(Capacity_DL, Capacity_UL)

• If return channel is NRT384 then UL capacity is very relevant.


Iub dimensioning and planning

Iub dimensioning target: Iub Throughput evaluation

Iub Throughput = Iub Control Plane capacity + Iub User Plane capacity

1. Define the VCCs Control Plane capacity:

• AAL2 Signalling VCC(s) capacity,• CNBAP VCC capacity,• DNBAP VCC(s) capacity.

2. Define the VCC(s) User Plane capacity:

• PDCP and RLC unchanged,• MAC slightly changed,• New FP-HS-DSCH (3GPP TR 25.877),• New AAL2 queuing and scheduling,• New AAL2 CAC (new ALCs, hidden AFs),• No SHO OH.

Affected by the Open Iub in RAN’05


Iub DimensioningIub Signalling evaluation: Open Iub

The Control Plane on Iub, especially C-NBAP and D-NBAP, needs checks for bandwidth recommendations mainly due to open Iub introduced in RAN’05.

Differences in kbps (on average) are:•C-NBAP UL +35 %•D-NBAP UL +143 %•D-NBAP DL +17 %

C-NBAP changes mainly in: •Nbr of CM reports: with Nokia Iub, the CM reports of the cells of the same BTS are in one message, in open Iub in their own messages

D-NBAP changes mainly in:•Nbr of DM reports: with Nokia Iub, the DM reports of 16 subscribers are in one message, in open Iub in their own messages•DL power control

0.0

10.0

20.0

30.0

40.0

50.0

60.0

2005 2006 2007 2008 2009 2010

1+1+1,3*WSPC

1+1+1,3*WSPC

1+1+1,3*WSPC

1+1+1,3*WSPC

1+1+1,3*WSPC

1+1+1,3*WSPC

Nokia Iub vs open Iub kbps UL

Nokia Iub C-NBAP kbps UL

Nokia Iub D-NBAP kbps UL

Open Iub C-NBAP kbps UL

Open Iub D-NBAP kbps UL


The Iub dimensioning problem

Define the VCC capacity which guarantees:

1. The QoS requirements for R99 traffic (maximum allowed delay and probability)2. “Good enough” HSDPA end user service3. Low AAL2 delay

In practice this means the definition of the following parameters:

1. VCC capacity2. SharedHSDPAallocation3. SharedHSDPAFlowControlAllocation

OR

1. VCC capacity2. SharedHSDPAallocation3. SharedHSDPAFlowControlAllocation

Premium HSDPA service: Find out what the HSDPA needs.

Background HSDPA Service: Find out the R99 needs and minimise The damage for HSDPA


Defining the capacity for the R99 DCH traffic

Due to the fact that the R99 DCH traffic is mapped to the high priority buffer we can define the capacity for the R99 traffic (CR99) in separation.

This capacity is used by the CAC when admission decisions are made for the highpriority traffic.

Once admitted, the R99 connections are not restricted to this capacity, they will use thewhole VCC capacity. This also means better service for the R99.

Inputs:1. Traffic mix2. QoS requirements e.g. max delay=10ms & probability=0.001

Algorithm: CAC.


Defining the SharedHSDPAallocation

- Premium HSDPA Service - • The SharedHSDPAallocation (CHSDPA) is the bandwidth hidden by

the CAC, if the total bandwidth is C=CR99+CHSDPA

• CHSDPA is the minimum capacity reserved to the HSDPA traffic only if CR99 = Peak_R99_rate.

• The dimensioning should be done so that the air interface is the bottleneck => good HSDPA service. This means that the Iub should be able to transport the amount of data scheduled by the HSDPA flow control. In this way the AAL2 delays and drop rates will also be reduced

• As the Air interface rate can be very high in good radio conditions then the high peak rates should be considered together with the probability of ever achieving that rate in practice.• Supporting the radio rates with a certain probability e.g.

90% should be enough • Showcase sites make an exception here. They should be

dimensioned so that full peak UE rates are supported also in Iub.


Simple Iub dimensionning – Premium HSDPA Service -

Model the users of a Node B in the RAN module of the Calipran tool

Set the desired throughput quantile target (the lower the better quality, can be lower than shown) and the Max delay for the HSDPA AAL2 buffering

For peak rate set this to 0


Simple Iub dimensionning – Premium HSDPA Service

• Calculate and check the resultUL/DL

SharedHSDPAallocation

2.22 / 2.56 MbpsBTS

DRNC

B


Iub Dimensioning – Background HSDPA Service -

• Initial calculation idea, still some open questions.• Consider the previous case with just 1xE1• 1xE1 = 1920 kbps for ATM

• - control plane 120 kbps• 1800 kbps left for User plane VCC

• In the average HSDPA can get the VCC bandwidth – the average R99 bandwidth.

• With low capacity Iub the Air IF could handle more traffic Flow control will be a problem unless the

SharedHSDPAFlowControlAllocation is set properly.• From the CAC capable tools we can see that

R99+CCCH needs to be roughly 1200 kbps for 50 AMR and 3 carriers.

• The mean traffic is about 850 kbps (Can we get this out of Calipran?)

• So the SharedHSDPAFlowControlAllocation should be around 950 kbps


RAN Dimensioning processTypically dimensioning for a RAN RFQ includes following four

steps:

1. Traffic engineering• Operator usually defines a traffic mix with QoS targets Estimated simultaneous # connections per bearer/service type

2. BTS configurations• Number of BTSs is usually given by the operator, but some BTSs

can be added during the dimensioning due to capacity reasons, if the traffic volumes are very high and the number of carriers/cell is limited.

Carrier configuration (1+1+1, 2+2+2, 3+3+3 or etc.) WSPC configuration (WSPCs for HSDPA, CCH and DCH)

3. Iub configurations• Number of BTSs, carrier configuration and simultaneous #

connections per bearer needed as an input. # E1 per BTS

4. RNC configurations• Iub results needed as an input.• Operator usually defines the BTSs or areas that should be covered

by one RNC location. # RNC and configurations


WSPC capacity calculationsWSPC capacity:

• HSDPA with 5 HS-PDSCH codes:• 16 HSDPA users (16 uplink HS-DPCCHs and 3.6 Mbit HSDPA downlink) • 30 DCHs at 16 kbit/s OR 14 DCHs + common channels

• HSDPA with 10 and 15 HS-PDSCH codes:• 16 HSDPA users (16 uplink HS-DPCCHs and 7.2 Mbit HSDPA downlink)

• Use following method to calculate needed processing capacity:• Calculate DL CEs = Rel99 traffic DL CEs + associated DL DCH CEs• Calculate UL CEs = Rel99 traffic UL CEs + associated UL DCH CEs• Select bigger one of DL CEs / UL CEs and add CEs for CCHs• Add required HSDPA CEs (min. 34, max. 3*64)

• Associated DL DCH (3.4 kbit/s SRB) takes capacity of one CE per HSDPA user.

• Associated UL DCH takes capacity related to its data rate: 4/4/16 CEs per user for data rates 64/128/384kbps.


WSPC capacity, example

INPUTS:If the Rel99 traffic requires 30 CE in DL and 20 in UL

(SHO OH included). The average number of HSDPA users is assumed to be

5 and associated UL traffic is carried on 64kbps bearer.

One WSPC card is allocated for HSDPA. BTS configuration is 1+1+1.

• RESULT:• DL CEs = 30 +5 and UL CEs= 20+4*5=40

• Total CEs for traffic + CCHs = 40 +16 =56

• HSDPA takes 34 CEs, so totally we need capacity of 56+34=90 CEs.

• For this capacity two WSPC cards is required (or WSPC + WSPA/D).


RNC dimensioning Constraints introduced by HSDPA

• New constraints have been added to current ones for the capacity requirements for HSDPA Data Solution:

[1] When no other service in any other transport channel than User Plane PS data on HSDPA is supported, except common channels.

* Subject to change when RAN5.1 is finalized

RAN05: RN2.1/A4.2

RAN05.1: RN2.2/A4.2

Number of simultaneous HSDPA active WBTSs

288 250*

Number of simultaneous HSDPA active cells

3*288 750*

HSDPA throughput on Iu [1]

100 Mbit/s 160 Mbit/s*

Maximum HSDPA data rate for one cell/BTS

1.8 Mbit/s 3.6 Mbits/s*

HSDPA RABs/BTS 16 32 (16/cell)*


RNC dimensioning DMPG Pooling

• The DMCU units reserved for HSDPA are selected by the operator.

• The maximum number of DMPGs reserved for HSDPA users in RNC configuration is now 48, but may still change.

• 4 DMPGs per DMCU unit

• The operator can freely reserve for HSDPA DMCUs in subracks 3 and 4 or DMPGs in all the subracks with DMCUs.

• Rule of thumb:

• 6 HSDPA-active WBTS/DMPG or

• 16 users/DMPG• So if there are only a few WBTS that are enabled for HSDPA, it is not necessary to use the entire DMCU pool


RNC Traffic capacity

• DMCU allocation has a linear relation to RNC traffic capacity

HSDPA BTS

step 1 step 2 step 3 step 4 step 5

Number of subscribers 73000 130000 186000 240000 300000 RNC Capacity without HSDPA

Busy Hour Call Attempts 40500 81500 122000 163000 204000

Erlangs 1300 2700 4000 5400 6800

Throughput Mbits/sec 48 85 122 159 196

Number of carriers 384 576 768 960 1152

Number of BTS 128 192 256 320 384

Max HSDPA Mbit/s 16 33 50 75 100 RNC Capacity with HSDPA

Erlangs 700 1400 2100 2700 3300

Non-HSDPA throughput Mbits/sec 26 45 64 79 95

40 80 125 185 250

Max HSDPA pool size (DMCU units) 2 4 6 9 12

DCH_pool_factor 0.83 0.80 0.79 0.75 0.73

DMCU units 12 20 28 36 44

Service Max traffic, no HSDPA pool

Max traffic, HSDPA pool

AMR 6800 Erl 6800*DCH_pool_factor

CS Video 196 Mbps 196*DCH_pool_factor

PS NRT 196 Mbps 196*DCH_pool_factor

DCH_pool_factor: DCH_Pool_Factor =

1 - DMCU_units_in_HSDPA_pool /

max_DMCU_units_in_RNC


Common HSDPA&DCH load factor

• The RNC traffic capacity for RNC Configuration 5 can be calculated followingly:

• [1] DCH_Pool_Factor = 1 - DMCU_units_in_HSDPA_pool / max_DMCU_units_in_RNC

• [2] HSDPA_Pool_Factor = DMCU_units_in_HSDPA_pool / max_DMCU_units_in_HSDPA_pool

• [3] max_DMCU_units_in_HSDPA_pool is 12• [4] non_HSDPA_load_index = AMR/(DCH_Pool_factor * 6800) +

CS_data/(DCH_Pool_factor * 196) + other_PS/(DCH_Pool_factor * 196) ≤ 1

• [5] HSDPA ≤ HSDPA_Pool_Factor * 100 Mbps• [6] 0.6 * HSDPA/(HSDPA_Pool_Factor * 100) + 0.6 *

non_HSDPA_load_index ≤ 1

• So in [4] the throughput of the DCHs in RNC is downgraded in relation to the DMCU units remaining outside the HSDPA pool.

• [6] is stating that the HSDPA and DCH throughput should not peak at the same time. The reason is that there are common resources for these services in the RNC and those can not handle the (DMCU adjusted) peak load in both HSDPA and DCH simultaneously.


HSDPA & DCH Combined RNC Load

•[1] DCH_Pool_Factor = 1 - DMCU_units_in_HSDPA_pool / max_DMCU_units_in_RNC•[2] HSDPA_Pool_Factor = DMCU_units_in_HSDPA_pool / max_DMCU_units_in_HSDPA_pool•[3] max_DMCU_units_in_HSDPA_pool is 12•[4] non_HSDPA_load_index = AMR/(DCH_Pool_factor * 6800) + CS_data/(DCH_Pool_factor * 196) + other_PS/(DCH_Pool_factor * 196) ≤ 1•[5] HSDPA ≤ HSDPA_Pool_Factor * 100 Mbps•[6] 0.6 * HSDPA/(HSDPA_Pool_Factor * 100) + 0.6 * non_HSDPA_load_index ≤ 1

HSDPA DCHNumber of DMCU in pool 11 33Max number of DMCU 12 44Pool Factor 92 % 75 %

HSDPA LoadMbps

R99 DCH LoadMbps

Traffic load at RNC 76 98RNC Limit 100 196Pool Factor 92 % 75 %Adjusted limit 91,7 147,0Load 83 % 67 %Combined Load Factor 90 %

[6]

Config5 RNC with 98 Mbps DCH and76 Mbps HSDPA Traffic load


RNC Connectivity

• AAL2 connectivity limit for one RNC is 1000 Mbps. • This does not reflect the maximum traffic but rather the

physical connections. • For example, 150 BTSs with 3 * E1UP VCC each will

consume

1.92 Mbps*3*150=855 Mbps worth of connectivity capacity, leaving 145 Mbps to be shared between Iu CS and Iur.

• A common estimate for Iu CS requirement is 50-100 Mbps. Iur is estimated to be about 8% of the traffic, meaning about 0.08*196 Mbps=16 Mbps.

• Iu-PS interface does not consume AAL2 capacity• If Iub is dimensioned according to the air

interface peak rate then the connectivity will

likely be a limiting factor.

Capacity Step

AAL2 conn. Limit (Mbps)

1 600

2 700

3 800

4 900

5 1000


BTS CAC

There is a BTS CAC for each RAN release:

RAN 1.5 ED2: SCR4.0PCR6.0VCCcapacity

RAN04 without AXUB (no AAM):

SCR4.0PCR6.0VCCcapacity

RAN04 with AXUB (AAM enabled):

25000SCR8.0PCR2.0VCCcapacity

RAN05: 25000SCR8.0PCR2.0VCCcapacity

If the HSDPA uplink channel is high capacity e. g. NRT384 then the uplink can be the dominating factor in the Iub capacity.

The capacity requirement for admission is set by the CAC at the BTS


References & Sources for Further Info

• Customer presentations, Nokia internal presentations, Publications and public presentations, Nokia intranet links, Competitor and operator presentations at:

• http://www2.connecting.nokia.com/net/imn/roadmapp.nsf/document/es3363yd4t?opendocument&click=

• RAN05 and HSDPA in DocLib and NOLs• http://www10.connecting.nokia.com/net/nco/ran05.nsf/document/

es525up8pr?opendocument• Documents from RAN Dimensioning Forum at:

• http://www10.connecting.nokia.com/net/rn/wcdmaran.nsf/document/bce11d367b350a2ac2256ff50037a2fc?opendocument&click=

• RAN'05 reference page at:• http://www10.connecting.nokia.com/net/rn/wcdmaran.nsf/document/

es52696k26?opendocument• Slideset on RNC architecture in A4.2 and A4.3 at:

• http://www6.connecting.nokia.com/net/wabsspct.nsf/document/es385r3gj4?opendocument

• Some PL useful documents on TRS features with HSDPA at:• http://atmweb.ntc.nokia.com/twiki/bin/view/Hangzhou/IubEfficiencyTask?

skin=print