IMS Dedicated bearers

Email exchange! Hope it helps!

-------------------------------------------------------------------------------------------------------------------------------------

My understanding of VoLTE bearers:

• A default bearer is automatically created as part of UE attach (This is UE-initiated IP-CAN session initiation). 
• It is possible to also include a dedicated bearer for signalling on UE attach but this is not compulsory (This is UE-initiated IP-CAN session modification).  
• A UE initiates an IMS session by sending a SIP INVITE message and IMS elements (typically the P-CSCF) triggers the activation of the dedicated bearer for the session via Rx/PCRF/Gx/PGW.  
• Similarly when a session is terminated the UE sends a SIP BYE message and the P-CSCF triggers removal of the dedicated bearer via Rx/PCRF/Gx/PGW.  (This is network initiated IP-CAN session modification for the VoLTE dedicated media bearer.)

The problem I see with this is the following scenario

• UE terminate an IMS call and sends a SIP BYE.  Typically the dedicated bearer is removed through Rx/PCRF/Gx.  BUT if the SIP BYE is lost in the network, the dedicated bearer remains and the user is still charged even though the call is "ended".

I think it is also possible to use UE initiated IP-CAN session modification for the IMS dedicated media bearer (I had a look at 4.5.1 Request for PCC rules in 3GPP TS 29.212 where it talks about IP-CAN session modification initiated by UE) - and I think it should work as follows:

• UE sends SIP INVITE and initiates dedicated bearer activation which goes PGW/Gx/PCRF.
• With SIP preconditions full IMS signalling only takes place once both sides have completed UE initiated dedicated bearer activation.  (Rx is still used but differently .. not 100% sure how)
• When the UE terminates the call it sends a SIP BYE message and activates the removal of the dedicated bearer.
• If a SIP BYE message is lost the dedicated bearer is still removed, the PCRF is informed, and in turn the IMS elements are informed via Rx.  The session will be fully torn down and charging will be stopped.

 -------------------------------------------------------------------------------------------------------------------------------------
- Have you explored anything in IMS that can provide a solution to lost SIP Bye?
- Is it a really good idea to rely on UE to establish/teardown the SIP signalling? How do you plan to interop with tons of UEs that will available in market soon.
- To me the solution should be driven from the network, based on the UE subscription. You can establish a non GBR dedicated bearer when UE is initially attached to the network for the purpose of SIP signaling, that can just stay there as long as UE is attached. QCI - 1 is designated for this. This will be inline with further SRVCC procedure.
- If dedicated bearer creation and deletion needs to be triggered by Rx, then I am afraid there is no trivial solution to deal with lost SIP Bye, unless IMS presents us with one.

-------------------------------------------------------------------------------------------------------------------------------------

If the signalling bearer is QCI 5 then the packet loss error rate is 10^-6.  This means that 1 in 1000 000  packets are lost.  So if the BYE is lost it seems likely that the signalling bearer will be torn down.  It is possible on IMS registration to register for notifications on the status of the signalling bearer - if the signalling bearer is lost then all media bearers are removed (no more charging) and the user is unregistered.

So maybe this is not a problem after all?

-------------------------------------------------------------------------------------------------------------------------------------

Regarding the QCI: From my understanding - the network will detect if the QCI guarantees for a bearer can no longer be met (i.e. if the signalling bearer - QCI 5 - can no longer receive loss rate of 10^-6).
 If this is detected the bearer will be torn down - PCRF informed etc.  Though I've yet to see this demonstrated I am pretty sure this capability exists in standard EPC.  So I think my original concern is
actually not a problem at all - what do you think?

Fallback to older RAT for throttling

We all are, painfully, aware of service providers applying fair usage policy, beyond a certain limit of data usage, by throttling mobile data speeds. Typically this is done using a PCRF/OCS. With latest revisions of 3GPP (Release 9) we can achieve FUP just by using PCRF. However I want to put forth another way of doing this. Push the LTE subscribers to UMTS after a data threshold; similarly push UMTS subscribers to GPRS/EDGE. Don’t kill me; I am just stating another feature of 3GPP :-).

Few years back we had GPRS/EDGE widely deployed, with UMTS coming in a new network was deployed along side of GPRS/EDGE. Also LTE is going to co-exist with UTRAN/GERAN. As of now most of the devices that do data are 3G capable and are always hooked on to UMTS/HSPA. The numbers of 3G/4G capable devices are on the rise leaving the GPRS/EDGE network least used. What if we push the 3G subscribers to GPRS/EDGE after a certain limit? This way we could still utilize the GERAN.

