Voice over LTE (VoLTE)

LTE is an all-IP mobile network core that is optimized for data transfer and to provide a broadband like data services. It was not designed to facilitate Circuit-Switched services (e.g. Telephony or SMS). Short-term solution the CSFB (circuit-switched-fallback) was developed so that LTE users can still have access to CS services. For a richer voice services (e.g. HD voice) the VoLTE solution was developed (GSMA 1R.92) and for this reason the IMS was given a new role. IMS has been around for some time but market acceptance was slow, together with LTE operators can show/use its (IMSI) true power and potential.

VoLTE Architecture

IMS architecture is access independent and can provide an all IP-based services like VoIP to any broadband user such as the LTE subscriber.

In the VoLTE architecture,

HSS provides user profile to the IMS core (Cx-Interface) and allowed services (Sh-Interface) during the UE attach and IMS registration procedure.
PCRF provides policy and charging control in IMS (similar purpose as in EPC) and determines how data flow should be treated and enforced by the P-GW (enforcement function or PCEF).
The EPS allocation of resources (e.g. reserve QoS for voice or video) is requested by IMS to PCRF (Rx-Interface). PCRF forwards the Rx-commands to PCEF using the Gx-Interface
IMS also connects to OCS (Online Charging System) via the (Ro-Interface)
For flow based charging P-GW’s enforcement function (PCEF) connects to OCS via the Gy-Interface

IMS Core

The IMS Core main components are the session and control nodes. Each control node is build for a specific or a couple of logical functions.

Main IMS Components:

P-CSCF (proxy call session control function) is the entry point for a VoLTE provisioned subscriber and serves as SIP proxy between the UE and IMS core. It also provide and maintain secured communication. In most cases the P-CSCF functionality is implemented in a (access) Session Border Controller
I-CSCF (interrogating call session control function) is obviously an interrogating node which mean it interrogates the HSS to determine the suitable S-CSCF to use during the UE registration procedure. It also used to determine where a particular UE is registered to during mobile terminating call. This function of I-CSCF can be compared to GMSC in the CS core.
S-CSCF (serving call session and control function) handles the subscriber profile obtained from HSS during registration and can invoke services that are provisioned for the user. It also provides session setup and tear-down, session control and routing functions. These functionality is similar to a VLR node from the CS Core. It also invoke iFC based applications (i.e. SSP like functionality)
TAS (Telephony Application Server) or MTAS (Multimedia Telephony Application Server) is considered as an enhancement on top of just a pure VoIP. It supports MMTEL services such as supplementary (e.g. divert), USSD, Video, etc.
MRF (Media Resource Function) whose main function is to process media streams (RTP streams) such as playing announcements/tones, collect DTMF digits, transcoding, etc. MRF is media plane that is under the control of an Application Server (AS)

Other IMS Components:

BGCF (Breakout Gateway Controller Function), the node responsible for selecting the next route for the session. Selection is based on routing configurations. In case a session needs to be routed to the circuit-switched domain (CS), it uses the BGCF using the Mi-Interface (SIP protocol) and select the appropriate IMS-MGCF. For peer IMS, BGCF selects the appropriate IBCF.
IMS-MGCF (IMS-Media Gateway Control Function), the BGCF evaluate the session where to route further. If the session needs to be routed to another CS domain.
IMS-MGW (IMS-Media Gateway), handles user plane traffic and may include transcoding.
IP-SMGW (IMS SMS Gateway), SMSC interface towards IMS and used to transport SMS traffic.
IBCF (Interconnect Border Gateway Function), border gateway node that is used to interconnect another IMS network or a non-IMS IP network and act as SIP-Proxy.

Default IMS Bearer Establishment

Before the UE IMS registration, it must first establish the default IMS bearer using the “IMS” APN.

The UE initiate a PDNConnectivityrequest using the IMS APN and forwarded to the MME
MME builds a Create Session Request (using the GTP protocol) towards the S-GW to create the IMS default bearer or VoLTE IMS Signaling.
PGW will allocate the IP address (e.g. IPv6) and initiate Credit Control Request (CCR-I) using Diameter to the PCRF. PCRF will bind the IP-address with the policy rules associated to the default bearer and in the pre-defined P-CSCF address (i.e. IP-address).
MME will send ActivateDefaultEPSBearerRequest containing the allocated IP-address, P-CSCF, etc to the UE. The request will be acknowledge by sending E-RABSetupResponse and ActivateDefaultEPSBearerAccept
MME will send Modify Bearer Request to the S-GW containing the EPS Bearer Identity, eNB address and TEID. The S-GW will acknowledge the request and downlink traffic is allowed.
MME will send NotifyRequest to HSS that includes PGW id for mobility.

IMS Registration

Once the UE establishes the IMS Signaling channel the next step is the IMS registration, it executes the procedure as defined in the 3GPP TS.23.228 (Section 5)

