9.2 PDP Context Activation, Modification, and Deactivation Functions

https://itectec.com/spec/9-2-pdp-context-activation-modification-and-deactivation-functions/

These functions are only meaningful at the NSS level and in the MS, and do not directly involve the BSS. An MS in STANDBY or READY state can initiate these functions at any time to activate or deactivate a PDP context in the MS, the SGSN, and the GGSN. A GGSN may request the activation of a PDP context to a GPRS-attached subscriber. A GGSN may initiate the deactivation of a PDP context.

Upon receiving an Activate PDP Context Request message, the SGSN shall initiate procedures to set up PDP contexts. Upon receiving a Deactivate PDP Context Request message, the SGSN shall initiate procedures to deactivate PDP contexts.

An MS does not have to receive the (De‑)Activate PDP Context Accept message before issuing another (De‑)Activate PDP Context Request. However, only one request can be outstanding for every NSAPI.

9.2.1 Static and Dynamic PDP Addresses

PDP addresses can be allocated to an MS in three different ways:

– the HPLMN operator assigns a PDP address permanently to the MS (static PDP address);

– the HPLMN operator assigns a PDP address to the MS when a PDP context is activated (dynamic HPLMN PDP address); or

– the VPLMN operator assigns a PDP address to the MS when a PDP context is activated (dynamic VPLMN PDP address).

It is the HPLMN operator that defines in the subscription whether a dynamic HPLMN or VPLMN PDP address can be used.

For every IMSI, zero, one, or more dynamic PDP address per PDP type can be assigned. For every IMSI, zero, one, or more static PDP addresses per PDP type can be subscribed to.

When dynamic addressing is used, it is the responsibility of the GGSN to allocate and release the dynamic PDP address.

Only static PDP addressing is applicable in the network-requested PDP context activation case.

9.2.2 Activation Procedures

9.2.2.1 PDP Context Activation Procedure

The PDP Context Activation procedure is illustrated in Figure 35. Each step is explained in the following list.

Figure 35: PDP Context Activation Procedure

1) The MS sends an Activate PDP Context Request (NSAPI, TI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options) message to the SGSN. The MS shall use PDP Address to indicate whether it requires the use of a static PDP address or whether it requires the use of a dynamic PDP address. The MS shall leave PDP Address empty to request a dynamic PDP address. The MS may use Access Point Name to select a reference point to a certain external network. Access Point Name is a logical name referring to the external packet data network that the subscriber wishes to connect to. QoS Requested indicates the desired QoS profile. PDP Configuration Options may be used to request optional PDP parameters from the GGSN (see GSM 09.60). PDP Configuration Options is sent transparently through the SGSN.

2) Security functions may be executed. These procedures are defined in subclause "Security Function".

3) The SGSN validates the Activate PDP Context Request using PDP Type (optional), PDP Address (optional), and Access Point Name (optional) provided by the MS and the PDP context subscription records. The validation criteria, the APN selection criteria, and the mapping from APN to a GGSN are described in annex A.

If no GGSN address can be derived or if the SGSN has determined that the Activate PDP Context Request is not valid according to the rules described in annex A, then the SGSN rejects the PDP context activation request.

If a GGSN address can be derived, the SGSN creates a TID for the requested PDP context by combining the IMSI stored in the MM context with the NSAPI received from the MS. If the MS requests a dynamic address, then the SGSN lets a GGSN allocate the dynamic address. The SGSN may restrict the requested QoS attributes given its capabilities, the current load, and the subscribed QoS profile. The SGSN sends a Create PDP Context Request (PDP Type, PDP Address, Access Point Name, QoS Negotiated, TID, MSISDN, Selection Mode, PDP Configuration Options) message to the affected GGSN. Access Point Name shall be the APN Network Identifier of the APN selected according to the procedure described in annex A. PDP Address shall be empty if a dynamic address is requested. The GGSN may use Access Point Name to find an external network. Selection Mode indicates whether a subscribed APN was selected, or whether a non-subscribed APN sent by MS or a non-subscribed APN chosen by SGSN was selected. Selection Mode is set according to annex A. The GGSN may use Selection Mode when deciding whether to accept or reject the PDP context activation. For example, if an APN requires subscription, then the GGSN is configured to accept only the PDP context activation that requests a subscribed APN as indicated by the SGSN with Selection Mode. The GGSN creates a new entry in its PDP context table and generates a Charging Id. The new entry allows the GGSN to route PDP PDUs between the SGSN and the external PDP network, and to start charging. The GGSN may further restrict QoS Negotiated given its capabilities and the current load. The GGSN then returns a Create PDP Context Response (TID, PDP Address, Reordering Required, PDP Configuration Options, QoS Negotiated, Charging Id, Cause) message to the SGSN. PDP Address is included if the GGSN allocated a PDP address. Reordering Required indicates whether the SGSN shall reorder N‑PDUs before delivering the N‑PDUs to the MS. PDP Configuration Options contain optional PDP parameters that the GGSN may transfer to the MS. These optional PDP parameters may be requested by the MS in the Activate PDP Context Request message, or may be sent unsolicited by the GGSN. PDP Configuration Options is sent transparently through the SGSN. The Create PDP Context messages are sent over the GPRS backbone network.

