9.2.3 Modification Procedures

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

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

9.2.3.0 General

Modification procedures modify parameters that were negotiated during an activation procedure for one or several PDP contexts. An MS, a GGSN, a P‑GW, an SGSN, a PCRF, or an RNC can request or initiate a modification procedure. The Modification procedures may possibly be triggered by the HLR as explained in clause "Insert Subscriber Data Procedure" or by an RNC in a RAB Release or an RNC-initiated RAB Modification procedure. An MS and SGSN can also decide about modification procedures after an RNC-initiated Iu release.

The following parameters can be modified:

– QoS Negotiated;

– Negotiated Evolved ARP;

– Radio Priority;

– Packet Flow Id;

– PDP Address (in case of the GGSN-initiated modification procedure);

– TFT (in case of MS- or GGSN or PDN GW-initiated modification procedure);

– Protocol Configuration Options (in case of MS and GGSN-initiated modification procedure);

– BCM (in case of GGSN-initiated or PDN GW-initiated modification procedure);

– Usage of Direct Tunnel;

– APN-AMBR; and

– indication for one or more 3GPP RATs of whether the PDP context can be offloaded to WLAN.

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

A GGSN can request the modification of parameters by sending an Update PDP Context Request message to the SGSN.

A P‑GW can request the modification of parameters by sending an Update Bearer Request message to the S‑GW.

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

An RNC can request an Iu release by sending an Iu Release Request message to the SGSN. After Iu release the MS and SGSN shall modify the PDP contexts according to the rules defined in clause "RNC-Initiated PDP Context Modification Procedure".

An RNC can request the release of a radio access bearer. After RAB release the MS and the SGSN shall locally modify the corresponding PDP context according to rules defined in the clause "RAB Release-Initiated Local PDP Context Modification Procedure".

A trace may be activated while a PDP context is active. To enable trace activation in a GGSN, the SGSN shall send an Update PDP Context Request message to the GGSN. To enable trace activation in a P‑GW, the SGSN shall send an Update Bearer Request message to the S‑GW. If PDP context modification is performed only to activate a trace, the SGSN shall not send a Modify PDP Context Request message to the MS.

When the APN restriction value configured in the GGSN/P‑GW is modified, the GGSN/P-GW applies the new APN restriction value to new PDP contexts/EPS bearers. Existing PDP contexts/EPS bearers continue to use the previous APN restriction value.

If the GGSN has stored information that the current SGSN supports the reporting of CGI/SAI/RAI and/or user CSG information changes, to enable or disable CGI/SAI/RAI and/or user CSG information change reporting for an already active PDP context, the GGSN shall send an Update PDP Context Request message to the SGSN. The SGSN shall behave according to clause 15.1.1a.

If the P‑GW has stored information that the current S4-SGSN supports the reporting of CGI/SAI/RAI and/or user CSG information changes, to enable or disable CGI/SAI/RAI and/or user CSG information change reporting for an already active EPS Bearer, the P‑GW shall send an Update Bearer Request message to the S‑GW. The S4-SGSN shall behave according to clause 15.1.1a.

An RNC may request the modification of some negotiated RAB related QoS parameters by sending a RAB Modify Request.

For S4-based SGSNs the SGSN-Initiated PDP Context Modification can be used in the following use case:

– HSS initiated subscribed QoS modification, where typically QoS related parameters are changed. The parameters that may be modified are EPS Bearer QoS of the default bearer and APN-AMBR.

– A handover or RAU from Gn/Gp SGSN to S4-SGSN, if the S4-SGSN detects that the mapped EPS subscribed QoS profile (i.e. the subscribed QoS profile mapped according to TS 23.401 [89], Annex E) of the default bearer is different from the EPS Subscribed QoS profile received from the HSS.

9.2.3.1 SGSN-Initiated PDP Context Modification Procedure

The SGSN-Initiated PDP Context Modification procedure is illustrated in Figures 70a and 70b.

Figure 70a: SGSN-Initiated PDP Context Modification Procedure, A/Gb mode

Figure 70b: SGSN-Initiated PDP Context Modification Procedure, Iu mode

NOTE 1: Steps 3, 4, 6, 7 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) are defined in clause 9.2.3.1A and procedure steps (B) are defined in clause 9.2.3.1B.

1) The SGSN may send an Update PDP Context Request (TEID, NSAPI, QoS Negotiated, Negotiated Evolved ARP, Trace Reference, Trace Type, Trigger Id, OMC Identity, serving network identity, MS Info Change Reporting support indication, DTI, APN-AMBR, CGI/SAI) message to the GGSN. If the Subscribed Evolved ARP value is changed then it shall be provided to the GGSN in the Negotiated Evolved ARP IE. If Direct Tunnel is established the SGSN provides to the GGSN the RNC’s Address for User Plane and TEID for downlink data and shall include the DTI to instruct the GGSN to apply Direct Tunnel specific error handling as described in clause 13.8. The QoS Negotiated may be equal to, an upgrade or a downgrade compared to the current QoS of the PDP context. The SGSN shall send the serving network identity to the GGSN. If QoS Negotiated received from the SGSN is incompatible with the PDP context being modified, the GGSN rejects the Update PDP Context Request. The GGSN operator configures the compatible QoS profiles. The SGSN shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity in the message if GGSN trace is activated while the PDP context is active. The SGSN shall copy Trace Reference, Trace Type, and OMC Identity from the trace information received from the HLR or OMC. If the modification is triggered by a change of the subscribed APN-AMBR only, then only one PDP context associated with that APN shall be modified.

