VoLTE - E2E Message Flows

1/42 MBB LTE SD P&C LTE E2E Field Performance
- VoLTE Message Flows -
3 LTE E2E Field Performance

4 - VoLTE Service Quality -
5
7 - Technical Note on E2E Message Flows

8
10
11 Document Status: Draft, Internal
12 Release 1.0, Issue 04
13 Date: 30th November 2012
14
15
16
17
18
19 Issued by the Nokia Siemens Networks GmbH & Co. KG
20 Copyright  Nokia Siemens Networks GmbH & Co. KG 2012
21 All Rights Reserved
Author: Dr. Andras Balazs MBB LTE SD P&C
22
NWS RA LTE E2E SA NE For NSN internal use only Tel.: +49.175.261.5151
Dr. A. Balazs Email: andras.balazs@nsn.com
2/42 LTE E2E Field Performance
1 Table of Contents
2 1. General Information ............................................................ 3

3 1.1 Revision History............................................................................................ 3
4 1.2 References ................................................................................................... 3
5 1.1.1 Product Descriptions .................................................................................... 3
6 1.1.2 Standard Documents .................................................................................... 4
7 1.3 Abbreviations and Glossary .......................................................................... 5
8 1.1.3 Abbreviations ................................................................................................ 5
9 1.1.4 Glossary ....................................................................................................... 6
10 1.4 List of Figures ............................................................................................... 6
11 2. Scope ................................................................................. 7
12 2.1 VoLTE Mobile to Mobile (MTM) Calls ........................................................... 7
13 2.2 Network Architecture .................................................................................... 7
14 3. Message Flow Descriptions ................................................ 9

15 3.1 High Level Message Flows ........................................................................... 9
16 3.1.1 LTE Detach .................................................................................................. 9
17 3.1.1.1 UE Initiated Detach ..................................................................................................... 9
18 3.1.1.2 Network Initiated Detach ........................................................................................... 10
19 3.1.2 SIP Registration.......................................................................................... 12
20 3.1.2.1 Successful Registration (HTTP Digest) .................................................................... 12
21 3.1.2.2 Unsuccessful Registration (HTTP Digest) ................................................................ 16
22 3.1.3 VoIP Call Setup .......................................................................................... 18
23 3.1.3.1 VoIP Call, Mobile-to-Mobile (MTM)........................................................................... 18
24 3.1.3.2 VoIP Call, MTM, B Party Busy .................................................................................. 20
25 3.1.4 VoIP Call Release ...................................................................................... 20
26 3.2 Detailed Message Flows............................................................................. 21
27 3.2.1 VoIP Call Overview..................................................................................... 21
28 3.2.2 Policy Controlled Session & Bearer Binding ............................................... 24
29 3.2.2.1 PCC over Gx Interface .............................................................................................. 25
30 3.2.2.2 PCC over Rx Interface .............................................................................................. 26
31 3.2.3 VoIP Call Setup with Bearer Binding........................................................... 28
32 3.2.4 LTE Attach.................................................................................................. 30
33 3.2.4.1 Initial Attach .............................................................................................................. 30
34 3.2.4.2 Re-Attach .................................................................................................................. 35
35 3.2.4.3 Initial Attach with LTE Network Details ..................................................................... 37
36 3.2.5 IMS Registration ......................................................................................... 39
37 3.2.6 VoLTE Call Setup ....................................................................................... 40
38 3.2.7 VoLTE Call Release ................................................................................... 41
39 3.2.8 LTE Detach ................................................................................................ 42
40
MBB LTE SD P&C For NSN internal use only Tel.: +49.175.261.5151
1 1. General Information
2 1.1 Revision History
Version Date Change Notes
V1.01 15.12.2011 First draft.
V1.02 20.12.2011 Editorial changes.
V1.03 03.05.2012 Update of VoLTE KPI Definitions.
V1.04 30.11.2012 Detailed message flows for 2-phase and 3-phase call setup alternative added.
KPI definitions and targets removed. These can be found in other documents.
Reference added.
3
4 Authors
Name Department
Dr. Andras Balazs MBB LTE SD P&C
6 1.2 References
7 1.1.1 Product Descriptions
[VoLTE_Trial] Vodafone Global VoLTE Trial, Call Flows for Phase 1, 14.01.2011.
[VoLTE_Demo] In-house VoLTE measurements in LTE Demo Network using RL20, May 2011.
[E2E_Field_KPI_Def] LTE E2E Field Network Performance for Offer and Acceptance, KPI Definitions
and Measurement Methods, MBB LTE SD P&C, V4.02, 30.11.2012.
[RL40_Field_KPI_Targets] LTE E2E Field Network Performance for Offer and Acceptance, KPI Targets for
RL40, MBB LTE SD P&C, V4.03, 30.11.2012.
[MSS_IMS_SR50] MSS Server IMS System, QoS Requirement Specification, SR 5.0, 02/2012.
8
1 1.1.2 Standard Documents

[3GPP23.203] 3GPP TS 23.203; V8.7.0 (2009-09); Policy and charging control architecture.
[3GPP23.401] 3GPP TR 23.401; v.8.x.x; General Packet Radio Service (GPRS) enhancements for Long Term
Evolution (LTE) access
[3GPP24.008] 3GPP TR 24.008; V8.5.0 (2009-03); Mobile Radio Interface Layer 3 Specification; Core network
protocols; Stage 3.
[3GPP24.228] 3GPP TR 24.228; V5.15.0 (2006-10); Signalling flows for the IP multimedia call control based on
Session Initiation Protocol (SIP) and Session Description Protocol (SDP);Stage 3 (Release 5)
[3GPP24.229] 3GPP TR 24.229; V8.8.0 (2009-06);IP multimedia call control protocol based on Session Initiation
Protocol (SIP) and Session Description Protocol (SDP);Stage 3 (Release 8)
[3GPP25.913] 3GPP TR 25.913; V8.0.0 (2008-12); Requirements for Evolved UTRA (E-UTRA) and Evolved UTRAN
(E-UTRAN).
[3GPP25.943] 3GPP TR 25.943; V8.0.0 (2008-12); Deployment Aspects (Release 8).
[3GPP26.114] 3GPP TS 26.114 V8.2.1 (2009-03); IP Multimedia Subsystem (IMS); Multimedia Telephony; Media
handling and interaction (Release 8).
[3GPP36.300] TS 36.300; v 8.x.x; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2
[3GPP36.331] TS 36.331; V8.6.0 (2009-06); Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource
Control (RRC) protocol specification
[3GPP36.401] TS 36.401; v 8.x.x; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Architecture
description
[RFC3261] IETF RCF 3261, SIP - Session Initiation Protocol, June 2002
2
1 1.3 Abbreviations and Glossary

2 1.1.3 Abbreviations
3 For the purposes of the present document, the abbreviations given in [3GPP21.905] and the
4 followings apply.
5 AF Application Function 63 NAS Non-Access Stratum

6 AMBR Aggregate Maximum Bit Rate 64 NE Network Element
7 AS Application Server 65 NRT Non Real Time
8 ASP Application Service Provider 66 OAM Operations and Maintenance
9 AV Audio / Video 67 p2e Picture-to-eye (for Video delay)
10 AVP Attribute Value Pair 68 PAPR Peak-to-Average-Power Ratio
11 AWGN Additive White Gaussian Noise 69 PCC Policy and Charging Control
12 BLER (Radio) Block Error Rate (initial, target) 70 PD Packet Delay
13 CDF Cumulative Distribution Function 71 PDU Packet Data Unit
14 CN Core Network 72 PDCP Packet Data Convergence Protocol
15 CQI Channel Quality Indication 73 PDV Packet Delay Variation
16 DL Downlink 74 P-GW Packet Data Network (PDN) Gateway
17 ECR Effective Coding Rate 75 PLMN Public Land Mobile Network
18 eNB eNodeB 76 PLR Packet Loss Rate
19 EPC Evolved Packet Core 77 PM Performance Management (of OAM)
20 EPS Evolved Packet System 78 PS Packet Switched
21 EPA Extended Pedestrian A 79 QAM Quadrature Amplitude Modulation
22 EVA Extended Vehicular A 80 QoE Quality of Experience
23 ETU Extended Typical Urban 81 QoS Quality of Service
24 E-RAB Evolved Radio Access Bearer 82 QPSK Quadrature Phase-Shift Keying
25 E-UTRAN Evolved UTRAN 83 OFDM Orthogonal Frequency Division Multiplex
26 FER Frame Error Rate (audio, or video) 84 PCC Policy and Charging Control
27 FTP File Transfer Protocol 85 PCEF Policy & Charging Enforcement Function
28 GBR Guaranteed Bit Rate 86 PCRF Policy and Charging Rule Function
29 GMC Golden Master Configuration 87 PDF Policy Decision Function
30 GTP GPRS Tunnelling Protocol 88 P-CSCF Proxy-Call Session Control Function
31 GUTI Globally Unique Temporary UE Identifier 89 RAN Radio Access Network
32 HARQ Hybrid Automatic Repeat Request 90 RAT Radio Access Technology
33 HLR Home Location Register 91 SLA Service Level Agreement
34 HSPA High Speed Packet Access 92 SLO Service Level Objective
35 HSS Home Subscriber Server 93 RPS Requests per Second
36 ICMP Internet Control Message Protocol 94 RRC Radio Resource Control
37 IE Information Element 95 RAB Radio Access Bearer
38 IETF Internet Engineering Task Force 96 RB Radio Bearer
39 IP Internet Protocol 97 RT Real Time
40 IP-CAN IP Connectivity Access Network 98 SAE System Architecture Evolution
41 ISD Inter-site Distance 99 SCTP Stream Control Transmission Protocol
42 IMSI International Mobile Subscriber Identity 100 SDF Service Data Flow
43 IWF Inter-working Function 101 SE Spectral Efficiency
44 KPI Key Performance Indicator 102 SFS System Feature Specification
45 KQI Key Quality Indicator 103 S-GW Serving Gateway
46 L3 Layer 3 104 SIR Signal to Interference Ratio
47 LTE Long Term Evolution 105 SINR Signal to Interference and Noise Ratio
48 LoS Line of Sight 106 SNR Signal to Noise Ratio
49 M2e Mouth-to-ear (for Audio delay) 107 SPR Subscriber Profile Repository
50 MAP Mobile Application Part 108 TA Tracking Area
51 MBR Maximum Bit Rate 109 TAU Tracking Area Update
52 MIMO Multiple Input, Multiple Output 110 TP Throughput
53 MM Mobility Management 111 TTI Transmission Time Interval
54 MME Mobility Management Entity 112 UDR User Data Repository
55 MMC Mobile to Mobile Call 113 UE User Equipment
56 MOS Mean Opinion Score 114 UL Uplink
57 MOS-CQ MOS – Conversational Quality 115 UTRAN Universal Terrestrial RAN
58 MOS-LQ MOS – Listener Quality 116 WS Work-station
59 MOC Mobile Originated Call 117
60 MT Mobile Termination (of the UE)
61 MTC Mobile Terminated Call
62 MTSI Multi-media Telephony Service over IMS
6/42 MBB LTE SD P&C LTE E2E Field Performance
1 1.1.4 Glossary
Application Function Provides application services to UEs by using IP-CAN bearers as transport links. One
(AF) example for AF is the P-CSCF of the IMS (IP Multimedia Subsystem of the CN).
AF Session Application layer session established by a signalling protocol of the AF that requires a
session set-up with explicit session description before the use of the service. One example
of an AF session is an IMS session, i.e. one VoLTE call.
Attribute-Value Pair Name and value of a parameter, exchanged in a communications protocol. Examples are
(AVP) Diameter messages, see also [RFC_3588]) exchanged over the Gx and Rx interfaces.
Binding Session and bearer binding are procedures of the PCRF by which IP flows described in an
AF Service Information are associated with IP-CAN (EPS) bearers.
IP-CAN bearer IP transmission path of defined capacity, delay and bit error rate, etc. See 3GPP TS 21.905
[1] for the definition of bearer. In the 4G access network, it corresponds to the EPS Bearer.
IP-CAN session Association between a UE and an IP network. The association is identified by one or more
UE IP addresses together with the UE identity information, if available, and a PDN
represented by an APN. An IP-CAN session incorporates one or more IP-CAN bearers. An
IP-CAN session exists as long as the related UE IP addresses are assigned and
announced to the PDN. In the 4G network, the IP-CAN session is maintained during the
Attached state of the UE and includes at least the default EPS bearer.
IP flow Unidirectional flow of IP packets with the same source IP address and port number and the
same destination IP address and port number and the same transport protocol. For bearer
mapping, it is described by the Traffic Flow Template (TFT).
PCC rule Set of information enabling the detection of a service data flow and providing parameters
for policy control and/or charging.
Service data flow An aggregate set of packet flows associated with an application service. In case of the
VoIP service, the SIP based IMS signaling and the RTP based voice media flows together
build the service data flow.
Service information Set of information conveyed from the AF to the PCRF over the Rx interface to be used as a
basis for PCC decisions at the PCRF including information about the AF session (e.g.
application identifier, type of media, bandwidth, IP address and port number).
2 1.4 List of Figures

