VoLTE S1 Handover preparation (1/3)

While UE crosses the border towards the neighborhood cell, the source eNB determines whether there needs a handover based on the received measurement report from the UE. When there is no established X2 connection with the target eNB, the source eNB determines to perform S1 handover. In this post, the handover preparation phase will be addressed. The handover preparation procedure includes the determination of handover by the eNB, handover request by the MME, the allocation of required resources and establishing the indirect data forwarding tunnels among NEs.

I. Indirect Data Forwarding Tunnel

S1 handover is different from the X2 handover in that the media is anchored by the SGW under the control of MME rather than by eNB. During the S1 handover, a temporary indirect data forwarding tunnel is established between two eNBs via the common SGW. All the media arriving at the source eNB while S1 handover is in progress, which can be uplink data from UE side or the downlink data from the network side, will be re-directed to the target eNB through this indirect data forwarding tunnel and buffered at the target eNB. When the S1 handover is completed, the buffered media at the target eNB is transferred to the UE. The following diagram shows Indirect Data Forwarding Tunnel established between the source eNB and target eNB anchored by the common SGW during S1 handover procedure.

Figure 1. Indirect Data Forwarding Tunnel in S1 handover

II. S1 handover preparation

As a precondition of this practice, the UE has PDN connections with the internet APN and IMS APN and there are three EPS bearers established in total with EPS bearer ID of ‘5’, ‘6’ and ‘7’ and the relocation of SGW/PGW does not occur. The S1 handover procedure is triggered by the source eNB. The MME controls establishing the Indirect Data Forwarding Tunnel by intermediating required data between two eNBs like Bearer Context. The Bearer Context contains EPS bearer ID and their GTP-U TEIDs corresponding to each EPS bearers. The SGW anchors the media transfer between source eNB and the target eNB. As the SGW and two eNBs are involved in the media control, they allocate the required media resources, generate their own GTP-U TEIDs and establishes S1 bearer and indirect data forwarding tunnels based on the GTP-U TEID of the peer node delivered via MME.

Figure 2. S1 handover procedure - preparation

[1] The UE periodically sends a measurement report to the serving eNB. This reporting mechanism is intended for the UE to find out the best cell to communicate with the network. The measurement report may contain the list of neighbor cells, signal strength, current condition, etc.

[2] Based on the received report, the serving eNB determines whether the handover is required and if it is required, the serving eNB selects a target eNB among the list of neighbor eNBs. If there is no X2 connection with the target eNB, the source eNB performs S1 handover and sends Handover Required to the serving MME requesting to prepare for resources at the target. 

•  MME UE S1AP ID: Unique identifier of the UE association over the S1 within the MME
• eNB UE S1AP ID: Unique identifier of the UE association over the S1 within the eNB
• Handover Type: The type of triggered handover in the source side (i.e., intraLTE, LTEtoUTRAN, LTEtoGERAN, UTRANtoLTE, GERANtoLTE)
• Cause: A reason for a particular event for the S1AP. In this practice, the value “Handover Desirable for Radio Reasons” indicates that the cause is related with radio. Refer to section 9.2.1.3 Cause of [TS36.413] for the detail.
• Target ID: The target eNB for the handover. It is composed of “Global eNB ID” and “selected TAI”. The Global eNB ID is composed of PLMN ID (MCC+MNC) and macro eNB-ID identifying the specific eNB of a certain operator in a certain country. The selected TAI uniquely identifies the target Tracking Area i.e., PLMN ID + TAC, identifying a specific tracking area that is served by that eNB.
• Source to Target Transparent Container: Information elements created by the source eNB and transmitted to the target eNB, which contains the RRC related information, E-RAB information, Target Cell-ID and UE History Information as shown in the following bullets.
• RRC Container: RRC Information used by the target eNB during handover preparation including UE capability information. Refer to “HandoverPreparationInformation” in section 10.2.2 “Message definitions” of TS36.331 for the detail.
• e-RABInformationList: The list of eRAB to be handed over. The E-RAB ID identifies a radio access bearer for a particular UE, which makes the E-RAB ID unique over one S1 connection. The “dL-Forwarding-proposed” indicates that the source eNB proposes the list of E-RABs for forwarding of data. In this practice, there are three E-RABs (i.e., E-RAB ID=’5’,’6’ and ‘7’) proposed and they actually represent existing E-RABs of the source eNB. If the target eNB accepts it in the Handover Request Acknowledge, the downlink data received by the source eNB during the handover will be forwarded to the target eNB through the indirect data forwarding tunnel.
• Target Cell ID: Globally unique cell identifier. It is composed of PLMN ID and Cell ID.
• UE-HistoryInformation: The list of cells that a UE has been served by in the active state prior to the target cell.

