Content for TS 23.060 Word version: 18.0.0

1… 5… 5.3.8… 5.4… 5.4.2… 5.4.9… 5.6… 5.6.2 5.6.3… 5.6.3.7… 5.7… 6… 6.3… 6.5… 6.6… 6.8… 6.9… 6.9.1.3 6.9.2… 6.9.2.2… 6.9.2.2.2 6.9.2.2.3… 6.9.2.2.5… 6.9.3… 6.10… 6.12… 6.13… 6.13.1.2… 6.13.2… 6.13.2.2 6.14… 8… 8.2 9… 9.2.2… 9.2.2.2 9.2.2.3… 9.2.3… 9.2.3.2… 9.2.3.3… 9.2.4… 9.2.4.2… 9.2.5… 12… 12.5… 12.6… 12.7… 12.8… 13… 14… 15… 15.3… 16… 16.2… A… B…

5.3.8 IMS voice over PS Session Supported Indication 5.3.8A Homogenous Support of IMS Voice over PS Sessions Indication 5.3.9 Closed Subscriber Group functions 5.3.10 UE Reachability function 5.3.11 Location Service functions 5.3.12 Selected IP Traffic Offload (SIPTO) function 5.3.13 Machine Type Communication (MTC) 5.3.14 Local IP Access (LIPA) function 5.3.15 Voice domain preference and UE's usage setting 5.3.16 Support for Application / Service Layer Rate Adaptation 5.3.17 Support for subscriptions without MSISDN 5.3.18 PS-only Service Provision and PS domain SMS support 5.3.19 Access and Mobility Restrictions 5.3.20 MS Power Saving Mode 5.3.21 Access network selection and traffic steering based on RAN-assisted WLAN interworking 5.3.22 User plane congestion management function 5.3.23 Dedicated Core Networks (DCNs) 5.3.24 Support for Monitoring Events 5.3.25 3GPP PS Data Off
...

5.3.8 IMS voice over PS Session Supported Indication |R8| p. 37

The serving PLMN, both in Iu mode and A/Gb mode, shall send an indication toward the UE during the Attach procedure and Routing Area Update procedures if an IMS voice over PS session is supported. The serving PLMN uses this indicator to indicate to the UE whether it can expect a successful IMS voice over PS session according to TS 22.173 with a bearer that supports Conversational Voice as specified in TS 23.203, when the UTRAN Iu mode is used. A UE with "IMS voice over PS" voice capability should take this indication into account when:

establishing voice over PS sessions (as specified in TS 23.221);
determining whether to deactivate ISR locally (as detailed in clauses 6.9.1.2.0 and 6.9.2.1); and
determining whether to perform a Routing Area Update when changing between GERAN and UTRAN cells within a Routing Area with both GERAN and UTRAN cells (to inform about IMS voice over PS sessions support as detailed in clauses 6.9.1.2.0 and 6.9.2.1).

The serving PLMN provides this indication based e.g. on local policy, HPLMN, Voice Support Match Indicator, the SRVCC capability of the network and UE and/or level of UTRAN coverage. The serving PLMN shall indicate to the UE that the UE can expect a successful IMS voice over PS session according to TS 22.173 with a bearer that supports Conversational Voice as specified in TS 23.203 only if the SGSN is configured to know that the serving PLMN has a roaming agreement for IMS voice with the HPLMN of the UE. This indication is per RAI within the SGSN.

On request from the HSS, the SGSN shall indicate the following:

whether or not an IMS voice over PS session is supported in the UE's current Routing Area ("IMS voice over PS Session Supported Indication"), together with the time of the last radio contact with the UE; and
the current RAT type.

5.3.8A Homogenous Support of IMS Voice over PS Sessions Indication |R11| p. 38

The "Homogenous Support of IMS Voice over PS Sessions" indication is provided by the SGSN to the HSS/HLR, and can be used by the HSS/HLR to avoid requesting the serving nodes whether or not an IMS voice over PS session according to TS 22.173 with bearer that supports Conversational Voice as specified in TS 23.203 is supported. This indication is stored in the SGSN MM context.

The SGSN shall behave as follows whenever it sends a Update Location or a Notify Request message to the HLR/HSS:

if "IMS Voice over PS Sessions" is supported homogeneously in all RAs in the serving SGSN for the UE, the SGSN shall include the "Homogenous Support of IMS Voice over PS Sessions" indication set to "Supported".
if none of the RAs of the serving SGSN supports "IMS Voice over PS Sessions" for the UE, the SGSN shall include the "Homogenous Support of IMS Voice over PS Sessions" indication set to "Not supported".
if "IMS Voice over PS Sessions" support is either non-homogeneous or unknown, the SGSN shall not include the "Homogenous Support of IMS Voice over PS Sessions" indication.

5.3.9 Closed Subscriber Group functions |R8| p. 38

A Closed Subscriber Group (CSG) identifies a group of subscribers who are permitted to access one or more CSG cells of the PLMN as a member of the CSG for a HNB. The following CSG related functions are defined:

CSG subscription handling function stores and updates the user's CSG subscription data at the MS and the network.
For closed mode, CSG access control function ensures a UE has valid subscription at a CSG where it performs an access.
Admission and rate control function is used to provide different admission and rate control for CSG and non-CSG members for a hybrid cell.
CSG charging function enables per CSG charging for a subscriber consuming network services via a CSG cell or a hybrid cell.
Paging optimization function is optionally used to filter paging messages based on RAI/LAI, UE CSG capability, user's CSG subscription data and CSG access mode in order to avoid paging at CSG cells where the UE is not allowed to access. If the MS has emergency bearer service the paging optimization function shall not be performed.
VPLMN Autonomous CSG roaming function is optionally supported whereby a VPLMN, if allowed by the HPLMN, stores and manages VPLMN specific CSG subscription information for roaming UEs without interaction with the HLR/HSS.

5.3.10 UE Reachability function |R9| p. 38

One or several services can subscribe to the HSS in order to be notified when the UE becomes reachable at NAS layer. On request from the HSS, the SGSN notifies the HSS when the UE is detected at NAS level by the SGSN, and the HSS notifies the subscribed services. An example service is SMS over IP.

5.3.11 Location Service functions |R9| p. 39

LCS procedures are described in the LCS stage 2 specification, see TS 23.271.