2) 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 stores QoS Negotiated and returns an Update PDP Context Response (TEID, QoS Negotiated, Negotiated Evolved ARP, Prohibit Payload Compression, APN Restriction, Cause, MS Info Change Reporting Action, CSG Information Reporting Action, APN-AMBR, PCO) message. 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 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 SGSN recalculates the UE-AMBR if the APN-AMBR was received from the GGSN: see clause 15.2.2. Protocol Configuration Options contains the BCM, ETFTN as well as other optional PDP parameters that the GGSN may transfer to the MS.

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

4) In Iu mode, radio access bearer modification may be performed by the RAB Assignment procedure.

5) In case the QoS profile, used as input to step 4 for Iu mode and step 3 for A/Gb mode, have been downgraded during those steps, the SGSN may inform the GGSN about the downgraded QoS profile by sending an Update PDP Context Request to the affected GGSN. The GGSN shall not attempt to renegotiate the QoS profile. 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 profile and that the GGSN shall accept the provided QoS profile without negotiation. The GGSN confirms the new QoS profile 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, 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 Update PDP Context Response in step 2 above.

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

6) The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated, and may send a Modify PDP Context Request (TI, QoS Negotiated, Radio Priority, Packet Flow Id, 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.

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.

7) The MS should accept the PDP context modification requested by the network if it is capable of supporting the modified QoS Negotiated. For a successful modification the MS acknowledges by returning a Modify PDP Context Accept message. 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.

An E-UTRAN capable MS shall set its TIN to "P-TMSI" if the modified PDP context was established before ISR activation.

NOTE 2: In order to facilitate operator control of the QoS an MS should accept a new QoS being assigned by the network even if the QoS is different from the one that the MS uses by default for a particular service type. One reason why the MS may not accept the modified QoS is if it has insufficient internal resources available to support the new QoS.

If the BCM parameter is not included in the Modify PDP Context Request message then the MS shall set the Bearer Control Mode to ‘MS_only’ for the PDP Address/APN pair (see clause 9.2).

NOTE 3: The logic to fallback to BCM ‘MS_only’ if the BCM parameter is not included in the Modify PDP Context Request message is an exception and only applies to the Modify PDP Context procedure.

8) If BSS trace is activated while the PDP context is active, 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 4: Step 7 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].

If an APN Restriction is received from the GGSN for this PDP Context, then the SGSN shall store this value for the PDP Context, replacing any previously stored value for this PDP context. The SGSN shall determine a (new) value for the Maximum APN Restriction using any stored APN Restriction and the received APN Restriction.

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.

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

C1) CAMEL_GPRS_Change_Of_QoS.

The procedure returns as result "Continue".

9.2.3.1A Request part of SGSN-Initiated EPS Bearer Modification Procedure using S4

The procedure described in Figure 70c shows only the steps, due to use of S4, that are different from the Gn/Gp variant of the procedures given by clause 9.2.3.1.

Figure 70c: Request part of SGSN-Initiated EPS Bearer Modification Procedure using S4

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

A) The SGSN sends the Modify Bearer Command (EPS Bearer Identity, EPS Bearer QoS, APN AMBR) message to the Serving GW. The EPS Bearer Identity identifies the default bearer. The EPS Bearer QoS contains the EPS subscribed QoS profile to be updated.

B) The Serving GW sends the Modify Bearer Command (EPS Bearer Identity, EPS Bearer QoS, APN AMBR) message to the PDN GW. If PCC infrastructure is deployed, the PDN GW informs the PCRF about the updated EPS Bearer QoS and APN-AMBR. The PCRF sends new updated PCC decision to the PDN GW. This corresponds to the PCEF-initiated IP‑CAN Session Modification procedure as defined in TS 23.203 [88].

C) The PDN GW sends the Update Bearer Request (EPS Bearer Identity, EPS Bearer QoS, APN AMBR) message to the Serving GW.

D) The Serving GW sends the Update Bearer Request (EPS Bearer Identity, EPS Bearer QoS, APN AMBR) 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", then the S4-SGSN shall, for non-GBR bearers, restrict the MBR sent to the UE to within 16 Mbps.

9.2.3.1B Update part of SGSN-Initiated EPS Bearer Modification Procedure using S4

The procedure described in Figure 70d shows only the steps, due to use of S4, which are different from the Gn/Gp variant of the procedures given by clause 9.2.3.1.

Figure 70d: Update part of SGSN-Initiated EPS Bearer Modification Procedure using S4

NOTE: Step A is common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP-based S5/S8, procedure step (B1) is defined in TS 23.402 [90]. Step B concern GTP based S5/S8.

A) The SGSN acknowledges the bearer modification to the Serving GW by sending an Update Bearer Response (TEID, EPS Bearer Identity, RAT type, DL TEID and DL Address, DTI) message. If the S4-SGSN established Direct Tunnel in step 4 it shall send Update Bearer Response and include the RNC’s Address for User Plane, TEID for downlink data. DTI is used to instruct the Serving GW to apply Direct Tunnel specific error handling as described in clause 13.8.

B) The Serving GW acknowledges the bearer modification to the PDN GW by sending an Update Bearer Response (TEID, EPS Bearer Identity, RAT type) message. The PDN GW may interact with PCRF (refer to TS 23.203 [88]).

9.2.3.2 GGSN-Initiated PDP Context Modification Procedure

The GGSN-Initiated PDP Context Modification procedure is illustrated in Figures 71a and 71b.

Figure 71a: GGSN-Initiated PDP Context Modification Procedure, A/Gb mode