I am not sure of limitations on radio side, but from core network it seems like a simple feature. HLR/HSS store information about subscriber and can dictate which Radio Access Technology (RAT) a UE can connect to. Refer to 3GPP TS 29.272 and look for “Access Restriction Data”. The AVP has values like “UTRAN Not Allowed”, “GAN Not Allowed”, “E-UTRAN Not Allowed” etc. Based on these values MME/SGSN will either allow or block the UE from accessing a corresponding RAT. Typically blocking a RAT will lead to an “Attach Reject” with definite “Cause” towards an UE. Assume a UE is blocked from E-UTRAN, so when that UE tries to gain E-UTRAN access, MME rejects the Attach with Cause “EPS services not allowed”. This will stop UE from connecting to E-UTRAN, until it is switched off and switched on. Similarly we can achieve this over UTRAN and make UE fallback to GERAN.

Downsides

• Identify the subscribers whose data threshold are hit and re-program the HSS/HLR to block access. Once billing cycle is complete re-program the HSS/HLR again to allow access.
• What happens when the coverage for the enforced RAT is not present? Assume the subscriber is pushed to GERAN and he/she is in a location where GERAN is not available.

This is pretty lousy solution to implement, but achievable. Nice way to implement is rate limit the subscriber using PCRF.  We could still use this feature to block certain users from accessing a RAT all-together, which is reasonable.

This shows the amount of control a mobile network can have over a subscriber!

Juniper MobileNext Platform

The number of subscribers using mobile network is on the rise day by day. It’s just not humans any more, its also machines. Machine-to-machine communication is expected to explode in the very near future. To support millions of subscribers and machines, there is serious need to build scalable networks right from the RAN all the way through to the core. It’s just not enough to build a scalable network, but also ensure the quality of experience. With machines the critical data is expected to make it to the servers on the other end of the mobile network without any loss. Imagine ATMs running on mobile networks!

Image Source

In this regards Juniper Networks has released a performance report for the MobileNext Broadband Gateway which seems very impressive. Juniper MobileNext GGSN/PGW was independently validated, for performance & scalability, by EANTC using Spirent tools. 

European Advanced Networking Test Center (EANTC) is internationally recognized as an objective test center. They provide vendor-neutral network performance test facilities for manufacturers, service providers and enterprise customers.

MobileNext is truly a distributed platform with clear control and data plane separation; enabling the GGSN/PGW to host millions of subscribers and simultaneously pump huge amounts of data traffic.  The numbers are clear in the below chart. Juniper claims that the MobileNext Broadband Gateway can host 8 Million Subscribers; transfer 434 Gbps of traffic with zero loss along with an activation rate of 48,000 sessions per second (168,000 transactions per second), all being done concurrently in a completely redundant system.  

Without redundancy MobileNext Broadband Gateway can host up to 12 Million Subscribers; transfer 551 Gbps of traffic with zero loss and handle 72K activations per second.  

Do we really need such a powerful device in the mobile core? Yes we do. Let’s take the direct tunnel case in 3G. If subscriber goes to idle mode, the direct tunnel is taken down by SGSN and when subscriber becomes active again a direct tunnel is created by SGSN. A Direct Tunnel create and delete leads to 2 transactions on GGSN. If there is charging trigger enabled for direct tunnel creation and deletion, count another 2 transactions. Now multiply that by the number of SGSNs/RNCs and subscribers. The number of transactions is quite significant, especially for a large operator.  Older generation hardware needs a gateway to be added every time there is an increase in transaction rate or data rate.

Another reason for need of high performance is machine to machine communication. Assume that smart meters are hooked on to the mobile network and are programmed to update the server at 6 in the morning in a location X. So at 6 in the morning there will be a bulk of create pdps followed by data transfer followed by delete pdp’s from location X. If we allocate different time slots for smart meters in different locations to update, there is constant pressure on the GGSN/PGWs to handle the high rate of transactions and data transfers throughout the day. Loss of data becomes a very critical, as a meter reading might be lost.

Small/Hybrid Cells and wifi offload is going to bring in many more subscribers and stress on the network. Not to forget the new devices and fancy applications that are melting the networks every day. Considering these aspects, the need for high performing and reliable mobile core is needed today and I believe we need these kind of platforms to build a scalable networks and ensure quality of experience.

IMS Emergency Calls over LTE – Short description

As operators are moving towards LTE, the need for emergency calls support over LTE is high, as they have to comply with local authorities. 3GPP has defined a nice procedure for emergency calls in Release 9(?). The support for emergency calls is required across the network and UE. Below is how the procedure works. 

First thing to consider is any UE can make an emergency call, provided network supports it. This means there is no subscription for that UE in HSS. This also means there is need for an emergency APN to be defined! I will avoid eNBs here as RRC always goes above my thinking capabilities. 

When UE wants to perform emergency attach, it will send an attach request with attach type as Emergency Attach.  Upon receiving this attach MME may or may not contact HSS for Authentication. If MME supports, then call may proceed even if Authentication fails if at all HSS was contacted. If authentication fails then MME may not contact HSS for Update location request. In a nut shell, when Emergency Attach is received Auth/Security procedure becomes optional. 

