9.2.2 Activation Procedures

23.0603GPPGeneral Packet Radio Service (GPRS)Release 17Service descriptionStage 2TS

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

9.2.2.1 PDP Context Activation Procedure

The PDP Context Activation procedure is illustrated in Figure 63 and Figure 64.

Figure 63: PDP Context Activation Procedure for A/Gb mode

Figure 64: PDP Context Activation Procedure for Iu mode

NOTE 1: All steps in figures 63 and 64, except steps 4 and 8, are common for architecture variants using Gn/Gp based interaction with GGSN and using S4 based interaction with S‑GW and P‑GW. For an S4-based interaction with S‑GW and P‑GW, procedure steps (A) and (B) are defined in clause 9.2.2.1A.

If Emergency Service is required and an emergency PDP Context is not already active the MS shall request a PDP Context for emergency services via emergency indication in the Activate PDP Context Request message when initiating the PDP Context Request Procedure. An emergency attached MS shall initiate the PDP Context Request procedure directly after the Attach procedure is completed. Any additional emergency PDP Context Activation by an MS shall be rejected by the SGSN if there is already an emergency PDP context activated.

1) The MS sends an Activate PDP Context Request (NSAPI, TI, PDP Type, PDP Address, Access Point Name, QoS Requested, Protocol Configuration Options, Request Type) message to the SGSN. In this version of the protocol, the MS shall leave PDP Address empty. The MS may use Access Point Name to select a reference point to a certain packet data network and/or to select a service. Access Point Name is a logical name referring to the packet data network and/or to a service that the subscriber wishes to connect to. QoS Requested indicates the desired QoS profile. For an E-UTRAN capable UE, the QoS requested shall indicate subscribed, interactive or background traffic class in this message. If the UE is not E-UTRAN capable, in this release the QoS requested should indicate subscribed, interactive or background traffic class in this message. If the request is as a result of a Network-Requested PDP context activation procedure, the MS shall not set the PDP Type to IPv4v6, but to the value received in the Request PDP Context Activation message: see clause 9.2.2.2.1.

NOTE 2: In case an S4-SGSN is used in the network the QoS Requested information element shall be ignored in the network.

Protocol Configuration Options is used to transfer the NRSU, ETFTU, Address Allocation Preference and 3GPP PS Data Off status to the GGSN and may be used to transfer the BCM as well as optional PDP parameters and/or request to the GGSN (see TS 29.060 [26] and TS 24.229 [75]). Protocol Configuration Options is sent transparently through the SGSN. NRSU indicates MS support of the network requested bearer control. ETFTU indicates MS support of the extended TFT filter format. The Protocol Configuration Options may include the Address Allocation Preference indicating that the MS prefers to obtain an IPv4 address only after the PDP Context Accept by means of DHCPv4 as defined in RFC 2131 [47]. 3GPP PS Data Off status indicates whether 3GPP PS Data Off is activated or deactivated in the MS.

If the SGSN has stored a value for the Maximum APN restriction and the value indicates the most restrictive type, then the SGSN shall reject any Activate PDP Context requests to a different APN, using the PDP Context Activation Reject message including an appropriate error cause.

If the SGSN decides to establish Direct Tunnel between RNC and GGSN, the SGSN provides to the RNC the Direct Tunnel specific parameters in step 5 "RAB Assignment Procedure" and shall initiate PDP Context Update procedure in step 8 to update IP Address and TEID for Downlink data.

Request Type indicates "Handover" when the MS has already an activated PDN GW/HA due to mobility with non-3GPP accesses, and is only interpreted by SGSNs using S4.

The PDP context activation for emergency services shall be exempted from the Maximum APN restriction control. If there is already an emergency bearer activated, the SGSN shall reject any PDP context activation request for normal services if the mobility and access restrictions do not allow the MS to access normal services.

If the message is being sent via a HNB which has a collocated L-GW, it includes the L-GW address in the Direct Transfer message to the SGSN.

2) In A/Gb mode, security functions may be executed. These procedures are defined in clause "Security Function".

3) In A/Gb mode and if BSS trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, Trigger Id, OMC Identity) message to the BSS. Trace Reference, and Trace Type are copied from the trace information received from the HLR or OMC.

4) 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 SGSN shall use the CSG Subscription Data to authorize the LIPA connection to the APN provided by the MS. A PDP Address may only be sent by an MS implemented according to an earlier protocol release. 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, the SGSN rejects the PDP context activation request.

If a GGSN address can be derived, the SGSN creates a TEID for the requested PDP context. If the MS requests a dynamic address, the SGSN lets a GGSN allocate the dynamic address. The SGSN may restrict the requested QoS attributes given its capabilities and the current load, and it shall restrict the requested QoS attributes according to the subscribed QoS profile. If the UE requests the subscribed MBR and the subscribed MBR is larger than 16 Mbps, the SGSN should restrict the requested MBR to 16 Mbps or lower, if the "Higher bitrates than 16 Mbps flag" in the MM Context is set to "not allowed".

If the subscription context does not indicate that the APN is for a connection to an SCEF the SGSN sends a Create PDP Context Request (PDP Type, PDP Address, Access Point Name, QoS Negotiated, Negotiated Evolved ARP, TEID, NSAPI, MSISDN, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Protocol Configuration Options, serving network identity, CN Operator Selection Entity, Maximum APN Restriction IMEISV, CGI/SAI, User CSG Information, RAT type, S-CDR CAMEL information, MS Info Change Reporting support indication, NRSN, Dual Address Bearer Flag, APN-AMBR) message to the affected GGSN. MSISDN is included if available in the stored UE context otherwise IMSI is included. The Negotiated Evolved ARP IE shall contain the Subscribed Evolved ARP value. If the SGSN did not receive a Subscribed Evolved ARP value in subscription data from the HLR the SGSN shall derive this value from the Allocation/Retention Priority of the QoS profile negotiated according to Annex E in TS 23.401 [89]. The inclusion of the Negotiated Evolved ARP IE indicates that the SGSN supports the Evolved ARP feature. The SGSN shall send the serving network identity serving network identity and the CN Operator Selection Entity to the GGSN. The CN Operator Selection Entity indicates whether the Serving Network has been selected by the UE or by the network. 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 a packet data network and optionally to activate a service for this APN. Selection Mode indicates whether a subscribed APN was selected, or whether a non-subscribed APN sent by an MS or a non-subscribed APN chosen by the 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, the GGSN is configured to accept only the PDP context activation that requests a subscribed APN as indicated by the SGSN with Selection Mode. Charging Characteristics indicates which kind of charging the PDP context is liable for. The charging characteristics on the subscription and individually subscribed APNs as well as the way the SGSN handles Charging Characteristics and chooses to send them or not to the GGSN is defined in TS 32.251 [70]. The SGSN shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if GGSN trace is activated. The SGSN shall copy Trace Reference, Trace Type, and OMC Identity from the trace information received from the HLR or OMC. The Maximum APN Restriction denotes the most stringent restriction as required by any already active PDP contexts. If there are no already active PDP contexts, this value is set to the least restrictive type (see clause 15.4). If the GGSN receives the Maximum APN Restriction, then the GGSN shall check if the Maximum APN Restriction value does not conflict with the APN Restriction value associated with this PDP context request. If there is no conflict the request shall be allowed, otherwise the request shall be rejected with the SGSN sending a PDP Context Activation Reject Message to the MS including an appropriate error cause. NRSN indicates SGSN support of the network requested bearer control. The Dual Address Bearer Flag shall be set when the MS requests PDN type IPv4v6 and all SGSNs, which the MS may be handed over to, are Release 8 or above supporting dual addressing, which is determined based on node pre configuration by the operator. For PDN type "non-IP", if the APN subscription data indicate a SCEF connection needs to be used, the SGSN establishes a T6b connection as specified in TS 23.682 [119] using the SCEF address indicated in subscription data. Steps 4 and 8 are not further executed, but the rest of the interactions with the MS apply as specified below.

