UMTS Call Flow

Motorola Confidential Proprietary

UMTS Detailed Call Flows Authors

Félix Bejarano Cebrián (GSD, Advanced Network Development Development Centre)

Status: Approved Document ID: ANDC-MA-00-0.3.4-RQ

Version: 1.01 Date: Novembe Novemberr 4, 2000 Motorola Network Solutions Solutions Sector 1501 W. Shure Drive Arlington Heights, Illinois 60004, USA

Abstract This document describes UMTS Detailed end-end end-end Call Flows.

MOTOROLA CONFIDENTIAL PROPRIETARY This document and the information contained in it is CONFIDENTIAL INFORMATION of Motorola and shall not be used, or published, or disclosed, or disseminated outside of Motorola in whole or in part without the expressed written consent of Motorola. This document contains trade secrets of Motorola. Reverse engineering of any or all of the information in this document is prohibited. The copyright notice does not imply publication of this document .

© 1999, 2000 Copyright 1999, 2000 Motorola, USA

UMTS Call Flows Novembe Novemberr 4, 2000

Approved 1

Motorola: ANDC-MA-00-0.3.4-RQ Version Version 1.01


Release History Version Draft 0.1 Draft 0.2 Draft 0.3

Release Date June 19, 2000 June 27, 2000 July 24, 2000

Author(s) Author(s) Félix Bejarano (ANDC) Félix Bejarano (ANDC) Félix Bejarano (ANDC)

Draft 0.4

August 2, 2000

Félix Bejarano (ANDC)

Draft 0.5 Draft 0.6 Approved 1.0

September September 1, 2000 September September 7, 2000 October October 4, 2000

Félix Bejarano (ANDC) Félix Bejarano (ANDC) Félix Bejarano (ANDC)

Draft 1.01

November November 4, 2000

Félix Bejarano (ANDC)


Approved 2

Change History Original Document Change requests from version 0.1 revision Mobile Terminated Call Establishment, Call Release and Soft Handover sections Inter-frequency FDD to FDD Hard Handover Handover section Update to 3GPP R99 June 2000 versions versions Section 6 included Change requests from version 0.6 revision. This version is now section 2.15 in UTRAN SFRAS version 1.5 Minor cosmetic changes



Table of Contents Release Release History ........................... ........................... ........................... ........................... ...................... 2 Table of Contents Contents........................ ........................ ........................... ........................... ........................... ...................... 3 Table of Figures Figures .......................... ........................... ........................... ........................... ...................... 5 Reference Reference List ......................... ........................... .......................... ........................... ........................... 6 Glossary of terms ........................ ........................... ........................... ........................... ...................... 7 1 Introduction Introduction ........................ ........................... ........................... ........................... .................... 23 1.1 Scope........................ Scope ........................ ........................... .......................... ........................... ......................... 23 1.2 Notation for for Signalling Signalling Procedures Procedures ........................ ........................... ........................... ....... 23 1.3 Explanation Explanation of Terms ........................... .......................... ........................... ......................... 24 2 End-End Call Establishment Establishment .......................... ........................... ........................... .................... 26 2.1 Mobile Originated Call Establishment Establishment ........................ ........................... ........................... .. 26 2.1.1 RRC Conne Connection ction Establishment Establishment procedures procedures ........................... ........................... ........... 27 2.1.2 Iu Signalling Signalling Connection Connection Establishment Establishment procedure procedure ......................... ........................... .. 30 2.1.3 UE-CN Signalling Signalling Messages .......................... ........................... ........................... ....... 31 2.1.4 Common Common ID procedure .......................... ........................... ........................... ................ 32 2.1.5 Security Functions....... Functions................................. .......................... ........................... ........................... ................ 33 2.1.5.1 2.1.5.2 2.1.5.3

2.1.6 2.1.7 2.1.7.1 2.1.7.2 2.1.7.3

Identity Check Procedure......................................................................................................33 Authentication and Key Agreement Agreement procedure ............ ............. ............. ............. ............. ...... 34 Security Mode Setup procedure ............ ............. ............. ............. ............. .............. ............. . 36

MM Connection Connection Established............................................. ........................... ................ 38 RAB Establishment Establishment ........................... ........................... ........................... .................... 39 DCH – DCH RAB Establishment Establishment procedure ............ .............. ............. ............. ............. ........ 39 RACH/FACH RACH/FACH – DCH Establishment Establishment procedure ............ ............. ............. ............. .............. ... 44 RACH/FACH – RACH/FACH Establishment procedure.......................................................46

2.1.8 Service Request Request and PDP Context Activation Activation procedure procedure (PS domain domain only) only) .................. 48 2.1.9 CS Domain Domain Call Setup Setup procedure procedure (CS domain domain only) only) ........................... ......................... 51 2.2 Mobile Terminated Terminated Call Establishment. Establishment........................... .......................... ........................... ......................... 54 2.2.1 Service Request Request and PDP Context Activation Activation procedure procedure (PS domain domain only) only) .................. 54 2.2.2 CS Domain Domain Call Setup Setup procedure procedure (CS domain domain only) only) ........................... ......................... 57 2.2.3 Paging procedures procedures ......................... .......................... ........................... ......................... 59 3 Call Release...... Release................................. ........................... ........................... ........................... ........................... ........... 63 3.1 Mobile Originated Call Release Release......................... ......................... ........................... ........................... ........... 63 3.1.1 PDP Context Deactivation Deactivation procedure (PS domain domain only) only)........................... ........................... .................... 63 3.1.2 Call Clearing procedure (CS domai domain n only) only) ....................... ........................... ................ 65 3.1.3 UTRAN Resources Resources Release Release procedures procedures ........................ ........................... .................... 66 3.1.3.1 Iu Signalling Connection Connection Release procedure ............ .............. ............. ............. ............. ........ 66 3.1.3.2 RRC Connection Release procedure......................................................................................67 3.1.3.3 RAB Release procedure........................................................................................................70 3.1.3.3.1 DCH-DCH RAB Release – Synchronised procedure.......................................................72 3.1.3.3.2 DCH-DCH RAB Release – Unsynchronised procedure...................................................75 3.1.3.3.3 RACH/FACH – DCH RAB Release procedure...............................................................77 3.1.3.3.4 RACH/FACH RACH/FACH – RACH/FACH RAB Release procedure ............. ............. ............. .......... 79

3.2 Mobile Terminated Terminated Call Release............... Release............... ........................... ........................... .................... 80 3.2.1 PDP Context Deactivation Deactivation procedure (PS domain domain only) only)........................... ........................... .................... 80 3.2.2 Call Clearing procedure (CS domai domain n only) only) ....................... ........................... ................ 82 4 Soft Handover..................... Handover..................... ........................... ........................... ........................... .................... 86 4.1 Radio Link Addition Addition (Branch Addition) Addition) ......................... ........................... ......................... 87 4.2 Radio Link Deletion Deletion (Branch Deletion) Deletion) .......................... ........................... ......................... 89 4.3 Radio Link Addition Addition & Deletion Deletion (Branch Addition Addition & Deletion Deletion - simultaneously) simultaneously) ............... 91 5 Hard Handover Handover ........................ .......................... ........................... ........................... ................ 94 UMTS Call Flows Novembe Novemberr 4, 2000

Approved 3



5.1 Inter-frequency FDD to FDD Hard Handover procedure........................................... ...........94 5.1.1 Without Switching in the CN (DCH state) ......................... ........................... ................94 5.1.2 With Switching in the CN (UE connected to two CN nodes, DCH state).......................99 5.1.2.1 5.1.2.2

6

Intra CN node procedure ...................................................................................................... 99 Inter CN node procedure .................................................................................................... 105

Other UMTS procedures.........................................................................................................112 6.1 SRNS Relocation Procedure..............................................................................................112 6.2 Other Mobility Management procedures............................................................................114 6.2.1 Example message flows for the paging procedure.............. ........................... ..............114 6.2.2 Mobility Management of active calls..........................................................................115 6.2.2.1 Soft/hard handover ............................................................................................................. 115 6.2.2.2 Intra-RNS URA Update ..................................................................................................... 116 6.2.2.3 Inter-RNS URA Update without SRNS relocation .............................................................. 116 6.2.2.4 Intra-RNS Cell Update ....................................................................................................... 117 6.2.2.5 Inter-RNS Cell Update without SRNS relocation................................................................ 119 6.2.2.5.1 Without C-RNTI re-allocation nor Physical Channel Reconfiguration............... ............ 120 6.2.2.5.2 With C-RNTI re-allocation or physical channel reconfiguration.................................... 121

Annex A. UMTS Call Flows Proposal.............................................................................................123

UMTS Call Flows November 4, 2000

Approved 4

Motorola: ANDC-MA-00-0.3.4-RQ Version 1.01


Table of Figures Figure 1: Example of signalling procedure notation ........................... ........................... .................... 24 Figure 2: NAS Signalling connections ......................... ........................... ........................... .................... 26 Figure 3: Establishment of the RRC connection on RACH/FACH ............................................................. 27 Figure 4: RRC connection establishment on DCH ........................... ........................... ........................... .. 28 Figure 5: Initial UE message to the CN ........................ ........................... ........................... .................... 30 Figure 6: Direct Transfer ......................... ........................... ........................... ........................... ........... 31 Figure 7: Common ID procedure........................ ........................... ........................... ........................... .. 32 Figure 8: Identity Check Procedure ......................... .......................... ........................... ......................... 33 Figure 9: Authentication and Key Agreement Procedure ........................... ........................... .................... 35 Figure 10: Security Mode Set-up Procedure ........................... ........................... ........................... ........... 36 Figure 11: (CM) Service Accept ........................ ........................... ........................... ........................... .. 38 Figure 12: Radio Access Bearer Establishment - DCH - DCH Establishment - Synchronized ........................ 41 Figure 13: Radio Access Bearer Establishment – RACH/FACH - DCH Establishment – Unsynchronised ....... 45 Figure 14: Radio Access Bearer Establishment – RACH/FACH – RACH/FACH Establishment – Unsynchronised .......................... .......................... ........................... ........................... ................ 47 Figure 15: Service Request and PDP context Activation Initiated by UE Procedures (PS domain only) 49 Figure 16:CS Domain Call Setup (CS domain only) ........................ ........................... ........................... .. 52 Figure 17: Successful Network-Requested PDP Context Activation Procedure ............................................ 55 Figure 18: Successful Mobile Terminated CS Domain Call Establishment .................................................. 58 Figure 19:Paging Procedure for different UE RRC modes ......................... ........................... .................... 61 Figure 20: PDP Context Deactivation Initiated by UE procedure ............................................................... 63 Figure 21: Call Clearing Initiated by UE procedure ......................... ........................... ........................... .. 65 Figure 22: Iu Signalling Connection Release Procedure........................ ........................... ......................... 67 Figure 23: RRC Connection release of a common transport channel........................................................... 68 Figure 24: RRC Connection release of a dedicated channel........................ ........................... .................... 69 Figure 25: RAB Release Procedure ......................... .......................... ........................... ......................... 71 Figure 26: Radio Access Bearer Release - DCH - DCH Release - Synchronised .......................................... 73 Figure 27: Radio Access Bearer Release - DCH - DCH Release - Unsynchronised ....................................... 76 Figure 28: Radio Access Bearer Release – RACH/FACH - DCH Release - Unsynchronised .......................... 78 Figure 29: Radio Access Bearer Release - RACH/FACH - RACH/FACH Release ....................................... 79 Figure 30: PDP Context Deactivation Initiated by SGSN procedure ........................................................... 80 Figure 31: PDP Context Deactivation Initiated by GGSN procedure .......................................................... 81 Figure 32: Call Clearing Initiated by MSC with Release message procedure ............................................... 82 Figure 33: Call Clearing Initiated by MSC with Disconnect message procedure ........................................... 84 Figure 34: Soft Handover - Radio Link Addition (Branch Addition) .......................................................... 88 Figure 35: Soft Handover - Radio Link Deletion (Branch Deletion) ........................................................... 90 Figure 36: Soft Handover - Radio link Addition & Deletion (Branch Addition & Deletion - simultaneously) ... 92 Figure 37: Inter-frequency FDD to FDD Hard Handover via Iur (UE in DCH state) ..................................... 96 Figure 38: Intra CN nodes Hard Handover with switching in the CN (UE connected to two CN nodes, DCH state) ........................................................................................................................................101 Figure 39: Inter CN nodes Hard Handover with switching in the CN (PS domain only, UE in DCH state) .....107 Figure 40: SRNS Relocation procedure (UE connected to two CN nodes, DCH state) .................................113

Figure 41: Paging message flow over Iu, Iub and Iur ......................... ........................... ...................115 Figure 42: Intra RNS URA Update..................................................................................................116 Figure 43: Inter RNS URA update without SRNS relocation .......................... ........................... ......117 Figure 44: Intra RNS Cell Update in case SRNC=CRNC............................ ........................... ..........118 Figure 45: Cell Update via Iur (case without C-RNTI re-allocation)........................................... ......120 Figure 46: Inter-RNS cell update via Iur (case with C-RNTI re-allocation) ......................................122


Approved 5



Reference List [1]

23.060 version 3.4.0 (2000-07):

General Packet Radio Service (GPRS); Service Description

[2]

23.108 version 3.2.0 (2000-03):

Mobile radio interface layer 3 specification; CN Protocols – Stage 2

[3]

23.121 version 3.3.0 (2000-03):

Architectural Requirements for Release 1999

[4]

24.008 version 3.4.1 (2000-07):

Mobile radio interface layer 3 specification; CN Protocols - Stage 3

[5]

25.331 version 3.3.0 (2000-06):

RRC protocol specification

[6]

25.401 version 3.3.0 (2000-06):

UTRAN Overall Description

[7]

25.410 version 3.2.0 (2000-03):

UTRAN Iu Interface: General Aspects and Principles

[8]

25.413 version 3.2.0 (2000-06):

UTRAN Iu Interface RANAP Signalling

[9]

25.420 version 3.1.0 (2000-03):

UTRAN Iur Interface: General Aspects and Principles

[10] 25.423 version 3.2.0 (2000-06):

UTRAN Iur Interface RNSAP Signalling

[11] 25.430 version 3.2.0 (2000-06):

UTRAN Iub Interface: General Aspects and Principles

[12] 25.433 version 3.2.0 (2000-06):

UTRAN Iub Interface NBAP Signalling

[13] 25.931 version 3.0.0 (2000-06):

UTRAN Functions, Examples on Signalling Procedures

[14] 29.060 version 3.5.0 (2000-06):

General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface

[15] 33.102 version 3.5.0 (2000-07):

3G Security; Security Architecture

[16] UTRAN SFRAS ver. 1.5:

UTRAN System Feature Requirements and Architecture Specifications Motorola GSM-3894-SFRAS-045


Approved 6



Glossary of terms Acronym

Definition

3GPP

3rd Generation Partnership Program

AAL

ATM Adaptation Layer

AAL2

ATM Adaptation Layer of type 2

AAL5

ATM Adaptation Layer of type 5

ABT/DT

ATM Block Transfer / Delayed Transmission

ABT/IT

ATM Block Transfer / Immediate Transmission

A&C

Authentication and Ciphering

ACCH

Associated Control Channel

ACD

Automatic Configuration Data

ACFE

Access Control Function Entity

ACP

Adjacent Channel Protection

ACSE

Association Control Service Element

ADM

Add and Drop Multiplexer

AE

Application Entity

AI

Acquisition Indication

AICH

Acquisition Indication Channel

AIS

Alarm Indication Signal

ALCAP

Access Link Control Application Part

AM

Acknowledged Mode (of RLC)

AMR

Adaptive Multi Rate (Transcoder)

AN

Access Network

AOA

Angle Of Arrival

AP

Application Process

APDU

Application Protocol Data Unit

APId

Access Point Identifier

APN

Access Point Name

APS

Automatic Protection Switching

ARIB

Association of Radio Industries and Business

ARQ

Automatic Repeat Request

ASAP

Alarm Severity Assignment Profile

ATC

ATM Transfer Capability

ATM

Asynchronous Transfer Mode


Approved 7



AUG

Administrative Unit Group

AU-n

Administrative Unit n with n being 4 or 3

AUTN

Authentication Token

AWGN

Added White Gaussian Noise

BBE

Background Block Error

BCCH

Broadcast Control Channel

BCH

Broadcast Channel

BER

Bit Error Rate

BIP-X

Bit Interleaved Parity-X

BLER

Block Error Rate

BMC

Broadcast Multicast Controller

BPSK

Binary Phase Shift Keying

BS

Base Station

BSC

Base Station Controller

BSS

Base Station System

BTS

Base Transceiver Station

C-

Control-

CA

Capacity Allocation

CAA

Capacity Allocation Acknowledgement

CAC

Connection Admission Control

CAMEL

Customized Applications for Mobile network Enhanced Logic

CAS

Channel Associated Signalling

CASC

Current Alarm Summary Control

CBR

Constant Bit Rate

CC

Call Control

CCBS

Call Completion Busy Subscriber

CCCH

Common Control Channel

CCH

Control Channel

CCPCH

Common Control Physical Channel

CCTrCH

Coded Composite Transport Channel

CD

Capacity Deallocation (radio context)

CD

Calibration Data (O&M context)

CDA

Capacity Deallocation Acknowledgement

CDMA

Code Division Multiple Access

CDR

Charging Detail Record

CDV

Cell Delay Variation


Approved 8



CDVT

Cell Delay Variation Tolerance

CFN

Connection Frame Number

CID

Channel Identifier

Ck

Cipher Key

CLP

Cell Loss Priority

CM

Configuration Management

CM

Call Management (in e.g. CM Service Request)

CmCH

Common Transport Channel

CMIP

Common Management Information Protocol

CMIS

Common Management Information Service

CMISE

Common Management Information Service Element

CN

Core Network

C-n

Container-n (n=1-4)

COL

Collocated Equipment

CP

Chip Period

CPCH

Common Packet Channel

CPICH

Common Pilot Channel

CPS

Common Part Sublayer

CRC

Cyclic Redundancy Check

CRCI

CRC Indicator

CRC-N

Cyclic Redundancy Check-N

CRNC

Controlling RNC

c-RNTI

RNTI allocated by CRNC

CS

Circuit Switched

CSES

Consecutive Severely Errored Second

CSN

Ciphering Sequence Number

CSUM

Checksum

CTCH

Common Traffic Channel

CTDMA

Code Time Division Multiple Access

CTP

Connection Termination Point (OAM context)

CTP

Common Transport Protocol (Protocol context)

DBR

Deterministic Bit Rate

DC

Dedicated Control (SAP)

DCA

Dynamic Channel Allocation

DCC

Data Communication Channel

DCCH

Dedicated Control Channel


Approved 9



DCH

Dedicated Channel

DCN

Data Communication Network

DHO

Diversity Handover (functional unit)

DL

DownLink

DoCoMo

Do Communication with Mobiles

DPCCH

Dedicated Physical Control Channel

DPCH

Dedicated Physical Channel

DPDCH

Dedicated Physical Data Channel

DRAC

Dynamic Resource Allocation Control

DRNC

Drift RNC

DRNS

Drift RNS

DRX

Discontinuous Reception

DS-CDMA

Direct-Sequence Code Division Multiple Access

DSCH

Downlink Shared Channel

DT

Data Transport

DTCH

Dedicated Traffic Channel

DTX

Discontinuous Transmission

EBER

Excessive Bit Error Ratio

ECASC

Extended Current Summary Alarm Control

EFCI

Explicit Forward Congestion Indication

EFD

Event Forwarding Discriminator

EIR

Equipment Identity Register

EIRP

Equivalent Isotropic Radiated Power

E-OTD

Enhanced OTD

ES

Errored Second

ETSI

European Telecommunication Standardisation Institute

F8

access link encryption function

FACH

Forward Access Channel

FAUSCH

Fast Uplink Signalling Channel

FBI

Feed Back Indicator

FCS

Frame Check Sequence

FDD

Frequency Division Duplex

FDMA

Frequency Division Multiple Access

FEC

Forward Error Correction

FEEB

Far End Errored Block

FEES

Far End Errored Second


Approved 10



FER

Frame Erasure Rate

FESES

Far End Severely Errored Second

FFS

For Further Study

FM

Fault Management

FP

Frame Protocol

FTAM

File Transfer Access Management

FTP

File Transfer Protocol

Gb

Gb interface (between SGSN and BSC)

GC

General Control (SAP)

GCRA

Generic Cell Rate Algorithm

GFR

Guaranteed Rate

GGSN

Gateway GPRS Serving Node

GMM

MM for GPRS services

GMSK

Gaussian Minimum Shift Keying

G-PDU

T-PDU plus GTP header

GPRS

General Packet Radio Service

GPRS-CSI

GPRS CAMEL Subscription Information

GPS

Global Positioning System

GRNC

Generic RNC

GSM

Global System for Mobile communications

GTP

GPRS Tunnelling Protocol

GTP-u

GTP user plane

HCS

Hierarchical Cell Structure

HE

Home Environment

HEC

Header Error Control

HFN

Hyper Frame Number

HHO

Hard Handover

HO

Handover

HOP

High Order Path

HOVC

Higher Order Virtual Container

IBTS

uplink Interference signal power level at Node B

ICB

Inter Carrier Board

ICD

Interface Control Document

ICH

Indicator CHannel

ICI

Inter Carrier Interface

IE

Information Element


Approved 11



IEC

Incoming Error Count

IETF

Internet Engineering Task Force

IK

Integrity Key

IMA

Inverse Multiplexing for ATM

IMEI

International Mobile Equipment Identity

IMEISV

International Mobile Equipment Identity Software Version

IMSI

International Mobile Subscriber Identity (identical for IMUI; used in GSM context)

IMUI

International Mobile User Identity (identical to IMSI; seems to replace IMSI in UMTS context)

INI

Inter Network Interface

IP

Internet Protocol

ISCP

Interference Signal Code Power

ISDN

Integrated Services Digital Network

ISF

Incoming Signal Failure

IS-FL

Idle Slot Forward Link

ISID

Idle Signal Identification

ISO

International Organisation for Standardization

IT

Information Technology

ITU

International Telecommunication Union

Iu

Reference point between Access and Serving Network domains

Iub

Iub interface (between Node B and RNC)

Iu-CS

Iu towards the Circuit Switched-Service Domain of the Core Network

Iu-PS

Iu towards the Packet Switched-Service Domain of the Core Network

Iur

Iur interface (between RNC and RNC)

IWF

Inter Working Function

IWU

Inter Working Unit

JD

Joint Detection

Kbps

kilo-bits per second

KSI

Key Set Identifier

Ksps

kilo-symbols per second

L1

Layer 1 (physical layer)

L2

Layer 2 (data link layer)

L3

Layer 3 (network layer)

L3-CE

Layer 3 Compression Entity

LAC

Link Access Control

LAI

Location Area Identity


Approved 12



LAN

Local Area Network

LAPD

Link Access Protocol for D-channel

LB

Laser Bias

LCAF

Location Client Authorisation Function

LCCF

Location Client Control Function

LCCTF

Location Client Coordinate Transformation Function

LCD

Loss of Cell Delineation (transmission context)

LCD

Low Constrained Delay (traffic context)

LCF

Location Client Function

LCS

Localisation Client Service

LDD

Low Delay Data

LIR

Limited IP Routing entity (in the RNC)

LLC

Link Layer Control

LMT

Local Maintenance Terminal

LNA

Low Noise Amplifier

LOF

Loss of Frame

LOP

Low Order Path

LOP

Loss of Pointer

LOS

Loss of Signal

LPA

Linear Power Amplifier

LSA

Localised Service Area

LSB

Least Significant Bit

LSBF

Location System Billing Function

LSCF

Location System Control Function

LSN

Local Sub Network

LSPF

Location Subscriber Privacy Function

LT

Laser Temperature

MA

Multiple Access

MAC

Medium Access Control

MAC-b

MAC entity handling BCH

MAC-c

MAC entity handling common channels (RACH, FACH)

MAC-d

MAC entity handling dedicated channels (DCH)

MAC-I

Message Authentication Code used for data Integrity of signalling messages

MAC-p

MAC entity handling paging channel (PCH)

MAC-sh

MAC entity handling shared channel (DSCH)

MAHO

Mobile Assisted Handover


Approved 13



MBS

Maximum Burst Size

MCC

Mobile Country Code

MCD

Manual Configuration Data

Mcps

Mega-chips per second

MD

Macro-diversity

ME

Mobile Equipment

MEHO

Mobile evaluated handover

MIB

Management Information Base

MM

Mobility Management

MNC

Mobile Network Code

MNRG

Mobile station Not Reachable for GPRS flag

MNRR

Mobile station Not Reachable Reason

MO

Mobile Originated

MOHO

Mobile Originated Handover

MS

Multiplex Section (transmission context)

MS

Mobile Station (GSM or security context)

MS-AIS

Multiplex Section Alarm Indication Signal

MSB

Most Significant Bit

MSC

Multi-Slot Cell (MPSR context)

MSC

Mobile services Switching Centre (Core Network Context)

MSID

Mobile Station Identifier

MSOH

Multiplex Section Overhead

MSP

Multiplex Section Protection

MS-RDI

Multiplex Section Remote Defect Indication

MS-REI

Multiplex Section Remote Error Indication

MSTE

Multiplex Section Terminating Element

MT

Mobile Terminated (call context)

MT

Mobile Terminal (equipment context)

MTP

Message Transfer Part

MUI

Mobile User Identifier

NAS

Non Access Stratum

NBAP

Node B Application Part

NCSES

Number of Consecutive Severely Errored Second

NDF

New Data Flag

NE

Network Element

NEHO

Network evaluated handover


Approved 14



NEM

Network Element Manager

NMC

Network Management Centre

NNI

Network Node Interface (includes INI and ICI interfaces)

NP

Nectar Pilot

NPC

Network Parameters Control

NRT

Non-Real Time

NSS

Network Sub System

NT

Nectar Telecom

Nt

Notification (SAP)

NW

Network

N-PDU

Network PDU

O&M

Operation and Maintenance

OAM

Operation Administration and Maintenance

OCCCH

ODMA Common Control Channel

ODCCH

ODMA Dedicated Control Channel

ODCH

ODMA Dedicated Channel

ODI

Outgoing Defect Indication

ODMA

Opportunity Driven Multiple Access

ODTCH

ODMA Dedicated Traffic Channel

OEI

Outgoing Error Indication

OFS

Out of Frame Second

OMC

Operation and Maintenance Centre

OOF

Out of Frame

ORACH

ODMA Random Access Channel

OS

Operation System

OSF

Offset Field

OSI

Open System Interconnection

OSL

Optical Signal Level

OTD

Observed Time Difference

OVSF

Orthogonal Variable Spreading Factor

PA

Power Amplifier

PC

Power Control

PCCH

Paging Control Channel

PCF

Positioning Calculation Function

PCH

Paging Channel

PCM

Pulse Code Modulation


Approved 15



PCR

Peak Cell Rate

PDCP

Packet Data Convergence protocol

PDH

Plesiochronous Digital Hierarchy

PDN

Packet Data Network

PDP

Packet Data Protocol

PDU

Protocol Data Unit

PG

Processing Gain

PHY

Physical layer

PhyCH

Physical Channel

PI

Paging Indicator

PICH

Page Indicator Channel

PID

Packet Identification

PJC

Pointer Justification Count

PJE

Pointer Justification Event

Pkg

Packages

PLM

Payload Mismatch

PLMN

Public Land Mobile Network

PM

Performance Management/Performance Monitoring

PMM

MM for PS domain

PN

Pseudo Noise

POH

Path Overhead

PPI

Plesiochronous Physical Interface

PPM

Parts Per Million

PRACH

Physical Random Access Channel

PRCF

Positioning Radio Co-ordination Function

PS

Packet Switched

PSAP

Presentation Service Access Point

PSC

Protection Switch Count

PSD

Protection Switch Duration

PSMF

Positioning Signal Measurement Function

PSN

Plane Switch Node

PSTN

Public Switched Telephone Network

PTE

Path Terminating Element

PVC

Permanent Virtual Connection

P-TMSI

Packet TMSI (equivalent to P-TMUI, used in GPRS context)

P-TMUI

Packet TMUI – (equivalent to P-TMSI, new name for it in the UMTS context)


Approved 16



PTR

Pointer

PUF

Power Up Function

QE

Quality Estimate

QoS

Quality of Service

QPSK

Quadratur e Phase Shift Keying

R0

UTRAN Release 0 (Pilot version)

R1

UTRAN Release 1 (First Commercial version)

RA

Routing Area

RAB

Radio Access Bearer

RAC

Routing Area Code

RAC

Radio Admission Control

RACH

Random Access Channel

RAI

Routing Area Identity (GPRS or Iu-PS context)

RAI

Remote Alarm Indication (transmission context)

RAID

Redundant Array of Independent Disks

RAN

Radio Access Network

RANAP

Radio Access Network Application Part

RAND

Random Challenge

RB

Radio Bearer

RDI

Remote Defect Indication

RDN

Relative Distinguished Name

REI

Remote Error Indication

RF

Radio Frequency

RFC

Request For Comment

RFN

Reference Frame Number

RLC

Radio Link Control

RLCP

Radio Link Control Protocol

RNC

Radio Network Controller

RNCC

Radio Network Connection Control

RNS

Radio Network Subsystem

RNSAP

Radio Network Subsystem Application Part

RNTI

Radio Network Temporary Identity

RP

Radio Processing

RRC

Radio Resource Control

RRM

Radio Resource Management

RS

Regenerator section


Approved 17



RSCP

Received Signal Code Power after despreading

RSOH

Regenerator Section Overhead

RSSI

Received Signal Strength Indicator

RT

Real Time

RU

Resource Unit

RX

Receive

SAAL

Signalling AAL (equivalent to SSCF over SSCOP over AAL5)

SACCH

Slow Associated Control Channel

SAP

Service Access Point

SBR

Statistical Bit Rate

SC

Service Control

SCCH

Synchronization Control Channel

SCCP

Signalling Connection Control Part

SCD

Selective Cell Discard

SCH

Synchronization Channel

SCR

Sustainable Cell Rate

SCTP

Simple Control Transmission Protocol

SD

Supervision Data (context configuration management)

SD

Signal Degrade (context SDH)

SDCCH

Stand-Alone Dedicated Control Channel

SDH

Synchronous Digital Hierarchy

SDU

Service Data Unit

SES

Severely Errored Second

SF

Signal Fail (transmission context)

SF

Spreading Factor (radio context)

SFN

System Frame Number

SG

Study Group

SGSN

Serving GPRS Support Node

SHO

Soft Hand Over

SIM

Subscriber Information Module

SIR

Signal-to-Interference Ratio

SLM

Signal Label Mismatch

SMS

Short Message Service

SN

Serving Network

SN

Sequence Number

SNMP

Simple Network Management Protocol


Approved 18



SOH

Section Overhead

SONET

Synchronous Optical Network

SP

Switching Point

SPA

Signalling Point Accessible

SPI

Signalling Point Inaccessible (SS7 context)

SPI

Synchronous Physical Interface (SDH context)

SPROC

System PROCessor

SRNC

Serving RNC

SRNS

Serving RNS

s-RNTI

RNTI allocated by SRNC

SSA

Signalling Subsystem Accessible

SSADT

Service Specific Assured Data Transfer

SSCF

Service Specific Coordination Function

SSCOP

Service Specific Connection-Oriented Protocol

SSP

Signalling Subsystem Prohibited

SSSAR

Service Specific Segmentation And Reassembly

SSTED

Service Specific Transmission Error Detection

STF

Start Field

STM

Synchronous Transport Module

STM(-N)

Synchronous Transport Module (-N)

STS(-N)

Synchronous Transport Signal (-N)

STTD

Space Time Transmit Diversity

TB

Transport Block

TBC

To Be Confirmed

TBD

To Be Defined

TBF

Transport Block Format

TBS

Transport Block Set

TCH

Traffic Channel

TCM

Tandem Connection Monitoring

TCOH

Tandem Connection Overhead

TCP

Transport Control Protocol

TCP

Transport Control Protocol

TC-RDI

Tandem Connection Remote Defect Indication

TC-REI

Tandem Connection Remote Error Indication

TCT

Tandem Connection Trace

TCTE

Tandem Connection Terminating Element


Approved 19



TDD

Time Duplex Division

TE

Terminal Equipment

TEID

Tunnel Endpoint ID

TFCI

Transport Format Combination Indicator

TFCS

Transport Format Combination Set

TFI

Transport Format Indicator

TFS

Transport Format Set

TFT

Traffic Flow Template

TFTP

Trivial File Transfer Protocol

TIM

Trace Identifier Mismatch

TLLI

Temporary Logical Link Identifier

TM

Transparent Mode (of RLC)

TMN

Telecommunication Management Network

TMSI

Temporary Mobile Subscriber Identity (used in GSM context, equivalent to TMUI)

TMUI

Temporary Mobile User Identity (new name for TMSI in the UMTS context)

TN

Termination Node

TOA or ToA

Time Of Arrival

TOAWE

TOA Window End point

TOAWS

TOA Window Start point

TP

Termination Point

TPC

Transmit Power Control

T-PDU

Original packet, for example an IP datagram, from UE or an external PDN

TR

Threshold Reset

TRX

Transmitter/Receiver

TSID

Test Signal Identification

TSS

Telecommunication Standardization Sector

TTC

Telecommunication Technology Committee

TTI

Time Transmission Interval (Radio Context)

TTI

Trail Trace Identifier (O&M context)

TTP

Trusted Third Party (security context)

TTP

Trail Termination Point (transmission context)

TU

Tributary Unit

TUG

Tributary Unit Group

TUG(-n)

Tributary Unit Group (-n)

TU-n

Tributary Unit-n


Approved 20



TX

Transmit

U-

