Telecom Tutorials by Samir Amberkar

Session Management (SM) [Under GPRS]
» SM - 24.007/8 «
» GPRS description - 23.060 «
» AT command - 27.007 «

In GSM, CC layer (sub-layer of CM layer) takes care of setup/teardown of a voice call. For user packet data transfers, "session(s)" need to managed similarly in GPRS. Obvious difference is when voice call is active, voice data transmission remain in progress. But in a session, data transmission may not be present all time, but session can still be active.

For GPRS, Session is PDP context and its associated parameters like NSAPI (Network Service Access Point Identifier) for distinction among PDP contexts for same MS on network side, QoS (Quality of Service) for properties of packet connection, Address for identication in PDN network, APN (Access Point Name) to mention GGSN to which user data need to sent etc. The procedures related to Activation, Deactivation, and Modification are taken care by SM (Session Management) layer, sub-layer of CM layer.

User can create a context with AT command +CGDCONT, mentioning required QoS and activate it with +CGACT command. Note that QoS is "negotiated" with network - which mean, though requested, network can provide different QoS than requested.

GPRS also has the concept of Secondary PDP contexts. A secondary PDP context is simply additional PDP context associated with primary PDP context. Secondary PDP contexts has same NSAPI (and so same PDP address) as their primary PDP context. Secondary PDP context is useful when MS need different QoS for same PDN and NSAPI (same PDP address). When there are multiple contexts associated with one address, there should be a way for GGSN to filter out packets so that they get associated with correct PDP context. This is achieved by having Traffic Flow Template (TFT) for each or all but one context. TFT can be mentioned with AT command +CGTFT. TFT is sent transparently to GGSN by SGSN.

Below diagram shows PDP context states:

PDP context remain active till MS is detached from network or PDP context is explicitly deactivated by user or network. Typically, GGSN will have only limited range of (or pool of) PDP addresses that it can use to associate to PDP contexts. To make way for new PDP context activation requests, GGSN may deactivate few PDP contexts not used for long time.

To activate PDP context, SM sends ACTIVATE PDP CONTEXT message to network as shown in below.

MS

BSS

SGSN

GGSN

Activate PDP context request The MS sends an Activate PDP Context Request (NSAPI, PDP Type (IP/X.25 etc.), PDP Address, APN, QoS, PDP Configuration Options) message to the SGSN. PDP Configuration Options are sent to GGSN transparently. PDP address is left blank for dynamic address else static address can be mentioned. Authentication/Ciphering SGSN validates the request with subscription records (received from HLR). Based on current load, subscribed QoS profile, SGSN comes out with negotiated QoS. Sends request to GGSN. Create PDP context request GGSN creates a new entry in its PDP context table. GGSN may need to talk to PDN, performing PDN specific procedures related to QoS, PDN address etc. GGSN may reject GGSN negotiated QoS. The SGSN inserts the NSAPI along with the GGSN address in its PDP context. If the MS has requested a dynamic address, the PDP address received from the GGSN is inserted in the PDP context. The SGSN returns an Activate PDP Context Accept (PDP Type, PDP Address, QoS Negotiated etc.) to MS. Create PDP context response Activate PDP context accept

As evident, user data transfer can only be done only when PDP context is active.

References: GPRS in Practice by McGuiggan

Copyright © Samir Amberkar 2010

§ §

GMM «

GPRS Index

» SNDCP