E2E VoLTE call flow : detach (UE-initiated)

The UE initiated detach procedure may occur when the UE is turned off or the UE needs to fall back from EPS services to non-EPS services or vice versa. Along with the detach procedure all the allocated resources are released and connections for signaling and bearer are disconnected.

The above figure shows the overall sequence of how the UE and the network releases related resources when the UE detaches. Upon receiving the detach request from the UE(1), the MME releases the EPS bearer context towards the S/PGW(2) and in turn, the bearer binding and the session binding is released over Gx and Rx(3,4). Apart from this procedure, the MME also releases the UE context towards the eNB(5) and the eNB releases RRC connection with the UE(6). Meanwhile, the IMS network is informed of bearer release from the PCRF and proceeds the release procedure of the SIP session(7).

I. EPS bearer release

Fig 1. Detach procedure - EPS bearer release

[1] The UE triggers the detach procedure from the LTE network by sending Detach Request towards the MME.

• Detach Type IE indicates the reason of detach procedure and where the UE is being detached from (i.e., EPS services only, non-EPS services only, both). In this example, the UE is being detached from the LTE network due to switch-off.
• EPS mobile identity IE is set to be GUTI when the UE has a valid GUTI. If the UE does not have the valid GUTI, the EPS mobile identity will be the IMSI.

The GUTI is a globally unique identifier of the UE. It is composed of the M-TMSI, PLMN-ID (MCC+MNC) and MMEI (MMEGI+MMEC). The M-TMSI is assigned by the MME when the UE attaches to the network and remain unchanged until the UE detaches from the network. The following shows the GUTI format and the sample message of Detach Request.

If it is the detach for EPS only or combined EPS/IMSI detach, the MME deactivates the EPS bearer context(s) for this UE locally and enter the state EMM-DEREGISTERED for this UE.

[2-3] The MME requests the S/PGW to delete the corresponding session by sending Delete Session Request. If there are multiple APNs that the UE was attached to, there will be multiple Delete Session Request, one for each APN. The message contains the list of EBIs to be deleted for each APN. In case of detach, all the EBIs belong to that APN shall be included.

Upon receiving the Delete Session Request, the SGW/PGW deactivates the EPS bearer context corresponding to the received EBIs of this UE. The bearer binding relation between EPS bearer and PCC rule is also released. The SGW/PGW responds with the Delete Session Response.

[4] The MME sends Detach Accept only if the Switch off parameter is not "Switch off". Otherwise, this transaction will be spared.

[5] The MME performs MME-initiated UE context release by sending UE Context Release Command to the eNB, which is to release the UE-associated logical connection. In this case, the message contains the cause value of "Detach". Upon receiving the UE Context Release Command, the eNB releases all related signaling and user data transport resources for the indicated UE by the UE S1AP ID.

[6-7] The eNB sends the RRC Connection Release to the UE. In case the RRC connection has not been released already, the RRC Connection Release will be sent as an Acknowledge Mode(AM). After releasing the RRC connection, the UE responds with the RRC Connection Release Complete.

NOTE Whether to use Acknowledge Mode (AM) or UnAcknowledge Mode(UM) is dependent on the requirements for the radio bearer such as packet loss, packet delay, etc. The basic difference between the UM and AM is that the UM would be compared with the UDP where re-transmission control is not provided, whereas the AM is more likely TCP. The detail for this technology may need to be referred to the radio expert.

[8] The eNB responds with the UE Context Release Complete to the MME and releases the S1 signaling connection. This step would be performed without necessarily waiting for the RRC Connection Release Complete from the UE. Upon receiving the UE Context Release Complete, the MME deletes any eNB related information.


II. IMS de-Registration

Once the GTP-C, S1-MME connection and the corresponding S1 bearers have been released, the network starts to release remaining resources and connections towards upstream.

Fig 2. Detach procedure - application level release

[9-10]  The PGW reports the event to the PCRF by sending Credit-Control-Request(CCR). The CCR contains the cause value set to be "TERMINATION-REQ". The "TERMINATION-REQ" is sent only when the IP-CAN session is terminated, i.e., detach. If there are multiple APNs to which the UE attaches, there will be multiple CCRs sent to the PCRF, one for each APN. The PCRF acknowledges with the Credit-Control-Answer(CCA).

[11-12] Upon receiving the CCR from the PGW containing the IP-CAN session termination event, the PCRF releases session binding relation between IP-CAN session and the corresponding AF-session and requests to release the Rx session by sending Abort Session Termination (ASR) to the P-CSCF. The message contains the Abort-cause value of "BEARER_RELEASED". The PCRF acknowledges with the Abort Session Answer (ASA).

[13] Upon receiving the CCR containing the cause value of "BEARER RELEASED", the P-CSCF performs de-registration procedure by sending the SIP REGISTER to the I-CSCF in the UE's home network with its Expires header set to zero. The P-CSCF performs a name-address resolution mechanism for P-Visited-Network-ID header to determine the address of the home network.

[14] The I-CSCF requests the registration state of the received Public User Identity to the HSS by sending the User-Authentication-Request(UAR) with its User-Authorization-Type set to "DE_REGISTRATION". The UAR contains the Public User Identity, Private User Identity, Visited Network Id, etc.

[15] The HSS determines if the user is currently registered and responds with the User-Authentication-Answer(UAA) with the corresponding S-CSCF name (i.e., Server-Name AVP). 

