4.5 High Level Function

23.6823GPPArchitecture enhancements to facilitate communications with packet data networks and applicationsRelease 17TS

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

4.5.1 Device Triggering Function

Device Triggering is the means by which a SCS sends information to the UE via the 3GPP network to trigger the UE to perform application specific actions that include initiating communication with the SCS for the indirect model or an AS in the network for the hybrid model. Device Triggering is required when an IP address for the UE is not available or reachable by the SCS/AS.

Device trigger message contains information that allows the network to route the message to the appropriate UE and the UE to route the message to the appropriate application. The information destined to the application, along with the information to route it, is referred to as the Trigger payload. The UE needs to be able to distinguish an MT message carrying device triggering information from any other type of messages.

NOTE: The Trigger payload, for example, upon the reception by the UE possibly provides information to the application that may trigger application related actions. The application in the UE may perform indicated actions, such as for example to initiate immediate or later communication to the SCS/AS, based on the information contained in the Trigger payload.

Device Triggering is subscription based. The subscription provides the information whether a UE is allowed to be triggered by a specific SCS. When device triggers are delivered via MT-SMS the serving nodes MME, SGSN and MSC provide the service towards a specific UE based on the UE’s subscription for MT-SMS and other subscription parameters affecting MT-SMS service provision.

Device triggering recall/replace functionality allows a SCS to recall or replace previously submitted trigger messages which are not yet delivered to the UE.

Charging data are collected for the device triggering. The MTC-IWF generates CDRs for the service requester. When device triggers are delivered via MT-SMS then network entities, like MME, SGSN, MSC or SMS-SC generate CDRs for SMS services provided for the mobile subscriber.

4.5.2 PS-only Service Provision

PS-only service provision is providing a UE with all subscribed services via PS domain. PS-only service provision implies a subscription that allows only for services exclusively provided by the PS domain, i.e. packet bearer services and SMS services. The support of SMS services via PS domain NAS is a network deployment option and may depend also on roaming agreements. Therefore, a subscription intended for PS-only service provision may allow also for SMS services via CS domain to provide a UE with SMS services in situations when serving node or network don’t support SMS via PS domain NAS. The functionality that enables PS-only service provision is described in TS 23.060 [6] and TS 23.272 [11].

The functionality that enables PS-only service provision for SMS delivery in IMS is described in TS 23.204 [13].

4.5.3 Core Network assisted RAN parameters tuning

Core Network assisted RAN parameters tuning aids the RAN in optimizing the setting of RAN parameters. See TS 23.401 [7] for details.

4.5.4 UE Power Saving Mode

A UE may adopt the PSM for reducing its power consumption. That mode is similar to power-off, but the UE remains registered with the network and there is no need to re-attach or re-establish PDN connections. A UE in PSM is not immediately reachable for mobile terminating services. A UE using PSM is available for mobile terminating services during the time it is in connected mode and for the period of an Active Time that is after the connected mode. The connected mode is caused by a mobile originated event like data transfer or signalling, e.g. after a periodic TAU/RAU procedure. PSM is therefore intended for UEs that are expecting only infrequent mobile originating and terminating services and that can accept a corresponding latency in the mobile terminating communication.

For mobile terminated data while a UE is in PSM, the functions for High latency communication may be used as described in clause 4.5.7.

PSM has no support in the CS domain on the network side. PSM should only be used by UEs using the PS domain, SMS and mobile originated IMS or CS services. A UE that uses mobile terminated CS services other than SMS should not use PSM as the CS domain does not provide support for mobile terminated CS voice services to UEs that are in PSM. A UE that uses delay tolerant mobile terminated IMS services other than SMS should not request for PSM unless IMS uses the functions for High latency communication as described in clause 4.5.7.

NOTE 1: The frequency of keep-alive messages on Gm impacts the possibility to use IMS services for UEs applying PSM.

Applications that want to use the PSM need to consider specific handling of mobile terminating services or data transfers. A network side application may send an SMS or a device trigger to trigger an application on UE to initiate communication with the SCS/AS, which is delivered when the UE becomes reachable. Alternatively a network side application may request monitoring of reachability for data to receive a notification when it is possible to send downlink data immediately to the UE, which is when the UE becomes reachable for downlink data transfer. Alternatively, if an SCS/AS has periodic downlink data, it is more efficient when the UE initiates communication with the SCS/AS to poll for downlink data with that period. For either of the options to work, the UE should request an Active Time that is together with the time being in connected mode long enough to allow for potential mobile terminated service or data delivery, e.g. to deliver an SMS.

When the UE wants to use the PSM it shall request an Active Time value during every Attach and TAU/RAU procedures. If the network supports PSM and accepts that the UE uses PSM, the network confirms usage of PSM by allocating an Active Time value to the UE. The network takes the UE requested value, the Maximum Response Time (defined in clause 5.6.1.4), if provided with the Insert Subscriber Data or Update Location Ack message from HSS, and any local MME/SGSN configuration into account for determining the Active Time value that is allocated to the UE. If the UE wants to change the Active Time value, e.g. when the conditions are changed in the UE, the UE consequently requests the value it wants in the TAU/RAU procedure.

NOTE 2: The minimum recommended length for the Active Time is the time allowing for the ‘msg waiting flag’ in the MME/SGSN to trigger the SMSC via the HSS to deliver an SMS to the MME/SGSN, e.g. 2 DRX cycles plus 10 seconds.

NOTE 3: The Maximum Response Time value can be configured as desired Active Time value in the HSS via O&M.

An Active Time may be shorter than the time estimated for delivering a waiting SMS to the UE in NOTE 2 above, e.g. 0 seconds. If the MME/SGSN allocates such a shorter Active Time to the UE, the MME/SGSN (for signalling only connections and if the ‘msg waiting flag’ is set) and the RAN (for connections with RAB(s) set up) should be configured to keep the connection with the UE sufficiently long such that a waiting SMS can be delivered.

NOTE 4: The RAN configuration of RAB connection times need not differentiate between UEs.

If the MME/SGSN is requested to monitor for Reachability for Data, the MME/SGSN (for signalling only connections) and the RAN (for connections with RAB(s) set up) should keep the connection for the Maximum Response Time less the Active Time, if Maximum Response Time is provided with the Insert Subscriber Data message from HSS. Otherwise a configured default Maximum Response Time is assumed by the MME/SGSN.

The UE is in PSM until a mobile originated event (e.g. periodic RAU/TAU, mobile originated data or detach) requires the UE to initiate any procedure towards the network. In Attach and RAU/TAU procedures a PSM capable UE may request a periodic TAU/RAU Timer value suitable for the latency/responsiveness of the mobile terminated services. If the UE wants to change the periodic TAU/RAU Timer value, e.g. when the conditions are changed in the UE, the UE consequently requests the value it wants in the TAU/RAU procedure.

