PDP Context Management

7.2 PDP Context Management

A PDP context contains routing information for packet transfer between an MS and a GGSN to have access to an external packet-switching network. It is identified by an exclusive MS PDP address (mobile's IP address). This means that the MS will have as many PDP addresses as activated PDP contexts.

A concept of secondary PDP context has been introduced in order to have several PDP contexts sharing the same PDP address and the same access to the external packet-switching network. This concept was introduced for multimedia applications where each medium type requires specific transport characteristics and is mapped into a specific PDP context. It is based on the traffic flow template, which is a filtering mechanism used by the GGSN to route downlink IP packets toward the appropriate medium within the MS.

A given PDP context is in the active state when this PDP address is activated for data transfer. Before transferring data between an MS and a GGSN, it is necessary that a PDP context be activated.

PDP context procedures have been defined in order to create, modify, and delete PDP contexts within the MS, SGSN, and GGSN entities. The SM protocol is used between the MS and the SGSN and the GTP protocol is used in the controlling plane between the SGSN and the GGSN for PDP context procedures.

7.2.1 PDP Context Definition

A PDP context provides access to an external packet-switching network through the PLMN network. The data associated with the PDP context is as follows:

• Access point name (APN). This is the reference to a GGSN.
• Network service access point identifier (NSAPI). This is an index of the PDP context that uses the services provided by the SNDCP layer for GPRS data transfer. Up to 11 applications over the SNDCP layer may be identified by the NSAPI parameter. The NSAPI parameter is present in the SNDCP header.
• LLC service access point identifier (LLC SAPI). This identifies the SAP used for GPRS data transfer at the LLC layer.
• PDP address. This identifies the MS address related to a particular PDP context. This field consists of several fields including the PDP type (IP or PPP), PDP address type (IPv4 or IPv6), and address information containing the IP address.
• QoS. This defines the quality of service related to a particular PDP context. Parameters related to QoS are described in Section 2.4.
• Radio priority. This specifies the priority level used by the MS at the lower layers for transmission of data related to a PDP context.
• Protocol configuration options. This defines external network protocol options associated with a PDP context. It may contain information about protocols such as the link control protocol (LCP), the PPP authentication protocol (PAP), the challenge handshake authentication protocol (CHAP), and the Internet Protocol Control Protocol (IPCP).

Several PDP contexts can be activated at the same time in the MS. This means that the MS is able to transfer or receive data at the same time for several applications. Each PDP context is identified at the MS level, at the SGSN level, and at the GGSN level by the NSAPI. This identifier will be used to identify the logical link within the MS between the SNDCP entity and the application layer. An NSAPI is associated with an individual PDP address. When the SGSN receives a packet from the GGSN addressed to an MS identified by its PDP address, the SGSN inserts the associated NSAPI in the SNDCP header. Thus when the MS receives a packet from the SGSN, it identifies the appropriate application layer from the NSAPI parameter included in the SNDCP header.

7.2.2 PDP Address

A mobile's PDP address (IP address) can be assigned statically at the time of subscription or dynamically when the context is activated, depending on the operator's choice. A PDP address assigned permanently is called a static PDP address while a PDP address assigned during a PDP context activation is called a dynamic PDP address. The dynamic PDP address assignment is provided either by the GGSN, which creates a new entry in its PDP context table, or by the PDN operator.

7.2.3 Traffic Flow Template

In the GPRS Release 99 recommendations, several activated PDP contexts may share the same PDP address and the same APN. This is not the case in the earlier releases.

Some applications should require at the same time several activated PDP contexts with different QoS profiles while reusing the same PDP address and other PDP context information from an existing active PDP context. For example, multimedia applications involve several flows (e.g., voice and video that request different QoS but the same PDP address and the same APN). As a result of several PDP contexts activated at the same time with the same PDP address and the same APN, the different multimedia application flows can be routed between the MS and the GGSN via different GTP tunnels and possibly different LLC links.

This means that the analysis of PDP address destination cannot be used by GGSN to determine the NSAPI of the terminated application. In order to route downlink IP packets toward the terminated application within the MS, the GGSN uses a filtering mechanism called traffic flow template (TFT) that is defined by a set of packet filters. If several PDP contexts are associated with a PDP address, a TFT is created by the MS to specify an IP header filter for each or all but one context. This mechanism allows for the association of one packet filter with one NSAPI that is the identifier of the PDP context.

Each packet filter consists of a packet filter identifier within a TFT, a packet filter evaluation precedence that specifies the precedence for the packet filter among all packet filters in a TFT, and a list of packet filter attributes. Each packet filter attribute is deduced from IPv4 or IPv6 headers. The MS will define values related to each packet filter attribute. These may or may not be combined later in a packet filter. Each packet filter contains at least one of the following packet filter attributes:

• Source address and subnet mask-IPv4 or IPv6 address along with a subnet mask;
• Protocol number/next header-IPv4 protocol number or IPv6 next header value;
• Port numbers-port number or range of port number;
• Security parameter index-IPSec security parameter index;
• Type of service (TOS)/traffic class and mask-IPv4 TOS octet or IPv6 traffic class octet along with a mask;
• Flow label-an IPv6 flow label.

A TFT is created for a new PDP context using the same PDP address and the same APN as an existing PDP context but with a different QoS profile. This new PDP context is called a secondary PDP context and is activated during a secondary PDP context activation procedure. After a TFT has been created for a new secondary PDP context, it is sent by the MS to the network during the secondary PDP context activation procedure. A TFT may be modified during a PDP context modification procedure initiated by the MS. A TFTis deleted when the associated PDP context is deactivated.

During packet transmission between the MS and the external packet network, the GGSN will compare the parameters of the IP PDU header with packet filters of the TFT. If a match is found between the IP PDU header and a packet filter, the GGSN is able to direct the IP PDU from the interconnected external PDN to the suitable activated PDP context identified by the NSAPI parameter. This is illustrated in Figure 7.17.

 Figure 7.17: TFT filtering mechanism.

7.2.4 PDP State

A PDP context may or may not be activated for data transfer. This is indicated by the PDP state.

A PDP state set to INACTIVE means that the PDP context does not contain any routing information for packet transfer between an MS and GGSN for a given PDP address. Data transfer is not possible in this state. A PDP state set to ACTIVE means that a PDP context is activated in the MS, the SGSN, and the GGSN with a PDP address in use and routing information for packet transfer between the MS and the GGSN. Data transfer is possible in this state. The MS will be attached for GPRS services to be in ACTIVE PDP state.

Figure 7.18 shows the transition between the PDP states.

 
Figure 7.18: PDP states.

7.2.5 SM Layer

The SM layer handles the PDP context procedures such as PDP context activation, deactivation and modification, and secondary PDP context activation, between the MS and the SGSN.

The PDP context procedures handled by the SM layer can be performed for a given MS only if a GMM context has been established. Otherwise, the GMM layer must establish a GMM context for the use of the GPRS-attach procedure.

All PDP context procedures processed by SM peer entities require a TBF connection on the radio interface.

7.2.6 PDP Context Procedures

7.2.6.1 PDP Context Activation Procedure

The PDP context activation procedure may be initiated either by the MS or the GGSN.

Initiated by MS

When an MS wishes to create a PDP context, it sends a PDP CONTEXT ACTIVATION REQUEST message to the SGSN with optional parameters such as the requested QoS, requested NSAPI, MS PDP address, protocol configuration options, and APN. The requested NSAPI is provided by the MS among the ones not currently used by another PDP context in the MS. A PDP address is provided only if the MS already has a static address.

Security functions may be performed in order to authenticate the MS. The SGSN is able to derive the GGSN address from the APN identifier in order to forward this request to the GGSN. The SGSN creates a downlink GTP tunnel to route IP packets from the GGSN to the SGSN. The GGSN creates a new entry in its PDP context table to route IP packets between the SGSN and the external packet-switching network. The GGSN creates an uplink GTP tunnel to route IP-PDU from SGSN to GGSN.

The GGSN then sends back to the SGSN the result of the PDP context creation with the negotiated QoS and if necessary the MS PDP address. Next the SGSN sends an ACTIVATE PDP CONTEXT ACCEPT to the MS by returning negotiated QoS parameters, radio priority, and if necessary the MS PDP address.

Figure 7.19 illustrates a PDP context activation procedure initiated by the MS.

 
Figure 7.19: PDP context activation initiated by MS.

Initiated by GGSN

When the network receives an IP packet from an external network, the GGSN checks if a PDP context is already established with that PDP address. If not, the GGSN sends a PDU NOTIFICATION REQUEST to the SGSN in order to initiate a PDP context activation. The GGSN has retrieved the IP address of the appropriate SGSN address by interrogating the HLR from the IMSI identifier of the MS. The SGSN then sends to the MS a request to activate the indicated PDP context. Next the PDP context activation procedure follows the one initiated by the MS. Once the PDP context is activated, the IP packet can be sent from the GGSN to the MS.

Figure 7.20 illustrates a PDP context activation procedure initiated by the GGSN.

 
Figure 7.20: PDP context activation initiated by network.

7.2.6.2 PDP Context Deactivation Procedure

As with the PDP context activation procedure, the PDP context deactivation procedure may be initiated by either the MS or the SGSN or GGSN.

Initiated by MS

In order to deactivate a PDP context, the MS sends a DEACTIVATE PDP CONTEXT message to the SGSN, which then sends a DELETE PDP CONTEXT message to the GGSN. If the PDP address was requested by the MS during the PDP context activation procedure, the GGSN releases this PDP address in order to keep it free for a subsequent PDP context activation. When the SGSN receives a PDP context deletion acknowledgment from the GGSN, the SGSN confirms to the MS the PDP context deactivation.

Figure 7.21 illustrates a PDP context deactivation procedure initiated by the MS.

 
Figure 7.21: PDP context deactivation initiated by MS.

Initiated by SGSN

When the PDP context deactivation is initiated by the SGSN, it sends a DELETE PDP CONTEXT REQUEST message to the GGSN. This procedure may occur when the HLR requests the deletion of PDP context due to the removal of general GPRS subscription data. The SGSN deletes the subscriber data when it receives the MAP DELETE SUBSCRIBER DATA message from the HLR. The SGSN acknowledges the delete subscriber data procedure by sending back a MAP DELETE SUBSCRIBER DATA ACK message to the HLR.

The GGSN deactivates the PDP context upon receipt of the DELETE PDP CONTEXT REQUEST message from the MS and releases the PDP address if this one was allocated dynamically during the PDP context activation procedure. When the SGSN receives a PDP context deletion acknowledgment from the GGSN, it initiates the PDP context deactivation in the MS by sending the DEACTIVATE PDP CONTEXT REQUEST message. When the MS has removed its PDP context, the MS sends back to the SGSN the DEACTIVATE PDP CONTEXT ACCEPT message.

Figure 7.22 illustrates a PDP context deactivation procedure initiated by the SGSN.

 
Figure 7.22: PDP context deactivation initiated by SGSN.

Iniated by GGSN

When the PDP context deactivation is initiated by the GGSN, it sends a DELETE PDP CONTEXT REQUEST message to the SGSN, which then sends to the MS a DEACTIVATE PDP CONTEXT REQUEST message. After having removed the PDP context, the MS sends a PDP context deactivation confirmation to the SGSN, which then sends a PDP context deletion acknowledgment to the GGSN. If the PDP address was requested by the MS during the PDP context activation procedure, the GGSN releases this PDP address.

Figure 7.23 illustrates a PDP context deactivation procedure initiated by the GGSN.

 
Figure 7.23: PDP context deactivation initiated by GGSN.

7.2.6.3 PDP Context Modification Procedure

The PDP context modification procedure is used to change the negotiated QoS, the radio priority level, or the TFT parameters negotiated during the PDP context activation procedure. This procedure may also be used to change the MS PDP address by the GGSN. The PDP context modification may be initiated by the MS, the SGSN, or the GGSN. The PDP context modification procedure initiated by the MS or GGSN was introduced in Release 99 of the GPRS recommendations, even though the PDP context modification procedure initiated by the SGSN was already introduced in Release 97 of the GPRS recommendations.

Initiated by SGSN

The PDP context modification initiated by the SGSN may occur after an inter-SGSN RA update procedure to change the negotiated QoS, the radio priority level, or the TFT negotiated during the PDP context activation procedure.

The SGSN sends an UPDATE PDP CONTEXT REQUEST message to the GGSN with a new QoS. The GGSN then checks if the new QoS is compliant with its capabilities and sends back to the SGSN in an UPDATE PDP CONTEXT RESPONSE message the negotiated QoS that takes into account if necessary some restrictions. The SGSN then sends new QoS parameters and a new radio priority parameter to the MS in a MODIFY PDP CONTEXT REQUEST message. If the MS accepts the new QoS parameters, it acknowledges the MODIFY PDP CONTEXT REQUEST message by sending to the SGSN a MODIFY PDP CONTEXT ACCEPT message.

Figure 7.24 illustrates a PDP context modification procedure initiated by the SGSN.

 
Figure 7.24: PDP context modification initiated by SGSN.

Note that if the new QoS is not accepted by the MS during the PDP context modification initiated by the SGSN, the MS will deactivate the PDP context by initiating the PDP context deactivation procedure.

Initiated by MS

The PDP context modification procedure initiated by the MS allows for a change in the negotiated QoS, the radio priority level, or the TFT negotiated during the PDP context activation procedure. The MS initiates the procedure by sending to the SGSN a MODIFY PDP CONTEXT REQUEST message, which may include a new requested QoS or new TFT parameters.

Next, the SGSN sends the new characteristics proposed for that PDP context to the GGSN by restricting if necessary the requested QoS in the UPDATE PDP CONTEXT REQUEST message. The GGSN then checks if the new QoS or TFT parameters are compliant with its capabilities and sends back to the SGSN in the UPDATE PDP CONTEXT RESPONSE message the negotiated QoS. When the SGSN receives the acknowledgment of the PDP context update from the GGSN, it sends to the MS a new radio priority and a packet flow ID on the QoS negotiated in a MODIFY PDP CONTEXT ACCEPT message.

Figure 7.25 illustrates a PDP context modification procedure initiated by the MS.

 
Figure 7.25: PDP context modification initiated by MS.

Initiated by GGSN

The GGSN initiates the procedure by sending to the SGSN an UPDATE PDP CONTEXT REQUEST message, which includes the desired QoS. A PDP address may be provided to the SGSN by the GGSN. Next, the SGSN sends to the MS the radio priority and packet flow ID on the requested QoS, which may be restricted if necessary in the MODIFY PDP CONTEXT REQUEST message. The MS acknowledges the requested QoS by sending to the SGSN a MODIFY PDP CONTEXT ACCEPT message; the SGSN then sends this acknowledgment to the GGSN in the UPDATE PDP CONTEXT RESPONSE message.

Figure 7.26 illustrates a PDP context modification procedure initiated by the GGSN.

 
Figure 7.26: PDP context modification initiated by GGSN.

Note that if the new QoS is not accepted by the MS during the PDP context modification initiated by the GGSN, it initiates the PDP context deactivation procedure.

7.2.6.4 Secondary PDP Context Activation Procedure

When an MS wishes to create a secondary PDP context in order to reuse the same PDP address and the same APN, it sends a secondary PDP context activation request to the SGSN with the requested QoS andTFT. Security functions may be performed in order to authenticate the MS. The SGSN creates a downlink GTP tunnel to route IP packets from GGSN to SGSN. It then sends the requested QoS and TFT parameters to the GGSN in the CREATE PDP CONTEXT REQUEST message while indicating the NSAPI assigned to the already activated PDP context with this PDP address.

The GGSN creates a new entry in its PDP context table to route IP packets between the SGSN and the external packet-switching network, which stores the TFT. The GGSN creates an uplink GTP tunnel to route IP-PDU from SGSN to GGSN. It then sends back to the SGSN the result of the secondary PDP context creation with a negotiated QoS. Next the SGSN sends an ACTIVATE SECONDARY PDP CONTEXT ACCEPT message to the MS by adding NSAPI and by returning QoS parameters and radio priority.

Figure 7.27 illustrates a secondary PDP context activation procedure initiated by the MS.

 
Figure 7.27: Secondary PDP context activation.