Figure 3. Handover Required

[3] the MME initiates the procedure by sending the Handover Request to the target eNB requesting to prepare for resources for handover.

•  MME UE S1AP ID: refer to step#2.
• Handover Type: refer to step#2.
• Cause: refer to step#2.
• UE-AMBR: Aggregated maximum bit rates per UE being applicable for Non-GBR bearers.
• E-RAB to be SetupList: A list of E-RAB to be setup where each item contains E-RAB ID, Transport Layer Address, GTP-TEID and E-RAB level QoS parameters as addressed in the following bullets.
• E-RAB ID: Refer to step#2
• The Transport Layer Address : IP address of the source eNB.
• The GTP-TEID : The GTP Tunnel Endpoint Identifier of the SGW towards the source eNB. This has been known to the MME during the initial attach of the UE and used by the source eNB to maintain the S1 bearer with the SGW. Now, the MME intends to take this to the target eNB to replace the existing S1 bearer in the end.
• E-RAB Level QoS Parameters indicates the QoS to be applied to the corresponding E-RAB. It is composed of QCI and ARP. Refer to the section 9.2.1.60 “Allocation of Retention Priority” in TS36.413 for the detail.
• Source to Target Transparent Container: Information elements created by the source eNB and transmitted to the target eNB. Refer to step#2.
• UESecurityCapabilities: Supported algorithms for encryption and integrity protection in the UE.
• HandoverRestrictionList: Roaming or access restrictions for subsequent mobility action for which the eNB provides information about the target of the mobility action towards the UE.
• SecurityContext: Security related parameters to the eNB which are used to derive security keys for user plane traffic and RRC signaling messages and to generate security parameters for the current S1 handover. 

Figure 4. Handover Request

[4] The target eNB allocates all the necessary resources for the admitted E-RABs and establishes uplink S1 bearer with the SGW. The target eNB creates its own GTP TEID for S1 bearers which will be delivered to the SGW later and used by the SGW to establish the downlink S1 bearer (SGWàtarget eNB), thereby replaces that the source eNB. The uplink and downlink GTP-TEID for each admitted E-RABs are also included. These DL/UL GTP-TEIDs are used for indirect media transfer. The target eNB responds with the Handover Request Acknowledge to the MME.

• MME UE S1AP ID: refer to step#2.
• eNB UE S1AP ID: refer to step#2.
• E-RAB Admitted List: The list of E-RAB for which the target eNB admitted to establish. This is composed of E-RAB ID, GTP-TEID, UL/DL GTP-TEIDs and the Transport Layer for each Admitted Item as addressed in the following bullets.
• E-RAB ID : Refer to step#2.
• GTP-TEID indicates GTP Tunneling Endpoint Identifier of the target eNB which will replace the corresponding GTP-TEID of the source eNB in the end (i.e., downlink S1 bearer).
• The DL/UL GTP-TEIDs indicate the Tunneling Endpoint Identifiers of the target eNB for Indirect Data Forwarding Tunnels. The following diagram shows the GTP TEID for indirect data forwarding dedicated for one E-RAB.
•  Target to Source Transparent Container: Information element that is used to transparently pass radio related information from the handover target to the handover source through the MME. The Handover Command is transparently delivered to the source eNB.

  

Figure 5. Handover Request Acknowledge

[5] Upon receiving the Handover Request Acknowledge, the MME sends the Create Indirect Data Forwarding Tunnel Request to the SGW, which contains the Bearer Context for each bearer which was received at step #4 from the target eNB. The Bearer Context represents the attributes of each bearer including bearer identifier and TEIDs as below:

• EPS Bearer ID : Identifier of EPS bearer to be established.
• eNB F-TEID for DL data forwarding: GTP Tunneling Endpoint Identifier created by the target eNB for downlink data forwarding. Refer to step#4 
• eNB F-TEID for UL data forwarding: GTP Tunneling Endpoint Identifier created by the target eNB for uplink data forwarding. Refer to step#4 

  

Figure 6. Create Indirect Data Forwarding Tunnel Request

[6] Upon receiving the Create Indirect Data Forwarding Tunnel Request, the SGW establishes the Indirect Data Forwarding Tunnel towards the target eNB using the received DL/UL eNB F-TEIDs. The SGW allocates its own UL/DL F-TEID for indirect data forwarding tunnel, which is delivered to the source eNB via MME at step #7. The SGW responds to the MME with the Create Indirect Data Forwarding Tunnel Response which contains the Bearer Context of the SGW.

• Cause : Indicates if the Indirect Data Forwarding Tunnel has been created in the SGW. Refer to section 7.2.19 “Create Indirect Data Forwarding Tunnel Response” of TS29.274 for the detail.
• EPS Bearer ID : refer to step #5.
• SGW F-TEID for DL data forwarding: GTP Tunneling Endpoint Identifier created by the SGW for downlink data forwarding.
• SGW F-TEID for UL data forwarding: GTP Tunneling Endpoint Identifier created by the SGW for uplink data forwarding.

  

Figure 7. Create Indirect Data Forwarding Tunnel Response

[7] The MME sends the Handover Command to the source eNB informing that resources for handover has been prepared at the target eNB. Upon receiving the Handover Command, the source eNB establishes Indirect Data Forwarding Tunnel towards the SGW using the received E-RAB Subject to Data Forwarding List, i.e., DL/UL GTP-TEIDs for each E-RAB.

• MME UE S1AP ID: refer to step#2.
• eNB UE S1AP ID: refer to step#2.
• Handover Type: refer to step#2.
• E-RAB Subject to Data Forwarding List : The list of E-RAB items to be used for indirect data forwarding. Each E-RAB Data Forwarding Item identifies the E-RAB context of each E-RAB and it consists of E-RAB ID, DL/UL GTP-TEIDs as addressed below.
• E-RAB ID: Refer to step #2.
• DL/UL GTP-TEIDs : Tunneling End Point Identifier of the SGW created and delivered at step #6 for the Indirect Data Forwarding Tunnel.
• Target To Source Transparent Container: Radio related information transparently delivered to the source eNB through the MME. It was created by the target eNB and sent to the MME at step #4.

Figure 8. Handover Command

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

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

VoLTE: Bearer binding and Session binding

The LTE supports the PCC(Policy and Charging Control) architecture for QoS control applied to service data flow. In the PCC architecture, the PCRF(Policy and Charging Rules Function) takes the role of a central network component interacting with P-CSCF, SPR(Subscription Profile Repository) and the EPC. The PCRF is always involved in the activities of EPS bearer creation by generating the PCC(Policy and Charging Control) rules and provisioning them to PDN GW(i.e., PCEF). In order to generate PCC rules, the PCRF needs to gather service data flow information from the P-CSCF and possibly the subscription information from the SPR. As the PCC rule shall be applied from the access network to the EPC core with consistency, the PCRF needs to be able to maintain the relations of different sessions over different interfaces across the IP-CAN, EPS bearer and applications, in which the binding mechanism becomes a basic concept.

NOTE In this article, it is assumed that the S5 between the SGW(Serving GW) and PGW(PDN GW) is using GTP, where the PGW becomes the end point of the GTP tunnel.


I. Session binding

The session binding is an association of the AF session information to one and only one IP-CAN session [TS23.203]. Th AF(Application Focus) session is defined as a service level session such as IMS service session that is established by the application level signaling protocol offered by the AF that requires a session-setup with explicit session description before the use of the service[TS29.214].

The IP-CAN session information is obtained by the PCRF during the UE initial attach procedure.
When the UE performs the initial attach to the LTE network, the PGW triggers the CCR-I towards the PCRF. The CCR-I contains the IP-CAN related AVPs such as Framed-IP-Address, IP-CAN-Type, RAT-Type, Called-Station-Id, AN-GW-Address. The following is an example of CCR-I captured over Gx.

