You are on page 1of 35

HSDPA Training 3.

HSDPA Architecture and Functional Split


by Jeroen Wigard et all.

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Agenda
HSDPA Logical Split & Responsibilities Quality of Service in HSDPA Measurements and UE capabilities Flow Control RRM in the RNC QoS Summary & TCP results RRM in RAN05

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Logical Split & Responsibilities

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Packet Domain Logical Architecture


SMS-GMSC SMS-IWMSC E Gd MSC/VLR HLR Gs Iu UTRAN Gb TE R MT Um SGSN BSS Gn Gp CGF GGSN Other PLMN Signalling Interface Signalling and Data Transfer Interface COMPANY CONFIDENTIAL Gf EIR SGSN Gn Ga
D

SM-SC C

The subject of The subject of this course this course

A R TE MT

Iu Uu

Gr

Gc Gi GGSN Ga Billing System PDN TE

NOKIA 2004

HSDPA, June 2004.

UTRAN Architecture
Uu

Node B Node B USIM USIM


Cu

RNS

Iu CS

Node B Node B
Iub

RNC RNC
Iur

MSC/ MSC/ VLR VLR

ME ME
UE

Node B Node B

RNC
RNS
Iu PS

SGSN SGSN
CN

UTRAN

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

HS-DSCH Protocol Model (1/2)


In this case the CRNC and MAC-d MAC-d SRNC are coincident. The High Speed MAC- HSMAC-hs HS-DSCHFP hs DSCHFP MAC (MAC-hs) entity in the PHY PHY TNL TNL Node B transfers MAC-hs PDU to the peer MAC-hs Uu UE NodeB CRNC/SRNC Iub entity in the UE over the Uu (air) interface. The Dedicated MAC (MAC-d) entity in the RNC transfers MAC-d PDUs to the MAC-hs in the Node B using the services of the HS-DSCH Frame Protocol (HS-DSCH FP) entity. A Relaying Function in the Node B relays the HS-DSCH frame received by HS-DSCH FP entity to the MAC-hs entity. HS-DSCH scheduling is performed by MAC-hs in the Node B. For the first Nokia HSDPA release, no HSDPA Iur support is given, so the SRNC and CRNC are always co-incident.
6 NOKIA 2004 HSDPA, June 2004.

DTCH DCCH

DCCH

DTCH

COMPANY CONFIDENTIAL

HS-DSCH Protocol Model (2/2)


In these cases TNL TNL DCCH DTCH the SRNC DTCH DCCH and CRNC CRNC MAC-d MAC-d are separated. Option a CRNC HS-DSCH In option a Flow Control HSHSMACHSHSMAC-hs Iur HS-DSCH DSCHFP DSCHFP hs DSCHFP DSCHFP Frame Protocol PHY PHY TNL TNL is used to TNL TNL interwork the UE Uu Flow Control Iub Iur NodeB SRNC CRNC function at the Controlling RNC with the MAC-d at the Serving RNC. In option b the SRNC is in control with the CRNC being bypassed, so the MAC-d in SRNC is located directly above MAC-hs in Node B, i.e. in the HS-DSCH user plane the SRNC is directly connected to the Node B.
COMPANY CONFIDENTIAL

Option b

NOKIA 2004

HSDPA, June 2004.

HS-DSCH Protocol Model (2/2)


In these cases TNL TNL DCCH DTCH the SRNC DTCH DCCH and CRNC CRNC MAC-d MAC-d are separated. Option a CRNC HS-DSCH In option a Flow Control HSMACHSHSHSMAC-hs Iur HS-DSCH DSCHFP DSCHFP hs DSCHFP DSCHFP Frame Protocol PHY PHY TNL TNL is used to TNL TNL interwork the Uu UE Flow Control Iub NodeB Iur SRNC CRNC function at the Controlling RNC with the MAC-d at the Serving RNC. In option b the SRNC is in control with the CRNC being bypassed, so the MAC-d in SRNC is located directly above MAC-hs in Node B, i.e. in the HS-DSCH user plane the SRNC is directly connected to the Node B.
COMPANY CONFIDENTIAL

Option b

NOKIA 2004

HSDPA, June 2004.

Functional Split Overview


RNC Admission Admission Control Control Capacity request User data Resource Resource Allocation Allocation Node-B Flow Control Flow Control Data Buffer Data Buffer HSDPA resource HSDPA resource monitor unit monitor unit H-ARQ H-ARQ manager manager Uplink UE Uplink UE information information (HS-DPCCH) (HS-DPCCH) ACK/NACK CQI & ACK/NACK HS-DSCH Packet Packet Scheduler Scheduler HS-SCCH Node-B Node-B measurements measurements

Codes (and power)

QoS QoS control control

QoS settings QoS settings UE capabilities UE capabilities & state & state Link Link Adaptation Adaptation

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Decides whether a user is admitted or not. Located in CRNC RNC Admission Admission Control Control Capacity request User data Resource Resource Allocation Allocation

Functional Split Overview


Node-B Flow Control Flow Control Data Buffer Data Buffer HSDPA resource HSDPA resource monitor unit monitor unit H-ARQ H-ARQ manager manager Uplink UE Uplink UE information information (HS-DPCCH) (HS-DPCCH) ACK/NACK CQI & ACK/NACK HS-DSCH Packet Packet Scheduler Scheduler HS-SCCH Node-B Node-B measurements measurements

