Content for  TS 23.401  Word version:  19.0.0

This clause provides an overview about functionality for Machine Type Communications according to service requirements described in TS 22.368. The specific functionality is described in the affected procedures and features of this and other specifications. For discrepancies between this overview clause and the detailed procedure and function descriptions, the latter take precedence. MTC functionality is provided by the visited and home networks when the networks are configured to support machine type communication. It applies to both the non-roaming case and the roaming case and some functionality may be dependent upon the existence of appropriate roaming agreements between the operators. Some of the MTC functions are controlled by subscriber data. Other MTC functions are based on indicators sent by the UE to the network. MTC functionality is performed by UEs that are configured to support different options as described in clause 4.3.17.4. Though motivated by scenarios and use cases defined in TS 22.368, the functions added to support MTC have general applicability and are in no way constrained to any specific scenario or use case except where explicitly stated. Unless otherwise stated in this specification, MTC functionality also applies over satellite access.

The number of MTC 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 UEs have the capability to generate normal quantities of signalling. As normal signalling from large numbers of UEs may cause overload independently whether the UE is used for MTC or not, generic functionality for overload and congestion control is required. The total signalling from large numbers of UEs is a concern in at least two situations:

• when an application (running in many UEs) requests many UEs to do "something" at the same time; and/or
• when many UEs 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.

