VoLTE S1 handover completion (3/3)

After the UE confirms the completion of the S1 handover in a new cell, the target eNB initiates the completion procedure by sending towards the network. The completion procedure involves the SGW and PGW replacing the downlink S1 bearer from the source eNB to the source eNB releasing the UE associated resources and lastly, the release of Indirect Forwarding Tunnels by the SGW.

Figure 1. S1 handover procedure - complete

[12] The target eNB sends the Handover Notify to the MME notifying that the UE has been identified in the target cell and S1 handover has been completed.

• E-UTRAN CGI: globally identifies a cell and composed of PLMN identity and Cell identity.
• TAI: uniquely identify a Tracking Area and composed of PLMN identity and TAC (Tracking Area Code). 

Figure 2. Handover Notify

[13] The MME sends the Modify Bearer Request to the SGW requesting to switch the media path from the source eNB to the target eNB. The switch of media path from the SGW is done by updating the S1 bearer tunneling end point.

• Indication: includes various application flags. Refer to section 7.2.7 “Modify Bearer Request” in [TS 29.274].
• Bearer Context: identifies the bearer to be modified. It is composed of EPS Bearer ID and S1 eNB F-TEID sub elements.

In this practice, there are three bearers, i.e., bearer id = 5,6,7. The bearer 5 and 6 belongs to the internet APN, meanwhile the bearer 7 belongs to the IMS APN. The MME sends multiple Modify Bearer Request for each APN.

Note that in the following message, the value of F-TEID is set to 0x018088ed. This value is the one that was sent by the target eNB in step [4] Handover Request Acknowledge where it represents the tunneling end point of the target eNB for the downlink S1 bearer. Now, the MME deliver this value to the S-GW so the S-GW can use this value as a new target end point for the media path. As such, the downlink media path on S1 bearer is switched from the source eNB to the target eNB.

Figure 3. Modify Bearer Request for bearer 7

The following message shows the Modify Bearer Request for the bearer 5 and 6. In the same as described in the above, the value of F-TEID is set to 0x018008ed and 0x018048ed for bearer 5 and 6, respective. They are the same values as were sent by the target eNB in step [4] Handover Request Acknowledge where they represent tunneling end points of the target eNB for the downlink S1 bearer.

Figure 4. Modify Bearer Request for bearer 5 and 6

Note that the Modify Bearer Request is also sent by the SGW to the PGW which is not depicted here. The SGW and PGW are logically separated but in many cases, they are deployed on the same platform.

[14] The Modify Bearer Response sent from the PGW to the SGW and from the SGW to the MME.

• Cause: indicates the result of modifying the requested bearer.
• Bearer Context: identifies the bearer that has been modified. It is composed of EPS Bearer ID, Cause and S1 eNB F-TEID sub elements.

Note that in the following message, the value of F-TEID is set to 0x005b8422. This value is the one that was sent by the MME to the target eNB in step [3] Handover Request where it represents the tunneling end point of the SGW for the uplink S1 bearer. The tunneling end point values of SGW is created when the UE attaches the network at the very beginning. Upon S1 handover, the MME sends this value to the target eNB and the target eNB establishes uplink S1 bearer to the SGW using this value. At this moment, the source eNB also has uplink S1 bearer connection with the SGW with the same tunneling end points. As both source eNB and target eNB can send traffic to the SGW, there is no change that the data sent by the UE gets lost during handover procedure.

Now, the SGW sends this TEID to the MME for the downlink S1 bearer informing the tunneling end point for the downlink S1 bearer.

Figure 5. Modify Bearer Response for bearer 7

The same principal is applied to the following message which is for bearer 5 and 6.

Figure 6. Modify Bearer Response for bearer 5 and 6

[15] The MME requests the release of UE-associated S1 logical connections over S1 interface by sending UE Context Release Command. The source eNB releases its resources related to the given UE.

• UE S1AP ID Pair: contains the UE S1AP identifiers. It is composed of MME UE S1AP ID and eNB UE S1AP ID
• Cause: indicates the reason for this command. Refer to section 9.2.1.3 “Cause” in TS36.413 for the detail.

Figure 7. UE Context Release Command

[16] The source eNB confirms the release of UE-associated S1 logical connections over S1 interface by sending UE Context Release Complete.

• MME UE S1AP ID: uniquely identifies the UE association with the S1 interface within the MME.
• eNB UE S1AP ID: uniquely identifies the UE association with the S1 interface within the eNB.

Figure 8. UE Context Release Complete

[17] The MME requests the SGW to delete the Indirect Forwarding Tunnels by sending Delete Indirect Data Forwarding Tunnel Request.

Figure 9. Delete Indirect Data Forwarding Tunnel Request

[18] The SGW responds with Delete Indirect Data Forwarding Tunnel Response to the MME.

