Wired n Wireless

ATT and IPhone

2012-01-30T03:04:00.000+05:30

Some time back I got hold of an IPhone from ATT and did a field test. It releived quite an interesting results and gave a blue print of ATT network. Field test application can be invoked using keypad and by typing *3001#12345#*. It shows a lot of information about cellular network including RRC, NAS and PDP context. I tried to analyze some part by taking a bus ride, from one place to another, which is apporximately 5 miles.

Routing Area and Cell id

Cell id kept changing every quarter to half a mile. Routing area changed every mile to 2. A cell id change mean that there was a NodeB change and Routing area change indicates that RNC has changed. I hope location reporting for cell id is not enabled, otherwise there will be so many updates to the network. Imagine a bus loaded with 40 people out which atleast 20 are carrying phones by ATT network. This creates 20 cell updates at almost same point. Cell Id update is optional so I am sure the cell id update must has been turned off in the network.

But Routing area cannot be avoided. Which means the network was receiving 20 Routing Area Updates every 5 mins from the bus. So if you combine the traffic that is outside the bus, during a peak time, its is quite a load on SGSN/RNCs to process the routing area updates. Unfortunately every Routing Area needs to be reprted to SGSN, but with LTE and concept of Tracking Area List the updates can be significantly reduced. But again that will depend on how the network is designed. During attach in LTE, network may send a max of 16 tracking areas and If UE is moving across those tracking areas then there is no need for a Tracking Area Update.

PDP contexts

The IPhone atleast opens 2 primary PDP contexts. One is for regular data and other is for visual voice mail. Now another interesting thing, for pulling an voice mail, phone always connects to a different APN, this means voice mail can be given free of charge without much of hassle. Because voice mail APN can be a plain APN withouth charging or DPI turned on.. On the other hand if voice mail is pulled from regular APN, then DPI needs to be turned on the APN and voice mail traffic should be zero rated. Its an absolute pain. So the work aroud is to make phone connect to different APN.

I was wondering, if a Phone is bought unlocked then how to make it connect to two different APNs. I know that I can trigger another primary pdp using a console connection and AT commands, but how do we do it from a phone. May be that is one of the reasons why ATT doenst unlock IPhones.

There are still some more interesting aspects to look at, but I will leave it you. Will grab an LTE phone and perform some more tests as and when time permits.

DPI, Policy and Charging

2012-01-14T00:40:00.001+05:30

I am particularly impressed by the amount subscriber management that 3GPP has provided. Per packet flow treatment per subscriber is super cool. However the implementation on mobile gateways is quite complex and need a lot of cpu and memory cycles. In simple words we really need powerful hardware sitting in edge with a efficient software to correctly enforce the policy and perform corresponding charging actions.

Just to point out, 3GPP allows service provider to treat each subscriber differently based on the subscription. A subscriber may be allowed to use certain traffic or block certain traffic, certain traffic may be treated with higher priority and bill him based on the application or location etc. The limit is endless. A very good business model is needed to make it happen though. So to allow or block certain traffic from a subscriber the gateways need to look deep into the packets, detect the flows, apply policies and report to the billing system. This is quite a lot of pressure on the gateways.

I was doing a study of various telecom plans available across the world. Interestingly some service providers were offering services like free Facebook or free sport channel at a flat monthly rate or free email etc. This makes me wonder why we even need these plans with LTE. These plans are efficient when there is sever crunch of radio resources and subscriber doesn't have fancy handsets, but with LTE the spectrum has widened and fancy handsets are becoming cheaper and cheaper. Will these plans still hold well?

For e.g a plan like free facebook will need the mobile gateway to look at all the packets flowing from subscriber, zero rate it and then inform the same to the billing system. This churns a lot of bandwidth in term of cpu and memory cycles on the gateway. More over the software on the gateways needs to be highly efficient.

But there is other side to it. A subscriber may be offered limited data over a period of time but as token of appreciation allow a service free. For e.g I would be very happy if “Google Maps” is offered free along with my monthly of say 200 meg. I mean truly free here, that is actually look at the Google Maps traffic and zero rating it. But service provider may not want to do, so he may allow another 50 meg of additional quota and call it token of appreciation. Duh!

In a nutshell, 3GPP subscriber management is amazing and I believe the broadband forum agrees. DPI, Policy and Charging are cool features on mobile gateways from engineering stand point. There are several other issues with DPI as people really don’t want service provider to look at their data. Anyway the service is available and I will leave it to the marketing to decide :-)

I would like to hear from you. Would you like certain services to be free along with your subscription or would you like service to be free for a low monthly or weekly rate or any other plans you want to see in the market?

Merry Christmas & Happy New Year

2011-12-26T00:50:00.000+05:30

Ian still around and answering emails for the 3rd year. Still plenty to come in new year as mobile networks evolve. Wish you all a very happy Christmas and new year. Thanks & Regards, Santosh

Location Reporting!

2011-09-09T06:07:00.000+05:30

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.

Understanding ISR

2011-08-03T23:55:00.003+05:30

Very detailed post from 3G and 4G blog.

http://3g4g.blogspot.com/2011/08/look-at-idle-state-signalling-reduction.html

Link to a old post in this blog.

http://wired-n-wireless.blogspot.com/2010/06/idle-mode-signaling-reduction.html

GTP Version Fallback

2011-08-03T23:40:00.000+05:30

I had a discussion with my colleagues about GTP fallback mechanisms. While 3G/2G allows GTP fallback from V1 to V0 over Gn interface the same is not true for S11 interface. LTE is designed all the way to speak GTPv2. However if you look at 3GPP TS 29.274 (section 7.10), there is an interesting section pointing to Fallback to GTPv1. Of course, refer to the latest revision of the spec as things have changed from older revisions.

A GTPv2 entity may fall back to GTPv1 when the other entity responds to a GTPv2 message with GTPv1 Version Not Supported message. This is a pretty much valid and straight forward case. If a UE is moving from UTRAN/GERAN to LTE using Tracking Area Update, then MME may request for UE context from SGSN over GTPv2 message if S3 interface is configured. But if SGSN doesn’t support S3 interface then it may send GTPv1 Version Not Supported to MME. MME in this case may fall back to GTPv1 and may request the context from SGSN over Gn interface.

The second scenario deals with S16 interface, about which I never ever thought of. S16 interface is between 2 SGSNs and is GTPv2 interface. If SGSN deployed is S4 SGSN then the two S4 SGSNs communicate over S16 using GTPv2. As far as I know S16 interface deployment is going to take a lot of time, but it is an interesting case. Now assume that UE is connected via S4 SGSN to a GGSN. Remember that though SGSN supports S4, the current scenario is that the UE is connected to a GGSN over GTPv1 interface. Now the UE moves to a new S4 SGSN using Routing Area Update. The new S4 SGSN may use S16 interface to fetch the UE context from old S4 SGSN. But the old S4 SGSN established the UE context over GTPv1. So the old S4 SGSN may send GTPv1 Version not supported to new S4 SGSN. The new S4 SGSN may now request the UE context over Gn using GTPv1. Thus the fallback to GTPv1.
This kind of detail in the specification is amazing and hats off to the GTP authors.

Simply Brilliant! Vodafone femto hacked!

2011-07-14T23:00:00.002+05:30

Must read!

http://thcorg.blogspot.com/2011/07/vodafone-hacked-root-password-published.html

MME Pool – Load Balancing and Re-balancing

2011-02-23T20:06:00.003+05:30

Reference - 3GPP TS 23.401 Section 4.3.7

As LTE is planned for larger deployment it is time to look at the load balancing and redundancy among the various core network nodes. I would like to present how a MME load balancing and redundancy can be achieved in this post. I will follow up this post with SGW and PGW pooling.

A MME in the network is identified by MME code and Group id. Each MME will have a weight factor configured that is conveyed to eNB during initial S1 setup. An eNB can talk to multiple MMEs in a pool. Based the weight factor eNB will decide which MME can be loaded with calls to what level. Assume that an eNB is communicating with 2 MMEs in a pool. MME-1 has weight of 100 and MME-2 has weight of 50. This means eNB, out of 3 UE attaches, will forward 2 attaches to MME-1 and 1 attach to MME-2. If in case MME-1 is down, then all calls will be routed to MME-2. This is one way of achieving load balancing and redundancy.

There is another way to achieve load rebalancing. This is the case when a MME feels overloaded, it can simply move the calls to other MME in a given pool. Assume above example. MME-1 has been overloaded and cannot handle any more calls. If MME-1 wants to free up some resources, than it release the S1 connections of UE towards eNB asking UE to perform a “load balancing TAU”. This is conveyed to UE by eNB in a RRC message. Once UE gets this message it shall send a Tracking area update message which is routed to MME-2 by eNB. This way MME-1 can gracefully move calls to other MME-2. It is assumed that MME-2 and MME-1 are connected over S10 interface as MME-2 should pull the UE context from MME-1.

If the MME is feeling overloaded, then it may also send Overload Start message to eNB asking it not to forward any calls to it. If necessary resources are available then MME may send Overload Stop indicating that it is ready to accept new calls.

Another way of achieving load balancing is using DNS at eNB. If UE is NOT connecting for the first time then it will populate GUMMEI to eNB in one of the RRC messages. Based on the GUMMEI eNB can perform a DNS query to obtain MME information and forward the UE messages to that particular MME. If the selected MME is not responding then eNB may forward the call to next available MME in the pool.

I believe this should help operators to plan their network.

Busy!

2011-01-31T14:58:00.000+05:30

Dear all, I am terribly busy these days and unable to post anything in the blog. I have all your emails with questions in my follow up list. Please bare with me for some more time, I shall get back to you all with my views.

Cheers, Santosh

Wired N Wireless completes 2 years

2010-12-31T19:24:00.000+05:30

With over 160,000 hits, this blog completes 2 years. Thank you for the support and wish you all a very happy new year.

Cheers, Santosh

Verizon 3G to LTE Handover Delay

2010-12-14T21:15:00.000+05:30

This is purely my thought and may not be entirely true.

I read news that users of Verizon network are experiencing a delay of 2 minutes when moving from 3G to LTE network. Users are experiencing this when they are continuously transmitting the data. I also read that in few instances subscribers are forced to unplug their dongles and plug them back to get LTE access. I was wondering what could be the reasons and below is what I think!

Frist Reason:-

Verizon network is CDMA based. LTE is GSM based. Since both technologies are entirely different it gives an impression that handovers are not going to be smooth. However 3GPP specs does provide solutions for smooth handovers. So why the delay? The places where LTE is deployed would have had 3G coverage. When a 3G network detects that UE is receiving stronger 4G signal it has to handover the UE to 4G network. But not complete 3G network would have been converged to 4G, so in few cases the 3G network would simply ignore 4G networks presence and make the UE to hook on to it. In this case users should stop transmitting data for a while so the UE may go into idle mode. Once UE is in idle mode and if it wants to send some data, it will perform cell re-selection and choose LTE network instead of 3G thus bringing subscribers back to LTE. This could be one reason why few subscribers had to plug out their dongles and place them back to get 4G access.

Second Reason:-

Next, assume that 3G network is converged to 4G. In this case moving from 3G to 4G should be smooth. But if the network elements are far away then the delay in the core network might result in higher handover time. However movement from 4G to 3G should be smooth, because where there is 4G network, 3G network would have been present and 4G network would have had complete information about it.

The fixes could go in several places. But I am assuming that first reason is what bothering the most and network should be fixed soon. Those who are interested to know more can refer to 3GPP Spec 23.402 for detailed call flows.

Vodafone launches LTE in Germany

2010-12-02T09:35:00.000+05:30

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

2010-11-28T15:41:00.000+05:30

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

2010-11-21T15:25:00.000+05:30

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

2010-10-10T14:07:00.001+05:30

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

2010-09-17T15:32:00.000+05:30

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

2010-08-26T09:37:00.000+05:30

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

2010-08-18T10:03:00.002+05:30

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

2010-08-01T20:13:00.000+05:30

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!

2010-07-28T10:16:00.000+05:30

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

2010-07-21T12:17:00.000+05:30

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

2010-07-07T20:08:00.000+05:30

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

2010-06-29T15:33:00.000+05:30

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

2010-06-14T16:58:00.001+05:30

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

2010-06-14T16:52:00.003+05:30

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!

2010-05-04T09:28:00.002+05:30

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

2010-04-21T20:55:00.001+05:30

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

2010-03-29T20:02:00.001+05:30

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

2010-03-24T20:24:00.000+05:30

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

2010-03-18T13:16:00.004+05:30

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.

LTE, Wimax and WIFI

2010-03-08T20:43:00.002+05:30

I observed this particular trend in India with regards to household. People typically have a PSTN phone at their home provided by the local govt operator (BSNL). Then they use mobile phones from various operators. Though mobile phones are extensively used for communication I observed that people prefer wired telephones to convey important information to the other party whenever possible. Many are very comfortable with using a PSTN line. Though mobile communication is exploding PSTNs are doing very good business too. I was thinking if we could offer more services over wired line it would be big hit in India. At-least my mom would be very happy to talk to her sister over a video phone. VOIP phones?

On a same note I still dont find the wireless internet in India to be great. I recently got a Wimax connection and its kinda bad. First, the connection is costly and next the speeds are bad. More over the webauth makes it worse when there are multiple computers at home. The basic connection setup takes forever and it is really frustrating sometimes. Though companies have been pushing for wimax, end users are really not happy with it, at-least me and my friends are not happy with it. Now I always think how my fixed line (DSL) used to work. Its been a downgrade for me. Similar is the experience with the 3G modems. Worst uplink speeds and during peak hours you hardly get anything. The point here is Wimax and 3G are still not proving to be perfect replacement for the wired connections.

Recently I came across a service provider providing wifi services. The adds display 4G enabled technology and gives away words like MIMO and OFDM. It caught my interest and was wondering for a while what the underlying technology could be. Guess what its our humble Wifi. I was always a fan of WIFI and with latest 802.11n its time to explore the wifi mesh networks. About 3 years back, when I was in college, I happened to listen to a lecture from a professor who came all the way from Israel. The lecture was on Wifi mesh networks and various routing algorithms involved in it. Typically a wifi mesh is formed of multiple adhoc networks. The lecture was quite interesting and we did some experiments with our laptops and could route packets through multiple laptops. It was fun but I never thought it would be commercially launched (college kid, lack of experience :-)) Now when I see the add, it reminds me of the lecture and experiments. 802.11n on the backhaul and supported 802.11a/b/g towards the customer end seems great. Backhaul is powered with MIMO and OFDM which provide high speeds between the nodes can help boost the network performance. But again the network has to be carefully designed and routes to the main node are to be optimally configured. I quite dont know how the network is really performing, should talk to someone who is using the mesh, but I am quite happy to see wifi growing. Imagine if these networks grow then wimax and mobile networks can get in trouble. More over this wifi mesh is seeming to be a lot cheaper than what other technologies are offering.

Just a thought!

3GPP Specs

2010-02-18T21:04:00.001+05:30

As we know there are hundreds of 3GPP specs. But when coming to the implementation will all that is written in the spec will be implemented. Of-course not. I think the specs give an detailed view of the architecture and how things should work . But there are some many things that are outside the specifications scope and mind you they can happen in the real world.

Ambiguous scenarios, negative scenarios, collision scenarios and what not. When coming to LTE I pity eNB and MME. They are most vulnerable to take a beating from various handsets. More over the interpretation of specifications from one engineer to other may be different, so the product might seem different. Hence IOTs are needed.

The wireless world is so different from the regular networking at Layer 2 and Layer 3. The IEEE standards and RFCs are clearly written, so the implementation is very clear. The thing to notice here is there are not many end user to it. Who would be running BGP or OSPF or MPLS? Most of the traffic in the internet is at Layer 7 and hence I feel difficulty is a bit less in internet. But I do agree at there are very complex protocols involved in the internet. But in wireless, the whole network is at the customers stake. A fake UE can bring down the back-end devices. So the equipment manufactures do implement lot of things that are outside the scope of the 3GPP specs. Just a thought.

LTE Tidbits-II

2010-02-09T20:29:00.001+05:30

Few more things are LTE below. Find part 1 here.

UE network attach:

We all know how important IMSI is and we wouldn't want to spill it out anytime. This requirement brings in a second type of attach procedure in LTE. Usually attach request from UE contains IMSI so that network can validate the same. Once network knows the UE's IMSI, it will generate a Globally Unique Temporary Identifier (Find details here) and assign it to UE. So for further communication UE can use GUTI instead of IMSI.

Why this? The Attach Request sent to the network is not encrypted. Security procedures are done only after network receives Attach Request. This means if IMSI is sent in Attach Request its susceptible to be known to outsider. To avoid this UE may send Old GUTI to network in Attach Request(The term "Old" is used here because it is assumed that UE is moving from one MME to other MME). Once the network receives that GUTI it will map the IMSI from it. Problem solved. What if the network doesn't know the GUTI, then it will have to ask the UE to send its IMSI. Network sends out an Identity Request to UE asking for its IMSI, to which UE will respond with Identity Response with its IMSI. Note that this message is not encrypted.

GUTI is assigned by the network. Which means UE should send its IMSI to network at-least once. If UE moves from one MME to other then its responsibility of MME to get the UE's IMSI from other MME based on the GUTI which UE has sent. Identity Request (for IMSI) should be sent only if MME fails to retrieve the IMSI.

Inter Rat Handovers:

There is special section in 3GPP TS 23.401 which we tend to ignore. Appendix. :-) If we look at inter handover requirements it is quite clear that SGSN's should be upgrade with new version of GTP protocol. But this Appendix has a different information altogether. Refer to Appendix 5 in the spec. Checkout the Routing and Tracking Area update procedures. They both speak of GTPv1 rather than GTPv2. This means MME has to support GTPv1 too. This sucks. Anyway, I still have my fingers crossed about inter RAT handovers. Hope they will be seems less.

More later. Comments/Corrections are welcome.

I will NOT be at Mobile World Congress this year!

2010-02-06T19:51:00.001+05:30

I will NOT be at MWC this year. :-) Neither was I last year nor the year before. :-D

But I am close follower of the event. Last year was all about mobile devices. HTC unveiled their new phone and so did other brands. Nokia N97 was announced just ahead of MWC. All in all last year was more of devices.

However this year I am guessing most of the attention would be towards LTE and HSPA+. Now the devices are in the market and we need speed. I want to see more of LTE demos, chipsets and handsets. Also an announcement regarding voice over LTE would be sweet.

With so much action in Barcelona its disheartening to see no 3G in India. I see an add today which says TV over Mobile phone. Cool! But dah! Network is still running GPRS. Considering a city like Bangalore in India this application makes no sense. Any way hope to see 3G soon in India.

I wish all visiting Barcelona for MWC a good luck and hope to see some live blogging from there. May be I will get a chance sometime in future to visit Barcelona :-)

LTE End to End Signaling:- Part 2

2010-01-30T16:54:00.000+05:30

I wrote about LTE End to End Signaling some time back. Based on public demand I enhanced the call flows a bit :-). Here are two calls showing Initial Attach and UE initiated detach procedures.

LTE UE Initial Attach

This is a huge call flow and there is a lot of processing involved. I would like give a brief out line of messages.

S1 Setup: This is where eNB is attached to the network. As long the eNB is functioning the S1 setup remains.

RRC Connections: Once UE comes up a RRC connection is established for communication with the network.

NAS: After RRC is established then begins the NAS signaling. UE sends Attach request along with PDN connectivity request to network. Attach is for attaching to the network and other message message is for establishing the bearers.

HSS: This is Home Subscriber System and it understands diameter protocol. Once MME receives Attach Request, it queries HSS for authentication details. HSS sends the authentication vectors to MME in Authentication Info Answer.

Authentication/Security: Networks requests UE for Auth vectors. Once UE provides the same MME compares the same with what HSS has sent. If they match UE is authenticated. Next is security. After the security all the NAS messages are encrypted using the security algorithms that were exchanged.

Bearers: After security network creates the EPS bearers first. (GTP messages). Then the radio bearers are created and RRC connections are modified accordingly. Once the radio bearers are created eNB downlink addresses are sent to SGW in GTP messages.

LTE UE Initiated Detach

UE decides to detach from the network. Its sends a detach request message to network. Network deletes the EPS bearers then the radio bearers are torn down. Finally RRC connection is released.

I hope the messages are correct. Comments are always welcome.

SGSN and LTE

2010-01-14T16:00:00.003+05:30

With LTE gaining more light I guess most of the network manufacturers are ready with basic attach, default and dedicated bearers, X2 and S1 handovers. But LTE as standalone will not make sense as it will deployed in just few places. Rest of the world will be still running on 2G/3G/CDMA networks. So there is a strong need for 3G/CDMA convergence with LTE which means inter RAT handovers. I think Europe will see 3G convergence with LTE while Verizon is working hard to converge their CDMA network into LTE in US. So, may be, this year will be about convergence and figuring out a proper solution for voice over LTE.

My interest here is SGSN. SGSN is a major signaling element in 3G packet core. It runs RANAP/NAS protocols towards RNC and GTPv1 towards GGSN. If 3G is to be converged into LTE then there has to be a software upgrade on SGSN as it needs to speak GTPv2 over S4 interface with LTE MME. This makes SGSN much more important and signaling intensive device. I am sure that both operators and equipment manufacturers are looking closely at the SGSN's now. The question here is how will the operators choose which 3G networks should support LTE and which shouldnt. Imagine this. I have a UE which has APN configured with a LTE PGW. While in roaming I may not find a LTE network so I will have to switch back to available 3G network. Now, that 3G network should be capable enough to support my UE's existence in the network. This means SGSN should go all the way to talk to LTE MME, pull the bearer contexts, map the QoS and serve the UE. This needs quite a lot of processing. Will existing SGSN be capable to do all this? This will probably need much powerful hardware on SGSN. I am very keen to see how things will go in this direction. I am hoping that Mobile World Congress this year will have some answers. Any thoughts?

Thank you all!

2010-01-02T13:11:00.005+05:30

Let me start with wishing you all a very happy and peaceful new year.

I started this blog as a new year(2009) resolution to keep track of my work. This day marks first anniversary of the blog. I never thought it would be useful to anybody. The idea was to make a record of what I was learning. What I was writing did make sense to some of you and I am quite happy about it. As of now the blog has around 125 subscribers and close to 50,000 hits. This blog goes into my achievements list.

This year I would like to continue writing. I moved a bit closer to technology which means the posts would be more accurate and simplified. In the process of writing blog I did learn a lot from many of you and also made some very good contacts. I take a moment to thank you all for the support. I also request you to let me know if any changes or enhancements are required to the blog. Any suggestions or comments are greatly welcomed.

Cheers, Santosh

Happy Holidays

2009-12-19T19:33:00.001+05:30

Time to take a break. I will be off for next two weeks. See you all in the new year.

LTE: Mobility Management States

2009-12-15T11:33:00.002+05:30

Manish from Layers7 blog is writing a series of articles on LTE mobility management states. There are two posts on his blog that discuss LTE EMM and ESM. Go ahead and check them out!

LTE NAS-1
LTE NAS-2

LTE: Inter RAT Handover (E-UTRAN to UTRAN)

2009-12-13T16:02:00.001+05:30

Below is the case where UE moves from LTE network to 3G network.

Source network is LTE and target network is 3G. Target SGSN communicates with MME over S3 interface. GTPv2 is protocol used here. This means existing 3G network SGSN's need a software upgrade. (GTPv1 --> GTPv2). We also assume that a LTE SGW is serving the 3G network. This means that SGSN again uses S4 interface to communicate with SGW.(GGSN is no longer required?) Below is the call flow and is self explanatory. I am considering that Indirect Data Forwarding tunnel is used. Details are in 3GPP TS 23.401 Chapter 5.5.2.1.

The messages are almost similar to what S1 handover uses. Only change is communication between RNC and SGSN which is RANAP based. Does this mean that no software upgrade is required in RNC?

I am interested in two things here;-

NSAPI: NSAPI is the identifier used to identify a control plane tunnel/PDP context. EBI is used in LTE for the same purpose. So when the UE moves from LTE to 3G, EBI is mapped to NSAPI. However this mapping is not complex as both NSAPI and EBI are 4 bit values. Also they both start with integer value of 5.

QoS:- QoS values are quite different in LTE when compared to 3G. EPS QoS to pre release 8 QoS mapping is explained in 3GPP TS 23.401 Annex 5.

Secondary PDP context and Direct tunneling!

2009-12-09T10:49:00.006+05:30

LTE dedicated bearers are something similar to secondary PDP contexts from GPRS world.

Direct tunneling is one of the release 7 features which says the user plane path could be directly from RNC to GGSN. This will avoid user plane processing in SGSN.

My question is how many service provider networks have implemented direct tunneling? Also who all have provided the support for activating secondary PDP context? I believe most of the smart phones do have support to activate secondary PDP contexts, but how many are actually doing it?

Could somebody please enlighten me in this regard? If the information is confidential please feel free to email me. I shall not disclose the information anywhere, it is for my personal study. Thanks!

LTE: PMIP & GTP based interface mapping

2009-12-02T22:49:00.001+05:30

We all know that S11 interface is GTP based while S5 interface could be GTP or PMIP based. If 3GPP TS 23.401 specifies GTP based interface then 3GPP TS 23.402 gives out PMIP based S5 interface details.

So I had this question for a while:- In PMIP based S5 interface there is only user plane tunnel per UE, while GTP based S1-U has several tunnels which we call as default and dedicated bearers. So how are so many tunnels with different QoS schemes mapped to single tunnel over PMIP S5 interface?

My theory:- For GTP based S5 interface PCRF communicates to PGW but for PMIP based S5 interface SGW interacts with PCRF. The interaction here is for enforcing the qos values on the tunnels. That is PCRF informs SGW what are the QoS values it should enforce in the downlink for user plane. Lets look at below figure.

Consider this. There are 3 bearers established, one default and two dedicated bearers. The uplink/downlink tunnel id's are as shown in figure. On S5 interface uplink/downlink GRE keys are exchanged. PCRF gives out QoS values that SGW should enforce on the GTP tunnels. Dedicated bearer 1 is associated with TFT 1. Say this is for HTTP traffic and TFT consists of Remote Port information, i.e Port 80. Dedicated bearer 2 is associated with TFT-2. TFT-2 indicates FTP traffic, i.e Remote Port Range 20 and 21. Corresponding TEID's are shown. So SGW happily enforces the QoS rules on the GTP tunnels. But how are these tunnels mapped over S5 interface which is PMIP based?

This is what I think. SGW pushes all the information that is coming on GTP tunnels 0x01, 0x02, 0x03 to GRE tunnel 0x11. The uplink should be blind and SGW shouldnt have anything to worry. But downlink is little complex. The data is coming to SGW over 0x0z GRE tunnel. Now SGW has to map this information into one of the three GTP tunnels. This is where it uses the TFT. SGW reads the incoming data and it forwards the data to HTTP tunnel if it sees that data is coming from port 80, else to FTP tunnel if data is coming on port 21 or it will blindly send it over default bearer. (Does deep packet inspection makes this possible?)

So the SGW mapping should be something like this. All the GTP tunnels ID's mapped to single GRE tunnel and TFT information used for segregating data in downlink.

Correct? Any other thoughts/ideas? Please feel free to comment.

LTE: APN, PCO & Initial Attach

2009-11-24T21:39:00.001+05:30

This post is out of an interesting conversation I had with one of my readers.

In LTE, UE gets attached to a network in a single shot. That is when the UE is switched on it will send a NAS message, Attach Request along with PDN connectivity request. Look here.

3GPP TS 24.301 has a little different story to tell though. According to the spec UE shall not include APN and PCO in the PDN connectivity request when the same is sent along with attach request. The spec says UE shall send the PDN connectivity request with a flag "ESM Information transfer" on and no APN or PCO shall be included. Once MME receives the Attach Request+PDN connectivity request, it shall go ahead and accept the attach but it shall not establish the EPS bearers just yet.

MME now goes ahead with establishing security context. Look here. After the security context is established MME will send a NAS message "ESM Information Request" asking UE for APN and PCO. Now UE shall send "ESM Information Response" with APN and PCO, encrypted(?). Once MME receives this response it will go ahed with establishing the EPS bearers. If the response doesn't include APN then default APN shall be used by MME.

Why this? I guess this is for security. We just dont want to reveal the user name passwords to any network that asks for it, right?. And also above is only valid if Attach Request and PDN connectivity request messages are sent together. The story is different if the two messages are sent separately. More thoughts?

LTE S1 Handover: Indirect tunnel

2009-11-21T19:10:00.001+05:30

I wrote about LTE S1 handover in the white paper. However I dint cover this interesting concept. I am working on next revision of white paper and will make it public soon.

X2 based handover is used when there is X2 link between source and target eNB's. This also means that EPC should be just informed about change in eNB FTEID's for downlink. If we look deep, the downlink packets are still sent to source eNB until EPC receives a handover complete notification and the target eNB FTEID's. The buffered downlink packets are sent to target eNB by source eNB later which are then sent to UE. These packets are directly sent over the X2 link. This means there is direct tunnel formed between source and target eNB for data forwarding.

Now I started looking at a S1 based handover. I saw something called Indirect Tunnel.

Now in S1 handover we assume that there is no X2 link between source and target eNB. Also I am assuming that SGW has changed during the handover. So the downlink packets buffered at the source eNB during handover execution should be sent all the way to Source SGW, then to target SGW and then to target eNB. To do this target MME sends a GTP based message Create Indirect Data Forwarding Tunnel Request to target SGW. In this message the target eNB FTEID for downlink are sent. In the same way the message is sent from source MME to source SGW. This will create a indirect tunnel between source and target eNB. After this the buffered packets are sent from source eNB to target eNB which are later sent to UE.

Sounds good? Anything to add? Please feel free.

An observation!

2009-11-19T23:17:00.001+05:30

There are bunch of office boys at the place I work. Since one year I have noticed them using big fat mobile phones while I carry a small GSM phone which can do nothing but voice and sms. So I talk to the boys and they tell me that these phones are made in China and apparently are very cheap. They also told me that these phones might stop working anytime or they might just keep working for years.

Later I observed them using GPRS and accessing WAP sites of service providers. They download a ringtone or a photo of an actress everyday. Now this made me wonder. People who have never used internet on a computer, or rather who have never used computer, have started using internet on mobile phone. So what happens when these guys realize the beauty of youtube. If 3G comes in and service providers start advertising youtube service on television, these guys are going to have a blast. Remember its the adds on television that made facebook so popular in India (Aircell advertisement?). This means India is directly moving to mobile internet, which is jumping over a step, skipping the internet revolution on PC. India is adding 10 million subscribers every month. Now with 3G coming and youtube like services rolling out just imagine how congested the networks are going to get!

Any thoughts?

IMS is the way to go?

2009-11-15T18:20:00.001+05:30

I have been strong supporter of VoLGA, but I have recently realized that industry should move towards one long term solution. I believe IMS is the way to go in future.

3GPP clarifies the LTE Myths - Strong support for IMS :-)

LTE Dedicated Bearers: The Big Question!

2009-11-13T20:41:00.001+05:30

I wrote about LTE dedicated bearers some time back(here , here and here ). Just when I thought I got every thing right I realized that I am back to square 1.

We know that dedicated bearers are network initiated. But the big question is when does the network decide to initiate the dedicated bearer. Many people have asked me about this so I thought of putting down what I knew.

In LTE there is a bearer which is always established until UE is shut down and it is called default bearer. Well UE can ask for a dedicated bearer by sending out a bearer allocation request to the network. Once network receives the UE request then we will have dedicated bearer. This is one case.

What we noticed is there is a trigger for dedicated bearer. Now if we look at the spec for dedicated bearer creation, it immediately starts with Create Bearer Request. Many are confused with what could be the trigger for this message. Next para should help.

Second case is:- default bearer is established. Network now wants to have all the http traffic put in separate dedicated bearer. So once the default bearer is established, network might ask UE to run the http traffic on dedicated bearer. Note here that there is no trigger for dedicated bearer, which means network is configured in such a way that all http shall run on dedicated bearers with a particular qos. Even if UE is running http of default bearer it may be asked to switch to dedicated bearer. If UE is not capable enough to run a http then it may reject the dedicated bearer request also it may reject the request if it thinks default bearer is fine for http.

Now the confusion here is IMS calls. Many say how will network initiate a dedicated bearer for IMS calls. The big confusion is with reception of IMS call. Well, this is what I think. IMS needs an application to be running UE, a special app. If UE is intelligent enough then it will request a dedicated bearer for IMS call while it is registering with network or when the IMS app on UE starts running. Else PGW may look at the packets that are being sent by UE (deep packet inspection?) and initiate a dedicated bearer by it self. The point here I want to make is we shouldnt think that network will create a dedicated bearer only when UE receives an IMS call, the bearer is created much ahead of it.

If we consider that network is modifying or creating a new bearer for already running traffic, then what about the UE application's connection state. Will the connection be reset as the bearer has to be switched. I dont know, an UE engineer should answer this. How ever this dedicated bearer is still pretty confusing, in fact many are confused with what could be triggers for a dedicated bearer creation. Any ideas?

Evaluating LTE SGW

2009-11-08T21:24:00.001+05:30

We know that Serving Gateway is one of the most important entities in LTE network. Say if XYZ service provider is evaluating a SGW, what are the factors that XYZ would be looking at. Lets avoid price and technical support offered by the equipment vendor here.

Serving Gateway is supposed to handle both control plane and user plane traffic. Just to increase the complexity, lets consider that S5 interface is PMIP based. So we have GTPv2 communication on S11 interface, GTP-U encapsulated traffic on S1-U interface, PMIP based control plane and GRE encapsulated user plane traffic on S5 interface. So the technical requirements are revolving around control and user plane.

Control Plane: Input to the SGW are GTPv2 messages and output are PMIP message towards PGW. In between SGW needs to communicate with PCRF/Radius servers for pulling other information. So first thing XYZ wants to see is a successful session established. That means we need to get the basic functionality correct. More over XYZ would also want to see how easy it is to configure the SGW. This may not be one of the criteria for evaluating the box but its good have a easy to use interface. Getting the basic functionality right means there needs to be a successful interop. That is the SGW should work with other vendors MME or eNB or PGW or etc. This also means that SGW vendor should get the specs right :-).

Next, XYZ wants to see how many sessions can be activated per second. Also XYZ would be very interested to see how many active sessions can the SGW handle. May be a million users per box? That means SGW should have million contexts activated and data base integrity should be smooth. XYZ might also want to see how many dedicated bearers can be activated for single default bearer. More over XYZ might fancy to see how many default/dedicated bearers can be activated and deactivated per second. This test might prove how strong is the box is.