If QoS Negotiated received from the SGSN is incompatible with the PDP context being activated (e.g., the reliability class is insufficient to support the PDP type), then the GGSN rejects the Create PDP Context Request message. The compatible QoS profiles are configured by the GGSN operator.

4) 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 selects Radio Priority based on QoS Negotiated, and returns an Activate PDP Context Accept (PDP Type, PDP Address, TI, QoS Negotiated, Radio Priority, PDP Configuration Options) message to the MS. The SGSN is now able to route PDP PDUs between the GGSN and the MS, and to start charging.

For each PDP Address a different quality of service (QoS) profile may be requested. For example, some PDP addresses may be associated with E-mail that can tolerate lengthy response times. Other applications cannot tolerate delay and demand a very high level of throughput, interactive applications being one example. These different requirements are reflected in the QoS profile. The QoS profile is defined in subclause "Quality of Service Profile". If a QoS requirement is beyond the capabilities of a PLMN, the PLMN negotiates the QoS profile as close as possible to the requested QoS profile. The MS either accepts the negotiated QoS profile, or deactivates the PDP context.

After an SGSN has successfully updated the GGSN, the PDP contexts associated with an MS is distributed as shown in clause "Information Storage".

If the PDP Context Activation Procedure fails or if the SGSN returns an Activate PDP Context Reject (Cause, PDP Configuration Options) message, then the MS may attempt another activation to the same APN up to a maximum number of attempts.

9.2.2.2 Network-Requested PDP Context Activation Procedure

The Network-Requested PDP Context Activation procedure allows the GGSN to initiate the activation of a PDP context. When receiving a PDP PDU the GGSN checks if a PDP context is established for that PDP address. If no PDP context has been previously established the GGSN may try to deliver the PDP PDU by initiating the Network-Requested PDP Context Activation procedure. The criteria used by the GGSN to determine whether trying to deliver the PDP PDU to the MS may be based on subscription information and are outside the scope of GPRS standardisation.

To support Network-Requested PDP Context Activation the GGSN has to have static PDP information about the PDP address. To determine whether Network-Requested PDP Context Activation is supported for a PDP address the GGSN checks if there is static PDP information for that PDP address.

Once these checks have been performed the GGSN may initiate the Network-Requested PDP Context Activation procedure.

The network operator may implement the following techniques to prevent unnecessary enquires to the HLR:

– implementation of the Mobile station Not Reachable for GPRS flag (MNRG) technique in GGSN, SGSN, and HLR (see subclause "Unsuccessful Network-Requested PDP Context Activation Procedure");

– the GGSN may reject or discard PDP PDUs after a previous unsuccessful delivery attempt. This systematic rejection of PDP PDUs would be performed during a certain time after the unsuccessful delivery;

– the GGSN may store the address of the SGSN with which the GGSN established the last PDP context. This would prevent an enquiry to the HLR. This SGSN address would be considered as valid during a certain time.

9.2.2.2.1 Successful Network-Requested PDP Context Activation Procedure

The Successful Network-Requested PDP Context Activation procedure is illustrated in Figure 36. Each step is explained in the following list.

Figure 36: Successful Network-Requested PDP Context Activation Procedure

1) When receiving a PDP PDU the GGSN determines if the Network-Requested PDP Context Activation procedure has to be initiated. The GGSN may store subsequent PDP PDUs received for the same PDP address.