For emergency attached UEs IMSI is included if available and if the IMSI cannot be authenticated the IMSI is included and marked as unauthenticated.

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 packet data network, and to start charging. The way the GGSN handles Charging Characteristics that it may have received from the SGSN is defined in TS 32.251 [70]. The GGSN may restrict QoS Negotiated given its capabilities and the current load or increase the QoS Negotiated based on any external input (e.g. policy control). The GGSN then returns a Create PDP Context Response (TEID, PDP Type, PDP Address, Protocol Configuration Options, QoS Negotiated, Negotiated Evolved ARP, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action, CSG Information Reporting Action, BCM, APN-AMBR, Delay Tolerant Connection) message to the SGSN. The GGSN sets the Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention Priority of the QoS Profile Negotiated is derived from the Evolved ARP according to the mapping principles of TS 23.401 [89], Annex E. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context. The SGSN shall apply the Negotiated Evolved ARP if received from the GGSN. If the MS has requested PDP type IPv4v6 and both IPv4 and IPv6 addressing is possible in the PDN but the Dual Address Bearer Flag is not set, or only single IP version addressing is possible in the PDN, the GGSN selects a single IP version (either IPv4 or IPv6). If the MS has requested PDP type IPv4 or IPv6, the GGSN uses the PDP type supplied by the MS in case it is supported in the PDN, otherwise an appropriate error cause will be returned. The GGSN allocates a PDP Address according to the selected PDP type. For PDP Type Non-IP the GGSN performs IPv6 address allocation only if point-to-point tunnelling using UDP/IP encapsulation is used. If no IP address is allocated, no PDP address (or a dummy address) is returned If the GGSN has selected a PDN type different from the one sent by the MS, the GGSN indicates, together with the PDP type IE, a reason cause to the MS why the PDP type has been modified as described in clause 9.2.1. PDP Address is included if the GGSN allocated a PDP address. If the GGSN has been configured by the operator to use External PDN Address Allocation for the requested APN, PDP Address shall be set to 0.0.0.0, indicating that the PDP address shall be negotiated by the MS with the external PDN after completion of the PDP Context Activation procedure. The GGSN shall relay, modify and monitor these negotiations as long as the PDP context is in ACTIVE state, and use the GGSN-Initiated PDP Context Modification procedure to transfer the currently used PDP address to the SGSN and the MS. However, the MS cannot rely on always getting a session management level update of the IP address, which it has negotiated with the external PDN. This is because the P-GW does not update the IP address within the EPS bearer modification procedure, see clause 9.2.3.2A. Protocol Configuration Options contains the BCM, ETFTN as well as optional PDP parameters that the GGSN may transfer to the MS. BCM shall also be sent as a separate IE to the SGSN. The GGSN includes a Delay Tolerant Connection indication if the GGSN supports receiving a rejection cause indicating that the MS is temporarily not reachable due to power saving and holding the mobile terminated procedures, until the GGSN receives a message indicating that the MS is available for end to end signalling. 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. Protocol Configuration Options is sent transparently through the SGSN. The Create PDP Context messages are sent over the backbone network. The BCM is used by the SGSN to handle unexpected session management signalling.

If QoS Negotiated received from the SGSN is incompatible with the PDP context being activated, the GGSN rejects the Create PDP Context Request message. The GGSN operator configures the compatible QoS profiles.

If an APN Restriction is received from the GGSN for this PDP Context, then the SGSN shall store this value for the PDP Context and the SGSN shall check this received value with the stored value for the Maximum APN Restriction to ensure there are no conflicts between values. If the consequence of this check results in the PDP context being rejected, the SGSN shall initiate a PDP Context Deactivation and return an appropriate error cause. If the PDP Context is accepted, it shall determine a (new) value for the Maximum APN Restriction. If there is no previously stored value for Maximum APN Restriction, then the Maximum APN Restriction shall be set to the value of the received APN Restriction.

The emergency PDP context activation shall be exempted from the Maximum APN restriction control.

If the MS Info Change Reporting Action and/or the CSG Information Reporting Action are received from the GGSN for this PDP context, then the SGSN shall store this for the PDP context and the SGSN shall report to that GGSN whenever a CGI/SAI/RAI or user CSG information change occurs that meets the GGSN request, as described in clause 15.1.1a.

The GGSN derives the BCM based on NRSU, NRSN and operator policy if previously received in the Create PDP Context Request message. The derived BCM is sent to the MS indicating the Bearer Control Mode applicable to all PDP Contexts within the activated PDP Address/APN pair.

The GGSN derives the ETFTN based on ETFTU and operator policy if ETFTU was previously received in the Create PDP Context Request message. The derived ETFTN is sent to the MS indicating that the extended TFT filter format can be used on all PDP Contexts within the activated PDP Address/APN pair.

The SGSN shall re-verify and may restrict the QoS Negotiated received in the response from the GGSN against the subscribed QoS profile and additionally restrict the QoS negotiated based on its capabilities and current load. The SGSN shall use this updated QoS Negotiated for the subsequent steps.

The SGSN shall apply a Negotiated Evolved ARP even if it is different from the Subscribed Evolved ARP.

The SGSN determines the UE AMBR to be used by the RAN based on the subscribed UE-AMBR and the APN AMBR for active APNs, see clause 15.2.2.

If the 3GPP PS Data Off UE Status was present in the Create PDP Context Request PCO, the GGSN shall include the 3GPP PS Data Off Support Indication in the Create PDP Context Response PCO if it supports the 3GPP PS Data Off feature.

If the GGSN detects that the 3GPP PS Data Off UE Status is active, the GGSN shall indicate this to the charging system for offline and online charging.

5) In Iu mode, RAB setup is done by the RAB Assignment procedure, see clause "RAB Assignment Procedure".

6) In Iu mode and if BSS trace is activated, the SGSN shall send an Invoke Trace (Trace Reference, Trace Type, Trigger Id, OMC Identity) message to the RAN. Trace Reference, and Trace Type are copied from the trace information received from the HLR or OMC.

NOTE 3: Step 6 is applied when the trace activation is triggered by means of signalling. Another alternative is the triggering of trace activation by the OMC. The details of both Trace Activation procedures are described in TS 32.422 [84].

7) In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause "BSS Context".

