I often wondered in the past what ‘Secondary PDP Contexts’ are good for in UMTS networks. I had a vague idea but never had the time to look up the details. These days I had and here’s a short explanation:
‘Secondary PDP contexts’ can be used to separate the real time data traffic from background or signaling traffic into different streams on the air interface while keeping a single IP address on the mobile device. This is done by an application providing the network with a list of IP addresses in a Traffic Flow Template. The mobile device and gateway router (GGSN) in the network will then screen all incoming packets and handle packets with the specified IP addresses differently, like not repeating them on the RLC layer after an air interface transmission error. This is transparent to the IP stack and the applications on both ends of the connection.
External providers of speech services such as Skype, however, do not have access to this functionality. A big advantage for operator controlled IMS services when things get wild on the air interface!?
Resources:
- Secondary PDP Context Activation: 3GPP TS 23.060, Chapter 9.2.2.1.1 (Rel 6)
- Traffic Flow Template Description: 3GPP TS 24.008, Chapter 10.5.6.12 (Rel 6)
Hi Martin,
The canonical example is starting to stream video while browsing the internet (e.g. YouTube). Or a click to call link being, well, clicked 🙂
Restating your paragraph above, the QoS profiles for the primary and secondary contexts can be different (and should be, otherwise I’d debate the utility)
The handset should be intelligent enough to spawn the secondary PDP context when required(/supported).
I could imagine that the utility of this is higher in a VoIP to handset environment, although I’d argue that we’d need support for multiple PDP as well as secondary PDP contexts in that case.
In the Push-to-Talk over Cellular (PoC) service which unfortunately did not get so popular in Europe the secondary PDP context is used exactly as you describe to seperate the control from the user plane. (see OMA Poc WG)
By doing so the Talk Bursts (RTP streams) that are real-time traffic and susceptible to latency are handled differently from the control (SIP) messages.