Figure 10. Delete Indirect Data Forwarding Tunnel Response

Red Mouse

REFERENCES

[1] 3GPP TS23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”, v12.4.0, Mar 2014

[2] 3GPP TS29.274, “Evolved General Packet Radion Service (GPRS) Tunneling Protocol for Control Plane (GTPv2-C); Stage3”, v13.2.0, Jun 2015

[3] 3GPP TS36.411, "Evolved Universal Terrestrial Radio Access (E-UTRA); S1 Application Protocol (S1AP)", v13.0.0, Jun 2015

VoLTE S1 handover execution (2/3)

S1 handover preparation procedure includes the decision of S1 handover by the source eNB, allocation of network resources to establish Indirect Data Forwarding Tunnel among two eNBs and common S-GW and establishment of uplink S1 bearer from the target eNB to the S-GW. Once the S1 handover preparation procedure is completed, the MME initiates the S1 handover by sending Handover Command to the UE via the source eNB. The UE executes the handover by detaching from the source eNB and attaching to the target eNB. Meanwhile, the downlink data is forwarded to the target eNB and buffered while the UE handover is in progress. Lastly, the UE informs the target eNB of the fact that the handover has been successfully completed and thereafter, the buffered data and downlink data is forwarded the UE through the target eNB. 

Figure 1. S1 handover procedure - execution

[8] The Handover Command received from the MME is wrapped by the source eNB within the RRC Connection Reconfiguration and sent to the UE. The RRC Connection Reconfiguration is the message to perform logical, transport and physical channel configurations. In this case, it is used to send NAS signaling to the UE to reduce the latency. Upon receiving the Handover Command, the UE detaches from the source eNB and performs handover to the target eNB.

[9] The source eNB stops assigning PDCP-SNs to downlink packets and sends the eNB Status Transfer to the target eNB via MME that contains uplink and downlink PDCP-SN and HFN (Hyper Frame Number) for each respective E-RAB. This procedure is initiated by the source eNB at the moment when it considers the transmitter/receiver status to be frozen. The use of PDCP-SN and HFN is part of overflow control mechanism for radio. The PDCP-SN is the serial number of PDCP packets increasing up to MAX-PDCN-SN. If the number reaches the MAX-PDCP-SN, the HFN is incremented by one. 

• Subject to Transfer Items: contains uplink/downlink PDCP-SN and HFN for each respective E-RAB.
• E-RAB ID: Identifies a radio access bearer for a particular UE. This value remains the same after S1-handover.
• uL-/dL-Count value: contains the PDCP-SN and HFN values
• Received Status of UL PDCP SDUs: indicates the missing and the received uplink SDUs (Service Data Units) for each bearer for which the source eNB has accepted the request from the target eNB for uplink forwarding.

  

Figure 2. eNB Status Transfer

[10] The MME forwards the received PDCP-SN and HFN information to the target eNB by sending MME Status Transfer. Upon receiving the MME Status Transfer, the target eNB does not deliver any uplink packet whose PDCP-SN is lower than the value received in the PDCP-SN in the uL-COUNT value. The target eNB uses the received PDCP-SN in the dL-COUNT value for the first downlink packet for which no PDCP-SN is assigned yet. The downlink traffic received by the source eNB is routed to the target eNB following the Indirect Data Forwarding Tunnel.

[11] After the UE successfully synchronized with the target cell, it sends a Handover Confirm to the target eNB. The Handover Confirm is contained in the RRC Connection Reconfiguration Complete message on RRC. Please note that, at this moment, there is no direct S1 bearer established yet between S-GW and the target eNB. Therefore, the downlink data is sent to the source eNB and forwarded to the target eNB following the Indirect Data Forwarding Tunnel. The uplink data from the UE will be forwarded to the S-GW following the direct S1 interface.

Red Mouse

REFERENCES

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

[2] 3GPP TS23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”, v12.4.0, Mar 2014

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

[4] Blog, “How LTE Stuff Works?: RRC Connection Reconfiguration”, Oct 2011

Bearer level event and VoLTE call setup failure

The application layer needs to be aware of bearer level status as the EPS bearer is tightly coupled with the application session and some events in an EPS bearer can affect the application session handling and resource management. For instance, when the VoLTE call session is about to be established, the IMS core establishes the logical connection with the UE. Meanwhile, the EPS will prepare for the EPS bearer through which signaling and payload will flow. If the EPS bearer is disconnected somehow (e.g., due to connection loss, user inactivity), the IMS core needs to be informed of it so the corresponding application session shall be handled accordingly. The PCC architecture handles the binding relations between the application session, PCC rules and the EPS bearers as is described in "Bearer binding and Session binding".

The following diagram shows the Policy and Charging Control (PCC) architecture that controls the EPS bearer related QoS policies and is used to request the bearer level event reporting and deliver the bearer events to application layer.

