Tuesday, December 8, 2009

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!

12 comments:

Anonymous said...

My understanding is that direct tunneling is going to live network, which follows the LTE trend, differ the control and user planes.
In the live network, there are smart phones that trigger UE initiated 2nd PDP context to require more QoS and TFT, but I guess not so many.
For the network initiated 2nd PDP, there is no UE supporting it right now, but it is coming soon since operators are interested in it. It gives operations the oppertunity to have full control of QoS and user data traffic.

Santosh said...

Hey thanks!

I only know one service provider that has implemented direct tunneling.

I also went through few smart phone developer forums and found that none of them could activate secondary PDP context. This was some time back though.

It would be very interesting to see how the initial LTE networks will roll out.

Duncan Salerno said...

Santosh,

There have been quite a few announcements on the Internet about providers using I-HSPA, which is the Nokia name for direct tunnel.

Anonymous said...

hello,

regarding direct tunneling in legacy UMTS: there is support for direct tunneling in SGSN and RNC without having the need for Rel. 7 as it is purely between SGSN, RNC and GGSN. So I can assure you, there is direct tunnelling ongoing without Rel. 7. You just push the RNC and the SGSN fellows and you get it. I know at least one network in Central Europe, close to the Alps which has Direct Tunnelling.

Regarding Secondary PDP Context, it is an Rel. 99 NAS feature, 24.008 is the Spec. I don't see any problems for Rel. 99 UE's in supporting it, actually it is a mandatory feature. Just the Core may not be so smart without IMS to go for Network Initiated PDP Context Activation so called NICA. Here we need to wait for PCRF. Or if the UE is clever it can go for MS Initiated Secondary PDP Context. It is just a matter of SGSN allowing/supporting it.

kind regards.

Anonymous said...

Hello,

I was tested multiple primary and multiple secondary PDP context in UMTS environment with direct tunnel implemented. All of them simple working. There is no need to worry about smart phone support.

Regards,

Santosh said...

Hey, great news. I am assuming that you tested them in the real network.

Greg said...

Santosh,

Yes it was end-to-end test. Unfortunately due to handset limitation user plane was restricted.
There was other aspect of this tests as well for me. I was interested if secondary PDP context can act alone without primary PDP context.
Unfortunately there is nothing in 3GPP about this issue. After couple tests with couple of different handset/chipsets i found out that this is per chipset's vendor implementation. Qualcom delete all related secondary PDP if primary PDP was deleted - Infineon keeps all remaining secondary PDP. Probably this is also different per chipset implementation but I'm to lazy to test each and every handset and software version :)

During the direct tunnel test Sony Ericsson C905 was used capable to open max 4 PDP either primary or secondary ( at least one primary PDP context is mandatory)
Here is simple AT commands recipe:

Test 1 - Simple one primary and one secondary PDP

Primary PDP config
at+cgdcont=1,"ip","internet"
at+cgeqreq=1,3

Secondary PDP config
at+cgdscont=2,1
at+cgtft=2,1,0,"8.8.8.8.255.255.255.255"
at+cgeqreq=2,2,64,64

PDP context activation
at+cgact=1,1
at+cgact=1,2

PDP context deactivation
at+cgact=0,1
at+cgact=0,2

Test 2 - Max amount of primary PDP

PDP definitions
at+cgdcont=1,"ip","internet"
at+cgdcont=2,"ip","internet"
at+cgdcont=3,"ip","internet"
at+cgdcont=4,"ip","internet"

PDP context activation
at+cgact=1,1
at+cgact=1,2
at+cgact=1,3
at+cgact=1,4

PDP context deactivation
at+cgact=0,1
at+cgact=0,2
at+cgact=0,3
at+cgact=0,4

Test 3 - Max amount of secondary PDP

Primary PDP definition
at+cgdcont=1,"ip","internet"
at+cgeqreq=1,1

Secondary PDP definition
at+cgdscont=10,1
at+cgtft=10,1,0,"8.8.8.8.255.255.255.255"
at+cgeqreq=10,2,64,64
at+cgdscont=11,1
at+cgtft=11,1,1,"8.8.4.4.255.255.255.255"
at+cgeqreq=11,3,64,64
at+cgdscont=12,1
at+cgtft=12,1,2,"1.2.3.4.255.255.255.255"
at+cgeqreq=12,3,64,64

PDP context activation
at+cgact=1,1
at+cgact=1,10
at+cgact=1,11
at+cgact=1,12

PDP context deactivation
at+cgact=0,1
at+cgact=0,10
at+cgact=0,11
at+cgact=0,12

Regards
Greg

Santosh said...

Greg! Awesome, thanks!

One more thing, a secondary PDP context is always tied with the Primary PDP context. Which means if the primary PDP context is deleted then automatically the secondary PDP contexts should be deleted. Bug with Infineon? :-)

More over there can be only one Primary PDP context per APN. So in Sony Ericsson case I am assuming that you had 1 Primary PDP and 3 Secondary PDP contexts. However there can be 4 Primary PDP contexts too, but they need to established for different APN's.

A special thanks for the AT commands, I am still trying to understand them.

Cheers, Santosh

P.S:- If the above information is not supposed to be made public, let me know.

Greg said...

Santosh,

Direct tunnel is nothing new for European operators and widely implemented now. This is pure money for them to obtain more capacity on SGSN implementing simple modification in RANAP and GTP.

Regarding your statements about relation between primary and secondary PDP. This is partially true.
You really need Primary PDP session to create Seconday PDP but then Secondary PDP using other unique set of identification parameter (GTP: NSAPI, TEDI ; RADIUS: SessionID, ChargingID, Ga: ChargingID, Gy: SessionID and set of others AVP and VSA) and then can act without Primary PDP. Only TFT ( Traffic Flow Template) and QoS profile make difference between Primary and Secondary PDP.
From the other hands it will be nice to close all related Secondary PDP when Primary PDP is terminated but for me the most important thing is knowledge about difference in chipset vendors implementation. There is also message for each end every AAA designers to start using MultiSessionID identifier not SessionID for PoD and CoA messages in case of zero balance users or QoS modification.

Regarding multiple primary PDP session and same APN. The main issue is the behavior or USB and serial bus in terminal. Please remember - you can always open PDP via USB and then using handset embedded web browser open second primary PDP.
I was also able using same Sony Ericsson C905 open two primary PDP session connected over the USB cable to one Linux PC. The first PDP use /dev/USB0 the second standard /dev/ttyACM0. Then local configuration of routing help to chose which interface use to which destination IP.

Regards,
Greg

Santosh said...

Cool! Thanks for the info!

Harish Kulkarni said...

which operators suppose secondary PDP initiated from UE?.

It would be interesting to see how future applications exploit network intelligence while providing services.

SHRIDHAR GOUR said...

HI,

I have one query regarding Radio Bearer Setup.

Do network establish another Radio Bearer Setup for secondary PDP context or it uses already esatblished radio bearer?