Thursday, June 25, 2009

Wired N Wireless Unplugged : For a week

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!

Saturday, June 20, 2009

LTE X2 Handover without SGW change

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.

LTE_X2_Handover.jpg

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.

Thursday, June 18, 2009

LTE QCI: Must checkout

Folks

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

Monday, June 15, 2009

LTE Handovers

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)

LTE & SAE Architecture.jpg

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.

Saturday, June 13, 2009

Bearer Aware Applications?

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

Wednesday, June 10, 2009

GTPv2 Spec New Version

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.

Tuesday, June 9, 2009

Are we looking at Interop here?

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.

Saturday, June 6, 2009

LTE : Bearer ID

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.


LTE_EBI.jpg

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.

Wednesday, June 3, 2009

LTE: QoS (Part 2)

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.