Figure 71b: GGSN-Initiated PDP Context Modification Procedure, Iu mode

NOTE 1: Steps 2‑5 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.3.2A.

1) The GGSN sends an Update PDP Context Request (TEID, NSAPI, PDP Address, QoS Requested, Negotiated Evolved ARP, Prohibit Payload Compression, APN Restriction, MS Info Change Reporting Action, CSG Information Reporting Action, TFT, Protocol Configuration Options, BCM, APN-AMBR, Retrieve Location) 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. QoS Requested indicates the desired QoS profile. The QoS Requested may be equal to, an upgrade or a downgrade compared to the current QoS of the PDP context. PDP Address is optional. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context. If the Bearer Control Mode is set to ‘MS/NW’, the TFT may be included in order to add, modify or delete the TFT related to the PDP Context (in accordance with the requirements in clauses 9.2.0 and 15.3.0). Protocol Configuration Options may contain the BCM 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. BCM indicates the Bearer Control Mode applicable to all PDP Contexts within the activated PDP Address/APN pair. The GGSN shall only indicate Bearer Control Modes allowed according to the NRSN and NRSU previously indicated by the SGSN and MS respectively. The SGSN may restrict a desired QoS profile given its capabilities, the current load, the current QoS profile, and the subscribed QoS profile. The SGSN shall apply a Negotiated Evolved ARP even if it is different from the Subscribed Evolved ARP. The BCM is used by the SGSN to handle unexpected session management signalling. If the GGSN determines the active APN-AMBR needs to be modified, the APN-AMBR is included in the request message. If the modification is triggered by a change of the APN-AMBR only, then only one PDP context associated with that APN shall be modified. The SGSN recalculates the UE-AMBR if the APN-AMBR was received from the GGSN: see clause 15.2.2. "Retrieve Location" is indicated if requested by the PCRF.

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 Update PDP Context Request 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.

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

3) In Iu mode, radio access bearer modification may be performed by the RAB Assignment procedure.

4) The SGSN selects Radio Priority and Packet Flow Id based on QoS Negotiated, and sends a Modify PDP Context Request (TI, PDP Address, QoS Negotiated, Radio Priority, Packet Flow Id, TFT, PCO, WLAN offloadability indication) message to the MS. PDP Address is optional. 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 be included if modified and take into account the Aggregate BSS QoS Profile, if any, returned from the BSS. The TFT is included only if it was received from the GGSN in the Update PDP Context Request message. Protocol Configuration Options contains the BCM as well as optional PDP parameters that the GGSN may transfer to the MS. Protocol Configuration Options is sent transparently through the SGSN. BCM indicates the Bearer Control Mode applicable to all PDP Contexts within the activated PDP Address/APN pair.

If only QoS parameter ARP is modified Steps 4, 5 may be skipped unless ISR is activated.

If the procedure is performed without steps 4 and 5 and location retrieval is requested and the UE is PMM_CONNECTED and unless the SGSN is configured not to retrieve CGI/SAI from the RNC under this condition, the SGSN uses the Location Reporting Procedure described in clause 12.7.5 to retrieve the SAI from the RNC.

NOTE 2: Based on operator policy and local regulation the SGSN is configured to either use the Location Reporting Procedure described in clause 12.7.5 for retrieving the CGI/SAI from the RNC, or to use the last known User Location information obtained from e.g. GPRS attach procedure, routeing area update procedure, etc.

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.

5) The MS should accept the PDP context modification requested by the network if it is capable of supporting any modified QoS Negotiated as well as any modified TFT. For a successful modification the MS acknowledges by returning a Modify PDP Context Accept message. If the MS is incapable of accepting a new QoS Negotiated it shall instead de-activate the PDP context with the PDP Context Deactivation Initiated by MS procedure.

An E-UTRAN capable MS shall set its TIN to "P-TMSI" if the modified PDP context was established before ISR activation.

NOTE 3: In order to facilitate operator control of the QoS an MS should accept a new QoS being assigned by the network even if the QoS is different from the one that the MS uses by default for a particular service type. One reason why the MS may not accept the modified QoS is if it has insufficient internal resources available to support the new QoS.

If the BCM parameter is not included in the Modify PDP Context Request message then the MS shall set the Bearer Control Mode to ‘MS_only’ for the PDP Address/APN pair (see clause 9.2).

NOTE 4: The logic to fallback to BCM ‘MS_only’ if the BCM parameter is not included in the Modify PDP Context Request message is an exception and only applies to the Modify PDP Context procedure.

6) Upon receipt of the Modify PDP Context Accept message, or upon completion of the RAB modification procedure, the SGSN returns an Update PDP Context Response (TEID, QoS Negotiated, CGI/SAI) message to the GGSN. If the SGSN receives a Deactivate PDP Context Request message, it shall instead follow the PDP Context Deactivation Initiated by MS procedure. The SGSN includes the last known location information.

If the Update PDP Context Request 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 is UE available for end to end signalling in a subsequent PDP Context Modification procedure.

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.

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

C1) CAMEL_GPRS_Change_Of_QoS.

The procedure returns as result "Continue".

9.2.3.2A PDN GW Initiated EPS Bearer Modification Procedure, using S4

The procedure described in figure 71c 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.3.2.

Figure 71c: PDN GW-Initiated EPS Bearer Modification Procedure

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

A) The P‑GW sends the Update Bearer Request (TEID, EPS Bearer Identity, EPS Bearer QoS, APN-AMBR, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action, TFT, Protocol Configuration Options, Retrieve Location) message to the S‑GW.