This brings the next point. APN. This is where 3GPP defines the magic term “MME Emergency Configuration Data” that is needed on MME, where Emergency APN is stored. Optionally QoS parameters and static PDN gateway address can be stored. So upon receiving an emergency attach MME knows where to send the Create Session Request. 

Another thing to note is a UE may not send IMSI in the attach request, if it doesn’t have one. Well, I should be able to make an emergency call even if I don’t have a SIM card. In this case IMEI is required. Basically mobile network is doomed without IMSI or IMEI. This needs SGW/PGW to be prepared for receiving Create Session requests without IMSIs or IMEIs. Another software modification! The QoS values, like ARP can be statically configured on MME or if Dynamic PCC is deployed then PCRF may provide these details. The PDN created for emergency service cannot be per-empted, so proper ARP values should be used. It is also expected that Emergency APN supports IPv4v6 PDN type just to be on safer side. 

Once everything is set, MME may send Create Session Request to SGW/PGW and based the Response the attach procedure may be completed. A UE may make an emergency call now. Once the call is complete UE need not detach. As soon as UE goes to idle mode, MME may go ahead and release the call. 

There are several nuts and bolts described in 3GPP TS 23.401, 24.301 and 29.274 if you want to look at the procedure in detail.

Location Reporting!

There was one interesting feature in Release 7 that dint make it to LTE in Release 8, however it has introduced as part of Release 9. I am talking about Location Reporting feature.

A PGW/GGSN needs to know the exact location of UE/MS so that it can do location based charging. Other reason why PGW/GGSN needs the exact UE location could be for lawful intercept. Any more reasons? 

Anyway the UE location is propagated by MME/SGSN to PGW/GGSN over ULI IE (User Location Information). Whenever a UE changes a cell or routing area or tracking area MME/SGSN may inform the PGW/GGSN about the same using location change reporting feature. In pre-release 7 if the UE moves from one routing area to other that is under same SGSN then there is no message over Gn interface towards GGSN. So how will SGSN send the User location information IE with new RAI to GGSN? There is a GTPv1 message called “MS Info Change Notification Request” that SGSN may send to GGSN indicating the UE location. GGSN, based on this, can do location based charging. 

This feature is missing in Release 8. Oh shoot! We completely forgot about it. Lets put in Release 9. 

In LTE the location reporting may be achieved in following way. First if MME/PGW supports location reporting then MME will ask eNB to report UE location. So, as and when UE moves from one TAI to other or from one cell to cell eNB will send Location Update message to MME. But how to propagate this info all the way to PGW? According to release 8, there is now way to do it. MME has to wait for the next available GTP message to send this information to SGW/PGW. Which means a cell change may never be reported to PGW or you need to have a eNB with just one cell under it and that is just covering one TAI, so that when UE moves from once cell to other there can be a handover and MME can send Modify bearer request to SGW with the ULI. This is little too much. So 3GPP Release 9  brought back the support for “Change Notification Request”. If UE moves from one cell to cell, MME may now send Change Notification Request that can be propagated all the way to PGW and PGW may further send UE location to PCRF or charging server. Thus bringing back location based charging. 

Refer to 3GPP TS 23.401 v 9.9.0 Section 5.9.2 which was missing in Release 8.

Release 7 equivalent is in 3GPP TS 23.060 Section 15.1.3.

Vodafone launches LTE in Germany

On Dec 1st 2010 Vodafone D2 in Germany has gone live their LTE network. The porject was towards offering high speed boradband in rural areas of Germany. Hope fully everything is going smooth for them.

Link here

Is anyone experiencing the LTE network in Germany? How is it working? Any comments.

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!

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.

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.

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.

TAU and RAU

This is in continuation to what I wrote some time back. (here)
TAU corresponds to Tracking Area Update in LTE and RAU corresponds to Routing Area Update in GERAN/UTRAN. A TAU or RAU is initiated by UE when it detects a new tracking area or routing area. Below call flows show how a UE performs RAU in GERAN and TAU in LTE when both GERAN/UTRAN and LTE networks are converged using Gn interfaces.
LTE UE's are expected to operate in dual mode, i.e support both LTE and UTRAN and more over both the radios are expected to be turned on all the time. Below call flows are with reference to Annex D of 23.401. SGSN is considered to be Gn based and MME is expected to support GTPv1. This means no changes to the existing 3G network (SGSN) is required to support below.

LTE - Routing Area Update

Looking at the call flow we can see that GGSN is missing. It is believed that to implement above both GGSN and PGW must reside on single box. So PGW is acting as GGSN for 3G world and it remains itself for LTE. PGW shall again speak both GTPv1 and v2 and will be responsible to map the contexts and qos (of 3G and 4G).