Handovers is another functionality which XYZ wants to see. Does SGW support various handovers mentioned in the spec. If so XYZ would prefer a number of users that can have successful handover per second.

Roaming too is important. There is typical requirement which arise with roaming scenarios. MME of visiting network might want to contact home network SGW for authentication, charging policy etc. Which means the GTP message is hopping for one router to other in the internet. Which also means that there needs to be some security involved. IPSec comes into picture. MME can encrypt the GTPv2 control messages in IPSec and pass it on to the home network SGW. This means SGW should also be to handle several IPSec sessions. I dont want to go below this layer. SGW might also be able to do BGP/OSPF/MPLS etc at the network layer. These could be some of the control plane requirements.

User Plane: First thing that comes into my mind is throughput. XYZ wants to see how may user plane session can be handled at what throughput. Usually the packet size is fixed in S1_U interface, so there is need to know the maximum throughput that box can achieve. I strongly believe that this is the most critical factors.

Finally, XYZ wants combination tests, thousands of sessions established along with thousands of user plane tunnels with different kinds of traffic. These are system level tests. If everything matches XYZ's requirement then they are ready to spend heck loads of money on the gateway.

These were few thoughts running through my mind. Feel free to add more!

IP CAN Session Establishment

2009-10-30T17:48:00.003+05:30

BBERF :- Bearer Binding and Event Reporting Function PCEF :- Policy Charging and Enforcement Function H-PCRF :- Home- Policy Charging and Rule Function V-PCRF :- Visited - Policy Charging and Rule Function

Do we need LTE any sooner?

2009-10-26T23:52:00.001+05:30

Ok, I have been thinking real hard on this. When do we exactly need LTE? Next year? Two years from now or three years from now? I am trying to understand various article which try to justify the right time to launch LTE, but I could read none of the articles completely. Either they are too long or they go over my head. So I thought I should do it in a simple way.

Lets break things in to two here. First, what do we baldy need that is lacking now. Second, what do we fancy/love to have.

Note that first need is something that is lacking us from doing things while second one is more like wow to have or something like that.

Before we categorize the needs we need to look at the market segment. That is how many people need that badly and how many are fancying it. The things which few people badly need could be fancy to few.

If we replace "we" with "I" in above statements it would make more sense to various individuals as the next generation is all about personalization.

So if you ask me I dont need LTE. Honestly I dont see its need for me atleast in next 5 years. I work in office where we run pretty good internet connection. I get back home and have a nice wifi to use. I really dont have big fat mobile so I skip my emails if I am traveling and can live with it. I am not a facebook addict, infact I dont know why I am still using it. I prefer to call up people and have conversations rather than facebook messages or what ever. SMS is the best way for me to send a message. In case I need to be hooked on to email all the time I would go get a black berry and use exiting 2G or 3G network. The only thing I fancy is a data card. It would be good to carry a data card hooked on to my laptop so that I can be at a remote place and still be connected. This is the case with me and also with tons of my friends. What good is LTE is going to do to me? In fact the whole corporate breed in India can fall into my category.

I want to hear from you. Do you need LTE? I would really appreciate your comments on this. Cheers!!

P.S: Please dont ask me to go back to stone age. I understand that few people do need mission critical applications, that need high data rates, running on their mobile devices all the time. I am just trying to figure out what is the right time to deliver LTE considering the huge costs involved with it. I would get a heart ache if LTE fails because it was launched too soon or too late.

I will add three more constraints. Available spectrum, back haul and number of devices. How will the time lines look considering these too.

LTE Tidbits

2009-10-24T19:13:00.001+05:30

Few more interesting things on LTE.

GTP & PMIPv6

So, looking at the market I came to know that PMIPv6 is the one that will be deployed over S5 interface, no matter wether the existing service provider network is GSM based or CDMA based. Even I have been PMIP supporter for a while as it avoids complexity over S5. Reduces complexity? I was thinking over bearers one day and realized something.

In LTE a UE can have 11 bearers altogether established per APN. Note that EPS bearers are GTP based bearers. Now on S5 interface there is no concept of default bearer or dedicated bearer. That is there is only one bearer (PMIP) per UE per APN. The question is how are multiple bearers on S1_U interface mapped to single bearer on S5 interface. Lets call each bearer as a pipe with different quality of service running different applications. Since each pipe is identified by a TEID we can enforce all the QoS on it over S1_U. But how will the same be mapped over S5 interface? Interesting? Any clues?

Hint: There is an entity called PCRF which is responsible for bearer establishments, QoS enforcements etc. So SGW contacts the PCRF or rather PCRF informs to SGW on how to handle each GTP pipe over S5 interface.

More later.

Handovers & Tracking Area Update

Have you noticed that there are no NAS messages sent for handovers? That means all the handover decisions are taken by eNB based on the power measurements etc and UE is informed to modify its RRC connections.

But if you take a look at 23.401, there is a call flow for Tracking Area Update which gives us an illusion of handover. This is special case I guess so it is separately dealt, not as handover, in the spec. The difference between handover and Tracking Area Update is the later is UE initiated. Each MME(or SGW?) has a list of tracking areas which it tracks. This list is sent to UE during default bearer establishment. If UE detects that it has entered a new tracking area that is not present in the list sent by MME, then it will trigger a Tracking Area Update procedure.

Radio Bearers and EPS Bearers

If you look at the default bearer and dedicated bearer establishment procedure there is an interesting fact hidden with respect to radio and eps bearers. For default bearer, EPS bearer is established first and then the corresponding radio bearer is established. But for dedicated bearer radio bearer is established first and then the EPS bearer. Before I prove it, this fact leads to another two interesting facts. They are MME is responsible for assigning EPS Bearer Identities and we need modify bearer request for default bearer establishment. Let prove all the three.

Looking at default bearer establishment, Create session request is sent from MME to SGW after it receives Initial UE message with PDN connectivity request+Attach request. Create session request includes the EBI and same is informed to SGW. SGW sends the response if the bearer is accepted along with its user plane information. With Create Session Response the EPS bearer is established (EBI is assigned & SGW user plane info is known). Later MME goes ahead with establishment of Radio bearers for the same using the EBI. Once the radio bearer is established (eNB user plane info is known) the same is indicated to SGW in modify bearer request. This proves the third fact.

Next, take a look at dedicated bearer establishment. Dedicated bearer is network initiated. That means Create Bearer request is coming from SGW and it contains LBI, SGW user plane info, TFT etc but no EBI (set to 0?). Once this message is received by MME, MME assigns an EBI and goes ahead with establishment of radio bearer. Once the radio bearer is established (eNB fteid is known), then MME informs the same to SGW in create bearer response along with the EBI. This proves another fact that MME has to assign EBI, but not SGW.

So the above two explanations prove the first fact.

Why EBI is of 4 bits?

EBI is 4 bits because NSAPI is of 4 bits. NSAPI is used to uniquely identify a PDP context in GSM/UMTS networks. To maintain the compatibility EBI is also set to 4 bits. This means there cannot be more than 16 values for EBI. Out of these 16 values 5 are reserved which explains why there cannot be more than 11 bearers. Dont ask me my NSAPI is of 4 bits :-)

Thats it folks, I have run out the ideas. More to follow. As usual any corrections or comments are are greatly welcome.

LTE Backhaul

2009-10-20T22:03:00.001+05:30

Let me start by wishing you all a very happy diwali.

Long back I wrote about MPLS being considered as backhaul for LTE. I believe it is still the choice. More random thoughts on the same below.

Many have said that with LTE bandwidths will explode, infact I say even with HSPA the bandwidths will explode. Lets not look at this from GPRS or UMTS or LTE perspective. The simple logic is if there are many users even with GPRS, bandwidth will explode if the link between SGSN and GGSN is thin. What is happening now is there is only one IP link in wireless core network, so there is not much emphasis on it. The case is same with HSPA. With LTE there are several IP links, devices that run on IP have increased and more over relation between these devices is many to many. The wireless core architecture is moving close towards the wired architecture.

Many IP devices bring in a Central management unit along with various OAM tools. So if Verizon wants to deploy LTE, how is it going to choose the EPC vendors. I dont think using MME from from NSN and SGW from ALU will be a good idea. This also means that EPC solution providers should also come up with Central management units for their devices. One place to configure and monitor the devices.

Next challenge is to keep up the service level agreements and end user quality of experience. This is very very challenging. I will touch base on this pretty soon.

Another challenge is the actual backhaul it self. While the fiber will be widely used there are other backhaul techniques like microwave and copper. I am not sure how many microwave links we will see, but yes, there are some solutions based on these links deployed and are running fine.

Next point is infrastructure sharing. Atleast in India I have seen BSNL lending its network to private operators. The same can be done with LTE.

Quite a few things lined up, it would interesting to see how they will shape up.

Cisco enters LTE?

2009-10-13T23:05:00.001+05:30

First, I am neither a market researcher nor an analyst. These are the thoughts of a newbie in wireless segment.

Today Cisco (CSCO) announced that it is going to acquire Starent Networks (STAR). Read here.

What does this acquisition mean to Cisco? Cisco is huge company with lot of network equipment. But since the start of LTE, Cisco hardly made any noise. As far as I know Cisco was not big in the wireless segment. I am still not aware how many are using SGSN/GGSN's from Cisco. While its counter parts Alcatel Lucent and NSN were aloud with there wireless solutions.

Starent on the other hand is evolving organization. It is small, but it proved its point in wireless segment. Verzion, Sprint Nextel and Vodafone has announce Satrent as one of their EPC solution provider. Starent net revenue was high compared to last year. So Cisco did what it is best at doing, went ahead and bought Starent.

Now Cisco will have a strong foot hold in wireless division. More over both Cisco and Starent supported the Wimax. I am happy to see this deal happening. Signs of market recovery?

LTE Whitepaper from Wired n Wireless

2009-10-09T17:41:00.003+05:30

I have been working on this White paper for quite long time and finally could finish. Here it is, all my work in LTE in single document. The document talks of LTE interfaces, network elements, radio network, user plane and control plane and handover scenarios. I havent gone too deep into technology as things are definitely complicated.

I hope it will be useful. I shall appreciate if you could take a look at it and pass on your comments.

I have uploaded the same in my Google code section here. The document is also available in scribd.

Direct link to the paper here. (Courtesy 3g4g.co.uk)

LTE Whitepaper

LTE End to End Signalling

2009-10-04T14:25:00.001+05:30

LTE Initial Attach/Default Bearer Establishment

LTE Dedicated Bearer Establishment

Thanks to Zahid of 3G4G blog for the RRC call flows. (here and here)

LTE: QoS and Bandwidth

2009-09-30T20:05:00.001+05:30

I want to touch base on two concepts here. I am quite not clear on things at this moment, may be some one can help!

Concept 1:

LTE QoS: Default bearers, Dedicated bearers, TFT and Bearer QoS (QCI, ARP, MBR, GBR) are the QoS variables in LTE (any more?). I am very much aware how these behave in EPC, but I am unable to map the same with UE. Assume a default bearer has been established. Note that there is no TFT associated with default bearer, but there is a bearer level QoS present in default bearer creation. This QoS might limit the bit rate on the network side. And these QoS values are indicated to the UE through a NAS message (Activate Default Bearer Context Request?). So far so good. Now UE wants to have a dedicated bearer for particular application. UE requests for a dedicated bearer using Bearer Resource Allocation NAS message which contains the TFT, or to say traffic flow aggregates. Once this message reaches EPC, PGW consults PCRF and allocates a QoS value to this particular TFT. The QoS allocated for the TFT is signaled to UE in Activate Dedicated Bearer Context Request NAS message. Now UE has the QoS values. The big confusion is how are these QoS values limiting the data flow from UE?

My theory: Basically there is QoS concept in air interface (what?). All the QoS rules are imposed by eNB, which means the bandwidth is controlled on the eNB side. So even if the UE gets all the spectrum it will not be able to do much as the bandwidth on the network side is limited. I believe the QoS for TFT is indicated to UE so that it can also regulate the usage of spectrum. Right? Totally out of mind?

Concept 2:

Considering the above "my theory" to be correct lets try and understand how service provider can offer services. In India there is no 3G yet (except for BSNL) on mobile phones. How ever there are mobile operators whose networks are 3G ready and have started offering 3G speeds over USB sticks (TATA and Reliance). When I spoke to their customer care executives I was told the USB sticks come with a limited data plan. They also told me that this restriction was imposed by the government. The restriction can be explained using "my theory". If we start offering unlimited data service over USB sticks people might start consuming all the spectrum all the time leaving nothing for others to use. Base stations are always throttling. This can be avoided by placing data usage limit or time limit. Good move.

On the other hand, all the Blackberry's in my office run on EDGE. These handsets are provided with unlimited data usage plans. This means I can connect a Blackberry to laptop and start using it as a modem and get unlimited access to internet. Only problem as of now is these devices are running on EDGE which means low speeds.

The authorizing body is imposing data limit usage on USB sticks while allowing unlimited access on mobile phones. What will happen when a 3G phone arrives? If the network is 7.2 Mbps ready and so is the device then people can get unlimited access using mobile phone at high rates. Its just a matter of USB cable which can give high rates on laptop too. So what will the plans be when 3G arrives here? I ask my boss, "Hey with 3G you will get 3 Mbps speed but you will be able to do only 3 GB per month". This actually surprised him and he said I would rather stay on EDGE and get unlimited access. People using blackberry's dont want to fall into limited usage schemes as its frustrating to keep monitoring how much data they have used all the time. These things seem quite contradictory.

I have no idea how things are going to turn up. Can anybody enlighten me? Thanks!

New revision of 3GPP Specs

2009-09-30T09:53:00.006+05:30

Folks, September revision of LTE specs are out. I could download latest revision of 3GPP TS 29.274 - v8.3.0 (GTPv2) spec but looks like rest of the specs are not on 3GPP website yet. I am guessing all the specs should be available in next two days as some final discussions are going on in email threads. The CR list for this spec is huge, will try and see what all has changed. If you are working on LTE then it is the time to start looking at these new specs.

NSN Finlad Folks!

2009-09-24T11:24:00.001+05:30

Any one from NSN Finland reading the blog? Would really like to have a word. Thanks. My email ID can be found in About Me section.

LTE Initial Setup

2009-09-20T17:07:00.000+05:30

Reference:

3GPP TS 36.213: EUTRAN Physical Layer Procedures

3GPP TS 36.331: EUTRAN RRC Protocol Specification

LTE Cell Search:

When the UE is powered up it needs a network to attach itself. The first towards it is Cell search. Cell Search is a procedure by which a terminal can find a potential cell to attach too.

As a part of cell search procedure the terminal obtains the identity of cell and estimates the frame timing of the identified cell. LTE supports 510 different cell identifiers divided into 170-cell identity group of 3 identities each.

LTE provides two signals in downlink;

- Primary Synchronization Signal

- Secondary Synchronization signal.

In first step of cell search, UE uses primary sync signal to find the timing on 5 ms basis. This signal is transmitted twice in each frame(as LTE frame is of 10 ms).

Terminal can use this signal to identify the frame timing with a 5 ms ambiguity. Here terminal locks it local oscillator frequency to the base station carrier frequency. The terminal also finds an identity within the cell. It also obtains partial knowledge about reference signal structure.

In the next step terminal detects the cell identity group and determines the frame timing using secondary synchronization signal.

Random Access Procedure

To transmit data terminal needs a connection setup with the network. So a terminal has to ask for one. Random access procedure is used to establish uplink and unique terminal ID.

- First step consists of UE transmitting a Random Access Preamble allowing the eNB to estimate the transmission timing of the terminal.

- In the next step network transmits a Random Access Response. This consists of timing advance command to adjust the terminal transmit timing, based on timing measurement received in the first step. In addition to establish uplink synchronization this step also assigns uplink resources to be used in next steps to the terminal. Temporary identity is also assigned to UE for further communication with the network. This response is sent on PDCCH.

- Third step consists of transmission of mobile terminal identity to the network using UL-SCH. The exact content of this signal depends on the state so of terminal whether the network previously knows it or not. (RRC_IDLE)

- 4^th step consists of contention resolution message from network to terminal on DL-SCH.

RRC Procedures

There are two RRC states in LTE. RRC_Idle & RRC_Connected.

In RRC_Idle there is no signaling radio bearer established, that is there is no RRC connection.

In RRC_Connected there is a signaling radio bearer established

Signaling Radio Bearers(SRB) are defined as Radio bearers that are used only to transmit RRC and NAS messages. SRB’s are classified into

Signaling Radio Bearer 0: SRB0: RRC message using CCCH logical channel.

Signaling Radio Bearer 1: SRB1: is for transmitting NAS messages over DCCH logical channel.

Signaling Radio Bearer 2: SRB2: is for high priority RRC messages. Transmitted over DCCH logical channel.

RRC Procedures:

- Paging

o To transmit paging info/system info to UE in RRC_IDLE state.

- RRC Connection Establishment

o The purpose is establishing SRB1.

o This procedure is initiated by UE when upper layers requests of a signaling connection when UE is in RRC_IDLE mode.

- RRC Connection Reconfiguration

o The purpose is to establish/modify/release radio bearers.

o Also to perform handovers

o Network initiated procedure(?)

- RRC Connection Re-Establishment