User-

UARFCN

UTRA Absolute Radio Frequency Channel Cha nnel Number

UAS

Unavailable Second

UBR

Unspecified Bit Rate

UDD

Unconstrained Delay Data

UDP

User Datagram Protocol

UE

User Equipment

UEA

UMTS Encryption Algorithm

UEFN

User Equipment Frame Number

UIA

UMTS Integrity Algorithm

UL

UpLink

UM

Unacknowledged Mode (of RLC)

UMTS

Universal Mobile Telecommunication Telecommunication System

UNEQ

Unequipped

UNI

User to Network Interface Interfa ce

UP

User Plane

UPC

Usage Parameters Control

URA

User Registration Area

USCH

Uplink Shared CHannel

USIM

UMTS Subscriber Subscr iber Identity Module

UTRA

UMTS Terrestrial Radio Access

UTRAN

UMTS Terrestrial Terrest rial Radio Access Network

Uu

Reference point between between User Equipment Equipment and Infrastructur Infra structur e domains, UMTS radio interface

UUI

User to User Indicator

VA

Voice Activity (factor) (fact or)

VBR

Variable Variab le Bit Rate

VC

Virtual Virtua l Channel

VCC

Virtual Virtua l Channel Connection

VCI

Virtual Channel Identifier

VC-n

Virtual Container n (n is 11, 12, 2, 3 or 4)

VLR

Visitor Location Register

VP

Virtual Path

VPC

Virtual Path Connection

VPI

Virtual Path Identifier


Approved 21



W-CDMA

Wideband CDMA

WG

Working Group

WG-n

Working Group (of 3GPP)

WTR

Wait-to-Restore

XMAC-I

eXpected Message Authentication Code used for data Integrity of signalling messages

XOR

eXclusive OR

XPU

AuXiliary Processing Unit

XRES

Expected Response

Yu

Reference point between Serving and Transit Trans it Network domains

Zu

Reference point between Serving and Home Network domains


Approved 22



1 Introduction 1.1 Scope This document describes detailed end-end signalling procedures for UMTS. Only UTRAN will be conside considered red as the Radio Access Access Network; Network; howev however, er, GSM parameters parameters transmitted transmitted within messages messages will be presented in order to document them for a possible UMTS-GSM handover, which is out of the scope of the first phase of this document document according to the document proposal in Annex A. In addition, only FDD solution is considered and only successful pr ocedures will be presented.

1.2 Notation for Signalling Signalling Procedures Procedures Following Following rules ru les will apply: • •

•

•

•

•

•

•

• •

•

Complex Complex signallin s ignalling g procedures pr ocedures may involve several several protocols in different nodes. Messages are always exchanged between nodes, i.e. the sender and the receiver of a message are nodes and not single protocol entities; entities; The protocol entity inside a node that is sending/receiving a message is represented by means of an ellipse, ellipse, containing the protocol pr otocol entity name; name; Each message is numbered, so that a numbered list with explanations can be added below the figure; Message parameters may be specified as shown in Figure 1 only when required for a clear understanding of the procedures; Message parameters listed in explanations are not all parameters, but those of relevance for the given procedure. Procedures within this document do not describe all possible cases, i.e., some assumptions will be made and explained along the document. In principle, signalling is represented by means of continuous arrows; dotted arrows will be used for optional signalling. A description of the relevant actions may be included as shown in Figure 1; The Setup and Release of Iub/Iur and Iu Data Transport Bearer with the ALCAP protocol is represented as shown in Figure 1; The transport channel used by the MAC protocol or the logical channel used by the RLC and RRC protocols pr otocols may be indicated before before the message name as shown in Figure 1.


Approved 23



UE

Node B Dr if t R NS

No de B Serving RNS

RNC Dri ft

RNC Serving

1. RA CH : M e s s a g e

M AC

CN

MAC

[ Pa ra me t ers ]

Action description

2. C CC H : M e s s a g e

RRC

RRC

[ Pa ra me te rs ] 3. Message

NB AP

N B AP

[ Pa ra met er s ] N B AP

4. Message

N B AP

RANAP

[ Pa ra me te rs ]

5. Message

RANAP

[ Pa ra me te rs ] RNSAP

6. Message

RNSAP

[ Pa ra me te rs ]

ALCAP Iub Bearer Setup/Release

ALCAP Iur Bearer Setup

Figure 1: Example of si gnalling procedure notation

1.3 Explanation of Terms Term Controlling Radio Network Controller (CRNC)

Drift Radio Network Controller (DRNC)

Generic Radio Network Controller (GRNC) Hard Handover

Iu Iu-CS Iu-PS Iub Iur


Definition A role an RNC can take with respect to a specific set of Node B's. This represents the RNC functions that deal with control of subtending Node Bs. There is only one Controlling RNC for any Node B. The Controlling RNC has the overall control of the logical resources of its node B's. This represents RNC functions that deal with control of functions during soft handover when the RNC is downstream from the serving RNC and has control over at least 1 Node B who has soft handover leg(s). This represents the RNC functions that are not covered by any of the other three types. This also relates to global functions such as transit or ATM functions. This is a category of handover procedures where all the old radio links in the UE are abandoned before the new radio links are activated. Interface reference point between the RNS and the Core Network. (See also Iu-CS and Iu-PS.) Interface between the RNC and the circuit switched side of the Core Network, typically the MSC. Interface between the RNC and the packet switched side of the Core Network, typically the SGSN. Interface between the RNC and the Node B. It is considered as a reference point. Interface between two RNSs. While this interface logically represents a point to point link between RNSs, the physical

Approved 24



Term

Node B Application Part (NBAP) Radio Access Network Application Part (RANAP) Radio Network Subsystem Application Part (RNSAP) Serving Radio Network Controller SRNC) Soft Handover

Softer Handover Universal Mobile Telephone System (UMTS)


Definition realisation may not be a direct link. It is also considered as a reference point. NBAP is used for setting up Radio Access Bearers (RAB) in the Radio Network Layer over the Iub. Radio Network Signalling over the Iu.

Radio Network Signalling over the Iur between the SRNC and DRNC. This represents the RNC functions that are used during an active call or data session. Soft handover is a category of handover procedures where the radio links are added and abandoned in such manner that the UE always keeps at least one radio link to the UTRAN. This typically involves multiple Node Bs. This is a type of soft handover that involves one or more cells of the same Node B. This represents the third generation mobile phone system that incorporates both Wideband CDMA for the FDD mode in the paired spectrum and Time Division – CDMA for the TDD mode in the unpaired spectrum.

Approved 25



2 End-End Call Establishment This clause presents the whole process to establish an end-end call for either CS or PS Core Network domains. This process is made up of different procedures that will be described separately in a time basis. A major distinction will be made between Mobile Originated procedures at calling end and Mobile Terminated procedures at called end.

2.1 Mobile Originated Call Establishment In order to focus on procedures directly related to the call set-up, it is assumed the UE is already attached to the network, but in IDLE mode. At this point, the user wants to establish a call, and then it will initiate procedures for call establishment. First of all, a signalling connection between the UE and the calling CN domain is required for transfer of higher layer (MM, CM) information. This is usually called a NAS signalling connection and refers to a logical connection composed of a RRC connection between UE and UTRAN and a RANAP or Iu signalling connection between UTRAN and CN. An UE has either zero or one RRC connection and either zero or one RANAP connection for every CN domain as shown in Figure 2. At a CM service request to any of the CN service domains, UE will only request establishment of a new signalling connection when no such connection exists towards the applicable CN service domain. UE is said to be in C/P-MM-CONNECTED mode if a signalling connection between UE and respective CS/PS CN is established.

UE

CS-CN

UTRAN

PS-CN

RANAP Connection RRC Connection

RANAP Connection

Figure 2: NAS Signalling connections


Approved 26



2.1.1 RRC Connection Establishment procedures If a RRC connection is already established, UE will use it. However, it is assumed UE is in IDLE mode for both CS and PS CN domains (i.e. CMM-IDLE and PMM-IDLE states), thus there is not even RRC signalling connection (RRC IDLE state) and its establishment is required to carry signalling messages between UE and UTRAN. It is possible to establish it either on a dedicated channel (DCH) or on a common transport channel (FACH/RACH). The former requires more signalling not only for this procedure, but also because a Radio Link Reconfiguration is likely to happen later at RAB assignment. On the other hand, it allows UTRAN to set UE in soft handover state immediately, which is not possible if we use the latter procedure. In release R0, only the case with RRC connection on RACH/FACH is applicable. As soon as both procedures are available, further studies will be required on the field in order to find out which one is optimal. So far, section 2.5.1 of UTRAN SFRAS describes an algorithm so that SRNC may choose between both procedures. The algorithm is based on the “ RRC Connection Establishment Cause” IE that UE sends in step 1 below. After the establishment of the RRC connection, UE will move into RRC-CONNECTED mode. Depending on the transport channel used (DCH or RACH/FACH), UE will be in Cell_DCH state or in Cell_FACH state within RRC-CONNECTED mode. Both cases are described next:

No de B Serving RNS

UE

Serving RN C

1. C C C H ( o n R A C H ) : R R C C o n n e c t i o n RRC

RRC

A l l oc a t e R N T I Select L1 and L2 pa ra met er s 6. C C C H ( o n F A C H ) : R R C C o n n e c t i o n S e t u p

RRC

RRC 7. DC CH ( o n R A C H ) : R R C C o n n ec t i o n S e t u p C o m p l e t e

RRC

RRC

8. DC CH ( o n F A C H ) : M e a s u r e m e n t C o n t r o l

RRC

RRC

Figure 3: Establishment of the RRC connection on RACH/FACH


Approved 27



UE

No de B S e r v i ng R N S

Serving RN C

1. C C C H ( o n R A C H ) : R R C C o n n ec t i o n R e q u es t RRC

RRC

Allocate RNTI Select L1 and L2 pa ra met ers 2. Radio Link Setup Request N B AP

NB AP

Start RX 3. Radio Link Setup Response N B AP

NB AP

4. ALCAP Iub Data Transport Bearer Setup

DCH-FP

5. NodeB-SRNC Data Transport Bearer Sync (FDD only)

DCH-FP

Start TX

RRC

RRC

RRC

6. C C C H ( o n F A C H ) : R R C C o n n e c t i o n S e t u p RRC 7. DC CH (o n DC H) : R R C C o n n e c t i on S e t u p C o m p l e t e RRC

8. DC CH (o n DC H) : Measurement Control RRC

Figure 4: RRC connection establishment on DCH

1. The UE initiates set-up of an RRC connection by sending RRC message RRC Connection Request on CCCH (mapped on RACH). UE starts timer T300. Parameters: Initial UE Identity, Establishment Cause and optionally a Measurement report 2. The SRNC may decide to use either the RACH/FACH or a DCH for this RRC connection. In both cases, it allocates RNTI and radio resources for the RRC connection. • •

When the RRC connection is set-up over RACH/FACH, the next step is step 6. When a DCH is to be set-up, NBAP message Radio Link Setup Request is sent to Node B for establishing the necessary resources for a new Node B Communication Context. Parameters: CRNC Communication Context ID, UL and DL DPCH Information (TFCS, UL Scrambling Code, etc.), DCH Information (general: Payload CRC Presence Indicator, UL FP Mode, ToAWS, ToAWE; specific: DCH ID, DL/UL Transport Format Set, Frame Handling Priority and QE-Selector), DSCH Information (DSCH ID, Transport Format Set, Frame Handling Priority, ToAWS and ToAWE), RL Information (RL ID, C-ID, First RLS Indicator, Frame Offset, Chip Offset, DL Code Information, etc.), and optional Transmission Gap Pattern Sequence Information and Active Pattern Sequence Information IEs. [see REF 25.433 for more details].

Note: UTRAN does not know what type of service is going to be required, so it uses default parameters at this point. That is why the DCH is likely to be reconfigured later at RAB assignment.


Approved 28



3. (DCH case only): Node B allocates resources, starts PHY reception, and responses with NBAP message Radio Link Setup Response. After this message, a communication context is established between Node B and CRNC. Parameters: CRNC Communication Context ID, Node B Communication Context ID, Communication Control Port ID, RL Information Response IEs (RL ID, RL Set ID, UL Interference Level, DCH/DSCH IDs, Transport layer addressing information -AAL2 address, AAL2 Binding Identity for the Iub Data Transport Bearer–, etc.), and optional Criticality Diagnostics. [see REF 25.433 for more details]. 4. (DCH case only): SRNC initiates set-up of Iub Data Transport bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to the DCH. The request for set-up of Iub Data Transport bearer is acknowledged by Node B. 5. (DCH case only): Node B and SRNC establish synchronism for the Iub Data Transport Bearer. Then Node B starts DL transmission. (FDD only). 6. Message RRC Connection Setup is sent on CCCH (mapped on FACH) from SRNC to UE, which stops timer T300. Parameters: Initial UE Identity, Activation Time (by default “now”), New U-RNTI and optional New C-RNTI, UTRAN DRX cycle length coefficient, Capability Update Requirement, RB IEs for each signalling radio bearers to setup, TrCH IEs for TrCHs to add or reconfigure, and PhyCH IEs. See TS. 25.331 for more details. 7. UE sends back a RRC Connection Setup Complete message on DCCH to the SRNC. This message is mapped either on RACH or on DCH depending on the decision made at step 2. Parameters: For each concerned CN domain, the CN domain Identity and the Hyper frame number to start in this CN domain. The message shall also include UE IEs (UE radio access capability and UE inter-system capability if requested in the RRC Connection Setup message).

At this point, RRC signalling connection is set up between UE and UTRAN and a UE context is built up in the SRNC. UE is in RRC-CONNECTED mode (either Cell_DCH or Cell_FACH state). UTRAN/UE may initiate from now on any RRC procedure according to UE state. Step 8 is an example procedure UTRAN may want to initiate at this point, i.e., this is a good moment to do it. Step 8 does not affect section 2.1.2 and vice versa, i.e., these procedures can be done at the same time. 8. SRNC sends RRC Measurement Control message in order to modify or to release measurement requests already configured by the System Information message, and in order to setup measurement request not configured by the System Information message. Parameters: Measurement Identity Number, Measurement Command, Measurement Reporting Mode (optional), Additional Measurements Lists (optional) and CHOICE Measurement Type (depending on the command).


Approved 29



2.1.2 Iu Signalling Connection Establishment procedure Once the RRC connection for signalling has been set up, the UE can use it to send a signalling establishment request to the required CN domain as shown in Figure 5. The content of these messages depends on the CN domain involved. So, we have to distinguish between CS and PS for the initial NAS message for a call set-up. - CS domain: for a GSM based CN (MSC), UE sends a CM Service Request message and starts timer T3230. Parameters: Mobile Identity (according to section 10.5.1.4 in [Ref 24.008]), Mobile Classmark 2, Ciphering Key Sequence Number (CKSN) and CM Service Type (“ mobile originating call establishment” in this example). - PS domain: for a GPRS based CN (SGSN), UE sends a Service Request message and starts timer T3317. Parameters: P-TMSI, Ciphering Key Sequence Number (CKSN) and Service Type (“ signalling” in this example).

The main difference is the Service Type content for each message. For a GSM based CN (CS domain) it is possible to specify that a CM Call Establishment is going to be established. On the other hand, for a GPRS based CN (PS domain) it just indicates there is signalling to be transferred, which in our example will be an “ Activate PDP Context” message. This is a new message for PS domain (i.e. this message does not exist in GPRS) and is specifically referred in standards as “Service Request procedure (UMTS only)” and it is described in section 2.1.8.

UE

RRC

Serving RN C

CN

9. DC CH :Initial Direct Transfer RRC

RANAP

10. Initial UE Message RANAP

Figure 5: Initial UE message to the CN

The description of the messages is the following: 9. UE sends RRC Initial Direct Transfer to SRNC. This message has to be used whenever a new signalling flow is required and it will trigger the establishment of a signalling connection if it does not exist yet, which is the case in this example. A signalling connection comprises one or several signalling flows. Parameters: Flow Identifier (allocated for a particular flow), Initial NAS Message, CN domain identity (it indicates the correct CN node into which the NAS message shall be forwarded) and optionally IE “Measured results”.


Approved 30



Note: When not stated otherwise elsewhere, UE may initiate this procedure also when another procedure is ongoing, and in that case the state of the latter procedure shall not be affected. Likewise, the reception by UTRAN of this message shall not affect the state of any other ongoing RRC procedure, when not stated otherwise elsewhere.

10. If IE “Measured results” is present, SRNC shall extract it. For there is not Iu signalling connection yet in this example, SRNC initiates it and sends the RANAP message Initial UE Message. Parameters: NAS PDU, CN domain indicator (indicating the CN domain towards which this message is sent), the same LAI which was the last LAI indicated to UE by UTRAN, the same RAC which was the last RAC indicated to UE by UTRAN (only for PS domain), the Service Area corresponding to cells from which UE is consuming radio resources and the Global RNC-ID.

At this point, the NAS signalling connection between UE and CN is established and it can be used for NAS message transfer. These messages are UE-CN signalling messages that are transported as a parameter and are not interpreted by UTRAN, as described in section 2.1.3.

2.1.3 UE-CN Signalling Messages As soon as the NAS connection is established, it is possible to transfer NAS messages transparently through UTRAN by means of the Direct Transfer procedures as shown in Figure 6.

UE

Node B Serving RNS

Serving RNC

RRC

A. DCCH : Uplink Direct Transfer

RRC

CN

B. Direct Transfer RANAP

RANAP

C. Direct Transfer RANAP

RRC

D. DCCH : Downlink Direct Transfer

RANAP

RRC

Figure 6: Direct Transfer

A. UE sends RRC Uplink Direct Transfer to S-RNC. Parameters: Flow Identifier (identify current flow), NAS message and optionally IE Measured Results. B. If IE “Measured results” is present, SRNC shall extract it. UTRAN sends RANAP Direct Transfer message to CN without interpretation of NAS message.


Approved 31



Parameters: NAS-PDU and, if message is sent to PS domain, S-RNC shall also add RAC+LAI. C. CN sends RANAP Direct Transfer message to SRNC. Parameters: NAS PDU and SAPI (to enable UTRAN to provide specific service for the transport of the message). D. SRNC sends RRC Downlink Direct Transfer to UE without interpretation of NAS message. Parameters: NAS message and CN domain Identity (to indicate UE which CN domain NAS message is originated from).

After describing these procedures and in order to avoid excessive number of messages in following procedures, all UE-CN signalling messages will be presented from now on as singular UECN messages through UTRAN. The use of Direct Transfer procedures will be indicated before the message name as shown in Figure 8. Note: When not stated otherwise elsewhere, Direct Transfer procedures may be initiated also when another another RRC R RC procedure pr ocedure is ongoing, ongoing, and in that case the latter procedure shall not be affected aff ected..

2.1.4 Common ID procedure procedure The purpose of the Common ID procedure is to allow the SRNC to create a reference between the permanen permanentt NAS UE Identity Identity of a UE and the RRC connec connection tion establishe established d for that UE in order order to coordinate UTRAN paging from either CS or PS domain. The SRNC associates the Permanent identity to the RRC connection of that UE and shall save it for the duration of the RRC connection. So, whenever a paging request is received, SRNC will check if an RRC connection connection exists by means of the Permanent NAS UE Identity (IMSI ).

Serving RN C

RANAP

CN

11. Common ID

RANAP

Figure 7: Comm on ID procedure

11. After having established an Iu signalling connection, and if the Permanent NAS UE identity (i.e. IMSI) is available, the CN shall send a RANAP Common ID message. Parameters: Permanent NAS UE Identity IE (IMSI).

Note: If IMSI is not available at the CN element, Identity Check Procedure is likely to take place and the Common ID procedure should be performed after that. This statement makes sense, however it has not been found yet within 3GPP specifications. On the other hand, in case of an emergency call,


Approved 32



for example, IMSI is not necessary and nor is the Common ID procedure, i.e., it is possible neither IMSI nor Common Common ID proced pr ocedure ure shall be performed. p erformed.

2.1.5 Security Functions (Security functions are described in detail in [Ref 33.102].) It is mandatory to start s tart integrity protection of signalling signalling messages messages by use of “ Security Mode Mode Setup” procedure at each new signalling connection establishment between UE and CN, which is the case for this example. So, the only procedures between UE and CN that are allowed after step 10 and before before the security security mode mode set-up proced procedure ure are the the follow following ing:: •

Identification by a permanent identity (i.e. request for IMSI), and

•

Authentication and Key agreement. agreement.

Depending on the information received on step 10 such as Mobile Identity and CKSN, the network may initiate any of these common security procedures. In this case, for these messages are NAS signalling signalling messages, messages, they they will will be transparen tr ansparently tly transfe tr ansferred rred through UTRAN by means means of Direct Transfer messages as described in 2.1.3.

2.1.5.1 Identity Check Procedure This procedure should be invoked by CN whenever the user cannot be identified by means of a temporary identity sent in step 10 (either A or B). UE shall be ready for this procedure at any time whilst a RRC connection exists (CS domain) or whilst it is attached (PS domain).

UE

Serving RN C

EIR

CN

12. Dir ect Tr ans fer : fer : Identity Request 13. Di rec t T ra ns er : I de de nt nt it it

R es es o ns ns e 14. Check IMEI 15. Check IMEI Ack

Figure 8: Identity Check Procedure

12. CN element (MSC/SGSN) sends NAS Identity Request message and starts timer (T3270 for CS domain; 3370 for PS domain). Parameters: IE Identity Type 1 (CS domain) or IE Identity Type 2 (PS domain), which specifies requested identification parameter. 13. UE responds with NAS Identity Response message. Upon reception, CN stops timer T3270 or 3370. Parameters: IE Mobile Identity as requested. UE may choose to send its IMSI encrypted, though this is FFS. UMTS Call Flows Novembe Novemberr 4, 2000

Approved 33



14. MSC/SGSN may decide decide to check check IMEI against EIR. If so, it sends Check IMEI to EIR. 15. EIR responds with Check IMEI Ack .

2.1.5.2 Authentication and Key Agreement procedure The purpose of this procedure is fourfold: •

To permit the network to check whether whether the t he identity identity provided by UE is acceptable a cceptable or not.

•

To provide parameters enabling UE to calculate a new UMTS ciphering key and a new UMTS integrity key.

•

•

To permit UE to t o authenticate the network. To let the network set the GSM ciphering mode (ciphering/no ciphering) and GSM ciphering algorithm (PS domain only).

For the fourth statement is only applicable to PS domain, this procedure has different parameters and is named differently for each CS and PS domain. It is named Authentication procedure for CS domain and Authentication and ciphering procedure for PS domain. The latter one can be used for either: •

Authentication only.

•

Setting of GSM ciphering mode mode and the GSM ciphering algorithm only. only.

•

Both of the above at the same time.

This procedure is always initiated and controlled by the network, though there is the possibility for UE to reject the network. This procedure is not mandatory at call establishment. Therefore, there is the possibility of unlimited and malicious reuse of compromised UMTS keys. To avoid attacks using compromised keys, USIM contains a mechanism to limit the amount of data that is protected by an access link key set (a cipher key CK and an integrity key IK). This mechanism will ensure that a cipher/integrity key set cannot be reused beyond the limit limit set by the operator. This mechanism consists basically in a counter the UE sends in step 7 (Ciphering hyper frame number). Authentication and Key Agreement procedure is mandatory performed if the counter reaches a maximum value. In addition, Authentication and Key Agreement procedure may be initiated by the network as often as the network operator wishes. It can occur as soon as the identity of the mobile subscriber is known by the VLR/SGSN. In CS domain, UE shall be ready to respond upon an Authentication Request at any time whilst a RRC connection exists. In PS domain, UE shall be ready to respond upon an Authentication and Ciphering Request at any time whilst whilst a PS signalling s ignalling connection connection exists (which includes includes an a n RRC connection). connection). If an authentication procedure is performed during a connection establishment, the new cipher key CK and integrity key IK shall be taken in use in both RNC and UE as part of the security mode negotiation negotiation that follows the authentication procedure (see section section 2.1.5.3). 2.1.5. 3).


Approved 34



UE

Serving RN C

HLR/Auc

CN

16. Send Authentication Info 17. Send AuthenticationInfo Ack 18. Dir ect Tr ans fe r : Authentication (and Ciphering) Request 19. Di rec t Tr ans er: Au t he nt i ca t io n a n d C i h er i n

R es o ns e

Figure 9: Authentication and Key Agreement Procedure

16. If CN element does not have previously stored UMTS Authentication Vector (quintuplets) for UE, a Send Authentication Info message is sent to HLR/AuC. Each quintuplet contains RAND, XRES, AUTN, CK and IK. Originally, all quintuplets are provided by HLR/AuC. Parameter: IMSI. 17. HLR/AuC responds with a send Authentication Info Ack message including an ordered array of quintuplets. 18. ( PS domain) SGSN selects the next in-order quintuplet and sends Authentication and Ciphering Request message to UE. SGSN starts timer T3360. Parameters: Ciphering Algorithm, A&C reference number and, if authentication is to be performed, RAND, AUTN, CKSN. It may also request IMEISV. (CS domain) MSC sends Authentication Request message and starts timer T3260. Parameters: CKSN, RAND and AUTN. 19. ( PS domain) If UE is capable of UMTS only, it shall ignore the Ciphering Algorithm IE in step 17, otherwise it shall store it in order to be used at an inter system change from UMTS to GSM. If UMTS Authentication parameters (RAND, AUTN, CKSN) are included in step 17, USIM in UE verifies AUTN and, if accepted, USIM processes the challenge information and sends Authentication and Ciphering Response message. USIM computes information according to [Ref 33.102] and it results in USIM passing a GPRS UMTS ciphering key, a GPRS UMTS integrity key and a GPRS GSM ciphering key to the ME, which shall overwrite previous keys. Parameters: A&C reference number (the same received in step 17), Authentication Response parameter and, if requested, IMEISV. (CS domain) USIM in UE verifies AUTN and, if accepted, USIM processes the challenge information and sends Authentication Response message. USIM computes information according to [Ref 33.102] and it results in USIM passing a UMTS ciphering key, a UMTS integrity key and a GSM ciphering key to the ME, which shall overwrite previous keys. Parameters: Authentication Response parameter.

Upon reception of the Authentication (and Ciphering) Response, network stops timer T3260 or T3360 and checks the validity of the response. In case authentication is not accepted by the network, it sends Authentication (and Ciphering) Reject and call establishment cannot proceed.


Approved 35



2.1.5.3 Security Mode Setup procedure As stated above, this procedure is mandatory in this example, for a signalling connection has just been established. It starts integrity protection and possible ciphering. User data towards CS domain shall always be ciphered according to the information received from CS domain and user data towards PS with the information received from PS domain. In addition, user data shall always be ciphered with the last received ciphering information and integrity protected with the last received integrity pr otection information. At this point in the call set-up process, UTRAN knows initial UE capability and the ciphering hyper frame number (step 1 and 7) and CN knows UE Classmark 2 (CS domain only) and CKSN (step 10). In addition, if authentication (and ciphering) procedure has been performed, new ciphering and integrity keys (CK and IK) generated there shall be taken in use in both RNC and UE as part of the security mode negotiation.

UE

CN

Serving RN C

Select allowed UIA, UEAs

R A N AP

20. Security Mode Command (UIA, UEA, IK, CK, UE classmark, etc)

RANAP

2 1 . G en er a te FR E SH . St a rt I nt e r i t D ec i h er i n 22. DCCH: Security Mode Command (CN Domain, UIA, UEA, IK, CK, UE classmark, etc) RRC

RRC

23. Control of UE Classmark, Start of Integrity, Verify Message, Start Ciphering

RRC

2 4 . D CC H : S ec u ri t M o de C o m l et e

RRC

25. Verify received message start Ciphering R A N AP

2 6 . Se cu r it

M o de C om l et e

RANAP

Figure 10: Security Mode Set-up Procedure

20. CN node determines which UIAs and UEAs are allowed to be used. Then, CN initiates integrity (and possible also ciphering) by sending RANAP Security Mode Command message. Parameters: Integrity Protection Information (key(s) and permitted algorithms), Key status (new or already used keys) and optionally Encryption Information (key(s) and permitted algorithms). Note: The set of permitted algorithms specified in the Security Mode Command message shall remain applicable for subsequent RAB Assignments and Intra-UTRAN Relocations.

21. SRNC decides which algorithms to use by selecting the first UEA and the first UIA UE/UTRAN capabilities support from the received list. SRNC generates a random value FRESH and initiates downlink integrity protection. If SRNC does not support any UIA in the list, it shall send back a Security Mode Reject message. UMTS Call Flows November 4, 2000

Approved 36



Note: prior to UTRAN initiates a security mode control procedure for control of ciphering and if the UE has radio bearers using RLC-AM or RLC-UM, UTRAN should suspend all radio bearers belonging to the CN domain for which the security mode control procedure is initiated. Signalling radio bearers are also suspended. Further, if the UE has radio bearers using RLC-TM, UTRAN sets the IE “ Activation time for DPCH” in the IE “ Ciphering mode info” to the CFN at which the new ciphering configuration shall become active. When the transmission of the Security Mode Command has been confirmed by RLC, UTRAN should resume all suspended radio bearers.

22. SRNC sends RRC Security Mode Command message. Before sending this message to UE, SRNC generates MAC-I and attaches this information to the message. Parameters: Integrity Check Info, Security Capability (Ciphering and Integrity Protection algorithm capabilities), optional Ciphering Mode Info (optional extra ciphering info as activation time, in case ciphering shall be controlled), optional Integrity Protection Mode Info (which contains UIA and FRESH to be used) and CN Domain Identity (necessary to identify set of keys to be used, i.e. PS or CS domain set of keys). 23. UE checks that UE security capability received is equal to UE security capability sent in initial NAS message (step 10). UE computes XMAC-I on the message received by using the indicated UIA, the stored COUNT-I and the received FRESH parameter. UE verifies the integrity of the message by comparing the r eceived MAC-I with the generated XMAC-I. 24. If all controls are successful, UE sends RRC Security Mode Complete message using the new ciphering if available, and/or the new integrity protection configuration. UE also generates MAC-I for this message. (If any control is unsuccessful, UE should send RRC Security Mode Failure message.) Parameters: Integrity Check Info, Uplink Integrity Protection Activation Info, Radio Bearer Uplink Ciphering Activation Time Info. Note: prior to UE sends back RRC Security Mode Complete message, UE shall suspend (from sequence number on, which are greater than or equal to each radio bearer’s downlink ciphering activation time in the IE Ciphering Mode Info received in step 22) all radio bearers using RLC-AM or RLC-UM that belong to the CN domain indicated in the IE CN Domain Identity received in step 22. Signalling radio bearers are also suspended. When the transmission of the Security Mode Command has been confirmed by RLC, UE shall resume data transmission on any suspended radio bearers.

25. At the reception of the response message, SRNC computes the XMAC-I on the message and verifies data integrity of the message by comparing the received MAC-I with the generated XMAC-I. 26. The transfer of the RANAP Security Mode Complete message from SRNC to CN ends the procedure. Parameters: Chosen Integrity Protection Algorithm and, if ciphering, Chosen Encryption Algorithm. In addition, it may also contain optional Criticality Diagnostics IE.

When UTRAN has received a Security Mode Complete message and the integrity protection has successfully been applied (step 25), UTRAN should continue applying integrity protection on all subsequent messages, though this will not be explicitly said any more. Regarding ciphering, UTRAN shall use: For radio bearers using RLC-AM or RLC-UM:


Approved 37



•

•

The old ciphering configuration for received RLC PDUs with RLC sequence number less than the RLC sequence number indicated in the IE Radio bearer uplink ciphering activation time info sent by UE in step 24. The new ciphering configuration for received RLC PDUs with RLC sequence number greater than or equal to the RLC sequence number indicated in the IE Radio bearer uplink ciphering activation time info sent by UE in step 24.

For radio bearers using RLC-TM: •

The new ciphering configuration for received RLC PDUs at the CFN as indicated in the IE Activation Time for DPCH in the IE Ciphering Mode Info.

2.1.6 MM Connection Established After receiving the first NAS message in step 10, CN may initiate common security functions as described above (Identity Check or Authentication and Ciphering) and shall perform the Security Mode Setup procedure, for this example establishes a new signalling connection. An indication from lower layers that the Security Mode Setup procedure is completed, or reception of a Service Accept message, shall be treated as a service acceptance by the UE. So, if Security Mode Setup procedure is performed, step 27 is not needed, otherwise it is.

UE

Serving RN C

CN

27: Direct Transfer: (CM) Service Accept

Figure 11: (CM) Service Accept

27. CN may send a CM Service Accept message (CS domain) or Service Accept (PS domain) message to UE in response to a Service Request message in order to inform UE of the acceptance of the request.

Timers started in section 2.1.2 shall be stopped now (T3230 for CS domain and T3317 for PS domain), and UE enters MM-CONNECTED mode, i.e., the MM connection is considered to be active. UE can now proceed with its pending UE-CN signalling procedure. As described in section 2.1.3, UE-CN signalling procedures are carried on Direct Transfer Messages transparently through UTRAN and they do not affect any other RRC procedure, unless otherwise stated elsewhere. In this example, the pending UE-CN signalling procedure is that in charge of originating a call, which is a different procedure for either PS or CS domain. For any PS or CS domain examples, it will be necessary to assign a RAB service. However, it is not defined exactly when this assignment should be initiated. So, RAB Establishment procedure is UMTS Call Flows November 4, 2000

Approved 38



described next and will use numbers from 28 up to 47, but its real initialisation time will be discussed later. PS domain originating call procedure is described in section 2.1.8 and CS domain originating call procedure is described in section 2.1.9.

