hsdpa architecture and functinal split

1 © NOKIA 2004 HSDPA, June 2004. COMPANY CONFIDENTIAL

3. HSDPA Architecture and Functional Split

by Jeroen Wigard et all.

HSDPA Training


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 RAN’05


Logical Split & Responsibilities


The subject ofthis course

The subject ofthis course

Packet Domain Logical Architecture

Gf

Uu

Um

D

Gi

Gn

Iu

Gc

CE

Gp

Gs

Signalling and Data Transfer Interface

Signalling Interface

MSC/VLR

TE MT UTRAN TEPDN

GrIu

HLR

Other PLMN

SGSN

GGSN

Gd

SM-SCSMS-GMSC

SMS-IWMSC

GGSN

EIRSGSN

GnCGF

GaGa

Billing

System

Gb

TE MT BSS

R

A

R


UTRAN Architecture

USIMUSIM

MEME

Cu

UE

Uu

UTRAN

Iub Iur

Node BNode B

RNCRNC

Node BNode B

RNS

Node BRNC

Node BRNS

MSC/VLR

MSC/VLR

SGSNSGSN

CN

Iu CS

Iu PS


HS-DSCH Protocol Model (1/2)• In this case

the CRNC andSRNC are co-incident.

• The High Speed MAC (MAC-hs) entity in the Node B transfers MAC-hs PDU to the peer MAC-hsentity in the UE over the Uu (air) interface.

• The Dedicated MAC (MAC-d) entity in the RNC transfers MAC-d PDUs to the MAC-hsin 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.

PHY PHY TNL

HS-DSCHFP

TNL

HS-DSCHFP

Iub UE NodeB CRNC/SRNC Uu

MAC-d

DCCH DTCH

MAC-hs

MAC-d

DTCH DCCH

MAC-hs


HS-DSCH Protocol Model (2/2)

• In these casesthe SRNC and CRNCare separated.

• In option aIur HS-DSCH Frame Protocol is used to interwork the Flow Control 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.

PHY PHY TNL

HS-DSCHFP

IubUE NodeB CRNCUu Iur SRNC

TNL

HS-DSCHFP

CRNC HS-DSCH Flow Control

TNL TNL

MAC-d

DCCH DTCH

MAC-d

DTCH DCCH

HS-DSCHFP

HS-DSCHFP

MAC-hs MAC-hs

CRNC

TNL TNL

-Option b

Option a


HS-DSCH Protocol Model (2/2)

• In these casesthe SRNC and CRNCare separated.

• In option aIur HS-DSCH Frame Protocol is used to interwork the Flow Control 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.

PHY PHY TNL

HS-DSCHFP

IubUE NodeB CRNCUu Iur SRNC

TNL

HS-DSCHFP

CRNC HS-DSCH Flow Control

TNL TNL

MAC-d

DCCH DTCH

MAC-d

DTCH DCCH

HS-DSCHFP

HS-DSCHFP

MAC-hs MAC-hs

CRNC

TNL TNL

-Option b

Option a


Functional Split OverviewRNC

ResourceAllocation

ResourceAllocation

AdmissionControl

AdmissionControl

QoScontrol

QoScontrol

Node-B

Flow ControlFlow Control

Data BufferData Buffer

Packet

Scheduler

Packet

Scheduler

LinkAdaptation

LinkAdaptation

H-ARQ manager

H-ARQ manager

HSDPA resourcemonitor unit


UE capabilities & state


QoS settingsQoS settings

User data

Capacity request

Codes (and power)

HS-DSCH

HS-SCCH

Node-B measurements

Node-B measurements

Uplink UE information(HS-DPCCH)


ACK/NACK

CQI & ACK/NACK



ResourceAllocation

ResourceAllocation

AdmissionControl

AdmissionControl

QoScontrol

QoScontrol

Node-B



Packet

Scheduler

Packet

Scheduler

LinkAdaptation

LinkAdaptation

H-ARQ manager

H-ARQ manager






User data

Capacity request

Codes (and power)

