UMTS Call Flow

Motorola Confidential Proprietary
UMTS Call Flows Approved Motorola: ANDC-MA-00-0.3.4-RQ

November 4, 2000 1 Version 1.01

UMTS
Detailed Call Flows

Authors
Flix Bejarano Cebrin
(GSD, Advanced Network Development Centre)

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

Version: 1.01
Date: November 4, 2000

Motorola
Network Solutions Sector
1501 W. Shure Drive
Arlington Heights, Illinois 60004, USA

Abstract

This document describes UMTS Detailed 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


Release History
Version Release Date Author(s) Change History
Draft 0.1 June 19, 2000 Flix Bejarano (ANDC) Original Document
Draft 0.2 June 27, 2000 Flix Bejarano (ANDC) Change requests from version 0.1 revision
Draft 0.3 July 24, 2000 Flix Bejarano (ANDC) Mobile Terminated Call Establishment, Call
Release and Soft Handover sections
Draft 0.4 August 2, 2000 Flix Bejarano (ANDC) Inter-frequency FDD to FDD Hard Handover
section
Draft 0.5 September 1, 2000 Flix Bejarano (ANDC) Update to 3GPP R99 June 2000 versions
Draft 0.6 September 7, 2000 Flix Bejarano (ANDC) Section 6 included
Approved 1.0 October 4, 2000 Flix Bejarano (ANDC) Change requests from version 0.6 revision.
This version is now section 2.15 in UTRAN
SFRAS version 1.5
Draft 1.01 November 4, 2000 Flix Bejarano (ANDC) Minor cosmetic changes



Table of Contents
Release History.................................................................................................................................. 2
Table of Contents............................................................................................................................... 3
Table of Figures ................................................................................................................................. 5
Reference List .................................................................................................................................... 6
Glossary of terms ............................................................................................................................... 7
1 Introduction............................................................................................................................. 23
1.1 Scope................................................................................................................................. 23
1.2 Notation for Signalling Procedures ..................................................................................... 23
1.3 Explanation of Terms ......................................................................................................... 24
2 End-End Call Establishment .................................................................................................... 26
2.1 Mobile Originated Call Establishment ................................................................................ 26
2.1.1 RRC Connection Establishment procedures ................................................................. 27
2.1.2 Iu Signalling Connection Establishment procedure ...................................................... 30
2.1.3 UE-CN Signalling Messages ....................................................................................... 31
2.1.4 Common ID procedure................................................................................................ 32
2.1.5 Security Functions....................................................................................................... 33
2.1.5.1 Identity Check Procedure...................................................................................................... 33
2.1.5.2 Authentication and Key Agreement procedure ...................................................................... 34
2.1.5.3 Security Mode Setup procedure ............................................................................................ 36
2.1.6 MM Connection Established........................................................................................ 38
2.1.7 RAB Establishment ..................................................................................................... 39
2.1.7.1 DCH DCH RAB Establishment procedure ......................................................................... 39
2.1.7.2 RACH/FACH DCH Establishment procedure .................................................................... 44
2.1.7.3 RACH/FACH RACH/FACH Establishment procedure....................................................... 46
2.1.8 Service Request and PDP Context Activation procedure (PS domain only) .................. 48
2.1.9 CS Domain Call Setup procedure (CS domain only) .................................................... 51
2.2 Mobile Terminated Call Establishment ............................................................................... 54
2.2.1 Service Request and PDP Context Activation procedure (PS domain only) .................. 54
2.2.2 CS Domain Call Setup procedure (CS domain only) .................................................... 57
2.2.3 Paging procedures ....................................................................................................... 59
3 Call Release............................................................................................................................. 63
3.1 Mobile Originated Call Release.......................................................................................... 63
3.1.1 PDP Context Deactivation procedure (PS domain only)............................................... 63
3.1.2 Call Clearing procedure (CS domain only) .................................................................. 65
3.1.3 UTRAN Resources Release procedures ....................................................................... 66
3.1.3.1 Iu Signalling 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 RAB Release procedure ................................................. 79
3.2 Mobile Terminated Call Release......................................................................................... 80
3.2.1 PDP Context Deactivation procedure (PS domain only)............................................... 80
3.2.2 Call Clearing procedure (CS domain only) .................................................................. 82
4 Soft Handover.......................................................................................................................... 86
4.1 Radio Link Addition (Branch Addition) ............................................................................. 87
4.2 Radio Link Deletion (Branch Deletion) .............................................................................. 89
4.3 Radio Link Addition & Deletion (Branch Addition & Deletion - simultaneously) ............... 91
5 Hard Handover ........................................................................................................................ 94


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 Intra CN node procedure ...................................................................................................... 99
5.1.2.2 Inter CN node procedure .................................................................................................... 105
6 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



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



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



Glossary of terms

Acronym Definition
3GPP 3
rd
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


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


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


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


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
I
BTS
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


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


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


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


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


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)


PTR Pointer
PUF Power Up Function
QE Quality Estimate
QoS Quality of Service
QPSK Quadrature 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


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


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


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


TX Transmit
U- User-
UARFCN UTRA Absolute Radio Frequency Channel 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 System
UNEQ Unequipped
UNI User to Network Interface
UP User Plane
UPC Usage Parameters Control
URA User Registration Area
USCH Uplink Shared CHannel
USIM UMTS Subscriber Identity Module
UTRA UMTS Terrestrial Radio Access
UTRAN UMTS Terrestrial Radio Access Network
Uu Reference point between User Equipment and Infrastructure domains, UMTS
radio interface
UUI User to User Indicator
VA Voice Activity (factor)
VBR Variable Bit Rate
VC Virtual Channel
VCC Virtual 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


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 Network domains
Zu Reference point between Serving and Home Network domains