o To re-establish RRC connection which involves SRB1 resumption and reactivation.

- Initial Security Activation

o Activate security upon RRC establishment.

o eNB initiated procedure.

RRC release procedure.

LTE Radio Interface

2009-09-19T16:42:00.001+05:30

LTE is not complete without the radio interface. It has been my burning desire to understand the radio network of LTE. I did some research and this is the second post on radio side of the network.

LTE Radio Interface User Plane protocols

In downlink data from SAE will enter eNB. The data is an IP packet. The IP packet is several protocols and is passed to UE.

LTE Radio Interface Control Plane Protocols

The control has two more layers over PDCP. RRC layer is terminated at eNB, while NAS layer goes all the way to MME.

Lets take a look at each layer individually: -

NAS: Non-Access Stratum (3GPP TS 24.301)

NAS is responsible for EPS bearer management, authentication, paging and mobility handling in ECM IDLE state.

RRC: Radio Resource Control (3GPP TS 36.331)

This layer is responsible for Broadcast and paging. It also takes care of RRC connection management, radio bearer control, mobility functions and UE measurement reporting and control.

PDCP: Packet Data Control Protocol (3GPP TS 36.323)

This layer is responsible for IP header compression to avoid unnecessary overhead in the payload. This layer is also responsible for ciphering and integrity protection check.

RLC: Radio Link Control (3GPP TS 36.322)

RLC is responsible for segmentation/concatenation, retransmission handling and in sequence delivery of messages to higher layers. RLC offers services to PDCP in form of radio bearer. These radio bearers are mapped to EPS bearers in EPC.

MAC: Media Access Control (3GPP TS 36.321)

Mac handles ARQ, uplink and downlink scheduling. The scheduling functionality is located in eNB. There is one MAC entity per cell for both uplink and downlink. The HARQ is present in both UE and eNB. MAC offers services to RLC inform of logical channels.

Physical Layer: (3GPP TS 36.201)

It handles coding/decoding, modulation/demodulation, multiple antennas etc. It offers services to MAC layer inform of transport channels.

LTE Channels Over view: (3GPP TS 36.300)

LTE Physical Channels: Downlink Channels

- Physical Broadcast Channel: PBCH

- Physical Control Format Indicator Format: PCFICH

o This informs UE about number of OFDM symbols used for the PDCCH’s.

o This is transmitted in downlink.

- Physical Downlink Control Channel: PDCCH

o Informs UE about resource allocation of PCH & DL-SCH and HARQ information related to DL-SCH

o PCH: Paging channel. DL-SCH: Downlink Synchronization Channel.

- Physical Hybrid ARQ Indicator Channel: PHICH

o Carries Hybrid ARQ Ack/NAK’s in response to uplink transmission

- Physical Downlink Shared Channel: PDSCH

o Carries DL-SCH and PCH

- Physical Multicast Channel: PMCH

o Carries Multicast channel (MCH).

Uplink Channels

- Physical Uplink Control Channel: PUCCH

o Carries HARQ ACK/NAK in response to downlink transmission

o Carries scheduling request.

- Physical Uplink Share Channel: PUSCH

o Carries UL-SCH

- Physical Random Access channel: PRACH

o Carries random access preamble.

LTE Transport Channels

The physical layer offers information transfer services to MAC and higher layers. The physical layer transport services are described by how and with characteristics data is transferred over the radio interface. (What kind of data is transferred is dealt in logical channels)

Downlink Transport Channels:

- Broadcast channel: BCH

o This channel is used to broadcast info in the entire cell.

o It has fixed and pre defined Transport Format (not aware of TF’s yet)

- Downlink Shared Channel: DL-SCH

o This channel is used for transmitting downlink data.

o It supports HARQ, dynamic link adaptation.

o It I can be used to broadcast data in entire cell.

o It supports UE discontinuous reception (DRX) to enable power saving in UE.

o It also supports MBMS transmission.

- Paging Channel: PCH

o Used for transmitting paging information.

o PCH supports DRX so that UE can sleep and wakeup to receive PCH in specific time intervals.

- Multicast Channel: MCH

o This channel is used to support MBMS.

Uplink Transport Channels:

- Uplink Shared Channel: UL-SCH

o Supports HARQ

o Counter part of DL-SCH

- Random Access Channel: RACH

Transport and Physical Channel Mapping

Downlink Channels:

Uplink Channels:

LTE Layer 2:

LTE layer 2 is split in MAC, RLC and PDCP.

Layer 2 Structure of downlink

Layer 2 Uplink Structure

The communication between two sub-layers is marked with circles. These are called Service Access Points (SAP). SAP between Physical layer and MAC sub-layer provides the transport channels. The SPA’s between MAC and RLC provide logical channels. Multiplexing several logical channels (i.e radio bearers) to same transport channel is preformed by MAC sub-layer.

Logical Channels:

MAC sub layer offers different kind of data services to RLC inform of logical channels. Logical channels define what type of data is transferred between UE and eNB. Logical Channels are classified into Control Channels (for control plane information transfer) and Traffic Channels (for transfer of user plane data)

Control Channels:

- Broadcast Control Channel: BCCCH

o This channel is used of broadcasting system control information.

o This is downlink channel.

- Paging Control Channel: PCCH

o Downlink channel.

o Transfers paging information and system information change notification.

o This channel is used for paging when the network does not know the location cell of the UE.

- Common Control Channel: CCCH

o Channel of transmitting control information between UE and network.

o This channel is used for UE’s having no RRC connection with the network.

- Multicast Control Channel: MCCH

o Point to Multi point downlink channel used for transmitting MBMS control information from the network to UE.

o This channel is only used by UE’s that receive MBMS.

- Dedicated Control Channel: DCCH

o A point-to-point bi directional channel that transmits dedicated control information between a UE and the network.

o Used by UE’s having an RRC connection.

Traffic Channels:

- Dedicated Traffic Channel: DTCH

o Uplink and downlink channel.

o Point-to-point channel dedicated to one UE for transfer of user data.

- Multicast Traffic Channel: MTCH

o Point-to-Multipoint downlink channel for transmitting traffic data from network to UE.

Mapping logical and transport channels:

Uplink

Downlink

LTE: Physical Layer

2009-09-14T15:52:00.001+05:30

I couldn't control my desire to learn the LTE physical layer, so I pushed everything aside and started reading 36 series specs. The Radio network of LTE looks fairly simple at a glance but the complexity increases as we go deep, just like any other system.

LTE Uu interface is what I am looking at. eNB behaves like a relay mapping the radio network to the IP network. The IP side consists of an interface towards MME over S1_MME and towards SGW over S1_U. The radio side communication also has two planes, user plane and control plane.

The above figure shows EUTRAN user plane. As we see we have a MAC layer, RLC and PDCP. Individual protocols shall be dealt with later. The user plane looks fairly simple as data from UE goes to eNB and eNB maps this data over GTP tunnel and sends it to SGW over S1_U. MAC, RLC and PDCP are at Layer 2 in UE and eNB.

However control plane adds few more things. L3 comes into picture for NAS signaling. This NAS signaling is carried all over to MME inside RRC signal.

Over PDCP we have RRC layer which is responsible for paging,RRC connection management, mobility functions etc etc. RRC is terminated in eNB. But NAS is terminated in MME. NAS is responsible for EPS bearer management, Authentication, security etc. Attach Request is a NAS signal which is carried all the way to MME.

Stepping few layers below we have PHY which is physical layer. This is where the actual engineering is. The whole concepts of high speeds come into picture because of sophisticated physical layer. Its no secrete what technologies are used here. OFDMA with 64 QAM and 2x2 MIMO is the most discussed combination for LTE. How does this combination give us such high speeds?

QAM : Quadrature Amplitude Modulation

Going back to engineering basics, we have a simple modulation scheme called PSK. Phase shift keying, which is analog to digital modulation scheme(transmitter side). In PSK we have 1 bit per symbol .0 and 1. Each bit is associated with a Phase shift. with 4 Phase shifts we can transmit 2 bits per symbol. As with 64 QAM we shall be able to transmit 6 bits per symbol. If we look at this scheme in the given bandwidth, by changing the modulation scheme, we are able to transmit more and more bits. This is resulting in increase of data rates.

Time to look at Shannon's theorem :

As I said above, changing the modulation scheme gives you more throughput. However hight modulation schemes can be only be used when the signal to noise ratio is high. From above theorem, channel capacity is bandwidth multiplied by logarithm of SNR. Higher the SNR higher is the channel capacity which means more throughput.

Second factor which increases channel capacity is bandwidth. Now bandwidth is directly proportional to symbol rate. Higher the symbol rate then higher is the bandwidth. But again, increasing the symbol rate doesn't increase the channel efficiency as channel bandwidth is fixed because available spectrum is finite. So there is a trade off between symbol rate and channel throughput. The basic idea is keeping on increasing the symbol rate(modulation scheme) doesn't always improve the efficiency. So considering these factors I think 64 QAM should be a suitable choice for LTE.

OFDM : Orthogonal Frequency Division Multiplexing

With above in mind lets head to OFDM. The theory behind OFDM is little confusing. Lets understand the below figure (FDMA).

Consider we have X amount of spectrum. This can be divided into channels of each Y amount of bandwidth. Each channel is separated by Guard band to avoid interference. This is basic idea in normal multiplexing schemes. I believe in CDMA we identify each channel by a code (?). So what is happening is we have equally spaced channels occupying the entire bandwidth. Note that these channels are non overlapping. Each channel has a subcarrier(?).

In OFDM: With OFDM systems, it is possible to increase throughput in a given channel without increasing channel bandwidth or the order of the modulation scheme. This is done using digital signal processing methods that enable a single channel to be created out of a series of orthogonal subcarriers. As below figure illustrates, subcarriers are orthogonal to one another such that the maximum power of each subcarrier corresponds with the minimum power (zero-crossing point) of the adjacent subcarrier. In a typical system, the bit stream for a channel is multiplexed across various subcarriers. These subcarriers are processed with an inverse Fourier transform (IFT) and combined into a single stream. As a result, multiple streams can be transmitted in parallel while preserving the relative phase and frequency relationship between them.

This way we can include more number of subcarriers in a given bandwidth thus increasing the overall system throughput.

MIMO : Multiple Input Multiple Output

The Shannon's theorem above is assumed to have 1 transmitter and 1 receiver antenna. If we consider multiple antennas then the theorem could be modified as

Thus in theory increasing the antennas will effectively increase the channel capacity without any change in available bandwidth. Now what we can do with MIMO is increase SNR by transmitting a unique bit stream using multiple antenna in the same channel. This is called Spatial Multiplexing.

With MIMO systems, the bit stream is multiplexed to multiple transmitters without changing the symbol rate of each independent transmitter. Thus, by adding more transmitters, we can increase the throughput of the system without affecting the channel bandwidth.

Thus the combination of OFDMA, MIMO and QAM will give us more bandwidth and higher data rates in LTE. The source for this post comes from various places and it would be stupid of me to post the names of the text books. Next, the above is my understanding of the system, kindly correct me if there are any mistakes. Will appreciate it.

Hope, this was helpful, more to come soon and comments are greatly welcomed.

LTE Handovers

2009-09-01T22:22:00.000+05:30

Below are possible handover scenarios in LTE. Any more scenarios you can think of? Let me know.

X2 Based handover without SGW change

X2 Based Handover with SGW changed

S1 Based Handover

S1 Based Handover -II

The above are the scenarios I can think when it comes to handovers in LTE. However all the scenarios may not make any sense during initial LTE deployments. My guess is that we will mostly see the first scenario during the initial stages, followed by the fourth scenario. Considering the first scenario, it will be very important to see how many sessions can a MME and SGW/PGW can handle. What would be performance numbers of the devices? These performance numbers are what drives the number of devices. My guess would be 1 SGW should be able to take care of say a Million general users. If we consider corporate networks and etc it may go beyond 1. I have no clue this is just a guess. Can anybody throw some light in this direction?

Excuse me for just posting the figures, I am working on something and its taking longer than I expected. More to come soon.

LTE : Tracking Area Update with SGW Change

2009-08-29T17:38:00.003+05:30

After an hour of Metallica rock and few shots of Espresso I sat down on the saturday afternoon to understand the another handover scenario in LTE. Some time back I wrote about Tracking Area Update Procedure without SGW change. In this post I would like to explore Tracking Area Update procedure WITH SGW change. Ref : 3GPP TS 23.401 5.3.3.1.

Before we dive into the post a quick note.

Tracking Area is the area/cell being tracked by an eNB. TAI change may indicate a change in eNB. Routing Area is the area/cells tracked by a SGW. So a SGW can track multiple tracking areas. The title of the post is little confusing. I say Tracking area update with SGW change and also say tracking area is taken care by eNB. Well if a eNB changes and the corresponding MME changes which may also lead to a SGW change. This is the scenario we are dealing below. The below picture should be of some help.

When UE detects that it has entered a new Cell then it begins a Tracking Area Update procedure by sending TAU request to the new eNB.

TAU Request : Tracking Area Request : TAU includes Active flags, EPS bearer status, Old GUTI, last visited TAI .. etc. EPS bearer status indicates each EPS bearer that is active in UE. Active flag is request by UE to activate radio and s1 bearer for all the active EPS bearer by the TAU procedure when UE is in ECM Idle mode. This message is sent along with other RRC parameters to eNB.

Once eNB receives this request it derives the MME from RRC parameters (which I have no idea) carrying the Old GUMMEI and indicated selected network. If this Old GUMMEI indicates the MME which eNB is not associated with, then eNB sends the TAU request to the new MME. This means that MME has changed here.

Before we dig more another very important note :

GUTI : Globally unique Temporary UE Identifier.

GUTI is an ID which uniquely identifies a UE in EPS without revealing the users permanent ID. GUTI is allocated by a MME which can be used to

uniquely identify the MME which allocated the GUTI
Uniquely identify the UE within the MME that allocated the GUTI

GUTI = GUMMEI + M-TMSI

where GUMMEI = MCC+MNC+MME Identifier and MME Identifier = MME Group ID+MME Code

GUMMEI : Globally unique MME Identifier which is used to identify a MME uniquely.

M-TMSI : It is a ID of UE. The relation between IMSI and M-TMSI is known only to UE and MME.

Context Request : The new MME receives the TAU request from eNB. New MME uses GUTI received from UE to derive old MME and sends a context request to old MME. A context request includes old GUTI, complete TAU request, P-TMSI, MME address etc. Basically this message is sent by new MME to old MME to inquire about UE's authenticity, the bearers created if any etc.

Context Response: The old MME receives context request message and validates the UE. Upon successful verification of UE old MME responds with context response. Context response include IMSI, MEI, MSISDN, EPS bearers context, SGW address and TEID's etc. This response gives out all the UE contexts setup in old MME to new MME. The new MME receives this message and happily store the UE context in it and sends context ACK to old MME. Context ack is sent with "SGW Change indication" to indicate the old MME that SGW is going to change.

Create Session Request/Response: If there was no change in SGW there will not be this message. Now that we are dealing with a case where SGW has changed, MME sends a Create session request message to new SGW. Why? Because the new SGW has no information about UE and there is a no way that two SGW's can communicate directly (Correct ?) Create session request is sent with IMSI, bearer contexts, Protocol type on S5/S8 interface, RAT type etc. SGW reads the PGW address and TFT's from bearer context. Based on the S5/S8 interface the bearer is modified. If the S5 interface is based on PMIP we shall see a proxy binding update message and if GTP is the protocol then we shall see a modify bearer request to indicate the change in RAT type, SGW fteids etc. The PDN may contact PCRF for the other info which I have no clue. :)

Update Location : Upon successful reception of create session response, the new MME sends a location update message to HSS to indicate that UE has changed its location. HSS identifies the UE old location in its database and sends a cancel location to old MME. Old MME acknowledges the cancel location with an Ack.

Delete Session Request/Response: The old MME sends the delete session request to clear all the bearer contexts to old SGW. Old SGW acknowledges to it by sending response and deleting the UE contexts.

Finally the new MME sends a TAU accept to UE which is accepted by UE. Now UE is communicating with entirely new SGW.

There are just too many things in this procedure to cover. I just highlighted the important sections and hope I got it correct. Feel free to correct me if I am wrong and any comments are always welcome.

Note: Context Request and Response are GTPv2 messages. Two MME's communicate over S10 interface which is GTP based.

LTE Flat Architecture or Insane Architecture?

2009-08-25T21:17:00.001+05:30

So every one is talking of how easy LTE is to work with all IP involved. Does making the whole network IP make LTE simpler than 3G networks? Now I am not an expert in 3G networks but I will still say LTE is no easy to deploy than finding a diamond in an ocean. And making it all IP doesnt make it simple too. Ok, so what do people mean by Flat? Is it IP everywhere which is making it flat? What about the protocols over IP? Lets try to analyze the below figure.

All that nice lady wants to do is make some calls and read some emails on her phone. What we have is LTE Uu interface which is an air interface. UE communicates to eNB via RRC protocol. Above RRC we have something called UE Layer 3. This is where all the attach request/response etc are created. RRC is way to communicate to with eNB. Below it is the complex OFDM network. OFDM along with MIMO makes it more complex for my little brain. When the sweet lady switches on here mobile phone UE triggers some messages to get attached to the network. This is where the control plane communication begins. Packet goes to eNB. S1-AP is the protocol which eNB uses to communicate with MME. This S1-AP is over SCTP transport which is yet another protocol in itself.

