Content for TS 23.401 Word version: 19.0.0

1… 4… 4.2.2… 4.3… 4.3.6… 4.3.8… 4.3.12… 4.3.16… 4.3.20… 4.3.25… 4.4… 4.6… 4.7… 5… 5.1.2… 5.3… 5.3.2… 5.3.3… 5.3.3.2 5.3.3.3… 5.3.4… 5.3.4B… 5.3.5… 5.3.8… 5.3.9… 5.4… 5.4.4… 5.5… 5.5.1.2… 5.5.2… 5.5.2.2… 5.5.2.3… 5.5.2.4… 5.6… 5.7.3… 5.7A… 5.10 5.11… 5.19… D… D.3… D.3.4 D.3.5 D.3.6 D.3.7… D.3.8… E F… J… K… L… M…

4.3.6 Radio Resource Management functions 4.3.7 Network management functions
...

4.3.6 Radio Resource Management functions p. 36

Radio resource management functions are concerned with the allocation and maintenance of radio communication paths, and are performed by the radio access network. RRM includes both idle mode and connected mode. The RRM strategy in E-UTRAN may be based on user specific information.

To support radio resource management in E-UTRAN the MME provides the parameter 'Index to RAT/Frequency Selection Priority' (RFSP Index) to an eNodeB across S1. The RFSP Index is mapped by the eNodeB 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 by the E-UTRAN:

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.

To provide additional support to radio resource management in E-UTRAN, the MME may provide the parameter 'Additional RRM Policy Index' (ARPI) to an eNodeB across S1. The ARPI is mapped by the eNodeB to locally defined configuration in order to apply specific RRM strategies.

An example of how this parameter may be used by the E-UTRAN is:

to prioritise the allocation of RAN resources to the set of UEs with the same ARPI.

The Serving PLMN can use the ARPI to carry information that is independent to the Reference SPID values documented in Informative Annex I of TS 36.300.

The MME receives the subscribed RFSP Index and subscribed ARPI from the HSS (e.g., during the Attach procedure). For non-roaming subscribers the MME chooses the RFSP Index and ARPI 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 MME 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 MME, including UE's usage setting and voice domain preference for E-UTRAN, if received during Attach and Tracking Area Update procedures (see clause 4.3.5.9).

NOTE:
One example of how the MME 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 occurrancy 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.
the ARPI In Use is identical to the subscribed ARPI, or
the MME chooses the ARPI in use based on the subscribed ARPI, the locally configured operator's policies and the UE related context information available at the MME.

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

The MME forwards the RFSP Index and ARPI in use to the eNodeB across S1. The RFSP Index and ARPI in use is also forwarded from source eNodeB to target eNodeB when X2 is used for intra-E-UTRAN handover, UE context retrieval, or, Dual Connectivity with a secondary RAN node.

The MME stores the subscribed RFSP Index and ARPI values received from the HSS and the RFSP Index and ARPI values in use. During the Tracking Area Update procedure, the MME may update the RFSP Index/ARPI value in use (e.g. the MME may need to update the RFSP Index/ARPI value in use if the UE related context information in the MME has changed). When the RFSP Index/ARPI value in use is changed, the MME immediately provides the updated RFSP Index/ARPI value in use to eNodeB by modifying an existing UE context or by establishing an new UE context in the eNodeB or by being configured to include the updated RFSP Index/ARPI value in use in the DOWNLINK NAS TRANSPORT message if the user plane establishment is not needed. During inter-MME mobility procedures, the source MME forwards both RFSP Index values and both ARPI values to the target MME. The target MME may replace the received RFSP Index and ARPI values in use with a new RFSP Index value in use or new ARPI value in use that is based on the operator's policies and the UE related context information available at the target MME.

The S1 messages that transfer the RFSP Index and ARPI to the eNodeB are specified in TS 36.413. Refer to TS 36.300 for further information on E-UTRAN.

To support a RAN with a mixture of RAN nodes that support and do not support the ARPI, the MME sends the ARPI In Use in the S1 interface PATCH SWITCH ACKNOWLEDGEMENT and HANDOVER REQUEST messages.

4.3.7 Network management functions p. 37

4.3.7.1 General p. 37

Network management functions provide mechanisms to support O&M functions related to the Evolved Packet System.

4.3.7.1a GTP-C signalling based Load and Overload Control |R12| p. 37