1 Introduction
1.1 Scope
This document describes detailed end-end signalling procedures for UMTS. Only UTRAN will
be considered as the Radio Access Network; however, GSM parameters transmitted within 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 according to the document proposal in Annex A.

In addition, only FDD solution is considered and only successful procedures will be presented.
1.2 Notation for Signalling Procedures
Following rules will apply:

Complex signalling procedures may involve 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;
The protocol entity inside a node that is sending/receiving a message is represented by means
of an ellipse, containing the protocol entity 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 may be indicated before the message name as shown in Figure 1.



UE Node B
Dri f t RNS
Node B
Servi ng RNS
RNC
Drift
RNC
Servi ng
CN
NBAP
MAC
NBAP
RANAP RANAP
RNSAP RNSAP
MAC
1. RACH : Message
RRC RRC
2. C CCH : Message
3. Message
6. Message
5. Message
[Paramet ers]
[Paramet ers ]
[Paramet ers ]
[Paramet ers ]
[Paramet ers ]
Act ion descr ipt ion
NBAP NBAP
4. Message
[Paramet ers ]
ALCAP Iub Bear er Set up/ Rel ease ALCAP I ur Bear er Set up

Figure 1: Example of signalling procedure notation
1.3 Explanation of Terms
Term Definition
Controlling Radio Network
Controller (CRNC)
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.
Drift Radio Network Controller
(DRNC)
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).
Generic Radio Network
Controller (GRNC)
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.
Hard Handover 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.
Iu Interface reference point between the RNS and the Core
Network. (See also Iu-CS and Iu-PS.)
Iu-CS Interface between the RNC and the circuit switched side of
the Core Network, typically the MSC.
Iu-PS Interface between the RNC and the packet switched side of
the Core Network, typically the SGSN.
Iub Interface between the RNC and the Node B. It is
considered as a reference point.
Iur Interface between two RNSs. While this interface logically
represents a point to point link between RNSs, the physical


Term Definition
realisation may not be a direct link. It is also considered as
a reference point.
Node B Application Part
(NBAP)
NBAP is used for setting up Radio Access Bearers (RAB)
in the Radio Network Layer over the Iub.
Radio Access Network
Application Part (RANAP)
Radio Network Signalling over the Iu.
Radio Network Subsystem
Application Part (RNSAP)
Radio Network Signalling over the Iur between the SRNC
and DRNC.
Serving Radio Network
Controller SRNC)
This represents the RNC functions that are used during an
active call or data session.
Soft Handover 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.
Softer Handover This is a type of soft handover that involves one or more
cells of the same Node B.
Universal Mobile Telephone
System (UMTS)
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.



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 PS-CN CS -CN UTRAN
RRC Connect i on
RANAP Connect i on
RANAP Connect i on

Figure 2: NAS Signalling connections



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:

UE Node B
Servi ng RNS
Ser vi ng
RNC
Allocat e RNTI
Sel ect L1 and L2
par amet er s
RRC RRC

1. CCCH ( on RACH) : RRC Connect i on
Request
RRC
RRC

6. CCCH ( on FACH) : RRC Connect i on Set up
RRC RRC

7. DCCH ( on RACH) : RRC Connect i on Set up Compl et e
RRC
RRC

8. DCCH ( on FACH) : Measur ement Cont r ol

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


UE Node B
Servi ng RNS
Ser vi ng
RNC
RRC
RRC

7. DCCH ( on DCH) : RRC Connect i on Set up Compl et e

5. NodeB -SRNC Dat a Tr anspor t Bear er Sync
(FDD onl y)
Allocat e RNTI
Sel ect L1 and L2
par amet er s
RRC RRC

1. CCCH ( on RACH) : RRC Connect i on Reques t
NBAP NBAP

3. Radi o Li nk Set up Response
NBAP NBAP

2. Radi o Li nk Set up Request
RRC
RRC

6. CCCH ( on FACH) : RRC Connect i o n Set up
St ar t RX
St ar t TX
4. ALCAP Iub Dat a Tr anspor t Bear er Set up
RRC
RRC

8. DCCH ( on DCH) : Measur ement Cont r o l

DCH -FP DCH -FP

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.


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



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 Ser vi ng
RNC
CN
RRC
RRC

9. DCCH :Init ial Direct Transfer
RANAP RANAP
10. Init ial UE Message

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.



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.

B. Direct Transfer
C. Direct Transfer
A. DCCH: Uplink Direct Transfer
UE Node B
Serving RNS
Serving
RNC
CN
RRC RRC
RANAP RANAP
RANAP RANAP
D. DCCH: Downlink Direct Transfer RRC 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.


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 UE-
CN 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 RRC procedure is ongoing, and in that case the latter procedure shall not be affected.

2.1.4 Common ID procedure
The purpose of the Common ID procedure is to allow the SRNC to create a reference between the
permanent NAS UE Identity of a UE and the RRC connection established for that UE in 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 exists by means of the Permanent NAS UE Identity (IMSI).

Ser vi ng
RNC
CN
RANAP RANAP
11. Common I D

Figure 7: Common 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,


for example, IMSI is not necessary and nor is the Common ID procedure, i.e., it is possible neither
IMSI nor Common ID procedure shall be performed.

2.1.5 Security Functions
(Security functions are described in detail in [Ref 33.102].)
It is mandatory to start integrity protection of signalling messages by use of Security Mode Set-
up 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 the security mode set-up procedure are the following:
Identification by a permanent identity (i.e. request for IMSI), and
Authentication and Key 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 messages, they will be transparently transferred through UTRAN by 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 Ser vi ng
RNC
EIR CN
12. Di rect Transf er : Ident it y Request
13. Di rect Transf er: Ident i t y Response
14. Check IMEI
15. Check I MEI 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.