NOTE 5: If the UE or application performs any periodic uplink data transfer with a periodicity similar to the Periodic TAU/RAU Timer value, it preferably requests a Periodic TAU/RAU Timer value that is at least slightly larger than the data transfer period to avoid periodic TAU/RAU procedures that would increase power consumption.

Any timers and conditions that remain valid during power-off, e.g. NAS-level back-off timers, apply in the same way during PSM. The UE may leave the PSM any time, e.g. for mobile originated communications.

If the network confirms the usage of PSM to a UE, the network shall not activate the ISR for such UE.

The specific procedure handling is described in TS 23.060 [6] and TS 23.401 [7].

4.5.5 Group Message Delivery

The Group Message Delivery feature allows an SCS/AS to deliver a payload to a group of UEs. Two methods of Group Message Delivery are specified:

– Group Message Delivery via MBMS which is intended to efficiently distribute the same content to the members of a group that are located in a particular geographical area when MBMS is used;

– Group Message Delivery via unicast MT NIDD for UEs which are part of the same External Group Identifier.

The specific procedure handling for group message delivery using MBMS is described in clause 5.5.1. The group message delivery using MBMS has limited applicability and does not support all the scenarios, e.g. UEs not supporting MBMS, UEs located in areas where MBMS is not deployed. The SCS/AS may recall or replace a previously submitted MBMS message; this is described in clause 5.5.2.

The Group MT NIDD procedure for delivering non-IP data to a group via unicast MT NIDD is described in clause 5.5.3. The SCEF uses the SCS/AS Identifier and the External Group Identifier to determine the APN that will be used to send the non-IP data to the group member UEs. This determination is based on local policies. When the SCEF receives a Group MT NIDD request from the SCS/AS, the SCEF queries the HSS to resolve the group members and forks the message by sending it in a unicast manner to all of the individual UEs that are associated with the External Group Identifier.

NOTE: In order for the non-IP data to reach each group member UE, each group member UE must have a PDN connection established to the APN and the SCS/AS must have performed an NIDD Configuration Procedure for the External Group Identifier.

4.5.6 Monitoring Events

4.5.6.1 General

The Monitoring Events feature is intended for monitoring of specific events in 3GPP system and making such monitoring events information available via the SCEF. It is comprised of means that allow the identification of the 3GPP network element suitable for configuring the specific events, the event detection, and the event reporting to the authorised users, e.g. for use by applications or logging, etc. If such an event is detected, the network might be configured to perform special actions, e.g. limit the UE access. Configuration and reporting of the following monitoring events may be supported:

– Monitoring the association of the UE and UICC and/or new IMSI-IMEI-SV association;

– UE reachability;

– Location of the UE, and change in location of the UE;

NOTE 1: Location granularity for event request, or event report, or both could be at cell level (CGI/ECGI), TA/RA level or other formats e.g. shapes (e.g. polygons, circles, etc.) or civic addresses (e.g. streets, districts, etc.).

– Loss of connectivity;

– Communication failure;

– Roaming status (i.e. Roaming or No Roaming) of the UE, and change in roaming status of the UE; and

NOTE 2: Roaming status means whether the UE is in HPLMN or VPLMN based on the most recently received registration state in the HSS.

– Number of UEs present in a geographical area;

– Availability after DDN failure; and

– PDN Connectivity Status.

To support monitoring features in roaming scenarios, a roaming agreement needs to be made between the HPLMN and the VPLMN. The set of capabilities required for monitoring may be accessible via different 3GPP interfaces/nodes. Selection of 3GPP interface(s) to configure/report the event is dependent on the type of the event, operator configuration, required frequency of event reporting, application provided parameters in monitoring event request, etc.

Support for Monitoring Events can be offered either via HSS, MME/SGSN (as described in clause 4.5.6.2) or via PCRF (as described in clause 4.5.6.3). Based on operator policies, it shall be possible to configure Monitoring Events such that some Monitoring Event follows procedures in clause 4.5.6.2 while another Monitoring Event follows procedures in clause 4.5.6.3. SCEF shall not enable a given Monitoring Event for the same UE via both HSS/MME/SGSN, and PCRF. For the case of group based Monitoring Events, the SCS/AS (either the same SCS/AS or different SCSs/ASs) may configure a Monitor Event with different External Group Identifiers. If, in such a case, more than one External Group Identifier point to the same UE and no Group Reporting Guard Time was provided with any of the monitoring event configurations, the MME, HSS, and SCEF should not send duplicate reports of the same event for the same UE to the same destination.

NOTE 3: If the configuration of Monitoring Events uses signalling which was specified as part of another feature than the Monitoring feature, then the requirements on the HSS, MME/SGSN and PCRF as specified by that feature apply e.g. not to generate accounting information, not to verify SLA etc.

4.5.6.2 Monitoring Events via HSS and MME/SGSN

Monitoring Events via the HSS and the MME/SGSN enables SCEF to configure a given Monitor Event at HSS or MME/SGSN, and reporting of the event via HSS and/or MME/SGSN. Depending on the specific monitoring event or information, it is either the MME/SGSN or the HSS that is aware of the monitoring event or information and makes it available via the SCEF.

The procedures for requesting specific monitoring information or event reports as well as the report procedures are described in clause 5.6.

Some subscription data in HSS for a UE may affect the event monitoring, and such subscription data is set taking the input from the specific parameter(s) of monitoring event(s) as specified in clause 5.6 or from the network parameter configuration(s) as specified in clause 5.18, or from both of them.

If the Enhanced Multiple Event Monitoring feature is supported, the HSS stores the specific parameters per SCEF Reference ID for the same or different event types from multiple SCS/ASs or the specific parameters for the network parameter configurations from multiple SCS/ASs, or from both of them.

4.5.6.3 Monitoring Events via PCRF

Monitoring Events via the PCRF enables the SCEF to retrieve the location information and to report communication failure of a UE. When not performing group monitoring, the SCEF acting as AF shall have an active Rx session to enable the PCRF to report these events. The procedure is defined in clause 6.2.3 of TS 23.203 [27]. The procedure for requesting location information, when not performing group monitoring, is described in clause 5.6.4.1.

The UE location information, provided over Rx, may include a time stamp to indicate when the UE was last-known to be in that location, i.e. if the current location or the last-known location is provided. The UE location information is reported at the time the Rx session is established, modified or terminated. The subscription to UE location information is not persistent across Rx sessions. The UE location information is provided for 3GPP IP-CAN type, for Trusted WLAN access (S2a) or untrusted WLAN (S2b) as defined in clause 6.2.3 of TS 23.203 [27].