8) In case the QoS attributes, used as input to step 5 for Iu mode or step 7 for A/Gb mode, have been downgraded during those steps, the SGSN may inform the GGSN about the downgraded QoS attributes by sending an Update PDP Context Request to the affected GGSN. The GGSN shall not attempt to renegotiate the QoS attributes. The No QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN does not upgrade the previously negotiated QoS attributes and that the GGSN shall accept the provided QoS attributes without negotiation. The GGSN confirms the new QoS attributes by sending an Update PDP Context Response to the SGSN. If the SGSN established Direct Tunnel in step 5 it shall send Update PDP Context Request and include the RNC’s Address for User Plane, TEID for downlink data, No QoS negotiation indication and the DTI. DTI is used to instruct the GGSN to apply Direct Tunnel specific error handling as described in clause 13.8. The GGSN(s) shall not include a PCO in the Update PDP Context Response if the No QoS negotiation indication is set. If the No QoS negotiation indication is not set, e.g. by a pre-Rel-7 SGSN and the GGSN includes a PCO in the Update PDP Context Response, it shall contain same information as the Protocol Configuration Options IE sent in the Create PDP Context Response in step 4 above.

If the SGSN does not receive PCO in this step and it has received PCO in step 4, then the SGSN shall forward the PCO received in step 4 to the UE.

9) The SGSN inserts the NSAPI along with the GGSN address in its PDP context. The PDP address received from the GGSN or from HSS subscription records is inserted in the PDP context. The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated, and returns an Activate PDP Context Accept (PDP Type, PDP Address, TI, QoS Negotiated, Radio Priority, Packet Flow Id, Protocol Configuration Options, WLAN offloadability indication) message to the MS. If the MS indicated in the MS Network Capability it does not support BSS packet flow procedures, then the SGSN shall not include the Packet Flow Id. In A/Gb mode, the QoS Negotiated shall take into account the Aggregate BSS QoS Profile, if any, returned from the BSS. Protocol Configuration Options are used to transfer the BCM and ETFTN to the UE and may be used to transfer optional PDP parameters to the UE (see TS 29.060 [26] and TS 24.229 [75]). Protocol Configuration Options is sent transparently through the SGSN. The BCM indicates the Bearer Control Mode applicable to all PDP Contexts within the activated PDP Address/APN pair. If the BCM parameter is not included in the message then the MS shall set the Bearer Control Mode to ‘MS_Only’ for the PDP Address/APN pair (see clause 9.2). If the ETFTN is included in the message then the MS may use the extended TFT filter format in subsequent MS requests. The SGSN is now able to route PDP PDUs between the GGSN and the MS, and to start charging.

If the MS is incapable of accepting the new QoS Negotiated, the MS should initiate application level signalling to lower the QoS requirements for the concerned application(s). If this is not possible then the MS shall instead de-activate the PDP context with the PDP Context Deactivation Initiated by the MS procedure.

The SGSN may include an indication whether the traffic of this PDP context is allowed to be offloaded to WLAN as described in clause 5.3.21.

For each PDP Context a different quality of service (QoS) profile may be requested. For example, some PDP contexts 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 clause "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, Protocol Configuration Options) message, the MS may attempt another activation to the same APN up to a maximum number of attempts.

If the MS requested for a PDP type IPv4v6 to a given APN and was granted PDP type IPv4 with no reason cause indicating that only the assigned PDP type is allowed, the MS should request for the activation of a parallel PDP Context to the same APN with PDP type IPv6.

If the MS receives no reason cause in response to an IPv4v6 PDP type and it receives an IPv6 prefix and Interface Identifier apart from the IPv4 address or 0.0.0.0 in the PDP Address field, it considers that the request for a dual address PDP was successful. It can wait for the Router Advertisement from the network with the IPv6 prefix information or it may send Router Solicitation if necessary.

The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]:

C1) CAMEL_GPRS_PDP_Context_Establishment.

In Figure 63 and Figure 64, procedures return as result "Continue".

C2) CAMEL_GPRS_PDP_Context_Establishment_Acknowledgement.

In Figure 63 and Figure 64, procedures return as result "Continue".

9.2.2.1A PDP Context Activation Procedure using S4

The procedures described in figures 64a and 64b show only the steps, due to use of S4, which are different from the Gn/Gp variant of the procedure given by clause 9.2.2.1.

Figure 64a: PDP Context Activation Procedure steps (A) using S4

NOTE 1: Steps A and D are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP-based S5/S8, procedure steps (A1) are defined in TS 23.402 [90]. Steps B and C concern GTP based S5/S8.

If there is already an emergency bearer activated, the SGSN shall reject any PDP context activation request for normal services if the mobility and access restrictions do not allow the MS to access normal services.

A) The SGSN shall use the HSS provided default APN if no APN is provided by the UE. If the PDN subscription context contains no PDN GW identity for this APN, or the APN has a LIPA permission of "LIPA Only" or "LIPA Conditional", the SGSN selects a PDN GW as described in clause PDN GW selection function. If the PDN subscription context profile contains a dynamically allocated PDN GW identity and the Request Type does not indicate "Handover" the SGSN may select a new PDN GW as described in clause PDN GW selection function, e.g. to allocate a PDN GW that allows for more efficient routing. If a Serving GW is not yet selected for this MS, the SGSN selects a Serving GW as described in clause Serving GW selection function. The SGSN sets the EPS Bearer Identity to an equivalent value as the NSAPI for the Bearer associated with the MS. Then the SGSN shall send a Create Session Request (IMSI, MSISDN, SGSN Control Plane TEID, PDN GW address, APN, RAT type, Default Bearer QoS, PDN Type, APN-AMBR, PDN Address, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information, serving network identity, CN Operator Selection Entity, SGSN User Plane TEID, Dual Address Bearer Flag, Protocol Type over S5/S8, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restrictions, CGI/SAI, User CSG Information, MS Info Change Reporting support indication, DTI) message to the selected Serving GW. MSISDN is included if available in the stored UE context. The RAT type is provided in this message for the later PCC decision. The SGSN may change the requested PDP type according to the subscription data for this APN as described in clause 9.2.1. The Dual Address Bearer Flag shall be set when the MS requests PDN type IPv4v6 and all SGSNs, which the MS may be handed over to, are release 8 or above supporting dual addressing, which is determined based on node pre‑configuration by the operator. SGSN User Plane TEID shall not be sent if the SGSN decides to establish the Direct Tunnel between RNC and Serving GW. DTI is used to instruct the Serving GW that the Direct Tunnel shall be established between RNC and Serving GW.

For an emergency PDP Context Activation the SGSN applies the parameters from SGSN Emergency Configuration Data for the emergency bearer establishment performed in this step and any potentially stored IMSI related subscription data are ignored by the SGSN. For emergency attached UEs IMSI is included if available and if the IMSI cannot be authenticated the IMSI is included and marked as unauthenticated.

The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface. Handover Indication is included if the Request type indicates handover. Selection Mode indicates whether a subscribed APN was selected, or whether a non‑subscribed APN chosen by the SGSN was selected. Selection Mode is set according to Annex A. The P‑GW may use Selection Mode when deciding whether to accept or reject the default bearer activation. For example, if an APN requires subscription, the P‑GW is configured to accept only the default bearer activation that requests a subscribed APN as indicated by Selection Mode. Charging Characteristics indicates which kind of charging the bearer context is liable for. If there is an EPS subscription context available for the MS, the SGSN shall ignore the QoS requested parameter sent by the MS, and use the EPS subscribed QoS profile as received from the HSS. For MSs, for which the S4-SGSN has not received an EPS subscribed QoS profile, the S4-SGSN treats MS originated QoS requests the same as the Gn/Gp SGSN, i.e. the requested QoS is used when deriving the Default Bearer QoS and the APN-AMBR from the QoS requested parameter sent by the MS. If the "Higher bitrates than 16 Mbps flag" in the MM Context of the UE is set to "not allowed", the S4-SGSN shall restrict the APN-AMBR in the EPS QoS profile to within 16 Mbps.