HS-DSCH

HS-SCCH

Node-B measurements

Node-B measurements



ACK/NACK

CQI & ACK/NACK

Decides whether a user is admitted or not. Located in

CRNC



ResourceAllocation

ResourceAllocation

AdmissionControl

AdmissionControl

QoScontrol

QoScontrol

Node-B



Packet

Scheduler

Packet

Scheduler

LinkAdaptation

LinkAdaptation

H-ARQ manager

H-ARQ manager






User data

Capacity request

Codes (and power)

HS-DSCH

HS-SCCH

Node-B measurements

Node-B measurements



ACK/NACK

CQI & ACK/NACK


CRNC

Takes care of resource allocation for HSDPA. Located

in CRNC



ResourceAllocation

ResourceAllocation

AdmissionControl

AdmissionControl

QoScontrol

QoScontrol

Node-B



Packet

Scheduler

Packet

Scheduler

LinkAdaptation

LinkAdaptation

H-ARQ manager

H-ARQ manager






User data

Capacity request

Codes (and power)

HS-DSCH

HS-SCCH

Node-B measurements

Node-B measurements



ACK/NACK

CQI & ACK/NACK


CRNC


in CRNC

QoS Control takes care of quality of service and UE capabilities and sends this information to the Node-B.

Located in SRNC



ResourceAllocation

ResourceAllocation

AdmissionControl

AdmissionControl

QoScontrol

QoScontrol

Node-B



Packet

Scheduler

Packet

Scheduler

LinkAdaptation

LinkAdaptation

H-ARQ manager

H-ARQ manager






User data

Capacity request

Codes (and power)

HS-DSCH

HS-SCCH

Node-B measurements

Node-B measurements



ACK/NACK

CQI & ACK/NACK


CRNC


in CRNC


Located in SRNC

UE sends feedback information in uplink (ACK/NACK & CQI)



ResourceAllocation

ResourceAllocation

AdmissionControl

AdmissionControl

QoScontrol

QoScontrol

Node-B



Packet

Scheduler

Packet

Scheduler

LinkAdaptation

LinkAdaptation

H-ARQ manager

H-ARQ manager






User data

Capacity request

Codes (and power)

HS-DSCH

HS-SCCH

Node-B measurements

Node-B measurements



ACK/NACK

CQI & ACK/NACK


CRNC


in CRNC


Located in SRNC

UE sends feedback information in uplink (ACK/NACK & CQI)

Total power used by the Node-B and power of

the DPCH per UE


Quality of Service (QoS)


3G QoS is an end-to-end issue

• The radio is the capacity limiting factor, since radio is a hostile medium for access.

• 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

RAN

- but the radio access is the most important QoS domain -

Quality of ServiceQuality of Service : the collective effect of service performances that determine the degree of satisfaction of a user of a service.


3GPP R99/R4/R5 QoS Model

• Voice call• Video call

• Streaming video• Streaming audio

• Web/WAP browsing• E-commerce• Server access

• File download• Mail download• SMS/MMS

Example applications

• 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 expectingthe data within a certain time• Minimize bit error rate• Non real-time

Traffic characteristics

Conversational

Streaming

Interactive 1,2,3

Background

Traffic Class

HDSPA

Nokias first

HSDPA release

Streaming has a guaranteed bitrate and

maximum delay and is thus more complex to deal

with.


What is QoS?

Conversational• Blocking,

• Call Dropping• Delay

• Call Quality (BLER)

Streaming• Blocking

• Call Dropping•Delay Jitter

• Call Quality (BLER)

Background• Throughput

• Transmission Delay• Queuing Delay

Interactive• Throughput

• Transmission Delay• Queuing Delay

Key QoS parameters for different traffic classes:


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

Allocation and retention priority (ARP): Fixed/static for each user

Integer [0-2] where 0 denotes the highest priority. These usually relate to the "classical" differentiation of gold, silver, and bronze users.

RNC and Node-B

Traffic class (TC): Is set for each user/PDP combination (can be re-negotiated on very slow basis).