PDN Address Information is included if it was provided by the P‑GW. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this EPS Bearer. The TFT is optional and included in order to add, modify or delete the TFT related to the PDP Context (in accordance with the requirements in clauses 9.2.0 and 15.3.0). Protocol Configuration Options optional EPS Bearer parameters that the P‑GW/PCRF may transfer to the MS. The PDN GW may have interacted with PCRF beforehand (refer to TS 23.203 [88]). "Retrieve Location" is indicated if requested by the PCRF.

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 an Update Bearer Response with a rejection cause indicating that MS is temporarily not reachable due to power saving and then sets the internal flag Pending Network Initiated PDN Connection Signalling. The rejection is forwarded by the Serving GW to the PDN GW.

B) If ISR is activated and UE is in PMM_IDLE or STANDBY state, S-GW shall first trigger the Network Triggered Service Request procedure (refer to TS 23.401 [89]).

The S‑GW sends the Update Bearer Request (TEID, EPS Bearer Identity, EPS Bearer QoS, APN-AMBR, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action, TFT, Protocol Configuration Options, Retrieve Location) 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", then the S4-SGSN shall, for non-GBR bearers, restrict the MBR sent to the UE to within 16 Mbps.

C) The SGSN acknowledges the bearer modification to the S‑GW by sending an Update Bearer Response (EPS Bearer Identity, User Location Information) message to the S‑GW. If there is no signalling with the MS, e.g. because the MS is in PMM_IDLE or STANDBY state, the SGSN provides the last known location information.

D) The S‑GW acknowledges the bearer modification to the P‑GW by sending an Update Bearer Response (EPS Bearer Identity, User Location Information) message. The PDN GW may interact with PCRF (refer to TS 23.203 [88]). The P‑GW 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.

If the bearer modification 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 MS is available for end to end signalling in the subsequent Modify Bearer Request message.

9.2.3.3 MS-Initiated PDP Context Modification Procedure

The MS-Initiated PDP Context Modification procedure is illustrated in Figures 72a and 72b.

Figure 72a: MS-Initiated PDP Context Modification Procedure, A/Gb mode

Figure 72b: MS-Initiated PDP Context Modification Procedure, Iu mode

NOTE 1: Steps 1, 4, 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.3.3A, procedure steps (B) are defined in clause 9.2.3.3B and procedure steps (C) are defined in clause 9.2.3.3C.

1) The MS sends a Modify PDP Context Request (TI, QoS Requested, TFT, Protocol Configuration Options) message to the SGSN. Either QoS Requested or TFT or both may be included. QoS Requested indicates the desired QoS profile, while TFT indicates the TFT that is to be added or modified or deleted from the PDP context. An E-UTRAN capable UE shall not modify the QoS for the first PDP context that was established within the PDN connection. A UE in this release that is not E-UTRAN capable should not modify the QoS for the first PDP context that was established within the PDN connection. Protocol Configuration Options may be used to transfer optional PDP parameters and/or requests to the GGSN.

The MS-Initiated PDP Context Modification Procedure is used to indicate the change of 3GPP PS Data Off UE Status to the GGSN via the PCO, only if the UE has been previously informed that the GGSN supports the 3GPP PS Data Off feature.

2) The SGSN may restrict the desired QoS profile given its capabilities, the current load, and the subscribed QoS profile. The SGSN sends an Update PDP Context Request (TEID, NSAPI, QoS Negotiated, TFT, Protocol Configuration Options, serving network identity, CGI/SAI, MS Info Change Reporting support indication, DTI, CGI/SAI, User CSG Information) message to the GGSN. If Direct Tunnel is established the SGSN provides to the GGSN the RNC’s Address for User Plane and TEID for downlink data and shall include the DTI to instruct the GGSN to apply Direct Tunnel specific error handling as described in clause 13.8. The SGSN shall send the serving network identity to the GGSN. If QoS Negotiated and/or TFT received from the SGSN is incompatible with the PDP context being modified (e.g., TFT contains inconsistent packet filters), the GGSN rejects the Update PDP Context Request. The GGSN operator configures the compatible QoS profile. Protocol Configuration Options is sent transparently through the SGSN if received in Modify PDP Context Request message. The GGSN may interact with the 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.

3) The GGSN may further restrict QoS Negotiated given its capabilities, operator policies and the current load or increase QoS Negotiated based on any external input (e.g. policy control). The GGSN stores QoS Negotiated, stores, modifies, or deletes TFT of that PDP context as indicated in TFT, and returns an Update PDP Context Response (TEID, QoS Negotiated, Negotiated Evolved ARP, Protocol Configuration Options, Prohibit Payload Compression, APN Restriction, MS Info Change Reporting Action, CSG Information Reporting Action) message. 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. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for this PDP context. 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.

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

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

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

5) In Iu mode, radio access bearer modification may be performed by the RAB Assignment procedure. In case the radio access bearer does not exist the RAB setup is done by the RAB Assignment procedure.

6) In case the QoS profile, used as input to step 5 for Iu mode and step 4 for A/Gb mode, have been downgraded during those steps, the SGSN may inform the GGSN about the downgraded QoS profile by sending an Update PDP Context Request to the affected GGSN. The GGSN shall not attempt to renegotiate the QoS profile. 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 profile and that the GGSN shall accept the provided QoS profile without negotiation. The GGSN confirms the new QoS profile 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 Update 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 a Modify 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 Modify PDP Context Response message.

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.

An E-UTRAN capable MS shall set its TIN to "P-TMSI" if the modified PDP context was established before ISR activation.

