Rajib Taid

Mobile Communications Systems Development


Скачать книгу

interfaces of an IMS system are shown in Figure 6.2. For more information on this reference architecture, refer to TS 23.228 [36]. The IMS was standardized for mobile communications networks and was introduced as part of the 3rd Generation Partnership Project (3GPP) Release 5 architecture to provide voice calls along with other multimedia services.

      The main network elements of an IMS is the call session control function (CSCF) and the media gateway control function (MGCF). As shown in Figure 6.2, the CSCF performs several roles: Proxy CSCF, Interrogating CSCF, and Serving CSCF.

       Proxy‐CSCF (P‐CSCF)

Schematic illustration of reference architecture of an IMS.

      Source: © 2015. 3GPP ™ TSs and TRs are the property of ARIB, ATIS, CCSA, ETSI, TSDSI, TTA and TTC who jointly own the copyright in them. © 2015, 3GPP.

       Interrogating CSCF (I‐CSCF)

      I‐CSCF contacts the Home Subscriber Server (HSS), and based on the response from the HSS, it forwards the call to the S‐CSCF.

       Serving CSCF (S‐CSCF)

      The S‐CSCF handles the registration of UEs, maintains sessions, and performs routing functions.

       MGCF

      The MGCF interconnects the IMS with PSTN or CS domain network element. For a mobile‐terminated (MT) call, the MGCF contacts the I‐CSCF. For more information on the above CSCFs, refer to TS 23.228 [36].

      The signaling protocol that is used to exchange information between a UE and the IMS is known as the Session Initiation Protocol (SIP) which uses the IP transport network. IMS uses the SIP messages to perform various functions and procedures such as registration, call establishments and release, session management, authentication, security, and charging. Though the SIP messages exchanged between a UE and the IMS are signaling/control plane information in nature with respect to the IMS, they are treated as user plane data by the E‐UTRAN and its core network. The real‐time voice packets are transferred through other protocols called Real‐Time Transport Protocol (RTP) andRTP Control Protocol (RTCP). For more information on the IMS, the reader is recommended to refer to TS 23.228 [36].

      6.2.1.2 UE Registration and Authentication

      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

       UE Registration with IMS through Authentication

Schematic illustration of allocation of default bearer with QCI = 5 for IMS signaling. Schematic illustration of 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

      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 partys 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