2) The GGSN may send a Send Routeing Information for GPRS (IMSI) message to the HLR. If the HLR determines that the request can be served, it returns a Send Routeing Information for GPRS Ack (IMSI, SGSN Address, Mobile Station Not Reachable Reason) message to the GGSN. The Mobile Station Not Reachable Reason parameter is included if the MNRG flag is set in the HLR. The Mobile Station Not Reachable Reason parameter indicates the reason for the setting of the MNRG flag as stored in the MNRR record (see GSM 03.40). If the MNRR record indicates a reason other than ‘No Paging Response’, the HLR shall include the GGSN number in the GGSN‑list of the subscriber.

If the HLR determines that the request cannot be served (e.g., IMSI unknown in HLR), the HLR shall send a Send Routeing Information for GPRS Ack (IMSI, MAP Error Cause) message. Map Error Cause indicates the reason for the negative response.

3) If the SGSN address is present and either Mobile Station Not Reachable Reason is not present or Mobile Station Not Reachable Reason indicates ‘No Paging Response’, the GGSN shall send a PDU Notification Request (IMSI, PDP Type, PDP Address) message to the SGSN indicated by the HLR. Otherwise, the GGSN shall set the MNRG flag for that MS. The SGSN returns a PDU Notification Response (Cause) message to the GGSN in order to acknowledge that it shall request the MS to activate the PDP context indicated with PDP Address.

4) The SGSN sends a Request PDP Context Activation (TI, PDP Type, PDP Address) message to request the MS to activate the indicated PDP context.

5) The PDP context is activated with the PDP Context Activation procedure (see subclause "PDP Context Activation Procedure").

9.2.2.2.2 Unsuccessful Network-Requested PDP Context Activation Procedure

If the PDP context requested by the GGSN cannot be established, the SGSN sends a PDU Notification Response (Cause) or a PDU Notification Reject Request (IMSI, PDP Type, PDP Address, Cause) message to the GGSN depending on if the context activation fails before or after the SGSN has sent a Request PDP Context Activation message to the MS. Cause indicates the reason why the PDP context could not be established:

– ‘IMSI Not Known’. The SGSN has no MM context for that IMSI (Cause in PDU Notification Response);

– ‘MS GPRS Detached’. The MM state of the MS is IDLE (Cause in PDU Notification Response);

– ‘MS Not GPRS Responding’. The MS is GPRS-attached to the SGSN but the MS does not respond. This may be due to the lack of a response to a GPRS Paging Request, due to an Abnormal RLC condition, or due to no Activate PDP Context Request message received within a certain time after the Request PDP Context Activation message was delivered to the MS (Cause in PDU Notification Reject Request);

– ‘MS Refuses’. The MS refuses explicitly the network-requested PDP context (Cause in PDU Notification Reject Request).

When receiving the PDU Notification Response or the PDU Notification Reject Request message the GGSN may reject or discard the PDP PDU depending on the PDP type.

After an unsuccessful Network-Requested PDP Context Activation procedure the network may perform some actions to prevent unnecessary enquires to the HLR. The actions taken depend on the cause of the delivery failure.

– If the MS is not reachable or if the MS refuses the PDP PDU (Cause value ‘MS Not GPRS Responding’ or ‘MS Refuses’), then the SGSN shall not change the setting of MNRG for this MS. The GGSN may refuse any PDP PDU for that PDP address during a certain period. The GGSN may store the SGSN address during a certain period and send subsequent PDU Notification Request messages to that SGSN.

– If the MS is GPRS-detached or if the IMSI is not known in the SGSN (Cause value ‘MS GPRS Detached’ or ‘IMSI Not Known’), then the SGSN, the GGSN, and the HLR may perform the Protection and Mobile User Activity procedures.

The Protection procedure is illustrated in Figure 37. Each step is explained in the following list.

Figure 37: Protection Procedure

1) If the MM context of the mobile is IDLE or if the SGSN has no information about that user, the SGSN returns a PDU Notification Response (Cause) message to the GGSN with Cause equal to ‘MS GPRS Detached’ or ‘IMSI Not Known’, otherwise the Cause shall be ‘Activation Proceeds’. If the Cause is ‘MS GPRS Detached’ or ‘IMSI Not Known’ and if the SGSN has an MM context for that user, the SGSN sets MNRG to indicate the need to report to the HLR when the next contact with that MS is performed.

