1. VoLTE Procedure Variations and Concepts storyboard
Ready to begin your journey through the Voice over LTE Procedure Variations and Concepts course?

2. Emergency calling (VoLTE)
Course objective
Differentiate between a VoLTE-to-VoLTE call procedure and the following procedures, including the IMS Network Elements required to support each call case:
Roaming
SRVCC and eSRVCC
Border Control
Call Continuity
VoWiFi
Emergency calling (VoLTE)
Emergency calling (VoWiFi)
IMS Messaging
Title: Course Objective
On our X minutes journey today we will explore the VoLTE related topics shown.
Storyline: Time will be added once final WBT is generated and clocked.

3. VoLTE-to-VoLTE Call Procedure Review
LO 301
Before we begin our journey through the variations of Voice over LTE procedure let us review the VoLTE-to-VoLTE call procedure.

4. VoLTE to VoLTE Call Origination - review
Terminating IMS
VoLTE to VoLTE Call Origination - review
HSS AS
LTE UE B party
P-CSCF
I-CSCF
S-CSCF
EPC
IMS
CMS-8200
OpenTAS
MME
S6a/S13
HSS AS
eUTRAN Sh
S1-MME
S11
S6b
ISC
Sh/ LDAP 1
eNodeB
PGW
S5/S8 4 Cx 5
S1-U 7 Gm
LTE UE A party
SGW 8
CFX-5000 Gx Mw
User Control
PCRF Rx 6 2
P-CSCF 3
S-CSCF
Here is a brief review of the Voice over LTE to Voice over LTE call procedure.
Storyline: Following text will appear as pop-ups with the numbers in slide.
1) Call Origination - The UE begins a call and sends an ‘INVITE’ message through the network to the PGW then on to the P-CSCF.
2) QoS Authorization - The P-CSCF invokes the QoS Authorization through the PCRF, but only for SIP signaling.
3) INVITE Forwarded - The P-CSCF forwards the INVITE to the S-CSCF known from the registration of the UE.
4) Selection of Application Server - The S-CSCF invokes the application server (AS) based on the User Profile of the UE.
5) The originating S-CSCF of UE A queries the database (ENUM) to decide whether a PSTN break-out needs to be performed, and forwards the INVITE to a BGCF, if PSTN breakout is needed, or to the Terminating IMS.
On the Terminating IMS, the I-CSCF contacts the HSS. The HSS notifies the I-CSCF which S-CSCF has UE (B party). The I-CSCF sends the INVITE message to the terminating S-CSCF. The terminating S-CSCF sends the TAS a message. The TAS executes the termination (T-ADS). The TAS sends a message back to the S-CSCF. The S-CSCF sends the INVITE message to the terminating P-CSCF. The terminating P-CSCF sends the INVITE message to the UE (B party).
6) Dedicated Bearer Setup - The P-CSCF receives the message from the terminating network and commands the PCRF to set up a Dedicated Bearer.
7) Dedicated Bearer Established - The PCRF, PGW, and SGW set up the Dedicated Bearer with the appropriate Quality of Service.
8) Call Begins - Both UEs have established Dedicated Bearers, terminating UE rings, call begins.

5. Roaming Support for VoLTE
LO 302
Now, that we’ve reviewed the VoLTE-to-VoLTE call procedure let us begin exploring the variations.
Our first stop is roaming support for VoLTE.

6. Visited Network (UE A) EPC eUTRAN Home Network (UE A and UE B) EPC IMS
P-CSCF
eUTRAN
MME
eNodeB
PGW
TrGW
LTE UE A party
SGW
IMS-AGW
I-BCF
PCRF
Home Network
(UE A and UE B)
IMS-AGW
TrGW
EPC
IMS AS
eUTRAN
MME
HSS
eNodeB
LTE UE B party
SGW
PGW
PCRF
P-CSCF
S-CSCF
I-BCF
TITLE: Roaming Support for VoLTE
Storyline: Highlight additional NEs when mentioned
When roaming either with the same Home Network for both UE A and UE B, or with different Home Networks for UE A and UE B, there are Interconnection Border Control Functions (I-BCFs) at the roaming Network-to-Network Interface (NNI) which is between the Visited Network and Home Network of UE A. To ensure IP network separation the media stream is always anchored via Transition Gateways (TrGW) at the network borders.
Let’s take a closer look at the IMS during roaming.
User Control