[16] The I-CSCF determines the address of the S-CSCF through the name-address resolution mechanism and sends the SIP REGISTER to that S-CSCF.

[17-18] Upon receiving the SIP REGISTER, the S-CSCF may trigger the 3rd-party de-Registration procedure towards the application server based on the iFC mechanism. On the other hand, the S-CSCF sends the Server-Assignment-Request(SAR) towards the HSS. In this example, the Server-Assignment-Type AVP is set to "USER_DEREGISTRATION_STORE_SERVER_NAME", which indicates that the give Public User Identity is no longer considered as registered and the HSS needs to keep the S-CSCF name after this action. 

[19-20] The 200 OK for the SIP REGISTER is sent towards the P-CSCF.

[21] The S-CSCF may send the SIP NOTIFY towards the UE to inform that the subscription has terminated. The body of the SIP NOTIFY includes the fact that the registration state has also been terminated. This SIP NOTIFY transaction is correlated with the subscription procedure that was done when the UE registered to this IMS network.

***

When it comes to IMS de-registration, it is supposed to happen before LTE attach in a normal situation and it would be a quite natural sequence considering the protocol stack. The UE shall release all the resources relating to applications before it detaches from the network. However, in this example, the UE performs LTE detach first and then the IMS Core initiates the IMS de-registration based on the bearer loss event reported from the PGW. This type of exceptional situation happens more often than not in reality. It can come from incomplete implementation of the VoLTE client in a UE or the UE might not be able to perform IMS de-registration for some reasons.

Red Mouse

REFERENCES

[1] 3GPP TS24.301, "Non-Access Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3", v12.4.0, Mar 2014
[2] 3GPP TS29.274, "3GPP Evolved Packet System (EPS); General Radio Packet Service (GPRS) Tunneling Protocol for Control Plane (GTPv2-C); Stage 3", v9.3.0, Jun 2014
[3] 3GPP TS23.401, "General Radio Packet Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", v12.4.0, Mar 2014
[4] 3GPP TS23.228, "IP Multimedia System (IMS); stage2", v11.4.0, Mar 2012
[5] 3GPP TS29.229, "Cx and Dx interfaces based on the Diameter Protocol; Protocol details", v12.6.0, Jun 2015
[6] 3GPP TS36.413, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)", v13.0.0, Jun 2015

[7] Netmanias, "EMM Procedure 2. Detach", Jan 2014

VoLTE: Service Request scenario in IDLE mode

The IDLE state is defined as the state when both RRC state (i.e., eNB and UE signaling connection state) and ECM state (i.e., NAS signaling connection state) are IDLE while the EMM state maintained by the MME is still REGISTERED. This indicates that the UE is logically attached to the LTE network but the physical connection and the corresponding resources have been released from the UE up to the SGW (i.e., DRB and S1 bearer). The UE may fall into the IDLE mode when there hasn't been any activities for a while between the UE and the LTE network or when it is regarded the UE connection is lost.

In order to transfer any data to the UE in the IDLE mode, the MME has to wake up the UE in the first place so the UE can reconnect to the network. While reconnecting to the network, the UE and the network shall recover required resources and connections over RRC, S1AP and S1 interfaces. Once the EPS bearer is recovered, the data buffered in the SGW can be transferred to the UE. The following shows the conceptual sequence of the data transfer to the UE in the IDLE mode.

Fig 1. Conceptual diagram of network initiated service request

I. Network Initiated Service Request

The following flow shows the detailed procedure of how the application payload is delivered to the UE in the IDLE mode. As a precondition, the UE stays in the IDLE mode and the payload (i.e., SIP Message) has arrived at SGW.

Fig 2. VoLTE call flow - network initiated service request 

[1] Upon receiving the data when there is no available S1 bearer at the moment as the UE is in IDLE mode, the SGW sends the Downlink Data Notification (DDN) to the MME to request for paging the UE. The DDN includes the EPS Bearer ID (EBI) stored in the EPS bearer context of the bearer on which the downlink data packet was received over S5 interface.

[2] The MME acknowledges the request by sending Downlink Data Notification Acknowledge.

[3] The MME initiates the paging procedures by sending PAGING message to each eNB that serves cells belonging to the tracking area in which UE is registered.

The following shows paging messages distributed across multiple eNBs that belong to the target TA List.

NOTE As the paging procedure itself can cause heavy traffic in the air, the MME may need to have an optimized paging scheme to minimize the side-effect. After having been awaken, the UE performs RRC connection establishment procedure with the eNB from which the paging was sent.

[4] Once the RRC connection is established, the UE requests the network to establish NAS Signaling connection, radio connection and S1 bearers by sending Service Request towards the MME. The Service Request is delivered wrapped in RRC Connection Complete and Initial UE Message on RRC and S1AP interfaces. The RRC state transits from the RRC-Idle to RRC-Connected.

[5] The MME requests to establish the E-RAB connection by sending the Initial Context Setup Request to the eNB.

• UE-AMBR indicates the maximum aggregated bit rate for non-GBR bearers for the concerned UE.
• E-RAB To Be Setup Item includes the E-RAB information for each EPS bearers to be setup. 

In this example, there are three E-RABs to be setup which is the list of non-GBR bearers. Each E-RAB information contains the E-RAB ID, ARP and the SGW GTP-U TEID.

