Location Reporting!

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

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

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

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

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

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

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

GTP Version Fallback

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.

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.

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

LTE S11 Interface : GTPv2 Code

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.

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.