Once UE detects that it is in 3G world it immediately triggers a Routing Area Update. We are assuming that UE is registered in LTE domain now. Once SGSN gets the RAU it looks for the old SGSN information to pull the UE context from (P-TMSI ?).To a Gn SGSN MME just acts as an another Gn SGSN. So the Gn SGSN sends SGSN context request to MME to which MME replies with the UE context. Later an Update PDP context is sent to GGSN(i.e PGW) to inform the change in the data path. At this point PGW shall map the LTE bearers to 3G PDP;s

LTE - Tracking Area Update

Similarly when UE moves from 3G to LTE it triggers a tracking area update.

Clearly the above are not handovers. Both TAU and RAU are triggered by UE which means UE is responsible for choosing the corresponding technology. Also this method might not be seamless too.

More thoughts on this?

Piggybacking in LTE

I observed an interesting feature in 3GPP TS 23.401. Feature is defined in Annex F. Now I wonder are Annexes really that important?

In LTE we always have a default bearer. Dedicated bearer may be created on need basis. Looking at the way industry is moving it is pretty evident that VOIP will be mainly used for voice over LTE. Operators would like to provide a good QoS for a voip call so they would want a dedicated bearer to handle the same. Also with LTE phones VOIP will be a very basic feature and would become a must on every LTE device. This means the network infrastructure should be capable enough to support dedicated bearer for every LTE phone and a dedicated bearer has to be activated as soon as the UE connects to the network to provision VOIP.

A dedicated bearer may be requested by UE or can be triggered by network based on rules and charging functions. Considering the above it would be nice to have both default and dedicated bearer established while UE is being attached to the network. Annex F exactly defines the same.

During the LTE UE initial attach, a create session request is sent to PGW. PGW responds with create session response. Note that dedicated bearer creation is initiated by PGW by sending create bearer request to SGW. Now 3GPP TS 29.274 provisions a method where a GTP message can be piggybacked to other. During initial attach, PGW can send a create bearer request piggybacked to the create session response indicating that it has initiated a dedicated bearer creation. Just a flag needs to be set in the GTP-C header of create session response (Octect 1 bit 5 from LSB) and create bearer request can be appended. There will be only one UDP header though. Once MME receives the create session response with piggybacked create bearer request it will initiate both default and dedicated bearer activation in single shot.

I find this mechanism very cool as lot of processing in PGW can be avoided with respect to PCRF interaction for dedicated bearer creation. This piggybacking can be enabled based on a IMSI or based on APN that is UE connecting to. Interesting!

Any thoughts?

LTE Tidbits III

Gn/GP handovers:

LTE will not be fully functional from day 1. We will need the legacy systems to support major number of customers. LTE specs describe the inter RAT handovers, but they do insist to upgrade the existing SGSNs and GGSNs. Now no operator wants to touch their existing fully functional system untill the new system is working without any problems. This means for some point of time both legacy and LTE systems should work together. This also means that operators would still want their legacy systems to talk to the LTE and vice versa.

To provision this 3GPP Ts 23.401 Annex D provides the call flows. According to the Annex existing SGSNs need not be touched.LTE functional elements such as MME and PGW will also support legacy protocols (GTPv1) so that both networks can communicate. To a SGSN, MME will just behave as another SGSN.

But these handovers are hard handovers which means there could be a connection loss. Also GGSNs from the existing networks should be replaced with LTE PGW, as the whole conecpt is based on LTE PGW as the comman anchor between the two networks. This shouldnt be much of a problem as PGWs are written keeping this mind and I personally believe that GGSN replacement will not be that much of a problem. The dissected call flows shall be posted soon.

ISR/TAU/RAU:-

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) procedures to inform the network about its current location. Note that these procedures can be 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 a routing area of SGSN at another. If both coverage areas are pretty close then it could result in ping-pong effect. That is a UE may get into a loop where it sends TAU to LTE network and next moment it sends RAU to 3G systems de-registering itself from LTE and vice versa.

Solution to this is proposed in Annex J of 3GPP TS 23.401. ISR - Idle-mode singalling Reduction.

The soultion suggests that UE be registered with both networks while it is in Idle mode. That is UE is registered to a tracking area of a MME and also to a routing area of a SGSN. This needs UE to explicitly support ISR and also both the networks should be capable enough to support the ISR. The common achor point between the networks is considered to be SGW, this also means that SGSNs and GGSNs should be upgraded to support Rel 8. This way ping pong effect is avoided. But this comes at an expense. As the UE is registered to both networks both the SGSN and MME will have to initiate a paging process to make UE move to connected state. However UE will initiate serivice request to network that it is currently camped on, i.e either LTE or 3G.

More to follow.