7.3 Tunnel Management Messages

29.0603GPPGeneral Packet Radio Service (GPRS)GPRS Tunnelling Protocol (GTP) across the Gn and Gp interfaceRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.3.1 Create PDP Context Request

A Create PDP Context Request shall be sent from a SGSN node to a GGSN node as a part of the GPRS PDP Context Activation procedure. For a PDP Type "Non-IP" the SGSN shall send the Create PDP Context Request to the GGSN only if the SGSN learns using the procedure specified in clause 5.9 of 3GPP TS 29.303 [46] that the GGSN supports the "Non-IP" PDP Type. After sending the Create PDP Context Request message, the SGSN marks the PDP context as "waiting for response". In this state the SGSN shall accept G-PDUs from the GGSN but shall not send these G-PDUs to the MS. A valid request initiates the creation of a tunnel between a PDP Context in a SGSN and a PDP Context in a GGSN. If the procedure is not successfully completed, the SGSN repeats the Create PDP Context Request message to the next GGSN address in the list of IP addresses, if there is one and if the SGSN did not receive a rejection message from the GGSN with a cause code indicating that the request cannot be fulfilled independently from any specific GGSN, e.g. "User Authentication failed" (see clause 7.7.1). Otherwise the activation procedure fails.

The Tunnel Endpoint Identifier Data I field specifies a downlink Tunnel Endpoint Identifier for G-PDUs which is chosen by the SGSN. The GGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent downlink G-PDUs which are related to the requested PDP context.

The Tunnel Endpoint Identifier Control Plane field specifies a downlink Tunnel Endpoint Identifier for control plane messages which is chosen by the SGSN. The GGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent downlink control plane messages which are related to the requested PDP context. If the SGSN has already confirmed successful assignment of its Tunnel Endpoint Identifier Control Plane to the peer GGSN, this field shall not be present. The SGSN confirms successful assignment of its Tunnel Endpoint Identifier Control Plane the GGSN when it receives any message with its assigned Tunnel Endpoint Identifier Control Plane in the GTP header from the GGSN.

The MSISDN of the MS shall be passed to the GGSN inside the Create PDP Context Request for a PDP Context Activation procedure other than the Secondary PDP Context Activation procedure. This additional information can be used when a secure access to a remote application residing on a server is needed. The GGSN would be in fact able to provide the user identity (i.e. the MSISDN) to the remote application server, providing it with the level of trust granted to users through successfully performing the GPRS authentication procedures, without having to re-authenticate the user at the application level. If no MSISDN is provided by the HSS, the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [2]) in the aforementioned procedure.

If the MS requests a dynamic PDP address and a dynamic PDP address is allowed, then the PDP Address field in the End User Address information element shall be empty. If the MS requests a static PDP Address then the PDP Address field in the End User Address information element shall contain the static PDP Address. In case the PDP addresses carried in the End User Address and optionally in the Protocol Configuration Option information element contain contradicting information, the PDP address carried in the End User Address information element takes the higher precedence. The Quality of Service Profile information element shall be the QoS values to be negotiated between the MS and the SGSN at PDP Context activation. The Evolved Allocation/Retention Priority I information element include the negotiated Evolved Allocation/Retention Priority based on the subscribed one received via Gr interface and SGSN capabilities if the SGSN supports it and if the support of Evolved Allocation/Retention Priority has been indicated by the current GGSN or if the SGSN has no information if GGSN supports Evolved Allocation/Retention Priority. If the SGSN has ever indicated the support of the eARP IE towards a GGSN, it then shall include it in all subsequent GTP messages (i.e. Create PDP Context Request and Update PDP Context Request) towards the same GGSN for a given PDN connection, assuming the eARP remains valid within the subscription and that GGSN supports eARP. The APN-AMBR IE shall be included based on the subscribed one received via Gr interface from the HLR and SGSN capabilities if the SGSN supports this IE.

The SGSN shall include an SGSN Address for control plane and an SGSN address for user traffic, which may differ from that provided by the underlying network service (e.g. IP). The GGSN shall store these SGSN Addresses and use them when sending control plane on this GTP tunnel or G-PDUs to the SGSN for the MS.

The SGSN shall include a Recovery information element into the Create PDP Context Request if the SGSN is in contact with the GGSN for the very first time or if the SGSN has restarted recently and the new Restart Counter value has not yet been indicated to the GGSN. The GGSN that receives a Recovery information element in the Create PDP Context Request message element shall handle it in the same way as when receiving an Echo Response message. The Create PDP Context Request message shall be considered as a valid activation request for the PDP context included in the message.

The SGSN shall include either the MS provided APN, a subscribed APN or an SGSN selected APN in the message; the Access Point Name may be used by the GGSN to differentiate accesses to different external networks.

The Selection Mode information element shall indicate the origin of the APN in the message.

For contexts created by the Secondary PDP Context Activation Procedure the SGSN shall include the linked NSAPI. Linked NSAPI indicates the NSAPI assigned to any one of the already activated PDP contexts for this PDN connection. If the requested PDP type is allowed by subscription and if the requested PDP type is IPv4v6, the SGSN sets the PDP type as requested if the GGSN supports PDP type IPv4v6. Otherwise, the SGSN shall set the PDP type to IPv4 or IPv6 where the selection between IPv4 and IPv6 is based on the result of the check.

NOTE 1: The check for PDP type IPv4v6 is implementation specific and configuration may be shared in roaming agreements.

NOTE 2: A Gn/Gp SGSN assumes coherent support for PDP type IPv4v6 across all SGSNs in a PLMN.

The Secondary PDP Context Activation Procedure may be executed without providing a Traffic Flow Template (TFT) to the newly activated PDP context if all other active PDP contexts for this PDN connection already have an associated TFT, otherwise a TFT shall be provided. TFT is used for packet filtering in the GGSN.

When using the Secondary PDP Context Activation Procedure, the Selection mode, IMSI, MSISDN, End User Address, Access Point Name and APN Restriction information elements shall not be included in the message.

If available, the IMSI shall be passed to the GGSN inside the Create PDP Context Request for a PDP Context Activation procedure other than the Secondary PDP Context Activation procedure.

If the MS is emergency attached and the MS is UICCless (i.e. the mobile terminal cannot obtain IMSI at all) or the IMSI is unauthenticated, the International Mobile Equipment Identity (IMEI) shall be used as the MS identity. If the MS is emergency attached and the MS is UICCless, the IMSI cannot be included in the message and therefore IMSI shall not be included in the message.

The Protocol Configuration Options (PCO) information element may be included in the request when the MS provides the GGSN with application specific parameters. The SGSN includes this IE in the Create PDP Context Request if the associated Activate PDP Context Request or Activate Secondary PDP Context Request from the MS includes protocol configuration options. The SGSN shall copy the content of this IE transparently from the content of the PCO IE in the Activate PDP Context Request message or Activate Secondary PDP Context Request.

The SGSN shall select one GGSN based on the user provided or SGSN selected APN. The GGSN may have a logical name that is converted to an address. The conversion may be performed with any name-to-address function. The converted address shall be stored in the "GGSN Address in Use" field in the PDP context and be used during the entire lifetime of the PDP context.

If the converted address includes an IPv6 address, the IPv4/IPv6 capable SGSN sends Create PDP Context Request to the GGSN including IPv6 addresses in the IEs SGSN Address for Control Plane and SGSN Address for user traffic. If the converted address only includes an IPv4 address, IPv4/IPv6 capable SGSN shall include IPv4 addresses in the IEs SGSN Address for Control Plane and SGSN Address for user traffic.

NOTE 3: A DNS query may be used as the name-to-IP address mapping of the GGSN. The IP address returned in the DNS response is then stored in the "GGSN Address in Use" field in the PDP context.

The IMSI information element, or the IMEI information element if the MS is emergency attached and the MS is UICCless or the MS is emergency attached but the IMSI is not authenticated together with the NSAPI information element uniquely identifies the PDP context to be created.

The SGSN shall not send a Create PDP Context Request for an already active context.

If a new Create PDP Context Request is incoming on TEID 0 for an already active PDP context, this Create PDP Context Request must be considered related to a new session. The existing PDP context shall be torn down locally, and the associated PDP contexts deleted locally, before the new session is created. If a new Create PDP Context Request is incoming on a TEID which is different from 0 and this TEID is already allocated to one or more activated PDP contexts, and the NSAPI IE value in this message matches the NSAPI value of an active PDP context, the GGSN shall send back a Create PDP Context Response with a rejection cause code. It is implementation dependent deciding whether to teardown or keep the existing PDP context.

If the GGSN uses the MNRG flag and the flag is set, the GGSN should treat the Create PDP Context Request as a Note MS Present Request and clear the MNRG flag.

The SGSN shall determine Charging Characteristics from the Subscribed Charging Characteristics and/or PDP Context Charging Characteristics depending on the presence of the information in the Packet Domain Subscription Data as defined in 3GPP TS 23.060 [4]. The requirements for the presence of the Charging Characteristics IE are defined in 3GPP TS 23.060 [4]. The contents of the Charging Characteristics IE are defined in 3GPP TS 32.251 [18] and 3GPP TS 32.298 [34].

The SGSN shall include Trace Reference, Trace Type, Trigger Id, OMC Identity and Additional Trace Info (Trace reference2, Trace Recording Session Reference, triggering events in GGSN, Trace Depth, List of interfaces to trace in GGSN and Trace Activity Control) in the message if GGSN trace is activated. The SGSN shall copy Trace Reference, Trace Type, OMC Identity and Additional Trace Info from the trace request received from the HLR or OMC and the Trace Activity Control shall be set to Trace Activation

For more detailed description of Trace Session activation/deactivation procedures see 3GPP TS 32.422 [31]

For SGSN and GGSN trace record description see 3GPP TS 32.423 [32].

The SGSN shall include the Routeing Area Identity (RAI) where the MCC and MNC components shall be populated with the MCC and MNC of the serving core network operator of the MS. The LAC and RAC components shall be populated by the SGSN with the value of "FFFE" and "FF", respectively. See one exception to this rule below in shared GERAN and UTRAN networks.