NOTE 2: If the SGSN does not accept QoS Requested, then steps 2 and 3 of this procedure are skipped, and the existing QoS Negotiated is returned to the MS in step 4.

NOTE 3: In this release of the standards no procedure is defined that uses the Protocol Configuration Options in the PDP context modification 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.

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

C1) CAMEL_GPRS_Change_Of_QoS.

The procedure returns as result "Continue".

9.2.3.3A Request part of MS-Initiated EPS Bearer Modification Procedure using S4

The procedure described in Figure 72c shows only the steps, due to use of S4, which are different from the Gn/Gp variant of the procedures given by clause 9.2.3.3.

Figure 72c: Request part of MS-Initiated Modification Procedure using S4

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

A) The SGSN identifies the bearer modification scenario that applies and sends the Bearer Resource Command (TEID, LBI, PTI, EPS Bearer QoS (excluding ARP), TFT, RAT type, Protocol Configuration Options, serving network identity, CGI/SAI, User CSG Information, MS Info Change Reporting support indication, DL TEID and DL Address, DTI) message to the selected Serving GW. If Direct Tunnel is established the S4-SGSN provides to the Serving GW the RNC’s Address for User Plane and TEID for downlink data and shall include the DTI to instruct the Serving GW to apply Direct Tunnel specific error handling as described in clause 13.8.

The Procedure Transaction Id, PTI, is dynamically allocated by the SGSN. The SGSN should ensure as far as possible that previously used PTI values are not immediately reused for the same UE. The SGSN stores the relationship between the assigned PTI and the received Linked TI during the lifetime of the procedure. PTI is used to differentiate between Update Bearer Requests triggered by this procedure, and any Update Bearer Requests initiated by the PDN GW. The PTI is released when the procedure is completed.

Bearer modification scenarios are described by table 3-3 (MS_only mode) and table 3-4 (MS/NW mode).

NOTE 2: Bearer modification procedure is also used to report in PCO the 3GPP PS Data Off status change in the MS/UE.

B) The Serving GW sends the Bearer Resource Command (LBI, PTI, EPS Bearer Id, EPS Bearer QoS (excluding ARP), TFT, RAT type, Protocol Configuration Options, serving network identity, CGI/SAI, User CSG Information, MS Info Change Reporting support indication) message. The Serving GW sends the message to the same PDN GW as for the EPS Bearer identified by the Linked Bearer Id. The EPS Bearer Id identifies the EPS Bearer, for which the modification was requested.

The PDN GW 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.

When interacting with PCRF, the PDN GW provides to the PCRF;

– the interpretation of the TFT, i.e.:

– the filter operation;

– the filter definitions for filters to be added or modified;

– the SDF filter identifier(s) for filters to be modified or deleted;

– the SDF filter identifier(s) for unchanged filters targeted with a QoS change;

– the requested QCI; and

– for a GBR QCI, the total requested GBR pertaining to (a) the filters added and (b) the set of PCC rules that have one or more SDF filter identifier(s) forwarded to the PCRF in the Gx request.

The PDN GW shall calculate the total requested GBR for Gx from the current Bearer GBR, the requested Bearer GBR from the MS and the QoS for the targeted PCC rules. The PDN GW identifies the targeted PCC rules based on the SDF filter identifier(s) corresponding to the packet filter identifier(s) provided by the MS in the parameter list of the TFT. If the MS did not provide any packet filter identifiers, the PDN GW shall use all SDF filter identifier(s), previously assigned on Gx, for this EPS bearer to identify the PCC rules. The total requested GBR is calculated by the following formula:

total requested GBR for Gx = max(0,sum(GBR[targeted PCC rules]) + (requested Bearer GBR – current Bearer GBR))

EXAMPLE: The targeted GBR bearer has GBR=500 and the MS requests to increase the bearer GBR to 750. The TFT operation is "No TFT operation", so the PDN GW considers all the MS-created TFT filters to be targeted and calculates the sum of the GBR values for the targeted PCC rules. The sum is 400 in this example. The formula yields a requested GBR=400+(750-500)=650. The list of targeted SDF filters, the QCI and GBR=650 is provided with the Gx request.

The TFT definition includes an operation, a list of packet filter identifiers and conditionally their packet filter definitions as well as an optional parameter list. The PDN GW shall assign packet filter identifiers as specified in the TFT received with the Bearer Resource Command for the corresponding packet filters. The MS use of the TFT parameter list is not specified in this Release for BCM MS-only. Valid combinations are shown in Table 3‑2. The absence of the TFT IE is treated as "No TFT operation".

The PDN GW shall forward, over Gx, an MS request to change the QCI only if the following prerequisites are fulfilled:

– there is no NW-initiated TFT filter on the same bearer; and

– the Gx request includes at least one SDF filter identifier from each of the PCC rules on the same bearer.

Table 3-2: TFT filter information elements per TFT operation

TFT operation	Packet filter(s)		Parameter list	Precondition
	identifier	definition
Create new TFT	M	M	N/A	No previous TFT on the same bearer
Delete existing TFT	N/A	N/A	N/A	Previous TFT on all bearers
Add packet filters to existing TFT	M	M	N/A	Previous TFT on the same bearer
Replace packet filters in existing TFT	M	M	N/A	Previous TFT on the same bearer
Delete packet filters from existing TFT	M	N/A	N/A	Previous TFT on the same bearer
No TFT operation	N/A	N/A	C1
C1: If the BCM is MS/NW, then the parameter list shall include the TFT filter identifiers, created by the MS, targeted with a QoS change.