The reporting of communication failure refers to the reporting of RAN/NAS release cause codes according to TS 23.401 [7], TS 23.060 [6], and TWAN/UWAN release causes according to TS 23.402 [26]. Once the RAN/NAS or TWAN/UWAN release cause codes are reported to the PCRF, the PCRF reports it to the SCEF according to TS 23.203 [27] for applicable IP-CAN types and RAT types listed in TS 23.203 [27].

Monitoring Events via the PCRF also enable the SCEF to request the location information of a group of UEs via Nt interface.

The procedure for requesting monitoring of a group of UEs via the PCRF is described in clause 5.6.4.1a. Group monitoring requests are sent by the SCEF to each PCRF in the operator´s network.

NOTE: The existing PCRF addressing mechanism defined in TS 23.203 [27] does not apply for requesting reporting events for a group of UEs.

The procedure for reporting the location information for a group of UEs is performed for each UE that has an IP-CAN session established at the time the SCEF requests the UE location for a group of UEs as described in clause 5.6.4.2.

The UE location information, provided over Nt, may include a time stamp to indicate when the UE was last-known to be in that location, i.e. if the current location or the last-known location is provided. The UE location information is provided for 3GPP IP-CAN type, for Trusted WLAN access (S2a) or untrusted WLAN (S2b).

4.5.6.4 Void

4.5.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. UE Power Saving Mode (see clause 4.5.4) or extended idle mode DRX (see clause 4.5.13) 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).

High latency communication is handled by an extended buffering of downlink data in the Serving GW controlled by the MME/S4-SGSN or in the Gn/Gp-SGSN. The MME/S4-SGSN asks the Serving GW to buffer downlink data until the UE is expected to wake up from its power saving state. The Gn/Gp-SGSN similarly buffers downlink data until the UE is expected to wake up from its power saving state. If a Serving GW change or a Gn/Gp-SGSN change is invoked, the buffered packets are forwarded and will not be lost. The number of packets to buffer is decided by the Serving GW or Gn/Gp-SGSN, but the MME/S4-SGSN may optionally provide a suggestion for the number of downlink packets to be buffered based on the information received from the HSS. The information received from the HSS may be subscription based or may be based on information provided by the SCS/AS during the configuration of the event, see clause 5.6.1.4.

For Control Plane CIoT EPS optimisation, High latency communication is handled by the buffering of downlink data in the Serving GW or the MME as described in TS 23.401 [7].

High latency communication may also be handled by notification procedures (see clause 5.7), when an MME/S4-SGSN is used (i.e. this procedure does not apply to a Gn/Gp-SGSN). The SCS/AS requests notification when a UE wakes up from its power saving state and sends downlink data to the UE when the UE is reachable. Especially for infrequent mobile terminated communication this may be suitable. This notification procedure is available based on two different monitoring events:

– Monitoring event: UE Reachability; or

– Monitoring event: Availability after DDN failure.

An SCS/AS may request a one-time "UE Reachability" notification when it wants to send data to the UE. Alternatively the SCS/AS may request repeated "Availability after DDN failure" notifications where each notification is triggered by a DDN failure i.e. the SCS/AS sends a downlink packet which is discarded by Serving GW but which triggers the MME/SGSN to send an event notification to the SCS/AS next time the UE wakes up.

When requesting to be informed of either "UE Reachability" or "Availability after DDN failure" notification, the SCS/AS may also request Idle Status Indication. If the HSS and the MME/SGSN support Idle Status Indication, then when the UE for which PSM or extended idle mode DRX is enabled transitions into idle mode, the MME/SGSN includes the time at which the UE transitioned into idle mode, the active time and the periodic TAU/RAU time granted to the UE by the MME/SGSN in the notification towards the SCEF, the eDRX cycle length and the Suggested number of downlink packets if a value was provided to the S-GW.

The length of the power saving intervals used by the network decides the maximum latency for a UE. An SCS/AS, which has a specific requirement on the maximum latency for UEs it communicates with, may provide its maximum latency requirement to the network. This is done either by interaction with the application in the UE and setting of appropriate time values in the UE (e.g. periodic RAU/TAU timer) for the Power Saving Mode, or by providing the maximum latency at the configuration of the "UE reachability" monitoring event (if used) (see clause 5.7).

The tools for High latency communication make the behaviour of the 3GPP network predictable when sending mobile terminated data to UEs applying power saving functions. The network will deliver downlink packets with high reliability for both stationary and mobile UEs when the UE wakes up from its power saving state. Therefore SCS/AS can adapt its retransmissions to reduce the load on both the SCS/AS itself and the network.

4.5.8 Support of informing about potential network issues

The SCS/AS may request the SCEF for being notified about the network status in a geographical area. The SCS/AS can request for a one-time reporting of network status or a continuous reporting of network status changes.

4.5.9 Resource management of background data transfer

The 3rd party SCS/AS requests a time window and related conditions from the SCEF for background data transfer to a set of UEs via the Nt interface. The SCS/AS request shall contain the SCS/AS identifier, SCS/AS Reference ID, the volume of data expected to be transferred per UE, the expected amount of UEs, the desired time window and optionally, network area information. The SCEF passes this information to a selected PCRF. The PCRF shall determine one or more transfer policies each including a recommended time window for the data transfer together with a maximum aggregated bitrate for the expected volume of data and a reference to the applicable charging rate during the time window and provide them to the SCEF together with a Reference ID. The SCEF shall forward the Reference ID and the transfer policies to the 3rd party SCS/AS. If more than one transfer policy was received, the 3rd party SCS/AS needs to select one of them and inform the SCEF about the selected transfer policy (which forwards it to the PCRF). If this is not done, none of the transfer policies provided by the operator will be valid.

NOTE 1: The maximum aggregated bitrate (optionally provided in a transfer policy) is not enforced in the network. The operator may apply offline CDRs processing (e.g. combining the accounted volume of the involved UEs for the time window) to determine whether the maximum aggregated bitrate for the set of UEs was exceeded by the ASP and charge the excess traffic differently.

NOTE 2: It is assumed that the 3rd party SCS/AS is configured to understand the reference to a charging rate based on the agreement with the operator.

After having negotiated the time window, the SCS/AS (acting as an AF), shall provide the Reference ID to the PCRF for each UE individually together with the SCS/AS session information via the Rx interface. Alternatively, the SCS/AS activates the selected transfer policy via the SCEF, for each UE in the group, by using the "Set the chargeable party at session set-up" or "Change the chargeable party during the session" procedure from clauses 5.12.1 and 5.12.2 to provide the Reference ID to the same or different PCRF. The PCRF retrieves the corresponding transfer policy from the SPR. The PCRF derives the PCC rules for the background data transfer according to this transfer policy and triggers PCC procedures according to TS 23.203 [27] to provide the respective policing and charging information to the PCEF.