In addition, in the Detach and PDP Context Deactivation procedures, the SGSN shall inform the GGSN/S-GW of the last known location of the MS, and shall provide information to enable the determination of the time at which the MS was in that location. The S-GW shall (if necessary taking into account information from the MME) inform the PDN-GW of the last known location of the MS, and shall provide information to enable the determination of the time at which the MS was in that location. If requested by the PCRF the GGSN/PDN-GW shall indicate this information to the PCRF as defined in TS 23.203. The information can also be made available on the Gi interface as specified in TS 29.061 and on the CDRs at the GGSN/PDN-GW as specified in TS 32.251.

5.3.12 Selected IP Traffic Offload (SIPTO) function |R9| p. 39

5.3.12.1 SIPTO with GW Selection |R10| p. 39

The SIPTO function enables an operator to offload certain types of traffic at a network node close to that UE's point of attachment to the access network or to a local network.

SIPTO function specified in TS 23.401, clause 4.3.15 is applicable, with the SGSN node providing the functions specified for the MME.

In order to fully utilise the benefit of the SIPTO with GW selection function, direct tunnel functionality as described in clause 15.6 should be applied.

In order to select a set of GWs (S-GW/P-GW or GGSN) for SIPTO above RAN service that is most appropriate for that UE's current location (during the PDP Context Activation Procedure (clauses 9.2.2.1 and 9.2.2.1A)), the SGSN checks the APN status for SIPTO for the user during the GW Selection function procedure as described in clause 5.3.7 and Annex A.

For SIPTO above RAN, as a result of UE mobility (e.g. detected by the SGSN at RAU), the target SGSN may allocate a different GW that is more appropriate for the UE's current location, e.g. the SGSN may know whether the UE's new location is served by the same GW as the old one. When the SGSN decides upon the need for GW relocation, the SGSN deactivates the impacted PDN connections indicating "reactivation requested" as specified in clause 9.2.4.2.

For SIPTO above RAN or SIPTO at the Local network with stand-alone GW (with S-GW and L-GW collocated), if SIPTO PDN connection is initiated as an additional subsequent PDN connection, S4-SGSN should check if the S-GW is optimal for the user's current location. If it is not, S4-SGSN may decide to perform a S4-SGSN triggered Serving GW relocation according to the clause 9.2.2.4, when possible (e.g. no other restriction apply).

5.3.12.1A SIPTO at the Local Network |R12| p. 39

5.3.12.1A.1 General p. 39

The SIPTO at the Local Network function enables an IP capable UE connected via a (H)NB to access a defined IP network (e.g. the Internet) without the user plane traversing the mobile operator's network except the (H)NB subsystem.

SIPTO at the Local Network can be achieved by selecting a L-GW function collocated with the (H)NB or selecting standalone GWs ( with S-GW and L-GW collocated) residing in the Local Network. In both cases the selected IP traffic is offloaded via the Local Network.

Specific to the HNB subsystem, SIPTO at the Local Network does not depend on CSG membership and the feature can be applied to any UE, as long as the UE is allowed to access the cell.

SIPTO at the Local Network is available for UTRAN access only.

For this Release of the specification there is no support for secondary PDP context on the PDN connection used for SIPTO at the Local Network.The Local GW (L-GW) shall reject any MS initiated Secondary PDP Context Activation Procedure or any PDP Context Modification Procedure that is for the SIPTO at local network PDN Connection.

SIPTO at the Local Network is intended for offloading Internet traffic only, thus the L-GW does not provide APN specific connectivity. Therefore if the subscription data in the HSS indicate that offload at the local network is allowed, this implies that the related APN is typically used for providing Internet connectivity.

The SIPTO at the Local Network function specified in TS 23.401, clauses 4.3.15 and 4.3.15a are applicable, with the SGSN node providing the functions specified for the MME and the (H)NB/RNC providing the functions specified for the (H)eNB.

5.3.12.1A.2 SIPTO at the Local Network with stand-alone GW (S-GW/L-GW collocated) function p. 40

SIPTO at the Local Network is achieved using a standalone GW (with S-GW and L-GW collocated) residing in the Local Network.

In order to select an appropriate Local GW (L-GW) for SIPTO at the local network service, the GW selection function in the SGSN uses the APN and the Local Home Network ID during the DNS interrogation as specified in TS 29.303 to find the GW identity of the L-GW to be selected. The Local Home Network ID is provided to the SGSN in every INITIAL UE MESSAGE and every UTRAN Originated DIRECT TRANSFER control message, Relocation Complete message and Enhanced Relocation Complete message as specified in TS 25.413. The (new) SGSN uses the Local Home Network ID to determine if the UE has left its current local network and if S-GW relocation is needed.

If SIPTO at local network with stand-alone GW, Serving GW relocation without mobility and ISR are supported in the core network, a Routing Area should only contain either cells inside one Local Home Network or cells inside the macro network. If a Routing Area contains both cells inside Local Home Network and cells inside the macro network, the ISR shall not be activated if the UE is allowed to use SIPTO at local network.

In the case using Gn/Gp SGSN and a new offload connection is requested, the PDP Context Activation Procedure (clause 9.2.2.1) can be used to set up the direct tunnel (Gn-UP) between HNB Subsystem/RNC and the Local GW.

5.3.12.1A.3 SIPTO at the Local Network with L-GW function collocated with HNB p. 40

The Local GW used for SIPTO at the Local Network may be same or different as the Local GW used for the LIPA functionality (if provided).

The HNB supporting the SIPTO at the Local Network function includes the Local GW address to the SGSN in every INITIAL UE MESSAGE and every UTRAN Originated DIRECT TRANSFER control message as specified in TS 25.413.

5.3.12.2 Support for SIPTO at Iu-ps |R10| p. 40

SIPTO can be achieved by adding an optional Traffic Offload Function at Iu interface as described in clause B.1. If implemented, and in order to activate SIPTO at Iu-ps, the SGSN shall send charging parameters including MSISDN, APN, Charging Characteristics in the RANAP messages whenever a RAB to be offloaded is requested to be setup as described in clause B.2.

5.3.13 Machine Type Communication (MTC) |R9| p. 40

5.3.13.1 General |R10| p. 40

This clause provides an overview about functionality for Machine Type Communications according to service requirements described in TS 22.368. The specific functionality is described in the affected procedures and features of this and other specifications. For discrepancies between this overview clause and the detailed procedure and function descriptions, the latter take precedence.

MTC functionality is provided by the visited and home networks when the networks are configured to support machine type communication. It applies to both the non-roaming case and the roaming case and some functionality may be dependent upon the existence of appropriate roaming agreements between the operators.

