Section: 4.3.7.4 MME control of overload 4.3.7.4.1 General
Content: 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[ Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 ]  [5] and TS 36.413[ Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) ]  [36]) 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[ Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) ]  [36]). NOTE 1: The MME implementation may need to take into account the fact that eNodeBs compliant to Release 9 and earlier version of the specifications do not support the percentage overload indication. 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[ Service accessibility ]  [67]); 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[ Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification ]  [37]. Additionally, an eNodeB provides support for the barring of UEs configured for Extended Access Barring, as described in TS 22.011[ Service accessibility ]  [67]. These mechanisms are further specified in TS 36.331[ Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification ]  [37]. 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). NOTE 5: 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 UEs requiring voice services are not configured for low access priority. 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.