NOTE 4: The serving core network operator ID is the PLMN ID of the SGSN which is currently serving the UE. An SGSN which supports multiple PLMN IDs is considered as logically different SGSNs.

The APN Restriction is an optional information element. In this instance, it is used by the SGSN to convey to the GGSN the highest restriction type out of all the currently active PDP Contexts for a particular subscriber.

The presence of the Common Flags IE is optional. If the NRSN bit of the Common Flags IE is set to 1, the SGSN supports the network requested bearer control. If NRSN bit of the Common Flags IE is set to 0 or the Common Flags IE is absent then the SGSN does not support network requested bearer control. If the Upgrade QoS Supported bit of the Common Flags IE is set to 1, the SGSN supports the QoS upgrade in Response message functionality. If Upgrade QoS Supported bit of the Common Flags IE is set to 0 or the Common Flags IE is absent then the SGSN does not support QoS upgrade in Response message functionality. The Dual Address Bearer Flag bit of the Common Flags IE shall be set to 1 if the PDP type, determined based on the MS request and subscription information, is set to IPv4v6 and all SGSNs, which the MS may be handed over to, are Release 9 or above supporting dual addressing, which is determined based on node pre‑configuration by the operator.

The SGSN may include the IMEI(SV) IE, CAMEL Charging Information Container IE and the User CSG Information IE if they are available (see clause 15.1.1a of 3GPP TS 23.060 [4] for more information). The SGSN shall include the User Location Information IE in the PDP Context Activation procedure. The SGSN shall include the CGI or SAI in the "Geographic Location" field of the User Location Information IE depending on whether the MS is in a cell or a service area respectively. The MS Time Zone IE shall be included in the Primary PDP Context Activation procedure, and may be included in the Secondary PDP Context Activation procedure. If the MS is emergency attached and the MS is UICCless or the IMSI is unauthenticated, the International Mobile Equipment Identity (IMEI) shall be included and used as the MS identity. If the User CSG Information IE is included then the SGSN shall include the CSG ID, Access mode, the CSG Membership Indication shall also be included if the Access mode is Hybrid Mode.

In shared networks,

– when the message is sent from the VPLMN to the HPLMN, the PLMN ID that is communicated in the User Location Information IE, Routeing Area Identity (RAI) IE and User CSG Information IE shall be that of the selected Core Network Operator for supporting UEs, or that of the allocated Core Network Operator for non-supporting UEs. As an exception, based on inter-operator roaming/sharing agreement, if the information on whether the UE is a supporting or non-supporting UE is available, the PLMN ID that is communicated to the HPLMN for non-supporting UEs shall be the Common PLMN ID. See clause 4.4 of 3GPP TS 23.251 [35];

– when the SGSN and GGSN pertain to the same PLMN, the Common PLMN ID shall be communicated in SAI/CGI to the GGSN, for both supporting and non-supporting UEs. The Core Network Operator PLMN ID (selected by the UE for supporting UEs or allocated by the network for non-supporting UEs) shall be communicated in RAI and User CSG Information.

The SGSN shall include the RAT Type IE during Primary PDP Context Activation procedure.

The Correlation-ID shall be included if the PDP Context Activation is performed as part of the Network Requested Secondary PDP Context Activation Procedure.

The presence of the Extended Common Flags IE is optional. The Unauthenticated IMSI bit field shall be set to 1 if the IMSI present in the message is not authenticated and is for an emergency attached MS. The CSG Change Reporting Support Indication (CCRSI) bit field shall be set to 1 if the SGSN supports CSG Information Change Reporting and if the SGSN’s operator policy permits reporting of User CSG Information change to the operator of the GGSN. If the CCRSI bit field is set to 0 or the Extended Common Flags IE is not included in the message, the GGSN shall assume that the SGSN originating the message does not support the CSG Information Change Reporting.

3GPP TS 23.060 [4] (e.g. clause 9.2.2.1) defines the SGSN shall send the MS Info Change Reporting Support Indication to the GGSN. This specification however specifies that the SGSN shall send the CSG Change Reporting Support Indication for CSG Information Reporting even if stage 2 refers to MS Info Change Reporting Support Indication.

The SGSN shall include the Signalling Priority Indication IE during the PDP Context Activation procedure and the Secondary PDP Context Activation procedure if the UE indicates low access priority during these procedures.

In shared networks, the SGSN shall include the CN Operator Selection Entity IE during the Primary PDP Context Activation procedure to indicate whether the Serving Network has been selected by the UE or by the network.

Based on operator policy, the SGSN shall include the Mapped UE Usage Type IE on the Gn interface, if available and if the SGSN supports the Dedicated Core Network feature. When present, it shall contain the mapped UE usage type applicable to the PDP Context.

NOTE 5: This information is used for the PGW-U selection (see Annex B.2 of 3GPP TS 29.244 [60]).

Based on operator policy, the SGSN shall include the UP Function Selection Indication Flags, if any of the applicable flags is set to 1. The DCNR flag shall be set to 1 on the Gn/Gp interface if it is desired to select a PGW-U which supports NR, e.g. for UEs indicating support of dual connectivity with NR in NAS signalling to the SGSN and without subscription restriction to use NR as secondary RAT.

NOTE 6: This information is used for the PGW-U selection (see Annex B.2 of 3GPP TS 29.244 [60]).

The optional Private Extension contains vendor or operator specific information.

Table 5: Information Elements in a Create PDP Context Request

Information element	Presence requirement	Reference
IMSI	Conditional	7.7.2
Routeing Area Identity (RAI)	Optional	7.7.3
Recovery	Optional	7.7.11
Selection mode	Conditional	7.7.12
Tunnel Endpoint Identifier Data I	Mandatory	7.7.13
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
NSAPI	Mandatory	7.7.17
Linked NSAPI	Conditional	7.7.17
Charging Characteristics	Conditional	7.7.23
Trace Reference	Optional	7.7.24
Trace Type	Optional	7.7.25
End User Address	Conditional	7.7.27
Access Point Name	Conditional	7.7.30
Protocol Configuration Options	Optional	7.7.31
SGSN Address for signalling	Mandatory	GSN Address 7.7.32
SGSN Address for user traffic	Mandatory	GSN Address 7.7.32
MSISDN	Conditional	7.7.33
Quality of Service Profile	Mandatory	7.7.34
TFT	Conditional	7.7.36
Trigger Id	Optional	7.7.41
OMC Identity	Optional	7.7.42
Common Flags	Optional	7.7.48
APN Restriction	Optional	7.7.49
RAT Type	Optional	7.7.50
User Location Information	Optional	7.7.51
MS Time Zone	Optional	7.7.52
IMEI(SV)	Conditional	7.7.53
CAMEL Charging Information Container	Optional	7.7.54
Additional Trace Info	Optional	7.7.62
Correlation-ID	Optional	7.7.82
Evolved Allocation/Retention Priority I	Optional	7.7.91
Extended Common Flags	Optional	7.7.93
User CSG Information	Optional	7.7.94
APN-AMBR	Optional	7.7.98
Signalling Priority Indication	Optional	7.7.103
CN Operator Selection Entity	Optional	7.7.116
Mapped UE Usage Type	Optional	7.7.123
UP Function Selection Indication Flags	Optional	7.7.124
Private Extension	Optional	7.7.46

7.3.2 Create PDP Context Response

The message shall be sent from a GGSN node to a SGSN node as a response of a Create PDP Context Request. When the SGSN receives a Create PDP Context Response with the Cause value indicating the request is accepted, the SGSN activates the PDP context and may start to forward T-PDUs to/from the MS from/to the external data network.

The Cause value indicates if a PDP context has been created in the GGSN or not. A PDP context has not been created in the GGSN if the Cause differs from "Request accepted", "New PDP type due to network preference" or "New PDP type due to single address bearer only". Possible Cause values are:

– "Request Accepted".

– "Context not found"

– "No resources available".

– "All dynamic PDP addresses are occupied".

– "No memory is available".

– "Missing or unknown APN".

– "Unknown PDP address or PDP type".

– "User authentication failed".

– "System failure".

– "Semantic error in the TFT operation".

– "Syntactic error in the TFT operation".

– "Semantic errors in packet filter(s)".

– "Syntactic errors in packet filters(s)".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

– "PDP context without TFT already activated".

– "APN access denied – no subscription".

– "APN Restriction type incompatibility with currently active PDP Contexts"

– "Collision with network initiated request".

– "New PDP type due to network preference".

– "New PDP type due to single address bearer only".

– "APN Congestion".

– "Bearer handling not supported".

"No resources available" indicates that not enough resources are available within the network to allow the PDP Context to be created. "Missing or unknown APN" indicates e.g. when the GGSN does not support the Access Point Name. "Unknown PDP address or PDP type" indicates when the GGSN does not support the PDP type or the PDP address.

"APN Congestion" indicates that the GGSN has detected congestion for the requested APN and performs overload control for that APN which does not allow the PDP Context to be created. When returning the cause "APN Congestion", the GGSN may include the GGSN Back-Off Time IE to indicate the time during which the SGSN should refrain from sending subsequent PDP Context requests to the GGSN for the congested APN for services other than emergency services. The last received value of the GGSN Back-Off Time IE shall supersede any previous values received from that GGSN and for this APN in the SGSN.

"User authentication failed" indicates that the external packet network has rejected the service requested by the user e.g. the authentication check in the RADIUS server failed. "PDP context without TFT already activated" indicates that a PDP context has already been activated without a TFT for that MS. "Context not found" indicates that a Create PDP Request for a subsequent PDP context has been received, but the PDP context associated with the request, which the SGSN believes to be active does not exist on the GGSN. "APN access denied – no subscription" indicates that the GGSN has denied the user access to an APN because a subscription is required, but the subscriber does not have the necessary subscription.

If the Secondary PDP Context Activation Procedure is related to an established PDP context for LIPA or for SIPTO at the local network, the LGW shall reject the Create PDP Context request with the cause value of "Bearer handling not supported".