MME communicates with SGW using GTPc protocol which is over UDP. So MME here needs to understand S1-AP over SCTP on one side and GTPc on the other side. More over it should be a powerful router to run normal routing and switching protocols (MPLS?). So far so good. Lets make it more dramatic. Bring on the PMIP over S5 interface. PMIP in itself is completely another technology. Till now we have protocols specific to LTE domain, but PMIP is generic protocol which is made to fit into LTE network. Thank god that PMIP is an IP over IP tunnel which makes it little simple. Mobile options sit over IPv6 which are put in UDP and transported over IPv4 between SGW and PGW (PMIPv6 over IPv4).

What happened till now? Just the control plane is established. Wait a minute. Where is the security? Charging Policy? Where are the registers? Well they are lying around some where and using "IP" for communication. Again, what happened till now? We have UE context established in eNB. eNB will map the air interface to particular tunnel in S1-U interface. MME has the UE context setup and has told SGW and eNB what information is required to run the user plane (tunnel id's, qos etc). Then we have user plane info exchanged between SGW and PGW which is PMIP based. So we have a mapping between S5 user plane (GRE key), S1-U (TEID's) and LTE Uu interface (God knows what).

Sweet lady wants to make a call. She dials in number and starts talking. User plane begins. Somehow data reaches eNB. eNB tunnels the data over GTP-U header to SGW. SGW removes the GTP header place GRE header and tunnels the data to PGW. PGW removes the GRE header and forwards the data to internet cloud. So simple! Right. I pity SGW here. The poor thing is struggling hard to decapsulate one header and encapsulate another.

Its not over yet. What about the routing protocols here? Many are suggesting the whole network to be based on MPLS cloud, which makes it more complicated. Even with all IP if somebody wants to understand LTE from end to end it will take days. This is one heck of network which looks more scary than a internet core network which is of BGP, OSPF or whatever greek and latin based.

Its just enough to understand one interface in LTE. Say if you want to master S11 interface which is GTP based reading GTP specs will just not get you there. We also need to understand what is happening before and after GTP to actually figure why GTP is behaving the way it is behaving. So I say download the whole 3GPP specs, make you own database and get insanely lost in the wireless network which also has too many wires :).

Oh wait wait. Dont go away, its still not over. Sweet lady is not done for the day. At this moment sweet lady opens her laptop and connects her phone to the laptop using USB. Now she is accessing her notebook over LTE network. Well USB has underlying RS232 techniques (? no idea) over which they make PPP to run. Now the packet first hops from the note book to phone over PPP and phone moves the packet further. Huh! Now it's done. Atleast I cant think any more. (3G/CDMA integration ?)

Tidbits : If you understand what I wrote above, it proves that direct tunneling cannot be established between eNB and PGW. It also proves the we just cannot integrate PGW and SGW into a single entity (When PMIP is used, else we should be able to get both in one device). S5 is the interface which SGW uses to communicate with PGW. S8 is the interface which visiting SGW uses to communicate with home PGW.

Thats it folks, I am still working on below post. Let me know how the above looks and feel very very free to correct me if I get things wrong.

LTE Unleashed - (Work in Progress)

2009-08-19T22:42:00.000+05:30

Folks! This is very much work in progress. I wanted to post everything in one single post, but I decided. The below work is still a draft, more like a rough notes, check back soon for more details. All your comments are greatly appreciated. Thanks!

Reference :

3GPP TS 23.401 : General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access

3GPP TS 24.301 : Universal Mobile Telecommunications System (UMTS);Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS);

3GPP TS 24.007 : Digital cellular telecommunications system (Phase 2+);Universal Mobile Telecommunications System (UMTS); LTE; Mobile radio interface signalling layer 3; General Aspects

3GPP TS 36.413 : LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); S1 Application Protocol (S1AP)

3GPP TS 36.300 : LTE;Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2

*********************************************************************************************************************************************************

During the Initial Attach procedure the Mobile Equipment Identity is obtained from the UE. The MME operator may check the ME Identity with an EIR. At least in roaming situations, the MME should pass the ME Identity to the HSS, and, if a PDN-GW outside of the VPLMN, should pass the ME Identity to the PDN-GW.

Initial Attach Procedure

3GPP TS 24.301 : NAS signalling:

The non-access stratum (NAS) described in the present document forms the highest stratum of the control plane between UE and MME at the radio interface (reference point "LTE-Uu"; see 3GPP TS 23.401 [10]).

Main functions of the protocols that are part of the NAS are:

the support of mobility of the user equipment (UE); and
the support of session management procedures to establish and maintain IP connectivity between the UE and a packet data network gateway (PDN GW).

3GPP TS 24_007 v 8.2.0 : Max EBI is 11.

Link between EMM and ESM

EPS session management messages for the default EPS bearer context activation are transmitted in an information element in the EPS mobility management messages
The success of the attach procedure is dependent on the success of the default EPS bearer context activation procedure

Avoiding NAS security here

EPS Session Management : ESM

24_301 : EPS Session Management (Chapter 6)

The main function of the ESM sublayer is to support the EPS bearer context handling in the UE and in the MME
The ESM comprises procedures for:
- the activation, deactivation and modification of EPS bearer contexts; and
- the request for resources (IP connectivity to a PDN or dedicated bearer resources) by the UE.

EPS bearer contexts can remain activated even if the radio and S1 bearers constituting the corresponding EPS bearers between UE and MME are temporarily released.

Default and dedicated EPS bearer contexts can be modified. Dedicated EPS bearer contexts can be released without affecting the default EPS bearer context. When the default EPS bearer context is released, then all dedicated EPS bearer contexts linked to it are released, too

The UE can request the network to allocate, modify or release additional EPS bearer resources. The network decides whether to fulfil a request for additional resources by activating a new dedicated EPS bearer context or modifying an existing dedicated or default EPS bearer context.

Two types of ESM procedures can be distinguished:

1) Procedures related to EPS bearer contexts:

These procedures are initiated by the network and are used for the manipulation of EPS bearer contexts:

- default EPS bearer context activation;

- dedicated EPS bearer context activation;

- EPS bearer context modification;

- EPS bearer context deactivation.

2) Transaction related procedures:

These procedures are initiated by the UE to request for resources, i.e. a new PDN connection or dedicated bearer resources, or to release these resources:

- PDN connectivity procedure;

- PDN disconnect procedure;

- bearer resource allocation procedure;

- bearer resource modification procedure.

When combined with the attach procedure, the PDN connectivity procedure can trigger the network to execute the following transaction related procedure:

- ESM information request procedure.

A successful transaction related procedure initiated by the UE triggers the network to execute one of the procedures related to EPS bearer contexts. The UE treats the start of the procedure related to the EPS bearer context as completion of the transaction related procedure.

When the UE or the network initiates a transaction related procedure, it shall include a valid procedure transaction identity value in the message header and set the EPS bearer identity to "no EPS bearer identity assigned".

Attach request is an EMM message.

Attach request is at Layer 3 in UE. It is send together with RRC parameters indicating the selected network and old GUMMEI.

Few things :-

-- GUTI : Globally unique temporary identity.

-- GUMMEI : Globally unique MME identifier. This consists of PLMN id, MME group Id, and an MME code. MME code is used in the eNB by NAS node selection function to select MME.

Once Attach request reaches eNB, eNB creates enter Initial Context setup function. The communication between eNB and MME is over S1 interface and S1-AP is protocol used.

Initial Context Setup Procedure : 36.300

eNB will send S1-AP initial UE message along with NAS service request, which is nothing but Attach Request. (FFS)

This will trigger MME to send Create session request. SGW will send a session response. Once the session response is recieved MME will send a S1-AP Initial Context Setup Request along with NAS message, which is Attach Accept. This message also contains EPS bearer QoS, EBI and TEID for SGW for user plane.

eNB will send Attach accept message to UE. UE shall store QOs. APN will be provided to UE if it is not aware of.

The UE may provide EPS Bearer QoS parameters to the application handling the traffic flow(s). The application usage of the EPS Bearer QoS is implementation dependent. The UE shall not reject the RRC Connection Reconfiguration on the basis of the EPS Bearer QoS parameters contained in the Session Management Request. UE may recieve an IP address too.

UE sends RRC message to eNB, indicating the completion of procedure.

eNB sends Initial Context Response message which includes TEID of the eNB and address of eNB. In the mean time Ue sends Attach complete with EBI.

After the Attach Accept message and once the UE has obtained a PDN Address, the UE can then send uplink packets towards the eNodeB which will then be tunnelled to the Serving GW and PDN GW.

Upon reception of both, the Initial Context Response message and the Attach Complete message in, the new MME sends a Modify Bearer Request (EPS Bearer Identity, eNodeB address, eNodeB TEID, Handover Indication) message to the Serving GW

3GPP TS 23.401 Annex E : LTE Qos To Pre Rel 8 QoS mapping

PMIP, LTE, CDMA and Mobility

2009-08-15T15:30:00.001+05:30

Last night we played a game of Cricket. I was returning home on my wonderful bike cruising at just over 105 KMPH for a stretch of 5 KM. With all the adrenalin kicking in and air gushing through ears I suddenly realized something. Can I receive or make a call at this speed? I dint test it though, but I believe people do test these scenarios. What if I am moving from one base to station and other? How smooth will the handover be? I will try to do some tests. I am a sensible driver and care of safety. Will do tests under guidance of experts. So relax. :)

I read a report from Unstrung which says Verizon will start commercial deployments of LTE in 2010. Boston and Seattle are the selected cities. Now, Verizon 3G network is CDMA EVDO based, which means there is no GTP in packet core. PMIP is the the protocol used in CDMA and Wimax, as far as I know. So looking at LTE network, lets guess how Verizon might deploy the network. I would say the MME and SGW (s11 interface) will be a GTP based interface, which is obvious. But S5/8 interface might have PMIPv6 running. If S5/8 interface is GTP too then I there might be problem converging Verizon 3G network with LTE(?). This leads to more questions. Lets say Verizon is using ALU 7750 rotuer with SGW blade and PGW blade.

First question : Will both the blades sit in the same router? Is it a good idea?

Second question : WIll these blades be generic? One firmware for GTP and other for PMIP? I believe the technology will be software controlled, just like the cisco routers.

Third question : How many interfaces are we looking at in a single SGW blade? Two interfaces are minimum, one towards MME and other towards SGW?

Fourth question : Can I combine both SGW and PGW functionality in single blade? PMIP and GTP will be software controlled, so will combining both SGW and PGW make any sense or will that violate the specs?

Just few thoughts! Let me know what you think.

Ok, I am not a big twitter user or fan. But I sport a small twitter box here (right side), do keep checking it. I usually put something related to technology there, you really dont have to follow me, the box there gives all the info. Incase you want to follow me on twitter here is the link : http://twitter.com/wiredNwireless

Customer is God!

2009-08-08T23:04:00.001+05:30

This is slightly off the track from usual stuff I write in the blog, but I feel it is very important and it is one of my interests too. Excuse me for doing so. Kindly go ahead and have a read, there might be some thing for you in the post. :)

With 2+ years of work experience I will not say that I have seen everything, but I will say that I have seen enough to quote that "Customer is God". You might be a guy sitting in lab and lost in your world trying to do something, but you should realize that you are working on something which will be sold to customers. You may be a entrepreneur or working for some organization, but the ultimate goal is to reach the customer.

In the present situation where every one is hit by recession, customer retention is the most important aspect of any organization. Holding to your customers by reducing the prices might work for few ,but I would say invention is important in retention. The customer expectations are growing day by day and we should be on our toes to deliver what customer wants rather forcing customer to use what we develop.

It take the whole organization to satisfy customer needs, not just bunch of marketing guys. Now that I am a tester I am the second point of contact to the customer. The first contact will be with support which might escalate the issue to the QA if required. So when I actually start writing my test plan and test cases I will keep in my mind the so called "Customer Use Cases" and make sure that piece of software or hardware works accordingly. The software or hardware should function the way the customer wants it to not the way we want it to. There can be a trade off. Development and R & D may come up with wonderful things but if the product is hard to use then effort is lost. My point here is customer satisfaction is not one mans job, but it takes the whole organization. Customer focus should be one of the key aspects of an organization. One unsatisfied customer might bring you huge losses.

I was going through my facebook messages some time back one guy said he recently bought an IPTV at his home. There was an immediate response to his message by one of his friends saying even he has an IPTV and they started discussing about the brand, support etc etc. Both of them were happy with the service and they exchanged good words for the company from which they purchased the IPTV. Now what happened here is visible to all their friends. So when I want an IPTV i would go for the brand which my friends bought because they have already used it and are pretty happy with it.

On the other hand I had bad experience with my mobile connection. I use a XYZ connection (I am a good guy so I am not mentioning the brand here :). I already did the damage I could do ) . I wanted them to enable Voice Mail service, unfortunately they were unable to do it. They dint even give a proper reason for it. Then I had problems calling my dad. When ever I dial my dad's number there is only 1 in 10 chance that I can make it through the first time. I am tired of their service. All my efforts in calling there customer care resulted in nothing but frustration. Unfortunately I cant move to another service provider. My number is spread across all my contacts and is printed in my business cards. Now if somebody asks me which service provider they should go for, when getting a new connection, my response would be "Don;t go for XYZ" . This is strange, instead of suggesting a service provider I am asking them not to go for XYZ. I will always give a bad response when somebody asks me about XYZ. Now I have few friends and they have few and the chain continues. Because of my response there is good chance the XYZ might loose many customers. This is what I am saying, one bad customer might screw the whole thing up for you. This is very much true in every market.

Now why did write this. I was browsing through and came across a website called "Customer experience board". There was a report from them with title "Service Invention to increase retention". The executive summary of the report actually made think in this direction. I recommend you to go ahead and download it. Read it, there might be something in for you to. If you are service provider then it is a must read. Take a look at the numbers.

The below numbers are from reports and they make so much sense.

"The biggest sources of customer pain are said to be unmet needs and expectations (63 percent), followed by product/service usability and complexity (42 percent), billing errors (44 percent), as well as quality or relevancy of service or product oﬀerings (31 percent)."

Now I want to emphasis the point that I am not here to promoting things. I write things which make sense to me and the above summary really made some sense in a way that I myself have seen changes in my organization. The process for support escalation have been minimized and there is lot of customer emphasis going on. The processes have been simplified when there is customer involved. I my self have pushed the regular work aside to solve the problems of the customers. I am not in position to say big things but if you want to make some money treat your customers as Gods.

Hope I managed to say what I wanted to say. :) Let me know your thoughts, I will be glad.

MyPhone

2009-08-06T23:15:00.001+05:30

Phones! Yes, I love the technology.

My interests in mobile phones started two years ago. Since my child hood I was technology addict. We used to watch youtube videos of Surface Computing and think that is the next generation. One day my friend showed me a video of a gadget which was working based on touch inputs. Untill then I only knew that ATM's and few computers could be operated by touching the screen. This was two years ago and that video blew my mind. Off course I am talking of the great "iPhone" & "iPod". I was luckily in US when the first gen iPod was released in 2007. I remember the trips to Best Buy and Fry;s almost everyday and asking the sales guys when I can get my iPod. After 7 days I could lay my hands on one of them and it was brilliant. I got home with it and the whole college and office was running behind me to get a glimpse of it. I enjoyed every moment of it. :) That was my first contact with Apple and I started loving its technology. Then I got a MacBook (An award! wow!) and I loved it even more.

Having said so much about Apple, I should say I am not an Apple fanboy. I love Nokia when it comes to phones. Some how iPhone never impressed me. In January this year I decided to buy a smart phone. So I started my search. New phones were being launched and I was pretty excited with all the things going on in the mobile world. Nokia, Apple, Palm, HTC..all lauched their new phones. But ..but ...but.... there is still no phone which actually satisfies all my fantasies. So I framed up a picture of "MyPhone".

MyPhone is combination of several phones. MyPhone has the features which are handpicked by me. So how does this MyPhone look and behave, what does it have internally. Lets dig in.

MyPhone is combination of four phones. Nokia N97+HTC Touch Pro 2+Palm Pre+iPhone. Pick the best in these phones and make a new phone which becomes MyPhone.

MyPhone is designed like a HTC Touch Pro 2. It has a solid QWERTY Keyboard which slides out to the left. The Screen can be adjustable. The keyboard is nicely designed, feels robust and easy to use. The keys light up when pressed. The build of the phone is like N97. Hard and Robust! How ever I dont like the way key board is designed in N97. But the slide out mechanism in N97 rocks. It feels so solid, but I would still prefer a adjustable screen instead of just one angle. So the design and form factor of MyPhone will be like Nokia N97 with a HTC Touch Pro 2 key board and adjustable screen.

When it comes to hardware MyPhone will feature a powerful 800 Mhz processor with 256 MB Ram. I am not much into processor technology so I will leave the processor to be selected by experts, but I insist it to be a high speed one. 800 MHz sounds pretty good and 256 MB of Ram will just give the boost. MyPhone will feature a 3.5 MM headset jack with a Micro USB and memory card expansion slot. It will have 32 GB of internal memory expandable to 48 GB. Just like N97. MyPhone will also feature a removable battery.

When it comes to taking pictures and recording video, MyPhone will feature a 5 MP cam with auto focus and powerful flash. It will record a HD quality video. MyPhone will be a robust phone which makes its presence felt when in your hands.