• Framed-IP-Address: The valid routable IPv4 address that is applicable for the IP Flows towards the UE at the PCEF. The PCRF shall use this address to identify the correct IP-CAN session binding[TS29.214].
• Freamed-IPv6-Prefix: A valid full IPv6 address that is applicable to an IP flow or IP flows towards the UE at the PCEF. The PCRF shall use this address to identify the correct IP-CAN session binding[RFC4005,RFC3162].
• IP-CAN-Type: Type of Connectivity Access Network in which the user is connected[TS29.212]. 
• RAT-Type: The Radio Access Technology that is currently serving the UE[TS29.212].
• Called-Station-Id: APN [TS29.212].

The service data flow information is obtained while the service session is set up. Upon UE request for VoLTE call setup, the SIP INVITE is delivered to the P-CSCF(i.e., AF) with an SDP offer. The SDP offer includes media session information such as 5-tuples(source ip address, destination ip address, source port, destination port and protocol), codec information, etc. Upon receiving the SIP INVITE, the P-CSCF interprets the received SDP contents into diameter AVPs and triggers the AAR towards the PCRF. The following shows an example of SDP contents included in the SIP INVITE.

NOTE It would be possible for the P-CSCF to trigger AAR once when the 183 Session In Progress is received(SDP answer) in order to reduce diameter traffic.

The following is an example of diameter AAR over Rx which includes the service data flow information.

• Media-Sub-Component: contains the requested bitrate and filters for the set of IP flows identified by their common Flow-Identifier[TS29.212].
• Flow-Description: defines a packet filter for an IP flow with the following information[TS29.212].
• Flow-Status: describes whether the IP flow(s) are enabled or disabled[TS29.214].
• Max-Requested-Bandwidth-UL/DL: Indicates the maximum requested bandwidth in bits per second for an uplink/downlink IP flow[TS29.214].
• RS-Bandwidth: indicates the maximum required bandwidth in bits per second for RTCP sender reports within the session component[TS29.214].
• Codec-Data: contain codec related information known at the AF[TS29.214].

Upon receiving the AAR, the PCRF binds the service data flow information received from the P-CSCF to a specific IP-CAN session received from the PGW.


II. Bearer Binding

The bearer binding is the association of the PCC rule and the QoS rule (if applicable) to an IP-CAN bearer within that IP-CAN[TS23.203]. Upon user's request for voice call, the SIP signals will flow through the EPS bearer of QCI=5 and there will be additional EPS bearer newly established to transfer voice traffic. In the same way as described in the previous section, the PCC rules are generated and provisioned to the PGW by the PCRF. The PGW enforces PCC rules accordingly by performing gating control over service data flow.

The PCC rule contains various parameters that can be used to control service data flow such as Flow-Information, Flow-Status, QoS, etc. The following snapshot shows an example of PCC rule contained in the diameter RAR over Gx for voice traffic.

Upon receiving the RAR, the PGW triggers the EPS bearer creation procedure by sending the Create Bearer Request to the MME. The Create Bearer Request contains the TEID for GTP-U created by the PGW and QoS parameters(QCI, MBR, GMBR) as well. In return, the corresponding response from the MME, Create Bearer Response, contains the allocated EBI(EPS Bearer ID) and the TEID for GTP-U created by the eNB. As an end point of the GTP Tunnel, the PGW shall maintain the relations between EPS bearers and PCC rules. The following is an example of Create Bearer Response captured over GTPv2.

***

The session binding and the bearer binding are basic concepts to understand how different type of sessions are related with each other over different interfaces within the PCC architecture. The IP-CAN session to which the UE is attached is bound with the AF session by the PCRF and the service data flow for that AF session is used to generate the PCC rules. These PCC rules are used to map the specific service data flow to a certain EPS bearer which belongs to that IP-CAN session.

Thanks to this binding relations, one event at one place makes a ripple effect to the other, thereby the LTE core can maintain the consistent status for the same UE. If the UE releases an AF session, the corresponding PCC rules for the service data flow belonging to that AF session are removed and in turn, the EPS bearer for that PCC rules will also be released. If the UE detaches from the network, the IP-CAN session will be released and in turn, all the AF session and EPS bearers belonging to the same IP-CAN will also be released.

