9.2.0 General

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

This clause describes the procedures to enable a GPRS-attached MS to initiate the activation, modification, and deactivation functions for a PDP context in the MS, the SGSN, the S‑GW and the P‑GW or GGSN. In addition procedures to enable a P‑GW or GGSN to request the activation, modification and deactivation of a PDP context to a GPRS-attached subscriber are described.

An MS that activates Primary PDP Context(s) of PDP Type Non-IP shall not activate Secondary PDP Contexts for such PDP Context(s).

NOTE 1: If the MS is in PMM‑IDLE state, it needs to perform a service request procedure to enter the PMM‑CONNECTED state before initiating these procedures.

NOTE 2: There are two procedures specified for GGSN initiated PDP Context Activation; the Network Requested PDP Context Activation Procedure and the Network Requested Secondary PDP Context Activation Procedure. P‑GWs support only the Network Requested Secondary PDP Context Activation Procedure. The network requested bearer control makes use of the Network Requested Secondary PDP Context Activation Procedure only.

NOTE 3: There is a one-to-one mapping between PDP contexts and EPS bearer contexts. PDP contexts established with the PDP Context Activation Procedure are mapped to default EPS bearer contexts as defined in TS 23.401 [89] and vice versa. PDP contexts established with the Secondary PDP Context Activation Procedure are mapped to dedicated EPS bearer contexts as defined in TS 23.401 [89] and vice versa. The TFT associated with a context is not changed by the mapping.

Upon receiving an Activate PDP Context Request message or an Activate Secondary PDP Context Request message, the SGSN shall initiate procedures to set up PDP contexts. The first procedure includes subscription checking, APN selection, and host configuration, while the latter procedure excludes these functions and reuses PDP context parameters including the PDP address but except the QoS parameters. Once activated, all PDP contexts that share the same PDP address and APN shall be managed equally. At least one PDP context shall be activated for a PDP address before a Secondary PDP Context Activation procedure may be initiated. When the MS performs an RA update procedure to change from a release 99 to a release 97 or 98 system, only one active PDP context per PDP address and APN shall be preserved. This PDP context is selected taking the QoS profile and NSAPI value into account.

When the SGSN is using the S4‑interface to an S‑GW for a PDP Context, EPS Bearer procedures will be used.

The EPS subscription context includes a mandatory EPS subscribed QoS profile for the default bearer of each subscribed APN. If the S4-SGSN has received an EPS subscribed QoS profile and the first PDP context to a given APN is activated, the S4-SGSN disregards the QoS requested by the MS and sends the EPS subscribed QoS profile for this APN to the S‑GW. For MSs, for which the S4-SGSN has not received an EPS subscribed QoS profile per APN, the S4-SGSN treats MS originated QoS requests the same as the Gn/Gp SGSN. For MSs, for which the S4-SGSN has not received a subscribed APN-AMBR per APN, the S4-SGSN provides APN-AMBR to the Serving GW and PDN GW. Details on mapping MBR to APN-AMBR are specified in Annex E of TS 23.401 [89].

The E-UTRAN capable MS shall not deactivate the PDP context created by the PDP Context Activation Procedure unless all PDP contexts for the same PDN connection are to be deactivated. The MS shall not modify the QoS of the PDP context created by the PDP Context Activation Procedure.

When the E-UTRAN capable MS is activating the first PDP context with the PDP Context Activation Procedure, the MS shall request for the subscribed QoS profile, but the MS may request for subscribed, interactive or background traffic class. If the EPS subscribed QoS profile information is available to the PDN GW (e.g. if PCC is deployed) and the PDN GW is connected to an Gn/Gp SGSN, the PDN GW shall modify the requested QoS according to the EPS subscribed QoS profile during the PDP Context Activation Procedure.

NOTE 4: As the Gn/Gp SGSN is not capable of allocating the EPS subscribed QoS profile, the MS and the PDN GW are responsible for this.

The non E-UTRAN capable MS should not deactivate the PDP context created by the PDP Context Activation Procedure unless all PDP contexts for the same PDN connection are to be deactivated. The MS should not modify the QoS of the PDP context created by the PDP Context Activation Procedure as long as the MS can achieve the same result using a different PDP context than the PDP context created by the PDP Context Activation Procedure.