MyPhone will also feature a touch screen. The touch will be a capacitive touch unlike N97. Touch screen would be like iPhone with an excellent response. A scroll of phone book or play list will be like magic. So MyPhone will have HTC Touch Pro 2 design with Nokia N97 form factor and iPhone as a touch screen. Movement from normal to landscape mode will be like magic..iPhone accelerometer?. MyPhone will also feature a virtual key board just for one those times. Zoom in and zoom out can done by pinch on the screen. Flicking through photos will be amazing.

MyPhone will run apps like Palm Pre. Each app will run as a card which will make the phone a true multitasking phone. Moving from app to other will be just like the way we do in desktop. Web browsing will be just like the one in iPhone and a pinch can zoom in or zoom out the page. MyPhone will also feature VPN so that I can connect to my office network.

Oh yeah, MyPhone will also feature Wifi with WPA 2, a GPS receiver and a FM transmitter. Maps and Photos can be tagged using GPS. MyPhone will also support flash which makes web browsing a great experience. Email will be fun, all the email clients can accessed at one place just like in iPhone.

All this will come at a good price, some where around 750$ including all the taxes.

If any body is manufacturing the kind of phone I mentioned above then let me know, I will be the perfect one to test it.

Final comments: In my the view the perfect phone has still not arrived. I love the N97 form factor but the resistive screen, application response time and processor makes it not a great choice. On the other hand iPhone does those like a magic but it doesnt have a external key board. Moreover iPhone just can do multitasking. Palm pre looks small. The screen isnt big enough and some how it doesnt suite me. HTC on the other hand seems great, but Windows on mobile... nope .. sorry. How about Android based phones? I never looked at them carefully, may be its the time now. So the "buying phone this year" decision is put on hold till next year. Moreover I am a victim of recession and just cant afford an expensive device now. I will be stuck with the below phone for a while and try to get the home button of my iPod fixed, the damn thing is not working for past 3 months :(

Let me know how MyPhone looks, I will be glad.

3GPP Radius Part2

2009-08-02T15:05:00.000+05:30

Some time back I wrote about 3GPP Radius. This is continuation of it.

What I said in the previous post was UE sends the authentication details in PCO field of Create PDP context/Create default bearer to GGSN/PGW. GGSN/PGW looks at that field and creates a Radius Access Request and sends it to a AAA server. AAA server can accept or reject the request. Its plain and simple. Lets look a little further.

IP address allocation: It would be interesting to see if Radius server can assign IP addresses to the UE. When a GGSN sends access request to AAA server, AAA server can respond to the request with access accept by placing an IP address in the Framed-IP field. This way we will not have to maintain a IP pool in GGSN, some processing reduced. GGSN can send the IP address received in Access accept to UE in PDP response message. So radius server will maintain a pool of ip addresses to be assigned to each UE and I believe it would be easy to maintain too.

The IP address can be returned to the radius server in Accounting Stop message. Once AAA server receives accounting stop it can free that ip address and assign it to other UE.

Accounting: I am quite not sure about it but I think accounting is done based on MSISDN. If so AAA server can maintain a table mapping MSISDN, IP address allocated, number of packets/octets in and out. Charging can be done based on this data. More over we can have static values of IP addresses to be assigned based on MSISDN. Assign this IP address to this MSISDN. Basically MSISDN becomes a kind of MAC address (?).

I believe most of the service providers do the way I mentioned above, if not I would be happy to know the other techniques.

FreeRadius : I am impressed. Simply superb is the word. I used Free Radius extensively in past few days and my god its just sweet. 100 requests at a time and still counting. What I did was create a local ip pool and when ever there is access request, reply with an IP address. It works superb. What I dint do was SQL Ip pool. I believe we can do Accounting scenario mentioned above pretty easily. (Log MSISDN, IP address, Accounting Packets/Octets in and out). The only problem with local IP pool was returning the IP addresses. IP addresses were not released when accounting stop was received. I tried every possible way but nope, it dint work. But Sql IP pool is supposed to work fine, I havent tested it but I believe it works fine. I dint try assigning IP addresses based on MSISDN too. Hope it works.

Thats pretty much it. Comments are always welcome.

Oh! Wish you all a very happy friendship day!

Arrg!!....June revision

2009-07-31T22:34:00.000+05:30

Just when I thought my life has become easy I see a new revision of 3GPP Release 8. It just cant get any more frustrating.

The idea was 3GPP Release 8 would freeze in Dec 2008 and there will be a bug fix version of it in March 2009. Oh no no, March doesnt have all the fixes, there comes a new revision in June. And guess what, GTP-C header has changed a bit. Seq no is now 3 bytes long and spare is 1 byte long (it was 2 and 2 respectively in march). Is it a good idea to jump on to june version of the specs now? or will have a new version of spec in next couple of months? any more bug fixes? Darn! I hate software.

Hey, does anybody know how to keep track of it these changes or 3GPP guys just meet when ever they feel like and bring out the new spec? I searched the entire 3GPP web site but couldn't get the details I wanted.

If you feel the same frustration I am feeling comment saying frustrated, if you are irritated say irritated. :) (Just kidding!)

FreeRadius + 3GPP Radius Part 2 next.

VoLGA: Take 1

2009-07-27T22:24:00.001+05:30

This past weekend I was tired of doing exciting stuff so I decided to get a printout of VoLGA Requirements and started reading it. The stage 1 document is sweet and nicely written in 13 pages. Considering my small brain, here is what I could understand.

VoLGA: Voice over LTE Generic Access : - I will refer it as V. VoLGA is just too much to write every time.

The whole idea of V is to make SMS and circuit switched calls possible over LTE. Rocket science! Dah! There is so much fuss about LTE that people actually forgot the fact that mobile phones were first designed to make calls. Some how I am strangely "attracted" to V. I started reading every possible post on internet about V when it was launched. I myself checked the forum almost once every day to see if there was any draft. Then came the first draft and before I could download it there were reviews about it all over the web by industry pundits. Nevertheless this is what I could grasp from stage 1 doc.

V resembles the 3GPP Generic Access Network (GAN) of which I have no clue. So there is a new network element inserted between EPS and CS network. This device will make CS calls and SMS possible over LTE. For V, all signaling and user plane traffic is fully transparent to EPS access network. This means EPS will see all V traffic as normal user plane traffic over suitable EPS bearers. If there is a EPS bearer then it means there is a UE initial attach. Cool.

V can work with both Iu-Mode and A-Mode giving full access to 2G/3G CS network. V provides handover from E-UTRAN to GERAN/UTRAN CS network. Handover the other way is not supported in Phase 1. For V to work there has to be few changes in UE. First, UE shall support CS signaling over EPS bearers. UE needs to be capable of supporting V services with serving PLMN. UE will be able to use EPS default bearer or connectivity for V service discovery, or a dedicated PDN connection. The same applies to signaling and user traffic too. That means a UE can use default or dedicated bearer for V service discovery, CS signaling, SMS and user(voice) traffic. QoS for EPS bearers must be supported else the call quality might go bad.

VANC : VoLGA Access Network Controller : manages UE's connection to V service. It will interface with MSC using the standard A or Iu interface.

V doesn't impact EPS much. All it needs is proper QoS, charging policy and header compression on user plane(?).

I believe the above is what I could make out. I will start reading the stage 2 and post architecture and stuff soon.

Questions : Am I missing something here or no one is talking about it? How in the world does CDMA circuit switched calls work over LTE? I mean V is all about GSM evolution talking to LTE, then what about the CDMA networks? How will LTE and CDMA work together for CS calls and SMS?

Have anything to say, feel absolutely free to drop in a line.

Tracking Trends!

2009-07-22T22:24:00.001+05:30

Something hit me today. GTPv2 is not exciting any more, because I figured it out and understand things there is pretty easy now. Read this.

I want to start looking at different things and blog about them instead of dumb GTP. So I figured out my wish list. I had a wish list before but this is new one. :-D

Volga: Volga is first the thing I want to track. My future posts post will be mostly on this technology. I have to say I absolutely have no idea about its architecture. I only know that in LTE circuit switched calls and SMS is not possible at this moment. CS fall back is not a good option and IMS is still far away. So this weekend its all about Volga.
Femtocells: I want to rip these femtos apart and look into the devices. Specs? Architecture? etc etc
OFDM/MIMO/64QAM: Radios signals and systems are my favourites since my engineering days. I still remember those days when I soldered a FM transmitter and broadcasted Eminem songs in college and apartment. I was pretty good with modulation, sampling and shannon;s theorems. TCP/IP made me forget them completely. I need to start reading radio.
S11 interface: The code which I wrote in last post needs to move ahead. I am working on dragging my friend in.
Mobiles: I am not a expert here. But I love to read reviews about them and may be post a few.

If something crazy is on my mind why should it be on blog and irritate the subscribers? There are few times where I said something would happen and it never happend, something I said I would do and never did. So I thought if I blog about what I want to do, I actually might do just for the sake that I wrote about it.

Wish me luck and have a nice day.

LTE user plane

2009-07-19T16:21:00.001+05:30

Questions. More questions!

This time focus in on LTE user plane and SGW load balancing. Picture this. eNB, MME and SGW. Control plane between MME and SGW, User plane between eNB and SGW controlled by MME. Perfect.

SGW : How many interfaces does an SGW have. When I read about ALU bringing in LTE device (ALU 7750) I went and checked out their website. Read here. A SGW is going to be a blade which will sit in a 7750 router. So is the case with Cisco. When I say a blade, how many interfaces will that blade have? Next how many blades can sit in a device? And how will the blades be controlled? Each blade will have its own software to control?

More elaboration: MME sends out a create session request to SGW. It picks up the SGW from SGW selection function. So a create session request will be sent to a particular SGW. Particular SGW mean a "Particular IP". Now SGW may respond to request with a Create Session Response. Note that Create Session response has FTEID of SGW, where in SGW can send information about another blade of SGW that is another interface, if it exists. That way SGW can balance the load? Say if 7750 has 10 SGW blades, then how will this load balancing be done. One main interface and having several other interfaces? How are all these blades controlled? Because there has to be a TEID mapping.

User Plane: When we say user plane is segregated from control plane, what do we mean here. Is user plane traffic going to hit the same interface of SGW where control plane is established. If yes, how good is this implementation? Again same question, if there exists multiple blades how are they controlled?

Below find SGW with little boxes which are nothing but blades. Will the blades be controlled by master software running on SGW or will there be a software for each blade. Say if two blades have to communicate how will they do it?

How it started: I am working a product which is supposed to test SGW. As there is no SGW available to test dev guys gave us a dummy implementation of SGW. Here both user plane and control plane traffic hit the same interface. I decided to write my own SGW. The problem is my SGW runs on a linux box and I wrote only control plane communication. After control data is supposed to flow. I noticed that data was hitting the same interface where control plane was established. Thats where my quest for separating the data and user plane began.

Folks any clue on how it is done? I really want to know how is the SGW made. Your reply's are appreciated and greatly welcomed.

LTE S11 Interface : GTPv2 Code

2009-07-12T16:07:00.001+05:30

I had an amazing vacation with family and friends. But past week took the juice out me. Too much was left out at work and I opted for time off at really crucial time of release. O2 must be feeling bad about us for delaying the software. Anyway, since the beginning I always wanted to do some practical stuff with LTE. I started talking to my good friend and colleague Gopal about doing some thing in LTE. We started with writing GTPv1 code, simulation between SGSN and GGSN for a start. Ok, he started writing the code and I was giving him the IE's and stuff. We did something there. Then we started working at LTE. S1-AP was my protocol of choice, we wrote one handover scenario there, though it was pretty crude. By then my friend who is code freak figured out memory management in C. Then I become little well versed with S11 interface of LTE so I started understanding the code he wrote. First problem was figuring out header file. We had to define structures for every IE and allocating memory to each IE was big pain.

Nevertheless we figured it out. Last week I spent couple of hours day to finish the S11 interface. Ok, so what I did in simple words.

I wrote MME, SGW and GTPv2 communication among them. The messages are

Create session request (MME---->SGW)
Create session response (SGW---> MME)
Modify bearer request (MME---->SGW)
Modify bearer response (SGW---> MME)
Bearer Resource Command - for dedicated bearer activation (MME---->SGW)
Create bearer request (SGW---> MME)
Create bearer response (MME---->SGW)
Bearer resource command - for dedicated bearer teardown (MME---->SGW)
Delete bearer request (SGW---> MME)
Delete bearer response (MME---->SGW)
Delete session request (MME---->SGW)
Delete session response (SGW---> MME)

The code is written in C using UDP socket programming. There are three file.

headers.h -- Contains all IE structures
MME.c --- This is the client for us, as it initiates the communication
SGW.c -- Responds to MME.

If you want to try the code you will need a linux box (I would prefer two linux boxes, one to run mme and other to run sgw.)

Compile the code

----- gcc mme.c -o mme

------ gcc sgw.c -o sgw

and run the code. Please note that you will need to run sgw first.

--- ./sgw

--- ./mme

Use tcpdump to capture the packets on localhost.

--- tcpdump -xXvvv -w temp.cap -s 1500 -i l0

If you want to run the code on two linux boxes, you will need to modify the ip address in mme.c. Find the below section in code and change 127.0.0.1 to ip address on which sgw is running.

ggsn.sin_family=AF_INET;

ggsn.sin_port=htons(2123);

ggsn.sin_addr.s_addr=inet_addr("127.0.0.1");

Thats it. Run the programs and capture the packets. You should see all the messages mentioned above. You will need latest development version of wireshark to view the messages. Get it here. Note that wireshark still doesnt dissect the messages completely. Atleast you can see the IE's.

Know limitations : Messages contains IE's which are mandatory and conditional to S11 interface. Create session request doesnt send ULI IE. All the values used in the code are dummy.

I will keep building this code for new messages (mobility next).

There it is guys, have fun and do let me know how it looks. Any changes or suggestions are always welcome.

Update: Guys, I started a project in google code for this. The code is uploaded there (Look at downloads section). Uploading the code in rapidshare was the most dumbest idea. Rapidshare! for uploading the code? Dah! I must have been really stupid.

Link : http://code.google.com/p/s11interface/

Download it, use it or do what ever you feel like. I have published to code under GNU GPL license. I will keep posting the code in download sections and if you want to share anything(patches) feel free to send it to me. I would be happy to update the patch in source. If any body want to be part of administering let me know. I really have no time to manage it, so I am not looking at version control and stuff.

Femtos for India?

2009-07-04T21:45:00.001+05:30

This is just one of those days I day dream. I have few thoughts popping in my head for a while, in fact I started thinking about them during my vacation. I am living in corporate world for past 2 years and I totally understand the network requirements there. But one week stay in my home town with my parents made think about the network in little different way.

Status in India right now : Non Corporate : Majority of India is middle class. With kids going to schools and colleges internet has become a revolution in India. People are using broadband connections offered by local vendors. Couple of years back came the DSL revolution. Every one started adopting to the DSL and ADSL. This brought in major players like Reliance, Bharti, TATA into access network zone. I have a BSNL DSL connection in my home here in Hyderabad. Couple of months back I purchased a wireless access point and my dad is enjoying his wireless connectivity. This applies to most of the homes in my apartment too except that they are still running on DSL without wifi.

OK. Why this back ground check. I started understanding femtos. There are new laptops coming into the market which are pretty cheap. Easily affordable by college students and people like my dad who just needs to check couple of websites and emails. This is my target segment for the discussion.

3G spectrum auctions are still due in India. LTE is still not mature for deployment. So India has to stick to HSPA+ with may be 3 Mbps speeds which is pretty good for the above market segment. The whole idea is "Replacing Wifi with Femtos". Is it possible. Consider this. There are 100 flats in my apartment. Every home has minimum of 2 mobile phones and one computer. Recently people have started purchasing small laptops. So what if, say Airtel, deploys a femto for my apartment giving out mobiles and wireless internet. A laptop with Airtel sim card built in providing internet over HSPA is perfect for my dad and off course great for college students. What will Airtel get by this? 200 mobile connections and 100 internet connections which is definitely good.

I see few difficulties here. First is the laptop with HSPA cards inbuilt. Is it good to have a inbuilt card or should service provider stick to usb sticks? If the cards are inbuilt customers are at the feet of service provider which I hate. But USB sticks are still not affordable, they are expensive. People would go for a DSL connection rather then investing heck lot on a USB. Next is femtos deployment. Migrating customers from one service provider to other is tough as there is still no number portability available. BTW number portability "may" arrive in India by end of september.

Is there is a way to manufacture HSPA cards which can work with any network? Can we make them as generic as wifi cards? Will technology allow it? My whole point is can India deploy femtos skipping wifi boom. A park with femto zone for people to relax and read on web. Coffee pub with femto. Apartments with femto. Isnt it wonderful? Corporate would any way go for them. Femtos will definitely be big hit in corporates.

What do you folks think? Am I completely out of mind or just started to loose my mind. I would like to know your views on this.

Wired N Wireless Unplugged : For a week

2009-06-26T11:29:00.004+05:30

Guys, time for me to take a break. Going on a vacation next week and the idea is to stay away from a computer, as much as possible. Will post some intersting and hand's on experiments when I come back. Adios!

LTE X2 Handover without SGW change

2009-06-20T20:02:00.000+05:30

Ok, here it is. First handover scenario in LTE. Inter eNB handover without SGW change which spec calls as X2 handover. X2 ah! sounds like X-Men. :) This handover is pretty simple to understand. This handover is explained in 23.401 section 5. What we have below is a UE is moving from source eNB to target eNB. Since the control plane is already established there will be just a change in the user plane.

