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.
 

 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.

Policies and Rules

With LTE ready for deployment, it is becoming increasingly important for operators to provide dedicated bearers. I had a chance to look at 3G demo, here in India, by one of the operators, and I was not pleased. There was an attempt to stream live TV over 3G supported mobile and stream was pretty bad. I was just wondering how far the base station was and if there was any secondary PDP context in place for enforcing a proper quality of service. Well that’s 3G.

In LTE PCRF is responsible for charging and triggering flow rules. PCRF is an intelligent device which based on the ongoing traffic or existing configuration triggers events towards PGW. There sits PCEF on PGW which is responsible for enforcing the rules triggered by PCRF. The interface between PCRF and PCEF is Gx.  Based on the triggers PCEF can go ahead and ask PGW to create a dedicated bearer or modify an existing bearer.  UE can request for a bearer creation or modification based on its need. But final decision is with PCEF. On other note I was wondering if LTE UE manufacturers would present any piece of code to mobile application developers for requesting a dedicated bearer for their app?

LTE is supposed to be a high speed network. Will creation of dedicated really matter at such high speeds? Will streaming video all of sudden get better once a dedicated bearer is created for it? Has any operator tested this? How does the result look?

S4 SGSN

As the LTE deployments are nearing it is becoming increasingly important to bring in smooth handover support between 3G/2G and LTE networks.  The networks are on expansion and are becoming complex. In amidst of all, different solutions for same problem is making life a bit more difficult. 

While we have a initial solution in place for migrating from 3G to LTE without changing much in the existing 3G network, it has been noticed that the service providers are now thrusting for a more smoother solution. Identifying few pockets of areas service providers are now willing to upgrade their exiting 3G network to be compliant with Release 8. I pity the SGSN for the burden it has to take to not only perform the existing functions but should also start processing LTE related calls. 

If the SGSN is migrated to Rel 8, then it has to support two new interfaces. S3 and S4. S3 is between MME and SGSN analogous to Gn interface. But S4 is totally new interface to SGSN analogous to S11 interface. The question is whether a S4 interface is needed at all. When a UE moves from 4G to 3G, SGSN requests for Context Information from MME over S3 interface. If the interface is Gn then protocol would have been GTPv1 which doest create any trouble for SGSN. As S3 is GTPv2 based, SGSN should implement the new protocol. So far so good. Anyway UE is in 3G network, SGSN has pulled the UE information from MME over S3, then what is the need for S4 interface. SGSN can as well simply go and talk to GGSN. Instead of this 3GPP has decide to route the SGSN to SGW over S4 interface. This is mainly done to remove the GGSN node as such. 

We know that LTE APNs are configured in PGW.  The idea is to reach the same APN in the PGW when UE is either connected from 4G or 3G or 2G. Which means in 3G and 2G it will become the responsibility of SGSN to talk to PGW through SGW. This will simply need no GGSN at all for LTE APNs and more over everything is Rel 8 compliant. The compliance will ensure smoother handovers and continuous data flow. So when a UE directly switches on in 3G network, SGSN will contact SGW for the establishing a session. When there is a handover involved again, SGSN will contact MME over S3 and SGW over S4. Ultimately for 4G APNs there wont be a need for GGSN and PGW to co-exist. Another important thing here will be support for IPv4IPv6 PDN types. This PDN type is not supported in 3G and is a feature of LTE. To ensure that this PDN type is supported over 3G the SGSNs should be Rel 8 compliant. 

Hence, SGSNs are overloaded. 

SDF, QCI and Dedicated bearers

I had an interesting discussion with one of my friends regarding the dedicated bearers and QCI and thought of posting the same.

SDF- Service Data Flow- An aggregate set of packet flows that matches a set of filters.
QCI – QoS Class Identifier – A parameter that is typically associated to packet forwarding/scheduling etc treatments.

QCI values can be from 1 to 9. Since QCI is an 8 bit field it can have 255 values. Values 10 to 255 are operator specific. A bearer is always associated with a QCI. A UE can have a max of 11 bearers but QCI are from 1 to 9. Which means the QCI can be repeated for the bearers.