During the PDP Context Activation Procedure the bearer control mode, applicable to all PDP Contexts within the activated PDP Address/APN pair, is negotiated. The Bearer Control Mode (BCM) is one of ‘MS_only’ or ‘MS/NW’:

– When ‘MS_only’ the MS shall request any additional PDP contexts for the PDP Address/APN pair through the Secondary PDP Context Activation Procedure. Session Management procedures described in 9.2 apply with the following restrictions:

– The P‑GW or GGSN shall not initiate any Network Requested Secondary PDP Context Activation.

– The P‑GW or GGSN shall not initiate any TFT operation.

– The P-GW shall reject any MS request for a secondary PDP context activation that is received without a TFT.

– For a TFT, when the MS uses the direction attribute, the MS shall ensure that there is at least one packet filter for the uplink direction (unless the TFT is for the PDP context that has been established with the PDP Context Activation Procedure).

– When ‘MS/NW’ both the MS and the P‑GW or GGSN may request additional PDP contexts for the PDP Address/APN pair. The MS shall use the Secondary PDP Context Activation Procedure. The P‑GW or GGSN shall use the Network Requested Secondary PDP Context Activation Procedure. The MS shall, when modifying the QoS of a PDP context, include a TFT with at least packet filter identifiers to indicate which packet filters in the TFT are associated with the QoS change.

NOTE 5: The MS indicates the packet filters in the TFT so that the network can perform the appropriate authorization, i.e. in-line with a valid state for the TFT settings (as defined in clause 15.3.0).

For ‘MS/NW’ the session Management procedures described in clause 9.2 apply with the following restrictions:

– The MS shall not modify the QoS of a PDP context until this PDP context is associated with a TFT containing packet filters set by the MS. If the TFT also contains packet filters set by the P‑GW/GGSN, the MS is only allowed to modify the bit rate parameters in the QoS profile of that PDP Context;

– The MS shall not initiate any Secondary PDP Context Activation without sending a TFT containing at least one packet filter for the uplink direction;

– The P-GW/GGSN shall not initiate any Network Requested Secondary PDP Context Activation without sending a TFT containing at least one packet filter for the uplink direction;

– The MS shall not add a TFT to a PDP context that was established without a TFT;

– The MS shall not delete the TFT from a PDP context that is associated with a TFT;

– The network shall not delete the TFT from a PDP context that is associated with a TFT unless the PDP context was created by the PDP Context Activation Procedure;

– Only the entity that sets a packet filter in the TFT (either MS or P‑GW/GGSN) is allowed to modify or delete this packet filter;

– For each TFT, the MS and the network shall ensure that among the packet filters under own control there is at least one packet filter for the uplink direction, or no own packet filter at all (unless the TFT is for the PDP context that has been established with the PDP Context Activation Procedure);

– For each packet filter the MS and the network shall indicate whether it corresponds to uplink, downlink or bi-directional traffic flow(s).

NOTE 6: The restriction below may be relaxed in a future Release. In the restriction below, packet filters without a declared direction are considered to be bi-directional.

– The P-GW/GGSN shall ensure that for all PDP contexts of the same APN/PDP address pair a valid state for the TFT settings (as defined in clause 15.3.0) is maintained.

NOTE 7: If a PDP context is to be used for services having downlink IP flows only, then the TFT needs to include a packet filter for the uplink direction that effectively disallows any useful uplink packet flows (see clause 15.3.3.4 for an example of such a packet filter).

NOTE 8: If the PDP context is to be used for services having uplink IP flows only, the TFT needs no packet filter for the downlink direction.

The MS indicates support of the network requested bearer control through the Network Request Support UE (NRSU) parameter, which is applicable to all PDP contexts within the same PDP address / APN pair. The SGSN indicates support of the network requested bearer control through the Network Request Support Network (NRSN) parameter.

If the NRSN is not included in the Update PDP Context Request message from the SGSN, or the SGSN does not indicate support of the network requested bearer control, the GGSN or P‑GW shall, following a SGSN-Initiated PDP Context Modification (triggered by SGSN change), perform a GGSN or P‑GW-Initiated PDP Context Modification to change the BCM to ‘MS-Only’ for all PDP-Address/APN-pairs for which the current BCM is ‘MS/NW’.