Fig 1. PCC architecture

[1] Upon receiving the request for voice call (i.e., SIP INVITE), the P-CSCF triggers the Authentication-and-Authorization Request (AAR) towards the PCRF containing the service information like source/destination ip addresses and ports, codec information, etc. The AAR also accommodates the list of events that the P-CSCF wants to be informed of.

[2-3] The PCRF generates the PCC rule for this application session and sends Re-Authorization Request (RAR) which contains the PCC rules.

[4] The EPC binds the received PCC rules and the EPS bearers so it can map the IP flow to the corresponding EPS bearer.

[5] When there is an event occurred that corresponds one of events listed in the received parameters, the P-GW reports the event to the PCRF by sending the Credit-Control Request (CCR) towards the PCRF.

[6] The PCRF unbinds the AF session from the IP-CAN and sends the Re-Authentication Request (RAR) or the Abort-Session Request (ASR) to the P-CSCF reporting the occurred event. Upon receiving the RAR or ASR, the P-CSCF may release or update the application session by sending appropriate error response to end points.

NOTE Refer to procedures described in "Voice Call Setup" and "dedicated EPS bearer creation" for the detail.

The following flow shows the voice call setup procedure where the voice session is about to establish but fails due to the error event occurred in the EPS bearer.

NOTE The step #1 to step #8 follows the normal procedure for VoLTE call setup as described in "dedicated EPS bearer creation".

[1-2] While VoLTE call setup procedure, the P-CSCF receives the SIP INVITE and 183 Session In Progress with SDP offer and SDP answer, respectively.

[3] The P-CSCF triggers the binding procedure by sending AAR towards the PCRF. The AAR includes the list of events that it wants to be informed of.

[4-6] The PCRF sends the PCC rule to the SGW/PGW so it can enforce the rule for the incoming IP flow. The SGW/PGW binds the received PCC rules with an EPS bearer and responds with the RAA towards the PCRF and in turn, the PCRF responds with the AAA towards the P-CSCF.

[7-8] The SGW/PGW initiates the EPS bearer creation procedure by sending the Create Bearer Request towards the MME. The MME request to activate the EPS bearer by sending Activate EPS bearer context request towards the eNB. The E-RAB Setup request over S1AP interface which delivers the NAS message to the eNB includes the list of E-RAB to be setup.

[9] Upon receiving the AAA from the PCRF, the P-CSCF proceeds the call setup procedure by sending the 183 Session In Progress which contains the SDP answer.

[10] In this example, the eNB responds with the error response with its cause value set to "multiple-E-RAB-ID-instances" which is the case when the eNB receives the same E-RAB ID as the one that already does exist.

Skimming over the trace history on S1AP interface, there was an attempt to delete the E-RAB but failed due to a problem in a radio interface, which is followed by X2 handover several times. It is suspected that the MME might have deleted the E-RAB ID anyway without considering the failure response and later on, re-assigned the same value for E-RAB in the E-RAB Setup Request while the eNB is still maintaining the value as the E-RAB release procedure has failed.

[11] The MME rejects the request for bearer creation by sending the Create Bearer Response to the SGW/PGW with its cause value set to "No resource available".

[12] The MME also initiates the E-RAB release procedure for the concerned E-RAB ID.

[13] Meanwhile, the SGW/PGW may internally revoke the bearer binding and informs the bearer event to the PCRF by sending CCR with its Charging-Rule-Report AVP set to RESOURCE_ALLOCATION_FAILURE.

[14] The PCRF informs the P_CSCF of the received bearer event by sending ASR with its Abort-cause AVP set to BEARER_RELEASED in this example. The ASR is sent when all the service data flows regarding the AF session are deleted. Otherwise, the PCRF would send RAR.

[15-16] The P-CSCF responds with the ASA and the PCRF with CCA.

[17, 21] Upon receiving the event report indicating the bearer release, the P-CSCF abort the call processing by sending the 503 Service Unavailable. The UE responds with the SIP ACK and releases all the resources regarding this application session.

[18-19] The P-CSCF sends the Session-Termination-Request towards the PCRF indicating that the application session has been terminated.

[20] The eNB responds to the E-RAB Release Command by sending the E-RAB Release Response towards the MME.

Red Mouse

REFERENCES

[1] 3GPP TS 29.213, "Policy and Charging Control signalling flows and Quality of Services (QoS) parameter mapping", v12.3.0, Mar 2014
[2] 3GPP TS 29.214, "Policy and Charging Control over Rx reference point", v13.2.0, June 2015
[3] TS 36.413, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)", v13.0.0, June 2015

VoLTE: PDN connectivity request vs handover