Red Mouse

VoLTE: Understanding of GTP TEID to use in LTE trouble shooting

The GTP(GPRS Tunneling Protocol) is a communication protocol used by the LTE to deliver IP packets within the EPC. The GTP-C is used to deliver the controlling signals over S11 and S5, whereas the GTP-U is used to deliver application payload over S1 and S5. 

I. TEID exchanges

The TEID(Tunnel Endpoint IDentifier) is generated by each node during the initial attach procedure. The Create Session Request includes the S11 MME DL TEID and the S5 SGW DL TEID, which are generated and included by MME and Serving GW respectively. The Create Session Response includes the S5 PGW UL TEID and the S11 SGW UL TEID, which are generated and included by PGW and Serving GW respectively.

The following diagram shows the actual call flow and depicts how the TEID is exchanged between NEs. Upon receiving the Create Session Request, the Serving GW establishes the downlink GTP-C tunnel towards the MME using the received S11 MME DL TEID. In the same way the MME establishes the uplink GTP-C tunnel towards the Serving GW using the received S11 SGW UL TEID. The TEID for GTP-U is included in the body of bearer related messages (e.g., Create Bearer Request/Response, Modify Bearer Request/Response). 

The newly generated TEID is included in the body of each sending message and delivered to the peer node. The peer node perceives the end point of the GTP based on the received TEID. When the message goes through the existing GTP tunnel, the TEID of the peer node will be included in the GTP header of the sending message. The following example shows the TEID included in the Create Session Request being sent from the MME towards the Serving GW. 

In the mean time, the following example shows the TEID included in Create Session Response, where the TEID received from the MME is used in the header and the newly generated TEID of Serving GW is included in the body.

II. TEID lifetime

The life time of the GTP-C session lasts along with the life time of the UE's IP-CAN connection. It starts when the UE attaches to network and ends when the UE detaches from the network. In case there are multiple PDNs , there is only one GTP-C session per UE. The following example shows the lifetime of the same GTP-C session, which is defined by same TEIDs. In this example, there are two Create Session Requests, each for different PDNs. Each Create Session Response is followed by the Modify Bearer Request for establishing default EPS bearers. Lastly, the Create Bearer Request is to establish dedicated EPS bearers.

The lifetime of the GTP-U depends on the attributes of the EPS bearer. The GTP-U connection associated with the default EPS bearer has the same lifetime of that of GTP-C connection, whereas the GTP-U connection associated with the dedicated EPS bearer will be dynamically created and deleted within the lifetime of IP-CAN connection.

III. TEID usage

When there are multiple EPS bearers established for the same APN and there needs to verify if  specific service data flow goes through the right EPS bearer, the TEID can be a useful tool to figure it out. The following example shows the GTP-U packet of the SIP REGISTER being sent from the UE towards the IMS Core. The TEID in the GTP header indicates "0x005b8422".

The following shows the same TEID appears in the body of a Modify Bearer Request. This Modify Bearer Request is for the EPS bearer of QCI=5.

Red Mouse

VoLTE: QCI=1 setup failure when S1 handover is in progress

In a mobile environment, by its nature, the handover may occur while the user is engaged in a VoLTE call session. The UE periodically reports measurements of various parameters to the eNB and the eNB determines whether the handover is required. Once it is determined by the eNB to trigger the handover, the eNB will decide whether to perform X2 handover or the S1 handover. When there is an existing X2AP connection towards the target eNB, the source eNB performs X2 handover. If there is no X2AP connection or the X2 handover attempt has failed for some reasons, the source eNB may trigger the S1 handover.

As to the PGW initiated bearer related requests(e.g., Create/Update/Delete Bearer request) there is no cause-id defined in the 3GPP TS29.274(r8),  Therefore, in this case, the MME may reject the request with the cause-id of reason unspecified. This cause-id will lead to the ripple effect towards the upstream forcing each node on the path to release the corresponding resources. This is shown in the following flow diagram.