Some of the MTC functions are controlled by subscriber data. Other MTC functions are based on indicators sent by the UE to the network. MTC functionality is performed by UEs that are configured to support different options as described in clause 5.3.13.3.

Though motivated by scenarios and use cases defined in TS 22.368, the functions added to support MTC have general applicability and are in no way constrained to any specific scenario or use case except where explicitly stated.

5.3.13.2 Overview of Protection from Potential MTC Related Overload |R10| p. 41

The number of Machine Type Communication devices may be several orders of magnitude greater than "traditional" devices. Many (but not all) MTC devices will be relatively stationary and/or generate low volumes of traffic. However, these MTC devices have the capability to generate normal quantities of signalling. As normal signalling from large numbers of MSs may cause overload independently whether the MS is used for MTC or not, generic functionality for overload and congestion control is required.

The total signalling from large numbers of MSs is a concern in at least two situations:

when an application (running in many MSs) requests many MSs to do "something" at the same time; and/or
when many MSs are roamers and their serving network fails, then they can all move onto the local competing networks, and potentially overload the not (yet) failed network(s).

To counter these potential problems, the following standardised indications and mechanisms are provided in a generic manner. These permit node specific features to be developed to protect the networks.

Where applicable, MSs can be configured for enhancements as described in subsequent bullets. Post-manufacturing configuration can be performed remotely as described in clause 5.3.13.3.
For mobile originated services, MSs configured for low access priority provide:
- the UTRAN with information indicating that the RR(C) connection establishment request has low access priority (see clause 5.3.13.3); and
- the GERAN with information indicating that the RR connection establishment request has low access priority (see clause 5.3.13.3), when accessing the network for the purpose of PS domain signalling.
In GERAN, "Implicit Reject" functionality permits the BSS to inhibit Random Access Channel signalling (see TS 44.018).
Clause 5.3.13.3 describes when low access priority is not applicable.
RRC signalling has the capability of providing 'extended wait timers' when rejecting messages.
SGSN can initiate rejection of RR(C) connection establishment in the GERAN/UTRAN MSs that access the network with low access priority. In addition, SGSN signalling or GERAN/UTRAN O&M can trigger GERAN/UTRAN to initiate Extended Access Barring in the GERAN /UTRAN. These mechanisms are further described in clause 5.3.6.4.
Overload messages from the SGSN to RNS/BSS are extended to aid the RAN in performing the functionality in bullets b, c and d above.
MSs configured with a long minimum periodic PLMN search time limit (see TS 24.368) have an increased minimum time inbetween their searches for more preferred PLMNs.

NOTE 1:
Following the failure of a more preferred PLMN, MSs configured as above might change to other local competing networks. Expiry of this search timer will lead to the MS re-attempting to access the failed network, and then, if that network has not yet recovered, reaccessing one of the local competing networks. Use of a too short timer for the more preferred PLMN search can both prevent the failed network from recovering, and, impose more load on the local competing networks.
At PLMN change, MSs configured to perform Attach with IMSI at PLMN change (see TS 24.368) do this rather than an RA update with P-TMSI (thus avoiding the need to reject the RA update, and to request the IMSI following the subsequent Attach with P-TMSI).

NOTE 2:
In the case of a network failure, this reduces the message processing load on a local competing network and hence makes that network more likely to survive the failure of the other network.
For mobile originated services, MSs configured for low access priority (see TS 24.368) provide a low access priority indication to the SGSN in NAS signalling that permits the SGSN to undertake protective measures (e.g. to permit the SGSN to immediately command the MS to move to a state where it does not need to generate further signalling messages and/or does not reselect PLMNs), as described in clause 5.3.6.4. Clause 5.3.13.3 describes when low access priority is not applicable.
Using periodic RAU timer information sent by the HSS and/or MS provided indication (bullet h above), the SGSN can allocate a long periodic RAU timer to the MS. A long periodic RAU timer is likely to slow down the rate at which an MS detects a network failure and thus it slows down the rate of movement of MSs from a failed network to other local competing networks (see clause 5.3.13.5).
Mechanisms for the SGSN and GGSN/P-GW to detect congestion associated with a particular APN (see clauses 5.3.6.2 and 5.3.6.3 and TS 23.401).
The addition of 'back off timers' to GMM and SM signalling messages (e.g. to rejection messages). These include some time randomisation to guard against a repeat of a load peak. The SGSN should be able to apply this behaviour on a per-APN basis as described in clause 5.3.6.2.
Mechanisms that permit the GGSN/P-GW to handle per-APN congestion (see clause 5.3.6.3 and TS 23.401).
When using the S4 architecture, an SGSN overload control mechanism to selectively limit the number of Downlink Data Notification requests the S-GW sends to the SGSN for downlink low priority traffic received for MSs in idle mode (see clause 5.3.6.5).
The BSS and RNS are provided with low access priority indications from the MS that permit them to steer "new MTC entrants into a pool area" to specific SGSNs (e.g. to an SGSN optimised for MTC devices by having a larger subscriber data base, see TS 23.236).
GERAN and/or UTRAN broadcast signalling can be used to command MSs configured to use the extended NMO I system information (see TS 24.368) to operate in Network Mode of Operation I while leaving other MSs operating in NMO II. This reduces the amount of signalling from MSs configured as above and may be particularly useful at times of the failure of another PLMN. Maintaining NMO II for existing MSs avoids changes to their existing service levels (see clause 6.3.3.1).

NOTE 3:
It is assumed that the mechanisms described in this entire clause are designed by stage-3 in a manner that allows extensibility and forward compatibility.
MS configured for specific handling of the invalid USIM state, the "forbidden PLMN list" and the "forbidden PLMNs for GPRS service list" remembers that the (U)SIM is invalid and keeps the PLMN forbidden lists even if the MS is switched off and then switched on.
When the MS has an activated PDP context that is without low access priority or the MS is requested to activate such a PDP context and the MS is configured with a permission for overriding low access priority, then the MS does not provide a low access priority indication to the SGSN in MM NAS signalling and also not to the RAN in the RR(C) requests. In the NAS request for activating a PDP context, this MS always indicates what the upper layers requested, i.e. the MS indicates low access priority in that NAS request unless the upper layers request activation of a PDN connection without low access priority.
When the MS has an activated PDP context that is without low access priority or the MS is requested to activate such a PDP context and the MS is configured with a permission for overriding Extended Access Barring, then the MS ignores any Extended Access Barring (if it is activated in the network) as defined in TS 22.011.

5.3.13.3 MS configuration and usage of indicators |R10| p. 42