4.3.7.1a.1 GTP-C Load Control p. 37

GTP-C Load Control feature is an optional feature which allows a GTP control plane node to send its Load Control Information to a peer GTP control plane node which the receiving GTP control plane peer node uses to augment existing GW selection procedure (i.e. as described in "PDN-GW Selection" and "Serving-GW Selection" according to clauses 4.3.8.1, and 4.3.8.2 respectively). Load Control Information reflects the operating status of the resources of the originating GTP control plane node.

Where certain pre-condition as described in clause 12.2.4.1 of TS 29.274, is applicable, an optional feature APN level load control may be supported and activated in the network. If this feature is activated, the PDN-GW may convey the Load Control Information at APN level (reflecting the operating status of the resources at the APN level), besides at node level.

GTP-C Load Control feature allows the Serving-GW to send its Load Control Information to the MME/SGSN.

GTP-C Load Control feature also allows the PDN-GW to send its Load Control Information to the MME/SGSN via a Serving-GW.

Upon receiving Load Control Information the MME/SGSN supporting GTP-C Load Control feature uses it according to clauses 4.3.8.1, and 4.3.8.2 for "PDN-GW Selection" and "Serving-GW Selection" respectively.

A node supporting GTP-C Load Control feature sends Load Control Information in any GTP control plane request or response message such that exchange of Load Control Information does not trigger extra signalling.

A node supporting GTP-C Load Control feature sends Load Control Information to a peer GTP control node based on whether local configuration allows for it.

A node supporting GTP-C Load Control feature may decide to send different values of Load Control Information on inter-network (roaming) and on intra-network (non-roaming) interfaces based on local configuration.

Local configuration may allow the VPLMN to decide whether or not to act upon Load Control Information sent from a peer GTP control plane node in the HPLMN.

4.3.7.1a.2 GTP-C Overload Control p. 38

GTP-C Overload Control feature is an optional feature. Nodes using GTP control plane signalling may support communication of Overload Control Information in order to mitigate overload situation for the overloaded node through actions taken by the peer node(s). This feature is supported over S4, S11, S5 and S8 interfaces via GTPv2 control plane protocol.

A GTP-C node is considered to be in overload when it is operating over its nominal capacity resulting in diminished performance (including impacts to handling of incoming and outgoing traffic). Overload Control Information reflects an indication of when the originating node has reached such situation. This information, when transmitted between GTP-C nodes may be used to reduce and/or throttle the amount of GTP-C signalling traffic between these nodes. As such, the Overload Control Information provides guidance to the receiving node to decide actions which leads to mitigation towards the sender of the information.

The Overload Control Information may convey information regarding the node itself and/or regarding specific APN(s) status. In order to mitigate overload,

it shall be possible to signal control information about the overload of a GTP-C node (e.g. S-GW, P-GW);
the PDN-GW may detect overload for certain APNs, e.g. based on Diameter overload indication received from a PCRF or from an external AAA server, or e.g. based on shortage of resources for an APN (IP address pool). It shall be possible to signal appropriate control information about the APN status in addition to the mechanism described in clause 4.3.7.5.

For a given APN, the PDN-GW shall either activate the congestion control by conveying the Overload Control Information at APN level or by conveying the "PDN-GW back-off time" (as specified in clause 4.3.7.5), but not both at the same time, as specified in more detail in clause 12.3.8 of TS 29.274.

GTP-C Overload Control feature allows the MME/SGSN to send its Overload Control Information to the PDN-GW via Serving-GW.

GTP-C Overload Control feature allows the Serving-GW to send its Overload Control Information to the MME/SGSN and P-GW.

GTP-C Overload Control feature also allows the PDN-GW to send its Overload Control Information to the MME/SGSN via a Serving-GW.

GTP-C overload Control feature should continue to allow for preferential treatment of priority users (eMPS) and emergency services as per existing specifications.

An MME/SGSN may during ESM and EMM procedures apply certain restrictions towards GWs (Serving-GW and/or PDN-GW as applicable) that have indicated overload, e.g.:

reject EPS Session Management requests from the UE (e.g. PDN Connectivity, Bearer Resource Allocation or Bearer Resource Modification Requests) with a Session Management back-off timer as described in clause 4.3.7.4.2;
reject Mobility Management signalling requests from UEs (such as Attach, Detach, Service Request, Tracking Area Update) with a Mobility Management back-off timer (e.g. reject Service Request requiring to activate user plane bearers in an overloaded SGW) as described in clause 4.3.7.4.2;
reject or accept requests for data transmission via Control Plane CIoT EPS Optimisation from UEs (e.g. Control Plane Service Request and ESM Data Transport) with a Control Plane data back-off timer as described in clause 4.3.7.4.2.7;
may reduce/throttle messages towards the GWs indicating overload status;
other implementation specific mechanisms, which are outside the scope of 3GPP specifications.

A PDN-GW may take the following actions for MME/SGSN which have indicated overload:

Limit or completely block non-GBR dedicated bearer establishment;
Limit or completely block all Dedicated Bearer establishments or modification, except QCI=1 bearers;
Limit or completely block all Dedicated Bearer establishments, including the QCI=1 bearers;
other implementation specific mechanisms, which are outside the scope of 3GPP specifications.

A node supporting GTP-C Overload Control feature sends Overload Control Information in any GTP control plane request or response message such that exchange of Overload Control Information does not trigger extra signalling.

The computation and transfer of the Overload Control Information shall not add significant additional load to the node itself and to its corresponding peer nodes. The calculation of Overload Control Information should not severely impact the resource utilization of the node.

Based on local policies/configuration, a GTP-C node may support Overload Control feature and act upon or ignore Overload Control Information in the VPLMN when received from HPLMN and in the HPLMN when received from VPLMN. When this feature is supported, a GTP-C node may decide to send different values of Overload Control Information on inter-network (roaming) and on intra-network (non-roaming) interfaces based on local policies/configuration.

4.3.7.2 Load balancing between MMEs p. 39

The MME Load Balancing functionality permits UEs that are entering into an MME Pool Area to be directed to an appropriate MME in a manner that achieves load balancing between MMEs. This is achieved by setting a Weight Factor for each MME, such that the probability of the eNodeB selecting an MME is proportional to its Weight Factor. The Weight Factor is typically set according to the capacity of an MME node relative to other MME nodes. The Weight Factor is sent from the MME to the eNodeB via S1-AP messages (see TS 36.413). If a HeNB GW is deployed, the Weight Factor is sent from the MME to the HeNB GW.

In some networks, the eNodeB may be configured to select specific MME for UEs configured for low access priority with a different load balance to that used for MME selection for other UEs.

When DCNs are used, load balancing by eNodeB is only performed between MMEs that belong to the same DCN within the same MME pool area, i.e. MMEs with the same PLMN and MMEGI value. When an MME serves multiple DCNs and one DCN is supported by multiple MMEs, in order to achieve load balancing across the MMEs of the same MME pool area supporting the same DCN, each DCN supported by this MME may have its own Weight Factor (Weight Factor per DCN). The Weight Factor per DCN is set according to the capacity of an MME node for a specific DCN relative to other MME nodes' capacity for that DCN within the same MME pool area. The eNodeB is provided with per DCN Weight Factors, if any, by the connected MMEs at the set-up of the S1 connection. The DCN Load Balancing functionality permits UEs that are entering into a pool area or being re-directed to an appropriate DCN to be distributed in a manner that achieves load balancing between the CN nodes of the same DCN. The eNodeB may be configured to select MME(s) from a specific CN for UEs configured for low access priority only for the case that no other information and configuration is available for selecting an MME from a specific DCN.

4.3.7.3 Load re-balancing between MMEs p. 40

The MME Load Re-balancing functionality permits UEs that are registered on an MME (within an MME Pool Area) to be moved to another MME.

The eNodeBs may have their Load Balancing parameters adjusted beforehand (e.g. the Weight Factor is set to zero if all subscribers are to be removed from the MME, which will route new entrants to the pool area into other MMEs).

