5.3 High-Level Functions

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

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

5.3.0 General

The following list gives the logical functions performed within the packet domain network for GPRS with GERAN or UTRAN accesses. Several functional groupings (meta functions) are defined and each encompasses a number of individual functions:

– Network Access Control Functions.

– Packet Routeing and Transfer Functions.

– Mobility Management Functions.

– Logical Link Management Functions (A/Gb mode).

– Radio Resource Management Functions.

– Network Management Functions.

– UE reachability function

5.3.1 Network Access Control Functions

Network access is the means by which a user is connected to a telecommunication network in order to use the services and/or facilities of that network. An access protocol is a defined set of procedures that enables the user to employ the services and/or facilities of the network.

User network access may occur from either the mobile side or the fixed side of the network. The fixed network interface may support multiple access protocols to packet data networks, for example IP. The set of access protocols to be supported is determined by the PLMN operator.

Individual PLMN administrations may require specific access-control procedures in order to limit the set of users permitted to access the network, or to restrict the capabilities of individual users, for example by limiting the type of service available to an individual subscriber. Such access control procedures are beyond the scope of the specifications.

5.3.1.1 Registration Function

Registration is the means by which a user’s Mobile Id is associated with the user’s packet data protocol(s) and address(es) within the PLMN, and with the user’s access point(s) to the packet data network. The association can be static, i.e. stored in an HLR, or dynamic, i.e. allocated on a per need basis.

5.3.1.2 Authentication and Authorisation Function

This function performs the identification and authentication of the service requester, and the validation of the service request type to ensure that the user is authorised to use the particular network services. The authentication function is performed in association with the Mobility Management functions.

5.3.1.3 Admission Control Function

The purpose of admission control is to calculate which network resources are required to provide the quality of service (QoS) requested, determine if those resources are available, and then reserve those resources. Admission control is performed in association with the Radio Resource Management functions in order to estimate the radio resource requirements within each cell.

5.3.1.4 Message Screening Function

A screening function concerned with filtering out unauthorised or unsolicited messages is required. This should be supported through packet filtering functions. All types of message screening are left to the operators’ control, e.g. by use of Internet firewalls.

5.3.1.5 Packet Terminal Adaptation Function

This function adapts data packets received / transmitted from/to terminal equipment to a form suitable for transmission by GPRS across the packet domain network.

5.3.1.6 Charging Data Collection Function

This function collects data necessary to support subscription and/or traffic fees.

5.3.1.7 Operator Determined Barring Function

The purpose of this function is to limit the service provider’s financial risk with respect to new subscribers or to those who have not promptly paid their bills by restricting a particular packet switched service.

The functionality of ODB is described in the TS 23.015 [66].

5.3.2 Packet Routeing and Transfer Functions

A route is an ordered list of nodes used for the transfer of messages within and between the PLMN(s). Each route consists of the originating node, zero or more relay nodes and the destination node. Routeing is the process of determining and using, in accordance with a set of rules, the route for transmission of a message within and between the PLMN(s).

5.3.2.1 Relay Function

The relay function is the means by which a node forwards data received from one node to the next node in the route.

5.3.2.2 Routeing Function

The routeing function determines the core network node to which a message should be forwarded and the underlying service(s) used to reach that GPRS Support Node (GSN), S‑GW or P‑GW, using the destination address of the message. The routeing function selects the transmission path for the "next hop" in the route.

Data transmission between core network nodes may occur across packet data networks that provide their own internal routeing functions, for example ITU-T Recommendation X.25 [34], Frame Relay or ATM networks.

5.3.2.3 Address Translation and Mapping Function

Address translation is the conversion of one address to another address of a different type. Address translation may be used to convert an packet data network protocol address into an internal network address that can be used for routeing packets within and between the PLMN(s).

Address mapping is used to map a network address to another network address of the same type for the routeing and relaying of messages within and between the PLMN(s), for example to forward packets from one network node to another.

5.3.2.4 Encapsulation Function

Encapsulation is the addition of address and control information to a data unit for routeing packets within and between the PLMN(s). Decapsulation is the removal of the addressing and control information from a packet to reveal the original data unit.

Encapsulation and decapsulation are performed between the core network nodes, and between the GPRS serving support node and the MS.

5.3.2.5 Tunnelling Function

Tunnelling is the transfer of encapsulated data units within and between the PLMN(s) from the point of encapsulation to the point of decapsulation. A tunnel is a two-way point-to-point path. Only the tunnel endpoints are identified.

5.3.2.6 Compression Function

The compression function optimises use of radio path capacity by transmitting as little of the SDU (i.e. the exterior PDP PDU) as possible while at the same time preserving the information contained within it. Only IP header compression is supported in Iu mode. The P‑GW/GGSN may instruct the SGSN to negotiate no data compression for specific PDP contexts.

5.3.2.7 Ciphering Function

The ciphering function preserves the confidentiality of user data and signalling across the radio channels and inherently protects the PLMN from intruders.

5.3.2.8 Domain Name Server Function

The Domain Name Server function resolves logical network node names to addresses. This function is standard Internet functionality according to RFC 1034 [43], which allows resolution of any name for GSNs and other nodes within the GPRS packet domain PLMN backbone networks.

5.3.2.9 DHCP function

The Dynamic Host Configuration Function allows to deliver IP configuration information for UEs. This function is standard Internet functionality.

5.3.3 Mobility Management Functions

5.3.3.1 General