NOTE 3: The SCS/AS will typically request sponsored connectivity for the background data transfer to individual UEs.

NOTE 4: A transfer policy is only valid until the end of its time window. The removal of outdated transfer policies from the SPR is up to implementation.

NOTE 5: The SCS/AS can contact the PCRF directly or interact with the PCRF via the SCEF.

4.5.10 E-UTRAN network resource optimizations based on communication patterns provided to the MME

Predictable communication patterns (CP) of a UE may be provided by the Application Server to the SCEF in order to enable network resource optimizations for such UE(s). The SCEF filters the CP parameters and forwards them to the HSS, which provides them to the MME. The MME may use the CP parameters as input to derive the CN assisted eNodeB parameters as described in TS 23.401 [7]. This feature is applicable to UEs served over the E-UTRAN access.

4.5.11 Support of setting up an AS session with required QoS

The 3rd party SCS/AS may request that a data session to a UE that is served by the 3rd party service provider (AS session) is set up with a specific QoS (e.g. low latency or jitter) and priority handling. This functionality is exposed via the SCEF towards the SCS/AS.

The SCS/AS can request the network to provide QoS for the AS session based on the application and service requirements with the help of a QoS reference parameter which refers to pre-defined QoS information.

NOTE 1: The pre-defined QoS information is part of the SLA between the operator and the 3rd party SCS/AS.

When the SCEF receives the request from the SCS/AS to provide QoS for an AS session, the SCEF acts as an AF per TS 23.203 [27] specifications and transfers the request to provide QoS for an AS session to the PCRF via the Rx interface.

NOTE 2: An SLA has to be in place defining the possible QoS levels and their charging rates. For each of the possible pre-defined QoS information sets, the PCRF needs to be configured with the corresponding QoS parameters and their values as well as the appropriate Rating-Group (or receive this information from the SPR).

NOTE 3: The QoS reference parameter is transferred by existing Rx parameters. Before the QoS reference parameter is forwarded, the SCEF can perform a mapping from the name space of the 3rd party AS to the name space of the operator.

If the SCEF gets informed about bearer level events for the Rx session (e.g. transmission resources are released/lost) the SCEF shall inform the SCS/AS about it.

4.5.12 Change the chargeable party at session set-up or during the session

The SCS/AS may request the SCEF to start or stop sponsoring a data session for a UE that is served by the 3rd party service provider (AS session), i.e. to realize that either the 3rd party service provider is charged for the traffic (start) or not (stop). The SCS/AS may request to be set as the chargeable party, i.e. sponsoring the traffic, either at AS session set-up or to change it during an ongoing AS session. The SCEF acts as an AF and existing functionality defined in TS 23.203 [27] for sponsored data connectivity is used to support this functionality. If the SCEF gets informed that the Rx session terminates (e.g. due to a release of PDN connection) the SCEF shall inform the SCS/AS about it and shall forward any accumulated usage report received from the PCRF.

4.5.13 Extended idle mode DRX

4.5.13.1 General

The UE and the network may negotiate over non-access stratum signalling the use of extended idle mode DRX for reducing its power consumption, while being available for mobile terminating data and/or network originated procedures within a certain delay dependent on the DRX cycle value.

Applications that want to use extended idle mode DRX need to consider specific handling of mobile terminating services or data transfers, and in particular they need to consider the delay tolerance of mobile terminated data. A network side application may send mobile terminated data, an SMS, or a device trigger, and needs to be aware that extended idle mode DRX may be in place. A UE should request for extended idle mode DRX only when all expected mobile terminating communication is tolerant to delay.

A UE that uses mobile terminated CS services other than SMS should not request for extended idle mode DRX as the CS domain does not provide support for mobile terminated CS voice services to UEs that are in extended idle mode DRX. A UE that uses delay tolerant mobile terminated IMS services other than SMS should not request for extended idle mode DRX unless IMS uses the functions for High latency communication as described in clause 4.5.7.

NOTE 1: The frequency of keep-alive messages on Gm impacts the possibility to use IMS services for UEs applying extended idle mode DRX.

In order to negotiate the use of extended idle mode DRX, the UE requests extended idle mode DRX parameters during attach procedure and RAU/TAU procedure. The SGSN/MME may reject or accept the UE request for enabling extended idle mode DRX. If the SGSN/MME accepts the extended idle mode DRX, the SGSN/MME based on operator policies and, if available, the extended idle mode DRX cycle length value in the subscription data from the HSS, may also provide different values of the extended idle mode DRX parameters than what was requested by the UE. If the SGSN/MME accepts the use of extended idle mode DRX, the UE applies extended idle mode DRX based on the received extended idle mode DRX parameters. If the UE does not receive extended idle mode DRX parameters in the relevant accept message because the SGSN/MME rejected its request or because the request was received by SGSN/MME not supporting extended idle mode DRX, the UE shall apply its regular discontinuous reception as defined in clause 5.13 of TS 23.401 [7].

NOTE 2: The extended idle mode DRX cycle length requested by UE takes into account requirements of applications running on the UE. Subscription based determination of eDRX cycle length can be used in those rare scenarios when applications on UE cannot be modified to request appropriate extended idle mode DRX cycle length. The network accepting extended DRX while providing an extended idle mode DRX cycle length value longer than the one requested by the UE, can adversely impact reachability requirements of applications running on the UE.

The specific negotiation procedure handling is described in TS 23.060 [6] and TS 23.401 [7].

If a UE requests via NAS both to enable PSM (requesting an active time and possibly a periodic TAU timer) and extended idle mode DRX (with a specific extended idle mode DRX cycle value), it is up to the SGSN/MME to decide whether to:

1. Enable only PSM, i.e. not accept the request for extended idle mode DRX.

2. Enable only extended idle mode DRX, i.e. not accept the request for an active time.

3. Enable both PSM (i.e. provide an active time) and extended idle mode DRX (i.e. provide an extended idle mode DRX parameters).

The decision between the three above, and which active time, periodic TAU timer and/or extended idle mode DRX cycle value to provide to the UE, are implementation dependent, based on local configuration, and possibly other information available in the SGSN/MME. The method selected is then used until the next Attach or RAU/TAU procedure is initiated, when a new decision may be made. If both extended idle mode DRX and PSM are enabled, the extended idle mode DRX cycle should be set in order to have multiple paging occasions while the active timer is running.

NOTE 3: To maximize the power saving while in the extended idle mode DRX cycle, the Periodic TAU timer needs to be longer than the extended idle mode DRX cycle.