Even though the handover is successful in this flow, the error cause of RESOURCE ALLOCATION FAILURE in the CCR over Gx will lead to the PCRF to send RAR(Re-Authentication Request) or ASR(Abort-Session-Request) over Rx with a cause-id of RESOURCE NOT AVAILABLE, and the process will end up with sending the 503 Service Unavailable by the P-CSCF. Upon receiving the 503 Service Unavailable, the UE releases all the resources for the call.

In a circumstance where the eNB is not optimized, the handover might occur relatively often. If this racing condition is not handled properly, the result will lead to bad user experiences for VoLTE as the rejection of the bearer related request may often lead to the VoLTE setup failure for QCI=1 bearer for voice.

In the 3GPP TS29.274(r9), the 3GPP has specified the proper cause value of "Temporarily rejected due to handover in progress" and in the 3GPP TS29.274(r11), "Temporarily rejected due to handover/TAU/RAU procedure in progress". This cause-id value is used by the MME rejecting the bearer related request when the handover results in the relocation of the Serving GW and/or MME. The PDN GW which initiated the bearer related request will be able to consider this error cause value to handle the rejection. 

The following flow shows one example of how to handle the rejected bearer related request. In this flow, the Create Bearer Request is rejected by the MME. The PDN GW may retry the Create Bearer Request based on the operator's policy. 

If there is no need of relocation of MME and/or Serving GW, the MME does not need to respond with the cause-id, rather it can perform store-and-forward way of message handling. In this case, the MME will temporarily store the message and wait for the handover to be completed and if it's done soon enough, the Create Bearer Request can be sent to the UE via the target eNB. How 'soon' is the 'soon enough' time is usually up to the operator's policy.

Red Mouse

VoLTE: End to end QoS control

The end to end QoS control is an important factor to be considered to provide a qualified service to users. It would become more so when the service is required to be provided in real time such as voice call or multimedia streaming.  If the voice call service is provided through the best-effort network where the QoS is not guaranteed, the users will experience frequent call attempt failure, call setup delay, call drop, voice cracking, etc. 

In the following are introduced several different level of QoS control methodologies for VoLTE service.

I. Separated APN for VoLTE

The UE can attach multiple PDNs at the same time and each PDN connection can have multiple EPS bearers. Each PDN connectivity has one default EPS bearer and can have multiple dedicated EPS bearers up to 11 in total. The UE is assigned with a different IP address for each APN by the P-GW during PDN connectivity procedure for each APN.

In general, the operator uses an IMS APN separately from the Internet APN. This dedicated APN for VoLTE service may have the intention to provide the quality of VoLTE service not to be affected by other non-real time service such as the internet service. The default APN is provided by the network based on subscriber profile fetched from the HSS during the initial attach procedure. 

The following diagram shows a call flow of initial attach procedure. During the initial attach procedure, the MME obtains the APN list from the HSS in the Location Update Answer message as a part of subscriber's profile. The MME determines the default APN based on the received APN list and parameters, creates the GTP-C session with the corresponding S-GW/P-GW. Once the GTP-C session is created successfully, the default APN information is delivered to the UE in the Attach Accept message. If the default APN is pre-configured in the UE, the same should also be the part of the subscriber profile stored in HSS in order to avoid the conflict which leads to the attach failure. If the default APN is not an IMS APN, the UE has to trigger additional PDN Connectivity with its APN parameter set to "IMS".

NOTE the EPS bearer creation procedure is not shown in this diagram. 

The following shows an example of the Location Update Answer message from the HSS which contains the APN list for the subscriber. Each APN-Configuration AVP under the APN-Configuration-Profile AVP contains the APN information. The Context-Identifier AVP which is one of sub AVPs of the APN-Configuration-Profile AVP is used to determine the defalut APN. Whereas, the same AVP under the Configuration-Profile AVP indicates the context identifier for respective APNs. Given this, the APN whose own Context-Identifier is matched with the upper level Context-Identifier will become the defualt APN. 

In this example, there are three APNs in total and the "IMS" APN will be selected as a default APN of which Context-Identifier(=10) has the same value as upper level Context-Identifier.

II. PCC(Policy and Charging Control) rules

