You are on page 1of 52

HSDPA Transmission Dimensioning Info Session

21.6. And 22.6.2005

NOKIA

FILENAMs.PPT/ DATE / NN

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).
2 NOKIA FILENAMs.PPT/ DATE / NN

RAN releases: HSDPA roadmap


HSDPA early (lab) trials with selected customers
HSDPA trials

3/05 E4 11/05 E1 E5 2/06 E4 5/06

RAN05

E1 2/04

RAN05.1

4/05

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

2H03

2004

2005

2006

For information, roadmap reference always from RAN marketing Strictly internal
3 NOKIA FILENAMs.PPT/ DATE / NN

HSDPA General principle


Channel quality information

Error correction Ack/Nack


L1 Feedback 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) Data QPSK (RAN05) or 16QAM modulation

Terminal 1 (UE)
L1 Feedback UL Channel is a R99 DCH No SHO on downlink

User may be time and/or code multiplexed.

Terminal 2
4 NOKIA FILENAMs.PPT/ DATE / NN

HSDPA Peak Bit Rates


Coding rate Coding rate 1/4 QPSK 2/4 3/4 2/4 16QAM 3/4 4/4 5 codes 600 kbps 1.2 Mbps 1.8 Mbps 2.4 Mbps 3.6 Mbps 4.8 Mbps 10 codes 1.2 Mbps 2.4 Mbps 3.6 Mbps 4.8 Mbps 7.2 Mbps 9.6 Mbps 15 codes 1.8 Mbps 3.6 Mbps 5.4 Mbps 7.2 Mbps 10.7 Mbps 14.4 Mbps

RAN05 RAN05.1
5 NOKIA FILENAMs.PPT/ DATE / NN

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
HSDPA Category 11 12 Modulation QPSK only QPSK only
QPSK/16QAM QPSK/16QAM QPSK/16QAM QPSK/16QAM QPSK/16QAM

Inter-TTI 2 1

Transport 5 Codes Block size 3630 3630


0.9 Mbps 1.8 Mbps 1.2 Mbps 1.8 Mbps 3.6 Mbps

10 Codes -

15 Codes -

1/2
3/4 5/6 7/8

3
2 1 1 1

7298
7298 7298 14411 20251

7.2 Mbps -

9
10

10.1 Mbps
14.0 Mbps

QPSK/16QAM

27952

(First one has smaller HARQ memory.)


6 NOKIA FILENAMs.PPT/ DATE / NN

HSDPA Cell throughput


Simulated cell throughput with mixed HSDPA and Rel.99 traffic. 5 codes assumed.
1090 kbps Pedestrian propagation 43% Gain channel. 780 kbps

1320 kbps
21% Gain

HSDPA: N.A.
DCH: 780 kbps No HSDPA
7 NOKIA FILENAMs.PPT/ DATE / NN

HSDPA: 670 kbps DCH: 410 kbps HSDPA 16QAM RR scheduling

HSDPA: 910 kbps

DCH: 410 kbps


HSDPA 16QAM PF scheduling

Main HSDPA features


RAN05 PS interactive and background traffic classes QPSK modulation Max. 5 HS-PDSCH codes No code multiplexing on HSPDSCH 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 Node B requires WN3.0
8 NOKIA FILENAMs.PPT/ DATE / NN

RAN05.1 PS interactive and background traffic classes 16QAM modulation Max. 5 HS-PDSCH codes No code multiplexing on HSPDSCH 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

HSDPA BTS Configuration in RAN05


WSPC with HSDPA SW card required
4 users

All BTS models/configurations, that can accommodate at least one WSPC, support HSDPA. One WSPC unit supports max. 3 HSDPA cells.

8 users

4 users

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 users Note 1: The actual amount of supported HSDPA -> Max. three HSDPA on usedin BTS. channel per WSPC depends heavily cells Uplink DCH
speed associated with HSDPA user, see dimensioning rules RAN05.1: max. 3 HSDPA WSPCs in BTS

NOKIA

FILENAMs.PPT/ DATE / NN

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.
10 NOKIA FILENAMs.PPT/ DATE / NN

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.

RNC with HSDPA will composed of two resource pools (user plane)
1. 2.

HSDPA solution in RNC (RN2.1 configuration)

RNC rel99/04/(05) pool 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 11 NOKIA FILENAMs.PPT/ DATE / NN