The mobility management functions are used to keep track of the current location of an MS within the PLMN or within another PLMN.

5.3.3.2 Idle Mode Signalling Reduction Function

The Idle mode Signalling Reduction (ISR) function provides a mechanism to limit signalling during cell‑reselection in idle mode between GERAN and E‑UTRAN or between UTRAN and E‑UTRAN and is described in TS 23.401 [89].

NOTE: This function is not used in GERAN/UTRAN only network deployments.

5.3.4 Logical Link Management Functions (A/Gb mode)

Logical link management functions are concerned with the maintenance of a communication channel between an individual MS and the PLMN across the radio interface. These functions involve the co-ordination of link state information between the MS and the PLMN as well as the supervision of data transfer activity over the logical link.

Refer to TS 44.064 [15] for further information.

5.3.4.1 Logical Link Establishment Function

Logical link establishment is performed when the MS attaches to the PS services.

5.3.4.2 Logical Link Maintenance Functions

Logical link maintenance functions supervise the logical link status and control link state changes.

5.3.4.3 Logical Link Release Function

The logical link release function is used to de-allocate resources associated with the logical link connection.

5.3.5 Radio Resource Management Functions

5.3.5.1 General

Radio resource management functions are concerned with the allocation and maintenance of radio communication paths, and are performed by the Radio Access Network. Refer to TS 43.064 [11] and to TS 43.051 [74] for further information on GERAN. Refer to TS 25.301 [50] for further information on UTRAN.

5.3.5.2 RAT/Frequency Selection Priority

To support radio resource management in UTRAN/GERAN, the SGSN provides the parameter ‘Index to RAT/Frequency Selection Priority’ to RNC across Iu and to BSC across Gb. The RFSP Index is mapped by the RNC/BSC to locally defined configuration in order to apply specific RRM strategies. The RFSP Index is UE specific and applies to all the Radio Bearers. Examples of how this parameter may be used in UTRAN/GERAN:

– to derive UE specific cell reselection priorities to control idle mode camping.

– to decide on redirecting active mode UEs to different frequency layers or RATs.

The SGSN receives the subscribed RFSP Index from the HSS (e.g., during the Attach procedure). For non-roaming subscribers the SGSN chooses the RFSP Index in use according to one of the following procedures, depending on operator’s configuration:

– the RFSP Index in use is identical to the subscribed RFSP Index, or

– the SGSN chooses the RFSP Index in use based on the subscribed RFSP Index, the locally configured operator’s policies and the UE related context information available at the SGSN, including the UE’s usage setting and voice domain preference for E-UTRAN, if received during Attach and Routing Area Update procedures (see clause 5.3.15).

NOTE 1: One example of how the SGSN can use the "UE voice capabilities and settings" is to select an RFSP value that enforces idle mode camping on 2G/3G for a UE acting in a "Voice centric" way and provisioned with "CS Voice preferred, IMS Voice as secondary", in order to minimize the occurrence of RAT changes. Another example is the selection of an RFSP value that prevents idle mode camping on 2G for a UE provisioned with "IMS PS voice preferred, CS Voice as secondary" if other RATs supporting IMS Voice are available, as the UE would in such case always select the CS domain for its voice calls.

For roaming subscribers the SGSN may alternatively choose the RFSP Index in use based on the visited network policy but can take input from HPLMN into account. (e.g. an RFSP Index value pre-configured per HPLMN, or a single RFSP Index value to be used for all roamers independent of the HPLMN).

NOTE 2: One example of how the SGSN can choose the RFSP Index in use for non-roaming or roaming subscribers with access restriction for E-UTRAN access due to access restriction in the subscription data or based on local configuration e.g. to reflect roaming restriction to E-UTRAN access, is to select an RFSP value that minimizes the risk of E-UTRAN cell reselection by a UE.

The SGSN forwards the RFSP Index in use to the RNC across Iu and to the BSC across Gb. The RFSP Index in use is also forwarded from source RNC to target RNC during the SRNS Relocation procedure for Intra-RAT handover.

The SGSN stores the subscribed RFSP Index value received from the HSS and the RFSP Index value in use. During the Routing Area Update procedure the SGSN may update the RFSP Index value in use and signal the updated value to the RNC across Iu and to the BSC across Gb, if the locally configured operator’s policies indicate to do so (e.g. the SGSN may need to update the RFSP Index value in use if the UE related context information has changed). During inter-SGSN mobility procedures, the source SGSN forwards both RFSP Index values to the target SGSN. The target SGSN may replace the received RFSP Index value in use with a new RFSP Index value in use that is based on the operator’s policies and the UE related context information available at the target SGSN.

The Iu messages that transfer the RFSP Index to the RNC are specified in TS 25.413 [56b].

The Gb messages that transfer the RFSP Index to the BSC are specified in TS 48.018 [78].

5.3.5.3 Service identification for improved radio utilisation for GERAN

The Service Class Indicator (SCI) (see TS 29.281 [120]) enables the GGSN/P-GW to provide the A/Gb mode GERAN access with an indication in the downlink user plane packet to assist the A/Gb mode GERAN access in providing specific RRM treatment in order to improve radio resource control and the overall performance of the GERAN.

NOTE 1: It is intended to standardize SCIs and relationship between SCIs and QoS classes in a future Release.

In the current specification, the SCI is only applicable for A/Gb mode GERAN access, and only for the Gn/Gp, S4 and the GTP based S5/S8 interfaces.

