Professional Documents
Culture Documents
UMTS Call Flow
UMTS Call Flow
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.
1999, 2000
Copyright 1999, 2000 Motorola, USA
Approved
1
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Release History
Version
Draft 0.1
Draft 0.2
Draft 0.3
Release Date
June 19, 2000
June 27, 2000
July 24, 2000
Author(s)
Flix Bejarano (ANDC)
Flix Bejarano (ANDC)
Flix Bejarano (ANDC)
Draft 0.4
August 2, 2000
Draft 0.5
Draft 0.6
Approved 1.0
September 1, 2000
September 7, 2000
October 4, 2000
Draft 1.01
November 4, 2000
Approved
2
Change History
Original Document
Change requests from version 0.1 revision
Mobile Terminated Call Establishment, Call
Release and Soft Handover sections
Inter-frequency FDD to FDD Hard Handover
section
Update to 3GPP R99 June 2000 versions
Section 6 included
Change requests from version 0.6 revision.
This version is now section 2.15 in UTRAN
SFRAS version 1.5
Minor cosmetic changes
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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
2.1.5.2
2.1.5.3
2.1.6
2.1.7
2.1.7.1
2.1.7.2
2.1.7.3
MM Connection Established........................................................................................ 38
RAB Establishment ..................................................................................................... 39
DCH DCH RAB Establishment procedure .........................................................................39
RACH/FACH DCH Establishment procedure ....................................................................44
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
Approved
3
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Approved
4
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Table of Figures
Figure 1: Example of signalling procedure notation .......................................................................... 24
Figure 2: NAS Signalling connections ................................................................................................... 26
Figure 3: Establishment of the RRC connection on RACH/FACH ............................................................. 27
Figure 4: RRC connection establishment on DCH ................................................................................... 28
Figure 5: Initial UE message to the CN .................................................................................................. 30
Figure 6: Direct Transfer ..................................................................................................................... 31
Figure 7: Common ID procedure........................................................................................................... 32
Figure 8: Identity Check Procedure ....................................................................................................... 33
Figure 9: Authentication and Key Agreement Procedure .......................................................................... 35
Figure 10: Security Mode Set-up Procedure............................................................................................ 36
Figure 11: (CM) Service Accept ........................................................................................................... 38
Figure 12: Radio Access Bearer Establishment - DCH - DCH Establishment - Synchronized ........................ 41
Figure 13: Radio Access Bearer Establishment RACH/FACH - DCH Establishment Unsynchronised ....... 45
Figure 14: Radio Access Bearer Establishment RACH/FACH RACH/FACH Establishment
Unsynchronised .......................................................................................................................... 47
Figure 15: Service Request and PDP context Activation Initiated by UE Procedures
(PS domain only)49
Figure 16:CS Domain Call Setup (CS domain only) ................................................................................ 52
Figure 17: Successful Network-Requested PDP Context Activation Procedure ............................................ 55
Figure 18: Successful Mobile Terminated CS Domain Call Establishment .................................................. 58
Figure 19:Paging Procedure for different UE RRC modes ........................................................................ 61
Figure 20: PDP Context Deactivation Initiated by UE procedure ............................................................... 63
Figure 21: Call Clearing Initiated by UE procedure ................................................................................. 65
Figure 22: Iu Signalling Connection Release Procedure............................................................................ 67
Figure 23: RRC Connection release of a common transport channel........................................................... 68
Figure 24: RRC Connection release of a dedicated channel ....................................................................... 69
Figure 25: RAB Release Procedure ....................................................................................................... 71
Figure 26: Radio Access Bearer Release - DCH - DCH Release - Synchronised .......................................... 73
Figure 27: Radio Access Bearer Release - DCH - DCH Release - Unsynchronised ....................................... 76
Figure 28: Radio Access Bearer Release RACH/FACH - DCH Release - Unsynchronised.......................... 78
Figure 29: Radio Access Bearer Release - RACH/FACH - RACH/FACH Release ....................................... 79
Figure 30: PDP Context Deactivation Initiated by SGSN procedure ........................................................... 80
Figure 31: PDP Context Deactivation Initiated by GGSN procedure .......................................................... 81
Figure 32: Call Clearing Initiated by MSC with Release message procedure ............................................... 82
Figure 33: Call Clearing Initiated by MSC with Disconnect message procedure........................................... 84
Figure 34: Soft Handover - Radio Link Addition (Branch Addition) .......................................................... 88
Figure 35: Soft Handover - Radio Link Deletion (Branch Deletion) ........................................................... 90
Figure 36: Soft Handover - Radio link Addition & Deletion (Branch Addition & Deletion - simultaneously) ... 92
Figure 37: Inter-frequency FDD to FDD Hard Handover via Iur (UE in DCH state) ..................................... 96
Figure 38: Intra CN nodes Hard Handover with switching in the CN (UE connected to two CN nodes, DCH
state) ........................................................................................................................................101
Figure 39: Inter CN nodes Hard Handover with switching in the CN (PS domain only, UE in DCH state) .....107
Figure 40: SRNS Relocation procedure (UE connected to two CN nodes, DCH state) .................................113
Figure 41: Paging message flow over Iu, Iub and Iur .......................................................................115
Figure 42: Intra RNS URA Update ..................................................................................................116
Figure 43: Inter RNS URA update without SRNS relocation ...........................................................117
Figure 44: Intra RNS Cell Update in case SRNC=CRNC.................................................................118
Figure 45: Cell Update via Iur (case without C-RNTI re-allocation).................................................120
Figure 46: Inter-RNS cell update via Iur (case with C-RNTI re-allocation) ......................................122
Approved
5
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Reference List
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
Approved
6
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Glossary of terms
Acronym
Definition
3GPP
AAL
AAL2
AAL5
ABT/DT
ABT/IT
A&C
ACCH
ACD
ACFE
ACP
ACSE
ADM
AE
Application Entity
AI
Acquisition Indication
AICH
AIS
ALCAP
AM
AMR
AN
Access Network
AOA
Angle Of Arrival
AP
Application Process
APDU
APId
APN
APS
ARIB
ARQ
ASAP
ATC
ATM
Approved
7
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
AUG
AU-n
AUTN
Authentication Token
AWGN
BBE
BCCH
BCH
Broadcast Channel
BER
BIP-X
BLER
BMC
BPSK
BS
Base Station
BSC
BSS
BTS
C-
Control-
CA
Capacity Allocation
CAA
CAC
CAMEL
CAS
CASC
CBR
CC
Call Control
CCBS
CCCH
CCH
Control Channel
CCPCH
CCTrCH
CD
CD
CDA
CDMA
CDR
CDV
Approved
8
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
CDVT
CFN
CID
Channel Identifier
Ck
Cipher Key
CLP
CM
Configuration Management
CM
CmCH
CMIP
CMIS
CMISE
CN
Core Network
C-n
Container-n (n=1-4)
COL
Collocated Equipment
CP
Chip Period
CPCH
CPICH
CPS
CRC
CRCI
CRC Indicator
CRC-N
CRNC
Controlling RNC
c-RNTI
CS
Circuit Switched
CSES
CSN
CSUM
Checksum
CTCH
CTDMA
CTP
CTP
DBR
DC
DCA
DCC
DCCH
Approved
9
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
DCH
Dedicated Channel
DCN
DHO
DL
DownLink
DoCoMo
DPCCH
DPCH
DPDCH
DRAC
DRNC
Drift RNC
DRNS
Drift RNS
DRX
Discontinuous Reception
DS-CDMA
DSCH
DT
Data Transport
DTCH
DTX
Discontinuous Transmission
EBER
ECASC
EFCI
EFD
EIR
EIRP
E-OTD
Enhanced OTD
ES
Errored Second
ETSI
F8
FACH
FAUSCH
FBI
FCS
FDD
FDMA
FEC
FEEB
FEES
Approved
10
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
FER
FESES
FFS
FM
Fault Management
FP
Frame Protocol
FTAM
FTP
Gb
GC
GCRA
GFR
Guaranteed Rate
GGSN
GMM
GMSK
G-PDU
GPRS
GPRS-CSI
GPS
GRNC
Generic RNC
GSM
GTP
GTP-u
HCS
HE
Home Environment
HEC
HFN
HHO
Hard Handover
HO
Handover
HOP
HOVC
IBTS
ICB
ICD
ICH
Indicator CHannel
ICI
IE
Information Element
Approved
11
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
IEC
IETF
IK
Integrity Key
IMA
IMEI
IMEISV
IMSI
IMUI
INI
IP
Internet Protocol
ISCP
ISDN
ISF
IS-FL
ISID
ISO
IT
Information Technology
ITU
Iu
Iub
Iu-CS
Iu-PS
Iur
IWF
IWU
JD
Joint Detection
Kbps
KSI
Ksps
L1
L2
L3
L3-CE
LAC
LAI
Approved
12
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
LAN
LAPD
LB
Laser Bias
LCAF
LCCF
LCCTF
LCD
LCD
LCF
LCS
LDD
LIR
LLC
LMT
LNA
LOF
Loss of Frame
LOP
LOP
Loss of Pointer
LOS
Loss of Signal
LPA
LSA
LSB
LSBF
LSCF
LSN
LSPF
LT
Laser Temperature
MA
Multiple Access
MAC
MAC-b
MAC-c
MAC-d
MAC-I
MAC-p
MAC-sh
MAHO
Approved
13
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
MBS
MCC
MCD
Mcps
MD
Macro-diversity
ME
Mobile Equipment
MEHO
MIB
MM
Mobility Management
MNC
MNRG
MNRR
MO
Mobile Originated
MOHO
MS
MS
MS-AIS
MSB
MSC
MSC
MSID
MSOH
MSP
MS-RDI
MS-REI
MSTE
MT
MT
MTP
MUI
NAS
NBAP
NCSES
NDF
NE
Network Element
NEHO
Approved
14
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
NEM
NMC
NNI
NP
Nectar Pilot
NPC
NRT
Non-Real Time
NSS
NT
Nectar Telecom
Nt
Notification (SAP)
NW
Network
N-PDU
Network PDU
O&M
OAM
OCCCH
ODCCH
ODCH
ODI
ODMA
ODTCH
OEI
OFS
OMC
OOF
Out of Frame
ORACH
OS
Operation System
OSF
Offset Field
OSI
OSL
OTD
OVSF
PA
Power Amplifier
PC
Power Control
PCCH
PCF
PCH
Paging Channel
PCM
Approved
15
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
PCR
PDCP
PDH
PDN
PDP
PDU
PG
Processing Gain
PHY
Physical layer
PhyCH
Physical Channel
PI
Paging Indicator
PICH
PID
Packet Identification
PJC
PJE
Pkg
Packages
PLM
Payload Mismatch
PLMN
PM
PMM
MM for PS domain
PN
Pseudo Noise
POH
Path Overhead
PPI
PPM
PRACH
PRCF
PS
Packet Switched
PSAP
PSC
PSD
PSMF
PSN
PSTN
PTE
PVC
P-TMSI
P-TMUI
Packet TMUI (equivalent to P-TMSI, new name for it in the UMTS context)
Approved
16
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
PTR
Pointer
PUF
Power Up Function
QE
Quality Estimate
QoS
Quality of Service
QPSK
R0
R1
RA
Routing Area
RAB
RAC
RAC
RACH
RAI
RAI
RAID
RAN
RANAP
RAND
Random Challenge
RB
Radio Bearer
RDI
RDN
REI
RF
Radio Frequency
RFC
RFN
RLC
RLCP
RNC
RNCC
RNS
RNSAP
RNTI
RP
Radio Processing
RRC
RRM
RS
Regenerator section
Approved
17
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
RSCP
RSOH
RSSI
RT
Real Time
RU
Resource Unit
RX
Receive
SAAL
SACCH
SAP
SBR
SC
Service Control
SCCH
SCCP
SCD
SCH
Synchronization Channel
SCR
SCTP
SD
SD
SDCCH
SDH
SDU
SES
SF
SF
SFN
SG
Study Group
SGSN
SHO
SIM
SIR
Signal-to-Interference Ratio
SLM
SMS
SN
Serving Network
SN
Sequence Number
SNMP
Approved
18
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
SOH
Section Overhead
SONET
SP
Switching Point
SPA
SPI
SPI
SPROC
System PROCessor
SRNC
Serving RNC
SRNS
Serving RNS
s-RNTI
SSA
SSADT
SSCF
SSCOP
SSP
SSSAR
SSTED
STF
Start Field
STM
STM(-N)
STS(-N)
STTD
TB
Transport Block
TBC
To Be Confirmed
TBD
To Be Defined
TBF
TBS
TCH
Traffic Channel
TCM
TCOH
TCP
TCP
TC-RDI
TC-REI
TCT
TCTE
Approved
19
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
TDD
TE
Terminal Equipment
TEID
Tunnel Endpoint ID
TFCI
TFCS
TFI
TFS
TFT
TFTP
TIM
TLLI
TM
TMN
TMSI
TMUI
Temporary Mobile User Identity (new name for TMSI in the UMTS context)
TN
Termination Node
TOA or ToA
Time Of Arrival
TOAWE
TOAWS
TP
Termination Point
TPC
T-PDU
TR
Threshold Reset
TRX
Transmitter/Receiver
TSID
TSS
TTC
TTI
TTI
TTP
TTP
TU
Tributary Unit
TUG
TUG(-n)
TU-n
Tributary Unit-n
Approved
20
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
TX
Transmit
U-
User-
UARFCN
UAS
Unavailable Second
UBR
UDD
UDP
UE
User Equipment
UEA
UEFN
UIA
UL
UpLink
UM
UMTS
UNEQ
Unequipped
UNI
UP
User Plane
UPC
URA
USCH
USIM
UTRA
UTRAN
Uu
UUI
VA
VBR
VC
Virtual Channel
VCC
VCI
VC-n
VLR
VP
Virtual Path
VPC
VPI
Approved
21
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
W-CDMA
Wideband CDMA
WG
Working Group
WG-n
WTR
Wait-to-Restore
XMAC-I
XOR
eXclusive OR
XPU
XRES
Expected Response
Yu
Zu
Approved
22
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
Approved
23
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
Node B
Drift RNS
Node B
Serving RNS
RNC
Drift
RNC
Serving
1. R A C H : Message
MAC
CN
MAC
[Paramet ers ]
Action description
2. C CCH : M e s s a g e
RRC
RRC
[Parameters ]
3. Message
NBAP
NBAP
[Parameters ]
NBAP
4. Message
NBAP
RANAP
5. Message
RANAP
[Parameters ]
[Parameters ]
RNSAP
6. Message
RNSAP
[Parameters ]
Iu
Iu-CS
Iu-PS
Iub
Iur
Definition
A role an RNC can take with respect to a specific set of
Node B's. This represents the RNC functions that deal with
control of subtending Node Bs. There is only one
Controlling RNC for any Node B. The Controlling RNC
has the overall control of the logical resources of its node
B's.
This represents RNC functions that deal with control of
functions during soft handover when the RNC is
downstream from the serving RNC and has control over at
least 1 Node B who has soft handover leg(s).
This represents the RNC functions that are not covered by
any of the other three types. This also relates to global
functions such as transit or ATM functions.
This is a category of handover procedures where all the old
radio links in the UE are abandoned before the new radio
links are activated.
Interface reference point between the RNS and the Core
Network. (See also Iu-CS and Iu-PS.)
Interface between the RNC and the circuit switched side of
the Core Network, typically the MSC.
Interface between the RNC and the packet switched side of
the Core Network, typically the SGSN.
Interface between the RNC and the Node B. It is
considered as a reference point.
Interface between two RNSs. While this interface logically
represents a point to point link between RNSs, the physical
Approved
24
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Term
Softer Handover
Universal Mobile Telephone
System (UMTS)
Definition
realisation may not be a direct link. It is also considered as
a reference point.
NBAP is used for setting up Radio Access Bearers (RAB)
in the Radio Network Layer over the Iub.
Radio Network Signalling over the Iu.
Radio Network Signalling over the Iur between the SRNC
and DRNC.
This represents the RNC functions that are used during an
active call or data session.
Soft handover is a category of handover procedures where
the radio links are added and abandoned in such manner
that the UE always keeps at least one radio link to the
UTRAN. This typically involves multiple Node Bs.
This is a type of soft handover that involves one or more
cells of the same Node B.
This represents the third generation mobile phone system
that incorporates both Wideband CDMA for the FDD
mode in the paired spectrum and Time Division CDMA
for the TDD mode in the unpaired spectrum.
Approved
25
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
CS -CN
UTRAN
PS -CN
RANAP Connection
RRC Connection
RANAP Connection
Approved
26
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Node B
Serving RNS
UE
Serving
RNC
1. C C C H ( o n R A C H ) : R R C C o n n e c t i o n
Request
RRC
RRC
Allocate RNTI
Select L1 and L2
parameters
6. C C C H ( o n F A C H ) : R R C C o n n e c t i o n S e t u p
RRC
RRC
7. D C C H ( o n R A C H ) : R R C C o n n e c t i o n S e t u p C o m p l e t e
RRC
RRC
8. D C C H ( o n F A C H ) : M e a s u r e m e n t C o n t r o l
RRC
RRC
Approved
27
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
Node B
Serving RNS
Serving
RNC
1. C C C H ( o n R A C H ) : R R C C o n n e c t i o n R e q u e s t
RRC
RRC
Allocate RNTI
Select L1 and L2
parameters
2. Radio Link Setup Request
NBAP
NBAP
Start RX
3. Radio Link Setup Response
NBAP
NBAP
DCH -FP
5. NodeB -S R N C D a t a T r a n s p o r t B e a r e r S y n c
(FDD only)
DCH -FP
Start TX
RRC
RRC
RRC
6. C C C H ( o n F A C H ) : R R C C o n n e c t i o n Setup
RRC
7. D C C H ( o n D C H ) : R R C C o n n e c t i o n S e t u p C o m p l e t e
RRC
8. D C C H ( o n D C H ) : M e a s u r e m e n t C o n t r o l
RRC
1. The UE initiates set-up of an RRC connection by sending RRC message RRC Connection
Request on CCCH (mapped on RACH). UE starts timer T300.
Parameters: Initial UE Identity, Establishment Cause and optionally a Measurement report
2. The SRNC may decide to use either the RACH/FACH or a DCH for this RRC connection. In
both cases, it allocates RNTI and radio resources for the RRC connection.
When the RRC connection is set-up over RACH/FACH, the next step is step 6.
When a DCH is to be set-up, NBAP message Radio Link Setup Request is sent to Node
B for establishing the necessary resources for a new Node B Communication Context.
Parameters: CRNC Communication Context ID, UL and DL DPCH Information (TFCS,
UL Scrambling Code, etc.), DCH Information (general: Payload CRC Presence Indicator,
UL FP Mode, ToAWS, ToAWE; specific: DCH ID, DL/UL Transport Format Set, Frame
Handling Priority and QE-Selector), DSCH Information (DSCH ID, Transport Format
Set, Frame Handling Priority, ToAWS and ToAWE), RL Information (RL ID, C-ID, First
RLS Indicator, Frame Offset, Chip Offset, DL Code Information, etc.), and optional
Transmission Gap Pattern Sequence Information and Active Pattern Sequence Information
IEs. [see REF 25.433 for more details].
Note: UTRAN does not know what type of service is going to be required, so it uses default
parameters at this point. That is why the DCH is likely to be reconfigured later at RAB
assignment.
Approved
28
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
3. (DCH case only): Node B allocates resources, starts PHY reception, and responses with
NBAP message Radio Link Setup Response. After this message, a communication context is
established between Node B and CRNC.
Parameters: CRNC Communication Context ID, Node B Communication Context ID,
Communication Control Port ID, RL Information Response IEs (RL ID, RL Set ID, UL
Interference Level, DCH/DSCH IDs, Transport layer addressing information -AAL2 address,
AAL2 Binding Identity for the Iub Data Transport Bearer, etc.), and optional Criticality
Diagnostics. [see REF 25.433 for more details].
4. (DCH case only): SRNC initiates set-up of Iub Data Transport bearer using ALCAP protocol.
This request contains the AAL2 Binding Identity to bind the Iub Data Transport Bearer to the
DCH. The request for set-up of Iub Data Transport bearer is acknowledged by Node B.
5. (DCH case only): Node B and SRNC establish synchronism for the Iub Data Transport
Bearer. Then Node B starts DL transmission. (FDD only).
6. Message RRC Connection Setup is sent on CCCH (mapped on FACH) from SRNC to UE,
which stops timer T300.
Parameters: Initial UE Identity, Activation Time (by default now), New U-RNTI and
optional New C-RNTI, UTRAN DRX cycle length coefficient, Capability Update
Requirement, RB IEs for each signalling radio bearers to setup, TrCH IEs for TrCHs to add or
reconfigure, and PhyCH IEs. See TS. 25.331 for more details.
7. UE sends back a RRC Connection Setup Complete message on DCCH to the SRNC. This
message is mapped either on RACH or on DCH depending on the decision made at step 2.
Parameters: For each concerned CN domain, the CN domain Identity and the Hyper frame
number to start in this CN domain. The message shall also include UE IEs (UE radio access
capability and UE inter-system capability if requested in the RRC Connection Setup
message).
At this point, RRC signalling connection is set up between UE and UTRAN and a UE context is
built up in the SRNC. UE is in RRC-CONNECTED mode (either Cell_DCH or Cell_FACH state).
UTRAN/UE may initiate from now on any RRC procedure according to UE state. Step 8 is an
example procedure UTRAN may want to initiate at this point, i.e., this is a good moment to do it. Step
8 does not affect section 2.1.2 and vice versa, i.e., these procedures can be done at the same time.
8. SRNC sends RRC Measurement Control message in order to modify or to release
measurement requests already configured by the System Information message, and in order
to setup measurement request not configured by the System Information message.
Parameters: Measurement Identity Number, Measurement Command, Measurement Reporting
Mode (optional), Additional Measurements Lists (optional) and CHOICE Measurement Type
(depending on the command).
Approved
29
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
RRC
Serving
RNC
CN
RANAP
Approved
30
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
UE
Node B
Serving RNS
Serving
RNC
RRC
RRC
CN
B. Direct Transfer
RANAP
RANAP
C. Direct Transfer
RANAP
RRC
RANAP
RRC
Approved
31
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Parameters: NAS-PDU and, if message is sent to PS domain, S-RNC shall also add
RAC+LAI.
C. CN sends RANAP Direct Transfer message to SRNC.
Parameters: NAS PDU and SAPI (to enable UTRAN to provide specific service for the
transport of the message).
D. SRNC sends RRC Downlink Direct Transfer to UE without interpretation of NAS message.
Parameters: NAS message and CN domain Identity (to indicate UE which CN domain NAS
message is originated from).
After describing these procedures and in order to avoid excessive number of messages in
following procedures, all UE-CN signalling messages will be presented from now on as singular UECN messages through UTRAN. The use of Direct Transfer procedures will be indicated before the
message name as shown in Figure 8.
Note: When not stated otherwise elsewhere, Direct Transfer procedures may be initiated also
when another RRC procedure is ongoing, and in that case the latter procedure shall not be affected.
Serving
RNC
CN
11. Common ID
RANAP
RANAP
11. After having established an Iu signalling connection, and if the Permanent NAS UE identity
(i.e. IMSI) is available, the CN shall send a RANAP Common ID message.
Parameters: Permanent NAS UE Identity IE (IMSI).
Note: If IMSI is not available at the CN element, Identity Check Procedure is likely to take place
and the Common ID procedure should be performed after that. This statement makes sense, however it
has not been found yet within 3GPP specifications. On the other hand, in case of an emergency call,
Approved
32
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
UE
Serving
RNC
EIR
CN
12. CN element (MSC/SGSN) sends NAS Identity Request message and starts timer (T3270 for
CS domain; 3370 for PS domain).
Parameters: IE Identity Type 1 (CS domain) or IE Identity Type 2 (PS domain), which
specifies requested identification parameter.
13. UE responds with NAS Identity Response message. Upon reception, CN stops timer T3270
or 3370.
Parameters: IE Mobile Identity as requested. UE may choose to send its IMSI encrypted,
though this is FFS.
UMTS Call Flows
November 4, 2000
Approved
33
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
Approved
34
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
Serving
RNC
HLR/Auc
CN
16. If CN element does not have previously stored UMTS Authentication Vector (quintuplets) for
UE, a Send Authentication Info message is sent to HLR/AuC. Each quintuplet contains
RAND, XRES, AUTN, CK and IK. Originally, all quintuplets are provided by HLR/AuC.
Parameter: IMSI.
17. HLR/AuC responds with a send Authentication Info Ack message including an ordered array
of quintuplets.
18. (PS domain) SGSN selects the next in-order quintuplet and sends Authentication and
Ciphering Request message to UE. SGSN starts timer T3360.
Parameters: Ciphering Algorithm, A&C reference number and, if authentication is to be
performed, RAND, AUTN, CKSN. It may also request IMEISV.
(CS domain) MSC sends Authentication Request message and starts timer T3260.
Parameters: CKSN, RAND and AUTN.
19. (PS domain) If UE is capable of UMTS only, it shall ignore the Ciphering Algorithm IE in step
17, otherwise it shall store it in order to be used at an inter system change from UMTS to
GSM. If UMTS Authentication parameters (RAND, AUTN, CKSN) are included in step 17,
USIM in UE verifies AUTN and, if accepted, USIM processes the challenge information and
sends Authentication and Ciphering Response message. USIM computes information
according to [Ref 33.102] and it results in USIM passing a GPRS UMTS ciphering key, a
GPRS UMTS integrity key and a GPRS GSM ciphering key to the ME, which shall overwrite
previous keys.
Parameters: A&C reference number (the same received in step 17), Authentication Response
parameter and, if requested, IMEISV.
(CS domain) USIM in UE verifies AUTN and, if accepted, USIM processes the challenge
information and sends Authentication Response message. USIM computes information
according to [Ref 33.102] and it results in USIM passing a UMTS ciphering key, a UMTS
integrity key and a GSM ciphering key to the ME, which shall overwrite previous keys.
Parameters: Authentication Response parameter.
Upon reception of the Authentication (and Ciphering) Response, network stops timer T3260 or
T3360 and checks the validity of the response. In case authentication is not accepted by the network, it
sends Authentication (and Ciphering) Reject and call establishment cannot proceed.
Approved
35
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
CN
Serving
RNC
RANAP
RANAP
RRC
RRC
25. Verify received message start Ciphering
26. Security Mode Complete
RANAP
RANAP
20. CN node determines which UIAs and UEAs are allowed to be used. Then, CN initiates
integrity (and possible also ciphering) by sending RANAP Security Mode Command
message.
Parameters: Integrity Protection Information (key(s) and permitted algorithms), Key status
(new or already used keys) and optionally Encryption Information (key(s) and permitted
algorithms).
Note: The set of permitted algorithms specified in the Security Mode Command message shall
remain applicable for subsequent RAB Assignments and Intra-UTRAN Relocations.
21. SRNC decides which algorithms to use by selecting the first UEA and the first UIA
UE/UTRAN capabilities support from the received list. SRNC generates a random value
FRESH and initiates downlink integrity protection. If SRNC does not support any UIA in the
list, it shall send back a Security Mode Reject message.
UMTS Call Flows
November 4, 2000
Approved
36
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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:
Approved
37
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
UE
Serving
RNC
CN
27. CN may send a CM Service Accept message (CS domain) or Service Accept (PS domain)
message to UE in response to a Service Request message in order to inform UE of the acceptance
of the request.
Timers started in section 2.1.2 shall be stopped now (T3230 for CS domain and T3317 for PS
domain), and UE enters MM-CONNECTED mode, i.e., the MM connection is considered to be active.
UE can now proceed with its pending UE-CN signalling procedure.
As described in section 2.1.3, UE-CN signalling procedures are carried on Direct Transfer
Messages transparently through UTRAN and they do not affect any other RRC procedure, unless
otherwise stated elsewhere.
In this example, the pending UE-CN signalling procedure is that in charge of originating a call,
which is a different procedure for either PS or CS domain.
For any PS or CS domain examples, it will be necessary to assign a RAB service. However, it is
not defined exactly when this assignment should be initiated. So, RAB Establishment procedure is
UMTS Call Flows
November 4, 2000
Approved
38
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
Approved
39
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
starts timer TRABAssgt. 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
UMTS Call Flows
November 4, 2000
Approved
40
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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
Drift RNS
Node B
Serving RNS
Drift
RNC
Serving
RNC
RANAP
CN
RANAP
[Establishment]
Select L1, L2 and Iu Data
Transport Bearer paramet ers
RNSAP
NBAP
[DCH Addition]
[DCH Addition]
NBAP
[ D C H A d d ition]
NBAP
NBAP
NBAP
NBAP
D C H -FP
D C H -FP
41. Radio Link Reconfigurati o n
Commit
RNSAP
RNSAP
NBAP
NBAP
RRC
45. Apply new transport format set
46. DCCH : R a d i o B e a r e r S e t u p C o m p lete
RRC
RRC
RANAP
RANAP
Figure 12: Radio Access Bearer Establishment - DCH - DCH Establishment - Synchronized
Approved
41
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
34. After DRNC receives message in step 33, if the modifications requested in step 30 are allowed
by the DRNS, and the DRNS has successfully reserved the required resources for the new
configuration of the Radio Link(s), DRNC notifies SRNC that the preparation is ready by
sending a RNSAP Radio Link Reconfiguration Ready message.
Parameters: RL Information Response (ID and optional UL Maximum and Minimum SIR,
which are decided by DRNC), DL Code Information (DL Scrambling Code, FDD DL
Channelisation Code Number and optional Transmission Gap Pattern Sequence Information
Response), Secondary CCPCH Information (TFCS, TFCI, etc.), DCH Information Response
(DCH ID, Binding ID, Transport Layer Address ), DSCH to be Added and/or Modified Information (DSCH ID, Binding ID, Transport Layer Address, etc.), and optionally IE
Criticality Diagnostics.
35. Node B controlled by SRNC shall reserve necessary resources for the new configuration of
the Radio Link(s) according to the parameters given in step 32. If this is possible, Node B
notifies CRNC that the preparation is ready by sending a NBAP Radio Link Reconfiguration
Ready message.
Parameters: CRNC Communication Context ID, RL Information Response (RL ID and DCH
Information Response IEs for DCHs to be Added and any other modified channel - DCH ID,
Binding ID, Transport Layer Address -), and optionally IE Criticality diagnostics.
Note: Of course, steps 30 through 35 do not have to be performed in a strict sequential manner,
but in the logical order. However, it is more time-efficient to perform step 30 before step 32. In
addition, there is no reason to wait for step 29.
36. Non-applicable in this procedure. This step is only applicable for DCH establishment on a
RACH/FACH RRC connection (section 2.1.7.2).
37. Non-applicable in this procedure. This step is only applicable for DCH establishment on a
RACH/FACH RRC connection (section 2.1.7.2).
38. As soon as SRNC receives Ready message in step 34, it can initiate setup of Iur/Iub Data
Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to
bind the Iur/Iub Data Transport Bearer to DCH.
39. As soon as SRNC receives Ready message in step 35, it can initiate setup of Iub Data
Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to
bind the Iub Data Transport Bearer to DCH.
40. (FDD only) All involved Nodes B and SRNC establish synchronism for the Iub and Iur Data
Transport Bearers.
Note: Iur and Iub Data Transport Bearer are not related and may be setup/release independently.
41. SRNC sends a RNSAP Radio Link Reconfiguration Commit message to DRNC. DRNC
shall switch to the new configuration previously prepared at the CFN requested.
Parameters: CFN and optional Active Pattern Sequence Information.
42. DRNC sends a NBAP Radio Link Reconfiguration Commit message to its Node B. This
message is really sent by CRNC to order the Node B to switch to the new configuration,
which has just been prepared for the Radio Link(s) within the Node B, at the CFN requested.
Parameters: Node B Communication Context ID, CFN and optional Active Pattern Sequence
Information.
43. SRNC (really CRNC) sends a NBAP Radio Link Reconfiguration Commit message to its
Node B. This message is really sent by CRNC to order the Node B to switch to the new
Approved
42
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
configuration, which has just been prepared for the Radio Link(s) within the Node B at the
CFN requested.
Parameters: Node B Communication Context ID, CFN and optional Active Pattern Sequence
Information.
44. SRNC sends an RRC Radio Bearer Setup message back to UE with all necessary parameters
for UE to configure itself. IE Activation Time is included to indicate when UE shall switch to
the new configuration.
Parameters: UE Information Elements (Integrity Check Info, optional Integrity Protection
Mode Info, optional Ciphering Mode Info, Activation Time, DRX indicator, UTRAN DRX
Cycle Length Coefficient, optional New U-RNTI and optional New C-RNTI), optional CN
Information Info, RB Information Elements (optional Signalling RB Information to Setup
List, Signalling RB Information to Setup, RAB Information to Setup List, RAB Information
for Setup, optional RB Information to be Affected List and RB Information to be Affected),
TrCh Information Elements for both UL and DL TrChs, PhyCh Information Elements for both
UL and DL Radio Resources. (For more detailed parameters information see [Ref 25.331]).
Note: Again, steps 41 through 43 shall be performed in a logical order. Step 44 does need to wait
for steps 41 through 43. In fact, [ref. 25.331] specifies UTRAN shall configure new radio links in
any new physical channel configuration and start transmission and reception on the new radio
links in order to initiate the RRC Radio Bearer Establishment procedure in step 44.
45. At this point, UE shall act upon all received IE as specified in section 8.5.7 of [Ref 25.331].
UE should turn off the transmitter during the reconfiguration. UE may first release the current
physical channel configuration and shall then establish a new physical channel configuration
according to the information received in step 44.
46. If reconfiguration succeeds, UE sends RRC Radio Bearer Setup Complete message to
SRNC.
Parameters: UE Information Elements (Integrity Check Info, optional Uplink Integrity
Protection Activation Info and Hyper frame number) and optional RB IE Radio Bearer Uplink
Ciphering Activation Time Info.
47. SRNC can now send back to CN a RANAP RAB Assignment Response message. UTRAN
may delete any old configuration.
Parameters: RABs setup IE as RAB ID, Transport Layer Address (PS domain only) and Iu
Transport Association (PS domain only); Data Volume IEs if requested in step 28 by CN
(Unsuccessfully Transmitted DL Data Volume and optional Data Volume Reference); RABs
queued RAB ID and RABs failed to setup, modify or release RAB ID and appropriate Cause
IE. In case RABs to be released, the message shall also contain the Data Volume IEs and if PS
domain and the procedure was initiated by UTRAN, the DL/UL GTP-PDU Sequence
Numbers. These two parameters will allow SGSN to restore proper values in case the PDP
Context is maintained and the RAB is re-established at a later stage. Finally, the message may
also contain optional Criticality Diagnostics IE.
Upon reception of the RAB Assignment Response message, CN shall stop timer TRABAssgt only if
none of the RABs have been queued by UTRAN. This is the case for this example, and then the RAB
Establishment procedure terminates at this point. (For further details on queuing, see [Ref 25.413]).
UE is now connected to UTRAN through at least two DCHs, one for the RRC signalling
connection and one for the transfer of user data.
Approved
43
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Approved
44
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
required resources, Node B responses to the CRNC with the NBAP Radio Link Setup
Response message. After this message, a communication context between Node B and CRNC
is established for concerned UE.
Parameters: CRNC Communication Context ID, Node B Communication Context ID,
Communication Control Port ID, RL Information Response IEs (RL ID, RL Set ID, UL
Interference Level, DCH/DSCH IDs, Transport layer addressing information -AAL2 address,
AAL2 Binding Identity for the Iub Data Transport Bearer, etc.), and optional Criticality
Diagnostics. [see REF 25.433 for more details].
UE
Node B
Drift RNS
Node B
Serving RNS
Drift
RNC
Serving
RNC
RANAP
CN
RANAP
[Establishment]
NBAP
NBAP
NBAP
NBAP
RRC
RRC
RANAP
RANAP
39. As soon as SRNC receives Response message in step 37, it can initiate setup of Iub Data
Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to
bind the Iub Data Transport Bearer to DCH.
44. SRNC sends an RRC Radio Bearer Setup message back to UE with all necessary parameters
for UE to configure itself as the new Transport Format Set. IE Activation Time is included to
indicate when UE shall switch to the new configuration.
Parameters: UE Information Elements (Integrity Check Info, optional Integrity Protection
Mode Info, optional Ciphering Mode Info, Activation Time which is just now for
unsynchronised procedure-, DRX indicator, UTRAN DRX Cycle Length Coefficient, optional
New U-RNTI and optional New C-RNTI), optional CN Information Info, RB Information
Elements (optional Signalling RB Information to Setup List, Signalling RB Information to
Setup, RAB Information to Setup List, RAB Information for Setup, optional RB Information
to be Affected List and RB Information to be Affected), TrCh Information Elements for both
UL and DL TrChs, PhyCh Information Elements for both UL and DL Radio Resources. (For
more detailed parameters information see [Ref 25.331]).
UMTS Call Flows
November 4, 2000
Approved
45
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
46. If configuration succeeds, UE sends RRC Radio Bearer Setup Complete message to SRNC.
Parameters: UE Information Elements (Integrity Check Info, optional Uplink Integrity
Protection Activation Info and Hyper frame number) and optional RB IE Radio Bearer Uplink
Ciphering Activation Time Info.
47. SRNC can now send back to CN a RANAP RAB Assignment Response message. UTRAN
may delete any old configuration.
Parameters: RABs setup IEs as RAB ID, Transport Layer Address (PS domain only) and Iu
Transport Association (PS domain only); Data Volume IEs if requested in step 28 by CN
(Unsuccessfully Transmitted DL Data Volume and optional Data Volume Reference); RABs
queued RAB ID and RABs failed to setup, modify or release RAB ID and appropriate Cause
IE. In case RABs to be released, the message shall also contain the Data Volume IEs and if PS
domain and the procedure was initiated by UTRAN, the DL/UL GTP-PDU Sequence
Numbers. These two parameters will allow SGSN to restore proper values in case the PDP
Context is maintained and the RAB is re-established at a later stage. Finally, the message may
also contain optional Criticality Diagnostics IE.
Upon reception of the RAB Assignment Response message, CN shall stop timer TRABAssgt only if
none of the RABs have been queued by UTRAN. This is the case for this example, and then the RAB
Establishment procedure terminates at this point. (For further details on queuing, see [Ref 25.413]).
UE is now connected to UTRAN through at least one DCH for the transfer of user data, and for
the RRC signalling connection it still uses the common transport channels (RACH/FACH).
Approved
46
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Note: UTRAN shall execute the requested RAB configuration. Resources shall be established
according to the values of IEs sent within this message and the resource situation, including UE
capabilities.
UE
Node B
Drift RNS
Node B
Serving RNS
Drift
RNC
Serving
RNC
RANAP
CN
RANAP
[Establishment]
RRC
RANAP
RANAP
29. (CS domain only) SRNC selects L1, L2 and Iu Data Transport Bearer parameters and initiates
Setup of Iu Data Transport Bearer using ALCAP protocol. This request contains the AAL2
Binding Identity to bind the Iu Data Transport Bearer to the RAB.
44. SRNC sends an RRC Radio Bearer Setup message back to UE with all necessary parameters
for UE to configure itself as the new Transport Format Set. IE Activation Time is included to
indicate when UE shall switch to the new configuration.
Parameters: UE Information Elements (Integrity Check Info, optional Integrity Protection
Mode Info, optional Ciphering Mode Info, Activation Time which is just now for
unsynchronised procedure-, DRX indicator, UTRAN DRX Cycle Length Coefficient, optional
New U-RNTI and optional New C-RNTI), optional CN Information Info, RB Information
Elements (optional Signalling RB Information to Setup List, Signalling RB Information to
Setup, RAB Information to Setup List, RAB Information for Setup, optional RB Information
to be Affected List and RB Information to be Affected), TrCh Information Elements for both
UL and DL TrChs, PhyCh Information Elements for both UL and DL Radio Resources. (For
more detailed parameters information see [Ref 25.331]).
46. If configuration succeeds, UE sends RRC Radio Bearer Setup Complete message to SRNC.
Parameters: UE Information Elements (Integrity Check Info, optional Uplink Integrity
Protection Activation Info and Hyper frame number) and optional RB IE Radio Bearer Uplink
Ciphering Activation Time Info.
47. SRNC can now send back to CN a RANAP RAB Assignment Response message. UTRAN
may delete any old configuration.
Parameters: RABs setup IE as RAB ID, Transport Layer Address (PS domain only) and Iu
Transport Association (PS domain only); Data Volume IEs if requested in step 28 by CN
(Unsuccessfully Transmitted DL Data Volume and optional Data Volume Reference); RABs
queued RAB ID and RABs failed to setup, modify or release RAB ID and appropriate Cause
IE. In case RABs to be released, the message shall also contain the Data Volume IEs and if PS
domain and the procedure was initiated by UTRAN, the DL/UL GTP-PDU Sequence
Numbers. These two parameters will allow SGSN to restore proper values in case the PDP
UMTS Call Flows
November 4, 2000
Approved
47
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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 TRABAssgt only if
none of the RABs have been queued by UTRAN. This is the case for this example, and then the RAB
Establishment procedure terminates at this point. (For further details on queuing, see [Ref 25.413]).
UE is still connected to UTRAN exclusively through common transport channels (RACH/FACH)
for both the transfer of user data and the RRC signalling connection.
Approved
48
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
The signalling procedure to be performed in this example is the PDP Context Activation
procedure, which will establish a PDP context between UE and core network for a specific QoS on a
specific NSAPI. This procedure is used to activate the first PDP context for a given PDP address and
APN, whereas all additional contexts associated to the same PDP address and APN are activated with
the Secondary PDP Context Activation procedure [Ref 23.060].
48. (PS domain only) UE sends a NAS Activate PDP Context Request message to SGSN and starts
timer T3380.
Parameters: Requested NSAPI, Requested LLC SAPI, Requested QoS, Requested PDP address
(static or dynamic and PDP Type), and optionally APN (for a certain external network and/or to
select a service) and/or Protocol Configuration Options (which will be sent transparently through
the SGSN).
28. RAB setup is done by any of the RAB Assignment Procedures described in section 2.1.7. It is
clear this procedure has to be performed after step 48, for CN needs the requested QoS. However
it seems following steps (50 and 51) to activate a PDP context in the GGSN do not clash with the
RAB establishment procedure, i.e., both procedures may be done in parallel. It is FFS within the
UMTS team how a changed of QoS by GGSN affects RAB.
49. (PS domain only) If BSS trace is activated, then SGSN shall send an Invoke Trace message to
SRNC.
Parameters: Trace Reference, Trace Type, Trigger ID, OMC Identity.
UE
3G-SGSN
SRNC
HLR
3G-GGSN
C1
28-47. Radio Access Bearer Setup
49. Invoke Trace
50. Create PDP Context Request
51. Create PDP Context Response
C2
52. Direct Transfer: Activate PDP Context Accept
Uplink PDU
Figure 15: Service Request and PDP context Activation Initiated by UE Procedures
(PS domain only)
Approved
49
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
UMTS Call Flows
November 4, 2000
Approved
50
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
Approved
51
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
Calling
MSC/VLR
SRNC
HLR
Called
MSC/VLR
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
UMTS Call Flows
November 4, 2000
Approved
52
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
the Mobile Originating Call Proceeding state (i.e., MSC has already received QoS in Bearer
Capabilities IE). However, it is a network dependent decision when to initiate the assignment of
an appropriate traffic channel (RAB Setup) during the mobile originating call establishment phase.
Initiation of a suitable RR procedure to assign an appropriate traffic channel does neither change
the state of a Call Control entity nor affect any call control timer.
Note: So, NAS signalling can be done at the same time than the RAB assignment procedure.
However, during certain phases of such an RR procedure, transmission of CC and MM messages
may be suspended (see GSM 4.18, section 3 and GSM 8.08 for more details).
If UE supporting multicall includes the SI IE in the Setup message in step 53, MSC shall
include the received SI into the RAB ID and send it back to the UE. The purpose of the SI IE is to
associate a particular call with a RAB and to identify whether a new traffic channel shall be
assigned, which is the case if UE generates a new SI value at the initiation of an originating call. If
UE does not send SI IE, MSC shall set the SI value to 1.
55. (CS domain only) Calling MSC sends ISUP Initial Address Message (IAM) to called MSC.
56. (CS domain only) Called MSC responses with ISUP Address Complete Message (ACM) after
receiving Alerting message from called user (this will be further described in Mobile Terminated
Call Establishment section).
57. (CS domain only) Upon step 56, MSC sends an Alerting message to UE and enters Call
Delivered state. UE shall then stop timers T303 and T310 (if running) and shall also enter the
Call Delivered state. In this state, for speech calls an alerting indication should be given to the
user. If the RAB assignment is completed and UE has activated the codec or interworking
function, MSC is responsible for the alerting indication otherwise UE should generate it.
Parameters: (All IEs are optional) Facility, Progress Indicator and User-User (if called remote user
included User-User IE in its alerting message). For more details see [Ref 24.008].
58. (CS domain only) Called MSC sends ISUP Answer Message (ANM) upon receiving an
indication that the call has been accepted.
59. (CS domain only) MSC shall connect the traffic channel if not connected already (including the
connection of an interworking function, if required) and then send a Connect message to UE.
Network starts timer T313 and enters Connection Indication state.
Parameters: (All are optional) Facility, Progress Indicator, Connected Number, Connected
Subaddress, User-User. For more details see [Ref 24.008]
60. (CS domain only) UE shall activate the codec or interworking function to the traffic channel if not
done yet, stop timers T303 and T310 (if running), return a Connect Acknowledge message to the
network and enter the Active state.
Upon reception of Connect Acknowledge, MSC shall stop timer T313 and enter Active state.
The CS domain call is now established.
Approved
53
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Approved
54
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
UTRAN
SGSN
HLR
GGSN
1. PDP PDU
C1
13. Radio Access Bearer Setup
49. Invoke Trace
50. Create PDP Context Request
51. Create PDP Context Response
C2
52. Direct Transfer: Activate PDP Context Accept
Downlink PDU
4. If SGSN Address is present and either MNRR is not present or MNRR indicates No paging
Response, the GGSN shall send a PDU Notification Request message to the SGSN
indicated by the HLR.
Parameters: IMSI, TEID (only if there is not yet a GTP tunnel between SGSN and GGSN),
End User Address (i.e., PDP Type and PDP Address), APN that wishes to connect to the UE
and optional Private Extension for vendor/operator specifics.
5. At this point, SGSN is responsible for requesting the UE to activate the indicated PDP
Context. SGSN sends back a PDU Notification Response message to GGSN to indicate that
Approved
55
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
Approved
56
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
Approved
57
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Parameters: There are many optional parameters such as Bearer Capability, Progress indicator,
Alert, User-User info, priority, etc. For further details see [ref 24.008].
UE
UTRAN
Called
MSC/VLR
HLR
Calling
MSC/VLR
1. ISUP IAM
2. Paging Request
3: RRC Connection Request
3: RRC Connection Setup
4. Initial Direct Transfer: Paging Response
5. Common ID
6: Security Functions
7. Direct Transfer: Setup
8. Direct Transfer: Call Confirmed
8. UE shall perform compatibility checking as described in [ref 24.008]. If the result of the
compatibility checking was compatibility, the Call Control entity of the UE shall enter the
Call Present state. If the call is allowed to continue UE shall acknowledge the Setup
message by sending a Call Confirmed message. UE enters then in Mobile Terminated Call
Confirmed state.
Parameters: UE may include one or two Bearer Capabilities to define the radio channel
requirements and other optional parameters such as Stream Identifier (SI). The purpose of the
SI IE is to associate a particular call with a RAB and to identify whether a new traffic channel
shall be assigned or not. For this example (first call) and whenever UE generates a new SI
value at the initiation of a call, a new traffic channel shall be assigned. If UE does not send SI
IE in the Call Confirmed message, MSC shall set the SI value to 1. Another possible case is
that a UE supporting multicall might not need a new traffic channel for the new call. If so, UE
UMTS Call Flows
November 4, 2000
Approved
58
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
Approved
59
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
UMTS Call Flows
November 4, 2000
Approved
60
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
UE
RNC
RNC
CN
NODE B
A) UE is in IDLE mode
RANAP
1. Paging
RANAP
RRC
RANAP
1. Paging
RANAP
2. Paging Request
RNSAP
RNSAP
RRC
3. PCCH: Paging Type I
RRC
RRC
RANAP
1. Paging
RANAP
RRC
Case B
2. An RRC connection exists and it has been identified thanks to the Permanent NAS UE
Identity. UE is in URA_PCH or Cell_PCH RRC state. An URA might be controlled by
different RNCs and UE might be camping in a cell controlled by other RNC, so RNC might
send a RNSAP Paging Request message to concerned RNCs.
Parameters: CHOICE paging area between URA and Cell (message will contain URA-Id or
C-Id), SRNC-Id, S-RNTI, IMSI, DRX Cycle Length Coefficient.
3. Corresponding CRNCs broadcast an RRC Paging Type I message as in case A but only in
those cells belonging to the URA if UE is in URA_PCH state or only in the known cell if UE
is in Cell_PCH state. UE will receive one paging request from each RNC and DRNC will
route all paging responses to the SRNC, who will forward them to the CN. It is then up to the
CN to filter the paging responses [ref UTRAN SFRAS section 2.7].
Parameters: Paging record list (from 1 to number of UEs paged in this message), Paging
Record (CHOICE Originator: if CN Originator record contains: Paging Cause, CN domain
Approved
61
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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 Update1 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.
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.
Approved
62
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
UE
UTRAN
3G-SGSN
3G-GGSN
C1
2. Delete PDP Context Request
3. Delete PDP Context Response
4. Direct Transfer: Deactivate PDP Context Accept
Approved
63
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
It will be assumed UE was an active user and all resources (Iu signalling, RAB, RRC connection)
were allocated. So, procedures to release all resources will be described.
In any case, the Delete PDP Context Request takes precedence over any other ongoing Tunnel
Management message. So, Delete PDP Context will always be performed regardless PDP state.
1. UE sends a Deactivate PDP Context Request message to the SGSN by means of the Direct
Transfer described in section 2.1.3. UE starts timer T3390.
Parameters: Session Management Cause (Regular Deactivation in this example, see [ref.
24.008] for more causes) and optional Tear Down Indicator IE, which may be included to
indicate whether only the PDP context associated with this specific Transaction Identifier
(TI2) or all active PDP context sharing the same PDP address as the PDP context associated
with this specific TI shall be deactivated. If it is not included, only this PDP context will be
deactivated. In this example, tear down will be considered to be requested.
2. SGSN sends a Delete PDP Context Request message to the GGSN. If Tear Down Indicator
was included, SGSN will request to deactivate all associated PDP context by including the
Tear Down Indicator in this message, too.
Parameters: NSAPI, optional Tear Down Indicator and optional Private Extension for
vendor/operator specifics.
3. GGSN shall be prepared to receive previous message at any time and shall always reply
regardless if the PDP context exists or not by sending a Delete PDP Context Response back
to SGSN. In this example, PDP context exists and GGSN removes it.
Parameters: Cause (set to Request Accepted in this example) and Private Extension for
vendor/operator specifics.
4. If the previous message contains a Cause IE other than Request Accepted, the PDP context
shall be kept active. This is not the case in this example, then SGSN replies to UE with a
Deactivate PDP Context Accept message. Upon reception of this message, UE shall stop
timer T3390.
Parameters: none specific IE.
At this point, SGSN shall initiate the release of UTRAN resources associated with this PDP
context as described in section 3.1.3.
For an UE with GPRS-CSI defined, CAMEL interaction may be performed, see referenced
procedures in 3G TS 23.078:
C1) CAMEL-GPRS-Deactivate-PDP-Context.
Every Layer 3 message consists of the following parts: protocol discriminator, transaction identifier, message
type and other IEs, if required. Most of parameters listed through this document are message specific IEs.
However, this procedure makes use of the TI to identify PDP Contexts associated to a PDP address, for each
PDP Context sharing a PDP address and APN shall be identified by an unique TI and an unique NSAPI. The
transaction identifier and its use are defined in TS 24.007.
Approved
64
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
UTRAN
Calling MSC
Called MSC
4. Upon reception of Release message, UE shall stop timer T305, send a Release Complete
message to the network, release MM connection and return Null state.
Parameters: only optional Facility and SS Version may apply to this example.
Upon reception of Release Complete message, MSC shall stop timer T308, release MM
connection and return to Null state. At this point, MSC shall initiate the release of UTRAN
resources associated with this call as described in section 3.1.3.
Approved
65
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
The release of the MM connection is done locally in the MM sublayer for both UE and MSC, i.e.
no MM message is sent over the radio interface for this purpose. If all MM connections are released
by its CM entities, UE starts timer T3240 and enters Wait for Network Command, expecting
UTRAN Resources Release. However, network may decide to maintain UTRAN resources in order to
establish another MM connection. In case none MM connection is established and UTRAN resources
are not released within time controlled by T3240 (i.e. timer expires), UE shall abort the radio
connection.
Approved
66
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
RNC
CN
Iu Release Request
RANAP
RANAP
5. Iu Release Command
RANAP
RANAP
RANAP
8. ALCAP Iu Data Transport
Bearer Release
Not required towards PS
domain
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.
Approved
67
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
This example assumes RRC connection is released because of Call Release. Nevertheless, RRC
connection could also be released for preservation of radio resources in case inactive UE, for example.
As described in section 2.1.1 RRC Connection Establishment procedures, an RRC connection may
be established on either dedicated channel (DCH) or common channels (RACH/FACH). The former
requires more signalling for DCH must be also released. On the other hand, it allowed UTRAN to set
UE in soft handover state immediately after RRC connection was established.
So, it will be assumed UE is in soft handover for the DCH RRC Release, while this statement does
not apply for the RACH/FACH RRC Release. First five steps for both cases are common as depicted
in Figure 23 and Figure 24.
Steps 5, 7 and 8 have just been described in the Iu Signalling Connection Release procedure. Step
6 is shown after step 8 in order to show the independency of these messages.
UE
Node B
Drift RNS
Node B
Serving
RNS
Drift
RNC
Serving
RNC
CN
5. Iu Release Co m m a n d
RANAP
RANAP
RANAP
7. Iu Release Complete
RANAP
RRC
RRC
RRC
6. Upon indication from the CN by the Iu Release Command message, SRNC can send RRC
Connection Release message to UE in order to initiate the release of the existing RRC
connection including the signalling link and all RABs between UE and UTRAN, if they exist.
SRNC may transmit several messages to increase the probability of proper reception by the
UE (the number and the interval for repetition are network options).
Parameters: Integrity Check Info, Release Cause (normal event in this example) and
Number of RRC Message Transmissions in case UE is in Cell_DCH state. If the CCCH
logical channel is used, the message shall also include the U-RNTI.
9. The reception of this message can interrupt any ongoing RRC procedure with the UE in
Cell_DCH and Cell_FACH state. Depending on its state, UE shall act in different way.
a. When in Cell_FACH state, UE shall send an RRC Connection Release Complete
message using acknowledged mode to the UTRAN. Regardless success at
transmission of this message, UE shall release all its radio resources, enter IDLE
mode and the procedure ends on the UE side.
Parameters: Integrity Check Info. If the CCCH logical channel is used, the message
shall also include the U-RNTI.
b. When in Cell_DCH state, UE shall send an RRC Connection Release Complete
message using unacknowledged mode to the UTRAN and shall initiate counter V308
and timer T308. V308 indicates number of repetitions for the message every time
T308 expires. V308 is decreased by one every repetition of RRC Connection Release
Approved
68
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Complete message. When V308 reaches the zero value, the UE shall release all its
radio resources, enter IDLE mode and the procedure ends on the UE side.
Parameters: Integrity Check Info. If the CCCH logical channel is used, the message
shall also include the U-RNTI.
Note: There must be a good reason for these timer and counter that I do not understand. Their
values are set by the operator.
Regardless reception of RRC Connection Release Complete message, UTRAN shall release all
UE dedicated resources. The procedure ends at this point in case RRC connection was established on
RACH/FACH. In case it was established on DCH, following steps are performed as depicted in Figure
24:
10. SRNC (really CRNC) requests its Node B to delete all existing Radio Link(s) for given UE by
sending the NBAP Radio Link Deletion Request message.
Parameters: Node B Communication Context ID and Radio Link ID for each RL to be
released.
UE
Node B
Drift RNS
Node B
Serving RNS
Drift
RNC
Serving
RNC
CN
5. Iu Release Command
RANAP
RANAP
7. Iu Release Complete
RANAP
RANAP
8. A L C A P I u B e a r e r R e l e a s e
6. (on DCCH or CCCH) RRC Connection Release
RRC
RRC
9. (on DCCH or CCCH) RRC Connection Release Complete
RRC
RRC
N BAP
11. Radio Link Deletion
RNSAP
RN S A P
NBAP
13. Radio Link Deletion Response
NBAP
NBAP
14. Radi o L i n k D e l e t i o n R e s p o n s e
N BAP
NBAP
15. Radio Link Deletion Response
RNSAP
RN S A P
11. SRNC requests DRNC to release all radio links it may have towards UE with the RNSAP
Radio Link Deletion Request message.
Parameters: Radio Link ID for each RL to be released.
Approved
69
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
12. Upon reception of this message, DRNC shall initiate deletion of all radio links identified in
the message for given UE by sending the NBAP Radio Link Deletion Request message to its
Node B.
Parameters: Node B Communication Context ID and Radio Link ID for each RL to be
released.
13. Upon reception of Radio Link Deletion Request message, the Node B controlled by SRNC
shall delete the Radio Link(s) identified in the message and release all associated resources
and respond to the CRNC with the NBAP Radio Link Deletion Response message.
Parameters: CRNC Communication Context ID and optionally Criticality Diagnostics.
14. Upon reception of Radio Link Deletion Request message, the Node B controlled by DRNC
shall delete the Radio Link(s) identified in the message and release all associated resources
and respond to the CRNC with the NBAP Radio Link Deletion Response message.
Parameters: CRNC Communication Context ID and optionally Criticality Diagnostics.
15. Upon reception of Radio Link Deletion Response message from its Node B, DRNC shall
respond to the SRNC with the RNSAP Radio Link Deletion Response message. Since all
radio links for the UE are deleted, DRNC shall also release the UE context, unless the UE is
using common resources in the DRNS.
Parameters: only optionally Criticality Diagnostics IE.
16. SRNC initiates release of not used resources Iub Data Transport Bearer using ALCAP
protocol.
17. DRNC initiates release of not used resources Iur and Iub Data 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.
Approved
70
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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 TRABAssgt. CN may request to establish, release or
modify one or several (3GPP allows up to 256) RABs at the same time, but only release will
be considered here. Then, the message shall contain only following parameters.
Parameters: a list of RABs to be released containing RAB ID and Cause for each one. The
Cause will be Normal Release for this example.
UE
RNC
RANAP
CN
RAB Release Request
RANAP
RANAP
RANAP
6. (bis) RNC shall be prepared to receive previous message containing RABs to be released at
any time and shall always reply to it. RNC shall initiate release of requested RABs through
different procedures depending on the connection established. Appropriate RAB release
procedures corresponding to those described in section 2.1.7 for RAB establishment are
described in following subsections.
7. (bis) RNC shall report to CN with a RAB Assignment Response message the result of all
requested RABs: list of RABs released and list of RABs failed to release. This message is sent
back to CN as soon as the UE responses to the RNC about the RABs it has been commanded
to release.
Parameters for released RABs: RAB ID for each RAB and, and if it is required by PS domain,
RABs Data Volume Report per RAB (Unsuccessfully Transmitted DL Data Volume and
optional Data Volume Reference), and if PS domain and the procedure was initiated by
UTRAN, the DL/UL GTP-PDU Sequence Numbers. These two parameters will allow SGSN
to restore proper values in case the PDP Context is maintained and the RAB is re-established
at a later stage.
Parameters for RABs failed to release: RAB ID and Cause IE.
This message can optionally send Criticality Diagnostics IE.
Approved
71
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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 TRABAssgt only if none of the RABs have been queued by UTRAN, which is the case for this
example (RABs to be released are not queued, in fact, if any of these RABs were in a queue, they shall
be taken out of the queue and released).
Next subsections describe appropriate RAB release procedures corresponding to those described
in section 2.1.7 for RAB establishment. As described in section 2.1.7 DCH-DCH RAB Release
procedure can be done either in a synchronised or unsynchronised manner. It was discussed for Call
Establishment Synchronised procedure was necessary; however, for this section any one could be
applied. So, both procedures will be described.
Due to the complexity of following procedures, numbering will start from 1 for each one,
otherwise it would become too ambiguous.
3.1.3.3.1 DCH-DCH RAB Release Synchronised procedure
This procedure is used to prepare a synchronised new configuration of all Radio Links related to
one UE-UTRAN connection. In this case, it is triggered in order to release the RAB associated to the
Call that has just been released.
This procedure will release a RAB on DCH when the RRC connection still uses a DCH after the
release and when synchronisation is needed according to section 2.1.7. It is assumed UE is in soft
handover and communicates via two Nodes B. One Node B is controlled by SRNC and the other one
is controlled by DRNC as depicted in Figure 26.
This procedure is quite similar to the DCH DCH RAB Establishment procedure described in
section 2.1.7.1. Then, only relevant difference is that DCH ID for RAB to be deleted is sent now
instead of all DCH to add information detailed there. Nevertheless, as it was already pointed out in
section 2.1.7.1, this procedure can add, modify and/or release DCHs at the same time for a given UEUTRAN connection.
Note: In fact, if synchronised procedure is needed, it is because TFCIs of remaining DCHs will
change. This imply then those DCHs shall be reconfigured in this procedure.
Messages 1, 16 and 17 for this procedure are already described above in section 3.1.3.3, steps 5B,
7B and 8B.
2. SRNC requests DRNC to prepare release of DCH carrying the RAB by sending RNSAP
Radio Link Reconfiguration Prepare message.
Parameters: Allowed Queuing Time (optional), UL and DL DPCH Information (optional),
DCH to delete Information (mandatory: DCH ID) and RL Information. Within this message
SRNC may also reconfigure (add, modify or delete) any other DCH or DSCH it has with
DRNC [see REF 25.423 for more details].
3. DRNC requests its Node B to prepare release of DCH carrying the RAB by sending NBAP
Radio Link Reconfiguration Prepare message (it is really sent by CRNC).
Parameters: Node B Communication Context ID, UL and DL DPCH Information (optional),
DCH to delete Information (mandatory: DCH ID), RL Information and optional DL Code
UMTS Call Flows
November 4, 2000
Approved
72
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Node B
Drift RNS
Node B
Serving RNS
Drift
RNC
Serving
RNC
RANAP
CN
1. RAB Assign m e n t
Request
RANAP
[Release]
RNSAP
NBAP
[DCH Deletion]
NBAP
NBAP
[DCH Deletion]
5. Radio Link Reconfiguration Ready
NBAP
NBAP
NBAP
NBAP
8. Radio Link Reconfiguration
Commit
RNSAP
RNSAP
NBAP
NBAP
NBAP
RRC
RRC
12. Apply new transport format set
13. DCCH : R a d i o B e a r e r R e l e a s e C o m p l e t e
RRC
RRC
RANAP
RANAP
1 7 . A L C A P I u D a ta Transport
Bearer Release
not required towards PS
domain
Figure 26: Radio Access Bearer Release - DCH - DCH Release - Synchronised
5. Node B controlled by DRNC shall reserve necessary resources for the new configuration of
the Radio Link(s) according to the parameters given in step 3. If this is possible, Node B
notifies CRNC that the preparation is ready by sending a NBAP Radio Link Reconfiguration
Ready message.
UMTS Call Flows
November 4, 2000
Approved
73
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Approved
74
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
If only DCH is to be deleted, but there are still any more channels on concerned Radio Link, a Radio Link
Reconfiguration procedure as described here is performed. In case UTRAN decided to release complete Radio
Link towards the UE, the Radio Link Deletion procedure would take place. An example for the latter case will
be described in next section.
Approved
75
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Release Synchronised procedure described above. The only different is that they are performed now
before Radio Link(s) reconfiguration takes place, for synchronization is not needed.
Then, UTRAN initiates Radio Link(s) reconfiguration for given UE-UTRAN connection as
following:
6. SRNC requests DRNC to release DCH carrying the RAB by sending RNSAP Radio Link
Reconfiguration Request message.
Parameters: optional Allowed Queuing Time, optional UL and DL DPCH Information, DCH
to delete Information (mandatory: DCH ID), and optional Transmission Gap Pattern Sequence
Number. Within this message SRNC may also reconfigure any other DCH it has with DRNC
for related UE [see REF 25.423 for more details].
UE
Node B
Drift RNS
Node B
Serving RNS
Drift
RNC
Serving
RNC
RANAP
CN
1. RAB Assignment
Request
[Release]
RANAP
RRC
RRC
3. DCCH Radio Bearer Release Complete
RRC
RRC
RANAP
4. RAB Assignment
Response
RANAP
5. ALCAP Iu Data
Transport Bearer Release
not required towards PS domain
6. RL Reconfiguration
Request
RNSAP
RNSAP
[DCH Deletion]
7. RL Reconfiguration Request
NBAP
NBAP
[DCH Deletion]
8. RL Reconfiguration Request
NBAP
NBAP
[DCH Deletion]
NBAP
RNSAP
10. RL Reconfiguration
Response
RNSAP
NBAP
NBAP
Figure 27: Radio Access Bearer Release - DCH - DCH Release - Unsynchronised
7. DRNC requests its Node B to release DCH carrying the RAB by sending RBAP Radio Link
Reconfiguration Request message (it is really sent by CRNC).
Parameters: Node B Communication Context ID, UL and DL DPCH Information (optional),
DCH to delete Information (mandatory: DCH ID), RL Information and optional DL Code
Information as IE FDD DL Channelisation Code Number or the DL Scrambling Code. Within
this message DRNC may also reconfigure any other DCH it has with concerned Node B [see
REF 25.433 for more details].
Approved
76
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
8. SRNC requests its Node B to prepare release of DCH carrying the RAB by sending RBAP
Radio Link Reconfiguration Request message (it is really sent by CRNC).
Parameters: Node B Communication Context ID, UL and DL DPCH Information (optional),
DCH to delete Information (mandatory: DCH ID), RL Information and optional DL Code
Information as IE FDD DL Channelisation Code Number or the DL Scrambling Code. Within
this message DRNC may also reconfigure any other DCH it has with concerned Node B [see
REF 25.433 for more details].
9. Node B controlled by DRNC shall reserve necessary resources for the new configuration of
the Radio Link(s) according to the parameters given in step 7. If this is possible, Node B
notifies CRNC that the preparation is ready by sending a NBAP Radio Link Reconfiguration
Response message.
Parameters: CRNC Communication Context ID, RL Information Response, and optionally IE
Criticality diagnostics. If DRNC is reconfiguring any other channel, it should send
corresponding Binding Information (DCH ID, Binding ID, Transport Layer Address);
however, no additional information is necessary for DCHs to be deleted.
10. After DRNC receives message in step 9, if the modifications requested in step 4 are allowed
by the DRNS, and the DRNS has successfully reserved the required resources for the new
configuration of the Radio Link(s), DRNC notifies SRNC that the preparation is ready by
sending a RNSAP Radio Link Reconfiguration Response message.
Parameters: RL Information Response (ID and optional UL Maximum and Minimum SIR,
which are decided by DRNC), Secondary CCPCH Information (DL Scrambling Code, FDD
DL Channelisation Code Number, TFCS, etc.), DL Code Information (DL Scrambling Code,
FDD DL Channelisation Code Number and optional Transmission Gap Pattern Sequence
Number) and optionally IE Criticality diagnostics. If SRNC is reconfiguring any other
channel, it should send corresponding Response Information (DCH ID, Binding ID, Transport
Layer Address); however, no additional information is necessary for DCHs to be deleted.
11. Node B controlled by SRNC shall reserve necessary resources for the new configuration of
the Radio Link(s) according to the parameters given in step 8. If this is possible, Node B
notifies CRNC that the preparation is ready by sending a NBAP Radio Link Reconfiguration
Response message.
Parameters: CRNC Communication Context ID, RL Information Response, and optionally IE
Criticality diagnostics. If SRNC is reconfiguring any other channel, it should send
corresponding Binding Information (DCH ID, Binding ID, Transport Layer Address);
however, no additional information is necessary for DCHs to be deleted.
Note: Of course, steps 6 through 11 do not have to be performed in a strict sequential manner, but
in the logical order. However, it is more time-efficient to perform step 6 before step 8.
12. DRNC initiates release of not used resources Iur and Iub Data Transport Bearer using ALCAP
protocol.
13. SRNC initiates release of not used resources Iub Data Transport Bearer using ALCAP
protocol.
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.3 RACH/FACH DCH RAB Release procedure
Approved
77
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
Node B
Drift RNS
Node B
Serving RNS
Drift
RNC
Serving
RNC
RANAP
CN
1. RAB Assignment
Request
RANAP
[Release]
RRC
RRC
RANAP
4. RAB Assignment
Response
RANAP
5. ALCAP Iu Data
Transport Bearer Release
not required towards PS domain
NBAP
NBAP
NBAP
Figure 28: Radio Access Bearer Release RACH/FACH - DCH Release - Unsynchronised
Messages 1 through 5 are exactly the same than in previous case, section 3.1.3.3.2 DCH-DCH
RAB Release Unsynchronised procedure.
Then, UTRAN initiates Radio Link Deletion for given UE-UTRAN connection with following
messages:
6. SRNC (really CRNC) requests its Node B to delete given Radio Link by sending the NBAP
Radio Link Deletion Request message.
Parameters: Node B Communication Context ID and Radio Link ID for each RL to be
released.
7. Upon reception of this message, the Node B shall delete the Radio Link(s) identified in the
message and release all associated resources and respond to the CRNC with the NBAP Radio
Link Deletion Response message.
Parameters: CRNC Communication Context ID and optionally Criticality Diagnostics.
UMTS Call Flows
November 4, 2000
Approved
78
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
8. SRNC initiates release of not used resources Iub Data Transport Bearer using ALCAP
protocol.
At this point, RAB associated to Call that has just been released is also completely released. UE
maintains both RRC and Iu connections in order to support any other ongoing PDP Context/Call.
UE
Node B
Drift RNS
Node B
Serving RNS
Drift
RNC
Serving
RNC
RANAP
CN
1. RAB Assignment
Request
RANAP
[Release]
2. DCCH Radio Bearer Release
RRC
RRC
3. DCCH Radio Bearer Release Complete
RRC
RRC
RANAP
4. RAB Assignment
Response
RANAP
5. ALCAP Iu Data
Transport Bearer Release
not required towards PS domain
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.
Approved
79
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
UTRAN
3G-SGSN
3G-GGSN
C1
1. Delete PDP Context Request
2. Delete PDP Context Response
3. Direct Transfer: Deactivate PDP Context Request
4. Direct Transfer: Deactivate PDP Context Accept
When procedure is initiated by SGSN as depicted in Figure 30, the following steps take place:
1. SGSN sends a Delete PDP Context Request message to the GGSN.
Parameters: NSAPI, optional Tear Down Indicator IE, which may be included to indicate that
all active PDP context sharing the same PDP address as the PDP context associated with this
specific NSAPI shall be deactivated. If it is not included, only this PDP context will be
deactivated. In this example, tear down indicator will be considered to be requested. Finally,
this message may also include optional Private Extension IE for vendor/operator specifics.
2. GGSN shall be prepared to receive previous message at any time and shall always reply
regardless if the PDP context exists or not by sending a Delete PDP Context Response back
to SGSN. In this example, PDP context exists and GGSN removes it.
Parameters: Cause (set to Request Accepted in this example) and Private Extension for
vendor/operator specifics.
3. SGSN does not have to wait for the Delete PDP Context Response message from GGSN
before sending a Deactivate PDP Context Request message to the UE. This message is sent
by means of the Direct Transfer described in section 2.1.3. SGSN starts timer T3395.
Approved
80
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
UTRAN
3G-SGSN
3G-GGSN
C1
2. Direct Transfer: Deactivate PDP Context Request
3. Direct Transfer: Deactivate PDP Context Accept
4. Delete PDP Context Response
When procedure is initiated by GGSN as depicted in Figure 31, the following steps take place:
1. GGSN sends a Delete PDP Context Request message to the SGSN.
Parameters: NSAPI, optional Tear Down Indicator IE, which may be included to indicate that
all active PDP context sharing the same PDP address as the PDP context associated with this
specific NSAPI shall be deactivated. If it is not included, only this PDP context will be
deactivated. In this example, tear down indicator will be considered to be requested. Finally,
this message may also include optional Private Extension IE for vendor/operator specifics.
2. SGSN sends a Deactivate PDP Context Request message to the UE. This message is sent by
means of the Direct Transfer described in section 2.1.3. SGSN starts timer T3395.
Parameters: Session Management Cause (Regular Deactivation, network failure or
reactivation requested) and optional Tear Down Indicator.
3. UE removes PDP context(s) and replies to SGSN with a Deactivate PDP Context Accept
message. Upon reception of this message, SGSN shall stop timer T3395.
Parameters: none specific IE.
4. SGSN does not have to wait for the Deactivate PDP Context Accept message from UE before
sending the Delete PDP Context Response message back to GGSN.
Parameters: Cause (set to Request Accepted in this example) and Private Extension for
vendor/operator specifics.
At this point for both cases, SGSN shall initiate the release of UTRAN resources associated with
this PDP context as described in section 3.1.3. It is assumed UE was an active user and all resources
(Iu signalling, RAB, RRC connection) were allocated. So, procedures to release all resources will
apply as for the Mobile Originated Call Release process.
Approved
81
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
For an UE with GPRS-CSI defined, CAMEL interaction may be performed, see referenced
procedures in 3G TS 23.078:
C1) CAMEL-GPRS-Deactivate-PDP-Context.
UE
UTRAN
Called MSC
Calling MSC
1. ISUP REL
2. Direct Transfer: Release
3. Direct Transfer: Release Complete
Figure 32: Call Clearing Initiated by MSC with Release message procedure
Approved
82
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
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.
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.
UMTS Call Flows
November 4, 2000
Approved
83
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
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.
UE
UTRAN
Called MSC
Calling MSC
1. ISUP REL
2. Direct Transfer: Disconnect
3. Direct Transfer: Release
4. Direct Transfer: Release Complete
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 process4. 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
Approved
84
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Allowed Actions IE is optional and, if sent, it shall be set to CCBS activation is not
possible. In the former case, MSC shall start timer T338, which shall not be greater than
T306 in case in-band tones/announcements are provided.
3. UE shall act as in case B regarding progress indicator #8 in any case. In addition, if Allowed
Actions IE is not included in previous message and/or CCBS is not possible, UE also acts
exactly in the same way than in case B. However, if Allowed Actions IE indicates Activation
of CCBS is possible, UE shall pass this indication to the upper layer, enter the Disconnect
Indication state, stop all running control timers and await a response from the upper layer.
This response may be any of the following two:
a. If upper layers request the clearing of the call, UE shall stop all running call control
timers, send Release message, start timer T308, and enter the Release Request state.
b. If upper layers request that the CCBS activation is to be attempted, UE shall send
Release message containing a Facility IE including an Invoke=CCBSRequest to the
network. UE shall also stop all running call control timers, start timer T308 and enter
the Release Request state.
Parameters (all optional IEs): Cause, Second Cause, Facility, User-User and SS version.
4. The Call Control entity of the network in any state except the Null state and the Release
Request state, shall, upon reception of Release message, act exactly as in case B if it does not
support CCBS activation or if CCBS has not been requested. In case CCBS is requested and
network supports it, Call Control entity of the network shall stop all running call control
timers (including T305, T306 or T338), then attempt to activate the Recall; then send a
Release Complete message, release the MM connection and return to the Null state.
Parameters(all optional IEs): Cause, Facility and User-User.
Note: In case T305, T306 or T338 expires, MSC shall send Release message and proceed as in
Case A. If it was T305 that expired, Release message shall contain Second Cause IE set to
Recovery on timer expiry.
The Call Control entity of the UE in any state, shall, upon reception of Release Complete
message, stop all running call control timers (including T308), release the MM connection and return
to the Null state. At this point, MSC shall initiate the release of UTRAN resources associated with
this call as described in section 3.1.3.
The release of the MM connection is done locally in the MM sublayer for both UE and MSC, i.e.
no MM message is sent over the radio interface for this purpose. If all MM connections are released
by its CM entities, UE starts timer T3240 and enters Wait for Network Command, expecting
UTRAN Resources Release. However, network may decide to maintain UTRAN resources in order to
establish another MM connection. In case none MM connection is established and UTRAN resources
are not released within time controlled by T3240 (i.e. timer expires), UE shall abort the radio
connection.
Approved
85
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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 reports5 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 userplane 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.
Measurement report is an RRC function between UE and UTRAN that is out of the scope of this section.
Approved
86
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Approved
87
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
Node B
Drift RNS
Drift
RNC
Serving
RNC
Decision to setup
new RL
RNSAP
NBAP
1 . R a d i o L i n k Setup
Request
RNSAP
NBAP
Start RX
3. Radio Link Setup
Response
NBAP
NBAP
RNSAP
RNSAP
6. Downlink Synchronisation
D C H -FP
D C H -FP
D C H - FP
6. Uplink Synchronisation
D C H -FP
Start TX
7. D C C H : Active Set Update
RRC
RRC
[Radio Link Addition]
8. D C C H : A c t i v e S e t U p d a t e C o m p l e t e
RRC
RRC
4. Upon reception of previous message, DRNC sends back a RNSAP Radio Link Setup
Response message to SRNC.
Parameters: RL Information Response (as RL ID, RL Set ID, SAI, UL Interference Level,
Secondary CCPCH Info, DL Code Information, DCH and DSCH Information Response and
Neighbouring Cell Information) and optional UL and DL SIR Target and Critically
Diagnostics. If there was not previous UE Context for this UE in the DRNC, DRNC shall also
include in the message the new D-RNTI and CN PS/CS Domain Identifiers to indicate CN
Domain nodes Target RNC is connected to (using LAC and RAC of the current cell).
5. As soon as SRNC receives previous message, it can initiate setup of Iur/Iub Data Transport
Bearer using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the
Iur/Iub Data Transport Bearer to DCH. This step may be repeated for each Iur/Iub Data
Transport Bearer to be setup.
Approved
88
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
Approved
89
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
corresponding radio link(s) towards UE with the RNSAP Radio Link Deletion Request
message.
Parameters: Radio Link ID for each RL to be released.
UE
Node B
Drift RNS
Drift
RNC
Serving
RNC
Decision to delete
old RL
RRC
[Radio Link Deletion]
2. D C C H : Active Set Update Complete
RRC
RRC
RNSAP
NBAP
NBAP
NBAP
NBAP
Stop R X a n d T X
RNSAP
4. Upon reception of this message, DRNC shall initiate deletion of all radio links identified in
the message for given UE by sending the NBAP Radio Link Deletion Request message to its
Node B.
Parameters: Node B Communication Context ID and Radio Link ID for each RL to be
released.
5. Upon reception of Radio Link Deletion Request message, the Node B controlled by DRNC
shall delete the Radio Link(s) identified in the message and release all associated resources
and respond to the CRNC with the NBAP Radio Link Deletion Response message. At this
point, resources are deallocated and both physical transmission and reception are stopped for
related radio link(s), though UE should not be using it from step 2.
Parameters: CRNC Communication Context ID and optionally Criticality Diagnostics.
6. Upon reception of Radio Link Deletion Response message from its Node B, DRNC shall
respond to the SRNC with the RNSAP Radio Link Deletion Response message. In case all
radio links for the UE were deleted, DRNC should also release the UE context, unless the UE
were using common resources in the DRNS.
Parameters: only optionally Criticality Diagnostics IE.
7. DRNC initiates release of not used resources Iur and Iub Data Transport Bearer using ALCAP
protocol.
UMTS Call Flows
November 4, 2000
Approved
90
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
At this point, all UTRAN resources associated to Radio Link that has just been released are also
completely released. The procedure is ended.
Approved
91
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Interference Level, DCH/DSCH IDs, Transport layer addressing information -AAL2 address,
AAL2 Binding Identity for the Iub Data Transport Bearer, etc.), and optional Criticality
Diagnostics. [See REF 25.433 for more details].
UE
Node B
Drift RNS
Node B
Serving RNS
Drift
RNC
Serving
RNC
Decision to setup
new RL and
release old RL
RNSAP
NBA P
NBAP
NBAP
NBAP
Start RX
description
RNSAP
D C H -FP
6. Downlink Synchronisation
6. Uplink Synchronisation
D C H -FP
D C H -FP
D C H -FP
Start TX
description
7. D C C H : A c t i v e S e t U p d a t e
RRC
RRC
[Radio Link Addition & Deletion]
RRC
8. D C C H : A c t i v e S e t U p d a t e C o m p l e t e
NBAP
NBAP
RRC
NBAP
NBAP
Stop RX and TX
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
Response message to SRNC.
Approved
92
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Parameters: RL Information Response (as RL ID, RL Set ID, SAI, UL Interference Level,
Secondary CCPCH Info, DL Code Information, DCH Information Response and
Neighbouring Cell Information, etc.) and optional Critically Diagnostics. [See REF 25.423 for
more details].
5. As soon as DRNC receives Radio Link Setup Response message, it can initiate setup of
Iub/Iur Data Transport Bearer using ALCAP protocol. This request contains the AAL2
Binding Identity to bind the Iub/Iur Data Transport Bearer to DCH. This step may be repeated
for each Iur/Iub Data Transport Bearer to be setup.
6. (FDD only) Node B and SRNC establish synchronism for the Iub and Iur Data Transport
Bearers, relative to already existing radio link(s). This is done by means of the appropriate
DCH Frame Protocol (DCH FP) Downlink Synchronisation and Uplink Synchronisation
frames. Then, Node B is ready to start DL physical transmission.
7. At this moment, new resources are ready. Then SRNC sends RRC Active Set Update (Radio
Link Addition & Deletion) message to UE on DCCH in order to update the active set of the
connections between the UE and UTRAN. The UE should keep on using the old Radio
Link(s) and transmitting while allocating the new Radio Link(s). In case all radio links were
replaced simultaneously, the UTRAN should include the IE U-RNTI, and the IEs CN
domain identity and NAS system information within the CN Information Info IE.
Parameters: UE IEs (Integrity Check Info, Activation Time and optional Integrity Protection
Mode Info, Ciphering Mode Info and New U-RNTI), optional CN Information Info IE (as
CN domain identity and NAS system information), RB IEs (PDCP information for each
RAB) and DL/UL Physical Channels IEs (as Radio Link Addition & Removal Information,
where Radio Link(s) to be added/removed are identified).
8. Upon reception of previous message, UE shall add indicated Radio Link(s). If the UE active
set is full or becomes full because of received message, UE shall first remove radio link(s),
which is/are indicated to remove, and then add radio link(s), which is/are indicated to add. UE
shall update its configuration (U-RNTI identity, Transport Format Set, etc.), if necessary.
Then, UE acknowledges new Radio Link configuration with RRC Active Set Update
Complete message.
Parameters: UE IEs (Integrity Check Info, and optional UL Integrity Protection Activation
Info) and RB IEs (PDCP information for each RAB and optional RB UL Ciphering Activation
Time Info).
9. Upon reception of this message, SRNC shall initiate deletion of all radio links for given UE,
as were indicated in step 1, by sending the NBAP Radio Link Deletion Request message to
its Node B.
Parameters: Node B Communication Context ID and Radio Link ID for each RL to be
released.
10. Upon reception of Radio Link Deletion Request message, the Node B controlled by SRNC
shall delete the Radio Link(s) identified in the message and release all associated resources
and respond to the CRNC with the NBAP Radio Link Deletion Response message. At this
point, resources are deallocated and both physical transmission and reception are stopped for
related radio link(s), though UE should not be using it from step 2.
Parameters: CRNC Communication Context ID and optionally Criticality Diagnostics.
11. SRNC initiates release of not used resources Iub Data Transport Bearer using ALCAP
protocol.
At this point, the new Active Set of connections between UE and UTRAN is being used on both
sides and all not used UTRAN resources are completely released. The procedure is ended.
Approved
93
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
5 Hard Handover
A Hard Handover imply all Radio Links established for a given UE need to be released and new
Radio Links need to be established. Network shall always take into account UE capabilities at
establishing new Radio Links. This document will describe following types of hard handovers:
UTRAN-to-UTRAN Hard Handovers
Inter-frequency FDD to FDD, i.e., with related cells on different frequencies
Intersystem Hard Handovers6
UMTS to GSM
GSM to UMTS
UMTS to GPRS
GPRS to UMTS
All these Hard Handovers procedures may or may not imply a switch in the CN connections. Both
cases will be described for all procedures. UTRAN SFRAS indicates UMTS-GPRS Hard Handovers
will be supported in R1.
On the other hand, [Ref. 25.401] specifies the possibility of both UE/Network initiated handovers.
Therefore, the handover function may be either controlled by the network, or independently by UE.
However, R0 and R1 will only implement network-initiated handovers, and it is believed within UE
Initiated handover will not exist in UMTS. Therefore, it will be assumed only SRNC takes the
decision to perform a Handover. This decision may be triggered by the following three main causes:
Strength Level Cause, which is measured through measurement reports from UE. This cause
is valid for all types of Handovers.
Cell Topology Cause, based on the current cells serving the UE and the knowledge the system
has of the surrounding cell topology. This cause is valid for FDD to FDD and UMTS to GSM
Hard Handovers.
Overload Cause, based on input to the Handover Control from the Overload Detection
Function. This cause is valid for FDD to FDD and UMTS to GSM Hard Handovers.
Intersystem Hard Handovers will be developed in a second phase of this document, according to Annex A.
Approved
94
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
37. UTRAN will first establish new RRC connection and new Radio Links, then UE will be
reconfigured, and finally old Radio Links will be deleted.
Based on IS-95 experience, it is known UE is likely to be in Soft Handover (more than 60% of
active UEs will be). Thus, UE is also likely to be linked to UTRAN through different RNCs. Then, old
Radio Links may be deleted for any old RNC (DRNC or SRNC) and new Radio Links may be
established for any new RNC (DRNC or SRNC). Figure 37 shows different boxes for Source RNC,
Target RNC and current SRNC in order to include all possibilities for this procedure. So, some
messages have been annotated to indicate when related message applies (Notes are explained at the
end of the procedure description).
1. The Handover Control function in the SRNC takes the decision of performing an Interfrequency FDD to FDD Hard Handover procedure. Then, SRNC sends RNSAP Radio Link
Setup Request message to Target RNC for new Radio Link(s) to be established. This
message will be sent to all new RNCs that are going to serve the UE after the Handover. If
there is not Iur signalling connection between SRNC and corresponding DRNC, a new Iur
signalling connection will be established now and it will be used for all RNSAP signalling
related to this UE.
Parameters: S-RNTI, D-RNTI (if UE Context already exists in Target RNC), optional
Allowed Queuing Time, UL and DL DPCH Information (TFCS, UL Scrambling Code, etc.),
DCH Information (general: Payload CRC Presence Indicator, UL FP Mode, ToAWS,
ToAWE; specific: DCH ID, TrCh Source Statistics Descriptor, DL/UL Transport Format Set,
DL/UL BLER, Allocation/Retention Priority, Frame Handling Priority, QE-Selector and
DRAC Control), DSCH Information (DSCH ID, TrCh Source Statistics Descriptor, Transport
Format Set, Allocation/Retention Priority, Scheduling Priority Indicator, BLER, PDSCH RL
ID and TFCS), RL Information (RL ID, C-ID, First RLS Indicator, Frame Offset, Chip Offset,
etc.), and optional Transmission Gap Pattern Sequence Information and Active Pattern
Sequence Information IEs [See REF 25.423 for more details].
(Note 1).
2. If requested resources are available, Target RNC sends NBAP Radio Link Setup Request
message to concerned Node B (this message is really sent by corresponding CRNC). This and
following message will establish a new Communication Context for UE between CRNC and
the Node B. If Target RNC is a DRNC, it may allocate a new D-RNTI that will be sent back
to SRNC in step 5. If Target RNC is the SRNC, it may also allocate a new RNTI and
resources for the RRC connection.
Parameters: CRNC Communication Context ID, UL and DL DPCH Information (TFCS, UL
Scrambling Code, etc.), DCH Information (general: Payload CRC Presence Indicator, UL FP
Mode, ToAWS, ToAWE; specific: DCH ID, DL/UL Transport Format Set, Frame Handling
Priority and QE-Selector), DSCH Information (DSCH ID, Transport Format Set, Frame
Handling Priority, ToAWS and ToAWE), RL Information (RL ID, C-ID, First RLS Indicator,
Frame Offset, Chip Offset, DL Code Information, Power control information etc.), and
optional Transmission Gap Pattern Sequence Information and Active Pattern Sequence
Information IEs. [See REF 25.433 for more details].
3. Node B shall establish new Radio Link(s) according to received parameters. If configuration
succeeds, Node B responses to CRNC with NBAP Radio Link Setup Response message.
Node B is now able to start UL physical reception on the new radio link (though UE will not
transmit anything yet).
Parameters: CRNC Communication Context ID, Node B Communication Context ID,
Communication Control Port ID, RL Information Response IEs (RL ID, RL Set ID, UL
Interference Level, DCH/DSCH IDs, Transport layer addressing information -AAL2 address,
Approved
95
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
AAL2 Binding Identity for the Iub Data Transport Bearer, etc.), and optional Criticality
Diagnostics. [See REF 25.433 for more details].
UE
Node B
Source
Node B
Target
RNC
Source
RNC
target
SRNC
RNSAP
2. Radio Link Setup Request
NBAP
1. Radio Link
Setup Request
Note 1
RNSAP
5. RL Setup
Response
Note 1
RNSAP
NBAP
Start RX
3. Radio Link Setup Response
NBAP
NBAP
RNSAP
DCH-FP
7. Uplink Synchronisation
DCH-FP
DCH-FP
DCH-FP
Start TX
8. DCCH : Physical Channel Reconfiguration
Note 3
RRC
NBAP
RRC
NBAP
RNSAP
RRC
RRC
RNSAP
NBAP
NBAP
RNSAP
RNSAP
NBAP
NBAP
Stop RX &TX
RNSAP
RNSAP
Figure 37: Inter-frequency FDD to FDD Hard Handover via Iur (UE in DCH state)
Approved
96
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
4. As soon as RNC receives previous message, it can initiate setup of Iub Data Transport Bearer
using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iub Data
Transport Bearer to DCH. This step may be repeated for each Iub Data Transport Bearer to be
setup.
5. Upon reception of previous message, Target RNC sends back a RNSAP Radio Link Setup
Response message to SRNC.
Parameters: RL Information Response (as RL ID, RL Set ID, SAI, UL Interference Level,
Secondary CCPCH Info, DL Code Information, DCH and DSCH Information Response and
Neighbouring Cell Information) and optional UL and DL SIR Target and Critically
Diagnostics. If there was not previous UE Context for this UE in the Target RNC, Target
RNC shall also include in the message the new D-RNTI and CN PS/CS Domain Identifiers to
indicate CN Domain nodes Target RNC is connected to (using LAC and RAC of the current
cell).
(Note 1).
6. As soon as SRNC receives previous message, it can initiate setup of Iur Data Transport Bearer
using ALCAP protocol. This request contains the AAL2 Binding Identity to bind the Iur Data
Transport Bearer to DCH. This step may be repeated for each Iur Data Transport Bearer to be
setup.
(Note 1).
7. (FDD only) Node B and SRNC establish synchronism for the Iub and Iur Data Transport
Bearers, relative to already existing radio link(s). This is done by means of the appropriate
DCH Frame Protocol (DCH FP) Downlink Synchronisation and Uplink Synchronisation
frames. Then, Node B is ready to start DL physical transmission.
8. When new radio resources are ready, SRNC sends RRC message to UE in order to trigger the
Handover (Note 3). Normally, the RRC Physical Channel Reconfiguration message is sent
on the DL DCCH. This message is used to establish, reconfigure and release physical
channels.
Parameters: UE Information Elements (Integrity Check Info, optional Integrity Protection
Mode Info, optional Ciphering Mode Info, Activation Time, DRX indicator, UTRAN DRX
Cycle Length Coefficient, optional New U-RNTI and optional New C-RNTI), optional CN
Information Info, RB Information Elements (RB with PDCP information for each RB with
PDCP), and PhyCh Information Elements for both UL and DL Radio Resources. (For more
detailed parameters information see [Ref 25.331]).
9. When UE stops transmitter because of reception of previous message, Source Node B detects
a failure on its Radio Link(s) and sends a NBAP Radio Link Failure Indication message to
its CRNC.
Parameters: CRNC Communication Context ID and Individual Radio Link(s) affected IDs or
Radio Links Set(s) affected IDs with the most appropriate Cause IE.
10. Upon reception of previous message, Source RNC sends a RNSAP Radio Link Failure
Indication message to SRNC.
Parameters: Individual Radio Link(s) affected IDs or Radio Links Set(s) affected IDs with the
most appropriate Cause IE.
(Note 2).
Note: Steps 8 and 9 are not directly related with the Handover procedure. However, they are
described to indicate the Radio Link failure shall be detected and reported as a normal failure,
for Source RNC and Source Node B do not know anything about the Hard Handover yet.
Approved
97
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
11. UE shall be able to receive a Physical Channel Reconfiguration message and perform a Hard
Handover at any time, even if no prior UE measurements have been performed on the target
cell and/or frequency. The UE should turn off the transmitter during the reconfiguration. UE
may first release the current physical channel configuration and shall then establish a new
physical channel configuration according to the information received in step 8 and [Ref.
25.331, section 8.5.7]. When the RRC connection is successfully established with the Target
RNC and necessary radio resources have been allocated, UE sends corresponding RRC
response message back to SRNC (Note 3). In this example and in the normal situation, the
RRC Physical Channel Reconfiguration Complete message is sent. When the transmission
of this message is confirmed by RLC, the UE shall resume data transmission on new Radio
Link(s).
Parameters: UE Information Elements (Integrity Check Info and optional Uplink Integrity
Protection Activation Info) and RB IEs (RB with PDCP information for each RB with PDCP
and optional Radio Bearer Uplink Ciphering Activation Time Info).
12. At this point the new configuration is up and working. Therefore, SRNC may indicate Source
RNC to delete old Radio Link(s) towards UE. SRNC sends RNSAP Radio Link Deletion
Request message to all Source RNCs that had old Radio Links towards UE before this
Handover procedure.
Parameters: Radio Link ID for each RL to be released.
(Note 2)
13. Upon reception of this message, Source RNC shall initiate deletion of all radio links identified
in the message for given UE by sending the NBAP Radio Link Deletion Request message to
its Node B.
Parameters: Node B Communication Context ID and Radio Link ID for each RL to be
released.
14. Upon reception of Radio Link Deletion Request message, the Node B controlled by Source
RNC shall delete the Radio Link(s) identified in the message and release all associated
resources and respond to the CRNC with the NBAP Radio Link Deletion Response message.
At this point, resources are deallocated and both physical transmission and reception are
stopped for old radio link(s).
Parameters: CRNC Communication Context ID and optionally Criticality Diagnostics.
15. Upon reception of Radio Link Deletion Response message from its Node B, Source RNC
initiates release of not used resources Iub Data Transport Bearer using ALCAP protocol.
16. Source RNC shall respond to the SRNC with the RNSAP Radio Link Deletion Response
message. Since all radio links for the UE have been deleted, Source RNC shall also release the
UE context, unless the UE is using common resources in the DRNS.
Parameters: only optionally Criticality Diagnostics IE.
(Note 2).
17. Not used resources Iur Data Transport Bearer are released using ALCAP protocol.
(Note 2).
Note 1: This message is not necessary when the Target RNC is the SRNC.
Note 2: This message is not necessary when the Source RNC is the SRNC.
Note 3: The messages used are only one example of the various messages that can be used to
trigger a handover, to confirm it or to indicate the handover failure. The different possibilities are
specified in [Ref. 25.331].
At this point, all UTRAN resources associated to old Radio Link(s) are completely released and
UE is using new Radio Link(s) on a different frequency. The Hard Handover procedure is ended.
Approved
98
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Approved
99
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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 TRELOCalloc. This message shall contain the
information (if any) required by the UTRAN to build the RAB configuration existing for the
UE before relocation.
Parameters: Permanent NAS UE Identity (if available), Cause, CN Domain Indicator, Source
RNC to Target RNC Transparent Container, Integrity Protection Information (if available), Iu
Signalling Connection Identifier, optional Encryption Information and RAB to be setup
Information for each RAB to be setup (RAB ID, RAB parameters, User Plane Information,
Transport Layer Address, Iu Transport Association, etc.).
3. In case any CN node belongs to the CS domain, i.e., it is an MSC. Target SRNC and MSC
shall establish the new Iu Data Transport Bearer for each RAB related to the MSC. This is
done by means of the ALCAP protocol.
At this point, the Target RNC shall initiate allocation of requested resources. The actions to be
taken are the same as specified for the same IEs in the RAB Establishment section. In addition, Target
SRNC shall take into account whether UE is involved in the relocation or not according to received
Relocation Type IE. The main difference is that if UE is involved in the process, it is possible Target
RNC establishes new necessary radio resources using the NBAP Radio Link Setup procedure (if the
first Radio Links and there is not UE Communication Context) or the NBAP Radio Link Addition
procedure (if not the first Radio Links and the UE Communication Context between Node B and
Target RNC already exists). In Figure 38, it is assumed UE is involved in the procedure and there is
not Communication Context established between Target Node B and Target SRNC. Then, Radio
Link(s) must be setup in following step. If Relocation Type IE indicates UE is not involved in the
process, it would not be possible to perform any of these procedures and only existing Radio Link(s)
could be used. For more details on this IE, see [ref. 25.413].
4. Target RNC allocates RNTI and radio resources for RRC and necessary Radio Link(s). Then,
CRNC in Target RNC sends NBAP Radio Link Setup Request message to Target Node B in
order to establish new UE Communication Context and necessary new Radio Link(s).
Parameters: CRNC Communication Context ID, UL and DL DPCH Information (TFCS, UL
Scrambling Code, etc.), DCH Information (general: Payload CRC Presence Indicator, UL FP
Mode, ToAWS, ToAWE; specific: DCH ID, DL/UL Transport Format Set, Frame Handling
Priority and QE-Selector), DSCH Information (DSCH ID, Transport Format Set, Frame
Handling Priority, ToAWS and ToAWE), RL Information (RL ID, C-ID, First RLS Indicator,
Frame Offset, Chip Offset, DL Code Information, Power control information etc.), and
optional Transmission Gap Pattern Sequence Information and Active Pattern Sequence
Information IEs. [See REF 25.433 for more details].
5. Node B shall establish new Radio Link(s) according to received parameters. If configuration
succeeds, Node B responses to CRNC with NBAP Radio Link Setup Response message.
Node B is now able to start UL physical reception on the new radio link (though UE will not
transmit anything yet).
Approved
100
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
Node B
Source
Node B
Target
SRNC
Source
SRNC
Target
1. Relocation Required
RANAP
RANAP
1. Relocation Required
RANAP
SGSN
MSC
RANAP
RANAP
2. Relocation Request
RANAP
2. Relocation Request
RANAP
RANAP
3. ALCAP Iu Data
Transport Bearer Setup
NBAP
NBAP
Start RX
NBAP
NBAP
D C H - FP
D C H -FP
Start TX
8. Relocation Request
Acknowledge
RANAP
RANAP
RANAP
RANAP
C1
9. Relocation Command
RANAP
9. Relocation Command
RANAP
RRC
RANAP
RANAP
RRC
RANAP
RANAP
RANAP
RANAP
RANAP
14. Re location
Detect
RANAP
RRC
RANAP
NBAP
RRC
RANAP
17. Relocation
Complete
RANAP
RANAP
RANAP
RANAP
RANAP
RANAP
RANAP
Figure 38: Intra CN nodes Hard Handover with switching in the CN (UE connected to two CN
nodes, DCH state)
Approved
101
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
6. As soon as Target RNC receives Radio Link Setup Response message, it can initiate setup of
Iub Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding
Identity to bind the Iub Data Transport Bearer to DCH. This step may be repeated for each Iub
Data Transport Bearer to be setup.
7. (FDD only) Node B and Target SRNC establish synchronism for the Iub Data Transport
Bearers, relative to already existing radio link(s). This is done by means of the appropriate
DCH Frame Protocol (DCH FP) Downlink Synchronisation and Uplink Synchronisation
frames. Then, Node B is ready to start DL physical transmission.
8. After all necessary resources for accepted RABs including the Iu user plane, are successfully
allocated, the Target SRNC shall send a RANAP Relocation Request Acknowledge message
to the CN. The transmission of this message terminates the Relocation Resource Allocation
procedure in the Target RNS.
Parameters: RABs setup IEs (RAB ID and if PS domain, Transport Layer Address and Iu
Transport Association), RABs failed to setup IEs (RAB ID and failure Cause), Chosen
Integrity Protection Algorithm (if available) and optional IEs Chosen Encryption Algorithm
and Critically Diagnostics. Finally, this message shall contain the Target RNC to Source RNC
Transparent Container for it has been assumed Relocation Type IE was set to UE involved in
relocation of SRNS. Since two nodes are considered in this example, the Target RNC may
decide to send the container to only one CN, for it will be sent transparently to Source RNC in
next step. This container contains RRC Initialisation Information and optionally D-RNTI if
Target RNC supports triggering of the Relocation Detect procedure via the Iur interface. (See
step 14).
9. The reception of previous message terminates the Relocation Resource Allocation procedure
in the CN nodes. However, CN nodes shall not release resources associated with the RABs
indicated as failed to set up in previous message. This is in order to make a return to the old
configuration possible in case of a failed or cancelled relocation. At this moment, if CN
decides to continue the relocation of SRNS, each CN node shall send RANAP Relocation
Command message to the source RNC and start timer TRELOCcompl.
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 TRELOCalloc, though it is not indicated in
specifications.
10. Upon reception of previous message from the PS domain, Source RNC shall start the timer
TDATAfwd, though Forwarding of Data will not start up to step 13. After receiving previous
message from all CN nodes involved in the process, Source RNC shall stop the timer
TRELOCprep and start the timer TRELOCOverall 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
UMTS Call Flows
November 4, 2000
Approved
102
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
channels. UTRAN should take the UE capabilities into account for setting the new
configuration. In addition, since there is a SRNS relocation in this example, new ciphering
and/or integrity protection information shall be sent if ciphering and/or or integrity protection
information are activated.
Parameters: UE Information Elements (Integrity Check Info, optional Integrity Protection
Mode Info, optional Ciphering Mode Info, Activation Time, DRX indicator, UTRAN DRX
Cycle Length Coefficient, optional New U-RNTI and optional New C-RNTI), optional CN
Information Info (which contains among others Location Area Identification and Routeing
Area Identification), RB Information Elements (RB with PDCP information for each RB with
PDCP), and PhyCh Information Elements for both UL and DL Radio Resources. (For more
detailed parameters information see [Ref 25.331]).
Note: If during the Relocation Preparation procedure the Source RNC receives any Direct
Transfer message (see section 2.1.3) it shall be handled normally. In case of reception of any
other Class 2 message, Source SRNC may execute it or suspend it (if relocation were
suspended, SRNC should resume any suspended procedure). After Relocation Preparation
procedure is terminated successfully (step 10), all RANAP messages received via the same Iu
signalling bearer shall be ignored, but the Iu Release Command that will be received in step
16.
11. (PS domain only) After sending previous message, the Source SRNC continues the execution
of relocation of SRNS by sending RANAP Forward SRNS Context message to the SGSN.
The purpose of this procedure is to transfer SRNS contexts from the Source to the Target
SRNS via the SGSN. SRNS contexts are sent for each concerned RAB and contain the
sequence numbers of the GTP PDUs next to be transmitted in the uplink and downlink
directions and the next PDCP sequence numbers that would have been used to send and
receive data from the UE. For connections using RLC unacknowledged mode, PDCP
sequence numbers are not used.
Parameters: DL GTP-PDU Sequence Number, UL GTP-PDU Sequence Number, DL N-PDU
Sequence Number, UL N-PDU Sequence Number and RAB ID for each corresponding RAB.
12. (PS domain only) SGSN forwards SRNS contexts to Target SRNS by means of RANAP
Forward SRNS Context message. Upon reception of this message, the Target SRNC resets
and restarts the RLC connections taking into account the received parameters. The PDCP
sequence numbers (PDCP-SNU, PDCP-SND) will be exchanged with the UE when
connection is established.
Parameters: DL GTP-PDU Sequence Number, UL GTP-PDU Sequence Number, DL N-PDU
Sequence Number, UL N-PDU Sequence Number and RAB ID for each corresponding RAB.
13. (PS domain only) After having sent the Forward SRNS Context message in step 11, Source
SRNC begins the Forwarding of Data for the RABs towards PS domain subject to data
forwarding. The data forwarding at SRNS relocation shall be carried out through the Iu
interface, meaning that the data exchanged between Source SRNC and Target SRNC are
duplicated in the Source SRNC and routed at IP layer towards the Target SRNC.
14. The detection of the UE will trigger the execution of the Relocation of SRNS at the Target
SRNS, which indicates it to both CN nodes by sending the RANAP Relocation Detect
message. When this message is sent, the Target SRNC shall start the SRNC operation.
Parameters: none specific IE.
Note: Source SRNC can also trigger the execution of the Relocation of the SRNS by sending
RNSAP Relocation Commit message to the Target SRNC (see section 6.1 SRNS Relocation
UMTS Call Flows
November 4, 2000
Approved
103
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Procedure). If UE were not involved in the process, the execution of the Relocation of SRNS
could only be triggered by the Relocation Commit message. In this example, since UE is
involved in the process, both the reception of this message and the UE detection could be
possible and the Relocation of SRNS would begin at Target SRNS as soon as it is triggered by
any means. However, since the handover is performed through the Iu interface, it is not clear
in specs if it is allowed to send an RNSAP message. If Relocation Commit message is
received and it contains the transparent RANAP Relocation Information IE the target RNC
shall use this information when finalising the Relocation, which also includes the information
transmitted in the Forward SRNS Context procedure for PS domain.
15. UE stops UL transmission when it receives Handover message in step 10. Then, Source Node
B will detect a failure in the Radio Link(s) and will send a NBAP Radio Link Failure
Indication message to its CRNC at Source SRNC.
Parameters: CRNC Communication Context ID and Individual Radio Link(s) affected IDs or
Radio Links Set(s) affected IDs with the most appropriate Cause IE.
16. UE shall be able to receive a Physical Channel Reconfiguration message and perform a Hard
Handover at any time, even if no prior UE measurements have been performed on the target
cell and/or frequency. The UE should turn off the transmitter during the reconfiguration. UE
may first release the current physical channel configuration and shall then establish a new
physical channel configuration according to the information received in step 8 and [Ref.
25.331, section 8.5.7]. When the RRC connection is successfully established with the Target
RNC and necessary radio resources have been allocated, UE sends corresponding RRC
response message back to SRNC (Note 1). In this example and in the normal situation, the
RRC Physical Channel Reconfiguration Complete message is sent. When the transmission
of this message is confirmed by RLC, the UE shall resume data transmission on new Radio
Link(s).
Parameters: UE Information Elements (Integrity Check Info and optional Uplink Integrity
Protection Activation Info) and RB IEs (RB with PDCP information for each RB with PDCP
and optional Radio Bearer Uplink Ciphering Activation Time Info).
17. After successful switch in Target RNC (now SRNC for UE) and when the new SRNC-ID + SRNTI are successfully exchanged with the UE by the radio protocols, new SRNC sends
RANAP Relocation Complete message to both CN nodes. Now, the SRNS relocation is
complete. At any phase up to this message is sent, the old communication links were all the
time existing and working and the procedure execution could be stopped and original
information restored. After this switch, UL traffic from Nodes B is routed via the newly
established MD-Combiner to the new MAC/RLC entities and finally to the correct Iu transport
bearer. DL data arriving from the new Iu link is routed to newly established RLC entities, to
the MAC and to the MD-splitter and Nodes B.
Parameters: none specific IE.
18. The Relocation Complete message shall be handled the same way though the Relocation
Detect message is not received yet. Hard Handover is successfully terminated. Then, CN
nodes instruct Source SRNS to release the Iu connection as described in the Iu Signalling
Connection Release procedure section. Then, old RRC connection and related UTRAN
resources will be released, except those resources used for data forwarding, which will not be
released until TDATAfwd expires. The Source SRNC will not respond with the Iu Release
Complete message until this timer has expired.
Note: CN nodes should stop timer TRELOCcompl though it is not indicated in specifications. In
addition, Source SRNS should also stop timer TRELOCoverall at receiving the Iu Release Command,
though it is not indicated in specifications.
Approved
104
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
19. After the UE has finished the reconfiguration process and if the new Routeing/Location Area
Identification is different from the old one, the UE initiates corresponding update procedure.
Note 1: The messages used are only one example of the various messages that can be used to
trigger a handover, to confirm it or to indicate the handover failure. The different possibilities are
specified in [Ref. 25.331].
At this point, all UTRAN resources associated to old Radio Link(s) are completely released and
UE is using new Radio Link(s) on a different frequency and via new SRNS including new Iu
signalling connections. The Hard Handover procedure is ended.
In case tracing were activated, this order will be lost after successful Relocation of SRNS. If the
tracing shall continue also after the relocation has been performed, RANAP CN Invoke Trace
message shall be re-sent from the CN towards the new SRNC after the Relocation Resource
Allocation procedure, which ends in step 9.
Finally, for an UE with GPRS-CSI defined, CAMEL interaction may be performed, see referenced
procedures in 3G TS 23.078:
C1) CAMEL-GPRS-SGSN-Context-Acknowledge.
Approved
105
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
active), Target ID, UTRAN Transparent Container and optional Private Extension for
vendor/operator specifics.
3. Upon reception of previous message, New SGSN prepares itself for the switch and may also
suspend data traffic between UE and itself for some bearers. Then, New SGSN shall initiate
the Relocation Resource Allocation procedure. This procedure will allocate resources for
Target RNS for the relocation of SRNS. New SGSN sends RANAP Relocation Request
message to Target SRNC and starts timer TRELOCalloc. This message shall contain the
information (if any) required by the UTRAN to build the RAB configuration existing for the
UE before relocation.
Parameters: Permanent NAS UE Identity (if available), Cause, CN Domain Indicator, Source
RNC to Target RNC Transparent Container, Integrity Protection Information (if available), Iu
Signalling Connection Identifier, optional Encryption Information and RAB to be setup
Information for each RAB to be setup (RAB ID, RAB parameters, User Plane Information,
Transport Layer Address, Iu Transport Association, etc.).
At this point, the Target RNC shall initiate allocation of requested resources. The actions to be
taken are the same as specified for the same IEs in the RAB Establishment section. In addition, Target
SRNC shall take into account whether UE is involved in the relocation or not according to received
Relocation Type IE. The main difference is that if UE is involved in the process, it is possible Target
RNC establishes new necessary radio resources using the NBAP Radio Link Setup procedure (if the
first Radio Links and there is not UE Communication Context) or the NBAP Radio Link Addition
procedure (if not the first Radio Links and the UE Communication Context between Node B and
Target RNC already exists). In Figure 39, it is assumed UE is involved in the procedure and there is
not Communication Context established between Target Node B and Target SRNC. Then, Radio
Link(s) must be setup in following step. If Relocation Type IE indicates UE is not involved in the
process, it would not be possible to perform any of these procedures and only existing Radio Link(s)
could be used. For more details on this IE, see [ref. 25.413].
4. Target RNC allocates RNTI and radio resources for RRC and necessary Radio Link(s). Then,
CRNC in Target RNC sends NBAP Radio Link Setup Request message to Target Node B in
order to establish new UE Communication Context and necessary new Radio Link(s).
Parameters: CRNC Communication Context ID, UL and DL DPCH Information (TFCS, UL
Scrambling Code, etc.), DCH Information (general: Payload CRC Presence Indicator, UL FP
Mode, ToAWS, ToAWE; specific: DCH ID, DL/UL Transport Format Set, Frame Handling
Priority and QE-Selector), DSCH Information (DSCH ID, Transport Format Set, Frame
Handling Priority, ToAWS and ToAWE), RL Information (RL ID, C-ID, First RLS Indicator,
Frame Offset, Chip Offset, DL Code Information, Power control information etc.), and
optional Transmission Gap Pattern Sequence Information and Active Pattern Sequence
Information IEs. [See REF 25.433 for more details].
5. Node B shall establish new Radio Link(s) according to received parameters. If configuration
succeeds, Node B responses to CRNC with NBAP Radio Link Setup Response message.
Node B is now able to start UL physical reception on the new radio link (though UE will not
transmit anything yet).
Parameters: CRNC Communication Context ID, Node B Communication Context ID,
Communication Control Port ID, RL Information Response IEs (RL ID, RL Set ID, UL
Interference Level, DCH/DSCH IDs, Transport layer addressing information -AAL2 address,
AAL2 Binding Identity for the Iub Data Transport Bearer, etc.), and optional Criticality
Diagnostics. [See REF 25.433 for more details].
Approved
106
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
Node B
Target
SRNC
Source
SRNC
Target
Old
SGSN
1. R e l o c a t i o n R e q u i r e d
RANAP
New
SGSN
GGSN
RANAP
2. Forward Relocation Request
3. Relocation Request
RANAP
NBAP
RANAP
NBAP
Start RX
NBAP
NBAP
D C H - FP
D C H - FP
Start TX
8. Relocation Request Acknowledge
RANAP
RANAP
9. Forward Reloc ation Response
C1
10. Relocation Command
RANAP
RRC
RANAP
RRC
12. Forward SRNS Context
RANAP
RANAP
13. Forward SRNS Context
14. Forward SRNS Context Acknowledge
RANAP
RANAP
RANAP
18. Upd ate PDP Context Request
19. Update PDP Context Response
RRC
RRC
RANAP
RANAP
RANAP
Figure 39: Inter CN nodes Hard Handover with switching in the CN (PS domain only, UE in
DCH state)
6. As soon as Target RNC receives Radio Link Setup Response message, it can initiate setup of
Iub Data Transport Bearer using ALCAP protocol. This request contains the AAL2 Binding
Identity to bind the Iub Data Transport Bearer to DCH. This step may be repeated for each Iub
Data Transport Bearer to be setup.
7. (FDD only) Node B and Target SRNC establish synchronism for the Iub Data Transport
Bearers, relative to already existing radio link(s). This is done by means of the appropriate
Approved
107
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
DCH Frame Protocol (DCH FP) Downlink Synchronisation and Uplink Synchronisation
frames. Then, Node B is ready to start DL physical transmission.
8. After all necessary resources for accepted RABs including the Iu user plane, are successfully
allocated, the Target SRNC shall send a RANAP Relocation Request Acknowledge message
to the New SGSN. The transmission of this message terminates the Relocation Resource
Allocation procedure in the Target RNS.
Parameters: RABs setup IEs (RAB ID and if PS domain, Transport Layer Address and Iu
Transport Association), RABs failed to setup IEs (RAB ID and failure Cause), Chosen
Integrity Protection Algorithm (if available) and optional IEs Chosen Encryption Algorithm
and Critically Diagnostics. Finally, this message shall contain the Target RNC to Source RNC
Transparent Container for it has been assumed Relocation Type IE was set to UE involved in
relocation of SRNS. This container contains RRC Initialisation Information and optionally
D-RNTI if Target RNC supports triggering of the Relocation Detect procedure via the Iur
interface. (See step 17). It will be sent transparently to Source RNC in step 10.
9. At this moment, the Relocation Resource Allocation procedure is terminated and the Target
SRNC and the New SGSN are ready for relocation of SRNS. Then, New SGSN sends the
Forward Relocation Response message to the Old SGSN in order to proceed with the
relocation. The message responses to the Forward Relocation Request message received in
step 2. This response transfers UTRAN information received from Target SRNC so that
Source SRNS may perform the Forwarding of Data.
Parameters: Cause (Request Accepted in this example), Tunnel Endpoint Identifier Control
Plane (the chosen by the New SGSN to be used in the GTP header for all subsequent control
plane messages from Old to New SGSN in case of Request Accepted), RANAP Cause
(mandatory if cause value is contained in previous RANAP message), UTRAN Transparent
Container (if received) and optional Private Extension for vendor/operator specifics. Finally,
one or more RAB Setup Information IE parameters shall be set in this message.
10. At this moment, if Old SGSN decides to continue the relocation of SRNS, it shall send
RANAP Relocation Command message to the Source RNC and start timer TRELOCcompl.
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 TRELOCalloc, though it is not indicated in
specifications.
11. Upon reception of previous message from the PS domain, Source RNC shall start the timer
TDATAfwd, though Forwarding of Data will not start up to step 16. After receiving previous
message from all CN nodes involved in the process, Source RNC shall stop the timer
TRELOCprep and start the timer TRELOCOverall 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
UMTS Call Flows
November 4, 2000
Approved
108
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Approved
109
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
20. UE shall be able to receive a Physical Channel Reconfiguration message and perform a Hard
Handover at any time, even if no prior UE measurements have been performed on the target
cell and/or frequency. The UE should turn off the transmitter during the reconfiguration. UE
may first release the current physical channel configuration and shall then establish a new
physical channel configuration according to the information received in step 11 and [Ref.
25.331, section 8.5.7]. When the RRC connection is successfully established with the Target
RNC and necessary radio resources have been allocated, UE sends corresponding RRC
response message back to SRNC (Note 1). In this example and in the normal situation, the
RRC Physical Channel Reconfiguration Complete message is sent. When the transmission
of this message is confirmed by RLC, the UE shall resume data transmission on new Radio
Link(s).
UMTS Call Flows
November 4, 2000
Approved
110
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Parameters: UE Information Elements (Integrity Check Info and optional Uplink Integrity
Protection Activation Info) and RB IEs (RB with PDCP information for each RB with PDCP
and optional Radio Bearer Uplink Ciphering Activation Time Info).
21. After successful switch in Target RNC (now SRNC for UE) and when the new SRNC-ID + SRNTI are successfully exchanged with the UE by the radio protocols, new SRNC sends
RANAP Relocation Complete message to the New SGSN. Now, the SRNS relocation is
complete. At any phase up to this message is sent, the old communication links were all the
time existing and working and the procedure execution could be stopped and original
information restored. After this switch, UL traffic from Nodes B is routed via the newly
established MDC to the new MAC/RLC entities and finally to the correct Iu transport bearer.
DL data arriving from the new Iu link is routed to newly established RLC entities, to the MAC
and to the MD-splitter and Nodes B.
Parameters: none specific IE.
22. The Relocation Complete message shall be handled the same way though the Relocation
Detect message is not received yet. Hard Handover is successfully terminated and New SGSN
communicates it to the Old SGSN by the Forward Relocation Complete message.
Parameters: optional Private Extension for vendor/operator specifics.
23. The Old SGSN shall acknowledge previous message with the Forward Relocation Complete
Acknowledge message.
Parameters: Cause (Request Accepted in this case) and optional Private Extension for
vendor/operator specifics.
24. Finally, Old SGSN instructs Source SRNS to release the Iu connection as described in the Iu
Signalling Connection Release procedure section. Then, old RRC connection and related
UTRAN resources will be released, except those resources used for data forwarding, which
will not be released until TDATAfwd expires. The Source SRNC will not respond with the Iu
Release Complete message until this timer has expired.
Note: Old SGSN should stop timer TRELOCcompl though it is not indicated in specifications. In
addition, Source SRNS should also stop timer TRELOCoverall at receiving the Iu Release Command,
though it is not indicated in specifications.
25. After the UE has finished the reconfiguration process the UE initiates Routing Area Update
procedure.
Note 1: The messages used are only one example of the various messages that can be used to
trigger a handover, to confirm it or to indicate the handover failure. The different possibilities are
specified in [Ref. 25.331].
At this point, all UTRAN resources associated to old Radio Link(s) are completely released and
UE is using new Radio Link(s) on a different frequency and via new SRNS and new SGSN, including
new Iu signalling connections. The Hard Handover procedure is ended.
In case tracing were activated, this order will be lost after successful Relocation of SRNS. If the
tracing shall continue also after the relocation has been performed, RANAP CN Invoke Trace
message shall be re-sent from the CN towards the new SRNC after the Relocation Resource
Allocation procedure, which ends in step 9.
Finally, for an UE with GPRS-CSI defined, CAMEL interaction may be performed, see referenced
procedures in 3G TS 23.078:
C1) CAMEL-GPRS-SGSN-Context-Acknowledge.
Approved
111
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Approved
112
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
Node B
Source
Node B
Target
RNC
Source
RNC
Target
MSC/SGSN
1. Relocation Required
RANAP
RANAP
1. Relocation Required
RANAP
SGSN/MSC
RANAP
2. Relocation Request
RANAP
RANAP
2. Relocation Request
RANAP
RANAP
3. ALCAP Iu Data
Transport Bearer Setup
4. Radio Link Setup Request
NBAP
NBAP
Start RX
NBAP
NBAP
D C H - FP
D C H - FP
Start TX
8. Relocation Request
Acknowledge
RANAP
RANAP
RANAP
RANAP
9. Relocation Command
RANAP
RNSAP
RANAP
10. Relocation
Commit
RANAP
RNSAP
RANAP
12. Relocation
Detect
RANAP
14. D C C H : R N T I Reallocation
RRC
RRC
RRC
RANAP
NBAP
RRC
RANAP
16. Relocation
Complete
RANAP
RANAP
RANAP
RANAP
RANAP
RANAP
RANAP
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.
UMTS Call Flows
November 4, 2000
Approved
113
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Approved
114
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
RNC
Node B
RNC
RANAP PAGING
Case1:
UE is in idle mode
FP PCH
Cases 2 and 3:
UE is in URA connected mode ),
or Cell-PCH state (only for R1)
FP PCH
RANAP PAGING
FP PCH
Case 4:
UE is in cell connected mode
with existing DCCH
DCCH : PAGING TYPE 2
RANAP PAGING
Figure 41: Paging message flow over Iu, Iub and Iur
Soft/hard handover
URA updating
Cell update procedure (for UEs in the PCH substate of the cell connected mode)
Approved
115
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Serving
RNC
RRC
[S-RNTI, SRNC-ID]
RRC
[S-RNTI, SRNC-ID]
RRC
Approved
116
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
also the C-RNTI and the Cell-ID indicated in the previous UPLINK SIGNALLING
TRANSFER INDICATION message.
7. The URA UPDATE CONFIRM is sent to the UE.
8. DRNC releases the allocated D-RNTI and C-RNTI.
UE
DRNC
Source
DRNC
Target
SRNC
MSC/SGSN
1. Reception of
Uu
Signalling Message
2. Decoding of RNC-ID
from the UL message
3. Allocate D-RNTI and
C- RNTI
4. Uplink Signalling Trasfer Indication
RNSAP
RNSAP
[C-RNTI, D-RNTI,
Uu Signalling Message
]
5. Decision:
Not to perform
SRNC relocation
RNSAP
6. Downlink Signalling
Transfer Request
[C-RNTI,
Uu Signalling Message
RNSAP
]
7. Transmission of
Uu Signalling Message
Approved
117
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
SRNC =
CRNC
RRC
RRC
[S-RNTI, SRNC-ID]
Allocate
C-RNTI
3 4 .D C C H : C e l l U p d a t e C o n f i r m
RRC
RRC
[S-RNTI, SRNC-ID, new C-RNTI]
4 5 .D C C H : R N T I R e - A l l o c a t i o n C o m p l e t e
RRC
RRC
5 6 .D C 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 m p l e t e
RRC
RRC
Cases where a new C-RNTI is allocated by the UTRAN are described in the next section.
Approved
118
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
4. In case common physical channels info are sent by SRNC, with or without a new CRNTI8, and optionally a new U-RNTI, UE acknowledges the RRC Cell Update Confirm
message with a RRC Physical Channel Reconfiguration Complete message.
5. In case a new C-RNTI, and optionally a new U-RNTI, is allocated by the SRNC but no
common physical channels info are sent, UE acknowledges the RRC message Cell Update
Confirm with a RRC message RNTI Re-Allocation Complete.
In Cell-FACH state: When the UE selects another cell (via Cell Reselection) or at periodiccell update. In those cases, the UE will remain in Cell-FACH state at the end of the procedure.
Therefore it requires a C-RNTI.
In Cell-PCH state:
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.
When the UE wants to transmit data or when it is paged by the UTRAN. In this case, the
UE will go to Cell-FACH state at the end of the procedure. It requires a C-RNTI.
In URA-PCH state: When the UE wants to transmit data or when it is paged by the UTRAN.
In this case, the UE will go to Cell-FACH state at the end of the procedure. It requires a CRNTI.
The SRNC will insert a C-RNTI in the New C-RNTI field of Cell Update Confirm only in the
cases where the UE ends the procedure in Cell-FACH state. In that case, the UE has to confirm by
sending a Physical Channel Reconfiguration Complete message or a RNTI Reallocation Complete
message back to the UTRAN, depending on whether the CELL UPDATE CONFIRM message
includes or not the IE "PRACH info" and/or the IE "Secondary CCPCH info".
Cases where a new C-RNTI is allocated by the UTRAN are described in the next section.
Approved
119
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
This example shows an Inter RNS cell update in DRNS without SRNS relocation when no Iur
RACH/FACH transport bearer exists, i.e. ALCAP is used to set up the needed Iur AAL2 connection.
In this example target RNS, source RNS and serving RNS are all located separately from each other.
UE
RRC
DRNC
Source
DRNC
Target
SRNC
MSC/SGSN
RRC-relay
2. Decoding of RNC-ID
from the UL message
3. Allocatinge C- RNTI + D-RNTI
4. Uplink Signalling Transfer Indication
RNSAP
RNSAP
[C-RNTI, UL message]
5. Decision:
Not to perform
SRNC relocation
RNSAP
RRC
RNSAP
Figure 45: Cell Update via Iur (case without C-RNTI re-allocation)
1. UE sends an RRC message CELL UPDATE to the UTRAN on the CCCH.
2. The target DRNC decodes the SRNC ID and the S-RNTI.
3. The target DRNC allocates a C-RNTI and a D-RNTI to the UE.
4. The target DRNC forwards the received uplink CCCH message towards the SRNC in
the RNSAP UPLINK SIGNALLING TRANSFER INDICATION message. The
UPLINK SIGNALLING TRANSFER INDICATION message includes also the cellID of the cell from which the CCCH message was received, the D-RNTI and the
allocated C-RNTI.
5. Upon reception of the UPLINK SIGNALLING TRANSFER INDICATION message
the SRNC decides not to perform SRNS Relocation towards the target RNC.
6. The SRNC initialises the UE context in the target RNC with the RNSAP COMMON
TRANSPORT CHANNEL RESOURCES REQUEST message. The message includes
the D-RNTI previously received in the UPLINK SIGNALLING TRANSFER
Approved
120
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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.
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.
4.
The target DRNC forwards the received uplink CCCH message towards the SRNC in
the RNSAP Uplink Signalling Transfer Indication message. The Uplink Signalling
Transfer Indication message includes also the Cell-ID of the cell from which the CCCH
message was received and the allocated D-RNTI and C-RNTI.
5.
Upon reception of the Uplink Signalling Transfer Indication message the SRNC
decides not to perform SRNS Relocation towards the target RNC.
6.
The SRNC initialises the UE context in the target RNC with the RNSAP Common
Transport Channel Resources Request message. The message includes the D-RNTI
previously received in the Uplink Signalling Transfer Indication message, as well as a
request for transport layer address and binding identity if there exists no appropriate Iur
transport bearer to be used for the UE.
7.
The target DRNC sends the transport layer address, binding identity and optionally
PHY parameters (FACH code...) to the SRNC with the RNSAP Common Transport
Channel Resources Response message.
8.
If there does not already exist an appropriate Iur transport bearer to be used for the UE,
a transport bearer is established via ALCAP (Q.AAL2) from the SRNC.
Approved
121
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
UE
RRC
DRNC
SRNC
MSC/SGSN
RRC-relay
2. Decoding of RNC-ID
from the UL message
3. Allocating D-RNTI + C- RNTI
4. Uplink Signalling Transfer Indication
RNSAP
RNSAP
[new C-RNTI, UL message]
5. Decision:
Not to perform
SRNC relocation
RRC
RRC
109. DCCH: RNTI Reallocation Complete
or Physical Channel Reconfiguration Complete
RRC
Figure 46: Inter-RNS cell update via Iur (case with C-RNTI re-allocation)
9.
The SRNC sends RRC Cell Update Confirm on DCCH to the UE. The message is sent
in the Iur user plane. It will be sent by the target DRNC to the UE on the FACH
coupled to the RACH.
10.
If the IE "PRACH info" and/or the IE "Secondary CCPCH info" were included in the
Cell Update Confirm, the UE sends a Physical Channel Reconfiguration Complete
message on DCCH successful reception of Cell Update Confirm. Otherwise, if a new
C-RNTI has been allocated, the UE sends RRC RNTI Re-allocation Complete on
DCCH successful reception of Cell Update Confirm.
11.
The SRNC releases the old C-RNTI in the DRNC by sending a Common Transport
Channel Resources Release Request message. This message may or may not include
the C-RNTI.
12.
The DRNC releases the indicated old C-RNTI. If the message Common Transport
Channel Resources Release Request includes the C-RNTI, DRNC deletes only that CRNTI, otherwise DRNC deletes the whole UE context.
Approved
122
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
Since there are two possibilities for RRC connection and three possibilities for RAB assignment, there are at
least six possible combinations. It is FFS which scenarios are the most efficient and likely to be used, depending
on the combination of services supported. So far, only three scenarios are described.
Approved
123
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01
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
a. After reselection
b. Periodic
c. With/without SRNC relocation
d. Combined
e. Inter SGSN (the same than c??)
f. Combined Inter SGSN and Inter MSC
11. URA Update
a. After reselection
b. Periodic
c. With/without SRNC relocation
12. Cell Update
a. After reselection
b. Periodic
c. With/without SRNC relocation
d. Combined?
13. SRNC Relocation (pure procedure, which has similarities with a SRNC Relocation within
point 4.b procedure)
Approved
124
Motorola: ANDC-MA-00-0.3.4-RQ
Version 1.01