2.1.7 RAB Establishment A Radio Access Bearer (RAB) service provides confidential transfer of data between UE and CN. CN shall translate the received service request to a RAB service, which is characterised by a set of attributes values CN communicates to SRNC in step 28 (this is further described in section 2.10.5 of UTRAN SFRAS). SRNC will set up required radio bearers for a given UE. The procedure within UTRAN depends on the RRC connection UE has established, i.e., RRC on DCH or RRC on RACH/FACH. It is possible to establish a RAB on several channels: RACH/FACH, DSCH and DCH. So, there are at least six possibilities, though it will depend on UE capabilities. Furthermore, a RRC connection reconfiguration (from/to RACH/FACH to/from DCH) is likely to happen depending on channels chosen for RAB assignment (for example, if RAB is established on DSCH, a DCH channel is required and it will probably be used for the RRC connection). SRNC shall decide which channel should be use depending on the received request from CN in step 28. Next sections presents three typical scenarios: DCH RAB establishment when RRC is on DCH; DCH RAB establishment when RRC is on RACH/FACH and RACH/FACH RAB establishment when RRC is on RACH/FACH. Section 2.5.1 of UTRAN SFRAS describes an algorithm so that SRNC may choose between different procedures depending on the combination of services requested. The algorithm is based on the “ RRC Connection Establishment Cause” IE that UE sends in step 1 in section 2.1.1 RRC Connection Establishment procedures. The RAB establishment can be done either in a synchronised or unsynchronised manner. The unsynchronised Radio Link and Radio Bearer procedures are used when there is no need to synchronise the time of switching from an old to a new configuration. This is the case when new TFCs are added or old TFCs are deleted without changing the TFCI values or the parameters values of the TFCs that are maintained. Otherwise the synchronised procedures must be used (See TS 25.331, TS 25.413, TS 25.423, TS 25.433 and TS 25.931 for additional information).

2.1.7.1 DCH – DCH RAB Establishment procedure In this case, an RRC connection on DCH is established. Then, RAB will be also established on a DCH. This case requires more signalling messages than the following ones because a Radio Link Reconfiguration is needed to modify the spreading code of the DCH already established. If there were no individualized TFCs at all, the unsynchronised procedure could be use. However, in this case, for there is already a DCH configured, TFCs within that DCH must be reconfigured now for the required QoS. So, it is necessary to use the synchronised procedure. In addition, it is assumed UE is in soft handover and communicates via two Nodes B. One Node B is controlled by SRNC and the other one is controlled by DRNC. The procedure is depicted in Figure 12. 28. CN translates Service Request received to a RAB service. Then, CN sends RANAP RAB Assignment Request message to SRNC in order to initiate establishment of the RAB. CN


Approved 39



starts timer T RABAssgt. CN may request to establish, release or modify one or several (3GPP allows up to 256) RABs at the same time. The message shall contain a list of RABs to establish or modify with their bearer characteristics and a list of RABs to release. In this example, for simplification, it will be considered only one RAB is going to be established, and for this is the first Request for the UE, there is none RAB to modify or to release. Parameters: For each RAB to be setup or modified, it shall contain the RAB ID, NAS Synchronisation Indication (if provided), RAB parameters ( QoS profile, Allocation/Retention Priority, etc.), User Plane Information (User Plane Mode, User Plane Mode Versions, Transport Layer Address, Iu Transport Association) and if PS domain, it shall also contain for each RAB to setup or modified the PDP Type Information, Data Volume Reporting Indication and DL/UL GTP-PDU and N-PDU sequence numbers. In case any RAB shall be released within this message, the message shall also contain those RABs ID and appropriate Cause IE for the release. Note: UTRAN shall execute the requested RAB configuration. Resources shall be established according to the values of IEs sent within this message and the resource situation, including UE capabilities.

29. (CS domain only) SRNC selects L1, L2 and Iu Data Transport Bearer parameters and initiates Setup of Iu Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iu Data Transport Bearer to the RAB. 30. SRNC requests DRNC to prepare establishment of DCH to carry the RAB by sending a RNSAP Radio Link Reconfiguration Prepare message. Parameters: optional Allowed Queuing Time, optional UL and DL DPCH Information (TFCS, Scrambling Code, etc.), DCH to add Information IEs (general: Payload CRC Presence Indicator, UL FP Mode, ToAWS, ToAWE; specific: DCH ID, TrCh Source Statistics Descriptor, DL/UL Transport Format Set, DL/UL BLER, Allocation/Retention Priority, Frame Handling Priority, QE-Selector and DRAC Control) and RL Information (RL ID, etc.). Within this message SRNC may also reconfigure (add, modify or delete) any other DCH it has with DRNC [see REF 25.423 for more details]. 31. DRNC shall reserve necessary resources for the new configuration of the Radio Link(s) according to the parameters given in step 30. So, it requests its Node B to prepare establishment of DCH to carry the RAB by sending a NBAP Radio Link Reconfiguration Prepare message (it is really sent by CRNC). Parameters: Node B Communication Context ID, optional UL and DL DPCH Information (TFCS, UL Scrambling Code, etc.), DCH to add Information (general: Payload CRC Presence Indicator, UL FP Mode, ToAWS, ToAWE; specific: DCH ID, DL/UL Transport Format Set, Frame Handling Priority and QE-Selector), RL Information (RL ID and optional DL Code Information as IE FDD DL Channelisation Code Number or the DL Scrambling Code), and optional Transmission Gap Pattern Sequence Information. Within this message DRNC may also reconfigure any other DCH and/or DSCH it has with concerned Node B [see REF 25.433 for more details]. 32. SRNC requests its Node B to prepare establishment of DCH to carry the RAB by sending a NBAP Radio Link Reconfiguration Prepare message (it is really sent by CRNC). Parameters: Node B Communication Context ID, optional UL and DL DPCH Information (TFCS, UL Scrambling Code, etc.), DCH to add Information (general: Payload CRC Presence Indicator, UL FP Mode, ToAWS, ToAWE; specific: DCH ID, DL/UL Transport Format Set, Frame Handling Priority and QE-Selector), RL Information (RL ID and optional DL Code Information as IE FDD DL Channelisation Code Number or the DL Scrambling Code), and


Approved 40



optional Transmission Gap Pattern Sequence Information. Within this message DRNC may also reconfigure any other DCH and/or DSCH it has with concerned Node B [see REF 25.433 for more details]. 33. Node B controlled by DRNC shall reserve necessary resources for the new configuration of the Radio Link(s) according to the parameters given in step 31. If this is possible, Node B notifies CRNC that the preparation is ready by sending a NBAP Radio Link Reconfiguration Ready message. Parameters: CRNC Communication Context ID, RL Information Response (RL ID and DCH Information Response IEs for DCHs to be Added and any other modified channel - DCH ID, Binding ID, Transport Layer Address -), and optionally IE Criticality diagnostics.

UE

N o de B Dr if t R NS

No de B Serving RNS

Drift RNC

Serving RN C

RANAP

CN

28. RAB Assignment Request

RANAP

[Establishment] Select L1, L2 and Iu Data Trans ort Bearer arameters

30. Radio Link Reconfiguration Prepare RNSAP

29. ALCAP Iu Data Transport Bearer Setup No t re qu ir ed to wa rd s PS domain

RNSAP N B AP

[DCH Addition]

3 1 . R a d i o L i n k R e c o n f ig u r a t i o n P r e p a r e N B AP

[DCH Addition]

3 2 . R a d i o L i n k R e c o n f i gu r a t i o n P r e p a r e

N B AP

[ D C H A d d i t i on ] NB AP

N B AP

33 Radio Link Reconfiguration Ready N B AP 34. Radio Link Reconfiguration Ready RNSAP

RNSAP

3 5 . R a d i o L i n k R e c o n f ig u r a t i o n R e a d y

N B AP

N B AP



39. ALCAP Iub Data Transport Bearer Setup 40. NodeB-SRNC Data T ransport Bearer Sync. DCH-FP

DCH-FP DCH-FP 4 1 . R a d i o L i n k R e c o n fi g u r a t i o n Commit RNSAP

RNSAP N B AP

42. Radio Link Reconfiguration Commit N B AP N B AP

43. Radio Link Reconfiguration Commit

N B AP

44. DC CH : Radio Bearer Setup RRC

RRC 45. Apply new transport format set 46. DC CH : R a d i o B e a r e r S e t u p C o m p l e te

RRC

RRC

RANAP

47. RAB Assignment Response

RANAP

Figure 12: Radio Access Bearer Establishment - DCH - DCH Establishment - Synchronized


Approved 41



34. After DRNC receives message in step 33, if the modifications requested in step 30 are allowed by the DRNS, and the DRNS has successfully reserved the required resources for the new configuration of the Radio Link(s), DRNC notifies SRNC that the preparation is ready by sending a RNSAP Radio Link Reconfiguration Ready message. Parameters: RL Information Response (ID and optional UL Maximum and Minimum SIR, which are decided by DRNC), DL Code Information (DL Scrambling Code, FDD DL Channelisation Code Number and optional Transmission Gap Pattern Sequence Information Response), Secondary CCPCH Information (TFCS, TFCI, etc.), DCH Information Response (DCH ID, Binding ID, Transport Layer Address ), DSCH to be Added – and/or Modified Information (DSCH ID, Binding ID, Transport Layer Address, etc.), and optionally IE Criticality Diagnostics. 35. Node B controlled by SRNC shall reserve necessary resources for the new configuration of the Radio Link(s) according to the parameters given in step 32. If this is possible, Node B notifies CRNC that the preparation is ready by sending a NBAP Radio Link Reconfiguration Ready message. Parameters: CRNC Communication Context ID, RL Information Response (RL ID and DCH Information Response IEs for DCHs to be Added and any other modified channel - DCH ID, Binding ID, Transport Layer Address -), and optionally IE Criticality diagnostics. Note: Of course, steps 30 through 35 do not have to be performed in a strict sequential manner, but in the logical order. However, it is more time-efficient to perform step 30 before step 32. In addition, there is no reason to wait for step 29.

36. Non-applicable in this procedure. This step is only applicable for DCH establishment on a RACH/FACH RRC connection (section 2.1.7.2). 37. Non-applicable in this procedure. This step is only applicable for DCH establishment on a RACH/FACH RRC connection (section 2.1.7.2). 38. As soon as SRNC receives Ready message in step 34, it can initiate setup of Iur/Iub Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iur/Iub Data Transport Bearer to DCH. 39. As soon as SRNC receives Ready message in step 35, it can initiate setup of Iub Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to DCH. 40. (FDD only) All involved Nodes B and SRNC establish synchronism for the Iub and Iur Data Transport Bearers.

Note: Iur and Iub Data Transport Bearer are not related and may be setup/release independently.

41. SRNC sends a RNSAP Radio Link Reconfiguration Commit message to DRNC. DRNC shall switch to the new configuration previously prepared at the CFN requested. Parameters: CFN and optional Active Pattern Sequence Information. 42. DRNC sends a NBAP Radio Link Reconfiguration Commit message to its Node B. This message is really sent by CRNC to order the Node B to switch to the new configuration, which has just been prepared for the Radio Link(s) within the Node B, at the CFN requested. Parameters: Node B Communication Context ID, CFN and optional Active Pattern Sequence Information. 43. SRNC (really CRNC) sends a NBAP Radio Link Reconfiguration Commit message to its Node B. This message is really sent by CRNC to order the Node B to switch to the new


Approved 42



configuration, which has just been prepared for the Radio Link(s) within the Node B at the CFN requested. Parameters: Node B Communication Context ID, CFN and optional Active Pattern Sequence Information. 44. SRNC sends an RRC Radio Bearer Setup message back to UE with all necessary parameters for UE to configure itself. IE Activation Time is included to indicate when UE shall switch to the new configuration. Parameters: UE Information Elements (Integrity Check Info, optional Integrity Protection Mode Info, optional Ciphering Mode Info, Activation Time, DRX indicator, UTRAN DRX Cycle Length Coefficient, optional New U-RNTI and optional New C-RNTI), optional CN Information Info, RB Information Elements (optional Signalling RB Information to Setup List, Signalling RB Information to Setup, RAB Information to Setup List, RAB Information for Setup, optional RB Information to be Affected List and RB Information to be Affected), TrCh Information Elements for both UL and DL TrChs, PhyCh Information Elements for both UL and DL Radio Resources. (For more detailed parameters information see [Ref 25.331]).

Note: Again, steps 41 through 43 shall be performed in a logical order. Step 44 does need to wait for steps 41 through 43. In fact, [ref. 25.331] specifies UTRAN shall configure new radio links in any new physical channel configuration and start transmission and reception on the new radio links in order to initiate the RRC Radio Bearer Establishment procedure in step 44.

45. At this point, UE shall act upon all received IE as specified in section 8.5.7 of [Ref 25.331]. UE should turn off the transmitter during the reconfiguration. UE may first release the current physical channel configuration and shall then establish a new physical channel configuration according to the information received in step 44. 46. If reconfiguration succeeds, UE sends RRC Radio Bearer Setup Complete message to SRNC. Parameters: UE Information Elements (Integrity Check Info, optional Uplink Integrity Protection Activation Info and Hyper frame number) and optional RB IE Radio Bearer Uplink Ciphering Activation Time Info. 47. SRNC can now send back to CN a RANAP RAB Assignment Response message. UTRAN may delete any old configuration. Parameters: RABs setup IE as RAB ID, Transport Layer Address (PS domain only) and Iu Transport Association (PS domain only); Data Volume IEs if requested in step 28 by CN (Unsuccessfully Transmitted DL Data Volume and optional Data Volume Reference); RABs queued RAB ID and RABs failed to setup, modify or release RAB ID and appropriate Cause IE. In case RABs to be released, the message shall also contain the Data Volume IEs and if PS domain and the procedure was initiated by UTRAN, the DL/UL GTP-PDU Sequence Numbers. These two parameters will allow SGSN to restore proper values in case the PDP Context is maintained and the RAB is re-established at a later stage. Finally, the message may also contain optional Criticality Diagnostics IE.

Upon reception of the RAB Assignment Response message, CN shall stop timer T RABAssgt only if none of the RABs have been queued by UTRAN. This is the case for this example, and then the RAB Establishment procedure terminates at this point. (For further details on queuing, see [Ref 25.413]). UE is now connected to UTRAN through at least two DCHs, one for the RRC signalling connection and one for the transfer of user data.


Approved 43



2.1.7.2 RACH/FACH – DCH Establishment procedure In this case, an RRC connection on RACH/FACH is established. Then, RAB is going to be established on a DCH. Since this is going to be the first DCH for the concerned UE, a new Communication Context must be created between Node B and CRNC for the UE. So, the Radio Link Setup procedure shall be used. If there were already a communication context, the Radio Link Addition Procedure should be used to add a new Radio Link(s). There is no need to synchronise the time of switching from an old to a new configuration. So, this procedure is done in an unsynchronised manner and requires less signalling. UE cannot be in handover when an RRC connection on RACH/FACH is established. So, DRNC does not participate in this procedure as depicted in Figure 13.

28. CN translates Service Request received to a RAB service. Then, CN sends RANAP RAB Assignment Request message to SRNC in order to initiate establishment of the RAB. CN starts timer T RABAssgt. CN may request to establish, release or modify one or several (3GPP allows up to 256) RABs at the same time. The message shall contain a list of RABs to establish or modify with their bearer characteristics and a list of RABs to release. In this example, for simplification, it will be considered only one RAB is going to be established, and for this is the first Request for the UE, there is none RAB to modify or to release. Parameters: For each RAB to be setup or modified, it shall contain the RAB ID, NAS Synchronisation Indication (if provided), RAB parameters ( QoS profile, Allocation/Retention Priority, etc.), User Plane Information (User Plane Mode and User Plane Mode Versions), Transport Layer Address, Iu Transport Association and if PS domain, it shall also contain for each RAB to setup or modified the PDP Type Information, Data Volume Reporting Indication and DL/UL GTP-PDU and N-PDU sequence numbers. In case any RAB shall be released within this message, the message shall also contain those RABs ID and appropriate Cause IE for the release. Note: UTRAN shall execute the requested RAB configuration. Resources shall be established according to the values of IEs sent within this message and the resource situation, including UE capabilities.

29. (CS domain only) SRNC selects L1, L2 and Iu Data Transport Bearer parameters and initiates Setup of Iu Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iu Data Transport Bearer to the RAB. 36. This step is really performed by CRNC in order to configure new Radio Link(s) within concerned Node B. CRNC sends NBAP Radio Link Setup Request message to Node B. Parameters: CRNC Communication Context ID, UL and DL DPCH Information (TFCS, UL Scrambling Code, etc.), DCH Information (general: Payload CRC Presence Indicator, UL FP Mode, ToAWS, ToAWE; specific: DCH ID, DL/UL Transport Format Set, Frame Handling Priority and QE-Selector), DSCH Information (DSCH ID, Transport Format Set, Frame Handling Priority, ToAWS and ToAWE), RL Information (RL ID, C-ID, First RLS Indicator, Frame Offset, Chip Offset, DL Code Information, etc.), and optional Transmission Gap Pattern Sequence Information and Active Pattern Sequence Information IEs. [see REF 25.433 for more details]. 37. Upon reception of Request message, Node B shall establish the new Radio Links according to the new parameters. If configuration succeeds and Node B has been able to allocate the


Approved 44



required resources, Node B responses to the CRNC with the NBAP Radio Link Setup Response message. After this message, a communication context between Node B and CRNC is established for concerned UE. Parameters: CRNC Communication Context ID, Node B Communication Context ID, Communication Control Port ID, RL Information Response IEs (RL ID, RL Set ID, UL Interference Level, DCH/DSCH IDs, Transport layer addressing information -AAL2 address, AAL2 Binding Identity for the Iub Data Transport Bearer–, etc.), and optional Criticality Diagnostics. [see REF 25.433 for more details].

UE

Node B Drift RNS

Node B Serving RNS

Drift RNC

Serving RNC

RANAP

CN


RANAP

[Establishment]

Select L1, L2 and Iu Data Transport Bearer Parameters

29. ALCAP Iu Data Transport Bearer Setup not required towards PS domain 36. Radio Link Setup Request

NBAP

NBAP

37. Radio Link Setup Response

NBAP

NBAP


RRC

RRC

44. DCCH: Radio Bearer Setup

RRC

46. DCCH: Radio Bearer Setup Complete RRC

RANAP


RANAP

Figure 13: Radio Access Bearer Establishment – RACH/FACH - DCH Establishment – Unsynchronised

39. As soon as SRNC receives Response message in step 37, it can initiate setup of Iub Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to DCH. 44. SRNC sends an RRC Radio Bearer Setup message back to UE with all necessary parameters for UE to configure itself as the new Transport Format Set. IE Activation Time is included to indicate when UE shall switch to the new configuration. Parameters: UE Information Elements (Integrity Check Info, optional Integrity Protection Mode Info, optional Ciphering Mode Info, Activation Time – which is just “now” for unsynchronised procedure-, DRX indicator, UTRAN DRX Cycle Length Coefficient, optional New U-RNTI and optional New C-RNTI), optional CN Information Info, RB Information Elements (optional Signalling RB Information to Setup List, Signalling RB Information to Setup, RAB Information to Setup List, RAB Information for Setup, optional RB Information to be Affected List and RB Information to be Affected), TrCh Information Elements for both UL and DL TrChs, PhyCh Information Elements for both UL and DL Radio Resources. (For more detailed parameters information see [Ref 25.331]). UMTS Call Flows November 4, 2000

Approved 45



46. If configuration succeeds, UE sends RRC Radio Bearer Setup Complete message to SRNC. Parameters: UE Information Elements (Integrity Check Info, optional Uplink Integrity Protection Activation Info and Hyper frame number) and optional RB IE Radio Bearer Uplink Ciphering Activation Time Info. 47. SRNC can now send back to CN a RANAP RAB Assignment Response message. UTRAN may delete any old configuration. Parameters: RABs setup IEs as RAB ID, Transport Layer Address (PS domain only) and Iu Transport Association (PS domain only); Data Volume IEs if requested in step 28 by CN (Unsuccessfully Transmitted DL Data Volume and optional Data Volume Reference); RABs queued RAB ID and RABs failed to setup, modify or release RAB ID and appropriate Cause IE. In case RABs to be released, the message shall also contain the Data Volume IEs and if PS domain and the procedure was initiated by UTRAN, the DL/UL GTP-PDU Sequence Numbers. These two parameters will allow SGSN to restore proper values in case the PDP Context is maintained and the RAB is re-established at a later stage. Finally, the message may also contain optional Criticality Diagnostics IE.

Upon reception of the RAB Assignment Response message, CN shall stop timer T RABAssgt only if none of the RABs have been queued by UTRAN. This is the case for this example, and then the RAB Establishment procedure terminates at this point. (For further details on queuing, see [Ref 25.413]). UE is now connected to UTRAN through at least one DCH for the transfer of user data, and for the RRC signalling connection it still uses the common transport channels (RACH/FACH).

2.1.7.3 RACH/FACH – RACH/FACH Establishment procedure In this case, an RRC connection on RACH/FACH is established. Then, RAB is also going to be established on a common transport channel (RACH/FACH). So, this procedure requires even less signalling than the previous procedure. Since there is no reconfiguration of common transport channels formats, this procedure is done in an unsynchronised manner. UE cannot be in handover when an RRC connection on RACH/FACH is established. So, DRNC does not participate in this procedure as depicted in Figure 14.

28. CN translates Service Request received to a RAB service. Then, CN sends RANAP RAB Assignment Request message to SRNC in order to initiate establishment of the RAB. CN starts timer T RABAssgt. CN may request to establish, release or modify one or several (3GPP allows up to 256) RABs at the same time. The message shall contain a list of RABs to establish or modify with their bearer characteristics and a list of RABs to release. In this example, for simplification, it will be considered only one RAB is going to be established, and for this is the first Request for the UE, there is none RAB to modify or to release. Parameters: For each RAB to be setup or modified, it shall contain the RAB ID, NAS Synchronisation Indication (if provided), RAB parameters ( QoS profile, Allocation/Retention Priority, etc.), User Plane Information (User Plane Mode, User Plane Mode Versions, Transport Layer Address, Iu Transport Association) and if PS domain, it shall also contain for each RAB to setup or modified the PDP Type Information, Data Volume Reporting Indication and DL/UL GTP-PDU and N-PDU sequence numbers. In case any RAB shall be released within this message, the message shall also contain those RABs ID and appropriate Cause IE for the release. UMTS Call Flows November 4, 2000

Approved 46



Note: UTRAN shall execute the requested RAB configuration. Resources shall be established according to the values of IEs sent within this message and the resource situation, including UE capabilities.

UE

Node B Drift RNS

Node B Serving RNS

Drift RNC

Serving RNC

RANAP

CN


RANAP

[Establishment]

29. ALCAP Iu Data Transport Bearer Setup not required towards PS domain RRC

RRC

44. DCCH: Radio Bearer Setup RRC

46. DCCH : Radio Bearer Setup Complete RRC

RANAP


RANAP

Figure 14: Radio Access Bearer Establishment – RACH/FACH – RACH/FACH Establishment – Unsynchronised

29. (CS domain only) SRNC selects L1, L2 and Iu Data Transport Bearer parameters and initiates Setup of Iu Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iu Data Transport Bearer to the RAB. 44. SRNC sends an RRC Radio Bearer Setup message back to UE with all necessary parameters for UE to configure itself as the new Transport Format Set. IE Activation Time is included to indicate when UE shall switch to the new configuration. Parameters: UE Information Elements (Integrity Check Info, optional Integrity Protection Mode Info, optional Ciphering Mode Info, Activation Time – which is just “now” for unsynchronised procedure-, DRX indicator, UTRAN DRX Cycle Length Coefficient, optional New U-RNTI and optional New C-RNTI), optional CN Information Info, RB Information Elements (optional Signalling RB Information to Setup List, Signalling RB Information to Setup, RAB Information to Setup List, RAB Information for Setup, optional RB Information to be Affected List and RB Information to be Affected), TrCh Information Elements for both UL and DL TrChs, PhyCh Information Elements for both UL and DL Radio Resources. (For more detailed parameters information see [Ref 25.331]). 46. If configuration succeeds, UE sends RRC Radio Bearer Setup Complete message to SRNC. Parameters: UE Information Elements (Integrity Check Info, optional Uplink Integrity Protection Activation Info and Hyper frame number) and optional RB IE Radio Bearer Uplink Ciphering Activation Time Info. 47. SRNC can now send back to CN a RANAP RAB Assignment Response message. UTRAN may delete any old configuration. Parameters: RABs setup IE as RAB ID, Transport Layer Address (PS domain only) and Iu Transport Association (PS domain only); Data Volume IEs if requested in step 28 by CN (Unsuccessfully Transmitted DL Data Volume and optional Data Volume Reference); RABs queued RAB ID and RABs failed to setup, modify or release RAB ID and appropriate Cause IE. In case RABs to be released, the message shall also contain the Data Volume IEs and if PS domain and the procedure was initiated by UTRAN, the DL/UL GTP-PDU Sequence Numbers. These two parameters will allow SGSN to restore proper values in case the PDP


Approved 47



Context is maintained and the RAB is re-established at a later stage. Finally, the message may also contain optional Criticality Diagnostics IE.

Upon reception of the RAB Assignment Response message, CN shall stop timer T RABAssgt only if none of the RABs have been queued by UTRAN. This is the case for this example, and then the RAB Establishment procedure terminates at this point. (For further details on queuing, see [Ref 25.413]). UE is still connected to UTRAN exclusively through common transport channels (RACH/FACH) for both the transfer of user data and the RRC signalling connection.

2.1.8 Service Request and PDP Context Activation procedure (PS domain only) The purpose of the Service Request procedure is just to transfer the 3G UE from PMM-IDLE to PMM-CONNECTED state so that it can transmit data or signalling. In the call establishment process described in this section, it is assumed this is the first PDP context UE is going to establish and UE is in PMM-IDLE state. So, UE needs to perform the Service Request procedure to enter PMMCONNECTED state before it can activate the PDP context. This procedure is also used by an UE in PMM-CONNECTED state to request resource reservation for active PDP contexts, though this case is not consider in this example (see TS 23.060 for further details). This is a new procedure needed for PS domain in UMTS (i.e. this procedure does not exist in GPRS) and is specifically referred in standards as “Service Request procedure (UMTS only)” within mobility management procedures for GPRS services (i.e., PS domain). First of all, UE must establish an RRC connection as described in steps 1 through 7. After that, a NAS Service Request message is received by SGSN inside RANAP Initial UE Message in step 10. Service Type within NAS message can take either of the following values: signalling, data or paging response: •

•

•

Signalling: whenever UE has any signalling message to be sent to the network in PMMIDLE mode (i.e., no secure PS signalling connection has been established). Data: whenever UE, either in PMM-IDLE or PMM-CONNECTED mode, has pending user data to be sent and no RAB is established for the PDP context. Paging response: whenever this procedure is triggered by the reception of a paging request for PS domain from the network in PMM-IDLE mode.

Service Type is set to signalling in our call set-up example. After receiving this message, SGSN may initiate common security functions as described above (Identity Check or Authentication and Ciphering) and shall perform the Security Mode Setup procedure. An indication from lower layers that the Security Mode Setup procedure is completed, or reception of a Service Accept message, shall be treated as a service acceptance by the UE (step 27). The timer T3317 started in step 10 shall be stopped, and UE enters GMM-REGISTER state and PMM-CONNECTED mode. Service Request is now finished (steps 1 through 27) and UE can now proceed with its pending UE-SGSN signalling procedure. As described in section 2.1.3, UE-CN signalling procedures are carried on Direct Transfer Messages transparently through UTRAN and they do not affect any other RRC procedure, unless otherwise stated elsewhere. UMTS Call Flows November 4, 2000

Approved 48



The signalling procedure to be performed in this example is the PDP Context Activation procedure, which will establish a PDP context between UE and core network for a specific QoS on a specific NSAPI. This procedure is used to activate the first PDP context for a given PDP address and APN, whereas all additional contexts associated to the same PDP address and APN are activated with the Secondary PDP Context Activation procedure [Ref 23.060].

48. (PS domain only) UE sends a NAS Activate PDP Context Request message to SGSN and starts timer T3380. Parameters: Requested NSAPI, Requested LLC SAPI, Requested QoS, Requested PDP address (static or dynamic and PDP Type), and optionally APN (for a certain external network and/or to select a service) and/or Protocol Configuration Options (which will be sent transparently through the SGSN). 28. RAB setup is done by any of the RAB Assignment Procedures described in section 2.1.7. It is clear this procedure has to be performed after step 48, for CN needs the requested QoS. However it seems following steps (50 and 51) to activate a PDP context in the GGSN do not clash with the RAB establishment procedure, i.e., both procedures may be done in parallel. It is FFS within the UMTS team how a changed of QoS by GGSN affects RAB. 49. (PS domain only) If BSS trace is activated, then SGSN shall send an Invoke Trace message to SRNC. Parameters: Trace Reference, Trace Type, Trigger ID, OMC Identity.

UE

3G- SGSN

SRNC

HLR

3G-GGSN

1: RRC Connection Request 6: RRC Connection Setup 10B. Initial Direct Transfer : Service Request 11. Common ID 12-26: Security Functions 48. Direct Transfer : Activate PDP Context Request

C1 28-47. Radio Access Bearer Setup 49. Invoke Trace 50. Create PDP Context Request 51. Create PDP Context Response

C2 52. Direct Transfer : Activate PDP Context Accept Uplink PDU

Figure 15: Service Request and PDP context Activation Initiated by UE Procedures (PS domain only)


Approved 49



50. (PS domain only) SGSN validates the Activate PDP Context Request using information received from UE in step 48 and PDP subscription records. The validation criteria are described in [Ref 23.060]. SGSN may restrict the requested QoS attributes given its capabilities, the current load and the subscribed QoS profile. If a GGSN address can be derived, SGSN creates a TEID to initiate the creation of a GTP tunnel for the requested PDP context and sends a Create PDP Context Request message to the affected GGSN. Parameters: TEID Data I (for downlink G-PDUs related to the requested PDP context), TEID Signalling (for downlink signalling related to the requested PDP context), MSISDN (optional IE for external authentication purposes), End User Address (shall be empty in order to request dynamic address), QoS Profile (QoS Negotiated by SGSN), SGSN Address for signalling, SGSN Address for user traffic, optional Recovery IE, APN, Selection Mode (which indicates the origin of the APN), IMSI, NSAPI, TFT, Protocol Configuration Options, Charging Characteristics (this IE shall also include an indication whether it was retrieved from subscription data received from the HLR or is a default profile that may be otherwise determined by the SGSN), if BSS trace is activated, the four parameters from trace related step (Trace Reference, Trace Type, Trigger ID, OMC Identity), and optional IE Private Extension for vendor or operator specifics. 51. (PS domain only) GGSN checks if this PDP context already exists for the UE, which is not the case (if it exists, GGSN shall replace old parameters with just received new ones). GGSN creates a new entry in its PDP context table and generates a Charging ID. When the Charging Characteristics sent by the SGSN have been determined by the SGSN, the GGSN may choose to ignore them. GGSN may use APN to find an external network and optionally to activate a service for this APN. GGSN is able now to route PDP PDUs between SGSN and external PDN, and to start charging. GGSN rejects the PDP context if QoS Negotiated received from the SGSN is incompatible with the PDP context being activated. The compatible QoS profiles are configured by the GGSN operator. In this example, it is assumed everything is right and GGSN then returns a Create PDP Context Response message to SGSN. Parameters: Cause (which is “ Request Accepted”, otherwise the PDP will not be created), TEID Data I (for uplink G-PDUs related to the requested PDP context), TEID Signalling (for uplink signalling related to the requested PDP context), GGSN Address for signalling, GGSN Address for user traffic, End User Address (only if GGSN allocated the address or if this is to be allocated by an external PDN; in the latter case IE is set to the allocated address, in the former it is set to 0.0.0.0), QoS Profile (QoS Negotiated by GGSN), Reordering Required (this IE shall be ignored when QoS Profile is R99), optional Recovery IE, Charging ID, Charging Gateway Address (so that SGSN transfer to it CDRs for this PDP Context), Protocol Configuration Options (optional parameters transparently transferred through SGSN to UE), and optional IE Private Extension for vendor or operator specifics. 52. (PS domain only) SGSN inserts the NSAPI along with GGSN addresses in its PDP context. If UE requested a dynamic address, the PDP address received from GGSN is also inserted in the PDP context. SGSN selects Radio Priority level and Packet Flow ID based on the QoS Negotiated and then sends a NAS Activate PDP Context Accept message back to UE. SGSN is now able to route PDP PDUs between GGSN and UE, and to start charging. Parameters: Negotiated LLC SAPI, Negotiated QoS, Radio Priority, and optionally PDP address and PDP Type (if UE did not request a static address), Packet Flow Identifier and Protocol Configuration Options. Note: The Radio Priority level and the LLC SAPI parameters, though not used in UMTS, shall be included in messages in order to support handover between UMTS and GSM networks.


Approved 50



Upon reception of an Activate PDP Context Accept message, UE shall stop timer T3380 and shall enter the state PDP-ACTIVE. If the offered QoS parameters received from the network differ from the QoS requested by UE, UE shall either accept the negotiated QoS or initiate the PDP Context Deactivation procedure. For each PDP Address a different QoS profile may be requested. If a QoS required is beyond the capabilities of a PLMN, the PLMN negotiates the QoS as close as possible to the requested profile. If UE accepts the negotiated QoS, UE is now able to send/receive PDUs to/from an external PDN, i.e., the call is established for PS domain. For an UE with GPRS-CSI defined, CAMEL interaction may be performed, see referenced procedures in 3G TS 23.078: C1) CAMEL-GPRS-Activate-PDP-Context. C2) CAMEL-GPRS-SGSN-Create-PDP-Context.