2) If the MS does not respond or refuses the activation request, the SGSN sends a PDU Notification Reject Request (IMSI, PDP Type, PDP Address, Cause) message to the GGSN with Cause equal to ‘MS Not GPRS Responding’ or ‘MS Refuses’. The GGSN returns a PDU Notification Reject Response message to the SGSN.

3) If Cause equals ‘IMSI Not Known’ the GGSN may send a Send Routeing Information for GPRS (IMSI) message to the HLR. The HLR returns a Send Routeing Information for GPRS Ack (IMSI, SGSN Address, Cause) message to the GGSN indicating the address of the SGSN that currently serves the MS. If SGSN Address is different from the one previously stored by the GGSN, then steps 3, 4, and 5 in Figure 36 are followed.

4) If SGSN Address is the same as the one previously stored in the GGSN, or if the Cause value returned in step 1 equals ‘MS GPRS Detached’, then the GGSN sets MNRG for that PDP address and sends a Failure Report (IMSI, GGSN Number, GGSN Address) message to the HLR to request MNRG to be set in the HLR. The HLR sets (if not already set) MNRG for the IMSI and adds GGSN Number and GGSN Address to the list of GGSNs to report to when activity from that IMSI is detected. GGSN Number is either the number of the GGSN, or, if a protocol-converting GSN is used as an intermediate node, the number of the protocol-converting GSN. GGSN Address is an optional parameter that shall be included if a protocol-converting GSN is used.

The Mobile User Activity procedure is illustrated in Figure 38. Each step is explained in the following list.

Figure 38: Mobile User Activity Procedure

1) The SGSN receives an indication that an MS is reachable, e.g., an Attach Request message from the MS.

2a) If the SGSN contains an MM context of the MS and MNRG for that MS is set, the SGSN shall send a Ready for SM (IMSI, MS Reachable) message to the HLR and clears MNRG for that MS.

2b) If the SGSN does not keep the MM context of the MS, the SGSN shall send an Update Location message (see subclause "Attach Function") to the HLR.

3) When the HLR receives the Ready for SM message or the Update Location message for an MS that has MNRG set, it clears MNRG for that MS and sends a Note MS GPRS Present (IMSI, SGSN Address) message to all the GGSNs in the list of the subscriber. (The Ready for SM message also triggers the SMS alert procedure as described in subclause "Unsuccessful Mobile-terminated SMS Transfer".) SGSN Address contains the address of the SGSN that currently serves the MS. Upon reception of Note MS Present, each GGSN shall clear MNRG.

9.2.2.3 Anonymous Access PDP Context Activation Procedure

The MS can anonymously initiate PDP Context Activation in IDLE, STANDBY, and READY states. An existing MM context in the SGSN is neither required nor used in this case. Only dynamic PDP addressing is applicable.

The Anonymous Access PDP Context Activation procedure is illustrated in Figure 39. Each step is explained in the following list.

Figure 39: Anonymous Access PDP Context Activation Procedure

1) The MS sends an Activate AA PDP Context Request (NSAPI, TI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options) message to the SGSN. The MS shall use a Random TLLI at the RLC/MAC layer for identification purposes. The MS shall use PDP Address to indicate that it requires the use of a dynamic PDP address. The MS shall use Access Point Name to select a reference point to a certain external network that provides anonymous services. QoS Requested indicates the desired QoS profile. PDP Configuration Options may be used to request optional PDP parameters from the GGSN (see GSM 09.60). PDP Configuration Options is sent transparently through the SGSN.

2) The SGSN may restrict the requested QoS value given its capabilities and the current load. The SGSN assigns an Auxiliary TLLI and creates an AA‑TID for the PDP-Context. The SGSN sends a Create AA PDP Context Request (PDP Type, PDP Address, Access Point Name, QoS Negotiated, AA‑TID, Selection Mode, PDP Configuration Options) message to the GGSN indicated by Access Point Name in the Activate AA PDP Context Request message. Selection Mode indicates how the APN was selected. The GGSN creates a new entry in its PDP context table and generates a Charging Id. The new entry allows the GGSN to route PDP PDUs between the SGSN and the server(s) that provide services for anonymous MSs, and to start charging. The GGSN may use Access Point Name to find an external network that provides anonymous services. The GGSN may further restrict QoS Negotiated given its capabilities and the current load. The GGSN then allocates a dynamic PDP Address and returns a Create AA PDP Context Response (AA‑TID, PDP Address, Reordering Required, PDP Configuration Options, QoS Negotiated, Charging Id, Cause) message to the SGSN. Reordering Required indicates whether the SGSN shall reorder N‑PDUs before delivering the N‑PDUs to the MS. PDP Configuration Options contain optional PDP parameters that the GGSN may transfer to the MS. These optional PDP parameters may be requested by the MS in the Activate PDP Context Request, or may be sent unsolicited by the GGSN. PDP Configuration Options is sent transparently through the SGSN. The GGSN shall check the source and destination address in all subsequent anonymous MO PDP PDUs received from the SGSN. If the GGSN detects a not allowed address in an MO PDP PDU, then the PDP PDU shall be discarded and the MM and PDP contexts shall be deleted in the GGSN, SGSN, and MS, as defined in subclause "Anonymous Access PDP Context Deactivation Initiated by GGSN Procedure".