HSDPA & Iub


HSDPA improves Iub efficiency compared to Release99 packet data since HSDPA is a time shared channel with a flow control in Iub Release99 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
1 1 2 2 = User 1 = User 2 = User 3
12 NOKIA FILENAMs.PPT/ DATE / NN

Iub link 1 Iub link 2

HSDPA Iub capacity

1 = TCP slow start 2 = Inactivity timer

Iub efficiently utilized by HSDPA

Retransmissions in HSDPA
Server RNC Node-B
MAC-hs Layer-1 retransmissions

TCP retransmissions RLC retransmissions

UE

13

NOKIA

FILENAMs.PPT/ DATE / NN

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 RLC traffic volume measurement; MAC-d transport Channel type switching; HSciphering for transparent mode RLC MAC-hs

MAC-d flow

Mac-hs is responsible for:



14

HSDSCH MAC-hs DSCH FP PHY TNL Iub

RLC MAC-d HSDSCH FP TNL RNC

Packet scheduling Link adaptation UE L1 error correction and retransmissions (H-ARQ) Flow control between RNC and BTS

PHY

HSPDSCH

Uu

BTS

This does not take AAL2 congestion into account


FILENAMs.PPT/ DATE / NN

NOKIA

HSDPA Protocol Model and Iub Overheads


RLC MAC-d MAC-hs
HS-DSCH MAC-d flow

RLC HSDSCH FP AAL2 PHY ATM PDH/SD H BTS Iub MAC-d HSDSCH FP AAL2 ATM PDH/SD H RNC

RLC Overhead 2 bytes added to 40 bytes segment MAC-d N/A HS-DSCH FP Overhead: For N x 42 bytes payload 7 byte header + 2 byte CRC AAL2 Overhead 3 bytes /packet (max 45 bytes) ATM Overhead 5/53 (6/53 for AAL2) PDH Overhead 2/32

MAC-hs

HSPDSCH

PHY

UE

Uu

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%
15 NOKIA FILENAMs.PPT/ DATE / NN

Transport network with HSDPA


MAC-d flows RT/NRT DCH connections AAL2 SDUs
CID=x CID=y

CPS-Packets Low priority buffer: maximum 7000 CPS-Packets default 2048

Segmentatio CID=z CID= n w & encapsulatio n

High priority buffer: 256 CPS-Packets


SP S
Assembly & transmission

Source

ATM cells CBR VCC

Destinatio n
CPSPackets

AAL2 DEMUX
CID=x CID=y CID=z CID= w

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

Reassembly AAL2 SDUs


16 NOKIA FILENAMs.PPT/ DATE / NN

Definition of the HSDPA parameters


SharedHSDPAallocation Defines the size of the shared HSDPA AAL2 Allocation in kilobits/s. This should be equal or greater than the MinimumRequiredSharedHSDPAallocation 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

NbrOfOverbookedHSDPAUsers
Defines 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 method


Defines 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 VCCs 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)
17 NOKIA FILENAMs.PPT/ DATE / NN

Available bandwidth for the HSDPA traffic SharedHSDPAallocation


VCC capacity Peak R99 DCH rate R99 DCH rate Available bandwidth for HSDPA Tim e VCC capacity SharedHSDPAallocation

Peak R99 DCH rate < VCC capacity

VCC Capacity- R99 DCH peak rate

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 18 NOKIA from the FILENAMs.PPT/ DATE / NN CAC

Available bandwidth for the HSDPA traffic


MinimumRequiredSharedHSDPAallocation
VCC capacity

RAN05

Shared HSDPAallocation

R99 DCH rate


t1 t2 t3

Tim e

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
19 NOKIA FILENAMs.PPT/ DATE / NN

Available bandwidth for the HSDPA traffic


MinimumRequiredSharedHSDPAallocation
Shared HSDPAallocation

RAN5.1

VCC capacity
t1 t2 t3

R99 DCH rate

MinimumRequiredSharedHSDPAallocation Tim e

20

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. FILENAMs.PPT/ DATE / NN NOKIAt3 the reservation reaches SharedHSDPAallocation and is no longer At

Maximum bandwidth for the HSDPA traffic


SharedHSDPAFlowControlAllocation
VCC capacity

Shared HSDPAallocation