2.1.9 CS Domain Call Setup procedure (CS domain only) The Call Control entity of the UE initiated establishment of a CC connection by requesting the MM sublayer to establish a mobile originating MM connection and entering the “ MM Connection Pending” state. First of all, UE must establish an RRC connection as described in steps 1 through 7. After that, Call Control entity of the UE starts timer T303 when the CM Service Request is sent inside RANAP Initial UE Message in step 10. CM Service Type within NAS message is set to “ mobile originating call establishment”. After receiving this message, MSC may initiate common security functions as described above (Identity Check or Authentication and Ciphering) and shall perform the Security Mode Setup procedure. An indication from lower layers that the Security Mode Setup procedure is completed, or reception of a CM Service Accept message, shall be treated as a service acceptance by the UE (step 27). The timer T3230 started in step 10 shall be stopped. UE enters PMM-CONNECTED mode and MM sublayer enters state “ MM Connection Active”. UE can now proceed with its pending UE-MSC signalling procedure, which is depicted in Figure 16 and described from step 53 (steps 48 through 52 apply only for PS domain as steps 53 through 60 apply only for CS domain).

53. (CS domain only) The Call Control entity of the UE sends a Setup message to its peer network entity. It then enters the “Call initiated” state, but timer T303 is not stopped yet. Parameters: The setup message shall contain all the information required by the network to process the call. In particular, it shall contain the Called Party address information and, if the UE supports multicall, it shall include the Stream Identifier (SI) IE. In this example, since there is no other ongoing call i.e. this the first call, the SI value shall be 1. It also shall contain UE Bearer Capability to describe the requested bearer service (for more details see [Ref 24.008]).


Approved 51



UE

Calling MSC/VLR

SRNC

HLR

Called MSC/VLR

1: RRC Connection Request 6: RRC Connection Setup 10B. Initial Direct Transfer : CM Service Request 11. Common ID 12-27: Security Functions

53. Direct Transfer : Setup 54. Direct Transfer : Call Proceeding 28-47. Radio Access Bearer Setup 55. ISUP IAM

56. ISUP ACM

57. Direct Transfer : Alerting

58. ISUP ANM 59. Direct Transfer : Connect

60. Direct Transfer : Connect Acknowledge

Figure 16:CS Domain Call Setup (CS domain only)

54. (CS domain only) The Call Control entity of the network enters the “Call Initiated” state. It shall then analyse the call information contained in the setup message. If the information received is valid and UE is authorized for the requested service, MSC shall send firstly Call Proceeding, secondly Alerting and finally Connect messages after proper events, but UE must be ready to receive any of them without having received the previous one (for more details, see [Ref 24.008]). In this example, it is assumed UE receives all three messages. MSC sends Call Proceeding to indicate UE that the call is being processed. MSC Call Contr ol entity enters the “ Mobile Originating Call Proceeding” state. Upon reception of this message, UE shall also enter the “ Mobile Originating Call Proceeding” state and shall stop timer T303. It shall initiate timer T310 unless a specific Progress Indicator IE is contained within the message (see 24.008 for more details). Parameters: This message shall reply to requested parameters by Setup message. The bearer capability IE shall contain the same parameters as received in the Setup except those presenting a choice. In this case, appropriate parameters indicating the results of those choices shall be included. In the case where the network supports multicall, UE shall be informed within this message, otherwise the UE supporting multicall shall regard that the network does not support multicall (for more details see [Ref 24.008]). 28-47. RAB setup is done by any of the RAB Assignment Procedures described in section 2.1.7. This procedure has to be performed after step the Call Control entity of the network has entered UMTS Call Flows November 4, 2000

Approved 52



the “ Mobile Originating Call Proceeding” state (i.e., MSC has already received QoS in Bearer Capabilities IE). However, it is a network dependent decision when to initiate the assignment of an appropriate traffic channel (RAB Setup) during the mobile originating call establishment phase. Initiation of a suitable RR procedure to assign an appropriate traffic channel does neither change the state of a Call Control entity nor affect any call control timer. Note: So, NAS signalling can be done at the same time than the RAB assignment procedure. However, during certain phases of such an RR procedure, transmission of CC and MM messages may be suspended (see GSM 4.18, section 3 and GSM 8.08 for more details).

If UE supporting multicall includes the SI IE in the Setup message in step 53, MSC shall include the received SI into the RAB ID and send it back to the UE. The purpose of the SI IE is to associate a particular call with a RAB and to identify whether a new traffic channel shall be assigned, which is the case if UE generates a new SI value at the initiation of an originating call. If UE does not send SI IE, MSC shall set the SI value to 1. 55. (CS domain only) Calling MSC sends ISUP Initial Address Message (IAM) to called MSC. 56. (CS domain only) Called MSC responses with ISUP Address Complete Message (ACM) after receiving Alerting message from called user (this will be further described in Mobile Terminated Call Establishment section). 57. (CS domain only) Upon step 56, MSC sends an Alerting message to UE and enters “Call Delivered” state. UE shall then stop timers T303 and T310 (if running) and shall also enter the “ Call Delivered” state. In this state, for speech calls an alerting indication should be given to the user. If the RAB assignment is completed and UE has activated the codec or interworking function, MSC is responsible for the alerting indication otherwise UE should generate it. Parameters: (All IEs are optional) Facility, Progress Indicator and User-User (if called remote user included User-User IE in its alerting message). For more details see [Ref 24.008]. 58. (CS domain only) Called MSC sends ISUP Answer Message (ANM) upon receiving an indication that the call has been accepted. 59. (CS domain only) MSC shall connect the traffic channel if not connected already (including the connection of an interworking function, if required) and then send a Connect message to UE. Network starts timer T313 and enters “ Connection Indication” state. Parameters: (All are optional) Facility, Progress Indicator, Connected Number, Connected Subaddress, User-User. For more details see [Ref 24.008] 60. (CS domain only) UE shall activate the codec or interworking function to the traffic channel if not done yet, stop timers T303 and T310 (if running), return a Connect Acknowledge message to the network and enter the “ Active” state. Upon reception of Connect Acknowledge, MSC shall stop timer T313 and enter “ Active” state. The CS domain call is now established.


Approved 53



2.2 Mobile Terminated Call Establishment This process starts whenever CN receives information from a remote user to an UE registered in that CN node. It is assumed the UE is already attached to the network, but in MM-IDLE mode for the CN domain the call is going to be established, which means UE will have to be paged. After paging, the corresponding Call Control entity in the network shall initiate the MM connection establishment, which is practically the same process described in previous section. So, those procedures described in section 2.1 will not be repeated here, but corresponding references will be made.

2.2.1 Service Request and PDP Context Activation procedure (PS domain only) UE in PMM-IDLE mode may have a PDP context activated; however, it is assumed it has not. Then, network will have to request PDP Context Activation. To support Network-Requested PDP Context Activation the GGSN has to have static PDP information about the PDP address, otherwise GGSN would discard PDP PDUs. It is also assumed GGSN has got necessary static PDP information for called UE.

1. When receiving a PDP PDU the GGSN checks if a PDP context is established for that PDP address. If not, GGSN checks if there is static PDP information for that PDP address. Once these checks have been performed, the GGSN initiates the Network-Requested PDP Context Activation procedure. The GGSN may store subsequent PDP PDUs received for the same PDP address. 2. The GGSN may send a Send Routing Information for GPRS message to the HLR. Parameters: IMSI. The network operator may implement the following techniques to prevent unnecessary queries to the HLR [ref 23.060]: •

•

•

MNRG technique in GGSN, SGSN and HLR; The GGSN may reject or discard PDP PDUs for a certain time after a previous unsuccessful delivery attempt; The GGSN may store the address of the SGSN with which it established the last PDP context. This SGSN address will be considered as valid during a certain time.

3. If the HLR knows IMSI and determines the request can be served, it returns a Send Routeing Information for GPRS Ack message to the GGSN that contains the SGSN Address. If HLR rejects the request, the message does not contain the SGSN Address, but an error cause. The successful case is always assumed. Parameters: IMSI, SGSN Address and the Mobile Station Not Reachable Reason (MNRR) if MNRG flag is set in the HLR.


Approved 54



UE

UTRAN

SGSN

HLR

GGSN 1. PDP PDU

2. Send Routeing Info for GPRS 3. Send Routeing Info for GPRS Ack 4. PDU Notification Request 5. PDU Notification Response 6. Paging Request 7: RRC Connection Request 7: RRC Connection Setup 8. Initial Direct Transfer : Service Request 9. Common ID 10: Security Functions 11. Direct Transfer : Request PDP Context Activation 12. Direct Transfer : Activate PDP Context Request

C1 13. Radio Access Bearer Setup 49. Invoke Trace 50. Create PDP Context Request 51. Create PDP Context Response

C2 52. Direct Transfer : Activate PDP Context Accept Downlink PDU

Figure 17: Successful Network-Requested PDP Context Activation Procedure

4. If SGSN Address is present and either MNRR is not present or MNRR indicates “ No paging Response”, the GGSN shall send a PDU Notification Request message to the SGSN indicated by the HLR. Parameters: IMSI, TEID (only if there is not yet a GTP tunnel between SGSN and GGSN), End User Address (i.e., PDP Type and PDP Address), APN that wishes to connect to the UE and optional Private Extension for vendor/operator specifics. 5. At this point, SGSN is responsible for requesting the UE to activate the indicated PDP Context. SGSN sends back a PDU Notification Response message to GGSN to indicate that


Approved 55



the PDP Context Activation will proceed, i.e., Cause value set t o “ Request Accepted” (for rejection cause values see [ref 23.060]). Parameters: Cause and optional Private Extension for vendor/operator specifics. 6. Since UE is assumed to be in PMM-IDLE mode, SGSN has to send a RANAP Paging Request message to UTRAN. The Paging Request procedure is exactly the same for both CS and PS domain as described in section 2.2.3 “Paging”. For PS domain, the Paging Request procedure triggers the Service Request procedure in the UE, which is fully described in section 2.1.8 “Service Request and PDP Context Activation procedure (PS domain only)” for the Mobile Originated Call Establishment. So, next steps will only describe those differences, if any, for messages and parameters for the Mobile Terminated Call Establishment process. 7. If an RRC connection does not exist, which is the case consider in this example, UE establishes it as described in section 2.1.1 “RRC Connection Establishment”. 8. Once the RRC connection is established, UE can use it to send a signalling establishment request to the required CN domain (PS domain in this section), which was indicated to UE in the paging procedure. This step is described in section 2.1.2 “Iu Signalling Connection Establishment”. In this case, the Service Type parameter within the NAS message is set to “paging response”. Upon reception of this message, SGSN shall stop paging timer T3313. 9. After having established the Iu Signalling connection, SGSN shall send a RANAP Common ID message as described in section 2.1.4 “Common ID procedure”. In the Mobile Terminated process for PS domain, the Permanent NAS UE Identity (i.e. IMSI) is always available because SGSN must receive it from GGSN in step 4. 10. At this point, the SGSN may perform the Authentication procedure and shall perform the Security Mode procedure as described in section 2.1.5 “Security Functions”. When UE receives the RRC Security Mode Command message UE knows that the Service Request message was successfully received in the SGSN. Note: It does not make sense to perform the Identity Check procedure for UE is already identified. Nor does optional message “(CM) Service Accept” described in section 2.1.6 “MM Connection Established”. In addition, if this were not the first call for UE, Common ID procedure and Security Mode Setup would not be mandatory.

11. SGSN knows whether the downlink packet requires RAB establishment or not. If SGSN receives a downlink PDU for an existing PDP context, it will re-establish resources for the PDP context. However, this is not the case for this example, i.e., there is not PDP context established. So, SGSN shall request the UE to activate a PDP context. SGSN sends a Request PDP Context Activation message to UE and starts timer T3385. Parameters: Offered PDP Address (PDP Address and PDP Type) and, if available, the APN. In this example, APN should be available for SGSN receives it in step 4. 12. UE shall either reject the PDP Context Activation by sending a Request PDP Context Activation Reject or initiate the PDP Context Activation procedure as described in section 2.1.8. The latter case is considered. Then, UE sends an Activate PDP Context Request message including the PDP Address, PDP Type and APN requested by the network in previous step. 13. Upon reception of previous message, SGSN shall stop timer T3385. Then, RAB Assignment procedure is performed as described in section 2.1.7.


Approved 56



At this point, exactly the same procedure applies as described in section 2.1.8 “Service Request and PDP Context Activation procedure (PS domain only)” for the Mobile Originated Call Establishment (steps 49 through 52). The only consideration is that the PDP context is established for PDP Type, static PDP Address and APN requested by GGSN in step 4. Once PDP context is established, it is possible for GGSN to deliver to UE all PDP PDUs stored while this process and following ones.

2.2.2 CS Domain Call Setup procedure (CS domain only) Note: Only standard procedure is described, i.e., CCBS feature is not considered.

It is assumed UE is registered to the CS domain network, but in CMM-IDLE mode. At this point, serving MSC will receive a call from a remote user. 1. Called MSC receives ISUP Initial Address Message (IAM) from calling MSC. 2. Since UE is assumed to be in CMM-IDLE mode, MSC has to send a RANAP Paging Request message to UTRAN. The Paging Request procedure is exactly the same for both CS and PS domain as described in section 2.2.3 “Paging”. 3. If an RRC connection does not exist, which is the case consider in this example, UE establishes it as described in section 2.1.1 “RRC Connection Establishment”. 4. Once the RRC connection is established, UE can use it to send a signalling establishment request to the required CN domain (CS domain in this section), which was indicated to UE in the paging procedure. This step is described in section 2.1.2 “Iu Signalling Connection Establishment”. In this case, the NAS message is not a CM Service Request message, but a Paging Response message. This message shall use the RR protocol discriminator as defined in GSM 04.18, chapter 9.1.25. This is so for reasons of backward compatibility. Upon reception of this message, MSC shall stop paging timer T3113. 5. After having established the Iu Signalling connection, and if the Permanent NAS UE identity (i.e. IMSI) is available, MSC shall send a RANAP Common ID message as described in section 2.1.4 “Common ID procedure”. In the Mobile Terminated process, the Permanent NAS UE Identity (i.e. IMSI) is always available because MSC must send it in step 2. 6. At this point, the MSC may perform the Authentication procedure and shall perform the Security Mode procedure as described in section 2.1.5 “Security Functions”. When UE receives the RRC Security Mode Command message UE knows that the Paging Response message was successfully received in the MSC. Then, MM UE entity shall enter state “Wait for Network Command” in order to wait for step 7 and do not interrupt Security Functions. Note: It does not make sense to perform the Identity Check procedure for UE is already identified. Nor does optional message “(CM) Service Accept” described in section 2.1.6 “MM Connection Established”. In addition, if this were not the first call for UE, Common ID procedure and Security Mode Setup would not be mandatory.

7. Upon completion of the MM connection, the Call Control entity of the network shall send the Setup message to its peer entity at the UE, start timer T303 and enter the “ Call Present” state. This message shall contain the multicall supported information if network supports multicall and this is the first call. If this information is not present, UE supporting multicall shall regard that the network does not support multicall. UE supporting multicall shall store this information and UE not supporting multicall shall ignore it.


Approved 57



Parameters: There are many optional parameters such as Bearer Capability, Progress indicator, Alert, User-User info, priority, etc. For further details see [ref 24.008].

UE

UTRAN

Called MSC/VLR

HLR

Calling MSC/VLR 1. ISUP IAM

2. Paging Request 3: RRC Connection Request 3: RRC Connection Setup 4. Initial Direct Transfer : Paging Response 5. Common ID 6: Security Functions 7. Direct Transfer : Setup 8. Direct Transfer : Call Confirmed

9. Radio Access Bearer Setup

10. Direct Transfer : Alerting 11. ISUP ACM

12. Direct Transfer : Connect 13. Direct Transfer : Connect Acknowledge 14. ISUP ANM

Figure 18: Successful Mobile Term inated CS Domain Call Establishment

8. UE shall perform compatibility checking as described in [ref 24.008]. If the result of the compatibility checking was compatibility, the Call Control entity of the UE shall enter the “ Call Present” state. If the call is allowed to continue UE shall acknowledge the Setup message by sending a Call Confirmed message. UE enters then in “ Mobile Terminated Call Confirmed” state. Parameters: UE may include one or two Bearer Capabilities to define the radio channel requirements and other optional parameters such as Stream Identifier (SI). The purpose of the SI IE is to associate a particular call with a RAB and to identify whether a new traffic channel shall be assigned or not. For this example (first call) and whenever UE generates a new SI value at the initiation of a call, a new traffic channel shall be assigned. If UE does not send SI IE in the Call Confirmed message, MSC shall set the SI value to 1. Another possible case is that a UE supporting multicall might not need a new traffic channel for the new call. If so, UE UMTS Call Flows November 4, 2000

Approved 58



might set this IE to “ No bearer” and shall take the decision of reusing an existing traffic channel or of creating a new one in the Connect message in step 12. 9. Upon reception of the Call Confirmed message, MSC shall stop timer T303, start timer T310 and enter the “ Mobile Terminated Call Confirmed” state. At this moment, RAB assignment procedure described in section 2.1.7 can be performed unless IE SI were set to “ No bearer”. In the latter case, the decision of establishing a new RAB will be taken in step 12. At RAB assignment, MSC shall include the received SI value into the RAB ID and send it back to UE in this procedure. However, it is a network dependent decision when to initiate the assignment of an appropriate traffic channel (RAB Setup) during the mobile terminated call establishment process. Initiation of a suitable RR procedure to assign an appropriate traffic channel does neither change the state of a Call Control entity nor affect any Call Control timer. 10. If Alert IE was present in Setup message (step 7), user alerting is initiated at the UE side as soon as an appropriate channel is available. User alerting means the generation of a tone or indication at the UE and sending of an Alerting message by the Call Control entity to its peer in the MSC. UE enters then the “ Call Received” state. 11. Upon reception of an Alerting message, Call Control entity of the MSC shall send an ISUP Address Complete message (ACM) to the calling MSC. Called MSC stops timer T310, starts timer T301 and enters then the “ Call Received” state. 12. User can accept the call while UE is in the “ Mobile Terminated Call Confirmed” state or in the “ Call Received” state. T he Call Control entity of the UE shall send a Connect message to its peer entity in the network, starts timer T313 and enters then the “ Connect Request” state. Parameters (all optional): Facility, Connected subaddress, User-User, SS version, SI. SI value assigned by UE shall be present if it was set to “ No Bearer” in the Call Confirmed message. If the user decides that an existing traffic channel will be reused, UE will set the SI value to the SI value of an existing traffic channel. If a new traffic channel is requested, SI will be set to a new value. In the latter case, RAB Assignment procedure will be performed now. 13. Upon reception of Connect message and through traffic channel is assigned and connected, MSC shall stop timer T310, T303 and T301 (if running) and then send a Connect Acknowledge message to its peer entity at the UE, which will stop timer T313 and enter “ Active” state. 14. MSC sends a ISUP Answer Message (ANM) to calling MSC and enter “ Active” state.

At this point, steps 59 and 60 from section 2.1.9 “CS Domain Call Setup procedure (CS domain only)” for the Mobile Originated Call Establishment process will be performed. Then, the CS domain call is established.

2.2.3 Paging procedures The general assumption within this document is that UE is attached/registered to the network and in MM-IDLE mode at the beginning of call establishment process. That is why it has been described for both PS and CS domain Paging procedure is necessary for the Mobile Terminated Call Establishment. UTRAN makes no difference in handling a paging request from a SGSN or from a MSC. In addition, paging procedure is performed in one domain irrespectively of the other. So, it would be possible a connection exists for the other domain, i.e., within UTRAN UE might be in different


Approved 59



RRC modes: idle mode, URA connected mode or cell connected mode. Paging procedure is different depending on the RRC state of the concerned UE. For the global process of Mobile Terminated Call Establishment, it will be assumed that there is not RRC connection, i.e. UE is in RRC idle mode. However, all Paging procedures will be considered in this section in order to fully describe the Paging Procedure. There are three possible cases: A. Idle mode, i.e., non-existing RRC connection B. URA connected mode or Cell_PCH state (i.e. cell connected mode without DCCH) C. Cell connected mode with existing DCCH and in Cell_DCH or Cell_FACH states

When a UE is both IMSI- and GPRS- attached in a network that operates in mode I (Gs interface exists), then the MSC/VLR executes paging for circuit-switched services via the SGSN. However, this case is not considered so far, for Gs interface is not developed yet. Regarding numbering, this procedure corresponds to step 2 for CS domain and to step 6 for PS domain for the Mobile Terminated Call Establishment process. However, this section will start number from 1 for every paging case described, otherwise numbering would become too ambiguous for this example. Figure 19 shows different paging scenarios. The first message CN sends to UTRAN is common for all three paging cases: 1. CN knows from last Location Update procedure at least the last LAI and/or RAI, which might be served by several RNCs. CN sends a RANAP Paging message to concerned RNCs (for simplicity, RANAP paging is sent to only one RNC in Figure 19). SGSN starts timer T3313 and MSC starts timer T3113. If timer expires, CN node may reinitiate procedure. Parameters: CN Domain Indicator, Permanent NAS UE Identity and optional following IEs: Temporary UE Identity, Paging Area ID, Paging Cause, Non Searching Indication and DRX Cycle Length Coefficient.

If TMSI is included, UTRAN should use it over the paging channel, otherwise IMSI shall be us ed. The Paging Area ID identifies the LAI (CS domain) or RAI (PS domain) in which paging shall be broadcast in case non-existing RRC connection (case A). If this IE is not present, the whole RNC area shall be used. RNCs will check the Permanent NAS UE Identity (i.e. IMSI) for an existing RRC connection if the Non Searching Indication is not present, otherwise the normal PCH paging will be initiate as for non-existing RRC connection (case A). RNC will now initiate proper paging RRC procedure depending on UE RRC mode:

Ø

Case A 2. UE is in idle mode. RNC broadcasts an RRC Paging Type I message on an appropriate paging occasion on the PCCH. It is possible to repeat paging on several paging occasions in order to increase the probability of proper reception. In addition, RNC may page several UEs in the same paging occasion by including one IE “ Paging Record” for each UE. Parameters: Paging record list (from 1 to number of UEs paged in this message), Paging Record (CHOICE Originator: if CN Originator record contains: Paging Cause, CN domain identity and CHOICE UE Identity – IMSI, TMSI, P-TMSI-; and if UTRAN Originator record contains: U-RNTI) and optional BCCH modification info.


Approved 60



3. Upon reception of a Paging Type I message, UE shall check each occurrence of the IE “ Paging Record” and compared the included identities for corr esponding CN domain indicated with its allocated CN UE identities. For each match, UE shall forward the identity and paging cause to the upper layer. UE in idle mode shall ignore UTRAN originated paging.

UE

RNC

RNC

CN

NODE B A) UE is in IDLE mode

RANAP

1. Paging

RANAP

2. PCCH: Pa ging Type I RRC

RRC

B) UE is in URA connected mode or in Cell_PCH RRC state

RANAP

1. Paging

RANAP

2. Paging Request RNSAP

RNSAP

3. PCCH: Pa ging Type I RRC

RRC 3. PCCH: Pa ging Type I

RRC

RRC

C) UE is in cell connected mode with existing DCCH

RRC

RANAP

2. DCCH: Paging Type 2

1. Paging

RANAP

RRC

Figure 19:Paging Procedure for different UE RRC modes Ø

Case B 2. An RRC connection exists and it has been identified thanks to the Permanent NAS UE Identity. UE is in URA_PCH or Cell_PCH RRC state. An URA might be controlled by different RNCs and UE might be camping in a cell controlled by other RNC, so RNC might send a RNSAP Paging Request message to concerned RNCs. Parameters: CHOICE paging area between URA and Cell (message will contain URA-Id or C-Id), SRNC-Id, S-RNTI, IMSI, DRX Cycle Length Coefficient. 3. Corresponding CRNCs broadcast an RRC Paging Type I message as in case A but only in those cells belonging to the URA if UE is in URA_PCH state or only in the known cell if UE is in Cell_PCH state. UE will receive one paging request from each RNC and DRNC will route all paging responses to the SRNC, who will forward them to the CN. It is then up to the CN to filter the paging responses [ref UTRAN SFRAS section 2.7]. Parameters: Paging record list (from 1 to number of UEs paged in this message), Paging Record (CHOICE Originator: if CN Originator record contains: Paging Cause, CN domain


Approved 61



identity and CHOICE UE Identity – IMSI, TMSI, P-TMSI-; and if UTRAN Originator record contains: U-RNTI) and optional BCCH modification info. 4. Upon reception of a Paging Type I message, UE shall check each occurrence of the IE “ Paging Record” and compare the included identities with its allocated U-RNTI. When there is a match, UE shall enter Cell_FACH state and perform a Cell Update 1 procedure with cause “paging response”. UE in this case shall ignore CN originated paging.

Ø

Case C 2. An RRC connection exists and it has been identified thanks to the Permanent NAS UE Identity. UE is in Cell_DCH or Cell_FACH RRC state, i.e. there is DCCH. RNC will transmit an RRC Paging Type 2 message on the DCCH. When not stated otherwise elsewhere, this procedure shall not affect any other ongoing RRC procedure. Parameters: Paging cause, CN domain identity, Paging Record Type Identifier. 3. Upon reception of a Paging Type 2 message, UE shall indicate it and forward the paging cause and the Paging Record Type Identifier to the upper layer entity indicated by the CN domain identity. UE will respond with a Paging Response sent over DCCH for CS domain and with the Service Request procedure for PS domain.

Note: For CS domain, Paging Response shall use the RR protocol discriminator as defined in GSM 04.18, chapter 9.1.25. This is so for reasons of backward compatibility.

For the Mobile Terminated Call Establishment process, case A is considered. So, an RRC connection need establishing as shown in both Figure 17: Successful Network-Requested PDP Context Activation Procedure and Figure 18: Successful Mobile Terminated CS Domain Call Establishment.

1 Since

this example does not consider this specific case, Cell Update will not be described in this section. However, Cell Update procedure is planned to be added to this document in the futur e.


Approved 62



3 Call Release This clause presents different procedures for call releasing for either CS or PS Core Network domains. Only the normal call release will be described, i.e. call release after completion of UE-CN transaction/call. However, Call Release concept for PS and CS domains is quite different. In the first case, PDP context Deactivation procedure will be considered. In the latter case, the Call Clearing procedure will be described. In both cases, RAB and signalling connection release will apply, i.e. it will be considered UE does not maintain any more active call. Then, only Iu signalling release and RRC connection release procedures will apply. However, section 3.1.3.3 will describe appropriate RAB release procedures corresponding to those described in section 2.1.7 for RAB establishment, for these procedures will be performed in many release cases where Iu connection is maintained. After this process, UE will remain attached/registered to the network, but in MM-IDLE mode. Detach procedures will be described in a different section according to the document proposal in Annex A. Again, a major distinction will be made between Mobile Originated procedures and Mobile Terminated procedures. In fact, release process has a local significance and only an indication for release will be sent to the remote user in step 2 of the CS domain Release process.

3.1 Mobile Originated Call Release 3.1.1 PDP Context Deactivation procedure (PS domain only) For PS domain, an established call means UE has a PDP context activated and user data can be transmitted/received through the PS network. At any point, user decides transaction is completed and wants to deactivate the PDP context.

UE

UTRAN

3G-SGSN

3G-GGSN

1. Direct Transfer : Deactivate PDP Context Request

C1 2. Delete P DP Context Request 3. Delete PDP Context Response 4. Direct Transfer: Deactivate PDP Context Accept

UTRAN Resources Release

Figure 20: PDP Context Deactivation I nitiated by UE procedure


Approved 63



It will be assumed UE was an active user and all resources (Iu signalling, RAB, RRC connection) were allocated. So, procedures to release all resources will be described. In any case, the Delete PDP Context Request takes precedence over any other ongoing Tunnel Management message. So, Delete PDP Context will always be performed regardless PDP state. 1. UE sends a Deactivate PDP Context Request message to the SGSN by means of the Direct Transfer described in section 2.1.3. UE starts timer T3390. Parameters: Session Management Cause (“ Regular Deactivation” in this example, see [ref. 24.008] for more causes) and optional Tear Down Indicator IE, which may be included to indicate whether only the PDP context associated with this specific Transaction Identifier (TI2) or all active PDP context sharing the same PDP address as the PDP context associated with this specific TI shall be deactivated. If it is not included, only this PDP context will be deactivated. In this example, tear down will be considered to be requested. 2. SGSN sends a Delete PDP Context Request message to the GGSN. If Tear Down Indicator was included, SGSN will request to deactivate all associated PDP context by including the Tear Down Indicator in this message, too. Parameters: NSAPI, optional Tear Down Indicator and optional Private Extension for vendor/operator specifics. 3. GGSN shall be prepared to receive previous message at any time and shall always reply regardless if the PDP context exists or not by sending a Delete PDP Context Response back to SGSN. In this example, PDP context exists and GGSN removes it. Parameters: Cause (set to “ Request Accepted” in this example) and Private Extension for vendor/operator specifics. 4. If the previous message contains a Cause IE other than “ Request Accepted”, the PDP context shall be kept active. This is not the case in this example, then SGSN replies to UE with a Deactivate PDP Context Accept message. Upon reception of this message, UE shall stop timer T3390. Parameters: none specific IE. At this point, SGSN shall initiate the release of UTRAN resources associated with this PDP context as described in section 3.1.3. For an UE with GPRS-CSI defined, CAMEL interaction may be performed, see referenced procedures in 3G TS 23.078: C1) CAMEL-GPRS-Deactivate-PDP-Context.

2 Every

Layer 3 message consists of the following parts: protocol discriminator, transaction identifier, message type and other IEs, if required. Most of parameters listed through this document are message specific IEs. However, this procedure makes use of the TI to identify PDP Contexts associated to a PDP address, for each PDP Context sharing a PDP address and APN shall be identified by an unique TI and an unique NSAPI. The transaction identifier and its use are defined in TS 24.007.


Approved 64



3.1.2 Call Clearing procedure (CS domain only) For CS domain, an established call means UE has a circuit-switched end-end connection established with a remote user. At any point, local user decides transaction is completed and wants to clear the CS call. [Ref 24.008] defines some conditions that will allow the introduction of shorter call clearing procedures in the future, however standard procedure will be described in this section. It will be assumed UE was an active user and all resources (Iu signalling, RAB, RRC connection) were allocated. So, procedures to r elease all resources will be described. 1. Call Control entity of the UE stops all running call control timers, sends Disconnect message to its peer entity of the network, starts timer T305 and enters “ Disconnected Request” state. Parameters: Cause (“ Normal Call Clearing” in this example), optional Facility, optional UserUser information and optional SS version. 2. Upon reception of previous message, Call Control entity of the MSC shall stop al running call control timers and initiate procedures to clear the call to the remote user by sending ISUP REL (release) message to remote MSC. 3. Then, MSC sends a Release message to its peer entity in the UE, starts timer T308 and enters “ Release Request” state. It is necessary to notice this message has got only local significance and does not imply an acknowledgement of clearing from the remote user (this apply for the whole release process). Parameters: only optional Facility IE may apply to this example.

UE

UTRAN

Callin MSC

Called MSC

1. Direct Transfer : Disconnect 2. ISUP REL 3. Direct Transfer: Release 4. Direct Transfer: Release Complete


Figure 21: Call Clearing Initiated by UE procedure

4. Upon reception of Release message, UE shall stop timer T305, send a Release Complete message to the network, release MM connection and return “ Null” state. Parameters: only optional Facility and SS Version may apply to this example. Upon reception of Release Complete message, MSC shall stop timer T308, release MM connection and return to “ Null” state. At this point, MSC shall initiate the release of UTRAN resources associated with this call as described in section 3.1.3.


Approved 65



The release of the MM connection is done locally in the MM sublayer for both UE and MSC, i.e. no MM message is sent over the radio interface for this purpose. If all MM connections are released by its CM entities, UE starts timer T3240 and enters “ Wait for Network Command”, expecting UTRAN Resources Release. However, network may decide to maintain UTRAN resources in order to establish another MM connection. In case none MM connection is established and UTRAN resources are not released within time controlled by T3240 (i.e. timer expires), UE shall abort the radio connection.

3.1.3 UTRAN Resources Release procedures It has been assumed UE was an active user and both resources for user traffic (RAB) and for signalling (Iu signalling and RRC connection) were allocated. So, procedures to release all resources will be described in this section. These procedures are handled in the same way for both PS and CS domain. If UE had any more PDP context or call established, CN node would initiate the RAB Assignment procedure in order to release just the RAB corresponding to the PDP Context or the Call that has just been released. If so, signalling connection would remain depending on the activity of the UE. On the other hand, if UE is releasing the last PDP Context/Call, the signalling connection is likely to be released, though CN may maintain it in order to establish another PDP Context/Call. The assumption for this example will be UE releases all resources and then only Iu signalling release and RRC release procedures will apply. However, section 3.1.3.3 will describe appropriate RAB release procedures corresponding to those described in section 2.1.7 for RAB establishment, for these procedures will be performed in many release cases where Iu connection is maintained.

3.1.3.1 Iu Signalling Connection Release procedure This procedure is used to release the Iu signalling connection and all remaining RABs of concerned UE. In this example, this procedure is used after last PDP Context/Call has been released and it is initiated by the CN. Nevertheless, this procedure could be requested by UTRAN in order to preserve resources or due to some UTRAN generated reason (e.g. “ Unspecified Failure”, “User Inactivity”). If UTRAN decided to initiate this procedure, it would send a RANAP Iu Release Request message to both CN domains, if both Iu connections exist. This message would indicate the UTRAN cause for the release. It would be up to each CN node to decide how to react to the request depending on the cause: 1. Initiating the Iu Release procedure 2. Re-establishing resources in case of failure 3. Maintaining resources