Support of SCI is optional in GERAN, A/Gb mode SGSN, and PGW/GGSN.

The GGSN/PGW is informed by the SGSN/MME of the UE’s current RAT.

When the UE is using an A/Gb mode GERAN the GGSN/PGW determines the value of the SCI based on configuration.The SCI is included in the downlink user plane data packet (see TS 29.281 [120]).

NOTE 2: The 3GPP charging architecture does not take the SCI value into account.

There is no impact on the S-GW as part of this feature. If the SCI is received at the S-GW, the S-GW forwards them transparently.

NOTE 3: This feature has no impact on the RNC, eNodeB and Iu mode SGSN. If (unusually) the SCI is received, these entities behave according to the existing specifications for the treatment of GTP extension headers.

An eNodeB or RNC shall ignore the Service Class Indicator if received over the S1-U, S12 or other interface.

When the serving A/Gb mode SGSN receives SCI in a GTP-U packet, it copies it, without modifying its value, into a Gb interface information element that is sent by the SGSN in the downlink Gb interface user data packet to the GERAN access. In order to allow the GERAN to map the SCI into RRM behaviour, the downlink Gb interface user data packet also carries the HPLMN ID (in the IMSI parameter) and additional information, added by the SGSN, which indicates whether the SCI is assigned:

– by a GGSN/P-GW in the Home PLMN, or

– by a GGSN/P-GW in the Visited PLMN, or

– by a GGSN/P-GW for which the SCIs are coordinated across the different operator group PLMNs and the serving PLMN of the SGSN (Operator Group GGSN).

Absence of additional information is an indication of a VPLMN provided SCI.

NOTE 4: The SGSN determines and indicates "Operator Group GGSN" based on local configuration, which consists of a list of specific APN-NIs and associated PLMN-IDs.

The A/Gb mode GERAN uses the information from the SGSN to determine whether to map, and how to map, the SCI to the related RRM behaviour. If the GERAN is not configured with an SCI mapping for the SGSN provided information, then the GERAN shall treat the user plane packet normally, i.e. the GERAN ignores the SCI.

NOTE 5: When sending downlink GTP-U packets, there are some transient periods where the "current RAT" information for the user may be incorrect at the GGSN/P-GW e.g. after a handover from (E)UTRAN to GERAN, or if the MS is in idle mode with ISR active, or if the MS is in idle mode and located in a Routing Area comprising GERAN and UTRAN cells. In these cases, the A/Gb mode GERAN may receive the first downlink user plane packets without Service Class Indicator.

In network sharing configurations (MOCN or GWCN) the SCI can be supported as specified in TS 23.251 [83].

5.3.6 Network Management Functions

5.3.6.1 General

Network management functions provide mechanisms to support O&M functions related to GPRS.

5.3.6.1a GTP-C signalling based Load and Overload Control

The S4-SGSN may support GTP-C based Load Control feature for enhanced GW selection procedures as described in TS 23.401 [89] clause 4.3.7.1a.1.

The S4-SGSN may support GTP-C signalling based Overload Control feature as described in TS 23.401 [89] clause 4.3.7.1a.2.

For details on the applicability and use of Load and Overload Control feature for PDN GW and Serving GW, see TS 23.401 [89], clause 4.3.7.1a.

5.3.6.2 NAS level congestion control

5.3.6.2.1 General

NAS level congestion control contains the functions: "APN based congestion control" and "General NAS level Mobility Management congestion control".

The use of the APN based MM and SM congestion control is for avoiding and handling of MM and SM signalling congestion associated with MSs with a particular APN. Both MSs and network shall support the functions to provide APN based MM and SM congestion control.

The SGSN may detect the NAS signalling congestion associated with the APN and start and stop performing the APN based congestion control based on criteria such as:

– Maximum number of active PDP contexts per APN;

– Maximum rate of PDP context activations per APN;

– One or multiple PDN GWs or GGSNs of an APN are not reachable or indicated congestion to the SGSN;

– Maximum rate of MM signalling requests associated with the devices with a particular subscribed APN; and/or

– Setting in network management.

The SGSN may detect the NAS signalling congestion associated with the MSs belonging to a particular group. The SGSN may start and stop performing the group based congestion control based on criteria such as:

– Maximum rate of MM and SM signalling requests associated with the devices of a particular group; and/or

– Setting in network management.

The SGSN may detect the NAS signalling congestion associated with the MSs that belong to a particular group and are subscribed to a particular APN. The SGSN may start and stop performing the APN and group specific NAS level congestion control based on criteria such as:

– Maximum number of active PDP contexts per group and APN;

– Maximum rate of MM and SM signalling requests associated with the devices of a particular group and a particular subscribed APN; and/or

– Setting in network management.

The SGSN should not apply NAS level congestion control for emergency services.

The SGSN may also use the reject of NAS level Mobility Management signalling requests under general congestion conditions such as detecting congestion of one or several DCNs in an SGSN serving multiple DCNs.

5.3.6.2.2 APN based Session Management congestion control

The APN based Session Management congestion control may be activated by SGSN due to e.g. congestion situation at SGSN, or by OAM at SGSN, or by a restart or recovery condition of a GGSN or PDN GW, or by a partial failure or recovery of a GGSN or PDN GW for a particular APN(s).

The SGSN may reject the Session Management (SM) requests from the MS (e.g. Activate PDP Context and Secondary PDP Context) with a Session Management back-off timer for congested APNs. If the MS provides no APN, then the SGSN uses the APN which is used in GGSN/PDN GW selection procedure.