14. MSC/SGSN may decide to 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 the identity provided by UE is acceptable or not.
To provide parameters enabling UE to calculate a new UMTS ciphering key and a new
UMTS integrity key.
To permit UE to 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 and the GSM ciphering algorithm 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 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 a PS signalling connection exists (which includes an RRC 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 that follows the authentication procedure (see section 2.1.5.3).



UE Ser vi ng
RNC
HLR/ Auc CN
18. Di rect Transf er : Aut hent icat ion ( and Ci pher i ng) Request
19. Di rect Transf er: Aut hent i cat i on (and Ci pher i ng) Response
16. Send Aut hent icat ion Info
17. Send Aut hent i cat i onInfo Ack

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.



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 protection 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 Ser vi ng
RNC
CN
Sel ect al l owed UI A, UEAs
20. Secur i t y Mode Command ( UI A, UEA,
IK, CK, UE classmar k, et c)
21. Gener at e FRESH. St ar t Int egr it y Decipher ing
22. DCCH: Secur i t y Mode Command ( CN Domai n,
UIA, UEA, IK, CK, UE cl assmar k, et c)
23. Cont r ol of UE Classmar k, St ar t of
Int egri t y, Ver ify Message, St ar t Cipher ing
24. DCCH: Secur i t y Mode Compl et e
25. Ver ify r eceived message st ar t Cipher ing
26. Secur i t y Mode Compl et e
RRC RRC
RRC RRC
RANAP
RANAP RANAP
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.


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 received 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 bearers 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:


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 Ser vi ng
RNC
CN
27: Dir ect Tr ansfer : (CM) Ser vice 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


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


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


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 Node B
Dri f t RNS
Node B
Servi ng RNS
Drift
RNC
Ser vi ng
RNC
CN
RNSAP RNSAP
34. Radi o Li nk Reconfi gur at i on
Ready
RRC RRC

46. DCCH : Radi o Bear er Set up Comp lete
NBAP
NBAP
35. Radi o Li nk Reconfi gur at i on Ready
NBAP
NBAP
33 Radi o Li nk Reconf i gur at i on Ready

40. NodeB - SRNC Dat a Tr anspor t Bear er Sync.

NBAP
NBAP
43. Radi o Li nk Reconf i gur at i on Commi t
RNSAP RNSAP
41. Radio Link Reconfigur at i on
Commi t
NBAP
NBAP
RRC RRC

44. DCCH : Radio Bear er Set up
45. Apply new t r anspor t for mat set
Select L1, L2 and Iu Dat a
Tr anspor t Bear er par amet ers
47. RAB As s i gnment
Response
29. ALCAP I u Dat a
Tr anspor t Bear er Set up
Not requi red t owards PS
domai n
RANAP RANAP
28. RAB As s i gnment
Request
[Est abl i shment ]
RNSAP RNSAP
Prepare
[DCH Addi t i on]
NBAP
NBAP
31. Radio Link Reconfigur at ion Pr epar e
[DCH Addi t i on]
NBAP
NBAP
32. Radi o Li nk Reconfi gur at i on Pr epar e
[ DCH Add ition]
ALCAP Iur Bear er Set up 38. ALCAP Iub Dat a Tr anspor t Bear er Set up
RANAP RANAP
DCH -FP
DCH-FP
DCH-FP

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



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


configuration, which has just been prepared for the Radio Link(s) within the Node B at the
CFN requested.
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.



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.

starts timer T
RABAssgt
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
for the release.

capabilities.

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


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.
Diagnostics. [see REF 25.433 for more details].

UE Node B
Drift RNS
Node B
Serving RNS
Drift
RNC
Serving
RNC
CN
RRC
RRC
46. DCCH: Radio Bearer Setup Complete
NBAP NBAP
37. Radio Link Setup Response
RRC
RRC
44. DCCH: Radio Bearer Setup
RANAP RANAP
47. RAB Assignment
Response
RANAP RANAP
28. RAB Assignment
Request
[Establishment]
NBAP
NBAP
36. Radio Link Setup Request
39. ALCAP Iub Data Transport Bearer Setup
29. ALCAP Iu Data Transport Bearer Setup
not required towards PS domain
Select L1, L2 and Iu Data
Transport Bearer Parameters

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
bind the Iub Data Transport Bearer to DCH.
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.
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: RABs setup IEs as RAB ID, Transport Layer Address (PS domain only) and Iu

RABAssgt
only if
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.

starts timer T
RABAssgt
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
for the release.


capabilities.

UE Node B
Drift RNS
Node B
Serving RNS
Drift
RNC
Serving
RNC
CN
RRC
RRC
46. DCCH: Radio Bearer Setup Complete
RRC
RRC
44. DCCH: Radio Bearer Setup
RANAP RANAP
47. RAB Assignment
Response
RANAP RANAP
28. RAB Assignment
Request
[Establishment]
29. ALCAP Iu Data Transport Bearer Setup

Figure 14: Radio Access Bearer Establishment RACH/FACH RACH/FACH Establishment
Unsynchronised
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.
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: RABs setup IE as RAB ID, Transport Layer Address (PS domain only) and Iu



RABAssgt
only if
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 PMM-
CONNECTED 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 PMM-
IDLE 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.
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.


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.

1: RRC Connection Request
3G-SGSN UE
10B. Initial Direct Transfer: Service Request
12-26: Security Functions
SRNC
6: RRC Connection Setup
HLR

3G-GGSN

51. Create PDP Context Response
50. Create PDP Context Request
48. Direct Transfer: Activate PDP Context Request
28-47. Radio Access Bearer Setup
C1
C2
49. Invoke Trace
Uplink PDU
52. Direct Transfer: Activate PDP Context Accept
11. Common ID

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


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.


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



53.Direct Transfer: Setup
UE
10B. Initial Direct Transfer: CM Service Request
12-27: Security Functions
SRNC
HLR

56. ISUP ACM
28-47. Radio Access Bearer Setup
60. Direct Transfer: Connect Acknowledge
54.Direct Transfer: Call Proceeding
58. ISUP ANM
57. Direct Transfer: Alerting
59. Direct Transfer: Connect
55. ISUP IAM
Calling
MSC/VLR
Called
MSC/VLR

11. Common ID

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 Control 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


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.



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.



UE SGSN GGSN
4. PDU Notification Request
HLR
1. PDP PDU
2. Send Routeing Info for GPRS
3. Send Routeing Info for GPRS Ack
11. Direct Transfer: Request PDP Context Activation
5. PDU Notification Response
UTRAN
6. Paging Request
Downlink PDU
8. Initial Direct Transfer: Service Request
10: Security Functions
51. Create PDP Context Response
50. Create PDP Context Request
12. Direct Transfer: Activate PDP Context Request
13. Radio Access Bearer Setup
C1
C2
49. Invoke Trace
52. Direct Transfer: Activate PDP Context Accept
9. Common ID

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


the PDP Context Activation will proceed, i.e., Cause value set to 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.



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.


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 Called
MSC/VLR
Calling
MSC/VLR
1. ISUP IAM
HLR
7. Direct Transfer: Setup
11. ISUP ACM
UTRAN
2. Paging Request
4. Initial Direct Transfer: Paging Response
6: Security Functions
14. ISUP ANM
8. Direct Transfer: Call Confirmed
9. Radio Access Bearer Setup
13. Direct Transfer: Connect Acknowledge
5. Common ID
10. Direct Transfer: Alerting
12. Direct Transfer: Connect

Figure 18: Successful Mobile Terminated 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


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


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


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

RANAP
UE RNC CN RNC

NODE B

RANAP
1. Paging
RANAP RANAP
1. Paging
RANAP RANAP
1. Paging
A) UE is in IDLE mode
2. PCCH: Paging Type I
RNSAP RNSAP
B) UE is in URA connected mode
or in Cell_PCH RRC state
2. Paging Request
C) UE is in cell connected mode
with existing DCCH
2. DCCH: Paging Type 2
RRC
RRC
RRC
RRC
RRC
RRC
RRC
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


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


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.