7. Visited Network (UE A) EPC eUTRAN Home Network (UE A and UE B) EPC IMS
P-CSCF
eUTRAN
MME
eNodeB
PGW
TrGW
LTE UE A party
SGW
IMS-AGW
I-BCF
PCRF
IMS-AGW
Home Network
(UE A and UE B)
TrGW
EPC
IMS AS
eUTRAN
MME
HSS
eNodeB
LTE UE B party
SGW
PGW
PCRF
P-CSCF
S-CSCF
I-BCF
TITLE: IMS Support for VoLTE Roaming
Roaming control in the Visited Network is performed based on the domain name if included in the SIP Register request. The P-CSCF supports a preconfigured blacklist/whitelise mechanism for allowed/forbidden domain names. It allows the visited operator to specify which users, from which domains, are allowed to roam. SIP Register requests are rejected by the P-CSCF if the domain name if roaming is not allowed.
Roaming control in the Home Network, or Networks, is supported on a per domain name basis or per IMS subscriber basis. Roaming control support on a per domain name basis is implemented on the I-CSCF. The roaming control is performed based on the domain name, as P-Visited-Network-ID, included in the SIP Register request. The I-CSCF supports a preconfigured blacklist/whitelist mechanism for allowed/forbidden domain names. The P-Visited-Network-ID (PVNI) is generated by the P-CSCF to identify its own location. In roaming control support on a per IMS subscriber basis the PVNI includes a preconfigured identifier of the Visited Network (Network-ID). The I-CSCF notifies the HSS via the Cx interface during IMS Registration. The HSS supports a preconfigured blacklist/whitelist mechanism including roaming lists with allowed/forbidden Network-IDs. During IMS Registration the HSS checks the specific list associated with the IMS subscriber and rejects the request when network access is not allowed.
Click on the numbers to view the roaming procedure. Storyline: The following information will appear as numbered popups in the final WBT similar to what was done in Course 1.
1. UE sends REGISTER request to P-CSCF
The P-CSCF checks the domain name of the user's IMS Public User Identity (IMPU). It determines whether the user is a Home user or a roaming user from a partner. The P-CSCF's SIP REGISTER request
includes the P-Visited-Network-ID (PVNI) header.
2. “Roaming Allowed” Flags introduced
It is configurable in the I-BCF whether roaming to and from a peer network is allowed per a Service Level Agreement (SLA). For this purpose two "Roaming allowed" flags, one for the Visited-I-BCF and one for the Home-I-BCF, are introduced. If roaming is not allowed then all REGISTER requests to and from that peer network are rejected.
a) P-CSCF forwards REGISTER to visiting I-BCF
b) Visting I-BCF forwards REGISTER to home I-BCF
c) Home I-BCF forwards REGISTER to I-CSCF
3. I-CSCF queries HSS
4. HSS answer
The HSS compares the value found in the Visited-Network-Identifier AVP to the ones in the pre-configured lists. The HSS determines if roaming is or is not allowed. Possible answers are:
DIAMETER_FIRST_REGISTRATION
DIAMETER_ERROR_ROAMING_NOT_ALLOWED
5a. If answer is "DIAMETER_FIRST_REGISTRATION“
The I-CSCF forwards the SIP REGISTER to the S-CSCF including the PVNI header. The S-CSCF includes the header in all subsequent 3rd party REGISTER requests towards the SIP-AS.
5b. If the answer is: "DIAMETER_ERROR_ROAMING_NOT_ALLOWED"
The SIP REGISTER request is rejected, and the response “SIP 403 Forbidden” is sent back to the UE.
User Control