The SGSN may deactivate PDP contexts belonging to a congested APN by sending the Deactivate PDP Context Request message to the MS with a Session Management back-off timer. If Session Management back-off timer is set in the Deactivate PDP Context Request message then the cause "reactivation requested" should not be set.

NOTE 1: MSs that do not support the Session Management back-off timer (including earlier release of MS) might contribute to increasing the signalling load in the SGSN by reattempting Session Management procedure.

The SGSN may store a Session Management back-off time per MS and APN when congestion control is active for an APN if a request without the low access priority indicator is rejected by the SGSN. The SGSN may immediately reject any subsequent request from the MS targeting to the APN before the stored Session Management back-off time is expired except Modify PDP Context Request -as it may be used by the MS to report 3GPP PS Data Off status change, see clause 5.3.25). If the SGSN stores the Session Management back-off time per MS and APN and the SGSN decides to send a Session Management Request message to a MS connected to the congested APN (e.g. due to decreased congestion situation), the SGSN shall clear the Session Management back-off time prior to sending any Session Management Request message to the MS.

NOTE 2: The above functionality is to diminish the performance advantage for MSs that do not support the NAS level back-off timer (e.g. pre-Rel‑10 MSs) compared to MSs that do support it.

The SGSN should not apply APN based congestion control for emergency services.

Upon reception of the Session Management back-off timer in the Session Management reject message or in the Deactivate PDP Context Request message, the MS shall take the following actions until the timer expires:

– If APN is provided in the rejected Session Management Request message or if the Session Management back-off timer is received in the Deactivate PDP Context Request message, the MS shall not initiate any Session Management procedures for the congested APN. The MS may initiate Session Management procedures for other APNs.

– If APN is not provided in the rejected Session Management Request message, the MS shall not initiate any Session Management requests without APN. The MS may initiate Session Management procedures for specific APN.

– Cell/RA/PLMN/RAT change do not stop the Session Management back-off timer.

– The MS is allowed to initiate the Session Management procedures when it is accessing the network with AC11‑15 or for emergency services even when the Session Management back-off timer is running.

– The MS is allowed to perform MS-initiated PDP Context Modification procedure to report 3GPP PS Data Off status change when the Session Management back off timer is running.

– If the MS receives a network initiated Session Management Request message for the congested APN while the Session Management back-off timer is running, the MS shall stop the Session Management back-off timer associated with this APN and respond to the SGSN.

– If the MS is configured with a permission for overriding low access priority and the Session Management back-off timer is running due to a reject message received in response to a request with low access priority, the upper layers in MS may request the initiation of Session Management procedures without low access priority.

The MS is allowed to initiate PDN disconnection procedure (e.g. sending Deactivate PDP Context Request) when the Session Management back off timer is running.

NOTE 3: The MS does not delete the related Session Management back-off timer when deactivating a PDP context.

The MS shall support a separate Session Management back-off timer for every APN that the MS may activate.

To avoid that large amounts of MSs initiate deferred requests (almost) simultaneously, the SGSN should select the Session Management back-off timer value so that deferred requests are not synchronized.

The APN based Session Management congestion control is applicable to the NAS SM signalling initiated from the MS in the control plane. The Session Management congestion control does not prevent the MS to send and receive data or initiate Service Request procedures for activating user plane bearers towards the APN(s) that are under SM congestion control.

5.3.6.2.3 APN based Mobility Management congestion control

The SGSN may perform APN based congestion control for MSs with a particular subscribed APN by rejecting Attach procedures with a Mobility Management back-off timer. If the subscription contains a wildcard APN, the SGSN should not reject the request.

When congestion control is active for MSs with a particular subscribed APN, a Mobility Management back-off timer may be sent by the SGSN to MS.

If SGSN maintains the MS context, the SGSN may store the back-off time per MS if a request without the low access priority indicator is rejected by the SGSN. The SGSN may immediately reject any subsequent request from the MS before the stored back-off time is expired.

NOTE 1: The above functionality is to diminish the performance advantage for MSs that do not support the NAS level back-off timer (e.g. pre-Rel‑10 MSs) compared to MSs that do support it.

After rejecting Attach Requests, the SGSN should keep the subscriber data for some time. This allows for the rejection of subsequent requests without HSS signalling when the congestion situation resulting from MSs with a particular subscribed APN persists. Similarly the SGSN may reject Attach Requests based on subscriber data that the SGSN may store after the Detach procedure.

While the Mobility Management back-off timer is running, the UE shall not initiate any NAS request for Mobility Management procedures. However, the UE is allowed to initiate Mobility Management procedures when it is accessing the network with AC11-15 or for emergency services even when the Mobility Management back-off timer is running.

NOTE 2: When receiving the Mobility Management back-off timer the MS behaviour is not APN specific.

While the Mobility Management back-off timer is running, the MS configured with a permission for overriding low access priority is allowed to initiate Mobility Management procedures without low access priority if the Mobility Management back-off timer was started due to a reject message received in response to a request with low access priority and the upper layers in MS request to activate a PDP context without low access priority or the MS has an activated PDP context that is without low access priority.

To avoid that large amounts of MSs initiate deferred requests (almost) simultaneously, the SGSN should select the Mobility Management back-off timer value so that deferred requests are not synchronized.

5.3.6.2.4 General NAS level Mobility Management congestion control