3 Figure 1: MSS-IMS Architecture for VoLTE ................................................... 8
4 Figure 2: 3GPP Two-phase SIP Registration ................................................. 13
5 Figure 3: VoLTE 2-phase Call Setup ............................................................. 22
6 Figure 4: VoLTE 3-phase Call Setup with Early Media .................................. 23
7 Figure 5: Policy & Charging Control (PCC), Reference Model ....................... 24
8 Figure 6: VoIP Call Setup w/o Early Media (2-phase) .................................... 29
9 Figure 7: VoIP Call Setup with Early Media and UPDATE ............................. 29
10 Figure 8: VoIP Call Setup with Early Media w/o UPDATE.............................. 30
11 Figure 9: LTE Network Attach, NAS Signaling & UE Authentication .............. 37
12 Figure 10: LTE Attach, Initial Context Setup .................................................. 38
13 Figure 11: Dedicated EPS Bearer Establishment for IMS Signaling ............... 39
14 Figure 12: Dedicated EPS Bearer Establishment for Voice Media ................. 40
15 Figure 13: VoLTE Call Release ..................................................................... 41
16 Figure 14: LTE Detach................................................................................... 42
17
For NSN internal use only

7/42 LTE E2E Field Performance -
VoLTE Message Flows
1 2. Scope
2 This Technical Note provides background information on VoIP call flows over LTE
3 considering
4 a) SIP layer signalling and

5 b) message flow details over the access network
6 Given the very high number of possible VoLTE scenarios, a selection is made
7 according to the feature scope of RL40.
8 2.1 Network Architecture

9 The network architecture of the IMS/PCC based, 3GPP compliant VoIP service
10 covering LTE access is shown on Figure 1. It is according to MSS-IMS SR5.0 (see
11 [MSS_IMS_SR50]). The NSN VoIP FastTrack solution is not considered any more.
12 In the LTE access network, dedicated bearers with QoS support for VoIP signaling
13 and media flows are provided. Two alternatives usage are considered:
14 a) Separate APN for VoLTE service, two bearers:
15 i. Default EPS bearer for IMS signaling (QCI=5), plus

16 ii. dedicated EPS bearer for voice (QCI=1)
17 b) Common APN for Data and VoLTE services, three bearers:
18 i. dedicated EPS bearer for voice (QCI=1)Default EPS bearer for Data
19 (QCI=9), plus
20 ii. dedicated EPS bearer for IMS signaling (QCI=5), and
21 iii. dedicated EPS bearer for voice (QCI=1)
22
VoLTE Message Flows
CS Core
LDAP O&M
VM ENUM/ Server (NetAct/NetM/@Com/iNMC)
Server VAS (OneNDS/
DNS Server NPS)
(NVS) Charging
Provisioning
(Billing System/
(SAAM)
Charge@once)
MSC-Server , Interconnect
HSS-FE GMSS,VMSS,
(CMS-8200) S-/I-CSCF, MGCF,SRVCC
IMS Core BGCF, MCF (MSS)
(CFX-5000)
HLR-FE
(DX HLR) MGW,
MRF
(MGW U)
P-CSCF PSTN/PLMN
(CFX-5000)
Subscriber
Database
(One-NDS)
PCRF
TLS-off (PCS-5000) SIP/IMS peer
IP-NetNetworks
load (F5
networks)
I-BCF Transport
(CFX-5000) Signaling/control
SAE GW MME
(Flexi NG) (Flexi NS)
E-UTRAN GERAN/UTRAN
(CS only)
4G/LTE 2G/3G
LTE SIP clients Mobile SIP clients

SRVCC
1
2 Figure 1: MSS-IMS Architecture for VoLTE
3 2.2 VoLTE Mobile to Mobile (MTM) Calls

4 UE States:
5  registered and non-registered
6  after registration, idle and active
7 RF Conditions:
8  good, average & poor RF conditions
9 Mobility:
10  stationary, walking and drive tests
11 Voice calls:
12  NB- & WB-AMR codec, with and w/o trans-coding (TrFr)
13 Voice inter-working scenarios, like LTE-PSTN, LTE-fixed VoIP, and LTE – 2G/3G
14 calls are out of scope for the current paper.
VoLTE Message Flows
1 3. Message Flow Descriptions

2 3.1 High Level Message Flows
3 The high level message flows describe the VoIP call setup and release procedures
4 on SIP level. They do not include details of E-UTRAN and EPC control flows for EPs
5 bearer setup. These are described in the Chapter 3.2.
6 The SIP message flow descriptions are an excerpt from [VoLTE_VDF_Trial].
7 3.1.1 LTE Detach

8 This chapter describes the LTE Detach procedure, which can either be requested by
9 the UE explicitly, or by the network, when e.g. the network operator wants to bar a
10 certain user.
11 3.1.1.1 UE Initiated Detach
12 The following call flow shows the UE-initiated Detach procedure. It is assumed that
13 the UE is in active (ECM-CONNECTED) state and has only one Default EPS Bearer
14 established.
15
LTE Detach (successful User-initiated Detach procedure)
HLR HSS
UE-A e.NB MME Serving GW PDN GW PCRF P-CSCF-A I-/S-CSCF-A NVS-A
(LTE) (IMS only)
IMS De-Registration procedure between the UE (initiating) and the IMS
1. UL Info Transfer (Detach Request)
2. UL NAS Transport (Detach Request)
3. Delete Session Request
5. CCR (IP-CAN Session Termination Request)

Dynamic PCC
6. CCA (IP-CAN Session Termination Acknowledgement)
7. Delete Session Response
9. DL NAS Transport (Detach Accept)
10. DL Info Transfer (Detach Accept)
11. UE Context Release Command
12. RRC Connection Release
13. UE Context Release Complete
16
17
18 Message Flow Description
19 1. Uplink Information Transfer (Detach Request): the UE sends a Detach Request to the
20 eNB. The request is carried within an RRC Uplink Information Transfer message (TS
21 36.331, Section 5.6.2) over the Uu interface if the UE is already in ECM Connected
VoLTE Message Flows
1 mode. If the UE is in Idle mode, the UE-initiated Detach Request is carried within the
2 RRC Connection Complete message.
3 2. Uplink NAS Transport (Detach Request): the eNB forwards the Detach Request to the
4 MME via the S1-MME interface. The request is carried within an Uplink NAS Transport
5 message including the fields MME-UE-S1AP, eNB-UE-S1AP, NAS-PDU (including the
6 Detach Type), EUTRAN-CGI, and TAI.
7 3. Delete Session Request: sent by the MME to the Serving-GW to deactivate the EPS
8 Bearer. The request includes the EPS Bearer ID. If the UE has several EPS bearers
9 established, a separate Delete Session Request message is sent for each of them.
10 4. Delete Session Request: the S-GW forwards the Delete Session Request to the PDN-
11 GW. The message is not seen in traces if the S-GW and P-GW are collocated.
12 5. CCR (IP CAN Session Termination-Request): if dynamic PCC is supported, the PDN-
13 GW sends a Credit Control Request (CCR) with CC-Request type set to Termination-
14 Request via the Gx interface to the PCRF. See also Section 7.3 of 3GPP standard TS
15 23.203.
16 6. CCA (IP CAN Session Termination Acknowledgement): the Credit Control Answer
17 (CCA) is sent by the PCRF to the PDN-GW to acknowledge the CCR received earlier.
18 7. Delete Session Response: sent by the PDN-GW to the Serving-GW. The Cause
19 parameter in the Delete Session Response message indicates the success of the
20 request (e.g., “request accepted”).
21 8. Delete Session Response: sent by the Serving-GW to the MME.
22 9. Downlink NAS Transport (Detach Accept): the MME sends a Detach Accept to the
23 eNB. This is carried within a Downlink NAS Transport message as part of the NAS-PDU.
24 The other fields of the message are the MME-UE-S1AP-ID and the eNB-UE-S1AP-ID.
25 10. Downlink Information Transfer (Detach Accept): the eNB forwards the Detach Accept
26 to the UE.
27 11. UE Context Release Command: sent by the MME to the eNB to release the S1-MME
28 signaling connection associated to the given UE. The details of this procedure can be
29 found in Section 5.3.3 of TS 23.401. The details of the UE Context Release Command
30 (and of the corresponding UE Context Release Complete) are described in Section 8.3.3
31 of TS 36.413.
32 12. RRC Connection Release: sent by the eNB to the UE in Acknowledged Mode. Once the
33 message is acknowledged by the UE, the eNodeB releases all radio resources
34 associated to the RRC connection and deletes the UE's context.
35 13. UE Context Release Complete: sent by the eNB to the MME. This releases the S1
36 connection between the eNB and the MME for the UE. Please, note that the UE´s
37 context remains in the MME´s cache and can be reused if the UE re-attaches in the
38 tracking area of the MME.
39 3.1.1.2 Network Initiated Detach
40 The call flow below shows the network initiated Detach procedure. In the example,
41 the UE is detached in response to the termination of the user´s subscription in the
42 HLR/HSS. For simplicity, it is assumed that the UE has only one Default EPS Bearer.
43
VoLTE Message Flows
LTE Detach (successful Network-initiated Detach procedure)
HLR HSS
(LTE) (IMS only)
IMS De-Registration procedure between the UE and the IMS (initiated by the HSS by sending an RTR to the S-CSCF)
1. Cancel Location Request (Subscription Withdrawn)
2. DL NAS Transport (Detach Request)
3. DL Info Transfer (Detach Request)
6. CCR (IP-CAN Session Termination Request)

Dynamic PCC
7. CCA (IP-CAN Session Termination Acknowledgement)
10. UL Info Transfer (Detach Accept)
11. UL NAS Transport (Detach Accept)
12. Cancel Location Answer
13. UE Context Release Command
14. RRC Connection Release
15. UE Context Release Complete
1
2
4 1. Cancel Location Request (CLR): sent by the HLR/HSS to the MME via the S6a
5 interface after the operator cancelled the LTE subscription of the subscriber. Since the
6 HLR/HSS desires the immediate release of the context and EPS Bearers maintained for
7 the LTE subscriber in the network, the CLR includes the Cancellation Type set to
8 Subscription Withdrawn.
9 2. Downlink NAS Transport (Detach Request): sent by the MME to the eNB. It is
10 assumed that the UE is in ECM-CONNECTED, such that the MME does not have to
11 page the UE.
12 3. Downlink Information Transfer (Detach Request): the eNB forwards the Detach
13 Request to the UE. This informs the UE that it has been detached from the network.
14 4. Delete Session Request: sent by the MME to the Serving-GW to deactivate the EPS
15 Bearer. The request includes the EPS Bearer ID. In the case that the UE has several
16 EPS bearers active, a separate Delete Session Request message is sent for each of
17 them.
18 5. Delete Session Request: the Service-GW forwards the Delete Session Request to the
19 PDN-GW.
20 6. CCR (IP CAN Session Termination-Request): if dynamic PCC is supported (in Test
21 Phase 2), then the PDN-GW sends a Credit Control Request (CCR) with the CC-
22 Request type set to Termination-Request via the Gx interface to the PCRF. See also
23 Section 7.3 of 3GPP standard TS 23.203.
VoLTE Message Flows
1 7. CCA (IP CAN Session Termination Acknowledgement): the Credit Control Answer
2 (CCA) is sent by the PCRF to the PDN-GW to acknowledge the CCR (IP CAN Session
3 Termination Request) received earlier.
4 8. Delete Session Response: sent by the PDN-GW to the Serving-GW. The Cause
5 parameter in the Delete Session Response message indicates the success of the
6 request (e.g., “request accepted”).
7 9. Delete Session Response: sent by the Serving-GW to the MME.
8 10. Uplink Information Transfer (Detach Accept): when the UE receives the Detach
9 Request (in step 2 in the call flow above), the UE acknowledges this request by sending
10 a Detach Accept message to the eNB/MME. This is done any time after step 2.
11 11. Uplink NAS Transport (Detach Accept): the eNB forwards the Detach Accept received
12 from the UE to the MME.
13 12. Cancel Location Answer (CLA): sent by the MME to the HLR/HSS to acknowledge the
14 CLR request received earlier from the HLR/HSS via the S6a-interface. This confirms the
15 release of the context and EPS Bearer(s) to the HLR/HSS.
16 13. UE Context Release Command: sent by the MME to the eNB to release the S1-MME
17 signaling connection for the UE. The details of this procedure can be found in Section
18 5.3.3 of TS 23.401. The details of the UE Context Release Command (and of the
19 corresponding UE Context Release Complete) are described in Section 8.3.3 of TS
20 36.413.
21 14. RRC Connection Release: sent by the eNB to the UE. The purpose of this is to release
22 the RRC connection, which includes the release of the established radio bearers as well
23 as all radio resources. The eNB sends the RRC Connection Release message to the UE
24 in Acknowledged Mode. Once the message is acknowledged by the UE, the eNodeB
25 deletes the UE's context.
26 15. UE Context Release Complete: sent by the eNB to the MME. This releases the S1
27 connection between the eNB and the MME for the UE.
28 3.1.2 SIP Registration
29 After the UE (user) has attached to the LTE access network, it needs to register at
30 the IMS to be able to receive IMS services. This section describes selected IMS
31 Registration procedures that include the actual registration of the UE at the IMS Core
32 (S-CSCF), as well as the 3rd Party Registration of IMS Application Servers.
33 3.1.2.1 Successful Registration (HTTP Digest)
34 This section describes the Registration procedure with successful user authentication
35 with HTTP Digest password based mechanism according to RFC2617 that was
36 adopted for SIP in RFC3261. The password has to be provisioned (out of band) on
37 the UE and on the HSS, and is not shown on the diagram below.
38
VoLTE Message Flows
SIP Registration with HTTP Digest Authentication (successful)
HLR HSS
(LTE) (IMS only)
LTE Attach Procedure
1. SIP Register
2. SIP Register
3. User Authorization Request