1. Where applicable, UEs can be configured for enhancements as described in subsequent bullets Post-manufacturing configuration can be performed remotely as described in clause 4.3.17.4.
2. For mobile originated services, UEs configured for low access priority provide the E-UTRAN with information indicating that the RRC connection establishment request has low access priority (see clause 4.3.17.4). Clause 4.3.17.4 describes when low access priority is not applicable.
3. RRC signalling has the capability of providing 'extended wait timers' when rejecting messages from UEs. These 'extended wait timers' are only used by UEs that access the network with low access priority.
4. The MME can initiate rejection of RRC connection establishments in the E-UTRAN for UEs that access the network with low access priority as described in clause 4.3.7.4.1. In addition, MME signalling or O&M can trigger E-UTRAN to initiate Extended Access Barring. These mechanisms are further described in clause 4.3.7.4.1.
5. Overload messages from the MME to E-UTRAN are extended to aid the RAN in performing the functionality in bullets b, c and d above.
6. UEs configured with a long minimum periodic PLMN search time limit (see TS 24.368) have an increased minimum time in between their searches for more preferred PLMNs.
7. At PLMN change, UEs configured to perform Attach with IMSI at PLMN change (see TS 24.368) do this rather than a TA update with GUTI (thus avoiding the need to reject the TA update, and to request the IMSI following the subsequent Attach with GUTI).
8. For mobile originated services, UEs configured for low access priority (see TS 24.368) provide a low access priority indication to the MME in NAS signalling that permit the MME to undertake protective measures (e.g. to permit the MME to immediately command the UE 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 4.3.7.4.1. Clause 4.3.17.4 describes when low access priority is not applicable.
9. Using Periodic TAU timer value sent by the HSS and/or UE provided low access priority indication (bullet h above), the MME can allocate a long periodic TAU timer value to the UE. A long periodic TAU timer is likely to slow down the rate at which a UE detects a network failure and thus it slows down the rate of movement of UEs from a failed network to other local competing networks (see clause 4.3.17.3).
10. Mechanisms for the MME and P-GW to detect congestion associated with a particular APN (see clauses 4.3.7.4.2 and 4.3.7.5).
11. The addition of 'back off timers' to EMM and ESM signalling messages (e.g. to rejection messages). These include some time randomisation to guard against a repeat of a load peak. The MME should be able to apply this behaviour on a per-APN basis. as described in clause 4.3.7.4.2
12. Signalling that permits the P-GW to request the MME to generate the above ESM signalling with 'back off timers' (see clause 4.3.7.5).
13. An MME overload control mechanism to selectively limit the number of Downlink Data Notification requests the S-GW sends to the MME for downlink low priority traffic received for UEs in idle mode (see clause 4.3.7.4.1a).
14. UE configured for specific handling of the invalid USIM state, the "forbidden PLMN list", the "forbidden PLMNs for attach in S1mode list" and the "forbidden PLMNs for GPRS service list" remembers that the USIM is invalid and keeps the PLMN forbidden lists even if the UE is switched off and then switched on.
15. When the UE has an activated PDN connection without low access priority or the UE is requested to establish such a PDN connection and the UE is configured with a permission for overriding low access priority the UE doesn't provide a low access priority indication to the MME in NAS MM signalling and also not to the RAN in the RRC requests. In the NAS request for activating a PDN connection this UE always indicates what the upper layers requested, i.e. the UE indicates low access priority in that NAS request unless the upper layers request activation of a PDN connection without low access priority.
16. When the UE has an activated PDN connection that is without low access priority or the UE is requested to activate such a PDN connection and the UE is configured with a permission for overriding Extended Access Barring, then the UE ignores any Extended Access Barring (if it is activated in the network) as defined in TS 22.011.
17. The eNodeB may use the low access priority indication provided by the UE to steer UEs configured for low access priority to specific MMEs.

To reduce network load from periodic TAU signalling and to increase the time until the UE detects a potential need for changing the RAT or PLMN (e.g. due to network problems) the longer values of the periodic TAU timer and Mobile Reachable timer shall be supported. A long periodic RAU/TAU timer value may be locally configured at MME or may be stored as part of the subscription data in HSS. During Attach and TAU procedures the MME allocates the periodic RAU/TAU timer value as periodic TAU timer to the UE based on VPLMN operator policy, low access priority indication from the UE, periodic RAU/TAU timer value requested by UE, subscription information received from the HSS and Start of Unavailability Period and/or Unavailability Period Duration if using a RAN that provides discontinuous coverage (see clause 4.13.8.2). If MME receives a subscribed periodic RAU/TAU timer value from the HSS it allocates the subscribed value to the UE as periodic TAU timer. A visited PLMN MME 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 UE. If no subscribed periodic RAU/TAU timer value is received from the HSS, the MME should:

• if the periodic RAU/TAU timer value requested by UE is within the boundaries of the VPLMN operator policy, allocate the value requested by the UE;
• if the periodic RAU/TAU timer value requested by UE 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 UE is lower than allowed per the VPLMN operator policy, allocate the lowest allowed value per the VPLMN operator policy.

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

• UE configured for low access priority; and/or
• UE configured with a permission for overriding low access priority, which is only applicable for a UE that is also configured for low access priority; and/or
• UE configured to perform Attach with IMSI at PLMN change; and/or
• UE configured with a long minimum periodic PLMN search time limit; and/or
• UE configured for specific handling of the invalid USIM state, the "forbidden PLMN list", the "forbidden PLMNs for attach in S1mode list" and the "forbidden PLMNs for GPRS service list"; and/or
• UE configured for Extended Access Barring; and/or
• UE configured with a permission for overriding Extended Access Barring, which is only applicable for a UE that is also configured for Extended Access Barring.

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

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

UEs can be configured for one or more of the above options. Post-manufacturing configuration of these options in the UE can be performed only by OMA DM or (U)SIM OTA procedures. UEs capable of the above options should support configuration of these options by both OMA DM and (U)SIM OTA procedures. A UE configured for low access priority shall transmit the low access priority indicator to the MME during the appropriate NAS signalling procedures and transmit the corresponding low access priority to the E-UTRAN during RRC connection establishment procedures. 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 4.3.12). When an emergency PDN connection gets established, the MME may, based on MME configuration, initiate the deactivation of any non-emergency PDN connection using the MME requested PDN disconnection procedure described in clause 5.10.3;
• for all procedures when preferential access to the network is provided to the UE by the Access Class 11-15 mechanism according to TS 36.331 and TS 22.011 e.g. for Multimedia Priority Services as described in clause 4.3.18;
• for RRC connection establishment procedures when responding to paging;
• for a UE configured with a permission for overriding low access priority under conditions described by bullet o in clause 4.3.17.2; or
• other specific situations described in TS 24.301.

