Sunday, November 28, 2010

LTE - Indirect Tunnel during Handover

LTE is a high speed network with an assumption of always on connectivity to packet data network even when UE is moving at high speeds. So during the handovers it is assumed there is no packet loss. But when UE is moving from source network to target network, there is definitely a connection break and make. While the connection is broken and again made at target network, the data to UE is buffered at the source eNB and forwarded to target eNB once the handover is complete. If there is a direct link between source and target eNB then data buffered at the source eNB will sent over it to target eNB. Else indirect tunnel will be used . Below figure shows S1 Handover with SGW Relocation when Indirect Tunnel is used.
 
LTE_S1_Handover.jpg
 This post specifically concentrates on how the buffered data will flow in case of indirect tunnel. Cristina in her blog has very clearly written about this, but I would like to make rather simple explanation


The links in “orange” are normal links and links in “black” form a indirect tunnel. The source eNB decides whether direct tunnel is present or not. If direct tunnel is not present, source eNB SHALL NOT include “Direct Path Forwarding Availability” IE in Handover Required message. To make things a bit simple I am assuming that MME has NOT been re-located, but considered that SGW is relocated. Once MME receives the “Handover Required” message it sees that target eNB is being served by another SGW. So MME will create a new session with target SGW and sends “Handover Request” message to target eNB. Target eNB shall respond with “Handover Request Success” and includes “indirect tunnel DL TEID” that is to be used by target SGW for indirect tunnel, along with normal S1-U DL TEID.  Once MME receives this message it shall forward “indirect tunnel DL TEID” to target SGW in “Create Indirect Tunnel Request message”. Now the target SGW gets to know the TEID which it should use for sending data over indirect tunnel and also gets ready to receive the data from source SGW. In Create Indirect Tunnel Response target SGW sends the “DL TEID” that source SGW should use to send data over indirect tunnel towards target SGW. This information is conveyed to source SGW by MME in “Create Indirect tunnel Request”. Now source SGW gets to know that indirect tunnel is created, so it sends a “UL TEID” that source eNB should use to buffered data over indirect tunnel to it. This TEID is sent to source eNB in handover command. This completes the indirect tunnel.

The data flow will be:-
- Source eNB buffered packets to Source SGW over UL TEID that source SGW sent.
- Source SGW sends packets to target SGW over DL TEID that target SGW has sent to MME, which was forwarded to source SGW.
- Target SGW sends packets to target eNB over DL TEID that target eNB has been sent to MME which was sent to target SGW.
 
I know this is bit confusing, but here it is.

9 comments:

Kirill said...

Thanks for the topic, Santosh! What is the purpose of UL forwarding and why is it optional (IE in "Create Indirect Data Forwarding" request is optional)?
As far as I understand, the idea behind these tunnels stuff is that we force the traffic left on source eNB to appear "magically" on target eNB.
So why DL is mandatory, while UL is optional?

Santosh Dornal said...

Hi Krill

I know what you are referring too. I dont understand the UL TEID in Indirect Tunnel too. But DL TEID is required because SGW should know the TEID using which it should send the data to eNB in indirect tunnel.

Thanks, Santosh

Kirill said...

Yes, DL indirect forwarding is clear. UL is also somewhat sensible. What surprises me is that UL forwarding is optional, while it should be mandatory if we don't want to get a missequencing.
If a UL message from target eNB arrives on SGW earlier than all messages from eNB, then we definitely get a mis-sequence. To avoid this UL forwarding may have been used.
May be, UL forwarding is optional because the volume of DL traffic is considerably larger than of UL, thus UL traffic is not important and this issue is left for implementors.

Manish Panchmatia said...

Hi Krill,

Yes, UL forwarding is required.

However, as per my knowledge, UL user packets can come to S-GW, even before modify bearer request from MME. (This is true for normal scenario, without handoff) The S-GW should handle them, buffer them. The S-GW will come to know about UE origin for this UL packets, once it receives modify bearer request from S-GW. The modify bearer request contains F-TEID for U-Plane.

Regards
Manish

Santosh Dornal said...

But the UL TEID is sent to eNB in Handover Request message. Why is the UL TEID required in indirect tunnel? eNB should not send the UE UL data through indirect tunnel even if the handover is not complete.

Kirill said...

Well, Santosh, according to many sequences in 23.401 and as far as I can tell, eNodeB will continue sending UL traffic until Release Resources. And UL-TEID will help SGW know that these messages need to be sent via indirect tunnel (or simply buffer them if there is no SGW relocation).

Manish is perfectly correct except that UL TEID are optional in Create Indirect Data Forwarding Tunnel Request (see 23.401, v.10.0.0, clause) 7.2.18

Santosh Dornal said...

What I meant was with Handover Request message target eNB will get to know the UL TEID of target SGW which is for the S1-U path. t.eNB should use this TEID to send any data towards SGW,but not the UL TEID from Indirect tunnel.

Also another point I want to make is TEIDs are negotiated. That is SGW sends it TEID to eNB and vice versa. But in Indirect tunnel case eNB is sending both UL and DL TEID to SGW. This is confusing.

Unknown said...

Thx for the great sharing.
but one question:
from the Spec.23.401-5.5.2.1.3-Step 11,

"it deletes the EPS bearer resources by sending Delete Session
Request (Cause, Operation Indication) messages to the Source Serving GW. The operation indication flag is not
set, that indicates to the Source Serving GW that the Source Serving GW shall not initiate a delete procedure towards the PDN GW."

So that, the GTP-C is still between Source SGW and PGW , and GTP-U is at Target SGW and PGW, right?
when the UE is deAtach in the U-TRAN, the SGSN will send Delete Bearer Req to Source SGW and Target SGW, one is inform Source SGW to release the resource of Control plane with PGW, another one is to release the resouce of control plane with SGW , right?

Sagar Sindwani said...

As per my understanding, target eNodeB send both UL and DL Transport address and TEID to source eNodeB only for the forwarding data that is buffered UL and DL data in source eNodeB.The above is send in Handover request acknowledgement to MME and by MME to source eNodeB.

In handover require Source eNodeB send UL TEID of S-GW to target eNodeB via. MME because when UE camped on to target eNodeB after that target eNodeB send path switch request to MME and after bearer modification MME will send path switch acknowledgement. Between this path switch request and acknowledgement UE uplink data data is send on that UL TEID provided by source eNodeB. And DL data on DL TEID provided by target eNodeB to MME( than to S-GW ) in path switch request message.



Correct me if I am wrong.......
Thanxx