SharedHSDPAFlowControlAllocation

R99 DCH rate

Tim e

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

21

NOKIA

FILENAMs.PPT/ DATE / NN

Simulation results
HSDPA sources (TCP) RT sources (AMR 12.2 + DCCH)

RNC

CBR VCC

BTS

Air interface Destination (sink)

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

22

NOKIA

FILENAMs.PPT/ DATE / NN

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:


23 NOKIA

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

FILENAMs.PPT/ DATE / NN

Simulation1: Performance in function of VCC capacity & AAL2 low priority buffer size
Traffic mix is static:
1. 2. 3. 4.

12 www (HSDPA) low priority AAL2 buffer 4 ftp (HSDPA) low priority AAL2 buffer 50 AMR 12.2 kbps high priority AAL2 buffer 66 DCCH high priority AAL2 buffer

Low priority AAL2 buffer: 2048, 4096 CPS Packets


SharedHSDPAallocation Required for the high priority traffic VCC Capacity [Mbps] [Mbps] [Mbps] 0.223 1.277 1.500 0.500 0.500 1.777 0.723 0.723 2.000 1.223 1.223 2.500 1.723 1.723 3.000 2.223 2.223 3.500 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
24 NOKIA FILENAMs.PPT/ DATE / NN

Simulation1: Bandwidth share


3500 3000

2500
Bandwidth [kbps]

2000 Average bandwidth used by the HSDPA traffic

1500

Available bandwidth (VCC capacity)

1000

500

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

0 1 1.5 2 2.5 VCC Capacity [Mbps] 3 3.5

25

NOKIA

FILENAMs.PPT/ DATE / NN

Simulation1: Drop probability at the low priority AAL2 buffer


40 35
Buffer=2048 Buffer=4096

30
Drop probability [%]

25

20

15

10

0 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]

26

NOKIA

FILENAMs.PPT/ DATE / NN

Simulation1: RLC retransmissions


60 Buffer = 2048 Buffer = 4096

50

Retransmitted RLC-PDUs [%]

40

30

20

10

0 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]

27

NOKIA

FILENAMs.PPT/ DATE / NN

Simulation1: Mean TCP throughput


1100 Buffer = 2048 Buffer = 4096

1000

900

TCP throughput [kbps]

800

700

600

500

400

300

200 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]

28

NOKIA

FILENAMs.PPT/ DATE / NN

Simulation1: Air interface throughput


1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 0 200 400 600 800 1000 1200 1400 1600 1800 Air interface throughput [kbps] VCC Capacity=1.5 Mbps VCC Capacity=1.777 Mbps VCC Capacity=2 Mbps VCC Capacity=2.5 Mbps VCC Capacity=3 Mbps VCC Capacity=3.5 Mbps

29

NOKIA

FILENAMs.PPT/ DATE / NN

Probability

Simulation2: Performance in function of rate control & low VCC capacity


Traffic mix is static:
1. 2. 3. 4.

12 www (HSDPA) low priority AAL2 buffer 4 ftp (HSDPA) low priority AAL2 buffer 50 AMR 12.2 kbps high priority AAL2 buffer 66 DCCH high priority AAL2 buffer

Low priority AAL2 buffer: 2048 CPS Packets VCC capacity: 2 Mbps (SharedHSDPAallocation: 0.723 Mbps) Four simulations by setting SharedHSDPAFlowControlAllocation:
1. 2. 3. 4.

Based on the SharedHSDPAallocation parameter (Dummy rate): 588 kbps Based on the mean rate of the high priority traffic (Mean rate): 842 kbps Based on the VCC capacity (VCC rate): 1628 kbps No rate control

30

NOKIA

FILENAMs.PPT/ DATE / NN

Simulation2: TCP performance


Dummy rate Mean rate VCC rate TCP throughput (total) [kbps] Mean TCP connection setup time [s] Mean page download rate [kbps]
90
Dummy rate Mean rate VCC rate No rate control

402.860 0.2399 37.512

691.440 0.1145 85.099

574.956 0.9345 48.782

No rate control 582.322 0.8303 67.045

80 70

60 50 40 30

cwnd

20 10

0 0 100 200 300 Time [s] 400 500 600

31

NOKIA

FILENAMs.PPT/ DATE / NN

Simulation2: Air interface throughput