A subscriber can by agreement with its operator be required to use MSs that are configured (see TS 24.368) to support one or more of the following options:

MS configured for low access priority; and/or
MS configured with a permission for overriding low access priority, which is only applicable for an MS that is also configured for low access priority; and/or
MS configured to use the extended NMO I system information; and/or
MS configured to perform Attach with IMSI at PLMN change; and/or
MS configured with a long minimum periodic PLMN search time limit; and/or
MS configured for Extended Access Barring; and/or
MS configured with a permission for overriding Extended Access Barring, which is only applicable for a UE that is also configured for Extended Access Barring;and/or
MS configured for specific handling of the invalid (U)SIM state, the "forbidden PLMN list" and the "forbidden PLMNs for GPRS service list".

NOTE 1:
When an MS is accessing the network with low access priority, the MS may be subject for longer backoff timers at overload and consequently need to be designed to be tolerant to delays when accessing the network.

MSs can be configured for one or more of the above options with the following restrictions:

in this Release of the specification, an MS that is configured for low access priority shall also be configured for Extended Access Barring; and
in this Release of the specification, an MS that is configured for Extended Access Barring shall be configured for low access priority.
in this Release of the specification, an MS that is configured for overriding low access priority shall also be configured for overriding Extended Access Barring; and
in this Release of the specification, an MS that is configured for overriding Extended Access Barring shall also be configured for overriding low access priority.

Post-manufacturing configuration of these options in the MS can be performed only by OMA DM or (U)SIM OTA procedures. MSs capable of the above options should support configuration of these options by both OMA DM and (U)SIM OTA procedures.

An MS configured for low access priority shall transmit the low access priority indicator to the SGSN during the appropriate NAS signalling procedures and transmit the corresponding low access priority to the UTRAN/GERAN during RR(C) connection establishment procedures, unless the MS is also configured with a permission for overriding low access priority where bullet q from clause 5.3.13.2 applies.

Low access priority shall not be applicable in the following situations:

for all procedures related to an emergency PDN connection; used for IMS Emergency sessions that are to be prioritized as per the requirements for IMS Emergency session procedures (see clause 5.10). When an emergency PDN connection gets established, the SGSN may, based on SGSN configuration, initiate the deactivation of any non-emergency PDN connection using the SGSN-initiated PDP Context Deactivation Procedure described in clause 9.2.4.2 and, in S4 mode, the SGSN Initiated PDN connection Deactivation Procedure described in clause 9.2.4.1A.1;
for all procedures when preferential access to the network is provided to the MS by the Access Class 11-15 mechanism according to TS 44.018, TS 44.060, TS 25.331 and TS 22.011;

NOTE 3:
The configuration of an MS for low access priority and Access Class 11-15 is configured independently of each other. However, the home operator can take care to prevent a subscription for Access Class 11-15 from being used in an MS configured for low access priority.
for RR(C) connection establishment procedures when responding to paging;
for an MS configured with a permission for overriding low access priority under conditions described by bullet bullet q from clause 5.3.13.2; or
other specific situations described in TS 24.008.

If the NAS session management request message used to establish a new PDN connection contains a low access priority indication, the SGSN shall forward the low access priority indication in the Create PDP Context Request message to the GGSN and, in S4 mode, in the Create Session Request message to the S-GW/P-GW. The low priority indication gets associated with a PDN connection when it is established and it shall not change until the PDN connection is deactivated.

The low access priority indication may be included in charging records by the visited and home networks. In order to permit the S-GW and/or Gn/Gp SGSN to include the low access priority indicator in the charging records, the low access priority indicator should be stored in the SGSN EPS/PDP Bearer contexts and should be passed as part of these contexts to other SGSN/MME or S-GW nodes in mobility management procedures.

A network node may invoke one or more of the following mechanisms based on the indicators received in signalling from MSs or forwarded by other network nodes:

based on the low access priority indicator in NAS request messages, bullets e, h, i, k and l as defined in clause 5.3.13.2; and/or
based on the low access priority for RR(C) connection establishment, bullets b, c and n as defined in clause 5.3.13.2.

An MS shall invoke one or more of the following mechanisms based on the configuration and capabilities of the MS:

when MS is configured with a long minimum periodic PLMN search time limit, MS invokes actions as described in bullet f in clause 5.3.13.2; and/or
when MS is configured to perform Attach with IMSI at PLMN change, MS invokes actions as described in bullet g in clause 5.3.13.2; and/or
when MS is configured to use the extended NMO I system information, MS invokes actions as described in bullet o in clause 5.3.13.2; and/or
when MS is configured for low access priority, MS invokes actions as described in bullets b and h in clause 5.3.13.2; and/or
when MS is configured for Extended Access Barring, MS invokes actions as defined in bullet d in clause 5.3.13.2; and/or
when MS is configured for specific handling of the invalid (U)SIM state, the "forbidden PLMN list" and the "forbidden PLMNs for GPRS service list", MS invokes actions as defined in bullet p) in clause 5.3.13.2; and/or
when MS is configured with a permission for overriding low access priority and Extended Access Barring, the MS invokes actions as described in bullets q and r in clause 5.3.13.2.

5.3.13.4 Void

5.3.13.5 Optimizing periodic RAU Signalling |R10| p. 44

To reduce network load from periodic RAU signalling and to increase the time until the MS detects a potential need for changing the RAT or PLMN (e.g. due to network problems) the longer values of the periodic RAU timer and Mobile Reachable timer shall be supported.

A long periodic RAU/TAU timer value may be locally configured at SGSN or may be stored as part of the subscription data in HSS. During Attach and RAU procedures the SGSN allocates the periodic RAU timer value as periodic RAU timer to the UE based on VPLMN operator policy, low access priority indication from the MS, periodic RAU/TAU timer value requested by MS and subscription information received from the HSS.

If SGSN receives a subscribed periodic RAU/TAU timer value from the HSS it allocates the subscribed value to the MS as periodic RAU timer. A visited PLMN SGSN may use subscribed periodic RAU/TAU timer value, if available, as an indication to decide for allocating a locally configured periodic RAU/TAU timer value to the MS.

If no subscribed periodic RAU/TAU timer value is received from the HSS, the SGSN should:

if the periodic RAU/TAU timer value requested by MS is within the boundaries of the VPLMN operator policy, allocate the value requested by the MS;
if the periodic RAU/TAU timer value requested by MS is higher than allowed per the VPLMN operator policy, allocate the highest allowed value per the VPLMN operator policy;
if the periodic RAU/TAU timer value requested by MS is lower than allowed per the VPLMN operator policy, allocate the lowest allowed value per the VPLMN operator policy.