If the NAS session management request message used to establish a new PDN connection contains a low access priority indication, the MME shall forward the low access priority indication 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 to include the low access priority indicator in the charging records, the low access priority indicator should be stored in the MME EPS Bearer contexts and should be passed as part of these contexts to other SGSN/MME or S-GW nodes in mobility management procedures. A network node may invoke one or more of the following mechanisms based on the indicators received in signalling from UEs 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 4.3.17.2; and/or
• based on the low access priority for RRC connection establishment, bullets b, c and q as defined in clause 4.3.17.2.

A UE shall invoke one or more of the following mechanisms based on the configuration and capabilities of the UE:

• when UE is configured with a long minimum periodic PLMN search time limit, the UE invokes actions as described in bullet f in clause 4.3.17.2; and/or
• when UE is configured to perform Attach with IMSI at PLMN change, the UE invokes actions as described in bullet g in clause 4.3.17.2; and/or
• when a UE is configured for low access priority, the UE invokes actions as described in bullets b and h in clause 4.3.17.2; and/or
• when UE is configured for specific handling of the invalid USIM state, the "forbidden PLMN list", the "forbidden PLMNs for attach in S1mode list" and the "forbidden PLMNs for GPRS service list", the UE invokes actions as defined in bullet n in clause 4.3.17.2; and/or
• when UE is configured for Extended Access Barring, the UE invokes actions as defined in bullet d in clause 4.3.17.2; and/or
• when a UE is configured with a permission for overriding low access priority and configured with a permission for overriding Extended Access Barring, the UE invokes actions as described in bullets o) and p) in clause 4.3.17.2.

The feature is specified in clause 5.3.13.6 of TS 23.060.

Functions for High latency communication may (depending on operator configuration) be used to handle mobile terminated (MT) communication with UEs being unreachable while using power saving functions (e.g. UE Power Saving Mode (see clause 4.3.22) or extended idle mode DRX (see clause 5.13a)) or UEs that are using a satellite access with discontinuous coverage. "High latency" refers to the initial response time before normal exchange of packets is established. That is, the time it takes before a UE has woken up from its power saving state and responded to the initial downlink packet(s). The feature is described in TS 23.682. The High latency communication includes invoking extended buffering of MT data at the Serving-GW when the UE is in a power saving state and not reachable. The handling is specified in the Network Triggered Service Request procedure, clause 5.3.4.3. Establishing the user plane for delivering the buffered data when the UE contacts the MME or SGSN by signalling shall be done in the Tracking Area Update and Routing Area Update procedures. The MME/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 TAU/RAU procedures with MME/SGSN change, the old MME/SGSN shall indicate in the context response to the new MME/SGSN that buffered DL data is waiting and hence the new MME/SGSN shall establish the user plane for delivery of the buffered DL data. When the DL Data Buffer Expiration Time has expired, the MME/SGSN considers no DL data to be buffered and no indications of Buffered DL Data Waiting are sent during context transfers at TAU procedures. At TAU/RAU procedures with Serving-GW change, the buffered DL data is forwarded to the new Serving-GW or Gn/Gp-SGSN. For Control Plane CIoT EPS Optimisation, the High latency communication includes invoking the buffering of MT data at the Serving-GW or the MME as specified in Mobile Terminated Data Transport in Control Plane CIoT EPS Optimisation with P-GW connectivity, clause 5.3.4B.3. When the UE contacts MME, MME delivers the buffered data using NAS PDUs. If MT data is buffered in MME, at TAU procedures with MME change the buffered data in the old MME is discarded. The High latency communication also includes sending event notifications to application servers that have requested "UE Reachability" or "Availability after DDN failure" monitoring events. Event notifications are sent when a UE becomes reachable, for example as part of the Attach Procedure, TAU/RAU procedures and the UE triggered Service Request procedure. When "UE Reachability" monitoring 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 MME is aware that some signalling or data is pending in the network for an UE that is known as being unreachable for a long duration, e.g. for UE's having extended idle mode DRX or PSM enabled, the MME may include a Pending Data indication in the next S1-AP message towards an eNodeB. If the eNodeB receives this indication, the eNodeB 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 MME may send a Pending Data indication to the target RAN node.

