Piggybacking in LTE

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

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

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

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

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

Any thoughts?

LTE: 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.

GTPc V2

After a long time I have found time to write something. Lately I have been reading GTPv2 for control plane. I got a transfer in my project and I will be testing one our products for GTP v2. This would be our companies entry into wireless segment (LTE), though we have GTP v1 already built in. So GTPv2-C can be found in 3GPP TS 29.274 v8.0.0 (Release 8). GTPv1-U can be found in 3GPP TS 29.281 v8.0.0 (Release 8). A combination of this control plane and user plane will be used in LTE. Our customers are most interested in performace testing of their devices, so we implement these two protocols and will give them a flexibility to run wide range of L7 protocols over the tunnels. Note that all this goes in single box. Isn't it interesting? Coming back to GTPv2-C, it will be used in EPC signalling interfaces S3,S4,S5,S8,S10,S11 and S16. Here is the general format of GTPv2-C Where: - if T = 0, TEID field is not present, k = 0, m = 0 and n = 5. - if T = 1, TEID field is present, k = 1, m = 5 and n = 9. - Bits 6-8 represent the Version field. - Bit 5 is spare, the sender shall set it to zero and the receiver shall ignore it. - Bit 4 represents the TEID flag (T). - Bits 3-1 are spare, the sender shall set it to zero and the receiver shall ignore it.

More Notes:

GTP v2-C messages shall be sent per UE on S3 , S10 and S16 interfaces GTP v2-C messages shall be sent per PDN Connection on S4 and S11 interfaces apart from the following exclusion Following GTP v2-C messages are sent per UE on S2 and S11 interfaces: - Downlink Data Notification/Acknowledgement - Stop paging

Traffic Flow Template information element is to specify the TFT parameters and operations for a PDP context.

My interests: - TS 29.281 v8.0.0 : GTPv1-U - TS 29.274 v8.4.1: GTPv2-C - TS 23.401 v8.4.2: GPRS enhancements for EUTRAN Access - TS 36.300 v8.6.0: EUTRAN Overall description. Stage2 - TS 29.060 v8.6.0: GTP across Gn and Gp interfaces I have some confirmation from our test tool. One traffic activity can create one PDP context. Other traffic activity may create secondary PDP context or use the existing context. Usually in mobiles we see only http traffic flowing, so there wont be a secondary PDP context created most of the times. Now I even have a confirmation from our test tool that secondary PDP are UE initiated. Correct?? Wrong? May be? But it makes sense now. One PDP context per traffic activity with particular traffic flow template. Super Cool. Then how does it work in LTE? Open Questions: How will the direct tunneling implemented in LTE? WIll there be a direct user plane tunnel established between eNodeB and PDN-GW? Do we still have PDP Contexts in GTPv2-C?Do we still have PDP contexts in GTP v2-C? How are secondary PDP contexts and dedicated bearers established? Are they network initiated or UE initiated?

I will write more about the protocol as I keep reading. Right now I have to go and train a guy for my older project.

March 14th : - Yesterday I had an eureka moment. I was not sitting in a bath tub though. My job project accelerated and we are expecting the software QA drop to be ready soon. Now GTP V2 is the bread and butter of LTE and I have to test our software for protocol conformance. Unfortunately there is no such tool. Even wireshark doesn't support version 2. So, my idea was to start writing a small custom tool which opens the V2 packet and reads the data and throws out pass of fail based on what it read.

But after a google search and second look at wireshark I found that people have started developing dissectors for GTP V2. Thats an incredible news. Even I found initial dissectors for GTP V2. I downloaded the source code and compiled. Hurray! Now my wireshark understand GTP C V2. Not entirely though. It just identifies the version field. Looks like there has to be lot of work done. I wrote to the dissector developer extending my help for testing the code. Haven't heard back though, but lets hope for the best. If you have any such ideas or anything to share just shoot a comment or email me santoshdornal at gmail dot com.

March 16th : AMBR : - Aggregate Maximum BIt Rate

This parameter refer to aggregate maximum bit rate for non-GBR flows.

APN-AMBR : THis is a subscription parameter stored per APN in HSS. This refers to maximum bit rate that can be consumed for all no GPR SDF's/SDF aggregates for this APN. This parametr is enforced by PDN-GW in downlink and by both UE and PDN-GW in uplink.

UE-AMBR: This parameter refers to maximum bit rate followed for all the non-GBP SDF's/SDF for this UE. This parameter is enforced in both uplink and downlink.

March 27th : Modify Bearer Request

I was wondering how is direct tunneling implemented in LTE. Well, there is a message called modify bearer request which doest it. Once the create session message is sent ,it is immediately followed by Modify Bearer request message indicating the user plane. Of-course this a control signal so this will be transmitted on S11 interface indicating S1-U interface. Now S1-U is manadatory, since DTI is by default in LTE, modify bearer request is mandatory alike GTP v1 where updated message is explicitly sent.

LTE Protocol Stack

LTE Control Plane
The control plane consists of protocols for control and support of the user plane functions:-

• controlling the E-UTRA network access connections, such as attaching to and detaching from E-UTRAN;
• controlling the attributes of an established network access connection, such as activation of an IP address;
• controlling the routeing path of an established network connection in order to support user mobility;
• controlling the assignment of network resources to meet changing user demands.

The Communication between MME and S-GW, MME and MME is taken care by GTP-C v2. This is again used to communicate with other nodes in UMTS and GERAN networks too. Eloboration soon!

LTE User Plane