3G-GGSN
3. Delete PDP Context Response
2. Delete PDP Context Request
3G-SGSN UTRAN UE
1. Direct Transfer: Deactivate PDP Context Request
4. Direct Transfer: Deactivate PDP Context Accept
UTRAN Resources Release
C1

Figure 20: PDP Context Deactivation Initiated by UE procedure


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
(TI
2
) 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
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.
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.


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 release 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 User-
User 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.

Called MSC
2. ISUP REL
Calling MSC UTRAN UE
1. Direct Transfer: Disconnect
4. Direct Transfer: Release Complete
3. Direct Transfer: Release

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.


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.


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.

CN
Iu Release Request
RNC UE
6. Release of RAB or RRC Connection
5. Iu Release Command
7. Iu Release Complete
RANAP RANAP
RANAP RANAP
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 carried out by different entities within the RNC.


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.

7. Iu Release Complet e
5. Iu Release Command
9. ( on DCCH or CCCH) RRC Connect i on Rel ease Compl et e

6. ( on DCCH or CCCH) RRC Connect i on Rel ease
UE Node B
Drift

RNS

Node B
Servi ng

RNS

Drift
RNC

Serving
RNC

CN
RRC
RRC

RANAP
RANAP
8. ALCAP Iu Bear er Release
RANAP
RANAP
RRC
RRC

Figure 23: RRC Connection release of a common 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


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.

14. Radi o Li nk Del et i on Response

12. Radi o Li nk Del et i on


10. Radi o Li nk Del et i on

9. ( on DCCH or CCCH) RRC Connect i on Rel ease Compl et e

6. ( on DCCH or CCCH) RRC Connect i on Rel ease


11. Radio Link Delet ion

UE

Node B

Drift

RNS

Node B

Serving

RNS

Drift

RNC

Serving

RNC

CN

RRC

RRC

RRC

NBAP

N

B

AP

RNSAP

NBAP

NBAP

NBAP

RN

S

AP

RANAP

RANAP

8. ALCAP Iu Bear er Release

ALCAP I ur Bear er
Release
17. ALCAP Iub Bear er Rel ease
16. ALCAP Iub Bear er Rel ease
5. I u Rel ease Command

7. Iu Rel ease Compl et e

RRC

RANAP

N

B

AP

RN

S

AP

NBAP

NBAP

RNSAP

RANAP

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.


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.
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
and respond to the CRNC with the NBAP Radio Link Deletion Response message.
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 Transport 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, but 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.


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

CN
RAB Release Request
RNC UE
6B. Release of RAB
5B. RAB Assignment Request
7B. RAB Assignment Response
RANAP RANAP
RANAP RANAP
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.


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 UE-
UTRAN 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


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).
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 f t RNS
Node B
Servi ng RNS
Dr ift
RNC
Ser vi ng
RNC
CN
RANAP RANAP
16. RAB Assi gnment
Response
17. ALCAP Iu Da t a Tr anspor t
Bear er Release
not requi red t owards PS
domai n
RANAP RANAP
1. RAB Assign ment
Request
[Rel ease]
RNSAP RNSAP
Ready
RRC
RRC

13. DCCH : Radi o Bear er Rel ease Compl et e
NBAP
NBAP
7. Radio Link Reconfigur at ion Ready
NBAP
NBAP
5. Radi o Li nk Reconfi gur at i on Ready
NBAP
NBAP
RNSAP RNSAP
Commi t
RRC
RRC

11. DCCH : Radio Bear er Release
12. Apply new t r anspor t for mat set
NBAP
NBAP
9. Radi o Li nk Reconfi gur at i on Commi t
15. ALCAP Iub Dat a Tr anspor t Bear er Rel ease
RNSAP RNSAP
Prepare
[ DCH Del et i on]
NBAP
NBAP
[ DCH Del et i on]