Under general overload conditions the SGSN may reject Mobility Management signalling requests from MSs. When a NAS request is rejected, a Mobility Management back-off timer may be sent by the SGSN. If SGSN maintains the MS context, the SGSN may store the back-off time per MS if a request without the low access priority indicator is rejected by the SGSN. The SGSN may immediately reject any subsequent request from the MS before the stored back-off time is expired. While the Mobility Management back-off timer is running, the MS shall not initiate any NAS request for Mobility Management procedures. While the Mobility Management back-off timer is running, the MS is allowed to access the network with AC11-15, perform Detach Procedure, perform mobile terminated services and initiate emergency services. While the Mobility Management back-off timer is running, the MS is allowed to perform Routing Area Update (or combined RA/LA update) if it is already in READY or PMM-CONNECTED state. After any such Detach procedure, the back-off timer continues to run. If the MS receives a paging request from the SGSN while the Mobility Management back-off timer is running, the MS shall stop the Mobility Management back-off timer and initiate the Service Request procedure or the Routeing Area Update procedure as described in clause 6.9.2.1.

The Mobility Management back-off timer shall not impact the UE’s function to perform Cell/RAT and PLMN change. Cell/RAT and RA change do not stop the Mobility Management back-off timer. The Mobility Management back-off timer shall not be a trigger for PLMN reselection. The back-off timer is stopped as defined in TS 24.008 [13] when a new PLMN that is not an equivalent PLMN is accessed.

When the MS receives a handover command, the MS shall proceed with the handover procedure regardless of whether the Mobility Management back-off timer is running.

The SGSN should not reject Routing Area Update procedures that are performed when the MS is already in READY or PMM-CONNECTED state.

If the SGSN rejects a Routing Area Update Request or a Service Request with a Mobility Management back-off timer which is larger than the sum of the MS’s periodic RA Update timer plus the implicit detach timer, the SGSN should adjust the mobile reachable timer and/or implicit detach timer such that the SGSN does not implicitly detach the MS while the Mobility Management back-off timer is running.

NOTE: This is to minimize unneeded signalling after the Mobility Management back-off timer expires.

5.3.6.2.5 Group specific NAS level congestion control

The group specific NAS level congestion control applies to a specific group of MSs. Each group has a group identifier assigned.

A MS belongs to a group, if the corresponding group identifier is stored in the MS’s subscription data in the HLR/HSS. A MS may belong to multiple groups and the SGSN may perform the Group specific NAS level congestion control to an MS as described below independent of whether Group specific NAS level congestion control is activated for one, multiple, or all groups the MS belongs to. The group identifier shall be stored per MS in the HLR/HSS and obtained by the SGSN as part of normal HLR/HSS signalling. A MS is not aware of a group subscription.

The group specific NAS level congestion control may be activated for Session Management signalling, or for Mobility Management signalling, or both. The group specific NAS level congestion control is activated based on operator policies.

When the group specific NAS level congestion control for Session Management signalling is active for a particular group, the SGSN’s behaviour is similar to that in clause 5.3.6.2.2, with the following modifications:

– SGSN may apply Session Management congestion control to all subscribed APNs for MSs that belong to this particular group.

NOTE: How the SGSN applies Session Management congestion control to all subscribed APNs is left to Stage 3.

– The SGSN may reject the Session Management (SM) requests from the MS belonging to this particular group (e.g. Activate PDP Context, Secondary PDP Context and Modify PDP Context Requests) with a Session Management back-off timer.

When group specific NAS level congestion control for Mobility Management signalling is active for a particular group and a particular APN, the SGSN’s behaviour is similar to that in clause 5.3.6.2.3, but applied to MSs with subscribed to this particular group rather that subscribed to a particular APN.

Group specific NAS level congestion control is performed at the SGSN based on the MS’s subscription information provided by the HLR/HSS. There is no impact on the MS, and hence, MS’s behaviour as described in clauses 5.3.6.2.2 and 5.3.6.2.3 does not change.

5.3.6.2.6 APN and group specific NAS level congestion control

The APN and group specific NAS level congestion control is the interclause of APN specific NAS level congestion control and Group specific NAS level congestion control, i.e. it applies to a specific group of MSs with a particular subscribed APN. Each group of UEs has a group identifier assigned and stored in the HSS.

A MS may belong to multiple groups and the SGSN may perform the APN and group specific NAS level congestion control to a MS as described below independent of whether the APN and group specific NAS level congestion control is activated for one, multiple or all groups the MS belongs to. The group identifier(s) shall be stored per MS in the HLR/HSS and obtained by the SGSN as part of normal HLR/HSS signalling. A MS is not aware of the group identifier(s) that the UE belongs to.

The APN and group specific NAS level congestion control may be activated for Session Management signalling, or for Mobility Management signalling, or both. The APN and group specific NAS level congestion control is activated based on operator policies.

When the APN and group specific NAS level congestion control for Session Management signalling is activated for a MS belonging to a particular group and initiating signalling to a particular subscribed APN, the SGSN’s behaviour is similar to that in clause 5.3.6.2.2, with the following modifications:

– The Session Management (SM) congestion control is applied to this particular APN, and for MSs belonging to this particular group.

– The SGSN may reject the SM requests from the MS belonging to this particular group and attaching to this particular APN (e.g. Activate PDP Context and Secondary PDP Context) with a Session Management back-off timer. If the MS provides no APN, then the SGSN uses the APN which is used in GGSN/PDN GW selection procedure.