5.3.13.6 Support of MSs configured for low access priority, Extended Access Barring and permission for override |R11| p. 45

An MS may be configured for low access priority and Extended Access Barring as defined in TS 22.011. This configuration is primarily for usage by applications or users that can tolerate being deferred when competing with other MSs for accessing network resources, e.g. during congestion situations. A subscriber can by agreement with its operator be required to use MSs that are configured for low access priority. The agreement may include a specific tariffing. CDRs show whether a PDN connections was activated for use with low access priority.

An MS that is configured for low access priority and Extended Access Barring may be also configured with a permission for an override of low access and Extended Access Barring priority restrictions. This configuration is primarily for usage by applications or users that most of the time can tolerate being deferred due to low access priority when competing with other MSs for accessing network resources, but occasionally the application or user needs access to the network also when the low access priority configuration would prevent getting access. For getting network access also during low priority access or Extended Access Barring restriction conditions, the user or application (upper layers in UE) may request the UE to initiate the activation of a PDN connection without low access priority.

The permission for overriding low access priority and Extended Access Barring restrictions by the application or user should be handled with care because as long as such a PDN connection without low access priority is active, the MS is not affected by any access restriction conditions that the network may set for access with low access priority. That is, after the activation of a PDN connection without low access priority, all further MM and RRC access requests of the UE are performed without low access priority as long as such a PDN connection is active.

A subscriber can, by agreement with its operator, be required to use MSs that are configured with a permission for overriding low access priority and Extended Access Barring. As the 3GPP system cannot determine whether any overriding of access restrictions by such MSs is justified, the agreement can include a specific tariffing to avoid excessive usage of overriding the low access priority. This can for example be a specific tariffing for the amount of activations and/or the duration of PDN connections that are not with low access priority. CDRs show whether the MS activated the PDN connection with or without low access priority, but not necessarily the access priority the MS uses for the individual data transfer requests.

5.3.13.7 High latency communication |R13| p. 45

Functions for High latency communication may be used to handle mobile terminated (MT) communication with UEs being unreachable while using power saving functions e.g. MS Power Saving Mode (see clause 5.3.20) or extended idle mode DRX depending on operator configuration. "High latency" refers to the initial response time before normal exchange of packets is established. That is, the time it takes before a UE has woken up from its power saving state and responded to the initial downlink packet(s). The feature is described in TS 23.682.

The High latency communication includes invoking extended buffering of MT data at the Gn/Gp-SGSN or at the Serving GW when the UE is in a power saving state and not reachable. The handling is specified in the Network Initiated Service Request Procedure using Gn/Gp, clause 6.12.2. Establishing the user plane for delivering the buffered data when the UE contacts the SGSN by signalling shall be done in the Routing Area Update procedures. The SGSN uses its parameter DL Data Buffer Expiration Time in the MM context information to remember if there is buffered DL data to be delivered when the UE becomes reachable. When set, the DL Data Buffer Expiration Time shall be cleared at any user plane setup to the RAN, i.e. buffered DL data can been delivered. At RAU procedures with SGSN change, it is indicated in the context response to the new SGSN that buffered DL data is waiting and hence the user plane needs to be established for delivery of the buffer DL data. At RAU procedures the buffered DL data is forwarded to the new Gn/Gp-SGSN or new Serving GW when needed.

The High latency communication also includes sending event notifications to application servers that have requested "UE Reachability" or "Availability after DDN failure" monitoring events. If the notifying node is not a Gn/Gp-SGSN, event notifications are sent when a UE becomes reachable, for example as part of the RAU procedures and the MS/UE Initiated Service Request Procedures (see also corresponding procedures in TS 23.401).

When "UE Reachability" moniorting is requested for UE's that are using extended idle mode DRX, an event notification is sent to the application server when the UE is about to become reachable for paging.

If the SGSN is aware that some signalling or data is pending in the network for an UE, e.g. whether the UE has extended idle mode DRX or PSM enabled, the SGSN may include a Pending Data indication in the next RANAP message towards the UTRAN. If the UTRAN receives this indication, it may take this information into account when determining user inactivity. At inter-RAN node handovers, if some signalling or data are still pending, the target SGSN may send a Pending Data indication to the target UTRAN node.

5.3.13.8 Support for Non-IP data |R14| p. 46

5.3.13.8.1 General p. 46

The support of Non-IP data is part of the CIoT EPS optimisations. A PDP Type "Non-IP" is used for Non-IP data. The Non-IP data delivery to SCS/AS is accomplished by one of two mechanisms:

Delivery using a Point-to-Point (PtP) SGi tunnel as defined in TS 23.401.
Delivery using SCEF as defined in TS 23.682.

Non-IP data in-sequence delivery cannot be guaranteed and data PDUs can be lost, i.e. delivery cannot be guaranteed.

Secondary PDP Context Activation for PDP Contexts of PDP Type Non-IP is not supported.

5.3.13.8.2 PDP Context Activation Procedure p. 46

The MS indicates in the Activate PDP Context Request that PDP type Non-IP shall be used. If the SGSN establishes a PDP contexct of PDP type Non-IP, header compression shall not be used for the PDP context.

5.3.13.8.3 Delivery mechanism p. 46

5.3.13.8.3.1 General p. 46

At each PDP Context Request, the SGSN decides which delivery mechanism (SCEF based delivery or Gi/SGi based delivery) is used for delivering the Non-IP data between RAN and AS. An indication associated with the used APN determines if SCEF based delivery or Gi/SGi based delivery shall be used.

5.3.13.8.3.2 SCEF based delivery p. 46

When the SGSN decides to use SCEF based delivery mechanism for Non-IP data, a T6b connection is established towards the selected SCEF. Such a connection is also known as an "SCEF Connection". The APN used for SCEF based delivery is an FQDN, which either resolves to an SCEF hostname or to an SCEF IP addresss.

The support of Non-IP data via the SCEF is further defined in TS 23.682.

5.3.13.8.3.3 Gi/SGi based delivery p. 46

When support of Non-IP data is provided at the Gi/SGi interface, different point-to-point tunneling techniques may be used. Point-to-point tunneling by UDP/IP encapsulation can be used as described in TS 23.401.

Support for the Gi/SGi based delivery of Non-IP data can be used by any MS.

