Rajib Taid - Mobile Communications Systems Development

In a live network of an operator, once a UE is registered and authenticated by the LTE/EPC as part of the LTE/EPS ATTACH procedure, TS 24.301 [46], a VoLTE‐capable UE is also required to register and authenticate itself with the IMS before it can start using IMS services. For these purposes, SIP signaling messages are exchanged between the UE and the IMS. Example 6.1below describes and illustrates the flow of signaling messages, starting from registration to call establishment, conversation, and its completion, for a typical VoLTE call between two mobile devices over an IMS.

Let us consider a typical VoLTE call performed between two UEs: UE1 and UE2. To enable a VoLTE call, the UEs are required to be registered with both the LTE EPC and IMS for the allocation of the necessary resources, for example, EPS bearers with required Quality of Service (QoS). Several steps are involved in a VoLTE call over the IMS as described below:

UE Registration with EPC and Allocation of Default Bearer with QoS Class Identifier (QCI) = 5

Figure 6.3below illustrates the allocation of a default bearer to each UE as part of its ATTACH procedure requested to the core network. The allocated default bearer has the QCI = 5, Priority =1, refer to TS 23.203 [33], with nonguaranteed bit rate (NGBR) that is used to exchange IMS signaling messages between the UE and IMS. The dotted lines in Figure 6.3indicate that some of the messages as part of the overall ATTACH procedure (which are exchanged between the UE and the EPC) are not shown in this figure. One such message is the Evolved Packet System Session Management (ESM) Information request, from EPC to UE, and its response, from UE to EPC. Using the ESM information response message, the UE provides the P‐CSCF ’ s Access Point Name (APN) in the case of the IMS.

UE Registration with IMS through Authentication

The UEs register with the IMS using the default bearer with QCI = 5 that was allocated during their registrations with EPC. To register with the IMS, a UE uses the SIP signaling message that is transferred as the user plane data over the LTE/EPS toward the IMS. P‐CSCF is connected with the P‐GW of the LTE/EPC. For a UE, the proxy CSCF is the entry and exit server in the IMS. A UE sends the APN of the P‐CSCF server in the SIP: REGISTER message to the IMS. The UE sends its authentication response details in the REGISTER message again to the IMS following the 401: Unauthorized request message from the IMS; see Figure 6.4.

Figure 6.3 Allocation of default bearer with QCI = 5 for IMS signaling.

Figure 6.4 Illustration: registration of UE in an IMS.

The end‐to‐end message flow for a typical registration of a UE in an IMS is ‐ UE < ‐>eNodeB<���− > S‐GW < ‐>P‐GW < ‐>P‐CSCF. Though not shown in Figure 6.4, once the P‐CSCF receives the registration request from a UE, it is further processed by the I‐CSCF, HSS, S‐CSCF server and responds with the SIP: 200 OK messages to the registered UE.

VoLTE Call over IMS

UEs that are EPC and IMS registered can establish a voice‐over IMS to facilitate a voice call between two subscribers. The SIP signaling messages flows associated with a typical VoLTE call between two UEs – UE1 and UE2 – over IMS are illustrated in Figure 6.5. Only the P‐CSFC is shown in the call flow below, though the I‐CSCF and S‐CSCF also take part in an IMS call.

In Figure 6.5, the E‐UTRAN and EPC/NAS‐related signaling messages that are exchanged with the UEs are not shown for simplicity of the flows. The INVITE method carries the calling and called party ’ s number and is used to establish a session between the two UEs. As shown in this figure, the EPS allocates a dedicated bearer with QCI = 1, Priority = 2, refer to TS 23.203 [33], with a guaranteed bit rate (GBR) over which the voice conversation takes place between the users. The establishment of a dedicated bearer for voice conversation purposes is intimated to the called UE through SIP:UPDATE method, following which it sends the SIP:RINGING status to the caller UE.

Figure 6.5 Illustration: VoLTE call between IMS registered UEs.

The IMS for VoLTE described above will be also the foundation for the voice services over the 5G system with essential extensions added, as part of the 3GPP Release 15, over some of the existing logical interfaces, such as the Rx, Sh.

The provision of a handover of an existing VoLTE call to a legacy GERAN or UTRAN system is known as the SRVCC (refer to TS 23.216 [35]) because of the single RAT capability of a UE at a given time only. Interworking through the SRVCC scenario is a bit similar to the one described in Section 6.2.1. However, there is a difference from the E‐UTRAN UE capability point of view. SRVCC interworking scenario is suitable for an LTE UE having only one radio capability at a given time. Because of this, a VoLTE call over the IMS is required to be handed over to the legacy GERAN or UTRAN system for the continuation of the IMS voice call. The interworking of network elements, with IMS, for the SRVCC feature is illustrated in Figure 6.6.

Figure 6.6 Illustration: legacy and LTE network interworking for VoLTE call HO through SRVCC.

For the SRVCC capability to be realized, a new logical interface Sv, refer to TS 29.280 [71], is defined between the

MME and the MSC server and

MME and SGSN, as shown above.

Figure 6.7further illustrates the SRVCC HO of an LTE/EPS IMS voice call made by the VoLTE user A to a PSTN user B.

In Figure 6.7, user A moved to a legacy 2G/3G coverage area. As the user moved away from the LTE coverage area and approaches a 2G/3G coverage area, the eNodeB detects a better signal level from the 2G/3G networks. UE sends the measurements reports to the eNodeB which in turn sends an SRVCC HO request to the MME. In Figure 6.7, the signaling and traffic paths are shown prior to and after the SRVCC HO. All the subsequent signaling and data communication takes place through the legacy network MSC server after the SRVCC HO is completed.

Figure 6.7 Illustration: VoLTE call HO through SRVCC feature.

How does SRVCC work?

Indication of Feature Support

An LTE UE indicates its SRVCC capability information through the class mark and network capability information sent along with the ATTACH Request message, refer to TS 24.301 [46], to the MME. MME indicates the SRVCC capability of a UE through the SRVCC operation possible IE in the INITIAL CONTEXT SETUP REQUEST MESSAGE, refer to TS 36.413 [97], to the eNodeB. MME may also request the SRVCC capability of a UE by sending the message UE Radio Capability Match Request (see Section 5.3.14 TS 23.401 [39] ) to the UE through the eNodeB. Any subsequent changes in the SRVCC capability of a UE are also updated to the HSS by the MME.