– The SGSN may deactivate PDP contexts from the MSs, belonging to this particular group and attaching to this particular APN, by sending the Deactivate PDP Context Request message to the MS with a Session Management back-off timer.

When APN and group specific NAS level congestion control for Mobility Management signalling is activated for a MS belonging to a particular group and with a particular subscribed APN, the SGSN’s behaviour is similar to that in clause 5.3.6.2.3, but applied to MSs with this particular subscribed APN and belonging to this particular group.

APN and group specific NAS level congestion control is performed at the SGSN based on the MS’s subscription information provided by the HLR/HSS. There is no impact on the MS, and hence, MS’s behaviour described in clauses 5.3.6.2.2 and 5.3.6.2.3 does not change.

5.3.6.3 GGSN control of overload

The GGSN may provide mechanisms for avoiding and handling overload situations. These include the rejection of PDP context requests from UEs.

The GGSN may detect congestion per APN and start and stop performing overload control based on criteria such as:

– Maximum number of active PDP contexts per APN and/or

– Maximum rate of PDP context activations per APN.

When performing overload control the GGSN rejects PDP context requests. When receiving the rejection from the GGSN, the SGSN rejects the UE’s PDP context request as specified in clause 5.3.6.2. In addition the GGSN may indicate a "GGSN back-off time" for a specific APN to the SGSN. The SGSN should reject PDP context requests from UEs for the specific APN related to that GGSN during the "GGSN back-off time", by the means specified in clause 5.3.6.2. If a GGSN indicates APN congestion by the "GGSN back-off time" the SGSN may select another GGSN of that APN instead of rejecting PDP context requests. unless there is already an existing PDP context to the same APN for the MS, in which case, the SGSN shall reject PDP context request

5.3.6.4 SGSN control of overload

The SGSN contains mechanisms for avoiding and handling overload situations. In an overload situation the SGSN can request the RNC to reduce any kind of signalling traffic as specified in TS 25.413 [56b].

In addition, the SGSN can request the BSC/RNC to reject the RR(C) connection establishments from MSs that access the network with low access priority that its connected BSCs/RNCs are generating on it.

A BSC/RNC supports rejecting of RR(C) connection establishments from MSs that access the network with low access priority. When rejecting an RR(C) connection request for overload reasons the BSC/RNC indicates to the MSs an appropriate timer value that limits further RR(C) connection requests.

If the network is operating in Network Mode of Operation II, then (because at a common LA/RA boundary Location Area Updates are initiated before Routeing Area updates) MSs will often initiate signalling connections towards the SGSN while in RRC connected state. If the SGSN has indicated an overload situation to the RNC, then the RNC can use the Signalling Connection Release message to avoid establishing the signalling connection with the SGSN.

Additionally, a BSC/RNC provides support for the barring of MSs configured for Extended Access Barring, as described in TS 22.011 [112]. These mechanisms are further specified in TS 48.016 [20] and TS 44.018 [85] for GERAN, TS 25.331 [52] for UTRAN.

A BSC/RNC may initiate Extended Access Barring when:

– all the SGSNs (and all the MSCs) connected to a BSC/RNC request to restrict the load for MSs that access the network with low access priority; or

– requested by O&M.

If a SGSN requests a BSC/RNC to restrict the load for MSs that access the network with low access priority, the SGSN should select all the BSCs/RNCs with which the SGSN has Gb/Iu interface connections (so that Extended Access Barring can be triggered if all SGSNs within a pool area are experiencing the same overload situation). Alternatively, the selected BSCs/RNCs may be limited to a subset of the BSCs/RNCs with which the SGSN has Gb/Iu interface connections (e.g. particular location area or where MSs of the targeted type are registered).

For GERAN, subsequent initial access attempts by a previously barred MS through Extended Access Barring is described in TS 44.018 [85].

In addition, to protect the network from overload the SGSN has the option of rejecting NAS request messages which include the low access priority indicator before rejecting NAS request messages without the low access priority indicator (see clause 5.3.6.2 for more information).

NOTE: It cannot be guaranteed that voice services will be available for mobile terminated calls while the Mobility Management back-off timer is running. It is recommended, that MS’s requiring voice services are not configured for low access priority.

5.3.6.5 S4-SGSN control of overload

Under unusual circumstances (e.g. when the S4-SGSN load exceeds an operator configured threshold), the S4-SGSN may restrict the signalling load that its SGWs are generating on it, if configured to do so.

The S4-SGSN can reject Downlink Data Notification requests for low priority traffic for UEs in idle mode or to further offload the S4-SGSN, the S4-SGSN can request the SGWs to selectively reduce the number of Downlink Data Notification requests it sends for downlink low priority traffic received for UEs in idle mode according to a throttling factor and for a throttling delay specified in the Downlink Data Notification Ack message.

SGW and S4-SGSN determine whether a bearer is for low priority traffic or not on the basis of the bearer’s ARP priority level and operator policy (i.e. operator’s configuration in the SGW and S4-SGSN of the ARP priority levels to be considered as priority or non- priority traffic). The S4-SGSN determines whether a Downlink Data Notification request is for low priority traffic or not on the basis of the ARP priority level that was received from the SGW and operator policy.

If ISR is not active for the UE, during the throttling delay, the SGW drops downlink packets received on all its low priority bearers for UEs known as not user plane connected (i.e. the SGW context data indicates no downlink user plane TEID) served by that S4-SGSN in proportion to the throttling factor, and sends a Downlink Data Notification message to the S4-SGSN only for the non throttled bearers.