Upon receiving the Initial Context Setup Request, the eNB executes the E-RAB configuration and creates UE context based on the received parameters. In the meantime, the MME may perform the security setup procedure with the UE for integrity protection and ciphering of signaling data.

[6-7] The eNB requests the UE to establish the DRB by sending RRC Connection Reconfiguration. Once the DRB is established successfully, the UE responds with the RRC Connection Reconfiguration Complete to the eNB.

[8] After the DRB is successfully established, the eNB responds with the Initial Context Setup Response to the MME. The ECM state transits from ECM-Idle to ECM-Connected.

• E-RAB Setup List is a list of E-RABs that has been successfully established, which contains each E-RAB ID and eNB GTP-U TEID.
• E-RAB Failed Setup List is a list of E-RABs that has failed to establish.

[9] The MME requests the SGW to resume the suspended S1 bearer by sending the Modify Bearer Request. If there were multiple APNs to which the UE was connected before falling into IDLE state, there can be multiple Modify Bearer Request sent, one for each APN.

The Bearer Context IE contains the EBI and the eNB GTP-U TEID with which the SGW will establish the S1 bearer towards the eNB. In this example, there are two EBIs one for the default EPS bearer and the other one for dedicated EPS bearer.

[10] The SGW responds with the Modify EPS bearer response containing the resulting cause value for each requested EBI. The Bearer Context IE contains the EBIs and the SGW GTP-U TEID which is the same value that was contained in the Initial Context Setup Request at step #5. 

Once the S1 bearer is recovered, the SGW starts sending buffered data towards the UE. This procedure happens seamlessly without necessarily user interaction.


II. UE Initiated Service Request
In the same way, the UE may initiate the service request procedure in the IDLE to perform the VoLTE call initiation or location update procedures in the IDLE mode.

[1-10] Same as [4-10] in the figure 2. During this procedure, the RRC connection and NAS signaling connection is re-established. The UE context is recovered in MME. The EPS bearer including DRB and the S1 bearer is also re-established.

[11-12] The UE may trigger the TAU procedure by sending Tracking Area Update (TAU) request following the criteria as defined in TS23.401. The TAU contains the UE's current Tracking Area Identifier (TAI) and the ECGI. The last visited TAI is included if the UE has a valid TAI of the last visited tracking area and used by the MME to make a good list of TAI(i.e., TAL) for the UE. The TAL is contained in the TAU Accept.

Please refer to "VoLTE: Tracking Area Update and Combined Attach" for the detail.


Once the EPS bearer is recovered, the UE is able to initiate a voice call setup procedure by sending SIP INVITE. If there is no service data flow for a while, the UE and the network may again fall into the IDLE state.

***

In order to optimize the transactions between the UE and the network, the eNB shall be optimized as to criteria based on which the UE state falls into the IDLE mode. Furthermore the MME shall also provide the optimized scheme for paging schedules considering user experiences. If the paging scheme (i.e., timer values) is too loose, it will aggravate user experiences. If it is too frequent, it will cause heavy traffic in the air.

Red Mouse

REFERENCES

[1] 3GPP TS29.274, "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Services (GPRS) Tunneling Protocol for Control Plane (GTPv2-C); stage 3", v13.0.0
[2] 3GPP TS36.413, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)", v12.3.0
[3] Netmanias, "LTE EMM and ECM States", Sep 2013

Updated: Sep 2015

VoLTE : UE initiated voice call release

When the VoLTE call session does exist, either one of users engaged in the call can release the call session by sending SIP BYE towards the IMS network in a normal case. The user's request comes to the IMS network and it makes a chain reaction from the IMS network to EPC and to the UE. The P-CSCF informs the release of the AF session (i.e., SIP session) to the PGW via the PCRF and the PGW initiates the release of allocated resources for that application. The following scenario shows the case where the user requested to end the voice call session.

[1-2] Upon request from the user, the UE sends SIP BYE towards the IMS network to release the existing SIP session.

• Call-ID header is a globally unique identifier of this SIP session. In this context, it will identify the SIP session to be released.
• Route header is a list of IP addresses of intermediary nodes which stays in the signaling path.
• P-Preferred-Identity header indicates the originating user's identity that is preferred by the user to be used.
• P-Access-Network-Info header includes the radio access technologies and cell id.

[3] The P-CSCF sends Session-Terminating-Request (STR) to inform the PCRF that the established session shall be terminated over Rx, which combines the AF session and the IP-CAN session. As a result of this procedure, the session binding between the AF session and the IP-CAN session is terminated.

[4] The PCRF requests to remove the corresponding PCC rule by sending the Re-Auth-Request (RAR) containing the Charging-Rule-Remove AVP to the PGW. In this example, there are two charging rules to be removed for RTP and RTCP as the voice media session is to be released.

[5-6] The PGW unbinds the PCC rules from the corresponding EPS bearer and responds with the Re-Auth-Answer (RAA) to the PCRF. The PCRF unbinds the AF session from the corresponding IP-CAN and responds with the Session-Termination-Answer (STA) to the P-CSCF.

[7] The PGW sends the Delete Bearer Request containing the EPS Bearer Id (EBI) towards the MME.

[8] The MME requests the eNB to deactivate the EPS bearer context by sending Deactivate EPS bearer context request, which is wrapped by the E-RAB Release Command and RRC Downlink Direct Transfer over S1AP and RRC respectively.

Upon receiving the E-RAB Release Command, the eNB releases allocated resources on Uu and S1 for the corresponding E-RAB(s).