The ARP of the PDP context activated with this procedure should be set appropriately to minimize the risk of unnecessary release.

The charging characteristics for the PS subscription and individually subscribed APNs as well as the way of handling Charging Characteristics and whether to send them or not to the P‑GW is defined in TS 32.251 [70]. The SGSN shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if S‑GW and/or P‑GW trace is activated. The SGSN shall copy Trace Reference, Trace Type, and OMC Identity from the trace information received from the HLR or OMC.

The Maximum APN Restriction parameter is used as described for the equivalent step in clause 9.2.2.1.

B) The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request (IMSI, MSISDN, APN, Serving GW Address for the user plane, Serving GW TEID of the user plane, Serving GW TEID of the control plane, RAT type, Default Bearer QoS, PDN Type, PDN Address, APN-AMBR, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information, serving network identity, CN Operator Selection Entity, Dual Address Bearer Flag, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, CGI/SAI, User CSG Information, MS Info Change Reporting support indication) message to the PDN GW indicated by the PDN GW address received in the previous step. MSISDN is included if available in the stored UE context. The PDN GW may interact with PCRF (refer to TS 23.203 [88]).

For emergency attached UEs IMSI is included if available and if the IMSI cannot be authenticated the IMSI is included and marked as unauthenticated.

C) The P‑GW creates a new entry in its EPS bearer context table and generates a Charging Id. The new entry allows the P‑GW to route user plane PDUs between the S‑GW and the packet data network, and to start charging. The way the P‑GW handles Charging Characteristics that it may have received is defined in TS 32.251 [70].

The PDN GW may restrict or increase Default Bearer QoS based on external input e.g. PCRF.

The PDN GW returns a Create Session Response (PDN GW Address for the user plane, PDN GW TEID of the user plane, PDN GW Address for the control plane, PDN GW TEID of the control plane, PDN Type, PDN Address, APN-AMBR, EPS Bearer Identity, EPS Bearer QoS, Protocol Configuration Options, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action, CSG Information Reporting Action, Presence Reporting Area Action, Delay Tolerant Connection) message to the Serving GW. The PDN GW takes into account the PDN type sent by the MS, the Dual Address Bearer Flag and the policies of operator when the PDN GW selects the PDN type to be used as follows. If the MS has requested PDN type IPv4v6 and both IPv4 and IPv6 addressing is possible in the PDN but the Dual Address Bearer Flag is not set, or only single IP version addressing is possible in the PDN, the PDN GW selects a single IP version (either IPv4 or IPv6). If the MS has requested PDN type IPv4 or IPv6, the PDN GW uses the PDN type supplied by the MS in case it is supported in the PDN, otherwise an appropriate error cause will be returned. The PDN GW allocates a PDN Address according to the selected PDN type. In case the PDN GW has selected a PDN type different from the one sent by the MS, the PDN GW indicates together with the PDN type IE a reason cause to the MS why the PDN type has been modified as described in clause 9.2.1. PDN Address is included if the P‑GW allocated a PDN Address. If the PDN has been configured by the operator so that the PDN addresses for the requested APN shall be allocated by usage of DHCPv4 only, or if the PDN GW allows the MS to use DHCPv4 for address allocation according to the Address Allocation Preference received from the MS, the PDN Address shall be set to 0.0.0.0, indicating that the IPv4 PDN address shall be negotiated by the MS with DHCPv4 after completion of the PDP Context Activation procedure. In case of external PDN addressing for IPv6, the PDN GW obtains the IPv6 prefix from the external PDN using either RADIUS or Diameter client function. In the PDN Address field of the Create Session Response, the PDN GW includes the Interface Identifier and IPv6 prefix. The PDN GW sends Router Advertisement to the UE after default bearer establishment with the IPv6 prefix information for all cases. The IP address allocation details are described in the clause "Static and Dynamic PDP Addresses". The PDN GW includes a Delay Tolerant Connection indication if the PDN GW supports receiving a rejection cause from the SGW indicating that the MS is temporarily not reachable due to power saving and holding mobile terminated procedures, until the PDN GW receives a message indicating that the MS is available for end to end signalling.

When the MS negotiates the IPv4 address with DHCPv4, the PDN GW shall relay, modify and monitor these negotiations. However, in contrast to the GGSN procedures, the PDN GW shall not update the IPv4 address to the SGSN nor to the MS.

The P‑GW derives the BCM based on NRSU and operator policy if previously received in the Create Default Bearer Request message. The derived BCM is sent to the MS indicating the Bearer Control Mode applicable to all PDP Contexts within the activated PDP Address/APN pair.

The P‑GW derives the ETFTN based on ETFTU, if received in the Create PDP Context Request message, and operator policy. The derived ETFTN is sent to the MS indicating whether the extended TFT filter format can be used on all PDP Contexts within the activated PDP Address/APN pair.

Protocol Configuration Options contains the BCM, ETFTN as well as optional PDN parameters that the P‑GW may transfer to the MS. These optional PDN parameters may be requested by the MS, or may be sent unsolicited by the P‑GW. Protocol Configuration Options are sent transparently through the S‑GW and SGSN.

When the Handover Indication is present, the PDN GW does not yet send downlink packets to the SGW; the downlink path is to be switched at step A1 of Figure 64b.

If the 3GPP PS Data Off status is present in PCO, PDN GW behaviour is as specified in TS 23.401 [89].

D) The Serving GW returns a Create Session Response (PDN Type, PDN Address, Serving GW address for User Plane, Serving GW TEID for User Plane, Serving GW TEID for Control Plane, APN-AMBR, EPS Bearer Identity, EPS Bearer QoS, PDN GW addresses and TEIDs (GTP‑based S5/S8) or GRE keys (PMIP‑based S5/S8) at the PDN GW(s) for uplink traffic, PDN GW Address for Control Plane, PDN GW TEID for Control Plane, Protocol Configuration Options, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action, CSG Information Reporting Action, Presence Reporting Area Action, Delay Tolerant Connection) message to the SGSN. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context.

If an APN Restriction is received from the P‑GW for this PDP Context, then the SGSN shall store this value for the PDP Context and the SGSN shall check this received value with the stored value for the Maximum APN Restriction to ensure there are no conflicts between values. If the consequence of this check results in the PDP Context being rejected, the SGSN shall initiate a PDP Context deactivation and return an appropriate error cause. If the PDP Context is accepted, it shall determine a (new) value for the Maximum APN Restriction. If there is no previously stored value for Maximum APN Restriction, then the Maximum APN Restriction shall be set to the value of the received APN Restriction.

When the PDN GW has changed Default Bearer QoS the SGSN shall use the new QoS parameter values during establishment of the PDP Context. However, if the "Higher bit rates than 16 Mbps flag" in the MM Context of the UE is set to "not allowed", the S4-SGSN shall, for non-GBR bearers, restrict the MBR sent to the UE to within 16 Mbps.

If the MS Info Change Reporting Action and/or the CSG Information Reporting Action are received for this bearer context, then the SGSN shall store this for the bearer context and the SGSN shall report to that P‑GW via the S-GW whenever a CGI/SAI/RAI or user CSG information change occurs that meets the P‑GW request, as described in clause 15.1.1a.