NBAP
NBAP
[ DCH Del et i on]
ALCAP I ur Bear er Rel ease 14. ALCAP Iub Dat a Tr anspor t Bear er Rel ease

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

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.
sending a RNSAP Radio Link Reconfiguration Ready message.
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.
Ready message.
Parameters: CRNC Communication Context ID, RL Information Response, and optionally IE

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
configuration, which has just been prepared for the Radio Link(s) within the Node B, at the
CFN requested.
Information.
10. SRNC (really CRNC) sends a NBAP Radio Link Reconfiguration Commit message to its
configuration, which has just been prepared for the Radio Link(s) within the Node B at the
CFN requested.
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.


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


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
CN
RNSAP RNSAP
10. RL Reconfiguration
Response
RRC
RRC
3. DCCH Radio Bearer Release Complete
NBAP
NBAP
11. Radio Link Reconfiguration Response
NBAP
NBAP
9. Radio Link Reconfiguration Response
RRC
RRC
2. DCCH Radio Bearer Release
RANAP RANAP
4. RAB Assignment
Response
13. ALCAP Iub Data Transport Bearer Release
5. ALCAP Iu Data
Transport Bearer Release
RANAP RANAP
1. RAB Assignment
Request
[Release]
RNSAP RNSAP
6. RL Reconfiguration
Request
[DCH Deletion]
NBAP
NBAP
7. RL Reconfiguration Request
[DCH Deletion]
NBAP
NBAP
8. RL Reconfiguration Request
[DCH Deletion]
ALCAP Iur Bearer Release 12. ALCAP Iub Data Transport Bearer Release

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).
this message DRNC may also reconfigure any other DCH it has with concerned Node B [see
REF 25.433 for more details].



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).
this message DRNC may also reconfigure any other DCH it has with concerned Node B [see
REF 25.433 for more details].
Response message.
sending a RNSAP Radio Link Reconfiguration Response message.
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.
Response message.
Criticality diagnostics. If SRNC is reconfiguring any other channel, it should send

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

3.1.3.3.3 RACH/FACH DCH RAB Release procedure


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

Node B

Drift RNS

Node B

Serving RNS

Drift

RNC

Serving

RNC

CN

RRC

RRC


NBAP

NBAP

7. Radio Link Deletion Response

RRC

RRC


RANAP

RANAP

4. RAB Assignment

Response


5. ALCAP Iu Data

RANAP

RANAP

1. RAB Assignment

Request

[Release]

NBAP

NBAP

6. Radio Link Deletion Request

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


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 Node B
Drift RNS
Node B
Serving RNS
Drift
RNC
Serving
RNC
CN
RRC
RRC
RRC
RRC
RANAP RANAP
4. RAB Assignment
Response
5. ALCAP Iu Data
RANAP RANAP
1. RAB Assignment
Request
[Release]

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




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.

3G-GGSN
3G-SGSN UTRAN UE
C1

Figure 30: PDP Context Deactivation Initiated 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.
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.


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.

3G-GGSN
3G-SGSN UTRAN UE
C1

Figure 31: PDP Context Deactivation Initiated 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.
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.

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.


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). In addition, network may initiate call clearing for any other particular network reason such as
communication failure.
[Ref 24.008], section 5.4.2, defines some exception conditions that allow different clearing
procedures. Some conditions will allow the introduction of shorter call clearing 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 clearing by sending Release message
B. Network initiates clearing by sending Disconnect message to an UE that does not support
the Prolonged Clearing Procedure
C. Network initiates clearing by sending Disconnect message to an UE that does support the
Prolonged Clearing Procedure

Case A
Network may initiate clearing by sending 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 described in section 3.1 will also apply now for the Mobile Terminated Call Release. This
case is depicted in Figure 32 and described below.

Calling MSC
1. ISUP REL
Called MSC UTRAN UE

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


1. Called MSC 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, 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; however, it may carry information of global
significance 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 of Release message, UE shall stop all running call control timers, 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.
connection.

Case B
Network initiates call clearing by sending a Disconnect message to an UE that does not support
the Prolonged Clearing Procedure. Figure 33 shows this scenario.
1. Called MSC 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 decides 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/announcements are provided, 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 Disconnect message by UE in any state except the Null state, the
Disconnect Indication state and the Release Request state, and depending on the reception
of progress indicator #8, UE has two possibilities:
a. If progress indicator #8 is not present, UE shall stop all running call control timers,
send Release message, start timer T308, and enter the Release Request state.
b. If progress indicator #8 is present, UE shall attach appropriate speech channel for
connecting the in-band tone/announcements, if connected and not attached yet, and
enter the Disconnect 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.


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, 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.
connection.

Calling MSC
1. ISUP REL
Called MSC UTRAN UE
2. Direct Transfer: Disconnect

Figure 33: Call Clearing Initiated by MSC with Disconnect message procedure
Case C
Network initiates call clearing by sending a Disconnect message to an UE that does support the
Prolonged Clearing Procedure. Then, Call Completion Busy Subscriber (CCBS) network feature
must be taken into account at the Call Release process
4
. 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 Disconnect message to its peer entity of the UE including
Allowed Actions IE set to Activation of CCBS is possible if CCBS is possible. Otherwise,

4
CCBS was not considered at CS domain Call Establishment.


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



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.


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, 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].

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.
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).
Diagnostics. [See REF 25.433 for more details].


UE Node B
Dri f t RNS
Drift
RNC
Ser vi ng
RNC
DCH- FP DCH -FP
6. Downl i nk Synchr oni sat i on
RNSAP RNSAP
1. Radi o Li nk Set up
Request
Start TX
NBAP NBAP