The UE initiates a SIP-register to the P-CSCF. The P-CSCF address was provided during the IMS bearer establishment
P-CSCF receives the SIP-register and may contact the PCRF for authorization by sending AAR (AuthenticateAuthorizationRequest) via the Rx-interface. PCRF will further consult P-GW via the Gx-interface
After successful authentication/re-authentication, P-CSCF examines the home domain name to realize the entry point to the home network (I-CSCF). The I- CSCF is determined via DNS or may be pre-configured in the P-CSCF. It also insert path header identifying the P-CSCF for routing. SIP-register is sent to I-CSCF.
I-CSCF query the HSS by sending UserAuthorizationRequest (UAR) via the Cx-Interface to obtain the S-CSCF. UAR will contain the Public Identity of the user (IMPU), Visited Network ID, Authorization type, etc. HSS will verify the if the user is allowed to register according to subscription, barring, etc. If there is no S-CSCF associated, HSS will return information related to S-CSCF capabilities allowing the I-CSCF to select the appropriate S-CSCF. Otherwise, S-CSCF will be sent in the UserAuthorizationAnswer (UAA).
I-CSCF then send the SIP-register to (selected) S-CSCF. The S-CSCF will identify that the SIP-Register is an initial IMS registration with IMS AKA related security.
The S-CSCF will initiate MultimediaAuthenticationRequest to the HSS (via the Cx/Dx-Interface) to retrieve the authentication vectors that will be used in performing IMS-AKA security. The HSS stores the S-CSCF name, associate the Public User Identity and returns the vectors the S-CSCF using MultimediaAuthenticationAnswer.
The S-CSCF will return a negative response to the UE (SIP: 401 Unauthorized) indicating that AKAv1-MD5 should be used . The P-CSCF removes the Cipher Key and Integrity Key from the 401 Unauthorized response and binds these to the Private User Identity with a set of temporary security associations for the result of the challenge. The P-CSCF then forwards the response to the UE.
The UE (upon receiving the 401 (Unauthorized)) response will extracts the RAND and AUTN parameters, calculates the RES, and derives the Cipher Key and Integrity Key from the RAND. The UE creates a temporary set of security associations based on parameters received from the P-CSCF (IPSec), and sends a new REGISTER request to the P-CSCF with a populated Authorization header containing the RES indicating that the message is integrity protected. The P-CSCF checks the temporary security associations, and verifies the security related information received from the UE. P-CSCF forwards the SIP REGISTER request to the I-CSCF with the RES included.
The I-CSCF will then issue a UserAuthorizationRequest to the HSS to retrieve the S-CSCF and forward the SIP-Register.
S-CSCF will verify if the RES received and the previously stored XRES match. S-CSCF will perform the Server Assignment Procedure by sending ServerAssignmentRequest (SAR) to the HSS to download the user profile and register the VoLTE user. S-CSCF sends 200 OK response to I-CSCF which forwards it to the P-CSCF. P-CSCF will update the temporary set of security with the newly establish security associations. Protecting the 200 OK with the security associations and sends 200 OK to the VoLTE UE. VoLTE receives the 200 OK and will replace the temporary security associations with the newly establish security associations and will be used for further messages towards the P-CSCF.
With the configured initialFIlterCriteria (iFC) within the subscriber profile, S-CSCF will send a SIP-Register message to a VoLTE AS (TAS). The TAS will use the UserDataRequest procedure to retrieve VoLTE data stored in the HSS.
Using the SIP-Subscribe message, VoLTE UE will subscribe to events in order to be notified for any status or registration changes. S-CSCF will send SIP Notify informing the active registration status.

VoLTE Call

When a VoLTE user initiate a call (Mobile Originating Call), the UE initiates a SIP-Invite that includes the SDP and QoS requirements.

The SIP-Invite request is sent to the P-CSCF that was discovered during registration procedure. Some of the parameters includes in the INVITE are the IMS Public User Identity of the Calling-Party and P-Access Network Info (PANI) or the access type of the A-Party and Request URI of the Called Party.
P-CSCF sends AuthorizationAuthenticationRequest (AAR) via the RX-interface to the PCRF. This is invoke when the UE requires pre-conditions. The AAR will contain subscription id, QoS, parameter, charging monitoring, etc. PCRF will then acknowledge and reply back with AutherizationAuthenticationAnswer (AAA).
P-CSCF forwards the INVITE to the S-CSCF. Upon receiving the INVITE, initial filter criteria (iFC) set for the user that is provided during registration is invoked. INVITE is forwarded to TAS for the supplementary services provided to the user.
P-CSCF invoke re-authentication procedure
Depending on the designed Call-Flow. TAS may invoke for example a Camel dialogue towards an Online Charging Services (OCS) for call realtime-charging and call monitoring.
TAS routes the INVITE to the S-CSCF. S-CSCF shall now determine where to route the call further based on the result of ENUM or internal routing configurations.
The called party (VoiP terminal in this example) will return an answer with SDP using the 183 Session Progress message.
183 Session Progress is forwarded to the VoLTE UE (A-party) and with the 100rel, PRACK is send and 200 OK (PRACK) is associated.
The VoLTE UE reserves the resources to reflect the SDP answer and will be confirmed by sending SIP UPDATE. The UPDATE will contain a new SDP Offer and the confirmed codec. This time pre-conditions should also be met and media streams are set active.
SIP UPDATE will be confirmed with a 200 OK (UPDATE) from the terminating side and media stream is active.
Terminating side is alerted and will send SIP 180 RINGING response towards the UE (via S-CSCSF, TAS and P-CSCF).NOTE: P-Early media is not present in the SIP 180, this mean the UE will generate local ring tone to the subscriber. No 100rel utilization because there is not SDP in the message.
Call is answered and B-party will send 200 OK to the calling Party (VoLTE User)