8. Visited Network (UE A) EPC eUTRAN Home Network (UE A and UE B) EPC IMS
P-CSCF
eUTRAN
MME
eNodeB
PGW
TrGW
LTE UE A party
SGW
IMS-AGW
I-BCF
PCRF
IMS-AGW
Home Network
(UE A and UE B)
TrGW
EPC
IMS AS
eUTRAN
MME
HSS
eNodeB
LTE UE B party
SGW
PGW
PCRF
P-CSCF
S-CSCF
I-BCF
TITLE: Open TAS Support for VoLTE Roaming
Storyline: Zoom on Open TAS
Inside the Open TAS a new database was created which provides several configurable parameters for a given roaming network. A maximum of 2000 roaming networks can be configured in the database. Each roaming network has an ID which is basically the content of the P-Visited-Network-ID (PVNI) header.
The PVNI embedded in the PVNI header of the SIP REGISTER request identifies the access network where the user is camping. During a 3rd party registration, the Open TAS parses the PVNI header and stores it in the Serving Profile Database (SPD).
3GPP defines that PVNI is inserted only in REGISTER requests. In the Nokia solution the Open TAS also supports PVNI in INVITE/MESSAGE requests. If no PVNI is received in the INVITE/MESSAGE, during call and message related service execution, the Open TAS uses the PVNI stored in the SPD, which was retrieved as part of the IMS registration procedure.
User Control

9. SRVCC and eSRVCC
LO 303
Let us continue our exploration by examing how the Single Radio Voice Call Continuity (SRVCC) differs from Voice over LTE (VoLTE).

10. EPC IMS eUTRAN Terminating IMS BSS/RNC IMS/MGW HSS AS GSM/WCDMA UE A
VoCS
SRVCC MSS MGCF
LTE UE B party
P-CSCF
I-CSCF
HLR
S-CSCF
SRVCC handover
EPC
IMS
Open TAS
eUTRAN
MME AS
eNodeB
HSS
PGW
LTE UE A
SGW
P-CSCF
S-CSCF
Voice over IMS bearer path Signalling
Voice over Circuit Switch (CS)
SRVCC-related Signalling
TITLE: Single Radio Voice Call Continuity (SRVCC)
To enable seamless voice service continuity from E-UTRAN access to UTRAN/GERAN access, Single Radio Voice Call Continuity (SRVCC) functionality is required. With SRVCC functionality, calls are not disconnected while roaming outside of the E-UTRAN coverage. The UE that supports SRVCC is handed over from E-UTRAN access to UTRAN/GERAN access, so that the service continues seamlessly.
Click on the numbers to explore the Single Radio Voice Call Continuity procedure. Storyline: The following information will appear as numbered popups in the final WBT similar to what was done in Course 1.
1. The User Equipment (UE) measures the LTE- and 2G 3G coverage.
2. The UE sends the measurement reports to the E-UTRAN (eNodeB).
3. The E-UTRAN makes the decision about the handover (HO) request and informs the Mobility Management Entity (MME) that the PS to CS HO is required.
4. The MME initiates the SRVCC for voice component towards the MSS (SRVCC). The MME can decide based on the Session Transfer Number for SRVCC (STN-SR) information whether the SRVCC procedure can be applied to the terminal.
5. The MSS (SRVCC) creates the anchor MSS function for the call. The SRVCC functionality in the MSS acts as CS anchor MSS towards the target 2G/3G CS domain and initiates the session transfer procedure to the SCC AS anchoring point by using the STN-SR. The SRVCC in the MSS together with the SCC AS anchor hides mobility between the LTE and the 2G/3G CS domain from the remote side of the call.
6. The MSS (SRVCC) prepares the CS handover to the target UTRAN/GERAN, or to the target MSS, in case the inter MSS HO is required.
7. In parallel, in case of simultaneous voice and non-voice data connection, the MME handles the PS to PS HO for non-voice.
8. The MSS (SRVCC) initiates the Voice Call Continuity towards the SCC AS anchor.
9. In parallel with step 8, the MSS (SRVCC) responds to the MME.
10. The MME commands the E-UTRAN to do the handover.
11. The E-UTRAN sends the HO command to the UE.
12. The UE completes the HO to UTRAN/GERAN.