4. User Authorization Answer (Capabilities)
5. Multimedia Auth Request (SIP-Digest)

6. Multimedia Auth Answer (HA1, qop)
7. SIP 401 Unauthorized (realm, nonce, qop)

9. SIP Register (nonce, cnonce)


12. User Authorization Answer (S-CSCF)
13. Server Assignment Request (S-CSCF)

14. Server Assignment Answer (User Profile Data)
15. SIP 200 OK

16. SIP 200 OK
17. AAR (Subscription to Signalling Path Status)

PCC/QoS Support for Signalling Bearer
18. AAA
19. SIP Register
20. MAP Update Location Request
21. MAP Insert Subscriber Data Request (Supplementary Service Data)

22. MAP Insert Subscriber Data Ack
23. MAP Update Location Ack
24. SIP 200 OK
25. SIP Subscribe (Reg-Event)
26. SIP 200 OK
27. SIP Notify (Reg-Event)
28. SIP 200 OK
1
2 Figure 2: 3GPP Two-phase SIP Registration

4 1. SIP Register: sent by the UE to the P-CSCF via the Gm-interface. This message
5 initiates the registration of the UE in the IMS.
6 2. SIP Register: sent by the P-CSCF to the I-CSCF via the Mw-interface. The I-CSCF
7 address is resolved by the P-CSCF via DNS SRV. For this, the P-CSCF uses the domain
8 name found in the R-URI of the SIP Register message. Note that the I-CSCF and S-
9 CSCF are co-located in the example call flow.
10 3. User Authorization Request (UAR): sent by the I-CSCF to the HSS via the Cx-
11 interface. This is to query the IMS Registration Status of the user from the HSS, which is
12 why the UAR/UAA is also denoted as IMS Registration Status Query. The Public-Identity-
13 AVP carries the IMPU (IMS Public User ID) that identifies the user. The User-Name-AVP
14 carries the IMPI (IMS Public User ID) which can be viewed as an identification of the
15 specific device of the user. A description of the UAR/UAA parameters can be found in
16 Section 6.1 of TS 29.228.
17 4. User Authorization Answer (UAA): sent by the HSS to the I-CSCF to answer the UAR.
18 Since the user is not registered in the HSS (Initial Registration), the UAA message
19 returns the Server Capabilities (in the Server-Capability-AVP) used afterwards by the I-
20 CSCF to select an appropriate S-CSCF for the user being registered. Once the I-CSCF
21 has selected the S-CSCF, it forwards the SIP Register message to the S-CSCF (this is
22 not shown in the call flow because the I-CSCF and S-CSCF are co-located on the same
23 system in the example deployment).
VoLTE Message Flows
1 5. Multimedia Auth Request (MAR): sent by the S-CSCF to the HSS via the Cx-interface.
2 This message is used to request authentication information from the HSS. The SIP-
3 Authenticate-Scheme-AVP in the request indicates the user authentication scheme used,
4 which is “SIP Digest” in this scenario (the HSSc supports the 3GGP R9 compliant HTTP
5 Digest authentication from NSN IMS7.2 release onwards).
6 6. Multimedia Auth Answer (MAA): sent by the HSS to the S-CSCF to answer the MAR.
7 The message returns the information needed by the S-CSCF for the authentication of the
8 UE (for HTTP Digest, the relevant parameters are Digest-Realm-AVP, Digest-Algorithm-
9 AVP, Digest-QoP-AVP, Digest-HA1-AVP). A description of these parameters can be
10 found in Section 6.3 of TS 29.228. In short, HTTP Digest is a challenge/response
11 authentication scheme, in which the S-CSCF sends a challenge to the UE that needs to
12 be responded appropriately by the UE based on the pre-configured shared secret
13 (password).
14 7. SIP 401 Unauthorized: sent by the S-CSCF to the I-CSCF and from there to the P-
15 CSCF. The WW-Authenticate header included in the SIP 401 message contains the
16 authentication challenge (nonce) to be answered by the UE.
17 8. SIP 401 Unauthorized: sent by the P-CSCF to the UE. When the UE receives the
18 message, it computes the HTTP Digest response for the challenge (nonce) received in
19 the SIP 401 message. This uses the MD5 algorithm.
20 9. SIP Register: sent by the UE to the P-CSCF. The Authorization header in the SIP
21 Register message is used to transfer the HTTP Digest response (cnonce) from the UE to
22 the P-CSCF.
23 10. SIP Register: sent by the P-CSCF to the I-CSCF.
25 interface. See also the description of the UAR in step 3 above.
27 To ensure that the received SIP Register message is forwarded to the same S-CSCF
28 that was selected for the Initial SIP Register message, the HSS returns the S-CSCF
29 address in the Server-Name-AVP to the I-CSCF. The I-CSCF then forwards the SIP
30 Register message to the S-CSCF (this is not shown in the call flow because the I-CSCF
31 and S-CSCF are co-located on the same system in the example deployment. Upon
32 receipt of the SIP Register, the S-CSCF verifies the Digest response found in the SIP
33 Authorization header. If correct, then the user is successfully authenticated. If not, then
34 the registration request is rejected using an error message.
35 13. Server Assignment Request (SAR): sent by the S-CSCF to the HSS via the Cx-
36 interface. The key tasks performed with the SAR/UAR procedure are: 1) to assign an S-
37 CSCF to an IMPU after the user has been successfully authenticated and 2 to download
38 the user profile from the HSS to the S-CSCF. The S-CSCF name assigned is carried in
39 the Server-Name-AVP in the SAR. The description of the SAR/SAA parameters can be
40 found in Section 6.1.2 of TS 29.228.
41 14. Server Assignment Answer (SAA): sent by the HSS to the S-CSCF to respond to the
42 SAR from the S-CSCF. The User-Data-AVP in the SAA includes the user profile
43 downloaded with this message from the HSS to the S-CSCF.
44 15. SIP 200OK: sent by the S-CSCF via the I-CSCF to the P-CSCF via the Mw-interface.
45 This message answers the SIP Register message received earlier in step 9 from the UE.
46 16. SIP 200OK: the P-CSCF forwards the SIP 200 OK received from the I-CSCF/S-CSCF
47 back to the UE via the Gm-interface. This completes the authentication of the UE.
VoLTE Message Flows
1 17. AA-Request (AAR): sent by the P-CSCF to the PCRF via the Diameter based Rx-
2 interface. This request is made by the P-CSCF to subscribe at the PCRF for Notifications
3 of the Signaling Path Status as described in Section 4.4.5 of TS 29.214. The Specific-
4 Action-AVP of the AA-Request indicates/requests the subscription (e.g.,
5 INDICATION_OF_LOSS_OF BEARER / INDICATION_OF_RELEASE_OF_BEARER). In
6 the case that the LTE signaling bearer is lost (LOSS_OF BEARER) or released
7 (RELEASE_OF BEARER), then the PCRF will indicate this event to the P-CSCF using
8 an RAR message (Rx-interface). Note that this feature is not supported in Phase 1.
9 18. AA-Answer (AAA): sent by the PCRF to the P-CSCF to acknowledge subscription to the
10 notification of the signaling path status made with the AAR (in step 17).
11 19. SIP Register: sent by the S-CSCF to the Voice Application Server (the NVS in the
12 example above) via the ISC-interface. It can be sent any time after the SIP 200 OK (in
13 step 15). This message is used to inform the Application Server about the IMS
14 registration of the user. This procedure is called 3rd Party Registration. In the case that
15 the user has several application servers in its user profile, the S-CSCF sends a separate
16 SIP Register message to each of them (this requires an Initial Filter Criteria for each
17 application server in the IMS User Profile of the user).
18 20. MAP Update Location Request: sent by the NVS Voice Application Server to the HLR
19 via the D-interface. This procedure is used by the NVS to retrieve the Supplementary
20 Service Data from the HLR. The Location Update procedure is described in Section 8.1.2
21 of TS 29.002.
22 21. MAP Insert Subscriber Data Request: sent by the HLR to the NVS Voice Application
23 server via the D-interface. This request carries the Supplementary Service Data from the
24 HLR to the NVS. The Insert Subscriber Data procedure is described in Section 8.8.1 of
25 TS29.002.
26 22. MAP Insert Subscriber Data Ack: sent by the NVS to the HLR to acknowledge the
27 MAP Insert Subscriber Data Request received from the HLR.
28 23. MAP Update Location Ack: sent by the HLR to the NVS to acknowledge the MAP
29 Update Location Request received earlier (in step 20) from the NVS Voice Application
30 Server.
31 24. SIP 200 OK: sent by the NVS Voice Application Server to the S-CSCF via the ISC-
32 interface. This messages successfully acknowledges the SIP Register request received
33 earlier (in step 19) from the S-CSCF.
34 25. SIP Subscribe (Reg-Event): sent by the P-CSCF to the S-CSCF via the Mw-interface.
35 This request is used by the P-CSCF to subscribe at the S-CSCF (the Registrar) for the
36 Registration Event Package defined in RFC3680. The SIP Subscribe includes the Event
37 header indicating the name of the package “reg”. This procedure can be initiated at any
38 time after the successful user authentication (SIP 200 OK in step 16). The Registration
39 Event Package is useful because it enables the support of additional network procedures
40 (e.g., the Network Initiated De-Registration). Note that the NCS Client (in the UE) used in
41 the example deployment does not yet support the Registration Event Package.
42 26. SIP 200 OK: sent by the S-CSCF to the P-CSCF via the Mw-interface. This message
43 successfully acknowledges the SIP Subscribe (Reg-Event) request.
44 27. SIP Notify (Reg-Event): sent by the S-CSCF to the P-CSCF via the Mw-interface. Upon
45 receipt of the subscription request for the Registration Event Package, the S-CSCF
46 generates a notification (SIP Notify with Event header indicating “reg”) that reports the
47 current status to the P-CSCF. Since the UE has just been successfully registered, the
VoLTE Message Flows
1 SIP Notify message includes the event ”registered” in the application/reginfo+xml

2 message body.
3 28. SIP 200 OK: sent by the P-CSCF to the S-CSCF via the Mw-interface. This message
4 acknowledges the SIP Notify request received earlier (in step 27) at the P-CSCF.
5 3.1.2.2 Unsuccessful Registration (HTTP Digest)
6 This section describes an unsuccessful HTTP Digest user authentication scenario

7 caused by the fact the wrong password is used by the UE for the user authentication.
8
Registration with HTTP Digest Authentication (unsuccessful, wrong password)
HLR HSS
(LTE) (IMS only)
LTE Attach Procedure
1. SIP Register
2. SIP Register

4. User Authorization Answer (Capabilities)
5. Multimedia Auth Request (SIP-Digest)

6. Multimedia Auth Answer (HA1, qop)



12. User Authorization Answer (S-CSCF)
The User Authentication on the

S-CSCF fails. The S-CSCF
computes a new challenge
(nonce) to be presented
to the UE