If the TFT operation is "Replace packet filters in existing TFT", then the PDN GW provides to the PCRF the Gx operation "modify filters" and the modified filter(s) and their respective SDF filter identifier(s), previously assigned on Gx, that correspond to the received packet filter identifiers of the EPS bearer together with the requested QCI and/or GBR for the targeted resources, if available.

If the TFT operation is "Delete packet filters from existing TFT", then the PDN GW provides to the PCRF the Gx operation "delete filters" and the SDF filter identifier(s), previously assigned on Gx, that correspond to the received packet filter identifiers of the EPS bearer together with the requested QCI and/or GBR for the targeted resources, if available.

If the TFT operation is "Add packet filters to existing TFT", then the PDN GW provides to the PCRF the Gx operation "add filters" and the new filter(s) together with the requested QCI and/or GBR for the targeted resources, if available. The PDN GW also includes all SDF filter identifier(s), previously assigned on Gx, for this EPS bearer.

If the TFT operation is "Create new TFT", then the PDN GW provides to the PCRF the Gx operation "add filters" and the new filter(s) together with the requested QCI and/or GBR for the targeted resources, if available.

If the TFT operation is "Delete existing TFT", then the PDN GW provides to the PCRF the Gx operation "delete filters" together with the SDF filter identifier(s), previously assigned on Gx, for the filters in the TFT to be deleted together with the requested QCI and/or GBR for the targeted resources, if available.

NOTE 2: The sending of the QCI/GBR change triggers the PCRF to perform an appropriate PCC rule operation to enable the continuation of the EPS bearer after the removal of the TFT by the UE.

If the TFT operation is "No TFT operation" or the TFT is missing (allowed in BCM MS-only only) in the Bearer Resource Command, then the PDN GW provides to the PCRF no Gx filter operation together with the requested QCI and/or GBR for the targeted resources. The PDN GW also includes, if BCM is MS-only, all SDF filter identifier(s), previously assigned on Gx, for this EPS bearer. If the BCM is MS/NW, the TFT shall contain packet filter identifiers and PDN GW shall include the SDF filter identifier(s) that correspond to the packet filter identifier(s) in the parameter list of the TFT.

NOTE 3: The requested modification being translatable to a Gx request is required but not the only condition for the procedure being successful.

Table 3-3: MS-initiated EPS bearer modification, MS_only mode

	PDP context modification use case	Information provided by UE and NAS signalling	Information provided by SGSN at S4 signalling (refer to TS 23.401 [89])
1	Add TFT filters and increase QoS	TFT filters added, New QoS of the PDP context (NOTE 1), Linked TI / NSAPI	QoS related to EPS Bearer, TFT filters added, TEID, EPS Bearer ID
2	Increase of QoS, TFT filters not specified	New QoS of the PDP context (NOTE 1), Linked TI / NSAPI	QoS related to EPS Bearer, TEID, EPS Bearer ID
3	Add/remove TFT filters, no QoS change	TFT filters added/removed, Linked TI / NSAPI	TFT filters added/removed, TEID, EPS Bearer ID
4	Remove TFT filters and decrease QoS	New QoS of the PDP context (NOTE 1), TFT filters removed, Linked TI / NSAPI	QoS related to EPS Bearer, TFT filters removed, TEID, EPS Bearer ID
5	Decrease of QoS, TFT filters not specified	New QoS of the PDP context (NOTE 1), Linked TI / NSAPI	QoS related to EPS Bearer, TEID, EPS Bearer ID
NOTE 1: Only the modified QCI and/or GBR parameters are forwarded by the SGSN.

Table 3-4: MS-initiated EPS bearer modification, MS/NW mode

	PDP context modification use case	Information provided by UE and NAS signalling	Information provided by SGSN at S4 signalling (refer to TS 23.401 [89])
1	Add TFT filters and increase QoS	TFT filters added, New QoS of the PDP context (NOTE 1), Linked TI / NSAPI	QoS related to EPS Bearer, TFT filters added, TEID, EPS Bearer ID
2	Increase of QoS related to one or more TFT filter(s)	New QoS of the PDP context (NOTE 1), Impacted TFT filter(s), Linked TI / NSAPI	QoS related to EPS Bearer filters, Impacted TFT filters, TEID, EPS Bearer ID
3	Increase of QoS, TFT filters not specified	Not allowed in MS/NW mode	Not allowed in MS/NW mode
4	Add/remove TFT filters, no QoS change	TFT filters added/removed, Linked TI / NSAPI	TFT filters added/removed, TEID, EPS Bearer ID
5	Decrease QoS related to one or more TFT filter(s)	New QoS of the PDP context (NOTE 1), Impacted TFT filter(s), Linked TI / NSAPI	QoS related to EPS Bearer filters, Impacted TFT filters, TEID, EPS Bearer ID
6	Remove TFT filters and decrease QoS	New QoS of the PDP context (NOTE 1) TFT filters removed, Linked TI / NSAPI	QoS related to EPS Bearer, TFT filters removed, TEID, EPS Bearer ID
7	Decrease of QoS, TFT filters not specified	Not allowed in MS/NW mode	Not allowed in MS/NW mode
NOTE 1: Only the modified QCI and/or GBR parameters are forwarded by the SGSN.

9.2.3.3B Execution part of MS-Initiated Modification Procedure using S4

The procedure described in Figure 72d shows only the steps, due to use of S4, that are different from the Gn/Gp variant of the procedures given by clause 9.2.3.3.

Figure 72d: Execution part of MS-Initiated Modification Procedure using S4

