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?

Idle Mode Signaling Reduction

When ever a UE moves to a new tracking area or routing area it triggers a tracking area update (LTE) or Routing area update (3G) procedure to inform the network about its current location. Note that these procedures are triggered while UE is in Idle mode or Connected Mode. Read below considering UE in Idle mode.

With the LTE systems coming in, both the network antennas (3G and LTE) might remain close to each other. This means a UE can be in a tracking area of a MME at one point and it can immediately move to routing area of SGSN at another. If both coverage areas are pretty close and UE is lingering at the border of both networks, it could result in ping-pong effect. That is a UE may get into a loop where it sends RAU to 3G system de-registering itself from LTE and vice versa by continuously doing cell reselection.

Solution to this is proposed in Annex J of 3GPP TS 23.401, which is ISR.

The solution assumes that SGSN is S4 SGSN. Also it is a requirement that both UE and network should understand ISR. ISR support is mandatory for E-UTRAN UEs that support GERAN and/or UTRAN and optional for the network.

Assume that UE is registered to the network through EUTRAN. Now UE re-selects a GERAN/UTRAN network and initiates a Routing Area Update. SGSN will send context request to MME asking for the UE context. Here MME may reply with context response along with ISR activate indication. Network shall switch on the ISR once it realizes the UE context is being pulled from a different RAT. Once the context response is received, RAU accept along with ISR active indication is sent to UE. Once UE receives the RAU accept along with ISR active, it shall store the GUTI from EUTRAN and also the newly received P-TMSI from GERAN/UTRAN. MME will also keep the UE context. SGW is informed about ISR activation by SGSN in Modify bearer request (ISR flag set). At this point UE is registered in both EUTRAN and GERAN/UTRAN, has both the network identifiers (P-TMSI and GUTI) and UE may not initiate a TAU or RAU (until the UE has identified a new TA/RA that is not in its list).

When data for UE arrives from network, SGW will send downlink data notification to both SGSN and MME. Both MME and SGSN will initiate paging. UE may respond to which ever paging message it has received and initiate a normal service request procedure later.

Thus the ping pong effect of TAU and RAU is minimized at the expense of paging the both networks.

Spec Ambiguity

Could somebody kindly tell me if a SGW could be relocated by a TAU request in connected mode? I think not? Interested in a debate? 3GPP TS 23.401 Chapter:- 5.3.3 Cheers, Santosh

LTE Tidbits IV

Continuation to LTE Tidbits I, II, III


There have been several questions on how RRC and EMM/ECM states are in sync. To begin with, RRC and EMM/ECM states are two seperate layers, each layer provides service to other but doesnt have authority to modify each other. eNB, acts as a relay between UE and MME, i.e it will receives RRC messages from UE and puts them in S1AP messages towards MME. This means eNB will simple pass the NAS pdu's from UE to MME without modifying them. SO at UE, there are two layers to maintain, RRC state and NAS state. We cannot have a state where there no radio bearers for dedicated bearer, but the NAS layer has the EBI for dedicated bearer.

S1AP Initial UE message holds an extereme importance. It is sent only when UE first establishes an RRC connection with eNB. This message is what makes UE move from ECM idle to connected mode.

FAQ's:-

1. In a normal TAU procedure, when MME decides to change the SGW, how does the new SGW come to know about the IP and TEID of eNB for data downlink flow and how does the eNB come to know about SGW IP and TEID?

[S] When a SGW has changed during TAU, MME will send a create session request towards the new SGW. This CSReq is for establishing the control plane.Now in CSRes the new SGW will respond with its own user plane IP and TEID that is used by eNB for uplink. This info is propagated to eNB in Initial context setup message. Now eNB will create radio bearers and once the radio bearers are created it will send downlink user plane IP and TEID in intial context setup response message to MME. This info is send to SGW in modify bearer request.