If QoS Negotiated received from the SGSN is incompatible with the PDP context being activated (e.g., the reliability class is insufficient to support the PDP type), then the GGSN rejects the Create AA PDP Context Request message. The compatible QoS profiles are configured by the GGSN operator.

3) The SGSN inserts the NSAPI along with the PDP address received from the GGSN in its PDP context. The SGSN selects Radio Priority based on QoS Negotiated and returns an Activate AA PDP Context Accept (A‑TLLI, PDP Type, PDP Address, TI, QoS Negotiated, Radio Priority, PDP Configuration Options) message to the MS. The SGSN is now able to route anonymous PDP PDUs between the GGSN and the MS and to start charging.

After an SGSN has successfully updated the GGSN, the MM and PDP contexts associated with an MS is distributed as shown in clause "Information Storage".

If the AA PDP Context Activation procedure fails or if the SGSN returns an Activate AA PDP Context Reject (Cause, PDP Configuration Options) message, then the MS may attempt another activation to the same GGSN up to a maximum number of attempts.

9.2.3 Modification Procedures

An SGSN can decide, possibly triggered by the HLR as explained in subclause "Insert Subscriber Data Procedure", to modify parameters that were negotiated during an activation procedure for one or several PDP contexts. The following parameters can be modified:

– QoS Negotiated; and

– Radio Priority.

The SGSN can request the modification of parameters by sending a Modify PDP Context Request message to the MS.

9.2.3.1 PDP Context Modification Procedure

The PDP Context Modification procedure is illustrated in Figure 40. Each step is explained in the following list.

Figure 40: PDP Context Modification Procedure

1) The SGSN may send an Update PDP Context Request (TID, QoS Negotiated) message to the GGSN. If QoS Negotiated received from the SGSN is incompatible with the PDP context being modified (e.g., the reliability class is insufficient to support the PDP type), then the GGSN rejects the Update PDP Context Request. The compatible QoS profiles are configured by the GGSN operator.

2) The GGSN may restrict QoS Negotiated given its capabilities and the current load. The GGSN stores QoS Negotiated and returns an Update PDP Context Response (TID, QoS Negotiated) message.

3) The SGSN sends a Modify PDP Context Request (TI, QoS Negotiated, Radio Priority) message to the MS.

4) The MS acknowledges by returning a Modify PDP Context Accept message. If the MS does not accept the new QoS Negotiated it shall de-activate the PDP context with the PDP Context Deactivation Initiated by MS procedure.

9.2.4 Deactivation Procedures

9.2.4.1 PDP Context Deactivation Initiated by MS Procedure

The PDP Context Deactivation Initiated by MS procedure is illustrated in Figure 41. Each step is explained in the following list.

Figure 41: PDP Context Deactivation Initiated by MS Procedure

1) The MS sends a Deactivate PDP Context Request (TI) message to the SGSN.

2) Security functions may be executed. These procedures are defined in subclause "Security Function".

3) The SGSN sends a Delete PDP Context Request (TID) message to the GGSN. The GGSN removes the PDP context and returns a Delete PDP Context Response (TID) message to the SGSN. If the MS was using a dynamic PDP address, then the GGSN releases this PDP address and makes it available for subsequent activation by other MSs. The Delete PDP Context messages are sent over the GPRS backbone network.

4) The SGSN returns a Deactivate PDP Context Accept (TI) message to the MS.

At GPRS detach, all PDP contexts for the MS are implicitly deactivated.