One thing. We are taking of scenario where source eNB and target eNB are both connected to same MME and SGW. If the physical connection changes then we will be looking at different handovers, which I will cover soon.

When UE moves from one eNB to other eNB, the eNB's communicate about the UE information using X2 protocol which unfortunately is out of my scope at this moment. :( The target eNB sends path switch request, which I believe is a S1message, to MME indicating that UE has changed its location. Here the bearers come into picture. Say UE has default and dedicated bearers established before the handover. Simply these bearers are to be updated for the new user plane. So MME sends out Modify bearer request which includes all the bearers information and new eNB information to SGW. That is Modify bearer request will contain EBI's (of default and dedicated bearers) and target eNB FTEID. All the info is sent in a single message which SGW may accept and return the response.

After that SGW sends out an end marker message to source eNB. End marker is a GTP-U message which indicates that there will not be any further user plane traffic on that TEID. Here we are sending this message to source eNB to tell that there will not be any user plane traffic sent to it from now on, offcourse for that UE. Source eNB send the same to target eNB. Rest two messages complete the handover.

What about QoS? I dont believe that there will be any qos change in the above scenario. How ever the qos information will have to be sent if the SGW changes. Then there may be new Qos values. This is for further study.

QoS is turning out to be quite complex then i thought. Research is one and will post more.

Thats pretty much it. I hope it was useful and comments are welcome.

LTE QCI: Must checkout

2009-06-18T23:19:00.001+05:30

Folks

Checkout 3G/4G blog by Zahid. It has very interesting picture defining QCI and end to end bearer QoS. Link here.

LTE Handovers

2009-06-15T23:00:00.001+05:30

Handovers is one of the major parts of LTE learning curve. I just started reading how handovers work in LTE. This post is to set expectations on how handovers work and give an over all idea. Handovers are defined in 3GPP TS 23.401 (Refer to the latest spec).

Before moving further lets understand the variables here. UE is the one which moving from one place to other. Along with it the network changes and so devices. For this post lets just stick on to LTE, that is we are talking only of Rel 8 LTE network here. As the network changes the possible devices that can change are eNodeB, MME and SGW. I usually consider that SGW and PGW are built in single device so they will always be placed together. Let me put a LTE network architecture here for reference. Too lazy to make a powerpoint slide so pulling one from internet :) (Image source : www.catapult.com)

UE is moving from one place to other connecting to different eNB. In turn eNB's are conne cted to MME and SGW. MME is connected to SGW and eNB's. So when UE move from one area to other the following combinations arise : -

Inter eNB handover or Intra MME handover : That means UE is moving from one eNB to other where both eNB's are connected to same MME.
Inter eNB handover with MME change : Here UE is moving from one eNB to other where each of the eNB's is connected to different MME's.
Inter eNB handover with MME and SGW change : Here UE is moving from one eNB to other where each eNB is connected to different MME and SGW.

The above are my naming conventions, we will go to what spec calls them in a minute. There are two things we need to understand. First is the way connections are made. eNB is connected to MME for control plane signaling and also has a direct link connected to S-GW for user plane traffic. So when there is change in eNB there is possibility that SGW handover has to be performed. Next is the way these devices communicate. Here is where we will have to look at two new protocols S1-AP and X2-AP. S1-AP is used for communication between two MME's and X2-AP is used for communication between two eNB's. GTPv2 is present in S11 and S5/S8 interfaces. eNB may communicate with MME using S1-AP protocol too.

3GPP Spec defines the above three scenarios as:

X2 Based Handover : without SGW change and with SGW change (3GPP TS 23.401 Clause 5.5.1.1)
S1 Based Handover : with eNB, MME and SGW change (3GPP TS 23.401 Clause 5.5.1.2)

We need to understand the UE and EPC behavior with respect to default and dedicated bearers. I dont believe that there will be any change in QoS with handovers.

This is brief over view of LTE handovers. In coming days I want to discuss each handover in detail with call flows. Unfortunately I will not be able to dig up S1-AP and X2-AP protocols in details but will do my best. I feel we will jump into few more handover scenarios as we proceed.

Until then adios. Comments are welcome.

Bearer Aware Applications?

2009-06-13T13:26:00.002+05:30

This is it guys. The final truth. Bearer aware applications. I honestly dont know if that term means anything other than applications running on a mobile choosing the bearers based on the network availability. Am I right? Lets consider that I am correct and move ahead with the discussion.

For past few days I was trying to understand the end to end working of LTE, though my scope is limited to EPC. The whole bearer creations, modifications etc seems very good, but it is very much required to understand how they exactly effect the communication. Everything originates from the mobile device and network has to support what mobile is asking. I want to take iPhone here as an example. Lets say we are browsing web on the iphone. With Skype integration in iphone now we can make voip calls too. So I keep browsing and find something really interesting on streaming protocols which I want to share with my cousin in Germany. So I open up skype make an voip call start discussing the streaming project with him. This is the scenario.

We need to consider few things here. FIrst is the network support, then mobile phone operating system and third is the applications. With LTE the above scenario is very much possible, so we have network support. I want to have my basic default bearer established. When I start Safari a dedicated bearer is established with HTTP TFT. When I launch skype and start making a voip call I will have another dedicated bearer established with QoS supporting voice. The network is intelligent enough to handle this.

Its quite clear to me how the network behaves. The problem I am facing is mobile phone operating system. The bearers are established based on the mobile phone, lets call it as UE, request. So the question is does the UE OS support establishing multiple bearers. That is the support has to be present in the OS? So I did some research. What I found was little annoying. Few google searches landed me into nokia developer forum where people were discussing the same thing. Do N-series of Nokia support establishment of multiple PDP contexts? (referring to 3G here). I read developers facing problems while activating secondary pdp context. A link said Symbian v0.9.3 has support for establishing multiple PDP context to multiple APN;s and multiple secondary PDP contexts support. This mean the UE OS should have the support for establishing the multiple bearers. This support can be used by applications to establish individual bearer for each of them to run. The question here is how the network will be evaluated? Meaning how will application understand when to create a new bearer? Will mobile OS talk to the application here? How is the design?

This is where I am stuck.

Moving further. I am part of corporate network. Say my company decided to have its own APN and run an email server. So mobile phones can connect to that APN and have a dedicated bearer with a QoS established to retrieve emails. How is this done? If we buy a mobile phone the APN settings are pre-configured. Which means when ever you connect to the network a connection to mentioned APN is established. If my company has to have its own APN, where is that APN to be placed. When I was configuring Cisco 7200 I had a option to configure multiple APN's with a single GGSN IP address. This mean if organizations want to have a APN they need to talk to the service providers? Is there a way to have an APN outside the service provider network? The big question is am I asking the right questions here or missing something?

Folks, any ideas? Search is on to find answers to above.

This actually makes me think of changing my career line for while. May be I should go work for a service provider for a while, understand things better and get back to software. Anybody offering :-D

GTPv2 Spec New Version

2009-06-10T21:05:00.001+05:30

Folks, there is a new version of GTPv2 spec (3GPP TS 29.274 v 8.2.0) checked into 3GPP website few days back. There are not many changes from the previous spec but I suggest you to start looking at the new version. It can be found here.

Are we looking at Interop here?

2009-06-09T20:16:00.001+05:30

I had tough time sleeping yesterday. Its getting very humid here. I was thinking about LTE, mobiles and networks lying on bed trying to sleep. Then suddenly something stuck me, not literally :).

Can this blog become a platform for Interop testing? Interop is way too big for my blog. But if we think again, most of the people who visit blog are engineers. Developers, testers etc. We look for the answers in the web there by landing at the blog. You may get an answer or may not. But you are the one who is writing a piece of code for LTE to work.

I must say that 3GPP specs are no less then a rocky mountain to climb. Specs are not clear or they may not refer to each other well or we might have problems trying to figure out the things. But we will come up with a product. We try to interop our devices with other vendor devices. We may succeed or fail utterly. The beauty of 3GPP is we often fail. :) A simple IE can make things worse. Few months back we shipped our GTPv1 solution to one of our customers. We had release 7 Direct Tunneling feature implemented. Our product was well tested and everything looked great while doing in house testing. When customer started executing tests we fell flat on our face. When ever there was an update message indicating direct tunnel was passed, the vendors GGSN responded saying mandatory IE in-correct. Damn! A second look at the packets revealed that one of the IE's was sent wrongly. A simple 2 byte value wrongly sent and the whole feature was biting dust. We identified the problem and fixed it in no time. I went back to the specs and read them again. I misread the word "shall" to "may" and everything went wrong. The IE "shall" be sent was written not "may" be. That lead to a confusion, leading to issues in Interop.

Thats how critical Interop is at the ground level. Pickup a SGSN from one vendor and GGSN from other and there "may" be interop issues. So how do we validate the interoperability? Buy a test tool? May be. Or identify your potential customers and make sure that your product is working well with them. That needs a lot of planning.

with LTE interop is becoming big. Interop not only between multi vendor devices but interop between various technologies is coming into existence. There is some time left for interop but I am closely following the stories. The biggest problem in telecom industry is collaboration. Its tough for two companies to work hand in hand or share atleast share the information. This is what I know. Say, one company is manufacturing eNB and other is exclusively manufacturing EPC then who will do the interop testing between eNB and MME. Network service provider? The engineers will definitely have sleep less nights. I really want to see how interop will progress.

These are just some thoughts based on my experience. I am still a novice in the industry trying to get the big picture. :)

Corrections/Comments are welcome.

LTE : Bearer ID

2009-06-06T14:35:00.001+05:30

EPS Bearer ID is similar to NSAPI from GTPv1. There is not much of a difference. I tried to capture the EBI;s in the below call flow. Its pretty much self explanatory. EBI values are always assigned by MME. So MME sets a EBI value for default bearer and sends it to SGW in Create Session request. In the same way MME again assigns the EBI value to dedicated bearer in Create Bearer Response.

One thing to note is LBI, which is Linked Bearer Id. This is the default bearer ID. It used to link dedicated bearers with the default bearer. Bearer Context : EBI mean that EBI value is sent in Bearer Context IE. EBI Id is of 4 bits, which mean we can have 16 bearers. But there are 5 reserved values which I could never find out. So we will have altogether 11 bearers.

PTI is procedure transaction ID. PTI, LBI and TAD will give us a unique combination to create/delete a dedicated bearer.

Correct me if I am wrong. Comments are welcome.

LTE: QoS (Part 2)

2009-06-03T20:14:00.001+05:30

In the last post we understood TFT and QoS behavior in LTE. What's important to understand is bearers are all about achieving QoS. The whole concept of bearers is just to provide proper quality of service to user thus enhancing the quality of experience. So what we know at this point is a default bearer always exists once the UE is switched ON, until it is powered off. Any other bearer is a dedicated bearer which is associated with a TFT and QoS.

In this post lets try to understand few more terms like TAD and QCI (QoS Class Identifier). The concentration is on UE requested bearer creation/modification procedure.

Basically a UE may request for dedicated bearer. Lets say we are running a web browser on our mobile phone. Now UE wants to establish a dedicated bearer for that. So UE sends out a request for bearer creation procedure. MME here sends sends out a bearer resource command which includes LBI (Linked Bearer ID), PTI (Procedure Transaction ID), TAD (Traffic Aggregate Descriptor), QoS.

TAD is a partial TFT. It includes packet filters for a particular L7 activity. In our case as we are running HTTP, TAD will include packet filter for HTTP. Now MME will send this information to PGW. Now PGW understands that a dedicated bearer has to be created for running HTTP traffic. So it sends out a create bearer request with TFT (HTTP) and QoS. Here UE may request for particular QoS.

Lets look at QCI here. QCI field may be mapped to a diff serv. (Assured Forwarding?) . Say QCI value is set to 2 which indicates a particular class of assured forwarding, say AF12. We have MBR and GBR values in QoS which may be set to some value.

Once MME requests create bearer request it responds with a bearer response creating a dedicated bearer for HTTP activity with a QoS value (QCI: AF12). After this our mobiles should start displaying the web pages with a speed equal to Roger Federer's ace. :)

Now, you remember that your boss has asked something and you want to email him. So another dedicated bearer for this email? Ok... lets stop and understand this a bit clearly. If your http dedicated bearer QoS is fine for running email then we may just use it. But you need to indicate this to PGW. So we do a bearer modification (update?) procedure instead of bearer creation. MME here will send bearer resource command with TAD mapped to email traffic, say IMAP(?). But note here the QoS is same. (QCI still is AF12). PGW looks at this and thinks that may be I should update the dedicated bearer to include IMAP too. So it sends out Update bearer request with newly added TFT for IMAP. (We already have TFT for HTTP). MME responds to saying OK.

At this point we have two activities running on single dedicated bearer. That means when there is no QoS change a single bearer may be used to run various traffics. This brings us to square one where I said bearer is all about QoS. Once email is done, PGW may remove that TFT (IMAP) from dedicated bearer.

This was just a short post to look at things when no QoS is changed. I will try to analyze the whole QoS with various IE's in coming days.

I hope it was useful and as usual comments are greatly welcomed.

LTE : QoS

2009-05-30T13:27:00.001+05:30

After a lot of brain storming I got close to understanding the QoS concepts in LTE. Over all QoS concept is clearly (?) defined in 3GPP TS 23.401 Clause 4.7. I wrote two posts some time back, one on Bearer lever QoS and other on EPS bearer. The idea is look at them together.

Before we proceed, there is term that needs to understood. TFT : Traffic Flow Template.

TFT is set of all packet filter associated with an EPS bearer. A packet filter may be associated with a protocol. A packet filter Identifier shall be used to identify a packet filter. For eg: lets say we have http traffic. Now we all know that destination port in Http is 80. So a packet filter can be created indicating destination port to 80 and this packet filter may associated with a ID which is nothing but packet filter ID. Now several packet filters can be combined to form a Traffic Flow Template. EBI+Packet filter ID gives us a "unique" packet filter Identifier. The following is the TFT for FTP protocol.

Let now try and understand the Bearer level QoS. Bearer level QoS is associated with a bearer and all traffic mapped to that will receive same bearer level packet forwarding treatment. Bearer level QoS parameter values of the default bearer are assigned by the network based on the subscription data received from HSS.

In LTE the decision to establish or modify a dedicated bearer is taken by EPC and bearer level QoS parameters are assigned by EPC. These values "shall" not be modified by MME but are forwarded transparently to EUTRAN. However MME may reject the establishment of dedicated bearer if there is any discrepancy.

Bearer QoS IE

Now we understand TFT and bearer QoS. A default bearer may or may not be associated with a TFT. But a dedicated bearer is always associated with TFT. So we have bearers, the qos values for them and TFT which indicate what type of application should run over them. This defines the LTE QoS. We have Uplink TFT and Downlink TFT which are used by UE and PDN in respective transmissions i.e uplink or downlink.

Lets look at following paragraph carefully.

The UE routes uplink packets to the different EPS bearers based on uplink packet filters in the TFT's assigned to those EPS bearers. We have evaluation packet precedence index in packet filter which is used by UE to search for a match (to map the application traffic). Once the UE finds a match it uses that particular packet filter to transmit the data. If there is no match UE transmits the data on bearer to which no TFT has been assigned.

Let understand this with an example. Say UE wants to transmit a FTP and HTTP data. Say a dedicated bearer is created for transmitting HTTP data and say FTP is to be transmitted on default bearer. So dedicated bearer is associated with a TFT which has packet filter for HTTP. This packet filter has a evaluation precedence. So when UE wants to send HTTP data, it looks at the evaluation index. After that it matches if that packet filter is for HTTP or not. Once it finds a match it uses that bearer to send HTTP traffic. Note here that Packet filter is associated with TFT and TFT is associated with dedicated bearer and dedicated bearer QoS is set. So a proper traffic shaping/ forwarding mechanism will be used to transmit the HTTP data. And FTP is transmitted over default bearer as there is no packet filter associated for it.

Thus is the QoS mechanism in LTE. I hope the post is clear. Feel free to write to me in case of any clarification.

I hope I got it right else correct me. Comments are greatly welcomed.

LTE : Tunnel Identifiers (GTPv2)

2009-05-24T12:37:00.001+05:30

From my LTE mind map in the last post, understanding bearers is the most important thing. I must agree with one my readers who pointed out that "MindMap" looks horrific and ugly. I know. I am very bad with sketches and that was the main reason for me to drop off from choosing medical sciences. :) Rest apart, lets get going.

First step in understanding bearers is tunnels. How are tunnels identified? I want to elaborate this post with complete LTE call flow where two activities are running on mobile phone, one is using default bearer and other is using dedicated bearer.

The trick is not to understand the whole message in single gulp. Divide the message into IE's and take up the activity of each IE separately. Note that we are only dealing with mandatory and conditional IE's here. The concentration is on TEID and FTEID fields.

The above call flow is self explanatory and is pretty simple. We see two fields TEID and FTEID. TEID is the field present in the GTP-C header and using which the tunnel is identified. FTEID is Fully Qualified Tunnel End Point Identifier. This IE is used to send TEID/GRE Key and IP info of sending entity.

Create Session Request is always sent with TEID value set to zero. There are bunch of other messages where TEID value is set to zero and sent. Refer to spec for details. The S-FTEID is senders FTEID. MME sends this field with a TEID value say 0x111 and IP address of it to S-GW.