"New PDP type due to network preference" indicates that the MS has requested PDP type IPv4v6 and only IPv4 or IPv6 address is allowed for the PDN based on GGSN operator policy, as specified in clause 9.2.1 in 3GPP TS 23.060 [4]. "New PDP type due to single address bearer only" indicates that the MS has requested PDP type IPv4v6 and both IPv4 and IPv6 addressing is possible in the PDN but the Dual Address Bearer Flag bit of the Common Flags IE is set to 0 or the Common Flags IE is absent, or only single IP version addressing is possible in the PDN, as specified in clause 9.2.1 in 3GPP TS 23.060 [4].

Only the Cause information element, optionally Protocol Configuration Options and optionally the Recovery information element shall be included in the response if the Cause contains another value than "Request accepted", "New PDP type due to network preference" or "New PDP type due to single address bearer only". The GGSN Back-Off Time IE may also be returned when rejecting a Create PDP Context Request with the cause "APN Congestion".

The Tunnel Endpoint Identifier for Data (I) field specifies an uplink Tunnel Endpoint Identifier for G-PDUs that is chosen by the GGSN. The SGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent uplink G-PDUs which are related to the requested PDP context.

The Tunnel Endpoint Identifier Control Plane field specifies an uplink Tunnel Endpoint Identifier for control plane messages, which is chosen by the GGSN. The SGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent uplink-control plane messages, which are related to the requested PDP context. If the GGSN has already confirmed successful assignment of its Tunnel Endpoint Identifier Control Plane to the peer SGSN, this field shall not be present. The GGSN confirms successful assignment of its Tunnel Endpoint Identifier Control Plane to the SGSN when it receives any message with its assigned Tunnel Endpoint Identifier Control Plane in the GTP header from the SGSN.

The GGSN may include the NSAPI received from the SGSN in the Create PDP Context Request message, in order to facilitate error handling in SGSN.

NOTE 1: If an SGSN receives a Create PDP Context Response with an NSAPI IE included for which there is no corresponding outstanding request, an SGSN may send a Delete PDP Context Request towards the GGSN that sent the Create PDP Context Response with the NSAPI included

The GGSN shall include a GGSN Address for control plane and a GGSN address for user traffic, which may differ from that provided by the underlying network service (e.g. IP).

If the Create PDP Context Request received from the SGSN included IPv6 SGSN address, an IPv4/IPv6 capable GGSN shall include IPv6 addresses in the fields GGSN Address for Control Plane and GGSN Address for user traffic, and IPv4 addresses in the fields Alternative GGSN Address for Control Plane and Alternative GGSN Address for user traffic. If SGSN included IPv4 SGSN addresses in the request, an IPv4/IPv6 capable GGSN shall include IPv4 addresses in the fields GGSN Address for Control Plane and GGSN Address for user traffic, and IPv6 addresses in the fields Alternative GGSN Address for Control Plane and Alternative GGSN Address for user traffic. An IPv4/IPv6 capable SGSN shall store these GGSN Addresses and use the addresses received in the fields GGSN Address for Control Plane and GGSN Address for user traffic when sending control plane signalling on this GTP tunnel or G-PDUs to the GGSN for the MS. An IPv4 only SGSN shall not store the IPv6 address included in the Alternative GGSN Address.

NOTE 2: An IPv4/IPv6 SGSN also stores the addresses received in the fields Alternative GGSN Address for Control Plane and Alternative GGSN Address for user traffic for inter-SGSN mobility scenarios. See clause 7.3.3.

If the MS requests a dynamic PDP address with the PDP Type IPv4, IPv6 or IPv4v6 and a dynamic PDP address is allowed, then the End User Address information element shall be included and the PDP Address field in the End User Address information element shall contain the dynamic PDP Address(es) allocated by the GGSN.

NOTE 3: If the GGSN uses DHCPv4 for IPv4 address allocation, then the GGSN sets the PDP Address field in the End User Address information element to "0.0.0.0", as specified in 3GPP TS 23.060 [4], clause 9.2.1.

If the MS requests a static PDP address with the PDP Type IPv4, IPv6 or IPv4v6, or a PDP address is specified with PDP Type PPP or Non-IP, then the End User Address information element shall be included and the PDP Address field shall not be included.

The PDP address in End User Address IE and in the Protocol configuration options IE shall be the same, if both IEs are present in the create PDP context response. When using the Secondary PDP Context Activation Procedure, the End User Address element shall not be included in the message.

The QoS values supplied in the Create PDP Context Request may be negotiated downwards by the GGSN. If the SGSN has indicated support for upgrade of QoS in the request message, the QoS values may also be negotiated upwards by the GGSN. The negotiated values or the original values from SGSN are inserted in the Quality of Service Profile information element of the Create PDP Context Response message. The Evolved Allocation/Retention Priority I IE shall be included as the authorized Evolved Allocation/Retention Priority if the GGSN supports this IE and if the Evolved Allocation/Retention Priority I IE has been included in the corresponding request message. If there is no authorized Evolved ARP received from GGSN, SGSN shall continue to use legacy ARP included in the Quality of Service (QoS) Profile IE. The APN-AMBR IE shall be included as the authorized APN-AMBR if the GGSN supports this IE and if the APN-AMBR IE has been included in the corresponding request message.

NOTE 4: The value of the authorized APN-AMBR is included in the APN-AMBR IE, which has a different type than the APN-AMBR with NSAPI IE (see clauses 7.7.98 and 7.7.101).

The GGSN may start to forward T-PDUs after the Create PDP Context Response has been sent. The SGSN may start to forward T-PDUs when the Create PDP Context Response has been received. In this case the SGSN shall also be prepared to receive T-PDUs from the GGSN after it has sent a Create PDP Context Request but before a Create PDP Context Response has been received.

The Reordering Required value supplied in the Create PDP Context Response indicates whether the end user protocol benefits from packet in sequence delivery and whether the SGSN and the GGSN therefore shall perform reordering or not. In other words, if reordering is required by the GGSN, the SGSN and the GGSN shall perform reordering of incoming T-PDUs on this path. When the Quality of Service (QoS) Profile is Release 99 the receiving entity shall ignore the Reordering Required.

The GGSN shall include the Recovery information element into the Create PDP Context Response if the GGSN is in contact with the SGSN for the first time or the GGSN has restarted recently and the new Restart Counter value has not yet been indicated to the SGSN. The SGSN receiving the Recovery information element shall handle it as when an Echo Response message is received but shall consider the PDP context being created as active if the response indicates successful context activation at the GGSN.

The Charging ID is used to identify all charging records produced in SGSN(s) and the GGSN for this PDP context. The Charging ID is generated by the GGSN and shall be unique within the GGSN.

The Charging Gateway Address is the IP address of the recommended Charging Gateway Functionality to which the SGSN should transfer the Charging Detail Records (CDR) for this PDP Context.

The Alternative Charging Gateway Address IE has a similar purpose as the Charging Gateway Address but enables co-existence of IPv4 and IPv6 stacks in the Ga charging interfaces, without mandating any node to have a dual stack. The format of the optional Alternative Charging Gateway Address information element is the same as the format of the Charging Gateway Address.

When both these addresses are present, the Charging Gateway address IE shall contain the IPv4 address of the Charging Gateway Function and the Alternative Charging Gateway address IE shall contain the IPv6 address of the Charging Gateway Function.

NOTE 5: The Charging Gateway Address and Alternative Charging Gateway Address both refer to the same Charging Gateway Function.

The APN Restriction is an optional information element. In this instance it is used by the GGSN to convey to the SGSN the restriction type of the associated PDP Context being set up.

The optional Private Extension contains vendor or operator specific information.

The Protocol Configuration Options (PCO) information element may be included in the response when the GGSN provides the MS with application specific parameters or to indicate the Bearer Control Mode to the MS.

If Bearer Control Mode is provided by the GGSN in the PCO, the Bearer Control Mode IE shall be included in order to inform the SGSN about the bearer control mode and shall indicate the same bearer control mode as indicated to the MS in the PCO.

The presence of the Common Flags IE is optional. If the Prohibit Payload Compression bit of the Common Flags IE is set to 1, then for A/Gb mode access the SGSN shall not compress the payload of user data regardless of whether the user asks for payload compression. If the Prohibit Payload Compression bit of the Common Flags IE is set to 0 or the Common Flags IE is absent then the SGSN shall perform payload compression when the user asks for it as per normal operation.

If the SGSN has indicated the support for MS Info Change Reporting and if the MS Info Change Reporting mechanism is to be started or stopped for this PDN connection, then the GGSN shall include the MS Info Change Reporting Action IE in the message and shall set the value of the Action field appropriately.

If the SGSN has indicated the support for CSG Information Change Reporting and if the CSG Information Reporting mechanism is to be started or stopped for this subscriber, then the GGSN shall include the CSG Information Reporting Action IE in the message and shall set the value of the Action field appropriately. .

If the PDN connection is "Delay Tolerant", the GGSN shall set the DTCI (Delay Tolerant Connection Indication) bit of the Extended Common Flags II to 1.

Table 6: Information Elements in a Create PDP Context Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Reordering required	Conditional	7.7.6
Recovery	Optional	7.7.11
Tunnel Endpoint Identifier Data I	Conditional	7.7.13
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
NSAPI	Optional	7.7.17
Charging ID	Conditional	7.7.26
End User Address	Conditional	7.7.27
Protocol Configuration Options	Optional	7.7.31
GGSN Address for Control Plane	Conditional	GSN Address 7.7.32
GGSN Address for user traffic	Conditional	GSN Address 7.7.32
Alternative GGSN Address for Control Plane	Conditional	GSN Address 7.7.32
Alternative GGSN Address for user traffic	Conditional	GSN Address 7.7.32
Quality of Service Profile	Conditional	7.7.34
Charging Gateway Address	Optional	7.7.44
Alternative Charging Gateway Address	Optional	7.7.44
Common Flags	Optional	7.7.48
APN Restriction	Optional	7.7.49
MS Info Change Reporting Action	Optional	7.7.80
Bearer Control Mode	Optional	7.7.83
Evolved Allocation/Retention Priority I	Optional	7.7.91
Extended Common Flag	Optional	7.7.93
CSG Information Reporting Action	Optional	7.7.95
APN-AMBR	Optional	7.7.98
GGSN Back-Off Time	Optional	7.7.102
Extended Common Flags II	Optional	7.7.118
Private Extension	Optional	7.7.46