In the specific case when the PSM active time provided by the UE is greater than the extended idle mode DRX cycle value provided by the UE, the SGSN/MME may enable both PSM and extended idle mode DRX. This allows a UE to minimize power consumption during the active time e.g. when the active time is slightly longer than typical active time values for example in the order of several minutes.

If extended idle mode DRX is enabled, the network handles mobile terminated data using high latency communication feature, according to clause 4.5.7, GTP-C retransmissions as described in TS 23.060 [6] and TS 23.401 [7], and applies techniques to handle mobile terminated SMS according to TS 23.272 [11] and location services according to TS 23.271 [33].

4.5.13.2 Paging for extended idle mode DRX in UTRAN

The procedure makes use of the regular DRX cycle mechanism for determination of Paging Occasions (POs) (see TS 25.304 [34]) in conjunction with a new TeDRX timer and a means to synchronize the start of the TeDRX timer with a time reference referred to here as Tref. The TeDRX timer is set to the extended Idle mode DRX cycle value negotiated earlier on NAS level. At TeDRX expiry i.e. when the extended Idle mode DRX cycle elapses the UE monitors the network for paging using regular DRX parameters.

CN and UE start the extended TeDRX timer at transmission and reception, respectively, of the Attach Accept or RAU Accept message where the relevant extended Idle mode DRX parameters are provided. In other words, Tref corresponds in the CN to the instant when RAU Accept message is sent and in the UE to the instant when the respective Accept message is received.

The TeDRX timer is maintained and used only when the Attach/RAU procedure was successfully executed and independent of UE’s PMM state, i.e. transitions between Idle and Connected mode do not affect the TeDRX timer.

In order to improve paging reliability e.g. to avoid paging misses due to cell reselection or due to imperfect synchronization of the Tref parameter in the UE and the SGSN, a Paging Transmission Window Time (PTW) described by its duration TPTW is introduced. During PTW the UE monitors the network for paging when the extended Idle mode DRX cycle based on the extended Idle mode DRX value expires. During the PTW there may be multiple opportunities to page the UE which monitors the network for paging using regular DRX parameters.

Figure 4.5.13.2-1 The usage of PTW and independence of the extended Idle mode DRX cycle from UE state

In reference to Figure 4.5.13.2-1, upon expiry of the TeDRX timer in the UE, the UE monitors the network for paging for TPTW seconds. TDRX is the duration of the regular DRX cycle.

The necessary information for applying the PTW is provided to the UE over NAS when extended Idle mode DRX is negotiated.

In the case of a paging trigger received in the CN for a UE in PMM Idle state, the CN forwards the paging message towards relevant RAN node(s) immediately if the paging trigger was received within the PTW. Otherwise the CN forwards the paging message shortly ahead of the beginning of the next PTW taking possible imperfections in the synchronization between the CN and the UE into account.

4.5.13.3 Paging for extended idle mode DRX in E-UTRAN

4.5.13.3.0 General

For WB-E-UTRAN, the extended idle mode DRX value range will consist of values starting from 5.12s (i.e. 5.12s, 10.24s, 20.48s, etc.) up to a maximum of 2621.44s (almost 44 min). For NB-IoT, the extended idle mode DRX value range will start from 20.48s (i.e. 20.48s, 40.96s, 81.92, etc.) up to a maximum of 10485.76s (almost 3 hours) (see TS 36.304 [35]). The extended idle mode DRX cycle length is negotiated via NAS signalling according to clause 4.5.13.1. The MME includes the extended idle mode DRX cycle length for WB-E-UTRAN or NB-IoT in paging message to assist the eNodeB in paging the UE.

NOTE: Heterogeneous support of extended idle mode DRX in tracking areas assigned by MME in a TAI list can result in significant battery life reduction in the UE as compared to homogeneous support by eNodeBs of extended idle mode DRX.

For extended idle mode DRX cycle length of 5.12s, regular paging strategy as defined in TS 23.401 [7] is used.

For extended idle mode DRX cycle length of 10.24s or longer, clauses 4.5.13.3.1, 4.5.13.3.2 and 4.5.13.3.3 apply.

4.5.13.3.1 Hyper SFN, Paging Hyperframe and Paging Time Window length

A Hyper-SFN (H-SFN) frame structure is defined on top of the SFN used for regular idle mode DRX. Each H-SFN value corresponds to a cycle of the legacy SFN of 1024 radio frames, i.e. 10.24s. When extended idle mode DRX is enabled for a UE, the UE is reachable for paging in specific Paging Hyperframes (PH), which is a specific set of H-SFN values. The PH computation is a formula that is function of the extended idle mode DRX cycle, and a UE specific identifier, as described in TS 36.304 [35]. This value can be computed at all UEs and MMEs without need for signalling. The MME includes the extended idle mode DRX cycle length and the PTW length in paging message to assist the eNodeB in paging the UE.

The MME also assigns a Paging Time Window length, and provides this value to the UE during attach/TAU procedures together with the extended idle mode DRX cycle length. The UE first paging occasion is within the Paging Hyperframe as described in TS 36.304 [35]. The UE is assumed reachable for paging within the Paging Time Window. The start and end of the Paging Time Window is described in TS 36.304 [35]. After the Paging Time Window length, the MME considers the UE unreachable for paging until the next Paging Hyperfame.

4.5.13.3.2 Loose Hyper SFN synchronization

NOTE: This clause applies for extended DRX cycle lengths of 10.24s or longer.

In order for the UE to be paged at roughly similar time, the H-SFN of all eNodeBs and MMEs should be loosely synchronized.

Each eNodeB and MME synchronizes internally the H-SFN counter so that the start of H-SFN=0 coincides with the same a preconfigured time epoch. If eNodeBs and MMEs use different epochs, e.g. due to the use of different time references, the GPS time should be set as the baseline, and the eNodeBs and MMEs synchronize the H-SFN counter based on the GPS epoch considering the time offset between GPS epoch and other time-reference epoch a preconfigured time. It is assumed that eNodeBs and MMEs are able to use the same H-SFN value with accuracy in the order of legacy DRX cycle lengths, e.g. 1 to 2 seconds. There is no need for synchronization at SFN level.

There is no signalling between network nodes required to achieve this level of loose H-SFN synchronization.

4.5.13.3.3 MME paging and paging retransmission strategy

NOTE: This clause applies for extended DRX cycle lengths of 10.24s or longer.

When the MME receives trigger for paging and the UE is reachable for paging, the MME sends the paging request. If the UE is not reachable for paging, then the MME pages the UE just before the next paging occasion.

The MME determines the Paging Time Window length based on paging retransmission strategy, and uses it to execute the retransmission scheme.

If the UE is unreachable for paging, then MME may follow clause 4.5.7 "High latency communication" for functionality related to Mobile Terminated communication with high latency.

4.5.14 Non-IP Data Delivery (NIDD)