11. EPC IMS eUTRAN Terminating IMS BSS/RNC IMS/MGW ATGW HSS AS
GSM/WCDMA UE A
VoCS
LTE UE B party
SRVCC / MSS / MGCF
P-CSCF
I-CSCF
HLR
S-CSCF
SRVCC handover
EPC
IMS
Open TAS
eUTRAN
MME
HSS AS
eNodeB
PGW
LTE UE A
SGW
PCRF
P-CSCF ATCF
S-CSCF
Voice over IMS bearer path Signalling
Voice over Circuit Switch (CS)
eSRVCC-related Signalling
TITLE: Enhanced Single Radio Voice Call Continuity (eSRVCC)
Storyline: Add animations to support narrations.
In order to minimize the voice interruption during access domain transfer, 3GPP defined Enhanced Single Radio Voice Call Continuity (eSRVCC) architecture, by adding Access Transfer Control Function (ATCF) and Access Transfer Gateway (ATGW) functionalities. ATCF and ATGW introduce new anchoring points for both user plane and control plane to eliminate the need of remote end update during handover.
In the Nokia eSRVCC solution the ATCF is co-located with the P-CSCF functionality residing in the CFX The P-CSCF supports the ATCF, used as the anchoring point for control plane which eliminates remote end update during SRVCC handover. The P-CSCF is a SIP proxy that is the first point of contact for the IMS terminal. It provides the Session Transfer Number for SRVCC (STN-SR) for the ATCF. The ATCF provides the anchoring in the serving network. It is included in the control plane session for the duration of the call and after the access transfer when the serving network provides eSRVCC for the subscriber.
The Access Transfer Gateway (ATGW) acts as the media anchor for sessions during the Enhanced Single Radio Voice Call Continuity procedure. The ATGW is controlled by the ATCF. The ATGW stays in the media path session for the duration of the IMS call, and stays in the call as well after the access transfer took place to the CS domain.

12. Border Control
LO 304
Let us now take a closer look at Border Control in a VoLTE perspective.

13. Border Control Open BGW EPC IMS eUTRAN CFX-5000 IMS-AGW / TrGW MME HSS
Iq/Ix H.248
IMS-AGW / TrGW
EPC
IMS
eUTRAN
MME
HSS AS
eNodeB
LTE UE B party
SGW
PGW
CFX-5000
PCRF
P-CSCF
S-CSCF
I-BCF
Nokia’s decomposed Session Border Controller (SBC) is comprised of the CFX-5000 based Border Control Function (BCF) and Open Border Gateway (Open BGW). The CFX-5000 and Open BGW are connected via the Iq/Ix H.248 interface. They help to ensure delivery of all IP Multimedia Subsystem (IMS) services to any device via any IP access.
Border Control functions in Voice over LTE can be divided into two groups:
Access Session Border Control (A-SBC) = IMS-ALG co-located with P-CSCF + IMS-AGW
Interconnect Session Border Control (I-SBC) = I-BCF + TrGW
Let us take a closer look at each type of Border Control function.
Storyline: Bring in labels (CFX-5000, Open BGW, and interface) when mentioned.
User Control

14. Access Border Control Open BGW EPC IMS eUTRAN CFX-5000 IMS-AGW MME HSSIq
IMS-AGW
EPC
IMS
eUTRAN
MME
HSS AS
eNodeB
LTE UE B party
SGW
PGW
CFX-5000
PCRF
P-CSCF
S-CSCF
IMS-ALG
Access Border Control Function for VoLTE contains the Access Border Control Function (A-BCF) and Access Border Gateway Function (A-BGF). The Access Border Control Function (A-BCF) is co-located with the Proxy Call Session Control Funtion (P-CSCF) in the CFX The A-BCF controls the Access Border Gateway Function (A-BGF) over the H.248 Iq interface.
Access Border Control prevents single end-user devices from making the IMS core network unavailable by denying their services and to continue serving other IMS users while under attack.
Storyline: Bring in border control NEs and interface when mentioned.
User Control