NOTE: Step B is common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP-based S5/S8, procedure step (B1) is defined in TS 23.402 [90]. Step A concern GTP based S5/S8.

A) If the request is accepted, the PDN GW Initiated Bearer Modification Procedure is invoked by the PDN GW to modify the EPS Bearer indicated by the TEID.

The PDN GW updates the TFT and the EPS Bearer QoS to match the aggregated set of service data flows. If the PCRF was contacted, the PDN GW uses the SDF filter(s) in the PCC rule(s) received from the PCRF to update the TFT. The PDN GW maintains the relation between the SDF filter identifier in the PCC rule received from the PCRF and the packet filter identifier of the TFT.

The PDN GW sends an Update Bearer Request (TEID, EPS Bearer Identity, PTI, EPS Bearer QoS, APN-AMBR, TFT, Protocol Configuration Options, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action) message to the Serving GW. The Procedure Transaction Id (PTI) parameter is used to link this message to the Request Bearer Resource Modification message received from the Serving GW.

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

If the 3GPP PS Data Off UE Status was present in the Bearer Resource Command PCO, the PDN GW behaviour is as specified in TS 23.401 [89].

B) The Serving GW sends an Update Bearer Request (PTI, EPS Bearer Identity, EPS Bearer QoS, TFT, APN AMBR, Protocol Configuration Options, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action) 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.

9.2.3.3C Response part of MS-Initiated Modification Procedure using S4

The procedure described in Figure 72e shows only the steps, due to use of S4, that are different from the Gn/Gp variant of the procedures given by clause 9.2.3.3.

Figure 72e: Response part of MS-Initiated Modification Procedure using S4

NOTE: Steps A is common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP-based S5/S8, procedure step (C1) is defined in TS 23.402 [90]. Step B concern GTP based S5/S8.

A) The SGSN acknowledges the bearer modification by sending an Update Bearer Response (TEID, EPS Bearer Identity, DL TEID and DL Address, DTI) message to the Serving GW. If the S4-SGSN established Direct Tunnel in step 5 it shall send Update Bearer Response and include the RNC’s Address for User Plane, TEID for downlink data and the DTI. DTI is used to instruct the Serving GW to apply Direct Tunnel specific error handling as described in clause 13.8.

B) The Serving GW acknowledges the bearer modification by sending an Update Bearer Response (TEID, EPS Bearer Identity) message to the PDN GW. The PDN GW may interact with PCRF (refer to TS 23.203 [88]).

9.2.3.4 RNC/BSS-Initiated PDP Context Modification Procedure

The RNC can request the release of the Iu connection (see clause "Iu Release Procedure"). The BSS may terminate the downlink data transfer to a MS by the Suspend procedure (which is triggered by the MS) or by the Radio Status procedure with cause "Radio contact lost with MS" or "Radio link quality insufficient to continue communication" both defined in TS 48.018 [78].

After Iu Release in Iu mode, or after termination of the downlink data transfer in A/Gb mode, the PDP contexts for architecture variants using Gn/Gp based interaction with GGSN are handled as follows:

– In the SGSN, for a PDP context using background or interactive traffic class, the PDP context is preserved with no modifications.

– In the SGSN, for a PDP context using streaming or conversational traffic class, the PDP context is preserved, but the maximum bit rate is downgraded to 0 kbit/s (for both uplink and downlink). The SGSN sends an Update PDP Context Request (TEID, QoS Negotiated) message to the GGSN to set the maximum bit rate to 0 kbit/s in the GGSN. The value of 0 kbit/s for the maximum bit rate indicates to the GGSN to stop sending packets to the SGSN for this PDP context. For the Iu mode the value of 0 kbit/s for the maximum bit rate for both uplink and downlink indicates to the SGSN that a RAB shall not be re-established for this PDP Context in subsequent Service Request Procedure. For the A/Gb mode the value of 0 kbit/s for the maximum bit rate for both uplink and downlink indicates that the SGSN shall not send any downlink data for this PDP Context. In Iu and A/Gb mode CAMEL procedure calls shall be performed, see referenced procedure in TS 23.078 [8b]: CAMEL_GPRS_Change_Of_QoS. The procedure returns as result "Continue".

For architecture variants using S4 based interaction with S‑GW and P‑GW, the PDP contexts are handled as follows:

– In the SGSN, for a PDP context using streaming or conversational traffic class, the PDP context is deactivated by the SGSN using the SGSN-initiated PDP Context Deactivation procedure.

– In the SGSN, for all other cases, the PDP context is preserved with no modifications.

In Iu mode the following procedures shall be performed in the MS when radio coverage is lost:

– For a PDP context using background or interactive traffic class, the PDP context is preserved even if RRC re-establishment procedures have failed.

– For a PDP context using streaming or conversational traffic class and only for the PDP context(s) that have a TFT that includes packet filter(s) set by the MS, the PDP context may be preserved, but the maximum bit rate is downgraded to 0 kbit/s (for both uplink and downlink) when the RRC re-establishment procedure has failed. The PDP contexts that are not preserved are all locally deactivated.

After coverage is regained on the GERAN or the UTRAN and if the MS did not deactivate the PDP Context locally the MS should start MS-initiated PDP Context Modification procedure or the PDP Context Deactivation procedure. The MS shall use the PDP Context Modification procedure to re-activate the PDP context and re-establish the RAB .

In A/Gb mode the following procedures shall be performed in the MS when radio coverage is lost, when the radio link quality is insufficient or when the MS suspends GPRS:

– For a PDP context using background or interactive traffic class, the PDP context is preserved.