Codes (and power)

QoS QoS control control

QoS settings QoS settings UE capabilities UE capabilities & state & state Link Link Adaptation Adaptation

10

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Decides whether a user is admitted or not. Located in CRNC RNC Admission Admission Control Control Capacity request User data Resource Resource Allocation Allocation

Functional Split Overview


Node-B Flow Control Flow Control Data Buffer Data Buffer HSDPA resource HSDPA resource monitor unit monitor unit H-ARQ H-ARQ manager manager Uplink UE Uplink UE information information (HS-DPCCH) (HS-DPCCH) ACK/NACK CQI & ACK/NACK HS-DSCH Packet Packet Scheduler Scheduler HS-SCCH Node-B Node-B measurements measurements

Codes (and power)

QoS QoS control control Takes care of resource allocation for HSDPA. Located in CRNC

QoS settings QoS settings UE capabilities UE capabilities & state & state Link Link Adaptation Adaptation

11

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Decides whether a user is admitted or not. Located in CRNC RNC Admission Admission Control takesrequest Capacity care of ControlQoS Control quality of service and UE capabilities User sends this and data information to the Node-B. Located in SRNC Resource Resource Allocation Allocation Codes (and power)

Functional Split Overview


Node-B Flow Control Flow Control Data Buffer Data Buffer HSDPA resource HSDPA resource monitor unit monitor unit H-ARQ H-ARQ manager manager Uplink UE Uplink UE information information (HS-DPCCH) (HS-DPCCH) ACK/NACK CQI & ACK/NACK HS-DSCH Packet Packet Scheduler Scheduler HS-SCCH Node-B Node-B measurements measurements

QoS QoS control control Takes care of resource allocation for HSDPA. Located in CRNC

QoS settings QoS settings UE capabilities UE capabilities & state & state Link Link Adaptation Adaptation

12

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Decides whether a user is admitted or not. Located in CRNC RNC Admission Admission Control takesrequest Capacity care of ControlQoS Control quality of service and UE capabilities User sends this and data information to the Node-B. Located in SRNC Resource Resource Allocation Allocation Codes (and power)

UE sends feedback Functional Split Overviewuplink information in (ACK/NACK & CQI) Node-B Flow Control Flow Control Data Buffer Data Buffer HSDPA resource HSDPA resource monitor unit monitor unit Uplink UE Uplink UE information information (HS-DPCCH) (HS-DPCCH) ACK/NACK CQI & ACK/NACK HS-DSCH Packet Packet Scheduler Scheduler HS-SCCH Node-B Node-B measurements measurements

H-ARQ H-ARQ manager manager

QoS QoS control control Takes care of resource allocation for HSDPA. Located in CRNC

QoS settings QoS settings UE capabilities UE capabilities & state & state Link Link Adaptation Adaptation

13

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Decides whether a user is admitted or not. Located in CRNC RNC Admission Admission Control takesrequest Capacity care of ControlQoS Control quality of service and UE capabilities User sends this and data information to the Node-B. Located in SRNC Resource Resource Allocation Allocation Codes (and power)

UE sends feedback Functional Split Overviewuplink information in (ACK/NACK & CQI) Node-B Flow Control Flow Control Data Buffer Data Buffer HSDPA resource HSDPA resource monitor unit monitor unit Uplink UE Uplink UE information information (HS-DPCCH) (HS-DPCCH) ACK/NACK CQI & ACK/NACK HS-DSCH Packet Packet Scheduler Scheduler HS-SCCH Node-B Node-B measurements measurements

H-ARQ H-ARQ manager manager

QoS QoS control control Takes care of resource allocation for HSDPA. Located in CRNC

QoS settings QoS settings UE capabilities UE capabilities & state & state Link Link Adaptation Adaptation

Total power used by the Node-B and power of the DPCH per UE

14

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Quality of Service (QoS)

15

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

3G QoS is an end-to-end issue


- but the radio access is the most important QoS domain The radio is the capacity limiting factor, since radio is a hostile medium for access.
RAN

If end-to-end QoS is to be guaranteed for the complete UTRAN architecture, all components must be specified to behave according to certain rules and have a certain well-defined responsibility. The rules should be configurable such that in the case of HSDPA, we can achieve a dynamic (e.g. time-varying depending on traffic) trade-off between tight QoS control and high system capacity.

RAN

Quality of Service : the collective effect of service performances that determine the degree of satisfaction of a user of a service.
16 NOKIA 2004 HSDPA, June 2004.

COMPANY CONFIDENTIAL

3GPP R99/R4/R5 QoS Model


Traffic Class Example applications Voice call Video call Streaming video Streaming audio Web/WAP browsing E-commerce Server access File download Mail download SMS/MMS Traffic characteristics Conversational pattern: stringent and low delay Minimize delay variation Real-time traffic Minimize delay variation Real-time traffic Request response pattern Minimize bit error rate Non real-time Destination is not expecting the data within a certain time Minimize bit error rate Non real-time Conversational