When the PDN connection is established with the IMS APN, the EPC and the PCRF creates the EPS bearer of QCI=5 for IMS signaling. Since then, all the SIP signaling in VoLTE goes through this EPS bearer of QCI=5. Subsequently, when the user requests a VoLTE call setup and the media information is exchanged end to end, the EPC and the UE creates dedicated EPS bearer(e.g., QCI=1 for Voice, QCI=2 for Video, etc) to transfer media traffic. 

The PCC architecture consists of P-CSCF(i.e., AF), PCRF, P-GW(i.e., PCEF) and S-GW(i.e., BBERRF). All of these components are involved in delivering the service data flow to the right EPS bearer with the right QoS conditions. The PCC rules generated or assigned by the PCRF define the mapping relations between the QoS paramemters and the service data flows. Upon receiving a VoLTE request(i.e., SIP INVITE with SDP offer), the P-CSCF extracts the 5-tuples of media information(i.e., source ip address, destination ip address, source port, destination port, protocol), codec profile, etc. The P-CSCF interworks these service data flow information to the PCRF and the PCRF either dynamically generates the corresponding PCC rules or assigns the predefined PCC rule. The PCC rules are provisioned to the P-GW. As its logical name suggests(i.e., PCEF), the P-GW performs gating control for the uplink/downlink traffic based on the given PCC rules. After successful PCC provisioning, the P-GW initiates the dedicated EPS bearer creation via the S-GW towards the eNB. 



The following example shows the PCC rule information in the RAR(Re-Authenticate Request) over Gx. In this case, there are two Charging-Rule-Definition AVPs defined each for RTP and RTCP respectively. The Charging-Rule-Definition AVP contains various information that is required for service data control such as PCC rule name(i.e., Charging-Rule-Name AVP), 5-tuple for each direction(i.e., Flow-Information AVP), QoS parameters(i.e., QoS-Information AVP), etc. The QOS parameters includes the QCI, GBR(UL/DL), AMBR(UL/DL), ARP, etc.

• QCI(CoS Class Index): A level of QoS classified based on the required quality per service usages.
• GBR(Guaranteed Bit Rate) : The minimum bit rate to be guaranteed for the given bearer. A certain amount of bandwidth will be reserved for this bearer. The GBR bearer always takes up resources over the radio link, even if no traffic is sent.
• AMBR(Aggregated Maximum Bit Rate) : The total bit rate that is allowed to be used for all non-GBR bearers associated with a specific APN/UE.
• ARP(Allocation and Retention Priority) : Being used to indicate a priority for the allocation and retention of bearers. It’s typically used to decide whether a bearer establishment or modification can be accepted or needs to be rejected due to resource limitations..

III. DSCP(Differentiated Services Code Point) marking

The DSCP marking is an IP level QoS control for each IP packet to flow through the backhaul with a certain priority and the appropriate latency. As the IP packets from different PDN with different QCI values will be mixed inside the backhaul(e.g., VoLTE, internet), the DSCP marking at IP layer would be an important factor to be considered by switches and routers to guarantee the quality service for VoLTE. Without DSCP marking, IP packets can be delayed or dropped significantly when there is a burst of IP traffic at the same time within the IP network.

The DSCP marking shall be done by both end points of the backhaul for both uplink and downlink IP packets based on the QCI of the service traffic. The following shows a recommended DSCP mapping relations between the QCI and the DSCP values as specified in GSMA IR.34 "Inter-Service Provider IP backbone guidelines". For instance, the IP packets with QCI=1 and 2 for voice and video respectively is marked with the 2E, whereas the IP packets with QCI=5 for IMS signaling will be marked as 1A.

NOTE the DSCP-QCI mapping relation is a part of operator's policy. All the switches and routers aware of DSCP values needs to adjust itself to the correct behavior according to the agreed DSCP values as to handling the IP packets.

The following shows an example of DSCP marking in the IP packet. In this example, the IP packet has been used to deliver the SIP INVITE and the IPv4 packet is wrapped by the IPv6 header at P-GW/S-GW. The 6-bit DS field in this IPv6 header is set to "2e"(i.e.,the Expedited Forwarding). This is a different value from the one specified in the above case 

Red Mouse