The GGSN/PDN-GW decides at PDP Context establishment based on pre-configuration which point-to-point tunneling technique is used for the Gi/SGi based delivery between the GGSN/PDN-GW and the AS as described in TS 23.401.

5.3.13.9 Introduction of CIoT GSM Optimisation |R14| p. 47

Cellular Internet of Things GSM Optimisation (CIoT GSM Optimization) provides support of:

Non-IP data (see clause 5.3.13.8);
Non-IP data delivery using SCEF (see TS 23.682);
APN Rate Control (see clause 15.2.3.2).

5.3.13.10 Restriction of use of Enhanced Coverage |R14| p. 47

Support of MSs in Enhanced Coverage is specified in TS 43.064.

The usage of Enhanced Coverage may require use of extensive resources (e.g. radio and signalling resources) from the network. This feature enables the operator to prevent specific subscribers from using Enhanced Coverage.

The MS indicates its capability of support for restriction of use of Enhanced Coverage for the RAT it is camping on in the Attach and RAU procedure to the SGSN. SGSN receives Enhanced Coverage Restricted parameter from the HLR. This parameter is kept as part of the subscription data in the HLR and specifies per PLMN whether the enhanced coverage functionality is restricted or not for the MS. For roaming MSs, if HLR doesn't provide any Enhanced Coverage Restricted parameter or the provided Enhanced Coverage Restricted parameter is in conflict with the roaming agreement, the SGSN uses default Enhanced Coverage Restricted parameter locally configured in the VPLMN based on the roaming agreement with the subscriber's HPLMN. The UE shall assume that restriction for use of Enhanced Coverage is same in the equivalent PLMNs. If the MS includes the support for restriction of use of Enhanced Coverage, SGSN sends Enhanced Coverage Restricted parameter to the MS in Attach/RAU Accept message. The MS shall use the value of Enhanced Coverage Restricted parameter to determine if enhanced coverage feature should be used or not.

The MS assumes Enhanced Coverage is allowed unless explicitly restricted by the network for a PLMN.

5.3.14 Local IP Access (LIPA) function |R10| p. 47

The LIPA function enables an IP capable UE connected via a HNB to access other IP capable entities in the same residential/enterprise IP network without the user plane traversing the mobile operator's network except HNB subsystem.

LIPA is available for UTRAN access only.

For this Release of the specification there is no support for secondary PDP context on the PDN connection used for Local IP Access.The PDN-GW/GGSN shall reject any MS initiated Secondary PDP Context Activation Procedure or any PDP Context Modification Procedure that is for the LIPA PDN Connection.

The LIPA function specified in TS 23.401, clause 4.3.16 is applicable, with the SGSN node providing the functions specified for the MME and the HNB providing the functions specified for the HeNB.

The HNB supporting the LIPA function includes the Local GW address to the SGSN in every INITIAL UE MESSAGE and every UTRAN Originated DIRECT TRANSFER control message as specified in TS 25.413.

5.3.15 Voice domain preference and UE's usage setting |R10| p. 47

If the UE supports CS fallback, or the UE is configured to support IMS voice, or both, and the UE is E-UTRAN capable, the UE shall include the information element "Voice domain preference and UE's usage setting" in Attach Request and Routing Area Update Request messages. The purpose of this information element is to signal to the network the UE's usage setting and voice domain preference for E-UTRAN. The UE's usage setting indicates whether the UE behaves in a voice centric or data centric way (as defined in TS 23.221). The voice domain preference for E-UTRAN indicates whether the UE is configured as CS Voice only, CS Voice preferred and IMS PS Voice as secondary, IMS PS Voice preferred and CS Voice as secondary, or IMS PS Voice only (as defined in TS 23.221).

5.3.16 Support for Application / Service Layer Rate Adaptation |R16| p. 48

The UTRAN and the UE support of Explicit Congestion Notification (ECN) according to the RFC 3168) are described in TS 23.401, TS 25.401 and TS 26.114.

If the UTRAN cannot sustain the GBR of an active GBR bearer the RNC should initiate a RAB Release according to clause 12.7.2. In addition, in case of UTRAN with GPRS (Gn/Gp SGSN with GGSN) the deactivation of the bearer is handled differently. The GPRS supports RNC initiated "PDP Context modification" where bearers are preserved in the core network for certain cases as described in clause 9.2.3.5 for architecture variants using Gn/Gp based interaction with GGSN.

5.3.17 Support for subscriptions without MSISDN |R10| p. 48

GPRS shall allow for operation whereby a MSISDN is not allocated as part of the subscription data. For example this can be useful for devices supporting MTC applications, see TS 23.682.

The following applies for a UE that operates without an MSISDN:

Presence of the MSISDN in the HLR/HSS subscription is optional.
The presence of the MSISDN in the SGSN MM context, PDP contexts and GGSN PDP contexts is dictated by its storage in HLR/HSS.
GTP support for MSISDN optionality whereby MSISDN is included only if available.
When the MSISDN is not available for CDR generation in the PS domain, the IMSI shall be used for CDR generation purposes.
Delivery of SMS destined to an MS without MSISDN.

The following services have unresolved MSISDN dependencies and are not supported at operation without MSISDN:

CAMEL Services.

5.3.18 PS-only Service Provision and PS domain SMS support |R11| p. 48

The HSS allows an operator to configure a subscription, which is limited to only PS services and SMS services. This limitation is indicated in the PS subscription data as "PS and SMS only". With this subscription the SMS service can either be provided via the PS domain or via the CS domain.

The support of SMS services via SGSN is a network deployment option and may depend also on roaming agreements. Therefore a subscription profile intended for PS-only service provision is either a subscription profile that is PS-only without any CS subscriber data, or it is a subscription profile for PS domain services and allowing also for SMS services via CS domain by CS subscriber data. The latter option of configuring a subscription is for providing a UE with PS domain and SMS services in situations when serving node or the visited network does not support SMS via SGSN.

If the subscription profile does not contain any CS subscriber data the HSS indicates this by the Network Access Mode information in the subscriber data provided to the SGSN. This indicates to the SGSN that the SGSN shall not perform any combined MM procedures for the UE and shall not establish a Gs association.

NOTE 1:

An operator should not configure a subscription profile without any CS subscription data when the UE/user shall be able to receive SMS services from an MME that uses SGs functionality for providing SMS services. It depends on (visited) network deployment or configuration whether the MME provides SMS services via "SMS in MME" or via SGs functionality. Further it should be noted that using PS-only service provision requires that the SMS-GMSC(s) deliver mobile terminating SMS via SGSN, which depends on network deployment or configuration (including a correct setting of the HSS "Transfer of SMS option" when the SMS-GMSC does not support two serving nodes addresses). For PS-only service provision it is therefore recommended that a home PLMN deploys an SMS-router and routes all terminating SMSs to its subscribers via the SMS-router. Especially when SMS-GMSCs from PLMNs other than the hPLMN are allowed to send mobile terminating SMS directly to the UE's serving CN node, but it cannot be ensured that all these SMS-GMSCs deliver SMS via SGSN.

The SGSN indicates that it offers SMS services via the PS domain to the HSS by an indication "SMS in SGSN offered" in the signalling with the HSS during the Attach/RAU procedure. In addition the SGSN may indicate a "Registration for SMS Request" according to the table below. The SGSN also forwards the capability indicated by the UE as an "SMS-only" indication to the HSS. When the subscription information indicates "PS and SMS only" the HSS shall respond to queries from SMS-GMSCs and SMS routers so that MT SMS gets routed to serving nodes in the PS domain when SMS via the PS domain are offered by these serving nodes.

Table 5.3.18-1: Registration For SMS Request values

SMS in SGSN Required	The SGSN can be configured to use this value when the UE indicates "SMS only" or when known that the subscription is "PS and SMS only" for asking the HSS to cancel any registered MSC.
SMS in SGSN Not Preferred	The SGSN can be configured to use this value for asking the HSS to not register the SGSN for SMS and to not cancel a registered MSC. This value can be requested regardless whether the UE indicates "SMS only" or the subscription is "PS and SMS only".
No Preference for SMS in SGSN	The SGSN has no preference about cancelling or keeping a registered MSC.

If the SGSN indicates "SMS in SGSN offered" and the PS subscriber data allow for SMS services and the home PLMN supports SMS services via SGSN, the HSS indicates "SMS in SGSN Support" in the subscriber data provided to the SGSN, unless the SGSN indicated "SMS in SGSN not Preferred" and the subscription allows for SMS via CS domain.

The HSS may be configured per visited PLMN whether SMS services via SGSN are supported and wanted, e.g. based on roaming agreement, for the specific visited PLMN. The HSS provision of CS subscriber data to any serving node requesting CS subscriber data follows regular procedures and is not affected.

When the HSS registers the SGSN for terminating SMS and the HSS has an old serving MSC registered, the HSS cancels the serving MSC for a UE if::

The SGSN indicates no parameter "Registration for SMS Request" and the MS indicated "SMS-only"; or
The SGSN indicated "SMS in SGSN Required" and the MS indicated "SMS-only"; or
The SGSN indicated "SMS in SGSN Required" and the subscription is "PS and SMS only"; or
The SGSN indicated "No Preference for SMS in SGSN" and the MS indicated "SMS-only".

A CS/PS enabled UE that needs only PS domain services and SMS services over NAS indicates this capability as "SMS-only" to the SGSN during combined GPRS / IMSI attach or combined RA/LA update procedures, i.e. the included CS registration is only requested for obtaining SMS services over NAS. Based on that UE provided information, based on preferences configured in SGSN and when the HSS provided subscription information indicates "SMS in SGSN Support", the SGSN then decides not to establish an association with an MSC when requested by the UE by combined GPRS / IMSI attach or combined RA/LA update procedures.

When the subscription information indicates "SMS in SGSN Support", the SGSN signals to the UE "SMS-Supported" in every Attach/RAU procedures to inform the UE that it can obtain SMS services via PS domain NAS from the SGSN. Thereby also UEs with CS services other than SMS are informed that SMS services via PS domain NAS can be obtained from the SGSN. The subscription information "SMS in SGSN Support" indicates to the SGSN that the UE's home PLMN is able and willing to provide SMS services via SGSN.

A CS/PS enabled UE that needs only PS domain services and SMS services over NAS and that receives indications in Attach/RAU procedures that it can obtain SMS services via SGSN should not perform an IMSI Attach or LAU procedures with the CS domain. That UE shall however perform combined RAU/LAU procedures when required by the network operation mode (NMO) for being informed when the PS domain provided services change.

If SGSN provide SMS services via PS domain for a CS/PS enabled UE, the SGSN may activate ISR for this UE by indicating ISR Activated in Combined RAU Accept message.

5.3.19 Access and Mobility Restrictions |R11| p. 50

S4-SGSNs and Gn/Gp-SGSNs determine mobility and access restrictions with LA granularity. Any time the UE performs a GPRS Attach or RAU the SGSN checks for access restrictions (see TS 23.221 and TS 23.008).

If roaming restriction to E-UTRAN access needs to be enforced, a SGSN that is connected to RNCs or BSCs that may handover or invoke release with redirection to E-UTRAN is configured with a list of HPLMN IDs that are permitted to access E-UTRAN unless restricted by the UE individual access restriction information received from HLR/HSS. Also, the SGSN shall set the E-UTRAN Service Handover IE (in Iu mode) or the Service UTRAN CCO (in A/Gb mode) to an appropriate value to inform the RNC or BSC respectively about connected-mode mobility restriction to E-UTRAN.

The SGSN shall also determine a RAT/Frequency Selection Priority that minimizes the risk of cell reselection of RATs that have access restrictions for a UE and provides the RAT/Frequency Selection Priority to the RNC or BSC, see clause 5.3.5.2.

5.3.20 MS Power Saving Mode |R12| p. 50

A MS may adopt a PSM that is described in TS 23.682. If an MS is capable of adopting a PSM and wants to use the PSM it shall request an Active Time value and may request a Periodic TAU/RAU Timer value during every Attach and RAU procedures, which are handled as described in TS 23.682. The MS shall not request a Periodic TAU/RAU Timer value if it is not requesting an Active Time value. The network shall not allocate an Active Time value if the MS has not requested it.

PSM has no support in the CS domain on the network side, but when PSM is activated the MS shall apply an Active Time regardless if the RR connection was used for accessing the PS or the CS domain.

If the network has allocated an Active Time value, the MS and the SGSN starts the Active Timer (see clause 6.2.3) with the Active Time value allocated by the network when transitioning from READY/PMM-CONNECTED to STANDBY/PMM-IDLE state. The MS shall stop the Active Timer, if running, when a transition to READY/PMM-CONNECTED state is made. When the Active timer expires, the MS deactivates its Access Stratum functions and enters PSM. In PSM, due to deactivation of Access Stratum functions if no RR connection exists, the MS stops all idle mode procedures, but continues to run any NAS timers that may apply, e.g. periodic RAU timer. The MS shall resume Access Stratum functions and idle mode procedures before the periodic RAU timer expires for performing the periodic RAU procedure as applicable. The MS may resume idle mode procedures and AS functions any time while in PSM, e.g. for mobile originated communications. Any timers and conditions that remain valid during power-off, e.g. for NAS-level back-off, apply in the same way during PSM.