The PDN connectivity procedure is to request the setup of a default EPS bearer  to a PDN[TS24.301]. The PDN can either be the default PDN or an additional PDN. When it is the default PDN, the UE establishes the default EPS bearer as a part of the process of initial attach. If it is a subsequent PDN, this procedure will establish additional default EPS bearer with that PDN. As such the UE supports multiple default EPS bearers in multiple PDNs.

When the PDN connectivity procedure does collide with the handover procedure, the EPS shall be able to handle the situation based on the principle of best effort. The MME may pause the bearer creation procedure and resume when the handover is completed or the MME shall reattempt the E-RAB setup request after the handover is completed[TS23.401].

The following is the case where the PDN connectivity procedure collides with the X2 handover.

The above is the case the PDN connectivity request is sent for the second PDN. In this example, the MME proceeds the activation of the default EPS bearer by sending the Activate default EPS bearer Context request over S1AP while the X2 handover is in progress at the eNB. The eNB rejects the E-RAB Setup request with its cause value set to "X2-handover-triggered". Upon receiving the rejection to the E-RAB Setup request, the MME shall wait until the X2 handover is completed. Once it is completed, the MME re-attempts the activation of the default EPS bearer request. The following shows the S1AP procedure where the E-RAB setup request is rejected while subsequent PDN connectivity procedure.

The same mechanism is also applied to the S1 handover case as shown below.

In this case, the MME requests activation of the default EPS bearer as a normal procedure before receiving the Handover Required while the eNB already sent the Handover Required and subsequently receives the Activate default EPS bearer Context request. If the handover is only in preparation stage, the eNB may be able to cancel the handover and continues the E-RAB setup procedure. Instead, in this example, the eNB rejects the E-RAB setup request with its cause value set to "S1 intra system handover triggered". Upon rejection, the MME hold the state until the S1 handover is completed and resumes by reattempting the activation of the default EPS bearer.

NOTE the MME may pause between the step #b and the setp #6  as it is already aware of the S1 handover in progress. However, from implementation point of view, it looks better to pause after the setp #6 as it is a common place both for S1 and X2 handover.

If the timer at MME expires and the PDN connectivity couldn't be completed, it is expected that the UE reattempts the PDN connectivity procedure. In order to request connectivity to an additional PDN, the UE shall start timer T3482 after sending PDN connectivity request and enter the state of PROCEDURE TRANSACTION PENDING[TS24.301]. The T3482 stops when the UE receives the Activate default EPS bearer Context request or if expires, the UE reattempts the PDN connectivity procedure.

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: E-RAB management vs Handover

The 3GPP TS36.413 addresses the racing condition between UE handover and the E-RAB management procedures. The UE handover occurs based on the measurement parameters sent by the UE whereas the EPS bearer creation as a part of VoLTE call setup procedure in general. When these two independent events occur at the same time, there can be a collision at eNB, as the eNB is involved in both procedures. In this collision state, the eNB has two options to take as follows:


I. Terminating the E-RAB Setup and continues the UE S1 handover

The following flow shows the eNB rejecting the E-RAB setup request and continues the handover procedure. Upon receiving the rejection to the E-RAB setup request with its cause id, e.g., "S1 intra system Handover Triggered", the MME continues the S1 handover procedure. In the meantime, the Create Bearer Request can be postponed temporarily until the handover is completed. If the Serving GW or MME is to be changed, the Create Bearer Request will be rejected with its cause id set to "Temporarily rejected due to handover" and the P-GW may retry the EPS bearer creation procedure after the S1 handover is completed(refer to http://bit.ly/1H4Z7yr for the detail).

II. Cancelling the UE handover and continues E-RAB Setup

The following shows the eNB cancels the S1 handover towards the MME and continues the EPS bearer creation procedure. Upon receiving the Handover Cancel, the MME terminates ongoing Handover Preparation procedure and release any resources associated with the handover preparation. If the eNB does not receive the Handover Cancel Ack, it is assumed that the handover is terminated successfully.

The following shows the eNB cancels the X2 handover to continue the EPS bearer creation procedure according to 3GPP TS36.423. Upon receiving the Handover Cancel, the target eNB releases any resources reserved for the concerned UE context.

III. Service impact
The eNB shall be able to handle the racing condition between two independent events(i.e., E-RAB setup request and handover) either by cancelling the handover or by rejecting the E-RAB setup request. The MME also needs to be able to handle the racing condition either by rejecting the bearer related requests with a corresponding reason (e.g., Temporarily rejected due to handover) or by possibly providing pause-and-resume mechanism itself for bearer related requests in case the handover is in progress. If the bearer related request is rejected, the PGW may realize the retry mechanism(refer to http://bit.ly/1H4Z7yr for the detail). If this type of racing condition is not handled appropriately, there could be frequent call drops or call setup failures based on eNB optimization status resulting in bad user experiences of VoLTE user.


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