hsdpa dimensioning
DESCRIPTION
Document for HSDPA DimensioningTRANSCRIPT
1 © NOKIA FILENAMs.PPT/ DATE / NN
HSDPA Transmission Dimensioning Info Session
21.6. And 22.6.2005
2 © 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).
3 © NOKIA FILENAMs.PPT/ DATE / NN
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
4 © NOKIA FILENAMs.PPT/ DATE / NN
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
5 © NOKIA FILENAMs.PPT/ DATE / NN
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
1.8 Mbps1.8 Mbps 3.6 Mbps3.6 Mbps 5.4 Mbps5.4 Mbps
16QAM16QAM
2/42/4
3/43/4
4/44/4
2.4 Mbps2.4 Mbps 4.8 Mbps4.8 Mbps 7.2 Mbps7.2 Mbps
3.6 Mbps3.6 Mbps 7.2 Mbps7.2 Mbps 10.7 Mbps10.7 Mbps
4.8 Mbps4.8 Mbps 9.6 Mbps9.6 Mbps 14.4 Mbps14.4 Mbps
RAN05
RAN05.1
6 © 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
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.)
7 © NOKIA FILENAMs.PPT/ DATE / NN
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.
8 © NOKIA FILENAMs.PPT/ DATE / NN
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
9 © NOKIA FILENAMs.PPT/ DATE / NN
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
10 © 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.
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.
11 © NOKIA FILENAMs.PPT/ DATE / NN
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
12 © NOKIA FILENAMs.PPT/ DATE / NN
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
13 © NOKIA FILENAMs.PPT/ DATE / NN
Retransmissions in HSDPA
Server RNC Node-B
UE
RLC retransmissions
TCP retransmissions
MAC-hs Layer-1
retransmissions
14 © 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• 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
15 © NOKIA FILENAMs.PPT/ DATE / NN
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%
16 © NOKIA FILENAMs.PPT/ DATE / NN
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.
17 © NOKIA FILENAMs.PPT/ DATE / NN
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)
18 © NOKIA FILENAMs.PPT/ DATE / NN
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
19 © NOKIA FILENAMs.PPT/ DATE / NN
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
20 © NOKIA FILENAMs.PPT/ DATE / NN
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 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
MinimumRequiredSharedHSDPAallocation
t1 t2
RAN5.1
t3
21 © NOKIA FILENAMs.PPT/ DATE / NN
Time
VCC capacity
R99 DCH rate
Maximum bandwidth for the HSDPA traffic
SharedHSDPAFlowControlAllocation
Shared HSDPAallocation
• 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
22 © NOKIA FILENAMs.PPT/ DATE / NN
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
23 © 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:
– 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
24 © NOKIA FILENAMs.PPT/ DATE / NN
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
25 © NOKIA FILENAMs.PPT/ DATE / NN
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)
26 © NOKIA FILENAMs.PPT/ DATE / NN
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
27 © NOKIA FILENAMs.PPT/ DATE / NN
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
28 © NOKIA FILENAMs.PPT/ DATE / NN
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
29 © NOKIA FILENAMs.PPT/ DATE / NN
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=1.777 Mbps
VCC Capacity=2 Mbps
VCC Capacity=2.5 Mbps
VCC Capacity=3 Mbps
VCC Capacity=3.5 Mbps
30 © NOKIA FILENAMs.PPT/ DATE / NN
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
31 © NOKIA FILENAMs.PPT/ DATE / NN
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
32 © NOKIA FILENAMs.PPT/ DATE / NN
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
33 © NOKIA FILENAMs.PPT/ DATE / NN
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.
34 © 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,• 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
35 © NOKIA FILENAMs.PPT/ DATE / NN
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
36 © 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 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
37 © 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 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.
38 © 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.
39 © 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
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
40 © NOKIA FILENAMs.PPT/ DATE / NN
Simple Iub dimensionning – Premium HSDPA Service
• Calculate and check the resultUL/DL
SharedHSDPAallocation
2.22 / 2.56 MbpsBTS
DRNC
B
41 © 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
• - 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
42 © NOKIA FILENAMs.PPT/ DATE / NN
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
43 © NOKIA FILENAMs.PPT/ DATE / NN
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.
44 © 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).
45 © 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:
[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)*
46 © 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
47 © NOKIA FILENAMs.PPT/ DATE / NN
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
48 © NOKIA FILENAMs.PPT/ DATE / NN
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.
49 © NOKIA FILENAMs.PPT/ DATE / NN
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
50 © NOKIA 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.
• 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
51 © NOKIA FILENAMs.PPT/ DATE / NN
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
52 © 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/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