7.3.3 Update PDP Context Request

An Update PDP Context Request message shall be sent from an SGSN to a GGSN as part of the GPRS inter-SGSN Routeing Area Update procedure, the PDP Context Modification procedure, to redistribute contexts due to load sharing or as part of the inter-system intra‑SGSN update procedure i.e. UE transitioning between UTRAN and GERAN A/Gb mode (and vice versa) on the same SGSN and if the SGSN decides to enable a direct GTP-U tunnel between the GGSN and the RNC. It shall be used to change the QoS and the path. For the inter-SGSN Routeing Area Update procedure the message shall be sent by the new SGSN.

The Update PDP Context Request shall also be used as part of:

– the Secondary PDP Context Activation Procedure to indicate that RAN Procedures are ready and that the SGSN is ready to receive payload from the GGSN on the new PDP Context;

– the UTRAN/GERAN to UTRAN (HSPA) SRVCC Procedure when the target node is a Gn/Gp SGSN as specified in 3GPP TS 23.216 [50]; or

– the HSS-based P-CSCF restoration procedure as specified in 3GPP TS 23.380 [57].

The NSAPI information element together with the Tunnel Endpoint Identifier in the GTP header unambiguously identifies a PDP Context in the GGSN.

The IMSI, if available, should be included and the GGSN should use the IMSI to verify if the Update PDP Context Request message is received for the right UE context.

NOTE 1: In some error scenarios, e.g. a delete PDP context request is lost over Gn/Gp interface, the hanging PDP Context in the SGSN can trigger an update towards the GGSN, if the GGSN has reassigned the F-TEID of the hanging PDP Context for another UE.

The Tunnel Endpoint Identifier Data field specifies a downlink Tunnel Endpoint Identifier for G-PDUs which is chosen by the SGSN. The GGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent downlink G-PDUs that are related to the requested PDP context.

The Tunnel Endpoint Identifier Control Plane field specifies a downlink Tunnel Endpoint Identifier Control Plane messages which is chosen by the SGSN. The GGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent downlink control plane messages that are related to the requested PDP context. If the SGSN has already confirmed successful assignment of its Tunnel Endpoint Identifier Control Plane to the peer GGSN, this field shall not be present. The SGSN confirms successful assignment of its Tunnel Endpoint Identifier Control Plane to the GGSN when it receives any message with its assigned Tunnel Endpoint Identifier Control Plane in the GTP header from the GGSN.

The Quality of Service Profile information element shall include the QoS negotiated between the MS and SGSN at PDP Context activation or the new QoS negotiated in the PDP Context Modification procedure. The Evolved Allocation/Retention Priority I information element shall include the negotiated Evolved Allocation/Retention Priority if the SGSN supports it and if the support of Evolved ARP has been indicated by the current GGSN or if the SGSN has no information if GGSN supports Evolved ARP. If the SGSN has ever indicated the support of the eARP IE towards a GGSN, it then shall include it in all subsequent GTP messages (i.e. Create PDP Context Request and Update PDP Context Request) towards the same GGSN for a given PDN connection, assuming the eARP remains valid within the subscription and that GGSN supports eARP. The APN-AMBR shall include the negotiated APN-AMBR if the SGSN supports it and if the support of APN-AMBR has been indicated by the current GGSN and the current SGSN changes the APN-AMBR or if the SGSN has no information if GGSN supports APN-AMBR.

The SGSN shall include an SGSN Address for control plane and an SGSN address for user traffic, which may differ from that provided by the underlying network service (e.g. IP).

The following requirements apply for IPv4/IPv6 capable SGSN and GGSN:

– For an Update PDP Context request triggered by an inter-SGSN mobility scenario, if an IPv4/IPv6 capable SGSN did not receive IPv6 addresses for both the GGSN control plane and GGSN user plane from the old SGSN, it shall include IPv4 addresses in the fields SGSN Address for Control Plane and SGSN Address for User Traffic and IPv6 addresses in the fields Alternative SGSN Address for Control Plane and Alternative SGSN Address for User Traffic. Otherwise, an IPv4/IPv6 capable SGSN shall use only SGSN IPv6 addresses if it has GGSN IPv6 addresses available for both the GGSN control plane and GGSN user plane.

– For an Update PDP Context Request triggered by an intra-SGSN scenario, an IPv4/IPv6 capable SGSN should only include SGSN addresses of the same type as the address type currently in use between the SGSN and GGSN for the PDP context, i.e. of the same type as the GGSN Address for Control Plane and GGSN Address for user traffic earlier received from the GGSN. For instance, if IPv4 is currently in use between the SGSN and GGSN, the SGSN should include SGSN IPv4 addresses and it should not include Alternative SGSN Addresses for Control Plane or User Traffic.

– In either case, if IPv6 SGSN addresses are included in the request and the GGSN supports IPv6 below GTP, the GGSN shall store and use the IPv6 SGSN addresses for communication with the SGSN and ignore the IPv4 SGSN addresses. If IPv6 SGSN addresses are included in the request and the GGSN supports only IPv4 below GTP, the GGSN shall store and use the IPv4 SGSN addresses for communication with the SGSN and ignore the IPv6 SGSN addresses. When active contexts are being redistributed due to load sharing, G-PDUs that are in transit across the Gn-interface are in an undetermined state and may be lost.

The SGSN shall include a Recovery information element into the Update PDP Context Request if the SGSN is in contact with the GGSN for the very first time or if the SGSN has restarted recently and the new Restart Counter value has not yet been indicated to the GGSN. The GGSN that receives a Recovery information element in the Update PDP Context Request message element shall handle it in the same way as when receiving an Echo Response message. The Update PDP Context Request message shall be considered as a valid update request for the PDP context indicated in the message.

The Traffic Flow Template (TFT) is used to distinguish between different user traffic flows.

The SGSN shall include Trace Reference, Trace Type, Trigger Id, OMC Identity and Additional Trace Info (Trace reference 2, Trace Recording Session Reference, triggering events in GGSN, Trace Depth, List of interfaces to trace in GGSN and Trace Activity Control) in the message if GGSN trace is activated while the PDP context is active. The SGSN shall copy Trace Reference, Trace Type, OMC Identity and Additional Trace Info from the trace request received from the HLR or OMC and the Trace Activity Control of the Additional Trace Info shall be set to Trace Activation

If SGSN deactivates the Trace Session to GGSN, the SGSN shall include the Additional Trace Info in the message and the Trace Activity Control shall be set to Trace Deactivation.

For more detailed description of Trace Session activation/deactivation procedures see 3GPP TS 32.422 [31]

For SGSN and GGSN trace record description see 3GPP TS 32.423 [32]

The SGSN shall include the Routeing Area Identity (RAI) if the serving core network operator has changed, or the SGSN may include it otherwise. The MCC and MNC components shall be populated with the MCC and MNC of the serving core network operator. The LAC and RAC components shall be populated by the SGSN with the value of "FFFE" and "FF", respectively. See one exception to this rule below in shared GERAN and UTRAN networks.

NOTE 2: The serving core network operator ID is the PLMN ID of the SGSN which is currently serving the UE. An SGSN which supports multiple PLMN IDs is considered as logically different SGSNs.

The optional Private Extension contains vendor or operator specific information.

The MS includes the Protocol Configuration Options (PCO) information element in the request if the MS wishes to provide the GGSN with application specific parameters. The SGSN includes this IE in the Update PDP Context Request if the associated Modify PDP Context Request from the MS includes protocol configuration options. The SGSN shall copy the content of this IE transparently from the content of the PCO IE in the Modify PDP Context Request message.

The presence of the Common Flags IE is optional. If the RAN Procedures Ready bit of the Common Flags IE is set to 1, then SGSN is ready to receive payload on the PDP Context indicated in the message. If RAN Procedures Ready bit of the Common Flags IE is set to 0 or the Common Flags IE is absent then the RAN procedures in the SGSN may or may not be ready. If the NRSN bit of the Common Flags IE is set to 1, the SGSN supports the network requested bearer control. If NRSN bit of the Common Flags IE is set to 0 or the Common Flags IE is absent then the SGSN does not support network requested bearer control. Handling of the Common Flags IE (also the handling of "No QoS negotiation" bit in the Common Flags IE) by GGSN is specified in clause 7.3.4 "Update PDP Context Response". If the Upgrade QoS Supported bit of the Common Flags IE is set to 1, the SGSN supports the QoS upgrade in Response message functionality. If Upgrade QoS Supported bit of the Common Flags IE is set to 0 or the Common Flags IE is absent then the SGSN does not support QoS upgrade in Response message functionality.

If the Direct Tunnel Flags IE is included and if the DTI bit of the Direct Tunnel Flags IE is set to 1, this indicates to the GGSN that for this PDP Context the SGSN is invoking a direct tunnel. In this case, the GGSN shall not change the allocated userplane Tunnel Endpoint Identifier Data and IP address in the corresponding Update PDP Context Response message. If the DTI bit of the Direct Tunnel Flags IE is set to 0 or the Direct Tunnel Flags IE is absent, this indicates to the GGSN that for this PDP Context the SGSN is not invoking a direct tunnel. All other fields of the Direct Tunnel Flags IE shall be ignored.

The SGSN may include the MS Time Zone IE if it is available (see clause 15.1.1a of 3GPP TS 23.060 [4] for more information). The SGSN shall include the User Location Information IE in the PDP Context Modification procedure and, if the SGSN has deferred the reporting of a previous ULI change until a RAB or user plane is established (see clause 7.5B.1.1), in a Service Request procedure when establishing a direct GTP-U tunnel between the GGSN and the RNC. The SGSN may include the User Location Information IE in the other procedures. If the User Location Information IE is included then the SGSN shall include the CGI or SAI in the "Geographic Location" field depending on whether the MS is in a cell or a service area respectively. If the SGSN supports CSG Information Change Reporting and if CSG Change Reporting is requested by the GGSN via the CSG Information Reporting Action, the SGSN shall include the User CSG Information IE if the UE is accessed via CSG cell or Hybrid cell. If the User CSG Information IE is included then the SGSN shall include the CSG ID, Access mode, the CSG Membership Indication shall also be included if the Access mode is Hybrid Mode. If the User CSG Information IE is not received, the GGSN shall consider that the UE has left CSG cell or the hybrid cell.