In addition the MME may off-load a cross-section of its subscribers with minimal impacts on the network and users (e.g. the MME should avoid offloading only the low activity users while retaining the high activity subscribers. Gradual rather than sudden off-loading should be performed as a sudden re-balance of large number of subscribers could overload other MMEs in the pool. With minimal impact on network and the user's experience, the subscribers should be off-loaded as soon as possible). The load re-balancing can off-load part of or all the subscribers.

To off-load ECM-CONNECTED mode UEs, the MME initiates the S1 Release procedure with release cause "load balancing TAU required" (clause 5.3.5). The S1 and RRC connections are released and the UE initiates a TAU but provides neither the S-TMSI nor the GUMMEI to eNodeB in the RRC establishment.

The MME should not release all S1 connections which are selected to be released immediately when offloading is initiated. The MME may wait until the S1 Release is performed due to inactivity. When the MME is to be offloaded completely the MME can enforce an S1 Release for all remaining UEs that were not offloaded by normal TAU procedures or by S1 releases caused by inactivity.

To off-load UEs which perform TA Updates or Attaches initiated in ECM-IDLE mode, the MME completes that procedure and the procedure ends with the MME releasing S1 with release cause "load balancing TAU required". The S1 and RRC connections are released and the UE initiates a TAU but provides neither the S-TMSI nor the GUMMEI to eNodeB in the RRC establishment.

When the UE provides neither the S-TMSI nor the GUMMEI in the RRC establishment, the eNodeB should select an MME based on the Weight Factors of the MMEs in the pool.

To off-load UEs in ECM-IDLE state without waiting for the UE to perform a TAU or perform Service request and become ECM-CONNECTED, the MME first pages UE to bring it to ECM-CONNECTED state. If paging the UE fails and ISR is activated, the MME should adjust its paging retransmission strategy (e.g. limit the number of short spaced retransmissions) to take into account the fact that the UE might be in GERAN/UTRAN coverage.

Hardware and/or software failures within an MME may reduce the MME's load handling capability. Typically such failures should result in alarms which alert the operator/O+M system. Only if the operator/O+M system is sure that there is spare capacity in the rest of the pool, the operator/O+M system might use the load re-balancing procedure to move some load off this MME. However, extreme care is needed to ensure that this load re-balancing does not overload other MMEs within the pool area (or neighbouring SGSNs) as this might lead to a much wider system failure.

When the Dedicated Core Network (DCN) feature is used, the DCN load re-balancing functionality permits UEs that are registered on an MME in the DCN (within a pool area) to be moved to another MME in the same DCN in a manner that achieves load balancing between the CN nodes of the DCN and pool area. The DCN load re-balancing is triggered by the source MME (within a DCN). The details are as follows:

If the UE is in ECM-IDLE state, the NAS Message Redirection procedure (see clause 5.19.1) is triggered at the next intra-MME Tracking Area Update Request enabling eNodeB to load balance between MMEs of the same DCN. To off-load UEs in ECM-IDLE state without waiting for the UE to perform a TAU or perform Service request, the MME first pages the UE to bring it to ECM-CONNECTED state and proceeds as described for the ECM-CONNECTED case below.
If the UE is in ECM-CONNECTED state, the MME performs the GUTI reallocation procedure, includes the unchanged GUTI of the UE and a non-broadcast TAI to induce the UE to perform a TAU procedure, and forces the UE to go to ECM-IDLE state. During the subsequent TAU procedure the MME uses the NAS Message Redirection procedure (see clause 5.19.1) to redirect the UE to another MME within the same DCN.

4.3.7.4 MME control of overload p. 41

4.3.7.4.1 General |R10| p. 41

The MME shall contain mechanisms for avoiding and handling overload situations. These can include the use of NAS signalling to reject NAS requests from UEs.

In addition, under unusual circumstances, the MME shall restrict the load that its eNodeBs are generating on it if it is configured to enable the overload restriction. This can be achieved by the MME invoking the S1 interface overload procedure (see TS 36.300 and TS 36.413) to all or to a proportion of the eNodeB's with which the MME has S1 interface connections. To reflect the amount of load that the MME wishes to reduce, the MME can adjust the proportion of eNodeBs which are sent S1 interface OVERLOAD START message, and the content of the OVERLOAD START message.

The MME should select the eNodeBs at random (so that if two MMEs within a pool area are overloaded, they do not both send OVERLOAD START messages to exactly the same set of eNodeBs).

The MME may optionally include a Traffic Load Reduction Indication in the OVERLOAD START message. In this case the eNodeB shall, if supported, reduce the type of traffic indicated according the requested percentage (see TS 36.413).

An MME supporting Control Plane CIoT EPS Optimisation may include an indication in the OVERLOAD START message indicating overload from data transfers via Control Plane CIoT EPS Optimisation.

Using the OVERLOAD START message, the MME can request the eNodeB to:

reject RRC connection requests that are for non-emergency, non-exception reporting and non-high priority mobile originated services; or

NOTE 2:
This blocks PS service and service provided by MSC following an EPS/IMSI attach procedure.
reject new RRC connection requests for EPS Mobility Management signalling (e.g. for TA Updates) for that MME;
only permit RRC connection requests for emergency sessions and mobile terminated services for that MME. This blocks emergency session requests from UEs with USIMs provisioned with Access Classes 11 and 15 when they are in their HPLMN/EHPLMN and from UEs with USIMs provisioned with Access Classes 12, 13 and 14 when they are in their home country (defined as the MCC part of the IMSI, see TS 22.011); or.

NOTE 3:
The MME can restrict the number of responses to paging by not sending paging messages for a proportion of the events that initiate paging. As part of this process, the MME can provide preference for paging UEs with Emergency Bearer Services and terminations associated with MPS ARP.
only permit RRC connection requests for high priority sessions, exception reporting and mobile terminated services for that MME;
reject new RRC connection requests from UEs that access the network with low access priority;
not accept RRC connection requests with RRC establishment cause "mo-data" or "delayTolerantAccess" from UEs that only support Control Plane CIoT EPS Optimisation.

NOTE 4:
The RRC connection requests listed in this clause also include the request for RRC Connection Resume.

When rejecting an RRC connection request for overload reasons the eNodeB indicates to the UE an appropriate timer value that limits further RRC connection requests for a while.

An eNodeB supports rejecting of RRC connection establishments for certain UEs as specified in TS 36.331. Additionally, an eNodeB provides support for the barring of UEs configured for Extended Access Barring, as described in TS 22.011. These mechanisms are further specified in TS 36.331. If the UE is camping on NB-IoT, Extended Access Barring does not apply.

An eNodeB may initiate Extended Access Barring when:

all the MMEs connected to this eNodeB request to restrict the load for UEs that access the network with low access priority; or
requested by O&M.

If an MME invokes the S1 interface overload procedure to restrict the load for UEs that access the network with low access priority, the MME should select all eNodeBs with which the MME has S1 interface connections. Alternatively, the selected eNodeBs may be limited to a subset of the eNodeBs with which the MME has S1 interface connection (e.g. particular location area or where devices of the targeted type are registered).

During an overload situation the MME should attempt to maintain support for emergency bearer services (see clause 4.3.12) and for MPS (see clause 4.3.18).

When the MME is recovering, the MME can either:

send OVERLOAD START messages with new percentage value that permit more traffic to be carried, or
the MME sends OVERLOAD STOP messages.

to some, or all, of the eNodeB(s).

In addition, to protect the network from overload the MME 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 4.3.7.4.2 for more information).