NOTE 9: An MS is informed of the change in BCM, by SGSN, via Protocol Configuration Options IE in Modify PDP Context Request. The support for PCO IE in Modify PDP Context Request was introduced during Release 5. Hence, the communication of change in BCM, for some pre-Release 6 deployments which do not support PCO IE in Modify PDP Context Request, to an MS may not be possible.

NOTE 10: Change of BCM from ‘MS-Only’ to ‘MS/NW’ has not been supported by the MS and the network since introduction of MS/NW BCM mode in Rel‑7.

An S4-based SGSN shall apply the BCM ‘MS/NW’ whenever the S4 is selected for a certain MS.

NOTE 11: The S4-SGSN needs to support the network requested bearer control due to the nature of the procedures and thus a dynamic signalling of NRSN and BCM is not necessary.

NOTE 12: There may be cases where BCM mode in an S4-SGSN is "MS/NW" but BCM mode in MS and P-GW is "MS-Only", e.g. when the MS does not send NRSU in PCO IE.

The MS indicates support of the extended TFT filter format through the Extended TFT Support UE (ETFTU) parameter, which is applicable to all PDP contexts within the same PDP address / APN pair. The network indicates the support of the extended TFT filter format for all PDP contexts within the same PDP address / APN pair through the Extended TFT Support Network (ETFTN) parameter.

Upon receiving a Deactivate PDP Context Request message, the SGSN shall initiate procedures to deactivate the PDP context. When the last PDP context associated with a PDP address is deactivated, N‑PDU transfer for this PDP address is disabled.

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

By sending a RAB Release Request or Iu Release Request message to the SGSN, the RAN initiates the release of one or more RABs. The preservation function allows the active PDP contexts associated with the released RABs to be preserved in the CN, and the RABs can then be re-established at a later stage.

An S4-based SGSN shall for all active PDN Connections for a certain MS use either S4 or Gn/Gp. This is achieved by the SGSN rejecting a PDP Context activation violating this:

– If an MS is sending an Activate PDP Context Request for an APN using Gn, the activation will be rejected by the SGSN if a PDP Context using S4 already exists for this MS;

– If an MS is sending an Activate PDP Context Request for an APN using S4, the activation will be rejected by the SGSN if a PDP Context using Gn already exists for this MS.

The list of QoS parameters that the PCEF may change, e.g. ARP or APN-AMBR or both, either based on local policy or based on PCRF interactions is described in clause 9.2.3.

In a roaming scenario, based on local configuration, the S4-SGSN may downgrade the ARP or APN-AMBR and/or remap QCI parameter values received from HSS to the value locally configured in S4-SGSN (e.g. when the values received from HSS do not comply with services provided by the visited PLMN). The PCEF may change the QoS parameter values received from the S4-SGSN based on interaction with the PCRF or based on local configuration. Alternatively, the PCEF may reject the bearer establishment.

NOTE 13: For certain APNs (e.g. the IMS APN defined by the GSMA) the QCI value is strictly defined and therefore remapping of QCI is not permitted.

NOTE 14: In roaming scenarios, the ARP/APN-AMBR/QCI values provided by the S4-SGSN for a default bearer may deviate from the subscribed values depending on the roaming agreement. If the PCEF (based on interaction with the PCRF or based on local configuration) upgrades the ARP/APN-AMBR/QCI parameter values received from the S4-SGSN, the default bearer establishment may be rejected by the S4-SGSN.

If case S4 is selected for a certain MS the SGSN shall not modify the EPS bearer level QoS parameters received from the PDN GW during establishment or modification of a default or dedicated bearer (except when the conditions described in NOTE 14 apply). Based on local configuration, the SGSN may reject the establishment or modification of a default or dedicated bearer only in the case of roaming when the bearer level QoS parameter values do not comply with a roaming agreement.

NOTE 15: For roaming, the S4-SGSN, based on local policies, can downgrade the ARP pre-emption vulnerability and/or pre-emption capability, APN-AMBR or MBR (for GBR bearers) parameters received over S8 and allow the bearer establishment or modification of a default or dedicated bearer. The HPLMN is expected to set EPS QoS parameters compliant with roaming agreements, therefore the HPLMN is not informed about any downgrade of EPS bearer QoS parameters. The consequences of such a downgrade are that APN-AMBR and MBR enforcement at the HPLMN and at the UE will not be aligned.