The support of Ethernet PDN type relies upon the selection of a P-GW that supports combined PGW+SMF functionality specified in TS 23.501, TS 23.502 and TS 23.503. This functionality may be supported by a PLMN even if it has no NG-RAN coverage, however, it does require that the subscriber has a subscription record in the 5GS UDM. This feature is described in clause 5.6.10.2 of TS 23.501. For PDN connection with Ethernet PDN type, IP address allocation is not needed. In contrast to the Non-IP PDN type, EPS Dedicated Bearers are supported for the Ethernet PDN type (including the TFT as described in clause 4.7.2.1). The details about the TFT packet filter(s) are described in clause 5.7.6.3 of TS 23.501. For PDN connection of Ethernet type, dynamic PCC is applied as described in clause 4.7.5 with the following differences:

• Dynamic PCC specified in TS 23.503 is applied, i.e. the PCEF interacts with the PCF using N7 interface as described in TS 23.501, and the PCEF does not interact with the PCRF using Gx interface as specified in TS 23.203.
• The SDF template included in the PCC rule(s) uses Ethernet packet filter as specified in TS 23.501.
• The description related to IP address configuration is not applicable.

Dedicated Core Network functionality (see clause 4.3.25) can be used to avoid the need for all MMEs in the PLMN to be upgraded to support Ethernet PDN Type. If the UE's attempt to use the Ethernet PDN Type is rejected by the network, the UE may attempt to gain service by requesting the Non-IP PDN type. Ethernet PDN Type is not supported in GERAN/UTRAN. If the UE only has an Ethernet PDN connection established, mobility to GERAN/UTRAN should be prevented. To do this, the MME shall indicate to the eNodeB in Handover Restriction List that GERAN/UTRAN is restricted. For PDN connection with Ethernet PDN type, mobility to Non 3GPP access to EPC is not supported.

Service Gap Control is an optional feature intended for MTC/CIoT UEs to control the frequency at which these UEs can access the network. That is, to ensure a minimum time gap between consecutive Mobile Originated data communications initiated by the UE. This helps reducing peak load situations when there are a large number of these UEs in an operator network. Service Gap Control is intended to be used for "small data allowance plans" for MTC/CIoT UEs where the applications are tolerant to service latency. Service Gap Time is a subscription parameter used to set the Service Gap timer and is enforced in the UE and in the MME on a per UE level (i.e. the same Service Gap Timer applies for all PDN connections that the UE has). The UE indicates its capability of support for Service Gap Control in the Attach Request message and TAU Request message to the MME. The MME passes the Service Gap Time to the UE in the Attach Accept message and/or Tracking Area Update Accept message for UE that has indicated its supports of the Service Gap Control. The Service Gap Control shall be applied in a UE when a Service Gap Time is stored in the UE context and applied in the MME when the Service Gap Time is stored in the MM context. Service Gap Control requires the UE to stay in ECM-IDLE mode for at least the whole duration of the Service Gap timer before triggering Mobile Originated user data transmission, except for procedures that are exempted (see TS 24.301). The Service Gap timer shall be started each time a UE moves from ECM-CONNECTED to ECM-IDLE, unless the connection request was initiated by the paging of a Mobile Terminated event, or after a TAU procedure without active flag or signalling active flag, which shall not trigger a new or extended Service Gap interval. When a Service Gap timer expires, the UE is allowed to send a connection request again. If the UE does so, the Service Gap timer will be restarted at the next ECM-CONNECTED to ECM-IDLE transition. The Service Gap control is applied in ECM-IDLE state only and does not impact UE Mobile Originated user data transmission or Mobile Originated signalling in ECM-CONNECTED state. The Service Gap timer is not stopped upon ECM-IDLE state to ECM-CONNECTED state transition. The UE shall not initiate connection requests for MO user plane data, MO control plane data, or MO SMS when a Service Gap timer is running. The UE shall also not initiate Attach Requests when a Service Gap timer is running, unless it is Attach Request without PDN connectivity or Emergency Attach which are allowed. The MME may enforce the Service Gap timer by rejecting connection request for MO user plane data, MO control plane data, or MO SMS when a Service Gap timer is running. The MME may enforce the Service Gap timer by not allowing Attach Requests when a Service Gap timer is running, unless it is Attach Request without PDN connectivity or Emergency Attach which are allowed. When rejecting the connection requests and the Attach Requests while the Service Gap timer is running, the MME may include a Mobility Management back-off timer corresponding to the time left of the current Service Gap timer. For the UEs that does not support Service Gap Control (e.g. pre-release-15 UEs), Service Gap Control may be enforced using "General NAS level Mobility Management control" as defined in clause 4.3.7.4.2.1. When the MME starts the Service Gap timer, the MME should invoke the Service Gap timer with a value that is slightly shorter than the Service Gap Time value provided to the UE in the subscription information received from the HSS. A UE which transitions from a PSM or eDRX power saving state shall apply Service Gap Control when it wakes up if the Service Gap timer is still running. Additional aspects of Service Gap Control:

• Service Gap Control applies in all PLMNs.
• When the Service Gap timer is running and the UE receives paging, the UE shall respond as normal.
• Service Gap Control applies to low priority (delayTolerant) and normal traffic.
• Service Gap Control does not apply to exception reporting for NB-IoT.
• Emergency Attach and Attach without PDN Connectivity are allowed when a Service Gap timer is running.
• Service Gap Control shall be effective also for UEs performing detach and reattach unless it is Attach Request without PDN connectivity or Emergency Attach.
• Tracking Area Update with active flag or signalling active flag is not allowed when a Service Gap timer is running except for emergency bearer services or if the UE is accessing with high priority access class in the range AC 11-15.
• If the Service Gap timer is running, the Service Gap is applied at PLMN selection as follows:
  1. Re-attach to the registered PLMN: The remaining Service Gap timer value survives and controls the re-attach.
  2. Attach or Tracking Area Update to a different PLMN: The remaining Service Gap timer value survives and controls the Attach/Tracking Area Update to the new PLMN.
  3. USIM swap: The Service Gap timer is no longer running and the Service Gap feature does not apply, unless re-instatiated by the serving PLMN.
• Multiple uplink packets and downlink packets are allowed during one RRC connection for UE operating within its APN Rate Control limits.

The following procedures are impacted by Service Gap Control:

• E-UTRAN Initial Attach, see clause 5.3.2.1;
• Tracking Area Update procedures, see clause 5.3.3;
• UE Triggered Service Request, see clause 5.3.4.1;
• Connection Resume Request, see clause 5.3.5A.

