Happy Holidays

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

LTE: Mobility Management States

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)

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!

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

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

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

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!

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?

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!

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

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

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?

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

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

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?

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

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

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

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

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!

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

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

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

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

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

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?

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)

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