Once S-GW receives this message it learns the IP address of MME and TEID field to be used in the response. S-GW creates create session Response message with TEID value 0x111 and S-FTEID. S-FTEID value here contains the TEID value,say 0x222, to be used by MME and IP address of the S-GW.

At this stage the control plane for communication between MME and SGW is set. MME uses TEID: 0x222 for sending any control plane info to S-GW and S-GW uses TEID 0x111 to send any control plane info to MME.

Once the control plane is set traffic has to flow. Modify Bearer Request is used to indicate the S1-U interface of eNB. So S-FTEID (S1-U eNB FTEID) value is set to say 0x0a + IP address and sent to S-GW. S-GW replies with its S1-U interface FTEID. At this stage the TEID for the user plane are set. User plane traffic will flow using the TEID's exchanged. Thus the traffic flows on default bearer.

Bearer Resource Command is used by MME to request for a dedicated bearer. Once S-GW receives bearer resource command it initiates a Create Bearer request. Observe that same TEID field is used which was negotiated earlier. In create bearer request S-GW includes S1-U SGW F-TEID for user plane traffic.

MME sends a Create Bearer Response message with the S1-U eNB FTEID. At this point the a dedicated bearer is created and user plane traffic tunnel is negotiated. Dedicated bearer user plane traffic flows using the TEID's exchanged.

The interface described above is S11. This interface is mapped to S5/S8 and S1-MME interfaces. TEID are used to identify and map the tunnels in various interfaces.

There have been significant changes in the messages from Dec spec to March spec. The above details are with respect to March spec (3GPP 29.274 v8.1.1). I hope I got them correct. Else please correct me.

In next posts I want to look at the EBI fields and QoS. Comments are greatly welcomed.

LTE Mind Map

2009-05-19T22:01:00.010+05:30

I tried to plot a mind map of LTE. The major links are set and we need to start looking at individual thread and plot a granular map. I honestly accept that I am not an artist and ... here is how it looks (Definitely shabby).

If any of you are interested in working out more maps for individual threads, please write to me. I would be very glad.

Flickr link to the image here.

LTE : Open Technology

2009-05-17T15:53:00.002+05:30

One fine evening I was browsing through books in shopping mall. I saw this book called "What Would Google Do?" . I already knew about this, so i picked up a copy and started reading it. I am half way through. Amazon link here

Its an amazing book written by Jeff Jarvis. The book talks of google as a platform, as an elegant organization, as a paradigm shift to many. I totally agree with it. As I read the book I started comparing LTE to Google. Sounds strange but yes I started doing it.

Lets start with Google. Google started as a search engine crawling millions of sites. Slowly google became a platform to so many things. Google shared it revenue with its user by AdSense. Google very intelligently directs the users to their destination. Google takes inputs from users and gets better with every click. Google gave out the APIs to the developers to write applications over it. Google started to become a converging point.

So google is an open technology and every one is making money out of it.

Long Term Evolution. The vision of LTE is convergence. Single global standard for mobile communication. LTE is providing a platform for all the technologies to coexist and converge. Mark Zuckerberg of Face book once said "Communities already exists. They are looking for a platform to communicate better. Its a foolish thought to start/control a community". Facebook later opened to developer who wrote numerous applications over it thus increasing the popularity of facebook. This has made lot of money not only to Facebook but also to the developers. Same is the case with IPhone. So many apps over IPhone and apple is benefitting so are developers. These all are open technologies/platforms where every one is benefitted.

Similar to this LTE is giving a platform to 2G/3G Wimax, Wlan networks to converge. Thus helping user move from one technology to other seamlessly. I would say LTE is a open technology not controlled by single entity. Its becoming a platform for all the techonolgies/users/companies/developers. With high speeds are emerging devices. With emerging devices are emerging applications. With applications, developers are emerging. In this process a lot of money is flowing. So every one is earning. More and more people are opening up. The one who doesnt open up are gone. For example yahoo. Yahoo tried to control the media for a long and now its going no where.

When I started reading LTE 8 months back I found no technical information about it in the internet except for the 3GPP specs. Then I decided to start a blog and write about how LTE works. I am not an expert but I try to publish what I read. Later I saw people reading the blog and posting their comments. Now, people working on LTE are already there. My blog is just providing a way to communicate. So blog is an open platform. If I start controlling the platform I will loose my readers.

The future is Open. Ajit Jaokar of Open Gardens writes a lot about Open technologies and systems. I encourage you to read the blog regularly.

To conclude, get hold of the above book. Read it and try to see if your business fits in that line.

Comments are greatly welcome

Who Makes What: LTE Equipment

2009-05-08T09:57:00.001+05:30

Very interesting article by Light Reading. Must read.

LTE : Wishlist

2009-05-06T22:50:00.000+05:30

Off-late work is keeping me busy and I am not finding time to do much except for logging and verifying bugs. :) I have jotted down few things which I feel are pretty important to understand LTE technology much better. I call it the "Wishlist". These are my priority now.

QoS : QoS is top in my list. I had tried posting something before but I still need to work more. There are acronyms like TFT , TAD's to understand. I still have couple of questions from readers to answer.
Dedicated Bearers: I still dont get the dedicated bearers completely. I am almost there. I wrote two posts on dedicated bearers sometime back and I almost understand how they work now. (Post 1 and Post 2)
3GPP Radius: I think I have got this one. There is not much difference in LTE and UMTS/GSM implementation of Radius authentication except for changes in few acronyms. If you pick up the free radius from freeradius.org you might just be able to authenticate user in GSM/UMTS domain as the dictionary for 3GPP is already available. But for LTE you might need to tweek something to make free radius work. I wrote something on Radius sometime back but more to follow.
Interop with 3GPP/Non 3GPP: LTE is all about convergence. So lots of networks will be coming together. There is need to understand how this will happen. This is not a high priority on the list but interop with 3G is definitely on the charts.
LTE Security aspects : I am still taking baby steps here. A lot needs to be done. :)

There is an event coming up on LTE. LTE World Summit in Germany from May 18th to 20th. Its one even that anyone working in LTE should watch out for. Unfortunately I cannot attend it. I am neither rich to afford a flight ticket nor my company is ready to sponsor. So attending one of these events is in my wish list too. :) There will be another LTE world summit in Asia, even that will be held in Hongkong in month september. It is very disheartening to see that nothing is happening in India. I know there are lot of people working on various LTE projects in India but 4G is not going to be deployed any sooner in India. I wish somebody takes up and initiative and arrange a meet in India where people from various companies can share their interests and show case their products. If I am unaware of any such events please enlighten me.

Having said 4G is far far away in India, 3G isn't coming any sooner too. THe spectrum auction again has been postponed. As elections are going on we might have to wait for the new government to form for spectrum to released. But BSNL has launched its 3G services which is not used by corporates. Lets hope we can have 3G at least by this year end.

I have a big question. Now that release 8 has free-zed how will any work on it will continue. Say something needs to changed in spec how will it be done. All changes go in Rel 9? That shouldn't be. Any ideas?

Right now all I can think of is LTE. But the question is pursuing it as career is a good idea? 3G took 7 years to deploy and work properly. LTE might 10 years. What after it? New technology? I dont know? Still thinking in that aspect as I have to move on with my career too.

I am in desperate need of tool using which I can make notes. I use windows PC in office and publish all my blogs from mac. So if I have to make a quick note on Mac which needs to be accessed on my office PC is getting difficult for me. I am right now using Google Notebook but I would really like to see some think like sticky which can used to make notes from any where and can be accessed any where. I am planning on buying a smart phone soon. So I will have three devices to make notes. I would really appreciate if any you know of any tool or service.

And finally I should say that my blog is not well maintained. Information is spread all over the blog and there is redundancy or lack of info in some posts. I apologize for that and will get better as the time passes by.

As always comments and emails are greatly welcome.

LTE: Few thoughts

2009-05-01T19:20:00.001+05:30

I have jotted down few things about LTE that were going through my mind.

Backhaul: With LTE wireless bandwidths shooting sky high there is a need for more stronger backhaul. To say we need a intelligent backhaul. Many proposed MPLS but still there is work to do.

Second biggest challenge is making the customer to move to LTE. At present we have 2G and 3G. With LTE there will three technologies running together and making the customers to move to LTE will be a hard task. To the customer technology doesn't matter. All consumer will ask for a high speed and ensured quality of service no matter if it is LTE or HSPA or HSPA+.

LTE has excellent data capabilities. But voice on LTE is still to be finalized. No matter how much bandwidth you give to a consumer voice is a must. Voice will stay. Is Volga just doing that?

From the operators perspective the timing has to be right to move to LTE. With the whole world on HSPA now, operator has tough time choosing the technology they want to move to. Should they move to HSPA+ or wait and move to LTE.

Migrating is one challenge, data plans and charging is other. With LTE how will be the data plans and charging. Cost per MB of data should go down else it doesn't make any sense to go to LTE.

LTE as a technology is challenge in itself. The specification are not clear yet. More over there is LTE Advance coming. Technology has to mature which will definitely take time. There were some issues with roaming when 3G was deployed. Such issues should be handled with LTE.

Making devices is a big challenge.

LTE shouldnt be deployed too early nor too late. The timing has to be proper.

Spectrum: Getting spectrum is tough task. I am not much aware of the spectrum issues and at what spectrum LTE is planned to deploy. Could some one enlighten me in this area please? :)

With LTE I feel there will be convergence and open devices will emerge. Take the latest skype integration in Iphone or N97 for example. With skype integration dependence on operator for voice call will fade away. For me using conference bridges in US through skype is free. So with the latest skype integration I can do a skype call from my device. This will reduce the dependence on laptop for skype call. Isnt it a nice Idea. Do keep your eyes open in this "Open Cloud" area. Share with me similar ideas.

Finally LTE is not only a technology, its business. Every has to share and eat. If single person eats everything he will die of indigestion and others die of starvation. Co existence is must.

Free free to post your thoughts here or email me.

LTE : UE initial Attach

2009-04-28T22:25:00.002+05:30

Source : 3GPP TS 23.401 & 3GPP TS 29.274 [LTE Bibles :) ]

Lots of people asked me about UE initial attach. So I thought of blogging about it. Initially I was confused about how UE attaches to the network. With specs talking of default bearer and dedicated bearer every thing went over head. I must also say that both specs which I mentioned above are not referring to each other very well. It will definitely take some time figure out how things are working in LTE. I remember attending a webinar conducted by Light reading where the presenter asked a question regarding the clarity and completion of specs. No wonder more that 60% of attendees voted to option saying specs are still not clear. Well understanding UE initial attach proves the point. Lets move ahead.

Now the LTE is all IP, there has to be always a bearer established. That means when the UE comes up it has to get an IP address. When you switch on the UE, UE sends out a attach request to eNB with bunch of IE's attached. Kindly refer to 3GPP TS 23.401 for IE's that UE send out. Note that this is encapsulated in RRC and and send to eNB. eNB forwards the request to MME. Here is where GTPv2 starts. So you should be having 3GPP TS 29.274 open. When MME receives attach request for the first time it puts in few more IE's and forwards the request to SGW, which forward the request to PGW. Now to understand initial attach better lets restrict ourselves to communication between MME, SGW and PGW. The communication between them takes place using GTPv2 protocol.

If you open 29.274 spec you will find create session request. This is used in UE initial attach to create default bearer. Confusion!! The message type is "Create Session Request" and it is creating "Default bearer". Yes, it is like that. This message is also used for other things like " UE requested PDN connectivity", "Tracking area update" etc etc. Spec clearly gives where this message is to be used. Ok! So we have Create session request being sent asking for establishment of default bearer. MME reads the APN and forwards the request to proper SGW, which again forwards it to PGW. Now PGW responds to the request with a response. This is "Create session response". The response contains Ip address to be assigned to the UE, default bearer ID etc. PGW sends the response to SGW which in turn forwards to MME.MME forwards the response to eNB which in turn sends it to UE. With this response we have a default bearer established. This how a create session request look like.

Refer to spec for detailed IEs. Now that you have default bearer established traffic from UE can start. Note that this bearer is always established. It gets torn down only when the UE is powered down or goes out of network area or something. After the default bearer is established traffic has to flow. Since we have direct tunneling, which means the user plane traffic flows from eNB to SGW without the intervention of MME. This is S1-U interface. To indicate this interface to PDN GW, MME sends out a modify bearer request immediately after the default bearer is created. So modify bearer request modifies the default bearer user plan. PGW responds to modify bearer request with modify bearer response. If the response is success then we have user plane setup for traffic flow. This completes the default bearer establishment from my perspective. You can sends other messages based on your implementation. But I think these two requests are must. So how does the call flow look like?

I hope the figure is visible. After that default bearer is established, we can ask for other bearers based on the applications running on UE. These are called dedicated bearers. I was completely confused when the dedicated bearers came in. I could not co-relate the dedicated bearer to secondary PDP context. But later I figured out the trick. I wrote about the dedicated bearers sometime back. Now if you go back to 29.274 you will find create bearer request. This request is used to establish dedicated bearers but not default bearer. I was very confused when I read the dedicated bearers are network initiated. The thing is since LTE is all on IP and if you are receiving a call then network may initiate dedicated bearer to forward that call to you. This doesnt mean that UE cannot ask for dedicated bearers. UE can ask for dedicated bearers by sending out bearer modification command but UE cannot send create bearer request. Bearer modification command will make PDN trigger a dedicated bearer. If you have just started reading the specs it will take a while to understand things, but once you figure out the specs it goes smooth.

I hope the post was useful. Will post more as time permits. As usual comments/questions are greatly welcomed.

PDN GW selection function

2009-04-27T20:52:00.001+05:30

Source : 3GPP TS 29.401 Clause: 4.3.8

The inspiration to the post is one of the comments raised by my blog reader. What does this PDN GW selection function mean? How is PDN allocated to the user? Can a UE have multiple PDN connections? Lets take each one step by step.

UE creates attach request and sends it to eNB. eNB forwards the request to MME. During Initial attach a UE "may send" APN in attach request. If UE sends attach request without an APN then MME will contact HSS which returns a default APN. If UE sends attach request with APN then HSS will return the corresponding PDN GW identity which may contain PDN GW IP address or PDN GW FQDN. If the case is where UE already has a PDN connection ,then UE "must" send the APN in attach request. Once the PDN GW is identified then S-GW forwards the attach request to that PDN GW.

So if UE is running two applications app1 and app2 and if app2 wants to use new pdn connection, then it sends out attach request by placing the new APN address. Basic idea is a APN is bound to PDN.

Alternatively a UE may ask for dedicated bearer establishment to the PDN GW. Then app1 can run on one bearer and app2 can run other bearer, but both are pointing to the same PDN. Note that network initiated dedicated bearer can only initiated by PDN GW to which UE has attached to.

Comments/Questions are greatly welcomed.

Mobile blogs and future: From Open Gardens

2009-04-27T15:53:00.002+05:30

Iam a follower of Ajit Jaokar's blog Open Gardens. Few days back he posted an very interesting post on Mobile blogs and its social apects. I encourage you to go ahead and read it. This is the link. My fav line from the post is "You should never trust a specific blog.You should read blogs from a variety of sources and then make up your own mind"

Session Initiation Protocol : My experience

2009-04-25T14:33:00.000+05:30

Back in 2006 I was trying to design/code an application over SIP. Well I was trying to submit it to my college so that I could graduate. When I presented the abstract my professors went crazy. The whole college said are you nuts. What is SIP? Being an electronics student how could you work on computers were some questions floating around. In India, especially in electronics fields professors are very unhappy with students. More and more students are turning towards computers leaving the Microwave and Core electronic fields. So with limited knowledge of what is SIP i got through the abstract stage. Then I had to understand the protocol.

SIP was very new in India in 2006. There were few people working in SIP application development, atleast I was told so. I started my design and I wanted to have 3 tier architecture with oracle data base hooked in instead of flat file. I had very fancy ideas I should say. 3 months of time and very limited programming knowledge I turned to Java. I liked Java. It was pretty easy for me to code there. I used Java swings to create the interface, JSP to create webpage and JDBC:ODBC to connect to database. The design seemed good.

But there was huge problem. How do I get SIP stack? Jain SIP was at my rescue. Open source Java API's for SIP. Search for the same in internet, its pretty nice API. So I was equipped with everything. What should I implement was the question.

I had these in my mind : User Agents (SIP phones) and SIP Proxy server. But as I said I wanted to have a very fancy application I thought of doing more. So I thought of implementing Do not Disturb/Call forwarding/RTP. Note that till then my idea was just to write the SIP signaling but not to code the actual voice. But RTP gave me breather and I did voice later. Ok , all set so how does my SIP phone look like?

Isn't it beautiful! I customized the buttons dial panel. I am huge fan of Matrix and green over black for messages was direct lift from matrix. :) People now say UI looks like skype but I had no idea what skype was back then. I loved the project so much that I continued the same in my Masters. For my post graduation I implemented conferencing/IM/Draw board features. I ran everything once and it worked just perfect. It was triumph moment when I submitted project in my engineering and masters. Everyone were impressed. Cool. I passed out with flying colours.

The above screen shows two SIP phones communicating and SIP proxy routing the calls. I tired checking in the code in source forge but I had no idea how to do it. I left it there. As always, I am happy to share the code with you guys if interested.

Write to me or comment here if you would like to know more.