56545828 Mastering HSDPA HSUPA Signaling Book 1 0 (1)

Mastering HSDPA/HSUPA

Signaling

www.awardsolutions.com

Communicating Communications

© 2007 Award Solutions, Inc. All rights reserved. No part of this book shall be reproduced or transmitted by any means, electronic, mechanical, photocopying, recording or otherwise, without the express written consent from Award Solutions, Inc.

2100 Lakeside Blvd. Suite 300 Richardson, Texas 75082 Phone: +1.972.664.0727 Fax: +1.972.664.0729 If you have any questions, concerns or comments regarding this course please write to us at: www.awardsolutions.com [email protected]

by training with those who already are

expertbecome

an

2100 Lakeside Blvd. Suite 300 Richardson, TX 75082 1.877.47.Award [email protected]

Award Solutions, Inc. is a knowledge-based company rooted in the areas of advanced wire-less and Internet technologies. Award’s areas of expertise include:

• WiMAX & Emerging Trends • Wireless Fundamentals • CDMA2000 - 1x and 1xEV-DO • GSM and GPRS • UMTS (W-CDMA) • IP, VoIP & IMS

Training Services

Award Solutions offers technical courses in wireless technologies and data communica-tions. Our courses range from introductory to advanced levels brimming with technical details.

The level of technical depth in our advanced technology training courses is unique to the marketplace. Award is known for teaching “beyond the facts” – we bring you the big picture view, and explain the hows and the whys, along with the factual details.

Overview of Services

Network Performance ServicesAward Solutions offers various services to help you in the area of network performance.

Training Solutions - Award Solutions brings together technology theory explained in class-rooms with their practical applications in a hands-on environment through Performance Workshops.

Some examples of Performance Workshop topics include: • 1x Radio Networks Performance • 1xEV-DO (Rev 0) Performance • AMR Performance • GSM Performance • GPRS and EDGE Performance • UMTS (W-CDMA) Performance

Network Solutions - Award believes in going beyond consulting to provide complete solu-tions to your network performance issues.

Some examples of services include: • Business Planning • Network Planning and Design • Network Performance and Optimization • Performance Benchmarking • Acceptance Testing

Customized Solutions

Award Solutions will be happy to customize our course content to meet your specific needs. We can integrate topics across our courses to deliver a custom “bootcamp” to cover only the information important to you and your team. These bootcamps are designed to help teams ramp up on new technologies quickly.

We offer a multitude of delivery methods:

Instructor led onsite training. Our instruc-tors travel to your facility to engage the stu-dents in an interactive learning experience.

Instructor led virtual classroom train-ing. Our instructors deliver our training courses over the Internet using web-based mul-timedia tools.

Performance Workshops. This offers a mix of classroom training and hands-on application of concepts learned in class.

Self-paced eLearning. Our eLearning courses enhance the learning experience using the full multimedia medium, rich with anima-tions, interactions and review questions.

Lunch & Learn. These short seminars help your team quickly learn the highlights of tech-nologies you choose from our curricula.

Webinar. A compact overview of current tech-nologies. Instructor led, and typically no longer than 90 minutes, they are delivered via the web.

expertbecome

an



Instructor led Courses

Emerging Trends

WiMAX Essentials

Exploring WiMAX

4G Technology Overview

Wireless Fundamentals

Wireless and 3G Basics

Wireless Technologies and Networks Overview

3G Comparative Overview

1x & 1xEV-DO

Exploring CDMA2000 (1x) Networks

Mastering CDMA2000 (1x) Call Processing

1x Radio Networks Performance Workshop

1xEV-DO Essentials

Mastering 1xEV-DO Radio Networks (Rev 0)

Mastering 1xEV-DO Radio Networks (Rev A)

Mastering 1xEV-DO Radio Networks (Rev 0 & Rev A)

Mastering 1xEV-DO Signaling (Rev 0)

Mastering 1xEV-DO Signaling (Rev 0 & Rev A)

1xEV-DO (Rev 0) Performance Workshop

Mastering 1xEV-DO (Rev C)

Mobile IP in 1x/1xEV-DO Networks

MMD (IMS) in 1x/1xEV-DO Networks

1x & 1xEV-DO (continued)

VoIP and SIP in 1x/1xEV-DO MMD Networks

Wireless Internet - From IP to 1xEV-

DO

GSM & GPRS/EDGE

Exploring GSM

GSM Performance Workshop

AMR Performance Workshop

Exploring GPRS and EDGE

Mastering GPRS and EDGE

GPRS and EDGE Performance Workshop

Wireless Internet - From IP to GPRS/EDGE and UMTS

UMTS (WCDMA)

UMTS Essentials

Exploring UMTS (WCDMA)

Mastering UMTS (WCDMA) Radio Networks

Mastering UMTS (R99) Signaling

UMTS (WCDMA) Performance Workshop

Mastering HSDPA

Mastering HSUPA

Mastering HSDPA/HSUPA Signaling

Mastering UMTS-LTE

IMS in UMTS Networks

Mastering UMTS Core Networks R4 & R5 (IMS)

UMTS (WCDMA) (continued)

Wireless Internet - From IP to GPRS/EDGE and UMTS

WiMAX

WiMAX Essentials

Exploring WiMAX

Mastering WiMAX Signaling

IP, VoIP & IMS

Internet Fundamentals for 3G

Exploring IPv6 for Wireless Networks

Exploring Voice over IP for Wireless Networks

Mastering SIP for Wireless Networks

IMS in UMTS Networks

MMD (IMS) in 1x/1xEV-DO Networks

VoIP and SIP in 1x/1xEV-DO MMD Networks

Instructor led Onsite Training

Instructor led Virtual Classroom Training


expertbecome

an


Emerging Trends

Overview of OFDM

Overview of WiMAX

Wireless Fundamentals

Overview of 3G Wireless Networks

WAP 2.0 and M-Services

Overview of Wireless LAN

1x & 1xEV-DO

Overview of CDMA2000 Networks

CDMA2000 Air Interface

CDMA2000 Packet Data Networks

Mobile IP for CDMA2000

1xEV-DO Networks (Rev 0)

1xEV-DO Networks (Rev A)

Overview of MMD (IMS) in 1x/1xEV-DO Networks

GSM & GPRS/EDGE

Overview of GPRS

GPRS Air Interface

GPRS Packet Data Operations

GPRS Mobility

UMTS (WCDMA)

Evolution from GSM to UMTS

Overview of UMTS

UMTS/WCDMA Air Interface Fundamentals

UMTS Signaling

GSM & GPRS/EDGE (continued)

UMTS Mobility

HSDPA (R5)

HSUPA (R6)

WiMAX

Overview of OFDM

Overview of WiMAX

IP, VoIP & IMS

Welcome to IP Networking

Overview of MPLS

IP Quality of Service

Session Initiation Protocol

Seamless Mobility

Overview of MMD (IMS) in 1x/1xEV-DO Networks

Self-paced eLearning Courses

Self-paced eLearning

All rights reserved. This course book and the material and information contained in it ("course

material") are owned by Award Solutions, Inc. ("Award"). The course material shall not be

modified, reproduced, disseminated, or transmitted by or in any medium, form, or means,

electronic or mechanical, including photocopying, recording, or any information retrieval

system, in whole or in part, without the prior express written consent of Award. The

unauthorized use, modification, reproduction, dissemination or transmission of the course

material, in whole or in part, is strictly prohibited.

The course material is designed and distributed as instructional aid for courses taught by

Award’s authorized employees and contractors. Award makes no representations or warranties

and disclaims all implied warranties with respect to the information contained herein or products

derived from use of such information and undertakes no obligation to update or otherwise

modify the information or to notify the purchaser or user of any update or obsolescence. Award’s

total liability in connection with the course material is the amount actually received by Award

from the purchaser/user for the purchase of the course material.

Table of Contents

Version 1.0

Table of Contents

HSPA Architecture and Protocols.......................................................1-1

UMTS Basic Data Call Setup .............................................................2-1

HSPA Key Concepts .........................................................................3-1

HSDPA Data Call Setup ....................................................................4-1

HSUPA Data Call Setup ....................................................................5-1

Multi-Services Scenario ....................................................................6-1

HSPA Interworking ..........................................................................7-1

Appendix: HSDPA Call Setup ...........................................................A-1

Acronyms .......................................................................................B-1

References......................................................................................C-1


HSPA Architecture and Protocols

HSPA Architecture HSPA Architecture and Protocolsand Protocols

1-1



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Objectives

1-2



ObjectivesObjectivesAfter completing this module, you will be able to:

• Describe the 3GPP release features• Draw the UMTS network architecture and

identify HSPA network impacts• Describe how UMTS separates the core

network’s functions from the radio access network’s functions

• Sketch and describe the UMTS radio access protocol stack, RRC, RLC, MAC and PHY

• Describe the protocol view with HSPA features • Identify different types of MAC protocols used

in HSPA

1-3



UMTS Release 99

• 2 Mbps theoretical peak packet data rates

• 384 kbps (practical)

UMTS Release 4

• MSC Server-based architecture

• Bearer Independent Call Control (CS)

UMTS Release 5

• HSDPA (14 Mbps downlink theoretical)

• IMS (IP Multimedia Subsystem for multimedia)

UMTS Release 6

• HSUPA (up to 5.76 Mbps uplink)

• MBMS (Multimedia Broadcast Multicast Service)

UMTS Release 7

• Multiple Input Multiple Output (MIMO) Antenna Systems in combination with Orthogonal

Frequency Division Multiplexing (OFDM)

UMTS Release 8

• LTE is an important work item in the 3GPP standards that concerns the Long Term Evolution

(LTE) of UMTS. LTE brings radical changes to the air interface as well as the network

architecture.

HSPA is a non-standard generic term that is often used to refer to both the uplink (HSUPA) and downlink

(HSDPA) high-speed packet technologies in 3GPP.

HSPA in a UMTS Roadmap

1-4



Release 4Bearer-independent CS architecture

Release 99Voice,2 Mbps data rate

Release 5HSDPA (14 Mbps DL),IP multimedia subsystem

R 7

Release 6HSUPA(5.76 Mbps UL),MBMS

Release 7OFDM/MIMO

HSPA in a UMTS RoadmapHSPA in a UMTS Roadmap

Frozen!(completed)

R 5R 6R 4

HSPA = HSDPA + HSUPA

R 8

Release 8LTE

R 99

1-5



3G Universal Mobile Telecommunications System (UMTS) networks are shown in the adjoining slide.

UMTS specifies a Core Network (CN) architecture and services to be offered on this CN. The UMTS

Terrestrial Radio Access Network (UTRAN) defines the radio access interface to land mobiles.

The UMTS CN is defined in a modular fashion and is completely independent of radio access

technologies. It specifies the Iu interface, which can be used by different Radio Access Networks (RANs)

to connect to the UMTS CN.

The figure shows a typical UMTS architecture where the CS and PS domains are supported by separate

physical entities. The CS domain is supported by an evolved 2G MSC/VLR, whereas the PS domain is

supported by an evolved 2G SGSN. Both the CS and PS domains support their own state machine. The

User Equipment (UE) maintains two separate state machines—one for the CS domain and one for the PS

domain.

The UTRAN maintains two Iu connections to the two different domains. The UTRAN provides one

unified set of radio bearers for both the PS domain and the CS domain. These radio bearers carry bursty

traffic for the packet domain and traditional telephony traffic for the CS domain. The UTRAN provides

the distribution functionality to the two domains.

The Home Location Register (HLR) is shared between the two domains. The HLR maintains a common

subscription database for both domains. However, it maintains separate location information for the two

domains.

The Impact of the Release 5 and Release 6 features for High Speed Packet Access (HSPA) are mainly in

the UTRAN and the UE. The Packet Switched Core Network (PS-CN) is impacted as well, but to a lesser

degree. The transport infrastructure also needs improvement in performance since larger amounts of data

have to be transported between the Radio Access Network (RAN) and the CN. This backhaul

improvement may be done gradually according to the requirements of the network operator as the volume

of HSPA traffic increases with time.

UMTS Network and HSPA

1-6



UMTS Network and HSPAUMTS Network and HSPA

Packet-Switched

Circuit-SwitchedHLR

3G MSC/VLR

MSC

3G-SGSNGGSN

GGSN

UTRAN

AuC

3G-SGSN

IP

SS7

IntraPLMN IP

Back bone

UE RNCNode B

MajorHSPA impact

MajorHSPA impact

Minor HSPA impact

Gradual capacity improvements

No impact

Uu

Iub

Iu-cs Iu-ps

RNC

Iur

1-7



The Access Stratum (AS) provides services related to the transmission of data over the radio interface and

the management of the radio interface to the other parts of UMTS.

The AS includes the following protocols:

• UE - Access Network: This protocol supports the transfer of detailed radio-related information to

coordinate the use of radio resources between the UE and the access network.

• Access Network - Core Network/Serving Network: This protocol supports the access from the

Core Network/Serving Network to the resources provided by the access network. It is independent

of the specific radio structure of the access network.

Non-Access Stratum (NAS) is a logical separation of the Core Network and Services Network from the

AS. This pertains to various functions used to provide services such as mobility management, location

management, security, etc. to the user in the UE.

It is important to note that NAS messages can transparently flow from the UE (through the access

network) to its peer entities in the Core Network (CN) or services network. Another key aspect is that the

UE contains both AS and NAS personalities, and together they provide the ability for the UE to obtain

both access and services. Based on the principles of Access Stratum (AS) and Non-Access Stratum

(NAS), the signaling protocols can be divided into access and non-access signaling protocols. These

signaling protocols are implemented between the UE and the UMTS network. To establish services, the

UE must invoke both access and non-access signaling procedures.

The access signaling procedures are invoked to set up, reconfigure and release radio bearers. These

procedures are related to the establishment of a radio connection from the UE all the way to the CNs. This

includes signaling to establish radio channels over the air, signaling to establish Iub user plane connections

within the radio network, and Iu signaling to establish Iu user plane connections between the UTRAN and

CNs.

A good illustration of the benefits of the separation of NAS vs. AS protocols is the HSPA technology. As

an air-interface solution, this technology does not imply any major changes with respect to the NAS when

the AS is modified.

Access and Non-Access Layers

1-8



Access and NonAccess and Non--Access LayersAccess Layers

Application-related Signaling(Voicemail, HTTP, email, etc.)

Service setup-related Signaling(GSM, GPRS or UMTS)

Radio-related Signaling

Node B

SGSN/GGSN

MSCUE

PSTN

Internet

Iu

Iu

RNC

Radio Connection

Non-AccessStratum

AccessStratum

Minimal HSPA

Impact

Major

HSPA

Impact

1-9



The packet signaling protocol reference model and packet traffic protocol reference model are shown as

illustration only. They are included as reference for the students to understand where the radio interface

protocols fit in.

The signaling user plane consists of the following functional components:

UE: This is the mobile and it contains the radio interface protocols as well as the Core Network

(CN) signaling protocols, Session Management (SM) and Packet Mobility Management

(PMM). These layers work together to provide the signaling required to run applications.

UTRAN: The Node B and RNC are simplified here as the UTRAN and the general protocol model

from a mobile’s perspective without any of the transport layer protocols.

3G-SGSN: This illustrates the use of the RANAP protocol for signaling on the Iu – the PS interface

and the GPRS Tunneling Protocol (GTP-C) control protocol used for tunnel establishment.

3G:GGSN: At the GGSN, the same signaling protocol, GTP-C, is used, and it runs on top of the

UDP/IP. Also, the GGSN can talk to the Internet and can use any L1 or L2 mechanisms.

Packet Signaling Protocol Reference Model

1-10



Packet Signaling Protocol Packet Signaling Protocol Reference ModelReference Model

PMM /SM

RRC

RLC

MAC

UMTS RF UMTS RFL1

UEUu

UTRANIu-PS

3G-SGSN

L1

RRC RANAP

RLC

MAC

AAL5/ATM

Signaling Bearer

PMM / SM

RANAP

AAL5/ATM

Signaling Bearer

SCCP SCCP

GGSN

L1

E.g., IP, PPP, OSP

GTP-C

L2

UDP/IP

L1

GTP-C

L2

UDP/IP

RRC

Relay

Radio Interface Protocols

1-11



The specific air interface protocol layer changes are summarized in this figure. There are primarily three

layers in the UMTS R99 air interface architecture.

• Layer 1 is the physical layer responsible for over-the-air functions such as spreading and

modulation.

• Layer 2 consists of the Medium Access Control (MAC) and Radio Link Control (RLC) layers. The

MAC layer handles system access operations and the RLC layer provides reliable delivery of user

traffic.

• The third layer is the Radio Resource Control (RRC) layer which is the brains of the RNC. The

RRC layer is responsible for all signaling and messaging to the UE.

The key enhancements to the air interface protocol layer architecture are the enhanced dedicated channel

(E-DCH) related functionalities, primarily at the MAC and physical layers. This enhanced channel enables

superior packet data performance in the uplink. The E-DCH control function is responsible for controlling

operations of the new channels introduced in HSUPA systems to handle packet data services. Changes to

the RRC are required so that E-DCH-related information can be communicated to the UE.

Protocol Changes for HSPA

1-12



Signaling Data

Radio Link Control (RLC)

Media Access Control (MAC)

Physical Layer

LinkLayer

PhysicalLayer

UpperLayers

Radio Resource Control (RRC)

L3

Supports new HSPA channelsand modulation

Protocol Changes for HSPAProtocol Changes for HSPA

Modified to manage

HARQ and HSPA process

UTR

AN

L2

L1

PDCP

Packet Data Convergence Protocol (PDCP)

User DataCS PS

Modified to support

HSPA call setup and

QoS

No Change

1-13



As indicated in the protocol stack for the control plane, the Radio Resource Control (RRC) protocol,

residing in the UE and the Serving RNC, is by far the most important signaling protocol for UE-UTRAN

signaling. One can say that the RRC is the master of the UTRAN, because we have all UE-UTRAN layer

3 signaling messaging at this layer, and it is also fully in charge of the lower layers (i.e., Radio Link

Control (RLC), Medium Access Control (MAC) and the Physical Layer). The latter means that the lower

layers always report conditions and states to the RRC, and the RRC can always, if needed, make changes

for the setting of lower layers.

On the UE side, this is done completely internally since all the above mentioned protocol layers reside in

the terminal. On the network side, the RRC, RLC and MAC reside in the RNC. However, since the

physical layer is at the Node B, the RRC-physical layer communication takes place over the Iub interface.

Radio Resource Control: RRC

1-14



Radio Resource Control: RRCRadio Resource Control: RRC• Master of UTRAN

– UE control: All UE UTRAN messages are at the RRC layer

– Lower layers control

RRC

RLC

MAC

PHY

1-15



Some of the functions performed by the Radio Link Control (RLC) layer are:

• Segmentation and Reassembly: Variable length Protocol Data Units (PDU) are segmented and

reassembled into and from smaller RLC Payload Units (PU). One RLC PDU may carry one PU or

several PDUs when the header is compressed. The minimum transmission size depends on the

smallest possible bit rate.

• Error Correction: In the acknowledged mode, the RLC layer provides error correction. The RLC

provides retransmission by:

– Selective Repeat

– Go Back N

– Stop-and-Wait Automatic Repeat Request (ARQ)

• In-sequence Delivery of Higher Layer PDUs: In the acknowledged mode, the RLC layer

preserves the order in which the higher layer PDUs were submitted. If the order of higher layer

PDUs is not desired, the out-of-sequence delivery is done using the other data transfer services.

• Transfer of User Data: The RLC provides three types of data transfer services to users of RLC

services:

− Transparent mode

− Unacknowledged mode

− Acknowledged mode

• Notification of Unrecoverable Errors If the RLC cannot resolve any errors using exception-

handling procedures, it notifies the upper layers about the errors.

Radio Link Control: RLC

1-16



Radio Link Control: RLCRadio Link Control: RLC

Functions

Notifies Upper Layers of

Unrecoverable Errors

Supports Automatic

Repeat Request (ARQ)

In-sequence Delivery of

Higher Layer PDUs

Error Correction

Segmentation and

Reassembly

Ciphering(AM and UM)

3 modes of operation

AM, UM, TM

1-17



• Ciphering RLC provides protection against unauthorized acquisition of data. Ciphering is done

either in the RLC or MAC layer depending on the type of RLC data (i.e., transparent or non-

transparent).

• QoS setting The QoS level can be set by the RRC. This affects how the retransmission protocol

will be used to correct errors that have been detected.

Radio Link Control: RLC (continued)

1-18



Radio Link Control: RLC Radio Link Control: RLC (continued)(continued)

Functions

Notifies Upper Layers of

Unrecoverable Errors

Supports Automatic

Repeat Request (ARQ)

In-sequence Delivery of

Higher Layer PDUs

Error Correction

Segmentation and

Reassembly

Ciphering(AM and UM)

3 modes of operation

AM, UM, TM

1-19



The Medium Access Control (MAC) protocol provides its services to the higher layers in the form of

logical channels, characterized by the type of information that is being sent on them. The MAC provides

its services to both the control plane and user plane.

Since the logical channels and transport channels exist above and below the MAC layer, it is quite natural

that the multiplexing of the logical into transport channels becomes a fundamental function for the MAC.

In the MAC layer, logical channels are mapped to transport channels according to the Transport Formats

(TFs). The MAC can also schedule and prioritize the resources (e.g., on the common channels) between

the UEs and between data flows.

When common transport channels are used, the UE ID is added and read by the MAC layer. In case the

RLC protocol is operating in the transparent mode and the ciphering procedure is on, ciphering occurs at

the MAC layer since there is no RLC header, and, hence, no sequence number.

Medium Access Control: MAC

1-20



Medium Access Control: MACMedium Access Control: MAC

Functions

Logical to Transport CH Multiplexing

TrCH Type Switching

Selection of Appropriate TF for Each

TrCH

Priority HandlingIdentification

of UEs on Common

TrCHs

Ciphering (if TM-RLC)

1-21



The Medium Access Control – High Speed (MAC-hs) entities handle HSDPA traffic in the UTRAN. For

each HSDPA UE, there is one MAC-d entity controlling its traffic. In addition, the MAC-d entity is

associated with a MAC-hs in the Node B. The transport blocks are sent from the MAC-d (in the RNC) to

the MAC-hs (in the Node B) using the HS-DSCH framing protocol on the user plane. These messages

may also carry inband signaling for each UE.

For HSUPA, the Node B is enhanced with the MAC-es entity. For each UE there is a MAC-e entity at the

Node B. This MAC protocol is responsible for the scheduling of resources for the UE as well as the

Hybrid-ARQ related processes. The MAC-e does the demultiplexing of MAC-e PDUs. At the RNC, the

MAC-es is responsible for receiving the MAC-e PDUs and reordering them according to a sequence

number. The MAC-es at the RNC is also responsible for macro-diversity processing that is needed as a

result of the uplink soft-handover. The MAC-es only resides at the S-RNC (serving RNC), which manages

radio resources for the UE.

MAC Changes in UTRAN

1-22



MAC-esMAC-esMAC-es

MAC-eMAC-eMAC-e MAC-hs

MAC-d

MAC Changes in UTRANMAC Changes in UTRAN

TransportChannels

MAC-dMAC-d

Iub

Logical Channels

RNC

TransportChannels

MAC-c/sh

Node BFraming Protocol

1-23



The functions of Medium Access Control – High Speed (MAC-hs) include:

• Multiplexes/Demultiplexes data to and from HS-PDSCH Channels: The MAC-hs receives

transport blocks for all UEs that have been assigned to the HS-DSCHs. The MAC-hs then

decides who receives data and on which HS-PDSCH.

• Handles the priority of data between UEs: The MAC handles the priority of data to different

UEs using a dynamic scheduling mechanism.

• Selects Modulation and number of spreading factors: The size of the data sent in one frame is

determined by the available modulation scheme. This is based on the channel conditions and the

number of available spreading factors based on the other traffic in the cell.

• Data transfer: The MAC-hs provides peer-to-peer transfer of MAC Service Data Units (SDU).

The MAC-hs also uses the Hybrid ARQ incremental redundancy scheme to send the data to the UE

and send the retransmission based on feedback from the UE.

MAC-hs Functions

1-24



MACMAC--hs Functionshs Functions• Multiplexes/Demultiplexes data to and from HS-PDSCH

channels• Handles the priority of data between UEs• Selects modulation and number of spreading factors• Data transfer

– Uses Hybrid ARQ to transfer data to the UE– Performs incremental redundancy based on the feedback from

the UE

TransportChannels

LogicalChannels

MAC Control

MAC-d

MAC Control

MAC – High SpeedMAC-hs

1-25



The MAC layer undergoes significant changes to support the HSUPA feature. The changes required at

various entities in a UMTS system are outlined below:

• UE Enhancement: The UE implements a new MAC entity that resides between the existing

MAC-d layer and the physical layer. This entity carries out the functions of the MAC-es and

MAC-e. The standard does not distinguish between these two sublayers at the UE. The MAC-e/es

entity takes care of (i) HARQ retransmissions, (ii) multiplexing of multiple MAC-d PDUs into a

single MAC-e PDU for the physical layer processing, and (iii) E-TFC selection (effectively, the

uplink data rate) based on the UTRAN instructions.

• Node B Modifications: The Node B requires a new MAC-e entity so that tasks related to

processing schedule requests from the UE and scheduling uplink resources, HARQ retransmissions

and E-DCH demultiplexing can be performed. The cells in the E-DCH active set influence the data

rate selection process executed by the UE.

• RNC Changes: The MAC-es is added to the RNC’s MAC layer so that selection combining of

uplink packets can be carried out and the in-sequence delivery of packets can be ensured.

The Transport Network Layer (TNL) helps transport information from one network entity to another. The

E-DCH Framing Protocol (FP) facilitates carrying of the information associated with the E-DCH.

E-DCH Protocol Architecture

1-26



EE--DCH Protocol ArchitectureDCH Protocol Architecture

PHY

MAC-e /MAC-es

MAC-d

PHY

MAC-e EDCH FP

Node B SRNCUE Uu Iub+Iur

DTCH DCCH DTCH DCCH

MAC-d

E-DCHFP

MAC-es

• HARQ• Multiplexing to

form MAC-e / MAC-es

• Rate selection

• Scheduling request processing

• Scheduling• HARQ• MAC-e Demux

• MAC-es disassembly

• Macro diversity selection combining

• Reordering

1-27



MAC-e Entity:

• A UE-specific MAC-e entity instance is created to handle E-DCH traffic from each UE at its

serving cell Node B

• A MAC-e PDU is the E-DCH-specific PDU for the current transmission

• A MAC-e PDU may consist of MAC-es PDUs from multiple flows

• A MAC-e PDU may also contain UE-specific schedule information

• The composition of a MAC-e PDU changes from one E-DCH transmission to the next since it is a

combination of data from multiple flows

• A Node B MAC-e entity demultiplexes the PDU sent by a UE

• A MAC-e PDU header should contain information about the contained MAC-es PDUs. The header

information assists the Node B in demultiplexing and retrieving schedule information, if included.

MAC-es:

• A MAC-es processing instance is created per the UE at the Serving RNC (SRNC)

• A MAC-es PDU is made up of MAC-d PDUs from a single flow

• The MAC-d PDUs included in a MAC-es PDU are sent as part of the MAC-e header information

• A MAC-es PDU header includes a Transmission Sequence Number (TSN) to assist with

resequencing of MAC-d PDUs for delivery at the SRNC. The SRNC may receive MAC-es PDUs

out of order due to the Hybrid ARQ. The MAC-es entity at the SRNC is responsible for the

reordering function.

What are MAC-e and MAC-es?

1-28



What are MACWhat are MAC--e and MACe and MAC--es?es?MAC-e

• One instance per UE at the Node B• Responsible for demux at the Node B• May contain MAC-es PDUs from multiple MAC

flows• Schedule information handler at the Node B

MAC-es• One instance per UE at the Serving RNC (SRNC)• Handles selection combining in case of macro

diversity• Responsible for MAC-es disassembly and

reordering

1-29



The UTRAN radio interface defines an elaborate channel structure for communication between different

layers. Each layer provides a set of channels through which upper layers can transfer information

(signaling and traffic). The radio interface layers define the following three types of radio channels:

• Physical channels: The physical channels are the interface between the UE and the UTRAN,

representing an over-the-air interface. Each physical channel is identified by a specific

channelization code. The physical channels specify how the data is transmitted over the air.

Physical channels are carried in 10 or 2 ms frames.

• Transport channels: Transport channels are the services provided by the physical layer to the

upper layers. A transport channel specifies how and with what characteristics upper layer

information is transmitted over the air. For example, if the user is on a simultaneous voice and data

call, voice and data traffic can be sent over different transport channels. Each application has

different requirements. Data might need higher protection than voice. Therefore, different transport

channels specify different protection schemes to transport user traffic. Transport channels are

mapped to physical channels, and transport channel frames are known as transport blocks.

Transport blocks can be 10, 20, 40 or 80 ms in length.

• Logical channels: Logical channels are the interface between the MAC and the RLC layer. The

logical channel is concerned with the type of data is transmitted, and logical channels understand

whether voice, signaling and data traffic is being sent. Each logical channel corresponds to one

RLC instance. The logical channels are mapped to transport channels, and logical channel frames

are the same size as corresponding transport channel blocks.

When a radio bearer is set up for a UE, all three types of channels have to be configured. For example, a

radio bearer for voice applications may have three logical and three transport channels to support different

classes of bits. However, all three transport channels are mapped to the same physical channel.

Radio Protocols and Channels

1-30



Radio Protocols and ChannelsRadio Protocols and Channels

Control Plane Signaling User Plane Information

Non-Access Stratum (NAS)

Access Stratum (AS)

Packet and Circuit CN Signaling data voice

PDCPRRC

MAC

voicedata

Logical Channels

Transport Channels

Physical Channels

RLC

PHY

1-31



HSDPA is an evolution from UMTS R99. Hence, HSDPA supports all the UMTS R99 configurations

without any restrictions. HSDPA also introduces new channels specifically designed to support high-speed

packet data services. These channels are:

1. High Speed – Downlink Shared Channel (HS-DSCH): The HS-DSCH is a new channel

designed to carry high-speed packet data traffic. Each cell may support one or more HS-DSCHs.

The HS-DSCH is a shared channel shared across all users requesting HSDPA specific high-speed

packet data services. Sharing of the HS-DSCH is based on Time-Division Multiplexing (TDM)

across multiple users.

2. High Speed - Shared Control Channel (HS-SCCH): The SCCH is a control channel associated

with the HS-DSCH. The SCCH conveys the HS-DSCH allocation information including the user

identity, the number of spreading factors used, and the modulation scheme.

3. High Speed - Dedicated Physical Control Channel (HS-DPCCH): The HSDPA system gathers

current radio condition information on a continuous basis from all the mobiles vying for access to

the HS-DSCH. Each UE measures and determines the C/I value of each active set pilot and report

the C/I of the best sector. Since HSDPA systems support the Hybrid ARQ scheme, the transmitter

(Node B) transmits some of the turbo-encoded symbols first and waits for a physical layer

acknowledgement from the receiver (UE). If the response is a NACK, the base station continues to

send additional symbols. If the response is an ACK, the base station stops sending the remaining

symbols and continues with the next packet. The mobile sends these ACK/NAK commands along

with the current CQI on the HS-DPCCH.

HSDPA Channels

1-32



HSDPA ChannelsHSDPA Channels

HS-DSCH (Transport Channel)/

HS-PDSCH(Physical Channel)

HS–DPCCH(PhysicalChannel)

New HSDPA Channels

Downlink

HS-SCCH(Physical Channel)

Uplink

1-33



High Speed Uplink Packet Access (HSUPA) introduces new channels to support uplink high speed packet

data services. The main channel of interest is the Enhanced Dedicated Channel (E-DCH), a transport

channel. In addition, other associated channels, primarily physical channels, enable high speed data

services on the uplink. These channels and their functions are described below:

1. Enhanced Dedicated Channel (E-DCH): The E-DCH is an uplink transport channel defined for

HSUPA. The E-DCH carries user traffic from the UE to the Node B on the uplink. An E-DCH

transport channel may be mapped to one or more physical channels as required. To achieve high

data rates while maintaining reverse link load at a manageable level, the E-DCH is controlled by

the Node B.

2. Enhanced Dedicated Physical Data Channel (E-DPDCH): The E-DPDCH carries E-DCH user

traffic from the UE on the uplink. Since the E-DPDCH is on the uplink, the channelization codes

are used to separate channels within a given UE. This allows HSUPA to use very short codes

(e.g., 2-bit or 4-bit codes) to send user data.

3. Enhanced Dedicated Physical Control Channel (E-DPCCH): The UE determines the rate of

transmission and associated transmission characteristics on the E-DCH. The E-DPCCH is an

uplink physical channel used to convey E-DPDCH transmission characteristics. The E-DPCCH

carries only physical layer control information related to the E-DPDCH.

4. E-DCH Hybrid ARQ acknowledgement Indicator Channel (E-HICH): The E-HICH is a

physical channel that carries information related to Hybrid ARQ. This downlink channel is used

by the Node B to convey a positive or negative acknowledgement (ACK/NACK) for a physical

layer packet received from a UE at the Node B.

HSUPA-Related Channels

1-34



HSUPAHSUPA--Related ChannelsRelated Channels

E-DPCCH(1)

Downlink

E-DCH

E-DPDCH(1 or more)E-AGCH E-RGCH E-HICH

Uplink

Transport

Physical

HSUPA Channels

1-35



5. E-DCH Absolute Grant Channel (E-AGCH): The E-AGCH is a physical channel used by the

Node B to convey absolute power ratio allocation for uplink E-DCH transmission.

6. E-DCH Relative Grant Channel (E-RGCH): The E-RGCH conveys power allocation for uplink

E-DCH transmission by the Node B. The E-RGCH conveys corrections to already communicated

serving grants, which is different from the absolute power allocation grants conveyed using the E-

AGCH channel.

It should be noted that there is only one transport channel in this set. All other channels exist only as

physical channels.

HSUPA-Related Channels (continued)

1-36



HSUPAHSUPA--Related Channels Related Channels (continued)(continued)

E-DPCCH(1)

Downlink

E-DCH

E-DPDCH(1 or more)E-AGCH E-RGCH E-HICH

Uplink

Transport

Physical

HSUPA Channels

1-37



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Summary

1-38



SummarySummary• HSPA is an enhancement in Release 5 & 6 of UMTS

specifications• HSPA technology has a significant impact on the UE-

UTRAN protocols• The PHY, MAC and the RRC layers are enhanced• For HSDPA, a new MAC-hs protocol is implemented at

the Node B• For HSUPA, the MAC-e protocol is implemented at the

Node B and a MAC-es is implemented at the RNC• The UE protocol stack is also impacted• New Transport and Physical channels are defined for

HSPA operations

1-39



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Review Questions

1-40



Review QuestionsReview Questions1. In what UMTS specification release do we first see HSUPA?2. What are the two main strata in UMTS called and what is their

difference?3. Name the air interface protocols of the UTRAN in order, assign a layer

number to each and place each protocol in the corresponding node.4. Which protocol(s) is not impacted by the HSPA operations?5. Which protocol needs to be implemented at the Node B for high-speed

downlink data transmissions?6. What new protocol needs to be implemented at the RNC for high-speed

uplink operations?7. In simple terms, describe the role of the framing protocol in HSPA

operations.8. Name all new channels needed for HSPA operations. What type(s) of

channel are these (Logical, Transport, Physical)?

1-41


UMTS Basic Data Call Setup

UMTS Basic Data UMTS Basic Data Call SetupCall Setup

2-1



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Objectives

2-2




• Explain how packet sessions are activated• Describe the actions of the radio network components

in a packet session• Discuss how Quality of Service (QoS) is established for

a packet session• Examine the roles of the MAC and RLC layers in a

packet session

2-3



To set up a PS connection in UMTS, the UE and the Network must go through a well-defined set of

procedures.

The procedure begins by the UE sending a request for necessary radio resources to start the call setup.

This procedure has to be initiated by the UE even in the case of an incoming call. As a result of this

request, we have to establish a signaling link between the UTRAN and Core Network (CN) as well. The

network must start the authentication procedures with the UE at this point and may carry out other

optional security related procedures. After passing the security procedures, the UE informs the CN about

the type of call and the specifics of the Quality of Service (QoS) required for the service. After this

specific request for a QoS is sent by the UE, the CN and the UTRAN negotiate an appropriate QoS that

may be granted to the UE, taking into account many factors like the subscriber profile and the cell load,

for example. Once the QoS level has been decided by the network, the UE must be informed and

configured with all the necessary parameters to set up a Radio Access Bearer (RAB). A RAB defines

exactly all the resources allocated to the mobile for a given service type. The final result of these

procedures is an established session (or circuit) with a well-defined QoS. It is important to take note that in

UMTS the QoS is more than just throughput and delay, although these are still among the most important

QoS parameters.

UMTS End-to-End View

2-4



UMTS EndUMTS End--toto--End ViewEnd View

Node BPS-CN

Iub IuUu

UE

End-to-End QoS

Radio Resources Iu connection

QoS Negotiation

Security-Related Procedures

Request for a QoS

RAB Setup

UTRAN

RNC

2-5



The RRC has two modes of operation: Idle mode and Connected mode. In idle mode, no signaling

connection exists between the UE and the UTRAN. When the UE is in the connected mode, user data may

be sent.

When the UE is powered on, it enters idle mode where it attempts to access a Public Land Mobile

Network (PLMN). It selects a cell that is able to provide available services, and tunes to its control

channel. This is known as “camping on a cell.” The process continues with a location registration

procedure. This effectively makes the UE known in the network. The UE continually monitors

neighboring cells to see if another cell is more suitable. This is particularly useful as the UE moves

throughout the network.

There are several reasons for a UE to “camp on a cell”:

• It enables the UE to receive system information from the PLMN

• The process of initiating a call is simpler, because the UE has already chosen a cell

• The UE is ready to accept incoming calls. The UE is notified of an incoming call via the control

channel to which the UE continues to listen.

• While idle, the UE is able to conserve battery consumption by sleeping and only waking up

periodically to check for incoming messages

The second mode of operation is the connected mode. In this mode, one and only one signaling connection

exists between the UE and the Radio Network Controller (RNC) – the RRC connection. In this mode, the

UE is assigned a Radio Network Temporary Identity (RNTI), which is used to identify the UE on common

transport channels. In addition, the UE is known at either the cell level or the UTRAN Registration Area

(URA) level (i.e., a set of cells). Depending on the state of the UE connection, different mechanisms are

used to communicate with the UE. Mobility procedures are also available in connected mode. These

include Cell/URA updates and handovers.

It is important to note that no radio resources are assigned to the UE when it is in idle mode. In contrast,

while the UE is in connected mode, there may be radio resources assigned.

RRC States

2-6



RRC StatesRRC States

Camping on a UTRAN cellIDLE MODE

Release RRCConnection

Establish RRCConnection



UTRAN Connected Mode

URA_PCH Cell_PCH

Cell_DCH Cell_FACH

HSPA data transmission

2-7



For HSPA operation, the RRC model as described above is completely valid. An HSPA-active mobile is

in the CELL_DCH mode during transmission and reception of data using the associated channels. Note

that for HSDPA, the downlink channel is in reality a fully shared channel, although we still call the RRC

state CELL_DCH. The UE still needs to be assigned dedicated channels for uplink power control and use

uplink dedicated channel(s) for transmission to the network. When the UE becomes inactive for a period

of time, the RNC can decide to put the mobile in CELL_PCH or URA_PCH states, where the UE updates

the RNC with its most current cell location.

RRC States (continued)

2-8



RRC States RRC States (continued)(continued)

Camping on a UTRAN cellIDLE MODE





UTRAN Connected Mode

URA_PCH Cell_PCH

Cell_DCH Cell_FACH

HSPA data transmission

2-9



This is a key figure that explains, at a high level, the steps that a mobile (denoted as UE from here on) and

the corresponding network go through when the mobile establishes a packet session.

Two planes are discussed in this module. The control plane is established initially to create a path for

exchanging signaling information needed for service creation.

Once the control plane is established, the user plane is established. In UMTS, the Radio Access Bearer

(RAB) denotes the combination of both the radio bearer (RB) between the UTRAN and the UE, and also

the bearer between the radio and core networks (CN) referred to as the Iu Bearer. In the packet domain,

the Iu bearer is a GPRS Tunneling Protocol (GTP) tunnel. This is an essential component for providing

various types of services with different Quality of Service (QoS). A specific RAB is associated with a

specific QoS to either the circuit- or packet-switched core network.

This concept will be explored in this module.

Data Session Setup Overview

2-10



Established at system configuration

Data Session Setup OverviewData Session Setup Overview

Node B

RRC

PS-CN PDN

Iu

Radio Bearer (RB)

ControlPlane

UserPlane

GTP-U

RAB = RB + Iu (GTP) Bearer

Iub IuUu

Physical Channel AAL2 Bearer SIG/AAL5

Physical Channel AAL2 Bearer

Summary of Packet Session

UERNC

2-11



Before anything can be done in UMTS, the Radio Resource Control (RRC) connection must be

established. The RRC connection is a logical connection between the UTRAN and the UE, with the

following characteristics:

• Used to identify all UE – UTRAN signaling, whether in the circuit or packet domain

• Only one RRC connection at any time

• Used by the UTRAN to track both the location and state of the user during the life of a call or

packet data session

• The Serving RNC (SRNC) is activated upon establishment of the RRC connection

• All messages sent over this connection are part of the RRC protocol

• The UE is identified with a Radio Network Temporary Identifier (RNTI)

RRC Connection Setup

2-12



PS-CN PDNIub Iu

RRC Connection SetupRRC Connection Setup

RNCNode B

RRC

ControlPlane

Uu


RRC Connection Request


RRC Connection Setup Complete

UE is now known to the SRNC

UE

2-13



After the establishment of the RRC Connection, the UE now starts communicating with the Packet

Switched Core Network (PS-CN) by sending the Attach Request message. At this point, the RNC creates

the Iu-Connection by piggy-backing the Attach Request message on a RANAP Initial UE Message. Upon

receiving this message, which is the first message from the UE, the PS-CN likely starts the security

procedures.

Assuming successful outcome of the security procedures, the PS-CN responds to the Attach Request (sent

from the UE) with an Attach Accept. This message normally contains a new P-TMSI number allocated to

the UE. The UE, therefore, acknowledges the reception of the P-TMSI by sending the Attach Complete

message.

Iu Connection Setup Overview

2-14



PS-CN PDNIub Iu

Iu Connection Setup OverviewIu Connection Setup Overview

RNCNode B

RRC

ControlPlane

Uu


Initial DT (Attach Request)

Initial UE Message (Att. Req.)

Iu

Signaling connection to UE complete

DT (Attach Accept)

DT (Attach Complete)

Authentication and Security

UE

2-15



The control plane has been set up and that is a key requirement so that the UE can proceed with the rest of

the data session setup.

The UE has set up the control plane and now has to set up the data plane. A key component of UMTS is

the Quality of Service (QoS) requested. This affects both the core network (CN) and radio network (RN).

The CN’s primary role is to understand the request for the service and insure that the UE has rights to this

service. The UE may ask for a different QoS than what is subscribed to, and the role of the CN is to check

the subscription information to see if this is allowed. It then passes the request to the RN.

The RN, which may be an independent entity from the CN, obtains the requirements from the CN. It then

performs two key steps:

• Call admission control: The RNC understands the RN limitations, and has to work with the Node

B to ensure that they can handle the load of the new UE together

• Mobile – UTRAN communication: The RNC then establishes the Node B’s radio link and

provides the mobile with the relevant information to initialize the radio interface protocol stack

Data Session Setup

2-16



PS-CN PDNIub Iu

Data Session SetupData Session Setup

RNCNode B

RRC

ControlPlane

Uu


IuUplink DT (Activate PDP Context Request)

DT (Activate PDP Context Request)

UE requests QoSPS-CN qualifies QoS

CN/UTRAN enforce QoS

RRC

UE

2-17



This figure demonstrates the exchange of information between a mobile (UE) and the CN for a packet

service. Typically, the user subscribes to a certain type of service such as Premium class or Gold class.

These classes have a specific mapping to Quality of Service (QoS) related parameters that the mobile

exchanges with the CN.

The mobile can also choose to request parameters that are different from what it is subscribed to, and the

networks decide if they can allow such a request. In this example, the UE has requested a packet service

with a specific QoS.

Some of the key parameters are shown in this figure such as:

• Class of Service: Interactive class such as a Web service

• Throughput 64 kbps: The expected rate of data transfer of the application

• Delay – 500 ms: Indication how much delay can be tolerated in the system

• Reliability: Indication of the level of reliability needed for this service

Packet Service Request to CN

2-18



Packet Service Request to CNPacket Service Request to CN

Packet Switched

Core Network

Quality of Service

UE requests QoS

QoSrequestedby the UE

Reliability10-3 BER

Throughput64 kbps max

Delay500 msec

ClassInteractive

UE

2-19



UMTS specifications divide applications and services into four different traffic classes. These

classifications are made based on different characteristics of traffic generated by these applications. The

four traffic classes are described below. HSPA is primarily designed for operation with non-real-time

services like web browsing or downloading of files. Real-time services require further enhancements to

minimize latency, especially for roaming (non-stationary) users.

Conversational class: Speech service is the most well known application of this class. This class is

characterized by stringent low delay and preservation of time relationship (variation) between information

entities of the stream. Although speech is a well-known application of this class, there are other

applications as well. With the advent of Internet and multimedia, new applications such as Voice over IP

(VoIP) and video conferencing tools require a conversational class. Another important characteristic of the

conversational class is that traffic is mostly symmetric.

Streaming class: Real time audio or video is a good example of applications in this class. Streaming is a

technique for transferring data so time relation (variation) between different data elements is maintained.

That is, the delay variation (jitter) should be as minimal possible. The application uses buffering

techniques to smooth delay variation so that the user does not experience any jitter in audio or video.

Streaming does not have requirements of low delay. Streaming applications are asymmetric in nature. The

bandwidth requirement from server to client is much higher than the bandwidth requirement from client to

server.

Interactive class: Web browsing and mCommerce transactions are well known examples of this class.

The class is characterized by a request-response pattern. There is no requirement for maintaining time

relation or low delay. However, overall round trip delay must be within acceptable limits. Reliability is

another important requirement for this class, since any error changes the meaning of transactions.

QoS Classes and HSPA

2-20



QoSQoS Classes and HSPAClasses and HSPA

- Background download of emails

- Destination is not expecting the data within a certain time

- Preserve payload content

BackgroundBest Effort

- Web browsing

- Request response pattern


Interactive Class

Best Effort

- Streaming video

- Voice, video callExample of the application

- Preserve time relation (variation) between information entities of the stream

- Preserve time relation between entities of stream

- Conversational pattern (stringent and low delay)

FundamentalCharacteristics

Streaming Class

Real Time

Conversational Class

Real Time

TrafficClass

Initial HSPA usage

2-21



Background class: Email retrieval and file transfer are well known examples of this class. There are no

delay or time relation requirement for this class. The destination is not expecting data within a certain

time. The class uses bandwidth when other classes are not using it. The reliability of data is important as

well.

Conversational class applications are the most delay sensitive, whereas background classes are the least

delay sensitive. In general, interactive and background classes require higher reliability. This can be

achieved by providing higher channel coding and retransmissions.

QoS Classes and HSPA (continued)

2-22



QoSQoS Classes and HSPA Classes and HSPA (continued)(continued)

- Background download of emails

- Destination is not expecting the data within a certain time


BackgroundBest Effort

- Web browsing

- Request response pattern


Interactive Class

Best Effort

- Streaming video

- Voice, video callExample of the application

- Preserve time relation (variation) between information entities of the stream

- Preserve time relation between entities of stream

- Conversational pattern (stringent and low delay)

FundamentalCharacteristics

Streaming Class

Real Time

Conversational Class

Real Time

TrafficClass

Initial HSPA usage

2-23



At this point, the Node B and the Serving Radio Network Controller (SRNC) are working together to

allow packet access to the mobile. An Asynchronous Transfer Mode (ATM) ATM Adaptation Layer type

2 (AAL2) bearer is set up for the user plane. This is done using the Node B Application Part (NBAP)

protocol between the Controlling Radio Network Controller (CRNC) functionality of the Radio Network

Controller (RNC) (within the same RNC in this example) and the Node B.

Key parameters of the Radio Link Setup message:

• Uplink scrambling code

• Channelization codes (UL & DL)

• Transport format set, protection choice

• Everything needed for the NodeB to talk to and hear the UE

The SRNC now turns its attention toward the mobile to set up the various layers in the mobile for the

packet session. This is done using the RRC protocol using the existing control plane that was set up

earlier.

Radio Link Setup

2-24



PS-CN PDNIub Iu

Physical Channel

UserPlane

Radio Link SetupRadio Link Setup

RNCNode BControlPlane

Uu

IuRRC

NodeB ready to talk/listen to UE

Protocol: NBAPConfigure ASIC to communicate with UESetup Transport Format Set

AAL2 Bearer

Radio Link Setup Request

Radio Link Setup Response

Bearer Synch AAL2 Bearer allocated

RAB Assignment Request

2-25



An example of the Call Admission Control process is shown in the table, which provides an example of

the Radio Network Controller (RNC) configuration for all services by a service provider.

As seen in the table, the Serving Radio Network Controller (SRNC) chooses to allow or disallow the

call based on several reasons. Using the specified criteria, the SRNC then decides to ask the Node B if it

can create the necessary radio links required to complete this session. This is done by issuing a Node B

Application Part (NBAP) Radio Link Setup message to the Node B, which contains the request to use

HSDPA channels for this data session and the QoS requirements of this data session.

The Node B receives this message, handles the request and provides feedback to the SRNC about this

session. This feedback might allow the call or to reject the call due to congestion in the cell (too many

UEs allocated to the HS-DSCH, not enough bandwidth for a high speed HS-DSCH, too much

interference, etc.).

Call Admission Control (CAC)

2-26



Call Admission Control (CAC)Call Admission Control (CAC)

SRNC

Node B

RAB Complete

Radio Link Setup (NBAP)

Radio Link Setup Response (NBAP)

Radio Bearer Setup (RRC)

Radio Bearer Setup Response (RRC)

Inform Mobile

Call Admission Control

RAB Assignment (QoS)

PacketSwitched

Core Network

Consult Node B

UE

2-27



Once the radio link between the SRNC and the Node B has been set up, the physical channel between the

mobile and the Node B is set up. To this end, a Radio Bearer Setup message is sent.

The path of this RRC message is the same as in the voice call scenario:

DCCH (logical channel) → DCH (transport channel) → DPCH over the air

The peer RRC layer in the mobile receives this message and starts processing the information.

Key parameters of the Radio Bearer Setup message include:

• RLC parameters (PDU size, mode: Acknowledge, Transparent or Unacknowledged)

• Convolution Encoder (transport channel configuration)

• Spreading factor/channelization code (physical channel configuration)

• Transport Format Set and Transport Format Combinations

• RRC Transaction Identifier that will be used for all communications and the RRC state that the

mobile needs to be in (CELL_DCH)

• Information on Packet Data Convergence Protocol (PDCP) for the mobile.

The mobile is completely configured to provide packet data transfer using this RRC message. The

response to this message indicates if the mobile is ready for this data transfer and proceeds with other

signaling required to complete the packet data transfer.

Radio Bearer Setup

2-28



PS-CN PDNIub Iu

UserPlane

Radio Bearer SetupRadio Bearer Setup


Uu

IuRRC

RB – setup packet traffic path

Protocol: RRCPhysical Layer setup

AAL2 Bearer

Radio Bearer Setup

Radio Bearer Setup CompleteUE in

Cell_DCHstate

Physical ChannelPhysical Channel

2-29



Here is an example of how the packets coming from the core network (CN) are received by the Serving

Radio Network Controller (SRNC) and then passed down the appropriate layers.

The PDCP (Packet Data Convergence Protocol) layer principally is involved in two areas:

1. Convergence between the radio layers and the network layers for ease of transition to other

protocols or technologies in the future

2. Provides a compression mechanism negotiated with the mobile as per Internet RFC2507

The Radio Link Control (RLC) provides a reliability mechanism that is employed here for packet session

since this is NOT a delay-constrained application. This was indicated in the Quality of Service (QoS)

request that was sent up by the mobile and agreed to by the network. The acknowledged mode of the RLC

is chosen to enhance reliability.

The Medium Access Control (MAC) provides a mechanism to resolve contention and allow information

with different priorities to flow through. It also provides a mechanism to map logical channels denoted by

Dedicated Traffic Channel (DTCH) (in this figure) to a Dedicated Channel (Transport channel). It requests

information from the appropriate RLC queues and passes them on to the physical layer (which is present at

the Node B).

The Physical layer is present at the Node B and is responsible for all physical layer functions. The

transport channels received in the Node B are processed and sent over the air.

All working parameters are set up so these layers can work together and with the RRC.

RRC Configures its Layers for Downlink

2-30



PDCP

RLC

MAC

DTCH

DCH

SRNC

RRC Configures its Layers for DownlinkRRC Configures its Layers for Downlink

Traffic from Packet Core

Network

RRC state cell_DCH

RAB ID=Radio Bearer ID

Acknowledged Mode

Allowed Formats and

Protection Characteristics

DPCH

Phy

Compression algorithm based on

RFC2507

2-31



The Serving Radio Network Controller (SRNC) has two roles:

1. Create the required radio-related configurations. This has been accomplished so far with the

creation of appropriate layers in the mobile and SRNC.

2. Create the necessary associations between the core and radio network. A General Packet Radio

Service (GPRS) Tunneling Protocol (GTP) User Plane tunnel is created and this association is

used to carry packet traffic between the SRNC and core network (CN). This enables packet

transfer to be reliably handled through a private IP backbone.

Since the appropriate tunnels and traffic paths have been created, the process of creating of all the

components of a Radio Access Bearer (RAB) are completed. This results in a Radio Access Bearer (RAB)

assignment complete message, as shown, to the CN. The CN then proceeds with any completion of

signaling that is required to continue with the packet session establishment.

It is also possible that the UTRAN is not capable of handling the request or is in the process of working on

the request from the CN. For such cases, provisions exist in the standard to send a RAB assignment

response that indicates the status or outcome of the request.

Completing the RAB

2-32



PS-CN PDNIub Iu

UserPlane

Completing the RABCompleting the RAB


Uu


IuRRC

UTRAN is ready!

GTP-U

AAL2 BearerPhysical Channel

Radio Bearer (RB)

RAB Assignment Response

RAB = RB + Iu (GTP) Bearer

Create the GTP-U tunnel

2-33



At this point, all bearer channels are set up for carrying traffic. In response to the Packet Data Protocol

(PDP) Context Request from the user equipment (UE), the core network (CN) sends a PDP Context

Accept, which indicates to the mobile that the CN has provided the mobile with resources needed for

packet transfer.

The CN also provides the negotiated QoS which may or may not be the same as the requested QoS from

the mobile. The mobile may also have requested an IP address, and this is indicated in this message as

well. All the ingredients for web surfing have been completed at this point.

Surf on, Sue!

Session Setup Completion

2-34



Session Setup CompletionSession Setup Completion

RNCNode B

PS-CN PDN

ControlPlane

Iub IuUu

Iu

Let’s start surfin’!

RRC

RAB = RB + Iu (GTP) Bearer UserPlane

DT (Activate PDP Context Accept)

UE may be assigned IP address, informed of

negotiated QoS

2-35



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Summary

2-36



SummarySummary• Call setup and packet session setup share

common messaging for the UTRAN• Packet session setup is more complex than

voice calls due to variations in the QoS• The MAC layer performs multiplexing and

resource coordination• The RLC layer coordinates reliability and

performs ciphering

2-37



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Review Questions

2-38



Review QuestionsReview Questions1. What are the key differences between a

call setup and a packet session setup?2. What are the key parameters

communicated to the RNC in the RAB Assignment Request?

3. What is the purpose of the RLC layer?4. What are the differences in the physical

channel requirements between a packet session and a call?

2-39


HSPA Key Concepts

HSPAHSPA Key ConceptsKey Concepts

3-1


HSPA Key Concepts

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Objectives

3-2


HSPA Key Concepts


• Describe the fundamental difference between uplink and downlink

• Contrast the link adaptation philosophies of UMTS R99, HSDPA and HSUPA

• Describe in simple terms the meaning and principles of Hybrid ARQ and Incremental Redundancy

• Sketch at a high level the steps involved in the operations of HSUPA and HSDPA

• Contrast the allocation of resources between the two HSPA technologies

3-3


HSPA Key Concepts

There are fundamental diffeences between the uplink and downlink in CDMA-based systems. In the

downlink, orthogonal channelization codes are used to separate different channels within a cell. This

prevents one user’s data in a cell from interfering with another user’s data. The downside is that only a

limited number of codes can be allocated in a cell. Between two cells, a scrambling code is used to

separate information. Since these codes are not orthogonal, the information of one cell does interfere with

the information on another cell. Because of this interference, the transmitted power needs to be minimized

to limit the interference.

In the uplink, scrambling codes are used to separate one UE’s transmission from another. Hence,

information one user transmits interferes with data transmission from all nearby users. In addition, a

number of individual UEs transmit data on the uplink simultaneously. To maintain the uplink interference

levels within base station design limit, we need to design a better uplink resource allocation algorithm that

manages all the UE transmissions. Uplink does not suffer from code space limitations like the downlink.

The base station seprates the received signals using the scrambling code first and as a result all UEs in a

cell may use the same code set without constraints.

Uplink vs. Downlink

3-4


HSPA Key Concepts

Uplink vs. DownlinkUplink vs. Downlink

Node B

UE power limitation, interference control,no code limitation

Code limitation, orthogonal codes, and

centralized power mgmt

3-5


HSPA Key Concepts

This chart compares the different adaptation techniques between an R99 Dedicated Channel, an R5

HSDPA channel, and an R6 Enhanced Dedicated Channel.

For the R99 dedicated channel, two key mechanisms are used to adapt the link. The first mechanism

includes the inner-loop and outer-loop power control algorithms and the ability to set the channel bit rate

via a variable spreading factor. Power control is only used to maintain an acceptable channel quality at a

minimum power level. The channel bit rate is not really a form of link adaptation, but a form of setting the

channel bit rate based on the needed bandwidth of the user’s service.

For the HSDPA channels, the key form of link adaptation is adapting the modulation scheme based on the

channel conditions. In addition, not shown in this chart is the ability to use Hybrid ARQ to minimize the

amount of protection information transmitted over the air.

With HSUPA channels (i.e., the E-DCH), power control and channel bit rate adaptation are used as in

R99. One key difference is that the channel bit rate can be varied by the UE independent of the RNC

based on the channel conditions and the amount of data that is needed. Also, added to HSUPA is the

requirement on the UE to help manage the UL interference based on feedback from the network.

HSDPA and HSUPA both use dynamic scheduling to achieve higher spectral efficiency and throughput

while adapting to current channel conditions.

Link Adaptation Techniques

3-6


HSPA Key Concepts

Link Adaptation TechniquesLink Adaptation Techniques

Power control Channel bit rate (Variable Spreading

Factor)

ONR99

R5 HSDPA

R6 HSUPA

ON

OFF OFF

ONON

Dynamic Scheduling

OFF

ON

ON

Variables

Adaptive Modulation

OFF

ON

OFF

3-7


HSPA Key Concepts

The figure depicts the conceptual operation of Hybrid ARQ.

The user bits are turbo-coded and properly interleaved and repeated to form a coded symbol sequence.

This coded symbol sequence is separated into 3 streams of data which are called the systematic, parity1

and parity 2 bits.

Next, the transmitter selects some of these symbols to be transmitted to the receiver. In the first

transmission, the HARQ process prioritizes the systematic bits. Typically, the first transmission has a 90%

chance of success. This portion is sent to the receiver. The receiver decodes these symbols and tries to

determine the original user bits by matching them with a possible physical layer CRC value. In this

example, we show that the receiver has not been able to decode the user bits completely and sends a

negative acknowledgement (NACK) to the transmitter.

After receiving a NACK, the transmitter again sends some more symbols from the coded symbol sequence

– parity 1. The receiver now combines symbols of both systematic and parity bits and decodes them to

figure out the original user bits.

This process continues until the receiver successfully decodes the symbols and sends an acknowledgement

(ACK), or until the transmitter decides to stop sending the coded symbols, whereby the upper layers (i.e.,

RLC or TCP) try to recover from the errors.

Hybrid ARQ Operation

3-8


HSPA Key Concepts

Hybrid ARQ OperationHybrid ARQ Operation

Receiver

Coded Symbol Sequence

NACK ACK

Transmitter

Systematic bits Parity1 Parity2

Systematic bits Parity1

Parity1Systematic bits

Systematic bitsReceiver Buffer

Parity1

Decoded Symbol Sequence

No need to send P2

3-9


HSPA Key Concepts

Let’s discuss how the HSDPA High Speed Downlink Shared Channel (HS-DSCH) operates at a 10,000

foot level. Multiple UEs may be assigned to the HS-DSCH by the RNC since it is a shared channel. HS-

DSCH operations may be summarized in the following 4-step procedure:

1. The first step in the HS-DSCH operation sequence is the Carrier-to-Interference (C/I) reporting by

all the UEs assigned to the HS-DSCH. Each mobile on the HS-DSCH measures its radio

conditions and provides the Node B with an accurate idea of the current receiving condition. The

Node B gathers the C/I report from all the UEs before proceeding to the next step. The UEs may

report the C/I value once every 2 milliseconds.

2. The scheduler is executed at the Node B to determine which user’s data should be transmitted

next. The standards do not specify the scheduling algorithm. Hence, the scheduling algorithm and

the assignment approach differ from one implementation to another.

3. The data is transmitted to the selected user. When the scheduler selects a user, it uses the C/I value

reported by the UE and the data buffer waiting for transmission to determine the data rate and

modulation scheme for the transmission. The Node B uses the selected configuration to send the

data over-the-air.

4. The UE receives the data and verifies the checksum. If the transmission was received properly, the

UE (who received the data) transmits an ACK to the Node B. If the transmitted information was

received with errors, the UE sends a NACK to the Node B.

These steps are repeated continuously to support the HS-DSCH effectively.

HSDPA Process Overview

3-10


HSPA Key Concepts

HSDPA Process OverviewHSDPA Process Overview

High-Speed Data Transmission

Node B

ACK/NAK

12

3

4

SchedulerSupporting Control Information

Run the Scheduling Algorithm

Channel Quality1

1

UE 1

UE 2

UE 3

Channel Quality

Channel Quality

UE 1

UE 1

---- 10101010101

3-11


HSPA Key Concepts

In HSDPA, the RAN can use a portion of downlink capacity as a shared channel in Time Division

Multiplexed (TDM) or Code Division Multiplexed (CDM) mode.

The serving Node B continuously receives the radio condition reports (CQIs) from all the UEs that are

requesting a higher data rate in the downlink. The Node B collects this information, and, based on several

other factors such as availability of user data, QoS, available transmit power, etc., schedules the downlink

transmission of packets to all the UEs over the shared channel. Short scheduling time units are used to

reduce inefficiencies and waste of the radio resources.

In TDM, a resource is utilized by different entities (e.g., UEs) at different times. In an HSDPA system, the

high speed channel transmits data in 2 ms intervals. When this channel utilizes TDM, only one user is

given data during a TTI. In the example shown here, the 2 ms TTI is given to User 3 first. No data is

transmitted on the high speed channel to any other user during this TTI. In the third 2 ms TTI, User 2 is

given data using the high speed channel. In the fifth 2 ms TTI, User 1 is given data on the high speed

channel. A different number of OVSF codes (at SF= 16) can be assigned to different users at different

times. The advantage of the TDM approach is simple implementation, but the disadvantage is that other

users need to wait to receive data on the high speed channel. For this reason, HSDPA also supports the

Code Division Multiplexing mode of operation. In CDM, a resource is utilized by different entities (e.g.,

UEs) at exactly the same time. When this channel utilizes CDM, multiple users receive data during a given

TTI. In the example shown here, in the second 2 ms TTI, User 1 and User 2 simultaneously receive data.

In the fourth 2 ms TTI, User 3 and User 2 are given data using the high speed channel. A different number

of OVSF codes (at SF= 16) can be assigned to different users during the same TTI, as well as during

different TTIs. The advantage of the combined TDM and CDM approach is more flexibility serving users

since the users requiring short latency (or delay) do not need to wait as long as they would if only TDM

were available. The disadvantage of the combined TDM-CDM approach is the complexity of

implementation. Note that HSDPA transmission in the downlink is completely asynchronous (i.e., the

packets sent on each TTI can be assigned to a UE at any time so that all the active UEs must be constantly

listening to the signaled scheduling information to find out whether a transmission is directed to them).

Asynchronous Transmission in HSDPA using CDM/TDM

3-12


HSPA Key Concepts

Asynchronous Transmission in Asynchronous Transmission in HSDPA using CDM/TDMHSDPA using CDM/TDM

Node B

UE1

UE2

UE3

CQI

CQI

CQI

Downlink Transmission

UE3. . .UE2

UE2 UE1UE2

UE1UE3

3-13


HSPA Key Concepts

A Node B is configured for certain transmit power (i.e., 20 to 40 watts). Some portion of this power is

allocated to control or overhead channels such as the Pilot, Forward Access Channel (FACH), and Paging

Channel (PCH). The remaining power is dynamically allocated to all the active users for their forward

traffic channels. Here the users at the edge of the sector, due to inferior channel conditions or to combat

other interference sources, need higher power to compensate for path loss. Similarly, the users near the

center of the sector are allocated much less power to their forward traffic channels. Since voice traffic

needs roughly a constant data rate, link adaptation is achieved through the change in transmit power. This

is called “fixed rate variable power” where the sector varies the transmit power but maintains a fixed

throughput to the user no matter where the user is located.

As depicted in the figure, the available transmit power is not utilized maximally at all times in a UMTS

R99 system. Since HSDPA systems are designed to support both voice and higher data rate packet data

users simultaneously, they need to support the downlink power management philosophy from UMTS R99

as well as add an efficient way to use the remaining power to provide high speed data. For voice and

medium rate data users, HSDPA systems maintain the traffic frame rate and adjust the transmit power by

performing fast downlink power control. This allows the HSDPA system to serve multiple voice users

with a symmetric low data rate bandwidth requirement.

However, for high-speed data users, the HSDPA system adopts the philosophy of allocating the remaining

available transmit power to a single user at any given time and adjusting the data rate based on the channel

conditions observed by the data user.

In other words, for voice and medium rate data users, the HSDPA system adjusts its transmit power, and

for higher rate data users, it adjusts its downlink data rate to accommodate varied radio conditions

observed by the users throughout the cell.

Power Management in HSDPA

3-14


HSPA Key Concepts

Power Management in HSDPAPower Management in HSDPA

TransmitPower

Time

MaxTDM/CDM Packet

Data ChannelU1 U2 U3U4

Overhead Channels

Voice and R99 data usersDOWNLINK

2ms

Available Pwr

Unused power in R99can be used for HSDPA

• Only ONE Node B transmits High Speed Channel

• Power assigned from a single CELL only

3-15


HSPA Key Concepts

In a UMTS R99 system, the downlink channels are identified by a unique Spreading Factor (SF) code on

the Orthogonal Variable Spreading Factor tree (OVSF). The SF codes vary in length from 4 bits to 512

bits. The SF codes are generated as shown. Out of these SF codes, certain codes are reserved for control

channels such as the pilot channel or the channel that broadcasts the system information broadcast for the

cell. The total number of OVSF codes at a given SF is the same as the SF. For example, there are 8

orthogonal codes at SF = 8. The HSDPA system uses the fixed SF of 16. There are 16 OVSF codes at SF

= 16. A maximum of 15 OVSF codes at SF = 16 can be used for HSDPA. These 15 codes can be assigned

to a single user during a TTI, or they can be shared among multiple users during the TTI. The voice users

and the HSDPA users share the same OVSF code tree.

Since HSDPA supports both voice and higher rate packet data users, spreading factor code management

becomes very critical. SFs for voice users are typically 128 bits in length. However, for high rate data

users, the length of the spreading factor codes can be quite short (up to 4 bits) for Dedicated Physical

Channels (DPCH) in UMTS R99 systems.

Thus, the co-existence of voice users and packet data users, both based on DPCH and HSDPA packet data

channels, poses important challenges for spreading factor code management.

OVSF Code Tree for HSDPA

3-16


HSPA Key Concepts

OVSF Code Tree for HSDPAOVSF Code Tree for HSDPA

C 1,0 = (1)

C 2,0 = (1, 1)

C 2,1 = (1,-1)

C 4,0 = (1, 1, 1, 1)

C 4,1 = (1, 1,-1,-1)

C 4,2 = (1,-1, 1,-1)

C 4,3 = (1,-1,-1, 1)

SF = 1

C 8,0

C 8,1

C 8,2

C 8,3

C 8,4

C 8,5

C 8,6

C 8,7

SF = 2 SF = 4 SF = 8

15 codes with SF=16 are available for HSDPA

…SF =16

C 16,0

HSDPA

SF = 32

3-17


HSPA Key Concepts

HSDPA systems achieve higher data rates for packet data services by introducing a number of

optimizations over the air. These optimizations are:

Fat-pipe scheduling: HSDPA systems use fat-pipe scheduling to achieve higher data rates. Time Division

Multiplexing (TDM) on new packet data channels is introduced in HSDPA. The entire set of packet data

channels is allocated to a single user for a specific duration. This allows the system to support 14 Mbps

services to users.

Dynamic channel estimation: The HSDPA system is based on the “variable power variable rate”

principle. The mobile station estimates and reports the channel quality for every scheduling period.

Higher order and adaptive modulation: HSDPA systems use higher order modulation techniques such

as Quadrature Phase Shift Keying (QPSK) and 16QAM (Quadrature Amplitude Modulation). The higher

order modulation schemes enable the system to push more bits through the air. The selection of

modulation is dynamic. That is, in every scheduling period, one of the modulation schemes is used based

on the existing radio conditions. The support for QPSK is mandatory, while the support for 16QAM is

optional.

Early acknowledgement schemes: Early acknowledgement is one of the Hybrid Automatic Repeat

reQuest (HARQ) schemes. The network schedules packet transmission to the system every scheduling

period. If the packet is successfully transmitted before the scheduled period is over, the remaining time

may be used for the next packet. Thus, the spectrum utilization is quite efficient.

Effective use of residual power: In HSDPA, power for transmission of high-speed channels in the

downlink is normally taken from the remaining power in the base station. This method of power allocation

in the cell makes effective use of power resources and avoids any intervention with power resources

allocated to other channels (like voice channels). However, the use of remaining power in the base station

limits the possibility of doing efficient power control in the downlink.

High Data Rate – Top Contributors

3-18


HSPA Key Concepts

High Data Rate High Data Rate –– Top ContributorsTop Contributors

Adaptive and Higher Order Modulation

Dynamic Channel Estimation

& Fast Feedback

Early Acknowledgement and Incremental

RedundancyChannel-sensitive

& Fat PipeScheduling

Effective Use of Residual Power in

the Downlink

IncreasedSpectral Efficiency

& Throughput

3-19


HSPA Key Concepts

HSUPA systems achieve higher data rates for packet data services by introducing a number of

optimizations over the air. These optimizations are:

Flexible bandwidth scheduling: HSUPA systems use a flexible bandwidth scheduling scheme to achieve

higher data rates. In the uplink, the UE’s transmit power varies based on the current channel conditions,

QoS requirements, and the amount of data that needs to be transmitted.

Dynamic & fast scheduling: The HSUPA system is based on the “variable power variable rate” principle.

The base station understands the needs of the UE and the current uplink interference level, and sends an

allocation of allowed uplink radio resources for the UE to use.

Early acknowledgement schemes: As with HSDPA, HSUPA utilizes the early acknowledgement scheme

of the Hybrid Automatic Repeat reQuest (HARQ). The UE schedules packet transmission to the system

every scheduling period. If the packet is successfully transmitted before the scheduled period is over, the

rest of the time may be used for the next packet. Thus, spectrum utilization is quite efficient.

Effective management of uplink interference: In HSUPA, power for transmission of high-speed

channels in the uplink is normally taken from available remaining power. This method of power allocation

in the cell makes effective use of power resources and avoids any intervention with power resources

allocated to other channels (like voice channels). The use of remaining power in the cell, however, limits

the possibility of performing efficient power control in the uplink.

High Data Rate – Top Contributors

3-20


HSPA Key Concepts

High Data Rate High Data Rate –– Top ContributorsTop Contributors

Dynamic schedule requests

& Fast scheduling

Early Acknowledgement and Incremental

Redundancy

Channel-sensitive & Flexible BandwidthScheduling

Effective Management of

Uplink Interference

IncreasedSpectral Efficiency

& Throughput

3-21


HSPA Key Concepts

The HSUPA process can be described in five basic steps. Note that the duration of time between the first

and last step is in the order of 10 ms.

1. The UE makes a scheduling request.

2. The scheduling requests of all of the UEs are received by the serving Node B. These requests

become important inputs to the scheduler algorithm in the Node B. The scheduler’s main task is

to determine the amount of power to allocate to each UE. The standards do not specify the

scheduling algorithm. Hence, the scheduling algorithm and the assignment approach differ from

one implementation to another.

3. Resources are granted to the selected users. When the scheduler selects a set of users, it uses the

uplink channel quality and the data bandwidth requests from the UE to decide the resource

allocation. The Node B signals the resource allowances over the air to the UEs.

4. The UE sends the data to the Node B which verifies the checksum.

5. If the transmission was received properly, the Node B (who received the data) transmits an ACK

to the UE. If the transmitted information was received with errors, the Node B sends a NACK to

the Node B.

These steps are repeated continuously to support the high-speed process effectively.

The HSUPA Process Overview

3-22


HSPA Key Concepts

The HSUPA Process OverviewThe HSUPA Process Overview

Serving Node B

Scheduling Request1

Scheduler


3 Granting allowed resources

High Speed Data+Associated signaling

4

ACK/NACK5

Node B

Node B

2

3-23


HSPA Key Concepts

When a UE transmits, it adds to the total interference in the uplink. As a result, an acceptable threshold

limit needs to be set. This limit is called the Rise over Thermal Threshold. It represents the amount of

interference that can be added to the uplink frequency above the thermal noise before the interference

becomes too high to decode any uplink information.

All of the UEs currently transmitting information on channels in other cells contribute to this interference.

Other sources of interference include, the UEs transmitting on dedicated channels in the cell in question

and the sum of the users that are transmitting on the E-DCH channels. As was have seen in HSDPA, the

goal is to share the available power that remains after allocating dedicated channels for high-speed packet

data (in this case it is for uplink high-speed packet data.).

The uplink interference management designed for HSUPA is used to manage the available power

efficiently to maximize the amount of data that can be transmitted in the uplink without sacrificing the

channel quality for the users that have been assigned dedicated channels (i.e., the voice calls).

UL Power/Interference Management

3-24


HSPA Key Concepts

UL Power/Interference ManagementUL Power/Interference Management

Thermal Noise

UEs on other cells

UE 1

UE 2UE n

Noise due to E-DCH channels

RoT Threshold

Each UE adds to the noise level. The noise level must be managed so that it stays below a threshold

Node B

3-25


HSPA Key Concepts

In a UMTS R99 system, the downlink channels are identified by a unique Spreading Factor (SF) code on

the Orthogonal Variable Spreading Factor tree (OVSF). The SF codes vary in length from 4 bits to 512

bits. The SF codes are generated as shown. Out of these SF codes, certain codes are reserved for control

channels such as the common pilot, and primary and secondary common control channels.

Since HSUPA supports a range of rates for packet data users, SF code selection is critical in determining

the achievable data rate. HSUPA uses a spreading factor of length 2 bits on the uplink to achieve high data

rates. When lower data rates are required, HSUPA uses higher length spreading codes. The peak rate of

5.76 Mbps in HSUPA requires he use of a 2-bit and a 4-bit spreading factor. The lowest data rate in

HSUPA is 15 kbps, and the corresponding spreading factor is 256 bits long.

OVSF Code Tree for HSUPA

3-26


HSPA Key Concepts

OVSF Code Tree for HSUPAOVSF Code Tree for HSUPA

C 1,0 = (1)

C 2,0 = (1, 1)

C 2,1 = (1,-1)

C 4,0 = (1, 1, 1, 1)

C 4,1 = (1, 1,-1,-1)

C 4,2 = (1,-1, 1,-1)

C 4,3 = (1,-1,-1, 1)

SF = 1

C 8,0

C 8,1

C 8,2

C 8,3

C 8,4

C 8,5

C 8,6

C 8,7

SF = 2 SF = 4 SF = 8

…

SF = 16 SF = 256…

These codes are used for max data rates in HSUPA

3-27


HSPA Key Concepts

Hybrid ARQ is defined for the downlink in R5 (HSDPA) and for the uplink in R6 (HSUPA). While they

have a lot of similarities in how they function, there is a key difference. In R5 HSDPA, HARQ is strictly

asynchronus. In other words, there is no fixed time relationship between two successive subpacket

transmissions. The HSDPA scheduler decides when a certain subpacket may be sent, and the scheduler

has full discretion to decide how many subpackets it will transmit for a given packet.

In R6, HSUPA is defined with strict timing relationship between subpackets of a given packet. This is

done to help with UE implementation. Each MAC flow is defined at radio bearer setup time with a

maximum number of HARQ retransmissions. The physical layer definition in the standards define a strict

timing relationship between two subpackets. For a 2 ms TTI, two subpacket transmission start times are

exactly 16 ms apart. For a 10 ms TTI, the inter subpacket start interval is defined as 40 ms. Unless a

positive ACK obviates the need for a subsequent subpacket, the next subpacket is sent using the

previously mentioned timing relationship.

Synchronous HARQ in UL

3-28


HSPA Key Concepts

Synchronous HARQ in ULSynchronous HARQ in UL

P2

SP2

P1

SP2

P2

SP1

P1

SP1

Fixed

Fixed

• Asynchronus in HSDPA & strictly synchronous in HSUPA• Inter subpacket interval is defined as:

- 2 ms TTI: 16ms- 10 ms TTI: 40ms

3-29


HSPA Key Concepts

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Summary

3-30


HSPA Key Concepts

SummarySummary• HSDPA and HSUPA use different link

adaptation techniques• HSDPA uses a fixed SF and adaptive

modulation• HSUPA uses variable SF and fixed modulation• Both technologies rely on a fast scheduling

mechanism• HSDPA operation is asynchronous on the

network side • HSUPA operation is fully synchronous

3-31


HSPA Key Concepts

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Review Questions

3-32


HSPA Key Concepts

Review QuestionsReview Questions1. Compare link adaptation in R99, R5 and

R6.2. Explain major differences between the UL

and DL.3. How does HARQ operate?4. Give a summary of HSDPA operations?5. How are OVSF codes used in HSPA?6. Why does HSDPA operate asynchronously

while HSUPA operation is synchronous?

3-33


HSDPA Data Call Setup

HSDPA HSDPA Data Call SetupData Call Setup

4-1



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Objectives

4-2




• List the RRC and radio bearer setup enhancements

• List the channel assigned during the HSDPA call• Describe how the UE selects the CQI during an

HSDPA data call• List the various types of radio reconfigurations

used during HSDPA data call set up• Describe the operation of the various types of

handover in HSDPA

4-3



The support of the HSDPA feature requires enhancement in RRC, MAC and physical layer protocols.

Some of the major RRC enhancement procedures required are mentioned below. The requirements vary

between R5 and R6 implementation.

1. RRC connection establishment needs enhancement to support HSDPA capabilities on the UE side

and assignment of signaling radio bearers for the control plane.

2. A new transport channel and both UL and DL channels have been introduced for HSDPA support.

The RRC has to be enhanced to assign these new channels for both uplink (control) and downlink

(control and user data).

3. Radio bearer setup and reconfiguration have been enhanced to configure logical channels, HS-

DSCH transport channels and physical channels according to QoS requested by the core network.

4. HSDPA employs Adaptive Modulation and Coding (AMC) techniques to support high speed

downlink data. To provide the best possible QoS to the user, the UTRAN requires feedback from

the UE about the downlink radio conditions. The UE periodically sends Channel Quality Indicator

(CQI) reports on the UL to the Node B. The Node B uses this as one of the parameters to schedule

the downlink data in the next TTI (Transmission timing interval ) for that UE. There are 31 CQI

values for each UE category.

5. The RRC decides, coordinates and executes handovers during an HSDPA call. This can be within

sectors of the serving Node B or Inter Node B/Inter RNC.

The MAC layer is also enhanced to support downlink data scheduling and handling of priority data based

on QoS. The MAC-d has been enhanced to support different MAC-d flows from different logical channels

and their priority. The MAC-hs has been introduced in HSDPA for scheduling downlink data and it is

located at the Node B. Based on CQI reports sent by the UE, QoS requested, and UE categories, the

MAC-hs executes an algorithm to schedule downlink data, which can be sent every 2 ms TTI.

HSDPA Enhancements

4-4



HSDPA EnhancementsHSDPA Enhancements

RRC Enhancements

CQI selectionHARQ + IR

Handover Procedures

(Best cell change)

DL SchedulingPower management

UE-RRCRNC-RRC

Node B

MAC-hs/Modulation RL Setup changes

Radio Bearer Enhancements

4-5



The figure depicts an overview of the procedures involved in the data call setup scenario. The first

mandatory procedure is to set up resources for the control plane. Therefore, the scenario starts with the

RRC Connection Establishment to create the UE-UTRAN signaling connection. Once the RRC

connection has been established, the UE contacts the Core Network (CN) using the first NAS message

(here called Service Request). As usual, the CN may or may not initiate the security procedures like

Authentication. Assuming that the outcome has been successful, the UE starts the login procedure, which

also is a request for an IP address. This procedure is called PDP Context Activation, which also involves

the negotiation of the QoS parameters.

After a successful negotiation, the SGSN triggers the setup of resources for the user plane using the RAB

Assignment procedure. Here, we assume that, based on the QoS parameters, the RNC always sets the cell

DCH to be the RRC state for the UE to establish the HSDPA radio bearer. Therefore, it starts the Radio

Link Setup procedure toward the Node B on the Iub interface. Once the RNC and the Node B have further

synchronized the bearer, the RNC can start the Radio Bearer Setup procedure over the air interface. The

PDP context procedure is finalized with an Accept message sent by the SGSN to the UE.


4-6



HSDPA Data Call SetupHSDPA Data Call SetupUE RNC GGSN

1. RRC Connection Establishment

2. Service Request

3. Security Procedures

4. PDP Context Activation Request

6. RL Setup 5. RAB Assignment

7. Radio Bearer Setup

Node B SGSN

Bearer Synch

8. PDP Context Accept

4-7



The first step to start the HSDPA data call scenario is the creation of resources for the control plane.

Between the UE and UTRAN this is done according to the RRC Connection Establishment. RRC

connection establishment is enhanced in R5 to support HSDPA functionality. RRC connection

establishment involves 3 steps:

1. RRC Connection Request sent by the UE (Reference specs 25.331):

This message is sent on the RACH Transport channel. The UE sends its

• Initial Identity: PTMSI, TMSI and Routing area Identity (RAI)

• Establishment Cause: Originating streaming call, originating interactive call, originating

background call, etc.

• Support of access stratum of higher releases than REL 99, in this case R5

• No HSDPA-related parameters are sent in this message in R5

2. RRC Connection Setup sent by the UTRAN (Reference specs 25.331)

This message is sent by the RNC to the UE on the FACH transport channel. The UTRAN sends

the following to the UE:

• Various Signaling Radio Bearer (SRB) information to be set up - mapping of logical

transport and physical channels

• The UE ID and UTRAN –RNTI (U-RNTI)

• The RRC indicator for the UE (e.g., Cell DCH)

• UE Capability Requirement: If set to “True”, then the UE has to send its Radio access

capabilities when it responds to this message

• No HSDPA-capable parameters are sent in this message

RRC Connection Enhancement - R5

4-8



RRC Connection Enhancement RRC Connection Enhancement -- R5R5UE RNC

1. RRC Connection Request

2. RRC Connection Setup

• Capability update required?

3. RRC Connection Complete

• HS-DSCH Physical layer category

No HSDPA Related Parameters

4-9



3. RRC Connection Complete (Reference specs 25.331)

The UE now enters the Cell DCH state and sends the last RRC message, RRC Connection Setup

Complete, for the establishment of the RRC Connection. It sends the CN domain ID and, if asked

in the RRC Connection Setup, its Radio Access Capability. This message is sent using the RLC-

AM, and the RNC responds with an RLC Status PDU (an acknowledgement) to handshake the

start of the acknowledge mode with the UE. The UE sends the radio access capability, which

contains:

• Downlink capability with simultaneous configuration (32,64,128,384 kbps)

• Physical channel capability, which indicates the support for the HS-PDSCH and physical

layer category (UE categories 1-12). Each UE category indicates the maximum number of

HS-DSCH codes it can receive (minimum inter–TTI interval, maximum number of bits a

HS-DSCH transport block can receive within an HS-DSCH TTI and total number of soft

channel bits). The Node B uses this as one of the key inputs to its scheduling algorithm.

RRC Connection Enhancement - R5 (continued)

4-10



RRC Connection Enhancement RRC Connection Enhancement -- R5 R5 (continued)(continued)UE RNC

1. RRC Connection Request

2. RRC Connection Setup

• Capability update required?

3. RRC Connection Complete

• HS-DSCH Physical layer category

No HSDPA Related Parameters

4-11



The Service Request is defined as the Initial Direct Transfer message in UMTS. It is sent to the RNC by

the UE containing the UE identity in the PS domain (P-TMSI), a reference number to the latest

authentication procedure (Key Set Information (KSI)) and the type of service (Signaling).

On receiving the Initial Direct Transfer (Service Request) from the UE, the RNC further transfers the

request to the SGSN using a Connection Oriented message to set up the Iu connection.

The SGSN in response starts authentication and security procedures. This includes the security mode

command, which includes the specified ciphering and integrity protection algorithm to be used by the

UTRAN along with the keys used for the same. Once the security procedures are completed, all

subsequent signaling and the data is sent securely over the air interface.

When all the bearer channels are setup for carrying traffic, the UE sends the SM Activate PDP Context

Request for SGSN. This is carried by the RRC Direct Transfer message, which is sent over the Iu interface

by the RANAP protocol. The message describes the service that the UE wants to activate and contains the

requested QoS profile. The message includes an NSAPI, which is added to identify this PDP context. To

communicate with the PS Domain, it is essential to have information regarding the IP address. It also

includes the requested PDP address parameter and Access Point Name (APN), which determines the entity

that allocates the IP address. The message also includes the Logical Link Control Service Access Point

Identifier (LLC- SAPI).

The SGSN now receives the Activate PDP Context message from the RNC using the RANAP DT over Iu

connection. Once it receives the request, it first uses the APN to find the GGSN, and then starts a

“handshake’ with the GGSN to negotiate the QoS parameters and create the GTP tunnel.

In response, the GGSN sends a Create PDP CTX Request to the RNC, indicating that the core network has

provided the mobile with resources needed for packet transfer. The message also includes the negotiated

QoS profile with the UE IP address. Since we are going to create a GTP tunnel, the tunnel endpoint

identity (TEIDS) and GGSN IP address are also sent.

When compared to R99, no changes are required in the service request to support HSDPA. The only

difference is that a higher QoS can be supported.

Service Request

4-12



Service RequestService RequestUE RNC GGSNInit. Dir. Transfer (Service Req.)

CR[IUM (Service Req.)]

UL DT (Activate PDP CTX Req.)

DT (Act. PDP CTX Req.)

SGSN

Create PDP CTX Req.

Security Procedures

Create PDP CTX Resp.

Check subscription: APN & QoS

Use APN GGSN addr

No changes for HSDPA except that higher QoS canbe negotiated

4-13



When the service between GGSN and SGSN is negotiated with a specific Quality of Service (QoS)

profile, the SGSN sends a RANAP RAB Assignment Request message to the RNC to set up user plane

resources.

The RAB Assignment is the mechanism for the CN to notify the UTRAN of the appropriate QoS and

attributes required to deliver the service. This request is translated into a Radio Link Setup Request sent

from the Radio Network Controller (RNC) to the Node B via Node B Application Part (NBAP) signaling,

and eventually a Radio Bearer Setup message sent from the RNC to the User Equipment (UE) via Radio

Resource Control (RRC) signaling. Once the radio resources have been assigned and set up, the RAB

Assignment Response completes the RAB by setting up the Iu (GTP) between the SGSN and RNC in the

case of a packet-switched data call, this is an ATM Adaptation Layer Type 5 (AAL5) connection.

Radio Access Bearer Assignment

4-14



UserPlane

Radio Access Bearer AssignmentRadio Access Bearer Assignment

RNCNode B

PS-CN PSTN

ControlPlane

Iub IuUu

IuRRC

Setup Radio Link


Setup Radio Bearer

Iu/AAL5

Complete the RAB

Radio Bearer (RB)

UE

RAB RB+Iu (GTP) bearer defines required QoS

4-15



When the RAB Assignment Request is sent by the Core Network (CN) to the RNC, which includes the

RAB ID and QoS that will indicate a need for relatively high bit rates in downlink. Some additional

inquiry regarding UE capability is required in R5/6 to support HSDPA.

If the UE Capability was not received during the RRC Connection Complete message, the UTRAN asks

for the mobile capability using the UE Capability Inquiry message. The most interesting information

element here, for the RNC, is the so-called “UE Category”.

Since the RNC has requested a capability update, the UE sends the UE Capability Information. The most

valuable piece of information here is whether the UE supports HSDPA and, if so, its category. These

parameters are included in the DL Capability with Simultaneous HS-DSCH Configuration and the

Physical Channel Capability.

UE Capability

4-16



UE CapabilityUE Capability

Node B

UE

RNC

UE Capability Inquiry

CN

RAB Assignmt Req.

UE Capability Information

Only if not sent in RRC

Connection Establishment

4-17



The figure describes the architecture of the MAC and functional split required to support HS-DSCH on the

UTRAN side. As shown in the example, the logical channels are based on QoS, and associated with user

data. This diagram shows 4 logical channels: DTCH1,DTCH 2,DTCH 3 and DCCH. These Logical

channels are multiplexed to produce MAC-d PDUs.

• C/T MUX: The function includes the C/T field when multiplexing several dedicated logical

channels onto one MAC-d flow.

• MAC –d Flow: It is a flow of MAC –d PDUs belonging to logical channels that are MAC-d

multiplexed. These MAC-d PDUs that have multiplexed data from several logical channels that

are called MAC-d flows.

In our example, DTCH 1 and DTCH 2 are multiplexed to produce one MAC-d flow named MAC-d flow

1, and DTCH 3 and DCCH are multiplexed to produce MAC-d flow 2.

The RNC then sends the configuration parameters to the Node B on the Radio Link Setup Request over

the Iub interface using the Node B Application Part (NBAP) protocol which includes the following:

• Associated MAC-d Flows with MAC-d Flow ID: Each MAC-d flow is identified by a MAC-d

flow identifier on the QoS and application.

• Priority queue identifier: Each MAC-d flow can have several priority queues, which are

identified by the priority queue ID.

UTRAN MAC

4-18



UTRAN MAC UTRAN MAC

MAC-d Flow: 1

RNCNode B

MAC-hs

RL Setup Request

PriorityQueue

PriorityQueue

PriorityQueue

PriorityQueue

Priority queue distribution

HARQ ENTITY

TFRC Selection

HS-DSCH

DTCH 1 DTCH 2 DCCHDTCH 3

C/T MUX

MAC-d flow: 1 MAC-d Flow: 2

ConfigureConfigure• Associated MAC-d flows with identifiers• Priority queue identifiers

MAC- d

C/T MUX

4-19



The MAC-hs layer has the following functional blocks:

• Priority Queue Distribution: This function manages HS-DSCH resources between HARQ

entities and data flows according to their priority class. It sets the priority class identifier and

Transmission Sequence Number (TSN) for each new data block being serviced. The TSN is sent

on the MAC-hs header to the UE by the Node B.

• Priority Queue: The MAC-hs, based on priority of flows, stores this data in priority queues which

are designated with the unique queue identifier.

• HARQ: One HARQ entity handles the hybrid ARQ functionality for one user and is capable of

supporting multiple instances (HARQ process) of stop and wait HARQ protocols. There is one

HARQ process per TTI.

• TFRC Selection: It performs the selection of an appropriate transport format and resource

combination for the data to be transmitted on the HS-DSCH.

UTRAN MAC (continued)

4-20



UTRAN MAC UTRAN MAC (continued)(continued)

MAC-d Flow: 1

RNCNode B

MAC-hs

RL Setup Request

PriorityQueue

PriorityQueue

PriorityQueue

PriorityQueue

Priority queue distribution

HARQ ENTITY

TFRC Selection

HS-DSCH

DTCH 1 DTCH 2 DCCHDTCH 3

C/T MUX

MAC-d flow: 1 MAC-d Flow: 2

ConfigureConfigure• Associated MAC-d flows with identifiers• Priority queue identifiers

MAC- d

C/T MUX

4-21



The figure illustrates the architecture of the MAC on the UE side.

The UE receives the data and performs physical layer functions, such as demodulation, based on

Modulation type, descrambling, and despreading of OVSF codes.

• HARQ: The HARQ functional entity is responsible for handling all tasks required for Hybrid

ARQ and for generating ACKs or NACKs.

• Reordering Queue Distribution: Its function is to route the MAC-hs PDUs to the correct re-

ordering buffer based on the Queue ID. The re-ordering buffer reorders received MAC-hs PDUs

according to the received TSN. The TSN and Queue ID are part of the MAC-hs headers

• Dis-assembler :The dis-assembler is responsible for the disassembly of MAC-hs PDUs. When a

MAC-hs PDU is disassembled, the MAC-hs header is removed, and the MAC-d PDUs are

delivered to a higher layer.

• MAC –d Flow: It is a flow of MAC–d PDUs that belong to logical channels which are MAC-d

multiplexed. These MAC-d PDUs, which have multiplexed data from several logical channels,

are called MAC-d flows.

• C/T MUX: It is used to de-multiplex a MAC-d flow into several logical channels.

In our example, MAC- d flow 1 is de-multiplexed into the corresponding logical channels DTCH1 and

DTCH2. MAC-d flow 2 is de-multiplexed into the corresponding logical channels DTCH3 and DCCH.

The RNC configures the UE with logical channel identifiers, associated MAC-d flows and priority queue

identifiers in the Radio Bearer Setup message.

UE MAC

4-22



UE MACUE MAC

• Associated MAC-d flows with identifiers• Priority Queue identifiers• Logical channel IDs• HARQ Processes

DCCHDTCH 1 DTCH 2 DTCH 3

MAC-d

Flow: 1 Flow: 2

MAC-hs

C/T MUXC/T MUX

RNC

RRC RRCRadio Bearer Setup

Configure

MAC-d

UE

MAC-d

4-23



The High Speed Shared Control Channel (HS-SCCH) is the control channel associated with the HS-

DSCH. The HS-SCCH transmits the HS-DSCH channel allocation information including the user

identification, codes allocated and the modulation scheme of the current burst. Since the HS-SCCH is

associated with the HS-DSCH, it exists only on the downlink. The HS-SCCH transmits HS-DSCH

allocation information 1.3 ms before the HS-DSCH burst is transmitted. In other words, the HS-DSCH

content-related control information is transmitted over the air slightly ahead of the HS-DSCH data

transmission, giving the UE enough time to “receive” the HS-DSCH burst correctly.

It is important to note that the HS-SCCH does not carry any upper layer signaling information. The HS-

SCCH carries only the control information for the HS-DSCH, which is sometimes known as MAC control

information.

Unlike the HS-DSCH, the HS-SCCH uses the fixed modulation scheme of QPSK, with SF = 128.

The HS-SCCH can be power-controlled by the Node B. There is no downlink soft handover for the HS-

SCCH.

Typically, the HS-SCCH and the HS-DSCH channels are used in pairs. The HS-SCCH carries the control

information of the HS-DSCH, and the HS-DSCH carries the user traffic. So, in a typical deployment, we

may have one HS-DSCH and one HS-SCCH in a cell. However, multiple HS-SCCHs can be supported in

a cell. The UE can monitor up to four HS-SCCH channels.

HS-SCCH assignment can be carried by the following:

• An RRC Connection Setup message in R6 during configuration of the signaling radio bearer

• An RL Setup Response sent by the Node B to the RNC in response to an RL Setup Request sent

by the RNC

• Once the Node B sends an RL Setup Response to the RNC, the RNC sends an RRC Radio Bearer

Setup message to the UE

HS-SCCH Assignment

4-24



HSHS--SCCH AssignmentSCCH Assignment

UE RNCNode B

RRC Connection Setup (R6)

Radio Bearer Setup(R5 & R6)

HS-SCCH info

DL SC-DefSC of CPICH

RL Setup Response (R5 & R6)

SF = 128

Can Configure 1 to Max HS-SCCH Codes

per Cell

Up to 4 per UE

4-25



All 3 messages carry:

• One to four HS-SCCH codes: This can be configured in the UTRAN to indicate how many HS-

SCCH codes can be used in this cell.

• For each HS-SCCH configured, the above-mentioned messages indicates the channelization code

of the HS-SCCH. The spreading factor for the HS-SCCH is always 128.

All UEs assigned to the HS-DSCH have to monitor the HS-SCCH(s) before receiving data on HS-

PDSCH(s).

HS-SCCH Assignment (continued)

4-26



HSHS--SCCH Assignment SCCH Assignment (continued)(continued)

UE RNCNode B

RRC Connection Setup (R6)

Radio Bearer Setup(R5 & R6)

HS-SCCH info

DL SC-DefSC of CPICH

RL Setup Response (R5 & R6)

SF = 128

Can Configure 1 to Max HS-SCCH Codes

per Cell

Up to 4 per UE

4-27



The Node B fills in parameters in the HS-SCCH on a dynamic basis.

• Channelization Code Set (CCS): This field is the number of spreading factor codes that are used

in this HS-DSCH for a 2 ms frame. The field consists of the location offset of the set of codes (4

bits) and number of OVSF codes (3 bits). The UE reads this Information on the HS-SCCH and

decodes the actual channelization codes which are used in the downlink.

• Modulation Scheme (MS): The data can be sent using either QPSK or 16QAM. This field

communicates which modulation scheme is used.

• Transport Block Size (TBS): In UMTS R99, all data that is sent to the UE is broken down into a

transport block. The field communicates the size of this transport block. The TBS is 6 bits and this

does not directly send actual transport block size. The HS-SCCH carries only the index that is 6

bits long, from which the UE can determine the actual size of the transport block.

• Hybrid ARQ Parameters (HAP): This parameter (HARQ Process Identifier) identifies the

HARQ process (or buffer) where the data is placed. A maximum of 8 processes can be handled by

the HARQ entity at the UE. Every 2 ms, the scheduler sends the packet corresponding to that

HARQ process. So, the HARQ process identifier can indicate to the UE which HARQ process the

current packet belongs to so the UE can process and assemble the information.

• Redundancy and Constellation Version (RV): Since we use turbo encoding in HSDPA, the

output consists of three streams of redundant data. The RV parameter implies the percentage of

real user data and what percentage is redundant data in the current transport block. It is planned as

a per scheduling algorithm whether the first packet is just the real transport block with no

redundant data or subsequent blocks can be the redundant data to help fix the error received in the

original “original data” transport block.

HS-SCCH Contents

4-28



HSHS--SCCH ContentsSCCH Contents

NDI CRCRVHAPTBSMSCCS

7 1 6 3 3 1 16

4-29



Each retransmission may use a different redundancy version, where each redundancy version is a different

subset of the coded bits. Each subset may contain a different number of bits. Chase-combining

corresponds to defining or using only a single redundancy version.

The redundancy version (RV) parameters r, s and constellation version parameter b are coded jointly to

produce the value Xrv. This is done according to the tables mentioned in the Standard according to the

modulation mode used.

• QPSK: RV Parameters (s, r)

• 16-QAM: RV Parameters (s, r, b)

• s: “1” to prioritize systematic bits; “0”, otherwise

• r: Choice of the set of parity bits

• b: Signal constellation rearrangement for 16-QAM.

• New Data Indicator (NDI): This field indicates whether this packet is the beginning of a new

transport block or part of an existing transport block

• CRC: After all of the above data is determined, a 16 bit CRC check is calculated.

1. This CRC is then masked with the H-RNTI of the subscriber that this packet is intended

for.

2. The UE receives the HS-SCCH information, performs a CRC calculation, and applies its

H-RNTI to the CRC.

3. If the CRC matched the received CRC, the data is for it; otherwise the UE disregards this

packet.

HS-SCCH Contents (continued)

4-30



HSHS--SCCH Contents SCCH Contents (continued)(continued)

NDI CRCRVHAPTBSMSCCS

7 1 6 3 3 1 16

4-31



Before a mobile can receive information on the HS-PDSCH(s), the UE must be assigned, via a Radio

Bearer Setup message, the necessary HS-SCCH information. The UE is also communicated the H-RNTI

that will be used to inform the UE when data is being sent to it.

In this example, UE1 has been assigned H-RNTI 1, and UE2 has been assigned H-RNTI 2.

All UEs store their H-RNTI, and they de-spread the HS-SCCH(s) using the information sent in the Radio

Bearer Setup message, for example CC = 6 and SF = 128.

HS-PDSCH Assignment

4-32



HSHS--PDSCH Assignment PDSCH Assignment

UE1 (H-RNTI 1)

UE2 (H-RNTI 2)

Radio Bearer SetupH-RNTI 1, Max HS-SCCH=1, CC=6, SF=128

H-RNTI 2, Max HS-SCCH=1, CC=6, SF=128

ALL UEs store their H-RNTIAll UEs de-spread HS-SCCH with CC=6,

SF=128

Radio Bearer Setup

Node B

4-33



Now, the HS-SCCH control data is sent on a particular 2ms TTI interval. Both UEs first de-spread the HS-

SCCH and look into the control data, which denotes the necessary information for monitoring and

processing of their scheduled user data in the subsequent 2ms TTI interval. The steps involved in this

process of decoding control data sent on HS-SCCH include:

1. Both UE1 and UE2 unmask the CRC sent on the HS-SCCH. This example indicates that the

CRC is masked with H-RNTI1.

Result: UE1 understands that this control information is meant for it and will receive the HS-

PDSCH data in the subsequent 2 ms TTI interval.

2. UE1 decodes the CCS, which is offset = 2, and the number of OVSF codes = 2.

Result: UE1 finds that it has been assigned 2 codes, which are CC = 1, SF = 16 and CC = 2, SF =

16.

3. UE1 now decodes the transport block size, which denotes TFRI = 1.

Result: The UE decodes and identifies that its assigned TBS is 1239 bits.

4. UE1 determines the modulation type, which can be QPSK or 16QAM. This example denotes that

the modulation type bit is set to 1.

Result: UE1 understands that this is16QAM.

5. UE1 identifies the RV value, which is denoted here as s = 1, r = 1, and b = 0.

Result: UE1 identifies that chase combining is used with constellation rearrangement.

HS-PDSCH Assignment

4-34



HSHS--PDSCH Assignment PDSCH Assignment

1TBS index

1,0,0RV (s, r, b)

1M

0010001CCS

H-RNTI1UE ID masked with CRC

UE1 (H-RNTI 1)

UE2 (H-RNTI 2)

HS-SCCH contents(2 ms TTI)

UE 1 side

UE 1/ UE2 unmask its CRC with its H-RNTI It is H-RNTI 1 (UE 1)

UE1 decodes CCS001=code group ind0001=code offset ind

No of OVSF codes=2, offset=2

CC 1, 16 and CC 2, 16

Determines the size of Transport blockTBS value =1

TBS Value =1 corresponds to 1239 bits

Determines Modulation type and RVModulation=16QAM and RV value uses chase combining

with constellation rearrangement

Node B

4-35



The High Speed – Dedicated Physical Control Channel (HS-DPCCH) is the channel used by a UE to

report current information about the link and the status of incoming packets. The current receiving radio

conditions are reported with the Channel Quality Indicators (CQI). The status of the incoming packet is

communicated with a Hybrid ARQ ACK (HARQ ACK).

On the uplink, each UE sends the quality report and CQI on its HS-DPCCH every 2 ms while it is

assigned an HS-DSCH. Since the HS-DPCCH is used to determine the possible rate of transmission to a

UE on the HS-DSCH, the HS-DPCCH does not exist and is not used when a UE is not on the HS-DSCH.

Please note that the mobile sends CQIs all the time as long as the HS-DSCH is assigned to it. It does not

matter whether the Node B is scheduling the UE’s user traffic on the HS-DSCH.

A UE uses the HARQ ACK on the HS-DPCCH to send an acknowledgement (ACK) or negative

acknowledgement (NACK) to the Node B. The ACK corresponds to a successful packet reception and the

NACK corresponds to an unsuccessful packet reception on the HS-DSCH. The UE decodes the received

packet at the physical layer. If the packet is received successfully, the mobile sends these ACK/NAK

responses back to the base station. Since this occurs at the physical layer, this mechanism is very fast and

achieves increased throughput.

Since the HS-DPCCH is associated with an HS-DSCH, each mobile on the HS-DSCH has one HS-

DPCCH. The Node B configures the UE to send the ACK/NACK at a fixed offset from the end of a

subpacket reception. Since the HARQ ACK transmission is related to a subpacket reception, the mobile

station does not transmit the HARQ ACK when it does not receive a subpacket on a HS-DSCH.

The UE derives HS-DPCCH channelization codes implicitly from the maximum number of DPDCHs (

NMAX DPDCH) signaled on the message.

• RRC connection setup (Only R6)

• Radio link setup response, NBAP message from the Node B to RNC (once the RNC receives this

message, it forwards this parameter to the UE in the Radio Bearer Setup message.

HS-DPCCH Assignment

4-36



HSHS--DPCCH DPCCH AssignmentAssignment

SPREADINGHS-DPCCH

SPREADING

∑

ScramblingCode

HS-DPCCH

(If NMAX DPDCH=0, 1, 3, 5)

Chs

Chs

(If NMAX DPDCH =2, 4, 6)

4-37



The NMAX DPDCH can take values from 0 to 6. Each value indicates the possible combinations of

channels in the uplink. These channels can have different combinations of DPDCH, HS-DPCCH and E-

DPDCH/E-DPCCH (R6 ). The possible combinations are documented in 25.213 specifications.

Based on NMAX DPDCH values, the UE knows the corresponding channelization codes of the HS-

DPCCH. The spreading factor for the HS-DPCCH is always 256.

NMAX DPDCH =0 corresponds to HS-DPCCH channelization code C ch,256,33

NMAX DPDCH =1 corresponds to HS-DPCCH channelization code Cch,256,64

NMAX DPDCH = 2,4,6 corresponds to HS-DPCCH channelization code Cch,256,1

NMAX DPDCH = 3,5 corresponds to HS-DPCCH channelization code Cch,256,32

HS-DPCCH Assignment (continued)

4-38



HSHS--DPCCH DPCCH AssignmentAssignment (continued)(continued)

SPREADINGHS-DPCCH

SPREADING

∑

ScramblingCode

HS-DPCCH

(If NMAX DPDCH=0, 1, 3, 5)

Chs

Chs

(If NMAX DPDCH =2, 4, 6)

4-39



There ate two components of the HS-DPCCH to support the downlink high-speed operation:

HARQ-ACK/NACK and CQI are channel-coded and then mapped to the physical channel. The HARQ-

ACK /NACK is transmitted in the first slot and the CQI is transmitted in the next two slots.

The HARQ-ACK/NACK is processed in parallel and sent at different times on the HS-DPCCH.

The structure of the HARQ-ACK/NACK and CQI are given below:

• HARQ = ACK/NAK:

Input: 1 bit

Output: 10 bits after Channel coding

ACK: All 1s

NACK: All 0s

• CQI

Coding scheme (20,5)

Input: 5 bits

Output: 20 bits after channel coding

The CQI can take values between 0 (no data) and 30 (maximum data rate)

Structure of HS-DPCCH

4-40



StructureStructure of of HSHS--DPCCHDPCCH

# of O/P bits

CQI

Channel

Coding

HARQ

10 bits 20 bits

ACK: All 1sNACK: All 0s

HARQ(ACK,NACK)

CQI(0 to 30)

# of I/P bits

Channel

Coding

(20, 5)

20 bits

HS-DPCCH

C 256, hs

PhysicalChannelMapping

10 bits

4-41



The UE transmits the CQI on the HS-DPCCH to the Node B. If the Node B transmits data using the CQI

parameters, the DL BLER is 10% or less under current channel conditions. For every UE category, a table

is defined in the standard that associates a CQI value with a set of parameters. The CQI includes the

following parameters:

TFRC Info: The TFRC is based on the resources currently being employed by the Node B for the UE,

and refers to the possible transport formats and modulation schemes as configured by higher layers. It also

includes the number of HS-PDSCHs.

• The UE assumes HS-PDSCH power by taking into account PHSPDSCH = PCPICH + Γ +∆. The UE uses

this assumption to determine whether, for the current radio conditions, it is able to receive data with

a transport format corresponding to a BLER of approximately 10%.

• TFRC reporting is more robust than C/I reporting since there may be inequality between receivers

at the UE. The receivers may perform differently for the same observed channel conditions.

Reference Power Adjustment ∆: It is also called the power reduction factor. This factor introduces a 1

dB difference in the assumed power for the best channel conditions when the maximum transport block

size can be received.

Measurement Power offset Γ: The measurement power offset Γ is sent in the Radio Bearer Setup

message. It indicates a positive or negative offset applied on CPICH power ( -6…… 13, in .5 dB steps).

This is used to bias the CPICH power so the UE can receive higher or lower HS-PDSCH power. This

causes the UE to report a higher or lower transport format block size, keeping the target BLER < .1. As a

result, the Node B can schedule data more or less based on the buffer queue to be transmitted in 2 ms TTI.

CQI Fundamentals

4-42



CQI FundamentalsCQI Fundamentals

TFRC info

Ref PowerAdjustment

MeasurementPower Offset

CQI ReportingCycle

CQI RepetitionFactor

• TB size• Modulation Type• No of HS-PDSCHs

• Power ReductionDL QualityExceeds UE Capability

HS-PDSCH Power= CPICH+ Offset Γ

• CQI Reporting Period≥ 2 ms

• No. of times CQI reported

PHSPDSCH = PCPICH + +∆Γ is sent in the Radio Bearer Setup message∆ is the Reference power adjustment which UE refers from CQI Table

Γ

CQI

4-43



CQI Reporting cycle: This parameter, also called CQI feedback cycle K, indicates the frequency of

transmission of CQI reports by the UE on the HS-DPCCH. K can assume values from 0, 2, 4, 8, 10, 20,

40, 80, and 160 in units of ms. For K = 0, the UE does not transmit the CQI value. The UE reports a CQI

value over the next consecutive HS-DPCCH subframes on slots allocated for the CQI. A low feedback

cycle is intended for some or all UEs having relatively less activity, static channel conditions, or low

capability, or if the Node B has high traffic load.

CQI Repetition factor: Based on CQI Reporting cycle K, this parameter determines the number of times

the CQI report is transmitted. It can assume values ranging from 1 to 4.

CQI Fundamentals (continued)

4-44



CQI Fundamentals CQI Fundamentals (continued)(continued)

TFRC info

Ref PowerAdjustment

MeasurementPower Offset

CQI ReportingCycle

CQI RepetitionFactor

• TB size• Modulation Type• No of HS-PDSCHs

• Power ReductionDL QualityExceeds UE Capability

HS-PDSCH Power= CPICH+ Offset Γ

• CQI Reporting Period≥ 2 ms

• No. of times CQI reported

PHSPDSCH = PCPICH + +∆Γ is sent in the Radio Bearer Setup message∆ is the Reference power adjustment which UE refers from CQI Table

Γ

CQI

4-45



This diagram shows an example of parameters that influence CQI repetition.

The CQI feedback or reporting cycle and CQI repetition factor are the two parameters that take care of

CQI repetition. The UE transmits the ACK/NACK information received from the MAC-hs in the slot

allocated to the HARQ ACK in the corresponding HS-DPCCH subframe as defined approximately 5 ms

after HS-DSCH subframe reception.

The UE follows a feedback cycle of 4 ms. This means every 4 ms the UE transmits a CQI value. Since the

CQI repetition factor is set to 2, a new report is only sent after two CQI transmissions.

The diagram illustrates the fact that CQI reporting and ACK/NACK reporting do not necessarily occur

within the same subframe.

If the UE does not have to be served within every subframe, the CQI reporting cycle can be set to a longer

value.

CQI Repetition

4-46



CQI RepetitionCQI Repetition

Frame No. 0 Frame No. 1 Frame No. 2 Frame No. 3

# 0

# 1

# 2

# 3

# 5

# 4

# 6

# 7

# 8

# 9

# 10

# 11

# 12

# 13

# 14

# 15

# 16

# 17

# 18

# 19

HS-DPCCH Subframes

HS-DSCH

#2

HS-DSCH

#5

HS-DSCH

#6

HS-DSCH

#7

HS-DSCH

#8

HS-DSCH

#3

HS-DSCH

#9

HS-DSCH#11

HS-DSCH#13

HS-DSCH#12

HS-DSCH#18

HS-DSCH#16

HS-DSCH#14

HS-DSCH#15

HS-DSCH#19

HS-DSCH#17

HS-DSCH#20

5 ms

5 ms

5 ms

CQI #2

CQI #2

HS-DSCH

#1

HS-DSCH

#4

HS-DSCH#10

AN

AN

CQI #1

AN

CQI #1

AN

CQI Feedback Cycle K= 4 msCQI Repetition Factor =2

4-47



CQI parameters are signaled to the UE and Node B by the RNC when it receives the RAB Assignment

Request from the SGSN with a specified QoS.

The RNC signals the Node B on the RL Set Request message, which is a NBAP message with the

following:

• CQI feedback cycle, K

• CQI repetition factor N_CQI transmit

• Measurement Power offset Γ

• N_ACK-NACK transmit. This indicates the number of times ( NACK/NACK transmit) the

ACK/NACK can be retransmitted on its specified slots on HS-DPCCH subframes.

• CQI power offset ∆CQI. This indicates the power offset of HS-DPCCH relative to DPCCH power

when the CQI is transmitted.

• ACK/NACK Power offset ∆ACK/NACK. This indicates the power offset of the HS-DPCCH relative

to DPCCH power when the ACK/NACK is transmitted on specified slots of HS-DPCCH

subframes.

• UE Physical layer category

On receipt of this message, the MAC-hs at the Node B configures these parameters and responds with an

NBAP RL Setup Response message.

The RNC then forwards all of the above parameters in the Radio Bearer Setup message to the UE.

When HS-DSCH data transmission starts, the UE monitors the data and reports the CQI value based on

current radio conditions. It uses the above parameters to report, retransmit the CQI periodically, and also

apply power offset to the HS-DPCCH when the CQI and ACK/NACK are transmitted.

CQI Measurement Feedback Signaling

4-48



CQI Measurement Feedback SignalingCQI Measurement Feedback SignalingUE Node B SGSN

RL Setup RequestRNC


RL Setup Response

Radio Bearer Setup

Radio Bearer Setup Complete

4-49



The estimation and reporting of the CQI by the UE helps the MAC-hs scheduler at the Node B determine

the TFRC information. The CQI report is one of the inputs to the Node B scheduler to determine the

transport block size format, number of HS-PDSCH channelization codes, modulation type based on

previous CQI reports, and current DL quality, which can be used in the next HS-DSCH data transmission.

It also guarantees a BLER of approximately 10%.

The UE determines the CQI value by measuring the Ec/No of the pilot, and for purposes of reporting

applies the formula given below:

PHSPDSCH = PCPICH + Γ +∆

Γ is sent in the Radio Bearer Setup message.

∆ is the Reference Power Adjustment in the CQI mapping table

The total received power is equally distributed among the different channelization codes of the reported

CQI value.

Besides using the power of HS PDSCH, it checks the varying parameters such as TB size, modulation

type, number of HS-PDSCH codes and reference power adjustment to provide a CQI value. The result of

this process is transport block size, modulation type, etc,. which maintains a BLER ≤ 10%. This is an

iterative algorithm that keeps running until a BLER of ≤ 10% is achieved.

The UE reports one of the CQI values 0 to 30. A lower CQI value indicates poorer channel conditions.

Each CQI value ranging from 0 to 30 has a different transport block size, modulation type, number of HS-

PDSCH channelization codes and reference power adjustment. All of these parameters vary for different

UE categories.

CQI Reporting

4-50



CQI ReportingCQI Reporting

BLER ≤ 10%

TB size

Modulation Type

No. of Spreading Codes

P(HS-PDSCH)

Reference power adjustment ∆

UE Categories (1-12)

CQI value0-300 – out of rangesignaling

HS- DPCCH

CQI Values sent to Node B

CPICH (Ec/No)

4-51



UE Category : There are 12 UE Categories. The mapping of CQI values, TB size, modulation type,

reference power adjustment, maximum number of HS-PDSCH codes, incremental redundancy buffer size

(NIR) and redundancy version values (Xrv) for each UE category are provided in specification 25.214.

Transport Block Size (TBS): The TBS for each UE category and CQI value indicates the maximum

transport channel bits it can receive in a 2 ms TTI.

Spreading Codes: For each UE category, this indicates how many maximum HS-PDSCH spreading

codes the UE can receive in a 2 ms TTI. The range is from 1 to 15.

Modulation Type: UE categories 1 to 10 can support both QPSK and 16QAM, whereas categories 11 and

12 support only QPSK.

Reference Power Adjustment ∆: The ∆ is specified for each UE category and CQI value in the CQI

mapping table. The ∆ can take a value equal to 0 or negative values. Negative values indicate that the UE

is able to receive the highest transport format according to its category with less HSPDSCH power. It also

means that channel conditions have improved in the downlink as reported by UE, so that the Node B in the

next TTI can send the highest transport format according to the UE category but with less power compared

to the previous HS-DSCH data transmission.

NIR and Xrv: The NIR indicates the total number of soft channel bits present in the Virtual IR buffer per

HARQ process. The Xrv denotes the redundancy version depending on the UE category. UE category 10

has the maximum soft channel bits.

CQI Reporting (continued)

4-52



CQI Reporting CQI Reporting (continued)(continued)

BLER ≤ 10%

TB size

Modulation Type

No. of Spreading Codes

P(HS-PDSCH)

Reference power adjustment ∆

UE Categories (1-12)

CQI value0-300 – out of rangesignaling

HS- DPCCH

CQI Values sent to Node B

CPICH (Ec/No)

4-53



This slide shows an example of the usage of different reference power adjustment values and the resulting

impact on HS-PDSCH DL power. The category used is 1.

1. The UE reports a CQI value of 17 on the UL HS-DPCCH. CQI = 17 corresponds to the MAX

TBS = 4189 bits, the number of OVSF codes = 5, modulation =16QAM, ∆ = 0, NIR = 9600 bits,

and Xrv =0.

2. The scheduler at the Node B uses this CQI value and other parameters to determine the TBS,

OVSF codes, and modulation type and sends the information on the HS-SCCH to the UE. Then, it

runs the algorithm and decides to send TBS = 4189 bit, the number of OVSF codes = 5,

modulation = 16QAM, RV = 0, and HAP = 1 on the HS-SCCH.

3. The UE monitors the HS-SCCH and decodes the HS-SCCH information. Now it receives HS-

DSCH data on the next 2ms TTI.

4. The UE now uses the formula to assume HS-PDSCH power and probes the TBS size, OVSF

codes, modulation type, etc. to check whether the BLER is ≤ 10%. In this case, it determines that

the BLER is approximately 8%. Please note that the mapping of -13 dB to 8% BLER is just an

example. The actual mapping of parameters to BLER is vendor implementation-specific.

5. Now it sends CQI = 23, which is a higher value. This indicates that channel conditions are good,

so that the UE can receive a maximum of 7168 transport block bits, with ∆ = -1. This is an

indication to the Node B that the UE can still receive a maximum of 7168 bits with lesser HS-

PDSCH power.

Reference Power Adjustment - Example

4-54



Reference Power Adjustment Reference Power Adjustment -- ExampleExample

High-Speed Data Transmission (HS-DSCH)

Node B

Channel Quality (HS-DPCCH)

2

3

4

SchedulerSupporting Control Information (HS-SCCH)


Channel Quality (HS-DPCCH)1

UE (Category 1) CQI=17, ACK

TBS=4189 bits, #OVSF codes=5Modulation=16QAM, ∆=0, NIR =9600bits,

Xrv =0

TBS=17 (4189 bits), #OVSF codes =5, Modulation=16QAM, RV=0, HAP=1

P HSPDSCH=P CPICH+Γ +∆=-13db+0+0

-13db ~ 8% BLER

5

CQI=23, ACK

TBS=7168 bits, #OVSF codes=5Modulation=16QAM, ∆=-1, NIR=9600 bits

Xrv=0

4-55



Up to this point, the RNC has been informed by the SGSN about the requested QoS parameters, and has

also found out exactly what the UE may be able to support. Therefore, it is now time to start preparing the

Node B for the traffic. For that reason, the RNC sends the Radio Link Setup over the Iub interface using

the Node B Application Part (NBAP) protocol. This message contains all the parameters it had for R99,

but it now has the HSDPA-related parameters as well. Some important parameters include:

1. Associated MAC-d flows, MAC-d flow ID and Priority queue ID

2. UE Physical layer Category: There are 12 UE categories. The RRC already has the information

about the UE category that was previously sent on the RRC Connection Setup Complete or UE

capability information. This provides the Node B with useful information for scheduling downlink

data like the maximum number of channelization codes supported by the UE, maximum transport

blocks supported per TTI, etc.

3. CQI and ACK/NACK Parameters: Channel quality indicator parameters and ACK/NACK

parameters related to HARQ processes are sent. HARQ types such as chase combining and

incremental redundancy are supported by the Node B. The UE sends an ACK/NACK for every

transmission on the uplink along with the CQI on the HS-DPCCH channel.

4. H-RNTI: A new HS-DSCH-RNTI can be sent to manage the mobility of the UE during the

HSDPA transaction.

RL Setup Enhancements – R5 & R6

4-56



RL Setup Enhancements RL Setup Enhancements –– R5 & R6 R5 & R6 UE Node B SGSN

RL Setup Request

RNC


RL Setup Response

4-57



Upon reception of the RL Setup Request message, the Node B answers with the Radio Link Setup

Response. Again, on top of all Release 99-related parameters, we also see the HSDPA-related parameters,

such as:

1. Binding ID and Transport Layer Address: For every MAC-d flow, the Node B configures the

Binding ID and transport layer address. The binding ID binds the AAL2 adaptation for the Iub.

2. HS-SCCH Information: The Node B also sends the RNC the maximum number of HS-SCCH

codes supported in this cell and the channelization code of supported HS-SCCHs.

3. HARQ Processes: Based on MAC-d flows and priority queues, the MAC-hs scheduler in the

Node B creates the maximum number of HARQ processes. Each 2 ms TTI supports only one

HARQ process, and the UE can receive several HARQ processes during its reception. The MAC-

hs partitions the soft buffer memory (soft channel bits) equally among the HARQ processes. The

maximum number of soft channel bits are fixed for each UE category.

4. Initial capacity allocation: The MAC-hs also indicates the maximum MAC-d PDU size and

scheduling priority indicator for each priority queue. The maximum number of priority queues the

MAC-hs can handle is also sent in this message.

RL Setup Enhancements – R5 & R6 (continued)

4-58



RL Setup Enhancements RL Setup Enhancements –– R5 & R6 R5 & R6 (continued)(continued)

UE Node B SGSN

RL Setup Request

RNC


RL Setup Response

4-59



After negotiation and setting up pf the resources on the Iub interface, the RNC sends the Radio Bearer

Setup message to the UE. Here, the UE is assigned a new H-RNTI which is only valid for the HSDPA

operation. In addition to all other Release 99 parameters, the UE also receives information about the

HSDPA channel assignment. Here, the most important ones include information related to the new

channels. In an information element, called DL HS-PDSCH Info, the UE receives the essential parameters

(scrambling and channelization code(s)) to decode the HS-SCCH and maximum number of HS-SCCHs

supported in this cell. It also includes information about how to send the CQI parameters. In addition, the

Γ (measurement power offset) parameter is sent to help the UE calculate the power of the HS-PDSCH.

This RRC message also carries logical channel IDs and their priorities, MAC-d flow IDs, the priority

queue ID, added HS-DSCH transport channel information, and the maximum number of HARQ processes

for the UE to configure them internally. It also carries the serving HS-PDSCH RL (radio Link) indicator.

The UE acknowledges the reception of the Radio Bearer Setup message by sending the Radio Bearer

Setup Complete message. On the Iu interface, using the RANAP protocol, the RNC now sends the RAB

Assignment Response to notify the SGSN that all the resources within the UTRAN have been granted for

the requested QoS.

The SGSN, having made sure that the requirements for the QoS are met, addresses the Activate PDP

Context Accept message to the UE. In this message, the SGSN informs the UE (in addition to all other

mandatory parameters) about the final negotiated set for the QoS.

RAB Setup Enhancements – R5 & R6

4-60



RAB Setup Enhancements RAB Setup Enhancements –– R5 & R6R5 & R6UE Node B SGSNRNC

RAB Assignment RequestRadio Bearer Setup

Radio Bearer Setup CompleteRAB Assignment Response

DL DT (Act PDP CTX Accept)

DT (Activate PDP CTX Accept)

4-61



What are some of the other factors that affect the scheduling of a high-speed packet data user?

QoS and Subscriber Profile: The Node B may be provided with key information such as a profile of the

subscriber as Gold class, Platinum class, etc. This may provide an indication of the priority associated with

the scheduling of the user.

History: The users’ usage history may be another input into the scheduler. The Node B may maintain

historical information on when the user was scheduled, how long it has been since the user has received

data, etc. The Node B may use this information to prevent “starvation,” where a specific user does not

have to wait an inordinate amount of time before receiving data. This also ensures that the throughput

demands of the user can be maintained.

Traffic Model: Another input may be traffic patterns that are configured in the operator’s network. The

HS-DSCH channel and its usage may vary based on the time of day. It may also vary based on whether it

is off-peak or peak time for data traffic. For example, the operator may want to ensure that voice capacity

is not reduced during peak voice call hours and that other times are available for increased high-speed data

usage. The operator might provide seasonal promotions, which can be another input to the scheduler.

UE capability: The capabilities of the UE also affect the scheduler. For example, the number of

simultaneous Automatic Repeat Request (ARQ) channels that a mobile can support influences the number

of simultaneous channels a Node B uses for a specific mobile. Mobiles may also be limited in the data

rates that they can support, which can factor into the Node B’s scheduler process.

Radio Resource availability: The number of available 16-bit length spreading factor codes can change

periodically depending on the number of UMTS R99 users. A possible approach is to configure the use of

spreading factor codes so that the available number changes only at certain times of the day. The Node B

can use this as another key input to ascertain the schedule of packet data.

The scheduler uses an assortment of static, transient and dynamic information to achieve the optimum

scheduler function. Static information includes the QoS, subscriber profile and traffic pattern

configuration. An example of dynamic information is the feedback received from the UE, such as the CQI

value and ACK/NACK, available spreading factor codes, historical information, etc.

DL Scheduler Inputs

4-62



DL Scheduler InputsDL Scheduler Inputs

Scheduled Users & Packet Formation Strategy

Radio ResourcesPower, OVSF Codes

Scheduler

UE CapabilityUser 1: User 2:

Traffic ModelMorning AfternoonEvening Off peak

QoS & Subscriber Profile

User 1: Best effort, silver class

User 2: High priority, platinum

class

HistoryHow long had the user been

waiting?

Feedback from uplink

(CQI, ACK/NACK)

Buffer StatusAmount of Data, Arrival Rate

4-63



Several scheduling techniques can be implemented at the Node B. The Implementation is manufacturer-

specific. One of the key scheduling techniques, called Proportional Fairness Scheduling, is described here.

We will describe the implementation with an example shown in the diagram.

Let’s consider three users: User 1, User 2 and User 3. These three users are in active packet data state,

which means they are allocated HSDPA Radio Network Temporary Identifiers (H-RNTI) from the

HSDPA network. These three users report CQI values using their individual CQI channels respectively.

The Node B scheduler uses this information to calculate the data rate that can be achieved. We will label

this as the “Data Rate Computed.” This information is updated every 2 ms as the users report their CQI.

R1, R2 and R3 represent the moving averages of the Data Rate Computed values maintained by the

scheduler over a period T for User 1, User 2 and User 3 respectively.

At every scheduling instance, the scheduler has to choose among transmission to three users. The

scheduler transmits to the user with the highest (Data Rate Computed)/R value. The user with the highest

(Data Rate Computed)/R value is considered to be close to its average data rate. If no data is to be sent to a

user, it is not considered in this computation.

Proportional Fairness Scheduling

4-64



Proportional Fairness Scheduling Proportional Fairness Scheduling

User 3User 1

User 2

CQI 1 CQI 2

CQI 3

User with highest ratio will be scheduled

User 1Data Rate

Computed / R1

R1, R2 & R3 moving average over period T

User 2Data Rate

Computed / R2

User 3Data Rate

Computed / R3

Translate CQI into the data rate for each mobile.

Compute

4-65



Prior to transmission of scheduled data, the Node B sends HS-SCCH control data. Since the UE knows the

HS-SCCH channelization code, it de-spreads the HS-SCCH and decodes the HS-SCCH contents, which

contain all the required information for UE to receive the HS-PDSCH data.

The output from the scheduler has the following control data:

• H-RNTI: Identification of the user(s) whose data is to be transmitted on the next HS-DSCH sub-

frame

• Transport Block Size: The amount of data to be transmitted for new transmission (same size for

retransmission)

• Schemes for Channel Coding and Redundancy: HARQ process ID, redundancy version and

maximum soft channel bits based on the UE category

• Modulation Type: The type of modulation to be used for the next transmission

• Channelization Code Set: The number of 16-chip OVSF codes to be used for the next

transmission. The scheduled data from the MAC-hs scheduler is multiplexed to the HS-DSCH

transport channel. In each TTI interval, one transport block is transmitted and these channel codes

data are mapped to the HS-PDSCH.

Packet Formation Strategy

4-66



Packet Packet FormationFormation StrategyStrategy

AdaptiveModulation

(QPSK, 16QAM)

# of OVSF Codes

Selected User(s)

AdaptiveTransport Block Size

(New Transmission)

Adaptive Coding or

Redundancy

Scheduler Outputs info Signaled on HS-SCCH

• H-RNTI

• Transport Block Set (TBS)• New Data Ind (NDI)

• HARQ ProcessIdentifier

• RedundancyVersion (RV)

M - Modulation type

ChannelizationCode Set (CCS)

4-67



This slide emphasizes more on MAC-d- and MAC-hs-related functions used to transmit downlink HSDPA

user data.

User data from the SGSN arrives at the RNC. The user data may arrive from an application server in the

form of streaming data, for example. The QoS for this application has already been set up.

The user data passes through the PDCP at the RNC, which may perform compression. After compression,

the user data packets are compressed and sent to the RLC layer. The RLC can act either in AM or UM

mode, which is determined by the higher layer protocols. The RLC can also perform ciphering of the user

packets to maintain integrity and protection when transmitting on the radio interface. The RLC performs

its own functions based on the AM/UM mode. For example, the RLC can do concatenation or

segmentation, and at the same time store each RLC PDU inside a transmission and retransmission buffer.

This helps the RLC retransmit RLC frames in case of RLC frame errors.

The RLC adds its own header information and forwards the RLC PDU to the MAC-d layer at the RNC.

The RLC communicates with the MAC-d through logical channels. There can be several logical channels

based on the QoS associated with user data. In this diagram, there are 4 logical channels: DTCH 1, DTCH

2, DTCH 3 and DCCH. The data from these logical channels can be multiplexed to produce MAC-d

PDUs. These MAC-d PDUs, which have multiplexed data from several logical channels, are called MAC-

d flows.

Several MAC-d flows can co-exist. For example, in this diagram DTCH 1 and DTCH 2 are multiplexed to

produce one MAC-d flow, and DTCH 3 and DCCH are multiplexed to produce another MAC-d flow.

MAC-d can also indicate to the Node B MAC-hs the priority of flows in the MAC-d. The priority of

MAC-d flows are indicated by higher layers, and they depend totally on the QoS / application requested

by each user. The MAC-d has already indicated to the MAC-hs in the NBAP message the priority of flows

in the MAC-d. So, the MAC-d flows are passed on to the MAC-hs at the Node B through the HS-DSCH

framing protocol. Based on the priority of flows, the MAC-hs stores this data in priority queues. There can

be several priority queues with a unique queue identifier. Now, the MAC-hs forwards the scheduled data

through the HARQ entity, which keeps track of different HARQ processes.

HSDPA User Data Flow

4-68



HSDPA User Data FlowHSDPA User Data FlowRNC

RLC AM/UM

PDCP

User data from SGSN

DTCH 1 DTCH 2 DTCH 3 DCCH

C/T MUX

MAC-d flows

MAC-d

Node B

MAC-hs

Priority Queue Distribution


PriorityQueue

PriorityQueue

PriorityQueue

PriorityQueue

HARQ ENTITY

HS-DSCH

Physical Layer Functions

MAC—hs Queue ID, TSN

Uu

Iub Framing Protocol

4-69



The HARQ entity at the Node B runs several HARQ processes in parallel. The MAC-hs adds its header,

and then forwards it to the physical layer through the HS-DSCH transport channel. The MAC-hs header

contains important information such as the queue identifier and Transmission Sequence Number (TSN).

The TSN is incremented for every MAC-hs PDU transmitted to its peer entity. One HS-DSCH transport

channel is capable of transmitting several priority classes of user data. Only one priority class can exist per

TTI. The user data is now channel-coded (turbo coding 1/3) and then divided into 3 streams of data by the

physical layer HARQ. The physical layer HARQ now transmits the subpackets based on the RV version

signaled previously on the HS-SCCH. The RV version can have varying parameters depending on HARQ

retransmission techniques. The HARQ retransmission techniques can be classified into chase combining,

partial incremental redundancy and full incremental redundancy. If 16QAM modulation is used,

constellation bit rearrangement is also applied. The constellation bit rearrangement is part of the RV

parameter. The HARQ bits are mapped to physical channel HS-PDSCH. Based on information signaled

on the HS-SCCH, the Node B physical layer forms the transport block, multi-spreads the HS-PDSCH data

with OVSF codes of spreading factor 16, and then spreads it with the cell-specific scrambling code of the

serving HS-PDSCH cell.

The UE receives the data and performs physical layer functions such as demodulation based on

modulation type, descrambling, de-spreading of OVSF codes, and the HARQ ACK/NACK. Then it

forwards the data to the MAC-hs layer at the UE. The re-ordering queue distribution function at the MAC-

hs routes the MAC-hs PDUs to the correct re-ordering buffer based on the Queue ID. Once the MAC-hs

PDUs are stored in the re-ordering buffer, the re-ordering entity reorders received MAC-hs PDUs

according to the received Transmission Sequence Number (TSN). The TSN is unique per priority queue.

Once the data stored in the re-ordering buffer is reordered, the MAC-hs disassembles the MAC-hs header

and forwards the MAC-d flows to the MAC-d layer. The MAC-d de-multiplexes the MAC-d PDUs from

different MAC-d flows into their corresponding logical channels. The data belonging to different logical

channels is sent to the RLC layer. The RLC checks for any errors if operating in RLC–AM mode. If errors

are found, it may request a retransmission from the RLC peer entity at the RNC. The RLC then assembles

the RLC SDUs and forwards them to the PDC. The PDCP performs decompression and passes the

payload to the applications layer.

HSDPA User Data Flow (continued)

4-70



HSDPA User Data Flow HSDPA User Data Flow (continued)(continued)RNC

RLC AM/UM

PDCP

User data from SGSN


C/T MUX

MAC-d flows

MAC-d

Node B

MAC-hs



PriorityQueue

PriorityQueue

PriorityQueue

PriorityQueue

HARQ ENTITY

HS-DSCH


MAC—hs Queue ID, TSN

Uu

Iub Framing Protocol

4-71



The UE receives the data and performs physical layer functions, such as demodulation based on

modulation type, descrambling, de-spreading of OVSF codes, and HARQ ACK/NACK. Then it forwards

the data to the MAC-hs layer at the UE. The re-ordering queue distribution function at the MAC-hs, routes

the MAC-hs PDUs to the correct re-ordering buffer based on the Queue ID. Once the MAC-hs PDUs are

stored in the re-ordering buffer, the re-ordering entity reorders received MAC-hs PDUs according to the

received Transmission Sequence Number (TSN). The TSN is unique per priority queue. Once the data

stored in the re-ordering buffer is reordered, the MAC-hs disassembles the MAC-hs header and forwards

the MAC-d flows to the MAC-d layer. The MAC-d de-multiplexes the MAC-d PDUs from different

MAC-d flows into their corresponding logical channels. The data belonging to different logical channels is

sent to the RLC layer. The RLC checks for any errors if operating in RLC–AM mode. If errors are found,

the UE may request for a retransmission from the RLC peer entity at the RNC.

HSDPA Traffic Flow

4-72



HSDPA Traffic FlowHSDPA Traffic FlowUE Node B

MAC-hs

Re-ordering Queue Distribution

Re-orderingBuffer



PriorityQueue

PriorityQueue

PriorityQueue

PriorityQueue

HARQ ENTITY

HS-DSCH


Re-orderingBuffer

MAC–d Flow

C/T MUX


RLC AM/UM

ApplicationsPDCP

MAC-hs Queue ID,

TSN

MAC–d Flow

UuPhysical Layer Functions

4-73



This figure depicts the usage of HSDPA channels among R99 channels. As stated before, HSDPA is an

evolution of R99. So, the UMTS R99 channels and HSDPA channels co-exist.

Since UMTS can support multiple services simultaneously, it is required to have both types of channels

simultaneously.

In addition to the above, the R00 uplink and downlink channels still support soft handover during an

HSDPA call. A UE in an HSDPA transaction can only be served by a single serving cell / Node B. Also,

no power control exists in the downlink for an HSDPA call. During soft handover, all active set Node Bs

can send power control commands to the UE. These power control commands, TPC bits, are carried by the

DPCCH in the downlink from all active set Node Bs. The power control is done on the DPDCH /

DPCCH. The HS-DPCCH power is always relative to the DPCCH. So, by varying the power of the

DPCCH, HS-DPCCH power is also varied. The offset to be used between the DPCCH and HS-DPCCH is

signaled during the radio bearer setup message.

Channel Usage

4-74



Channel UsageChannel Usage

UE

Serving Node B

Other “Active”Node Bs

CQI/ACK-NACK

HS-DPCCH(HSDPA)

Voice, Data, Signaling/TCI, Pilot, TPC

DPCH (non-HSDPA)

HSDPA and R99 server for the UE

DPCH

DPDCH/DPCCH

DPCH

HS-SCCH/HS-PDSCHHSDPA Control/data

R99 Server for

this UE

R99 Server for

this UE

DPDCH/DPCCH

Voice, Data, Signaling/TFCI, Pilot, TPC

DPDCH/DPCCH

4-75



Three types of reconfiguration methods are used in UMTS. All three methods have been enhanced at the

RRC to support HSDPA.

1. Radio Bearer Reconfiguration

Radio bearer reconfiguration is required when the following changes occur:

• When the Quality Of Service (QoS) changes, such as adding a new service to the old

service. This is very common in UMTS, and reconfiguration happens frequently

throughout the life cycle of a call. In HSDPA, there also can be multi services like circuit-

switched calls with HSDPA. So, if a circuit-switched call is already established and an

HSDPA call is added to the existing circuit-switched call, Radio Bearer Reconfiguration

is performed by the RRC.

• Change of RLC content

• Change of TFS/TFCS

• Assignment/release of physical channels

2. Transport Channel Reconfiguration

The transport channel reconfiguration is required when the following changes occur:

• Changes in traffic volume

• Changes in TFS

• Use of a new transport channel

• Need to change physical channel bandwidth

A good example of transport channel reconfiguration is during an Inter-Node B HS-DSCH hard

handover.

Reconfiguration Types and Functions

4-76



Reconfiguration Types and FunctionsReconfiguration Types and Functions

Radio Bearerreconfiguration

Transport channel

Reconfiguration

Physical channelReconfiguration

• Change of QoS• Change of RLC content • Change of TFS/TFCS• Assignment/release of

physical channels


• Changes in TFS• Use of new transport

channel• May change physical

• Changes in RRC states• changes in DL CC• No transport channel

type switching

Reconfiguration

4-77



3. Physical Channel Configuration

Physical channel reconfiguration can be needed when the following changes occur:

• Changes in RRC states such as moving from a cell DCH to Cell FACH state

• Changes in DL Channelization codes

• When transport channel type switching happens, physical channel reconfiguration cannot

be performed

Good examples of physical channel reconfiguration are Intra-Node B handovers in HSDPA and

sector switching within a Node B.

Reconfiguration Types and Functions (continued)

4-78



Reconfiguration Types and FunctionsReconfiguration Types and Functions(continued)(continued)

Radio Bearerreconfiguration

Transport channel

Reconfiguration

Physical channelReconfiguration

• Change of QoS• Change of RLC content • Change of TFS/TFCS• Assignment/release of

physical channels


• Changes in TFS• Use of new transport

channel• May change physical

• Changes in RRC states• changes in DL CC• No transport channel

type switching

Reconfiguration

4-79



The following example shows a message sequence flow explaining the setup of an HS-DSCH. For

example, the UE is already on a CS call, and now it wants to download a video streaming application. The

UE is an HSDPA-capable mobile, and the UTRAN may provide HSDPA resources for this service. The

UE is in a cell_ DCH state. In case no RL has already been established, the Radio Link Setup procedure is

used instead of the Radio Link Reconfiguration procedure. In this case, the RL has been already

established.

1. The RNC receives a RANAP RAB Assignment Request message from the SGSN requesting a

specific QoS. The RNC requests the Node B to prepare for configuration or reconfiguration of the

HS-DSCH.

2. To channel-switch to the HS-DSCH, the radio link, which carries the HS-DSCH, has to be

reconfigured. The SRNC initiates a radio link reconfiguration by sending the Radio Link

Reconfiguration Prepare message to the Node B.

Parameters: HS-DSCH information and an SRNC-selected HS-PDSCH RL ID

HS-DSCH information contains all MAC-d details, CQI parameter and ACK/NACK information.

3. The Node B configures resources for the HS-DSCH and responds with the NBAP Radio Link

Reconfiguration Ready message.

Parameters: The HS-DSCH Information Response which contains HS-SCCH channelization

codes, HARQ processes, etc.

4. The NBAP Radio Link Reconfiguration Commit message is sent from the SRNC to the Node B.

5. The RNC initiates setup of Iub data transport bearers using the ALCAP protocol. This request

contains the AAL2 binding identity to bind the Iub data transport bearer to the HS-DSCH.

6. The RNC sends the RRC Radio Bearer Reconfiguration message to the UE to establish the

requested HS-DSCH.

HS-DSCH Configuration

4-80



HSHS--DSCH ConfigurationDSCH ConfigurationUE RNC GGSNSGSN

1. RAB Assign. Req.

Node B

2. Radio Link Reconfig Prepare

3. Radio Link Reconfig Ready

4. Radio Link Reconfig Commit

5. Iub Trans Bearer Setup6. Radio Bearer Reconfiguration

7.Radio Bearer Reconfig Comp

8. HS-DSCH Capacity Request

9. HS-DSCH Capacity Allocation

10. Information Transfer11.HS-SCCH/HSPDSCH Data

• Change in QoS can add/del MAC-d flow and also change priority queues

QoS modification

4-81



7. The UE replies with the RRC Radio Bearer Reconfiguration Complete message. At this point, the

HS-DSCH transport channel has been set up, and it is assumed that the MAC-hs in the Node B

has already been configured earlier to have access to a pool of HS-PDSCH resources for HS-

DSCH scheduling. The RNC also sends a RAB Assignment Response to the SGSN.

8. As soon as the RNC detects the necessity to send HS-DL data on one HS-DSCH, it sends an HS-

DSCH capacity request control frame within the HS-DSCH frame protocol to the Node B.

Parameters: Common Transport Channel Priority Indicator and User Buffer Size.

9. The Node B determines the amount of data (credits) that can be transmitted on the HS-DSCH and

reports this information back to the RNC in a HS-DSCH capacity allocation control frame in the

HS-DSCH frame protocol.

Parameters: Common Transport Channel Priority Indicator, HS-DSCH credits, HS-DSCH

interval, HS-DSCH repetition period, and maximum MAC-d PDU length.

10. The RNC starts sending DL data to the Node B. This is done via the two HS-DSCH frame

protocols on the Iub interface. The Node B schedules the DL transmission of DL data on the HS-

DSCH, which includes allocation of PDSCH resources.

11. The Node B transmits the control information for the concerned UE using the HS-SCCH. The

Node B then sends the HS-DSCH data to the UE on the HS-PDSCH(s).

HS-DSCH Configuration (continued)

4-82



HSHS--DSCH ConfigurationDSCH Configuration (continued)(continued)UE RNC GGSNSGSN

1. RAB Assign. Req.

Node B




5. Iub Trans Bearer Setup6. Radio Bearer Reconfiguration


8. HS-DSCH Capacity Request

9. HS-DSCH Capacity Allocation

10. Information Transfer11.HS-SCCH/HSPDSCH Data

• Change in QoS can add/del MAC-d flow and also change priority queues

QoS modification

4-83



Radio bearer release is also enhanced in RRC to support HSDPA. Radio bearer release can simultaneously

release a service and reconfigure another service if two services are accessed by the UE simultaneously.

1. The UE has finished downloading an application using HSDPA. So, the UE sends a Deactivate

PDP Context Request, which is a Direct Transfer message. It sends the APN, IP address, QoS

negotiated, etc. to the RNC.

2. The RNC forwards this message as a RANAP Direct Transfer Deactivate PDP Context message

to the SGSN. It sends the GTP TE-ID along with the above parameters.

3-4. The SGSN requests the GGSN to delete the tunnel by sending a Delete PDP Context Request

established for this APN, IP address and QoS. The GGSN talks to the external network and

requests it to release the connection. The GGSN responds to the SGSN with a Delete PDP

Context Response.

5. The SGSN sends a RAB Release Request to delete the RAB assigned on the Iu and radio bearer

assigned to the UE for this QoS and application.

6. The RNC requests the Node B to prepare release of the HS-DSCH carrying the radio access

bearer (Radio Link Reconfiguration Prepare).

Parameters: Delete MAC-d flows HS-PDSCH RL ID

7. The Node B notifies the RNC that release preparation is ready (Radio Link Reconfiguration

Ready).

8. The NBAP Radio Link Reconfiguration Commit message is sent from the RNC to the Node B.

9. The RRC Radio Bearer Release message is sent by the RNC to the UE.

Parameters: HS-DSCH information such as HS-SCCH codes, MAC- d flows to delete, priority

queues, etc.

10. The UE sends the RRC Radio Bearer Release Complete message to the SRNC.

Radio Bearer Release - HSDPA

4-84



Radio Bearer Release Radio Bearer Release -- HSDPAHSDPAUE RNC GGSN

1. UL DT (DeActivate PDP CTX Req.) 2. DT (Deact. PDP CTX Req.)

SGSN

3.Delete PDP CTX Req.

4. Delete PDP CTX Res

Node B

5. RAB Release Request

6. RL Reconfig. Prep.

7. RL Reconfig. Ready

9. Radio Bearer Release

10. Radio Bearer Release Comp

8. RL Reconfig. Commit

11. Iub Trans Bearer Release

4-85



11. Unused resources in the RNC and the Node B (Serving RNS, if any) are released. The RNC

initiates release of the Iub (serving RNS) data transport bearer using the ALCAP protocol.

12. The SRNC acknowledges the release of the radio access bearer with the Radio Access Bearer

Release Response message.

Radio Bearer Release - HSDPA (continued)

4-86



Radio Bearer Release Radio Bearer Release -- HSDPA HSDPA (continued)(continued)UE RNC GGSN

1. UL DT (DeActivate PDP CTX Req.) 2. DT (Deact. PDP CTX Req.)

SGSN

3.Delete PDP CTX Req.

4. Delete PDP CTX Res

Node B

5. RAB Release Request

6. RL Reconfig. Prep.


9. Radio Bearer Release



11. Iub Trans Bearer Release

4-87



The HS-DSCH is only allocated in the downlink for HSDPA users. There are two aspects to managing

mobility when using the HS-DSCH.

The first is related to the signaling aspects of managing the neighbor list when using the HS-DSCH. The

second category is related to mobility management when the UE is receiving traffic on the HS-DSCH.

When a mobile station is involved in a packet data session using the HS-DSCH, it may also be configured

to monitor multiple pilots of nearby base stations. This is the same mechanism used in UMTS R99 systems,

where the mobile station is monitoring all the base stations in the neighbor list. The Node B and UE

communicate to constantly add, delete or change the members of the active set. The base stations may be

moving between active, neighbor and candidate sets as they monitor and measure pilot channel strength.

Therefore, as part of using the HS-DSCH, even though there is only one HS-DSCH that is actively

transmitting data, the mobile station is always monitoring all members of the active set. All the existing

mechanisms used in UMTS R99 are used here as well to manage the active set.

When the mobile station is actively receiving traffic on the HS-DSCH, the situation is different. The

mobile station receives packet data from one base station on the HS-DSCH. The mobile station receives

packet data from the base station that it hears the best. This is determined by measuring the Carrier-to-

Interference (C/I) ratio of the pilot channels of the base stations in the active set.

Multiple HS-DSCHs are not used in the downlink for several reasons.

• Multiple HS-DSCH channels from Node Bs require coordination and this renders CQI

measurements invalid. Such a scenario might significantly reduce the achievable throughput of the

system.

• The HS-DSCH uses available power and this may be quite different in the two Node Bs/cells

• The CQI measurements from multiple cells is required

Handover Procedures While Using the HS-DSCH

4-88



Handover Procedures While Using Handover Procedures While Using the HSthe HS--DSCHDSCH

HS-DSCH

Measurements TrafficCreate Active, Neighbor and

Monitored Sets

• Transmission from (one cell, one Node B)

• Serving Cell part ofthe Active Set

4-89



The diagram shows how the UE manages the neighbor list in HSDPA system when using the HS-DSCH.

The basic handover support mechanisms remain the same in HSDPA as in UMTS R99. The RNC sends a

measurement control message in which the RNC provides the neighbor list and the reporting criteria to the

UE. It also specifies the conditions under which the UE should send the Measurement Report message.

Periodic reporting is also supported. One of the reporting events is the “Change of Best Cell.” Since the

HS-DSCH transmission occurs only from a single cell, layer 3 signaling messages are used.

In our example, the mobile station currently is being served by Node B A. So, the UE belongs to only one

of the radio links assigned to the UE, the serving HS-DSCH radio link. The cell associated with the

serving HS-DSCH radio link is defined as the serving HS-DSCH cell.

There must be synchronization between the UE and UTRAN indicating when transmission and reception

is stopped and re-started. Two possibilities for a serving HS-DSCH cell change exist:

1. A synchronized serving HS-DSCH cell change defines the start and stop of HS-DSCH

transmission and reception at a certain time typically selected by the network.

2. An unsynchronized serving HS-DSCH cell change defines the start and stop of HS-DSCH

transmission and reception is performed "as soon as possible" (stated by UE performance

requirements) at either side.

Handover Measurement Management

4-90



Handover Measurement ManagementHandover Measurement Management

UE

Measurement Control

Measurement Report

Physical Channel Reconfiguration(Intra-Node B Handover)

Transport Channel Reconfiguration(Inter-Node B Handover)

Node B

Node B

UE

Neighbor List

Cell ACell B

…

Measurement Report

Intra-Node B & Inter-Node B Hard

Handovers for HS-PDSCHs

Synchronized Non synchronized

4-91



The serving HS-DSCH cell change may also be categorized with respect to the serving HS-DSCH Node

B.

The UE might, while monitoring the neighbor list, notice that another Node B / cell is received strongly by

measuring the pilot strength. The UE transmits a Measurement Report message containing intra-frequency

measurement results triggered by the event 1D “Change of Best Cell“ to the RNC:

1. Intra-Node B Hard Handover: The source and target HS-DSCH cells are both controlled by the

same Node B. The serving HS-DSCH Node B is not changed.

In the case of an intra-Node B hard handover, the RNC then decides to change the physical

channels of the UE. Therefore, the RNC responds with a Physical Channel Reconfiguration or

Transport Channel Reconfiguration message that instructs the UE to the new cell/sector and the

new set of spreading factor codes that will be used for the SCCH and HS-DSCH.

2. Inter-Node B Hard Handover: The Node B controlling the target HS-DSCH cell is different

from the Node B controlling the source HS-DSCH cell.

In the case of an inter-Node B hard handover, the RNC sends a Transport Channel

Reconfiguration message on the old configuration. This message indicates the configuration after

handover, both for DCH and HS-DSCH. The Transport Channel Reconfiguration message

includes a flag indicating that the MAC-hs entity in the UE will be reset. The message also

includes an update of transport channel related parameters for the HS-DSCH in the target HS-

DSCH cell.

Handover Measurement Management (continued)

4-92



Handover Measurement Management Handover Measurement Management (continued)(continued)

UE

Measurement Control

Measurement Report

Physical Channel Reconfiguration(Intra-Node B Handover)

Transport Channel Reconfiguration(Inter-Node B Handover)

Node B

Node B

UE

Neighbor List

Cell ACell B

…

Measurement Report

Intra-Node B & Inter-Node B Hard

Handovers for HS-PDSCHs

Synchronized Non synchronized

4-93



If any of the primary CPICHs within the reporting range become better than the previously best primary

CPICH, the UE sends a measurement report if event 1D is ordered by the UTRAN.

The hysteresis parameter may be connected with each reporting event. The value of the hysteresis is given

to the UE in the reporting criteria field of the Measurement Control message.

In the example shown in the slide, the hysteresis ensures that the event 1D (primary CPICH 2 becomes the

best cell) is not reported until the difference is equal to the hysteresis value. The fact that the primary

CPICH 1 becomes best afterward is not reported at all in the example since the primary CPICH 1 does not

become sufficiently better than the primary CPICH 2.

HSDPA - Best Cell Change

4-94



HSDPA HSDPA -- Best Cell ChangeBest Cell Change• Hysteresis

– Send measurement report only when the difference of signal strengths equals the hysteresis value

– Best cell change - 1D event

CPICH 1

CPICH 2Hysteresis

Hysteresis

Reporting event 1D

Time

Measurementquantity

4-95



The slide describes intra-Node B synchronized handovers or sector switching of the UE. Our example

consists of a UE with an active set that includes sectors 1, 2 and 3.

Sector 1 is the serving HSDPA cell with the HS-SCCH and HS-PDSCH in the downlink and the HS-

DPCCH in the uplink. The other R99 channels DPCCH/DPDCH in both uplink and downlink in sectors 1,

2 and 3 still exist since support for soft handoff in uplink and downlink for regular R99 services still has to

be supported. So, when event 1D is triggered, in this example sector 3 becomes the best cell. Intra-Node B

handover is triggered from sector 1 to sector 3. The system reconfigures sector 3 with HSDPA uplink and

downlink channels and releases sector 1. Other R99 channels still exist without change.

Intra-Node B – Sync (Sector Switching)

4-96



IntraIntra--Node B Node B –– Sync (Sector Switching)Sync (Sector Switching)

DPCCH/DPDCH

DPCCH

/DPD

CH

HS-SCCH/HS-DPCCH

DPCCH/DPD

CH

Active Set: Sectors 1, 2, and 3Switches to sector 3

Sector 1 Sector 3Sector 2

Source Target

4-97



This slide depicts the intra-Node B synchronized handover message sequence. The word synchronized

means that the activation time is sent to the UE which informs the UE about the time at which it should

switch over to the target cell/ sector. In this example, it is assumed that the HS-DSCH transport channel

and radio bearer parameters do not change. If the transport or radio bearer parameters are used, the serving

HS-DSCH cell change needs to be executed by the transport channel reconfiguration procedure or radio

bearer configuration procedure

1. The UE sends a measurement report E (1D) to the SRNC via the DCCH to indicate a better cell.

The measurement report criteria can be P-CPICH (Ec/Io).

2. The SRNC decides to perform a best cell change to sector 1D.

3. The SRNC requests the serving HS-DSCH Node B to perform a synchronized radio link

reconfiguration using the NBAP Synchronized Radio Link Reconfiguration Prepare message.

Parameters provided include HS-DSCH information, the HS-DSCH RNTI and the HS-PDSCH

RL ID.

4. The serving HS-DSCH Node B returns an NBAP Synchronized Radio Link Reconfiguration

Ready message. Parameters carried include the HS-DSCH information response.

5. The SRNC now transmits NBAP Radio Link Reconfiguration Commit message to the Node B.

This message provides the activation time in the form of a Connection Frame Number (CFN).

6. The SRNC transmits the RRC Physical Channel Reconfiguration message to the UE. Parameters

provided include activation time, MAC-hs reset indicator, serving HS-DSCH RL ID, HS-SCCH

set information and the H-RNTI.

7. At the indicated activation time, the UE stops receiving the HS-DSCH in the source cell and starts

HS-DSCH reception in the target cell. The UE then returns a Physical Channel Reconfiguration

Complete message via the DCCH.

Intra-Node B – Sync (Sector Switching)

4-98



IntraIntra--Node B Node B –– Sync (Sector Switching)Sync (Sector Switching)S - NB

1

SRNC

23Active set sectors 1, 2, 3HSDPA serving cell is 1

1.Measurement Report (event 1D)

3.RL Reconfig. Prepare



6.Physical Channel Reconfiguration

7. Physical Channel Reconfiguration Complete

2. Decision for best cell change to sector 3

Start TX/RX at target Stop TX/RX in source at given activation time

4-99



This slide illustrates a synchronized inter-Node B serving HS-DSCH cell change in combination with a

hard handover. This is possible when fast handovers of both the DCH and HS-DSCH are required. To

trigger the hard handover, the SRNC sends a Transport Channel Reconfiguration message on the old

configuration. This message takes care of both the DCH and HS-DSCH configurations after handover.

The Transport Channel Reconfiguration message includes a flag indicating that the MAC-hs entity in the

UE shall be reset. This message also includes the transport channel parameters for the HS-DSCH in the

target HS-DSCH cell.

1. The UE sends a measurement report event 1D to the SRNC on the DCCH to indicate a better cell.

2. The SRNC decides that there is a need for a hard handover with the serving HS-DSCH cell

change to sector 1, T-NB

3. The SRNC transmits a Radio Link Setup Request message to the target Node B.

4. The target Node B allocates resources, starts physical layer reception on the DPCH on a new radio

link and responds with the NBAP Radio Link Setup Response message. It provides the HS-DSCH

Information Response.

5. The SRNC initiates setup of a new Iub data transport bearer for the DCH using the ALCAP

protocol. This request contains the AAL2 binding ID to bind the Iub data transport bearer to the

DPCH.

6. The SRNC requests the source HS-DSCH Node B to perform a Synchronized Radio Link

Reconfiguration Prepare, removing its HS-DSCH resources for the source HS-DSCH radio link.

Parameters include HS-DSCH information, an allocated H-RNTI and the HS-PDSCH RL ID.

7. The source HS-DSCH Node B responds with a Synchronized Radio Link Reconfiguration Ready.

Parameters provided include the HS-DSCH Information Response.

8. The SRNC transmits an NBAP Radio Link Reconfiguration Commit to the source cell indicating

when the MAC-hs will stop sending HS-DSCH data blocks. At the indicated activation time, the

source Node B stops and the target HS-DSCH Node B starts transmitting on the HS-DSCH to the

UE. Parameters in this message include activation time in the form of a CFN.

Inter-Node B – Sync Hard Handover

4-100



InterInter--Node B Node B –– Sync Hard HandoverSync Hard HandoverS - NB

1

SRNC

.

23Active set sectors1, 2, 3HSDPA Serving cell is (1, S-NB)


3. RL Setup Request

4. RL Setup Response

T - NB1

Start TX

Start TX

5. Iub Bearer - DCH

6. RL Reconfiguration Prepare

7. RL Reconfiguration Ready

8. RL Reconfiguration Commit

9. RL Reconfig Prepare

10. RL Reconfig Ready

2. Decision for best cell change to sector 1,T-NB

4-101



9. Now, the SRNC requests the target HS-DSCH Node B to perform a Synchronized Radio Link

Reconfiguration Prepare. This message informs the Node B to add HS-DSCH resources of the

target HS-DSCH radio link.

10. The Node B responds with an NBAP Radio Link Reconfiguration Ready. It consists of an HS-

DSCH Information Response.

Inter-Node B – Sync Hard Handover (continued)

4-102



InterInter--Node B Node B –– Sync Hard Handover Sync Hard Handover (continued)(continued)S - NB

1

SRNC

23Active set sectors1, 2, 3HSDPA Serving cell is (1, S-NB)


3. RL Setup Request


T - NB1

Start TX

Start TX

5. Iub Bearer - DCH






2. Decision for best cell change to sector 1,T-NB

4-103



11. The SRNC initiates the setup of a new Iub data transport bearer using an ALCAP protocol. This

request contains the AAL2 Binding ID to bind the Iub data transport bearer to the HS-DSCH.

12. The HS-DSCH transport bearer to the target HS-DSCH Node B is established. The SRNC now

transmits an NBAP Radio Link Reconfiguration Commit message to the Node B. The parameters

sent in this message include the activation time in the form of a CFN.

13. The SRNC transmits an RRC message Transport Channel Reconfiguration to the UE. Parameters

provided include activation time, the MAC-hs Reset Indicator, serving HS-DSCH radio link

indicator, HS-SCCH set information and the H-RNTI.

14. At the indicated activation time, the UE initiates establishment of the DPCH in the target cell.

When physical layer synchronization is established in the target cell, the UE starts DPCH

reception, and also starts transmission and reception of the HS-DSCH in the target cell. The UE

responds with a Transport Channel Reconfiguration Complete message.

15. The SRNC will initiate the procedure of Radio Link deletion Request to the source Node B to de-

allocate radio resources (DPCH and HS-PDSCH’s )

16. The source Node B releases the HS-DSCH and DCH resources and returns a Radio Link Deletion

response to the SRNC. Finally the DCH and HS-DSCH ALCAP transport bearers are released.

Inter-Node B – Sync Hard Handover

4-104



InterInter--Node B Node B –– Sync Hard HandoverSync Hard HandoverS - NB

1

SRNC

.

23

12. RL Reconfig Commit

T - NB1

13. DCCH Transport Channel Reconfiguration sent on old config

11. Iub bearer HS-DSCH

Start TX/RX at Target Stop TX/RX in source at given activation time

14. Transport Channel Reconfiguration Complete

15. RL Deletion Request16. RL Deletion ResponseStop TX/RX

4-105



This figure depicts an inter-Node B serving HS-DSCH cell change performed after an active set update. In

this example, a new radio link is added that is different from the source Node B and belongs to a target

Node B. The cell added to the active set becomes the serving HS-DSCH cell in the second step. The entire

procedure consists of an ordinary Active Set Update procedure in the first step and a synchronized serving

HS-DSCH cell change in the second step. Please refer specs 25.308.

1. The UE transmits a Measurement Report message containing intra-frequency measurement

results.

2. Based on the received measurement reports and/or load control algorithms, the SRNC determines

the need for the combined radio link addition and serving HS-DSCH cell change, and sends a

Radio Link Setup message to the T-NB.

3. The T-NB responds with a Radio Link Setup Response message to the SRNC.

4. The SRNC establishes the new radio link in the target Node B for the dedicated physical channels

and transmits an Active Set Update message to the UE. The message includes the necessary

information for establishment of the dedicated physical channels in the added radio link (but not

the HS-PDSCH).

5. When the UE has added the new radio link, it returns an Active Set Update Complete message.

The SRNC will now carry on with the next step of the procedure, which is the serving HS-DSCH cell

change. The target HS-DSCH cell is the newly added radio link, only including dedicated physical

channels. For the synchronized serving HS-DSCH cell change, both the source and target Node Bs are

first prepared for execution of the handover at the activation time.

6. The SRNC requests the S-Node B to perform a Synchronized Radio Link Reconfiguration

Prepare, removing its HS-DSCH resources for the source HS-DSCH radio link. Parameters

include HS-DSCH information, the allocated H-RNTI and the HS-PDSCH RL ID.

Cell Change after Active Set Update

4-106



Cell Change after Active Set UpdateCell Change after Active Set UpdateS - NB

1

SRNC

.

23T - NB

1

4. Active Set Update

1. Measurement Report

2. RL Setup Request


5. Active Set Update Complete




4-107



7. The source HS-DSCH Node B responds with the synchronized Radio Link Reconfiguration

Ready message. Parameters provided include the HS-DSCH Information Response.

8. The SRNC transmits an NBAP Radio Link Reconfiguration Commit message to the S-NB,

indicating when the MAC-hs will stop sending HS-DSCH data blocks. At the indicated activation

time, the source Node B stops and the target HS-DSCH Node B starts transmitting on the HS-

DSCH to the UE. Parameters in this message include activation time in the form of a CFN.

Cell Change after Active Set Update (continued)

4-108



Cell Change after Active Set Update Cell Change after Active Set Update (continued)(continued)

S - NB1

SRNC

.

23T - NB

1

4. Active Set Update

1. Measurement Report

2. RL Setup Request


5. Active Set Update Complete




4-109



9. Now the SRNC requests the T-Node B to perform a synchronized Radio Link Reconfiguration

Prepare. This message informs the Node B to add HS-DSCH resources to the target HS-DSCH

radio link.

10. The Node B responds with an NBAP Radio Link Reconfiguration Ready. It consists of an HS-

DSCH Information Response.

11. The SRNC now transmits an NBAP Radio Link Reconfiguration Commit message to the Node B.

The parameters sent in this message include the activation time in the form of a CFN.

12. The SRNC then sends a Transport Channel Reconfiguration message, which indicates the target

HS-DSCH cell and the activation time to the UE. The message may also include a configuration

of transport channel-related parameters for the target HS-DSCH cell, including an indication to

reset the MAC-hs entity, and a status report for each RLC entity associated with the HS-DSCH

that should be generated.

Thus, at the indicated activation time the transmission from the target HSDSCH cell is started, and

the transmission from the source Trx is stopped.

13. When the UE has completed the serving HS-DSCH cell change it returns a Transport Channel

Reconfiguration Complete message to the SRNC.

Inter-Node B – Cell Change after Active Set Update

4-110



InterInter--Node B Node B –– Cell Change after Active Cell Change after Active Set UpdateSet Update

S - NB1

SRNC

23T - NB

1

12. Transport Channel Reconfiguration




Start Trx for HSDSCH in the target HSDSCH cell, stop Trx in the source HSDSCH cell at the given activation time

13. Transport Channel Reconfiguration Complete

4-111



To perform the cell re-selection operation, the UE first needs to know the necessary system information

about the system it is camping on as well as the systems that are in the surrounding geographical area – the

neighbor cells.

First, the UE searches for the strongest cell and performs the PLMN selection and cell selection. Once it

synchronizes with the current cell, it monitors the Broadcast Channel (BCH) and gathers information

about the current cell and its neighbors from the System Information Blocks (SIB). A SIB groups together

system information of the same nature. The SIBs are sent on the BCH periodically. The UMTS

specification describes over 15 different types of SIBs. The SIBs that carry information relevant for cell

selection and re-selection are SIBs 1, 2, 3, 4,5, 11 and 12.

For example, SIB 1 carries various parameters related to Non Access Stratum (NAS) and the core

networks (CN). It also specifies various constants and timers the UE has to use during various operations

such as cell re-selection. Various cell selection and re-selection criteria are specified in SIB 3 (for idle

mode) and SIB 4 (for connected mode). In addition, SIBs 11 and 12 also describe parameters related to

specific radio measurements. The system information block type 5 contains parameters for the

configuration of the common physical channels in the cell.

In R6, SIB 5 has been modified to indicate whether it is an “HSDPA-capable cell”, which means that the

UE may consider this cell as part of the HSDPA coverage area.

The UTRAN broadcasts an HSDPA cell indicator in SIB block 5 to indicate whether the cell is HSDPA-

capable or not.

HSDPA Cell Indicator - R6

4-112



HSDPA Cell Indicator HSDPA Cell Indicator -- R6R6

UE

Node B

SIB 5Configuration of common physical

channel parametersHSDPA cell indicator

4-113



Most of the parameters in the RRC connection establishment procedure in R6 are the same as in R5, but a

few parameters carried by these messages indicate HSDPA support. The enhancements in R6 include:

1. RRC Connection Request sent by the UE

• Domain Indicator: Indicates whether the Core Network (CN) is Circuit-Switched (CS)

or Packet-Switched (PS). In an HSDPA data call, the call is routed by the RNC to the

SGSN in the PS domain through the Iu Interface.

• Access Stratum Release Indicator: Should support R6 also

• UE Capability Indication: Sent by the UE to inform the RNC about its indicating its

HSDPA functionality

2. RRC connection setup sent by UTRAN

• H-RNTI Assignment: H-RNTI is the HSDPA UE Identity. The H-RNTI is an ID for the

UE that will be doing HSDPA within a cell. The H-RNTI variable is a 16-bit string that

stores the assigned H-RNTI for this UE when in the CELL-DCH state and a HS-DSCH

transport channel has been allocated. It gets cleared when leaving the UTRA RRC-

connected mode.

• Downlink HS-PDSCH: The HS-PDSCH is a new channel in HSDPA that carries high-

speed packet data traffic. It is a shared channel across all users requesting HSDPA

specific high-speed packet data services.

Downlink HS-PDSCH includes the information parameters such as HS-SCCH control

information, which consists of the DL Scrambling code to be applied for HS-SCCH, HS-

SCCH channelization codes, the maximum number of Dedicated Physical Data Channels

(DPDCH) from which HS-DPCCH channelization codes are derived by the UE and

measurement feedback information that is used for the channel quality indication (CQI)

procedure in the physical layer on the serving HS-DSCH radio link.

3. The RRC Connection Complete message from the UE may carry UE radio access capability

parameters whose contents are the same as in the R5 RRC Connection Complete message.

RRC Connection Enhancement - R6

4-114



RRC Connection Enhancement RRC Connection Enhancement -- R6R6UE RNC


• UE capability indication- HS-DSCH


• H-RNTI, DL HS-PDSCH info

RRC Connection Complete

• (HS-DSCH physical layer category)

4-115



In R5, whenever a user is configured to use the HS-SCCH and HS-PDSCH, it is mandatory to set up

Dedicated Physical channels (DPCH) in both the UL and DL. The DPCH carries pilot and TPC bits

(control part) if the user is not doing any conversational services. Since each DPCH requires a code to be

used in UL and DL, R6 introduced the Fractional Dedicated Physical Channel (F-DPCH), a more efficient

management of code resources that allows HSDPA users to share given codes. To maximize the number

of UEs that can be multiplexed on one code, it is assumed that:

• DCCH signaling is carried on the HS-DSCH

• UE-specific TPC bits are present to maintain the UL power control loop for each UE

• Pilot bits can be present to allow the F-DPCH to be power-controlled and allow DL

synchronization to be maintained by each UE. However, further study is required to determine

whether the F-DPCH needs to carry dedicated pilots.

This slide illustrates the dedicated channels DPCH1, DPCH2 and DPCH3 associated with HS-SCCH(s)

and HS-PDSCH(s) for 2 different UEs configured to use HS-SCCH and HS-PDSCH.

When the DL timings of these channels are properly chosen, it appears that the DL spreading codes is not

necessary to distinguish between the UEs. A single code is sufficient to carry TPC and pilot bits associated

with these HSDPA UEs and still maintain the same periodicity of one slot for the transmission of this

information in the downlink.

If only TPC bits are transmitted, the number of TPC bits can be the same as in R99, or can be increased to

equal the number of pilot bits in R99.

F-DPCH Requirement

4-116



Subframe SubframeSubframe#1#0

Subframe Subframe Subframe#3 #4 #5 #6 #7#2

FF--DPCH Requirement DPCH Requirement

UE1

UE2

Node B

CPICH

10 ms

PCCPCH

UE 1 DPCH

UE 2 DPCH

Subframe Subframe

UL 1 DPCCH

UL 2 DPCCH

TPC +Pilot bits for one slot

F-DPCH

HS-PDSCH

4-117



The RNC receives the RANAP RAB Assignment Request message from the SGSN requesting RAB

assignment. The RNC requests a Node B to prepare for reconfiguration of the F-DPCH in the downlink.

The RNC sends a Radio Link Setup Request message. The Node B reserves necessary resources and

configures the new radio link(s) according to the F-DPCH information, such as DL power control,

included in the message. It also includes the reference F-DPCH transmission power in case the Node B is

configured to use the F-DPCH in the downlink. It ranges from 0 to 6 dB in steps of 0.25 dB.

The Node B responds to the RNC by sending an RL Setup Response message to RNC.

Once the RNC receives the F-DPCH parameters, it forwards them to the UE in a Radio Bearer Setup

message. The message includes the downlink F-DPCH information for each radio link. The information

consists of elements such as:

• Primary CPICH usage for channel estimation

• The F-DPCH frame offset is called τF-DPCH,n which contains offset (in number of chips) between the

beginning of the P-CCPCH frame and the beginning of the F-DPCH frame

• Secondary CPICH information

• Secondary scrambling codes

• Code numbers

• TPC combination index radio links with the same index have TPC bits, which for the UE are

known to be the same

F-DPCH Assignment

4-118



FF--DPCH AssignmentDPCH AssignmentUE Node B SGSN

RL Setup Request

RNC


RL Setup Response

Radio Bearer Setup

• RAB ID

• F-DPCH info • Power Offset info

• Downlink F-DPCH info for each RL

4-119



The UE transmits an ACK/NACK in response to HS-DSCH transmission. In R5, when the ACK/NACK

is not transmitted on the HS-DPCCH, the UE always uses DTX in the ACK/NACK field of the HS-

DPCCH. For example, if the UE fails to detect the HS-SCCH contents, the UE will use DTX in the

corresponding ACK/NACK field. This may lead the Node B to misinterpret this DTX as an ACK, which

might cause loss of the HS-DSCH data at the physical layer.

To reduce the probability of such misinterpretations, the transmission power of ACK messages must be set

to a high value. So, there should be a desirable method by which the Node B can set its ACK detection

threshold closer to DTX without resulting in misinterpretations. R6 employs an effective method to

distinguish between DTX and ACK on the HS-DPCCH without requiring large ACK transmit power.

Along with ACK/NACK transmit power, the Preamble (“PRE”) and Postamble (“POST”) are being

transmitted on HS-DPCCH. The code words of PRE and POST are given in the slide. The PRE codeword

is transmitted in a packet burst prior to transmitting the HARQ ACK message when the UE detects the

HS-SCCH control information. A POST codeword is transmitted after transmission of a HARQ ACK

message, unless another HS-DSCH packet is detected. The transmission of the PRE and POST codeword

depend on the current value of repetition factor N_acknack_transmit and the UE capability inter-TTI.

ACK/NACK Transmit Power Reduction - R6

4-120



ACK/NACK Transmit PowerACK/NACK Transmit PowerReduction Reduction -- R6R6

Node BUE

ACK ACK

NACK NACK

PRE PRE

POSTPOST

1111111111

0010010010

0000000000

0100100100

Channel Coding

(1, 10)

# of I/P bits

# of O/P bits

HS-DPCCH info

4-121



This example shows how preamble (PRE) and postamble (POST) code words are sent when

N_acknack_transmit = 1. For clarity, the HS-DPCCH and HS-SCCH subframes corresponding to the HS-

DSCH subframe “N” are both given the same subframe designation, “N.” The two parts of this scheme are

as follows:

• The UE transmits a PRE in subframe N-1 on the HS-DPCCH when the UE detects control

information for it in subframe N on the HS-SCCH. The preamble is not transmitted in subframe N-

1 if an ACK or NACK is to be transmitted in N-1 as a result of a packet in an earlier subframe on

the HS-DSCH

• The UE decodes the HS-DSCH packet and transmits the HARQ ACK/NACK in subframe N on the

HS-DPCCH. If the UE's Inter TTI capability is 1, the UE transmits a POST in subframe N+1 on

the HS-DPCCH (unless a packet is detected in subframe N+1 on the HS-DSCH, in which case an

ACK/NACK is sent, or HS-SCCH control information is detected in subframe N+2, in which case

a PRE is sent).

If the UE's inter-TTI capability is greater than 1, there is no need to transmit the POST in subframe N+1,

because an HS-DSCH packet cannot be received in subframe N+1 on the HS-DSCH.

From subframes N+2 and onward on the HS-DPCCH, the UE goes back to using the DTX in the

ACK/NACK field unless new relevant control information is detected on the HS-SCCH.

Pre - Post Example

4-122



Pre Pre -- Post ExamplePost Example

N N+2 N+3N+1

N N+1 N+2 N+3Data packet

HS-SCCH

HS-DSCH

HS-DPCCH PRE ACK or NACK POST

NN-1 N+1 N+2

PREAMBLE transmitted in sub-frame N-1 to indicate reception of relevant signaling information in sub frame N on HS-SCCH

Normal ACK/NACK to indicate correct or incorrect decoding of packet

POSTAMBLE transmitted in sub-frame N+1 (unless a packet is correctly decoded from sub-frame N+1 on the HS-DSCH, or control information is detected in subframe N+2 on the HS-SCCH

4-123



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Summary

4-124



SummarySummary• RRC establishment procedures have been

enhanced to include the HS-DSCH capability of the UE

• Radio Link (NBAP), Radio Bearer Setup (RRC) and Radio Bearer reconfiguration procedures have been enhanced to assign HSDPA logical, transport and physical channel parameters to the UE

• The SRNC configures the Node B and UE with QoS parameters for receiving scheduled data at the UE and the scheduling of resources at the Node B

• The UE determines the CQI and reports it on the HS-DPCCH. The Node B uses this as one of the key inputs to schedule HS-DSCH resources.

• When an HS_DSCH best cell change occurs, intra-Node B and inter-Node B handovers are possible

4-125



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Review Questions

4-126



Review QuestionsReview Questions1. Which message carries HS-DSCH physical

layer capabilities?2. What is the significance of assigning an

H-RNTI?3. What is a MAC-d flow?4. What is the purpose of the queue ID and

TSN in the MAC-hs header?5. What is the function of the HARQ entity in

the UE and Node B?

4-127


HSUPA Data Call Setup

HSUPA Data Call HSUPA Data Call SetupSetup

5-1



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Objectives

5-2



ObjectivesObjectives

After completing this module, you will be able to:• Identify the RRC Connection enhancements• Describe the Radio Bearer enhancements during

HSUPA data call set up• List the HSUPA channel assignments• Describe how the UE selects the E-TFC and how the

Node B schedules during an HSUPA data call• List the various types of radio reconfiguration types

used during HSUPA data call set up• List various types of handovers used in HSUPA and

when they are used

5-3



The support of HSUPA requires enhancement of the Radio Resource Control (RRC), Message

Authentication Code (MAC) and physical layer protocols.

Some of the Major RRC enhancement procedures required are mentioned below for HSUPA Release 6

implementation:

• RRC connection establishment needs enhancement to support HSUPA capabilities at the UE and

assignment of signaling radio bearers for the control plane

• HSUPA introduces a new HSUPA Enhanced Dedicated Channel (E-DCH) transport channel, and

uplink and downlink physical channels. The RRC is responsible for assignment of E-DCH transport

channel parameters, physical channel spreading codes and their spreading factors.

• Radio bearer setup and radio bearer reconfiguration have been enhanced to configure logical

channels, E-DCH transport channels and physical channels according to Quality of Service (QoS)

requested by the core network

• The RRC at the Radio Network Controller (RNC) configures the RRC at the UE with certain QoS

parameters that enable the UE to choose the best transport block size and enhanced transport format

combination selection (E-TFC selection) for high speed uplink data transmission.

• The RRC decides, coordinates, and executes soft handovers during HSUPA calls. This can be

within sectors of the serving Node B or Inter Node B/Inter RNC.

HSUPA Enhancements

5-4



HSUPA EnhancementsHSUPA Enhancements

RRC Enhancements

E-TFC selection Handover Procedures

(Best Cell Change)

GrantsInterference management

HARQ+IR

UE-RRCRNC-RRC

MAC-e RL Setup changes


MAC-es

Node B

5-5



The MAC layer is also enhanced at both the UE and UMTS Terrestrial Radio Access Network (UTRAN)

to support high speed uplink transmission.

A new MAC entity (MAC-es) is added at the Serving Radio Network Controller (SRNC) to provide in-

sequence delivery (re-ordering) and to handle combining of data from different Node Bs in a soft

handover.

A new MAC entity (MAC-e) is introduced in the Node B to handle HARQ retransmissions, scheduling

and MAC-e demultiplexing.

A new MAC entity (MAC-es / MAC-e) is implemented in the UE below the MAC-d. The MAC- es /

MAC-e in the UE handles Hybrid ARQ (HARQ) retransmissions, scheduling, MAC-e multiplexing, and

transport block size selection (Enhanced Dedicated Channel (E-DCH) Transport Format Combination (E-

TFC) selection).

HSUPA Enhancements (continued)

5-6



HSUPA Enhancements HSUPA Enhancements (continued)(continued)

RRC Enhancements

E-TFC selection Handover Procedures

(Best Cell Change)

GrantsInterference management

HARQ+IR

UE-RRCRNC-RRC

MAC-e RL Setup changes


MAC-es

Node B

5-7



To perform cell re-selection, the UE first needs to know the necessary system information about the

system it is camping on. In addition, the UE needs to be aware of the systems that are in the surrounding

geographical area – the neighbor cells.

The UE searches for the strongest cell and performs the Public Land Mobile Network (PLMN) selection

and cell selection. First, it synchronizes with the current cell. Then it monitors the Broadcast Channel

(BCH) and gathers information about the current cell and its neighbors from the System Information

Blocks (SIBs). The system information block groups together system information of the same nature. The

SIBs are sent on the BCH periodically. The UMTS specification describes over fifteen different types of

SIBs. The SIBs that carry information relevant for cell selection and re-selection are SIBs 1, 2, 3, 4, 5, 11

and 12.

For example, SIB 1 carries various parameters related to Non Access Stratum (NAS) and the core

networks (CN). It also specifies various constants and timers the UE has to use during various operations

such as cell re-selection. Various cell selection and re-selection criteria are specified in SIB 3 (for idle

mode) and SIB 4 (for connected mode). In addition, SIBs 11 and 12 also describe parameters related to

specific radio measurements. The system information block type 5 contains parameters for the

configuration of the common physical channels in the cell.

In Release 6, SIB 5 has been modified to indicate whether there is an HSUPA-capable cell, which means

that the UE may consider this cell as part of the HSUPA coverage area.

The UTRAN broadcasts the “EDCH cell indicator” in SIB block 5 to indicate whether the cell is HSUPA-

capable. Please Refer to 25.331 specs for further details.

HSUPA Cell Indicator

5-8



HSUPA Cell Indicator HSUPA Cell Indicator

R6 Indicates HSUPA-capable Cell

SIB 5 Configuration of Common

Physical Channel ParametersEDCH Cell Indicator

5-9



The figure depicts an overview of the procedures involved in the data call setup scenario. The first

mandatory procedure is to set up resources for the control plane. Therefore, the scenario starts with the

“Radio Resource Control (RRC) Connection Establishment” to create the UE – UMTS Terrestrial Radio

Access Network (UTRAN) signaling connection. Once the RRC connection has been established, the UE

contacts the core network using the first Non Access Stratum (NAS) message (here called Service

Request). As usual, the core network may or may not initiate the security procedures like authentication.

Assuming that the outcome has been successful, the UE starts the “Log in” procedure, which also is a

request for an IP address. This procedure is called “Packet Data Protocol (PDP) Context Activation,”

which also involves the negotiation of the QoS parameters.

After a successful negotiation, the Serving GPRS Support Node (SGSN) triggers the setup of resources for

the user plane using the Radio Access Bearer (RAB) Assignment procedure. Here we assume, based on

the QoS parameters, that the Radio Network Controller (RNC) always sets the cell Dedicated Channel

(DCH) to be the RRC state for the UE to establish the HSUPA radio bearer. Therefore, it starts the Radio

Link Setup procedure toward the Node B on the Iub interface. Once the RNC and the Node B have further

synchronized the bearer, the RNC can start the Radio Bearer Setup procedure over the air interface. The

PDP context procedure is finalized with an Accept message sent by the SGSN to the UE.

Data Call Setup - HSUPA

5-10



Data Call Setup Data Call Setup -- HSUPAHSUPAUE RNC GGSN

1. RRC Connection Establishment

2. Service Request

3. Security Procedures

4. PDP Context Activation Request

6. RL Setup5. RAB Assignment

8. Act. PDP Context Accept

7. Radio Bearer Setup

Node B SGSN

Bearer Synch

5-11



In addition to “R99” and “R5” parameters, the RRC connection establishment procedure in “R6” carries

some important parameters that indicate Enhanced Dedicated Channel (E-DCH) support. The major

parameters transmitted include:

1. The RRC Connection request sent by the UE

• Initial identity: PTMSI, TMSI and RAI (Routing Area Identity).

• Establishment Cause: Originating streaming call, originating interactive call, originating

background call, etc.

• Domain Indicator: Indicates whether the CN (Core Network) is circuit-switched (CS) or

packet-switched (PS). In the case of an HSUPA data call, the call is routed by the RNC to

the SGSN in the PS domain through the Iu Interface.

• The Access Stratum release indicator should support “R6” also

• The UE sends a UE-capability indication that it is capable of supporting E-DCH( HSUPA)

+ HS-DSCH (HSDPA) functionality or only HS-DSCH functionality

RRC Connection Enhancements

5-12



RRC Connection EnhancementsRRC Connection EnhancementsUE RNC


• UE Capability Indication - HS-DSCH+E-DCH


• Primary E-RNTI, Secondary E-RNTI, E-DCH info

RRC Connection setup Complete

• EDCH Physical layer category

5-13



2. Radio Resource Control (RRC) connection setup is sent by the UMTS Terrestrial Radio

Access Network (UTRAN)

• Enhanced Dedicated Channel (E-DCH) Radio Network Temporary Identifier (E-

RNTI) Assignment: The E-RNTI is the HSUPA UE Identity. The E-RNTI indicates that

the UE has a High Speed Physical Downlink Shared Channel (E-DCH) assignment within

a cell. There are two types of E-RNTIs: Primary E-RNTI and secondary E-RNTI. A UE

can be assigned both a primary and secondary E-RNTI or only a secondary E-RNTI. All

UEs can be assigned only primary E-RNTIs. If the UE needs to be given another set of

resources based on the Quality of Service (QoS), it can be assigned a separate secondary E-

RNTI. The E-RNTI variable is a 16-bit string and stores the assigned E-RNTI for this UE

when in CELL-DCH state and an Enhanced Dedicated Channel (E-DCH) transport channel

has been allocated.

• E-DCH Information: E-DCH information includes parameters such as Enhanced

Dedicated Physical Control Channel (E-DPCCH) information, Enhanced Dedicated

Physical Data Channel (E-DPDCH) information, and whether the radio link is a serving

link. It also includes the E-DCH Absolute Grant Channel (E-AGCH), E-DCH Relative

Grant Channel (E-RGCH) and E-DCH HARQ Acknowledgement Indicator Channel (E-

HICH) spreading codes for each link. This message also indicates whether UE radio access

capability is required to be sent on the Radio Resource Control (RRC) Connection

Complete message.

RRC Connection Enhancements (continued)

5-14



RRC Connection Enhancements RRC Connection Enhancements (continued)(continued)

UE RNC


• UE capability Indication - HS-DSCH+E-DCH





5-15



3. Radio Resource Control (RRC) Connection Setup Complete

• The UE now enters the “CELL-DCH” state and sends the last RRC message for the

establishment of the RRC connection called “RRC Connection Setup Complete.” It sends

the CN domain ID and, if asked in the RRC Connection Setup, its Radio Access

Capability. This message is sent using the RLC-AM, and the RNC responds with an “RLC

Status PDU” (an acknowledgement) to handshake the start of the acknowledge mode with

the UE. The UE sends the Radio access capability, which contains the most information for

the Enhanced Dedicated Channel (E-DCH).

• Physical Channel Capability: This indicates the support of the E-DCH and the physical

layer category (UE categories 1-6). Each UE category indicates the maximum number of

E-DCH codes transmitted, minimum spreading factor, support of the 10 ms and 2 ms

Transmission Time Interval (TTI) E-DCH, and the maximum number of bits of an E-DCH

transport block transmitted within 10 ms and 2 ms E-DCH TTI.

RRC Connection Enhancements (continued)

5-16



UE RNC


• UE capability Indication - HS-DSCH+E-DCH



RRC Connection setup Complete


RRC Connection Enhancements RRC Connection Enhancements (continued)(continued)

5-17



Service Request: The service request is defined as the Initial Direct Transfer message in UMTS. It is sent

to the RNC by the UE containing the UE identity in the Packet-Switched (PS) domain (P-TMSI), a

reference number to the latest authentication procedure, Key Set Identifier (KSI) and the type of service

(Signaling).

On receiving the initial Direct Transfer (service Request) from the UE, the RNC further transfers the

request to the SGSN using a Connection Oriented message to set up the Iu connection.

In response, the SGSN starts security procedures, which includes the Security Mode Command. This

message carries the specified ciphering and integrity protection algorithm and keys to be used by the

UTRAN. Once the security procedures are completed, all subsequent signaling and data are sent securely

over the air interface.

When all the bearer channels are set up for carrying traffic, the UE sends an SM Activate PDP Context

Request for the SGSN. It is an RRC Direct Transfer message, which is sent over the Iu interface by the

RANAP Direct Transfer. The purpose of the message is to describe the service that the UE wants to

activate, and contains the requested QoS profile. The message includes the NSAPI, and is added to

identify this PDP context. To communicate with the packet-switched (PS) domain, it is essential to have

information regarding the IP address. It also includes the “Requested PDP Address” parameter and Access

Point Name (APN), which determines the entity that allocates the IP address. It also includes the Logical

Link Control Service Access Point Identifier (LLC- SAPI).

The SGSN now receives the Activate PDP Context message from the RNC using the RANAP DT over the

Iu connection. Once it receives the request, it first uses the APN to find the GGSN and then starts a

“handshake” with the GGSN to negotiate the QoS parameters and create the GTP tunnel.

In response, the GGSN then sends a “Create PDP CTX Request” to the RNC, which indicates that the CN

has provided the mobile with resources needed for packet transfer, and includes the negotiated QoS profile

with the UE IP address. Once the GTP tunnel is created, the tunnel endpoint identity TEIDS and GGSN IP

address are also sent.

As compared to R99, no changes are required in the service request to support HSUPA. The only

difference is that higher QoS can be supported.

Initial Data Call Setup

5-18



Initial Data Call SetupInitial Data Call SetupUE RNC GGSNInit. Dir. Transfer (Service Req.)

CR [IUM (Service Req.)]

UL DT (Activate PDP CTX Req.)

DT (Act. PDP CTX Req.)

SGSN

Create PDP CTX Req.

Security Procedures

Create PDP CTX Resp.

Check subscription: APN & QoS

use APN GGSN addr

• No Changes for HSUPA except that higher QoS canbe requested/negotiated

Requested QoS Profile• Traffic Class: Interactive• Max Bitrate

• P-TMSI• Service Type: signaling

5-19



The RAB Assignment Request is sent by the CN to the RNC, which includes the RAB ID and QoS. This

indicates a need for relatively high bit rates on uplink. Some additional inquiry regarding UE capability is

required in Release 6 to support HSUPA

If the UE Capability was not received during the Radio Resource Control (RRC) Connection Complete

message, the UTRAN asks for the mobile capability using the UE Capability Inquiry message. The most

interesting information element here, for the RNC, is the so-called “UE Physical layer Category.”

Since the RNC has requested a capability update, the UE sends the UE Capability Information message.

The most valuable piece of information here is whether the UE supports the Enhanced Dedicated Channel

(E-DCH) (HSUPA) and, if so, its category. These parameters are included in the Physical Channel

Capability message.

UE Capability - R6

5-20



UE Capability UE Capability -- R6R6

Node B

UE

RNC

UE Capability Inquiry

CN

RAB Assignmt Req

UE Capability Information Only if not sent in RRC

Connection Establishment

(Request for RA – Capability including category info)

• DL Capability with simultaneous HS-DSCH configuration

• PH-CH Capability• Support for E-DCH• E-DCH “Category”

5-21



When the service between the GGSN and SGSN is negotiated with a specific QoS profile, the SGSN sends

a RANAP RAB Assignment Request message to the RNC to set up user plane resources. Then, it requests

the UTRAN to allocate the necessary radio resources via the Radio Access Bearer (RAB) Assignment

Request.

The RAB assignment is the mechanism for the CN to notify the UTRAN of the appropriate Quality of

Service (QoS) and attributes required to delivery of the service. This request is translated into a radio link

setup request sent from the Radio Network Controller (RNC) to the Node B via Node B Application Part

(NBAP) signaling. It is also translated into a Radio Bearer Setup message sent from the RNC to the User

Equipment (UE) via Radio Resource Control (RRC) signaling. Once the radio resources have been

assigned and set up, the RNC communicates with the Node B with the AAL2 bearer. The RAB

Assignment Response completes the RAB by setting up the Iu (GTP) between the SGSN and RNC in the

case of a packet-switched data call. An ATM Adaptation Layer Type 5 (AAL5) connection is set up

between the RNC and Node B.

Finally, the resources available at the Node B and UE agree to the radio bearer, and a successful RAB

assignment response is sent to the Packet Switched Core Network (PS-CN).

Radio Access Bearer Assignment

5-22



UserPlane

Radio Access Bearer AssignmentRadio Access Bearer Assignment

RNCNode B

PS-CN PSTNIub IuUu

IuRRC

Setup Radio Link


Setup Radio Bearer

Iu/AAL5

Complete the RAB

Radio Bearer (RB)

UE

RAB RB+Iu (GTP) bearer defines required QoS

ControlPlane

5-23



Let us discuss basic terminology introduced as part of Enhanced Dedicated Channel (E-DCH) operations

in HSUPA. The E-DCH is independent of the DCH defined in R99. Radio resource allocation and

configuration does not have to be identical to R99-based DCH allocations or R5-based HS-DSCH

allocations.

• DCH Active Set: R99-defined active set. The set of cells that provides radio resources to carry

traffic for the DCH. Per the R99 definition, it is a collection of cells that support DCH traffic to the

UE in both uplink and downlink directions.

R6 defines the E-DCH active set, serving E-DCH cell, serving E-DCH Radio Link Set and non-serving E-

DCH radio links for HSUPA operations. Let us define these terms now.

• E-DCH Active set: It defines the set of cells that carry the traffic for E-DCH on the uplink. These

cells also support associated physical layer channels on the downlink to support E-DCH operations

for the UE. The E-DCH active set is an identical or a proper subset of the DCH active set.

• Serving E-DCH cell: This is the cell from which the UE receives absolute grants for E-DCH. In

other words, this cell controls the radio resource allocations (i.e., power offset with respect to

DPCCH for the E-DPDCH). Each UE on the E-DCH has one and only one serving cell. The

serving E-DCH cell is a member of the serving E-DCH RLS.

• Serving E-DCH Radio Link Set (RLS): This is defined as the set of cells, including the serving

E-DCH cell, from which the UE may receive and combine relative grants. From a practical

perspective, the serving E-DCH RLS consists of the active set member cells from the Node B that

contains the E-DCH serving cell.

• Non-serving E-DCH RL: Every cell that belongs to the E-DCH active set but is not part of the

same Node B that contains the serving cell. These cells send relative grants to the UE, but these

grants cannot be combined at the UE receiver. Every UE on E-DCH may have zero, one or more

non-serving E-DCH radio links.

E-DCH Terminology

5-24



EE--DCH TerminologyDCH Terminology

C3 C1

C2

Node B1 Node B2

Node B3

C5

C4DCH Active Set: {C1, C2, C4, C5}

E-DCH Active Set:{C1, C2, C4}

C1: E-DCH Serving Cell

Serving E-DCH RLS:{C1, C2}

Non-serving E-DCH RLS: {C4}

5-25



This diagram illustrates the role of different channels involved in HSUPA. In this example, the Enhanced

Dedicated Channel (E-DCH) has an active set consisting of 3 sectors from 2 different Node Bs. A serving

E-DCH cell is designated by the RNC as part of radio link setup process through Radio Resource Control

(RRC) signaling. The cells that are not part of the serving cell’s Node B are referred to as the non-serving

E-DCH radio link set. The following channels are processed by the UE:

1. The UE receives absolute grant information from the E-DCH serving cell on the E-DCH Absolute

Grant Channel (E-AGCH).

2. The UE also receives a relative grant (i.e., corrections) from the serving and non-serving E-DCH

RLSs on the E-DCH Relative Grant Channel (E-RGCH).

3. The UE transmits information on the uplink using the E-DPDCH (and associated control

information is sent on the E-DPCCH).

4. When the E-DCH Active Set cells receive this information, a Hybrid ARQ (HARQ) process at

each cell (in the E-DCH Active Set) transmits an ACK or a NACK based on the information

received related to current packets using the HARQ approach.

5. Along with HSUPA channels, R99 channels, DL DPCH and UL DPCH also exist. These

channels consist of pilot and power control bits. The power control bits sent on the DL DPCH are

used to power control UL DPCCH. E-DPDCH and E-DPCCH powers are relative to the UL

DPCCH power.

Channel Usage

5-26



Channel UsageChannel Usage

UE

Serving Node B

High Speed Data and control data

E-DPDCH / E-DPCCH

Scheduling/Noise Control

E-AGCH/E-RGCH

Scheduling

E-DPDCH / E-DPCCH

E-RGCH

E-HICHE-HICH

ACK/NACK

Data, Signaling / TPC, TFCI, Pilot

DPDCH/DPCCH

DPCH

Data, Signaling / TPC, TFCI, Pilot

DPCH

DPDCH/DPCCH

Noise Control

Non-Serving Node B

5-27



HSUPA physical downlink channel information is sent on the Radio Bearer Setup or Radio Bearer

Reconfiguration message.

• E-AGCH spreading codes of spreading factor 256 are carried by the Radio Bearer Setup message

or Radio Bearer Reconfiguration message from the RNC to the UE.

• The RNC assigns E-RGCH spreading codes of spreading factor 128 to the UE and also sends one

of the 40 signature sequences for each radio link on the serving and non-serving RLS. The relative

grants are primarily power control commands chosen according to the uplink RoT measured by the

serving and non-serving RLSs.

• The RNC also assigns E-HICH information to the UE for every radio link in the serving and non

serving RLSs whose spreading codes and signature sequences are the same as the E- RGCH. The

E-HICH carries HARQ ACK/NACK information.

HSUPA DL Channels Assignment

5-28



HSUPA DL Channels AssignmentHSUPA DL Channels Assignment

Node B

Node B

Serving RLS

Non-Serving RLS

UE

E-AGCH

• E-AGCH CC with SF = 256• Only assigned by serving E-DCH

cell

E-RGCH

• E-RGCH CC with SF = 128 and signature sequences

• Serving and non-serving RLS

HICH

• Same CC and signature seq. asE-RGCH

• Serving and non-serving RLS

RB setup

5-29



The E-DCH Dedicated Physical Data Channel (E-DPDCH) carries the E-DCH transport channel. The E-

DPDCH supports both 10 ms TTI and 2 ms TTI. If 2 ms TTI is used, E-DPDCH uses a 2 ms subframe for

transmission. Depending on the data rates required for uplink E-DCH transmission, the UE may use 1 or

more E-DPDCHs. The E-DPDCH uses a range of spreading factors (2 to 256) to support different data

rates. For example, to support a 1.92 Mbps data rate, the E-DPDCH uses SF = 2. As the data rates go

down, the SF value goes up (i.e., more spreading gain). For example, when the desired data rate on the E-

DPDCH is 60 kbps, SF = 64 is used. The E-DPDCH is power-controlled by the Node B. In addition, soft

handover is supported on the E-DCH. To support soft handover, HSUPA defines the concepts of serving

E-DCH cell, serving E-DCH Radio Link Set (RLS) and non-serving E-DCH RLS.

The E-DCH Dedicated Physical Control Channel (E-DPCCH) is the E-DCH associated physical layer

signaling channel transmitted by the UE. There is at most one E-DPCCH per UE. No E-DCH/E-DPDCH

transmission can occur without an associated E-DPCCH transmission. E-DPCCH control information is

transmitted at a rate of 15 kbps using a spreading factor of 256. The spreading code of E-DPCCH is fixed

to (CC256,1).

HSUPA UL Channel Assignment

5-30



HSUPA UL Channel AssignmentHSUPA UL Channel Assignment

UE Serving Node B

High Speed Data and Signaling

E-DPDCH / E-DPCCH

SchedulingNoise control

E-DPDCH / E-DPCCH

Non-Serving Node B

• Assigned in Radio Bearer Setup message• E-DPDCH CC SF varies from 2 to 256 • E-DPDCH sent on 2 or 10ms TTI• E-DPCCH CC is fixed (CC256,1)

5-31



The SRNC configures the Node B and UE with various Quality of Service (QoS) related information.

Let us discuss the parameters provided by the SRNC to the Node B to enable reservation of resources and

scheduling.

• Scheduling priority for each logical channel mapped to the E- DCH and the corresponding mapping

between the logical channel identifier and DDI value.

– The Data Description Indicator (DDI) is nothing but mapping between the MAC-d PDU

size and the Enhanced Dedicated Channel (E-DCH) MAC-d flow ID.

– The E-DCH MAC-d flows are defined as MAC-es PDUs, carrying MAC-d data sharing

the same traffic characteristics, and that can be multiplexed with MAC-es PDUs of the

same or other MAC-d flows on the MAC-e.

– There can be up to 8 MAC-d flows and 15 Logical channels that can be multiplexed on

the transport channel (E DCH).

• The maximum UL, UE power, non-scheduled grant for MAC-d flows

• The HARQ profile per MAC-d flow, which consists of the power offset attribute and maximum

number of transmissions attribute

• E-DPCCH power offset: The Node B can use this power offset to convert between rate and power

in its resource allocation operation

• Power offsets for reference E-TFCs

Assignment of QoS Parameters to the Node B

5-32



Assignment of QoS Parameters to the Assignment of QoS Parameters to the Node BNode B

Node BRNC

RLC AM/UM

RRC

DTCH 1 DTCH 2 DCCH

MAC-d

MAC-d flows

MAC-es

MAC-d flows

MAC-d flow =1

MAC-d flow =2

MAC-e

Logical Channel IDsLogical Cha PriorityMAC-d Flow IDs

RL Setup Request

DDI• E-DCH MAC-d Flow ID • MAC-d PDU size • MAX UE Power

• E-DPCCH PO

HARQ• Power Offset• Max # of

Transmissions

5-33



The QoS related parameters provided by the SRNC to the UE on the Radio Bearer Setup message enable

QoS-based E-TFC selection. The MAC-e functionality at the UE performs E-TFC selection, the

multiplexing of logical channels in MAC-e PDUs and HARQ operation.

E-TFC selection Parameters

• Power Offset for Reference E-TFCs: The reference E-TFC and its power offset are sent to

the UE, mainly to maintain the same level of quality for other E-TFCs calculated by UE

identical to reference E-TFCs

• E-DPCCH Power Offset: This is the relative power difference between the DPCCH and E-

DPCCH

DDI (Data Description Indicator)

• Logical Channel Priority: The priority is based on the QoS requested by the UE. For

example, logical channel DTCH 1 can have a high priority than DTCH 2.

• Mapping between Logical Channels and MAC-d Flows: For example, DTCH 1 is mapped

to MAC-d flow ID 1. DTCH 2 and DCCH are multiplexed as a single MAC-d flow ID 2.

HARQ Profile

• The HARQ Profile per MAC-d flow consists of the power offset attribute and maximum

number of transmissions attribute. The E-TFC selection mechanism in the UE uses the power

offset attribute to choose the BLER operating point for the transmission. Maximal latency can

be regulated by the maximum number of transmissions attribute.

Grant Parameters

• Non-Scheduled grant for MAC-d flows configured for non-scheduled transmissions

Assignment of QoS Parameters to the UE

5-34



Assignment of QoS Parameters Assignment of QoS Parameters to the UEto the UE

UE Node B RNC

RRC

MAC-es / e

DTCH 1 DTCH 2

RLC AM/UM

RRC Radio Bearer Setup• DDI Logical channel id, PDU size. MAC-d flow ID• E-TFCI selection Parameters, Happy bit delay condition

MAC- d flowsMAC-d flow 1

MAC-d flow 2

DDI E-TFC Selection Parameters

HARQ Profile

Non-Scheduled Grant

DCCH

MAC-d

5-35



Up to this point, the RNC has been informed, from the SGSN, about the requested QoS parameters, and

has also found out exactly what the UE may be able to support. Therefore, it is now time to start preparing

the Node B for traffic. For that reason, the RNC sends the radio link setup request over the Iub interface

using the Node B Application Part (NBAP) protocol. This message contains all the parameters it had for

R99 and R5, but now has the HSUPA-related parameters as well. Some important parameters are:

• Enhanced Dedicated Channel (E-DCH) RL Indication: Indicates whether each link in the active

radio link set is an E-DCH RL

• E-AGCH, E-RGCH and E- HICH power offset

• Maximum number of spreading codes for the E-DPDCH and the puncture limit. The puncture limit

indicates the amount of puncturing applied in order to minimize the number of dedicated physical

channels.

• Reference E-TFCI information and the reference E-TFCI power offset

• The 2 ms or 10 ms TTI information for the E-DCH, which indicates whether the RSN-based RV

index is used or RV = 0

• The list of E-DCH MAC-d flow IDs and their corresponding power offsets, and the maximum

number of transmissions

• Scheduling priority indicator, E-DCH DDI value mapping with MAC-d flow ID and MAC-d PDU

size, as well as the maximum number of bits per MAC-e PDU

RL Setup Enhancements

5-36



RL Setup EnhancementsRL Setup EnhancementsUE Node B SGSN

RL Setup Request

RNC


RL Setup Response

• E-DCH DDI mapping • Maximum number of EDPDCH CCs

5-37



Upon reception of the RL Setup Request message, the Node B is supposed to answer with the Radio Link

Setup Response message. Again, on top of all Release 99- and R5-related parameters, we also see the

HSUPA-related parameters, such as:

• The spreading code of E-AGCH, E-RGCH and E-HICH for each radio link

• The signature sequences of the E_RGCH and E-HICH for each radio link

• Primary E-RNTI and secondary E-RNTI value and an indication whether the Grant selector is

primary or secondary

• Serving cell determination of the initial serving grant value

• HARQ process allocation for scheduled transmission grant and 2 ms non–scheduled grant

RL Setup Enhancements (continued)

5-38



RL Setup Enhancements RL Setup Enhancements (continued)(continued)

• Pri E-RNTI, Sec E-RNTI• E-AGCH, E-RGCH, E-HICH CC

UE Node B SGSN

RL Setup Request

RNC


RL Setup Response

5-39



After negotiating and setting up resources on the Iub interface, the RNC sends the Radio Bearer Setup

message to the UE. The Radio Bearer Setup message contains:

• E-AGCH, E-RGCH and E-HICH spreading codes and their signature sequences, primary E-RNTI,

secondary E-RNTI and primary or secondary E-RNTI grant selector

• The E-DPCCH power offset, which is the E-DPCCH/DPCCH power offset and

Happy_Bit_Delay_Condition. The happy bit delay condition is the time over the current grants

relative to the TEBS (Total E-DCH buffer status) is evaluated. This is done after the E-TFC

selection procedure.

• The E- TFC selection parameters such as the list of reference E-TFC and its power offset

• Mapping between the logical channel, MAC-d PDU size, MAC-d flow ID and Data Description

Indicator (DDI). For each MAC-d flow, its power offset and maximum number of transmissions

and also the list of options of various E-DCH MAC-d flows that can be multiplexed into one MAC-

e PDU.

• HARQ indication whether it is RV=0 or an RSN-based RV index

• Maximum number of E-DPDCH spreading codes (2 to 64) and puncturing limit

• Initial serving grant and non-scheduled grant

• E-DCH scheduling Information parameters

• The UE acknowledges reception of the Radio Bearer Setup message by sending the Radio Bearer

Setup Complete message. On the Iu interface, using the RANAP protocol, the RNC now sends the

RAB Assignment Response to notify the SGSN that all the resources within the UTRAN have been

granted for the requested QoS.

The SGSN, having made sure that the requirements for the QoS are met, addresses the Activate PDP

Context Accept message to the UE. In this message, the SGSN informs the UE (in addition to all other

mandatory parameters) of the final negotiated set for the QoS.

RAB Setup Enhancements

5-40



RAB Setup Enhancements RAB Setup Enhancements UE Node B SGSNRNC


Radio Bearer Setup

Radio Bearer Setup CompleteRAB Assignment Response

DL DT (Act PDP CTX Accept)DT (Activate PDP CTX Accept)

• DDI mapping, E-RNTI, maximum number of EDPDCH CCs

• HARQ info. E-FC selection parameters

• RAB ID

• The final negotiated QoS

5-41



This diagram captures the complete set of R6 channels. To operate HSDPA and HSUPA, R99 channels are

still required for pilot reference and power control. In addition, there can be a scenario of Multi RAB calls

in which a UE can be on an R99 voice call with HSDPA download and HSUPA upload. This also requires

presence of R99 channels in addition to HSDPA and HSUPA channels. In this example, the UE is in soft

handover with C11, C21 and C10 Node Bs. C10 is the serving Node B for both HSDPA and HSUPA. C11

and C12 are Node Bs consisting of non-serving RLSs for HSUPA operation. If the UE is on an R99 voice

call, it is served by all 3 Node Bs.

R99 channels include:

• DL DPCH: Carries voice, signaling, pilot, power control commands (TPC) and TFCI (Transport

Format Combination Identifier), if the R99 voice call exists. Otherwise, it carries signaling, pilot,

and power control commands if only an HSDPA or an HSUPA call exists.

• UL DPCH- DPDCH+DPCCH: The DPDCH channel carries voice and signaling with its

associated channel DPCCH carrying pilot, TFCI and TPC.

For HSDPA operation:

• The downlink uses the High Speed Common Control Channel (HSCCH). The HSCCH carries the

Channelization Code Set (CCS), Modulation Type (M), Transport Block Size (TBS), HARQ

Process Identifier(HAP), Redundancy Version (RV), New Data Indicator (NDI) and H-RNTI

masked with CRC. This information enables the UE to understand HS-PDSCH assignment

parameters. Using this information, the UE can receive and decode the scheduled data sent on the

HS-PDSCH, transmitted in the next 2 ms TTI. When on an HSDPA call, the UE can be served by

one and only one serving Node B. For example, C10 is the serving Node B that supports HSDPA

functionality. No soft handover in downlink is possible, whereas soft handover in the uplink can

still exist.

• On the uplink, the UE transmits the High Speed Dedicated Physical Control Channel (HS-

DPCCH), which contains the Channel Quality Indicator (CQI) and ACK / NACK.

Complete R6 Channels

5-42



Complete R6 ChannelsComplete R6 Channels

UE

C10High Speed Data and Signaling

E-DPDCH / E-DPCCH


E-AGCH/E-RGCH

Scheduling

E-RGCH

E-DPDCH / E-DPCCH

E-RGCH

E-HICH

E-HICH

E-HICHACK/NACK

E-DPDCH / E-DPCCH

DPDCH/DPCCHDPCH

DPDCH/DPCCH

DPCH

Voice, Data, Signaling / TPC, TFCI, Pilot

DPDCH/DPCCH

Voice, Signaling, TFCI, Pilot, TPC

DPCH

CQI, ACK/NACK

HS-DPCCH

High speed Control/Data

HS-SCCH/ HS-PDSCH

C11

C21

5-43



For HSUPA upload from the UE, C10 is the serving Node B that contains the Enhanced Dedicated

Channel (E-DCH) serving cell and other cells that are part of the serving RLS. C11 and C21 are non-

serving Node Bs, and all the cells in this Node B are part of E-DCH non-serving RLS. All cells in C10,

C11 and C21 are part of the E-DCH active set.

Downlink Channels are:

• E- AGCH: This is transmitted only by the serving cell and provides a scheduled grant to the UE

when the UE sends the scheduling request to the Node B. The scheduled grant is simply suitable

power allocated to the UE so it can transmit data at the desired QoS.

• E-RGCH: This can be sent by both serving and non serving RLS cells. All of these cells measure

the rise over thermal in the uplink and sends suitable power control commands to UE.

• E-HICH: This channel can be carried by both the serving and non-serving RLSs. All serving and

non-serving Node Bs receive the high-speed uplink data form the UE. All E-DCH active set Node

Bs try to decode the packet. If the packet is received successfully, an ACK is sent. Otherwise a

NACK is transmitted.

Uplink channels for HSUPA operation include:

• E-DPDCH: Carries high-speed uplink data and scheduling requests

• E-DPCCH: Carries control information such as the E-TFCI and the retransmission sequence

number (this channel is always associated with the E-DPDCH)

Complete R6 Channels (continued)

5-44



Complete R6 Channels Complete R6 Channels (continued)(continued)

UE

C10High Speed Data and Signaling

E-DPDCH / E-DPCCH


E-AGCH/E-RGCH

Scheduling

E-RGCH

E-DPDCH / E-DPCCH

E-RGCH

E-HICH

E-HICH

E-HICHACK/NACK

E-DPDCH / E-DPCCH

DPDCH/DPCCHDPCH

DPDCH/DPCCH

DPCH

Voice, Data, Signaling / TPC, TFCI, Pilot

DPDCH/DPCCH

Voice, Signaling, TFCI, Pilot, TPC

DPCH

CQI, ACK/NACK

HS-DPCCH

High speed Control/Data

HS-SCCH/ HS-PDSCH

C11

C21

5-45



HSUPA uplink operations on the Enhanced Dedicated Channel (E-DCH) support two types of

transmission: Non-scheduled and Node B controlled scheduled. Let us discuss briefly both of these types.

1. Non-scheduled mode of E-DCH transmission: The Radio Resource Control (RRC) signaling

configures the UE to a maximum data rate. The UE may transmit up to this configured data rate at

any time. This is simple and easy to implement from a UE’s perspective. It is also suitable for

sending signaling messages on the signaling radio bearer as well as transmitting user traffic for

guaranteed bit rate types of services. The non-scheduled transmission type reduces the signaling

overhead and shortens the scheduling delays for time critical, low data rate services. However, it

increases the complexity of implementation at the RNC admission control. Another negative factor

is that it reduces the radio link throughput on the uplink since admission control and load

management functions assume the peak rate transmissions for their computation. The UE may not

have data to send all the time, which results in underutilized reserved radio resources.

2. Node B controlled Scheduled E-DCH transmission: E-DCH active set members schedule grants

(i.e., power allocations to UEs for uplink data transmissions on the E-DCH). The serving E-DCH

cell may allocate absolute grants based on its reverse link interference measurements, which tell

the UE the maximum power offset it can use for uplink E-DPDCH transmission with respect to the

power-controlled DPCCH channel. Non-serving DCH cells may measure their reverse link

interference and influence a UE on the reverse link transmission rates and power. A non-serving

E-DCH RL may cause the UE uplink reverse link transmission rates to go down if the cell’s uplink

RoT is very high. Serving E-DCH RLS members may cause the uplink transmission rates to go

up, go down, or stay the same based on their own RoT measurements. As can be seen, the

scheduled approach is very dynamic, and, hence, can result in better uplink performance for each

cell. However, the cost of this approach is the increased signaling overhead on the air interface and

the complexity and delay introduced due to the centralized scheduling at each cell.

Uplink Transmission

5-46



Uplink Transmission Uplink Transmission Types of Uplink

TransmissionNon-

ScheduledNode B

Controlled

• E-DCH may transmit up to a configurable rate any time

• SRBs & GBR servicesPros:• Minimal signaling overhead

& short scheduling delayCons:• Complexity of

implementation & sub-optimal throughput

• Scheduling grants controlled by Node Bs

• All other servicesPros:• Better performanceCons:• Increased signaling

overhead & scheduling delay

5-47



This slide provides a high level picture of a typical Node B controlled scheduled mode Enhanced

Dedicated Channel (E-DCH) operation. Once a UE has been assigned the E-DCH for uplink data

transmission, the UE follows these steps:

1. The UE looks at its buffer status for each logical channel and sends a scheduling request to the

serving cell. The request information includes the logical channel identity, buffer status and the

available power ratio at the UE.

2. The serving E-DCH cell in the E-DCH active set typically provides a power allocation or grant to

the UE. The allocation can be an absolute grant from the E-DCH serving cell. Members of the

serving E-DCH RLS may send an UP, DOWN or HOLD relative grant command to the UE. Non-

serving E-DCH Active Set members may send a HOLD or DOWN command to help maintain

their reverse link load levels. The type of grants sent from the serving E-DCH cell is

implementation-dependent. The network may send absolute and relative grants either at the

request of the UE or autonomously to react to changing reverse link load conditions.

3. The UE receives the grant information from different active set members. The UE goes through a

deliberate process to identify the reverse link data rate for transmission based on the following:

• The current serving grant

• Data in buffer logical channels in priority order

• The available power ratio for the E-DCH transmission with respect to the power

controlled DPCCH channel

4. The UE transmits the data on E-DCH/E-DPDCH channels and the associated physical layer

control information on the E-DPCCH.

Uplink Data Transmission Overview

5-48



Uplink Data Transmission OverviewUplink Data Transmission Overview

UE UTRAN

2. Absolute and Relative Grants

(E-AGCH and E-RGCH)(Autonomous or in response to Scheduling Request)

4. Data and Control Info

(E-DCH and E-DPCCH)

5. ACK or NACK

(E-HICH)

3. Data Rate Selection at UE

(E-DCH and E-DPCCH)(Scheduling Request: Logical Channel, Buffer Occupancy,

Available Power Ratio)

1. Scheduling Information and Happy Bit

5-49



5. Active set member cells receive and process the information to determine whether the packet can

be decoded correctly. Each processing cell makes a determination whether an ACK or NACK

will be sent on the E-DCH Hybrid ARQ acknowledgement Indicator Channel (E-HICH) in

response to the received data on the E-DPDCH. Please keep in mind that cells in the same Node B

perform digital combining before the decoding process, and send the same ACK/NACK value. If

one of the cells sends an ACK to the UE, the HARQ process at the UE clears the buffer for the

packet and prepares for transmission of the next packet.

This sequence is repeated for every TTI cycle as needed. Please note that steps 1 and 2 may not be

required for each TTI transmission.

Uplink Data Transmission Overview (continued)

5-50



Uplink Data Transmission Overview Uplink Data Transmission Overview (continued)(continued)

UE UTRAN

2. Absolute and Relative Grants

(E-AGCH and E-RGCH)(Autonomous or in response to Scheduling Request)

4. Data and Control Info

(E-DCH and E-DPCCH)

5. ACK or NACK

(E-HICH)

3. Data Rate Selection at UE

(E-DCH and E-DPCCH)(Scheduling Request: Logical Channel, Buffer Occupancy,

Available Power Ratio)

1. Scheduling Information and Happy Bit

5-51



Let’s discuss the scheduling request information transmitted by the UE. What information is sent by UE as

part of scheduling requests?

• Highest Priority Logical Channel ID (HLID - 4 bits): Identifies the highest priority logical

channel that has data available in its buffer.

• Total Enhanced Dedicated Channel (E-DCH) Buffer Status (TEBS - 5 bits): Identifies the total

amount of data available across all logical channels. This field corresponds to the amount of data in

bytes that is available for transmission and re-transmission in the RLC layer.

• Highest Priority Logical channel Buffer Status (HLBS - 4 bits): Indicates the amount of

available data from the highest priority logical channel ID relative to the highest buffer size value

reported by the TEBS field.

• UE Power Headroom (UPH - 5 bits): Indicates the maximum UE transmission power and

corresponding DPCCH code power. The maximum UE power is the lowest maximum UL

transmission power allowed in a cell and maximum power capability of the UE determined by the

power class of the mobile.

– The UE might send a feedback bit called a “Happy Bit” on the E-DPCCH for every E-

DCH transmission. The UE may be unhappy if it is transmitting as much scheduled data as

allowed by the serving grant and it has enough power available to transmit at a higher data

rate, and TEBS requires more than the Happy_Bit_Delay_Condition. The

Happy_Bit_Delay_Condition is a timer in ms transmitted by the SRNC in a Radio Bearer

Setup message.

Transmission of Scheduling Requests

5-52



Transmission of Scheduling RequestsTransmission of Scheduling Requests

UE

Node B

Serving RLSRNC

Scheduling Request infoMAC-e

E-DCH

UPH TEBS HLBS HLID5 bits 5 bits 4 bits 4 bits Scheduling

info

How?• Stand alone tx• Along with data tx • Happy Bit on E-DPCCH

When?• No scheduling grant available: data needs to be sent• Scheduling grant periodically - RB Setup message

Scheduling info part of MAC-e header

5-53



• The UE sends the scheduling request if it has data to send and has no serving grant available. This

allows the active set E-DCH cells to schedule grants for the UE to enable data transmission on the

uplink in a timely manner. Even if a UE has a serving grant available for current transmission, the

UE may periodically send scheduling requests to update the scheduler at the Node B of its

changing status. This allows the schedulers at the Node B to obtain an up-to-date picture of the

current state of the UE and its buffers to help with ongoing scheduling decisions to better utilize the

uplink.

• The UE may send scheduling information on the MAC-e PDU either as a standalone transmission

or piggybacked with the MAC-e PDU data.

• The happy bit is sent by the MAC-e layer at the UE to the physical layer, which further inserts this

bit on the E-DPCCH whenever E-DCH transmission occurs.

Transmission of Scheduling Requests (continued)

5-54



Transmission of Scheduling Requests Transmission of Scheduling Requests (continued)(continued)

UE

Node B

Serving RLS

Scheduling Request infoMAC-e

E-DCH

UPH TEBS HLBS HLID5 bits 5 bits 4 bits 4 bits Scheduling

info

How?• Stand alone tx• Along with data tx • Happy Bit on E-DPCCH

When?• No scheduling grant available: data needs to be sent• Scheduling grant periodically- RB Setup message

Scheduling info part of MAC-e header

RNC

5-55



An example of how and when the UE sends a scheduling request to the Node B is illustrated in this slide.

This is the initial process executed by the UE to request a grant from the Node B.

The UE has been assigned a primary E-RNTI 1 and secondary E-RNTI 2 on the Radio Bearer Setup

message. Please note several UEs can be assigned one primary E-RNTI. The Node B may also treat the

current scheduling Request from a UE differently from other UEs in the serving cell. This may be based on

the current attributes of scheduling request information. Therefore, the Node B may assign a grant with a

secondary E-RNTI value to that UE.

From higher layers, the MAC-e layer at the UE receives the following:

• Logical channel identifier

• Its priority (HLID)

• The Total Enhanced Dedicated Channel (E-DCH) buffer status (TEBS)

• The percentage of highest logical channel buffer occupancy relative to all logical channel buffers

waiting to be transmitted (HLBS)

• Power Headroom (UPH), which is the ratio of maximum power allowed for UE-to-DPCCH code

power

The UPH also provides the UE with enough power on the uplink to send data at a high rate. This process

triggers the transmission of the happy bit on the E-DPCCH. The UE is unhappy if it has enough power

headroom to transmit data at a much higher rate. The UE shows its unhappiness by sending a happy bit = 0

on the E-DPCCH physical channel. The status of the happy bit is indicated by the MAC-e to the physical

layer.

Sending Scheduling Request - Example

5-56



Sending Scheduling Request Sending Scheduling Request -- Example Example UE


MAC-d

Node BDTCH 1 DTCH 2

Priority 1 Priority 2

Logical channel id =1

HLID= 1TEBS=30 bytes

HLBS= 75%UPH= 8db

Logical Channel

ID=2HLID=2

TEBS=30 bytes

HLBS= 25%

Happy Bit = 0 Unhappy

MAC e/ es


E-DCH scheduling

E-DCHcontrol

MAC-e

0001 00101 1110 01000

HLID TEBS HLBS UPH

Scheduling Request info

E-DPDCH

E-DPCCH (Happy Bit = 0)

SG

(Pri E-RNTI 1, Sec E-RNTI 2)

MAC- e PDU

Serving Node B

5-57



In this example, there are 2 Logical channels: 1 and 2. Logical channel ID 1 has priority 1 and logical

channel ID 2 has priority 2. As a result, logical channel ID 1 has higher priority.

Therefore, HLID is set to 1-0001 (4 bits). The total E-DCH buffer status for logical channel ID 1 and 2 is

30 bytes. As a result, TEBS is set to 30 bytes. From 25.321 specs, 30 bytes corresponds to index 5 (00101,

5 bits).

The highest logical channel buffer (i.e., the logical channel ID 1 buffer) has approximately 75% of the total

E-DCH buffer data to be transmitted. From 25.321, 75% corresponds to index 14 (1110, 4 bits). The UE

has 8 db of power headroom (01000, 5 bits) to transmit data at a much higher rate. In this example, it is

assumed that the UE is utilizing the current serving grant relative to the TEBS to its maximum over

happy_bit _delay_ condition. The UE has enough data to send from its highest priority logical channel and

equally enough uplink power headroom to transmit at a higher data rate. This triggers the UE to feel

unhappy and it indicates the status on the E-DPCCH. Therefore, the UE forwards the Scheduling Request

message, which is part of the MAC-e PDU on the E-DPDCH physical channel. The E-DCH control at the

Node B receives the scheduling request information and forwards it to the E-DCH scheduling block at the

MAC-e layer of the Node B. The Node B may now assign a scheduling grant to the UE.

Sending Scheduling Request - Example (continued)

5-58



Sending Scheduling Request Sending Scheduling Request -- Example Example (continued)(continued)

UE


MAC-d

Node BDTCH 1 DTCH 2

Priority 1 Priority 2

Logical channel id =1

HLID= 1TEBS=30 bytes

HLBS= 75%UPH= 8db

Logical Channel

ID=2HLID=2

TEBS=30 bytes

HLBS= 25%

Happy Bit = 0 Unhappy

MAC e/ es


E-DCH scheduling

E-DCHcontrol

MAC-e

0001 00101 1110 01000

HLID TEBS HLBS UPH

Scheduling Request info

E-DPDCH

E-DPCCH (Happy Bit = 0)

SG

(Pri E-RNTI 1, Sec E-RNTI 2)

MAC- e PDU

Serving Node B

5-59



The absolute grant and the relative grant are two types of grants sent by the Node B to the UE. The

absolute grant may be sent only by the serving Enhanced Dedicated Channel (E-DCH) cell to a UE. The

Node B scheduler makes the decision on the absolute grant for a UE based on multiple parameters:

• QoS requirements for the current packet data service

• Measured uplink interference level (RoT)

• The scheduling request that contained information on the logical channel data waiting in the buffer

to be sent by the UE

Absolute grants sent by the serving E-DCH cell contain:

• E-DCH Radio Network Temporary Identifier (E-RNTI): The E-RNTI is a 16-bit identifier

allocated by the SRNC to identify the UE on the E-DCH transmissions. The network may assign

the same E-RNTI value to one or more UEs. Each UE may also be assigned a primary E-RNTI and

a secondary E-RNTI. The E-RNTI assignments are performed using RRC signaling messages.

When grants are sent over the air on the E-AGCH, the grant recipient is identified within the

contents by masking the CRC of the contents with an E-RNTI value. This ensures that the grants

are properly processed by only the intended recipients (i.e., UEs that have been allocated the E-

RNTI).

• Maximum power ratio: A 5-bit value that identifies the maximum E-DPDCH/DPCCH power

ratio that the UE may use for E-DCH transmission.

• HARQ Process Activation flag: This bit is used in different ways. One use is to indicate a switch

between primary and secondary E-RNTI usage. This bit is also used for process activation of the

HARQ processes. In other words, this bit indicates whether the primary absolute grant (i.e., the

absolute grant sent with the primary E-RNTI as the identifier) is activating or deactivating one or

all of the HARQ processes. Please note that each HARQ process is responsible for sending a

packet on the E-DCH.

Transmission of Grants by the Node B

5-60



Transmission of Grants by the Node BTransmission of Grants by the Node B

Uplink RoT

Uplink RoT

QoS from SRNC

Scheduling request from UE

Absolute Grant(E-AGCH)

Relative Grant (E-RGCH)

MAC- e

Physical Layer

Serving Cell

Node B

MAC- e

Physical Layer

Serving and non-serving Cell

Node B

E-RNTI

Max. allowed power ratio

HARQ flag

16 bits

5 bits1 bit

• (UP=+1, HOLD =0, or DOWN=-1) for serving cell

• (HOLD=0 or DOWN=-1) for Non-serving cell

• 1 or more UEs• Same E-RGCH can be assigned to

multiple UEs

5-61



Relative grants may be sent by the Node B scheduler to all the UEs that include this cell in their Enhanced

Dedicated Channel (E-DCH) active set. However, the commands that are sent as relative grants change

from a serving E-DCH RLS to a non-serving E-DCH RLS. The relative grant communicates the following

to the UE:

• The relative grant, like the absolute grant, may be sent to one or more UEs

• Relative grants are used in conjunction with absolute grants and serve as a complement to absolute

grants

• Relative grant commands differ for serving E-DCH active set members and non-serving E-DCH

Active Set members

– Serving E-DCH RLS member cells can send an UP, DOWN or HOLD relative grant

command to a UE

– Non-serving E-DCH cells may send a DOWN (to manage the rising RoT on their uplink) or

a HOLD command (which essentially is DTXed, and, hence, is not really a feedback)

Transmission of Grants by the Node B (continued)

5-62



Transmission of Grants by the Node BTransmission of Grants by the Node B(continued)(continued)

Uplink RoT

Uplink RoT

QoS from SRNC

Scheduling request from UE

Absolute Grant(E-AGCH)

Relative Grant (E-RGCH)

MAC- e

Physical Layer

Serving Cell

Node B

MAC- e

Physical Layer

Serving and non-serving Cell

Node B

E-RNTI

Max. allowed power ratio

HARQ flag

16 bits

5 bits1 bit

• (UP=+1, HOLD =0, or DOWN=-1) for serving cell

• (HOLD=0 or DOWN=-1) for Non-serving cell

• 1 or more UEs• Same E-RGCH can be assigned to

multiple UEs

5-63



This example shows how serving and non-serving Node Bs schedule grants once they receive scheduling

requests from the UE.

The serving Node B uses the scheduling request information and uplink Rise over Thermal (RoT) to

determine the scheduling grant. The scheduling grant is nothing but the traffic-to-pilot ratio or the ratio of

E-DPDCH to E-DPCCH.

The first process involves measurement of total RoT by serving Node Bs and non-serving Node Bs. The

Measured RoT is compared with the predefined UL RoT threshold. Based on this comparison, the serving

Node B may assign an absolute grant or relative grant. The non-serving Node B assigns relative grants

based on the compared results. In this example, both the serving and non-serving Node Bs measure the

total uplink ROT and find that the measured value is below the UL ROT threshold.

In process number 2, the serving Node B determines the scheduling/serving grant and assigns a value of

20 db maximum E-DPDCH-to-E-DPCCH power. This information is sent on the E-AGCH physical

channel. The actual mechanism of how the serving grant is determined by the Node B and how the 20 db

value has been decided is beyond the scope of this example. This example shows only the processes

involved in transmitting grants to the UE.

The E-AGCH has 3 fields: Identity type (primary or secondary E-RNTI identifier, 16 bit string), maximum

power allowed (5 bits) and a grant scope or HARQ flag indicating whether the primary absolute grant (i.e.,

the absolute grant sent with the Primary E-RNTI as the identifier) is activating or deactivating one or all of

the HARQ processes.

In this example, the primary E-RNTI 1 has been signaled and the HARQ flag = 0, which indicates that all

HARQ processes are activated or deactivated by usage of the primary E-RNTI.

In addition to absolute grants, in process number 3 the serving Node B also signals a Power “HOLD”

command to the UE on the E-RGCH channel since the UL RoT measured has not exceeded the threshold.

For the non-serving Node B, the measured total ROT is below the threshold, which triggers the non–

serving Node B to send a power HOLD command to the UE on the E-RGCH channel. Please note that the

power UP command cannot be sent by any cell that is part of the non-serving RLS.

Scheduling and Grants - Example

5-64



Scheduling and Grants Scheduling and Grants -- ExampleExample

UE ServingNode B

Scheduling Grant

E-AGCH

Scheduling

E-RGCH

HOLD

Noise Control

2

HOLD

E-RGCH3

UL E-DCH

3

Measured UL RoT below UL RoT

Threshold

Scheduling Request

Uplink RoT

Pri E-RNTI 1 Power=20db

HARQFlag =0

Measured UL RoT below UL RoT

Threshold

Non-servingNode B

Uplink RoT

1 1

5-65



This slide depicts the data rate selection process at a UE. Prior to data transmission operations on the

Enhanced Dedicated Channel (E-DCH), the SRNC sets up configuration parameters using Radio Resource

Control (RRC) signaling for all logical channels, MAC-d flows and Hybrid ARQ (HARQ) processes

related to the E-DCH. Every TTI (2 ms or 10 ms), the UE executes the E-TFC selection algorithm. The

UE follows these steps to select the E-TFC:

1. The UE determines whether it has to take into account scheduled or non-scheduled grants for

upcoming transmission

2. The UE selects a MAC-d flow and identifies the MAC-d flows that can be multiplexed according

to the multiplexing list provided.

3. The UE identifies the power offset to use based on the HARQ profile of the selected MAC-d flow.

4. Once it calculates the power offset, it determines the maximum MAC-e PDU size or E-TFC that

can be transmitted in the next TTI.

5. The UE also uses a reference E-TFCI and its power offset to compare with the selected E-TFC.

The variation in these values may lead to a quality that cannot be sustained during upcoming

transmission. This huge variation may result in an E-TFC blocked state.

6. Among the E-TFCS selected, UE may use the smallest E-TFC that maximizes the transmission of

data for both the scheduled and non-scheduled grant.

The Node B also includes the number of transmissions that have been required to decode the PDU

correctly on each MAC-es PDU sent to the SRNC. So, the SRNC has an up-to-date power offset, which it

may decide to signal to the UE and the Node Bs in the E-DCH active set. These new power offset

attributes are for one or more MAC-d flows.

The resulting MAC-e PDU is transmitted during the next TTI. Now, the HARQ process for the next TTI

takes these as input values and forms the transport block. Turbo coding and related functions are executed

on the PDU. Data is then spread across the number of E-DPDCH channels required for the chosen data

rate. Data and related control information are then sent over the air using the necessary number of E-

DPDCHs and the associated E-DPCCH.

Data Rate Selection at the UE

5-66



Data Rate Selection at the UEData Rate Selection at the UE

E-TFC Selection Algorithm (New Tx)

HARQ Functionality

Physical Layer

Priority per Logical Channel

E-DCH E-DPCCH

Absolute & RelativeGrants (Max Power

Ratio)

Current Flows for E-DCH

E-TFC & MAC-e PDU for next TTI HARQ profile

E-TFC RSN (Implicit Indication at RV)

Power OffsetMax # of

Retx

(RRC) HARQ Profile for each

MAC-d flow

Power Offset

Reference E-TFC Power Offset

MAC e / es

5-67



The E-DCH Dedicated Physical Data Channel (E-DPDCH) carries the E-EDH transport channel. The E-

DPDCH supports both the 10 ms TTI and 2 ms TTI. If the 2 ms TTI is used, the E-DPDCH uses a 2 ms

subframe for transmission. Depending on the data rates required for uplink E-DCH transmission, the UE

may use one or more E-DPDCHs. The E-DPDCH uses a range of spreading factors to support different

data rates. For example, to support a 1.92 Mbps data rate, the E-DPDCH uses SF = 2. As the data rates go

down, the SF value goes up (i.e., more spreading gain). For example, when the desired data rate on the E-

DPDCH is 60 kbps, SF = 64 is used. The E-DPDCH is power-controlled by the Node B. In addition, soft

handover is supported on the E-DCH. To support soft handover, HSUPA defines the concepts of the

serving E-DCH cell, the serving E-DCH Radio Link Set (RLS) and the non-serving E-DCH RLS.

The serving E-DCH RLS is the set of sectors in the E-DCH active set from the Node B that includes the

serving E-DCH cell. The non-serving E-DCH RLs are the E-DCH active set cells that do not belong to the

E-DCH serving RLS.

E-DPDCH

5-68



EE--DPDCHDPDCH

1 Subframe = 2 ms

0 14. . .1 2

1 Radio frame = 10 ms

2560 chips10 x 2 (k+2) bits

k = 0..5

• E-DPDCH carries the E-DCH in 2 or 10 ms TTIs• There can be 1 or more E-DPDCHs per UE depending on

the data rate• Spreading Factor ranges from 2 (1920 kbps) to 256

(15kbps)

5-69



E-DPCCH contents transmitted in each slot are shown in this diagram. In each slot, 10 bits of information

are sent. These 10 bits of information are related to physical layer transmission characteristics and

feedback on the E-DCH.

1. E-DCH Transport Format Combination Indicator (E-TFCI): This field indicates the transport

format that was used by the UE on the E-DCH to the receiving Node B. the E-TFCI is similar to

the TFCI used in DCH transmission.

2. Retransmission Sequence Number (RSN): This field indicates the retransmission sequence

number of the packet that is being sent over the air. This is related to the Hybrid Automatic Repeat

Request (HARQ) processing of user traffic received on the E-DCH. The receiving HARQ process

understands the contents, and it uses this information to help with the decoding process.

3. Happy Bit: This is a one-bit feedback from the UE to the serving cell of the E-DCH to indicate

whether it is receiving enough transmission power grants to meet its transmission needs. This is

determined by the UE by comparing the buffered data size with the number of TTIs required to

transmit them. If the number of TTIs needed is more than a configured threshold, the UE sends an

“unhappy” bit!

E-DPCCH

5-70



EE--DPCCHDPCCH

1 Subframe = 2 ms10 bits

Transport format infoRetrans-mission

info

Statusinfo

• E-DPCCH carries control information associated with E-DCH• There is only one E-DPCCH for each UE• The Spreading Factor is always 256 (15 kbps)

1 Radio frame = 10 ms

0 141 2 13

5-71



Let us discuss the E-DCH data transmission by the UE to the Node B. The data from the application and

PDCP reaches the RLC Layer. The RLC adds its own header and forwards the RLC PDU to the MAC-d

through the logical channel. The MAC-e already has a mapping table consisting of the logical channel,

MAC-d flow and MAC-d PDU size. The MAC-d PDU size is determined by the E-TFC selection

algorithm at the MAC-e. The mapping of the logical channel, MAC-d flow and MAC-d PDU size is

identified by the Data Descriptor Indicator (DDI, 6bits). The DDI is part of the MAC-e header.

The MAC-d PDUs are then transmitted to the MAC-es layer. Multiple MAC-d PDUs are concatenated

into MAC-es PDUs by the MAC-es layer, and it further multiplexes one or more multiple MAC-es PDUs

into a single MAC-e PDU. This functionality is handled by the Multiplexing and Transmission Sequence

Number (TSN) setting entity at the MAC–es layer. The TSN is a six-bit field that increments for every

MAC-es PDU transmitted on the air interface. The TSN is set for each logical channel and MAC-es PDU.

The TSN is header information inside the MAC-es PDU.

The MAC-es PDU is further forwarded to the MAC-e PDU, which adds the DDI and N as its header. N is

a 6-bit field that corresponds to consecutive PDUs corresponding to the same DDI value. The MAC-e

PDU is forwarded to the HARQ process entity at the MAC-e. The HARQ entity is responsible for storing

and retransmitting the MAC-e payload. It also provides the E-TFC, the Retransmission Sequence Number

(RSN) and the power offset to be used by physical layer. The physical layer derives the RSN, Connection

Frame Number (CFN) and the subframe number, in the case of a 2 ms TTI. All of these parameters are

required by the physical layer to transmit the HARQ processes. The HARQ entity can use the RV derived

from the RSN table or RV = 0 for every transmission, if signaled by the Radio Resource Control (RRC).

Finally, the HARQ data is sent in the next TTI. The MAC-e PDU is now forwarded to the physical layer,

which further adds its own header information. The final data is sent on the E-DPDCH physical channel.

E-DCH Transmission from the UE

5-72



EE--DCH Transmission from the UEDCH Transmission from the UE

Numbering

DTCH 1 DTCH 2

RLC AM/UM

Numbering

MAC-es/e

MAC- D flowsMAC-d flow 1

MAC-d flow 2

Header Data

Data

TSN Data

DDI N Data

Physical layer FunctionsE DPDCH

E-DPCCH /DPCH

RLC PDU

MAC PDU

MAC-es PDU

MAC-e PDU

Data E-DCH

MAC-d

DCCH

HARQ process

Multiplexing/TSN setting

5-73



Let us discuss how the UTRAN receives E-DCH data from the UE.

The physical layer at the Node B receives the E-DCH information on the E-DPDCH. The physical layer at

the Node B removes its header information and forwards the MAC-e PDU through the E-DCH transport

channel. The MAC-e PDUs from layer 1 are forwarded to the HARQ entity at the MAC-e in the Node B.

The HARQ entity handles multiples instances of Stop-and-Wait HARQ protocols. Each HARQ process

tries to decode the packet received from the physical layer. If the reception is successful, then an ACK is

generated by the HARQ entity; otherwise a NACK is sent.

The successfully decoded MAC-e PDUs are forwarded to a demultiplexing function at the MAC-e in the

Node B. This function demultiplexes the MAC-e PDUs into MAC-es PDUs and forwards them to the

associated MAC-d flow. The DDI value sent on the MAC-e header from the UE helps the Node B MAC-e

forward MAC-es PDUs to the corresponding MAC-d flow. The Node B already has the configuration of

the DDI mapping to the MAC-d flow and MAC-d PDU size. The DDI and N are also sent to the MAC-es

at the RNC by the MAC-e on the Iub FP.

The MAC-es already has the mapping of the logical channel to the MAC-d flow and MAC-d PDU size.

Based on the DDI value and N sent by the Node B to the RNC, the MAC-es can determine from the table

which logical channel this MAC-d flow belongs to. The re-ordering queue distribution function is

responsible for routing the MAC-es PDUs to the correct re-ordering buffer. Each logical channel has a re-

ordering buffer. In fact, the DDI, N and Logical channel mapping is handled by the re-ordering queue

distribution function.

Once the MAC-es PDUs reach the re-ordering buffer, the MAC-es reorders its PDUs based on the TSN

transmitted by the UE on the MAC-es header and the Node B-tagged CFN. Once the MAC-es PDUs are

reordered they are delivered to the disassembly function of the MAC-es. This function removes the MAC-

es header and forwards the MAC-d PDUs to the MAC-d layer. The MAC-d further forwards it to the RLC,

which strips its header sends it to the PDCP.

E-DCH Reception at the UTRAN

5-74



EE--DCH Reception at the UTRANDCH Reception at the UTRANNode B RNC

RLC AM/UMDTCH 1 DTCH 2 DCCH


MAC-d

Dis-Assembly

Re-Ordering

MAC- es

MAC-d flows

De-Multiplexing

HARQ Profile per MAC-d flow

MAC-d flow=1

MAC-d flow=2

MAC-e

E-DPDCH E-DPCCH

Data

DDI N Data

TSN Data

Data

Header Data RLC PDU

MAC-d PDU

MAC-es PDU

MAC –e PDU

DDI,N (Iub-FP)

E-DCH

Reordering queue

distribution

Reordering queue

distribution

MAC-d flows

5-75



This block diagram provides a high level flow of what happens to user data processed within the E-DCH

transport channel. When the UE E-TFC selection algorithm picks a new packet for transfer over the air, the

transport block experiences the following steps prior to physical channel handling:

• A 24-bit CRC is calculated and attached to the data to be sent over the air

• A transport block is formed with a maximum block size of 5114 bits for input into the turbo coder

• Channel coding is done using the R = 1/3 rate turbo coder

• Physical layer Hybrid ARQ (HARQ) processing is performed. The rate matching function is

executed, which produces the subset of turbo coder output bits to match the requirements of the E-

DPDCH physical channels. Moreover, the bit selection process has 4 redundancy versions to

choose from. Each option prioritizes different combinations of systematic and parity bits from the

turbo coder output.

• The last step in E-DCH transport channel processing is segmenting the bits for the required number

of E-DPDCH physical channels. Once the data bits are segmented, block interleaving is performed

to add some time diversity to radio link transmission of the data.

• Next, the appropriate spreading codes are used to spread the data, and the UE scrambling code is

applied to scramble the data to make it ready for air interface transmission.

E-DCH Transmission Strategy

5-76



EE--DCH Transmission Strategy DCH Transmission Strategy

(E-TFC)(Turbo, Rate = 1/3)

CRC Attachment

Channel Coding

HARQ Rate

Matching

Physical Channel

Segmentation & Interleaving

E-DPDCH

Node B

Node B

Serving RLS

Non-Serving RLS

E-TFCI7 bits

RSN 2 bits

UE

Channel Coding

Physical channel Mapping

E-DPCCH

E-HICHACK=+1, NACK=-1

E-HICHACK=+1, NACK=0

1 Happy bit

5-77



Let’s look at the contents of the E-DPCCH transmission. The E-DPCCH should transmit the control

information to help the receiving cell identify and retrieve contents of the E-DCH. The following two key

pieces of information are sent within the E-DPCCH:

1. The Retransmission Sequence Number (RSN) is a 2-bit sequence number used to identify the

transmitted data and help avoid or prevent soft buffer corruption at the receiver. The uplink HARQ

transmissions are based on a synchronous model for retransmission. The RSN is a 2-bit value and,

hence, if the receiver loses 3 consecutive retransmission packets, the subsequent data received may

be incompatible with buffered data for the same HARQ process. Therefore, the Node B should

avoid the soft buffer corruption problem by flushing the buffer when 3 consecutive RSN

transmissions are lost.

2. Each transmission identified by the RSN may send different parts of the coded data as dictated by

one of four possible RV values. The UE may be signaled by the Radio Resource Control (RRC) to

use only an RSN value of 0. In this case, the RV prioritizes the systematic bits and retransmits

exactly the same information in each retransmission. The second option is that the RV index to be

used for the next transmission through the HARQ process is determined by the RSN. A mapping

between the RSN and RV index is defined in the standards, and this mapping is used by the UE to

determine the set of bits to transmit. Also, the receiver (Node B) can guess the bit positions of the

received bits by looking at the received RSN on the E-DPCCH.

3. Another key piece of information transmitted on the E-DPCCH is the E-TFCI value. The E-TFCI,

which is a 7-bit index value, specifies the payload size.

Let’s look at the behavior of HARQ processes at the UE. The idea of HARQ (and E-DCH) is to transmit

information packets without errors.. The UE receives the E-HICH channel ACK or NACK from each of

the serving RLSs and non–serving RLSs. The ACK/NACK is sent by the E-HICH physical channel. For

the serving RLS E-HICH, the ACK corresponds to +1 and the NACK corresponds to -1. For the non-

serving RLS, the ACK corresponds to +1 and the NACK corresponds to 0.

E-DCH Transmission Strategy (continued)

5-78



EE--DCH Transmission Strategy DCH Transmission Strategy (continued)(continued)

(E-TFC)(Turbo, Rate = 1/3)

CRC Attachment

Channel Coding

HARQ Rate

Matching

Physical Channel

Segmentation & Interleaving

E-DPDCH

Node B

Node B

Serving RLS

Non-Serving RLS

E-TFCI7 bits

RSN 2 bits

UE

Channel Coding

Physical channel Mapping

E-DPCCH

E-HICHACK=+1, NACK=-1

E-HICHACK=+1, NACK=0

1 Happy bit

5-79



There are 3 types of reconfiguration methods used in UMTS. All three methods have been enhanced at the

Radio Resource Control (RRC) to support HSUPA.

1. Radio Bearer Reconfiguration, which is required when there are the following changes:

• When the Quality of Service (QoS) changes, such as the addition of a new service to the

old service. This is very common in UMTS and reconfiguration happens frequently

throughout the lifecycle of a call. Multi services like circuit-switched calls with HSUPA

can occur simultaneously. Therefore, if a circuit-switched call is already established and an

HSUPA call is added to an existing circuit-switched call, radio bearer reconfiguration is

performed by the RRC. This message adds a new E-DCH transport channel with

corresponding E-DCH MAC-d flows and logical channel priorities.

• Change of RLC content

• Change of TFS/TFCS

• Assignment/release of physical channels

Reconfiguration Types and Functions

5-80



Reconfiguration Types and FunctionsReconfiguration Types and Functions

• Change of QoS• Change of RLC

content • Change of TFS/TFCS• Assignment/release

of physical channels


• Changes in TFS• Use of new

transport channel• May change

physical

• Changes in RRC states

• Changes in DL CC• No transport channel

type switching

Radio BearerReconfiguration Transport Channel

ReconfigurationPhysical ChannelReconfiguration

Reconfiguration

5-81



2. Transport channel reconfiguration

The transport channel is required when the following changes occur:


• Changes in TFS

• Use of a new transport channel

• Change in physical channel bandwidth

3. Physical Channel Configuration

Physical channel reconfiguration can be required when the following changes occur:

• Changes in Radio Resource Control (RRC) states like moving from the cell DCH to the

cell FACH state

• Changes in DL Channelization codes

Physical channel reconfiguration cannot be performed when transport channel switching occurs.

Reconfiguration Types and Functions(continued)

5-82



Reconfiguration Types and FunctionsReconfiguration Types and Functions(continued)(continued)

Radio BearerReconfiguration Transport Channel

ReconfigurationPhysical ChannelReconfiguration

Reconfiguration

• Change of QoS• Change of RLC

content • Change of TFS/TFCS• Assignment/release

of physical channels


• Changes in TFS• Use of new

transport channel• May change

physical

• Changes in RRC states

• Changes in DL CC• No transport channel

type switching

5-83



The following example shows the message sequence flow explaining the setup of the E-DCH

configuration. Also, the TTI reconfiguration is shown in the same scenario.

1. The RNC receives the RAB Assignment Request RANAP message from the SGSN requesting a

specific QoS. The RNC requests the Node B to prepare for reconfiguration and configuration of

the E-DCH.

2. The RNC transmits a request to the E-DCH serving Node B to perform a synchronized radio link

reconfiguration using the NBAP Radio Link Reconfiguration Prepare message for the E-DCH

radio link. It includes information regarding DCHs to Delete IE, the serving E-DCH RL ID, and

the E-DCH FDD.

3. The E-DCH Node B responds with the NBAP Radio Link Reconfiguration Ready message, which

includes the DCH Information Response, E-DCH FDD Information Response and the E-RNTI.

4. The RNC initiates setup of a new Iub Data transport bearer using the ALCAP protocol. The

parameters include the AAL2 Binding Identity to bind the Iub data transport bearer to the E-DCH.

5. The RNC then transmits the NBAP Radio Link Reconfiguration Commit message to the E-DCH

Node B, which includes the activation time. It consists of the RNC selected activation time in the

form of a CFN.

6. The RNC then transmits a Radio Resource Control (RRC) Radio Bearer Reconfiguration message

to the UE, which includes activation time, E-DCH information and the E-RNTI.

7. The UE responds with the RRC Radio Bearer Reconfiguration Complete message to the RNC.

E-DCH Configuration

5-84



EE--DCH Configuration DCH Configuration UE RNC GGSNSGSNNode B




4. ALCAP Iub Data Trans. Setup EDCH



QoS modification1. RAB Assign. Req.

5-85



This slide explains E-DCH TTI reconfiguration.

8. The RNC transmits the NBAP Radio Link Reconfiguration Prepare message to request the E-

DCH Node B to perform a synchronized radio link reconfiguration for the E-DCH radio link.

9. The E-DCH Node B responds to the RNC with the Radio Link Reconfiguration Ready message,

which consists of the E-DCH FDD Information Response.

10. The RNC then transmits the NBAP Radio Link Reconfiguration Commit message to the E-DCH

Node B, which includes the RNC selected activation time in the form of a CFN.

11. The RNC also sends the Radio Bearer Reconfiguration message to the UE, including activation

time, E-DCH information (TTI change) and the E-RNTI.

12. The UE responds with a Radio Resource Control (RRC) Radio Bearer Reconfiguration Complete

message, which is sent to the SRNC.

E-DCH TTI Reconfiguration

5-86



EE--DCH TTI Reconfiguration DCH TTI Reconfiguration UE RNC GGSNSGSNNode B





13. Radio Bearer Reconfig Complete

8. ALCAP Iub Data Trans. Release DCH

5-87



Radio Bearer Release is also enhanced in the Radio Resource Control (RRC) to support HSUPA. The

Radio Bearer Release can simultaneously release a service and reconfigure another service if two services

are accessed by the UE simultaneously.

This example depicts release of a radio access bearer on an Enhanced dedicated channel (E-DCH).

1. The SGSN initiates release of the radio access bearer with the RANAP Radio Access Bearer

Assignment Request message.

2. The RNC initiates release of the Iu Data Transport bearer between the CN and the SRNC using the

ALCAP protocol.

3. The RNC than sends requests to the Node B to prepare release of the E-DCH carrying the radio

access bearer Radio Link Reconfiguration Prepare message, which consists of E-DCH

information, the E-DCH serving cell ID, and the E-DCH MAC-d flows to delete.

4. The Node B responds to the RNC that release preparation is ready by transmitting the Radio Link

Reconfiguration Ready message.

5. The RNC then sends the NBAP Radio Link Reconfiguration Commit message to the Node B.

6. The RRC Radio Bearer Release message is sent by the RNC to the UE, which includes E-DCH

information, the E-DCH serving cell ID, and the E-DCH MAC-d flows to delete.

Radio Bearer Release

5-88



Radio Bearer ReleaseRadio Bearer ReleaseUE RNC GGSNSGSNNode B

3.RL Reconfig. Prep.

6.Radio Bearer Release


4.RL Reconfig. Ready

Apply new transport format set

1.RAB Assign. Req.

2. ALCAP Iu Data Trans. Bearer Release

5-89



7. The UE sends the Radio Resource Control (RRC) Radio Bearer Release Complete message to the

RNC.

8. The RNC initiates release of the Iub (Serving RNS) Data Transport bearer using the ALCAP

protocol. Unused resources in the RNC and Node B are thereby released.

9. The RNC sends an acknowledgement of the released radio access bearer by transmitting the Radio

Access Bearer Assignment Release message.


5-90



Radio Bearer ReleaseRadio Bearer ReleaseUE RNC GGSNSGSNNode B

8. ALCAP Iub Data Trans Bearer Release

9. RAB Assignment (Rel.)


5-91



This example illustrates a soft handover where the traditional R99 active set and E-DCH-reduced active set

are contrasted. The R99 active set contains the Node Bs that have R99 channels in uplink and downlink

soft handover. As is the case with R99, during a soft handover the Node B in the active set transmits data

to the UE and receives data from the UE. The UE and the Node B carry out maximal ratio combining

while the RNC performs selection combining in the uplink.

In the beginning, the UE is communicating with Node B1. The Active Set at this time contains Node B1

only. The UE continues to monitor pilot strengths from the neighbor Node Bs (Node B2, B3 and B4 in the

diagram). As the UE moves away from Node B1 and toward a neighbor Node B, Node B2, it finds Node

B2 and Node B3 capable of providing a good quality signal. Hence, the RNC makes Node B1, Node B2,

and Node B3 part of the R99 active set. The RNC then creates a subset of the active set and forms the E-

DCH active set of Node B1 and Node B2. Now, the R99 channels between the UE and the UTRAN (with

Node B1, Node B2, and Node B3) experience soft handover, while the E-DCH is in soft handover with

only Node B1 and Node B2.

Soft Handover

5-92



Node B4

Soft HandoverSoft Handover

Node B 3

Node B 1

Node B2

Initial Communication

1

SimultaneousCommunicationwith Multiple Node Bs

2

3

R99 Active Set: {Node B1, 2, 3}E-DCH Active Set: {Node B1, 2}

5-93



The creation of the E-DCH active set by the RNC is not standardized and thus implementation-specific.

The network infrastructure vendor can implement any suitable algorithm to provide product

differentiation. The RNC can choose the cells that provide the best uplink throughput so that the user-

perceived throughput is high. The RNC can also look at the available radio resources and the Quality of

Service (QoS). For example, if a substantial number of resources are available, higher E-DCH data rates

can be supported. One of the E-DCH active set members is chosen to be the E-DCH serving cell, and the

RNC can choose the cell with the best downlink quality (e.g., with the largest pilot (Ec/N0) among the E-

DCH active set members). The overall E-DCH handover process still relies on Radio Resource Control

(RRC) signaling as is the case with R99. The RNC allocates resources such as E-RNTI, HARQ processes,

serving grant (i.e., the allowed uplink resource for high-speed data transfer), and the radio channels

associated with the E-DCH. Recall that the E-RNTI is the temporary identity of the UE that has an E-DCH

operation set up with the RNC. Transmission of one new packet is the responsibility of one HARQ

process. The RNC can configure a suitable number of processes to enable the UE to continuously send

data in the uplink.

E-DCH Handover Algorithm at the RNC

5-94



EE--DCH Handover Algorithm at the RNCDCH Handover Algorithm at the RNC

RNCHandover

Algorithm forE-DCH Active Set

Implementation-specific

Algorithm

RRC-signaling based UTRAN-

based handover

Possible criteria for E-DCH Serving Cell and Serving RLS: (i) RLS with

highest UL throughput potential & (ii) Serving Cell: Best Downlink Quality

Resource Allocation (E-RNTI, HARQ Processes, Serving Grant, Radio

Channels)

5-95



There are several ways to convey the handover decision of the RNC to the UE. The E-DCH handover

process again reuses the existing mechanisms to indicate the change in the active set for both R99 and R6

to the UE. Examples of the messages that the RNC may send to the UE include the Radio Bearer

Reconfiguration and Active Set Update. It is possible to send a single message that indicates both an

HSDPA cell change and an E-DCH Active Set change. The E-DCH-specific information carried in the

messages includes the following:

• UE Identities: Primary and secondary E-RNTI

• Allocated Radio Channels in all E-DCH Active Set Cells: Examples of the contents include the

serving grant, primary vs. secondary grant selector, E-DPCCH/EDPCCH power offset, E-DPDCH

reference E-TFCI set, HARQ process allocation, E-AGCH channelization code, E-HICH DL

scrambling code, E-HICH channelization code, E-HICH signature sequence, E-RGCH signature

sequence, F-DPCH time offset, F-DPCH code number, and the F-DPCH TPC command error rate

target.

• Indicator of the Serving (or scheduling) E-DCH Radio Link: This informs the UE what the

serving cell is via P-CPICH information.

Conveying the Handover Decision

5-96



Conveying the Handover DecisionConveying the Handover Decision

UE RNC

E-RNTI (Primary,

Secondary)

E-DPCH, E-DPDCH, E-AGCH, E-RGCH,

E-HICH, and F-DPCCH info

SchedulingE-DCH Cell Indicator

Physical Channel Reconfiguration(Intra-Node B Hard Handover: HSDPA, Soft Handover: HSUPA)

Transport Channel Reconfiguration(Inter-Node B Hard Handover: HSDPA, Soft handover: HSUPA)

Active Set Update(R99 + R6)

5-97



If any of the primary CPICHs within the reporting range becomes better than the previously best primary

CPICH, the UE sends a measurement report if the event 1D is ordered by the UTRAN.

The hysteresis parameter may be connected with each reporting event. The value of the hysteresis is given

to the UE in the reporting criteria field of the Measurement Control message.

In the example, the hysteresis ensures that the event 1D (primary CPICH 2 becomes the best cell) is not

reported until the difference is equal to the hysteresis value. The fact that primary CPICH 1 becomes best

afterward is not reported at all in the example since the primary CPICH 1 does not become sufficiently

better than primary CPICH 2.

Event 1J is a new criteria defined exclusively for HSUPA operations.

Best Cell Change

5-98



Best Cell ChangeBest Cell ChangeThe UE sends a measurement report only when the difference of signal strengths is greater than a threshold (Hysteresis) for a predefined duration (Time to Trigger)

– event 1D: Change of Best Cell

CPICH 1

CPICH 2Hysteresis

Hysteresis

Reporting event 1D

Time

Measurementquantity

ΔTTime to Trigger

5-99



The UE sends a measurement report triggered by event 1J when a cell that is exclusively in the DCH

active set becomes stronger than the weakest cell in the E-DCH Active Set. Simply put, this event

indicates transition of a cell from the R99 active set to the R99+R6 active set.

Event 1J is mainly used for managing the E-DCH active set when there is a difference in the members of

the two sets. In real operational scenarios we expect the DCH active set and E-DCH active set to be one

and the same. However, to further simplify HSUPA operations, it may be advantageous to have the

smallest possible active set size for the E-DCH to reduce processing power and hardware resource usage at

the UE and the Node B. As a result, there may be scenarios in which the E-DCH active set size is different

(less than) from the DCH active set size. In our example, CPICH P3 belongs only to the DCH active set,

so the DCH active set size is one greater than the E-DCH active set size. In such a case, event 1J can help

the network (RNC) decide when to replace P1 in the E-DCH active set with P3 from the DCH active set.

This mechanism guarantees that the best radio links in the DCH active set are also included in the E-DCH

active set when there is a difference between the two.

It may seem paradoxical that a downlink measurement procedure is used as the basis for making decisions

about which cells should be used for uplink radio links! Unfortunately, there are no mechanisms available

today for making uplink quality estimates on a per-radio-link basis in an effective and useful manner. The

uplink measurements at the Node B are a per Radio Link Set (RLS) and not per Radio Link (RL), which is

necessary to evaluate the quality of the uplink. In conclusion, the usefulness of this measurement is based

on the assumption of a symmetric radio-link quality in both uplink and downlink, which is valid in most

situations.

Event 1J for HSUPA

5-100



Event 1J for HSUPAEvent 1J for HSUPA

P1

P2

Event 1J Time

Pilot Strength

P3

DCH Active set = {P1, P2, P3} E-DCH Active Set = {P1, P2}

E-DCH Active Set = {P3, P2}Triggered by event 1J

5-101



This slide depicts the Intra Node B synchronized E-DCH cell handover message sequence. As shown in

the diagram, the UE contains the active set, which includes sectors 1, 2, and 3. The E-DCH serving RLS is

1 and 2 and the HSUPA-serving cell is sector 1. The word synchronized means that the activation time is

sent to the UE, which informs the UE about the time at which it should switch over to the target cell /

sector.

1. The need for a serving E-DCH cell change is decided by the SRNC. It thereby requests the serving

E-DCH S-NB to perform a synchronized radio link reconfiguration using the NBAP Synchronized

Radio Link Reconfiguration Prepare message. This message includes the E-DCH RL ID.

2. The serving E-DCH S-NB transmits an NBAP Radio Link Reconfiguration Ready message to the

SRNC. The parameters included in this message are the AGCH channelization code (and

scrambling code) and E-RNTI.

3. The SRNC now responds to the S-NB by transmitting the NBAP Radio Link Reconfiguration

Commit message, which includes the SRNC-selected activation time in the form of a CFN.

4. The Radio Bearer Reconfiguration message is then transmitted from the SRNC to the UE with

information parameters such as activation time, E-DCH information and the E-RNTI.

5. At the specified activation time, the UE now stops reception of E-DCH absolute grants from the

source E-DCH cell and starts reception of E-DCH absolute grants from the target E-DCH cell. It

thereby sends a Radio Bearer Reconfiguration Complete message to the SRNC in return.

Intra-Node B – Sync E-DCH Cell Change

5-102



IntraIntra--Node B Node B –– Sync ESync E--DCH Cell ChangeDCH Cell Change

S - NB1

SRNC

23Active Set Sectors 1, 2, 3

EDCH-Serving RLS is 1, 2HSUPA Serving Cell is 1

1. RL Reconfig. Prepare

2. RL Reconfig. Ready3. RL Reconfig. Commit

4. Radio Bearer Reconfiguration• Activation time, Serving E- DCH RL IND, EDCH Control Channel info• E-RNTI

5. Radio Bearer Reconfiguration Complete

Measurement Report

E-DCH best cell change to sector 2

5-103



This slide illustrates a synchronized inter Node B serving E-DCH cell change. As shown in the diagram,

the UE contains the active set, which includes sectors 1, 2, and 3. The E-DCH-serving RLS is 1 and 2 and

the E-DCH serving cell is sector 1, S-NB. The best cell change happens to T-NB, sector 1.

1. In this example, the source and target E-DCH cells are controlled by different Node Bs (i.e., S-NB

and T-NB). The SRNC decides there is a need for a serving E-DCH cell change. As a result, it

requests the source E-DCH S-NB to perform a synchronized radio link reconfiguration using the

NBAP Radio Link Reconfiguration Prepare message, which removes its E-DCH resources for the

source E-DCH radio link. This message includes information parameters such as E-DCH MAC-d

flows to delete.

2. The source E-DCH S-NB responds by sending an NBAP Radio Link Reconfiguration Ready

message to the SRNC, which includes no E-DCH related parameters.

3. The SRNC sends a Radio Link Reconfiguration Prepare Requests message to the target E-DCH T-

NB to perform a synchronized radio link reconfiguration.

Using the NBAP message, which adds E-DCH resources for the T-NB radio link, this message

includes E-DCH FDD information, a DRNC-selected E-RNTI and the E-DCH RL ID.

4. The target E-DCH T-NB responds with the NBAP Radio Link Reconfiguration Ready message in

return to the SRNC, which contains the E-DCH FDD information response.

5. Initiated by the SRNC, the new Iub Data transport bearers are set up using the ALCAP protocol.

This request includes the AAL2 binding identity to bind the Iub data transport bearer to the E-

DCH.

6. The SRNC transmits the NBAP Radio Link Reconfiguration Commit message to the source E-

DCH S-NB, which includes the activation time. At the activation time, the source E-DCH S-NB

stops and the target E-DCH T-NB starts transmitting on the E-DCH to the UE. This message

includes the SRNC-selected activation time in form of a CFN.

Inter-Node B – Sync Serving E-DCH Cell Change

5-104



InterInter--Node B Node B –– Sync Serving ESync Serving E--DCH Cell DCH Cell ChangeChange

S - NB1

SRNC

23Active Set Sectors 1, 2, 3E-DCH Serving RLS 1, 2HSUPA Serving Cell is (1, S-NB)

1. RL Reconfig. Prepare

T - NB1





Active set sectors 1, 2, 3E-DCH non-serving RLS 1, 2

23

5. ALCAP Iub Data Trans. Bearer Setup

5-105



7. The SRNC transmits the NBAP Radio Link Reconfiguration Commit message to the target E-

DCH T-NB, which consists of the activation time. At the indicated activation time, the source E-

DCH S-NB stops, and the target E-DCH Node B starts transmitting on the E-DCH to the UE. It

includes the SRNC selected activation time in the form of a CFN.

8. The SRNC then transmits the Radio Resource Control (RRC) Radio Bearer Reconfiguration

message to the UE. This includes information parameters such as activation time, E-DCH

information and the E-RNTI.

9. At the indicated activation time, the UE stops receiving the E-DCH in the source E-DCH cell and

starts E-DCH reception in the target E-DCH cell. The UE thus responds and returns a RRC Radio

Bearer Reconfiguration Complete message to the SRNC.

10. If the new Iub data transport bearer was set up in step 5, the SRNC initiates release of the old Iub

data transport bearer using the ALCAP protocol.

Inter-Node B – Sync Serving E-DCH Cell Change

5-106



InterInter--Node B Node B –– Sync Serving ESync Serving E--DCH DCH Cell ChangeCell ChangeS - NB

1

SRNC

.

23Active Set Sectors 1, 2, 3E-DCH Serving RLS 1, 2HSUPA Serving Cell is (1, S-NB)


T - NB1

9. Radio Bearer Reconfiguration Comp.

Active Set Sectors 1, 2, 3E-DCH Non-Serving RLS 1, 2

23


10. ALCAP Iub Data Trans. Bearer Release

5-107



The data that the Node B receives on the uplink E-DCH must be transported to the RNC for possible

selection combining with other data blocks (when macro-diversity is used) and subsequently transmitted to

the packet core network. The transport of user data between the Node B and the RNC is done over the Iub

interface on the user plane of the Iub protocol stack. The user plane utilizes the Frame Protocol (FP), and

the diagram in this chart outlines the structure of the E-DCH Data FP.

Each MAC-es PDU that is received by the Node B is disassembled into MAC-d flows and sent on separate

transport bearers to the RNC. The FP normally sends data frames on the uplink and downlink every TTI,

i.e. transmission time interval (10, 20, 40 or 80 ms). HSUPA efficiency may be increased in the case of a

2ms TTI by bundling subframes into one E-DCH frame and sending the E-DCH frames every 10 ms, for

example.

Here we see the generic format for the E-DCH data frame. Each frame is divided into a Header and

Payload part. The Header carries the frame type (control or data), a cyclic redundancy check (CRC) for the

header portion, a frame sequence number (FSN) which counts the frame itself as well as a Connection

Frame Number (CFN) that indicates when this MAC-e PDU was decoded at the physical layer. The

remainder of the header carries MAC-es specific info like the Data Description Indicator (DDI), which is a

mapping to MAC-d flow ID and size, the number of MAC-es PDUs, the number of HARQ

retransmissions and the number of MAC-d PDUs (all for each subframe). All this information is necessary

for the correct demultiplexing of the frames at the RNC and their subsequent delivery to the higher layers.

For a 2 ms TTI, a maximum of 5 subframes can exist and the subframe number ranges from 0 to 4.

The payload is a concatenation of MAC-es PDUs for each subframe. Thus, the first MAC-es PDU of the

first subframe is followed by the second MAC-es PDU of the first subframe, etc. until the last MAC-es

PDU of the last subframe. There is also the possibility of attaching an optional 16-bit Payload CRC field

that applies to the entire payload.

E-DCH Data Frame

5-108



EE--DCH Data FrameDCH Data Frame

DDI1 … DDI n

FT: Frame Type

Payload CRC

1st Subframe info

Subframe 1 Payload

Frame Sequence Number

Connection Frame Number

Header CRC FT

Last Subframe info

Hea

der

Payl

oad

Number of MAC-es PDUs

Number of HARQ Retransmissions

Number of MAC-d PDUs

Last Subframe Payload

MAC-es PDUs 1st to last Subframe

Optional

5-109



During HSUPA operations, the UE is often in soft handover with more than on cell, thus using the same

benefits of macro-diversity that exist in R99. Since the responsibility of retransmitting erroneous transport

blocks is now at the Node B and not the RNC, The UE must decode the individual acknowledgments on a

downlink feedback channel (E-HICH) from each and every cell that it is communicating with. A single

positive acknowledgment (ACK) from any one of the cells in its E-DCH active set is enough for the UE to

proceed with subsequent Hybrid ARQ transmissions. The Serving E-DCH cell is the one with the overall

responsibility with regards to scheduling and grant of uplink radio resources to the UE. This cell is usually

the cell with the best radio conditions (and is the serving HSDPA cell as well in the likely case when

HSDPA is used simultaneously).

When the Serving E-DCH cell fails to receive an uplink E-DCH payload (MAC-e PDU), unlike the other

cells in the active set, it must report that failure to the RNC. It will do so if the decoding fails after the

maximum number of retransmissions have been reached and the Retransmission Sequence Number (RSN)

indicates that the UE has started with a new payload (RSN=0). In that case, at least one of the other cells in

the active set must have succeeded in decoding the previously sent data. At this point, the serving cell

sends a HARQ failure indication to the RNC. This is done by setting the ‘Number of MAC-es PDUs’ field

to zero and sending the true number of retransmissions that occurred for the failed payload. The HARQ

failure indication helps the RNC in doing the selection-combining better, and is also an indirect measure of

how well the serving E-DCH cell is performing compared to the other cells in the uplink.

HARQ Failure Indication

5-110



HARQ Failure IndicationHARQ Failure Indication

RNC

ACK

NACK

RSN=0RSN=0

RSN=0NACK

RSN=0

Data Frame

HARQ Failure Ind.

No data transmission

or failure indication

Serving E-DCH Cell

5-111



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Summary

5-112



SummarySummary• RRC establishment procedures have been enhanced to

indicate the E-DCH capability of the UE • Radio Link (NBAP), Radio Bearer Setup (RRC) and Radio

Bearer Reconfiguration procedures have been enhanced to assign HSUPA logical, transport and physical channel parameters to the UE

• SRNC configures the Node B and UE with QoS Parameters for E-TFC selection at the UE and scheduling of grants at the Node B

• The UE transmits scheduling info and / or Happy Bit for request for grants from the Node B

• Based on assigned grants, logical channel priority, buffer status and HARQ profile, the UE selects the best possible transport block to be transmitted

• Whenever an E-DCH best cell change occurs, intra-Node B and inter-Node B handovers are possible

5-113



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Review Questions

5-114



Review QuestionsReview Questions1. Which message carries the E-DCH physical layer

capability?2. What is the significance of assigning primary and

secondary E-RNTIs and when are they used? What messages signal these values to the UE?

3. What is the E-DCH MAC-d flow?4. What is the DDI? What are the parameters that are

mapped to the DDI at the Node B and UE? How are they signaled to the Node B and UE?

5. What parameters trigger the UE to request scheduled grants and how are they sent?

6. What is the difference between synchronous and un-synchronous cell change procedures?

5-115


Multi-Services Scenario

MultiMulti--Services Services ScenarioScenario

6-1



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Objectives

6-2




• Describe the Multi-RAB / Multi-Services scenario of AMR/HSDPA/HSUPA

• Step through the call flow for– AMR/HSDPA– AMR/HSUPA

• Draw the end-to-end call of Multi-Services that includes AMR voice, HSDPA and HSUPA data calls

6-3



It is assumed that the UE is already registered with the Core Network (CN). When a user starts to browse a

website, an HSDPA call is set up. This slide illustrates RRC connection establishment for the start of the

HSDPA session.

• The UE initiates an RRC connection by sending an RRC Connection Request on the CCCH to the

RNC. This message contains the UE identity and the establishment cause is a high priority

signaling call.

• The RNC allocates a U-RNTI and an H-RNTI that uniquely identify the UE in the system. These

identities are sent in the RRC Connection Setup message (on the DL- CCCH).

• The UE acknowledges the RNC by transmitting a RRC Connection Setup Complete message.

RRC Connection Establishment for HSDPA

6-4



RRC Connection Establishment for RRC Connection Establishment for HSDPAHSDPA

UE

RNC PS-CN




Establishing a Web browsing session

6-5



• The required service request is sent by the UE to the RNC in an Initial DT (Service Request)

message that mentions the type of service. In our example, the type of service is signaling.

• The RNC forwards the service request to the SGSN by transmitting the Connection Request

message, and piggybacks the Initial UE Message to the SGSN, which carries the previously

mentioned Service Request CR [IUM (service request)]. It also sends the Iu-signaling link identity.

• The SGSN may invoke the security procedures for authentication, ciphering and integrity check at

this point.

• Either at the end of or absence of security procedures, the upper layer in the UE sends a request to

the CN to set up the data session. The UE requests the desired QoS by sending a direct transfer

RRC UL DT (Activate PDP CTX Req.) message to the RNC. It contains parameters such as APN,

PDP address attributes, and all the necessary QoS characteristics.

• The RNC forwards the request by sending the DT (Activate PDP Context) (a NAS message) using

the initial UE RANAP message to the SGSN on the GTP-C link.

• The SGSN transmits the Create PDP Context Request to the GGSN in a “handshake” procedure to

negotiate the requested QoS and create a GTP-U tunnel. The tunnel is identified by the Tunnel End

Point IDs (TEID).

Setting Up an HSDPA Call

6-6



Setting Up an HSDPA Call Setting Up an HSDPA Call UE

RNC SGSN

Initial DT (Service Request) CR [IUM (Service Request)]

Security Procedures

GGSN

UL DT (Activate PDP CTX Req.) DT

(Act. PDP CTX Req.) Create PDPCTX Req.

Create PDPCTX Res.

6-7



• After negotiation of QoS in the Core Network (CN) (i.e., between the SGSN and GGSN) the

SGSN sends the RANAP RAB Assignment Request message over the Iu Interface to the RNC.

This message indicates in specific terms the QoS with several attributes such as throughput, delays,

error rate, RAB ID, etc.

• The RNC sends an NBAP RL Setup Request message to the Node B to set up a radio link to carry

the traffic for the UE with the desired QoS. It includes Mac-d flows needed, the HS-DSCH

physical layer category and CQI parameters.

• An appropriate radio link is set up by the Node B, which responds to the RNC with the NBAP RL

Setup Response message. This message includes HS-SCCH control information.

• To assign the required radio channels to support high speed data, the RNC sends the RRC Radio

Bearer Setup message to the UE. It includes Mac-d flows to add HS-DSCH information, H-RNTI

and U-RNTI.

• The UE thus acquires a new radio link and sends the RB Setup Complete message in return to the

RNC.

• The RNC further notifies the CN by sending the RANAP RAB Assignment Response message

indicating that radio resources are set up for the UE. The radio bearer for negotiated QoS has been

set up now.

• The PDP context establishment is finally completed by the GGSN and SGSN by sending the DT

PDP Context Accept message to the RNC.

• The RNC forwards the DL DT PDP Context Accept message to the UE. The UE now has an IP

address associated with the APN and itself.

The Web browsing session is now activated.

Radio Bearer for HSDPA

6-8



Radio Bearer for HSDPARadio Bearer for HSDPAUE

RNC SGSNNode B1 RAB

Assignment Req.

Radio Bearer Setup

RB Setup Complete RAB AssignmentRes.

DT PDP CNXT Acc.DL DT PDP CNTXT Accept

Web Browsing Session Active

RL Setup Request

RL Setup Resp.

6-9



In this scenario of high-speed data service, the following channels exist over the air:

• High-speed user data is carried in the downlink on the HS-DSCH along with the HS-SCCH

control information.

• User data at R99 rates are carried in the uplink on the DPDCH along with signaling.

• To support high-speed user data in the downlink, the uplink also contains the HS-DPCCH for CQI

and ACK/NACK signaling.

• The downlink contains the DPCCH to cater to the TFC and power control information. Power

control is done only for data transmission on the uplink by the DL DPCCH. HS-DPCCH power

now depends on the power offset with respect to the UL DPCCH.

Channels Used for an HSDPA Call

6-10



Channels Used for an HSDPA CallChannels Used for an HSDPA Call

DPCCH (TFCI, Pilot and Power Control)

HS-SCCH/HS-DSCH (Control/Data and Signaling)

HS-DPCCH (CQI and ACK/NACK)

DPDCH ( Data and Signaling)

6-11



In our scenario described earlier, a user makes a call to a friend to describe her trip to Europe. The

example illustrates signaling messages to establish an AMR call.

1. To set up a call, the UE sends the Initial Direct Transfer (Service Request) message to the RNC.

2. The RNC chooses the required CN and forwards the CR [IUM (service request)] (NAS message)

using the initial UE RANAP message to the MSC.

3. The CN may start with Security procedures that consist of the RANAP Security Mode Command

message to the RNC to start ciphering of a radio link for the UE.

4. The UE sends a NAS UL DT Setup message that includes the dialed digits of the desired

destination for the CN using a Direct Transfer RRC message.

5. The RNC then transparently forwards the NAS DT Setup message to the CN using the RANAP

Direct Transfer message.

6. The CN then sends the DT Call Proceeding message to the RNC.

7. The RNC passes the DL DT Call Proceeding message to the UE.

8. To set up the Radio Access Bearer (RAB) to carry the desired QoS for AMR voice, the CN sends

a RAB Assignment Request message to the RNC.

9. To assign the radio channels, the RNC sends the RRC Radio Bearer Setup message to the UE,

which consists of RAB information and UL and DL channelization codes.

10. The UE acquires a new radio link, and sends the Radio Bearer Setup Complete message back to

the RNC.

11. The RNC sends the Radio Bearer Reconfiguration message to the UE since some of the RLC

relevant parameters needed to be modified and reconfigured at the UE.

12. After required modification in the RLC parameters, the UE sends the Radio Bearer

Reconfiguration Complete message to the RNC.

Establishment of an AMR Call

6-12



Establishment of an AMR CallEstablishment of an AMR CallUE

RNC MSC

Initial DT (Service Request)CR [IUM (Service Request)]

Security ProceduresUL DT Setup DT Setup

DT Call ProceedingDL DT Call ProceedingRAB Assignment RequestRadio Bearer Setup


RAB Assignment ResponseDT AlertingDL DT Alerting

UL DT Connect DT ConnectDT Connect AcknowledgeDL DT Connect Acknowledge

Radio Bearer ReconfigurationRadio Bearer Reconfiguration Comp.

Initiating a voice (AMR) call

6-13



The functions of the Radio Bearer Setup message and Radio Bearer Reconfiguration message can be

combined into a single Radio Bearer Reconfiguration message in specific implementations.

1. The RNC sends a RANAP RAB Assignment Response message to the MSC indicating that radio

resources are set up for the UE.

2. The MSC sends the DT Alerting message to the RNC indicating that the called party is being

alerted by a ring tone.

3. The RNC forwards this information to the UE by sending a UL DT Alerting message.

4. When the called party answers, the MSC completes the connection by sending a DT Connect

message to the RNC.

5. The RNC transmits this indication by sending a UL DT Connect message to the UE.

6. The UE in response sends the DL DT Connect Acknowledge message to the MSC.

7. The RNC transmits a DT Connect Acknowledgement message to the MSC.

The user is now talking to her friend using the established AMR call.

Establishment of an AMR Call (continued)

6-14



Establishment of an AMR CallEstablishment of an AMR Call (continued)(continued)UE

RNC MSC

Initial DT (Service Request)CR [IUM (Service Request)]

Security ProceduresUL DT Setup DT Setup

DT Call ProceedingDL DT Call ProceedingRAB Assignment RequestRadio Bearer Setup


RAB Assignment ResponseDT AlertingDL DT Alerting

UL DT Connect DT ConnectDT Connect AcknowledgeDL DT Connect Acknowledge


Initiating a voice (AMR) call

6-15



In this scenario of simultaneous high-speed data and voice, the following channels exist over the air.

• High-speed user data is carried in the downlink on the HS-DSCH along with the HS-SCCH for

control information.

• User data at R99 speed is carried in the uplink on the DPDCH, which may also carry user voice

and signaling.

• To support high-speed user data in the downlink, the uplink also contains the HS-DPCCH for

CQI/ACK signaling.

• Additionally, user voice and associated signaling are carried on the DPDCH in the uplink and

downlink.

• Both uplink and downlink have to contain the DPCCH to cater to TFC and power control

information. Power control is done only for voice on the downlink by the UL DPCCH, but for both

voice and data on the uplink by the DL DPCCH.

Channels Used for an HSDPA/Voice Call

6-16



Channels Used for an HSDPA/Voice CallChannels Used for an HSDPA/Voice Call

Multi-RAB Configuration


HS-SCCH/HS-DSCH (Control/Data and Signaling)

DPDCH (Voice and Signaling)



DPDCH (Voice, Data and Signaling)

6-17



Suzanne decides to upload the photographs of her tour in Europe for her friend to view. She composes an

email message with the photographs and sends it to her friend’s email address.

The UE triggers a Direct Transfer Service Request message with the appropriate PDP context status for

the email service. This example illustrates the use of the same APN for both HSDPA and HSUPA, and

uses the same QoS. This Direct Transfer message is forwarded by the RNC to the SGSN on the Iu-PS

signaling link. This may result in invoking security procedures for HSUPA service.

Addition of an HSUPA-to- HSDPA/AMR Call

6-18



Addition of an HSUPAAddition of an HSUPA--toto-- HSDPA/AMR HSDPA/AMR Call Call

UE

RNC

Initial DT(Service Request)

CR [IUM (Service Request)]

Security Procedures

AMR call and web browsing

is ongoing

Starts uploading data

SGSN GGSN

6-19



1. After negotiation in the Core Network (CN) (i.e., between the SGSN and GGSN), the SGSN

sends the RANAP RAB Assignment Request message over the Iu Interface to the RNC. This

message indicates in specific terms the QoS by data rate, delay, acceptable error rate, etc.

2. The RNC sends an NBAP RL Setup Request message to the Node B to set up a radio link to carry

the traffic for the UE with the desired E-DCH MAC-d flow ID(s).

3. An appropriate radio link is thereby setup by the Node B that responds to the RNC with the

NBAP RL Setup Response message. To assign the required radio channels to support high-speed

data, the RNC sends the RRC Radio Bearer Setup message to the UE. It contain all UL and DL E-

DCH channelization codes and signature sequences.

4. The UE thus acquires a new radio link and sends the RB setup Complete message in return to the

RNC. The RNC further notifies the CN by sending the RANAP RAB Assignment Response

message indicating that radio resources are set up for the UE. The CN and the UE may now

exchange traffic.

Adding an HSUPA to an Existing HSDPA/AMR Call

6-20



Adding an HSUPA to an Existing Adding an HSUPA to an Existing HSDPA/AMR CallHSDPA/AMR Call

UE

RNC SGSNNode B1

RAB Assignment Req

RL setup Request

RL setup Response

Radio Bearer Setup

RB setup Complete

RAB Assignment Response

AMR voice call and uploading photos is active, Web browsing in standby state

ServingCell sector 1Sector 1,2,3 E-DCHActive set and servingRLS

2 3


6-21



In this scenario of simultaneous high-speed data and voice, the following channels exist over the air:

• High-speed user data is carried in the uplink on the E-DPDCH along with E-DPCCH for control

information.

• The CQI, ACK/NACK information in the uplink is carried on the high-speed HS-DPCCH.

• In the downlink, high-speed user data is carried on the HS-DSCH and control information is carried

on the HS-SCCH.

• To support high-speed user data in the uplink, the downlink also contains the E-AGCH, E-RGCH

and E-HICH.

• Additionally, user voice along with associated signaling is carried on the DPDCH in the downlink

as well as the uplink.

• Both the uplink and downlink have to contain the DPCCH to cater for TFC and power control

information. Power control is done only for voice on the downlink by the uplink DPCCH. For both

voice and data on the uplink, the downlink DPCCH is used.

Simultaneous HSDPA, HSUPA and Voice

6-22



Simultaneous HSDPA, HSUPA and VoiceSimultaneous HSDPA, HSUPA and VoiceMulti-RAB Configuration


HS-SCCH, HS-DSCH (High Speed Data)

DPDCH (Voice and Signaling)



DPDCH (Voice and Data, Signaling)

E-DPDCH,E-DPCCH (Data and Control Info.)

E-AGCH,E-RGCH (Absolute and Relative Grants)

E-HICH (ACK and NACK)

6-23



The user, Suzanne, has finished uploading the photo files. This slide illustrates the procedure for HSUPA

call release on detecting inactivity for HSUPA service.

1. To release the radio access bearer with the negotiated QoS, the SGSN sends the RAB Assignment

Request (Release) to the RNC.

2. The RNC sends the Radio Link Reconfiguration Prepare message to the Node B. The message

includes E-DCH information parameters to be deleted such as E-DCH MAC-d flows, logical

channel IDs, and E-DCH radio links.

3. The Node B informs the RNC that it is ready for RL reconfiguration by sending the RL

Reconfiguration Ready message. The message includes the E-DPDCH, E-AGCH, E-RGCH and

E-HICH channel deletion information for each radio Link.

4. The RNC then sends an RL Reconfiguration Commit message to the Node B. Now, the old radio

link is released. On receiving this message, the Node B switches to the new configuration at the

next coming CFN with a value equal to the value requested by the RNC in the CFN IE.

5. The RNC forwards the Radio Bearer Release message to the UE. The RNC instructs the UE to

delete all E-DCH MAC-d flows, etc.

6. The UE responds to the RNC with the Radio Bearer Release Complete.

7. The RNC sends a Radio Bearer Reconfiguration message to the UE since some of the RLC

relevant parameters need to be modified and reconfigured at the UE.

8. After required modification in the RLC parameters, the UE sends a Radio Bearer Reconfiguration

Complete message to the RNC.

9. Finally The RRC connection pertaining to HSUPA control plane is released both on Iu and RRC

Now the user continues with the ongoing call to her friend and the Web browsing session.

Release of an HSUPA Call

6-24



Release of an HSUPA CallRelease of an HSUPA CallUE

RNC

RAB assign. Req( Release)


Radio Bearer Release Complete

SGSN

AMR voice call, web browsing session continues and uploading photos is in standby state

Radio Bearer Reconfiguration

Radio Bearer Reconfig. CompleteRAB Assignment

Response (Released)

Node B1

RL Reconfig. Prepare

RL Reconfig. Ready

RL Reconfig. Commit

Uploading is completed

SGSN

Signaling Connection Release RLSDRLC

6-25



The user now wants to close the call with her friend. This slide depicts the signaling messages used to

release the AMR call.

1. The UE initiates the procedure by sending a UL Direct Transfer (Disconnect) (call control NAS

message) indicating the normal clearing of the call.

2. The RNC further transmits this to the MSC by sending a DT (Disconnect) message.

3. The MSC transmits a Direct Transfer Release to the RNC

4. The RNC transmits this message by sending a Direct Transfer (Release) to the UE. Now the UE

and MSC have released the direst transfer transaction between NAS CC peer layers.

5. The UE responds with the Uplink Direct Transfer (Release complete), indicating the release of the

AMR call.

6. The RNC forwards the DT (Release Complete) message to the MSC.

7. The MSC initiates the procedure by sending the RLSD to release the SCCP connection.

8. The RNC sends a Signaling Connection Release to release the RRC control plane pertaining to the

AMR call.

9. The RNC finally sends an RLC message to the MSC indicating release of all resources pertaining

to the AMR call

Now the user continues browsing the website.

Release of an AMR Call

6-26



Release of an AMR CallRelease of an AMR CallUE

RNC MSC

6. DT (Release Complete)

Only Web browsing session continuesand uploading photos is in standby state

1. UL Direct Transfer (Disconnect)2. DT (Disconnect)

3. DT (Release)4. DL Direct Transfer (Release)

5. UL DT (Release Complete)

Terminating a voice call

7. RLSD8. Signaling Connection (Release)9. RLC

6-27



She finally also wants to close the Web browsing session.

The slide depicts the signaling messages involved in releasing the HSDPA call.

1. The UE sends a UL DT Deactivate PDP CTX Request to the RNC to deactivate the negotiated

QoS, which includes the APN, IP Address and QoS type.

2. The RNC transmits this transparently by sending a DT (Deactivate PDP Context Request) to the

SGSN.

3. The SGSN sends a Delete PDP Context Request to the GGSN.

4. The GGSN responds with a Delete PDP context Response to the SGSN. As a result, the tunnel for

the UE ID is deleted

5. To release the radio access bearer and negotiated QoS, the SGSN sends a RAB Assignment

(Release) Request to the RNC.

6. The RNC sends a Radio Bearer Release message to the UE .The parameters carried include HS-

DSCH MAC-d flows to delete and the RABS to be removed

7. The UE responds to the RNC with a Radio Bearer Release Complete.

8. The RNC responds to the SGSN with a RAB Assignment (Release) Response message.

9. The SGSN indicates the deactivation of QoS to the RNC by sending a DT (Deactivate PDP

Context Accept).

10. The RNC transmits a DL DT (Deactivate PDP Context Accept ) message to the UE indicating the

deactivation of the QoS is complete.

Release of an HSDPA Call

6-28



Release of an HSDPA CallRelease of an HSDPA CallUE

RNC

UL DT (Deactivate PDP CTX Req.)DT (Deact. PDPCTX Request) Delete PDP

CTX Request

Delete PDP CTX Res.RAB Assignment (Rel.)

RequestRadio Bearer Release


DT (DeAct. PDP CTX Accept)

DL DT(Deactivate PDP CTX Accept)

Web browsing session closed

RAB Assignment (Release) Resp.

RRC Connection Release Request

RRC Connection Rel. Complete

Iu Release

SGSN GGSN

6-29



The Web browsing session is deactivated:

1. The SGSN initiates the procedure by sending an Iu Release Command to release the Iu connection

and all UTRAN resources related only to that Iu connection. The procedure uses connection-

oriented signaling.

2. The RNC finally sends an Iu Release Complete message to the SGSN indicating release of all

resources.

3. The RNC sends an RRC Connection Release Request to the UE to release the SRB.

4. The UE responds with an RRC Connection Release Complete to the RNC.

The UE is now in idle state.

Release of an HSDPA Call (continued)

6-30



Release of an HSDPA Call Release of an HSDPA Call (continued)(continued)UE

RNC

UL DT (Deactivate PDP CTX Req.)DT (Deact. PDPCTX Request) Delete PDP

CTX Request

Delete PDP CTX Res.RAB Assignment (Rel.)

RequestRadio Bearer Release


DT (DeAct. PDP CTX Accept)

DL DT(Deactivate PDP CTX Accept)

Web browsing session closed

RAB Assignment (Release) Resp.

RRC Connection Release Request

RRC Connection Rel. Complete

Iu Release

SGSN GGSN

6-31



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Summary

6-32



SummarySummary• Several scenarios of R99, R5 and R6 multi-

services can be handled together• An AMR call can be added to an existing

HSDPA service and vice versa• An HSUPA service can be added to an

existing AMR call while HSDPA service is in standby state

• Once the HSDPA service resumes, it can be added to an existing HSUPA and AMR call, making it possible for all services to coexist

6-33



___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Review Questions

6-34



Review QuestionsReview Questions

1. When can the UE and network go to standby state? What is the effect?

2. What is the effect of Radio Bearer Reconfiguration?

3. When the RRC connection is released, does the PDP context still exist?

4. Can a Radio Bearer Release message reconfigure a particular service while releasing another service?

6-35


HSPA Interworking

HSPA InterworkingHSPA Interworking

7-1


HSPA Interworking

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Objectives

7-2


HSPA Interworking


• Describe the need for an R5/R6-to-R99 handover and list the processes and parameters required for supporting the handover

• Describe the processes and step through the end-to-end message flow for Inter-RAT handovers between HSPA and GPRS/EDGE

• Describe the processes and step through the end-to-end message flow for Inter-RAT handovers between GPRS/EDGE and HSPA

7-3


HSPA Interworking

This slide illustrates an example of R5- to-R99 handovers. As shown in this diagram, cell 1 in Node B1

and cell 1 and 2 in Node B2 are part of the active set. The UE is on a voice call served by cell, Node B1

and cell 1 and cell 2 in Node B2. The UE is in soft handover with these cells. The best HS-DSCH serving

cell is cell 1, which is part of cell 1 in Node B2. Node B1 does not support R5.

The UE continuously monitors the active set cells and other neighboring cells and measures their pilot

strength. The UE, while monitoring the active set, notices that cell 1 in Node B1 is received stronger than

the current serving cell 1 in Node B2. The UE transmits a Measurement Report message on the DPCCH to

the RNC. The message contains intra-frequency measurement results, triggered by the event 1D "change

of best cell.” The RNC must decide whether to switch to cell 1 in Node B1 that supports only R99, and

initiate a Radio Bearer Reconfiguration.

The situation of going from R5 to R99 is rare (only at the borders). So, the RNC determines that the UE is

clearly going away from the HSDPA coverage area, and triggers a Radio Bearer Reconfiguration and hand

down to R99.

R5-to-R99 Handovers (Initial)

7-4


HSPA Interworking

R5R5--toto--R99 R99 HandoversHandovers (Initial)(Initial)

UE

Serving Cell - cell 1DPCH

HS-SCCH/HS-PDSCH

HS-DPCCH/DPDCH/DPCCH

DPDCH/DPCCH

DPCHNo support of R5/HSDPA

Best Cell change event 1D is triggered to cell 1 in Node B1 butNode B1 does not support HSDPA

After best cell change to cell 1 in Node B1,UE has been reconfigured

by Node B1 from HSDPA to R99 data call

The UE is on a voice call with Node B1, cell 1 and Node B2 cell 1 and cell2 (soft handover) and HSDPA call with Node B2, cell 1 (serving cell)

High-Speed control/data

CQI, ACK/NACK / Pilot,TPC, Voice and Sig

Voice, Signaling, TPC, Pilot

Voice, Signaling, TPC, Pilot

Voice, Signaling, Data, Pilot, TPC

Node B12

1

3Node B2

213

Active set cells cell 1

Active set cells cell 1, and cell2

7-5


HSPA Interworking

This example summarizes the R5-to-R99 handover signaling messages.

As shown in the figure, the UE is in cell 1 of the HSDPA serving cell with source Node B2.

1. The UE transmits a Measurement Report message containing intra-frequency measurement results

(here assumed to be triggered by the event 1D “Change of Best Cell“).

2. The SRNC performs the best cell change on cell 1in Node B1, which supports only R99.

3. The SRNC sends a synchronized Radio Link Reconfiguration Prepare message to the source Node

B. Parameters that are sent mainly include HS-DSCH MAC-d Flows to Delete.

4. The source Node B2 responds with the Radio Link Reconfiguration Ready.

5. The SRNC sends a Radio Link Reconfiguration Prepare message to the target Node B1 asking it

to perform a synchronized radio link reconfiguration. Parameters include RAB reconfiguration

information, UL and DL transport channels to be configured, RLC parameters to be modified,

DCH information like DPDCH /DPCCH codes, and scrambling codes on the UL and DL

scrambling code.

6. The target Node B1 informs the SRNC that it is ready for RL reconfiguration by sending a Radio

Link Reconfiguration Ready message to the SRNC. Parameters include DCH information.

7. The SRNC initiates a setup of new Iub Data Transport Bearers using the ALCAP protocol. This

request contains the AAL2 binding identity to bind the Iub data transport bearer to the DCH.

R5-to-R99 Handovers (Prepare)

7-6


HSPA Interworking

R5R5--toto--R99 R99 HandoversHandovers (Prepare)(Prepare)Node B2

1

SRNC

2. Decision for best cell change to cell 1,Node B1(only R99 support)

23

HSDPA Serving cell is (Cell 1, Node B2)1. Measurement Report (event 1D)

Node B11

7. Iub bearer - DCH





7-7


HSPA Interworking

8. The SRNC transmits the NBAP Radio Link Reconfiguration Commit message to the source Node

B2. Parameters include activation time in the form of a CFN. At the indicated activation time, the

source HS-DSCH Node B2 stops and the target DCH Node B1 starts transmitting on the DCH to

the UE.

9. The SRNC now transmits a Radio Link Reconfiguration Commit to the target Node B1 including

the activation time. Parameters include selected activation time in the form of a CFN.

10 SRNC now sends a Radio Bearer Reconfiguration to the UE. Parameters include activation time,

DCH information, transport channel information, RLC parameters logical channel identifiers with

priorities, and the new U-RNTI, if required.

11. On successful radio bearer reconfiguration, the UE sends a Radio Bearer Reconfiguration

Complete message to the SRNC. Now, the target cell starts DCH transmission and the source cell

stops HS-DSCH transmission.

12. Now, the SRNC initiates release of the old Iub data HS-DSCH transport bearer using the ALCAP

protocol.


7-8


HSPA Interworking

R5R5--toto--R99 HandoversR99 Handovers (Prepare)(Prepare)NodeB2

1SRNC

.

23


Node B11



12. Iub Bearer HS-DSCH Release


7-9


HSPA Interworking

We have already seen that how the UE switches from the R5 serving cell to the R99 serving cell. This

slide gives the overview of changes / reconfigurations required after switching to an R99 cell that is from

a R5 data call to an R99 data call.

Now cell 1 in Node B1 becomes the serving cell for the UE, which is an R99 serving cell. Nevertheless,

the UE is now reconfigured to a R99 data call from an R5 data call. Since the UE is in soft handover

between cell 1 in Node B1 and cells 2 and 3 in Node B2, the reconfigured data call and voice call is

handled by both Node Bs. On both the UL and DL in active set cells of both Node Bs, the UE is on a

voice call. The UE is on a data call on the DL in active set cells of both Node Bs. The channels used for

transmission and reception are DPCH in the downlink and DPDCH/DPCCH in the uplink for both Node

Bs. The signaling, power control commands, pilot preamble and TFCI are sent on the UL, and the DL.HS-

PDSCH link between the UE and cell 1 in Node B2 is deleted after reconfiguration.

R5-to-R99 Handovers (Final)

7-10


HSPA Interworking

R5R5--toto--R99 HandoversR99 Handovers (Final)(Final)

UE

DPCH

DPDCH/DPCCH

DPDCH/DPCCH

DPCH

After Reconfiguration

R99 data and voice call

HSDPA link is deleted and voice call /

R99 Data call continues

Voice, signaling/TPC, Pilot, TFCI

Voice, Data, Signaling /TPC,Pilot, TFCIVoice, Sig / TPC, Pilot, TFCI

Voice, Data, Sig /TPC, Pilot, TFCI

Node B12

1

Serving cell-cell 1

3

Node B22

1

3

Active Set cells cell 1

Active Set cells cell 1,

and cell2

7-11


HSPA Interworking

This diagram shows the reason for handovers between R6 and regular R99 networks with their associated

channels.

Cell 1 in Node B1, cell 1 in Node B2 and cell 1 in Node B3 are in active sets. Cell 1 in Node B1 and cell 1

in NodeB2 belong to the E-DCH active set. Cell in Node B1 is the E-DCH serving cell and cell 1 in Node

B2 is part of the non-serving RLS. Cell 1 in Node B3 supports only R99. This scenario depicts the 3-way

soft handover of the UE between cell 1 in Node B1, cell 1 in Node B2 and cell 1 in Node B3 for voice

calls, and the E-DCH uplink transmission by the UE to cell 1 in Node B1 and cell 1 in Node B2. The UE

monitors all pilots in active sets and measures their pilot strength. It happens that the UE reports cell 1 in

Node B3 has greater strength than serving cell 1 in Node B1. This triggers an event 1D “Best Cell

Change” to cell 1 in Node B3, which supports only R99. The RNC must decide whether to switch to cell 1

in Node B3, which supports only R99, and initiate a Radio Bearer Reconfiguration.

Going from R6 to R99 is rare (only at the borders). So, the RNC determines that the UE is clearly going

away from the HSUPA coverage area and triggers a Radio Bearer Reconfiguration and hand down to R99.

R6-to-R99 Handovers (Initial)

7-12


HSPA Interworking

R6R6--toto--R99 HandoversR99 Handovers (Initial(Initial))

UE

Serving Cell 1

E-DPDCH / E-DPCCH

E-AGCH/E-RGCH

E-RGCH

DPCCH/ DPDCH

E-HICH

E-HICH

E-DPDCH / E-DPCCH

DPCH

Triggers event 1D

DPCH

DPDCH/DPCCHDPCH

DPDCH /-DPCCH

Scheduling/Noise control

High-Speed Data/control

ACK/NACK

Voice, Sig / Pilot, TPC,TFCI

Voice, Sig / TPC, Pilot, TFCI

Voice, Sig / TPC,Pilot, TFCI

Voice, Sig / Pilot, TPC,TFCI

Voice, Sig / Pilot, T

PC, TFCI

Node B32

13


No E-DCHR99 Voice call

Node B22

1

3


E-DCH active set cell 1

Non serving RLSR99 Voice call


E-DCH active set cell 1

Serving cell 1R99 Voice call

Node B12

13

7-13


HSPA Interworking

This example summarizes the R6-to-R99 handover preparation messages.

As shown in the figure, the UE is in cell 1, which is the HSUPA serving cell within NodeB1.

1. The UE transmits a Measurement Report message containing intra-frequency measurement

results, here assumed to be triggered by the event 1D “Change of Best Cell."

2. The SRNC performs the best cell change decision to cell 1, Node B3, which supports only R99.

3. The SRNC sends a synchronized Radio Link Reconfiguration Prepare message to the source Node

B1. Parameters that are sent mainly are E-DCH MAC-d flows to delete.

4. The source Node B1 responds with the Radio Link reconfiguration Ready.

5. The SRNC sends a Radio Link Reconfiguration Prepare message to the target Node B3, asking it

to perform synchronized Radio Link Reconfiguration. Parameters include RAB reconfiguration

information, UL and DL transport channels to be configured, RLC parameters to be modified,

DCH information like DPDCH /DPCCH codes, scrambling codes on UL and the DL scrambling

code.

6. The target Node B3 informs the SRNC that it is ready for RL reconfiguration by sending a Radio

Link Reconfiguration Ready message to the SRNC. Parameters include the DCH information

response.

7. The SRNC initiates a setup of new Iub data transport bearers using the ALCAP protocol. This

request contains the AAL2 binding identity to bind the Iub data transport bearer to the DCH.


7-14


HSPA Interworking


1

SRNC23

HSUPA Serving cell is (1,Node B1)1. Measurement Report (event 1D)

Node B31

7. Iub Bearer - DCH





2. Decision for best cell change to cell 1, Node B3 (only R99 support)

7-15


HSPA Interworking

8. The SRNC transmits the NBAP Radio Link Reconfiguration Commit message to the source Node

B1. Carried parameters include activation time in the form of CFN. At the indicated activation

time, the source E-DCH Node B1 stops and the target DCH Node B3 starts transmitting on the

DCH to the UE.

9. The SRNC now transmits a Radio Link Reconfiguration Commit to the target Node B3, including

the activation time. Parameters include selected activation time in the form of a CFN.

10 The SRNC now sends a Radio Bearer Reconfiguration to the UE. Parameters include activation

time, DCH information, transport channel information, RLC parameters, logical channel

identifiers with priorities, and a new U-RNTI, if required.

11. On successful radio bearer reconfiguration, the UE sends a Radio bearer Reconfiguration

Complete message to the SRNC. Now, the target cell starts DCH transmission and the source cell

stops HS-DSCH transmission.

12. Now, the SRNC initiates release of the old Iub data E-DCH transport bearer using the ALCAP

protocol.


7-16


HSPA Interworking


1SRNC

.

23


NodeB31



12. E-DCH Bearer Release


7-17


HSPA Interworking

After Reconfiguration, UE still continues to be on soft handover between cell 1 of Node B1, cell 2 of

NodeB2 and cell 3 of Node B3 for voice and R99 uplink data service.

Both UL and DL carries signaling, power control commands, pilot bits and TFCI. The new DCH transport

channel is set up in all three Node Bs and signaled to the UE. During reconfiguration, the serving E-DCH

radio link is deleted and the corresponding UL and DL channels for HSUPA are removed.

R6-to-R99 Handovers (Final)

7-18


HSPA Interworking

R6R6--toto--R99 HandoversR99 Handovers (Final)(Final)

UE

DPDCH/DPCCH

DPCH

DPCCH/ DPDCH

DPCH

DPDCH/DPCCH

DPCH

Reconfigured to R99 data

call

HSUPA link deleted

After reconfiguration, the UE is in soft handover with cell 1 of Node 1, cell 1 of Node B2 and cell 1 of Node B3 having

voice and UL data transfer

Voice, Data, Signaling/TPC, Pilot, TFCI

Voice, Signaling/TPC, Pilot, TFCI

C2

Node B32

1

Node B22

1

3

3

Node B12

1

Active Set Cells cell 1

R99 Voice call and R99 UL Data call 3


R99 voice call and R99 UL data call


R99 voice call and R99 UL data call

7-19


HSPA Interworking

The initial deployment of UMTS R5 and R6 networks will not provide ubiquitous coverage. Since the

basis of UMTS’s Core Network (CN) architecture is the Global System for Mobile communications

(GSM) and the General Packet Radio System (GPRS), many GSM operators will be deploying UMTS as

their 3rd generation mobile wireless network. While existing GSM networks provide seamless coverage,

the 3G coverage area will be initially focused on the population centers.. Users will be provided with dual-

mode phones, which may operate in either UMTS or GSM mode. While in the city, users will be able to

take advantage of the advanced capabilities of the 3G UMTS network. However, upon driving out of the

UMTS coverage area, they must be handed to the GSM network if the service is to be kept active.

Note that some service or service capabilities might be unavailable or might need to be downgraded when

a handover from HSPA to GSM/GPRS or HSPA (HSDPA and HSUPA) to GPRS /EDGE occurs.

Cell reselection and handovers are possible between HSPA and GPRS/EDGE and vice versa. They are

also called Inter-RAT cell reselection and handovers. HSPA works only in RRC “Cell DCH” state.

So, there is no UE-initiated cell reselection directly from HSPA to GPRS. However, network-initiated cell

reselection, moving from HSPA to GPRS, is possible. The UTRAN sends an RRC Cell Change Order

message from the RNC to the UE to move the UE from an HSPA/R99 cell to the GPRS cell. Network-

assisted cell change can be ordered by the network if, for example, the network is loaded or for the

purposes of flow control.

The cell reselection and packet-switched handover procedures between HSPA and GPRS/EDGE and vice

versa are similar to R99.

R4 introduces the concept of GERAN, where the GSM/GPRS BSS can have an Iu interface with SGSN

and MSC/VLR. The old interfaces of A/GB mode can still exist and handovers between A/GB mode

GSM/GPRS networks and Iu mode GSM/GPRS are also supported. Similarly, handovers between the

UMTS Iu mode and GSM/GPRS Iu mode or UMTS Iu mode and GSM/GPRS A/GB are also possible.

Radio resource management strategies are now handled by the RRC when GSM/GPRS BSS operates in

the Iu mode.

HSPA – GPRS/EDGE Interworking

7-20


HSPA Interworking

HSPA Cells GPRS CellsHSDSCH Serving CellE-DCH Serving Cell

Iu/GbIu

Iub A bis

Node B

RNC

Non-serving

RLS

Serving RLSNode B

GPRS Serving

Cell

SGSN Core

BTS BTS

BSC

HSPA – GPRS/EDGE Interworking

7-21


HSPA Interworking

This slide illustrates UTRAN signaling procedures for UTRAN-to-GPRS cell reselection triggered by the

serving RNC. Please also refer to specs 25.931.

1. As soon as the trigger is detected by the SRNC, it initiates the handover to GSM/BSS by sending

the RRC Cell Change Order from UTRAN message to the UE.

2. The target GPRS cell is reselected by the UE and the radio connection to the GSM/BSS is now

established.

3. The GPRS Routing Area Update procedure is initiated by the UE by sending the GMM Routing

Area Update Request message to the SGSN.

4. The SGSN sends the RANAP SRNS Context Request message to the SRNC listing the PS RABs

for which context transfer shall be performed.

5. The RANAP SRNS Context Response message is sent by the SRNC in response to the SGSN,

which contains the context information of all referenced PS RABs whose transfer is successful.

6. To recover the buffered data, the SGSN transmits the RANAP SRNS Data Forward Command

message to the SRNC. The message includes the list of PS RABs whose data should be

forwarded, and necessary tunnelling information to be used for data forwarding.

Network-Initiated UMTS – GPRS Cell Reselection

7-22


HSPA Interworking

NetworkNetwork--Initiated UMTS Initiated UMTS –– GPRS Cell GPRS Cell Reselection Reselection

UESRNC

Node B1

1. Cell Change order from UTRAN

2. Relocation to the target GPRS cell, radio link establishment in GSM/BSS

3. Routing Area Update Req.

4. SRNS CNXT Req.

5. SRNS CNXT Response

6. SRNS Data Forward Comm.

BSC

CNSGSN

7-23


HSPA Interworking

7. For each PS RAB indicated by the SRNS Data Forward Command, the SRNC starts duplicating

and tunnelling the buffered data back to the SGSN.

8. To initiate release of the Iu connection with the UTRAN, the SGSN sends the RANAP Iu Release

Command message to the SRNC.

9. The SRNC sends the RANAP Iu Release Complete message to the SGSN when the data

forwarding timer (i.e.T DATAfwd ) of the RNC expires.

10. The release of Iu the data transport bearer using the ALCAP protocol is initiated by the SRNC.


7-24


HSPA Interworking

NetworkNetwork--Initiated UMTS Initiated UMTS –– GPRS Cell GPRS Cell ReselectionReselection

UESRNCCN

SGSN Node B1

8. Iu Rel.Command

7. Forwarding of PDUs

9. Iu Rel.Complete

10. ALCAP Iu Bearer Rel.

BSC

7-25


HSPA Interworking

11. The SGSN validates the UE’s presence in the new RA by sending the GMM Routing Area Update

Accept message to the UE. The message may contain a new P-TMSI that the network assigns to

the UE.

12. The GMM Routing Area Update Complete message is sent by the UE to acknowledge the

assignment of a new P-TMSI.

13. The SGSN and BSS can execute the BSS Packet Flow Context procedure and data transmission

can resume in the GPRS.

14. The NBAP Radio Link Deletion Request message is sent by the SRNC to the Node B to initiate

the release of the link.

15. The Node B confirms the release of the link by sending the NBAP Radio Link Deletion Response

message to the SRNC.

16. The Node B initiates the release of the Iub data transport bearer using the ALCAP protocol.


7-26


HSPA Interworking

NetworkNetwork--Initiated UMTS Initiated UMTS –– GPRS GPRS Cell ReselectionCell Reselection

UE

SRNC Node B1

14. Radio Link Del. Req.

15. Radio LinkDel. Resp.

16. ALCAP Iu Bearer Rel.

11. Routing Area Update Acc.

12. Routing Area Update Comp.

13.Creating BSS flow CTX. data resume in GPRS

BSCCN

SGSN

7-27


HSPA Interworking

Handovers are used in cellular mobile systems to maintain connections as mobiles move between the

coverage areas of different base stations. The handover procedure involves four distinct algorithmic phases

that are discussed as mentioned in the figure.

Monitor: The first phase is monitoring, which includes communicating neighbor lists, taking signal

strength measurements of the current cell and cells in neighbor, and reporting the measurements.

In the monitoring phase, the mobile sends the current signal strength of the current cell and the cells in

the neighbor list to the network to facilitate the handover process. The network monitors the

transmission conditions between each MS and its current cell, and moves the MS to a new cell as

necessary.

Trigger: In the trigger or detection phase, the network detects that a handover may be required. This

can be based on a number of different factors such as signal strength, signal quality, interference,

distance, or traffic level in the current cell. The next phase of the handover process is the target cell

selection phase. In this phase, the network uses network topology information and measurements to

evaluate a list of candidate cells and select a target cell for the handover.

Target Selection: The target cell is selected in the target selection phase, and the channels for

transmission and reception are allocated to that cell. If no target cell is found, the mobile again returns

to the first phase that it is monitoring. It again starts monitoring the current as well as neighbor cells

until the target cell is selected.

Execution: In this phase, the MS changes to the new channel and resumes the call. Thus, the

handover is executed and completed successfully in this phase. If no acceptable target cell is available,

the handover can be attempted again later. After completion of this phase, it again enters the first

phase and starts monitoring the measurements of current cells and neighbor cells.

Handover Phases

7-28


HSPA Interworking

Handover PhasesHandover Phases

Monitor

Trigger

TargetSelection

Execution

NoTargetFound

• Communicating Neighbor List

• Taking Measurements

• Reporting Measurements

• Executing the Handover

• Completing the Handover

7-29


HSPA Interworking

The UE performs different measurement procedures as controlled by the UTRAN in its idle mode and

connected mode.

When the UE is in idle mode, the system information elements are broadcast in System Information

Blocks (SIB). It receives measurement control information related to Inter–RAT measurement in system

information SIBs 11 and 12. These SIBs are transmitted from the RNC to the UE.

The UE measures its surrounding environment as instructed by the UTRAN. The UTRAN may control a

measurement in the UE either by using the broadcast system information and/or by sending a

Measurement Control message. In the broadcast system information, the measurement control information

is included in SIB 11 or 12.

When the UE is in connected mode, the RNC sends a Measurement Control message to the UE. The

Measurement Control message includes the following information:

• The type of measurement (for example, intra-frequency and/or inter-frequency measurement)

• The quantity the UE should measure (for example CPICH Ec/I0 – chip energy per total received

channel power density)

• The characteristics of the events that should trigger a measurement report, etc.

For example, an event can be that the signal strength of a monitored cell becomes stronger than the cell the

UE is currently connected to. Based on the requirement set by the UTRAN, the UE may need to send a

measurement report to inform the UTRAN for the consideration of a handover.

When an event ordered by the UTRAN occurs, the UE sends a Measurement Report message to the

UTRAN. This message includes the information related to the event as requested by the UTRAN’s

measurement control information. A measurement report is closely related to the initiation of a soft

handover. Thus, the UTRAN controls the entire measurement criteria.

Inter-RAT Measurements

7-30


HSPA Interworking

If UE in idle mode

InterInter--RAT MeasurementsRAT Measurements

RNCNode B

CN PSTNIub IuUu

Measurement Control

UTRAN controls measurement criteria

If UE in connectedmode

BCH/PCCPCH

System Information Blocks(11/12)

RRC

Measurement Report

7-31


HSPA Interworking

The Inter-RAT measurement parameters are sent to the UE in either System Information Blocks (SIB) 11

or 12, or in a Measurement Control message, depending on whether it is in idle state or connected state.

The key parameters included are shown in the figure.

Inter-RAT Cell Info List: This provides the UE with the list of GPRS neighbors. It includes the Base

Station Identification Code (BSIC) and the Absolute Radio Frequency Channel Number (ARFCN) for the

GPRS cells. Additionally, it also includes the compressed mode parameters.

Inter-RAT Measurement Quantity: This specifies the GPRS radio parameters that need to be measured

by the UE. For GPRS, it specifies whether the RSSI or path loss should be measured. It also involves

BSIC identification and verification.

Inter-RAT Measurement Criteria: This specifies the thresholds and hysteresis values to trigger

reporting of Inter-RAT measurements if threshold-based reporting is enabled. In addition, this message

(either SIB 11 or 12 or Measurement Control) includes parameters for periodic reporting if periodic

reporting is enabled.

Key Parameters for Inter-RAT

7-32


HSPA Interworking

Key Parameters for InterKey Parameters for Inter--RATRAT

Inter-RAT Measurement Criteria

Inter-RAT Measurement Quantity

Inter-RAT Cell Info List

Thresholds and Hysteresis values for triggering Inter-RAT measurement reports

GPRS Radio parameters to be measured• RSSI or Path loss• BSIC Identification and Verification

The list of GPRS Neighbors• BSIC for GPRS cells• BCCH ARFCN • Compressed mode parameters

7-33


HSPA Interworking

Since each neighboring cell in a UMTS system normally is operating on the same frequency as the serving

cell or set of cells (in the case of soft handover), the UMTS UE can perform intra-frequency measurements

while sending and receiving data on the physical layer RF interface. However, there are scenarios,

especially during early stages of UMTS deployment, in which ubiquitous coverage with a single UMTS

carrier is not the case. In these situations, the UTRAN can direct the UE to tune to a different UMTS

frequency or another radio access technology (RAT). This implies tuning to a different frequency to

measure the conditions and report to the UTRAN, thus initiating inter-frequency or inter-RAT hard

handovers.

The need for inter–frequency measurements requires some mechanism to allow the UE to continue with

the current operation and still measure the new frequency. The compressed mode procedure allows the

UE, with only one receiver, to obtain measurements and still continue with the original connection.

As compared to the HSDPA operation, the DPCH is given priority. This means, for example:

• If part of the HS-SCCH or HS-PDSCH overlaps with a downlink compression gap, the UE

neglects the HS-SCCH or HS-PDSCH transmission

• If part of a HS-DPCCH slot allocated for ACK/NACK or CQI overlaps with an uplink

transmission gap on the associated DPCH, the UE does not transmit the ACK/NACK or CQI

information in that slot

Inter-Frequency and Inter-RAT Measurements

7-34


HSPA Interworking

InterInter--Frequency and Frequency and InterInter--RAT MeasurementsRAT Measurements

• How does the UE report on Inter-Frequency and Inter-RAT events?

• Compressed Mode – the UE and the UTRAN negotiate a mechanism to take time away from transmitting and receiving data to tune to a different frequency or radio access technology

• The DPCH-compressed mode has priority over HSDPA operation

7-35


HSPA Interworking

As discussed earlier, the four phases of the UE, the trigger, and target selection phases are considered.

For the trigger and target selection phases, the manufacturer of the RNC designs both of these steps. The

following information provides clues regarding the structure of the algorithms:

• The handover algorithm must be designed so that the serving cell has an acceptable signal strength

and signal quality (RSCP, Ec/Io and Transport Channel, BLER in UMTS)

• The handover algorithm must take into account the signal strength of the neighbor cells, and a

handover can occur based a neighbor’s signal strength, not on the serving cells signal strength

• The service provider needs to set a priority of UMTS vs. GSM/GPRS

– This may trigger a handover to UMTS, not because of pool signal quality on the GSM cell,

but because the UMTS cell has a satisfactory quality and a higher preference.

Trigger and Target Selection

7-36


HSPA Interworking

Trigger and Target SelectionTrigger and Target Selection

• Decisions are proprietary in the RNC! • Decisions are based on cause for

handover:– Current cell signal strength and quality

• Signal strength - CPICH Ec/Io, RSCP• Quality - Transport channel BLER

– Adjacent cell signal strength• GSM/GPRS or UMTS cell

Monitor

Trigger

TargetSelection

Execution

NoTargetFound

7-37


HSPA Interworking

This graph represents the Inter-Rat reporting event, and considers UMTS and GSM/GPRS measurement

quantities. The UMTS and GSM/GPRS threshold are as shown and time to trigger is mentioned. This

indicates the period of time during which the event condition has to be satisfied before sending a

measurement report.

Four measurement report events have been defined to support Inter-RAT measurements. The first event is

the most important, and is shown in the slide. The 3A event is defined so the mobile reports when the total

UMTS signal strength drops below a threshold and the best GSM/GPRS signal quality goes above a

threshold. These thresholds are independent. This can be key for the RNC to know when to initiate the

UMTS to GSM/GPRS handover.

Inter-RAT Reporting Event

7-38


HSPA Interworking

InterInter--RAT Reporting EventRAT Reporting Event• Send measurement report only after the UMTS

quality drops below a threshold and the GSM quality is above a threshold

Time

Measurementquantity

Time to trigger

Reporting event 3A

UMTS

GSM

GSM Threshold

UMTS Threshold

7-39


HSPA Interworking

The final phase of executing the handover is discussed in this slide. The HSPA-to-GPRS/EDGE handover

may occur in GERAN Gb mode as well as GERAN Iu mode. The key message that is used to trigger the

handover from HSPA to GPRS/EDGE is the Handover from UTRAN Command. The contents of an

HSPA Handover Command message are included as a parameter in the Handover from UTRAN

Command message. This Handover from UTRAN Command message includes all information needed by

the mobile to access the new GPRS/EDGE traffic channel that has been assigned. This message includes

the new ARFCN and TBFs (temporary block flow) assigned to the mobile. After the mobile has changed

frequencies and synchronized with the GPRS/EDGE system, the mobile sends a Handover Complete

message on the newly acquired traffic channel (PDTCH) if it is in Iu mode. For Gb mode, any RLC block

that is sent on the newly acquired traffic channel (PDTCH) and successfully decoded by the GPRS BSS is

considered a successful handover.

Executing the Handover

7-40


HSPA Interworking

Executing the HandoverExecuting the Handover

Monitor

Trigger

TargetSelection

Execution

NoTargetFound

GERAN GBMode

GERAN Iu Mode

• Handover from UTRAN command

• First RLC block that is decoded successfully

HSPA HO to GPRS/EDGE

• Handover from UTRAN command

• Handover complete

7-41


HSPA Interworking

This slide illustrates an HSPA-to-GPRS/EDGE handover in Iu mode. Please refer to specs 25.922 for the

message flow and contents of each message on 25.413, 44.118 and 25.331.

1. The UE sends the Measurement Report whenever inter-RAT events are triggered to the RNC.

This includes the measurement results of the ARFCN, BSIC, and signal strength of the BCCH

ARFCN measured on neighboring GPRS cells.

2. Depending on the information in the Measurement Report, the serving RNC makes the decision to

relocate. The serving RNC sends a Relocation Required message to the SGSN. It contains

parameters like relocation type, cause, security algorithm, HS-DSCH MAC-d flow ID, E-DCH

MAC-d flow ID, security parameters and RAB identifier, source identifier and target Identifier.

3. The Core Network (CN) initiates the procedure by generating a Relocation Request message

toward the T-GSM-BSSS. The parameters are similar to Relocation Required parameters. A new

IU signaling Iu connection identifier is sent with the UE identity and RABs to be set up with RAB

identifiers.

4. After all necessary resources for accepted RABs including the initialized Iu user plane are

successfully allocated, the T-GSM-BSS sends a Relocation Request Acknowledge message to the

CN, which includes the RAB ID and Transport Layer Address, d-RNTI.

5. The Relocation Command message is sent by the CN (SGSN) to the serving RNC to indicate that

resources for the relocation are allocated in the T-GSM-BSS. If the target system (including target

CN) does not support all existing RABs, the Relocation Command message contains a list of

RABs, indicating all the RABs that are not supported by the target system. It also includes the

RAB ID and transport layer address.

6. The serving RNC sends a Handover from UTRAN Command message to the UE. The message is

used for handover from HSPA to GPRS/EDGE, as mentioned in our example. It includes UE

information elements such as integrity check information, activation time and RB information

elements such as the RAB information list to reconfigure.

HSPA-to-GPRS/EDGE Handover - Iu Mode

7-42


HSPA Interworking

HSPAHSPA--toto--GPRS/EDGE Handover GPRS/EDGE Handover -- Iu Iu ModeMode

2. Relocation Required1. Measurement Report

5. Relocation Command6. Handover from UTRAN

Command

7. Relocation Detect

8. Handover Complete

9. Relocation Complete

10. Iu Release Command

11. Iu Release Complete

3. Relocation Request

4. Relocation Request ACK

T-BSSCN-SGSNS-BSCUE

7-43


HSPA Interworking

7. The T-GSM-BSS sends a Relocation Detect message to the CN (SGSN) The Relocation Detect

message indicates the detection by the T-GSM-BSS of an SRNS relocation execution to the CN.

When the Relocation Detect message is sent, the T-GSM BSS starts serving -GSM-BSS

operation.

Upon receipt of the Relocation Detect message, the CN may switch the user plane from the

serving RNC to the T-GSM-BSS

8. When the UE has sent a Handover Complete message to the T-GSM-BSS, the UE initiates a

temporary block flow toward GPRS and sends a RA update request.

9. The T-GSM-BSS sends a Relocation Complete message to the CN (SGSN) to indicate that the T-

GSM-BSS has relocated the SRNS.

10. This message is sent by the CN to order the RNC to release all resources related to the Iu

connection. After the IU Release Command message has been sent, the CN does not send further

RANAP connection-oriented messages on this particular connection. The IU Release Command

message includes a Cause IE indicating the reason for the release (e.g., "Successful Relocation",

"Normal Release," "Release due to UTRAN Generated Reason," "Relocation Cancelled," and "No

Remaining RAB").

11.The SRNS sends an IU Release Complete message to the CN (SGSN) as a response to the IU

Release Command message. Reception of an IU Release Complete message terminates the

procedure in the CN. RRC connections are also released.

HSPA-to-GPRS/EDGE Handover - Iu Mode (continued)

7-44


HSPA Interworking

HSPAHSPA--toto--GPRS/EDGE Handover GPRS/EDGE Handover -- Iu Iu Mode Mode (continued)(continued)


5. Relocation Command6. Handover from UTRANCommand


8. Handover Complete





4. Relocation Request ACK.

T-BSSCN-SGSNS-BSCUE

7-45


HSPA Interworking

The slide illustrates an HSPA-to-GPRS/EDGE handover in Gb mode. Please refer to specs 25.922 for the


1. The UE sends the measurement report to the RNC, which includes the measurement results of

neighbor GPRS cells signal strength, BSIC and their BCCH ARFCN.

2. The serving RNC sends a Relocation Required message to the SGSN. The parameters are MS

radio Access capability, Inter RAT handover information, page mode, and Global TFI.

3. The SGSN initiates the PS Handover Request procedure by sending a PS-Handover-Request PDU

to the T-GSM-BSS, source BSS to target BSS information container. The container contains

mainly Inter-RAT handover information, Global TFI, etc.

4. After all necessary resources are successfully allocated, the T-GSM-BSS sends a PS Handover

Request Acknowledge message to the Core Network (CN), which consists of PS handover

command information from the NAS.

5. The Relocation Command message is sent by the CN (SGSN) to the serving RNC to indicate that

resources for the relocation are allocated in the T-GSM-BSS. This includes PS handover

command information.

6. The serving RNC sends a Handover from UTRAN Command message to the UE, which is used

for handover from HSPA to GPRS/EDGE as mentioned in our example. It includes a Gb mode

message, and the contents are from a PS handover command. The PS handover commands are TFI

assignment, Radio blocks and Timeslot, USF values and granularity for uplink transmission.

7. When the UE sends the first GPRS/EGPRS RLC block to the GSM BSS (and the BSS is able to

decode successfully), this indicates that the handover is successful.

8. The T-GSM-BSS initiates the PS Handover Complete procedure in the case of successful PS

handover on receipt of the first correct RLC data block from the MS in the target cell.

HSPA-to-GPRS/EDGE Handover - Gb Mode

7-46


HSPA Interworking

HSPAHSPA--toto--GPRS/EDGE Handover GPRS/EDGE Handover -- Gb Gb ModeMode



7. First RLC block on PDTCH successfully received then go to 8

8. PS Handover Complete



3. PS handover Request

4. PS Handover Req ACK

T-BSSCN-SGSNSRNCUE

7-47


HSPA Interworking

9. This message is sent by the CN (SGSN) to order the SRNC to release all resources related to the

Iu connection. After the IU Release Command message has been sent, the CN does not send

further RANAP connection-oriented messages on this particular connection. The IU Release

Command message includes a Cause IE indicating the reason for the release (e.g., "Successful

Relocation," "Normal Release," "Release due to UTRAN Generated Reason," "Relocation

Cancelled," and "No Remaining RAB").

10. The SRNS sends an IU Release Complete message to the CN (SGSN) in response to the IU

Release Command message. Receipt of an IU Release Command message terminates the

procedure in the CN. The RRC connections are also released.

HSPA-to-GPRS/EDGE Handover - Gb Mode (continued)

7-48


HSPA Interworking

HSPAHSPA--toto--GPRS/EDGE Handover GPRS/EDGE Handover -- Gb Gb ModeMode (continued)(continued)



7. First RLC block on PDTCH successfully received then go to 8

8. PS Handover Complete



3. PS handover Request

4. PS Handover Req ACK

T-BSSCN-SGSNSRNCUE

7-49


HSPA Interworking

Both UMTS and the GPRS include reporting measurement procedures whose included parameters are

discussed individually.

While the mobile is active on a call, it sends a Packet Measurement Report or an Enhanced Measurement

Report in every SACCH block. This works out to a measurement report being sent periodically or when

polled by the network. Unlike with UMTS, GPRS sends a measurement report periodically versus when a

preset trigger is met.

The type of report that the mobile sends is dictated in the Measurement Information message. The

measurement report includes the required GPRS parameters for the serving cell such as the ARFCN,

BSIC, and Rxlev. The UMTS report includes the UARFCN, Scrambling code, and Ec/No or RSCP. Also

included (as needed) is the signal strength of the top 6 UMTS cells based on the type of measurement that

was instructed by the Measurement Information message.

Reporting Measurements

7-50


HSPA Interworking

Reporting MeasurementsReporting Measurements

• Packet Measurement Report: Sent periodically or when polled by the network

• Reports include:– GPRS

• ARFCN• BSIC• RxLev

– UMTS• UARFCN• Scrambling Code• Ec/No or RSCP

Monitor

Trigger

TargetSelection

Execution

NoTargetFound

Monitor

Trigger

TargetSelection

Execution

7-51


HSPA Interworking

The final phase of executing the handover is discussed in this slide. The GPRS/EDGE-to-HSPA handover

may occur in Gb mode as well as Iu mode. The key message that triggers the handover from GPRS/EDGE

to HSPA in GERAN Gb Mode is the PS Handover Command. This message is sent on the packet-

associated control channel (PACCH) by the network to the mobile station to command the mobile station

to leave the current cell and change to a new cell.

After the mobile has changed frequencies and synchronized with the HSPA system, the mobile sends a

Handover Complete message on the newly acquired traffic channel.

In GERAN Iu Mode, the message for initiating GPRS/EDGE-to-HSPA Handover is the Intersystem

Handover to UTRAN Command message which is sent by the network to the mobile to initiate the

handover-to-UTRAN procedure. The Intersystem Handover to UTRAN Command message contains the

RRC transaction identifier, activation time, integrity check information, and integrity protection mode

information.

The mobile, on synchronization with changed frequencies of the HSPA system, sends a Handover to

UTRAN Complete message on the newly acquired traffic channel.

Executing the Handover

7-52


HSPA Interworking

Executing the HandoverExecuting the Handover

Monitor

Trigger

TargetSelection

Execution

NoTargetFound

GERAN GBMode

GERAN Iu Mode

• PS handover command

• Handover to UTRAN complete

• Intersystem handover to UTRAN command

• Handover to UTRAN complete

GPRS/EDGE to HSPA HO

7-53


HSPA Interworking

The slide summarizes GPRS/EDGE to HSDPA handover in Iu mode. Please refer to specs 25.922 for the


1. The UE sends the Packet Measurement Report to the S-BSS, which includes the measurement

results like the 3G cell list and their reporting quantity.

2. Depending on the Measurement Report, the serving S-BSS decides to Relocate.

The purpose of the Relocation Preparation procedure is to prepare relocation of the SRNS, with or

without involving the UE. The S-BSS initiates the procedure by sending a Relocation Required

message to the CN (SGSN). In the case of a GPRS/EDGE-to-HSPA handover, in the Relocation

Required message the serving S-BSS indicates the following parameters: the source RNC to target

RNC transparent container, which contains Inter-RAT handover information with Inter-RAT

capabilities.

3. The CN initiates the procedure by generating a Relocation Request message to the T-RNC. This

also consists of the source RNC to target RNC transparent container.

4. After all necessary resources for accepted RABs (including the initialised Iu user plane) are

successfully allocated, the T-RNC sends a Relocation Request Acknowledge message to the CN

that includes RABs that are reconfigured, Uplink and Downlink DCH transport channel

parameters, radio link information, HS-DSCH information, E-DCH information, HS-DSCH

MAC-d flows and E-DCH MAC-d flows.

5. The Relocation Command message is sent by the CN (SGSN) to the S-BSS to indicate that

resources assigned by the T-RNC. The CN forwards the same parameters sent by the TRNC to the

source BSS.

GPRS/EDGE-to-HSPA - Iu Mode

7-54


HSPA Interworking

GPRS/EDGEGPRS/EDGE--toto--HSPA HSPA -- Iu ModeIu Mode

2. Relocation Required

1. PacketMeasurement Report

5. Relocation Command6. Intersystem to UTRAN

Handover Command7. Relocation Detect

8. Handover to UTRAN Complete






T-RNCCN-SGSNS-BSCUE

7-55


HSPA Interworking

6. The Intersystem Handover to UTRAN Command message is sent by the S-BSS to the mobile to

initiate the handover to UTRAN procedure. The Intersystem Handover to UTRAN Command

message contains the RRC transaction identifier, activation time, integrity check information, and

Radio Bearer Reconfiguration message parameters. It consists of HS-DSCH MAC-d flows to add,

E-DCH MAC-d flows to add, logical channel identifiers, E-DCH information, HS-DSCH

information, and information on each radio Link.

7. The T-RNC sends a Relocation Detect message to the CN (SGSN) to indicate the detection by the

T-RNC of an S-BSS relocation execution. When the Relocation Detect message is sent, the T-

RNC starts serving –RNC operation.

Upon reception of the Relocation Detect message, the CN may switch the user plane from the S-

BSS to the T-RNC.

8. When the UE has sent the Handover to UTRAN Complete message to the T-RNC, it has changed

frequencies and is now synchronized with the HSPA system. The R99 channels on both DL and

UL for power control, Pilot, HSDPA UL and DL channels and UL and DL HSUPA channels are

now configured.

9. The T-RNC sends a Relocation Complete message to the CN (SGSN) to indicate the completion

by the T-RNC of the relocation of the S-BSS.

10. This message is sent by the CN to order the S-BSS to release all resources related to the Iu

connection. After the IU Release Command message has been sent, the CN does not send further

RANAP connection-oriented messages on this particular connection. The IU Release Command

message includes a Cause IE indicating the reason for the release (e.g., "Successful Relocation“).

11. The S-BSS sends an IU Release Complete message to the CN (SGSN) in response to the IU

Release Command message. Reception of the IU Release Complete message terminates the

procedure in the CN. The RRC connection with the GSM/BSS Iu mode is now released.

GPRS/EDGE-to-HSPA - Iu Mode (continued)

7-56


HSPA Interworking

GPRS/EDGEGPRS/EDGE--toto--HSPA HSPA -- Iu ModeIu Mode(continued)(continued)











T-RNCCN-SGSNS-BSCUE

7-57


HSPA Interworking

This slide summarizes GPRS/EDGE-to-HSPPA handover in Gb mode. Please refer specs 25.922 for the

message flow and contents of each message on 25.413, 48.018, 25.331 and 44.060.

1. The UE sends the Packet Measurement Report to the S-BSS, which includes the measurement

results. This includes the scrambling code of the cells, their Pilot Ec/No, and RSCP.

2. The S-BSS sends the PS Handover Required message to the CN (SGSN). This message consists

of the source RNC-to-Target RNC transparent container, which consists of the Inter-RAT

handover information with Inter-RAT capabilities.

3. The CN (SGSN) initiates the procedure by generating a Relocation Request message to the T-

RNC. The Core Network (CN) forwards the contents to the T-RNC that were previously sent by

the source BSS.

4. The target RNC sends a Relocation Request Acknowledge to the CN. The contents include a

target RNC to source RNC transparent container with handover to UTRAN command message

parameters.

5. After all necessary resources are successfully allocated, the CN (SGSN) sends a PS Handover

Request Acknowledge message to the S-BSS which contains the parameters of the above

message.

6. The S-BSS sends a PS Handover Command to the UE which includes the Handover to UTRAN

command parameters. The parameters carried include the RAB parameters to add list, E-DCH

MAC-d flow ID, HS-DSCH MAC-d flow ID, E-DCH information, HS-PDSCH information,

information for radio links, and the serving cell scrambling code.

7. The T-RNC sends the Relocation Detect message to the CN (SGSN). The purpose of the

Relocation Detect procedure is to indicate to the CN the detection by the T-RNC of an S-BSS

relocation execution. When the Relocation Detect message is sent, the T-RNC starts serving –

RNC operation.

GPRS/EDGE-to-HSPA - Gb Mode

7-58


HSPA Interworking

GPRS/EDGEGPRS/EDGE--toto--HSPA HSPA -- Gb ModeGb Mode











T-RNCCN-SGSNS-BSCUE

7-59


HSPA Interworking

Upon reception of the Relocation Detect message, the CN may switch the user plane from the S-BSS to

the T-RNC.

8. When the UE has sent the Handover to UTRAN Complete message to the T-RNC, it has changed

frequencies and is now synchronized with the HSPA system. The mobile sends a Handover to

UTRAN Complete message on the newly acquired DPCCH logical channel.

9. The T-RNC sends a Relocation Complete message to the CN (SGSN) to indicate to the CN that

the T-RNC has relocated the S-BSS.

GPRS/EDGE-to-HSPA - Gb Mode (continued)

7-60


HSPA Interworking

GPRS/EDGEGPRS/EDGE--toto--HSPA HSPA -- Gb ModeGb Mode(continued)(continued)

2. PS Handover Required

1. Packet Measurement Report

5. PS handover request Ack.

6. PS Handover Command


8. Handover to UTRAN complete



4. Relocation Request Ack.

T-RNCSGSNS-BSCUE

7-61


HSPA Interworking

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Summary

7-62


HSPA Interworking

SummarySummary• There can be many reasons to hand over from R6/R5 to

R99. One of the reasons can be Best Cell Change, “event 1D”

• When Best Cell Change is initiated by the RNC, the target cell may only support R99, and, hence, the R6/R5 data call is reconfigured to an R99 call

• Handovers/Interworking between HSPA and GPRS/EDGE and vice versa is possible, and it is based on a UE Measurement Report triggered due to Inter-RAT measurement event results. The process is similar to R99–GPRS/EDGE interworking.

• HSPA-to-GPRS/EDGE and vice versa handover execution works in both Iu and Gb modes

• The messages and their corresponding parameters vary between Iu mode and Gb mode for HSPA–GPRS/EDGE handovers and vice versa

7-63


HSPA Interworking

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

___________________________________________________________________________________

Review Questions

7-64


HSPA Interworking

Review QuestionsReview Questions

1. Is a UE-initiated cell reselection possible directly from HSPA to GPRS/EDGE?

2. What is the process initiated by the RNC for handing over an R5/R6 data call to R99?

3. To support the Iu mode of operation at GSM-BSS, what is the major change required at the BSS?

4. When can network-assisted cell reselection occur?

7-65

Appendix: HSDPA Call Setup

Mastering HSDPA/HSUPA Signaling A-1

Appendix: HSDPA Call Setup Table of Contents Multi-Service Calls

1. RRC Connection Request (UL-CCCH)............................................ 3 2. RRC Connection Setup (DL-CCCH)................................................ 3 3. RRC Connection Setup Complete (UL-DCCH)................................. 5 4. Service Request.......................................................................... 7 5. Initial Direct Transfer (UL-DCCH)................................................. 7 6. Measurement Control (DL-DCCH)................................................. 7 7. Security Mode Command (DL-DCCH)............................................ 8 8. Security Mode Complete (UL-DCCH)............................................. 9 9. Uplink Direct Transfer (UL-DCCH).................................................9 10. Activate PDP Context Request...................................................... 10 11. Radio Bearer Setup (DL-DCCH).................................................... 10 12. Radio Bearer Setup Complete (UL-DCCH)......................................13 13. Radio Bearer Reconfiguration (DL-DCCH)………………..............…….. 13 14. Radio Bearer Reconfiguration Complete (UL-DCCH)....................... 14 15. Downlink Direct Transfer (DL-DCCH)............................................ 14 16. Activate PDP Context Accept........................................................ 14 17. Radio Bearer Reconfiguration (DL-DCCH)...................................... 15 18. Radio Bearer Reconfiguration Complete (UL-DCCH)....................... 16

Adding Voice over Existing Data

19. CM Service Request..................................................................... 17 20. Initial Direct Transfer (UL-DCCH)................................................. 17 21. Security Mode Command (DL-DCCH)............................................ 18 22. Security Mode Complete (UL-DCCH)............................................. 18 23. Setup......................................................................................... 18


A-2 Mastering HSDPA/HSUPA Signaling

Call Attempt 24. Uplink Direct Transfer (UL-DCCH)................................................. 19 25. Downlink Direct Transfer (DL-DCCH)............................................ 19 26. Call Proceeding........................................................................... 19 27. Radio Bearer Setup (DL-DCCH).................................................... 20 28. Radio Bearer Setup Complete (UL-DCCH) .................................... 22 29. Downlink Direct Transfer (DL-DCCH)............................................ 22 30. Alerting...................................................................................... 22

Call Setup

31. Downlink Direct Transfer (DL-DCCH)............................................ 22 32. Progress..................................................................................... 23 33. Connect......................................................................................23

Call Established

34. Connect Acknowledge................................................................. 23 35. Uplink Direct Transfer (UL-DCCH).................................................23

Releasing Data Call and Maintaining Voice Call

36. Deactivate PDP Context Request.................................................. 23 37. Uplink Direct Transfer (UL-DCCH)................................................. 24 38. Radio Bearer Release Complete (UL-DCCH)................................... 24 39. Signaling Connection Release (DL-DCCH)...................................... 24 40. Disconnect..................................................................................24 41. Uplink Direct Transfer (UL-DCCH)................................................. 24 42. Downlink Direct Transfer (DL-DCCH)............................................ 25 43. Release...................................................................................... 25

Releasing Voice Call – Call End

44. Release Complete....................................................................... 25 45. Uplink Direct Transfer (UL-DCCH)................................................. 25 46. RRC Connection Release (DL-DCCH)............................................. 25 47. RRC Connection Release Complete (UL-DCCH).............................. 26



Scenario The present document captures the Multi service calls which includes 1.Adding voice over existing data 2.Releasing voice and maintaining data 3.Finally releasing data The above scenario outlines the following messages and parameters

a) RRC related message and parameters b) RB setup related messages and parameters c) PDP Context activation

Multi-Service Calls 1.RRC Connection Request (UL-CCCH) Parameters Rb_Id : 0 Initial UE-Identity : tmsi-and-LAI plmn-Identity : MCC , MNC Location area code (LAC) : 52904 (Hex 0xCEA8) Establishment Cause : originating High Priority Signalling Protocol ErrorIndicator : noError 2.RRC Connection Setup (DL-CCCH) Parameters Rb_Id : 0 Initial UE-Identity : tmsi-and-LAI plmn-Identity : MCC , MNC Location area code (LAC) : 52904 (Hex 0xCEA8) rrc-Transaction Identifier : 0 new-U-RNTI SRNC-Identity S-RNTI rrc-State Indicator : cell-DCH capability Update Requirement ue-Radio Capability FDD Update Requirement : True RLC-Info Choice UL-RLC-Mode : ul-UM-RLC-Mode dl-RLC-Mode DL-RLC-Mode : dl-UM-RLC-Mode RB-MappingInfo : UL-Logical Channel Mappings : one Logical Channel UL-Transport Channel Type : dch mac-Logical Channel Priority : 2 DL-Logical Channel Mapping List : DL-Transport Channel Type : dch dch : 31



Logical Channel Identity : 1 polling Info timer Poll : tp140 poll-SDU : sdu1 last Transmission PDU-Poll : True poll Window : pw50 ul-Common Trans ChInfo mode Specific Info : fdd UL-TFCS TFCS : normal TFCI-Signaling Normal TFCI-Signaling Explicit TFCS-Configuration : complete complete Power Offset Information gain Factor Information Gain Factor Information : computed Gain Factors Computed Gain Factors : Gain Factor Information : signaled Gain Factors Signaled Gain Factors Mode Specific Info : fdd Gain Factor BetaC : 11 Gain Factor BetaD : 15 Reference TFC-ID : 0 UL-Add Reconf Trans Ch Info List : ul-Transport Channel Type : dch transport Channel Identity : 31 transport Format Set Transport Format Set : dedicated Trans Ch TFS Dedicated DynamicTF-Info List : rlc-Size : octetModeType1 OctetModeRLC-SizeInfoType1 : sizeType1 sizeType1 : 16 number Of Tb Size List : Number Of Transport Blocks : zero Logical Channel List : all Sizes semistaticTF-Information Channel Coding Type : convolutional convolutional : third rate Matching Attribute : 185 crc-Size : crc16 DL-Common Trans Ch Info mode Specific Info : fdd dl-Parameters : same As UL dl-Add Reconf Trans Ch Info List DL-Add Reconf Trans Ch Info List : dl-Transport Channel Type : dch



dl-transport Channel Identity : 31 power Control Algorithm Power Control Algorithm : algorithm1 algorithm1 : 1 dB (Raw value: 0) scrambling Code Type : long SC scrambling Code : 14350723 spreading Factor : sf64 puncturing Limit : pl1 dl-Common Information dl-DPCH-Info Common cfn Handling : initialise dl-DPCH-Power Control Info mode Specific Info : fdd dpc-Mode : singleTPC power Offset Pilot-pdpdch : 12 spreading Factor And Pilot SF512-AndPilot : sfd128 sfd128 : pb4 position Fixed Or Flexible : fixed mode Specific Info : fdd default DPCH-Offset Value : 177664 Primary CPICH-Info Primary Scrambling Code : 253 dl-DPCH-Info Per RL DL-DPCH-InfoPerRL : fdd PCPICH-Usage For Channel Est : may Be Used dpch-Frame Offset : 24064 DL-Channelisation Code List tpc-Combination Index : 0 3.RRC Connection Setup Complete (UL-DCCH) Parameters Rb_Id : 2 rrc-Transaction Identifier : 0 CN-Domain Identity : cs-domain start-Value cn-Domain Identity : ps-domain start-Value UE-Radio AccessCapability pdcp-Capability lossless SRNS-Relocation Support : False supportForRfc2507 : not Supported rlc-Capability total RLC-AM-Buffer Size : kb150 maximum RLC-Window Size : mws2047 maximum AM-Entity Number : am16 Transport Channel Capability



dl-Trans Ch Capability max No Bits Received : b6400 max Conv Code Bits Received : b6400 turbo Decoding Support Turbo Support : supported supported : b6400 max Simultaneous Trans Chs : e8 max Simultaneous CCTrCH-Count : 1 max Received Transport Blocks : tb32 max NumberOf TFC : tfc128 max Number Of TF : tf64 ul-Tran sCh Capability max No Bits Transmitted : b6400 max Conv Code Bits Transmitted : b6400 turbo Encoding Support Turbo Support : supported supported : b6400 max Simultaneous Trans Chs : e8 mode Specific Info : fdd max Transmitted Blocks : tb32 max Number Of TFC : tfc64 max Number Of TF : tf64 Rf-Capability physical Channel Capability downlink Phys Ch Capability max No DPCH-PDSCH-Codes : 1 max No Phys Ch Bits Received : b9600 supportForSF-512 : False support Of PDSCH : False simultaneous SCCPCH-DPCH-Reception Simultaneous SCCPCH-DPCH-Reception : not Supported Uplink Phys Ch Capability max No DPDCH-Bits Transmitted : b9600 support Of PCPCH : False UE-Multi Mode RAT-Capability multi RAT-Capability List multi mode Capability : fdd security Capability cipheringAlgorithmCap-spare15 : 0 cipheringAlgorithmCap-uea1 : 1 integrityProtectionAlgorithmCap-uia1 : 1 integrityProtectionAlgorithmCap-spare0 : 0 support For UE-GPS-Timing Of Cell Frames : False support For IPDL : False UE-Radio Access Capability Band FDD List : Radio Frequency Band FDD : fdd1900



ue-Powe Class : class3 tx Rx Frequency Separation : mhz190 measurement Capability Compressed Mode Measurement Capability FDD List : Radio Frequency Band FDD : fdd1900 dl-Measurements FDD : True ul-Measurements FDD : True radio Frequency Band FDD : spare3 UE-Power Class : class3 tx Rx Frequency Separation : mhz190 Measurement Capability rlc-Capability-r5-ext physical Channel Capability fdd-hspdsch : supported hsdsch-physical-layer-category : 12 4.Service Request Parameters Service Type Service Type : (0) Signalling Ciphering key sequence number Key sequence : (6) 6 P-TMSI Odd/even indication : (0) Even number of digits Type of identity : (4) TMSI/P-TMSI TMSI/P-TMSI : Hex 0xE0012C5E PDP context status NSAPI(7) : (0) SM state of the corresponding PDP context is PDP-INACTIVE. 5.Initial Direct Transfer (UL-DCCH) Parameters Rb_Id : 3 CN-Domain Identity : ps-domain intra Domain Nas Node Selector version : release99 CN-Type : gsm-Map-IDNNS gsm-Map-IDNNS routing basis : local PTMSI routing parameter initial DirectTransfer-v3a0ext 6.Measurement Control (DL-DCCH) Parameters



Rb_Id : 2 Measurement Control : r3 MeasurementControl-r3 rrc-Transaction Identifier : 0 measurement Identity : 1 Measurement Command : setup setup Measurement Type : intra Frequency Measurement Intra Freq Cell Info List Removed Intra Freq Cell List : remove All Intra Freq Cells New Intra Freq Cell List Intra Freq Cell ID : 0 Cell Info Cell Individual Offset : 0 Mode Specific Info : fdd Primary CPICH-Info Primary Scrambling Code : 253 Read SFN-Indicator : True tx-Diversity Indicator : False intra Freq Meas Quantity filter Coefficient : fc2 mode Specific Info : fdd intra Freq Meas Quantity-FDD : cpich-Ec-N0 Intra Freq Reporting Quantity active Set Reporting Quantities cpich-Ec-N0-reporting Indicator : True cpich-RSCP-reporting Indicator : True pathloss-reporting Indicator : False monitored Set ReportingQuantities ReportCriteria IntraFreqReportCriteria : intraFreqReportingCriteria intraFreqReportingCriteria eventCriteriaList IntraFreqEventCriteriaList : Intra Freq Event : e1a Intra Freq Event : e1b Intra Freq Event : e1c Intra Freq Event : e1d Measurement Report Transfer Mode : acknowledged Mode RLC Periodical Or Event Trigger : event Trigger 7.Security Mode Command (DL-DCCH) Parameters Rb_Id : 2 Integrity Check Info



Message Authentication Code rrc-Message Sequence Number : 1 Security Mode Command : r3 rrc-Transaction Identifier : 0 Security Capability cipheringAlgorithmCap-spare15 : 0 cipheringAlgorithmCap-uea1 : 1 cipheringAlgorithmCap-uea0 : 1 integrityProtectionAlgorithmCap-spare15 : 0 integrityProtectionAlgorithmCap-uia1 : 1 integrityProtectionAlgorithmCap-spare0 : 0 Ciphering Mode Info Ciphering Mode Command : start Restart Start Restart : UEa1 RB-Activation Time Info List : RB-Identity : 1 RLC-Sequence Number : 0 Integrity Protection Mode Command : start Integrity Protection Integrity Prot Init Number Integrity Protection Algorithm : uia1 CN-Domain Identity : PS-domain 8.Security Mode Complete (UL-DCCH) Parameters Rb_Id : 2 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 1 RRC-Transaction Identifier : 0 UL-Integ Protection Activation Info rrc-Message Sequence Number List rb-UL-Ciph Activation Time Info RB-Activation Time Info List : rb-Identity : 1 rlc-Sequence Number : 0 9.Uplink Direct Transfer (UL-DCCH) Parameters Rb_Id : 3 Integrity Check Info Message Authentication Code rrc-Message Sequence Number : 1 CN-Domain Identity : ps-domain nas-Message



10.Activate PDP Context Request Parameters Requested QoS Delay class : (0) Subscribed delay class Reliability class : (0) Subscribed reliability class Peak throughput : (0) Subscribed peak throughput Precedence class : (0) Subscribed precedence Mean throughput : (0) Subscribed mean throughput Traffic Class : (0) Subscribed traffic class Delivery order : (0) Subscribed delivery order Delivery of erroneous SDU : (0) Subscribed delivery of erroneous SDUs Maximum SDU size : (0) Subscribed maximum SDU size Maximum bit rate for uplink : (0) Subscribed Maximum bit rate for downlink : (0) Subscribed Residual BER : (0) Subscribed residual BER SDU error ratio : (0) Subscribed SDU error ratio Transfer delay : (0) Subscribed transfer delay Traffic Handling priority : (0) Subscribed traffic handling priority Guaranteed bit rate for uplink : (0) Subscribed Guaranteed bit rate for downlink : (0) Subscribed Requested PDP address PDP type organisation : (1) IETF allocated address PDP type number : (33) IPv4 address No PDP address included Access point name Access Point Name : isp.cingular Protocol configuration options Configuration protocol : (0) PPP Protocol ID : Protocol ID : CHAP (Hex 0xC223) 11.Radio Bearer Setup (DL-DCCH) Parameters Rb_Id : 2 Integrity Check Info Message Authentication Code rrc-Message Sequence Number : 2 Radio Bearer Setup-r5 activation Time : 52 new-H-RNTI RRC-State Indicator : cell-DCH CN-Domain Identity : ps-domain re-Establishment Timer : useT315 rb-Information Setup List RB-Information Setup List-r5 : rb-Identity : 16



pdcp-Info lossless SRNS-Reloc Support Lossless SRNS-Reloc Support : not Supported pdcp-PDU-Header : absent RLC-InfoChoice-r5 : rlc-Info-r5 UL-RLC-Mode : ul-AM-RLC-Mode ul-AM-RLC-Mode transmission Window Size : tw128 timer RST : tr250 max-RST : rst4 Polling Info timer Poll : tp160 last Transmission PDU-Poll : True last Retransmission PDU-Poll : True poll Window : pw50 DL-RLC-Mode-r5 : dl-AM-RLC-Mode-r5 dl-AM-RLC-Mode-r5 dl-RLC-PDU-size OctetModeRLC-SizeInfoType1 : sizeType2 in Sequence Delivery : True receiving Window Size : rw2047 dl-RLC-Status Info timer Status Prohibit : tsp70 missing PDU-Indicator : True rlc-One Sided ReEst : False RB-MappingInfo-r5 : UL-Logical Channel Mappings : one Logical Channel One Logical Channel ul-Transport Channel Type UL-Transport Channel Type : dch dch : 24 rlc-Size List : configured mac-Logical Channel Priority : 8 DL-LogicalChannelMappingList-r5 : DL-TransportChannelType-r5 : hsdsch hsdsch : 1 RB-Identity : 1 UL-Common Transort Channel Info mode Specific Info : fdd ul-TFCS TFCS : normal TFCI-Signaling Normal TFCI-Signaling Explicit TFCS-Configuration : complete complete Power Offset Information gain Factor Information



Gain Factor Information : computed Gain Factors ul-Add Reconfiguration Transport Channel Info List UL-Add Reconfiguration Transport Channel Info List : ULl-Transport Channel Type : dch transport Channel Identity : 31 Transport Format Set : dedicated Trans Ch TFS Dedicated Trans Ch TFS Dedicated Dynamic TF-Info List : rlc-Size : octetModeType1 Number Of Transport Blocks : one Channel Coding Type : convolutional convolutional : third rate Matching Attribute : 230 crc-Size : crc16 dl-Parameters : dl-DCH-TFCS TFCS : normal TFCI- Signaling DL-Add Reconf Trans Ch Info List-r5 : dl-Transport Channel Type DL-TrCH-Type Id1-r5 : hsdsch tfs-Signalling Mode : hsdsch Harq Info number Of Processes : 6 memory Partitioning : implicit add Or Reconf MAC-d Flow MAC-hs-Add Reconfiguration Queue-List : mac-hs Queue Id : 1 mac-d FlowId : 1 reordering Release Timer : rt50 mac-hs Window Size : mws16 MAC-d-PDU-Size Info-List : mac-d-PDU-Size : 336 mac-d-PDU-Index : 1 UL-Channel Requirement-r5 : ul-DPCH-Info UL-DPCH-Power Control Info-r5 : fdd DPCCH-Power Offset : -98 Power Control Algorithm : algorithm1 delta ACK : 5 delta NACK : 5 ack-NACK-repetition-factor : 1 scrambling Code Type : long SC scrambling Code : 14350723 spreading Factor : sf16 puncturing Limit : pl0-96 mode Specific Phys Ch Info : fdd DL-HSPDSCH-Information HS-SCCH-Info



mode Specific Info : fdd HS-SCCH Channelisation Code Info Measurement-feedback-Info mode Specific Info : fdd measurement Power Offset : 16 feedback-cycle : fc8 cqi-Repetition Factor : 1 delta CQI : 4 dl-Common Information dl-DPCH-Info Common cfn Handling : maintain power Offset Pilot-pdpdch : 12 spreading Factor And Pilot position Fixed Or Flexible : fixed tfci-Existence : False mode Specific Info : fdd mac-hs Reset Indicator: true Primary CPICH-Info Primary Scrambling Code : 253 Serving HSDSCH-RL-indicator : True dl-DPCH-InfoPerRL DL-DPCH-InfoPerRL-r5 : fdd pCPICH-Usage For Channel Est : may Be Used dpch-Frame Offset : 24064 DL-Channelisation Code List : sf-And Code Number tpc-Combination Index : 0 12.Radio Bearer Setup Complete (UL-DCCH) Parameters Rb_Id : 2 Integrity Check Info Message Authentication Code rrc-Message Sequence Number : 2 rrc-Transaction Identifier : 0 13.Radio Bearer Reconfiguration (DL-DCCH) Parameters Rb_Id : 2 Integrity Check Info Message Authentication Code rrc-Message Sequence Number : 3 Radio Bearer Reconfiguration : later-than-r3 rrc-Transaction Identifier : 0 Radio Bearer Reconfiguration-r5 RRC-State Indicator : cell-DCH



RB-Information Reconfiguration List-r5 : rb-Identity : 2 UL-RLC-Mode : ul-AM-RLC-Mode transmission Window Size : tw32 timer RST : tr550 max-RST : rst1 Polling Info timer Poll : tp310 poll-SDU : sdu1 last Transmission PDU-Poll : True last Retransmission PDU-Poll : True poll Window : pw50 DL-RLC-Mode-r5 : dl-AM-RLC-Mode-r5 dl-AM-RLC-Mode-r5 dl-RLC-PDU-size sizeType1 : 16 in Sequence Delivery : True receiving Window Size : rw32 dl-RLC-Status Info timer Status Prohibit : tsp230 missing PDU-Indicator : True DL-HSPDSCH-Information 14.Radio Bearer Reconfiguration Complete (UL-DCCH) Parameters Rb_Id : 2 Integrity Check Info Message Authentication Code rrc-Message Sequence Number : 3 rrc-Transaction Identifier : 0 15.Downlink Direct Transfer (DL-DCCH) Parameters Rb_Id : 3 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 1 RRC-Transaction Identifier : 0 CN-Domain Identity : ps-domain nas-Message 16.Activate PDP Context Accept Parameters TI flag : (1) The message is sent to the side that originates the TI Transaction identifier : 0 Protocol discriminator : (10) GPRS session management messages



Negotiated QoS Delay class : (1) Delay class 1 Reliability class : (3) Unacknowledged GTP and LLC; Acknowledged RLC, Protected Peak throughput : (9) Up to 256 000 octets/s Precedence class : (2) Normal priority Mean throughput : (31) Best effort Traffic Class : (3) Interactive class Delivery order : (2) Without delivery order ('no') Delivery of erroneous SDU : (3) Erroneous SDUs are not delivered ('no') Maximum SDU size : (150) 1500 octets Maximum bit rate for uplink : (151) 2048 kbps Maximum bit rate for downlink : (151) 2048 kbps Residual BER : (7) 1*10E-5 SDU error ratio : (4) 1*10E-4 Transfer delay : (32) 1000 ms Traffic Handling priority : (1) Priority level 1 Guaranteed bit rate for uplink : (16) 16 kbps Guaranteed bit rate for downlink : (64) 64 kbps Radio priority level value : (1) Priority level 1 (highest) Packet data protocol address PDP type organization : (1) IETF allocated address PDP type number : (33) IPv4 address Address : 166.214.152.248 Protocol configuration options 17.Radio Bearer Reconfiguration (DL-DCCH) Parameters Rb_Id : 2 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 5 RRC-Transaction Identifier : 0 Radio BearerReconfiguration-r5 activation Time : 120 rrc-State Indicator : cell-DCH specification Mode : complete RB-Information Reconfig List-r5 : UL-RLC-Mode : ul-AM-RLC-Mode transmission Window Size : tw512 timer RST : tr250 max-RST : rst4 polling Info timer Poll : tp110



last Transmission PDU-Poll : True poll Window : pw50 dl-RLC-Mode-r5 DL-RLC-Mode-r5 : dl-AM-RLC-Mode-r5 dl-AM-RLC-Mode-r5 dl-RLC-PDU-size Octet Mode RLC-Size InfoType1 : sizeType2 part1 : 2 in Sequence Delivery : True receiving Window Size : rw2047 DL-RLC-Status Info timer Status Prohibit : tsp100 missing PDU-Indicator : True RLC-One Sided ReEst : False UL-Common Transport Channel Info mode Specific Info : fdd TFCS : normal TFCI-Signaling Explicit TFCS-Configuration : complete Gain Factor Information : computed Gain Factors UL-Add Reconfiguration Transport Channel Info List Dedicated Dynamic TF-Info List : RLC-Size : octetModeType1 Number Of Tb Size List : crc-Size : crc16 ul-Transport Channel Type : dch transport Channel Identity : 24 Transport Format Set : dedicated Trans Ch TFS Dedicated Trans Ch TFS Dedicated Dynamic TF-Info List rlc-Size : octetModeType1 octetModeType1 Number Of Transport Blocks : zero Logical Channel List : all Sizes Semistatic TF-Information Channel Coding Type : turbo Rate Matching Attribute : 110 crc-Size : crc16 UL-Channel Requirement-r5 : ul-DPCH-Info mode Specific Info : fdd scrambling Code Type : long SC scrambling Code : 14350723 spreading Factor : sf4 puncturing Limit : pl0-72 mode Specific Phys Ch Info : fdd 18.Radio Bearer Reconfiguration Complete (UL-DCCH)



Parameters Rb_Id : 2 Integrity Check Info Message Authentication Code rrc-Message Sequence Number : 4 rrc-Transaction Identifier : 0 1.Adding Voice over existing data 19.CM Service Request Parameters CM service type Service type : (1) Mobile originating call establishment or packet mode connection establishment Mobile station classmark Revision level : (2) Mobile station supporting R99 or later versions of the protocol ES IND : (1) "Controlled Early Classmark Sending" option is implemented in the MS A5/1 : (0) Encryption algorithm A5/1 available RF Power Capability : (3) class 4 PS capability (pseudo-synchronization capability) : (1) PS capability present SS Screening Indicator (defined in TS 24.080) : 1 SM capability (MT SMS pt to pt capability) : (1) Mobile station supports mobile terminated point to point SMS VBS notification reception : (0) No VBS capability or no notifications wanted VGCS notification reception : (0) No VGCS capability or no notifications wanted FC Frequency Capability : (0) (GSM900 only:) The MS does not support E-GSM or R-GSM CM3 : (1) The MS supports options that are indicated in classmark 3 IE LCS VA capability : (0) LCS value added location request notification capability not supported UCS2 : (0) The ME has a preference for the default alphabet (defined in GSM 03.38) over UCS2. SoLSA : (0) The ME does not support SoLSA. CMSP: CM Service Prompt : (0) "Network initiated MO CM connection request" not supported. A5/3 : (0) Encryption algorithm A5/3 not available A5/2 : (1) Encryption algorithm A5/2 available Mobile identity Odd/even indication : (0) Even number of digits Type of identity : (4) TMSI/P-TMSI TMSI/P-TMSI : Hex 0x0125A3D4 20.Initial Direct Transfer (UL-DCCH) Parameters Rb_Id : 3 Integrity Check Info Message Authentication Code rrc-Message Sequence Number : 2 CN-Domain Identity : cs-domain intra Domain Nas Node Selector version : release99 CN-Type : gsm-Map-IDNNS



gsm-Map-IDNNS Routing basis : local PTMSI Routing parameter nas-Message initial Direct Transfer-v3a0ext 21.Security Mode Command (DL-DCCH) Parameters Rb_Id : 2 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 11 RRC-Transaction Identifier : 0 Security Capability cipheringAlgorithmCap-spare15 : 0 cipheringAlgorithmCap-uea1 : 1 integrityProtectionAlgorithmCap-uia1 : 1 integrityProtectionAlgorithmCap-spare0 : 0 Ciphering Mode Info ciphering Mode Command Ciphering Mode Command : start Restart RB-DL-Ciph Activation Time Info RB-Activation Time Info List : rb-Identity : 1 rlc-Sequence Number : 0 Integrity Protection Mode Command : modify dl-Integrity Prot Activation Info Integrity Protection Algorithm : uia1 CN-Domain Identity : cs-domain 22.Security Mode Complete (UL-DCCH) Parameters Rb_Id : 2 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 10 RRC-Transaction Identifier : 0 UL-Integ Prot Activation Info RRC-Message Sequence Number List : rb-UL-Ciph Activation Time Info RB-Activation Time Info List : RB-Identity : 1 RLC-Sequence Number : 0 23.Setup Parameters



Bearer capability 1 Radio channel requirement : (3) The MS supports at least full rate speech version 1 and half rate speech version 1. The MS has a greater preference for full rate speech version 1. Coding standard : (0) GSM standardized coding as described below Transfer mode : (0) circuit mode Information transfer capability : (0) speech Coding : (0) octet used for extension of information transfer capability CTM : (0) CTM text telephony is not supported Speech version indication : (4) GSM full rate speech version 3 Coding : (0) octet used for extension of information transfer capability Speech version indication : (2) GSM full rate speech version 2 Called party BCD number Type of number : (0) Unknown Numbering plan identification : (1) ISDN/telephony numbering plan (Rec. E.164/E.163) Number : 9727575744 CC Capabilities Maximum number of supported bearers : 1 bearer supported PCP : (0) The mobile station does not support the Prolonged Clearing Procedure. DTMF : (1) The mobile station supports DTMF. Maximum number of speech bearers : 0 Call Attempt 24.Uplink Direct Transfer (UL-DCCH) Parameters Rb_Id : 3 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 3 CN-Domain Identity : cs-domain nas-Message 25.Downlink Direct Transfer (DL-DCCH) Parameters Rb_Id : 3 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 2 Downlink DirectTransfer-r3 RRC-Transaction Identifier : 1 CN-Domain Identity : cs-domain nas-Message 26.Call Proceeding Parameters Time: 12:25:04.21



Command Code : 16 Length : 19 Log Code (Hex) : 0x713A 1.25 ms/40 counter (32 kHz clock) : 57 CFN : 16 1.25 ms counter : 60613325 Direction : (0) From network Message length : 2 Transaction identifier : 8 Protocol discriminator : (3) Call control; call related SS messages 27.Radio Bearer Setup (DL-DCCH) Parameters Rb_Id : 2 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 12 RRC-Transaction Identifier : 0 Radio Bearer Setup-r5 activation Time : 132 rrc-State Indicator : cell-DCH RAB-InformationSetupList-r5 : RAB-Identity : gsm-MAP-RAB-Identity gsm-MAP-RAB-Identity : 00000001 cn-Domain Identity : cs-domain re-Establishment Timer : useT314 RLC-InfoChoice-r5 : rlc-Info-r5 UL-RLC-Mode : ul-TM-RLC-Mode ul-TM-RLC-Mode dl-RLC-Mode-r5 DL-RLC-Mode-r5 : dl-TM-RLC-Mode RB-MappingInfo-r5 : UL-Logical Channel Mappings : one Logical Channel UL-Transport Channel Type : dch dch : 8 rlc-Size List : configured mac-Logical Channel Priority : 7 DL-Logical Channel Mapping List-r5 : dl-Transport Channel Type DL-TransportChannelType-r5 : dch dch : 8 UL-Common Trans Ch Info mode Specific Info : fdd ul-TFCS TFCS : normal TFCI-Signalling Explicit TFCS-Configuration : complete



Power Offset Information gain Factor Information Gain Factor Information : computed Gain Factors Computed Gain Factors : 0 Number Of Tb Size List : Number Of Transport Blocks : zero Logical Channel List : allSizes Semistatic TF-Information Channel Coding Type : convolutional convolutional : third rate Matching Attribute : 185 crc-Size : crc16 DL-Add Reconfiguration Transport Channel Info List-r5 : dl-Transport Channel Type DL-TrCH-TypeId1-r5 : dch dch : 31 tfs-Signalling Mode : explicit-config explicit-config Transport Format Set : dedicated Trans Ch TFS rlc-Size : octetModeType1 number Of Tb Size List : dch-Quality Target bler-Quality Value : -2.0 UL-ChannelRequirement-r5 : ul-DPCH-Info ul-DPCH-Info mode Specific Info : fdd scrambling Code Type : long SC scrambling Code : 14350723 spreading Factor : sf16 tfci-Existence : True puncturing Limit : pl0-76 mode Specific Phys Ch Info : fdd DL-DPCH-Info Common cfn Handling : maintain mode Specific Info : fdd power Offset Pilot-pdpdch : 12 spreading Factor And Pilot SF512-And Pilot : sfd128 sfd128 : pb4 position Fixed Or Flexible : fixed tfci-Existence : False dl-Information Per RL-List DL-InformationPerRL-List-r5 : Mode Specific Info : fdd Primary CPICH-Info Primary Scrambling Code : 253



Serving HSDSCH-RL-indicator : True dl-DPCH-InfoPerRL DL-DPCH-InfoPerRL-r5 : fdd PCPICH-Usage For Channel Est : may Be Used dpch-Fram eOffset : 24064 DL-Canalization Code List : SF-And Code Number SF512-AndCodeNumber : sf128 sf128 : 9 tpc-Combination Index : 0 28.Radio Bearer Setup Complete (UL-DCCH) Parameters Rb_Id : 2 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 11 RRC-Transaction Identifier : 0 count-C-Activation Time : 120 29.Downlink Direct Transfer (DL-DCCH) Parameters Rb_Id : 3 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 3 Downlink Direct Transfer-r3 rrc-Transaction Identifier : 2 CN-Domain Identity : cs-domain nas-Message 30.Alerting Parameters Transaction identifier : 8 Protocol discriminator : (3) Call control; call related SS messages Message type : 1 Progress indicator Coding standard : (3) Standard defined for the GSM PLMNS Location : (4) Public network serving the remote user Progress description : (8) In-band information or appropriate pattern now available Call Setup 31.Downlink Direct Transfer (DL-DCCH) Parameters Rb_Id : 3 Integrity Check Info Message Authentication Code



RRC-Message Sequence Number : 4 Downlink Direct Transfer : r3 RRC-Transaction Identifier : 3 CN-Domain Identity : CS-domain nas-Message 32.Progress Transaction identifier : 8 Protocol discriminator : (3) Call control; call related SS messages Message type : 3 Progress indicator Coding standard : (3) Standard defined for the GSM PLMNS Location : (2) Public network serving the local user Progress description : (2) Destination address in non-PLMN/ISDN 33.Connect Parameters Transaction identifier : 8 Protocol discriminator : (3) Call control; call related SS messages Progress indicator Coding standard : (3) Standard defined for the GSM PLMNS Location : (2) Public network serving the local user Progress description : (32) Call is end-to-end PLMN/ISDN Call Established 34.Connect Acknowledge Parameters Transaction identifier : 0 Protocol discriminator : (3) Call control; call related SS messages Message type : 15 35.Uplink Direct Transfer (UL-DCCH) Parameters Rb_Id : 3 Integrity Check Info message Authentication Code RRC-Message Sequence Number : 4 CN-Domain Identity : cs-domain nas-Message 2.Releasing Data call and maintaining Voice call 36.Deactivate PDP Context Request Parameters TI flag : (0) The message is sent from the side that originates the TI



Transaction identifier : 0 Protocol discriminator : (10) GPRS session management messages Message type : 70 SM cause Cause value : (36) Regular deactivation78 Tear down indicator (TDI) flag : (1) Tear down requested 37.Uplink Direct Transfer (UL-DCCH) Parameters Rb_Id : 3 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 4 CN-Domain Identity : cs-domain nas-Message 38.Radio Bearer Release Complete (UL-DCCH) Rb_Id : 2 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 12 RRC-Transaction Identifier : 0 39.Signalling Connection Release (DL-DCCH) Parameters Rb_Id : 2 Message length : 6 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 15 Signalling Connection Release : r3 RRC-Transaction Identifier : 0 CN-Domain Identity : ps-domain 40.Disconnect Parameters Transaction identifier : 0 Protocol discriminator : (3) Call control; call related SS messages Message type : 37 Cause Coding standard : (3) Standard defined for the GSM PLMNS Location : (0) user cause value : (16) Normal call clearing 41.Uplink Direct Transfer (UL-DCCH) Parameters



Rb_Id : 3 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 6 CN-Domain Identity : cs-domain nas-Message 42.Downlink Direct Transfer (DL-DCCH) Parameters Rb_Id : 3 Message length : 10 Integrity Check Info message Authentication Code RRC-Message Sequence Number : 8 Downlink Direct Transfer : r3 RRC-Transaction Identifier : 3 CN-Domain Identity : cs-domain nas-Message 43.Release Parameters Transaction identifier : 8 Protocol discriminator : (3) Call control; call related SS messages Message type : 45

3. Releasing Voice call Call End 44.Release Complete Parameters Transaction identifier : 0 Protocol discriminator : (3) Call control; call related SS messages Message type : 42 45.Uplink Direct Transfer (UL-DCCH) Parameters Rb_Id : 3 Message length : 10 Integrity Check Info message Authentication Code RRC-Message Sequence Number : 7 CN-Domain Identity : cs-domain nas-Message 46.RRC Connection Release (DL-DCCH) Parameters



Rb_Id : 1 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 1 RRC Connection Release : r3 RRC-Transaction Identifier : 0 n-308 : 1 release Cause : normal Event 47.RRC Connection Release Complete (UL-DCCH) Parameters Rb_Id : 1 Message length : 6 Integrity Check Info Message Authentication Code RRC-Message Sequence Number : 1 RRC-Transaction Identifier : 0

Acronyms

Mastering HSDPA/HSUPA Signaling B-1

Acronyms

Acronyms

B-2 Mastering HSDPA/HSUPA Signaling

Acronyms


Acronyms 2.5G Wireless Systems in-between 2nd and 3rd generation 2G Second Generation Wireless Systems 3G Third Generation Wireless Systems 3GPP Third Generation Partnership Project 3GPP2 Third Generation Partnership Project 2 8-PSK 8 Phase Shift Keying 16QAM 16 Quadrature Amplitude Modulation A/D Analog to Digital AA Anonymous Access AAA Authentication, Authorization and Accounting AAL ATM Adaptation Layer AAL2 ATM Adaptation Layer type 2 AAL5 ATM Adaptation Layer type 5 AAS Adaptive Antenna System AC (AuC) Authentication Center ACELP Algebraic Code Excited Linear Prediction ACH Access Channel ACK Acknowledge or Acknowledgement ACN Access Channel Number ARFCN Absolute Radio Frequency Channel Number AGCH Access Grant Channel AGW Access Gateway AI Acquisition Indication AICH Acquisition Indication Channel A-Key Authentication Key ALCAP Access Link Control Application Part AM Acknowledged Mode AM Amplitude Modulation AMC Adaptive Modulation and Coding AMR Adaptive Multi-Rate AN Access Network AP Access Point API Application Program Interface APN Access Point Name ARQ Automatic Repeat request AS Access Stratum ATM Asynchronous Transfer Mode

Acronyms


AuC Authentication Center AUTN Authentication Token AWI Alert with Information BCCH Broadcast Control Channel BCFE Broadcast Control Functional Entity BCH Broadcast Channel BCMCS Broadcast and Multicast Services BER Bit Error Rate BGP Border Gateway Protocol BPSK Binary Phase Shift Keying BS Base Station BSC Base Station Controller BSIC Base Station Identity Code BSS Base Station System BSSMAP Base Station System Mobile Application Part BTS Base Station Transceiver System, Base Transceiver Station BW Bandwidth CAC Connection Admission Control CC Call Control CC Channel Coding CC Conference Call CCCH Common Control Channel CCH Control Channel CCITT Consultative Committee of the Int’l Telegraph and Telephone CCS Common Channel Signaling CCTrCH Coded Composite Transport Channel CD Call Delivery CDMA Code Division Multiple Access CELP Code Excited Linear Predictive CGF Charging Gateway Function CI Cell Identity CID Channel ID CID Circuit Identification CID Connection Identifier CK Ciphering Key CM Connection Management CN Core Network CP Cyclic Prefix CPCH Common Packet Channel CPI Capability Preference Information CPICH Common Pilot Channel CQI Channel Quality Indicators CQICH Channel Quality Indication Channel CQM Core Quality of Service Manager

Acronyms


CQM Core Quality of Service Manager CRC Cyclic Redundancy Check CRNC Controlling Radio Network Controller C-RNTI Cell Radio Network Temporary Identity CS Circuit-Switched CSC Customer Service Center CS-CN Circuit Switched Core Network CSD Circuit-Switched Data CSMA/CA Carrier Sense Multiple Access/Collision Avoidance CSMA/CD Carrier Sense Multiple Access/Collision Detect CSN Communication Services Network CT Call Transfer CTCH Common Traffic Channel CW Call Waiting DCCH Dedicated Control Channel DCH Dedicated Channel DCS Digital Cellular Systems DES Digital Encryption Standard DHCP Dynamic Host Configuration Protocol DL Downlink DNS Domain Name Server DPCCH Dedicated Physical Control Channel DPCH Dedicated Physical Channel DPDCH Dedicated Physical Data Channel DRC Data Rate Control DRNC Drift Radio Network Controller DRNS Drift Radio Network Subsystem D-RNTI Drift RNTI DS Direct Spread DS-CDMA Direct-Sequence Code Division Multiple Access DSCH Downlink Shared Channel DSCP Differentiated Service Code Point DSL Digital Subscriber Line DSSS Direct Sequence Spread Spectrum DTCH Dedicated Traffic Channel DTX Discontinuous Transmission EIR Equipment Identification Register EACH Enhanced Access Channel E-AGCH E-DCH Absolute Grant Channel E-DCH Enhanced – Dedicated Channel EDGE Enhanced Data Rates for Global Evolution E-DPCCH E-DCH Dedicated Physical Control Channel E-DPDCH E-DCH Dedicated Physical Data Channel E-HICH E-DCH HARQ Acknowledgement Indicator Channel

Acronyms


E-TFC E-DCH Transport Format Combination E-TFCI Enhanced Dedicated Channel Transport Format Combination Identifier FACCH Fast Associated Control Channel FACH Forward Access Channel FCC Federal Communications Commission F-CCCH Forward Common Control CHannel FCCH Frequency-Correction Channel FCH Forward Control Channel FCH Frame Control Header FCS Frame Check Sequence FDD Frequency Division Duplex FDM Frequency Division Multiplexing FDMA Frequency Division Multiple Access F-DPCH Fractional Dedicated Physical Channel FEC Forward Error Correction FER Frame Error Rate FHSS Frequency Hopping Spread Spectrum FM Frequency Modulation FN Frame Number FP Frame Protocol FSK Frequency Shift Keying FTP File Transfer Protocol GERAN GSM EDGE Radio Access Network GGSN Gateway GPRS Support Node GI Guard Interval GLR Gateway Location Register GMM GPRS Mobility Management GMSC Gateway Mobile Switching Center GMSK Gaussian Minimum Shift Keying GPRS General Packet Radio Service GPS Global Positioning System GSM Global System for Mobile Communication GSN GPRS Support Node GT Guard Time GTP GPRS Tunneling Protocol GUI Graphical User Interface H-ARQ Hybrid ARQ HDR High Data Rate H-FDD Half-Frequency Division Duplex HLBS Highest Priority Logical Channel Buffer Status HLID Highest Priority Logical Channel ID HLR Home Location Register HO Handover HRPD High Rate Packet Data

Acronyms


HSCSD High-Speed Circuit Switched Data HSDPA High Speed Downlink Packet Access HS-PDSCH High Speed Physical Downlink Shared Channel HSS Home Subscriber Server HTML Hyper Text Markup Language HTTP Hype Text Transfer Protocol H-RNTI High-Speed Radio Network Temporary Identifier HRPD High Rate Packet Data HSCSD High-Speed Circuit Switched Data HSDPA High Speed Downlink Packet Access HS-DPCCH High Speed – Dedicated Physical Control Channel HS-DSCH High Speed – Downlink Shared Channel HS-SCCH High Speed - Shared Control Channel HSS Home Subscriber Server HSUPA High Speed Uplink Packet Access ICI Inter-Carrier Interference IE Information Elements IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IFFT Inverse Fast Fourier Transform IK Integrity Key IKE Internet Key Exchange IMEI International Mobile Equipment Identity IMS IP Multimedia Subsystem IMSI International Mobile Subscriber Identity IMT International Mobile Telecommunication IP Internet Protocol IPSec Internet Protocol Security Ipv4 Internet Protocol version 4 Ipv6 Internet Protocol version 6 IS Interim Standard ISDN Integrated Services Digital Network ISI Inter-Symbol Interference ISM Industrial Scientific Medical ISP Internet Service Provider ITU International Telecommunication Union IWF InterWorking Function kbps Kilobits per second L1 Layer 1 (physical layer) L2 Layer 2 (data link layer) L2CAP Link Level Control and Adaptation Protocol L3 Layer 3 (network layer) LAC Link Access Control LAC Location Area Code

Acronyms


LAI Location Area Identity LAN Local Area Network LAPB Link Access Procedure, Balanced LAPD Link Access Procedure for the D channel LOS Line of Sight LRN Location Routing Number LTU Logical Transport Unit MAC Medium Access Control MAH Mobile Access Hunting MAN Metropolitan Area Network MAP Mobile Access Protocol MAP Mobile Application Part MBMS Multimedia Broadcast Multicast Service MC Messaging Center MC MultiCarrier MCC Mobile Country Code MC-CDMA Multi-Carrier Code Division Multiple Access MCM Multi-Carrier Modulation MCS Modulation and Coding Scheme ME Mobile Equipment MEID Mobile Equipment Identifier MIME Multiple Internet Mail Extensions MIMO Multiple Input Multiple Output MIP Mobile IP MM Mobility Manager/Mobility Management MN Mobile Node MNC Mobile Network Code MN ID Mobile Node Identifier MOU Minutes of Use MS Mobile Station MSB Most Significant Bits MSC Mobile Switching Center MSI Mobile Session Identifier MSID Mobile Station Identifier MSS Mobile Subscriber Station MT Mobile Terminal Mux Multiplex NACK Negative ACK NAI Network Access Identifier N-AMPS Narrowband Advanced Mobile Phone System NAS Non-Access Stratum NAT Network Address Translation NBAP Node B Application Part NDI New Data Indicator

Acronyms


NMSI National Mobile Station Identity NMT Nordic Mobile Telephone NNI Network to Network Interface NSAPI Network layer Service Access Point Identifier OA&M Operations, Administrations and Maintenance ODCH ODMA Dedicated Channel ODMA Opportunity Driven Multiple Access ODTCH ODMA Dedicated Traffic Channel OFDM Orthogonal Frequency Division Multiplexing OFDMA Orthogonal Frequency Division Multiplexing Access OMC Operations and Maintenance Centers OMC-R Operations Maintenance Center - Radio OMC-S Operations Maintenance Center - Switching OS Operating System OSI Open Systems Interconnection OSPF Open Shortest Path First OVSF Orthogonal Variable Spreading Factor P2MP Point-to-Multipoint P2P Point-to-Point PACCH Packet Associated Control Channel PAGCH Packet Access Grant Channel PAN Personal Area Network P-ARQ Packet ARQ PBCCH Packet Broadcast Control Channel PC Power Control PCB Power Control Bit PCCH Packet Common Control Channel PCCH Paging Control Channel PCF Packet Control Function PCH Paging Channel PCM Pulse Code Modulation PCPCH Physical Common Packet Channel PCS Personal Communication Services PCU Packet Control Unit PD Protocol Discriminator PDA Personal Digital Assistant PDC Personal Digital Cellular PDCCH Packet Dedicated Control Channel PDCH Packet Data Channel PDCP Packet Data Convergence Protocol PDN Packet Data Node PDP Packet Data Protocol PDSN Packet Data Serving Node PDTCH Packet Data Traffic Channel

Acronyms


PDU Protocol Data Unit PER Packet Error Rate PHY Physical Layer PIN Personal Identification Number PLMN Public Land Mobile Network PN Pseudo-random Noise PPCH Packet Paging Channel PPDN Public Packet Data Network PPM Pulse Position Modulation PPP P oint-to-Point Protocol PPTP Point-to-Point Tunneling Protocol PRACH Physical Random Access Channel PRI Primary Rate Interface PS Packet-Switched PSDU Protocol Service Data Unit PS-CN Packet Switched-Core Network PSK Phase Shift Keying PSTN Public Switched Telephone Network PTM Point to Multipoint PTP Point to Point P-TMSI Packet TMSI (Temporary Mobile Subscriber Identity) QAM Quadrature Amplitude Modulation QoS Quality of Service QPSK Quadrature Phase Shift Keying RA Routing Area RAB Radio Access Bearer RAC Routing Area Code RACH Random Access Channel RAI Routing Area Identity RAN Radio Access Network RANAP Radio Access Network Application Part RAND Random Number RARP Reverse Address Resolution Protocol RAT Radio Access Technology RATI Random Access Terminal Identifier RB Radio Bearer RBP Radio Burst Protocol REL Release Request RF Radio Frequency RLC Radio Link Control RLC Release Confirm RLP Radio Link Protocol RN Radio Network RNC Radio Network Controller

Acronyms


RNS Radio Network Subsystem RNSAP Radio Network Subsystem Application Part RNTI Radio Network Temporary Identity RRC Radio Resource Control RRI Reverse Rate Indicator RRP Registration Reply RRQ Registration Request RSCP Received Signal Code Power RSN Retransmission Sequence Number Rsp Response SAAL Signaling ATM Adaptation Layer SAC Service Area Code SAC Subscriber Access Channel SACCH Slow Associated Control Channel SAP Service Access Point SAPI Service Access Point Identifier SAR Segmentation and Reassembly Sublayer SC Single Carrier SCCH Supplemental Code Channel SCCP Signaling Connection Control Part SCH Synchronization Channel SDCCH Standalone Dedicated Control Channel SDLC Synchronous Data Link Control SDU Service Data Unit SGSN Serving GPRS Support Node SIB System Independent Building Blocks/System Information Block SID System Identifier SIM Subscriber Identity Module SMS Short Message Service SM-SC Short Message Service Center SMS-GMSC Short Message Service-Gateway MSC SMS-IWMSC Short Message Service-Interworking MSC SMTP Simple Mail Transfer Protocol SN Service Node SNR Signal to Noise Ratio SRNC Serving Radio Network Controller SRNS Serving RNS SS Subscriber Station SS7 Signaling System 7 S-SCM Serving SCM SSD Shared Secret Data SSN Sub System Number SSP Service Switching Point STC Space Time Coding

Acronyms


TB Transport Blocks TBF Temporary Block Flow TC Transport Channel TCAP Transaction Capabilities Application Part TCH Traffic Channel TCH/FS Traffic Channel/Full Rate Speech TCH/HS Traffic Channel/Half Rate Speech TCP Transmission Control Protocol TCP/IP Transmission Control Protocol/Internet Protocol TCS BIN Telephony Control Specification-Binary TD Transmit Diversity TDD Time Division Duplex TDM Time Division Multiplex(ing) TDMA Time Division Multiple Access TE Terminal Equipment TEBS Total E-DCH Buffer Status TEID Tunnel Endpoint Identifier TF Transport Format TFCI Transport Format Combination Indicator TFCS Transport Format Combination Set TFI Transport Format Identifier TFS Transport Format Set TI Transaction Identifier TID Tunnel Identifier TM Traffic Mode TM Transparent Mode TMSI Temporary Mobile Subscriber Identity TP Transmission Protocol TRAU Transcoder and Rate Adaptor Unit TRN Temporary Routing Number TTA Telecommunication Technology Association UARFCN UMTS Absolute Radio Frequency Channel Number UDP User Datagram Protocol UE User Equipment UI User Interface UL Uplink UM Unacknowledged Mode UMTS Universal Mobile Telecommunications System URA User Registration Area URL Uniform Resource Locator U-RNTI UTRAN Radio Network Temporary Identity USIM UMTS Subscriber Identity Module UTRA UMTS Terrestrial Radio Access UTRAN UMTS Terrestrial Radio Access Network

Acronyms


VLR Visitor Location Register VoIP Voice over Internet Protocol VPN Virtual Private Network WLAN Wireless Local Area Networks WLL Wireless Local Loop WPD Wireless Packet Data WSP Wireless Service Provider WWW World Wide Web

References

Mastering HSDPA/HSUPA Signaling C-1

References

References

C-2 Mastering HSDPA/HSUPA Signaling

References

Mastering HSDPA/HSUPA Signaling C-3

References

Standards 1. 3GPP TS 23.002: “Network architecture” 2. 3GPP TS 23.003: “Numbering, addressing and identification” 3. 3GPP TS 23.060: “General Packet Radio Service (GPRS); Service description; Stage 2” 4. 3GPP TS 23.107: “Quality of Service (QoS) concept and architecture” 5. 3GPP TS 23.107: “Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle

mode” 6. 3GPP TS 23.930: “Iu principles” 7. 3GPP TS 24.008: “Mobile radio interface Layer 3 specification; Core network protocols; Stage 3” 8. 3GPP TS 25.133: “Requirements for support of radio resource management (FDD) ” 9. 3GPP TS 25.301: “Radio Interface Protocol Architecture” 10. 3GPP TS 25.302: “Services provided by the physical layer” 11. 3GPP TS 25.304: “User Equipment (UE) procedures in idle mode

and procedures for cell reselection in connected mode” 12. 3GPP TS 25.308: “High Speed Downlink Packet Access (HSDPA),Overall description” 13. 3GPP TS 25.309: “FDD Enhanced Uplink, Overall description ” 14. 3GPP TS 25.321: “Medium Access Control (MAC) Protocol Specification” 15. 3GPP TS 25.322: “Radio Link Control (RLC) Protocol Specification” 16. 3GPP TS 25.323: “Packet Data Convergence Protocol (PDCP) specification” 17. 3GPP TS 25.331: “Radio Resource Control (RRC) Protocol Specification” 18. 3GPP TS 25.410: “UTRAN Iu Interface : General Aspects and Principles” 19. 3GPP TS 25.413: “UTRAN Iu Interface RANAP signaling” 20. 3GPP TS 25.420: “UTRAN Iur Interface: General Aspects and Principles” 21. 3GPP TS 25.423: “UTRAN Iur interface Radio Network Subsystem Application Part

(RNSAP)signaling” 22. 3GPP TS 25.425: “UTRAN Iur interface user plane protocols for Common Transport Channel,

data streams” 23. 3GPP TS 25.427: “UTRAN Iur/Iub interface user plane protocol for DCH data streams” 24. 3GPP TS 25.430: “UTRAN Iub Interface: General Aspects and Principles” 25. 3GPP TS 25.433: “UTRAN Iub interface NBAP signaling” 26. 3GPP TS 25.435: “UTRAN Iub interface user plane protocols for CCH data streams” 27. 3GPP TS 25.808: “FDD enhanced uplink; Physical layer aspects” 28. 3GPP TS 25.858: “Physical layer aspects of UTRA High Speed Downlink Packet Access” 29. 3GPP TS 25.832: “Manifestations of Handover and SRNS relocation” 30. 3GPP TS 25.851: “RAB Quality of Service (QoS) Renegotiation over Iu” 31. 3GPP TS 48.018: “BSS GPRS Protocol (BSSGP) 32. 3GPP TS 25.901: “Network Assisted Cell Change (NACC) from UTRAN to GERAN; Network Side

Aspects”

References

C-4 Mastering HSDPA/HSUPA Signaling

33. 3GPP TS 25.922: “Radio resource management strategies” 34. 3GPP TS 25.931: “UTRAN Functions, examples on signaling procedures” 35. 3GPP TS 29.060: “General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across

the Gn and Gp interface 36. 3GPP TS 33.102: “3G security; Security architecture” 37. 3GPP TS 43.022: “Functions related to Mobile Station (MS) in idle mode and group receive mode 38. 3GPP TS 44.060: “General Packet Radio Service (GPRS),Mobile Station (MS) - Base Station

System (BSS) interface” 39. 3GPP TS 44.118: “Mobile radio interface layer 3 specification, Radio Resource Control (RRC)

protocol, Iu Mode” UMTS Forum Technical Reports 1. A Regulatory Framework for UMTS 2. The Path towards UMTS – Technologies for the Information Society Web Sites 1. Third Generation Partnership Project (3GPP) Homepage – www.3GPP .org 2. European Telecommunications Standards Institute – www.etsi.org 3. UMTS Forum – www.umts-forum.org 4. ITU web site for IMT-2000 - www.itu.int/imt 5. Telecommunication Industries Association – www.tiaonline.org 6. Universal Wireless Communications Consortiums – www.uwcc.org 7. Association of Radio Businesses and Industries (Japan) –

www.arib.or.jp/arib/english/index.html 8. Telecommunication Technologies Association (Korea)– www.tta.or.kr/e_frame4.html 9. CDMA Development Group – www.cdg.org 10. Ericsson web site – www.ericsson.com/wcdma

56545828 Mastering HSDPA HSUPA Signaling Book 1 0 (1)

Documents

generation partnership project

mastering hsdpa hsupa signaling

ovsf codes 5 modulation 16qam

surrounding geographical area

hspriority queue distribution

strict timing relationship

radio link del

signaling radio bearer