The Iu Release Request message does not apply to this example, which describes a normal Iu Signalling Release procedure and will continue from step 5 as depicted in Figure 22. 5. In this example, CN sends a RANAP Iu Release Command message in order to initiate the Iu signalling connection release. UMTS Call Flows November 4, 2000

Approved 66



Parameters: Cause (“ Normal Release” in this example). 6. Upon reception of previous message, RNC shall initiate clearing of all UTRAN resources related only to the Iu connection to be released. If no other connection remains, RNC will release the RRC connection, which is the case for this example. Otherwise it will only release corresponding RABs. Both procedures will be described in following sections.

UE

RNC

CN Iu Release Request

RANAP

RANAP

5. Iu Release Command 6. Release of RAB or RRC Connection 7. Iu Release Complete RANAP

RANAP 8. ALCAP Iu Data Transport Bearer Release Not required towards PS domain

Figure 22: Iu Signalling Connection Release Procedure

7. The RNC returns any related assigned Iu user plane resources to IDLE mode and sends back to CN a RANAP IU Release Complete message. This message does not have to wait for the release of UTRAN resources to be completed. Parameters: If it is required by PS domain, RABs Data Volume Report per RAB (RAB ID, Unsuccessfully Transmitted DL Data Volume and optional Data Volume Reference), and if PS domain and the procedure was initiated by UTRAN, the RABs Released Group (RAB ID, DL/UL GTP-PDU Sequence Numbers). The latter group will allow SGSN to restore proper values in case the PDP Context is maintained and the RAB is re-established at a later stage. This message can optionally send Criticality Diagnostics IE. 8. SRNC initiates release of the Iu Data Transport Bearer between the CN and the SRNC using the ALCAP protocol. This step is not required for PS domain as it was not setup at Call Establishment for PS domain. The reception of the Iu Release Complete message terminates the procedure in the CN. This means call is released from CN point of view.

3.1.3.2 RRC Connection Release procedure The Iu Signalling Connection Release procedure triggers the RRC Connection Release procedure in step 6 as described above, where it was already stated that the Iu Release Complete message does not have to wait for UTRAN resources to be completely released. In fact, both procedures may be done at the same time, for they are car ried out by different entities within the RNC.


Approved 67



This example assumes RRC connection is released because of Call Release. Nevertheless, RRC connection could also be released for preservation of radio resources in case inactive UE, for example. As described in section 2.1.1 RRC Connection Establishment procedures, an RRC connection may be established on either dedicated channel (DCH) or common channels (RACH/FACH). The former requires more signalling for DCH must be also released. On the other hand, it allowed UTRAN to set UE in soft handover state immediately after RRC connection was established. So, it will be assumed UE is in soft handover for the DCH RRC Release, while this statement does not apply for the RACH/FACH RRC Release. First five steps for both cases are common as depicted in Figure 23 and Figure 24. Steps 5, 7 and 8 have just been described in the Iu Signalling Connection Release procedure. Step 6 is shown after step 8 in order to show the independency of these messages.

UE

Nod e B Dri ft RNS

Nod e B Serving RNS

Drift RNC

Serving RNC

CN

5. Iu Release Command RANAP

RANAP

RANAP

7. Iu Release Complete

RANAP

8. ALCAP Iu Bearer Release 6. (on DCCH or CCC H) RRC Connection Release RRC

RRC

9. (on DCCH or CC CH) RRC Connection Release Complete

RRC

RRC

Figure 23: RRC Connection release of a com mon transport channel

6. Upon indication from the CN by the Iu Release Command message, SRNC can send RRC Connection Release message to UE in order to initiate the release of the existing RRC connection including the signalling link and all RABs between UE and UTRAN, if they exist. SRNC may transmit several messages to increase the probability of proper reception by the UE (the number and the interval for repetition are network options). Parameters: Integrity Check Info, Release Cause (“normal event” in this example) and Number of RRC Message Transmissions in case UE is in Cell_DCH state. If the CCCH logical channel is used, the message shall also include the U-RNTI. 9. The reception of this message can interrupt any ongoing RRC procedure with the UE in Cell_DCH and Cell_FACH state. Depending on its state, UE shall act in different way. a. When in Cell_FACH state, UE shall send an RRC Connection Release Complete message using acknowledged mode to the UTRAN. Regardless success at transmission of this message, UE shall release all its radio resources, enter IDLE mode and the procedure ends on the UE side. Parameters: Integrity Check Info. If the CCCH logical channel is used, the message shall also include the U-RNTI. b. When in Cell_DCH state, UE shall send an RRC Connection Release Complete message using unacknowledged mode to the UTRAN and shall initiate counter V308 and timer T308. V308 indicates number of repetitions for the message every time T308 expires. V308 is decreased by one every repetition of RRC Connection Release


Approved 68



Complete message. When V308 reaches the zero value, the UE shall release all its radio resources, enter IDLE mode and the procedure ends on the UE side. Parameters: Integrity Check Info. If the CCCH logical channel is used, the message shall also include the U-RNTI.

Note: There must be a good reason for these timer and counter that I do not understand. Their values are set by the operator.

Regardless reception of RRC Connection Release Complete message, UTRAN shall release all UE dedicated resources. The procedure ends at this point in case RRC connection was established on RACH/FACH. In case it was established on DCH, following steps are performed as depicted in Figure 24: 10. SRNC (really CRNC) requests its Node B to delete all existing Radio Link(s) for given UE by sending the NBAP Radio Link Deletion Request message. Parameters: Node B Communication Context ID and Radio Link ID for each RL to be released.

UE

No de B Dr if t RN S

No de B Serving RNS

Drift R NC

Serving RNC

CN

5. Iu Release Command RANAP

RANAP 7. Iu Release Complete

RANAP

RANAP

8. ALCAP Iu Bearer Release 6 . ( o n D C C H o r C C C H ) R R C C o n n e c t i o n R e l ea s e RRC

RR C 9. (on DCCH or CCCH) R RC Connection Release Complete

RRC

RR C

10. Radio Link Deletion NB AP

N B A P 11. Radio Link Deletion RNSAP

RN S A P

12. Radio Link Deletion NB AP

NB AP 13. Radio Link Deletion Response

NB AP

NB AP

14. Radio Link Deletion Response

N B A P

NB AP 15. Radio Link Deletion Response RNSAP

RN S A P

16. ALCAP Iub Bearer Release

17. ALCAP Iub Bearer Release

ALCAP Iur Bearer Release

Figure 24: RRC Connection release of a dedicated channel

11. SRNC requests DRNC to release all radio links it may have towards UE with the RNSAP Radio Link Deletion Request message. Parameters: Radio Link ID for each RL to be released.


Approved 69



12. Upon reception of this message, DRNC shall initiate deletion of all radio links identified in the message for given UE by sending the NBAP Radio Link Deletion Request message to its Node B. Parameters: Node B Communication Context ID and Radio Link ID for each RL to be released. 13. Upon reception of Radio Link Deletion Request message, the Node B controlled by SRNC shall delete the Radio Link(s) identified in the message and release all associated resources and respond to the CRNC with the NBAP Radio Link Deletion Response message. Parameters: CRNC Communication Context ID and optionally Criticality Diagnostics. 14. Upon reception of Radio Link Deletion Request message, the Node B controlled by DRNC shall delete the Radio Link(s) identified in the message and release all associated resources and respond to the CRNC with the NBAP Radio Link Deletion Response message. Parameters: CRNC Communication Context ID and optionally Criticality Diagnostics. 15. Upon reception of Radio Link Deletion Response message from its Node B, DRNC shall respond to the SRNC with the RNSAP Radio Link Deletion Response message. Since all radio links for the UE are deleted, DRNC shall also release the UE context, unless the UE is using common resources in the DRNS. Parameters: only optionally Criticality Diagnostics IE. 16. SRNC initiates release of not used resources Iub Data Transport Bearer using ALCAP protocol. 17. DRNC initiates release of not used resources Iur and Iub Data Tra nsport Bearer using ALCAP protocol.

At this point, all UTRAN resources associated to Call that has just been released are also completely released. UE will remain attached/registered to the network, bu t in MM-IDLE mode.

3.1.3.3 RAB Release procedure This procedure is used to release one or several RABs of concerned UE. In this example, this procedure is not used for it is assumed the last PDP Context/Call has been released and Iu Signalling Connection Release procedure is initiated by the CN. However, it is described here for it can be performed in many release cases where Iu signalling connection is maintained. This procedure could be requested by UTRAN in order to preserve resources or due to some UTRAN generated reason (e.g. “ Unspecified Failure”, “ User Inactivity”). In this case, RNC sends RANAP RAB Release Request message to related CN. The message identifies every RAB to be released and indicates corresponding Cause. It is up to CN node to decide how to react to the request: •

•

If the CN decides to release some or all indicated RABs, CN may decide to invoke the RAB Assignment procedure (release RAB) to this effect. If no RABs will remain according to this message and CN decision, the CN may decide to initiate the Iu Signalling Connection Release procedure if it does not want to keep the Iu signalling connection. The Cause value then is “ No remaining RAB”.

Note: This time, specifications permit sending RAB Release Request message only to CN domain associated to RABs to be released.

The RAB Release Request message does not apply to this example, which describes a normal RAB Signalling Release procedure for a normal Call Release process. UMTS Call Flows November 4, 2000

Approved 70



RAB Assignment procedure is also described in section 2.1.7 within the Call Establishment process, for it is the common procedure to establish, modify or release RABs for a given UE. However, next sections will only describe those specific aspects f or RAB release. For similitude to the Iu Signalling Connection Release procedure and because RAB Release procedure would be in place of former one in a Release procedure where no Iu signalling release is performed, numbering will remain the same. 5. (bis) CN sends RANAP RAB Assignment Request message to SRNC in order to initiate release of indicated RABs. CN starts timer T RABAssgt. CN may request to establish, release or modify one or several (3GPP allows up to 256) RABs at the same time, but only release will be considered here. Then, the message shall contain only following parameters. Parameters: a list of RABs to be released containing RAB ID and Cause for each one. The Cause will be “ Normal Release” for this example.

UE

RNC RANAP

CN RAB Release Request

RANAP

5B. RAB Assignment Request RANAP

RANAP

6B. Release of RAB 7B. RAB Assignment Response RANAP

RANAP

8B. ALCAP Iu Data Transport Bearer Release Not required towards PS domain

Figure 25: RAB Release Procedure

6. (bis) RNC shall be prepared to receive previous message containing RABs to be released at any time and shall always reply to it. RNC shall initiate release of requested RABs through different procedures depending on the connection established. Appropriate RAB release procedures corresponding to those described in section 2.1.7 for RAB establishment are described in following subsections. 7. (bis) RNC shall report to CN with a RAB Assignment Response message the result of all requested RABs: list of RABs released and list of RABs failed to release. This message is sent back to CN as soon as the UE responses to the RNC about the RABs it has been commanded to release. Parameters for released RABs: RAB ID for each RAB and, and if it is required by PS domain, RABs Data Volume Report per RAB (Unsuccessfully Transmitted DL Data Volume and optional Data Volume Reference), and if PS domain and the procedure was initiated by UTRAN, the DL/UL GTP-PDU Sequence Numbers. These two parameters will allow SGSN to restore proper values in case the PDP Context is maintained and the RAB is re-established at a later stage. Parameters for RABs failed to release: RAB ID and Cause IE. This message can optionally send Criticality Diagnostics IE.


Approved 71



8. SRNC initiates release of the Iu Data Transport Bearer between the CN and the SRNC using the ALCAP protocol. This step is not required for PS domain as it was not setup at Call Establishment for PS domain.

The reception of the RAB Assignment Response message informing of RAB release terminates the procedure in the CN. This means corresponding call is released from CN point of view. CN shall stop timer T RABAssgt only if none of the RABs have been queued by UTRAN, which is the case for this example (RABs to be released are not queued, in fact, if any of these RABs were in a queue, they shall be taken out of the queue and released). Next subsections describe appropriate RAB release procedures corresponding to those described in section 2.1.7 for RAB establishment. As described in section 2.1.7 DCH-DCH RAB Release procedure can be done either in a synchronised or unsynchronised manner. It was discussed for Call Establishment Synchronised procedure was necessary; however, for this section any one could be applied. So, both procedures will be described. Due to the complexity of following procedures, numbering will start from 1 for each one, otherwise it would become too ambiguous.

3.1.3.3.1 DCH-DCH RAB Release – Synchronised procedure This procedure is used to prepare a synchronised new configuration of all Radio Links related to one UE-UTRAN connection. In this case, it is triggered in order to release the RAB associated to the Call that has just been released. This procedure will release a RAB on DCH when the RRC connection still uses a DCH after the release and when synchronisation is needed according to section 2.1.7. It is assumed UE is in soft handover and communicates via two Nodes B. One Node B is controlled by SRNC and the other one is controlled by DRNC as depicted in Figure 26. This procedure is quite similar to the DCH – DCH RAB Establishment procedure described in section 2.1.7.1. Then, only relevant difference is that DCH ID for RAB to be deleted is sent now instead of all DCH to add information detailed there. Nevertheless, as it was already pointed out in section 2.1.7.1, this procedure can add, modify and/or release DCHs at the same time for a given UEUTRAN connection. Note: In fact, if synchronised procedure is needed, it is because TFCIs of remaining DCHs will change. This imply then those DCHs shall be reconfigured in this procedure.

Messages 1, 16 and 17 for this procedure are already described above in section 3.1.3.3, steps 5B, 7B and 8B.

2. SRNC requests DRNC to prepare release of DCH carrying the RAB by sending RNSAP Radio Link Reconfiguration Prepare message. Parameters: Allowed Queuing Time (optional), UL and DL DPCH Information (optional), DCH to delete Information (mandatory: DCH ID) and RL Information. Within this message SRNC may also reconfigure (add, modify or delete) any other DCH or DSCH it has with DRNC [see REF 25.423 for more details]. 3. DRNC requests its Node B to prepare release of DCH carrying the RAB by sending NBAP Radio Link Reconfiguration Prepare message (it is really sent by CRNC). Parameters: Node B Communication Context ID, UL and DL DPCH Information (optional), DCH to delete Information (mandatory: DCH ID), RL Information and optional DL Code UMTS Call Flows November 4, 2000

Approved 72



Information as IE FDD DL Channelisation Code Number or the DL Scrambling Code. Within this message DRNC may also reconfigure any other DCH and/or DSCH it has with concerned Node B [see REF 25.433 for more details]. 4. SRNC requests its Node B to prepare release of DCH carrying the RAB by sending NBAP Radio Link Reconfiguration Prepare message (it is really sent by CRNC). Parameters: Node B Communication Context ID, UL and DL DPCH Information (optional), DCH to delete Information (mandatory: DCH ID), RL Information and optional DL Code Information as IE FDD DL Channelisation Code Number or the DL Scrambling Code. Within this message SRNC may also reconfigure any other DCH and/or DSCH it has with concerned Node B [see REF 25.433 for more details]. UE

Node B Dri ft RN S

No de B Serving RNS

Drift RNC

Serving RN C

RANAP

CN

1. RAB Assignment Request RANAP [ R e l ea s e ]

2. Radio Link Reconfiguration Prepare R N S AP [DCH Deletion]

R N S AP N BA P

3. Radio Link Reconfiguration Prepare

N BA P [DCH Deletion] 4. Radio Link Reconfiguration Prepare

NB AP

N BA P

[DCH Deletion] 5 . R a d i o L i n k R e c o n f i gu r a t i o n R e a d y NB AP

N BA P

6. Radio Link Reconfiguration Ready R N S AP

R N S AP

7. Radio Link Reconfiguration Ready

NB AP

N BA P 8. Radio Link Reconfiguration Commit R N S AP R N S AP

N BA P

9. Radio Link Reconfiguration Commit NB AP

1 0 . R a d i o L i n k R e c o n f i g u r a t i o n C o m mi t

NB AP

N BA P

1 1 . DC CH : Radio Bearer Release

RRC

RRC 12. Apply new transport format set 13. DC CH : Radio Bearer Release Complete

RRC

RRC

1 4 . A L C A P I u b D a t a T r a n s p o r t B e a r e r R e l e a se


15. ALCAP Iub Data Transport Bearer Release

RANAP


RANAP

1 7 . A L C A P I u D a t a T r a n s p or t Bearer Release not required towards PS domain

Figure 26: Radio Access Bearer Release - DCH - DCH Release - Synchronised

5. Node B controlled by DRNC shall reserve necessary resources for the new configuration of the Radio Link(s) according to the parameters given in step 3. If this is possible, Node B notifies CRNC that the preparation is ready by sending a NBAP Radio Link Reconfiguration Ready message.


Approved 73



Parameters: CRNC Communication Context ID, RL Information Response and optionally IE Criticality diagnostics. If DRNC is reconfiguring any other channel, it should send corresponding Binding Information (DCH ID, Binding ID, Transport Layer Address); however, no additional information is necessary for DCHs to be deleted. 6. After DRNC receives message in step 5, if the modifications requested in step 2 are allowed by the DRNS, and the DRNS has successfully reserved the required resources for the new configuration of the Radio Link(s), DRNC notifies SRNC that the preparation is ready by sending a RNSAP Radio Link Reconfiguration Ready message. Parameters: RL Information Response (ID and optional UL Maximum and Minimum SIR, which are decided by DRNC), DL Code Information (DL Scrambling Code, FDD DL Channelisation Code Number and optional Transmission Gap Pattern Sequence Information Response), Secondary CCPCH Information (TFCS TFCI, etc.), and optionally IE Criticality diagnostics. If SRNC is reconfiguring any other channel, it should send corresponding information; however, no additional information is necessary for DCHs to be deleted. 7. Node B controlled by SRNC shall reserve necessary resources for the new configuration of the Radio Link(s) according to the parameters given in step 4. If this is possible, Node B notifies CRNC that the preparation is ready by sending a NBAP Radio Link Reconfiguration Ready message. Parameters: CRNC Communication Context ID, RL Information Response, and optionally IE Criticality diagnostics. If DRNC is reconfiguring any other channel, it should send corresponding Binding Information (DCH ID, Binding ID, Transport Layer Address); however, no additional information is necessary for DCHs to be deleted.

Note: Of course, steps 2 through 7 do not have to be performed in a strict sequential manner, but in the logical order. However, it is more time-efficient to perform step 2 before step 4.

At this point in section 2.1.7.1, ALCAP Data Transport Bearer setup and synchronisation is performed for it was the call establishment. This is not needed now because they are already setup. Then, following steps are performed as shown in Figure 26. 8. SRNC sends a RNSAP Radio Link Reconfiguration Commit message to DRNC. DRNC shall switch to the new configuration previously prepared at the CFN requested. Parameters: CFN and optional Active Pattern Sequence Information. 9. DRNC (really CRNC) sends a NBAP Radio Link Reconfiguration Commit message to its Node B. This message is really sent by CRNC to order the Node B to switch to the new configuration, which has just been prepared for the Radio Link(s) within the Node B, at the CFN requested. Parameters: Node B Communication Context ID, CFN and optional Active Pattern Sequence Information. 10. SRNC (really CRNC) sends a NBAP Radio Link Reconfiguration Commit message to its Node B. This message is really sent by CRNC to order the Node B to switch to the new configuration, which has just been prepared for the Radio Link(s) within the Node B at the CFN requested. Parameters: Node B Communication Context ID, CFN and optional Active Pattern Sequence Information. 11. SRNC sends an RRC Radio Bearer Release message to UE. If transport channels are modified in uplink and/or downlink, UTRAN shall set TFCS according to the new transport channels. IE Activation Time is included to indicate when UE shall switch to the new configuration. UMTS Call Flows November 4, 2000

Approved 74



Parameters: UE Information Elements (Integrity Check Info, optional Integrity Protection Mode Info, optional Ciphering Mode Info, Activation Time, DRX indicator, UTRAN DRX Cycle Length Coefficient, optional New U-RNTI and optional New C-RNTI), optional CN Information Info, RB Information Elements (RAB Information to Release List, RAB Information to Release, optional RB Information to be Affected List and RB Information to be Affected), TrCh Information Elements for both UL and DL TrChs, PhyCh Information Elements for both UL and DL Radio Resources. (For more detailed parameters information see [Ref 25.331]). Note: Again, steps 8 through 10 shall be performed in a logical order. Step 11 does need to wait for steps 8 through 10. In fact, [ref. 25.331] specifies UTRAN shall configure new radio links in any new physical channel configuration and start transmission and reception on the new radio links in order to initiate the RRC Radio Bearer Establishment procedure in step 11.

12. At this point, UE shall act upon all received IE as specified in section 8.5.7 of [Ref 25.331]. UE shall turn off the transmitter during the reconfiguration. UE may first release the current physical channel configuration and shall then establish a new physical channel configuration according to the information received in step 11. 13. If reconfiguration succeeds, UE sends RRC Radio Bearer Release Complete message to SRNC. Parameters: UE Information Elements (Integrity Check Info and optional Uplink Integrity Protection Activation Info) and optional RB IE Radio Bearer Uplink Ciphering Activation Time Info. 14. DRNC initiates release of not used resources Iur and Iub Data Transport Bearer using ALCAP protocol. 15. SRNC initiates release of not used resources Iub Data Transport Bearer using ALCAP protocol.

At this point, RAB associated to Call that has just been released is also completely released. UE maintains both RRC and Iu connections in order to support any other ongoing PDP Context/Call.

3.1.3.3.2 DCH-DCH RAB Release – Unsynchronised procedure The procedure described is used to reconfigure 3 all Radio Links related to one UE-UTRAN connection. In this case, it is triggered in order to release the RAB associated to the Call that has just been released. This procedure will release a RAB on DCH when the RRC connection still uses a DCH after the release and when synchronisation is not needed in the cells used by the UE-UTRAN connection according to section 2.1.7. It is assumed UE is in soft handover and communicates via two Nodes B. One Node B is controlled by SRNC and the other one is controlled by DRNC as depicted in Figure 27. Messages 1,4 and 5 for this procedure are already described above in section 3.1.3.3, steps 5B, 7B and 8B. Messages 2 and 3 are exactly the same than messages 11 and 13 for the DCH-DCH RAB 3 If

only DCH is to be deleted, but there are still any more channels on concerned Radio Link, a Radio Link Reconfiguration procedure as described here is performed. In case UTRAN decided to release complete Radio Link towards the UE, the Radio Link Deletion procedure would take place. An example for the latter case will be described in next section.


Approved 75



Release – Synchronised procedure described above. The only different is that they are performed now before Radio Link(s) reconfiguration takes place, for synchronization is not needed. Then, UTRAN initiates Radio Link(s) reconfiguration for given UE-UTRAN connection as following: 6. SRNC requests DRNC to release DCH carrying the RAB by sending RNSAP Radio Link Reconfiguration Request message. Parameters: optional Allowed Queuing Time, optional UL and DL DPCH Information, DCH to delete Information (mandatory: DCH ID), and optional Transmission Gap Pattern Sequence Number. Within this message SRNC may also reconfigure any other DCH it has with DRNC for related UE [see REF 25.423 for more details]. UE

Node B Drift RNS

Node B Serving RNS

Drift RNC

Serving RNC

RANAP

CN


RANAP

[Release] 2. DCCH Radio Bearer Release

RRC

RRC 3. DCCH Radio Bearer Release Complete

RRC

RRC

RANAP


RANAP

5. ALCAP Iu Data Transport Bearer Release not required towards PS domain 6. RL Reconfiguration Request

RNSAP

RNSAP

[DCH Deletion] 7. RL Reconfiguration Request NBAP

NBAP [DCH Deletion] 8. RL Reconfiguration Request

NBAP

NBAP [DCH Deletion]

NBAP

9. Radio Link Reconfiguration Response NBAP

RNSAP

10. RL Reconfiguration Response

RNSAP

11. Radio Link Reconfiguration Response

NBAP

NBAP




Figure 27: Radio Access Bearer Release - DCH - DCH Release - Unsynchronised

7. DRNC requests its Node B to release DCH carrying the RAB by sending RBAP Radio Link Reconfiguration Request message (it is really sent by CRNC). Parameters: Node B Communication Context ID, UL and DL DPCH Information (optional), DCH to delete Information (mandatory: DCH ID), RL Information and optional DL Code Information as IE FDD DL Channelisation Code Number or the DL Scrambling Code. Within this message DRNC may also reconfigure any other DCH it has with concerned Node B [see REF 25.433 for more details].


Approved 76



8. SRNC requests its Node B to prepare release of DCH carrying the RAB by sending RBAP Radio Link Reconfiguration Request message (it is really sent by CRNC). Parameters: Node B Communication Context ID, UL and DL DPCH Information (optional), DCH to delete Information (mandatory: DCH ID), RL Information and optional DL Code Information as IE FDD DL Channelisation Code Number or the DL Scrambling Code. Within this message DRNC may also reconfigure any other DCH it has with concerned Node B [see REF 25.433 for more details]. 9. Node B controlled by DRNC shall reserve necessary resources for the new configuration of the Radio Link(s) according to the parameters given in step 7. If this is possible, Node B notifies CRNC that the preparation is ready by sending a NBAP Radio Link Reconfiguration Response message. Parameters: CRNC Communication Context ID, RL Information Response, and optionally IE Criticality diagnostics. If DRNC is reconfiguring any other channel, it should send corresponding Binding Information (DCH ID, Binding ID, Transport Layer Address); however, no additional information is necessary for DCHs to be deleted. 10. After DRNC receives message in step 9, if the modifications requested in step 4 are allowed by the DRNS, and the DRNS has successfully reserved the required resources for the new configuration of the Radio Link(s), DRNC notifies SRNC that the preparation is ready by sending a RNSAP Radio Link Reconfiguration Response message. Parameters: RL Information Response (ID and optional UL Maximum and Minimum SIR, which are decided by DRNC), Secondary CCPCH Information (DL Scrambling Code, FDD DL Channelisation Code Number, TFCS, etc.), DL Code Information (DL Scrambling Code, FDD DL Channelisation Code Number and optional Transmission Gap Pattern Sequence Number) and optionally IE Criticality diagnostics. If SRNC is reconfiguring any other channel, it should send corresponding Response Information (DCH ID, Binding ID, Transport Layer Address); however, no additional information is necessary for DCHs to be deleted. 11. Node B controlled by SRNC shall reserve necessary resources for the new configuration of the Radio Link(s) according to the parameters given in step 8. If this is possible, Node B notifies CRNC that the preparation is ready by sending a NBAP Radio Link Reconfiguration Response message. Parameters: CRNC Communication Context ID, RL Information Response, and optionally IE Criticality diagnostics. If SRNC is reconfiguring any other channel, it should send corresponding Binding Information (DCH ID, Binding ID, Transport Layer Address); however, no additional information is necessary for DCHs to be deleted. Note: Of course, steps 6 through 11 do not have to be performed in a strict sequential manner, but in the logical order. However, it is more time-efficient to perform step 6 before step 8.

12. DRNC initiates release of not used resources Iur and Iub Data Transport Bearer using ALCAP protocol. 13. SRNC initiates release of not used resources Iub Data Transport Bearer using ALCAP protocol.


3.1.3.3.3 RACH/FACH – DCH RAB Release procedure


Approved 77



In this case, an RRC connection is established on RACH/FACH, and RAB is established on a DCH. In order to describe the Radio Link Deletion procedure, it will be assumed UTRAN decides to release complete RL corresponding to DCH to be released, otherwise a Radio Link Reconfiguration would take place. Then, the Radio Link Deletion procedure will be described. It will be assumed some Radio Link(s) remain and RRC connection still uses RACH/FACH after the release. There is no need to synchronise the time of switching from an old to a new configuration. So, this procedure is done in an unsynchronised manner and requires less signalling. UE cannot be in handover when an RRC connection on RACH/FACH is established. So, DRNC does not participate in this procedure as depicted in Figure 28.

UE

Node B Drift RNS

Node B Serving RNS

Drift RNC

Serving RNC

RANAP

CN


RANAP

[Release]

RRC

RRC

2. DCCH Radio Bearer Release RRC 3. DCCH Radio Bearer Release Complete RRC

RANAP


RANAP

5. ALCAP Iu Data Transport Bearer Release not required towards PS domain

NBAP

NBAP

6. Radio Link Deletion Request

NBAP

7. Radio Link Deletion Response NBAP


Figure 28: Radio Access Bearer Release – RACH/FACH - DCH Release - Unsynchronised

Messages 1 through 5 are exactly the same than in previous case, section 3.1.3.3.2 DCH-DCH RAB Release – Unsynchronised procedure. Then, UTRAN initiates Radio Link Deletion for given UE-UTRAN connection with following messages: 6. SRNC (really CRNC) requests its Node B to delete given Radio Link by sending the NBAP Radio Link Deletion Request message. Parameters: Node B Communication Context ID and Radio Link ID for each RL to be released. 7. Upon reception of this message, the Node B shall delete the Radio Link(s) identified in the message and release all associated resources and respond to the CRNC with the NBAP Radio Link Deletion Response message. Parameters: CRNC Communication Context ID and optionally Criticality Diagnostics.


Approved 78



8. SRNC initiates release of not used resources Iub Data Transport Bearer using ALCAP protocol.


3.1.3.3.4 RACH/FACH – RACH/FACH RAB Release procedure In this case, both RRC connection and RAB are established on RACH/FACH. This procedure requires even less signalling than the previous procedure, for there is not even a Radio Link established. Then, only messages 1 through 5, which are exactly the same than in previous cases and are already described, apply for this case. Since there is no reconfiguration of common transport channels formats, this procedure is done in an unsynchronised manner. UE cannot be in handover when an RRC connection on RACH/FACH is established. So, DRNC does not participate in this procedure as depicted in Figure 29.

UE

Node B Drift RNS

Node B Serving RNS

Drift RNC

Serving RNC

RANAP

CN


RANAP

[Release] 2. DCCH Radio Bearer Release

RRC

RRC 3. DCCH Radio Bearer Release Complete

RRC

RRC

RANAP


RANAP

5. ALCAP Iu Data Transport Bearer Release not required towards PS domain

Figure 29: Radio Access Bearer Release - RACH/FACH - RACH/FACH Release



Approved 79



3.2 Mobile Terminated Call Release 3.2.1 PDP Context Deactivation procedure (PS domain only) For PS domain, an established call means UE has a PDP context activated and user data can be transmitted/received through the PS network. At any point, network may decide to deactivate the PDP context for any network reason (timer expiration, network failure…). Both SGSN and GGSN may initiate the procedure. As depicted in Figure 30 and Figure 31, messages are exactly the same for both procedures. The only difference is which device sends every message and when every message is sent. However, both procedures will be described separately for better understanding. In any case, the Delete PDP Context Request takes precedence over any other ongoing Tunnel Management message. So, Delete PDP Context will always be performed regardless PDP state.

UE

UTRAN

3G-SGSN

3G-GGSN

C1 1. Delete PDP Context Request 2. Delete PDP Context Response 3. Direct Transfer : Deactivate PDP Context Request 4. Direct Transfer: Deactivate PDP Context Accept


Figure 30: PDP Context Deactivation Initi ated by SGSN procedure

When procedure is initiated by SGSN as depicted in Figure 30, the following steps take place: 1. SGSN sends a Delete PDP Context Request message to the GGSN. Parameters: NSAPI, optional Tear Down Indicator IE, which may be included to indicate that all active PDP context sharing the same PDP address as the PDP context associated with this specific NSAPI shall be deactivated. If it is not included, only this PDP context will be deactivated. In this example, tear down indicator will be considered to be requested. Finally, this message may also include optional Private Extension IE for vendor/operator specifics. 2. GGSN shall be prepared to receive previous message at any time and shall always reply regardless if the PDP context exists or not by sending a Delete PDP Context Response back to SGSN. In this example, PDP context exists and GGSN removes it. Parameters: Cause (set to “ Request Accepted” in this example) and Private Extension for vendor/operator specifics. 3. SGSN does not have to wait for the Delete PDP Context Response message from GGSN before sending a Deactivate PDP Context Request message to the UE. This message is sent by means of the Direct Transfer described in section 2.1.3. SGSN starts timer T3395.


Approved 80



Parameters: Session Management Cause (“ Regular Deactivation”, “network failure” or “reactivation requested”) and optional Tear Down Indicator. 4. UE removes PDP context(s) and replies to SGSN with a Deactivate PDP Context Accept message. Upon reception of this message, SGSN shall stop timer T3395. Parameters: none specific IE.

UE

UTRAN

3G-SGSN

3G-GGSN

1. Delete PDP Context Request

C1 2. Direct Transfer : Deactivate PDP Context Request 3. Direct Transfer: Deactivate PDP Context Accept 4. Delete PDP Context Response


Figure 31: PDP Context Deactivation Initi ated by GGSN procedure

When procedure is initiated by GGSN as depicted in Figure 31, the following steps take place: 1. GGSN sends a Delete PDP Context Request message to the SGSN. Parameters: NSAPI, optional Tear Down Indicator IE, which may be included to indicate that all active PDP context sharing the same PDP address as the PDP context associated with this specific NSAPI shall be deactivated. If it is not included, only this PDP context will be deactivated. In this example, tear down indicator will be considered to be requested. Finally, this message may also include optional Private Extension IE for vendor/operator specifics. 2. SGSN sends a Deactivate PDP Context Request message to the UE. This message is sent by means of the Direct Transfer described in section 2.1.3. SGSN starts timer T3395. Parameters: Session Management Cause (“ Regular Deactivation”, “network failure” or “reactivation requested”) and optional Tear Down Indicator. 3. UE removes PDP context(s) and replies to SGSN with a Deactivate PDP Context Accept message. Upon reception of this message, SGSN shall stop timer T3395. Parameters: none specific IE. 4. SGSN does not have to wait for the Deactivate PDP Context Accept message from UE before sending the Delete PDP Context Response message back to GGSN. Parameters: Cause (set to “ Request Accepted” in this example) and Private Extension for vendor/operator specifics. At this point for both cases, SGSN shall initiate the release of UTRAN resources associated with this PDP context as described in section 3.1.3. It is assumed UE was an active user and all resources (Iu signalling, RAB, RRC connection) were allocated. So, procedures to release all resources will apply as for the Mobile Originated Call Release process.