Integer representing conversational (=0), streaming (=1), interactive (=2), and background (=3) traffic.

RNC

Traffic handling priority (THP):Is set for each user/PDP combination (can be re-negotiated on very slow basis).

Integer [0-2] where 0 denotes the highest priority. Only valid for the interactive traffic class (TC=2).

RNC

PARAMETER DESCRIPTION AVAILABILITY


Overview of QoS related parameters (2/2)

Common channel priority indicator (CmCH-PI) and scheduling priority (SPI): Is set for each PDP context.

Integer [0-15] per PDP, where 0 denotes the highest priority.

RNC and Node-B

PARAMETER DESCRIPTION AVAILABILITY

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

RNC and Node-B

Guaranteed bitrate 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

With the discard timer and the guaranteed bitrate the bitrate and delay jitter can be controlled.

With the discard timer and the guaranteed bitrate the bitrate and delay jitter can be controlled.


QoS in Nokias first HSDPA release

• Nokia’s 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 CmCH-PI is to be used.

• It might be possible to serve streaming as best effort service over HSDPA. This is to be studied.


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

• This implies

1. The transfer delay attribute of streaming class STILL defines the transfer delay, exactly as for the Conversational class.

2. The network designer may derive the delay variation tolerance implicitly from the given transfer delay value.

3. In other words, delay variation allowed in the network is NOT subject to any limit, as long as the transfer delay value is met.

4. In practice, the allowed delay variation must be less than or equal to the transfer delay.

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. This is not used in Nokias first HSDPA release.

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. This is not used in Nokias first HSDPA release.


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.


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


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

RNC

Node-B

UE

RLC layer retransmissions

TCP layer retransmissions.(incl. slow start effect)

L1 retransmissions.


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 don’t keep the RLC BLER very close to zero!

RNC

Node-B

UE

Iub

Scheduling Queue


0,00

20,00

40,00

60,00

80,00

100,00

120,00

140,00

160,00

RTT (ms)

DC

H 2

003

2006 H

SD

PA

(0%

load)

2006 H

SD

PA

50%

quein

g load

2006 H

SD

PA

80%

quein

g load

Queing Delay

Extra load delay

Backbone

SGSN+GGSN

Iu

RNC

Iub

Node-B

Air Interface

bufferingdelayDL

bufferingdelayUL

User Equipment

RTT (40B) for HSDPA

• RTT of a 40BPING 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 250 40B PING messages per second.