14. SIP401 Unauthorized (realm, nonce, qop)
The UE may continue its attempt to register with IMS by sending SIP Register messages. The S-CSCF will always generate a new challenge
for each request. The S-CSCF will block the UE when a pre-configured threshold is reached.
9
11 1. SIP Register: sent by the UE to the P-CSCF via the Gm-interface. This message
12 initiates the registration of the UE in the IMS.
13 2. SIP Register: sent by the P-CSCF to the I-CSCF via the Mw-interface. The I-CSCF
14 address is resolved by the P-CSCF via DNS SRV. For this, the P-CSCF uses the domain
15 name found in the R-URI of the SIP Register message. The I-CSCF and S-CSCF are co-
16 located in the example call flow above.
18 interface. This is to query the IMS Registration Status of the user from the HSS. The
19 Public-Identity-AVP carries the IMPU (IMS Public User ID) that identifies the user. The
20 User-Name-AVP carries the IMPI (IMS Public User ID).
22 Since the user is not registered in the HSS (Initial Registration), the UAA message
23 returns the Server Capabilities (in the Server-Capability-AVP) used afterwards by the I-
24 CSCF to select an appropriate S-CSCF for the user being registered. Once the I-CSCF
25 has selected the S-CSCF, it forwards the SIP Register message to the S-CSCF (this is
VoLTE Message Flows
1 not shown in the call flow because the I-CSCF and S-CSCF are co-located on the same
2 system in the example deployment).
3 5. Multimedia Auth Request (MAR): sent by the S-CSCF to the HSS via the Cx-interface.
4 This message is used to request authentication information from the HSS. The SIP-
5 Authenticate-Scheme-AVP in the request indicates the user authentication scheme used,
6 which is “SIP Digest” in this scenario (the HSSc supports the 3GGP R9 compliant HTTP
7 Digest authentication from NSN IMS7.2 release onwards).
8 6. Multimedia Auth Answer (MAA): sent by the HSS to the S-CSCF to answer the MAR.
9 The message returns the information needed by the S-CSCF for the authentication of the
10 UE (for HTTP Digest, the relevant parameters are Digest-Realm-AVP, Digest-Algorithm-
11 AVP, Digest-QoP-AVP, Digest-HA1-AVP). A description of these parameters can be
12 found in Section 6.3 of TS 29.228.
13 7. SIP 401 Unauthorized: sent by the S-CSCF to the I-CSCF and from there to the P-
14 CSCF. The WW-Authenticate header included in the SIP 401 message contains the
16 8. SIP 401 Unauthorized: sent by the P-CSCF to the UE. When the UE receives the
17 message, it computes the HTTP Digest response for the challenge (nonce) received in
18 the SIP 401 message. Since this call flow scenario assumes that the UE uses the wrong
19 password, the computed response (cnonce) will not match such that the user
20 authentication fails later on.
21 9. SIP Register: sent by the UE to the P-CSCF. The Authorization header in the SIP
22 Register message is used to transfer the HTTP Digest response (cnonce) from the UE to
23 the P-CSCF.
24 10. SIP Register: sent by the P-CSCF to the I-CSCF.
26 interface. See also the description of the UAR in step 3 above.
28 To ensure that the received SIP Register message is forwarded to the same S-CSCF
29 that was selected for the Initial SIP Register message, the HSS returns the S-CSCF
30 address in the Server-Name-AVP to the I-CSCF. The I-CSCF then forwards the SIP
31 Register message to the S-CSCF (this is not shown in the call flow because the I-CSCF
32 and S-CSCF are co-located on the same system in the example deployment). Upon
33 receipt of the SIP Register, the S-CSCF verifies the Digest response found in the SIP
34 Authorization header. The Digest response does not match because the UE used the
35 wrong password. The S-CSCF thus returns a SIP 401 error response to the UE. This
36 includes a new challenge (nonce) such that the UE can try to register again.
37 13. SIP 401 Unauthorized: sent by the S-CSCF to the I-CSCF via the Mw-interface. The
38 WW-Authenticate header included in the SIP 401 error response contains the (new)
40 14. SIP 401 Unauthorized: the P-CSCF forwards the SIP 401 Unauthorized response to the
41 UE via the Gm-interface.
42 The UE may continue its attempt to register in the IMS by sending new SIP Register
43 messages to the IMS. The S-CSCF will always generate a new challenge for each of
44 these requests and return it using a SIP 401 response as shown above. The S-CSCF will
45 block the UE when a pre-configured threshold is reached.
VoLTE Message Flows
1 3.1.3 VoIP Call Setup

2 3.1.3.1 VoIP Call, Mobile-to-Mobile (MTM)
3 The diagram below shows the SIP message flow in the general case, where the
4 calling and the called party either belong to different service providers (roaming
5 case), or they are registered at different IMS domains of the same operator. It shows
6 SIP layer signaling messages w/o details of E-UTRAN and EPC control flows for the
7 establishment of dedicated EPS bearers for voice.
8 For sake of simplicity, the diagram neither shows SIP 100 Trying messages, which
9 are normally generated in response to the reception of the SIP INVITE message by
10 network elements along the transport path, and by the receiving UE.
SIP–UA call to SIP–UA

CFX-5000
UE-A P-CSCF-A S-CSCF-A NVS-A ENUM HSS I-CSCF-B S-CSCF-B NVS-B HLR P-CSCF UE-B
1. INVITE 2. INVITE 3. INVITE

P-AI A P-AI = A
R-URI = B
P-Charging ICID = P-AI = tel-A
SDP offer
Record-Route= pcscfA Record-Route = scscfA
4. INVITE
5. Convert B-number to
international format
6. ENUM query for B

7. Response (success)
8. INVITE
R-URI = IMPU (B)
Record-Route = scscfA 9. LIR
IMPU (B)
10. LIA
S-CSCF-B
11. INVITE 12. INVITE
R-URI = IMPU (B)
Record-Route = scscfB 13. SRI
Record-Route = scscfA
14. PRN
15. PRN ack
16. SRI ack
17. INVITE
18. INVITE 19. INVITE
R-URI = contact (B) R-URI = contact (B)
P-Called-Party = B P-Called-Party = B
Record-Route = scscfB
20. Alert the user
22. 180 ringing 21. 180 ringing

23. 180
26. 180 ringing 25. 180 24. 180 31. User takes the
27. 180
30. 180 29. 180 28. 180 call
33. 200 OK 32. 200 OK
34. 200 OK SDP answer
37. 200 OK 36. 200 OK 35. 200 OK
38. 200 OK
41. 200 OK 40. 200 OK 39. 200 OK
42. ACK 43. ACK 44. ACK
45. ACK
46. ACK 47. ACK
48. ACK
49. ACK 50. ACK
Call established
11
12
14 1. UE-A initiates the call using the address of the B-party as provided by the user. The SIP
15 INVITE message contains the SDP offer and is sent to the same P-CSCF, which was
16 contacted at registration time.
17 2. Before forwarding the SIP INVITE to the S-CSCF, the P-CSCF includes the identity of
18 the A-party in the P-Asserted Identity header field based on registration information (SIP-
19 URI). The P-CSCF also generates an ICID and adds it in a P-Charging-Vector header
20 field. In order to stay in the call path for subsequent requests, the P-CSCF inserts a
21 Record-Route header field. Note: If the P-CSCF is a B2BUA (like the ACME SBC), it will
22 not use the Record-Route header field defined for SIP proxies.
VoLTE Message Flows
1 3. Note: If HTTP digest is used and the UE does not provide credentials right away, then
2 the S-CSCF will challenge the UE (depending on configuration) with a “407 Proxy
3 Authentication” required response. This and the related ACK message are not shown in
4 the call flow. The S-CSCF performs originating service control and invokes the NVS
5 (Network Voice Service, or VoIP Application Server). In order to stay in the call path for
6 subsequent requests, the S-CSCF inserts a Record-Route header field. It usually also
7 adds a P-Asserted Identity header field for the Tel-URI.
8
9 4. After executing potential originating services, the NVS returns the call to the S-CSCF
10 based on the Route header information in message 3.
11 5. If the B-party address in the request-URI is phone number based, but not in international
12 format, the S-CSCF converts the telephone number to international format.
13 6. IF the B-party number is a telephone number, the S-CSCF performs an ENUM query for
14 the B-party number (SIP-URI).
15 7. The ENUM server returns as SIP-URI the B-party address, which is the IMPU of user B.
16 8. Using the ENUM result as (potentially new) request-URI, the S-CSCF follows the
17 procedures in RFC 3263 to identify the B-party I-CSCF. The S-CSCF forwards the
18 INVITE – again with a record-route header field.
19 9. The I-CSCF queries the HSS with the IMPU of B …
20 10. ... and receives the S-CSCF name of the B-party S-CSCF in the LIA response.
21 11. The I-CSCF forwards the INVITE message to the S-CSCF.
22 12. The S-CSCF performs terminating service control and invokes the NVS. In order to stay
23 in the call path for subsequent requests, the S-CSCF also inserts a Record-Route header
24 field.
25 13. - 16. The NVS interrogates the HLR.
26 17. After executing potential terminating services, the NVS returns the call to the S-CSCF
27 based on the Route header information in message 12.
28 18. The S-CSCF replaces the request-URI by the contact of B from the registration. It adds a
29 P-Called-Party header with the Request-URI it received in message 17. In order to stay
30 in the call path for subsequent requests, the S-CSCF inserts a Record-Route header
31 field. The message is forwarded to the P-CSCF of user B, which is known from the
32 service route discovery at registration.
33 19. After removing information not sent to the UE, the P-CSCF forwards the SIP INVITE
34 message to UE-B.
35 20. - 30. The B-party user is alerted and a “SIP 180 Ringing” response is returned along the
36 same path as the INVITE was sent.
37 31. - 41. The B-party user answers the call. A 200 OK response is sent along the same path
38 as the 180. The SIP 200 OK (to INVITE) message contains the SDP response.
39 42. - 50. The SIP ACK message acknowledges the receipt of the SIP 200 OK (INVITE) by
40 the A-party. It is sent along the route established at session initiation. SIP proxies, who
41 did not “record-route”, are not in the path of the ACK, i.e. the I-CSCF is not in the path of
42 the ACK or of any subsequent request.
43 The session is now established. The established SIP session (VoIP call) consists of three
44 dialogues: one between UE-A and NVS-A, one between NVS-A and NVS-B, and one
VoLTE Message Flows
1 between NVS-B and UE-B. In case of centralized IMS system (non-roaming case), we have
2 one NVS and each CSCF role has only one instance.
3
4 3.1.3.2 VoIP Call, MTM, B Party Busy
SIP-UA to SIP-UA call, B party is busy

CFX-5000
UE-A P-CSCF-A S-CSCF-A NVS-A ENUM HSS I-CSCF-B S-CSCF-B NVS-B P-CSCF-B UE-B
Messages 1- 18. like in VoIP call setup
19. INVITE
20. 486
21. 486 busy here
busy here
22. 486
23. ACK
24. ACK 25. ACK
28. 486 busy here 27. 486 26. 486
29. 486
30. ACK
31. ACK 32. ACK
35. 486 34. 486 33. 486
36. ACK 37. ACK 38. ACK
5
6 The call is initiated as described in Chapter 3.1.3.1 (messages 1-18). Once the
7 INVITE (19, like in 3.2.1) reaches UE-B, it does not alert User B, since the B-party is
8 busy. Therefore, UE-B returns a SIP 486 response (to INVITE) towards UE-A
9 (messages 20-22, 26-29, and 33-35), which is acknowledged with a SIP ACK
10 message (23-25, 30-32, and 36-38) on each dialogue.
11 3.1.4 VoIP Call Release
12 The diagrams below show SIP message flows for the VoIP call release procedure,
13 when initiated by the calling or by the called party, respectively. The call must have
14 been established before as described in Chapter 3.1.3.1.
15 Message flow details of releasing the associated EPS bearers of the UEs for SIP
16 signaling and for voice media transport are shown in Chapter 3.2.
17
SIP–UA call to SIP–UA, User A terminates the call.
CFX-5000
1. BYE 2. BYE 3. BYE

6. 200 OK 5. 200 OK 4. 200 OK
7. BYE
8. BYE 9. BYE
11. 200 OK 10. 200 OK
12. 200 OK 13. BYE
14. BYE 15. BYE
17. 200 OK 16. 200 OK
18. 200 OK
18
19
VoLTE Message Flows
SIP–UA call to SIP–UA, User B terminates the call

CFX-5000
2. BYE 1. BYE
3. BYE
4. 200 OK
5. 200 OK 6. 200 OK
8. BYE 7. BYE
9. BYE
10. 200 OK
11. 200 OK 12. OK
15. BYE 14. BYE 13. BYE
16. 200 OK 17. 200 OK 18. 200 OK
1
2 Once the user terminates the call, the UE sends a SIP BYE request, which follows
3 the same path like the SIP ACK message (steps 1-3, 7-9, and 13-15). The SIP 200
4 OK message is sent on each dialogue (steps 4-6, 10-12, and 16-18).
5 3.2 Detailed Message Flows

6 3.2.1 VoIP Call Overview
7 Figure 3 and Figure 4 below summarize all phases of a VoLTE call:
8 1. LTE Attach
9 2. IMS Registration
10 3. VoLTE Call Setup
11 4. Audio conversation
12 5. VoLTE Call Release
13 6. LTE Detach
14 The procedures for Network Attach/Detach and for IMS Registration/De-Registration