In shared networks,

The SGSN shall include the RAT Type IE if the RAT Type has changed or the SGSN may include it otherwise (see clause 15.1.1a of 3GPP TS 23.060 [4] for more information).

The presence of the Extended Common Flags IE is optional. The CSG Change Reporting Support Indication (CCRSI) bit field shall be set to 1 if the SGSN supports CSG Information Change Reporting and if the SGSN’s operator policy permits reporting of User CSG Information change to the operator of the GGSN. If the CCRSI bit field is set to 0 or the Extended Common Flags IE is not included in the message, the GGSN shall assume that the SGSN originating the message does not support the CSG Information Change Reporting. 3GPP TS 23.060 [4] (e.g. clause 9.2.2.1) defines the SGSN shall send the MS Info Change Reporting Support Indication to the GGSN. In such case SGSN shall use the CSG Change Reporting Support Indication for CSG Information Reporting even if stage 2 refers to MS Info Change Reporting Support Indication. The CS to PS SRVCC indication (CPSR) bit field shall be set to 1 if UTRAN/GERAN to UTRAN (HSPA) SRVCC Procedure is underway as specified in 3GPP TS 23.216 [50].

The SGSN shall include the Extended Common Flags IE and set the PCRI (P-CSCF Restoration Indication) bit field to 1, for the IMS PDN connection, if the SGSN has received the indication from the HSS that a P-CSCF restoration is required for this user, as specified in 3GPP TS 23.380 [57]. If the PDN connection is "Delay Tolerant" and if there is pending network initiated PDN connection signalling, the SGSN shall set the UASI (UE Available for Signalling Indication) bit field during a RAU, a Service Request procedure for UTRAN, or at receipt of an uplink LLC PDU for user data or any valid LLC frame serving as a paging response for GERAN.

The SGSN shall include the Signalling Priority Indication IE during a PDP Context Modification procedure if the UE indicates low access priority during that procedure.

In shared networks, the SGSN shall include the CN Operator Selection Entity IE during the Routeing Area Update procedure, if the information is available, to indicate whether the Serving Network has been selected by the UE or by the network.

The IMEI(SV) should be included if the IMSI is not available and the GGSN should use the IMEI(SV) to verify if the Update PDP Context Request message is received for the right UE context.

Table 7: Information Elements in an SGSN-Initiated Update PDP Context Request

Information element	Presence requirement	Reference
IMSI	Optional	7.7.2
Routeing Area Identity (RAI)	Optional	7.7.3
Recovery	Optional	7.7.11
Tunnel Endpoint Identifier Data I	Mandatory	7.7.13
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
NSAPI	Mandatory	7.7.17
Trace Reference	Optional	7.7.24
Trace Type	Optional	7.7.25
Protocol Configuration Options	Optional	7.7.31
SGSN Address for Control Plane	Mandatory	GSN Address 7.7.32
SGSN Address for User Traffic	Mandatory	GSN Address 7.7.32
Alternative SGSN Address for Control Plane	Conditional	GSN Address 7.7.32
Alternative SGSN Address for User Traffic	Conditional	GSN Address 7.7.32
Quality of Service Profile	Mandatory	7.7.34
TFT	Optional	7.7.36
Trigger Id	Optional	7.7.41
OMC Identity	Optional	7.7.42
Common Flags	Optional	7.7.48
RAT Type	Optional	7.7.50
User Location Information	Optional	7.7.51
MS Time Zone	Optional	7.7.52
Additonal Trace Info	Optional	7.7.62
Direct Tunnel Flags	Optional	7.7.81
Evolved Allocation/Retention Priority I	Optional	7.7.91
Extended Common Flags	Optional	7.7.93
User CSG Information	Optional	7.7.94
APN-AMBR	Optional	7.7.98
Signalling Priority Indication	Optional	7.7.103
CN Operator Selection Entity	Optional	7.7.116
IMEI(SV)	Optional	7.7.53
Private Extension	Optional	7.7.46

An Update PDP Context Request may also be sent from a GGSN to an SGSN:

– to re-negotiate the QoS of a PDP context;

– to provide a PDP address to the SGSN (and MS);

– to request the User Location Information IE from the SGSN. The latter shall be used by GGSN when it acts as a DHCP Relay Agent or Mobile IP Foreign Agent;

– to request the start/stop of MS Info Change Reporting and/or CSG Info Change Reporting;

– to check that the PDP context is still active at the SGSN. In such a case, the GGSN shall include the optional IMSI IE, to add robustness against the case the SGSN has re-assigned the TEID to another PDP context (this may happen when the PDP context is dangling at the GGSN). Also, the "Quality of service profile" IE and the "End user Address" IE shall not be included in this case;

– for network requested bearer control, to add, modify or delete the TFT related to the PDP Context or to change the Bearer Control Mode;

– when a direct tunnel is used and the GGSN receives an Error Indication message from the RNC. In such a case, the GGSN shall include the NSAPI IE and the Direct Tunnel Flags IE with the EI bit set; orNOTE 2: SGSN and GGSN behaviour for RNC failure and recovery is defined in 3GPP TS 23.007 [3].

– as part of the P-CSCF restoration procedure (see 3GPP TS 23.380 [57]).

The Quality of Service Profile information element shall include the GGSN requested QoS. The Evolved Allocation/Retention Priority I IE shall be included if Evolved Allocation/Retention Priority has been newly authorized and if the GGSN supports this IE and if the support of Evolved ARP has been indicated by the current SGSN. The APN-AMBR IE shall be included if APN-AMBR has been newly authorized and if the GGSN supports this IE and if the support of APN-AMBR has been indicated by the current SGSN.

The End User Address information element shall contain a valid IPv4 or IPv6 address.

The GGSN shall include a Recovery information element into the Update PDP Context Request if the GGSN has restarted recently and the new Restart Counter value has not yet been indicated to the SGSN. The SGSN that receives a Recovery information element in the Update PDP Context Request message element shall handle it in the same way as when receiving an Echo Response message. The Update PDP Context Request message shall be considered as a valid update request for the PDP context indicated in the message.

The NSAPI information element together with the Tunnel Endpoint Identifier in the GTP header unambiguously identifies a PDP Context in the SGSN.

The GGSN includes the Protocol Configuration Options (PCO) information element in the request if the GGSN wishes to provide the MS with application specific parameters or to indicate the Bearer Control Mode to the MS. The SGSN includes this IE in the Modify PDP Context Request message if the associated Update PDP Context Request message from the GGSN includes protocol configuration options. The SGSN shall copy the content of this IE transparently from the content of the PCO IE in the Update PDP Context Request message.

The optional Private Extension contains vendor or operator specific information.

The TFT is optional and included in order to add, modify or delete the TFT related to the PDP Context for network requested bearer control.

The APN Restriction is an optional information element. In this instance it is used by the GGSN to convey to the SGSN the restriction type of the associated PDP Context being updated.

If the SGSN has indicated the support for MS Info Change Reporting and if the MS Info Change Reporting mechanism is to be started or stopped for this subscriber, then the GGSN shall include the MS Info Change Reporting Action IE in the message and shall set the value of the Action field appropriately.

If the SGSN has indicated the support for CSG Information Change Reporting and if the CSG Information Reporting mechanism is to be started or stopped for this PDN connection, then the GGSN shall include the CSG Information Reporting Action IE in the message and shall set the value of the Action field appropriately.

The GGSN shall include the Extended Common Flags IE and set the RetLoc (Retrieve Location) bit field to 1 if it requests the SGSN to provide the user’s location information, e.g. upon receipt of such a request from the PCRF. If the GGSN initiated Update PDP Context Request message is only used to request the user’s location information from the SGSN, the NSAPI IE shall be any one of the already activated PDP contexts for this PDN connection.

Table 8: Information Elements in a GGSN-Initiated Update PDP Context Request

Information element	Presence requirement	Reference
IMSI	Optional	7.7.2
Recovery	Optional	7.7.11
NSAPI	Mandatory	7.7.17
End User Address	Optional	7.7.27
Protocol Configuration Options	Optional	7.7.31
Quality of Service Profile	Optional	7.7.34
TFT	Optional	7.7.36
Common Flags	Optional	7.7.48
APN Restriction	Optional	7.7.49
MS Info Change Reporting Action	Optional	7.7.80
Direct Tunnel Flags	Optional	7.7.81
Bearer Control Mode	Optional	7.7.83
Evolved Allocation/Retention Priority I	Optional	7.7.91
Extended Common Flags	Optional	7.7.93
CSG Information Reporting Action	Optional	7.7.95
APN-AMBR	Optional	7.7.98
Private Extension	Optional	7.7.46

7.3.4 Update PDP Context Response

The message shall be sent from a GGSN node to a SGSN node as a response of an Update PDP Context Request.

If the SGSN receives an Update PDP Context Response with a Cause value other than "Request accepted", it shall abort the update of the PDP context.

If the SGSN receives an Update PDP Context Response with a Cause value "Non-existent", it shall delete the PDP Context.

Possible Cause values are:

– "Request Accepted".

– "Non-existent".

– "Service not supported".

– "System failure".

– "Semantic error in the TFT operation".

– "Syntactic error in the TFT operation".

– "Semantic errors in packet filter(s)".

– "Syntactic errors in packet filters(s)".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

– "Bearer Control Mode violation".

– "Bearer handling not supported".

– "UE is temporarily not reachable due to power saving".

If the update PDP context request is related to an established PDP context for LIPA or for SIPTO at the local network, the LGW shall reject the update PDP context request with the cause value of "Bearer handling not supported".

