Professional Documents
Culture Documents
NOKIA
FILENAMs.PPT/ DATE / NN
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
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
Terminal 2
4 NOKIA FILENAMs.PPT/ DATE / NN
RAN05 RAN05.1
5 NOKIA FILENAMs.PPT/ DATE / NN
UE categories
12 different UE categories
Inter-TTI 2 1
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
1320 kbps
21% Gain
HSDPA: N.A.
DCH: 780 kbps No HSDPA
7 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
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
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.
RNC rel99/04/(05) pool supports all features and interfaces that has been define in RN2.1 solution
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
Retransmissions in HSDPA
Server RNC Node-B
MAC-hs Layer-1 retransmissions
UE
13
NOKIA
FILENAMs.PPT/ DATE / NN
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
Packet scheduling Link adaptation UE L1 error correction and retransmissions (H-ARQ) Flow control between RNC and BTS
PHY
HSPDSCH
Uu
BTS
NOKIA
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
Source
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.
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)
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
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
RAN05
Shared HSDPAallocation
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
RAN5.1
VCC capacity
t1 t2 t3
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
Shared HSDPAallocation
SharedHSDPAFlowControlAllocation
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
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
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
2500
Bandwidth [kbps]
1500
1000
500
25
NOKIA
FILENAMs.PPT/ DATE / NN
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
50
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
1000
900
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
29
NOKIA
FILENAMs.PPT/ DATE / NN
Probability
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
80 70
60 50 40 30
cwnd
20 10
31
NOKIA
FILENAMs.PPT/ DATE / NN
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]
418.952
723.652
813.822
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
2.
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
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
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
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
38
NOKIA
FILENAMs.PPT/ DATE / NN
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
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
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
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)
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
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.
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.
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
Max traffic, no HSDPA pool AMR 6800 Erl CS Video 196 Mbps PS NRT FILENAMs.PPT/ DATE / NN 196 Mbps 47 NOKIA
Service
[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
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]
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
52