15 are shown for one UE (A party) only. The procedures look the same for the B party.
16 The diagrams provide a simplified overview of the VoIP call without providing E-
17 UTRAN+EPC control plane details, and without the exchange of SIP messages
18 internal to the IMS based VoIP server infrastructure. They show, where are
19 application layer messages linked to the creation or release of EPS bearers. Details
20 of session and bearer bindings are described in separate Chapters.
21 The diagram in Figure 3 shows the basic VoIP call setup procedure without Early
22 Media negotiation (called 2-phase call setup). Dedicated bearer setup for voice
23 begins only after the B Party has accepted the call. The message sequence of a 3-
24 phase call setup with Early Media is shown in Figure 4.
25 In order to provide the required service quality for VoIP, the application layer
26 signaling and media flows have to be aligned well with EPS bearers on network level.
27 This session and bearer alignment is provided by Policy and Charging Control (PCC)
28 functions of the EPC, as described in Chapter 3.2.2. The analysis of detailed
29 message flows follows in subsequent chapters.
30
VoLTE Message Flows
UE A LTE+EPC A IMS+VoIP AS EPC+LTE B UE B

LTE
Attach LTE
1. Random Access Procedure
Network VoLTE Registration,
2. NAS Signaling Setup Procedure Access Call Setup & Release
3. Authentication & Security Proc.
- 2 phase -
4. Default Bearer Setup - QCI9
5. Initial Context Setup Procedure
6. Update Default Bearer - QCI9
IMS SIP REGISTER (via QCI9)
Register SIP 401 Unauthorized (challenge)
SIP REGISTER (answer) IMS / SIP

SIP 200 OK (REGISTER)
Registration
7. Dedicated Bearer Setup - QCI5
VoIP SIP INVITE (via QCI5)
Call SIP 100 Trying SIP INVITE
SIP 100 Trying

VoLTE
Alert User
Call Setup
SIP 180 Ringing (Ringing)
Ringing SIP 180 Ringing Pick-up

SIP 200 OK (INVITE) phone
Call SIP 200 OK (INVITE)
Established
SIP ACK (INVITE) SIP (ACK) INVITE
Voice Media
RTP AMR-WB (via QCI1) RTP AMR-WB (via QCI1) Transfer
SIP BYE (via QCI5)

SIP BYE
VoLTE SIP 200 OK (BYE)
Call Call Release SIP 200 OK (BYE)
10. Dedicated Bearer Release - QCI1
Terminated
IMS SIP REGISTER (Expire=0) (via QCI5)
DeRegister
SIP 200 OK (REGISTER) IMS / SIP
De-Registration
LTE
Detach 13. Default Bearer Release – QCI9
1 UE A LTE+EPC A IMS+VoIP AS EPC+LTE B UE B
2 Figure 3: VoLTE 2-phase Call Setup
VoLTE Message Flows
LTE-Uu Gi-m-x Gi-m-x LTE-Uu

UE A LTE+EPC A IMS+VoIP AS EPC+LTE B UE B
LTE
Attach LTE Network Access

VoLTE Call Setup
- 3 phase -
IMS
Register IMS / SIP Registration
VoIP SIP INVITE (via QCI5)

SIP INVITE (SDP Offer)
Call
3-Phase VoLTE Call Setup
SIP 183 Provisional Response (SDP Answer)
SIP 183 Provisional Response (SDP Answer)
Dedicated Bearer Setup - QCI1
Dedicated Bearer Setup - QCI1
SIP PRACK SIP PACK
SIP 200 OK (PRACK) SIP 200 OK (PRACK)
SIP UPDATE (SDP Offer) SIP UPDATE (SDP Offer)
Alert User
Ringing SIP 180 Ringing SIP 180 Ringing (Ringing)
Pick-up
SIP 200 OK (INVITE) phone
Open Gate - QCI1
Call SIP 200 OK (INVITE) 1st RTP AMR-WB (via QCI1)
Established
Open Gate - QCI1
SIP ACK (INVITE)
1st RTP AMR-WB (via QCI1) SIP (ACK) INVITE
Voice Media
RTP AMR-WB (via QCI1) RTP AMR-WB (via QCI1)
Transfer
Call
VoLTE Call Release
Terminated
IMS
IMS / SIP De-Registration
DeRegister
LTE
LTE Network Detach
Detach
1 UE A LTE+EPC A IMS+VoIP AS EPC+LTE B UE B
2 Figure 4: VoLTE 3-phase Call Setup with Early Media
VoLTE Message Flows
1 3.2.2 Policy Controlled Session & Bearer Binding

2 Application layer signaling and media flows are bound to EPS bearers with the
3 requested QoS support using Policy and Charging Control (PCC) functions.
4 Reference model, basic notions, messages and parameters of the PCC as used on
5 the Gx and Rx interfaces are provided in this section.
6 The PCC Reference Model [3GPP_29.212] is shown in Figure 5. In the context of

7 this document, only the functions AF, PCRF and PCEF and their interactions via the
8 Gx and Rx interfaces are of importance. The Gx interface is specified in
9 [3GPP_29.212], common signaling flows of the Rx and the Gx interfaces in
10 [3GPP_29.213], while the Rx interface itself is given in [3GPP_29.214].
e.g. P-CSCF
Application
Function
(AF)
Rx
Subscription Sp
Profile Policy and
Repository Charging Rules
Function
(SPR)
(PCRF)
Gxx Online Charging
Gx System
(OCS)
Gy
Service Data Flow
Bearer Binding Policy and Based Credit
and Event Charging Control
Reporting Enforcement
Function Function
(BBERF) (PCEF)
Offline
Charging
AN-Gateway PDN Gateway System
Gz (OFCS)
11
12 Figure 5: Policy & Charging Control (PCC), Reference Model
13 The Application Function (AF), the Policy and Charging Rules Function (PCRF) and
14 Policy and Charging Enforcement Function (PCEF) are Diameter applications
15 [RFC_3588] playing client or server roles:
16  Gx interface: PCRF is server, PCEF is client
17  Rx interface: AF is server, PCRF is client
18 In the VoLTE scenario, the AF is played by the P-CSCF or by the first hop SIP Proxy
19 if no IMS is used. The PCRF is part of the Policy Server, while the PCEF is co-
20 located with the PDN-GW.
VoLTE Message Flows
1 3.2.2.1 PCC over Gx Interface

2 The Gx interface is used for provisioning and removal of PCC rules between the
3 PCRF and the PCEF and the transmission of traffic plane events from the PCEF to
4 the PCRF. Its use for charging control is not dealt with in this paper.
5 The purpose of the PCC rule is to:

6  Detect a packet belonging to a service data flow.
7  Select the downlink IP CAN bearer to the data flow.
8  Enforce the use of the correct IP-CAN bearer for uplink IP flows.
9  Identify the service the service data flow belongs to.
10  Provide policy control for a service data flow.
11 There are two different types of PCC rules:

12  Dynamic PCC rules are provisioned by the PCRF to the PCEF. These PCC
13 rules may either be predefined or dynamically generated in the PCRF.
14  Predefined PCC rules are preconfigured in the PCEF. Predefined PCC rules
15 can be activated or deactivated by the PCRF.
16 Among others, the PCC rules consist of:

17  service identifier;
18  service data flow filter(s);
19  QoS parameters, etc.
20 By the creation, modification and removal of PCC rules in the PCEF (PDN-GW), it is
21 possible to establish, modify and remove EPS bearers with the required QoS support
22 for application layer service flows. The binding of service flows to EPS bearers are
23 shown in detailed message flows in subsequent chapters. In order to understand the
24 operations via the Gx interface in different phases of VoLTE call establishments and
25 releases correctly, the terms IP-CAN Session and IP-CAN Bearer have to be
26 explained.
27 The IP-CAN Session denotes the association between the UE and the PDN network.
28 The association is identified by the IP addresses of the UE and by the APN of the
29 PDN. An IP-CAN Session incorporates one or more IP-CAN Bearers. An IP-CAN
30 Session exists as long as the IP addresses of the UE are assigned and announced
31 to the PDN. In the VoLTE scenario, the IP-CAN Session corresponds to the Attached
32 state of the UE to the LTE network. It includes at least one IP-CAN Bearer, the
33 default EPS bearer.
34 IP-CAN Session Establishment is initiated by the PDN GW (PCEF) during the LTE
35 Attach procedure. The PCEF sends a Diameter Credit Control (CC) message with
36 the Request Type "INITIAL_REQUEST" to the PCRF. The PCEF supplies the user
37 identification and other attributes to allow the PCRF to identify the PCC rules to be
38 applied. The other attributes include the IP-CAN type (“3GPP-EPS”) and the radio
39 access technology (RAT Type =“E-UTRAN”), PDN information, and the UE´s IP
40 address. Furthermore, the PCEF also indicates support for network-initiated bearer
41 request procedures (if appropriate). If available, the PCEF also indicates if the default
42 EPS bearer is requested to be used for IMS signalling. The PCEF may provide ARP
43 and QCI values corresponding to the Default EPS Bearer QoS.
VoLTE Message Flows
1 IP-CAN Session Termination: by the PDN GW (PCEF) during LTE Detach.It sends a
2 CC-Request with Request Type "TERMINATION_REQUEST".
3 In case of network initiated termination of the IP-CAN Session (forced LTE Detach,
4 e.g. due to termination of the UE´s subscription – with trigger from SPR), the PCRF
5 sends a Re-Auth(RA)-Request including the cause of Session Release. The PCEF
6 acknowledges the command by sending an RA-Answer message to the PCRF and
7 instantly removes/deactivates all PCC rules that have been previously installed or
8 activated on that IP-CAN Session. This leads to releasing all IP-CAN Bearers, i.e. the
9 dedicated EPS bearers of the UE.
10 IP-CAN Session Modification: can occur on request by the PDN-GW (PCEF) in the
11 following cases (“Pull” mode):
12  new IP-CAN (EPS) bearer is being established, modified or terminated,

13  UE-initiated resource modification occurs,
14  some Event trigger is fired.
15 The PCEF sends a CC-Request of the type "UPDATE_REQUEST" to solicit the

16 evaluation of the corresponding PCC rule by the PCRF. For an IP-CAN Session
17 modification, where an existing IP-CAN (EPS) Bearer is modified, the PCEF
18 identifies the specific event that caused the IP-CAN session modification (.e.g. EPS
19 bearer release due to radio link error). If the PCRF does not accept the CC-Request
20 (e.g. because the UE is requesting enhanced QoS for services not known to the
21 PCRF), it rejects the request using a CC-Answer with the corresponding result code.
22 The IP-CAN Session can also be modified by the PCRF (in “Push” mode) by
23 unsolicited requests to the PDN-GW (PCEF). The PCRF may provision PCC rules
24 without obtaining a request from the PCEF, e.g. in response to Diameter messages
25 received by the PCRF via the Rx interface. In such cases, the PCRF includes these
26 PCC rules in RA-Request messages to the PCEF. (No CCR/CCA messages are
27 triggered by this RA-Request.) The PCRF never sends a new RA-Request to the
28 PCEF until the previous RA-Request has been acknowledged for the same IP-CAN
29 Session.
30 The provisioning of new PCC rules, may lead to the creation of additional IP-CAN
31 (dedicated EPS) bearers in the “container” of the IP-CAN Session, or to the
32 modification of existing EPS bearers.
33 In summary, the following Diameter commands are used between the PCEF and the
34 PCRF over the Gx interface to create, modify or terminate IP-CAN Sessions, and
35 thus, implicitly create/modify or terminate IP-CAN (EPS) Bearers:
36  Credit Control (CC) Request / Answer

37  Re-Auth (RA) Request / Answer
38 3.2.2.2 PCC over Rx Interface

39 The Rx interface is used to exchange application level session information between
40 the Policy and Charging Rules Function (PCRF) and the Application Function (AF).
41 This information is part of the input used by the PCRF for PCC decisions. The PCRF
42 exchanges the PCC rules with the PCEF and QoS rules with the Bearer Binding and
VoLTE Message Flows
1 Event Reporting Function (BBERF, both located in the PDN-GW when considering
2 the VoLTE scenario) as described in the previous chapter over the Gx interface.
3 The Application Function (AF) is a component of application services that require