Approved 81



For an UE with GPRS-CSI defined, CAMEL interaction may be performed, see referenced procedures procedures in in 3G TS 23.078: C1) CAMEL-GPRS-Deactivate-PDP-Context.

3.2.2 Call Clearing procedure (CS domain only) For CS domain, an established call means UE has a circuit-switched end-end connection established with a remote user. At any point, remote user decides transaction is completed and wants to clear the CS call. Then, called MSC will receive an ISUP REL (Release) message from calling MSC (step 2 in the Call Clearing procedure (CS domain only) for Mobile Originated Call Release process). process). In addition, addition, network network may initiate initiate call call clearing clearing for any other other particular network network reason such such as communication communication failure. [Ref 24.008], section 5.4.2, defines some exception conditions that allow different clearing procedures. procedures. Some Some conditio conditions ns will will allow allow the introductio introduction n of shorter shorter call clearing clearing procedures procedures in the future. Apart from these exception conditions, the call control entity of the network shall initiate clearing by sending a Disconnect message. Three main possibilities for Call Clearing will be described in this section: A. Network initiates initiates clearing by sending sending Release message B. Network initiates clearing clearing by sending Disconnect Disconnect message to an UE UE that does not support the “ Prolonged Prolonged Clearing Procedure” C. Network initiates clearing clearing by sending Disconnect Disconnect message message to an UE that does support the “ Prolonged Prolonged Clearing Procedure”

Ø

Case A

Network Network may initiate clearing clearing by sendin sending g a Release message, corresponding to step 3 in the Call Clearing procedure (CS domain only) for Mobile Originated Call Release process. If so, call clearing procedure procedure described described in section 3.1 will will also apply now for the Mobile Terminated Terminated Call Release. Release. This case is depicted in Figure 32 and a nd described below. below.

UE

UTRAN

Called MSC

Call Callin in MSC MSC

1. ISUP REL 2. Direct 2. Direct Transfer: Release Transfer: Release 3. Direct 3. Direct Transfer: Release Transfer: Release Complete


Figure 32: Call Clearing Initiated by MSC with Release message m essage procedure


Approved 82



1. Called MSC may may receive an ISUP REL (Release) message from calling MSC (step 2 in the Call Clearing procedure (CS domain only) for Mobile Originated Call Release process) as an indication for Call Clearing. 2. MSC stops all running call control timers, timers, sends sends a Release message to its peer entity in the UE, star ts timer T308 T3 08 and enters “ Release Release Request” Request” state. It is necessary to notice this message has got only local significance; however, it may carry information of global significance when when used as the first call clearing message, which is the case now. Parameters (all optional IEs): Cause, Second Cause, Facility and User-User. 3. Upon reception reception of Release message, message, UE shall stop all running call control control timers, send a connection and return retur n “ Null” Null” state. stat e. Release Complete message to the network, release MM connection Parameters: only optional Facility and SS Version may apply to this example. Upon reception of Release Complete message, MSC shall stop timer T308, release MM connection connection and return to “ Null” Null” state. At this point, MSC shall initiate the release of UTRAN resources associated with this call as described in section 3.1.3. The release of the MM connection is done locally in the MM sublayer for both UE and MSC, i.e. no MM message is sent over the radio interface for this purpose. If all MM connections are released by its CM entitie entities, s, UE starts timer timer T3240 and enters enters “ Wait for Network Network Comman Command”, d”, expectin expecting g UTRAN Resources Release. However, network may decide to maintain UTRAN resources in order to establish another MM connection. In case none MM connection is established and UTRAN resources are not released within time controlled by T3240 (i.e. timer expires), UE shall abort the radio connection.

Ø

Case B

Network Network initiates initiates call clearing clearing by sendin sending g a Disconne Disconnect ct message message to an UE that does does not support the “ Prolonged Prolonged Clearing Procedure”. Procedure”. Figure 33 shows this scenario. 1. Called MSC may may receive an ISUP REL (Release) message from calling MSC (step 2 in the Call Clearing procedure (CS domain only) for Mobile Originated Call Release process) as an indication for Call Clearing. 2. Call Control entity of MSC decide decidess to send a Disconnect message to its peer entity of the UE. MSC enters the “Disconnect Indication” state and starts timer T306, if in-band tones/announcemen tones/announcements ts are a re provide pr ovided, d, or timer T305 otherwise. Parameters: mandatory Cause IE and optional Progress Indicator (#8 -“in-band information or appropriate pattern now available”-, included if in-band tones/announcements are provided, or any other number otherwise) and User-User IEs. 3. Upon reception of of Disconnect Disconnect message by UE in any state except except the “ Null” Null” state, the “ Disconnect Disconnect Indication” Indication” state and the “ Release Release Request” Request” state, st ate, and depending on the reception reception of progress indicator #8, UE has two possibilities: a. If progress indicator indicator #8 is not present, UE shall shall stop all running call control timers, timers, send Release message, start timer T308, and enter the “Release Request” state. b. If progress indicator indicator #8 is present, present, UE shall attach appropriate speech speech channel channel for connecting the in-band tone/announcements, if connected and not attached yet, and enter the “ Disconnect Disconnect Indication” Indication” state. UE will remain in this state until upper layers request the clearing of the call. Then, or if there were not speech channel connected, UE shall act as in case a. Parameters (all optional IEs): Cause, Second Cause, Facility, User-User and SS version. UMTS Call Flows Novembe Novemberr 4, 2000

Approved 83



4. The Call Control entity of the network network in any state except the “ Null” Null” state and the “ Release Release Request” state, shall, upon reception of Release message, stop all running call control timers (including T305 or T306), send a Release Complete message, release the MM connection and return to the “Null” state. Parameters(all optional IEs): Cause, Facility and User-User. Note: In case T305 or T306 expires, MSC shall send Release message and proceed as in Case A. If it was T305 that expired, Release message shall contain Second Cause IE set to “Recovery on timer expiry”.

The Call Control entity of the UE in any state, shall, upon reception of Release Complete message, stop all running call control timers (including T308), release the MM connection and return to the “Null” state. At this point, MSC shall initiate the release of UTRAN resources associated with this call as described in section 3.1.3. The release of the MM connection is done locally in the MM sublayer for both UE and MSC, i.e. no MM message is sent over the radio interface for this purpose. If all MM connections are released by its CM entitie entities, s, UE starts timer timer T3240 and enters enters “ Wait for Network Network Comman Command”, d”, expecting expecting UTRAN Resources Release. However, network may decide to maintain UTRAN resources in order to establish another MM connection. In case none MM connection is established and UTRAN resources are not released within time controlled by T3240 (i.e. timer expires), UE shall abort the radio connection.

UE

UTRAN

Called MSC

Call Callin in MSC MSC

1. ISUP REL 2. Direct Transfer : Disconnect 3. Direct 3. Direct Transfer: Release Transfer: Release 4. Direct 4. Direct Transfer: Release Transfer: Release Complete


Figure 33: Call Clearing I nitiated by MSC with Disconnect message procedure Ø

Case C

Network Network initiates initiates call clearing clearing by sendin sending g a Disconne Disconnect ct message message to an UE that does does support the “ Prolonged Prolonged Clearing Procedure”. Procedure”. Then, Call Completion Busy Subscriber (CCBS) (CC BS) network feature 4 must be taken into account at the Call Release process . Figure 33 is also valid for this case, for messages are the same and the only difference is in parameters messages contain. So, only these differences will be described below: 2. Call Control entity of MSC sends sends Disconnect message to its peer entity of the UE including Allowed Allowed Actions IE set to t o “ Activation Activation of CCBS is possible” if CCBS is possible. Otherwise, 4 CCBS

was not considered at CS domain Call Estab lishment. lishment.


Approved 84



Allowed Actions IE is optional and, if sent, it shall be set to “ CCBS activation is not possible”. In the former case, MSC shall start timer T338, which shall not be greater than T306 in case in-band tones/announcements are provided. 3. UE shall act as in case B regarding progress indicator #8 in any case. In addition, if Allowed Actions IE is not included in previous message and/or CCBS is not possible, UE also acts exactly in the same way than in case B. However, if Allowed Actions IE indicates “ Activation of CCBS is possible”, UE shall pass this indication to the upper layer, enter the “ Disconnect Indication” state, stop all running control timers and await a response from the upper layer. This response may be any of the following two: a.

If upper layers request the clearing of the call, UE shall stop all running call control timers, send Release message, start timer T308, and enter the “ Release Request” state.

b. If upper layers request that the CCBS activation is to be attempted, UE shall send Release message containing a Facility IE including an Invoke=CCBSRequest to the network. UE shall also stop all running call control timers, start timer T308 and enter the “ Release Request” state. Parameters (all optional IEs): Cause, Second Cause, Facility, User-User and SS version. 4. The Call Control entity of the network in any state except the “Null” state and the “Release Request” state, shall, upon reception of Release message, act exactly as in case B if it does not support CCBS activation or if CCBS has not been requested. In case CCBS is requested and network supports it, Call Control entity of the network shall stop all running call control timers (including T305, T306 or T338), then attempt to activate the Recall; then send a Release Complete message, release the MM connection and return to the “ Null” state. Parameters(all optional IEs): Cause, Facility and User-User. Note: In case T305, T306 or T338 expires, MSC shall send Release message and proceed as in Case A. If it was T305 that expired, Release message shall contain Second Cause IE set to “ Recovery on timer expiry”.

The Call Control entity of the UE in any state, shall, upon reception of Release Complete message, stop all running call control timers (including T308), release the MM connection and return to the “Null” state. At this point, MSC shall initiate the release of UTRAN resources associated with this call as described in section 3.1.3. The release of the MM connection is done locally in the MM sublayer for both UE and MSC, i.e. no MM message is sent over the radio interface for this purpose. If all MM connections are released by its CM entities, UE starts timer T3240 and enters “ Wait for Network Command”, expecting UTRAN Resources Release. However, network may decide to maintain UTRAN resources in order to establish another MM connection. In case none MM connection is established and UTRAN resources are not released within time controlled by T3240 (i.e. timer expires), UE shall abort the radio connection.


Approved 85



4 Soft Handover Soft Handover is the technology that allows a call to be served by multiple cells controlled by multiple cell sites (Nodes B) at the same time. These Nodes B may belong to several RNCs, which introduces the concepts of SRNC and DRNC as explained in section 1.3. Soft Handover eliminates ping-pong effect, reduces number of dropped calls and reduces interferences, which increases capacity. Then, it is good to have UE in Soft Handover. In fact, based on IS-95 experience, it is known more than 60% of active UEs will be in Soft Handover. [Ref. 25.401] indicates the possibility of both UE/Network initiated handovers. Therefore, the handover function may be either controlled by the network, or independently by UE. However, R0 and R1 will only implement network-initiated handovers, and it is believed within UE Initiated handover will not exist in UMTS. Therefore, it will be assumed only SRNC takes the decision to perform a Handover. In Soft Handover, radio links are added and deleted in such manner that the UE always keeps at least one radio link to the UTRAN. The main cause that triggers a Soft Handover procedure is the Strength Level, i.e., radio links are added and deleted based on measurements reports 5 by the UE on relative downlink signal strength. As discussed in section 2.1.1 RRC Connection Establishment procedures, it is possible UE sends measurements in an RRC Connection Request message. Based on IS-95 experience, it is desirable to place an UE into Soft Handover as quickly as possible. Then, it would be desirable UTRAN adds soft handover legs even before the RAB was established. However, this is only possible if the RRC connection is established on DCH. In release R0, RRC connection on DCH is not supported yet. Then, Soft Handover will not be possible until a RAB on DCH is set up. As soon as RRC connection on DCH establishment is available, further studies will be required on the field in order to find out the optimal procedures. In Soft Handover, SRNC maintains always Iu connections to CN domains, while UE adds/deletes radio links to both SRNC and DRNC. When radio links are added, the macro-diversity splitting/selection function in the appropriate network elements are also instructed to begin diversity processing with the new radio link. Likewise, when radio links are deleted, the macro diversity splitting/selection function in the appropriate network elements are also instructed to stop diversity processing with that deleted radio link. The macro-diversity splitting/selection function is needed to perform selection of upstream user plane information toward the Iu interface, and duplication of downstream user-plane information toward the Iub or Iur. This function always resides in SRNC and may also reside in DRNC. For R0 it will reside only in the SRNC, though in R1 it will be supported in both SRNC and DRNC. See [Ref UTRAN SFRAS, section 2.8.3] for more details on this function. This section will describe different procedures for adding and/or deleting radio links between UE and UTRAN. These procedures apply only to intra-frequency FDD mode and do not affect at all to the Iu interface and the CN.

5 Measurement

report is an RRC function between UE and UTRAN that is out of the scope of this section.


Approved 86



4.1 Radio Link Addition (Branch Addition) Due to received measurements reports, SRNC takes the decision to setup a new radio link(s) via a Node B controlled by another RNC (DRNC) than the SRNC. Procedure is depicted in Figure 34. As shown in the figure, UTRAN shall prepare new additional radio link(s) in the UTRAN prior to instruct the UE to update its Active Set with the new radio link(s). It is assumed this is the first radio link to be established via this DRNC, thus macro-diversity combining/splitting within DRNC would not be performed, if supported. Moreover, a new Iur signalling connection, which will be used for all RNSAP signalling related to this UE, will be established. In addition, the Radio Link Setup Procedure will be performed for this first radio link. If this were not the first radio link to the concerning UE via this DRNC, Radio Link Addition procedure would be performed instead. 1. SRNC takes the decision to setup the new radio link and requests DRNC for radio resources by sending RNSAP Radio Link Setup Request message. As this is assumed to be the first radio link via the DRNC for this UE, this message triggers the establishment of a new Iur signalling connection, which will be used for all RNSAP signalling related to this UE. Parameters: S-RNTI, D-RNTI if existing (which is not the case, for there is not context in DRNC for this UE yet), optional Allowed Queuing Time, UL and DL DPCH Information (TFCS, UL Scrambling Code, etc.), DCH Information (general: Payload CRC Presence Indicator, UL FP Mode, ToAWS, ToAWE; specific: DCH ID, TrCh Source Statistics Descriptor, DL/UL Transport Format Set, DL/UL BLER, Allocation/Retention Priority, Frame Handling Priority, QE-Selector and DRAC Control), DSCH Information (DSCH ID, TrCh Source Statistics Descriptor, Transport Format Set, Allocation/Retention Priority, Scheduling Priority Indicator, BLER, PDSCH RL ID and TFCS), RL Information (RL ID, CID, First RLS Indicator, Frame Offset, Chip Offset, etc.), and optional Transmission Gap Pattern Sequence Information and Active Pattern Sequence Information IEs [See REF 25.423 for more details]. 2. If requested resources are available, DRNC sends NBAP Radio Link Setup Request message to concerned Node B (this message is really sent by corresponding CRNC). This and following message will establish a new Communication Context for UE between CRNC and the Node B. DRNC may allocate a new D-RNTI that will be sent back to SRNC in step 4. Parameters: CRNC Communication Context ID, UL and DL DPCH Information (TFCS, UL Scrambling Code, etc.), DCH Information (general: Payload CRC Presence Indicator, UL FP Mode, ToAWS, ToAWE; specific: DCH ID, DL/UL Transport Format Set, Frame Handling Priority and QE-Selector), DSCH Information (DSCH ID, Transport Format Set, Frame Handling Priority, ToAWS and ToAWE), RL Information (RL ID, C-ID, First RLS Indicator, Frame Offset, Chip Offset, DL Code Information, Power control information etc.), and optional Transmission Gap Pattern Sequence Information and Active Pattern Sequence Information IEs. [See REF 25.433 for more details]. 3. Node B shall establish new Radio Link(s) according to received parameters. If configuration succeeds, Node B responses to CRNC with NBAP Radio Link Setup Response message. Node B is now able to start UL physical reception on the new radio link (though UE will not transmit anything yet). Parameters: CRNC Communication Context ID, Node B Communication Context ID, Communication Control Port ID, RL Information Response IEs (RL ID, RL Set ID, UL Interference Level, DCH/DSCH IDs, Transport layer addressing information -AAL2 address, AAL2 Binding Identity for the Iub Data Transport Bearer–, etc.), and optional Criticality Diagnostics. [See REF 25.433 for more details]. UMTS Call Flows November 4, 2000

Approved 87



UE


Drift RNC

Serving RNC

Decision to setup new RL

RNSAP

N B A P

2. Radio Link Setup Request


RNSAP

NBAP

Start RX 3. Radio Link Setup Response

N B A P

NBAP

RNSAP

5. ALCAP Iub Bearer Setup

DCH-FP

DCH-FP


RNSAP


6. Downlink Synchronisation

6. Uplink Synchronisation

DCH-FP

DCH-FP

Start TX 7. D C C H : A c t i v e S e t Up d a t e RRC

RRC [Radio Link Addition] 8. DC C H : A c t i v e S e t U p d a t e C o m p l e t e RRC

RRC

Figure 34: Soft Handover - Radio Link Addition (Branch Addition)

4. Upon reception of previous message, DRNC sends back a RNSAP Radio Link Setup Response message to SRNC. Parameters: RL Information Response (as RL ID, RL Set ID, SAI, UL Interference Level, Secondary CCPCH Info, DL Code Information, DCH and DSCH Information Response and Neighbouring Cell Information) and optional UL and DL SIR Target and Critically Diagnostics. If there was not previous UE Context for this UE in the DRNC, DRNC shall also include in the message the new D-RNTI and CN PS/CS Domain Identifiers to indicate CN Domain nodes Target RNC is connected to (using LAC and RAC of the current cell). 5. As soon as SRNC receives previous message, it can initiate setup of Iur/Iub Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iur/Iub Data Transport Bearer to DCH. This step may be repeated for each Iur/Iub Data Transport Bearer to be setup.


Approved 88



6. (FDD only) Node B and SRNC establish synchronism for the Iub and Iur Data Transport Bearers, relative to already existing radio link(s). This is done by means of the appropriate DCH Frame Protocol (DCH FP) Downlink Synchronisation and Uplink Synchronisation frames. Then, Node B is ready to start DL physical transmission. 7. At this moment, resources are ready. Then SRNC sends RRC Active Set Update (Radio Link Addition) message to UE on DCCH in order to update the active set of the connections between the UE and UTRAN. The UE should keep on using the old Radio Link(s) and transmitting while allocating the new Radio Link(s). Parameters: UE IEs (Integrity Check Info, Activation Time and optional Integrity Protection Mode Info, Ciphering Mode Info and New U-RNTI), optional CN Information Info IE, RB IEs (PDCP information for each RAB) and DL/UL Physical Channels IEs (as Radio Link Addition Information, where Radio Link(s) to be added are identified). 8. Upon reception of previous message, UE shall add indicated Radio Link(s) and update its configuration (U-RNTI identity, Transport Format Set, etc.), if necessary. Then, UE acknowledges new Radio Link establishment with RRC Active Set Update Complete message. Parameters: UE IEs (Integrity Check Info, and optional UL Integrity Protection Activation Info) and RB IEs (PDCP information for each RAB and optional RB UL Ciphering Activation Time Info).

At this point, the procedure is ended. A new Radio Link(s) is/are established and the new Active Set of connections between UE and UTRAN is being used on both sides.

4.2 Radio Link Deletion (Branch Deletion) Due to received measurements reports, SRNC takes the decision to delete an old radio link(s) via a Node B controlled by another RNC (DRNC) than the SRNC. Procedure is depicted in Figure 35. SRNC first updates UE-UTRAN connections Active Set and then releases radio resources in the UTRAN. 1. SRNC sends RRC Active Set Update (Radio Link Deletion) message to UE on DCCH in order to update the active set of the connections between the UE and UTRAN. In this case, message will indicate old radio link(s) to be removed. Parameters: UE IEs (Integrity Check Info, Activation Time and optional Integrity Protection Mode Info, Ciphering Mode Info and New U-RNTI), optional CN Information Info IE, RB IEs (PDCP information for each RAB) and DL/UL Physical Channels IEs (as Radio Link Removal Information, where Radio Link(s) to be removed are identified). 2. Upon reception of previous message, UE shall deactivate DL reception via indicated old Radio Link(s) and update its configuration (U-RNTI identity, Transport Format Set, etc.), if necessary. Then, UE acknowledges old Radio Link deletion with RRC Active Set Update Complete message. From now on, the new connections Active Set is used on both sides. Parameters: UE IEs (Integrity Check Info, and optional UL Integrity Protection Activation Info) and RB IEs (PDCP information for each RAB and optional RB UL Ciphering Activation Time Info). 3. When UTRAN receipts Active Set Update Complete message, UTRAN may remove radio link(s) that were indicated to remove in step 1. SRNC requests DRNC to release


Approved 89



corresponding radio link(s) towards UE with the RNSAP Radio Link Deletion Request message. Parameters: Radio Link ID for each RL to be released. UE


Drift RN C

Serving RN C

Decision to delete old RL

1. DC C H : Active Set Update RR C

RR C [Radio Link Deletion] 2. DC C H : A c t i v e S e t U p d a t e C o m p l e t e RR C

RR C

R N S AP

N B A P

N B A P



3. Radio Link Deletion Request R N S AP

N BAP

NBAP

Stop RX and TX R N S AP

7 . A L C A P I u b B e a r e r R e le a s e

6. Ra dio Link Deletion Response R NS AP

ALCA P Iur Bearer Release

Figure 35: Soft Handover - Radio Link Deletion (Branch Deletion)

4. Upon reception of this message, DRNC shall initiate deletion of all radio links identified in the message for given UE by sending the NBAP Radio Link Deletion Request message to its Node B. Parameters: Node B Communication Context ID and Radio Link ID for each RL to be released. 5. Upon reception of Radio Link Deletion Request message, the Node B controlled by DRNC shall delete the Radio Link(s) identified in the message and release all associated resources and respond to the CRNC with the NBAP Radio Link Deletion Response message. At this point, resources are deallocated and both physical transmission and reception are stopped for related radio link(s), though UE should not be using it from step 2. Parameters: CRNC Communication Context ID and optionally Criticality Diagnostics. 6. Upon reception of Radio Link Deletion Response message from its Node B, DRNC shall respond to the SRNC with the RNSAP Radio Link Deletion Response message. In case all radio links for the UE were deleted, DRNC should also release the UE context, unless the UE were using common resources in the DRNS. Parameters: only optionally Criticality Diagnostics IE. 7. DRNC initiates release of not used resources Iur and Iub Data Transport Bearer using ALCAP protocol. UMTS Call Flows November 4, 2000

Approved 90



At this point, all UTRAN resources associated to Radio Link that has just been released are also completely released. The procedure is ended.

4.3 Radio Link Addition & Deletion (Branch Addition & Deletion - simultaneously) Due to received measurements reports, UTRAN takes the decision to delete a radio link(s) and add a new one(s). The simultaneous Radio Link Addition & Deletion procedure is needed when the maximum number of branches allowed for the macro-diversity set has already been reached. SRNC shall first prepare new additional radio link(s) in the UTRAN and then updates UE-UTRAN connections Active Set. Finally, UTRAN releases not used radio resources. In this example, it will be considered UTRAN deletes a radio link belonging to a Node B controlled by the SRNC, and establishes a new radio link via a Node B controlled by another RNC (DRNC) than the SRNC. It will be considered there is already at least one Radio Link established to the concerning UE via this DRNC. Then, RNSAP Radio Link Addition procedure will be performed instead of the Radio Link Setup procedure described in section 4.1 Radio Link Addition (Branch Addition). However, it will be considered the Node B is a new Node B, thus there is not Communication Context for concerning UE between DRNC and the new Node B. Therefore, NBAP Radio Link Setup procedure will be performed as in section 4.1. If there were already a Communication Context established (i.e., this were not the first radio link for concerning UE in the Node B), the NBAP Radio Link Addition procedure would be used. This example is depicted in Figure 36. 1. SRNC takes the decision to setup new radio link(s) and delete old one(s) as explained above. Then, SRNC requests DRNC for radio resources by sending RNSAP Radio Link Addition Request message. Parameters: UL SIR Target, RL Information (RL ID, C-ID, Frame Offset, Chip Offset, Diversity Control Field, etc.), and optional Active Pattern Sequence Information [See REF 25.423 for more details]. 2. If requested resources are available, DRNC sends NBAP Radio Link Setup Request message to new Node B (this message is really sent by corresponding CRNC). This and following message will establish a new Communication Context for UE between CRNC and the Node B. Parameters: CRNC Communication Context ID, UL and DL DPCH Information (TFCS, UL Scrambling Code, etc.), DCH Information (general: Payload CRC Presence Indicator, UL FP Mode, ToAWS, ToAWE; specific: DCH ID, DL/UL Transport Format Set, Frame Handling Priority and QE-Selector), DSCH Information (DSCH ID, Transport Format Set, Frame Handling Priority, ToAWS and ToAWE), RL Information (RL ID, C-ID, First RLS Indicator, Frame Offset, Chip Offset, DL Code Information, Power control information etc.), and optional Transmission Gap Pattern Sequence Information and Active Pattern Sequence Information IEs. [See REF 25.433 for more details]. 3. Node B shall establish new Radio Link(s) according to received parameters. If configuration succeeds, Node B responses to CRNC with NBAP Radio Link Setup Response message. Node B is now able to start UL physical reception on the new radio link (though UE will not transmit anything yet). Parameters: CRNC Communication Context ID, Node B Communication Context ID, Communication Control Port ID, RL Information Response IEs (RL ID, RL Set ID, UL UMTS Call Flows November 4, 2000

Approved 91



Interference Level, DCH/DSCH IDs, Transport layer addressing information -AAL2 address, AAL2 Binding Identity for the Iub Data Transport Bearer–, etc.), and optional Criticality Diagnostics. [See REF 25.433 for more details].

UE

Node B Dr if t RN S

No de B Serving RNS

Drift RNC

Serving RN C

Decision to setup new RL and r e l e a s e o ld R L

R N S AP

NB A P

N B A P


NBAP


NBAP

Start RX

R N S AP

5 . A L C A P I u b D a t a T r a n s p o rt B e a r e r S e t u p

DCH-FP

1. Ra dio Link Addition Request RNSAP

4. Radio Link Addition Response RNSAP

ALCAP Iur Data Transport Bearer Setup

6. Downlink Synchronisation


DCH-FP

DCH-FP

DCH-FP

Start TX 7. DC C H : A c t i v e S e t U p d a t e RRC

RRC [Radio Link Addition & Deletion]

RRC

8. DC CH : A c t i v e S e t U p d a t e C o m p l e t e

N B A P

N B A P

9. Radio Link Deletion Requ est

RRC

N B A P

10. Radio Link Release Response

N BAP

Stop RX a nd TX

11. ALCAP Iub Data T ransport Bearer Release

Figure 36: Soft Handover - Radio l ink Addition & Deletion (Branch Addition & Deletion simultaneously)

4. Upon reception of previous message, DRNC sends back a RNSAP Radio Link Addition Response message to SRNC.


Approved 92



Parameters: RL Information Response (as RL ID, RL Set ID, SAI, UL Interference Level, Secondary CCPCH Info, DL Code Information, DCH Information Response and Neighbouring Cell Information, etc.) and optional Critically Diagnostics. [See REF 25.423 for more details]. 5. As soon as DRNC receives Radio Link Setup Response message, it can initiate setup of Iub/Iur Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub/Iur Data Transport Bearer to DCH. This step may be repeated for each Iur/Iub Data Transport Bearer to be setup. 6. (FDD only) Node B and SRNC establish synchronism for the Iub and Iur Data Transport Bearers, relative to already existing radio link(s). This is done by means of the appropriate DCH Frame Protocol (DCH FP) Downlink Synchronisation and Uplink Synchronisation frames. Then, Node B is ready to start DL physical transmission. 7. At this moment, new resources are ready. Then SRNC sends RRC Active Set Update (Radio Link Addition & Deletion) message to UE on DCCH in order to update the active set of the connections between the UE and UTRAN. The UE should keep on using the old Radio Link(s) and transmitting while allocating the new Radio Link(s). In case all radio links were replaced simultaneously, the UTRAN should include the IE “U-RNTI”, and the IEs “CN domain identity” and “ NAS system information” within the “CN Information Info” IE. Parameters: UE IEs (Integrity Check Info, Activation Time and optional Integrity Protection Mode Info, Ciphering Mode Info and New U-RNTI), optional CN Information Info IE (as “ CN domain identity” and “ NAS system information”), RB IEs (PDCP information for each RAB) and DL/UL Physical Channels IEs (as Radio Link Addition & Removal Information, where Radio Link(s) to be added/removed are identified). 8. Upon reception of previous message, UE shall add indicated Radio Link(s). If the UE active set is full or becomes full because of received message, UE shall first remove radio link(s), which is/are indicated to remove, and then add radio link(s), which is/are indicated to add. UE shall update its configuration (U-RNTI identity, Transport Format Set, etc.), if necessary. Then, UE acknowledges new Radio Link configuration with RRC Active Set Update Complete message. Parameters: UE IEs (Integrity Check Info, and optional UL Integrity Protection Activation Info) and RB IEs (PDCP information for each RAB and optional RB UL Ciphering Activation Time Info). 9. Upon reception of this message, SRNC shall initiate deletion of all radio links for given UE, as were indicated in step 1, by sending the NBAP Radio Link Deletion Request message to its Node B. Parameters: Node B Communication Context ID and Radio Link ID for each RL to be released. 10. Upon reception of Radio Link Deletion Request message, the Node B controlled by SRNC shall delete the Radio Link(s) identified in the message and release all associated resources and respond to the CRNC with the NBAP Radio Link Deletion Response message. At this point, resources are deallocated and both physical transmission and reception are stopped for related radio link(s), though UE should not be using it from step 2. Parameters: CRNC Communication Context ID and optionally Criticality Diagnostics. 11. SRNC initiates release of not used resources Iub Data Transport Bearer using ALCAP protocol. At this point, the new Active Set of connections between UE and UTRAN is being used on both sides and all not used UTRAN resources are completely released. The procedure is ended.


Approved 93



5 Hard Handover A Hard Handover imply all Radio Links established for a given UE need to be released and new Radio Links need to be established. Network shall always take into account UE capabilities at establishing new Radio Links. This document will describe following types of hard handovers: Ø

UTRAN-to-UTRAN Hard Handovers •

Ø

Inter-frequency FDD to FDD, i.e., with related cells on different frequencies

Intersystem Hard Handovers6 •

UMTS to GSM

•

GSM to UMTS

•

UMTS to GPRS

•

GPRS to UMTS

All these Hard Handovers procedures may or may not imply a switch in the CN connections. Both cases will be described for all procedures. UTRAN SFRAS indicates UMTS-GPRS Hard Handovers will be supported in R1. On the other hand, [Ref. 25.401] specifies the possibility of both UE/Network initiated handovers. Therefore, the handover function may be either controlled by the network, or independently by UE. However, R0 and R1 will only implement network-initiated handovers, and it is believed within UE Initiated handover will not exist in UMTS. Therefore, it will be assumed only SRNC takes the decision to perform a Handover. This decision may be triggered by the following three main causes: •

•

•

Strength Level Cause, which is measured through measurement reports from UE. This cause is valid for all types of Handovers. Cell Topology Cause, based on the current cells serving the UE and the knowledge the system has of the surrounding cell topology. This cause is valid for FDD to FDD and UMTS to GSM Hard Handovers. Overload Cause, based on input to the Handover Control from the Overload Detection Function. This cause is valid for FDD to FDD and UMTS to GSM Hard Handovers.

5.1 Inter-frequency FDD to FDD Hard Handover procedure 5.1.1 Without Switching in the CN (DCH state) This is an UTRAN to UTRAN Hard Handover procedure performed when UE is moved to cells on different frequencies. UE is assumed to be in DCH state, i.e. in PMM-CONNECTED mode. Then, the Handover Control function in the SRNC decides that this Hard Handover type is necessary. Since there is not CN switching, SRNC will remain the same as before and CN nodes will not participate in the procedure. RNC signalling will take place via the Iur interface, as depicted in Figure 6 Intersystem

Hard Handovers will be developed in a second phase of this document, according t o Annex A.


Approved 94



37. UTRAN will first establish new RRC connection and new Radio Links, then UE will be reconfigured, and finally old Radio Links will be deleted. Based on IS-95 experience, it is known UE is likely to be in Soft Handover (more than 60% of active UEs will be). Thus, UE is also likely to be linked to UTRAN through different RNCs. Then, old Radio Links may be deleted for any old RNC (DRNC or SRNC) and new Radio Links may be established for any new RNC (DRNC or SRNC). Figure 37 shows different boxes for Source RNC, Target RNC and current SRNC in order to include all possibilities for this procedure. So, some messages have been annotated to indicate when related message applies (Notes are explained at the end of the procedure description). 1. The Handover Control function in the SRNC takes the decision of performing an Interfrequency FDD to FDD Hard Handover procedure. Then, SRNC sends RNSAP Radio Link Setup Request message to Target RNC for new Radio Link(s) to be established. This message will be sent to all new RNCs that are going to serve the UE after the Handover. If there is not Iur signalling connection between SRNC and corresponding DRNC, a new Iur signalling connection will be established now and it will be used for all RNSAP signalling related to this UE. Parameters: S-RNTI, D-RNTI (if UE Context already exists in Target RNC), optional Allowed Queuing Time, UL and DL DPCH Information (TFCS, UL Scrambling Code, etc.), DCH Information (general: Payload CRC Presence Indicator, UL FP Mode, ToAWS, ToAWE; specific: DCH ID, TrCh Source Statistics Descriptor, DL/UL Transport Format Set, DL/UL BLER, Allocation/Retention Priority, Frame Handling Priority, QE-Selector and DRAC Control), DSCH Information (DSCH ID, TrCh Source Statistics Descriptor, Transport Format Set, Allocation/Retention Priority, Scheduling Priority Indicator, BLER, PDSCH RL ID and TFCS), RL Information (RL ID, C-ID, First RLS Indicator, Frame Offset, Chip Offset, etc.), and optional Transmission Gap Pattern Sequence Information and Active Pattern Sequence Information IEs [See REF 25.423 for more details]. (Note 1). 2. If requested resources are available, Target RNC sends NBAP Radio Link Setup Request message to concerned Node B (this message is really sent by corresponding CRNC). This and following message will establish a new Communication Context for UE between CRNC and the Node B. If Target RNC is a DRNC, it may allocate a new D-RNTI that will be sent back to SRNC in step 5. If Target RNC is the SRNC, it may also allocate a new RNTI and resources for the RRC connection. Parameters: CRNC Communication Context ID, UL and DL DPCH Information (TFCS, UL Scrambling Code, etc.), DCH Information (general: Payload CRC Presence Indicator, UL FP Mode, ToAWS, ToAWE; specific: DCH ID, DL/UL Transport Format Set, Frame Handling Priority and QE-Selector), DSCH Information (DSCH ID, Transport Format Set, Frame Handling Priority, ToAWS and ToAWE), RL Information (RL ID, C-ID, First RLS Indicator, Frame Offset, Chip Offset, DL Code Information, Power control information etc.), and optional Transmission Gap Pattern Sequence Information and Active Pattern Sequence Information IEs. [See REF 25.433 for more details]. 3. Node B shall establish new Radio Link(s) according to received parameters. If configuration succeeds, Node B responses to CRNC with NBAP Radio Link Setup Response message. Node B is now able to start UL physical reception on the new radio link (though UE will not transmit anything yet). Parameters: CRNC Communication Context ID, Node B Communication Context ID, Communication Control Port ID, RL Information Response IEs (RL ID, RL Set ID, UL Interference Level, DCH/DSCH IDs, Transport layer addressing information -AAL2 address,


Approved 95



AAL2 Binding Identity for the Iub Data Transport Bearer–, etc.), and optional Criticality Diagnostics. [See REF 25.433 for more details].

UE

Node B Source

Node B Target

RNC Source

RNC target

SRNC

RNSAP 2. Radio Link Setup Request

NBAP

1. Radio Link Setup Request Note 1

RNSAP

NBAP

Start RX 3. Radio Link Setup Response

NBAP

NBAP


RNSAP

5. RL Setup Response Note 1

RNSAP

6. ALCAP Iur Data Transport Bearer S etup Note 1 7. Downlink Synchronisation

DCH-FP


DCH-FP

DCH-FP

DCH-FP

Start TX 8. DCCH : Physical Channel Reconfiguration Note 3

RRC

NBAP

9. Radio Link Failure Indication

RRC

NBAP

RNSAP

10. Radio Link Failure Indication Note 2

11. DCCH : Physical Channel Reconfiguration Complete Note 3

RRC

RNSAP

NBAP NBAP



RNSAP

RRC 12. Radio Link Deletion Request Note 2

RNSAP

NBAP NBAP

Stop RX &TX


RNSAP

16. Radio Link Deletion Response Note 2

RNSAP

17. ALCAP Iur Data Transport Bearer Release Note 2

Figure 37: Inter-frequency FDD to FDD Hard Handover via Iur (UE in DCH state)


Approved 96



4. As soon as RNC receives previous message, it can initiate setup of Iub Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to DCH. This step may be repeated for each Iub Data Transport Bearer to be setup. 5. Upon reception of previous message, Target RNC sends back a RNSAP Radio Link Setup Response message to SRNC. Parameters: RL Information Response (as RL ID, RL Set ID, SAI, UL Interference Level, Secondary CCPCH Info, DL Code Information, DCH and DSCH Information Response and Neighbouring Cell Information) and optional UL and DL SIR Target and Critically Diagnostics. If there was not previous UE Context for this UE in the Target RNC, Target RNC shall also include in the message the new D-RNTI and CN PS/CS Domain Identifiers to indicate CN Domain nodes Target RNC is connected to (using LAC and RAC of the current cell). (Note 1). 6. As soon as SRNC receives previous message, it can initiate setup of Iur Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iur Data Transport Bearer to DCH. This step may be repeated for each Iur Data Transport Bearer to be setup. (Note 1). 7. (FDD only) Node B and SRNC establish synchronism for the Iub and Iur Data Transport Bearers, relative to already existing radio link(s). This is done by means of the appropriate DCH Frame Protocol (DCH FP) Downlink Synchronisation and Uplink Synchronisation frames. Then, Node B is ready to start DL physical transmission. 8. When new radio resources are ready, SRNC sends RRC message to UE in order to trigger the Handover (Note 3). Normally, the RRC Physical Channel Reconfiguration message is sent on the DL DCCH. This message is used to establish, reconfigure and release physical channels. Parameters: UE Information Elements (Integrity Check Info, optional Integrity Protection Mode Info, optional Ciphering Mode Info, Activation Time, DRX indicator, UTRAN DRX Cycle Length Coefficient, optional New U-RNTI and optional New C-RNTI), optional CN Information Info, RB Information Elements (RB with PDCP information for each RB with PDCP), and PhyCh Information Elements for both UL and DL Radio Resources. (For more detailed parameters information see [Ref 25.331]). 9. When UE stops transmitter because of reception of previous message, Source Node B detects a failure on its Radio Link(s) and sends a NBAP Radio Link Failure Indication message to its CRNC. Parameters: CRNC Communication Context ID and Individual Radio Link(s) affected IDs or Radio Links Set(s) affected IDs with the most appropriate Cause IE. 10. Upon reception of previous message, Source RNC sends a RNSAP Radio Link Failure Indication message to SRNC. Parameters: Individual Radio Link(s) affected IDs or Radio Links Set(s) affected IDs with the most appropriate Cause IE. (Note 2). Note: Steps 8 and 9 are not directly related with the Handover procedure. However, they are described to indicate the Radio Link failure shall be detected and reported as a normal failure, for Source RNC and Source Node B do not know anything about the Hard Handover yet.


Approved 97



11. UE shall be able to receive a Physical Channel Reconfiguration message and perform a Hard Handover at any time, even if no prior UE measurements have been performed on the target cell and/or frequency. The UE should turn off the transmitter during the reconfiguration. UE may first release the current physical channel configuration and shall then establish a new physical channel configuration according to the information received in step 8 and [Ref. 25.331, section 8.5.7]. When the RRC connection is successfully established with the Target RNC and necessary radio resources have been allocated, UE sends corresponding RRC response message back to SRNC (Note 3). In this example and in the normal situation, the RRC Physical Channel Reconfiguration Complete message is sent. When the transmission of this message is confirmed by RLC, the UE shall resume data transmission on new Radio Link(s). Parameters: UE Information Elements (Integrity Check Info and optional Uplink Integrity Protection Activation Info) and RB IEs (RB with PDCP information for each RB with PDCP and optional Radio Bearer Uplink Ciphering Activation Time Info). 12. At this point the new configuration is up and working. Therefore, SRNC may indicate Source RNC to delete old Radio Link(s) towards UE. SRNC sends RNSAP Radio Link Deletion Request message to all Source RNCs that had old Radio Links towards UE before this Handover procedure. Parameters: Radio Link ID for each RL to be released. (Note 2) 13. Upon reception of this message, Source RNC shall initiate deletion of all radio links identified in the message for given UE by sending the NBAP Radio Link Deletion Request message to its Node B. Parameters: Node B Communication Context ID and Radio Link ID for each RL to be released. 14. Upon reception of Radio Link Deletion Request message, the Node B controlled by Source RNC shall delete the Radio Link(s) identified in the message and release all associated resources and respond to the CRNC with the NBAP Radio Link Deletion Response message. At this point, resources are deallocated and both physical transmission and reception are stopped for old radio link(s). Parameters: CRNC Communication Context ID and optionally Criticality Diagnostics. 15. Upon reception of Radio Link Deletion Response message from its Node B, Source RNC initiates release of not used resources Iub Data Transport Bearer using ALCAP protocol. 16. Source RNC shall respond to the SRNC with the RNSAP Radio Link Deletion Response message. Since all radio links for the UE have been deleted, Source RNC shall also release the UE context, unless the UE is using common resources in the DRNS. Parameters: only optionally Criticality Diagnostics IE. (Note 2). 17. Not used resources Iur Data Transport Bearer are released using ALCAP protocol. (Note 2). Note 1: This message is not necessary when the Target RNC is the SRNC. Note 2: This message is not necessary when the Source RNC is the SRNC. Note 3: The messages used are only one example of the various messages that can be used to trigger a handover, to confirm it or to indicate the handover failure. The different possibilities are specified in [Ref. 25.331].

At this point, all UTRAN resources associated to old Radio Link(s) are completely released and UE is using new Radio Link(s) on a different frequency. The Hard Handover procedure is ended.


Approved 98



5.1.2 With Switching in the CN (UE connected to two CN nodes, DCH state) This is an UTRAN to UTRAN Hard Handover procedure performed when UE is moved to cells on different frequencies. UE is assumed to be connected to two CN nodes simultaneously and in DCH state, i.e. in PMM-CONNECTED mode. Then, the Handover Control function in the SRNC decides that this type of Hard Handover is necessary. Switching in the CN means Source SRNC is going to be relocated to a Target SRNC. Then, also Iu connections need to be re-established for new SRNC using the Relocation procedure, i.e., the procedure to be performed is the Combined Hard Handover and SRNS Relocation Procedure. Unlike previous procedure, RNC signalling will take place now via the Iu interface. The SRNS relocation procedure shall be co-ordinated in all Iu connections existing for the UE in order to allow relocation co-ordination in the Target SRNC. If the Target SRNC is connected to the same CN nodes as the Source SRNC, Intra CN nodes SRNS Relocation procedure is performed. If the Target SRNC is connected to different CN nodes than the Source SRNC, Inter CN nodes SRNS Relocation procedure is performed. Both Intra and Inter CN nodes Combined Hard Handover and SRNS Relocation Procedures will be described below. In addition, the SRNC switching may be performed with or without the UE involvement. In the latter case, UE is already under Target SRNC control, i.e., there are already RABs established via Target SRNC. Then, Source SRNC transfers the “Serving” function to the Target RNC transparently to the UE and only existing RABs will be allowed to be used after the relocation. This section will assume UE is involved in the relocation, i.e. it is still under Source SRNC control and it is moving to a location controlled by the Target SRNC (based on any of the causes explained in the introduction of section 5). To simplify, it will be assumed Source Node B and Target Node B are directly under respective Source SRNC and Target SRNC, and no other Node B or DRNC will be considered, though they are likely to exist as explained in 5.1.1. If this were the case, appropriate procedure could be easily figured out from this and previous sections.

5.1.2.1 Intra CN node procedure In this case, Target SRNC is connected to the same SGSN and the same MSC than Source SRNC. Again, UTRAN will first relocate SRNC, establish new Iu connections, RRC connection and new Radio Links; then, UE will be reconfigured, and finally old Iu connections and Radio Link(s) will be deleted. In PS domain, if the routeing area is changed, then this procedure is followed by an Intra SGSN Routeing Area Update procedure. In CS domain, if the location area is changed, then this procedure is followed by an Intra MSC Location Area Update procedure. The procedure is depicted in Figure 38 and described in following steps: 1. Source SRNC will first perform the Relocation Preparation procedure. This procedure shall be initiated simultaneously on all Iu signalling connections existing for the UE. SRNC sends RANAP Relocation Required message to all CN nodes UE is connected to and starts timer TRELOCprep.


Approved 99



Parameters: Relocation Type (UE involved or not), Cause, Source ID (RNC-ID of the Source SRNC), Target ID (RNC-ID of the Target SRNC) and Source RNC to Target RNC transparent container, which includes IEs such as Number of Iu connections, Relocation Type, security information, UE Capabilities, RRC Context to be relocated, etc. [See REF 25.413 for more details]. 2. Upon reception of previous message, CN nodes prepare themselves for the switch and may also suspend data traffic between UE and themselves for some bearers. Each CN node shall initiate the Relocation Resource Allocation procedure. This procedure will allocate resources for Target RNS for the relocation of SRNS. Each CN node sends RANAP Relocation Request message to Target SRNC and starts timer T RELOCalloc. This message shall contain the information (if any) required by the UTRAN to build the RAB configuration existing for the UE before relocation. Parameters: Permanent NAS UE Identity (if available), Cause, CN Domain Indicator, Source RNC to Target RNC Transparent Container, Integrity Protection Information (if available), Iu Signalling Connection Identifier, optional Encryption Information and RAB to be setup Information for each RAB to be setup (RAB ID, RAB parameters, User Plane Information, Transport Layer Address, Iu Transport Association, etc.). 3. In case any CN node belongs to the CS domain, i.e., it is an MSC. Target SRNC and MSC shall establish the new Iu Data Transport Bearer for each RAB related to the MSC. This is done by means of the ALCAP protocol. At this point, the Target RNC shall initiate allocation of requested resources. The actions to be taken are the same as specified for the same IEs in the RAB Establishment section. In addition, Target SRNC shall take into account whether UE is involved in the relocation or not according to received Relocation Type IE. The main difference is that if UE is involved in the process, it is possible Target RNC establishes new necessary radio resources using the NBAP Radio Link Setup procedure (if the first Radio Links and there is not UE Communication Context) or the NBAP Radio Link Addition procedure (if not the first Radio Links and the UE Communication Context between Node B and Target RNC already exists). In Figure 38, it is assumed UE is involved in the procedure and there is not Communication Context established between Target Node B and Target SRNC. Then, Radio Link(s) must be setup in following step. If Relocation Type IE indicates UE is not involved in the process, it would not be possible to perform any of these procedures and only existing Radio Link(s) could be used. For more details on this IE, see [ref. 25.413]. 4. Target RNC allocates RNTI and radio resources for RRC and necessary Radio Link(s). Then, CRNC in Target RNC sends NBAP Radio Link Setup Request message to Target Node B in order to establish new UE Communication Context and necessary new Radio Link(s). Parameters: CRNC Communication Context ID, UL and DL DPCH Information (TFCS, UL Scrambling Code, etc.), DCH Information (general: Payload CRC Presence Indicator, UL FP Mode, ToAWS, ToAWE; specific: DCH ID, DL/UL Transport Format Set, Frame Handling Priority and QE-Selector), DSCH Information (DSCH ID, Transport Format Set, Frame Handling Priority, ToAWS and ToAWE), RL Information (RL ID, C-ID, First RLS Indicator, Frame Offset, Chip Offset, DL Code Information, Power control information etc.), and optional Transmission Gap Pattern Sequence Information and Active Pattern Sequence Information IEs. [See REF 25.433 for more details]. 5. Node B shall establish new Radio Link(s) according to received parameters. If configuration succeeds, Node B responses to CRNC with NBAP Radio Link Setup Response message. Node B is now able to star t UL physical reception on the new radio link (though UE will not transmit anything yet).


Approved 100



6. As soon as Target RNC receives Radio Link Setup Response message, it can initiate setup of Iub Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to DCH. This step may be repeated for each Iub Data Transport Bearer to be setup. 7. (FDD only) Node B and Target SRNC establish synchronism for the Iub Data Transport Bearers, relative to already existing radio link(s). This is done by means of the appropriate DCH Frame Protocol (DCH FP) Downlink Synchronisation and Uplink Synchronisation frames. Then, Node B is ready to start DL physical transmission. 8. After all necessary resources for accepted RABs including the Iu user plane, are successfully allocated, the Target SRNC shall send a RANAP Relocation Request Acknowledge message to the CN. The transmission of this message terminates the Relocation Resource Allocation procedure in the Target RNS. Parameters: RABs setup IEs (RAB ID and if PS domain, Transport Layer Address and Iu Transport Association), RABs failed to setup IEs (RAB ID and failure Cause), Chosen Integrity Protection Algorithm (if available) and optional IEs Chosen Encryption Algorithm and Critically Diagnostics. Finally, this message shall contain the Target RNC to Source RNC Transparent Container for it has been assumed Relocation Type IE was set to “ UE involved in relocation of SRNS”. Since two nodes are considered in this example, the Target RNC may decide to send the container to only one CN, for it will be sent transparently to Source RNC in next step. This container contains RRC Initialisation Information and optionally D-RNTI if Target RNC supports triggering of the Relocation Detect procedure via the Iur interface. (See step 14). 9. The reception of previous message terminates the Relocation Resource Allocation procedure in the CN nodes. However, CN nodes shall not release resources associated with the RABs indicated as failed to set up in previous message. This is in order to make a return to the old configuration possible in case of a failed or cancelled relocation. At this moment, if CN decides to continue the relocation of SRNS, each CN node shall send RANAP Relocation Command message to the source RNC and start timer T RELOCcompl. Parameters: Target RNC to Source RNC Transparent Container and L3 Information IEs (if received by the CN from the Target RNC), RAB ID for RABs to be released, RABs towards PS domain subject to data forwarding IEs if CN node belong to PS domain (RAB ID, Transport Layer Address and Iu Transport Association) and optional Critically Diagnostics. Note: It was not found when CN receives that L3 Information IE, which is defined in GSM 08.08. In addition, CN nodes should stop timer T RELOCalloc, though it is not indicated in specifications.

10. Upon reception of previous message from the PS domain, Source RNC shall start the timer TDATAfwd, though Forwarding of Data will not start up to step 13. After receiving previous message from all CN nodes involved in the process, Source RNC shall stop the timer TRELOCprep and start the timer T RELOCOverall and the Relocation Prepare procedure is terminated at the Source RNC. Previous message also contains a list of RABs IDs indicating all the RABs that are not supported by the Target SRNC. However, Source SRNC shall not release resources associated with these RABs. This is in order to make a return to the old configuration possible in case of a failed or cancelled relocation. After receiving previous message from all CN nodes involved in the process and when the Source SRNC is ready, it shall trigger the execution of relocation of SRNS by sending corresponding RRC message to the UE, for it is assumed UE is involved in the relocation. Normally, the RRC Physical Channel Reconfiguration message on the DL DCCH is sent (Note 1). This message is used to establish, reconfigure and release physical


Approved 102



channels. UTRAN should take the UE capabilities into account for setting the new configuration. In addition, since there is a SRNS relocation in this example, new ciphering and/or integrity protection information shall be sent if ciphering and/or or integrity protection information are activated. Parameters: UE Information Elements (Integrity Check Info, optional Integrity Protection Mode Info, optional Ciphering Mode Info, Activation Time, DRX indicator, UTRAN DRX Cycle Length Coefficient, optional New U-RNTI and optional New C-RNTI), optional CN Information Info (which contains among others Location Area Identification and Routeing Area Identification), RB Information Elements (RB with PDCP information for each RB with PDCP), and PhyCh Information Elements for both UL and DL Radio Resources. (For more detailed parameters information see [Ref 25.331]). Note: If during the Relocation Preparation procedure the Source RNC receives any Direct Transfer message (see section 2.1.3) it shall be handled normally. In case of reception of any other Class 2 message, Source SRNC may execute it or suspend it (if relocation were suspended, SRNC should resume any suspended procedure). After Relocation Preparation procedure is terminated successfully (step 10), all RANAP messages received via the same Iu signalling bearer shall be ignored, but the Iu Release Command that will be received in step 16.

11. (PS domain only) After sending previous message, the Source SRNC continues the execution of relocation of SRNS by sending RANAP Forward SRNS Context message to the SGSN. The purpose of this procedure is to transfer SRNS contexts from the Source to the Target SRNS via the SGSN. SRNS contexts are sent for each concerned RAB and contain the sequence numbers of the GTP PDUs next to be transmitted in the uplink and downlink directions and the next PDCP sequence numbers that would have been used to send and receive data from the UE. For connections using RLC unacknowledged mode, PDCP sequence numbers are not used. Parameters: DL GTP-PDU Sequence Number, UL GTP-PDU Sequence Number, DL N-PDU Sequence Number, UL N-PDU Sequence Number and RAB ID for each corresponding RAB. 12. (PS domain only) SGSN forwards SRNS contexts to Target SRNS by means of RANAP Forward SRNS Context message. Upon reception of this message, the Target SRNC resets and restarts the RLC connections taking into account the received parameters. The PDCP sequence numbers (PDCP-SNU, PDCP-SND) will be exchanged with the UE when connection is established. Parameters: DL GTP-PDU Sequence Number, UL GTP-PDU Sequence Number, DL N-PDU Sequence Number, UL N-PDU Sequence Number and RAB ID for each corresponding RAB. 13. (PS domain only) After having sent the Forward SRNS Context message in step 11, Source SRNC begins the Forwarding of Data for the RABs towards PS domain subject to data forwarding. The data forwarding at SRNS relocation shall be carried out through the Iu interface, meaning that the data exchanged between Source SRNC and Target SRNC are duplicated in the Source SRNC and routed at IP layer towards the Target SRNC. 14. The detection of the UE will trigger the execution of the Relocation of SRNS at the Target SRNS, which indicates it to both CN nodes by sending the RANAP Relocation Detect message. When this message is sent, the Target SRNC shall start the SRNC operation. Parameters: none specific IE. Note: Source SRNC can also trigger the execution of the Relocation of the SRNS by sending RNSAP Relocation Commit message to the Target SRNC (see section 6.1 SRNS Relocation


Approved 103



Procedure). If UE were not involved in the process, the execution of the Relocation of SRNS could only be triggered by the Relocation Commit message. In this example, since UE is involved in the process, both the reception of this message and the UE detection could be possible and the Relocation of SRNS would begin at Target SRNS as soon as it is triggered by any means. However, since the handover is performed through the Iu interface, it is not clear in specs if it is allowed to send an RNSAP message. If Relocation Commit message is received and it contains the transparent RANAP Relocation Information IE the target RNC shall use this information when finalising the Relocation, which also includes the information transmitted in the Forward SRNS Context procedure for PS domain. 15. UE stops UL transmission when it receives Handover message in step 10. Then, Source Node B will detect a failure in the Radio Link(s) and will send a NBAP Radio Link Failure Indication message to its CRNC at Source SRNC. Parameters: CRNC Communication Context ID and Individual Radio Link(s) affected IDs or Radio Links Set(s) affected IDs with the most appropriate Cause IE. 16. UE shall be able to receive a Physical Channel Reconfiguration message and perform a Hard Handover at any time, even if no prior UE measurements have been performed on the target cell and/or frequency. The UE should turn off the transmitter during the reconfiguration. UE may first release the current physical channel configuration and shall then establish a new physical channel configuration according to the information received in step 8 and [Ref. 25.331, section 8.5.7]. When the RRC connection is successfully established with the Target RNC and necessary radio resources have been allocated, UE sends corresponding RRC response message back to SRNC (Note 1). In this example and in the normal situation, the RRC Physical Channel Reconfiguration Complete message is sent. When the transmission of this message is confirmed by RLC, the UE shall resume data transmission on new Radio Link(s). Parameters: UE Information Elements (Integrity Check Info and optional Uplink Integrity Protection Activation Info) and RB IEs (RB with PDCP information for each RB with PDCP and optional Radio Bearer Uplink Ciphering Activation Time Info). 17. After successful switch in Target RNC (now SRNC for UE) and when the new SRNC-ID + SRNTI are successfully exchanged with the UE by the radio protocols, new SRNC sends RANAP Relocation Complete message to both CN nodes. Now, the SRNS relocation is complete. At any phase up to this message is sent, the old communication links were all the time existing and working and the procedure execution could be stopped and original information restored. After this switch, UL traffic from Nodes B is routed via the newly established MD-Combiner to the new MAC/RLC entities and finally to the correct Iu transport bearer. DL data arriving from the new Iu link is routed to newly established RLC entities, to the MAC and to the MD-splitter and Nodes B. Parameters: none specific IE. 18. The Relocation Complete message shall be handled the same way though the Relocation Detect message is not received yet. Hard Handover is successfully terminated. Then, CN nodes instruct Source SRNS to release the Iu connection as described in the Iu Signalling Connection Release procedure section. Then, old RRC connection and related UTRAN resources will be released, except those resources used for data forwarding, which will not be released until T DATAfwd expires. The Source SRNC will not respond with the Iu Release Complete message until this timer has expired. Note: CN nodes should stop timer T RELOCcompl though it is not indicated in specifications. In addition, Source SRNS should also stop timer T RELOCoverall at receiving the Iu Release Command, though it is not indicated in specifications.


Approved 104



19. After the UE has finished the reconfiguration process and if the new Routeing/Location Area Identification is different from the old one, the UE initiates corresponding update procedure. Note 1: The messages used are only one example of the various messages that can be used to trigger a handover, to confirm it or to indicate the handover failure. The different possibilities are specified in [Ref. 25.331].

At this point, all UTRAN resources associated to old Radio Link(s) are completely released and UE is using new Radio Link(s) on a different frequency and via new SRNS including new Iu signalling connections. The Hard Handover procedure is ended. In case tracing were activated, this order will be lost after successful Relocation of SRNS. If the tracing shall continue also after the relocation has been performed, RANAP CN Invoke Trace message shall be re-sent from the CN towards the new SRNC after the Relocation Resource Allocation procedure, which ends in step 9. Finally, for an UE with GPRS-CSI defined, CAMEL interaction may be performed, see referenced procedures in 3G TS 23.078: C1) CAMEL-GPRS-SGSN-Context-Acknowledge.