4.5.14.1 General

Functions for NIDD may be used to handle mobile originated (MO) and mobile terminated (MT) communication with UEs, where the data used for the communication is considered unstructured from the EPS standpoint (which we refer to also as Non-IP). The support of Non-IP data is part of the CIoT EPS optimizations. The Non-IP data delivery to SCS/AS is accomplished by one of two mechanisms:

– Delivery using SCEF;

– Delivery using a Point-to-Point (PtP) SGi tunnel.

The delivery using a Point-to-Point (PtP) SGi tunnel is further described in TS 23.401 [7].

NIDD via the SCEF is handled using a PDN connection to the SCEF. The UE may obtain a Non-IP PDN connection to the SCEF either during the Attach procedure (see clause 5.3.2.1 of TS 23.401 [7]) or via UE requested PDN connectivity (see clause 5.10.2 of TS 23.401 [7]) or via PDP Context Activation Procedure (see clause 9.2.2.1 of TS 23.060 [6]).

NOTE 1: The UE is not made aware that a particular Non-IP PDN connection is provided via SCEF or via PGW. However, the network informs the UE whether a particular Non-IP PDN connection uses Control plane CIoT Optimization (see TS 23.401 [7]).

An association between the SCS/AS and a PDN Connection to the SCEF needs to be established to enable transfer of non-IP data between the UE and the SCS/AS. When the Reliable Data Service is not enabled, the SCEF determines the association based on provisioned policies that may be used to map an SCS/AS identity and User identity to an APN. When the Reliable Data Service is enabled, the SCEF determines the association based on port numbers and provisioned policies that may be used to map SCS/AS identities and User identity to an APN (see clause 4.5.14.3).

NOTE 2: When more than one SCS/AS is associated with the same PDN Connection, it is permissible for packets to or from one port number to be associated with more than one SCS/AS. Also, any polices that are applied to the PDN Connection (e.g. APN Rate Control), apply to traffic from all of the SCS/AS’s that are associated with the PDN Connection.

NIDD via SCEF uses the User Identity, APN, and the SCS/AS identity to identify which UE a particular T6a/T6b connection belongs to. The User Identity is the user’s IMSI. The user’s IMSI shall not be used on the interface between SCEF and SCS/AS. In order to perform NIDD configuration or to send or receive NIDD data, the SCS/AS shall use MSISDN or External Identifier to identify the user. In order to facilitate correlation of SCS/AS requests to T6a/T6b connection for a given UE, the HSS provides to the SCEF (see NIDD Configuration procedure in clause 5.13.2) the user’s IMSI, and if available, the MSISDN (when NIDD Configuration Request contains an External Identifier) or if available, External Identifier (when NIDD Configuration Request contains an MSISDN).

Depending on operator configuration, the SCEF may perform buffering of MO and/or MT Non-IP data. In this release of specification, neither the MME/SGSN nor the IWK-SCEF are expecting to buffer data pertinent to PDN connection to the SCEF.

The Protocol Configuration Options (PCO) may be used to transfer parameters between the UE and SCEF (e.g. maximum packet size). The PCO’s information shall be passed transparently through the MME/SGSN. As specified in TS 23.401 [7] and TS 23.060 [6], the PCO is sent in the EPS Session Management signalling between UE and MME and in GPRS Session Management signalling between UE and SGSN.

The SCEF applies rate control as described in clause 4.7.7 of TS 23.401 [7].

4.5.14.2 Enhancements for reliable delivery of NIDD

To ensure reliable delivery of Non-IP data (NIDD) between UE and SCEF using the Control Plane CIoT EPS Optimization, the following functions may be supported by the 3GPP system:

– Reliable delivery by acknowledgements on a hop-by-hop basis, i.e. the link layer protocol on each interface used for NIDD uses acknowledgments and nodes apply retransmissions if needed to ensure reliable delivery.

– The UE may retransmit UL data that was not acknowledged by the RLC on the AS layer in the UE;

– The MME may retransmit DL data for which it got a non-delivery indication from the eNodeB (see e.g. clause 5.3.4B.3, step 15 of TS 23.401 [7]);

– The MME indicates to the SCEF the status of the DL data delivery. The SCEF may forward this status to the AS;

– Disabling/enabling of MME retransmission is handled by a subscription parameter ‘Acknowledgements of downlink NAS data PDUs’.

4.5.14.3 Reliable Data Service

The Reliable Data Service may be used by the UE and SCEF or P-GW when using PDN Connection of PDN Type ‘Non-IP’. The service provides a mechanism for the SCEF or P-GW to determine if the data was successfully delivered to the UE and for UE to determine if the data was successfully delivered to the SCEF. When a requested acknowledgement is not received, the Reliable Data Service retransmits the packet. The service is enabled or disabled based on APN Configuration per SLA.

When the service is enabled, a protocol is used between the end-points of the Non-IP PDN Connection. The protocol uses a packet header to identify if the packet requires no acknowledgement, requires an acknowledgement, or is an acknowledgment and to allow detection and elimination of duplicate PDUs at the receiving endpoint. Reliable Data Service supports both single and multiple applications within the UE. Port Numbers in the header are used to identify the application on the originator and to identify the application on the receiver. The UE, the SCEF and the P-GW may support reservation of the source and the destination port numbers for their use and subsequent release of the reserved port numbers. Reliable Data Service protocol (as defined in TS 24.250 [47]) also enables applications to query their peer entities to determine which port numbers are reserved and which are available for use at any given time.

During NIDD Configuration, the SCS/AS may indicate which serialization formats it supports for mobile originated and mobile terminated traffic in the Reliable Data Server Configuration. When port numbers are reserved by the UE, the serialization format that will be used by the application may be indicated to the SCEF. When port numbers are reserved by the SCEF, the serialization format that will be used by the application may be indicated to the UE. If the receiver does not support the indicated serialization format, it rejects the port number reservation request and the sender may re-attempt to reserve the port number with a different serialization format. If, during NIDD Configuration, the SCS/AS indicated that it supports multiple serialization formats, the SCEF determines the serialization format that it will indicate to the UE based on local policies and previous negotiations with the UE (e.g. the SCEF may indicate the same serialization format that was indicated by the UE or avoid indicating a serialization format that was previously rejected by the UE). When serialization formats are configured for reserved port numbers, the SCEF stores the serialization formats as part of the Reliable Data Service Configuration and provides the updated Reliable Data Service Configuration to the SCS/AS.

NOTE: Whether the UE Application or SCS/AS supports a given serialization format is outside the scope of 3GPP specifications.

The UE indicates its capability of supporting Reliable Data Service in the Protocol Configuration Options (PCO) to the SCEF or P-GW. If SCEF or P-GW supports and accepts Reliable Data Service then it indicates to the UE, in the PCO, that the Reliable Data Service shall be used if enabled in the APN configuration.