4 policing and charging control of traffic plane resources (e.g. EPS bearer and E-RAB
5 resources). One example of an application function is the P-CSCF if IMS is used.
6 The AF uses the Rx interface to provide the information on the application session
7 (AF session), which is needed to prepare and enforce policy decisions to the PCRF.
8 The Policy Control and Charging Rules Function (PCRF) is a functional element that
9 encompasses policy control decision and flow based charging control functionalities.
10 The PCRF provides network control of the detection, gating, QoS and flow based
11 charging of service data flows via the PCEF, which has the executive role. The
12 PCRF receives session and media related information from the AF, and on the other
13 hand, it informs the AF of traffic plane (e.g. bearer modification, or termination)
14 events. The PCRF checks if the service information provided by the AF is consistent
15 with the operator defined policy rules before using the service information to derive
16 the applicable QoS for the service. In the VoLTE scenario, the service information
17 contains the identification of IMS signaling and voice data flows, and uses it to setup
18 and control the required level of QoS support on the associated EPS bearers (via the
19 PDN-GW, PCEF).
20 For understanding the operations on the Rx interface, the term AF Session and its
21 relationship (binding) to IP-CAN Bearers is explained.
22 The “AF Session” is an application layer association of the UE with the requested
23 application service (server entity). It is established by a signalling protocol of the AF
24 that requires a session setup with explicit session description before the use of the
25 service becomes possible. One example for an AF session is an IMS session,
26 because IMS requires a SIP/SDP based negotiation about media parameters before
27 the multi-media call is established. Since a VoLTE call is one type of IMS based
28 multi-media sessions, we may associate an AF Session with a VoLTE call when
29 considering VoLTE scenarios. The VoLTE call is initiated with A SIP INVITE
30 message.
31 The means to forward binding requests between AF Sessions and IP-CAN Bearers is
32 the “Rx Diameter Session”, which is setup between the AF and the PCRF for the
33 exchange of PCC control messages. Information on service data flows of an AF
34 Session are sent to the PCRF. The PCRF is binding the signalling and media IP
35 flows of the AF Session (i.e. of the VoLTE call) to IP-CAN (i.e. EPS) bearers and
36 controls their creation, modification, QoS support and termination of these bearers
37 via the PCEF (PDN-GW). Since IP-CAN bearers are contained by an IP-CAN
38 Session, the operations take the form of IP-CAN Session modification requests via
39 the Gx interface.
40 Since the signaling path of IMS sessions (SIP) is common for all IMS based multi-
41 media services, it is of advantage to bind the signaling flow to an IP-CAN (EPS)
42 bearer already at IMS registration time. For this reason, binding requests are
43 forwarded via the Rx interface not only during VoLTE call setup, but also during IMS
44 Registration, although SIP REGISTRATION requests do not contain a media
45 component (SDP).
VoLTE Message Flows
1 Since the termination of the IP-CAN Session (UE Detach), or the modification or
2 release of IP-CAN Bearers have affects on application layer service flows, these
3 events are forwarded to the AF from the PCEF (PDN-GW) via the PCRF if the AF
4 has registered for such information. For this reason, the Rx Diameter Session also
5 provides commands (messages) for the indication of status changes of IP-CAN
6 Session and Bearers.
7 In summary, the following Diameter commands are used between the AF (P-CSCF)
8 and the PCRF over the Rx interface to bind AF session information (VoLTE call) with
9 operations on and status changes of IP-CAN Sessions and IP-CAN (EPS) Bearers
10 (indirectly via Gx interface commands by the PCRF):
11  Auth- Application (AA) Request/Answer:

12 AAR sent by AF to provide AF Session Information with requested QoS
13 support, while PCRF responding with AAA including the authorized service
14 parameters.
15  Re-Auth (RA) Request/Answer:
16 RAR sent by PCRF to the AF indicate specific action (e.g. about bearer status
17 modification), while AF responding with RAA.
18  Session-Termination (ST) Request/Answer
19 STR sent by AF to inform the PCRF that an AF Session has been terminated,
20 while PCRF responding with STA indicating corresponding actions.
21  Abort-Session (AS) Request/Answer
22 ASR sent by PCRF to indicate that the IP-CAN bearer for the established AF
23 Session is no longer available, while AF responds with ASA.
24 3.2.3 VoIP Call Setup with Bearer Binding

25 Two-phase call setup with QCI5 default bearer for SIP signaling and QCI1 bearer for
26 voice is shown in Figure 6 below. The initial state of both UEs is IDLE. The media
27 bearer is setup after the incoming call is accepted by the called party. The SIP
28 signaling and the creation of the dedicated bearer are running in parallel. This allows
29 faster call setup times, but the initial voice delay may become longer, when the
30 media path is not yet set up as the call connection is accomplished. The example is
31 from a commercial customer network with RL30, but the EPC and IMS/PCC are from
32 3rd party vendors.
33 The next message flow diagram (Figure 7) shows a VoLTE call setup with “Early
34 Media”, where the dedicated bearer for voice is created before the called user is
35 alerted. The bearer is blocked on the PDN-GW during the call setup procedure. The
36 “Gate” is opened after QoS negotiation is completed and the B party accepts the call.
37 The calling UE can accept or modify the SDP answer of the called UE with an
38 UPDATE message containing an updated QoS offer. The example message flow
39 shows NSN IMS/PCC behavior. The creation of the dedicated bearer and opening
40 the gate are blocking the SIP signaling. This leads to longer call setup times, but the
41 bearers are already available at call completion time and the first voice packets can
42 immediately be sent.
43 The third example (in Figure 8) shows an option of the 3-phase call setup, where the
44 called party is not waiting for the UPDATE message, but alerts the called UE
45 immediately after PRACK. This message sequence is also possible with NSN
46 IMS/PCC.
VoLTE Message Flows
UE-A eNB MME S/P-GW PCRF P-CSCF P-CSCF PCRF S/P-GW MME eNB UE-B
A dialing
Service Request
Initial Context Setup incl.

QCI5, QCI6 Bearer Modification
SIP INVITE (SDP offer) SIP INVITE (SDP offer) SIP INVITE (SDP offer)
Downlink Data Notification & Paging
100 Trying AAR
Service Request
AAA
AAR
Initial Context Setup incl.
AAA QCI5, QCI6 Bearer Modification
SIP INVITE (SDP offer)
100 Trying
Ringing 180 Ringing 180 Ringing 180 Ringing Alert B

to A (Ringing)
200 OK (INVITE, SDP Answer) 200 OK (INVITE, SDP Answer) Pick up

AAR AAR phone
AAA AAA
RAR RAR
Session 200 OK (INVITE, SDP Answer)

Setup
Dedicated Bearer Setup (QCI1) Dedicated Bearer Setup (QCI1)
SIP ACK SIP ACK SIP ACK

RAA RAA
1st voice from B RTP ( AMR-WB) RTP ( AMR-WB), A <- B RTP ( AMR-WB)
1st voice to B RTP ( AMR-WB) RTP ( AMR-WB), A -> B RTP ( AMR-WB)
2 Figure 6: VoIP Call Setup w/o Early Media (2-phase)
UE-A S/P-GW PCRF P-CSCF P-CSCF PCRF S/P-GW UE-B

Dialing INVITE (SDP offer) INVITE (SDP offer) INVITE (SDP offer)
183 (SDP answer)

AAR RAR
Dedicated Bearer Activation

183 (SDP answer) AAA RAA
RAR AAR
Dedicated Bearer Activation RAA AAA

183 (SDP answer)
PRACK PRACK PRACK

200 OK (PRACK) 200 OK (PRACK) 200 OK (PRACK)
UPDATE (SDP offer) UPDATE (SDP offer) UPDATE (SDP offer)

200 OK (UPDATE, SDP answer) 200 OK (UPDATE , SDP answer) 200 OK (UPDATE , SDP answer)
Ringing 180 (Ringing) 180 (Ringing) 180 (Ringing) Alert B

to A (Ringing)
PRACK / 200 OK (PRACK)
200 OK (INVITE) Pick up

RAR phone
AAR RTP ( AMR-WB)
RAA
Open Gate
200 OK (INVITE) AAA
RAR AAR
Open Gate
RAA AAA
Session 200 OK (INVITE)
Setup ACK ACK ACK
RTP ( AMR-WB) RTP ( AMR-WB) RTP ( AMR-WB)
4 Figure 7: VoIP Call Setup with Early Media and UPDATE
VoLTE Message Flows
UE-A S/P-GW PCRF P-CSCF P-CSCF PCRF S/P-GW UE-B
Dialing INVITE (SDP offer) INVITE (SDP offer) INVITE (SDP offer)
183 (SDP answer)

AAR RAR

AAA RAA
183 (SDP answer)
RAR AAR

RAA AAA
183 (SDP answer)
PRACK PRACK PRACK

200 OK (PRACK) 200 OK (PRACK) 200 OK (PRACK)
180 (Ringing) 180 (Ringing) 180 (Ringing)

Ringing Alert B
to A (Ringing)
200 OK (INVITE) Pick up
phone
AAR RAR
Open Gate
AAA RAA RTP ( AMR-WB)
200 OK (INVITE)
RAR AAR
Open Gate
RAA AAA
Session 200 OK (INVITE)
Setup ACK ACK ACK
RTP ( AMR-WB) RTP ( AMR-WB) RTP ( AMR-WB)
2 Figure 8: VoIP Call Setup with Early Media w/o UPDATE
3 3.2.4 LTE Attach

4 The UE (end-user) needs to register to the LTE network before the VoIP service can
5 be used. The procedure is denoted as LTE Network Attachment.
6 This section describes the Initial LTE Attach and Detach procedures. The 3GPP
7 standard procedures are described in TS 23.401. Section 5.3.2 therein includes the
8 Attach procedures and Section 5.3.8 describes the Detach procedures.
9 3.2.4.1 Initial Attach
10 This section describes a successful Initial LTE Attach procedure, where the UE is not
11 known to the MME at the time of the Attach requests. The UE is authenticated using
12 the associated user profile in the HLR.
13
VoLTE Message Flows
Initial LTE Attach with Authentication (successful, user not in MME, part I)
HLR HSS
(LTE) (IMS only)
1. System Information Broadcast
2. MAC Random Channel Access
3. RRC Connection Request
4. RRC Connection Setup
5. RRC Connection Setup Complete (Attach Request)
6. Initial UE Message (Attach Request)
7. Authentication Information Request
8. Authentication Information Answer
9. DL NAS Transport (Authentication Request)
10. DL Info Transfer (Authentication Request)
11. UL Info Transfer (Authentication Response)
12. UL NAS Transport (Authentication Response)
13. DL NAS Transport (Security Mode Command)
14. DL Info Transfer (Security Mode Command)
15. UL Info Transfer (Security Mode Complete)

Authentication / Security
16. UL NAS Transport (Security Mode Complete)
17. Update Location Request
18. Update Location Ack
19. Create Session Request
1
2
Initial LTE Attach with Authentication (successful, user not in MME, part II)
HLR HSS
(LTE) (IMS only)
21. CCR (IP CAN Session Establishment Request)

Dynamic PCC
22. CCA (IP CAN Session Establishment Ack)
23. Create Session Response
25. Initial Context Setup Request (Attach Accept)
26. UE Capability Enquiry UE Radio Capability