In addition, for UEs that don't support the Service Gap Control feature (see clause 4.3.17.9), the MME may use "General NAS level Mobility Management control" as defined in clause 4.3.7.4.2.1.

4.3.7.4.1a Throttling of Downlink Data Notification Requests |R10| p. 42

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

The MME can reject Downlink Data Notification requests for non-priority traffic for UEs in idle mode or to further offload the MME, the MME can request the SGWs to selectively reduce the number of Downlink Data Notification requests it sends for downlink non-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.

The SGW determines whether a bearer is to be subjected to the throttling of Downlink Data Notification Requests on the basis of the bearer's ARP priority level and operator policy (i.e. operator's configuration in the SGW of the ARP priority levels to be considered as priority or non- priority traffic). While throttling, the SGW shall throttle the Downlink Data Notification Requests for low and normal priority bearers by their priority. The MME determines whether a Downlink Data Notification request is priority or non-priority traffic 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 non-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 MME in proportion to the throttling factor, and sends a Downlink Data Notification message to the MME 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 MME and only sends the DDN to the SGSN. If both MME and SGSN are requesting load reduction, the SGW drops downlink packets received on all its non-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 MME. The reception of a throttling delay restarts the SGW timer associated with that MME.

4.3.7.4.1b Throttling of NIDD Submit Requests |R13| p. 43

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

4.3.7.4.2 NAS level congestion control |R10| p. 43

4.3.7.4.2.1 General p. 43

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

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

The MME 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 EPS bearers per APN;
Maximum rate of EPS Bearer activations per APN;
One or multiple PDN-GWs of an APN are not reachable or indicated congestion to the MME;
Maximum rate of MM signalling requests associated with the devices with a particular subscribed APN; and/or
Setting in network management.