Each bearer is also associated with TFT. Yes, even the default bearer can be assigned a TFT after the recent spec changes. TFT can have multiple packet filters resulting in multiple SDFs. Now the confusion is with this statement - “Each Service Data Flow (SDF) is associated with one and only one QoS Class Identifier (QCI).”

Since two dedicated bearers can have same QCI the above statement leads to confusion. Reading the statement again makes sense. A bearer is associated with QCI and set of packet filters that will lead to multiple SDF’s. This means multiple SDF’s can be treated with same type of service but one SDF cannot be given multiple treatments. This also means that you cannot assign same packet filter to two dedicated bearers. Hence the above statement!

Roaming trouble

What makes cellular communication standout from other wireless technologies is its roaming ability. No matter in which country you are just dial the number and talk. This makes mobile communication truly mobile.  But the technology behind is not that simple.

I was wondering how difficult will it get for an operator to maintain so many roaming agreements. A given operator may have to maintain like, say, 100 roaming agreements. Well considering LTE a given MME will have to talk to 100 different HSSs and SGW will have to communicate to 100 different PGWs.  Whoa!

There is a nice way to maintain the list of PGWs based on the various APNs. MME informs the SGW which PGW it has to contact for which IMSI. The S8 interface is UDP based and DNS maintains detailed records of APN to PGW mappings. So its relatively easy to fetch a PGW and establish a tunnel for the user. But for HSS its little complicated. Now that HSS runs on diameter, there are several solutions proposed to reach home hss from visiting network. Also diameter runs on tcp or sctp which means there is always a connection established. This is quite difficult as the MME has to reach several HSS across the world. Looking forward to some interesting solutions here. Diameter relays, proxies ?

CS Fallback - A Study

We know that LTE doesn’t have basic voice and SMS support. To mitigate this 3GPP proposes fall back to CS network for voice and SMS. Though the industry pundits frown, I believe CS fallback has to be launched by operators deploying LTE, at-least for initial stages. Let’s look at how this works. In EPS a new interface is required to connect to the CS network. It’s called SGs, based on Gs interface, and runs SGsAP protocol. This interface is between MME and MSC Server. Next requirement is overlapping networks. It is expected to have a GERAN/UTRAN network along with EUTRAN for UE to fallback to CS. The concept is simple. UE will attach to the network through EUTRAN, MME will ask MSC to update UE location in its database, when a call is made or received UE is simply asked to fall back to CS network to answer/make the call. However note that sending and receiving SMS doesn’t need UE to fall back to CS network.

Few more details! When UE is attaching to EUTRAN, UE will perform a combined attached. That is a new IE, mobile class mark, will be sent in Attach Request asking MME to perform a combined attach. Once Attach request is received, MME will send a location update request informing MSC of UE’s location. This way UE is now known to LTE as well as CS network. When a UE has to make a call, it will simply send an extended service request to MME. MME will inform eNB that UE has to now move to GERAN/UTRAN network. If inter RAT handovers are supported, UE will be handed-over to GERAN/UTRAN network else UE’s EUTRAN connection is released and is asked to connect to GERAN/UTRAN. Because of this LTE services on UE will be disrupted.

UE attaching to EUTRAN & CS Networks

SMS is delivered over signaling channel. This means there will be no data path established to deliver or receive SMS. SMS will be sent over a signaling message. Exactly for this reason, SMS delivery or reception doesn’t need UE to fall back to CS network. Once the UE is attached to both MSC and EUTRAN and if MSC wants to deliver a SMS to UE, it will simply send a downlink unit data to MME with SMS content. MME will dump this message in NAS message and send it to UE. In the same way if UE wants to send a SMS it will dump the message in NAS message and send it to MME. MME will extract SMS content and send it to MSC over Sgs interface. This operation doesn’t need UE to fall back to CS network thus ensuring smooth delivery of SMS.

Mobile Orginated SMS delivery in Idle mode

One important thing to note here is that MME should keep a proper mapping of Tracking Area and Location Area. This is because MME needs to know to which MSC the UE should be connected to, based on the tracking area received in attach request. MME will map the tracking area to the corresponding location area and will pick the MSC based on the location area. All the details regarding CS Fallback are present in 3GPP TS 23.272. Refer to same for all the call flows.