Information Procedure
27. UE Capability Information
28. UE Capability Info Indication
29. RRC Connection Reconfiguration (Attach Accept)
30. RRC Connection Reconfiguration Complete
31. Initial Context Setup Response
32. UL Direct Transfer (Attach Complete)
33. UL NAS Transport (Attach Complete)
Uplink Data
34. Modify Bearer Request
35. Modify Bearer Response
Downlink Data
IMS Registration procedure between the UE and the IMS
3
VoLTE Message Flows
1
3 1. System Information Broadcast: the UE reads the system information broadcasted
4 periodically in every LTE cell (only one is illustrated in the call flow). This provides the UE
5 with the cell information. The UE passively listens to the broadcast information and
6 determines the signal strength.
7 2. Random Access: After the UE has selected an LTE cell with best radio conditions to
8 access, it initiates/performs the Random Access Channel (RACH) procedure as defined
9 in TS 36.321.
10 3. RRC Connection Request: sent from the UE to the eNB. The purpose of this request is
11 to establish an RRC connection. Details of the RRC Connection establishment procedure
12 can be found in Section 5.3.3 of TS 36.331.
13 4. RRC Connection Setup: sent by the eNB to the UE. Successful reception indicates the
14 establishment of the SRB1 (Signaling Radio Bearer) between the UE and the eNB.
15 5. RRC Connection Setup Complete (Attach Request): sent by the UE to the eNB. The
16 RRC message includes the Attach Request in its body as a NAS message together with
17 a PDN Connectivity Request, indicating the type of the PDN (PCO) the UE wants to
18 connect to. The request includes the IMSI such that a separate NAS Identity Request /
19 Response message exchange between the UE and the MME (in order to obtain the IMSI
20 from the UE) is not required.
21 6. Initial UE Message (Attach Request): sent by the eNB to the MME. The request is
22 carried to the MME within the NAS-PDU part of the S1-AP Initial UE Message. It also
23 contains the PDN Connectivity Request, which is used later by the MME when initiating
24 the establishment of the Default EPS bearer (see also the Create Session Request
25 message below).
26 7. Authentication Information Request (AIR): sent by the MME to the HLR/HSS. This
27 message initiates the user authentication by requesting one or more Authentication
28 Vectors (default = 1) from the HLR/HSS. The AIR request includes the IMSI received
29 from the UE to identify the subscriber. It also includes the Visited PLMN Identifier. The
30 details of the AIR are described in Section 7.2.5 of TS 29.272.
31 8. Authentication Information Answer (AIA): sent by the HLR/HSS to the MME. AIR
32 contains the Authentication Vector requested by the MME with the AIR. The
33 Authentication Vector (RAND, XRES, AUTN, KASME) is used for the authentication of
34 the UE. It is found in the Authentication-Info part of the AIA. The details of the AIA are
35 described in Section 7.2.6 of TS 29.272.
36 9. Downlink NAS Transport (Authentication Request): sent by the MME to the eNB to
37 request the authentication of the UE. The NAS-PDU carries the authentication request
38 including the EPS challenge (RAND, AUTN).
39 10. Downlink Information Transfer (Authentication Request): sent by the eNB to the UE.
40 Upon receipt of the Authentication Request from the MME, the eNB forwards the request
41 to the UE.
42 11. Uplink Information Transfer (Authentication Response): sent by the UE to the eNB.
43 Upon receipt of the EPS challenge from the eNB/MME, the UE computes the response
44 (RES) for the EPS challenge in order to authenticate the UE. The RES parameter is
45 transferred via the eNB to the MME.
46 12. Uplink NAS Transport (Authentication Response): upon receipt of the Authentication
47 Response by the eNB, the eNB forwards the response to the MME. The NAS-PDU of the
VoLTE Message Flows
1 message includes the authentication response (RES) of the UE. The MME then performs
2 the actual authentication. The UE is successfully authenticated when RES matches
3 XRES.
4 13. Downlink NAS Transport (Security Mode Command): sent by the MME to the eNB. In
5 order to request the NAS security support (integrity- and confidentiality protection
6 (ciphering)), the MME sends the Security Mode Command via the eNB to the UE. The
7 request specifies the integrity- and ciphering algorithms based on the relayed UE
8 capabilities.
9 14. Downlink Information Transfer (Security Mode Command): upon receipt of the
10 Security Mode Command by the eNB, the request is passed on to the UE.
11 15. Uplink Information Transfer (Security Mode Complete): send by the UE via the eNB
12 to the MME. This response messages acknowledges the Security Mode Command
13 request received (via the eNB) from the MME.
14 16. Uplink NAS Transport (Security Mode Complete): upon receipt of the Security Mode
15 Complete by the eNB, the request is passed on to the MME. After the successful
16 enabling of the NAS security support, the subsequent message exchange is protected
17 (integrity and ciphering).
18 17. Update Location Request (ULR): sent by the MME to the HLR/HSS. The request
19 includes the identity of the MME, the IMSI, the ME Identity, MME capabilities, etc. The
20 MME identity is stored in the HLR/HSS and identifies the MME as the current registrar of
21 the UE. The S6a interface between the MME and the HLR/HSS is described in 3GPP
22 TS 29.272.
23 18. Update Location Answer (ULA): sent by the HLR/HSS to the MME to acknowledge the
24 ULR. The ULA message returns the subscription data of the user to the MME. The
25 subscription data contains one (or more) PDN subscription context (one for each APN
26 that the UE is allowed to connect to) including the QoS parameters for the default EPS
27 bearer.
28 19. Create Session Request: sent by the MME to the Serving GW (S-GW). This request
29 initiates the establishment of a default EPS bearer. The message includes the following
30 parameters: IMSI, MSISDN, ME Identity, User Location Info, RAT type, APN, PDN type,
31 APN-AMBR, PDN GW address, default EPS Bearer QoS, PCO, etc. The message
32 details can be found in 3GPP TS 29.274 (GTPv2-C description).
33 20. Create Session Request: sent by the Serving GW to the PDN GW (P-GW). Upon
34 receipt of the Create Session Request, the Serving GW creates a new context entry into
35 the EPS bearer table. Afterwards, it sends a Create Session Request to the PDN GW
36 whose address it received in the request. Please note that this message may be internal
37 to the network element S/P-GW if the S-GW and the P-GW are co-located (this is the
38 case in EPC 8.0).
39 21. CCR (IP CAN Session Establishment Request): if dynamic Policy and Charging
40 Control (PCC) is supported, then the PDN GW sends an initial Credit Control Request
41 (CCR) via the Gx interface to the PCRF to request PCC authorization of the UE (user).
42 The request includes the IMSI, APN, the Bearer QoS, etc. See also Section 7.2 of 3GPP
43 TS 23.203. The PCRF downloads the associated user profile from the HSS by sending
44 Sh UDR (User Data Request?) and receiving Sh UDA (User Data Answer?) message
45 including the user’s policy profile. The Sh UDR/UDA messages are not shown in the call
46 flow above.
47 22. CCA (IP CAN Session Establishment Acknowledgement): the Credit Control Answer
48 (CCA) is sent by the PCRF to the PDN GW to acknowledge the CCR (IP CAN Session
VoLTE Message Flows
1 Establishment Request). The message returns the Default-EPS-Bearer-QoS, Bearer-

2 Control-Mode, Event Triggers, etc. to the PDN GW (PCEF).
3 23. Create Session Response: sent by the PDN GW to the Serving GW. This
4 acknowledges the Create Session Request.
5 24. Create Session Response: sent by the Serving GW to the MME. It acknowledges the
6 Create Session Request.
7 25. Initial Context Setup Request (Attach Accept): sent by the MME to the eNB. The
8 Attach Accept is transferred in the NAS-PDU of the Initial Context Setup message. It
9 includes the parameters: MME-UE-S1AP-ID, eNB-UE-S1AP-ID, UE-AMBR, E-RAB-to-
10 be-Setup-list, UE Security-Capabilities, Security-Key.
11 26. UE Capability Enquiry: sent by the eNB to the UE. This message is triggered by the
12 Initial Context Setup Request received from the MME (see the trigger condition described
13 in Section 5.11.2 of TS 23.401). As part of the UE Radio Capability Information
14 Procedure, the eNB requests the UE Radio Capability from the UE and uploads it to the
15 MME in the S1 interface UE Capability Info Indication message (see below). The actions
16 related to the UE Capability Handling (Enquiry- / Information message) are described in
17 Section 5.6.3 of TS 36.331.
18 27. UE Capability Information: sent by the UE to the eNB. This message is used by the UE
19 to inform the network about the UE Radio Capability information. It contains information
20 on the RATs that the UE supports (e.g., frequency bands, features). This information is
21 passed by the eNB to the MME.
22 28. UE Capability Info Indication: sent by the eNB to the MME. MME stores Radio
23 Capability Information received from the UE with this message. The reported UE radio
24 Capabilities include physical and PDCP layer parameters (e.g., RoHC support), RF
25 measurement parameters (e.g., Frequency Band Information), feature group indicators
26 (e.g., Radio Bearer support (SRB1, SRB2 for DCCH + 8xAM DRB)). See Section 5.11.2
27 of TS 23.401 for a description of the general behavior.
28 29. RRC Connection Reconfiguration (Attach Accept): sent by the eNB to the UE. This
29 includes the EPS Radio Bearer Identity and the Attach Accept message. The APN is also
30 provided to the UE to notify the UE of the APN for which the Default EPS Bearer has
31 been established. The UE may change the radio resource configuration. See also
32 Section 5.3.5 of TS 36.331.
33 30. RRC Connection Reconfiguration Complete: sent by the UE to the eNB to
34 acknowledge the RRC Connection Reconfiguration request.
35 31. Initial Context Setup Response: sent by the eNB to the MME. It includes the MME-UE-
36 S1AP-ID, eNB-UE-S1AP-ID, E-RAB-Setup-List, etc.
37 32. Uplink Information Transfer (Attach Complete): the UE sends an Uplink
38 InformationTransfer message to the eNB. This includes the Attach Complete message in
39 the ESM message container. The Attach Complete message includes the EPS Bearer
40 Identity, etc.
41 33. Uplink NAS Transport (Attach Complete): the eNB forwards the Attach Complete
42 message received from the UE to the MME. It is carried in the NAS-PDU of the Uplink
43 NAS Transport message. In total, the UL NAS Transport message includes the following
44 content: MME-UE-S1AP-ID, eNB-UE-S1AP-ID, NAS-PDU, E-UTRAN CGI (cell id.), and
45 the TAI (Tracking Area Identifier).
46 34. Modify Bearer Request: upon receipt of the Attach Complete indication from the eNB,
47 the MME sends a Modify Bearer Request to the Serving GW. A prerequisite for this is
VoLTE Message Flows
1 that the MME has also received the Initial Context Response (step 31). The Modify
2 Bearer Request includes for example the EPS Bearer ID, eNB F-TEID, etc. Note that the
3 Serving GW does not forward the Modify Bearer Request to the PDN GW (this is only
4 done in the case of a handover from a non-3GPP access).
5 35. Modify Bearer Response: upon receipt of the Modify Bearer Request message, the
6 Serving GW sends a Modify Bearer Response message back to the eNB. This
7 acknowledges the Modify Bearer Request.
8 After the LTE Attach and the establishment of the Default EPS Bearer, the IMS
9 Registration is performed. The IMS Registration procedure is shown in Chapter 3.1.2.
10 3.2.4.2 Re-Attach
11 This section describes a successful LTE Attach procedure for the case that the user
12 is already in the MME. The call flow shown below basically differs from the one
13 described in the previous section by the Location Update procedure that is omitted
14 when the user context is already in the MME.
15
LTE Attach with Authentication (successful, user already in the MME, part I)
HLR HSS
(LTE) (IMS only)
1. System Information Broadcast
2. MAC Random Channel Access
3. RRC Connection Request
4. RRC Connection Setup
5. RRC Connection Setup Complete (Attach Request)
6. Initial UE Message (Attach Request)
7. Authentication Information Request
8. Authentication Information Answer
9. DL NAS Transport (Authentication Request)
10. DL Info Transfer (Authentication Request)
11. UL Info Transfer (Authentication Response)
12. UL NAS Transport (Authentication Response)
13. DL NAS Transport (Security Mode Command)
14. DL Info Transfer (Security Mode Command)
15. UL Info Transfer (Security Mode Complete)
16. UL NAS Transport (Security Mode Complete) Authentication / Security
Update Location is
ommitted since the user
is already in the MME
16
17
VoLTE Message Flows
LTE Attach with Authentication (successful, user already in MME, part II)
HLR HSS
(LTE) (HSS only)
19. CCR (IP CAN Session Establishment Request)

Dynamic PCC
20. CCA (IP CAN Session Establishment Ack)
23. Initial Context Setup Request (Attach Accept)
24. UE Capability Enquiry UE Radio Capability

Information Procedure
25. UE Capability Information
26. UE Capability Info Indication
27. RRC Connection Reconfiguration (Attach Accept)
28. RRC Connection Reconfiguration Complete
29. Initial Context Setup Response
30. UL Direct Transfer (Attach Complete)
31. UL NAS Transport (Attach Complete)
Uplink Data
32. Modify Bearer Request
33. Modify Bearer Response
Downlink Data
IMS Registration procedure between the UE and the IMS
VoLTE Message Flows
1 3.2.4.3 Initial Attach with LTE Network Details

LTE-Uu S1-MME S11 S6a
UE eNodeB MME S-GW / P-GW HLR / HSS

Initial LTE Attach
2. NAS Signaling Setup Procedure
ATT_U_1 RRC Connection

RRC CONNECTION Establishment
REQUEST
ATT_N_1
RRC CONNECTION
CCCH SETUP
ATT_U_2 RRC CONNECTION
SETUP COMPLETE SBR1 is established,
DCCH but neither encrypted,
(NAS Attach + PDN
S1-AP: INITIAL UE nor integrity protected.
Connectivity Req.s) ATT_N_2
MESSAGE
(NAS Attach + PDN
Connectivity Req.s)
3. Authentication & Security Mode Procedure
NAS requests & responses transferred in NAS UL/DL Direct

Transfer messages, which are mapped to:
 RRC UL/DL INFORMATION TRANSFER, and
 S1-AP UL/DL NAS TRANSPORT messages.
ATT_M_1
NAS Identity Request (optional)
Core Network initiated Identity procedure (optional),
ATT_U_3
if IMSI is unknown to MME (not sent with Attach).
NAS Identity Response (IMSI)
ATT_M_2 Diameter: Authentication Info Request - AIR
( -> IMSI, MCC+MNC, E-UTRAN)

ATT_H_1
Diameter: Authentication Info Answer - AIA
(<- Auth. vector: RAND, AUTN, XRES, KASME)
ATT_M_3
NAS Authentication Request (RAND, AUTN)
ATT_U_4 Challenge the UE

NAS Authentication Response (RES)
ATT_M_4 Check if RES = XRES