The Tunnel Endpoint Identifier Data field specifies an uplink Tunnel Endpoint Identifier for G-PDUs that is chosen by the GGSN. The SGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent uplink G-PDUs that are related to the requested PDP context. This information element shall be included if the Cause contains the value "Request accepted" and may contain a new Tunnel Endpoint Identifier Data only if DTI bit of the Direct Tunnel Flags IE is set to 0 or the Direct Tunnel Flags IE is absent in the corresponding Update PDP Context Request.

The Tunnel Endpoint Identifier Control Plane field specifies an uplink Tunnel Endpoint Identifier Control Plane messages which is chosen by the GGSN. The SGSN shall include this Tunnel Endpoint Identifier in the GTP header of all subsequent uplink control plane messages which are related to the requested PDP context. If the GGSN has already confirmed successful assignment of its Tunnel Endpoint Identifier Control Plane to the peer SGSN, this field shall not be present. The GGSN confirms successful assignment of its Tunnel Endpoint Identifier Control Plane to the SGSN when it receives any message with its assigned Tunnel Endpoint Identifier Control Plane in the GTP header from the SGSN.

The QoS values supplied in the Update PDP Context Request may be negotiated downwards by the GGSN. If the SGSN has indicated support for upgrade of QoS in the request message, the QoS values may also be negotiated upwards by the GGSN. In case the "No QoS negotiation" flag has been set to 1 by the SGSN in the corresponding request, the QoS values shall not be renegotiated, neither upwards, nor downwards (see also PCO handling below). The negotiated values or the original value from SGSN is inserted in the Quality of Service Profile information element. This information element shall be included if the Cause contains the value "Request accepted". The Evolved Allocation/Retention Priority I IE shall be included if Evolved Allocation/Retention Priority has been newly authorized and if the GGSN supports this IE and if the Evolved ARP has been included in the corresponding request message. If there is no authorized Evolved ARP received from GGSN, SGSN shall continue to use legacy ARP included in the Quality of Service (QoS) Profile IE. The APN-AMBR IE shall be included if APN-AMBR has been newly authorized and if the GGSN supports this IE and if the APN-AMBR has been included in the corresponding request message.

The GGSN may start to forward T-PDUs after the Update PDP Context Response has been sent. The SGSN may start to forward T-PDUs when the Update PDP Context Response has been received. In this case the SGSN shall also be prepared to receive T-PDUs from the GGSN after it has sent an Update PDP Context Request but before an Update PDP Context Response has been received.

The GGSN shall include a GGSN address for user traffic, which may differ from that provided by the underlying network service (e.g. IP). If DTI bit of the Direct Tunnel Flags IE is set to 0 or the Direct Tunnel Flags IE is absent in the corresponding Update PDP Context Request, and the GGSN needs to change the IP Address, the GGSN shall include the new IP address. Otherwise, the GGSN shall include the currently used IP address. An IPv4/IPv6 capable GGSN shall include both its IP version addresses. If the Update PDP Context Request received from the SGSN included IPv6 SGSN addresses, an IPv4/IPv6 capable GGSN shall include an IPv6 address in the field GGSN Address for User Traffic and a corresponding IPv4 address in the field Alternative GGSN Address for User Traffic. If SGSN included only an IPv4 SGSN address in the request, IPv4/IPv6 capable GGSN shall include IPv4 address for user traffic in the field GGSN Address for User Traffic and IPv6 address in the field Alternative GGSN Address for User Traffic. An IPv4/IPv6 capable SGSN shall store the GGSN Addresses and use the address received in the field GGSN Address for user traffic when sending G-PDUs to the GGSN for the MS. An IPv4 only SGSN shall not store the IPv6 address included in the Alternative GGSN Address. When active contexts are being redistributed due to load sharing, G‑PDUs that are in transit across the Gn-interface are in an undetermined state and may be lost.

The GGSN shall also include a GGSN address for control plane, which shall not differ from that provided at PDP context setup time and shall remain unchanged for the lifetime of the PDP context. If the Update PDP Context Request received from the SGSN included IPv6 SGSN addresses, an IPv4/IPv6 capable GGSN shall include an IPv6 address in the field GGSN Address for Control Plane and a corresponding IPv4 address in the field Alternative GGSN Address for Control Plane. If SGSN included only an IPv4 SGSN address in the request, IPv4/IPv6 capable GGSN shall include IPv4 address for Control plane in the field GGSN Address for Control Plane and IPv6 address for Control plane in the field Alternative GGSN Address for Control Plane. An IPv4/IPv6 capable SGSN shall use the address received in the field GGSN Address for Control Plane when sending control plane signalling on this GTP tunnel to the GGSN for the MS.

The GGSN Address for control plane and the GGSN Address for user traffic shall be included if the Cause contains the value "Request accepted". The Alternative GGSN Addresses shall be included if the GGSN supports IPv6 below GTP and the Cause contains the value "Request accepted".

The GGSN shall include the Recovery information element into the Update PDP Context Response if the GGSN is in contact with the SGSN for the first time or if the GGSN has restarted recently and the new Restart Counter value has not yet been indicated to the SGSN. The SGSN receiving the Recovery information element shall handle it as when an Echo Response message is received but shall consider the PDP context as updated and active if the response cause indicates a successful operation at the GGSN.

The Charging ID is used to identify all charging records produced in SGSN(s) and the GGSN for this PDP context. The Charging ID has been previously generated by the GGSN and is unique for this PDP context. If an inter-SGSN routing area update occurs, it is transferred to the new SGSN as part of each active PDP context. This information element shall be included if the Cause contains the value "Request accepted".

The Charging Gateway Address is the IP address of the recommended Charging Gateway Functionality to which the SGSN should transfer the Charging Detail Records (CDR) for this PDP Context.

NOTE 1: The Charging Gateway Address and Alternative Charging Gateway Address both refer to the same Charging Gateway Function.

The optional Private Extension contains vendor or operator specific information.

The GGSN may include the Protocol Configuration Options (PCO) information element in the response if the GGSN wishes to provide the MS with application specific parameters or to indicate the Bearer Control Mode to the MS.

If the "No QoS negotiation" bit of the Common Flags IE in the Update PDP Context Request message was set to 1, then the GGSN shall not re-negotiate QoS in the corresponding Update PDP Context Response and shall not include the Protocol Configuration Options (PCO) information element in the message). If the "No QoS negotiation" bit of the Common Flags IE was set to 0 or the Common Flags IE was absent from the Update PDP Context Request message (e.g. message was sent by pre Rel-7 SGSN), then:

– the GGSN may re-negotiate QoS in the corresponding Update PDP Context Response;

– the GGSN may include a PCO in the Update PDP Context Response message, but the PCO shall contain at least the same information as the PCO IE, which was sent earlier (see e.g. clause 9.2.2 "Activation Procedures" in 3GPP TS 23.060 [4]).

The APN Restriction is an optional information element. In this instance it is used by the GGSN to convey to the SGSN the restriction type of the associated PDP Context being updated.

If the SGSN has indicated the support for MS Info Change Reporting and if the MS Info Change Reporting mechanism is to be started or stopped for this PDN connection in the SGSN, then the GGSN shall include the MS Info Change Reporting Action IE in the message and shall set the value of Action field appropriately.

Table 9: Information Elements in an Update PDP Context Response sent by a GGSN

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Recovery	Optional	7.7.11
Tunnel Endpoint Identifier Data I	Conditional	7.7.13
Tunnel Endpoint Identifier Control Plane	Conditional	7.7.14
Charging ID	Conditional	7.7.26
Protocol Configuration Options	Optional	7.7.31
GGSN Address for Control Plane	Conditional	GSN Address 7.7.32
GGSN Address for User Traffic	Conditional	GSN Address 7.7.32
Alternative GGSN Address for Control Plane	Conditional	GSN Address 7.7.32
Alternative GGSN Address for User Traffic	Conditional	GSN Address 7.7.32
Quality of Service Profile	Conditional	7.7.34
Charging Gateway Address	Optional	7.7.44
Alternative Charging Gateway Address	Optional	7.7.44
Common Flags	Optional	7.7.48
APN Restriction	Optional	7.7.49
Bearer Control Mode	Optional	7.7.83
MS Info Change Reporting Action	Optional	7.7.80
Evolved Allocation/Retention Priority I	Optional	7.7.91
CSG Information Reporting Action	Optional	7.7.95
APN-AMBR	Optional	7.7.98
Private Extension	Optional	7.7.46

The message can also be sent from a SGSN node to a GGSN node as a response of a GGSN-initiated Update PDP Context Request.

If the GGSN receives an Update PDP Context Response with a Cause value other than "Request accepted", it shall abort the update of the PDP context if the associated Update PDP Context Request was sent only to re-negotiate the QoS of a PDP context. Furthermore if the associated Update PDP Context Request included an "End User Address" information element the GGSN shall delete the PDP context using the Delete PDP Context procedure and may notify the Operation and Maintenance network element.

Possible Cause values are the same as for the Update PDP Context Response sent by a GGSN except the cause code "UE is temporarily not reachable due to power saving" shall only be included by a SGSN. When the optional IMSI IE value differs from the IMSI IE value associated to the PDP context, the SGSN shall respond using the cause value "Non-existent".

The SGSN includes the Protocol Configuration Options (PCO) information element in the response if the MS wishes to provide the GGSN with application specific parameters. The SGSN includes this IE in the Update PDP Context Response message if the associated Modify PDP Context Accept message from the MS includes protocol configuration options. The SGSN shall copy the content of this IE transparently from the content of the PCO IE in the Modify PDP Context Accept message.

The QoS values supplied in the Update PDP Context Request may be negotiated downwards by the SGSN. The negotiated values or the original value from GGSN is inserted in the Quality of Service Profile information element. This information element shall be included if the Cause contains the value "Request accepted" and a QoS information element was supplied in the corresponding request message. The Evolved Allocation/Retention Priority I information element shall include the negotiated Evolved Allocation/Retention Priority if the SGSN supports this IE and if an Evolved Allocation/Retention Priority I information element was supplied in the corresponding request message. The APN-AMBR IE shall be included if the SGSN supports this IE and if the APN-AMBR has been included in the corresponding request message.