The MME may detect the NAS signalling congestion associated with the UEs belonging to a particular group. The MME may start and stop performing the group specific NAS level 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 MME may detect the NAS signalling congestion associated with the UEs that belong to a particular group and are subscribed to a particular APN. The MME may start and stop performing the APN and group specific NAS level congestion control based on criteria such as:

Maximum number of active EPS bearers 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 MME should not apply NAS level congestion control for high priority access and emergency services.

With General NAS level Mobility Management control, the MME 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 MME serving multiple DCNs.

In addition, for UEs that don't support the Service Gap Control feature (see clause 4.3.17.9), the MME may return a Mobility Management back-off timer to the UE in responses to requests where the intention is to send MO data or re-attach with PDN connectivity when the Service gap timer for the UE is running at the MME.

4.3.7.4.2.2 APN based Session Management congestion control p. 43

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

The MME may reject the EPS Session Management (ESM) requests from the UE (e.g. PDN Connectivity, or Bearer Resource Allocation Requests) with a Session Management back-off timer when ESM congestion associated with the APN is detected. If the UE provides no APN, then the MME uses the APN which is used in PDN-GW selection procedure.

The MME may deactivate PDN connections belonging to a congested APN by sending the NAS Deactivate EPS Bearer Context Request message to the UE with a Session Management back-off timer. If Session Management back-off timer is set in the NAS Deactivate EPS Bearer Context Request message then the cause "reactivation requested" should not be set.

The MME may store a Session Management back-off time per UE and APN when congestion control is active for an APN if a request without the low access priority indicator is rejected by the MME. The MME may immediately reject any subsequent request from the UE targeting to the APN before the stored Session Management back-off time is expired. If the MME stores the Session Management back-off time per UE and APN and the MME decides to send a Session Management Request message to a UE connected to the congested APN (e.g. due to decreased congestion situation), the MME shall clear the Session Management back-off time prior to sending any Session Management Request message to the UE.

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

If APN is provided in the rejected EPS Session Management Request message or if the Session Management back-off timer is received in the NAS Deactivate EPS Bearer Context Request message, the UE shall not initiate any Session Management procedures for the congested APN. The UE may initiate Session Management procedures for other APNs.
If APN is not provided in the rejected EPS Session Management Request message, the UE shall not initiate any Session Management requests of any PDN type without APN. The UE may initiate Session Management procedures for specific APN.
Cell/TA/PLMN/RAT change do not stop the Session Management back-off timer.
The UE is allowed to initiate the Session Management procedures for high priority access and emergency services even when the Session Management back-off timer is running.
The UE is allowed to initiate Bearer Resource Modification procedure to report 3GPP PS Data Off status change when the EPS Session Management back off timer is running.
If the UE receives a network initiated EPS Session Management Request message for the congested APN while the Session Management back-off timer is running, the UE shall stop the Session Management back-off timer associated with this APN and respond to the MME.
If the UE 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 the UE may request the initiation of Session Management procedures without low access priority.

The UE is allowed to initiate PDN disconnection procedure (e.g. sending PDN Disconnection Request) when the EPS Session Management back off timer is running.

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

To avoid that large amounts of UEs initiate deferred requests (almost) simultaneously, the MME 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 ESM signalling initiated from the UE in the control plane. The Session Management congestion control does not prevent the UE to send and receive data or initiate Service Request procedures for activating user plane bearers towards the APN(s) that are under ESM congestion control.

4.3.7.4.2.3 APN based Mobility Management congestion control p. 44

The MME may perform the APN based congestion control for UEs with a particular subscribed APN by rejecting Attach procedures with a Mobility Management back-off timer.

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

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

After rejecting Attach Requests, the MME should keep the Subscriber Data for some time. This allows for rejection of subsequent requests without HSS signalling when the congestion situation resulting from UEs with a particular subscribed APN persists.

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 the Mobility Management procedures for high priority access and emergency services even when the Mobility Management back-off timer is running. While the Mobility Management back-off timer is running, the UE is allowed to perform Tracking Area Update if it is already in connected mode.

While the Mobility Management back-off timer is running, the UE configured with a permission for overriding low access priority is allowed to initiate the 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 the UE request to activate a PDN connection without low access priority or the UE has an activated PDN connection that is not with low access priority.

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

4.3.7.4.2.4 General NAS level Mobility Management congestion control p. 45