If Presence Reporting Area Action is received for this bearer context, the S4-SGSN shall store this for the bearer context and shall report to that P-GW via the S-GW whenever a change of UE presence in Presence Reporting Area is detected, as described in clause 15.1.3.1.

Figure 64b: PDP Context Activation Procedure steps (B) using S4

NOTE 3: Steps A and B are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8.

NOTE 4: The steps A1 and A2 are executed only upon handover from non-3GPP access.

A) In case the QoS attributes, used as input to step 5 for Iu mode or step 7 for A/Gb mode, have been downgraded during those steps, the SGSN rejects the PDP Context Activation and terminates the procedure. If the SGSN established Direct Tunnel in step 5 it shall send Modify Bearer Request and include the RNC’s Address for User Plane, TEID for downlink data and DTI. DTI is used to instruct the S‑GW to apply Direct Tunnel specific error handling as described in clause 13.8. An Update Bearer Request shall also be sent to the S‑GW if the UE has indicated Request type "Handover" in the Activate PDP Context Request message, and in that case the Handover Indicator shall be included in the message. An Update Bearer Request shall also be sent to the S‑GW if the SGSN has been requested to report a change of UE presence in Presence Reporting Area, and in that case the message shall include the Presence Reporting Area Information comprising the PRA identifier(s) and indication(s) on whether the UE is inside or outside the area(s). When receiving the request for reporting change of UE presence in Presence Reporting Area, and the S4-SGSN decides not to activate reporting UE presence in one or more of the received Presence Reporting Area(s), the S4-SGSN reports also the inactive Presence Reporting Area(s) in this message.

A1) If the Handover Indication is included in step A, the Serving GW sends a Modify Bearer Request(Handover Indication) message to the PDN to prompt the PDN GW to tunnel packets from non 3GPP IP access to 3GPP access system and immediately start routing packets to the Serving GW for the default and any dedicated EPS bearers established. If Presence Reporting Area Information is included in step A, the Serving GW sends a Modify Bearer Request (Presence Reporting Area Information) message to the PDN GW.

NOTE 5: The PDN GW forwards the Presence Reporting Area Information to the PCRF and/or the OCS as defined in TS 23.203 [88].

A2) The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW.

B) The Serving GW acknowledges by sending Modify Bearer Response to the SGSN. The Serving GW can then send its buffered downlink packets.

C) After the SGSN receives Modify Bearer Response in step B, if an EPS bearer was established and if the subscription data indicates that the user is allowed to perform handover to non-3GPP accesses and if the SGSN selected a PDN GW that is different from the PDN GW identity which was indicated by the HSS in the PDN subscription context, the SGSN shall send an Update Location Request including the PDN GW identity, the APN and information identifying the PLMN in which the PDN GW is located to the HSS for mobility with non‑3GPP accesses.

If the MS is emergency Attached, SGSN shall not send any Update Location Request to an HSS.

D) The HSS stores the PDN GW identity and the associated APN, and sends an Update Location Response to the SGSN.

If the S6d interface is used between an S4-SGSN and HSS, the messages "Update Location Request" and "Update Location Response" shall be replaced with "Notify Request" and "Notify Response".

If the MS requested for a dual address PDP type (IPv4v6) to a given APN and was granted a single address PDP type (IPv4 or IPv6) by the network with a reason cause ‘single address bearers only’, the MS should request for the activation of a parallel PDP Context to the same APN with a single address PDP type (IPv4 or IPv6) other than the one already activated. If the MS receives no reason cause in response to an IPv4v6 PDP type and it receives an IPv6 prefix and Interface Identifier apart from the IPv4 address or 0.0.0.0 in the PDN Address field, it considers that the request for a dual address PDP was successful. The MS shall ignore the IPv6 prefix as described in the step 3 in clause 9.2.1.1. It can wait for the Router Advertisement from the network with the IPv6 prefix information or it may send Router Solicitation if necessary.

9.2.2.1.1 Secondary PDP Context Activation Procedure

The Secondary PDP Context Activation procedure may be used to activate a PDP context while reusing the PDP address and other PDP context information from an already active PDP context, but with a different QoS profile. Procedures for APN selection and PDP address negotiation are not executed. A unique TI and a unique NSAPI shall identify each PDP context sharing the same PDP address and APN.

Any emergency secondary PDP context activation procedure shall be initiated by the network. An MS with an active emergency PDP context shall not initiate the Secondary PDP Context Activation procedure for the emergency PDN connection unless triggered by the Network Requested Secondary PDP Context Procedure.

In the Secondary PDP Context Activation procedure the MS shall provide a TFT. The TFT contains attributes that specify an IP header filter that is used to route downlink N-PDUs to the newly activated PDP context (as described in clause 9.3). The TFT may also contain attributes that specify an IP header filter that is used to identify uplink IP flow(s) to apply policy control functionality as described in TS 23.203 [88].

The Secondary PDP Context Activation procedure may only be initiated after a PDP context is already activated for the same PDP address and APN. The procedure is illustrated in Figure 65 and Figure 66.

Figure 65: Secondary PDP Context Activation Procedure for A/Gb mode

NOTE 1: Steps 1, 2, 5 and 7 are common for architecture variants using Gn/Gp based interaction with GGSN and using S4 based interaction with S‑GW and P‑GW. For an S4 based interaction with S‑GW and P‑GW, procedure steps (A) are defined in clause 9.2.2.1.1A and procedure steps (B) are defined in clause 9.2.2.1.1B.

Figure 66: Secondary PDP Context Activation Procedure for Iu mode

NOTE 2: Steps 1, 4 and 7 are common for architecture variants using Gn/Gp based interaction with GGSN and using S4 based interaction with S‑GW and P‑GW. For an S4 based interaction with S‑GW and P‑GW, procedure part (A) is defined in clause 9.2.2.1.1A.

1) The MS sends an Activate Secondary PDP Context Request (Linked TI, NSAPI, TI, QoS Requested, TFT, Protocol Configuration Options) message to the SGSN. Linked TI indicates the TI value assigned to any one of the already activated PDP contexts for this PDP address and APN. QoS Requested indicates the desired QoS profile. TFT is sent transparently through the SGSN to the GGSN to enable packet classification for downlink data transfer. TI and NSAPI contain values not used by any other activated PDP context. Protocol Configuration Options may be used to transfer optional PDP parameters and/or requests to the GGSN (see TS 29.060 [26] and TS 24.229 [75]). Protocol Configuration Options is sent transparently through the SGSN.

If the SGSN decides to establish Direct Tunnel between RNC and GGSN, the SGSN provides to the RNC the Direct Tunnel specific parameters in step 4 "RAB Assignment Procedure" and shall initiate PDP Context Update procedure in step 6 to update IP Address and TEID for Downlink data.

2) In A/Gb mode, security functions may be executed. These procedures are defined in clause "Security Function".

3) The SGSN validates the Activate Secondary PDP Context Request using the TI indicated by Linked TI. The same GGSN address is used by the SGSN as for the already-activated PDP context(s) for that TI and PDP address.