15. Interconnect Border Control Function
Open BGW
Interconnect Border Control Function Ix
TrGW
EPC
IMS
eUTRAN
MME
HSS AS
eNodeB
LTE UE B party
SGW
PGW
CFX-5000
PCRF
P-CSCF
I-CSCF
S-CSCF
I-BCF
The Interconnect Border Control Function contains the Interconnect Border Control Function (I-BCF) in the CFX-5000, and the Interconnect Border Gateway Function (I-BGF) and Transistion Gateway (TrGW) in the Open BGW. The I-BCF controls the I-BGF via the H.248 Ix interface.
Interconnect Border Control Function for VoLTE is used in connections to other IMS or SIP networks over non-trusted interconnections, and interconnections over public IP networks. The Interconnect Border Control protects the network border on signaling and media level. It can be used in an originating network, a terminating network, or a transit network. The I-BCF provides border control between two IMS networks, or between IMS and non-IMS SIP networks. 
User Control

16. Basic Differences Between VoLTE and VoWiFi During Call Procedures
LO 306
We will now examine the differences between the Voice over LTE call procedure and Voice over WiFi call procedures.

17. Basic Differences between VoLTE and VoWiFi during Call Procedures
Voice over LTE
IMS
LTE UE A party
eNodeB
SGW
PGW
Voice over WiFi
UE A party
IMS
WiFi
TWAG/ePDG
PGW
Trusted Access
Untrusted Access
Voice over WiFi are alternative access architectures that use the existing IP Multimedia Subsystem (IMS) platform.
There are three access architectures available for Voice over WiFi. They are:
Trusted Access
Untrusted Access
Storyline: Bring in bullet list when mentioned.
Let us take a closer look at each of these access architectures to learn how they differ from Voice over LTE access.

18. Voice over WiFi – Trusted Access
Voice over LTE
IMS
LTE UE A party
eNodeB
SGW
PGW
S1-U S5
Voice over WiFi
UE A party
IMS
WiFi
TWAG
PGW
S2a
As we know in a Voice over LTE call the User Equipment (UE) connects to the network via the eNodeB, Serving Gateway (SGW), and Packet Data Network Gateway (PGW) using the S1-U and S5 interfaces.
In a trusted WiFi access the UE connects to the network via WiFi and a Trusted Wireless Access Gateway (TWAG). The TWAG uses the S2a interface to connect to the serving PGW.
Storyline: Bring in interfaces and NEs when mentioned.

19. Voice over WiFi – Untrusted Access
Voice over LTE
IMS
LTE UE A party
eNodeB
SGW
PGW
S1-U S5
Voice over WiFi
UE A party
IMS
WiFi
ePDG
PGW
IPSec
S2b
Here we can see that an Untrusted Access to WiFi creates an IPSec tunnel to connect to an evolved Packet Data Gateway (ePDG) toward the serving Packet Data Network Gateway (PGW) via available Wi-Fi access point. The ePDG connects to the serving PGW using the S2b interface. In Nokia's Voice over WiFi solution the S2b interface is based on GPRS Tunneling Protocol (GTP).
Storyline: Bring in interfaces and NEs when mentioned.

20. Emergency Call in VoLTE
LO 307
What does an emergency call look like with Voice over LTE? Here we will find out.