Under general overload conditions the MME may reject Mobility Management signalling requests from UEs. When a NAS request is rejected, a Mobility Management back-off timer may be sent by the MME and MME may store the back-off time per UE if a request without the low access priority indicator is rejected by the MME and if MME maintains the UE context. The MME may immediately reject any subsequent request from the UE before the stored back-off time is expired. While the Mobility Management back-off timer is running, the UE shall not initiate any NAS request for Mobility Management procedures except for Detach procedure and except for high priority access, emergency services and mobile terminated services. After any such Detach procedure, the back-off timer continues to run. While the Mobility Management back-off timer is running, the UE is allowed to perform Tracking Area Update if it is already in connected mode. If the UE receives a paging request from the MME while the Mobility Management back off timer is running, the UE shall stop the Mobility Management back-off timer and initiate the Service Request procedure or the Tracking Area Update procedure as described in clause 5.3.3.0.

While the Mobility Management back-off timer is running, the UE configured with a permission for overriding low access priority is allowed to initiate the 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 UE request to establish a PDN connection without low access priority or the UE has an established PDN connection that is without low access priority.

While the Mobility Management back-off timer is running, the UE configured with permission for sending exception reporting is allowed to initiate the Control Plane Service Request procedure for exception reporting. If the Mobility Management back-off timer was started due to a reject message received in response to a request for exception reporting, the UE shall not initiate the Control Plane Service Request procedure for exception reporting while the Mobility Management back-off timer is running.

The Mobility Management back-off timer shall not impact Cell/RAT and PLMN change. Cell/RAT and TA 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.301 when a new PLMN that is not an equivalent PLMN is accessed.

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

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

The MME should not reject Tracking Area Update procedures that are performed when the UE is already in connected mode.

For idle mode inter CN node mobility, the MME may reject Tracking Area Update procedures and include a Mobility Management back off timer value in the Tracking Area Reject message.

If the MME rejects Tracking Area Update request or Service request with a Mobility Management back-off timer which is larger than the sum of the UE's periodic TAU timer plus the Implicit Detach timer, the MME should adjust the mobile reachable timer and/or Implicit Detach timer such that the MME does not implicitly detach the UE while the Mobility Management back-off timer is running.

4.3.7.4.2.5 Group specific NAS level congestion control p. 46

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

A UE belongs to a group, if the corresponding group identifier is stored in the UE's subscription data in the HSS. A UE may belong to multiple groups and the MME may perform the Group specific NAS level congestion control to an UE as described below independent of whether Group specific NAS level congestion control is activated for one, multiple, or all groups the UE belongs to. The group identifier shall be stored per UE in the HSS and obtained by the MME as part of normal HSS signalling. A UE 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 MME's behaviour is similar to that in clause 4.3.7.4.2.2, with the following modifications:

MME may apply ESM congestion control to all subscribed APNs for UEs that belong to this particular group.