[9-10] The eNB sends the RRC Connection Reconfiguration request to release the radio bearer. The UE releases allocated resources on Uu.

[11-12] The UE responds with the Deactivate EPS bearer Context accept to the MME and the eNB responds with the E-RAB Release Response to the MME.

[13] Upon receiving the E-RAB Release Response, the MME updates the ECM and EMM state of the UE and sends Delete Bearer Response to the SGW/PGW. The SGW/PGW releases allocated resources on S1 and S5.

Red Mouse

E2E VoLTE call setup(4/4) - dedicated EPS bearer creation

While SIP signaling is in progress in VoLTE call setup, a dedicated EPS bearer is created for voice media transfer. The dedicated EPS bearer for voice is temporary one as it lasts only during the voice media session which is different from the default EPS bearer in that the default EPS bearer is persistent until the UE is detached from the LTE. The creation of dedicated EPS bearer is triggered by the P-CSCF sending service data information (i.e., AAR) to the PCRF. Once the dedicated EPS bearer is created for voice, there comes two EPS bearer created between the UE and the IMS APN, i.e., a default EPS bearer for SIP signaling and a dedicated EPS bearer for voice media. On top of this, there can be more dedicated EPS bearers created with different PCC rules and QoS according to service types.

I. Introduction

The P-CSCF converts the media information in the SDP into the service data information and sends it to the PCRF. The PCRF performs session binding between IP-CAN session and the Application Session, generates PCC rules and provisions them to the SGW/PGW. The SGW/PGW requests to the MME the creation of dedicated EPS bearer using the received PCC rules. The SGW/PGW also performs bearer binding between PCC rules and the to-be-created IP-CAN bearer. The creation of dedicated EPS bearer procedure is composed of sequential procedures of creating uplink S1 bearer, DRB (Data Radio Bearer) and downlink S1 bearer across UE, eNB and SGW/PGW.

NOTE the S5 interface between SGW and PGW is not depicted in the following practice for simplicity.

II. Creation of a dedicated EPS bearer for voice traffic

The following scenario shows the procedure of creating a dedicated EPS bearer during VoLTE call setup.

Fig 1. dedicated EPS bearer creation

[59] The SGW/PGW generates its own GTP-U TEID and initiates the procedure to create a dedicated EPS bearer by sending Create Bearer Request (CBR) to the MME. The CBR contains Bearer Context information of the dedicated EPS bearer to be created.

• (Linked) EPS Bearer ID: Indicate the default bearer associated with the PDN connection.
• Bearer Context: a set of information for dedicated EPS bearer to be created which contains EPS Bearer ID, Bearer TFT, GTP-U TEID and Bearer QoS.
• EPS Bearer ID : a requested EPS bearer ID to be created and shall be set to '0' at this stage.
• Bearer TFT : the uplink packet filters to be sent all the way down to the UE and applied by the UE when the UE sends out RTP and RTCP packet.
• SGW GTP-U TEID : the identifier of the SGW as an end point of the GTP-U tunnel.
• Bearer QoS : QoS for this dedicated EPS bearer which includes UL/DL MBR, UL/DL GBR and QCI.

Fig 2. IEs in Create Bearer Request

[60] Upon receiving the CBR, the MME allocates the EPS bearer ID and requests the UE to activate the dedicated EPS bearer by sending Activate dedicated EPS bearer context request towards the UE. The message is delivered to the UE being contained in the E-RAB Setup request and the RRC Downlink Direct Transfer over S1AP and RRC interfaces respectively. The E-RAB Setup request contains SGW GTP-U TEID and the E-RAB level QoS parameters e.g., ARP, UL/DL MBR, UL/DL GBR, etc.

• e-RAB ID: unique identifier of the E-RAB for the UE. Please note that the E-RAB ID=’5’ was for the default EPS Beaer with the Internet APN, ‘6’ was for default EPS bearer with the IMS APN and now, it is set to be ‘7’.
• e-RAB level QoS Parameters: QoS to be applied to an E-RAB, which contains QCI, ARP, MBR and GBR of the E-RAB. This is a copy of the received Bearer level QoS at step #59.
• SGW GTP-TEID: the identifier of the SGW at the end of GTP-U tunnel.

Fig 3. IEs in E-RAB Setup Request

  

The following snapshot shows the Active dedicated EPS bearer context request contained in the Non-Access-Stratum (NAS) PDU container.

• EPS QoS: QoS of an EPS bearer context which includes QCI, MBR and GBR of the EPS bearer
• Traffic Flow Template (TFT): the uplink packet filters to be sent all the way down to the UE and applied by the UE when it sends RTP and RTCP packet.
• Linked Transaction Identifier (TI): the identifier of the active PDP context from which PDP address for the new PDP context could be derived.
• Negotiatiated QoS: QoS of a PDP context

  

Fig 4. IEs in Activate dedicated EPS bearer context request

Upon receiving the E-RAB Setup request, the eNB allocates the required resources and establishes uplink S1 bearer with the SGW as part of the E-RAB establishment.

[61-62] The eNB sends the RRC Connection Reconfiguration request to the UE. The UE modifies the radio bearer accordingly and responds with the RRC Conenction Reconfiguration Complete.

[63] The eNB responds with the the E-RAB Setup response to the MME and it contains eNB GTP-U TEID which is allocated by the eNB.