Streaming has a guaranteed bitrate and maximum delay and is thus more complex to deal with.
HDSPA

Streaming Interactive 1,2,3

Background

Nokias first HSDPA release

17

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

What is QoS?
Key QoS parameters for different traffic classes: Conversational Blocking, Call Dropping Delay Call Quality (BLER) Interactive Throughput Transmission Delay Queuing Delay Streaming Blocking Call Dropping Delay Jitter Call Quality (BLER) Background Throughput Transmission Delay Queuing Delay

18

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Overview of QoS related parameters for HSDPA (1/2)


PARAMETER Allocation and retention priority (ARP): Fixed/static for each user DESCRIPTION Integer [0-2] where 0 denotes the highest priority. These usually relate to the "classical" differentiation of gold, silver, and bronze users. AVAILABILITY RNC and Node-B

Traffic class (TC): Is set for each Integer representing conversational (=0), RNC user/PDP combination (can be re- streaming (=1), interactive (=2), and background negotiated on very slow basis). (=3) traffic. Traffic handling priority (THP): Is set for each user/PDP combination (can be renegotiated on very slow basis). Integer [0-2] where 0 denotes the highest priority. Only valid for the interactive traffic class (TC=2). RNC

19

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Overview of QoS related parameters (2/2)


PARAMETER Common channel priority indicator (CmCH-PI) and scheduling priority (SPI): Is set for each PDP context. Discard timer DESCRIPTION Integer [0-15] per PDP, where 0 denotes the highest priority. AVAILABILITY RNC and Node-B

One value per PDP context, which indicates the discard timer per MAC-d packet. This timer indicates when the Node-B can discard a SDU. This indicates the guaranteed number of bits per second that Node B should deliver over the air interface under normal operating conditions (provided there is data to deliver).

RNC and Node-B RNC and Node-B

Guaranteed bitrate

With the discard timer and the guaranteed bitrate the bitrate and delay jitter can be With the discard timer and the guaranteed bitrate the bitrate and delay jitter can be controlled. controlled.
20 NOKIA 2004 HSDPA, June 2004.

COMPANY CONFIDENTIAL

QoS in Nokias first HSDPA release


Nokias first HSDPA release will be serving interactive and background traffic in a best effort way. Streaming with guaranteed bitrate and maximum delay is not supported. It is still open whether weighting according to ARP, SPI and/or CmCHPI is to be used. It might be possible to serve streaming as best effort service over HSDPA. This is to be studied.

21

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Transfer delay of streaming class


From 23.107:

"The transfer delay requirements for streaming are typically in a range where at least in a part of this range RLC re-transmission may be used. It is assumed that the application's requirement on delay variation (delay jitter) is expressed through the transfer delay attribute, which implies that there is no need for an explicit delay variation attribute." The transfer delay attribute of streaming class STILL defines the transfer delay, exactly as for the Conversational class. The network designer may derive the delay variation tolerance implicitly from the given transfer delay value. In other words, delay variation allowed in the network is NOT subject to any limit, as long as the transfer delay value is met. In practice, the allowed delay variation must be less than or equal to the transfer delay.

This implies
1. 2. 3. 4.

The discard time value given by the RNC to the Node-B should be set, while taking The discard time value given by the RNC to the Node-B should be set, while taking the e2e delay and other delay components (for instance in the CN) into account. the e2e delay and other delay components (for instance in the CN) into account. This is not used in Nokias first HSDPA release. This is not used in Nokias first HSDPA release.
22 NOKIA 2004 HSDPA, June 2004.

COMPANY CONFIDENTIAL

Goal of QoS in HSDPA for future releases


Target of HSDPA is streaming, interactive and background services. Streaming has a guaranteed bitrate and a maximum delay jitter, so it requires tight QoS control. Interactive and background are best effort services according to the specifications, so no tight QoS control is needed. However it is believed that just best effort is in reality not good enough in the future for interactive and background services. A target bitrate and maximum delay will be offered to the customers for these services by the operators. The goal is thus to offer a guaranteed bitrate and a maximum delay for at least streaming services, while when possible the same mechanisms can be applied for interactive and background services.

23

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

How can this be done?


Different traffic classes, THP and ARPs can be mapped into different SPI (and corresponding CmCH-PI) values in the RNC (operator can choose this mapping) The Node-B needs to follow the following rules:

Fulfill the discard timer and guaranteed bitrate constraints of all traffic. If it is not possible to fulfill these constraints (overload), then the delay constraints of the traffic with the highest SPI priority must be fulfilled first.

By having the SPI mapping and the discard timer and guaranteed bit rate values, the operator can specify the amount of QoS control for all future services. For instance setting the SPI to one value for all traffic and setting the discard timer values to infinity and the guaranteed bitrate to zero means there is no QoS control (everything is best effort). Another possibility is to only define discard timer and guaranteed bitrate values for the streaming traffic and giving streaming the highest priority (lowest SPI value).

24

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Retransmissions in HSDPA
HSDPA introduces L1 H-ARQ on top of the existing RLC ARQ. For traffic based on TCP there is an additional layer of retransmissions (TCP retransmissions) Internet server Node-B RNC
RLC layer retransmissions TCP layer retransmissions. (incl. slow start effect)
25 NOKIA 2004 HSDPA, June 2004.