NOTE:
How the MME applies ESM congestion control to all subscribed APNs is left to Stage 3.
The MME rejects the EPS Session Management (ESM) request(s) from the UE belonging to this particular group (e.g. PDN Connectivity, or Bearer Resource Allocation 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, the MME's behaviour is similar to that in clause 4.3.7.4.2.3, but applied to UEs subscribed to this particular group rather that subscribed to a particular APN.

Group specific NAS level congestion control is performed at the MME based on the UE's subscription information provided by the HSS. There is no impact on the UE, and hence, UE's behaviour as described in clauses 4.3.7.4.2.2 and 4.3.7.4.2.3 does not change.

4.3.7.4.2.6 APN and group specific NAS level congestion control p. 46

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

A UE may belong to multiple groups and the MME may perform the APN and group specific NAS level congestion control to an UE as described below independent of whether the APN and group specific NAS level congestion control is activated for one, multiple or all groups the UE belongs to. The group identifier(s) shall be stored per UE in the HSS and obtained by the MME as part of normal HSS signalling. A UE 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 UE belonging to a particular group and initiating signalling to a particular APN, the MME's behaviour is similar to that in clause 4.3.7.4.2.2, with the following modifications:

The EPS Session Management (ESM) congestion control is applied to this particular APN, and for UEs belonging to this particular group,
The MME may reject ESM requests from the UEs belonging to this particular group and attaching to this particular APN (e.g. PDN Connectivity, or Bearer Resource Allocation Requests) with a Session Management back-off timer. If the UE provides no APN, then the MME uses the APN which is used in PDN-GW selection procedure.
The MME may deactivate PDN connections of the UEs, belonging to this particular group and attaching to this particular APN, by sending the NAS Deactivate EPS Bearer Context Request message to the UE with a Session Management back-off timer.

When the APN and group specific NAS level congestion control for Mobility Management signalling is activated for a UE belonging to a particular group and with a particular subscribed APN, the MME's behaviour is similar to that in clause 4.3.7.4.2.3, but applied to UEs with this particular subscribed APN and belonging to this particular group.

APN and group specific NAS level congestion control is performed at the MME based on the UE's subscription information provided by the HSS. There is no impact on the UE, and hence, UE's behaviour described in clauses 4.3.7.4.2.2 and 4.3.7.4.2.3 does not change.

4.3.7.4.2.7 Control Plane data specific NAS level congestion control p. 47

Under overload conditions the MME may restrict requests from UEs for data transmission via Control Plane CIoT EPS Optimisation. A Control Plane data back-off timer may be returned by the MME (e.g.in Attach/TAU/RAU Accept messages, Service Reject message or Service Accept message). While the Control Plane data back-off timer is running, the UE shall not initiate any data transfer via Control Plane CIoT EPS Optimisation, i.e. the UE shall not send any Control Plane Service Request with ESM Data Transport message as defined in TS 24.301. The MME shall store the Control Plane data back-off timer per UE and shall reject any further request (other than exception reporting and a response to paging) for data transmission via Control Plane Service Request from that UE while the Control Plane data back-off timer is still running.

If the UE is allowed to send exception reporting, the UE may initiate Control Plane Service Request for exception reporting even if Control Plane data back-off timer is running.

The UE may respond with Control Plane Service Request without ESM Data Transport to a paging even if the Control Plane data back-off timer is running.

If the MME receives a Control Plane Service Request in reponse to paging, and the MME has a Control Plane data back-off timer running for the UE, and the MME is not overloaded, and MME decides to accept the Control Plane Service Request, then the MME shall respond with Service Accept message without the Control Plane data back-off timer and stop the Control Plane data back-off timer. If the UE receives a Service Accept message without the Control Plane data back-off timer from the MME while the Control Plane data back-off timer is running, the UE shall stop the Control Plane data back-off timer. The Control Plane data back-off timer in the UE and the MME is stopped at PLMN change.

If the MME receives a Control Plane Service Request with ESM Data Transport message, and decides to send the UE a Control Plane data back-off timer, the MME may decide to process the Control Plane Service Request with ESM Data Transport message, i.e. decrypt and forward the data payload, or not based on the following:

If the UE has additionally indicated in a NAS Release Assistance Information in the NAS PDU that no further Uplink or Downlink Data transmissions are expected, then the MME may process (integrity check/decipher/forward) the received Control Plane data packet, and send SERVICE ACCEPT to the UE with Control Plane data back-off timer. The UE interprets this as successful transmission of the Control Plane data packet and starts the Control Plane data back-off timer.
For all other cases, the MME may decide to not process the received control plane data packet and sends SERVICE REJECT to the UE with Control Plane data back-off timer. The UE interprets this indication as unsuccessful delivery of the control plane data packet and starts the Control Plane data back-off timer. Then MME may take into consideration whether the PDN Connection is set to Control Plane only to make the decision whether to reject the packet and send SERVICE REJECT or move the PDN connection to user plane and process the data packet.
Alternatively, if UE has not provided in the in Control Plane service request the NAS Release Assistance Information, and the EPS bearer belongs to a PDN connection not set to Control Plane only, and UE supports User Plane CIoT Optimisation (or legacy S1-U), then the MME may initiate establishment of S1-U bearer during Data Transport in Control Plane CIoT EPS Optimisation (according to the procedure defined in clause 5.3.4B.4). In this case MME may also return a Control Plane data back-off timer within the NAS message.

The MME only includes the Control Plane data back-off timer if the UE has indicated support for Control Plane data back-off timer in the Attach/TAU/RAU request.

4.3.7.5 PDN-GW control of overload |R15| p. 48

The PDN-GW may provide mechanisms for avoiding and handling overload situations. These include the rejection of PDN connection requests from UEs.

The PDN-GW may detect APN congestion and start and stop performing overload control based on criteria such as:

Maximum number of active bearers per APN; and/or
Maximum rate of bearer activations per APN.

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