Request
RNSAP RNSAP
Response
NBAP NBAP
Response
St ar t RX
Decision t o set up
new RL
RRC RRC

8. DCCH : Act i ve Set Updat e Compl et e
RRC
RRC

7. DCCH : Act ive Set Updat e
[Radi o Li nk Addi t i on]
ALCAP Iur Bear er Set up 5. ALCAP Iub Bear er Set up
DCH -FP DCH -FP
6. Uplink Synchr onisat ion

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.


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


corresponding radio link(s) towards UE with the RNSAP Radio Link Deletion Request
message.

UE Node B
Dri f t RNS
Drift
RNC
Ser ving
RNC
RRC RRC
2. DCCH : Act ive Set Updat e Complet e
Decision t o delet e
old RL
RNSAP RNSAP
Request
NBAP NBAP
Request
RNSAP RNSAP
Response
NBAP NBAP
Response
St op RX and TX
RRC
RRC
[Radi o Li nk Del et i on]
ALCAP Iur Bear er Release 7. ALCAP Iub Bear er 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.
released.
5. Upon reception of Radio Link Deletion Request message, the Node B controlled by DRNC
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.
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.
protocol.


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.



6. Uplink Synchr onisat ion
RNSAP RNSAP
1. Radi o Li nk Addi t i on
Request
St ar t TX
descr ipt ion
RNSAP RNSAP
4. Radi o Li nk Addi t i on
Response
NBA P NBAP

2. Radio Link Set up Request
NBAP NBAP
3. Radi o Li nk Set up Response
St art RX
descr ipt ion
Deci si on t o set up
new RL a nd
r elease old RL
NBAP

9. Radi o Li nk Del et i on Request
NBAP NBAP
10. Radi o Li nk Rel ease Response
St op RX and TX
11. ALCAP Iub Dat a Tr anspor t Bear er Release
RRC RRC

8. DCCH : Act i ve Set Updat e Compl et e
RRC RRC

[ Radi o Li nk Addi t i on & Del et i on]
NBAP
UE Node B
Drift RNS
Node B
Servi ng RNS
Drift
RNC
Ser vi ng
RNC
DCH-FP
DCH-FP
DCH-FP DCH-FP
6. Downlink Synchr onisat ion
ALCAP Iur Dat a Tr anspor t
Bear er Set up

Figure 36: Soft Handover - Radio link Addition & Deletion (Branch Addition & Deletion -
simultaneously)
4. Upon reception of previous message, DRNC sends back a RNSAP Radio Link Addition


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.
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.
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.
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.
released.
10. Upon reception of Radio Link Deletion Request message, the Node B controlled by SRNC
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.
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.


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 Handovers
6

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 to Annex A.


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 Inter-
frequency 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.



Stop RX &TX
RNSAP RNSAP
1. Radio Link
Setup Request
Note 1
UE Node B
Source
Node B
Target
RNC
Source

RNC
target

SRNC
RRC
RRC
11. DCCH : Physical Channel Reconfiguration Complete
Note 3
RRC
8. DCCH : Physical Channel Reconfiguration
Note 3 RRC
6. ALCAP Iur Data
Transport Bearer Setup
Note 1
NBAP NBAP

2. Radio Link Setup Request
NBAP NBAP
3. Radio Link Setup Response
NBAP NBAP

13. Radio Link Deletion Request
NBAP NBAP
14. Radio Link Deletion Response
4. ALCAP Iub Data Transport Bearer Setup
RNSAP RNSAP 16. Radio Link Deletion Response
Note 2
17. ALCAP Iur Data
Note 2
RNSAP
5. RL Setup
Response
Note 1
RNSAP
RNSAP 12. Radio Link Deletion Request
Note 2
RNSAP
NBAP NBAP
9. Radio Link Failure Indication
RNSAP RNSAP 10. Radio Link Failure Indication
Note 2
Start RX
DCH-FP DCH-FP
7. Downlink Synchronisation
Start TX
DCH-FP DCH-FP
7. Uplink Synchronisation

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


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


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


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
T
RELOCprep
.


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



U E S R N C
S o u r c e
S R N C
T a r g e t
M S C N o d e B
S o u r c e
N o d e B
T a r g e t
S G S N
R A N A P
1 . R e l o c a t i o n Re q u i r e d
R A N A P R A N A P
R A N A P R A N A P

2 . Re l o c a t i o n Re q u e s t
R A N A P R A N A P
8 . R e l o c a t i o n R e q u e s t
Ac k n o wl e d g e
R A N A P R A N A P
1 . Re l o c a t i o n Re q u i r e d
R A N A P R A N A P

2 . Re l o c a t i o n Re q u e s t
R A N A P
8 . R e l o c a t i o n R e q u e s t Ac k n o wl e d g e
3 . AL C AP I u D a t a
T r a n s p o r t Be a r e r S e t u p
N B A P N B A P
4 . R a d i o L i n k S e t u p R e q u e s t
N B A P N B A P
5 . R a d i o L i n k S e t u p R e s p o n s e
6 . AL C AP I u b Da t a T r a n s p o r t Be a r e r S e t u p
S t a r t R X
D C H - FP D C H - FP
7 . Do wn l i n k & Up l i n k S y n c h r o n i s a t i o n
S t a r t T X
R A N A P R A N A P
1 7 . Re l o c a t i o n
C o mp l e t e
R R C R R C
1 6 . DC C H : P h y s i c a l C h a n n e l R e c o n f i g u r a t i o n C o mp l e t e No t e 1
R A N A P R A N A P
1 7 . R e l o c a t i o n C o mp l e t e
R A N A P
1 8 . I u R e l e a s e C o mma n d
R A N A P
R A N A P
1 8 . I u R e l e a s e C o mma n d
R A N A P
R A N A P R A N A P
1 4 . Re l o c a t i o n
De t e c t
R A N A P
R A N A P
1 4 . Rel o c a t i o n De t e c t
N B A P N B A P
1 5 . Ra d i o L i n k F a i l u r e I n d i c a t i o n
R A N A P R A N A P