5.1.2.2 Inter CN node procedure In this case, Target SRNC is connected to different CN nodes than Source SRNC. Again, the system will first relocate CN nodes and the SRNC, establish new Iu connections, new RRC connection and new Radio Links; then, UE will be reconfigured, and finally old Iu connections and Radio Link(s) will be deleted. In PS domain, this procedure is followed by an Inter SGSN Routeing Area Update procedure. Note: In CS domain, the inter MSC handover is described in GSM 09.08. However, corresponding 3GPP TS specifying this procedure could not be found. That is why only the PS domain case is described in this section so far.

The procedure is depicted in Figure 39 and described in following steps: 1. Source SRNC will first perform the Relocation Preparation procedure. This procedure shall be initiated simultaneously on all Iu signalling connections existing for the UE. SRNC sends RANAP Relocation Required message to Old SGSN UE is connected to and starts timer TRELOCprep. Parameters: Relocation Type (UE involved or not), Cause, Source ID (RNC-ID of the Source SRNC), Target ID (RNC-ID of the Target SRNC) and Source RNC to Target RNC transparent container, which includes IEs such as Number of Iu connections, Relocation Type, security information, UE Capabilities, RRC Context to be relocated, etc. [See REF 25.413 for more details]. 2. The Old SGSN determines from the Target ID IE that this is an inter-SGSN SRNS relocation. Then it sends the Forward Relocation Request message to the New SGSN in order to convey necessary information to perform the relocation. At the same time, the Old SGSN starts a timer for the MM and PDP contexts. Parameters: IMSI, Tunnel Endpoint Identifier Control Plane (the chosen by the Old SGSN to be used in the GTP header for all subsequent control plane messages from New to Old SGSN), RANAP Cause, MM Context, PDP Context (only included if any PDP context is


Approved 105



active), Target ID, UTRAN Transparent Container and optional Private Extension for vendor/operator specifics. 3. Upon reception of previous message, New SGSN prepares itself for the switch and may also suspend data traffic between UE and itself for some bearers. Then, New SGSN shall initiate the Relocation Resource Allocation procedure. This procedure will allocate resources for Target RNS for the relocation of SRNS. New SGSN sends RANAP Relocation Request message to Target SRNC and starts timer T RELOCalloc. This message shall contain the information (if any) required by the UTRAN to build the RAB configuration existing for the UE before relocation. Parameters: Permanent NAS UE Identity (if available), Cause, CN Domain Indicator, Source RNC to Target RNC Transparent Container, Integrity Protection Information (if available), Iu Signalling Connection Identifier, optional Encryption Information and RAB to be setup Information for each RAB to be setup (RAB ID, RAB parameters, User Plane Information, Transport Layer Address, Iu Transport Association, etc.). At this point, the Target RNC shall initiate allocation of requested resources. The actions to be taken are the same as specified for the same IEs in the RAB Establishment section. In addition, Target SRNC shall take into account whether UE is involved in the relocation or not according to received Relocation Type IE. The main difference is that if UE is involved in the process, it is possible Target RNC establishes new necessary radio resources using the NBAP Radio Link Setup procedure (if the first Radio Links and there is not UE Communication Context) or the NBAP Radio Link Addition procedure (if not the first Radio Links and the UE Communication Context between Node B and Target RNC already exists). In Figure 39, it is assumed UE is involved in the procedure and there is not Communication Context established between Target Node B and Target SRNC. Then, Radio Link(s) must be setup in following step. If Relocation Type IE indicates UE is not involved in the process, it would not be possible to perform any of these procedures and only existing Radio Link(s) could be used. For more details on this IE, see [ref. 25.413]. 4. Target RNC allocates RNTI and radio resources for RRC and necessary Radio Link(s). Then, CRNC in Target RNC sends NBAP Radio Link Setup Request message to Target Node B in order to establish new UE Communication Context and necessary new Radio Link(s). Parameters: CRNC Communication Context ID, UL and DL DPCH Information (TFCS, UL Scrambling Code, etc.), DCH Information (general: Payload CRC Presence Indicator, UL FP Mode, ToAWS, ToAWE; specific: DCH ID, DL/UL Transport Format Set, Frame Handling Priority and QE-Selector), DSCH Information (DSCH ID, Transport Format Set, Frame Handling Priority, ToAWS and ToAWE), RL Information (RL ID, C-ID, First RLS Indicator, Frame Offset, Chip Offset, DL Code Information, Power control information etc.), and optional Transmission Gap Pattern Sequence Information and Active Pattern Sequence Information IEs. [See REF 25.433 for more details]. 5. Node B shall establish new Radio Link(s) according to received parameters. If configuration succeeds, Node B responses to CRNC with NBAP Radio Link Setup Response message. Node B is now able to star t UL physical reception on the new radio link (though UE will not transmit anything yet). Parameters: CRNC Communication Context ID, Node B Communication Context ID, Communication Control Port ID, RL Information Response IEs (RL ID, RL Set ID, UL Interference Level, DCH/DSCH IDs, Transport layer addressing information -AAL2 address, AAL2 Binding Identity for the Iub Data Transport Bearer–, etc.), and optional Criticality Diagnostics. [See REF 25.433 for more details].


Approved 106



UE

No de B Target

SRNC Source

SRNC Target

Old SGSN

1. Relocation Required

RANAP

Ne w SGSN

GGSN

RANAP 2 . F o r w a r d R e l o c a t i on R e q u e s t 3. Relocation Request

RANAP

N B A P


RANAP

NBAP

Start RX

N B A P


NBAP


DCH-FP

7. Downlink & Uplink Synchronisation

DCH-FP

Start TX RANAP

8. Relocation Request Acknowledge

RANAP

9. Forward Relocation Response

C1 10. Relocation Command

RANAP

RRC

1 1 . D C C H : P h y s i c a l C h a n n el R e c o n f i g u r a t i on No te 1

RANAP

RRC

12. Forward SRNS Context

RANAP

RANAP 13. Forward SRNS Context 14. Forward SRNS Context Acknowledge

RANAP

15. Forward SRNS Context

RANAP

16. Forwarding of Data

17. Relocation Detect RANAP

RANAP 1 8 . U p d a t e P D P C o n t e x t R e q u es t 19. Update PDP Context Response

RRC

2 0 . D C C H : P h y s i ca l C h a n n e l R e c on f i g u r a t i o n C o m p l e t e N o t e 1

RRC

RANAP

21. Relocation Complete

RANAP

22. Forward Relocation Complete 2 3 . F o r w a r d R e l o c a t i o n C o m p l e t e A c k n o w l ed g e RANAP

2 4 . I u R e l e a s e C o mm a n d

RANAP

25. Routing Area Update

Figure 39: Inter CN nodes Hard Handover with switching in the CN (PS domain only, UE in DCH state)

6. As soon as Target RNC receives Radio Link Setup Response message, it can initiate setup of Iub Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to DCH. This step may be repeated for each Iub Data Transport Bearer to be setup. 7. (FDD only) Node B and Target SRNC establish synchronism for the Iub Data Transport Bearers, relative to already existing radio link(s). This is done by means of the appropriate


Approved 107