2. In Initial Attach procedure, how does the eNB comes to know about the SGW IP and TEID?
[S] Same philosophy as above applies. The trick here is radio bearers will be created only once the network has setup the EPS bearers. Once EPS bearer is created using CSReq/Res, only then then eNB creates the radio bearers and this info is sent to SGW by MME in Modify bearer req/resp

3. If OI=0 in both CSR during initial attach and S1 based HO, why does the SGW not send CSR towards the PGW in S1 based HO?

[S]CSReq is used to create EPS bearers. In S1 HO case the EPS bearers are already created, so CSReq will not be sent to PGW. BUt since the SGW has changed, PGW should be informed of new SGW, so a modify bearer request is sent to PGW.

Summer Break! Wedding bells are ringing!

Hands are trembling, feet are cold. Yes, I am getting married. Will be off from blog and email untill June.

See you all then!

Cheers, Santosh

EMM, ECM, RRC States, TAU and Handovers

Its very interesting to observe the connection between 5 terms mentioned in the subject line.

Refer here and here for details on EMM, ECM and RRC states.

EMM has two states:- EMM Registered and EMM De-registered. When a UE is connected to the network it moves from EMM De-registered to EMM Registered. Also the ECM state moves to ECM connected from ECM idle. Before these two happening the RRC state in UE is moved from RRC idle to RRC connected. So when UE is actively connected to the network the states in UE/network are RRC Connected, ECM Connected and EMM Registered.

When UE moves to Idle mode first the RRC connection is released. That is RRC state moves from RRC connected to idle. Then ECM state moves to ECM idle from connected. This mean eNB has released the RRC connection and network has released the UE bearer context information but EMM state is Registered. This is termed as S1 release in 3GPP TS 23.401. It would be interesting to know that ECM idle state is valid only on S1 and S11 interface. The UE information is actively maintained in PGW but is released in eNB and MME. Also the behavior of network in ECM idle mode is different in different cases. (future posts). The basic idea of idle mode is UE is not know to the network and in connected mode UE is known to the network. The term "known" refers to UE location, bearer information etc.

TAU - Tracking Area Update. A tracking area is a group of cells that are being tracked by a SGW. When UE is connected to the network, a list of tracking areas are sent to it. When a UE moves to new tracking area it will trigger a tracking area update procedure as defined in 3GPP TS 23.401. A TAU can be triggered when UE is in idle mode or connected mode.

Now at any given point of time UE can be in idle or connected mode. If UE is in connected mode and moving from one place to other then handovers take place. Note that handovers are transparent to UE except that UE now camps on to a new eNB. Also handovers are network initiated. This means a handover can happen when the UE is known to the network, i.e when UE is in connected state. Also after the handover if UE finds that it is present in new tracking area then it can initiate a tracking area update.

But a UE need not be in a connected state all the time. What happens when a UE is in idle mode and is moving from one place to other? When UE is in idle mode, MME will have the UE's last know location. So if some data arrives to UE, while it is in idle mode, MME will initiate paging process to find UE. Now if UE has moved from the last know location how will the MME know the UE's new location. This is where TAU becomes extremely important. In this case it is the responsibility of UE to inform about its location to network. This is done by sending TAU. As I said when UE is attached to the network MME sends a list of tracking areas. So if MME wants to find UE i.e is in idle mode, it will simply send paging message to the eNB and eNB will page for the UE. But if UE is in new tracking area, that is not in the list received during initial attach, it will initiate a TAU. Once network receives TAU it will store the UE's location info.

To initiate a TAU UE should have a RRC connection. First thing it does is it camps on to a nearest eNB by doing cell re-selection process. After RRC connection is established UE may send TAU to network. Note that ECM state in network is still idle for that UE. But TAU may move the ECM state in network from idle to connected. (future post)

Thus if we look at overall picture a handover can happen when UE is in EMM Registered, ECM connected and RRC connected state. A TAU may be initiated by UE when it is in EMM Registered, ECM idle and RRC idle state. Both the procedures help UE in its movement from one place to other.