No scheduling delay (most positive RTT

estimate

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

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


0,00

100,00

200,00

300,00

400,00

500,00

600,00

700,00

RTT (ms)

DC

H 2

003

2006 H

SD

PA

(0%

load)

2006 H

SD

PA

50%

quein

g load

2006 H

SD

PA

80%

quein

g load

Queing Delay

Extra load delay

Backbone

SGSN+GGSN

Iu

RNC

Iub

Node-B

Air Interface

bufferingdelayDL

bufferingdelayUL

User Equipment

RTT (1500B) for HSDPA

• RTT of a 1500BPING 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.

No scheduling delay (most positive RTT

estimate

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

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


Measurements & UE capabilities


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.


UE reference combinations

172,800115,20057,60019,200Total number of soft channel bits

20,43214,6007,3007,300Maximum transport block size per TTI (bits)

2226Minimum inter-TTI interval (ms)

151055Maximum number of HS-DSCH codes received

9751FDD HS-DSCH category

PHY parameters

8866Maximum number of AM RLC entities

1501005050Total RLC AM and MAC-hs buffer size (kbytes)

RLC and MAC-hs parameters

10 Mbps class

7 Mbps class

3.6 Mbps class

1.2 Mbps class

Reference combination


Flow Control


Flow Control (1/3)

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

Node B RNC

CAPACITY REQUEST


Flow Control (2/3)

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

Node B RNC

CAPACITY ALLOCATION


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


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 Node-B buffer

UE1

UE2

UE3

Schedu

ling


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.


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


User data flow (1/2)

• When the RNC has been granted capacity by the Node B via the HS-DSCH 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 (CmCH-PI) may be transmitted in one MAC-d flow in the same HS-DSCH DATA FRAME.

CRNCNode B

HS-DSCH DATA FRAME

RNC


User Buffer Size in the RNC is also reported.

User data flow (2/2)

• The data is coming from the RNC to Node-B in MAC-d PDU’s.

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

Header CRC

header

7 0

User Buffer Size

FT

Payload CRC

Payload CRC ( cont )

NumOfPDU

User Buffer Size ( cont)

Spare Extension

MAC-d PDU 1

MAC-d PDU 1 (cont.)

MAC- d PDU n (cont)

Spare bits 7-4

Spare bits 7-4

payload

Tail

MAC-d PDU Length

MAC-d PDU Length Spare bits 2-0

MAC-d PDU n

CmCH-PISpare bit 7-4


MAC-hs data units

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

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

MAC-hs header MAC-hs SDU Padding (opt) MAC-hs SDU

Mac-hs payload

MAC-d PDU


RRM in the RNC


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.


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-B’s

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


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 resetof the MAC-hs for the user inin the source Node-B.

• Hence, buffered PDU’s in thesource Node-B are lost, i.e.,needs to be recovered by higherlayers (typically RLC layer).

• HSDPA is not supported over the Iur in Nokia’s implementation, so the Node-B’s need to be below the same RNC. Otherwise relocation is used, which may lead to the loss of more PDU’s

SRNC

Source Node-B Target Node-B

HS-DSCH HS-DSCH

UE


Recovery of PDU’s 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.

RLC

RLC

MAC-d

MAC-d

MAC-hs

MAC-hs

Iub Flow control

Node-BSRNC

HARQmanager Packet

schedulerLink

adaptation

RLC statusreport(AM)

UE


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 PDU’s 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 uplinkpower control problems of the HS-DPCCH.


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 PDU’s 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.


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 non-SHO mode to be served on HSDPA. Only requires implementation of HS-DSCH to DCH handover.

HS-DSCH HS-DSCHDCH in SHO

Active set -> 2 -> Handover to DCH in SHO

Active set -> 1 ->Handover to HS-DSCH


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 Rel’99 DCH.


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.


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 HS-PDSCH resources from the cell.

· If the HS-PDSCH FDD Code Information field contains one or more codes and HS-PDSCH 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 HS-PDSCH resources are currently configured in the cell, replace the current range of codes with this new range of codes for HS-PDSCH channels.


Resource Allocation Considerations

• The resource allocation in RAN’06 is dynamic with a slow update interval (every 2 s).

• The codes will be allocated with this rate, where the allocationalgorithm 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.


QoS thoughts


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.


TCP performance over HSDPA (1/2)

0

5

10

15

20

25

30

35

40

45

1 2 3 4 5 6 7 8 9 10 11 12

Number of Users

Do

wn

lin

k t

ime 1

00 k

Bfi

le (

s)

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%

High bitrates give a gain in download time, but the improvement is not linear with the bitrate increase due to the TCP slow start

High bitrates give a gain in download time, but the improvement is not linear with the bitrate increase due to the TCP slow start

100 kB webpage download

Including TCP slow start (RTT = 200 ms)


Including TCP slow start (RTT = 200 ms)


TCP performance over HSDPA (2/2)

0

0,2

0,4

0,6

0,8

1

1,2

1 2 3 4 5 6 7 8 9 10 11 12

Number of Users

Uti

lisa

tio

n

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 dedicated channels is low for high bitrates, while the utilisation of the HS-DSCH can get very close to 100% due

to the time duplex nature. This is a part of the gain from HSDPA!

Utilisation on dedicated channels is low for high bitrates, while the utilisation of the HS-DSCH can get very close to 100% due

to the time duplex nature. This is a part of the gain from HSDPA!




HSDPA RRM in RAN05


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


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


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


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


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…


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


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


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

• 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


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


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)

hsdpa architecture and functinal split

Documents