21. 5 PSAP 1 2 4 6 3 EPC IMS eUTRAN BSS/RNC IMS/MGW EATF GSM/WCDMA UE A
VoCS
SRVCC / MSS / MGCF
HLR
SRVCC handover
EPC 1
IMS
eUTRAN
MME
eNodeB
HSS
PGW
LTE UE A
SGW 2 4
E-CSCF 6
PCRF
P-CSCF
S-CSCF 3
Voice over IMS bearer path Signalling
Voice over Circuit Switch (CS)
SRVCC-related Signalling
TITLE: Emergency Call in VoLTE
Click on the numbers to learn about an emergency call in a VoLTE environment.
Storyline: The following will appear as numbered pop-ups in final output.
1 - The User Equipment (UE) and Evolved Packet Core (EPC) support emergency bearers as well as emergency attach procedures.
2 - The Proxy Call Session Control Function (P-CSCF) detects emergency calls and routes them to the Emergency CSCF (E-CSCF).
3 - The E-CSCF provides integrated the Routing Decision Function (RDF) to route emergency calls to the correct Public Safety Answering Point (PSAP) destination address based on the location of the UE.
4 - The S-CSCF supports the IMS emergency registration procedure.
5 - The Emergency Access Transfer Fucntion (EATF) supports Single Radio Voice Call Continuity (SRVCC) handover to the CS domain for emergency calls.
6 - The Policy and Charging Rules Function (PCRF) supports emergency calls and signaling including control of the default and the dedicated emergency bearers.

22. VoWiFi Emergency Call in VoLTE IMS-based Network
LO 308
Here we will explore a Voice over WiFi (VoWiFi) emergency call in a Voice over LTE IMS-based network.

23. Voice over WiFi Emergency Call - Trusted Access
Voice over LTE
IMS
LTE UE A party
eNodeB
SGW
PGW
S1-U S5
Voice over WiFi
UE A party
IMS
WiFi
TWAG
PGW
S2a
If Circuit Switched (CS) or Long Term Evolution (LTE) accesses are not available or the user equipment (UE) does not detect an emergency call attempt, the UE may try to make an emergency call via WiFi. In this case the support of emergency calls via Wi-Fi is implementation specific, because Wi-Fi emergency calls are not standardized by 3GPP or GSMA. Different types of devices with Voice over WiFi (VoWiFi) support may behave differently for emergency calls.

24. Voice over WiFi Emergency Call – Untrusted Access
PSAP
EATF 5
IMS 1 2
UE A party
CMS-8200
OpenTAS
WiFi
ePDG
PGW
S2b
IPSec 3 9 8 4
E-CSCF 10 7
P-CSCF
S-CSCF 6 11
If a UE initiates an emergency call in an Untrusted Access, it is assumed that the call behaves the same as a Voice over LTE (VoLTE) device in LTE access.
A non UE-detected emergency call is handled as a normal Voice over WiFi call until the P-CSCF, where the call can be detected as an emergency call, routed to the E-CSCF or rejected with 380 response with alternative service.
Click on the numbers to learn more about an emergency call in an Untrusted WiFi access scenario.
Storyline: Following will appear in numbered pop-ups. All number circles will be same size in final output these are placeholders only.
1 – An Emergency Attach is performed to the evolved Packet Data Gateway (ePDG). An Emergency Access Point Name (APN) is used and the default emergency bearer is established by ePDG.
2 – Emergency registration is done.
3 - The UE detects the Emergency call via an sos indication in the Request Uniform Resource Identifier (URI) and International Mobile Equipment Identity (IMEI) in Session Initiation Protocol (SIP) instance parameter of the Contact header.
4 – The P-CSCF detects an emergency call and routes the call to E-CSCF.
5 – The EATF anchors the Emergency call control plane.
6 – Lawful Interception (LI) for emergency calls is done via the P-CSCF/BGW.
7 – The PCRF creates the default and dedicated Emergency bearers to the PGW during Emergency Attach and call. During Wi-Fi LTE mobility, those bearers are switched between the ePDG and SGW.
8 – The same Emergency APN must be configured in the MME, ePDG, and UE.
9 – The UE indicates the “handover”- information in the E-UTRAN Emergency Attach.
10 – Call back as normal terminating call from Public Safety Answering Point (PSAP) by use of the mobile subscriber integrated services digital nework number (MSISDN).
11 – Because the home network control model is used in VoWiFi calls and the call cannot be routed to the PSAP in the visited network, the E-CSCF rejects the Emergency call initiated from the visited network.