Professional Documents
Culture Documents
PDP Context
PDP Context
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.
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 TFT is 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.
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.
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.
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.
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.
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.