In order to prevent situations where a Reliable Data Service instance needs to interface to both the user and control plane, the Reliable Data Service may only be used with PDN connections for which the "Control Plane Only" indicator is set or with PDN connections using the Control Plane EPS CIoT Optimization when the MME does not move PDN connections to the user plane. The Control Plane CIoT EPS Optimization is defined in TS 23.401 [7].

4.5.15 Support of PFD management via SCEF

The PFDs may be managed by the 3rd party SCS/AS via the SCEF, which ensures the secure access to the operator’s network even from the 3rd party SCS/AS in untrusted domain. The 3rd party SCS/AS may request to create, update or remove PFDs in the PFDF via the SCEF.

The specific procedure for PFD management via SCEF is described in clause 5.14.1.

4.5.16 MSISDN-less MO-SMS via T4

MSISDN-less MO-SMS via T4 is subscription based. The subscription provides the information whether a UE is allowed to originate MSISDN-less MO-SMS. Support for subscription without MSISDN is defined in TS 23.012 [36].

The UE is pre-configured with the Service Centre address that points to SMS-SC that performs this MO-SMS delivery via MTC-IWF delivery procedure. The recipient of this short message is set to the pre-configured address of the SCS/AS (i.e. Address of the destination SME). If UE has multiple external IDs associated to the same IMSI, the external ID that is associated with an SMS may be determined from the UE’s IMSI and the Application Port ID value in the TP-User-Data field (see TS 23.040 [12]). The MTC-IWF may obtain the external-ID by querying the HSS with the IMSI and application port ID via S6m.

UE is aware whether the MO-SMS delivery status (success or fail) based on the SMS delivery report from SMS-SC. The network does not perform any storing and forwarding functionality for MO-SMS.

NOTE: This way of communicating small data is considered an intermediate method that will eventually be replaced by Non-IP Data Delivery (NIDD) procedures.

4.5.17 Enhanced Coverage Restriction Control via SCEF

Restriction of use of the Enhanced Coverage is specified in TS 23.060 [6] and TS 23.401 [7]

The support for Enhanced Coverage Restriction Control via SCEF enables 3rd party service providers to query status of, enhanced coverage restriction or enable/disable enhanced coverage restriction per individual UEs. The specific procedure for Enhanced Coverage Restriction Control via SCEF is described in clause 5.16.

4.5.18 MBMS user service for UEs using power saving functions

MBMS Bearer Services as defined in TS 23.246 [29] together with MBMS User Services defined in TS 26.346 [38], or MBMS Bearer Services accessed via the MB2 interface defined in TS 23.468 [30], provide means to deliver data or triggering payload over broadcast to multiple UEs at the same time. However, for devices using power saving functions, e.g. Power Saving Mode (defined in clause 4.5.4) or extended idle mode DRX (defined in clause 4.5.13), the UEs are usually unreachable for long periods of time. Moreover, different UEs are likely to be reachable at different times. Therefore, it is important that the time intervals the UE stays awake to receive MBMS user service or to discover if there is any MBMS user service scheduled for delivery, should not necessarily be the same as the reachable intervals negotiated for extended idle mode DRX or PSM.

If a UE becomes unreachable for unicast service due to either PSM or extended idle mode DRX, the UE may still perform MBMS specific procedures, e.g. activation/deactivation of the MBMS bearer service, MBMS data transfer reception, reception of service announcement (if needed), as defined in TS 23.246 [29] and TS 26.346 [38].

For those intervals the UE needs to be awake for MBMS bearer service, the following cases can be identified:

1. When the UE’s need to be awake due to MBMS coincides with the UE already being in connected mode due to other reasons, the UE follows normal connected mode procedures.

2. When the UE’s need to be awake due to MBMS coincides with the UE already being in idle mode and reachable (e.g. in active time for PSM or PTW for eDRX) the UE follows normal idle mode procedure.

3. When the UE’s need to be awake due to MBMS coincides with the UE being in idle mode and in deep sleep, i.e. unreachable for paging to the network, the UE leaves the deep sleep state only to perform procedures related to MBMS service.

– If the MBMS user service does not require the UE to transition to connected mode, i.e. the UE receives MBMS user service in idle mode, then the UE does not update the MME to become reachable for paging. The UE would therefore still be considered unreachable for paging in the MME. This minimizes the signalling between the UE and the network.

– If the MBMS user service requires the UE to transition to connected mode (e.g. for HTTP reception reporting, file repair, etc.) then the UE performs regular procedures for ECM connected mode. This would therefore make the UE become reachable in the network for other unicast services.

4. When the UE is in the middle of an MBMS data transfer, and the UE is scheduled to move to deep sleep due to power saving, e.g. end of PTW for extended idle mode DRX or expiration of active time for PSM, then the UE does not go to deep sleep during the remainder of the current MBMS data transfer.

NOTE 1: If at the end of the current MBMS data transfer, the UE knows there is another MBMS data transfer scheduled soon, in that case depending of the time between MBMS data transfers, the UE can decide to go to sleep between MBMS data transfers.

There are two possible ways the UE can be notified of an upcoming MBMS broadcast session start:

1. If MBMS User Services defined in TS 26.346 [38] is used, the UE needs to receive MBMS service announcement while awake (i.e. while in connected mode, or while idle mode during PTW for extended idle mode DRX, or active time for PSM). The UE wakes up if not already awake for MBMS service reception based on the schedule received in the service announcement. For this option, the MBMS service announcement may be provided via MBMS broadcast service announcement or via any of the possible unicast service announcement delivery mechanisms defined in TS 23.246 [29]. If MBMS access via the MB2 interface as defined in TS 23.468 [30] is used, similar mechanisms need to be provided by the application layer using unicast mechanisms.

NOTE 2: In order to allow all UEs using power saving function to receive the service announcement in time to be able to receive the MBMS broadcast data delivery, the application server needs to be aware of the maximum unreachable period of the UEs.

2. The UE may be configured by the application server with specific times to perform MBMS procedures, and wakes up from deep-sleep if needed at those times. The UE may also receive MBMS service announcements and/or MBMS broadcast delivery at those times (if needed).

NOTE 3: The configuration (e.g. TMGI, start time) is out of scope of 3GPP and assumed to be performed between application server and UE at application layer. The application server needs to initiate MBMS bearer service procedures during those time intervals.

4.5.19 Enhancements to Location Services for CIoT

Location Services (LCS) are defined in TS 23.271 [33]. In order to support Location Services for CIoT UEs, following enhancements to Location Services are defined (refer to TS 23.271 [33] for detailed procedures):

– Deferred location for the UE availability event:

– When extended idle mode DRX or PSM is used, a deferred location request for UE available event allows an LCS Client to obtain the UE location as soon as the UE becomes available.

NOTE: Without deferred location for UE available event, an LCS Client can configure a Monitoring Event for UE Reachability and issue a Mobile Terminated Location Request (MT-LR) when the UE reachability is reported, but this will fail if the UE becomes unreachable again before the MT-LR is performed.

– The procedures for deferred location from V-GMLC to the external client and the EPC Mobile Terminating Location Request (EPC-MT-LR) procedure are combined properly in the V-GMLC as specified TS 23.271 [33].

– Indication of UE RAT type and/or coverage level to Evolved Serving Mobile Location Centre (E-SMLC):

– Providing an E-SMLC with an indication of the RAT type and/or the coverage level may enable the E-SMLC to appropriately determine a maximum size, maximum frequency and maximum transfer delay for positioning messages sent to and from the UE.

– RAT type and coverage level indications from the MME to the E-SMLC are introduced in TS 23.271 [33].

– For the case of coverage level, and indication of coverage level from eNB to MME is introduced.

– Support of UE positioning measurements in idle mode:

– NB-IoT UEs or Cat-M1 UEs may perform measurements for some positioning methods only when in ECM-IDLE state due to minimal resources.

– An E-SMLC that is aware of this (e.g. from an indication sent by the UE) may allow additional response time to the UE (e.g. in the QoS) to obtain the measurements. An MME that is aware of this (e.g. from the UE access type) may also allow additional time for a location session to complete.

– Addition of Periodic and Triggered Location for EPC:

– A flexible periodic and/or triggered Mobile Terminated Location Request (MT-LR) capability is useful to enable UE location at times other than when a UE normally becomes available and/or with better granularity than a cell ID.

– New procedures are introduced in TS 23.271 [33] to initiate and maintain deferred periodic and triggered event reporting and to cancel reporting by an LCS client, UE or network entity. The area event, periodic event and motion event are clarified in the context of EPC access. Impacts to LCS messages between an LCS Client and GMLC, between GMLCs and between an H-GMLC and PPR are included.

– Support of Last Known Location for a UE that are unreachable for long periods of times:

– For UEs that are unreachable for long periods of time, e.g. using extended idle mode DRX or PSM, last known location support enables an external LCS client to receive some information on UE location without waiting (e.g. a few hours) for the UE to become reachable.

– The EPC-MT-LR procedure defined in TS 23.271 [33] is enhanced to support last known location based on a last known serving cell.

4.5.20 MBMS user service for NB or M UE categories

TS 36.306 [41] defines UE categories M1, M2 for WB-E-UTRAN and NB1, NB2 for NB-IoT that can only support limited bandwidth and transport block size. In order for UEs of these categories to be able to receive MBMS service, E-UTRAN needs to be able to determine the UE category that applies to the specific service indicated by the TMGI.

In order for E-UTRAN to know the UE categories for MBMS bearer service, the UE Capability for MBMS (which includes UE Category for MBMS and optionally associated coverage level for MBMS) is provided by SCS/AS to the BMSC via the SCEF. Using PLMN specific QCI information, the characteristics are signalled by the BM-SC to E-UTRAN following the procedures described in clause 5.5.1 of the present specification and TS 23.246 [29]. This includes:

– QCI(s) that are determined taking into account the UE Category for MBMS that indicates the "M" or "NB" category (M1, M2, NB1, NB2) as defined in TS 36.306 [41] that can receive the service indicated by the TMGI. E-UTRAN uses the QCI to determine the radio parameters that would determine the categories of UEs that are required to receive the service. EUTRAN is configured with the QCI to UE Category for MBMS mapping.

NOTE 1: The way UE Category for MBMS needs to be interpreted is to allow PLMN specific QCI to be derived by the BMSC that would allow the MBMS service to be received by each UE type. For example, for UE Category for MBMS "M1 and M2", a QCI will be derived that will map to radio configuration that would allow M1 and M2 UEs to receive the service over the radio interface. For UE Category Info "NB2", a QCI will be derived that will map to radio configuration that would allow only NB2 UEs to receive the service over the radio interface.

– Optionally, the SCS/AS may provide additional information regarding the coverage level for the related MBMS service. The coverage level indicates if the MBMS service is intended to be received by UEs located in extended coverage and is used by E-UTRAN to determine the radio configuration required, e.g. determine the number of repetitions, to reach the UEs that receive the MBMS service. Three levels of Coverage Level for MBMS are defined as "normal", "medium" and "high". The coverage level information, when provided, shall be reflected via the QCI.

NOTE 2: It is up to E-UTRAN implementation how the coverage level information can be used.

NOTE 3: A single QCI does not allow for both NB and M category UEs to receive the same service indicated by one TMGI.

4.5.21 Network Parameter Configuration via SCEF

The SCS/AS may issue network parameter configuration requests to the network, via the SCEF, to suggest parameter values that may be used for Maximum Latency, Maximum Response Time and Suggested Number of Downlink Packets. By suggesting values for these parameters, the SCS/AS may influence certain aspects of UE/network behaviour such as the UE’s PSM, extended idle mode DRX, and extended buffering configurations. Based on operator’s configuration, the SCEF and HSS may choose to accept, reject or modify the suggested configuration parameter value. The SCEF indicates accepted/modified values to the SCS/AS. This feature can also be used to suggest parameter values for a group of UEs.

NOTE: The SCS/AS can observe how the MME ultimately configures the UE for PSM and extended idle mode DRX by configuring "UE Reachability" or "Availability after DDN failure" notifications with the Idle Status Indication option (see clause 4.5.7).

The specific procedure for Network Parameter Configuration via SCEF is described in clause 5.18.

4.5.22 RACS information provisioning

The UCMF (UE radio Capability Management Function) stores all UE Radio Capability ID mappings in a PLMN and is responsible for assigning every PLMN-assigned UE Radio Capability ID in this PLMN, see TS 23.401 [7]. Provisioning of Manufacturer-assigned UE Radio Capability ID entries in the UCMF is performed from an AS that interacts with the UCMF either directly (according to TS 23.502 [48] and TS 29.675 [49]) or via the SCEF (according to TS 29.122 [44] or via Network Management).

4.5.23 Support of satellite access

Support of satellite access for NB-IoT, WB-E-UTRAN and LTE-M is specified in TS 23.401 [7]. Unless otherwise stated in this specification, MTC functionality applies to NB-IoT, WB-E-UTRAN and LTE-M over satellite access. To support satellite access for NB-IoT, WB-E-UTRAN and LTE-M, the system enhancements including satellite RAT type, network/access selection, verification of UE location and Tracking Area Update, etc., are defined in TS 23.401 [7].