The SGSN shall include the Recovery information element into the Update PDP Context Response if the SGSN has restarted recently and the new Restart Counter value has not yet been indicated to the GGSN. The GGSN receiving the Recovery information element shall handle it as when an Echo Response message is received but shall consider the PDP context as updated and active if the response cause indicates a successful operation at the SGSN.

If the SGSN sends Update PDP Context Response message in order to re-establish the user plane tunnel between SGSN and GGSN, then the SGSN includes only the Cause IE, the SGSN Address for User Traffic IE and Tunnel Endpoint Identifier Data IE. The GGSN shall include Tunnel Endpoint Identifier Data in the GTP header of all subsequent downlink G-PDUs which are related to the requested PDP Context.

In the MS to GGSN direction, the SGSN shall include the User Location Information IE, and may include the MS Time Zone information element. The SGSN shall include the CGI or SAI in the "Geographic Location" field of the User Location Information IE depending on whether the MS is in a cell or a service area respectively.

In shared networks,

– when the message is sent from the VPLMN to the HPLMN, the PLMN ID that is communicated in the User Location Information IE shall be that of the selected Core Network Operator for supporting UEs, or that of the allocated Core Network Operator for non-supporting UEs. As an exception, based on inter-operator roaming/sharing agreement, if the information on whether the UE is a supporting or non-supporting UE is available, the PLMN ID that is communicated to the HPLMN for non-supported UEs shall be the Common PLMN ID. See clause 4.4 of 3GPP TS 23.251 [35];

If the Direct Tunnel Flags IE is included and if the DTI bit of the Direct Tunnel Flags IE is set to 1, this indicates to the GGSN that for this PDP Context the SGSN is invoking a direct tunnel. If the DTI bit of the Direct Tunnel Flags IE is set to 0 or the Direct Tunnel Flags IE is absent, this indicates to the GGSN that for this PDP Context the SGSN is not invoking a direct tunnel. All other fields of the Direct Tunnel Flags IE shall be ignored.

If the Direct Tunnel Flags IE is included with the DTI bit set to 1, and if the SGSN Address for User Traffic IE and Tunnel Endpoint Identifier Data IE are also included, they shall contain RNC’s User Plane address and TEID.

If the Direct Tunnel Flags IE is absent, or the DTI bit is set to 0, but the SGSN Address for User Traffic IE and Tunnel Endpoint Identifier Data IE are included they shall contain SGSN’s User Plane addresses and TEID.

NOTE 2: Use case, when the DT is still used and the RNC TEID and/or user plane address has changed cannot be clarified in this release for backward compatibility reasons.

Table 10: Information Elements in an Update PDP Context Response sent by a SGSN

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Recovery	Optional	7.7.11
Tunnel Endpoint Identifier Data I	Optional	7.7.13
Protocol Configuration Options	Optional	7.7.31
SGSN Address for User Traffic	Optional	GSN Address 7.7.32
Quality of Service Profile	Conditional	7.7.34
User Location Information	Optional	7.7.51
MS Time Zone	Optional	7.7.52
Direct Tunnel Flags	Optional	7.7.81
Evolved Allocation/Retention Priority I	Optional	7.7.91
APN-AMBR	Optional	7.7.98
Private Extension	Optional	7.7.46

7.3.5 Delete PDP Context Request

A Delete PDP Context Request shall be sent from a SGSN node to a GGSN node as part of the GPRS Detach procedure or the GPRS PDP Context Deactivation procedure or from a GGSN node to a SGSN node as part of the PDP Context Deactivation Initiated by GGSN procedure. A request shall be used to deactivate an activated PDP Context or an activated set of PDP contexts associated to a PDN connection. The Delete PDP Context Request shall also be used as part of the UTRAN (HSPA) to UTRAN/GERAN SRVCC Procedure when the source node is a Gn/Gp SGSN as specified in 3GPP TS 23.216 [50].

A GSN shall be prepared to receive a Delete PDP Context Request at any time and shall always reply regardless if the PDP context exists or not (as per the Delete PDP Context Response message description clause), except in cases described below.

If any collision occurs, the Delete PDP Context Request takes precedence over any other Tunnel Management message.

The Teardown Ind is used to indicate whether all PDP contexts that share the same PDN connection with the PDP context identified in the request should also be deactivated. This may trigger the deletion of all the information kept for a MS at a GSN, if no other PDP contexts associated to other PDP addresses are active on the GSN. If the Teardown Ind information element value is set to "1", then all PDP contexts that share the same PDN connection with the PDP context identified by the NSAPI included in the Delete PDP Context Request Message shall be torn down. If more than one PDP Contexts are active that share the same PDN connection, only the PDP context identified by the NSAPI included in the Delete PDP context Request shall be torn down if the value of this information element is "0" or this information is not included. The SGSN shall copy this IE to the Delete PDP Context Request from the associated Deactivate PDP Context Request initiated by MS, if it is included. This information element shall NOT be included by the SGSN if the Deactivate PDP Context Request message from the MS does NOT include the Tear down indicator at PDP Context Deactivation initiated by MS. However, exceptionally this information element shall be included and its value set to "1" by the sending GSN only when the last PDP context associated to a PDN connection is torn down and there are no outstanding Create PDP context requests for other PDP context different from the one being torn down for that PDN connection.

If a GSN receives a Delete PDP context without a Teardown Indicator or with a Teardown Indicator with value set to "0" and only that PDP context is active for a PDN connection, then the GSN shall ignore the message. (Note: This is symptom of a race condition. The reliable delivery of signalling messages will eventually lead to a consistent situation, allowing the teardown of the PDP context.)

In the MS to GGSN direction, the SGSN includes the Protocol Configuration Options (PCO) information element in the request if the MS wishes to provide the GGSN with application specific parameters. The SGSN includes this IE in the Delete PDP Context Request message if the associated Deactivate PDP Context Request message from the MS includes protocol configuration options. The SGSN shall copy the content of this IE transparently from the PCO IE in the Deactivate PDP Context Request message.

In the MS to GGSN direction, the SGSN shall include the MS Time Zone information element, if it has changed since last reported.

In the MS to GGSN direction, the SGSN shall include the User Location Information information element and the ULI Timestamp information element indicating the time when the User Location Information was acquired. The SGSN shall include the CGI or SAI in the "Geographic Location" field of the User Location Information IE depending on whether the MS is in a cell or a service area respectively.

In shared networks,

In the GGSN to MS direction, the GGSN includes the Protocol Configuration Options (PCO) information element in the request if the GGSN wishes to provide the MS with application specific parameters. The SGSN includes this IE in the Deactivate PDP Context Request message if the associated Delete PDP Context Request message from the GGSN includes protocol configuration options. The SGSN shall copy the content of this IE transparently from the PCO IE in the Delete PDP Context Request message.

In the GGSN to MS direction, the GGSN may include Cause IE with the value "Reactivation Requested". In that case, the GGSN shall include the Teardown Ind information element with its value set to "1". If the SGSN supports this IE in this message, it shall map it to corresponding NAS cause code with the same name (see 3GPP TS 24.008 [5]) in the Deactivate PDP Context Request message.

The presence of the Extended Common Flags IE is optional. The Voice Bearer (VB) bit field shall be set to 1 if the PDP context to be deleted is used for voice during UTRAN (HSPA) to UTRAN/GERAN SRVCC Procedure as specified in 3GPP TS 23.216 [50].

The optional Private Extension contains vendor or operator specific information.

The SGSN shall include the Cause IE if the Delete PDP Context Request message is sent to the GGSN due to a network problem as specified in the clause 15.7 of 3GPP TS 23.060 [4]. It indicates to the peer entity the reason of the failure.

Possible Cause Values are:

– "Network Failure".

– "QoS parameter mismatch".

Table 11: Information Elements in a Delete PDP Context Request

Information element	Presence requirement	Reference
Cause	Optional	7.7.1
Teardown Ind	Conditional	7.7.16
NSAPI	Mandatory	7.7.17
Protocol Configuration Options	Optional	7.7.31
User Location Information	Optional	7.7.51
MS Time Zone	Optional	7.7.52
Extended Common Flags	Optional	7.7.93
ULI Timestamp	Optional	7.7.114
Private Extension	Optional	7.7.46

7.3.6 Delete PDP Context Response

The message shall be sent as a response of a Delete PDP Context Request. A GSN shall delete PDP context(s) when GSN receives Delete PDP Context Request message.

A GSN shall ignore a Delete PDP Context Response for a non-existing PDP context.

If a GSN receives a Delete PDP Context Request message for a non existing PDP context, it shall send back to the source of the message a Delete PDP Context Response message with cause value "Non existent". The TEID value used in the response message shall be zero.

Possible Cause values are:

– "Request Accepted".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE Incorrect".

– "Invalid message format".

– "Non existent".

For error handling, if the received Delete PDP Context Response contains a cause value other than "Request accepted" and "Non Existent", refer to clause 11.

In the GGSN to MS direction, the GGSN includes the Protocol Configuration Options (PCO) information element in the response if the GGSN wishes to provide the MS with application specific parameters. The SGSN includes this IE in the Deactivate PDP Context Accept message if the associated Delete PDP Context Response message from the GGSN includes protocol configuration options. The SGSN shall copy the content of the IE transparently from the PCO IE in the Delete PDP Context Response message.

In the MS to GGSN direction, the SGSN includes the Protocol Configuration Options (PCO) information element in the response if the MS wishes to provide the GGSN with application specific parameters. The SGSN includes this IE in the Delete PDP Context Response message if the associated Deactivate PDP Context Accept message from the MS includes protocol configuration options. The SGSN shall copy the content of the IE transparently from the PCO IE in the Deactivate PDP Context Accept message.

In the MS to GGSN direction, the SGSN shall include the MS Time Zone information element, if it has changed since last reported.

In shared networks,

The optional Private Extension contains vendor or operator specific information.