When the Active Timer expires for the MS, the SGSN knows that the MS entered PSM and is not available for paging. The SGSN handles availability for paging as detailed in clause 6.2.3.

On MS side the PSM complies with some substates of GMM-REGISTERED, as specified in TS 24.008. The SGSN considers the MS to be GMM-REGISTERED, but not reachable. The MS's Access Stratum functions are considered as deactivated during PSM regardless if the MS is attached to the PS or PS and CS domain and therefore limiting the supported procedures in the respective domains.

For mobile terminated data while an MS is in PSM, the functions for High latency communication may be used as described in clause 5.3.13.7.

When the MS has bearers for emergency services, the MS shall not apply PSM.

5.3.21 Access network selection and traffic steering based on RAN-assisted WLAN interworking |R12| p. 51

As described in TS 36.300, TS 36.331, TS 25.304 and TS 25.331, UTRAN and E-UTRAN may provide RAN assistance parameters to the UE via RRC signalling. TS 23.401 describes how the network provides to the MS the WLAN offloading permissions for the UE and PDP context in NAS signalling.

For traffic steering decisions using procedures defined in TS 25.304 the S4-SGSN may provide a WLAN offloadability indication of a PDN Connection to the UE. The S4-SGSN may provide a per-RAT indication for the PDN connection, e.g. if the indication is different for UTRAN and for E-UTRAN. If the S4-SGSN provides a single indication, the UE shall apply such indication both to E-UTRAN and UTRAN.

The S4-SGSN may provide an updated WLAN offloadability indication of a PDN Connection to the UE. This may be initiated by HSS as part of the Insert Subscriber Data procedure as described in clause 6.11.1.1. It can also be initiated by S4-SGSN by invoking step 6 and step 7 of a PDP Context Modification Procedure as described in clause 9.2.3.1, Figure 70b when the UE is in Iu mode or by adding the WLAN offloadability indication to a session management NAS message sent to the UE as part of an existing procedure. The S4-SGSN shall not trigger signaling to a PMM-IDLE UE solely for the purpose of updating the WLAN offloadability indication.

The indication of whether a PDN connection is offloadable or not offloadable should be passed from the source to the target serving node in mobility management procedures from a S4-SGSN to a MME/S4-SGSN. This allows the target S4-SGSN/MME to learn the indication previously provided to the UE and to decide the need for updating the indication.

When the MS receives, as described in TS 23.401 the indication of whether a PDP context is offloadable or not, the MS stores the indication. Upon performing inter-RAT mobility the MS shall not reset the stored indication unless it receives a new indication from the network. If the UE is in A/Gb mode, the UE does not use the indication received from S4-SGSN or previously stored for as long as it is in A/Gb mode.

Traffic steering decisions using procedures defined in TS 25.304 are not applicable to non-seamless WLAN offload (see TS 23.402 for the definition of non-seamless WLAN offload).

5.3.22 User plane congestion management function |R13| p. 51

See clause 4.3.24 of TS 23.401.

5.3.23 Dedicated Core Networks (DCNs) |R13| p. 51

5.3.23.1 General p. 51

This feature enables an operator to deploy multiple core networks within a PLMN with each core network consisting of one or multiple CN nodes. Overview of UE non-assisted DCN selection feature is provided in clause 4.3.25.1 and UE assisted DCN selection feature is provided in clause 4.3.25.1a of TS 23.401. Specific impacts to supporting DCNs for UTRAN and GERAN accesses are captured in this specification and in TS 23.236.

5.3.24 Support for Monitoring Events |R13| p. 51

The Monitoring Events feature is intended for monitoring of specific events in 3GPP system and making such monitoring event information available via the Service Capability Exposure Function (SCEF). The architecture and related functions to support Monitoring Events for S4-SGSN are defined in TS 23.682. Monitoring Events feature for Gn/Gp SGSN isn't supported.

5.3.25 3GPP PS Data Off |R14| p. 52

5.3.25.1 General p. 52

This clause provides an overview about feature for 3GPP PS Data Off according to service requirements described in TS 22.011.

3GPP PS Data Off feature specified in TS 23.401 is applicable, with the SGSN node providing the functions specified for the MME and the GGSN node providing the functions of the PGW.

The MSs are configured with up to two lists of 3GPP PS Data Off Exempt Services and the list(s) are provided to the MSs by HPLMN via Device Management or UICC provisioning. When the MS is configured with two lists, one list is valid for the MSs camping in the home PLMN and the other list is valid for any VPLMN the MS is roaming in. If the MS is configured only a single list, without an indication to which PLMNs the list is applicable, then this list is valid for the home PLMN and any PLMN the MS is roaming in.

When the MS requests PDP Context Activation, the MS shall send its current 3GPP PS Data Off status (i.e., activated, inactivate) in PCO to the GGSN/PGW as described in clause 9.2.2.

If 3GPP PS Data Off status is activated, the MS prevents the sending of uplink IP packets and non-IP data except those related to 3GPP PS Data Off Exempt Service as defined in TS 23.221, based on the pre-configured list of 3GPP Data Off Exempt Services.

For those PGWs/GGSNs that indicated support for the 3GPP PS Data Off feature during PDP Context Activation procedure, the MS shall report a change of its 3GPP PS Data Off status in PCO immediately by using MS-initiated PDP Context Modification procedure to those PGWs/GGSNs as described in clause 9.2.3.3, this also applies to the scenario of inter-RAT mobility procedure to GERAN/UTRAN and also to scenarios where the 3GPP PS Data Off status is changed when the session management back-off timer is running as specified in clause 5.3.6. If the MS has not received any 3GPP PS Data Off Support Indication during PDP Context Activation procedure, it shall not report any change of its 3GPP PS Data Off Status for this PDN connection.

The MS discovers whether a PGW/GGSN supports 3GPP PS Data Off feature during PDP Context Activation procedure via the presence of the 3GPP PS Data Off Support Indication in the Activate PDP Context Accept message.

The additional behaviour of the PGW/GGSN for 3GPP PS Data Off is controlled by local configuration or policy from the PCRF as defined in TS 23.203.