L1 retransmissions.

UE

COMPANY CONFIDENTIAL

RTT and RLC retransmissions


RLC retransmissions are having a great impact on the TCP round trip time (RTT) TCP. The RTT is the most important factor for TCP performance (throughput, delay). Low RLC retransmission delays will also loosen the buffer constraints for L2 in the UE. The RLC retransmission delay consists of UE processing, uplink ACK transmission, Node-B and RNC processing, Iub transmission delay, Downlink transmission and the Downlink scheduling delay. The downlink scheduling delay can be minimized by increasing the priority of RLC retransmissions (moving them in front of the queue). This is however not possible, since the Node-B cannot differentiate between an original and a retransmission. This will lead to potential very long TCP RTT, if we dont keep the RLC BLER very close to zero!
RNC Node-B Iub
Scheduling Queue
26 NOKIA 2004 HSDPA, June 2004.

UE
COMPANY CONFIDENTIAL

RTT (40B) for HSDPA


RTT of a 40B PING packet. The numbers for 2003 fit with the measured values. Scheduling delay is RTT (ms) modelled as a M/M/1/N queue with N=32 (max number of users). 50% load correponds to 250 40B PING messages per second.
160,00 140,00 120,00 100,00 80,00 60,00 40,00 20,00 0,00 Queing Delay Extra load delay Backbone SGSN+GGSN Iu RNC Iub Node-B Air Interface bufferingdelayDL bufferingdelayUL User Equipment 2006 HSDPA 50% queing load 2006 HSDPA 80% queing load 2006 HSDPA (0% load)