Table 12: Information Elements in a Delete PDP Context Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Protocol Configuration Options	Optional	7.7.31
User Location Information	Optional	7.7.51
MS Time Zone	Optional	7.7.52
ULI Timestamp	Optional	7.7.114
Private Extension	Optional	7.7.46

7.3.7 Error Indication

Error Indication message is specified in 3GPP TS 29.281 [42].

7.3.8 PDU Notification Request

When receiving a T-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 T-PDU by initiating the Network-Requested PDP Context Activation procedure. The criteria, used by the GGSN to determine whether trying to deliver the T-PDU to the MS or not, may be based on subscription information in the GGSN and are outside the scope of GPRS standardisation.

As part of the Network-Requested PDP Context Activation procedure the GGSN sends a PDU Notification Request message to the SGSN indicated by the HLR. If the GGSN has an active PDP context with different SGSN from the one indicated by the HLR, then the SGSN information shall be obtained from an active PDP context. When receiving this message, the SGSN shall be responsible for requesting the MS to activate the indicated PDP Context.

The IMSI is inserted in the IMSI information element in the PDU Notification Request message.

The End User Address information element contains the PDP type and PDP address that the SGSN shall request the MS to activate.

The Access Point Name information element identifies the access point of packet data network that wishes to connect to the MS.

The GGSN shall include a GGSN Address for control plane. The SGSN shall store this GGSN Address and use it when sending control plane messages to the GGSN.

The Tunnel Endpoint Identifier Control Plane information element shall be a tunnel endpoint identifier Control Plane selected by the GGSN and shall be used by the SGSN in the GTP header of the corresponding PDU Notification Response or PDU Notification Request Reject message.

The GGSN includes the Protocol Configuration Options (PCO) information element in the request if the GGSN wishes to provide the MS with application specific parameters. The SGSN includes this IE in the Request PDP Context Activation message if the associated PDU Notification Request message from the GGSN includes protocol configuration options. The SGSN shall copy the content of the IE transparently from the PCO IE in the PDU Notification Request message.

If the GGSN receives a Create PDP Context Request before the PDU Notification Response, the GGSN shall handle the Create PDP Context Request as normal context activation and ignore the following PDU Notification Response.

If the SGSN receives a PDU Notification Request after a Create PDP Context Request has been sent but before a Create PDP Context Response has been received, the SGSN shall:

– send a PDU Notification Response with Cause "Request accepted" without any further processing; and then

– wait for the Create PDP Context Response.

The optional Private Extension contains vendor or operator specific information.

Table 14: Information Elements in a PDU Notification Request

Information element	Presence requirement	Reference
IMSI	Mandatory	7.7.2
Tunnel Endpoint Identifier Control Plane	Mandatory	7.7.14
End User Address	Mandatory	7.7.27
Access Point Name	Mandatory	7.7.30
Protocol Configuration Options	Optional	7.7.31
GGSN Address for Control Plane	Mandatory	7.7.32
Private Extension	Optional	7.7.46

7.3.9 PDU Notification Response

The message is sent by a SGSN to GGSN as a response of a PDU Notification Request.

The Cause value "Request accepted" indicates if the PDP context activation will proceed. The PDP context activation procedure will not proceed for other Cause values.

Possible Cause values are:

– "Request Accepted".

– "No resources available".

– "Service not supported".

– "System failure".

– "IMSI/IMEI not known".

– "MS is GPRS Detached".

– "GPRS connection suspended".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

– "Roaming restriction".

After an unsuccessful activation attempt the GSNs may perform some actions to prevent unnecessary enquires to the HLR as described in the clause Unsuccessful Network-Requested PDP Context Activation procedure in 3GPP TS 23.060 [4].

The optional Private Extension contains vendor or operator specific information.

Table 15: Information Elements in a PDU Notification Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Private Extension	Optional	7.7.46

7.3.10 PDU Notification Reject Request

If the PDP context activation proceeds after the PDU Notification Response, but the PDP context was not established, the SGSN sends a PDU Notification Reject Request message. The Cause value indicates the reason why the PDP Context could not be established:

– "MS is not GPRS Responding".

– "MS Refuses".

When receiving the PDU Notification Reject Request message the GGSN may reject or discard the stored T-PDU(s) depending on the PDP type.

After an unsuccessful activation attempt the GSNs may perform some actions to prevent unnecessary enquiries to the HLR as described in the clause Unsuccessful Network-Requested PDP Context Activation procedure in 3GPP TS 23.060 [4].

The Tunnel Endpoint Identifier in the GTP header of the PDU Notification Reject Request message shall be the same as the Tunnel Endpoint Identifier Control Plane information element of the PDU Notification Request that triggered the reject.

The Tunnel Endpoint Identifier Control Plane information element shall be a tunnel endpoint identifier Control Plane selected by the SGSN and shall be used by the GGSN in the GTP header of the corresponding PDU Notification Reject Response message.

The End User Address information element contains the PDP type and PDP address of the PDP context that could not be activated.

The Access Point Name shall be the same as the Access Point Name of the received PDU Notification Request message that triggered the reject.

The SGSN includes the Protocol Configuration Options (PCO) information element in the request if the MS wishes to provide the GGSN with application specific parameters. The SGSN includes this IE in the PDU Notification Reject Request message if the associated Request PDP Context Activation Reject message from the MS includes protocol configuration options. The SGSN shall copy the content of the IE transparently from the PCO IE in the Request PDP Context Activation Reject message.

The optional Private Extension contains vendor or operator specific information.

Table 16: Information Elements in a PDU Notification Reject Request

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Tunnel Endpoint Identifier Control Plane	Mandatory	7.7.14
End User Address	Mandatory	7.7.27
Access Point Name	Mandatory	7.7.30
Protocol Configuration Options	Optional	7.7.31
Private Extension	Optional	7.7.46

7.3.11 PDU Notification Reject Response

The message is sent by a GGSN to SGSN as a response of a PDU Notification Reject Request.

Possible Cause values are:

– "Request Accepted".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

The optional Private Extension contains vendor or operator specific information.

Table 17: Information Elements in a PDU Notification Reject Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Private Extension	Optional	7.7.46

7.3.12 Initiate PDP Context Activation Request

The GGSN sends an Initiate PDP Context Activation Request message to the SGSN to initiate the Secondary PDP Context Activation Procedure for network requested bearer control.

The Initiate PDP Context Activation Request shall be sent to the SGSN Address for Control Plane and TEID associated with any one of the already activated PDP contexts for this PDN connection.

Linked NSAPI indicates the NSAPI assigned to any one of the already activated PDP contexts for this PDN connection.

Quality of Service Profile is the QoS Requested by the GGSN. The Evolved Allocation/Retention Priority I IE may be included if the GGSN supports this IE and if the support of Evolved ARP has been indicated by the current SGSN.

The Protocol Configuration Options (PCO) information element may be included in the request when the GGSN provides the UE with application specific parameters. The SGSN shall copy the content of this IE transparently to the content of the PCO IE in the Request Secondary PDP Context Activation.

The Traffic Flow Template (TFT) may be provided. The detailed use cases are detailed described in clause 9.2.2.3 of 3GPP TS 23.060 [4]. TFT is used for packet filtering. The SGSN shall copy the content of this IE transparently to the content of the TFT IE in the Request Secondary PDP Context Activation.

The Correlation-ID shall be included and is used to correlate the subsequent Secondary PDP Context Activation Procedure with the Initiate PDP Context Activation message.

NOTE: The Correlation-ID is used in GTP and corresponds over the air-interface to the TI, which is assigned by the SGSN and sent to MS in the Request Secondary Context Activation as described in 3GPP TS 23.060 [4].

The optional Private Extension contains vendor or operator specific information.

Table 7.3.12.1: Information Elements in an Initiate PDP Context Activation Request

Information element	Presence requirement	Reference
Linked NSAPI	Mandatory	7.7.17
Protocol Configuration Options	Optional	7.7.31
Quality of Service Profile	Mandatory	7.7.34
TFT	Conditional	7.7.36
Correlation-ID	Mandatory	7.7.82
Evolved Allocation/Retention Priority I	Optional	7.7.91
Private Extension	Optional	7.7.46

7.3.13 Initiate PDP Context Activation Response

The message is sent by a SGSN to GGSN as a response of an Initiate PDP Context Activation Request message after the SGSN receives from the UE either a positive acknowledgment (Activate Secondary PDP Context Request message) or a negative acknowledgment (Secondary PDP Context Activation Reject message), or if SGSN does not receive any response from the UE before the Radio Interface timer T3385 expires (see TS 24.008 [5]), or if the UE is temporarily not reachable due to power saving. If the PDP context was not established, the SGSN includes a Cause Code to indicate the reason why the PDP Context could not be established.

The Cause value "Request accepted" indicates that the Initiate PDP Context Activation was successful. The Initiate PDP Context Activation procedure was not successful for other Cause values.

Possible Cause values are:

– "Request Accepted".

– "No resources available".

– "Service not supported".

– "System failure".

– "Mandatory IE incorrect".

– "Mandatory IE missing".

– "Optional IE incorrect".

– "Invalid message format".

– "Context not found".

– "Semantic error in the TFT operation",

– "Syntactic error in the TFT operation",

– "Semantic errors in packet filter(s)"

– "Syntactic errors in packet filters(s)"

– "MS is not GPRS Responding".

– "MS Refuses".

– "Invalid Correlation-ID".

– "PDP Context without TFT already activated".

– "Bearer Control Mode violation".

– "UE is temporarily not reachable due to power saving".

The SGSN includes the Protocol Configuration Options (PCO) information element in the response if the MS wishes to provide the GGSN with application specific parameters. The SGSN includes this IE in the Initiate PDP Context Activation Response message if the Request PDP Context Activation Reject message from the MS includes protocol configuration options. The SGSN shall copy the content of the IE transparently from the PCO IE in the Request PDP Context Activation Reject message. The optional Private Extension contains vendor or operator specific information.

Table 7.3.13.1: Information Elements in an Initiate PDP Context Activation Response

Information element	Presence requirement	Reference
Cause	Mandatory	7.7.1
Protocol Configuration Options	Conditional	7.7.31
Private Extension	Optional	7.7.46