1 2 . F o r wa r d S R NS C o n t e x t
1 3 . F o r wa r d i n g o f Da t a

1 9 . R o u t i n g / L o c a t i o n Ar e a Up d a t e
R A N A P R A N A P
9 . R e l o c a t i o n C o mma n d
R A N A P
9 . R e l o c a t i o n C o mma n d
R A N A P
R R C
1 0 . DC C H : P h y s i c a l C h a n n e l R e c o n f i g u r a t i o n No t e 1
R R C
R A N A P R A N A P
1 1 . F o r wa r d S R NS C o n t e x t
C 1

Figure 38: Intra CN nodes Hard Handover with switching in the CN (UE connected to two CN
nodes, 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
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
T
DATAfwd
, 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
T
RELOCprep
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


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.
Information Info (which contains among others Location Area Identification and Routeing
Area Identification), RB Information Elements (RB with PDCP information for each RB with

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

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.
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.
Link(s).
17. After successful switch in Target RNC (now SRNC for UE) and when the new SRNC-ID + S-
RNTI 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.
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.


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.

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
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
T
RELOCprep
.
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


active), Target ID, UTRAN Transparent Container and optional Private Extension for
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).



UE S R NC
Tar get
Ol d
SGSN
New
S GS N
Node B
Tar get
S R NC
Sour ce
GGS N
R AN AP
1. Rel oc a t i on Requi r ed
R AN AP R AN AP
2. For wa r d Rel oc a t i on Reques t
R AN AP R AN AP

3. Rel oca t i on Reques t
R AN AP
8 . Rel oc a t i on Requ es t Ac knowl edge
N B AP N B AP
4. Ra di o Li nk Set up Reques t
NB AP NB AP
5. Ra di o Li nk Set up Res pons e
6. ALCAP I ub Da t a Tr a ns por t Bea r er Set up
St a r t RX
DC H - FP DC H - FP
7 . Downl i nk & Up l i nk Sync hr oni s a t i on
St a r t TX
C 1
9. For wa r d Rel oc a t i on Res pons e
R AN AP
R AN AP
17. Rel oca t i on Det ect
R AN AP R AN AP

1 5 . For wa r d SRNS Cont ex t
16. For wa r di ng of Da t a
R AN AP R AN AP
1 0 . Rel oc a t i on Comma nd
R R C
11. DCCH : Phys i c a l Cha nnel Rec onf i gur a t i on
Not e 1 R R C
R AN AP R AN AP
1 4 . F or wa r d S RNS Cont ex t Ac knowl edge
18. Upd a t e PDP Cont ext Reques t
1 9 . Up da t e PDP Cont ex t Res p ons e
R R C R R C
20. DCCH : Phys i ca l C ha nnel Rec onf i gu r a t i on Comp l et e Not e 1
R AN AP R AN AP
21. Rel oc a t i on Compl et e
R AN AP
2 4 . I u Rel ea s e Comma nd
R AN AP

25. Rout i ng Ar ea Upda t e
22. For wa r d Rel oc a t i on Compl et e
2 3 . For wa r d Rel oc a t i on Comp l et e Ac knowl edge

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


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
T
DATAfwd
, 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
T
RELOCprep
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
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.
Information Info (which contains among others Location Area Identification and Routeing
Area Identification), RB Information Elements (RB with PDCP information for each RB with

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


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 related 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.
Link(s).


21. After successful switch in Target RNC (now SRNC for UE) and when the new SRNC-ID + S-
RNTI 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.
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
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.

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
C1) CAMEL-GPRS-SGSN-Context-Acknowledge.



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



UE R N C
Sour ce
R N C
Tar get
MS C/ S GS N No d e B
Sour ce
No d e B
Tar get
S GS N/ MS C
R A N A P
1. Rel oc a t i on Requ i r ed
R A N A P R A N A P
R A N A P R A N A P

2 . Rel oc a t i on Requ es t
R A N A P R A N A P
Ac k n o wl e d g e
R A N A P R A N A P
1 . Rel oc a t i on Requ i r ed
R A N A P R A N A P

R A N A P
8 . Re l oc a t i on Re qu e s t Ac knowl e dge
R A N A P R A N A P
9 . Re l o c a t i o n Co mma n d
R A N A P
9 . Re l oc a t i on Comma nd
R A N A P
3 . ALCAP I u Da t a
Tr a ns por t Bea r er Set up
N B A P N B A P
4 . Ra di o Li nk S et u p Requ es t
N B A P N B A P
5 . Ra di o Li nk S et u p Res p ons e
6 . ALCAP I u b Da t a Tr a n s por t Bea r er Set up
S t a r t RX
D C H- FP D C H - FP
7 . Downl i nk & Up l i nk S ync hr oni s a t i on
St a r t TX
R A N A P R A N A P
1 6 . Rel oc a t i on
Comp l et e
R A N A P R A N A P
1 6 . Rel oc a t i on Comp l et e
R A N A P
1 7 . I u Re l e a s e Co mma n d
R A N A P
R A N A P
1 7 . I u Re l e a s e Co mma n d
R A N A P

1 8 . Rou t i ng/ Loc a t i on Ar ea Up da t e

R A N A P R A N A P
Det ect
R N S AP R N S AP
C o mmi t
R R C RRC
15. D C C H: RNT I Re a l l oc a t i on Comp l e t e
R A N A P
R A N A P
1 2 . Rel oc a t i on Det ec t
N B A P N B A P
13. Ra di o Li nk Fa i l ur e I ndi c a t i on
11. For wa r d i ng of Da t a
R R C R R C
14. D C C H : RNT I Rea l l oca t i on

