Content for TS 23.682 Word version: 18.0.0

1… 4.2 4.3… 4.4… 4.5… 4.5.7… 4.5.14… 4.6… 5… 5.3… 5.5… 5.6… 5.6.2… 5.6.6… 5.7… 5.8… 5.9… 5.13… 5.14… 5.15 5.16 5.17… 5.18 5.19… A… C…

4.5.7 High latency communication 4.5.8 Support of informing about potential network issues 4.5.9 Resource management of background data transfer 4.5.10 E-UTRAN network resource optimizations based on communication patterns provided to the MME 4.5.11 Support of setting up an AS session with required QoS 4.5.12 Change the chargeable party at session set-up or during the session 4.5.13 Extended idle mode DRX
...

4.5.7 High latency communication |R13| p. 30

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.

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 |R13| p. 31

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 |R13| p. 31

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.

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 to provide the respective policing and charging information to the PCEF.

4.5.10 E-UTRAN network resource optimizations based on communication patterns provided to the MME |R13| p. 31

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. 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 |R13| p. 32

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.

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 specifications and transfers the request to provide QoS for an AS session to the PCRF via the Rx interface.

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 |R13| p. 32

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 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 |R13| p. 32

4.5.13.1 General p. 32

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.

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.

The specific negotiation procedure handling is described in TS 23.060 and TS 23.401.

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:

Enable only PSM, i.e. not accept the request for extended idle mode DRX.
Enable only extended idle mode DRX, i.e. not accept the request for an active time.
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.

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 and TS 23.401, and applies techniques to handle mobile terminated SMS according to TS 23.272 and location services according to TS 23.271.

4.5.13.2 Paging for extended idle mode DRX in UTRAN p. 33

The procedure makes use of the regular DRX cycle mechanism for determination of Paging Occasions (POs) (see TS 25.304) 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.

Copy of original 3GPP image for 3GPP TS 23.682, Fig. 4.5.13.2-1: The usage of PTW and independence of the extended Idle mode DRX cycle from UE state

Figure 4.5.13.2-1: The usage of PTW and independence of the extended Idle mode DRX cycle from UE state
(⇒ copy of original 3GPP image)

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

4.5.13.3.0 General p. 34

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

For extended idle mode DRX cycle length of 5.12s, regular paging strategy as defined in TS 23.401 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 p. 34

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

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

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.