• E-RAB ID: unique identifier of the E-RAB for one UE. This value is originally assigned by the MME and if this is already occupied, the UE can change it.
• eNB GTP-U TEID: the identifier of the eNB at the end of GTP-U tunnel. The eNB newly assigns the GTP-U TEID for this dedicated EPS bearer and it is delivered to the SGW via MME.

  

Fig 5. IEs in E-RAB Setup Response

[64] The UE responds with the Activate dedicated EPS bearer context response to the MME which is wrapped in the RRC Uplink Direct Transfer and S1AP Uplink NAS Transport on RRC and S1AP interfaces respectively.

• E-UTRAN Cell Group Identifier (CGI): globally unique identifier of a cell (PLMN ID + ECI)
• Tracking Area Identifier (TAI): globally unique identifier of a tracking area [PLMN ID + TAC]

Fig 6. IEs in Activate dedicated EPS bearer context response

  

[65] The MME responds to the SGW/PGW by sending Create Bearer Response. The Create Bearer Response contains the eNB GTP-U TEID which was received at step #63. Upon receiving the Create Bearer Response, the SGW establishes downlink S1 bearer towards the eNB.

Fig 7. IEs in Create Bearer Response

II. PDN connectivity and EBI allocation

The following shows the summary of all the procedures shown in the VoLTE call setup procedures, in which steps (1) to (4) are performed at the background automatically.

(1)    UE turend on.

(2)    PDN connection with the Internet APN: the QCI of the default EPS bearer = ‘9’, EBI = ‘5’.

(3)    PDN connection with the IMS APN: the QCI of the default EPS bearer = ‘5’, EBI = ‘6’.

(4)    IMS registration through the default EPS bearer with IMS APN.

(5)    The dedicated EPS bearer creation for voice upon request for VoLTE service: the QCI of the default EPS bearer = ‘1’, EBI = ‘7’.

Fig 8. PDN connection and EBI allocation

Red Mouse

REFERENCES

[1] 3GPP TS25.331, "Radio Resource Network (RRC); Protocol specification", v12.3.0, Sep 2014

[2] 3GPP TS24.301, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage3", v12.4.0, Mar 2014

[3] 3GPP TS24.008, "Mobile radio interface Layer 3 specification; Core network protocols; Stage3", v13.4.0, Dec 2015

[4] 3GPP TS29.274, "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS); Tunneling Protocol for Control Plane (GTPv2-C); Stage3", v13.0.0, Dec 2014

[5] 3GPP TS36.331, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification", v12.3.0, Sep 2009

[6] 3GPP TS36.413, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)", v12.3.0, Sep 2014

Last updated: 1 Jan 2016

E2E VoLTE call setup(3/4) - Voice call setup

Once the IMS registration is successfully done between the UE and the IMS network, the user can make a VoLTE call. Upon request for voice call from the user, the VoLTE UE starts SIP signaling with the IMS core. The SIP messages are routed based on initial Filter Criteria (iFC) in the IMS Core and delivers SDP offer and answer to establish media session along with various SIP headers. As a consequence of the SIP signaling, a new dedicated EPS bearer is established between the UE and the SGW/PGW which is used to transfer voice media. The QoS of this new dedicated EPS bearer is defined by the PCC rules generated by the PCRF.

Introduction

While the SIP messages go through the default EPS bearer (QCI=5) towards the IMS core, the voice media path is established at the front-end NEs taking the role of IMS Application Level Gateway (IMS-ALG) and IM Access Gateway based on SDP negotiation. The following diagram shows the conceptual diagram of IMS-ALG and IMS Access Gateway model specified in 3GPP TS23.228. The IMS-ALG controls media resources and gating functions of the IM Access Gateway over Iq interface. It acts as a B2BUA and can modify the SDP and SIP headers of SIP messages if necessary. The IM Access Gateway executes the allocation and release of transport addresses, IP versioning and the media gating function under the control of the IMS-ALG.

Fig 1. IMS-ALG and IMS Access Gateway model

The following diagram shows how the media path is established. Upon request from the user for voice call setup, the UE sends VoLTE call setup request (i.e., SIP INVITE) to the IMS core with an SDP offer, which contains the allocated media information of the originating UE [A]. The IMS-ALG allocates media resource in the IM Access Gateway to which the originating VoLTE UE can access. The allocated media information at IM Access Gateway is sent back to the UE in the response as an SDP answer [a]. The IMS-ALG allocates additional media resource for the upstream, includes it in the SDP offer and sends it towards the remote IMS-ALG [B]. The IMS-ALG in the remote IMS network responds with the SDP answer containing the media access point of IM Access Gateway in the same network [b]. The IMS-ALG in the remote network also allocates another media resources and sends it to the UE as an SDP offer [C]. In turn, the UE will also send back the response including SDP answer of its own [c].

NOTE the gray arrow indicates the signaling path and the rest indicate the media path and its direction.

Fig 2. Media path establishment

NOTE The IM Access Gateway functionality is typically provided by Service Border Controller (SBC).

II. VoLTE call setup procedure

Upon request from the user for VoLTE call setup, the UE initiates SIP signaling with the IMS core. The P-CSCF address is informed to the UE when the UE attaches to the network. The signaling path beyond the P-CSCF is determined based on a routing mechanism of IMS core. The SDP negotiation is performed along with the SIP signaling and determines the media path for voice call setup.