Figure 40: SRNS Relocation procedure (UE connected to two CN nodes, DCH state)
11. (PS domain only) Previous message contains necessary information for forwarding in place of
the Forward SRNS Context procedure used in the Hard Handover cases. After sending it,
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.
12. The reception of the Relocation Commit message in step 10 triggers the execution of the
Relocation of the SRNS. Then Target SRNS sends the RANAP Relocation Detect message to
both CN nodes and starts the SRNC operation.


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.


RNC
Node B
RNC
UE
RANAP PAGING
RANAP PAGING
RANAP PAGING
RNSAP PAGING REQUEST
DCCH : PAGING TYPE 2
FP PCH
Case1:
UE is in idle mode
Case 4:
UE is in cell connected mode
with existing DCCH
Cases 2 and 3:
UE is in URA connected mode ),
or Cell-PCH state (only for R1)
FP PCH
FP PCH

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.


6.2.2.2 Intra-RNS URA Update
UE Serving
RNC
RRC
RRC
1. CCCH: URA Update
[S-RNTI, SRNC-ID]
RRC RRC
2. CCCH or DCCH: URA Update Confirm
[S-RNTI, SRNC-ID]
RRC RRC
3.DCCH: RNTI Re-Allocation Complete

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


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
3. Allocate D-RNTI and
C- RNTI
5. Decision:
Not to perform
SRNC relocation
RNSAP RNSAP
4. Uplink Signalling Trasfer Indication
[C-RNTI, D-RNTI,
Uu Signalling Message ]
1. Reception of Uu
Signalling Message
2. Decoding of RNC-ID
from the UL message
RNSAP RNSAP
6. Downlink Signalling
Transfer Request
7. Transmission of
Uu Signalling Message
8. Release of D-RNTI and
C- RNTI
[C-RNTI,
Uu Signalling Message ]

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.



UE SRNC =
CRNC
RRC
RRC
23. CCCH: Cel l Updat e
[ S-RNTI, SRNC-ID]
RRC RRC
34.DCCH: Cel l Updat e Conf i rm
[ S- RNTI , SRNC- I D, new C- RNTI ]
Allocat e
C- RNTI
RRC RRC
45.DCCH: RNTI Re-Al l ocat i on Compl et e
RRC RRC
56.DCCH: Physi cal Channel Reconf i gurat i on Compl et e
RRC
RRC
12. PCCH: Pagi ng Type 1

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 U-
RNTI, 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 allocated by the UTRAN are described in the next section.


4. In case common physical channels info are sent by SRNC, with or without a new C-
RNTI
8
, 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 periodic-
cell 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 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.
l 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 C-
RNTI.
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 allocated by the UTRAN are described in the next section.


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 DRNC
Source
DRNC
Target
SRNC MSC/SGSN
RNSAP RNSAP
101. Common Transp. Ch. Resources Release Request
3. Allocatinge C- RNTI + D-RNTI
5. Decision:
Not to perform
SRNC relocation
RNSAP RNSAP
4. Uplink Signalling Transfer Indication
[C-RNTI, UL message]
from the UL message
RNSAP RNSAP
6. Common Transp. Ch. Resources Request
Release C- RNTI + D-RNTI
RRC
1. CCCH: Cell Update
RRC-relay
RRC
9. DCCH: Cell Update Confirm
RRC
RNSAP RNSAP
7. Common Transp. Ch. Resources Response.
8. ALCAP Iur bearer
setup

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 cell-
ID 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


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.



UE DRNC SRNC MSC/SGSN
RNSAP RNSAP
110. Common Transport Channel
Resources Release Request
3. Allocating D-RNTI + C- RNTI
5. Decision:
Not to perform
SRNC relocation
RNSAP RNSAP
4. Uplink Signalling Transfer Indication
[new C-RNTI, UL message]
from the UL message
RNSAP RNSAP
6. Common Transp. Ch. Resources Request
121. Release indicated C- RNTI
RRC
1. CCCH: Cell Update
RRC-relay
RRC
98. DCCH: Cell Update Confirm
RRC
RRC
109. DCCH: RNTI Reallocation Complete
or Physical Channel Reconfiguration Complete RRC
RNSAP RNSAP
7. Common Transp. Ch. Resources Response.
[old C-RNTI]
8. ALCAP Iur bearer
setup

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 C-
RNTI, otherwise DRNC deletes the whole UE context.



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.


a. Without switching in CN, i.e., using Iur interface (Study implications, if any, to
existing CN connections)
b. With both PS and CS CN connections and switching in CN, i.e., using Iu interface
c. With 1 leg in a DRNC

5. Hard Handover
a. From UMTS to GSM (for both PS and CS domain)
b. From GSM to UMTS (for both PS and CS domain)

6. Modification of Call Mode, QoS or PDP context (secondary PDP contexts)

7. Attachment
a. For PS domain
b. For CS domain
c. Combined
d. Mobile Originated/Terminated

8. Detachment
a. For PS domain
b. For CS domain
c. Combined
d. Mobile Originated/Terminated

9. Location Area Update
a. After reselection
b. Periodic
c. With/without SRNC relocation
d. Inter-MSC

10. Routing Area Update
b. Periodic
d. Combined
e. Inter SGSN (the same than c??)
f. Combined Inter SGSN and Inter MSC

11. URA Update
b. Periodic

12. Cell Update
b. Periodic
d. Combined?

13. SRNC Relocation (pure procedure, which has similarities with a SRNC Relocation within
point 4.b procedure)

UMTS Call Flow

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

UMTS Call Flow

Загружено:

Авторское право:

Доступные форматы

Motorola Confidential Proprietary

UMTS Call Flows Approved Motorola: ANDC-MA-00-0.3.4-RQ

Вам также может понравиться