The SGSN may restrict the requested QoS attributes given its capabilities and the current load, and it shall restrict the requested QoS attributes according to the subscribed QoS profile, which represents the maximum QoS per PDP context to the associated APN. The GGSN may restrict or increase, and negotiate the requested QoS as specified in clause "PDP Context Activation Procedure". The SGSN sends a Create PDP Context Request (QoS Negotiated, TEID, NSAPI, Primary NSAPI, TFT, Protocol Configuration Options, serving network identity, IMEISV, CGI/SAI, RAT type, S-CDR CAMEL information, CGI/SAI/RAI change support indication, Correlation-ID) message to the affected GGSN. The SGSN shall send the serving network identity to the GGSN. Primary NSAPI indicates the NSAPI value assigned to any one of the already activated PDP contexts for this PDP address and APN. TFT is included only if received in the Activate Secondary PDP Context Request message. Protocol Configuration Options is sent transparently through the SGSN if received in the Activate secondary PDP Context Request message. If the Secondary PDP Context Activation Procedure is performed as part of the Network Requested Secondary PDP Context Activation Procedure (clause 9.2.2.3) and if the GGSN included Negotiated Evolved ARP in the Initiate PDP Context Activation then the SGSN shall include the provided negotiated Evolved ARP in the Create PDP Context Request. The Correlation-ID shall only be included if the Secondary PDP Context Activation is performed as part of the Network Requested Secondary PDP Context Activation Procedure (clause 9.2.2.3), and shall be linked to the TI as described in clause 9.2.2.3.

The GGSN uses the same packet data network as used by the already activated PDP context(s) for that PDP address, generates a new entry in its PDP context table, and stores the TFT. The new entry will allow the GGSN to route PDP PDUs via different GTP tunnels between the SGSN and the packet data network. The GGSN returns a Create PDP Context Response (TEID, QoS Negotiated, Negotiated Evolved ARP, Cause, Protocol Configuration Options, Prohibit Payload Compression, APN Restriction, CGI/SAI/RAI change report required) message to the SGSN. The GGSN sets the Negotiated Evolved ARP based on local policy or PCC. The Allocation/Retention Priority of the QoS Profile Negotiated is derived from the Evolved ARP according to the mapping principles of TS 23.401 [89], Annex E. Protocol Configuration Options may be used to transfer optional PDP parameters to the UE (see TS 29.060 [26] and TS 24.229 [75]). The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context. If an APN Restriction is received from the GGSN for this PDP Context, then the SGSN shall store this value for the PDP Context.

If the CGI/SAI/RAI report required is received from the GGSN for this PDP context, then the SGSN shall store this for the PDP context and the SGSN shall report to that GGSN whenever a CGI/SAI/RAI change occurs that meets the GGSN request.

The SGSN shall re-verify and may restrict the QoS Negotiated received from the GGSN against the subscribed QoS profile and additionally restrict the QoS negotiated based on its capabilities and current load. The SGSN shall use this updated QoS Negotiated for the subsequent steps.

The SGSN shall apply a Negotiated Evolved ARP even if it is different from the Subscribed Evolved ARP.

The GGSN may interact with PCRF (refer to TS 23.203 [88]), e.g. to deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF.

4) In Iu mode, RAB setup is done by the RAB Assignment procedure.

5) In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause "BSS Context".

6) The SGSN sends an Update PDP Context Request message to the GGSN, including the QoS attributes that have been accepted by the RAN. In case the QoS attributes have been downgraded in step 5 for A/Gb mode or in step 4 for Iu mode, the SGSN may inform the GGSN about the downgraded QoS. The GGSN shall not attempt to renegotiate the QoS attributes. A RAN Procedures Ready flag is included in the Update PDP Context Request. A GGSN that receives an Update PDP Context Request with a RAN Procedures Ready flag set, should start to route downlink PDP PDUs immediately. The No QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN does not upgrade the previously negotiated QoS attributes and that the GGSN shall accept the provided QoS attributes without negotiation. The GGSN confirms the reception of the message and the potentially downgraded QoS attributes by sending an Update PDP Context Response to the SGSN. If the SGSN established Direct Tunnel in step 4 it shall send Update PDP Context Request and include the RNC’s Address for User Plane and downlink TEID for data, the No QoS negotiation indication and DTI. DTI is used to instruct the GGSN to apply Direct Tunnel specific error handling as described in clause 13.8. The GGSN(s) shall not include a PCO in the Update PDP Context Response if the No QoS negotiation indication is set. If the No QoS negotiation indication is not set, e.g. by a pre-Rel-7 SGSN and the GGSN includes a PCO in the Update PDP Context Response, it shall contain same information as the Protocol Configuration Options IE sent in the Create PDP Context Response in step 3 above.

If the SGSN does not receive PCO in this step and it has received PCO in step 3, then the SGSN shall forward the PCO received in step 3 to the UE.

7) The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated, and returns an Activate Secondary PDP Context Accept (TI, QoS Negotiated, Radio Priority, Packet Flow Id, Protocol Configuration Options, WLAN offloadability indication) message to the MS. If the MS indicated in the MS Network Capability it does not support BSS packet flow procedures, then the SGSN shall not include the Packet Flow Id. In A/Gb mode, the QoS Negotiated shall take into account the Aggregate BSS QoS Profile, if any, returned from the BSS. Protocol Configuration Options is sent transparently through the SGSN if received in the Create PDP Context Response message. The SGSN is now able to route PDP PDUs between the GGSN and the MS via different GTP tunnels and possibly different LLC links.

The SGSN may include an indication whether the traffic of this PDP context is allowed to be offloaded to WLAN as described in clause 5.3.21.

For each additionally activated PDP context a QoS profile and TFT may be requested.

If the secondary PDP context activation procedure fails or if the SGSN returns an Activate Secondary PDP Context Reject (Cause, Protocol Configuration Options) message, the MS may attempt another activation with a different TFT, depending on the cause.

The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [8b]:

C1) CAMEL_GPRS_PDP_Context_Establishment.

In Figure 65 and in Figure 66, procedures return as result "Continue".

C2) CAMEL_GPRS_PDP_Context_Establishment_Acknowledgement.

In Figure 65 and in Figure 66, procedures return as result "Continue".

9.2.2.1.1A Secondary PDP Context Activation Procedure, PDP Creation part, using S4

The procedure described in figure 66a shows only the steps, due to use of S4, that are different from the Gn/Gp variant of the procedure given by clause 9.2.2.1.1.

Figure 66a: Secondary PDP Context Activation Procedure using S4

NOTE 1: Steps A, D and E are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP-based S5/S8, procedure parts (A1) and (A2) are defined in TS 23.402 [90]. Steps B, C and F concern GTP-based S5/S8.

A) The SGSN validates the Activate Secondary PDP Context Request using the TI indicated by Linked TI. The same P‑GW and S‑GW addresses are used by the SGSN as for the already-activated PDP context(s) for that TI and PDP address.

NOTE 2: The EPS Bearer QoS parameters for the traffic flow aggregate are derived from the QoS Release 99 profile.

The Procedure Transaction Id, PTI, is dynamically allocated by the SGSN for the Activate Secondary PDP Context procedure when using S4. The SGSN should ensure as far as possible that previously used PTI values are not immediately reused for the same MS. The SGSN shall store the relationship between the assigned PTI and the received Linked TI during the lifetime of the procedure. The PTI is released when the procedure is completed.

The SGSN sends the Bearer Resource Command (LBI, PTI, EPS Bearer QoS (excluding ARP), TFT, RAT type, Protocol Configuration Options) message to the selected Serving GW. The same Serving GW is used by the SGSN as for the PDP Context identified by the Linked TI received in the Activate Secondary PDP Context Request message.