Multimedia Priority Service (MPS) allows certain subscribers (i.e. Service Users as per TS 22.153) priority access to system resources in situations such as during congestion, creating the ability to deliver or complete sessions of a high priority nature. Service Users are government-authorized personnel, emergency management officials and/or other authorized users. MPS supports priority sessions on an "end-to-end" priority basis. MPS is based on the ability to invoke, modify, maintain and release sessions with priority, and deliver the priority media packets under network congestion conditions. MPS is supported in a roaming environment when roaming agreements are in place and where regulatory requirements apply. MPS is supported for Service Users using UEs connecting via 3GPP access. MPS is also supported for Service Users using UEs that support connecting via Trusted or Untrusted non-3GPP access via WLAN as specified in TS 23.402 for MPS. ePDG selection is according to clause 4.5.4 in TS 23.402. A Service User obtains priority access to the Radio Access Network by using the Access Class Barring mechanism according to TS 36.331 and TS 22.011. This mechanism provides preferential access to UEs based on its assigned Access Class. If a Service User belongs to one of the special access-classes as defined in TS 22.011, the UE has preferential access to the network compared to ordinary users in periods of congestion. MPS subscription allows users to receive priority services, if the network supports MPS. The same MPS subscription applies to access via 3GPP access and non-3GPP access via WLAN. MPS subscription entitles a USIM with special Access Class(es). MPS subscription includes indication for support of Priority EPS Bearer Service, IMS priority service and CS Fallback priority service support for the end user. Priority level regarding Priority EPS Bearer Service and IMS are also part of the MPS subscription information. The usage of priority level is defined in TS 23.203 and TS 23.228. An MPS subscription may include an optional MPS for Messaging indication which sets(enables)/clears(disables) the MPS priority treatment of messaging service (i.e. SMS over NAS, SMS over IP and messaging over IMS are all controlled by one indication). The MPS for Messaging indication is used in EPC entities and is not delivered to the UE. The detailed MPS for Messaging indication handling is further specified in TS 23.272 for SMS over NAS via MME, in TS 23.204 for SMS over IP and in TS 23.228 for messaging over IMS. The MPS for Messaging indication in subscription data may be provisioned via SCS/AS as specified in TS 23.682. An MPS Service User is treated as an On Demand MPS subscriber or not, based on regional/national regulatory requirements. On Demand service is based on Service User invocation/revocation explicitly and applied to the PDN connections for an APN. When not On Demand, MPS service does not require invocation, and provides priority treatment for all EPS bearers for a given Service User after attachment to the EPS network. Since the Service User has an access class within the range for priority services, the Establishment Cause in RRC connection request is set to highPriorityAccess. When the eNodeB receives mobile initiated signalling with establishment cause set to highPriorityAccess, the eNodeB handles the RRC connection request with priority. When the MME receives and verifies mobile initiated signalling with establishment cause set to highPriorityAccess, the MME establishes the S1 bearer with priority. The terminating network identifies the priority of the MPS session and applies priority treatment, including paging with priority, to ensure that the MPS session can be established with priority to the terminating user (either a Service User or normal user). Priority treatment for MPS includes priority message handling, including priority treatment during authentication, security, and location management procedures. Priority treatment for MPS session requires appropriate ARP and QCI (where necessary for non-GBR bearers) setting for bearers according to the operator's policy. When an MPS session is requested by a Service User, the following bearer management principles apply in the network:

• EPS bearers (including default bearer) employed in an MPS session shall be assigned ARP value settings appropriate for the priority level of the Service User.
• Setting ARP pre-emption capability and vulnerability for MPS bearers, subject to operator policies and depending on national/regional regulatory requirements.
• Pre-emption of non-Service Users over Service Users during network congestion situation, subject to operator policy and national/regional regulations.

Priority treatment is applicable to IMS based multimedia services, priority EPS bearer services (PS data without IMS interaction) and CS Fallback. For Multimedia Priority services any EPC functions, procedures and capabilities are provided according to this clause's specification except when specified differently in the following clauses.

The Service User receives on demand priority treatment according to its MPS profile, i.e. On-Demand. If the Service User is not authorized to use on-demand priority request, the Service User receives priority treatment (i.e. appropriate ARP and QCI ) at initial attach for all bearers, based on user profile data stored in the HSS/SPR and authorized by the PCRF (see clause 7.2 of TS 23.203). An On-Demand Service User requires explicit invocation/revocation via SPR MPS user profile update (see clause 7.5 of TS 23.203). Since MPS user profile are part of inputs for PCC rules, the update will trigger PCC rules modification to achieve appropriate ARP and QCI settings for bearers (see clause 7.4.2 of TS 23.203). When the eNodeB receives mobile initiated signalling with establishment cause set to highPriorityAccess, the eNodeB handles the RRC connection request with priority. When the MME receives and verifies mobile initiated signalling with establishment cause set to highPriorityAccess, the MME establishes the S1 bearer with priority. Based on MPS EPS priority subscription, MME can verify whether the UE is permitted to handle the request preferentially comparing to other UEs not prioritized. An AF for MPS Priority Service is used to provide Priority EPS Bearer Services using network-initiated resource allocation procedures (via interaction with PCC) for originating accesses.