DCH Frame Protocol (DCH FP) Downlink Synchronisation and Uplink Synchronisation frames. Then, Node B is ready to start DL physical transmission. 8. After all necessary resources for accepted RABs including the Iu user plane, are successfully allocated, the Target SRNC shall send a RANAP Relocation Request Acknowledge message to the New SGSN. The transmission of this message terminates the Relocation Resource Allocation procedure in the Target RNS. Parameters: RABs setup IEs (RAB ID and if PS domain, Transport Layer Address and Iu Transport Association), RABs failed to setup IEs (RAB ID and failure Cause), Chosen Integrity Protection Algorithm (if available) and optional IEs Chosen Encryption Algorithm and Critically Diagnostics. Finally, this message shall contain the Target RNC to Source RNC Transparent Container for it has been assumed Relocation Type IE was set to “ UE involved in relocation of SRNS”. This container contains RRC Initialisation Information and optionally D-RNTI if Target RNC supports triggering of the Relocation Detect procedure via the Iur interface. (See step 17). It will be sent transparently to Source RNC in step 10. 9. At this moment, the Relocation Resource Allocation procedure is terminated and the Target SRNC and the New SGSN are ready for relocation of SRNS. Then, New SGSN sends the Forward Relocation Response message to the Old SGSN in order to proceed with the relocation. The message responses to the Forward Relocation Request message received in step 2. This response transfers UTRAN information received from Target SRNC so that Source SRNS may perform the Forwarding of Data. Parameters: Cause (“ Request Accepted” in this example), Tunnel Endpoint Identifier Control Plane (the chosen by the New SGSN to be used in the GTP header for all subsequent control plane messages from Old to New SGSN in case of “ Request Accepted”), RANAP Cause (mandatory if cause value is contained in previous RANAP message), UTRAN Transparent Container (if received) and optional Private Extension for vendor/operator specifics. Finally, one or more RAB Setup Information IE parameters shall be set in this message. 10. At this moment, if Old SGSN decides to continue the relocation of SRNS, it shall send RANAP Relocation Command message to the Source RNC and start timer T RELOCcompl. However, Old SGSN shall not release resources associated with given UE. This is in order to make a return to the old configuration possible in case of a failed or cancelled relocation. Parameters: Target RNC to Source RNC Transparent Container and L3 Information IEs (if received by the Old SGSN from the Target RNC), RAB ID for RABs to be released, RABs towards PS domain subject to data forwarding IEs (RAB ID, Transport Layer Address and Iu Transport Association) and optional Critically Diagnostics. Note: It was not found when CN receives that L3 Information IE, which is defined in GSM 08.08. In addition, CN nodes should stop timer T RELOCalloc, though it is not indicated in specifications.

11. Upon reception of previous message from the PS domain, Source RNC shall start the timer TDATAfwd, though Forwarding of Data will not start up to step 16. After receiving previous message from all CN nodes involved in the process, Source RNC shall stop the timer TRELOCprep and start the timer T RELOCOverall and the Relocation Prepare procedure is terminated at the Source RNC. Previous message also contains a list of RABs IDs indicating all the RABs that are not supported by the Target SRNC. However, Source SRNC shall not release resources associated with these RABs. This is in order to make a return to the old configuration possible in case of a failed or cancelled relocation. After receiving previous message from all CN nodes involved in the process and when the Source SRNC is ready, it shall trigger the execution of relocation of SRNS by sending corresponding RRC message to the UE, for it is assumed UE is involved in the


Approved 108



relocation. Normally, the RRC Physical Channel Reconfiguration message on the DL DCCH is sent (Note 1). This message is used to establish, reconfigure and release physical channels. UTRAN should take the UE capabilities into account for setting the new configuration. In addition, since there is a SRNS relocation in this example, new ciphering and/or integrity protection information shall be sent if ciphering and/or or integrity protection information are activated. Parameters: UE Information Elements (Integrity Check Info, optional Integrity Protection Mode Info, optional Ciphering Mode Info, Activation Time, DRX indicator, UTRAN DRX Cycle Length Coefficient, optional New U-RNTI and optional New C-RNTI), optional CN Information Info (which contains among others Location Area Identification and Routeing Area Identification), RB Information Elements (RB with PDCP information for each RB with PDCP), and PhyCh Information Elements for both UL and DL Radio Resources. (For more detailed parameters information see [Ref 25.331]). Note: If during the Relocation Preparation procedure the Source RNC receives any Direct Transfer message (see section 2.1.3) it shall be handled normally. In case of reception of any other Class 2 message, Source SRNC may execute it or suspend it (if relocation were suspended, SRNC should resume any suspended procedure). After Relocation Preparation procedure is terminated successfully (step 10), all RANAP messages received via the same Iu signalling bearer shall be ignored, but the Iu Release Command that will be received in step 24.

12. After sending previous message, the Source SRNC continues the execution of relocation of SRNS by sending RANAP Forward SRNS Context message to the Old SGSN. The purpose of this procedure is to transfer SRNS contexts from the Source to the Target SRNS via the Old and the New SGSN. SRNS contexts are sent for each concerned RAB and contain the sequence numbers of the GTP PDUs next to be transmitted in the uplink and downlink directions and the next PDCP sequence numbers that would have been used to send and receive data from the UE. For connections using RLC unacknowledged mode, PDCP sequence numbers are not used. Parameters: DL GTP-PDU Sequence Number, UL GTP-PDU Sequence Number, DL N-PDU Sequence Number, UL N-PDU Sequence Number and RAB ID for each corresponding RAB. 13. The Old SGSN forwards previous message to the New SGSN with the Forward SRNS Context message. Parameters: RAB Context IE for each received RAB and optional Private Extension for vendor/operator specifics. 14. The New SGSN shall acknowledge previous message with the Forward SRNS Context Acknowledge message. Parameters: Cause (“ Request Accepted” in this case) and optional Private Extension for vendor/operator specifics. 15. New SGSN forwards SRNS contexts to Target SRNS by means of RANAP Forward SRNS Context message. Upon reception of this message, the Target SRNC resets and restarts the RLC connections taking into account the received parameters. The PDCP sequence numbers (PDCP-SNU, PDCP-SND) will be exchanged with the UE when connection is established. Parameters: DL GTP-PDU Sequence Number, UL GTP-PDU Sequence Number, DL N-PDU Sequence Number, UL N-PDU Sequence Number and RAB ID for each corresponding RAB. 16. After having sent the Forward SRNS Context message in step 11, Source SRNC begins the Forwarding of Data for the RABs towards PS domain subject to data forwarding. The data forwarding at SRNS relocation shall be carried out through the Iu interface, meaning that the


Approved 109



data exchanged between Source SRNC and Target SRNC are duplicated in the Source SRNC and routed at IP layer towards the Target SRNC. 17. The detection of the UE will trigger the execution of the Relocation of SRNS at the Target SRNS, which indicates it to the New SGSN by sending the RANAP Relocation Detect message. When this message is sent, the Target SRNC shall start the SRNC operation. In addition, UE stops UL transmission when it receives Handover message in step 11. Then, Source Node B will detect a failure in the Radio Link(s) and will send a NBAP Radio Link Failure Indication message to its CRNC at Source SRNC as in step 15 in Figure 38. Parameters (RANAP message): none specific IE. Note: Source SRNC can also trigger the execution of the Relocation of the SRNS by sending RNSAP Relocation Commit message to the Target SRNC (see section 6.1 SRNS Relocation Procedure). If UE were not involved in the process, the execution of the Relocation of SRNS could only be triggered by the Relocation Commit message. In this example, since UE is involved in the process, both the reception of this message and the UE detection could be possible and the Relocation of SRNS would begin at Target SRNS as soon as it is triggered by any means. However, since the handover is performed through the Iu interface, it is not clear in specs if it is allowed to send an RNSAP message. If Relocation Commit message is received and it contains the transparent RANAP Relocation Information IE the target RNC shall use this information when finalising the Relocation, which also includes the information transmitted in the Forward SRNS Context procedure for PS domain.

18. The New SGSN sends an Update PDP Context Request message to concerned GGSNs so that they can update their contexts. Parameters: TEID Data I (for downlink G-PDUs related to the requested PDP context), TEID Control Plane (for downlink control plane messages related to the requested PDP context), QoS Profile (QoS Negotiated), SGSN Address for control plane, SGSN Address for user traffic, optional Recovery IE, NSAPI, optional TFT, if BSS trace is activated, the four parameters from trace r elated step (Trace Reference, Trace Type, Trigger ID, OMC Identity), and optional IE Private Extension for vendor or operator specifics. 19. The GGSNs update their PDP Contexts fields and return an Update PDP Context Response message to the New SGSN. If the New SGSN receives this message with a Cause value other than “ Request Accepted”, it shall deactivate the PDP Context and the relocation is aborted. Parameters: Cause (“ Request Accepted” in this case), TEID Data I (for uplink G-PDUs related to the requested PDP context), TEID Control Plane (for uplink control plane messages related to the requested PDP context), QoS Profile (QoS that may be Negotiated downwards by the GGSN), GGSN Address for control plane, GGSN Address for user traffic, optional Recovery IE, Charging ID, Charging Gateway Address and optional IE Private Extension for vendor or operator specifics. 20. UE shall be able to receive a Physical Channel Reconfiguration message and perform a Hard Handover at any time, even if no prior UE measurements have been performed on the target cell and/or frequency. The UE should turn off the transmitter during the reconfiguration. UE may first release the current physical channel configuration and shall then establish a new physical channel configuration according to the information received in step 11 and [Ref. 25.331, section 8.5.7]. When the RRC connection is successfully established with the Target RNC and necessary radio resources have been allocated, UE sends corresponding RRC response message back to SRNC (Note 1). In this example and in the normal situation, the RRC Physical Channel Reconfiguration Complete message is sent. When the transmission of this message is confirmed by RLC, the UE shall resume data transmission on new Radio Link(s).


Approved 110



Parameters: UE Information Elements (Integrity Check Info and optional Uplink Integrity Protection Activation Info) and RB IEs (RB with PDCP information for each RB with PDCP and optional Radio Bearer Uplink Ciphering Activation Time Info). 21. After successful switch in Target RNC (now SRNC for UE) and when the new SRNC-ID + SRNTI are successfully exchanged with the UE by the radio protocols, new SRNC sends RANAP Relocation Complete message to the New SGSN. Now, the SRNS relocation is complete. At any phase up to this message is sent, the old communication links were all the time existing and working and the procedure execution could be stopped and original information restored. After this switch, UL traffic from Nodes B is routed via the newly established MDC to the new MAC/RLC entities and finally to the correct Iu transport bearer. DL data arriving from the new Iu link is routed to newly established RLC entities, to the MAC and to the MD-splitter and Nodes B. Parameters: none specific IE. 22. The Relocation Complete message shall be handled the same way though the Relocation Detect message is not received yet. Hard Handover is successfully terminated and New SGSN communicates it to the Old SGSN by the Forward Relocation Complete message. Parameters: optional Private Extension for vendor/operator specifics. 23. The Old SGSN shall acknowledge previous message with the Forward Relocation Complete Acknowledge message. Parameters: Cause (“ Request Accepted” in this case) and optional Private Extension for vendor/operator specifics. 24. Finally, Old SGSN instructs Source SRNS to release the Iu connection as described in the Iu Signalling Connection Release procedure section. Then, old RRC connection and related UTRAN resources will be released, except those resources used for data forwarding, which will not be released until T DATAfwd expires. The Source SRNC will not respond with the Iu Release Complete message until this timer has expired. Note: Old SGSN should stop timer T RELOCcompl though it is not indicated in specifications. In addition, Source SRNS should also stop timer T RELOCoverall at receiving the Iu Release Command, though it is not indicated in specifications.

25. After the UE has finished the reconfiguration process the UE initiates Routing Area Update procedure. Note 1: The messages used are only one example of the various messages that can be used to trigger a handover, to confirm it or to indicate the handover failure. The different possibilities are specified in [Ref. 25.331].

At this point, all UTRAN resources associated to old Radio Link(s) are completely released and UE is using new Radio Link(s) on a different frequency and via new SRNS and new SGSN, including new Iu signalling connections. The Hard Handover procedure is ended. In case tracing were activated, this order will be lost after successful Relocation of SRNS. If the tracing shall continue also after the relocation has been performed, RANAP CN Invoke Trace message shall be re-sent from the CN towards the new SRNC after the Relocation Resource Allocation procedure, which ends in step 9. Finally, for an UE with GPRS-CSI defined, CAMEL interaction may be performed, see referenced procedures in 3G TS 23.078: C1) CAMEL-GPRS-SGSN-Context-Acknowledge.


Approved 111



6 Other UMTS procedures This section collects some extra procedures that need to be further detailed and described, i.e., only a general overview will be presented in order to inspect and include them for September 2000 release of Motorola UTRAN SFRAS.

6.1 SRNS Relocation Procedure This procedure is only performed for a UE in PMM-CONNECTED mode. Source SRNC takes the decision of moving the UTRAN to CN connection point at the UTRAN side to a Target SRNC, i.e., the Iu links are relocated. The Target SRNC is also chosen by the Source SRNC. The SRNS relocation procedure shall be co-ordinated in all Iu connections existing for the UE in order to allow relocation co-ordination in the Target SRNC. If the Target SRNC is connected to the same CN nodes as the Source SRNC, Intra CN nodes SRNS Relocation procedure is performed. If the Target SRNC is connected to different CN nodes than the Source SRNC, Inter CN nodes SRNS Relocation procedure is performed. This procedure is very similar to the Hard Handover With Switching in the CN (UE connected to two CN nodes, DCH state) described in section 5.1.2 (the case for the UE connected to only one CN node can be easily inferred from this one). As an example, the Intra-CN node SRNS Relocation procedure will be described, though only new messages will be described within this section. The procedure is shown in Figure 40. As in section 5.1.2, it will be assumed Source Node B and Target Node B are directly under respective Source SRNC and Target SRNC, and no other Node B or DRNC will be considered. Sections 1 through 9 are already described in section 5.1.2. The only different is that the Relocation Type IE sent in the first message, RANAP Relocation Request, shall now be set to “ UE not involved”. This will affect to the detection of the relocation, as it will be described in step 12. The Relocation Commit message sent in step 10 is really the first different message, though it has also been commented in section 5.1.2: 10. When the Relocation Preparation procedure is terminated successfully for all existing Iu connections and the Source SRNC is ready, it should trigger the execution of Relocation of the SRNS. The Source RNC sends the RNSAP Relocation Commit message to the Target RNC to request the Target RNC to proceed with the Relocation. When the UE is utilising one or more radio links in the DRNC the message shall be sent using the connection oriented service of the signalling bearer and no further identification of the UE context in the DRNC is required. If on the other hand, the UE is not utilising any radio link the message shall be sent using the connectionless service of the signalling bearer and the D-RNTI IE received in the Target RNC to Source RNC Transparent Container shall be included in the message to identify the UE context in the Target RNC. Parameters: optional D-RNTI and also optional RANAP Relocation Information IE, which contains Direct Transfer Information for each established Direct Transfer Context (NAS-PDU and SAPI) and RABs Contexts (the sequence numbers of the GTP-PDUs next to be transmitted in the uplink and downlink directions and the next PDCP sequence numbers that would have been used to send and receive data from the UE).


Approved 112



13. As in section 5.1.2. 14. At this point, Target SRNC sends an RRC RNTI Reallocation message to the UE in order to allocate its new identity and communicate any changed additional parameter. Parameters: Integrity Check Info, optional Integrity Protection Mode Info, optional Ciphering Mode Info, New U-RNTI, optional C-RNTI, DRX Indicator, optional UTRAN DRX Cycle Length Coefficient, optional CN Information Info and optional RB with PDCP Information for each RB with PDCP information in the case of lossless SRNS relocation. 15. Upon reception of previous message, UE shall start store and start use the values of these IEs as the new current values. If the CN IE is present, the UE shall forward the content to the related NAS entity. Then, UE responses with the RRC RNTI Reallocation Complete message. Parameters: Integrity Check Info, optional Uplink Integrity Protection Activation Info, and optional RB IEs (Radio Bearer Uplink Ciphering Activation Time Info and RB with PDCP Information for each RB with PDCP information in the case of lossless SRNS relocation). 16. UTRAN may delete any old C-RNTI and U-RNTI and the RNTI Reallocation procedure end. Then, SRNS Relocation continues as in section 5.1.2.

6.2 Other Mobility Management procedures This section will include the update for the section 2.15.1 of UTRAN SFRAS v.1.4 reviewed along with ALCATEL. These procedures are likely to be completed in a second phase of this document as proposed in Annex A.

6.2.1 Example message flows for the paging procedure This procedure is explained in detail in section 2.2.3 Paging procedures. 1. The paging procedure for UEs in idle mode makes use of the PCCH. On the Iub interface, the paging message is transferred with the PCH frame protocol. 2. For UEs in URA connected mode, the RNC sends the paging message in all cells belonging to the URA. On the Iur, the paging message is transferred in the RNSAP PAGING REQUEST message with the URA-Id IE. On the Iub, the paging message is transferred in the PCH frame protocol. 3. For UEs in Cell-PCH state (only in R1 since the UE cannot be in Cell-PCH state in R0), the RNC sends the paging message in the cell where the UE is known to be. On the Iur, the paging message is transferred in the RNSAP PAGING REQUEST message with the C-Id IE. On the Iub, the paging message is transferred in the PCH frame protocol. 4. For UEs with a DCCH, the paging message is sent over the DCCH.

In cases 1, 2 and 3, UTRAN initiates the paging procedure by broadcasting a PAGING TYPE 1 message on an appropriate paging occasion on the PCCH. In case 4, UTRAN initiates the procedure by transmitting a PAGING TYPE 2 message on the DCCH. UMTS Call Flows November 4, 2000

Approved 114



UE

RNC

Node B

RNC

RANAP PAGING Case1: UE is in idle mode

FP PCH

Cases 2 and 3: UE is in URA connected mode ), or Cell-PCH state (only for R1)

FP PCH

RANAP PAGING

RNSAP PAGING REQUEST

FP PCH

Case 4: UE is in cell connected mode with existing DCCH DCCH : PAGING TYPE 2

RANAP PAGING

Figure 41: Paging message flow over Iu, Iub and Iur

6.2.2 Mobility Management of active calls The Mobility management function keeps track of the UEs location in the UTRAN at URA or Cell level and provides this information to the active UE register if needed: if there is a DCCH, the active UE register does not need to know the current cell (actually the active set) of the UE. Following telecom procedures provide input to the mobility management function: -

Soft/hard handover

-

URA updating

-

Cell update procedure (for UEs in the PCH substate of the cell connected mode)

6.2.2.1 Soft/hard handover See relevant sections in this document.


Approved 115



6.2.2.2 Intra-RNS URA Update UE

Serving RNC

1. CCCH: URA Update RRC

RRC

[S-RNTI, SRNC-ID]

2. CCCH or DCCH: URA Update Confirm RRC

RRC [S-RNTI, SRNC-ID]

3.DCCH: RNTI Re-Allocation Complete RRC

RRC

Figure 42: Intra RNS URA Update 1. This procedure is initiated after URA reselection or periodically based on timer T306 even if no URA reselection took place. UE sends a RRC message URA Update to the UTRAN, after having made URA re-selection. 2. Serving RNC acknowledges the message by RRC URA Update Confirm. 3. In case a new C-RNTI and/or a new U-RNTI has been allocated by the SRNC in the URA Update Confirm message, then UE sends a RRC message RNTI Re-Allocation Complete message.

6.2.2.3 Inter-RNS URA Update without SRNS relocation This example shows an Inter RNS URA update in DRNS without SRNS relocation. In this example target RNS, source RNS and serving RNS are all located separately from each other. 1. UE sends a RRC message URA UPDATE to the UTRAN on the CCCH, after having made cell re-selection and URA has changed. 2. Upon reception of the message from a UE, controlling RNC decodes the SRNC-ID and the S-RNTI. 3. The UE is not registered in the CRNC (SRNC-ID and SRNTI unknown), thus CRNC allocates a D-RNTI and a C-RNTI for the UE. 4. Controlling RNC forward the received Uu signalling message towards the SRNC by RNSAP UPLINK SIGNALLING TRANSFER INDICATION message. Messages includes also the cell-ID from which the message was received and the allocated D-RNTI and C-RNTI. 5. Upon reception of the RNSAP message SRNC decides not to perform a SRNS relocation towards the target RNC. 6. SRNC replies with the RNSAP DOWNLINK SIGNALLING TRANSFER REQUEST message containing the DL Uu signalling message to be sent to UE. Message includes UMTS Call Flows November 4, 2000

Approved 116



also the C-RNTI and the Cell-ID indicated in the previous UPLINK SIGNALLING TRANSFER INDICATION message. 7. The URA UPDATE CONFIRM is sent to the UE. 8. DRNC releases the allocated D-RNTI and C-RNTI.

UE

DRNC Source

DRNC Target

SRNC

MSC/SGSN

1. Recep tion of Uu Signalling Message 2. Decoding of RNC-ID from the UL message 3. Allocate D-RNTI and C- RNTI 4. Uplink Signalling Trasfer Indication RNSAP

RNSAP [C-RNTI, D-RNTI, Uu Signalling Message

] 5. Decision: Not to perform SRNC relocation

RNSAP

6. Downlink Signalling Transfer Request [C-RNTI, Uu Signalling Message

RNSAP ]

7. Transmission of Uu Signalling Message

8. Release of D-RNTI and C- RNTI

Figure 43: Inter RNS URA update without SRNS relocation

6.2.2.4 Intra-RNS Cell Update Two cases are considered: •

The UE performs Cell Update procedure under its Serving RNC, i.e. when SRNC = CRNC.

•

The UE performs Cell Update procedure under a CRNC different from SRNC

Case 2 is described in the section “Inter-RNS Cell Update without SRNS Relocation”. Case 1 is described below: The following figure represents the RRC messages exchanged between the SRNC and the UE during a Cell Update procedure when SRNC = CRNC.


Approved 117



UE

SRNC = CRNC

12 . PC CH : Pa g i n g T y pe 1 RR C

RR C

2 3. C C C H : C e l l U p d a t e RR C

RR C

[S-RNTI, SRNC-ID]

Allocate C-RNTI 34 . DC CH : Ce ll Up da te Co nf i rm RR C

RR C [S-RNTI, SRNC-ID, new C-RNTI]

4 5. DC CH : RN T I Re -A l lo ca ti o n Co mp le te RR C

RR C

56 . DC CH : Ph ys ic a l Ch an ne l Re co nf ig ur a ti on Co mp le te RR C

RR C

Figure 44: Intra RNS Cell Update in case SRNC=CRNC The Cell Update procedure could be initiated by a UE in CELL_FACH state (e.g. on cell change), or CELL_PCH state (e.g. on cell change, or if the UE wants to transmit UL data), or URA_PCH state (e.g. on URA change, or if the UE wants to transmit UL data), and in this case this scenario begins at step 2. Or it could be initiated by the SRNC, when a UE is in URA_PCH or CELL_PCH state and when SRNC wants to trigger state transition (e.g. to establish a signalling connection). In this case, it begins at step 1. 1. In the case a UE in URA_PCH or CELL_PCH state has to be paged. The SRNC sends a RRC message Paging Type 1 in the cell where the UE is located (CELL_PCH), or in the cells corresponding to the URA where the UE is located (URA_PCH). 2. UE sends a RRC message Cell Update to the UTRAN. Upon reception of RRC Cell Update message Serving RNC may allocate a new C-RNTI 7, and optionally a new URNTI, for the UE. 3. Serving RNC acknowledges the message by RRC Cell Update Confirm. SRNC may include a new C-RNTI (if a new C-RNTI is re-allocated), and optionally a new U-RNTI, and/or common physical channels related information.

7 Cases

where a new C-RNTI is a llocated by the UTRAN are described in the next section.


Approved 118



4. In case common physical channels info are sent by SRNC, with or without a new CRNTI8, and optionally a new U-RNTI, UE acknowledges the RRC Cell Update Confirm message with a RRC Physical Channel Reconfiguration Complete message. 5. In case a new C-RNTI, and optionally a new U-RNTI, is allocated by the SRNC but no common physical channels info are sent, UE acknowledges the RRC message Cell Update Confirm with a RRC message RNTI Re-Allocation Complete.

6.2.2.5 Inter-RNS Cell Update without SRNS relocation Two cases are considered: the case where a C-RNTI is allocated by the UTRAN, and the case where no C-RNTI is allocated. According to TS 25.331, the UE always deletes its C-RNTI at the beginning of the Cell Update procedure. C-RNTI is used to identify the UE in the cell only when the UE is in CELL FACH state, i.e. transmitting/receiving data. Therefore, there is no C-RNTI reallocation procedure when the UE does not end the procedure in Cell-FACH state. An UE can initiate a Cell Update for following reasons: cell reselection, periodic cell update, UL data transmission, paging response, etc. The initial state of the UE can be Cell-FACH state, Cell-PCH state or URA-PCH state. Main examples where the UE initiates a Cell Update procedure are listed according to its initial state: l

In Cell-FACH state: When the UE selects another cell (via Cell Reselection) or at periodiccell update. In those cases, the UE will remain in Cell-FACH state at the end of the procedure. Therefore it requires a C-RNTI.

l

In Cell-PCH state:

l

l

When the UE selects another cell (via Cell Reselection), or at periodic-cell update. In those cases, the UE will go back to Cell-PCH state at the end of the procedure. It does not need a C-RNTI.

l

When the UE wants to transmit data or when it is paged by the UTRAN. In this case, the UE will go to Cell-FACH state at the end of the procedure. It requires a C-RNTI.

In URA-PCH state: When the UE wants to transmit data or when it is paged by the UTRAN. In this case, the UE will go to Cell-FACH state at the end of the procedure. It requires a CRNTI.

The SRNC will insert a C-RNTI in the “New C-RNTI” field of Cell Update Confirm only in the cases where the UE ends the procedure in Cell-FACH state. In that case, the UE has to confirm by sending a Physical Channel Reconfiguration Complete message or a RNTI Reallocation Complete message back to the UTRAN, depending on whether the CELL UPDATE CONFIRM message includes or not the IE "PRACH info" and/or the IE "Secondary CCPCH info".

8 Cases

where a new C-RNTI is a llocated by the UTRAN are described in the next section.


Approved 119



6.2.2.5.1 Without C-RNTI re-allocation nor Physical Channel Reconfiguration

This example shows an Inter RNS cell update in DRNS without SRNS relocation when no Iur RACH/FACH transport bearer exists, i.e. ALCAP is used to set up the needed Iur AAL2 connection. In this example target RNS, source RNS and serving RNS are all located separately from each other.

UE

RRC

DRNC Source

DRNC Target

1. CCCH: Cell Update

SRNC

MSC/SGSN

RRC-relay 2. Decoding of RNC-ID from the UL message 3. Allocatinge C- RNTI + D-RNTI 4. Uplink Signalling Transfer Indication RNSAP

RNSAP [C-RNTI, UL message] 5. Decision: Not to perform SRNC relocation

6. Common Transp. Ch. Resources Request RNSAP

RNSAP

7. Common Transp. Ch. Resources Response. RNSAP RNSAP

8. ALCAP Iur bearer

9. DCCH: Cell Update Confirm RRC

RRC

101. Common Transp. Ch. Resources Release Request RNSAP

RNSAP

Release C- RNTI + D-RNTI

Figure 45: Cell Update via Iur (case without C-RNTI re-allocation) 1. UE sends an RRC message CELL UPDATE to the UTRAN on the CCCH. 2. The target DRNC decodes the SRNC ID and the S-RNTI. 3. The target DRNC allocates a C-RNTI and a D-RNTI to the UE. 4. The target DRNC forwards the received uplink CCCH message towards the SRNC in the RNSAP UPLINK SIGNALLING TRANSFER INDICATION message. The UPLINK SIGNALLING TRANSFER INDICATION message includes also the cellID of the cell from which the CCCH message was received, the D-RNTI and the allocated C-RNTI. 5. Upon reception of the UPLINK SIGNALLING TRANSFER INDICATION message the SRNC decides not to perform SRNS Relocation towards the target RNC. 6. The SRNC initialises the UE context in the target RNC with the RNSAP COMMON TRANSPORT CHANNEL RESOURCES REQUEST message. The message includes the D-RNTI previously received in the UPLINK SIGNALLING TRANSFER


Approved 120



INDICATION message, as well as a request for transport layer address and binding identity if there exists no appropriate Iur transport bearer to be used for the UE. 7. The target DRNC sends the transport layer address, binding identity and optionally PHY parameters (FACH code...) to the SRNC with the RNSAP COMMON TRANSPORT CHANNEL RESOURCES RESPONSE message. 8.

If there does not already exist an appropriate Iur transport bearer to be used for the UE, a transport bearer is established via ALCAP (Q.AAL2) from the SRNC.

9. The SRNC sends RRC CELL UPDATE CONFIRM on DCCH to the UE. The message is sent in the Iur user plane. It will be sent by the target DRNC to the UE on the FACH coupled to the RACH. The message does not contain new C-RNTI (nor optionally U-RNTI) neither IE “ PRACH info” and/or IE “ Secondary CCPCH info”. 10. The SRNC releases the UE context in the source DRNC by sending a COMMON TRANSPORT CHANNEL RESOURCES RELEASE REQUEST message. The source DRNC releases the D-RNTI and the C-RNTI.

6.2.2.5.2 With C-RNTI re-allocation or physical channel reconfiguration This is the case where the DRNC decides to allocate a new C-RNTI for the UE, or to change the IE "PRACH info" and/or the IE "Secondary CCPCH info". This example shows a cell update in DRNS without SRNS relocation when no Iur RACH/FACH transport bearer exists, i.e. ALCAP is used to set up the needed Iur AAL2 connection. 1.

UE sends an RRC message Cell Update to the UTRAN on the CCCH, after having made cell re-selection.

2.

Upon reception of the CCCH message from a UE, the target DRNC decodes the SRNC ID and the S-RNTI.

3.

The target DRNC allocates a D-RNTI and a C-RNTI to the UE.

4.

The target DRNC forwards the received uplink CCCH message towards the SRNC in the RNSAP Uplink Signalling Transfer Indication message. The Uplink Signalling Transfer Indication message includes also the Cell-ID of the cell from which the CCCH message was received and the allocated D-RNTI and C-RNTI.

5.

Upon reception of the Uplink Signalling Transfer Indication message the SRNC decides not to perform SRNS Relocation towards the target RNC.

6.

The SRNC initialises the UE context in the target RNC with the RNSAP Common Transport Channel Resources Request message. The message includes the D-RNTI previously received in the Uplink Signalling Transfer Indication message, as well as a request for transport layer address and binding identity if there exists no appropriate Iur transport bearer to be used for the UE.

7.

The target DRNC sends the transport layer address, binding identity and optionally PHY parameters (FACH code...) to the SRNC with the RNSAP Common Transport Channel Resources Response message.

8.

If there does not already exist an appropriate Iur transport bearer to be used for the UE, a transport bearer is established via ALCAP (Q.AAL2) from the SRNC.


Approved 121



UE

RRC

DRNC

1. CCCH: Cell Update

SRNC

MSC/SGSN

RRC-relay 2. Decoding of RNC-ID from the UL message 3. Allocating D-RNTI + C- RNTI 4. Uplink Signalling Transfer Indication RNSAP

RNSAP [new C-RNTI, UL message] 5. Decision: Not to perform SRNC relocation

6. Common Transp. Ch. Resources Request RNSAP

RNSAP

7. Common Transp. Ch. Resources Response. RNSAP RNSAP

8. ALCAP Iur bearer

98. DCCH: Cell Update Confirm RRC

RRC

RRC 109. DCCH: RNTI Reallocation Complete or Physical Channel Reconfiguration Complete

RNSAP

RRC 110. Common Transport Channel Resources Release Request RNSAP [old C-RNTI]

121. Release indicated C- RNTI

Figure 46: Inter-RNS cell update via Iur (case with C-RNTI re-allocation) 9.

The SRNC sends RRC Cell Update Confirm on DCCH to the UE. The message is sent in the Iur user plane. It will be sent by the target DRNC to the UE on the FACH coupled to the RACH.

10.

If the IE "PRACH info" and/or the IE "Secondary CCPCH info" were included in the Cell Update Confirm, the UE sends a Physical Channel Reconfiguration Complete message on DCCH successful reception of Cell Update Confirm. Otherwise, if a new C-RNTI has been allocated, the UE sends RRC RNTI Re-allocation Complete on DCCH successful reception of Cell Update Confirm.

11.

The SRNC releases the old C-RNTI in the DRNC by sending a Common Transport Channel Resources Release Request message. This message may or may not include the C-RNTI.

12.

The DRNC releases the indicated old C-RNTI. If the message Common Transport Channel Resources Release Request includes the C-RNTI, DRNC deletes only that CRNTI, otherwise DRNC deletes the whole UE context.


Approved 122



Annex A. UMTS Call Flows Proposal This paper intends to summarize all call flows that would be interesting to develop within the UMTS Call Flows document in order to have a complete document to face test cases in UMTS Field Trials. It is defined to develop in a first phase ending by the end on July 2000 procedures from point 1 through 4. Rest of procedures is proposed to be added in a second phase of the document. Procedures 9 through 13 are Location related procedures that can be combined and are likely to be involved in other procedures such as Attachments and Handovers. Note: It would be useful to identify which procedures are going to be supported for Field Trials.

1. Call Establishment a. Mobile Originated i. RRC connection (on RACH/FACH and on DCH) ii. Iu signalling iii. Direct Transfer iv. Common ID v. Security Functions (Identity, Authentication and Security Mode) vi. RAB assignment (three possibilities: RACH/FACH, DSCH, DCH)9 vii. Both PS and CS Service Request (NAS call establishment). b. Mobile Terminated i. Paging (Type I and Type II and cases for different RRC states for UE) ii. Modifications to procedures in 1.a 2. Call Release a. Mobile Originated i. PDP context deactivation for PS domain and Call Clearing for CS domain ii. Iu release iii. RAB release (different cases) iv. RRC release (on RACH/FACH and on DCH) b. Mobile Terminated i. Modifications to procedures in 2.a 3. Soft Handover (Study implications, if any, to existing CN connections) a. Radio Link Addition b. Radio Link Deletion c. Radio Link Addition and Deletion d. Cases with 1 leg in a DRNC 4. Hard Handover (intra UMTS hard handover only, i.e., inter frequency handover)

9 Since

there are two possibilities for RRC connection and three possibilities for RAB assignment, there are at least six possible combinations. It is FFS which scenarios are the most efficient and likely to be used, depending on the combination of services supported. So far, only three scenarios are described.


Approved 123


UMTS Call Flow

Recommend Documents