1 0.9 0.8 0.7 0.6

Dummy rate Mean rate VCC rate No rate control

Probability

0.5 0.4 0.3 0.2 0.1 0 0 200 400 600 800 1000 1200 1400 1600 1800 Air interface throughput [kbps]

Dummy rate Mean rate VCC rate


Air interface throughput (total) [kbps]
32 NOKIA FILENAMs.PPT/ DATE / NN

418.952

723.652

813.822

No rate control 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) 33 NOKIA FILENAMs.PPT/ DATE / NN

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, Affected by the Open Iub in RAN05 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.
FILENAMs.PPT/ DATE / NN

34

NOKIA

Iub Dimensioning
Iub 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 RAN05.
Nokia Iub vs open Iub kbps UL
60.0 50.0 40.0 30.0 20.0

Nokia Iub C-NBAP kbps UL Nokia Iub D-NBAP kbps UL Open Iub C-NBAP kbps UL

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

10.0 0.0 2005 2006 2007 2008 2009 2010 1+1+1, 1+1+1, 1+1+1, 1+1+1, 1+1+1, 1+1+1, 3*WSPC 3*WSPC 3*WSPC 3*WSPC 3*WSPC 3*WSPC

Open Iub D-NBAP kbps UL

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
35 NOKIA FILENAMs.PPT/ DATE / NN

The Iub dimensioning problem


Define the VCC capacity which guarantees:

1. The QoS requirements for R99 traffic (maximum allowed delay and prob 2. Good enough HSDPA end user service 3. Low AAL2 delay In practice this means the definition of the following parameters: 1. VCC capacity 2. SharedHSDPAallocation 3. SharedHSDPAFlowControlAllocation OR 1. VCC capacity 2. SharedHSDPAallocation 3. SharedHSDPAFlowControlAllocation
Background HSDPA Service: Find out the R99 needs and minimise The damage for HSDPA Premium HSDPA service: Find out what the HSDPA needs.

36

NOKIA

FILENAMs.PPT/ DATE / NN

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 high priority traffic.

Once admitted, the R99 connections are not restricted to this capacity, they will use whole VCC capacity. This also means better service for the R99. Inputs: 1. Traffic mix 2. QoS requirements e.g. max delay=10ms & probability=0.001 Algorithm: CAC.

37

NOKIA

FILENAMs.PPT/ DATE / NN

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.

38

NOKIA

FILENAMs.PPT/ DATE / NN

Simple Iub dimensionning


Premium HSDPA Service Model the users of a Node B in the RAN module of the Calipran tool For peak rate set this to 0

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
39 NOKIA FILENAMs.PPT/ DATE / NN

Simple Iub dimensionning Premium HSDPA Service


Calculate and check the result
UL/DL

SharedHSDPAallocation

40

NOKIA

FILENAMs.PPT/ DATE / NN

Iub Dimensioning
Background HSDPA Service -

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

In the average HSDPA can get the VCC bandwidth the average R99 bandwidth. With low capacity Iub the Air IF could handle more traffic

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

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
FILENAMs.PPT/ DATE / NN

41

NOKIA

RAN Dimensioning process


Typically 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
42 NOKIA FILENAMs.PPT/ DATE / NN

WSPC capacity calculations


WSPC 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 16 HSDPA users (16 uplink HS-DPCCHs and 7.2 Mbit HSDPA downlink)

HSDPA with 10 and 15 HS-PDSCH codes:

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.

43

NOKIA

FILENAMs.PPT/ DATE / NN

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

44

NOKIA

FILENAMs.PPT/ DATE / NN

RNC dimensioning
Constraints introduced by HSDPA
New constraints have been added to current ones for the capacity requirements for HSDPA Data Solution: RAN05: RN2.1/A4.2 288 RAN05.1: RN2.2/A4.2 250*

Number of simultaneous HSDPA active WBTSs Number of simultaneous HSDPA active cells HSDPA throughput on Iu [1] Maximum HSDPA data rate for one cell/BTS HSDPA RABs/BTS

3*288
100 Mbit/s 1.8 Mbit/s 16

750*
160 Mbit/s* 3.6 Mbits/s* 32 (16/cell)*

[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


45 NOKIA FILENAMs.PPT/ DATE / NN

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
46 NOKIA FILENAMs.PPT/ DATE / NN

RNC Traffic capacity


DMCU allocation has a linear relation to RNC traffic capacity
step 1 Number of subscribers Busy Hour Call Attempts Erlangs Throughput Mbits/sec Number of carriers Number of BTS Max HSDPA Mbit/s Erlangs Non-HSDPA throughput Mbits/sec HSDPA BTS Max HSDPA pool size (DMCU units) DCH_pool_factor DMCU units 73000 40500 1300 48 384 128 16 700 26 40 2 0.83 12 step 2 130000 81500 2700 85 576 192 33 1400 45 80 4 0.80 20 step 3 186000 122000 4000 122 768 256 50 2100 64 125 6 0.79 28 step 4 240000 163000 5400 159 960 320 75 2700 79 185 9 0.75 36 step 5 300000 204000 6800 196 1152 384 100 3300 95 250 12 0.73 44 RNC Capacity with HSDPA RNC Capacity without HSDPA

Max traffic, no HSDPA pool AMR 6800 Erl CS Video 196 Mbps PS NRT FILENAMs.PPT/ DATE / NN 196 Mbps 47 NOKIA

Service

Max traffic, HSDPA pool 6800*DCH_pool_factor 196*DCH_pool_factor 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.
48 NOKIA FILENAMs.PPT/ DATE / NN

HSDPA & DCH Combined RNC Load


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

Traffic load at RNC RNC Limit Pool Factor Adjusted limit Load Combined Load Factor
[1] [2] [3] [4] [5] [6]
49 NOKIA

HSDPA Load R99 DCH Load Mbps Mbps 76 98 100 196 92 % 75 % 91,7 147,0 83 % 67 % 90 %

Config5 RNC with 98 Mbps DCH and 76 Mbps HSDPA Traffic load

[6]

DCH_Pool_Factor = 1 - DMCU_units_in_HSDPA_pool / max_DMCU_units_in_RNC HSDPA_Pool_Factor = DMCU_units_in_HSDPA_pool / max_DMCU_units_in_HSDPA_pool max_DMCU_units_in_HSDPA_pool is 12

non_HSDPA_load_index = AMR/(DCH_Pool_factor * 6800) + CS_data/(DCH_Pool_factor * 196) + other_PS/(DCH_Pool_factor * 196) 1 HSDPA HSDPA_Pool_Factor * 100 Mbps 0.6 * HSDPA/(HSDPA_Pool_Factor * 100) + 0.6 * non_HSDPA_load_index 1
FILENAMs.PPT/ DATE / NN

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. Capacity AAL2 conn. Step Limit (Mbps) Iu-PS interface does not consume AAL2 capacity 1 600 If Iub is dimensioned according to the air 2 700 interface peak rate then the connectivity will 3 800 4 900 likely be a limiting factor.
5
50 NOKIA FILENAMs.PPT/ DATE / NN

1000

BTS CAC
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

There is a BTS CAC for each RAN release: RAN 1.5 ED2:

VCC capacity 0.6 PCR 0.4 SCR VCC capacity 0.6 PCR 0.4 SCR VCC capacity 0.2 PCR 0.8 SCR 25000 VCC capacity 0.2 PCR 0.8 SCR 25000

RAN04 without AXUB (no AAM): RAN04 with AXUB (AAM enabled): RAN05:
51 NOKIA

FILENAMs.PPT/ DATE / NN

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/es3 363yd4t?opendocument&click= RAN05 and HSDPA in DocLib and NOLs http://www10.connecting.nokia.com/net/nco/ran05.nsf/document/es525u p8pr?opendocument Documents from RAN Dimensioning Forum at: http://www10.connecting.nokia.com/net/rn/wcdmaran.nsf/document/bce 11d367b350a2ac2256ff50037a2fc?opendocument&click= RAN'05 reference page at: http://www10.connecting.nokia.com/net/rn/wcdmaran.nsf/document/es5 2696k26?opendocument Slideset on RNC architecture in A4.2 and A4.3 at: http://www6.connecting.nokia.com/net/wabsspct.nsf/document/es385r3g j4?opendocument Some PL useful documents on TRS features with HSDPA at: http://atmweb.ntc.nokia.com/twiki/bin/view/Hangzhou/IubEfficiencyTask? NOKIA FILENAMs.PPT/ skin=print DATE / NN

52

You might also like