MPS for Data Transport Service is an on-demand service that may be invoked/revoked by an authorized MPS Service User using a UE with a subscription for MPS (i.e. according to its MPS profile), or using a UE that does not have a subscription for MPS (using methods not in scope of this specification). MPS for Data Transport Service requires explicit invocation. The Service User invokes the service by communicating with an AF. The authorization of an MPS for Data Transport Service request is done by the AF or by the PCRF according to clause 6.1.11.5 of TS 23.203. Upon successful authorization the PCRF performs the necessary actions to achieve appropriate ARP and QCI settings for the bearers (see clause 6.1.11.5 of TS 23.203). MPS for Data Transport Service enables the prioritization of all traffic on the default bearer and other bearers upon AF request. The QoS modification to the default bearer and other bearers is done based on operator policy and regulatory rules by means of local PCRF configuration. For MPS for Data Transport Service, the AF may also create an SDF for signalling priority between the UE and the AF (see clause 6.1.11.5 of TS 23.203).

CS Fallback allows users to fallback to GERAN/UTRAN/1x RTT while in E-UTRAN access thus allowing the network to transfer the call towards GERAN/UTRAN CS domain. In order to ensure that a priority CSFB call to/from a service user is given proper priority treatment in the EPS, MPS subscription indicates the user's CS priority status, i.e. MPS CS Priority, which is provided to MME with user's subscription information. When the eNodeB receives mobile initiated signalling with establishment cause set to highPriorityAccess, the eNodeB handles the RRC connection request with priority. When the MME receives and verifies mobile initiated signalling with establishment cause set to highPriorityAccess, the MME establishes the S1 bearer with priority. Details on the priority treatment of CSFB, see TS 23.272.

Based on regional/national requirements and network operator policy, MPS shall be exempted from network congestion controls up to the point where further exemptions cause network instability. The MME should not apply NAS level congestion control for mobile initiated signalling with establishment cause set to highPriorityAccess. The MME should not apply congestion control for termination requests related with an ARP associated with MPS.

When a UE is in ECM-CONNECTED mode with a bearer having an ARP associated with MPS, the MME should not release the UE for load re-balancing, except under critical conditions such as the need to perform an MME node restart. The MME should wait until the UE initiates a TAU or becomes ECM-IDLE before initiating load re-balancing.

The indication of mapped or native GUTI shall be signalled by the UE to the MME as an explicit indication in Attach Request and TAU Request messages. The indication of mapped or native P-TMSI/RAI shall be signalled by the UE to the SGSN as an explicit indication in Attach Request and RAU Request messages. The MME/SGSN resolves the old MME/SGSN using old GUTI respective old P-TMSI/RAI sent in the Attach request and TAU/RAU request messages, and determines if the old GUTI or the old P-TMSI/RAI is mapped or native by one of the following two methods:

• Indication using most significant bit (MSB) in LAC and MME Group ID.
• Explicit indication sent from UE to MME and SGSN.

For PLMNs deployed with such mechanism the MME differentiates between a GUMMEI mapped from P-TMSI/RAI and a native GUMMEI based on the value of most significant bit of the MME Group ID; i.e. the MSB is set to "0" then the GUMMEI is mapped from P-TMSI/RAI and if MSB is set to "1", the GUMMEI is a native one, as specified in TS 23.003. For PLMNs deployed with such mechanism the S4-SGSN differentiates between a P-TMSI/RAI mapped from GUTI and a native P-TMSI/RAI based on the value of most significant bit of the LAC; i.e. the MSB is set to "1" then the P-TMSI/RAI is mapped from GUTI and if MSB is set to "0", the P-TMSI/RAI is a native one, as specified in TS 23.003.

For PLMNs deployed with such mechanism the MME differentiates between a GUTI mapped from P-TMSI/RAI or a native GUTI based on the explicit indication sent by the UE. For PLMNs deployed with such mechanism the S4-SGSN differentiates between a P-TMSI/RAI mapped from GUTI or a native P-TMSI/RAI based on the explicit indication sent by the UE.