B) The Serving GW sends the Bearer Resource Command (LBI, PTI, EPS Bearer QoS (excluding ARP), TFT, RAT type, Protocol Configuration Options) message to the PDN GW. The Serving GW sends the message to the same PDN GW as for the EPS Bearer identified by the Linked Bearer Id. The PDN GW derives from the RAT type indicating GERAN or UTRAN and the absence of the EPS Bearer Id that a new EPS Bearer needs to be established. The PDN GW may interact with PCRF (refer to TS 23.203 [88]) and provides to the PCRF the TFT operation add together with the new filter(s) and the QCI and/or GBR, if available. The PDN GW shall accept packet filter identifiers specified by the MS in the TFT.

C) If the request is accepted, the Dedicated Bearer Activation Procedure is invoked to establish a new EPS Bearer by the PDN GW and the PDN GW sends the Create Bearer Request (PTI, EPS Bearer QoS, TFT, S5/S8-TEID, LBI, Protocol Configuration Options) message to the Serving GW. The PTI allocated by the SGSN is used as a parameter in the invoked Dedicated Bearer Activation Procedure to correlate it to the Activate Secondary PDP Context Procedure. The PDN GW shall assign packet filter identifiers as specified in the TFT received with the Bearer Resource Command for the corresponding TFT filters. The PDN GW/PCRF may restrict or increase, and negotiate the requested QoS as specified in clause "PDP Context Activation Procedure". If the PCRF was contacted, the EPS Bearer QoS is updated according to the QoS of the received PCC rules. In addition, the PDN GW uses the SDF filter(s) in the PCC rule(s) received from the PCRF to generate the TFT. The PDN GW maintains the relation between the SDF filter identifier in the PCC rule and the packet filter identifier of the TFT.

If the request for a specific QoS is not accepted or the request does not include a TFT, or the PCC rule(s) received from the PCRF include any SDF filter (that is to to be provided to the MS) that was not requested by the MS, the PDN GW sends a reject indication, which shall be delivered to the MS. A cause indicates the reason why the request was rejected.

D) The Serving GW sends the Create Bearer Request (PTI, EPS Bearer QoS, TFT, UL TEID, LBI, Protocol Configuration Options) message to the SGSN. If the "Higher bit rates than 16 Mbps flag" in the MM Context of the UE is set to "not allowed", the S4-SGSN shall, for non-GBR bearers, restrict the MBR sent to the UE to within 16 Mbps.

E) The SGSN acknowledges the bearer activation to the Serving GW by sending a Create Bearer Response (EPS Bearer Identity, DL TEID, User Location Information) message. The SGSN sets the EPS Bearer Identity to the same value as the NSAPI for the Bearer associated with the MS. The DL TEID value can be either the SGSN user plane TEID (2G or non-DT 3G) or the RNC user plane TEID.

F) The Serving GW acknowledges the bearer activation to the PDN GW by sending a Create Bearer Response (EPS Bearer Identity, S5/S8-TEID, User Location Information) message. The PDN GW may interact with PCRF (refer to TS 23.203 [88]). The PDN GW may deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF (refer to TS 23.203 [88]).

NOTE 3: The Serving GW determines that a Create Dedicated Bearer Response belongs to a previously sent Create Dedicated Bearer Request based on protocol specific details as described in TS 29.274 [92].

9.2.2.1.1B Void

9.2.2.2 Network-Requested PDP Context Activation Procedure

NOTE: These procedures only apply for SGSNs using Gn/Gp

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 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 clause "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 67.

Figure 67: 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 Send Routeing Information for GPRS (IMSI) message to the HLR. If the HLR determines that the request can be served, it returns 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, APN) message to the SGSN indicated by the HLR. Otherwise, the GGSN shall set the MNRG flag for that MS. The GGSN shall not use PDP Type IPv4v6. 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, APN) message to request the MS to activate the indicated PDP context.

5) The PDP context is activated with the PDP Context Activation procedure (see clause "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"), 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"), the SGSN, the GGSN, and the HLR may perform the Protection and Mobile User Activity procedures.

The Protection procedure is illustrated in Figure 68.

Figure 68: 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 Send Routeing Information for GPRS (IMSI) message to the HLR. The HLR returns 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 67 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 all PDP address(es) for that MS 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 69.

Figure 69: 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 clause "GPRS 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 clause "Unsuccessful Mobile-terminated SMS Transfer".) SGSN Address field is 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 Network Requested Secondary PDP Context Activation Procedure using Gn

The Network Requested Secondary PDP Context Activation Procedure allows the GGSN to initiate the Secondary PDP Context Activation Procedure (see clause 9.2.2.1.1). The Network Requested Secondary PDP Context Activation Procedure when using Gn is illustrated in figure 69b.

Figure 69b: Network Requested Secondary PDP Context Activation Procedure using Gn

1) The GGSN sends an Initiate PDP Context Activation (Linked NSAPI, QoS Requested, TFT, Protocol Configuration Options, Correlation-ID, Negotiated Evolved ARP)) message to the SGSN. The QoS Requested, TFT, and Protocol Configuration Options are sent transparently through the SGSN. The TFT shall contain uplink packet filter(s) and should contain downlink packet filter(s). The Correlation-ID is used by the GGSN to correlate the subsequent Secondary PDP Context Activation Procedure (as described below) with this message. The Negotiated Evolved ARP may be included if the GGSN supports this IE and if the support of Evolved ARP has been indicated by the SGSN.

If the MS is in IDLE state and extended idle mode DRX is enabled for the MS, the SGSN will trigger Network Initiated Service Request Procedure from step 2 (which is specified in clause 6.12.2), and start a timer which is configured to a value smaller than the GTP re-transmission timer. If the SGSN receives no response from the MS before the timer expires, the SGSN rejects the Initiate PDP Context Activation message with a rejection cause indicating that the MS is temporarily not reachable due to power saving and, if a Delay Tolerant Connection indication was set for the PDN connection, the SGSN sets the internal flag Pending Network Initiated PDN Connection Signalling. If the Initiate PDP Context Activation message is rejected with a cause indicating that the MS is temporarily not reachable due to power saving, then the GGSN re-attempts the same procedure after it receives the indication that the UE is available for end to end signalling in a subsequent PDP Context Modification procedure.

2) The SGSN sends a Request Secondary PDP Context Activation (Linked TI, TI, QoS Requested, TFT, Protocol Configuration Options) message to the MS. The Linked TI indicates the TI value assigned to the Active PDP Context corresponding to the Linked NSAPI previously received as described in step 1 above. The SGSN shall store a linkage between the TI value assigned to the new PDP Context, and the Correlation-ID received from the GGSN in the Initiate PDP Context Activation message.

3) The MS sends an Activate Secondary PDP Context Request:

a) That initiates the Secondary PDP Context activation procedure as described in 9.2.2.1.1. The Linked TI, TI, QoS Requested, and Protocol Configuration Options sent in the Activate secondary PDP Context Request shall be the same as previously received in step 2 above. The TFT shall contain the packet filters received in the Request Secondary PDP Context Activation message. The MS shall apply the uplink packet filters in the TFT on any uplink traffic, only packets conforming to any of the uplink packet filters in the TFT may be sent on the PDP context. If the MS did not receive a TFT in the Request Secondary PDP Context Activation message (which can only happen in case of a pre-Release 11 GGSN), the MS shall either send the Activate secondary PDP Context Request without a TFT or reject the request.