Upon receiving call setup request (i.e., SIP INVITE), the P-CSCF informs the PCRF of the service data flow information. The PCRF triggers the Evolved Packet Core (EPC) to create a dedicated EPS bearer of QCI=1 for voice media by generating and provisioning PCC rules to the SGW/PGW. The PCC rules include QoS parameters and rules to be applied to service data flows based on which the SGW/PGW establishes mapping relations between service data flows and the EPS bearers.

NOTE Based on GSMA IR.92, the UE is strongly recommended to support the precondition framework for VoLTE. Please note that, in the following practice, the precondition procedure has been disabled before testing. Please refer to FCM.01, IR.92 and 3GPP TS 24.229 for the detail.

NOTE While the following procedure shows the only originating side, the same procedure and principles can also be applied to the terminating side. The signaling procedure handled within the IMS core has not been described to avoid complexities as it can vary based on the deployment architecture as per IMS vendor.

Fig 3. VoLTE setup call flow

[48] Upon request from the user to make a voice call, the originating UE sends the SIP INVITE towards the P-CSCF.

• Supported header: a list of option tags indicating supporting features. In this example, the "timer" and "100rel" indicate support of session timer and a reliable delivery of the provisional response (i.e., 183 Session In Progress), respectively.
• P-Early-Media header: indicator of whether the UE supports the early media mode.
• Allow header: a list of SIP methods that is supported by the UE.
• P-Preferred-Identity header: the originating user's identity that is preferred by the originating user to be used. This header is replaced with the P-Asserted-Identity header by the P-CSCF in the IMS network. If the SIP message is sent towards untrusted IMS core, the P-Asserted-Identity header shall be removed.
• User-Agent header: VoLTE client information
• Privacy header: preference of sending UE indicating that any sensitive information shall be hidden from any parties that do not need to know it.
• Accept-Contact header: a list of features of target UE preferred by the sending UE
• P-Access-Network-Info header: the radio access technology and cell identity.
• Session-Expires header: a valid period of time of this SIP INVITE session. The parameter “uac” indicates that the sending UE will refresh the session before the timer is expired.
• P-Preferred-Service header: service identification user wishes to be used. This header is replaced with the P-Asserted-Service header by the P-CSCF.
• Content-Type: media type of the message-body sent to the recipient.
• Route header: a list of IP addresses of intermediary nodes which the SIP request will go through. This would a copy of Service-Route header returned in 200 OK response to SIP REGISTER, which is inserted by the S-CSCF. The Service-Route header indicates the intermediary node associated with that S-CSCF.
• From header: sending user’s SIP URI or TEL URI
• To header: recipient’s SIP URI or TEL URI
• Call-ID header: a globally unique identifier of the SIP session. All the SIP messages of the same session must have the same Call-ID value.
• CSeq header: sequence of the same SIP method. The sequence number is incremented as the same SIP method is being sent.
• Max-Forwards header: maximum number of hops that the message can go through.
• Contact header: the contact address, device capabilities, feature-tags, etc. of the sending UE.
• Via header: a list of SIP addresses of intermediary nodes. The entry is inserted by each node that wants to stay in the signaling path for the SIP response. The response message for this request (e.g., 183 session in progress, 100 Trying, 200 OK, etc) will be transferred to the originating UE following the reverse path listed in this header.
• Content-Length: body length in bytes.

Fig 4. headers in SIP INVITE

The SIP INVITE contains an SDP offer. The SDP defines media information of the sending node which contains the contact ip address, port number and a list of supporting codec information. The following shows descriptions of each parameters used in SDP.

• ‘o’ (originator and session identifier): <username><session-id><network type><address type><ip address>
• ‘s’ (session name): any textual session name
• ‘c’ (connection data): <network type><address type><connection address>
• ‘t’ (timing): <start time><stop time>
• ‘m’ (media description): <media type><port><protocol><fmt: media format description>
• ‘b’ (bandwidth): AS (application specific) – maximum RTP session bandwidth (kbytes), RS – sending RTCP bandwidth (bytes), RR – receiving RTCP bandwidth (bytes)
• ‘a=rtpmap’ (attributes): <payload type><encoding name><clock rate><encoding parameters>
• ‘a=fmtp’(attributes): format specific parameters related with the corresponding media
• ‘a=ptime’(attributes): length of time represented by the media in a packet (ms)
• ‘a=maxptime’(attributes): maximum amount of media that can be encapsulated in each packet(ms)

The following is an SDP example included in the SIP INVITE captured on the Gm interface. The UE’s IP address is “100.64.63.41” and port number for audio is “1234”, which is depicted as [A] in Fig2.

Fig 5. Attributes in Session Description Protocol (SDP) offer

NOTE Upon receiving the SIP INVITE with an SDP offer, the P-CSCF may send service data information to the PCRF of which flow-status AVP set to ‘DISABLED’. In this case, the P-CSCF will send additional service data information when it receives the 183 Session In Progress with SDP answer. In the following example, the service data information is sent only once when the P-CSCF obtains SDP offer and answer all together at step #48.

The P-CSCF responds with a 100 Trying provisional response. The provisional response is a one-way response sent back to the originating side used as informative. It is not necessarily guaranteed for its safe arrival.

Fig 6. Parameters in 100 Trying

[49] The terminating UE locally allocates resources, generates the 183 Session In Progress along with SDP answer and sends it back towards the originating UE. The 183 Session In Progress arrives the originating S-CSCF following the reverse path of the SIP messages. The S-CSCF forwards it to the P-CSCF.