Mandate CS Fallback

There is so much debate going on about voice technology that should be used over LTE. I have my view here. Before a proper voice technology is figured out, I would assume that CS fallback will become a mandatory feature on all LTE phones. Though VoLGA and IMS seem to be good solutions, but they don’t solve many other issues, like roaming for e.g.

Its obvious that LTE phones will support 3G/2G technologies. Also with release 8 SGSN’s coming in the packet handovers to 3G/2G technologies from LTE and vice versa would be smooth. This means LTE phones are already equipped with 3G/2G chipsets. If so then why cant  CS fallback be made mandatory?

Yes, agreed that to access a voice call one should be cut out of LTE. But at least I am able to make a voice call even if I am not in my home network. Analyzing how the voice call can disrupt the packet service for individual users can be a separate case study. For e.g corporate users are heavily dependent on emails. So if voice call lands on their mobile the LTE service will switched off for couple of minutes which is very acceptable for an email user. Rest may not be convinced, but it does solve the problem.

One more point is SMS. I heard that SMS is mandatory in Europe, that is if a user is roaming then the roaming charges(?) should be informed to the subscriber by an SMS. If that is the case the CS fall back does help with smooth delivery of SMS over Sgs interface. However this may not be a permanent solution. As the technologies mature we can find a better way to deal with voice and data co-existence without breaking each others connection. Untill then operators please give us CS fall back support and also do not mess up your networks with putting many additional nodes.

Must Read!

A book that explains SAE packet core in a nice way! A must read for engineers working in mobile packet core.

Amazon link: http://amzn.com/0123748267

UE NAS and MME NAS

Quick thought regarding the NAS layers between UE and MME. Since UE and MME directly cannot talk to each there could be a disconnect between the both. Consider this. When UE goes into idle mode, it is not known to the network until the network receives a TAU. In the mean time imagine that network initiated a bearer deletion procedure. If eNB doesn’t find the UE then bearer is implicitly detached on MME and eNB, but the bearer information is still present with the UE. At this point there could be a disconnect between UE NAS layer and MME NAS layer.

Assume another scenario where handover is in progress. Because of some reason the target eNB has not accepted a particular bearer. The same is conveyed to network in S1AP message and to UE in RRC messages. But NAS layers in MME and UE still have the bearer information. There could be several cases like this where there can be different NAS states in UE and MME. The question here is will RRC and NAS layers in UE be in sync. That is if a Data radio bearer for a particular bearer is not established, will the NAS layer be intimated the same by RRC and UE will delete the bearer from its NAS layer?

Anybody?

3G to 4G

Its interesting to look at how operators would be migrating from 3G/2G to 4G. 3G/2G networks are here to stay for a long time. 4G is the one which is supposed to co-exist with the existing 3G/2G networks. 3G/2G inter-working with 4G might need few tweaks on the packet core of exiting 3G/2G networks and also of-course the whole new 4G network deployment itself. Below are few such change I can think of from packet core network perspective. (I am assuming here that there are no major upgrades done on 3G network, which means 3G network is still pre Rel 8)

GGSN & PGW integration:- This will be a big change but shouldn't be that complicated to an operator. I am assuming that LTE subscribers will be given a new APN that can be accessed over a 3G or 4G network. This would need GGSN and PGW to co-exist as there is need to share the APN along with user context
HLR/HSS:- HLR is database from 2G/3G. HSS is the new database in 4G. I would like these two entities to co-exist and share the data. We dont want to SGSN to contact one database and MME to contact other for authenticating the same imsi.

DNS integrations:- The same dns servers in 3G network should help MME in selecting SGW and PGW. Few entries need to be added and MME should be pointed to that DNS
SGSN configuration changes:- SGSN shoud be configured to point to new GGSN if users from LTE are moving to 3G network. This should not be a big problem as new subscribers mean new imsi and imsi can be mapped to a APN in SGSN (?) which in turn identifies the GGSN

Gn interface:- There is need for Gn interface between MME and SGSN to provision inter RAT handovers. If UE is moving from 4G to 3G then the Gn SGSN should be able to contact MME and pull out the UE context and vice versa.



Each point can taken up for discussion. Any more scenarios you can think of?