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, Annex E) of the default bearer is different from the EPS Subscribed QoS profile received from the HSS.
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.
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, 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.
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.
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.
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.
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).
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.
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, 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:
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.
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.
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.
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.
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).