If ISR is active for the UE, during the throttling delay, the SGW does not send DDN to the S4-SGSN and only sends the DDN to the MME. If both MME and SGSN are requesting load reduction, the SGW drops downlink packets received on all its low priority bearers for UEs known as not user plane connected (i.e. the SGW context data indicates no downlink user plane TEID) in proportion to the throttling factors.

The SGW resumes normal operations at the expiry of the throttling delay. The last received value of the throttling factor and throttling delay supersedes any previous values received from that S4-SGSN. The reception of a throttling delay restarts the SGW timer associated with that S4-SGSN.

5.3.6.6 Throttling of NIDD Submit Requests

Under unusual circumstances (e.g. when the SGSN load exceeds an operator configured threshold), the SGSN may restrict NIDD Submit Request messages that its SCEFs are generating on it, if configured to do so.

5.3.7 Selection functions

5.3.7.1 SGW/PGW/GGSN selection function (3GPP accesses)

The SGSN supporting both S4 and Gn/Gp shall support selection of SGW/PGW and GGSN.

The Gn/Gp SGSN shall support selection of GGSN and may optionally support selection of PGW.

For a given UE, the SGSN shall select the same GGSN/PGW for all the PDP contexts belonging to the same APN.

At PDP Context activation, in addition to network local policy, it shall be possible for SGSN to use:

– the UE capability (as indicated in the MS Network Capability);

– subscription restriction to use NR as secondary RAT;

– the configuration about the roaming agreement for E-UTRAN with the HPLMN of the UE; and

– the UE Usage Type if DCNs are deployed in the network,

as input to select GGSN, or a SGW and PGW.

It shall be possible to configure the selection function on the SGSN to give priority towards SGW/PGW for E-UTRAN capable UEs, and GGSN for non E-UTRAN capable UE.

It shall also be possible to configure the selection function on the SGSN to select GGSN/PGW using Gp when there is no roaming agreement for E-UTRAN with the HPLMN of the UE.

NOTE: EPS-based mobility to non-3GPP accesses is only possible if the SGSN selects a PDN GW.

The S4-SGSN supporting GTP-C Load Control feature performs enhanced PDN GW selection as described in the clause 4.3.8.1 of TS 23.401 [89].

5.3.7.2 Serving GW selection function

The Serving GW selection function is described in the clause "Serving GW selection function" of TS 23.401 [89].

5.3.7.3 SGSN selection function

The SGSN selection function selects an available SGSN to serve a UE. The selection is based on network topology, i.e. the selected SGSN serves the UE’s location and in case of overlapping SGSN service areas, the selection may prefer SGSNs with service areas that reduce the probability of changing the SGSN. Other criteria for SGSN selection may be load balancing between SGSNs. In networks that deploy dedicated MMEs/SGSNs, e.g. for UEs configured for low access priority, the possible target SGSN selected by source MME/SGSN is typically restricted to SGSNs with the same dedication.

When a MME/SGSN supporting DCNs selects a target SGSN, the selected target SGSN is restricted to SGSNs that belong to the same DCN. The DNS procedure may be used by the source CN node to select the target SGSN from a given DCN. If both low access priority and UE Usage Type parameter are used for SGSN selection, selection based on UE Usage type parameter overrides selection based on the low access priority indication.

When selecting an SGSN for an MS that is accessing for the purpose of utilizing EC-GSM-IoT (see TS 43.064 [11]), the SGSN selection function in the BSC shall select an SGSN taking into account the SGSN’s support (or non-support) for CIoT GSM Optimization.

5.3.8 IMS voice over PS Session Supported Indication

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 [121] with a bearer that supports Conversational Voice as specified in TS 23.203 [88], 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 [80]);

– 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 [121] with a bearer that supports Conversational Voice as specified in TS 23.203 [88] 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

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 [121] with bearer that supports Conversational Voice as specified in TS 23.203 [88] 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

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.

NOTE: The support of the Closed Subscriber Group functions is optional for an UTRAN MS.

5.3.10 UE Reachability function

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

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

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 [88]. The information can also be made available on the Gi interface as specified in TS 29.061 [27] and on the CDRs at the GGSN/PDN GW as specified in TS 32.251 [70].

5.3.12 Selected IP Traffic Offload (SIPTO) function

5.3.12.1 SIPTO with GW Selection

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 [89] 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.

NOTE: If the above procedure for GW relocation is initiated while the UE has active applications, it may cause disruption of services that are affected if the IP address changes.

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

5.3.12.1A.1 General

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 [89] 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

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 [100] 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 [56b]. 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

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 [56b].

5.3.12.2 Support for SIPTO at Iu-ps

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)

5.3.13.1 General

This clause provides an overview about functionality for Machine Type Communications according to service requirements described in TS 22.368 [110]. 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 [110], 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

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.

a) 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.

b) 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 [85]).

Clause 5.3.13.3 describes when low access priority is not applicable.

c) RRC signalling has the capability of providing ‘extended wait timers’ when rejecting messages.

d) 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.

e) 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.

f) MSs configured with a long minimum periodic PLMN search time limit (see TS 24.368 [111]) 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.

g) At PLMN change, MSs configured to perform Attach with IMSI at PLMN change (see TS 24.368 [111]) 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.

h) For mobile originated services, MSs configured for low access priority (see TS 24.368 [111]) 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.