The MS shall maintain the previously negotiated Bearer Control Mode for the PDP Address/APN pair (see clause 9.2) and ignore any BCM parameter, if included in the Request Secondary PDP Context Activation message.

b) The SGSN returns an Initiate PDP Activation Response (Cause) message to the GGSN. This acknowledges the PDP context activation request towards the GGSN.

9.2.2.3A Network Requested Secondary PDP Context Activation Procedure using S4

The Network Requested Secondary PDP Context Activation Procedure allows the P‑GW to initiate the Secondary PDP Context Activation Procedure towards the MS. The Network Requested Secondary PDP Context Activation Procedure when using S4 is illustrated in figure 69c.

Figure 69c: Network Requested Secondary PDP Context Activation Procedure using S4

NOTE: Steps 2‑7 and 9 are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [90]. Steps 1 and 8 concern GTP based S5/S8.

1. The PDN GW uses the QoS policy to assign the EPS Bearer QoS, i.e., it assigns the values to the bearer level QoS parameters QCI, ARP, GBR and MBR; see TS 23.401 [89]. The PDN GW may have interacted with PCRF beforehand (refer to TS 23.203 [88]). The PDN GW sends a Create Bearer Request message (Bearer QoS, TFT, S5/S8 TEID, LBI, Protocol Configuration Options) to the Serving GW, the Linked EPS Bearer Identity (LBI) is the EPS Bearer Identity of a bearer for this MS and PDN connection.

The TFT shall contain uplink packet filter(s) and should contain downlink packet filter(s).

2. The Serving GW sends the Create Bearer Request (EPS Bearer QoS, TFT, UL TEID, LBI, CGI/SAI/RAI change report required, Protocol Configuration Options) message to the SGSN.

If the MS is in IDLE state and extended idle mode DRX is enabled for the MS, the SGSN will trigger Network Initiated Service Request Procedure from step 2 (which is specified in clause 6.12.2), and start a timer which is configured to a value smaller than the GTP re-transmission timer. If the SGSN receives no response from the MS before the timer expires, the SGSN sends a Create Bearer Response with a rejection cause indicating that the MS is temporarily not reachable due to power saving and, if a Delay Tolerant Connection indication was set for the PDN connection, the SGSN sets the internal flag Pending Network Initiated PDN Connection Signalling. The rejection is forwarded by the Serving GW to the PDN GW. In this case, the steps 3-9 are skipped.

3. Same as step 2 in clause 9.2.2.3, where Linked NSAPI equals LBI. The LBI is received from the S‑GW in the Create Bearer Request message.

The SGSN may include an indication whether the traffic of this PDP context is allowed to be offloaded to WLAN as described in clause 5.3.21.

4. The MS initiates the Secondary PDP Context activation procedure as described in clause 9.2.2.1.1.

The SGSN validates the Activate Secondary PDP Context Request using the TI indicated by Linked TI. The same S‑GW and P‑GW addresses are used by the SGSN as for the already-activated PDP context(s) for that TI and PDP address.

5. In A/Gb mode, security functions may be executed. These procedures are defined in clause "Security Function".

6a. In Iu mode, RAB setup is done by the RAB Assignment procedure.

6b. In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause "BSS Context".

7. The SGSN acknowledges the bearer activation to the Serving GW by sending a Create Bearer Response (EPS Bearer Identity, UL TEID, DL TEID, User Location Information) message. The SGSN sets the EPS Bearer Identity to an equivalent value as the NSAPI for the Bearer associated with the MS. The DL TEID value can be either the SGSN user plane TEID (2G or non-DT 3G) or the RNC user plane TEID.

8. The Serving GW acknowledges the bearer activation to the PDN GW by sending a Create Bearer Response (EPS Bearer Identity, S5/S8-TEID, User Location Information) message. The PDN GW may interact with PCRF (refer to TS 23.203 [88], e.g. to to deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF.

If the dedicated bearer activation is rejected with a cause indicating that the MS is temporarily not reachable due to power saving, then the PDN GW re-attempts the same procedure after it receives the indication that the is MS available for end to end signalling in the subsequent Modify Bearer Request message.

9. Same as step 7 in clause 9.2.2.1.1.

9.2.2.4 S4-SGSN triggered Serving GW relocation

This procedure is used if the S4-SGSN determines the Serving Gateway is to be relocated due to events other than those described in the mobility events scenarios (see clause 6.9.2.2). Such scenario exists during the establishment of PDN connection for SIPTO at Local Network with standalone L-GW or SIPTO above RAN. The MS sends an Activate PDP Context Request message to the S4-SGSN which determines that the Serving GW should be relocated.

Figure 9.2.2.4-1: S4-SGSN triggered Serving GW relocation

1. The Serving GW relocation procedure may be triggered by the S4-SGSN due to events that may benefit from a Serving GW relocation other than the ones described in the mobility procedures.

2. The SGSN selects the new Serving GW as described in TS 23.401 [89] under clause 4.3.8.2 on "Serving GW selection function" and 4.3.15, and sends a Create Session Request message (SGSN Tunnel Endpoint Identifier for Control Plane, EPS Bearer ID(s), SGSN Address for Control Plane, RNC Address(es) and TEID(s) for User Traffic (Direct Tunnel is used), PDN GW addresses and TEIDs (for GTP based S5/S8) or GRE keys (for PMIP based S5/S8) at the PDN GW(s) for uplink traffic, serving network identity, CGI/SAI, RAT type, MS Info Change Reporting support indication, DTI). If Direct Tunnel is established the SGSN shall include the DTI to instruct the S‑GW to apply Direct Tunnel specific error handling procedure as described in clause 13.8.

3a. The new Serving GW sends Modify Bearer Request (EPS Bearer ID(s), serving network identity, CGI/SAI, RAT type, MS Info Change Reporting support indication) messages to the P‑GWs involved.

3b. The P‑GWs acknowledge with sending Modify Bearer Response (TEID, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action) messages to new S‑GW. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this EPS Bearer context.

4. The new Serving GW acknowledges the user plane switch to the SGSN via the message Create Session Response (Cause, Serving GW Tunnel Endpoint Identifier for Control Plane, Serving GW Address for Control Plane, Protocol Configuration Options, PDN GW addresses and TEIDs (for GTP based S5/S8) or GRE keys (for PMIP based S5/S8) at the PDN GW(s) for uplink traffic, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action). The SGSN starts timer, to be used in step 6a.

5. The SGSN sends Serving GW Relocation Notification message to the RNC. The SGSN provides to the RNC the new Serving GW’s Address for user Plane and TEID(s) for Uplink data. The RNC starts using the new Serving GW address and TEID(s) for forwarding subsequent uplink packets.

Editor’s note: It belongs to Stage 3 domain whether an existing S1-AP message or a new message need to be used for step 5. This specification will be aligned according to Stage 3 specification once available.

6a. When the timer has expired after step 5, the SGSN releases the bearer(s) in old S‑GW by sending a Delete Session Request message.

6b. The old S‑GW acknowledge bearer deletion.

If the Serving GW relocation procedure towards a new Serving GW fails, based on operator policy, the S4-SGSN should go back to the old Serving GW and disconnect the PDN connection (e.g. SIPTO at local network) that are not allowed to remain connected.