– For a PDP context using streaming or conversational traffic class and only for the PDP context(s) that have a TFT that includes packet filter(s) set by the MS, the PDP context may be preserved, but the maximum bit rate is downgraded to 0 kbit/s (for both uplink and downlink). The PDP Contexts that are not preserved are all locally deactivated.

After coverage or radio link quality is regained on the GERAN or the UTRAN or when GPRS services shall resume and if the MS did not deactivate the PDP Context locally the MS should start MS initiated PDP Context Modification procedure or the PDP Context Deactivation procedure. The MS shall use the PDP Context Modification procedure to re-activate the PDP context.

9.2.3.5 RAB Release-Initiated Local PDP Context Modification Procedure

The RNC can request a RAB to be released through the RAB Release procedure without releasing the Iu connection.

After the RAB(s) release the SGSN shall handle the PDP context for architecture variants using Gn/Gp based interaction with GGSN as follows:

– In the SGSN, for a PDP context using background or interactive traffic class, the PDP context is preserved with no modifications.

– In the SGSN, for a PDP context using streaming or conversational traffic class, the PDP context is preserved, but the maximum bit rate is downgraded to 0 kbit/s (for both uplink and downlink) when the associated RAB is released. The SGSN sends an Update PDP Context Request (TEID, QoS Negotiated) message to the GGSN to set the maximum bit rate to 0 kbit/s in the GGSN. The value of 0 kbit/s for the maximum bit rate indicates to the GGSN to stop sending packets to the SGSN on this PDP context. The value of 0 kbit/s for the maximum bit rate for both uplink and downlink indicates to the SGSN that a RAB shall not be re-established for this PDP Context in subsequent Service Request Procedure. CAMEL procedure calls shall be performed, see referenced procedure in TS 23.078 [8b]: CAMEL_GPRS_Change_Of_QoS. The procedure returns as result "Continue".

For architecture variants using S4 based interaction with S‑GW and P‑GW, the PDP contexts are handled as follows:

– In the SGSN, for a PDP context using background or interactive traffic class, the PDP context is preserved with no modifications.

– In the SGSN, for a PDP context using streaming or conversational traffic class, the PDP context is deactivated by the SGSN using the SGSN-initiated PDP Context Deactivation procedure.

The following procedures shall be performed in the MS when the RRC layer indicate to higher layer that a RAB has been released and the RAB release was not initiated due to a PDP Context Deactivation Procedure:

– For a PDP context using background or interactive traffic class, the PDP context is be preserved with no modifications.

– For a PDP context using streaming or conversational traffic class and if the TFT include packet filter(s) set by the MS, the PDP context may be preserved, but the maximum bit rate is downgraded to 0 kbit/s (for both uplink and downlink). If the TFT only include packet filter(s) set by the network, or if the TFT include packet filter(s) set by the MS and the PDP context was not preserved, the PDP context is locally deactivated in the MS.

At this point or at a later stage (for preserved PDP contexts), the MS may start a PDP Context Deactivation procedure or PDP Context Modification procedure. The MS shall use the PDP context modification procedure to re-activate the PDP context and to re-establish the RAB.

9.2.3.6 RAN-initiated RAB Modification Procedure (Iu mode)

The RNC-initiated RAB Modification procedure permits an Iu mode RAN to propose modifications to any negotiable RAB parameter for an MS after RAB establishment, TS 25.413 [56b]. RAB parameters are equivalent to RAB attributes as defined in TS 23.107 [58] for each QoS class. The procedure is depicted in the figure below.

Figure 73: RAN-initiated RAB Modification Procedure

1) The RAN sends a RAB Modify Request (RAB ID, RAB Parameter Values) message to the SGSN.

2) The SGSN may decide to ignore the message or to invoke the PDP Context Modification procedure as described in clause 9.2.3.1, which includes the SGSN RAB Modification procedure. For architecture variants using S4 based interaction with S‑GW and P‑GW, the SGSN shall always ignores the message.

9.2.3.7 SGSN-initiated procedure on UE’s CSG membership change

For an MS in PMM-CONNECTED State and connected via a CSG cell, if the SGSN detects that the UE’s CSG membership to that cell has expired, the SGSN shall send an appropriate Iu message to the RAN which includes an indication that the CSG membership of the UE has expired. The RAN receiving this indication may initiate a handover to another cell. If the UE is not handed over the RAN should initiate the release of the Iu connection with an appropriate cause. The SGSN initiates Iu release after a configurable time if the UE is not handed over or released by the CSG cell. If the CSG membership expires for a MS with ongoing emergency bearer services, no indication that the CSG membership of the UE has expired is sent to the RAN and the SGSN shall initiate deactivation of all non-emergency PDP connections.

For an MS in PMM-CONNECTED State and connected via a hybrid cell, if the SGSN detects that the UE’s CSG membership to that cell has changed or expired, the SGSN shall send an appropriate Iu message to the RAN which includes an indication that the CSG membership of the UE has changed. Based on this information the RAN may perform differentiated treatment for CSG and non-CSG members. If the SGSN has been requested to report user CSG information changes to the GGSN/PDN GW for the MS, thea Gn/Gp-SGSN shall send the change notification message to the GGSN with user CSG Information to indicate the CSG membership change and a S4-SGSN shall send the change notification message to the Serving GW with user CSG Information to indicate the CSG membership change. The Serving GW shall send the change notification message with the user CSG Information to the PDN GW. The SGSN shall release the impacted LIPA PDN connection if the LIPA CSG authorization data for this CSG cell is no longer valid due to UE’s CSG membership changed or expired.