No scheduling delay (most positive RTT estimate

Note that the real scheduling delay may be much longer!!!


27 NOKIA 2004 HSDPA, June 2004.

Scheduling delay modelled as M/M/1/N queing with queing load of 50 and 80%

DCH 2003

COMPANY CONFIDENTIAL

RTT (1500B) for HSDPA


RTT of a 1500B PING packet. The numbers for 2003 fit with the measured values. Scheduling delay is modelled as a M/M/1/N queue with N=32 (max number of users). 50% load correponds to about 27 1500 B PING messages per second.
RTT (ms) 300,00 700,00

No scheduling delay (most positive RTT estimate


Queing Delay Extra load delay Backbone SGSN+GGSN Iu RNC Iub Node-B Air Interface bufferingdelayDL bufferingdelayUL User Equipment 2006 HSDPA 50% queing load 2006 HSDPA 80% queing load 2006 HSDPA (0% load) DCH 2003

600,00

500,00

400,00

200,00

100,00

0,00

Note that the real scheduling delay may be much longer!!!


28 NOKIA 2004 HSDPA, June 2004.

Scheduling delay modelled as M/M/1/N queing with queing load of 50 and 80%

COMPANY CONFIDENTIAL

Measurements & UE capabilities

29

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Node-B measurements
Non HSDPA Power measurement: The amount of transmitted carrier power of all codes not used by HS-PDSCH or HS-SCCH transmission over a measurement period. HS-DSCH required power, reports the minimum necessary power per priority class to meet the Guaranteed Bit Rate for all the established HS-DSCH connections belonging to this priority class (SPI). For each priority class, a list of UEs requiring a particularly high amount of power to meet the Guaranteed Bit Rate for their established HS-DSCH connections may be included. HS-DSCH provided bitrate, reports the total number of MAC-d PDU bits per priority class transmitted over the radio interface during the measurement period, divided by the duration of the measurement period. Only bits from acknowledged MAC-hs PDUs are taken into account. A code utilization measurement is expected to be added to the specs, but in what form is still being discussed in 3GPP.

30

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

UE reference combinations
Reference combination 1.2 Mbps class 3.6 Mbps class 50 6 7 Mbps class 100 8 10 Mbps class 150 8 RLC and MAC-hs parameters Total RLC AM and MAC-hs buffer size (kbytes) 50 Maximum number of AM RLC entities PHY parameters FDD HS-DSCH category 1 5 5 2 7,300 57,600 7 10 2 14,600 115,200 9 15 2 20,432 172,800 6

Maximum number of HS-DSCH codes received 5 Minimum inter-TTI interval (ms) Maximum transport block size per TTI (bits) Total number of soft channel bits 6 7,300 19,200

31

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Flow Control

32

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Flow Control (1/3)


Node B RNC

CAPACITY REQUEST

The HS-DSCH Capacity Request procedure provides means for the RNC to request HS-DSCH capacity by indicating the user buffer size in the RNC for a given priority level (CmCH-PI). The RNC is allowed to reissue the HS-DSCH Capacity Request if no CAPACITY ALLOCATION has been received within an appropriate time threshold.

33

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Flow Control (2/3)


Node B RNC CAPACITY ALLOCATION

HS-DSCH Capacity Allocation procedure is generated within the Node B. It may be generated either in response to a HS-DSCH Capacity Request or at any other time. The current understanding in 3GPP is that the Node-B is in control of the flow, so the flow control is mainly controlled by the Node-B sending capacity allocation messages. The Node-B does know the status of the buffers in the RNC by the capacity request. So the Node B may use this message to modify the capacity at any time, irrespective of the reported user buffer status.
34 NOKIA 2004 HSDPA, June 2004.

COMPANY CONFIDENTIAL

Flow Control (3/3)


The HS-DSCH CAPACITY ALLOCATION message includes a number of parameters:
It indicates the number of MAC-d PDUs that the RNC is allowed to transmit for

the MAC-d flow, indicated by the HS-DSCH Credits.


The associated priority level indicated by the CmCH-PI. The Maximum MAC-d PDU length, HS-DSCH Interval, indicating a time interval during which the HS-DSCH Credits

granted may be transmitted.


HS-DSCH Repetition Period, indicating the number of subsequent intervals that

the HS-DSCH Credits granted may be transmitted.

Any capacity previously granted is replaced. If HS-DSCH Credits = 0, the RNC shall immediately stop transmission of MAC-d PDUs. If HS-DSCH Credits = 2047, the RNC can transmit MAC-d PDUs with unlimited capacity. If the HS-DSCH Repetition Period = "unlimited repetition period" it indicates that the RNC may transmit the specified number of MAC-d PDUs for an unlimited period according to the bounds of Maximum MAC-d PDU Length, HS-DSCH Credits and HS-DSCH Interval .
35 NOKIA 2004 HSDPA, June 2004.

COMPANY CONFIDENTIAL

Example Simple Flow Control Implementation


The most simple implementation for the flow controller is to do periodic capacity allocations. The order of the capacity allocations among the UEs can be either round robin or based on the MAC-hs or RLC buffer status (or a combination of both). This implementation has some constraints with regards to the guaranteed bitrate and number of simultaneous users.
UE1 UE2 UE3 RNC buffer UE2 UE3 Node-B buffer
COMPANY CONFIDENTIAL

UE1 Scheduling

36

NOKIA 2004

HSDPA, June 2004.

Example Advanced Flow Control Implementation


A more advanced flow control implementation can take the following into account: Buffer status in the Node-B Guaranteed Bitrate. Scheduling Priority (SPI) and CmCH-PI. Buffer status in the RNC. Air interface bitrate. Discard timer. The flow control implementation in reality will be a trade off between complexity and performance.
37 NOKIA 2004 HSDPA, June 2004.

COMPANY CONFIDENTIAL

AAL2 and HSDPA


A user has an AAL2 connection over the Iub interface. Thanks to AAL2 multiplexing, the AAL2 packets from several AAL2 connections can be transported on one ATM virtual channel connection (VCC) (maximum 248 (=2^8-8 reserved combinations) AAL2 connections into one VCC). The maximum datarate of such an AAL2 connection equals 2 Mbps, while the maximum bitrate of a VCC is around 10 Mbps. This means that user bitrates of 3.6 Mbps at the air interface can only last for the time it lasts to play out the packets for this user in the Node-B buffer. This issue is being discussed in 3GPP for rel.5
COMPANY CONFIDENTIAL

38

NOKIA 2004

HSDPA, June 2004.

User data flow (1/2)


Node B
RNC CRNC

HS-DSCH DATA FRAME

When the RNC has been granted capacity by the Node B via the HSDSCH CAPACITY ALLOCATION Control Frame or via the HS-DSCH initial capacity allocation and the RNC has data waiting to be sent, then the HS-DSCH DATA FRAME is used to transfer the data. Multiple MAC-d PDUs of same length and same priority level (CmCHPI) may be transmitted in one MAC-d flow in the same HS-DSCH DATA FRAME.

39

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

User data flow (2/2)


7 Header CRC

0 FT CmCH-PI

The data is coming from the RNC to Node-B in MAC-d PDUs. For HS-DSCH the MAC-d PDU format equals the MAC-d PDU format for the non HS-DSCH case. These MAC-d PDU contain a header, a tail and a data field. The minimum size of the header is 22 bits.

Spare bit 7-4

MAC-d PDU Length MAC-d PDU Length NumOfPDU User Buffer Size User Buffer Size ( cont) Spare bits 7-4 MAC-d PDU 1 Spare bits 2-0 header

MAC-d PDU 1 (cont.) payload MAC-d PDU n

Spare bits 7-4

User Buffer Size in the RNC is also reported.

MAC- d PDU n (cont)

Spare Extension Payload CRC Payload CRC ( cont ) Tail

40

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

MAC-hs data units


Queue ID TSN SID1 N1 F1 SID2 N2 F2 SIDk Nk Fk

MAC-d PDU
MAC-hs header MAC-hs SDU MAC-hs SDU Mac-hs payload Padding (opt)

The different header fields in the MAC-hs PDU are given by:
- Queue identifier (Queue ID) provides identification of the reordering queue in the receiver (3 bits). - Transmission Sequence Number (TSN) provides an identifier for the transmission sequence number on the HS-DSCH (6 bits). - Size index identifier (SID) identifies the size of a set of consecutive MAC-d PDUs (3 bits). - Number of MAC-D PDUs (N) identifies the number of consecutive MAC-d PDUs with equal size (7 bits). The maximum number of PDUs transmitted in a single TTI shall be assumed to be 70. If more PDUs are received, the UE behaviour is unspecified. - Flag (F) is a flag indicating if more SID fields are present in the MAC-hs header or not. If the F field is set to "0" the F field is followed by a SID field. If the F field is set to "1" the F field is followed by a MAC-d PDU.
41 NOKIA 2004 HSDPA, June 2004.

COMPANY CONFIDENTIAL

RRM in the RNC

42

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Admission Control
Admission Control is located in the CRNC and decides whether or not a user is allowed to start using HS-DSCH (and other channels). The challenge for admission control is on how the CRNC can know whether the Node-B has room for a new user. The measurements: Non HSDPA Power measurement, Total Power, HS-DSCH required power and HS-DSCH provided bitrate can be used. In Nokia first HSDPA release admission simply consist of checking whether the number of HSDPA users is below a certain threshold (16 users) This solution however does not allow streaming users on the HS-DSCH, since no guarantees can be given that they can be served. This solution is simple.

43

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

HSDPA Handover Options


There are several handover options for HSDPA:
Inter Node-B HS-DSCH to HS-DSCH handover: handover between two HS-DSCH

at different Node-Bs
Intra Node-B HS-DSCH to HS-DSCH handover: handover between two HS-DSCH

at different sectors in the same Node-B.


Handover between HS-DSCH <-> DCH.

Compressed mode and HSDPA is supported in Nokias first release and thus are interfrequency handovers from HSDPA possible (10 ms gaps).

44

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Inter Node-B HS-DSCH to HS-DSCH HO


Handover decision is done by SRNC. Reporting event 1D: Change of best cell in 25.331 used for HO decision
UE informs UTRAN when another P-CPICH in the active set becomes better than the

previously best P-CPICH in its active set. A hysteresis margin can be included.

Inter Node-B HO requires reset of the MAC-hs for the user in in the source Node-B. Hence, buffered PDUs in the source Node-B are lost, i.e., Source Node-B needs to be recovered by higher layers (typically RLC layer). HS-DSCH HSDPA is not supported over the Iur in Nokias implementation, so the Node-Bs need to be below the same RNC. Otherwise relocation is used, which may lead to the loss of more PDUs

SRNC

Target Node-B

HS-DSCH

UE

45

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Recovery of PDUs in the Source Node-B


SRNC knows if the data has been correctly received by UE based on RLC status report (Acknowledged mode) Transmission of an RLC status report from UE is triggered when the UE is informed to reset the MAC-hs which happens during inter Node-B HS-DSCH handover.
SRNC Iub Node-B
HARQ manager Packet scheduler Link adaptation

RLC

MAC-d

Flow control

MAC-hs

RLC status report (AM) UE

RLC

MAC-d

MAC-hs

46

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Intra Node-B HS-DSCH to HS-DSCH HO


All data in the Node-B are moved from the source MAC-hs to the new target MAC-hs, including information related physical layer HARQ (MAC-hs preservation). Hence, during intra Node-B HS-DSCH to HS-DSCH handover, there is no need for recovery of lost PDUs in the source MAC-hs. A UE in 2-way softer handover may also have the uplink HS-DPCCH received at both cells using maximal ratio combining, i.e., no uplink power control problems of the HS-DPCCH.

47

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Handover from HS-DSCH <-> DCH


Possible triggers for HS-DSCH to DCH handover:
The UE is moving to a cell without HSDPA The UE enters SHO mode (active set size becomes larger than one) The load on HSDPA becomes too high (pre-emption actions)

Handover from HS-DSCH to DCH requires reset of the MAC-hs, so recovery of lost PDUs in the MAC-hs is required. Thus, from a logical point of view intra Node-B HS-DSCH to HS-DSCH handover is simpler than handover from HS-DSCH to DCH. Handover from DCH to HS-DSCH should in principle be relative simple to implement, but it is questionable whether it is really needed.

48

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

HSDPA Handover & Coverage (1/2)


The HSDPA coverage area within a cluster of HSDPA capable cells can be controlled via the handover strategy. Full HSDPA coverage under mobility requires support of both inter and intra Node-B HS-DSCH to HS-DSCH handover. Limited HSDPA coverage can be implemented by only allowing UEs in nonSHO mode to be served on HSDPA. Only requires implementation of HSDSCH to DCH handover.
Active set -> 2 -> Handover to DCH in SHO Active set -> 1 -> Handover to HS-DSCH

HS-DSCH DCH in SHO

HS-DSCH

49

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

HSDPA Handover & Coverage (2/2)


Consequences of implementing a solution with limited HSDPA coverage, where only UEs in non-SHO mode are served:
The number HSDPA capable UEs per cell are limited due to reduced

HSDPA coverage area. This may cause problems, since a minimum of 6-8 HSDPA UEs is required per cell to obtain the multi-user diversity gain from intelligent scheduling. For a lower number of HSDPA UEs per cell , it may also be difficult to have 100% utilization of the HS-DSCH.
The HSDPA cell capacity gain is lower for the limited coverage

scenario, since HSDPA capable UEs in SHO-mode are forced to use Rel99 DCH.

50

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Resource Allocation (1/2)


The CRNC takes care of the resource allocation for HSDPA. The resources consist of codes and power. The CRNC sends a PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST to the Node-B in order to adjust the amount of resources. If the PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message includes HS-PDSCH and HS-SCCH Total Power fields, the Node B shall not exceed this maximum transmission power on all HS-PDSCH and HS-SCCH codes in the cell. If a value has never been set or if the value of the HS-PDSCH Total Power message is equal to or greater than the maximum transmission power of the cell the Node B may use all unused power for HS-PDSCH and HS-SCCH codes.

51

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Resource Allocation (2/2)


If the PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message includes the HS-PDSCH and HS-SCCH Scrambling Code fields, the Node B shall use this as the scrambling code for all HS-PDSCHs and HS-SCCHs. If a value has never been set, the Node B shall use the primary scrambling code for all HS-PDSCH and HS-SCCH codes. If the PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message includes HS-PDSCH FDD Code Information field, the Node B shall:
If the HS-PDSCH FDD Code Information field contains no code, delete any existing HSPDSCH resources from the cell. If the HS-PDSCH FDD Code Information field contains one or more codes and HSPDSCH resources are not currently configured in the cell, use this list as the range of codes for HS-PDSCH channels. If the HS-PDSCH FDD Code Information field contains one or more codes and HSPDSCH resources are currently configured in the cell, replace the current range of codes with this new range of codes for HS-PDSCH channels.

52

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Resource Allocation Considerations


The resource allocation in RAN06 is dynamic with a slow update interval (every 2 s). The codes will be allocated with this rate, where the allocation algorithm is still open. It is to be decided whether power is to be allocated or whether we allow the Node-B to use the remaining (not used by non-HSDPA) power for HSDPA.

53

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

QoS thoughts

54

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Summary: Quality of service


Nokias first HSDPA release does provide best effort service. Nokias first HSDPA release will just serve interactive and background traffic and not (guaranteed bitrate) streaming traffic Potentially weighting with traffic class, ARP or THP will be implemented. This leaves lots of potential enhancements for next releases. The next two slides show some performance of TCP over HSDPA compared to DCH and DSCH.

55

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

TCP performance over HSDPA (1/2)


45 40 Downlink time 100 kB file (s) 35 30 25 20 15 10 5 0 1 2 3 4 5 6 7 8 9 10 11 12 Number of Users
DCH, 384 kbps, RLC_BLER=10% DCH, 32 kbps, RLC BLER=10% HSDPA, 384 kbps, RLC BLER=1% HSDPA, 1.2 Mbps, RLC BLER=1% HSDPA, 3.6 Mbps, RLC BLER=1%

100 kB webpage 100 kB webpage download download Including TCP slow Including TCP slow start (RTT = 200 ms) start (RTT = 200 ms)

High bitrates give a gain in download time, but the improvement is not linear High bitrates give a gain in download time, but the improvement is not linear with the bitrate increase due to the TCP slow start with the bitrate increase due to the TCP slow start
56 NOKIA 2004 HSDPA, June 2004.

COMPANY CONFIDENTIAL

TCP performance over HSDPA (2/2)


1,2 1 0,8 Utilisation 0,6 0,4 0,2 0 1 2 3 4 5 6 7 8 9 10 11 12 Number of Users
DCH, 384 kbps, RLC_BLER=10% HSDPA, 384 kbps, RLC BLER=1% HSDPA, 1.2 Mbps, RLC BLER=1% HSDPA, 3.6 Mbps, RLC BLER=1%

Utilisation on Utilisation on dedicated channels is dedicated channels is low for high bitrates, low for high bitrates, while the utilisation of while the utilisation of the HS-DSCH can get the HS-DSCH can get very close to 100% due very close to 100% due to the time duplex to the time duplex nature. This is aapart of nature. This is part of the gain from HSDPA! the gain from HSDPA! 100 kB webpage 100 kB webpage download download

57

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

HSDPA RRM in RAN05

58

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Baseline: RAN05 + 3GPP rel5 (HSPDA)


Possibility to merged into RN2.1 program (?) Supports Rel 99 UEs + HSDPA capable UEs Solution also for 1 carrier frequency (interoperability reasons) Only interactive / background traffic (HSDPA) Full change of baseline Rel-4 to Rel-5 or using only relevant parts of Rel-5
It seen more beneficial to adopt the full Rel-5 Risks of having errors in copying ASN.1 is eliminated Majority of the Rel-5 changes are HSDPA related Non-HSDPA related additional work due to this: No major issues known, ffs (Jukka N.)

59

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Current RN2.1 features needed by HSDPA


RN2.1 current features required for HSDPA
Open Iub DSP capacity and memory usage enhancement DMPG reallocation, currently only a raw requirement for RN2.1m ffs (Juha S.)

RN2.1 current features to be discussed for HSDPA


Service & Load based HO, if enhanced one needed for interoperability reasons Detection of low throughput DCH users, ffs (Pma) Radio Connection Performance measurement Link handler

Other RN2.1 features seen essential (not HSDPA related)


FP update MDC jitter toleration Enhanced priority based scheduling and overload control RLC Re-establishment

60

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Interfaces
Open Iub; the same req. for RNC and BTS
Rel-5 Do we support the private messages? If not we miss: Non HSDPA power measurement BTS init is different Private messages also preferred to not to use Common measurement procedure at all in RN2.1 Work amount: 0 person weeks

Iu: PS+CS Iu interface supported like in RN2.1 Iur: No Iur support for HSDPA
Rejection of HS-DSCH setup in DRNC

61

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

HSDPA performance
Pico cell HSDPA RL throughput ~ 2 Mbit/s Macro cell HSDPA RL throughput ~ 1 Mbit/s RNC: Peak HSDPA throughput Iub: 2Mbit/s
Divided between # of subscribers

RNC internal: Peak for one subs: 2Mbit/s


Open ???

RNC internal: Peak for one subs: 1 Mbit/s Handling of RAB maximum bit rate:
Ignored by RRM Can be the input for platform / transport resources

62

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Reference RABs
No Multi RAB
HSDPA + 64 kbit/s UL + SRB HSDPA + 384 kbit/s UL + SRB RN2.1 reference RABs for non HSDPA UEs

The return channel configuration is done by parameters


64 or 384 Normal packet scheduling is done for the DCH 384 may face blocking (to be measured)

The usage of HS-DSCH is decided in the channel type selection


Input: UE capability, BTS capability, SHO condition, current RAB combination, capacity (10 users),

IFHO/ISHO measurements ongoing, HSDPA enabled, penalty time

If HS-DSCH is allocated no other kind of RABs or several PS RABs are admitted


Option1: The HS-DSCH is cleared and 0/0 DCH is allocated, new RAB/RB is setup right after

separately, preferred

Option2: The HS-DSCH and its RAB is cleared Functionality not guaranteed with other vendors CN Option3: reject the new RABs and wait for escalation

63

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

RRC connection state handling


The state transition from Cell_DCH to Cell_FACH and onwards to Cell_PCH/URA_PCH preferred
HSDPA is seen not to cause extra complexity for state transitions Cell_DCH to Cell_PCH studied anyway for RN2.1 (Jyri K.) Exception is RRC Connection Re-establishment that uses Cell_FACH Continuity for RAN06 Cell_DCH

idle will cause capacity problems due to long inactivity detection time even with the small amount of HSDPA UEs
The resource reservation is done based on max. bit rate in DMCU

This may also be the solution for mobility requirements

Inactivity detection as currently must be further studied for HSDPA (Jukka N.)
One additional parameter for HSDPA inactivity in MCC

64

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Basic HSDPA call


NBAP: Physical Shared Channel Reconfiguration Request run right after the cell setup
Fixed/tunable parameters delivered in this phase No updates, but HSDPA disabling possible Changes needed also in database

From idle:
RANAP: RAB Assignment 0/0 DCH allocated, no changes, depends on basic RN2.1 implementation NBAP: Radio Link Reconfiguration & RRC: Radio Bearer Reconfiguration & AAL2 setup

From Cell_FACH
NBAP: Radio Link Setup & RRC: Radio Bearer Reconfiguration & AAL2 setup

Release
Moving to DCH 0/0 (evaluated elsewhere)

Common RRC changes

65

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Resource reservation (RRM)


Cell resource reservation static, done in the cell setup, if HSDPA enabled Allows separate RNC resource pooling for HSPDA & rest of the services Maximum 10 (PIIFIL) HSPDA subscribers per cell
If the number is exceeded the DCH is selected in channel type selection

Support of 5 codes for HS-DSCH (PIIFIL)


Changes to code tree optimization

Static power budget for BTS (WCEL) CQI, ACK, NACK, T1, Discard Timer (PIIFIL) MAC, RLC, HS-DPCCH, HS-DSCH parameters (PIIFIL) Fixed HS-SCCH code Enabling/disabling HSDPA support in the cell (WCEL parameter) Parameter needs for RNC & transport resources
Min (RAB maximum, operator parameter (WCEL max 2M))? UL DCH bit rate (64 or 384) SRB bit rate 3.4 Change of DMCU in HS-DSCH setup HSDPA, June 2004.

66

NOKIA 2004

COMPANY CONFIDENTIAL

PIIFIL parameters

Handovers
No mobility for HSPDA No SHO for HSDPA and associated DCH No macrodiversity for associated DCH or HSDPA return CH No Inter System HO No Hard HO for HSDPA No handover from DCH to HSDPA Rapid channel type switching from HSDPA to DCH 0/0 Normal HOs for non HSDPA RABs In case of HO is triggered the UE is moved from Cell_DCH to Cell_PCH state directly? Alternatively moving to DCH 0/0 could be applied, preferred The HSDPA usage is forbidden by MCC/BRM for x seconds for the UE
DCH will be allocated

Separate identifiers for HSDPA Ues in WCELL parametrization


Enables separation of HSDPA Ues in HO decision

67

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Security
Ciphering is supported for non HSDPA services Ciphering is supported for HSPDA services
If it was found problems while testing, the ciphering will be deactivated

68

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

Interoperabilty
Enhanced load and service based HO will be done if high pressure from customers
HSDPA Ues differentiated and treated specificly Also non HSDPA Ues can be directed to wanted cell Requires 2 layers (frequencies)

69

NOKIA 2004

HSDPA, June 2004.

COMPANY CONFIDENTIAL

You might also like