NAS Security Mode Command
ATT_U_5
NAS Security Mode Complete (MEI)
All subsequent NAS
ATT_M_5 messages are encrypted &
NAS Identity Request (optional) integrity protected.
ATT_U_6
NAS Identity Response (MEI)
ATT_M_6
Diameter: Update Location Request - ULR
(ME Identity Check)
ATT_H_2
Diameter: Update Location Answer - ULA
NAS Ciphered Options Request (optional) (ME Identity Response)
User profile with Default
ATT_U_7
EPS QoS is returned.
NAS Ciphered Options Response
4. Default Bearer Setup
6. Update Default Bearer
UE eNodeB MME S-GW / P-GW HSS

2
3 Figure 9: LTE Network Attach, NAS Signaling & UE Authentication
VoLTE Message Flows
LTE-Uu S1-MME S11 Gx
UE eNodeB MME S-GW / P-GW PCRF

Initial LTE Attach
2. NAS Signaling Setup Procedure
3. Authentication & Security Mode Procedure
4. Default Bearer Setup
ATT_M_7
GTP-C: Create IP-CAN Session
Session Request
ATT_S_1
Credit Control
Request - CCR
ATT_P_1
Credit Control
GTP-C: Create Session Answer - CCA
Response
S1-AP: INITIAL CONTEXT New IP-CAN Session is established by P-GW.

SETUP REQUEST ATT_M_8 Implies creation of default EPS Bearer (QCI9).
(NAS Attach Accept +

ATT_N_3 Activate Default EPS EPS Bearer Id. and
Bearer Ctx. Request) QoS Parameters
RRC CONNECTION
RECONFIGURATION
(NAS Attach Accept +

Activate Default EPS Bearer
Ctx. Request)
UE Capability Enquiry
ATT_U_8
RRC CONNECTION
RECONF. COMPLETE
UE Capability Information
ATT_N_4
S1-AP: INITIAL CONTEXT
SETUP RESPONSE
UE Capability Information
RRC UL INFORMATION
TRANSFER
EUE
(NAS Attach Complete +
Activate Default EPS Bearer
Ctx. Accept) S1-AP: UL NAS
ATT_N_6
TRANSPORT
(NAS Attach Complete +

EPS Bearer Complete)
first UL data possible 6. Update Default Bearer
ATT_M_9
GTP-C: Modify Bearer EPS bearer created
Request
ATT_S_2
GTP-C: Modify Bearer
Response Buffered DL packets can
be sent now.
first DL data possible
UE eNodeB MME S-GW / P-GW HSS
Diameter messages, Gx interface:

CCR/CCA – Credit Control Request (S/P-GW) /Answer (PCRF): IP-CAN Session Establishment (LTE Attach, default EPS QCI9)
1
2 Figure 10: LTE Attach, Initial Context Setup
VoLTE Message Flows
1 3.2.5 IMS Registration

LTE-Uu S1-MME S11 Gx Rx
UE eNodeB MME S/P-GW PCRF P-CSCF
SIP REGISTER REGISTER
SIP 200 OK
IMS Signaling
EPS_C_1
SIP 200 OK (REGISTER)
AF Session Creation (Rx) and EPS_C_2

IMS IP-CAN Session Modification (Gx) AA-Request – AAR
Registration Service Info (IMS signaling),
EPS_P_1
Specific Actions
AA-Answer – AAA
PCRF binds new AF Session (for IMS Signaling) RA-Request – RAR
to existing IP-CAN Session of the UE
(created at LTE Attach, default EPS QCI9), with Create, activate
PCC & QoS rules EPS_S_1
IP-CAN Session Modification request, which implies
the creation of dedicated EPS Bearer (QCI5). RA-Answer – RAA
EPS_P_2 Store AF Session
Dedicated EPS Bearer Setup (QCI=5)

GTP-C: Create Bearer Select IP-CAN Bearer by PCC
Request rule, create EPS QCI=5 bearer.
S1-AP: E-RAB
SETUP REQUEST EPS_M_1 TFT, QCI5, MBR, etc.
(NAS Activate Dedicated

EPS Bearer Ctx. Request)
EPS_N_1
RRC CONNECTION
RECONFIGURATION

EPS_U_1
RRC CONNECTION
RECONF. COMPLETE
EPS_N_2
RRC UL INFORMATION S1-AP: E-RAB

TRANSFER SETUP RESPONSE

EPS Bearer Ctx. Accept)
S1-AP: UL NAS
EPS_N_3
TRANSPORT
(NAS Activate Dedicated Cell id. & TAI of the UE

EPS_M_2
GTP-C: Create Bearer
Response
Access Network Info EPS_S_2
(RAT Type)

RAR/RAA – Re-Authorization Request (PCRF) /Answer (S/P-GW): IP-CAN Session Modification (SIP REGISTER, dedicated EPS
QCI5) Diameter messages, Rx interface:
AAR/AAA – Auth-Application Request (P-CSCF) /Answer (PCRF): initial authentication of new AF Session (for IMS signaling)
Abbreviations
AF: Application Function
IP-CAN => E-UTRAN/EPC Access Network
2
3 Figure 11: Dedicated EPS Bearer Establishment for IMS Signaling
VoLTE Message Flows
1 3.2.6 VoLTE Call Setup

SIP INVITE SIP INVITE
SIP 200 OK
IMS Signaling
EPS_C_1
SIP 200 OK (INVITE)
EPS_C_2
VoLTE AA-Request – AAR
Call Setup Service Info (IMS signaling),
EPS_P_1
Specific Actions
AA-Answer – AAA
PCRF binds new AF Session (for voice media)
to existing IP-CAN Session of the UE with RA-Request – RAR
IP-CAN Session Modification request implying the Create, activate
creation of dedicated EPS Bearer (QCI=1). PCC & QoS rules EPS_S_1
RA-Answer – RAA
Select IP-CAN Bearer by PCC EPS_P_2 Store AF Session

rule, create dedicated EPS
bearer with QCI=1.
Dedicated EPS Bearer Setup (QCI=1)
EPS_S_2
Request
S1-AP: E-RAB TFT, QCI1, GBR, etc.
SETUP REQUEST EPS_M_1

EPS_N_1
RRC CONNECTION
RECONFIGURATION

EPS_U_1
RRC CONNECTION
RECONF. COMPLETE
EPS_N_2

TRANSFER SETUP RESPONSE

S1-AP: UL NAS
EPS_N_3
TRANSPORT
(NAS Activate Dedicated Cell id. & TAI of the UE

EPS_M_2
Response
EPS_S_3

RAR/RAA – Re-Authorization Request (PCRF) /Answer (S/P-GW): IP-CAN Session Modification (SIP INVITE, dedicated EPS QCI1)
Diameter messages, Rx interface:
AAR/AAA – Auth-Application Request (P-CSCF) /Answer (PCRF): initial authentication of new AF Session (for VoIP)
Abbreviations
2
3 Figure 12: Dedicated EPS Bearer Establishment for Voice Media
VoLTE Message Flows
1 3.2.7 VoLTE Call Release

SIP BYE SIP BYE
SIP 200 OK
IMS Signaling
EPS_C_1
SIP 200 OK (BYE)
AF Session Termination(Rx) and EPS_C_2

IP-CAN Session Modification (Gx) ST-Request – STR
VoLTE Store Service Info, EPS_P_1
Call Release Identify IP-CAN Session
ST-Answer – STA
RA-Request – RAR
Remove identified
PCC & QoS rules EPS_S_1
RA-Answer – RAA
Select IP-CAN Bearer by PCC EPS_P_2 Remove AF Session

rule, execute signaling for each
affected EPS bearer separately.
Dedicated EPS Bearer Release (QCI=1)
EPS_S_2
GTP-C: Delete Bearer
Request
EPS_M_1
S1-AP: E-RAB
RELEASE COMMAND
(NAS Deactivate Dedicated

EPS_N_1
RRC CONNECTION
RECONFIGURATION Release DRB
resources
EPS_U_1
RRC CONNECTION
RECONF. COMPLETE
EPS_N_2

TRANSFER RELEASE RESPONSE

S1-AP: UL NAS
EPS_N_3
TRANSPORT

EPS_M_2
Response
EPS_S_3

RAR/RAA – Re-Authorization Request (PCRF) /Answer (S/P-GW): IP-CAN Session Modification (release Dedicated EPS QCI=1)
STR/STA – Session Termination Request (P-CSCF) /Answer (PCRF): initial authentication of new AF Session (for VoIP)
Abbreviations
2
3 Figure 13: VoLTE Call Release

VoLTE Message Flows
1 3.2.8 LTE Detach

LTE Detach, UE Initiated
DET_U_1 LTE
Detach
RRC UL INFORMATION
TRANSFER
(NAS Detach) DET_N_1 S1-AP: UL NAS

TRANSPORT
(NAS Detach)
Default Bearer Release
DET_M_1
Request
DET_S_1
Response
IP-CAN Session Termination (Gx),

AF Session Termination (Rx)
DET_S_2
CC-Request – CCR
Remove all
PCC & QoS rules of the DET_P_1
IP-CAN Session CC-Answer – CCA
DET_S_3 DET_P_2
ST-Request – STR
Notify al AF Sessions
DET_C_1
registered for the event.
ST-Answer – STA
UE Context & RRC Connection Release
DET_M_2
S1-AP: UE CONTEXT
RELEASE
(NAS Detach Accept)

DET_N_2
Release DRB
RRC DL INFORMATION resources
TRANSFER
(NAS Detach Accept) Release RRC

Connection
RRC CONNECTION
RELEASE

CCR/CCA – Credit Control Request (S/P-GW) /Answer (PCRF): IP-CAN Session Termination (LTE Detach, default EPS QCI9)
STR/STA – Session Termination Request (PCRF) /Answer (P-CSCF): termination of still active AF Session(s) if any (for VoIP)
Abbreviations
2
3 Figure 14: LTE Detach

VoLTE - E2E Message Flows

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VoLTE - E2E Message Flows

Uploaded by

Copyright:

Available Formats

1/42 MBB LTE SD P&C LTE E2E Field Performance

- VoLTE Message Flows -

3 LTE E2E Field Performance

7 - Technical Note on E2E Message Flows

11 Document Status: Draft, Internal

12 Release 1.0, Issue 04

13 Date: 30th November 2012

19 Issued by the Nokia Siemens Networks GmbH & Co. KG

20 Copyright  Nokia Siemens Networks GmbH & Co. KG 2012

21 All Rights Reserved

Author: Dr. Andras Balazs MBB LTE SD P&C

2 1. General Information ............................................................ 3

14 3. Message Flow Descriptions ................................................ 9

V1.01 15.12.2011 First draft.

V1.02 20.12.2011 Editorial changes.

V1.03 03.05.2012 Update of VoLTE KPI Definitions.

Dr. Andras Balazs MBB LTE SD P&C

1 1.1.2 Standard Documents

[3GPP25.943] 3GPP TR 25.943; V8.0.0 (2008-12); Deployment Aspects (Release 8).

1 1.3 Abbreviations and Glossary

5 AF Application Function 63 NAS Non-Access Stratum

2 1.4 List of Figures

For NSN internal use only

4 a) SIP layer signalling and

8 2.1 Network Architecture

15 i. Default EPS bearer for IMS signaling (QCI=5), plus

17 b) Common APN for Data and VoLTE services, three bearers:

LTE SIP clients Mobile SIP clients

2 Figure 1: MSS-IMS Architecture for VoLTE

3 2.2 VoLTE Mobile to Mobile (MTM) Calls

1 3. Message Flow Descriptions

6 The SIP message flow descriptions are an excerpt from [VoLTE_VDF_Trial].

7 3.1.1 LTE Detach

11 3.1.1.1 UE Initiated Detach

IMS De-Registration procedure between the UE (initiating) and the IMS

1. UL Info Transfer (Detach Request)

2. UL NAS Transport (Detach Request)

3. Delete Session Request

4. Delete Session Request

5. CCR (IP-CAN Session Termination Request)

7. Delete Session Response

8. Delete Session Response

9. DL NAS Transport (Detach Accept)

10. DL Info Transfer (Detach Accept)

11. UE Context Release Command

12. RRC Connection Release

13. UE Context Release Complete

LTE Detach (successful Network-initiated Detach procedure)

1. Cancel Location Request (Subscription Withdrawn)

2. DL NAS Transport (Detach Request)

3. DL Info Transfer (Detach Request)

4. Delete Session Request

5. Delete Session Request

6. CCR (IP-CAN Session Termination Request)

8. Delete Session Response

9. Delete Session Response

10. UL Info Transfer (Detach Accept)

11. UL NAS Transport (Detach Accept)

12. Cancel Location Answer

13. UE Context Release Command

14. RRC Connection Release

15. UE Context Release Complete

SIP Registration with HTTP Digest Authentication (successful)

LTE Attach Procedure