i) 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).

j) 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 [89]).

k) 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.

l) Mechanisms that permit the GGSN/P-GW to handle per-APN congestion (see clause 5.3.6.3 and TS 23.401 [89]).

m) 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).

n) 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 [73]).

o) 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 [111]) 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.

p) 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.

q) 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.

r) 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 [112].

5.3.13.3 MS configuration and usage of indicators

A subscriber can by agreement with its operator be required to use MSs that are configured (see TS 24.368 [111]) 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.

NOTE 2: The low access priority indicator in NAS signalling and the corresponding low access priority for RR(C) connection establishment are used by the network to decide whether to accept the NAS request or the setup of the RR(C) connection, respectively.

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 [85], TS 44.060 [77], TS 25.331 [52] and TS 22.011 [112];

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 [13].

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.

NOTE 4: In this release there is no other usage of storing the low access priority indicator in EPS/PDP Bearer contexts other than for the purpose to include it in charging records. Particularly, the low access priority indicator in EPS/PDP Bearer contexts is not used by the network to make overload control decisions.

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

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

An MS may be configured for low access priority and Extended Access Barring as defined in TS 22.011 [112]. 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

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 [119].

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 [89]).

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

5.3.13.8.1 General

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 [89].

– Delivery using SCEF as defined in TS 23.682 [119].

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

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

5.3.13.8.3.1 General

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

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 [119].

5.3.13.8.3.3 Gi/SGi based delivery

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 [89].

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 [89].

NOTE: The pre-configuration can be done in the GGSN/PDN-GW per APN or based on other criterion such as SLA between operator and 3rd party application service provider, etc.

5.3.13.9 Introduction of CIoT GSM Optimisation

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 [119]);

– APN Rate Control (see clause 15.2.3.2).

5.3.13.10 Restriction of use of Enhanced Coverage

Support of MSs in Enhanced Coverage is specified in TS 43.064 [11].

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

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 [89] 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 [56b].

5.3.15 Voice domain preference and UE’s usage setting

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 [80]). 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 [80]).

NOTE: Depending on operator’s configuration, the UE’s usage setting and voice domain preference for E-UTRAN can be used by the network to choose the RFSP Index in use (see clause 5.3.5). As an example, this enables the enforcement of selective idle mode camping over GERAN/UTRAN for voice centric UEs relying on CS Fallback for voice support in E-UTRAN.

5.13.16 Support for Application / Service Layer Rate Adaptation

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

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

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 [119].

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

a) Presence of the MSISDN in the HLR/HSS subscription is optional.

b) The presence of the MSISDN in the SGSN MM context, PDP contexts and GGSN PDP contexts is dictated by its storage in HLR/HSS.

c) GTP support for MSISDN optionality whereby MSISDN is included only if available.

d) When the MSISDN is not available for CDR generation in the PS domain, the IMSI shall be used for CDR generation purposes.

e) Delivery of SMS destined to an MS without MSISDN.

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

a) CAMEL Services.

NOTE: There may be additional problems with the following services: I-WLAN, SMS, IMS, LCS, MNP, Presence Services, MBMS, GUP, Charging, Remote Device Management and Over-the-Air configuration.

5.3.18 PS-only Service Provision and PS domain SMS support

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.

NOTE 2: In earlier Releases, CS is considered as primary domain and PS optional and related UEs may try to always get CS registration. The SGSN should not request "SMS in SGSN Required" for UEs that assume a need for being always also CS attached when PS attached.

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

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 [80] and TS 23.008 [79]).

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

A MS may adopt a PSM that is described in TS 23.682 [119]. 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 [119]. 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.

NOTE 1: When the PSM is activated the MS might not be available for paging of Mobile Terminated CS services even though the MS is registered in the CS domain.

NOTE 2: The Attach and RAU procedures of this specification are not showing the details of the Periodic RAU Time and Active Time negotiation, i.e. are not showing the related IEs.

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 [13]. 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

As described in TS 36.300 [122], TS 36.331 [37], TS 25.304 [51b] and TS 25.331 [52], UTRAN and E-UTRAN may provide RAN assistance parameters to the UE via RRC signalling. TS 23.401 [89] 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 [51b] 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 [89] 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 [51b] are not applicable to non-seamless WLAN offload (see TS 23.402 [90] for the definition of non-seamless WLAN offload).

5.3.22 User plane congestion management function

See clause 4.3.24 of TS 23.401 [89].

5.3.23 Dedicated Core Networks (DCNs)

5.3.23.1 General

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 [89]. Specific impacts to supporting DCNs for UTRAN and GERAN accesses are captured in this specification and in TS 23.236 [73].

5.3.24 Support for Monitoring Events

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 [119]. Monitoring Events feature for Gn/Gp SGSN isn’t supported.

5.3.25 3GPP PS Data Off

5.3.25.1 General

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

3GPP PS Data Off feature specified in TS 23.401 [89] 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 [80], 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.

NOTE 1: When the MS detects that the PGW/GGSN does not support 3GPP PS Data Off feature, how the MS reacts to non-exempt MT requests from the network is implementation dependent.

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 [88].

NOTE 2: For the PDN connection used for IMS services, the 3GPP Data Off Exempt Services are enforced in the IMS domain as specified TS 23.228 [123]. Policies configured in the PGW/GGSN/PCRF need to ensure those services are always allowed when the 3GPP PS Data Off status of the MS is set to "activated".