• Record-Route header: a list of IP addresses that is copied from the Route header by the terminating UE in the received SIP INVITE. The value of this header will be reused by the originating UE when it composes Route header upon sending subsequent SIP request.
• Require header: a list of option tags indicating features that needs to be supported by the recipient (i.e., the originating UE) of this message. In this case, the "100rel" indicates the originating UE shall support the reliable delivery of provisional response. 

NOTE the provisional response, 1xx, is an informative response therefore it does not usually require the reliable delivery. However, 183 Session In Progress would be an exception as it contains the SDP answer.

• RSeq header: the sequence number of this response. The value of this header is copied to the CSeq header in the following SIP PRACK sent by the originating UE.
• P-Asserted-Identity header : the authorized user's identity of the sending user of this message (i.e., the terminating user)
• P-Charging-Vector header: a collection of charging information, which consists of IMS Charging Identity (ICID) value, the address of the SIP proxy that creates the ICID value and the Inter Operator Identifiers (IOI). The ICID indicates a globally unique charging value that identifies a dialog, the IOI identifies both the originating and terminating networks involved in a SIP dialog. In the following example, the full text for the header is as follow:

icid-value=0.274.195-1418282284.647;term-ioi=32345;term-ioi=22345;icid-generated-at=10.75.0.5;term-ioi=Type3Term;orig-ioi=32345

Fig 7. Headers in 183 Session In Progress

[50] Upon receiving the 183 Session In Progress, the P-CSCF triggers the Authentication and Authorization Request (AAR) towards the PCRF to inform the fact that there is a new Application Focus (AF) session being created. The PCRF performs session binding between the AF session and the corresponding IP-CAN session.

NOTE AF indicates an element offering applications that require the Policy and Charging control of the user plane resources. In this context, it indicates the P-CSCF.

• Session-Id AVP: identifier of Rx session for this application. It lasts until this application (i.e., VoLTE session) does exist.
• AF-Application-Identifier AVP: identifier of the VoLTE call session assigned by the P-CSCF.
• Media-Component-Description AVP: media information of the service data flow
• Service-Info-Status AVP: the status of the service information that the P-CSCF is providing to the PCRF.
• FINAL SERVICE INFORMATION (0): the service has been fully negotiated between the two nodes and the provided service information is the result of the negotiation.
• PRELIMINARY SERVICE INFORMATION (1): the provided service information is a preliminary and further negotiation is to be needed between two nodes.

NOTE In this example, the value is set to be “FINAL SERVICE INFORMATION” as the P-CSCF has both SDP offer and answer.

• AF-Charging-Identifier AVP: identifier for charging correlation with bearer layer.
• Specific-Action AVP: a list of events that P-CSCF wants to be informed from the PCRF. The PCRF shall report to the P-CSCF when any of these events occurs.
• Subscription-Id AVP: identifier of the end user’s subscription. It holds subscription type and data. Multiple instances of the subscription-id indicates multiple type of identifiers of the same subscriber such as E164, SIP URI, IMSI, etc.
• Framed-IP-Address AVP: UE’s IP address which is allocated by the PGW during initial attach procedure.
• Required-Access-Info AVP: indicator of query by the P-CSCF for access network information.

Fig 8. AVPs in AAR

The Media-Component-Description AVP reflects the SDP offer and answer which includes the media type, direction and codec information.

• Media-Sub-Component AVP: descriptions for media flows. There are two sub components appears in this snapshot, one for RTP and the other one for RTCP.
• Flow-Description AVP: description for IP flow in each direction, of which IP addresses and port numbers are copied from the SDP offer and answer by the P-CSCF.
• Uplink IP flow: UE (“100.64.63,41”, “1234”) à SBC (“10.75.23.197”, “10570”)
• Downlink IP flow: SBC (“10.75.23.197”, “10570”) à UE (“100.64.63,41”, “1234”)
• Flow-Status AVP: permission status of each media flow.
• ENABLED-UPLINK (0): enable associated uplink IP flow(s) only.
• ENABLED-DOWNLINK (1): enable associated downlink IP flow(s) only.
• ENABLED (2): enable all associated IP flow(s)
• DISABLED (3): disable all associated IP flow(s)
• REMOVED (4): remove all associated IP flow(s)
• Media-Type AVP: the type of media stream e.g., audio, video, data, text, message.
• Max-Requested-Bandwidth-UL/DL AVP: the Maximum Bit Rate (MBR) of the IP flow in each direction. The bandwidth contains all the overhead coming from IP layer and the layer above e.g., IP, UDP, RTP, RTP payload.
• RS-Bandwidth AVP: maximum required bandwidth for RTCP sender reports.
• RR-Bandwidth AVP: maximum required bandwidth for RTCP receive reports.
• Codec-Data AVP: codec related information known at the P-CSCF.

Fig 9. Sub-AVPs of Media-Component-Description AVP

[51] Upon receiving the AAR, the PCRF generates PCC rules. PCC rules includes IP flow description for uplink and downlink (i.e., 5-tuple), QoS information, the flow status, etc. The SGW/PGW performs bearer binding between the received PCC rules and the corresponding IP-CAN bearer. The IP flow shall be mapped to a specific IP-CAN bearer based on these PCC rules by the SGW/PGW