If the SGSN receives a Deactivate PDP Context Request (TI) message for a PDP context that is currently being activated, then the SGSN shall stop the PDP Context Activation procedure without responding to the MS, and continue with the PDP Context Deactivation initiated by MS procedure.

9.2.4.2 PDP Context Deactivation Initiated by SGSN Procedure

The PDP Context Deactivation Initiated by SGSN procedure is illustrated in Figure 42. Each step is explained in the following list.

Figure 42: PDP Context Deactivation Initiated by SGSN Procedure

1) The SGSN sends a Delete PDP Context Request (TID) message to the GGSN. The GGSN removes the PDP context and returns a Delete PDP Context Response (TID) message to the SGSN. If the MS was using a dynamic PDP address, then the GGSN releases this PDP address and makes it available for subsequent activation by other MSs. The Delete PDP Context messages are sent over the GPRS backbone network. The SGSN may not wait for the response from the GGSN before sending the Deactivate PDP Context Request message.

2) The SGSN sends a Deactivate PDP Context Request (TI) message to the MS. The MS removes the PDP context and returns a Deactivate PDP Context Accept (TI) message to the SGSN.

9.2.4.3 PDP Context Deactivation Initiated by GGSN Procedure

The PDP Context Deactivation Initiated by GGSN procedure is illustrated in Figure 43. Each step is explained in the following list.

Figure 43: PDP Context Deactivation Initiated by GGSN Procedure

1) The GGSN sends a Delete PDP Context Request (TID) message to the SGSN.

2) The SGSN sends a Deactivate PDP Context Request (TI) message to the MS. The MS removes the PDP context and returns a Deactivate PDP Context Accept (TI) message to the SGSN.

3) The SGSN returns a Delete PDP Context Response (TID) message to the GGSN. If the MS was using a dynamic PDP address, then the GGSN releases this PDP address and makes it available for subsequent activation by other MSs. The Delete PDP Context messages are sent over the GPRS backbone network. The SGSN may not wait for the response from the MS before sending the Delete PDP Context Response message.

9.2.4.4 Anonymous Access PDP Context Deactivation Initiated by MS Procedure

The MS shall not issue explicit deactivation request messages to delete anonymous contexts in the network. Instead, the READY timer shall be used as an implicit deactivation timer to save signalling traffic on the radio interface.

The Anonymous Access PDP Context Deactivation Initiated by MS procedure is illustrated in Figure 44. Each step is explained in the following list.

Figure 44: Anonymous Access PDP Context Deactivation Initiated by MS Procedure

1) The READY timer expires in the MS and SGSN.

2) The SGSN sends a Delete AA PDP Context Request (AA‑TID) message. The GGSN removes the PDP context and returns a Delete AA PDP Context Response (AA‑TID) message to the SGSN. The GGSN releases this PDP address and makes it available for subsequent anonymous activation by other MSs.

9.2.4.5 Anonymous Access PDP Context Deactivation Initiated by GGSN Procedure

If the GGSN detects a misuse or fraud of the anonymous context as described in subclause "Anonymous Access PDP Context Activation Procedure", step 2, it shall initiate the deactivation independently of the READY timer expiry.

If the anonymous server detects a misuse or fraud, it may request the GGSN to deactivate the AA context. The method that the anonymous server uses to inform the GGSN is outside the scope of the GSM specifications.

The Anonymous Access PDP Context Deactivation Initiated by GGSN procedure is illustrated in Figure 45. Each step is explained in the following list.

Figure 45: Anonymous Access PDP Context Deactivation Initiated by GGSN Procedure

1) The GGSN sends a Delete AA PDP Context Request (AA‑TID) message to the SGSN.

2) The SGSN may send an Identity Request (Identity Type = IMSI or IMEI) message to the MS. The MS shall respond with an Identity Response (IMSI or IMEI) message.

3) The SGSN sends a Deactivate AA PDP Context Request (TI) message to the MS. The MS removes the PDP context and returns a Deactivate AA PDP Context Accept (TI) message to the SGSN.

4) The SGSN returns a Delete AA PDP Context Response (AA‑TID) message to the GGSN. The GGSN releases this PDP address and makes it available for subsequent activation by other MSs. The Delete AA PDP Context messages are sent over the GPRS backbone network. The SGSN may not wait for the accept from the MS before sending the Delete AA PDP Context Response message.