• Charging-Rule-Definition AVP: A PCC rule. There are two PCC rules showing up for voice call, one for RTP and the other one for RTCP.
• Charging-Rule-Name AVP: A PCC rule name. It is uniquely defined within the same IP-CAN. If the PCC rule is pre-defined in PGW as is the case for default EPS bearer, it is uniquely defined within the PGW.
• Flow-Information AVP: a single IP flow packet filter. It includes the ip address and port number and the direction of the IP flow.
• Flow-Status AVP: permission status of each media flow. Refer to step#49 for the detail.
• QoS-Information AVP: QoS information to be applied to the IP flow, which includes QoS Class Identifier (QCI), GBR (Guaranteed Bit Rate), MBR (Maximum Bit Rate) and ARP (Allocation Retention Precedence).
• QoS-Class-Identifier AVP: QoS Class Identifier
• Guaranteed-Bitrate-UL/DL AVP: guaranteed for service data flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above e.g., IP, UDP, RTP and RTP payload.
• Max-Requested-Bandwidth-UL/DL AVP: the Maximum Bit Rate (MBR) of the IP flow in each direction. The bandwidth contains all the overhead coming from IP layer and the layer above e.g., IP, UDP, RTP, RTP payload.
• Allocation-Retention-Priority AVP: The priority of allocation and retention. When a new media resource is required to be allocated and all the resources are already occupied, the PGW can release the allocated media resource and re-allocate it for the new IP flow based on this value.
• Precedence AVP: the order of applying the service data flow template consisting of service data flow filters to the service data flow at PGW.
• Flows AVP: Indicator of the IP flow to which this PCC rule is to be applied.

Fig 10. AVPs of RAR

[52] The SGW/PGW initiates the EPS bearer creation procedure and responds with the Re-Auth-Answer (RAA) to the PCRF.

• Access-Network-Charging-Address AVP: IP address of the network entity within the access network performing charging.
• 3GPP-SGSN-MCC-MNC AVP: MCC and MNC of the access network.
• 3GPP-User-Location-Info AVP: UE’s current location. It is composed of Tracking Area Identity (TAI) and E-UTRAN Cell Global Identifier (ECGI).

Fig 11. AVPs of RAA

[53] The PCRF responds with the AAA to the P-CSCF.

Fig 12. AVPs of AAA

[54] Upon receiving the successful AAA from the PCRF, the P-CSCF continues the SIP signaling by forwarding the 183 Session In Progress towards the UE. The following snapshot shows headers of 183 Session In Progress captured on Gm interface.

• P-Early-Media header: indicator of whether the UE supports the early media mode. The early media option has been disabled in the practice.

Refer to step#47 and step#48 for the detailed description for SIP headers.

Fig 13. Headers of 183 Session In Progress

The following snapshot shows the SDP answer included in the 183 Session In Progress. The SBC is going to be a peer node from UE’s perspective. Given that, the IP address and port number represents the SBC to which the originating UE shall connect for media. The codec information represents the one supported by the SBC. Refer to step#47 for the detailed description for SDP attributes.

Fig 14. SDP answer in 183 Session In Progress

The SDP answer delivered to the originating UE shows the IP address is 10.75.23.197 and port number is 10570, which is depicted as [a] in Fig2.

[55] The UE confirms that the 183 Session In Progress with SDP answer has been received safely by sending SIP PRACK.

• RACK header: the sequence number the corresponding 183 Session In Progress and the SIP INVITE.

Refer to step#47 for the detailed description for other headers.

Fig 15. Headers in SIP PRACK

[56] The 200 OK response to the SIP PRACK is received by the UE.

Fig 16. Headers in 200 OK for PRACK

[57] The 180 Ringing provisional response is received by the UE. It indicates the voice call setup request is being notified to the recipient. Refer to step#47 and step#48 for the detailed description for headers.

NOTE If the option tag ‘100rel’ appears in the Require header, the UE shall acknowledge the provisional response by sending PRACK. If it appears in Supported header, it is just informative.

Fig 17. Headers in 180 Ringing

[58] The 200 OK response for the SIP INVITE is received by the UE. It indicates that the terminating user answered the phone. Upon receiving the response, the UE allocates the media resource. Refer to step#47 and step#48 for the detailed description for headers.

Fig 18. Headers in 200 OK for SIP INVITE

[59] The UE sends SIP ACK towards the terminating user. Refer to step#47 for the detailed description for headers.

Fig 19. Headers in SIP ACK

Red Mouse

REFERENCES

[1] 3GPP TS 23.228, "IP Multimedia System (IMS); Stage 2", v11.4.0, Mar 2012

[2] 3GPP TS 24.229, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); stage3", v11.3.0, Mar 2012

[3] 3GPP TS 24.628, "  ", v11.3.0, Mar 2012

[4] 3GPP TS 29.212, "Policy and Charging Control (PCC); Reference points", v12.6.0, Sep 2014

[5] 3GPP TS 29.214, "Policy and Charging Control over Rx reference point", v12.5.0, Sep 2014

[6] IETF RFC7315, "Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for 3GPP", July 2014

[7] IETF RFC4028, "Session Timer in the Session Initiation Protocol (SIP)", Apr 2005

[8] IETF RFC3264, "A offer and answer model with the Session Description Protocol (SDP)", Jun 2002

[9] IETF RFC3262, "Reliability of the Provisional Responses in Session Initiation Protocol (SIP)", Jun 2002

[10] IETF RFC3608, “Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration”, Oct, 2003

Last Updated: 26th Dec 2015