Content for  TS 23.401  Word version:  19.1.0

Basic support for discontinuous coverage is specified in clause 4.3.5.2 and clause 4.3.17.7. The present clause 4.13.8 provides additional optional enhancements to discontinuous coverage:

• Mobility management and power saving optimization, see clause 4.13.8.2; and
• Coverage availability information provisioning to the UE, see clause 4.13.8.3; and
• Coverage availability information provisioning to the MME, see clause 4.13.8.4; and
• Paging, see clause 4.13.8.5; and
• Overload control, see clause 4.13.8.6.

In the following, "Enhanced Discontinuous Coverage" functionality includes the following enhancements as listed above: Mobility management and power saving optimization described in clause 4.13.8.2, and Overload control described in clause 4.13.8.6. During Attach or TAU procedures, a UE supporting Enhanced Discontinuous Coverage provides "Enhanced Discontinuous Coverage Support" indication as part of UE Core Network Capability in the Attach Request or TAU Request message to the MME. The MME receiving an Attach Request or a TAU Request message from the UE including "Enhanced Discontinuous Coverage Support" indicates whether Enhanced Discontinuous Coverage is supported by providing the "Enhanced Discontinuous Coverage Support" indication to the UE in the Attach Accept or TAU Accept message.

For satellite access that provides discontinuous network coverage, and in case both the UE and the network support Enhanced Discontinuous Coverage, then the Mobility Management and UE Power Saving Optimization functionality may be used. If both the UE and the network indicate support for "Enhanced Discontinuous Coverage Support" and if the UE determines it will lose coverage and will become unavailable, and decides to remain in no service during that time, then:

• The UE may be able to determine, including considering current and expected future locations of the UE, a Start of Unavailability Period and/or Unavailability Period Duration for when it expects to be out of coverage.
• The UE triggers a TAU procedure and includes an indication of upcoming loss of coverage in the TAU Request message to the MME. If the UE is able to determine a Start of Unavailability Period and/or Unavailability Period Duration it also includes them in the TAU Request message.
• The UE should trigger the TAU procedure early enough such that the procedure, under normal conditions, is able to complete before the start of the unavailability period.
• The UE and the MME re-negotiate unavailability at every TAU procedure, if it is required. If Start of Unavailability Period and/or Unavailability Period Duration is not included in a TAU Request message any pending loss of coverage configuration stored in the UE context at MME is discarded.
• If the UE determines an upcoming loss of coverage to the network no longer applies or determines a new Start of Unavailability Period or Unavailability Period Duration related to the upcoming loss of coverage, the UE sends a new TAU Request to the MME to update the Start of Unavailabililty Period and/or Unavailability Period Duration.

Upon receiving a TAU Request message from the UE including an indication of upcoming loss of coverage or Attach request message:

• If the UE did not include a Start of Unavailability Period in the TAU Request message, the MME considers implicitly the Start of Unavailability Period to be the time at which it has received the TAU Request message from the UE. If the UE included a Start of Unavailability Period, the Start of Unavailability Period indicates the time at which the UE determines it expects to lose coverage, i.e. time until which the UE determines it is available.
• The MME may determine, if not provided by the UE, or update the Unavailability Period Duration and/or the Start of Unavailability Period.
  If the MME knows an Unavailability Period Duration and/or the Start of Unavailability Period (e.g. based on information available to the MME as described in clause 4.13.8.4) for the UE, and the UE not include an Unavailability Period Duration and/or the Start of Unavailability Period or included an Unavailability Period Duration and/or the Start of Unavailability Period different to the Unavailability Period Duration and/or the Start of Unavailability Period known to the MME, the MME should include the Unavailability Period Duration and/or the Start of Unavailability Period known to the MME in the TAU Accept or Attach Accept message and use those values in subsequent steps of this procedure. How the UE treats the MME provided Unavailability Period Duration and/or the Start of Unavailability Period is up to UE implementation e.g. to help to determine when to return to coverage after a discontinuous coverage period, whether to listen to paging in eDRX, not to initiate any NAS signalling (including Service Request for MO data) within the discontinuous coverage period in case of any UL signalling/data request or the UE may deactivate its Access Stratum functions for satellite access in order to optimise power consumption until coverage returns, etc.
• The MME indicates to the UE in the Attach Accept or TAU Accept whether the UE is not required to perform a TAU procedure when the unavailability period has ended.
  The MME indicates to the UE in the Attach Accept or TAU Accept whether the UE is not required to perform a TAU procedure when the unavailability period has ended.
• The MME stores the information that the UE is unavailable at the Start of Unavailability Period in the UE context, and considers the UE is unreachable from then until the UE enters ECM_CONNECTED state.

If the UE requests power saving features the MME uses procedures defined in other clauses to provide the UE with timers (e.g. periodic TAU timer, extended idle mode DRX (see clause 5.13a), and PSM mode configuration (see clause 4.3.22)), and may also consider the Unavailability Period Duration (if available) and Start of Unavailability Period (if available). Unless the MME indicated that the UE is not required to perform a TAU procedure when the unavailability period has ended, then once the event which makes the UE unavailable is completed in the UE, the UE triggers a TAU procedure. If the event which makes the UE unavailable is delayed to a future time or cancelled or unavailability period deviates from negotiated value in the UE, the UE triggers TAU procedure. The MME should adjust the mobile reachable timer or Implicit Detach timer or both such that the MME does not implicitly detach the UE while the UE is out of coverage, see clause 4.3.5.2. Features described for High latency communication in clause 4.3.17.7 may be used to handle mobile terminated (MT) communication with UEs being unreachable due to satellite access with discontinuous coverage and the Unavailability Period Duration (if available) and Start of Unavailability Period (if available) may be used when determining the Downlink Buffering Duration time. The UE may send Tracking Area Update request message to inform the network of its UE unavailability period even if Mobility Management back-off timer is running.

A UE may use satellite coverage availability information for satellite access to support discontinuous coverage operations. Satellite coverage availability information can be provided to a UE by an external server via a PDN Connection or SMS. The protocol and format of satellite coverage availability information via PDU Connection or SMS is not defined in this release of the specification, but some examples on the information that constitutes the satellite coverage availability information is defined in Annex N.

The MME may use satellite coverage availability information to support satellite access by UEs with discontinuous coverage operation. Satellite coverage availability information may be provisioned to the MME by O&M. The satellite coverage availability information is not UE specific and can be applied by the MME for any UE in the affected area.

In the case of satellite access that provides discontinuous network coverage, the MME may utilize sub-area paging (e.g. first page in the last known ECGI or TA and retransmission in all registered TAs). The MME may utilize the location information as received at or before the S1 release due to the discontinuous coverage for paging optimisation. The MME may e.g. receive UE location from eNodeB during the Attach or TAU procedure e.g. triggered for Mobility Management and Power Saving Optimization for discontinuous network coverage as described in clause 4.13.8.2, or the MME may request the Location Reporting Procedure when the UE is in ECM_CONNECTED state as described in clause 5.9.1.

The MME and UE may only use the procedure defined in this clause if both the UE and MME indicate "Enhanced Discontinuous Coverage Support", see clause 4.13.8.1. In order to avoid a large number of UEs causing excessive signalling load on the network when leaving coverage or re-gaining coverage after being out of coverage, the MME may determine a Maximum Time Offset controlling when UEs are allowed to initiate NAS signalling with the network, as described in this clause. In this case, the MME determines this Maximum Time Offset based on network configuration, high priority access and priority services. The MME sends this Maximum Time Offset to individual UEs during the Attach or TAU procedures. If the UE receives this Maximum Time Offset from the network in an Attach or TAU Accept, the UE shall replace any previously received Maximum Time Offset on the same RAT type and PLMN with this one. When the UE knows a later time at which coverage will be lost and when the UE does not send a TAU Request to the MME in advance (see clause 4.13.8.2), the UE determines a random value up to the minimum of the latest Maximum Time Offset for this PLMN and RAT type and the time until coverage will be lost. The UE shall send the TAU Request at the time when coverage will be lost less the random value to the MME indicating the loss of coverage. Upon returning to coverage after being out of coverage due to discontinuous coverage, the UE sets the discontinuous coverage wait timer value to a random value up to and including the latest Maximum Time Offset for this PLMN and RAT type, and starts this timer. The UE shall not initiate any NAS signalling on that RAT Type and PLMN while the discontinuous coverage wait timer is running. The UE shall stop the discontinuous coverage wait timer and initiate NAS signalling if the UE receives paging message, has pending emergency services or when UE enters a Tracking Area outside the current Tracking Area List.

The Store and Forward Satellite Operation applies in E-UTRAN with satellite access and is suitable for delay-tolerant communication services (e.g. CIoT/MTC, SMS, etc.). If the satellite does not support Store and Forward Satellite operation and there is no feeder link connection to the ground network, then the satellite cannot provide any service to any UEs. When both the service link and feeder link are available, all services can be provided. To support Store and Forward Satellite operation, some network functionality needs to be deployed on the satellite payload. Example deployments are described in Annex O.

In Store and Forward Satellite operation, the end-to-end exchange of signalling/data traffic is handled in a sequence of steps reflecting the intermittent availability of the service link when the satellite can exchange data with the UE and of the intermittent availability of the ground link when the satellite can exchange data with the core network. This is depicted in Figure 4.13.9.1-1. For example, a simple sequence of events for the transmission of data from the UE to a server on the ground may involve two steps: firstly, when service link is available (e.g. location L1 in Figure 4.13.9.1-1) the UE sends the data to the satellite. Subsequently (e.g. location L2 in Figure 4.13.9.1-1), the satellite carrying the payload connects to the ground network and delivers the UE data to the network. Downlink data can be stored onto the same or a different satellite and provided to the UE later using the first step and the process is repeated. When a satellite supports Store and Forward Satellite operation and is operating in S&F Mode, the on-board eNodeB broadcasts an indication of operating in S&F Mode as described in TS 36.300, which the UE uses to determine the current operation mode of the satellite. If a satellite is operating in S&F Mode and if a UE is enabled for Store and Forward Satellite operation, then the UE indicates the S&F capability during Attach and Tracking Area Update. The MME may adapt periodic update timer, mobile reachable timer and Implicit Detach timer to the fact that the UE is served in S&F mode. When an MME is operating in S&F Mode:

• If the MME cannot complete a NAS procedure with the information currently available on the satellite e.g. when the MME does not have UE security context or, if the MME needs to retrieve UE-specific authentication vectors or subscription information from the ground network, it shall reject the NAS procedure. In this case, if the UE supports Store and Forward Satellite operation, the MME shall include a reject cause indicating the NAS rejection is due to S&F operation.
• If a UE indicates Store and Forward capability, the MME may provide to the UE a S&F Wait Timer when accepting or rejecting a NAS procedure.

When the S&F Wait Timer expires, the UE may perform a NAS procedure, which can be a subsequent NAS procedure or a reattempt of a NAS procedure previously rejected with a S&F reject cause. If the UE did not indicate Store and Forward capability in NAS signalling, if the network determines to reject the UE, the network shall reject the UE request with a cause non-specific to S&F Mode. The MME may indicate to UE the Uplink S&F estimated delivery time in NAS messages (Attach accept or TAU accept message or service accept). How UE uses this information is left for UE implementation. The MME may trigger a Update Location procedure with the HSS along with the authentication procedure to fetch subscription information from the HSS. The MME may indicate the timestamp information to HSS during the Update Location procedure. This timestamp information shall be used by the HSS to ensure that newer location for that UE is not cancelled. If MME makes an Update Location Request before the completion of the authentication procedure, it shall include an indication that this Location Update is provisional, i.e. the HSS shall not consider the UE as registered until it receives the final Update Location Request (without indication that the Location Update is provisional). The timestamp information is the time when the on-board of satellite MME part has received the NAS procedure from the UE. The HSS compares the timestamp received in the Update Location Request with any stored timestamp of a previous Update Location Request and determines whether to accept or reject the request. If the received Update Location Request does not include a timestamp, the HSS assumes the present time as the timestamp of the received Update Location Request. The HSS shall reject the Update Location Request, if the timestamp associated with this request is older than the stored timestamp. If the HSS accepts the Update Location Request, the HSS shall store the timestamp associated with the latest Update Location Request. If the HSS does not support the timestamp, the MME shall reject a UE Attach request for S&F Mode. The EPS may expose whether a UE is in S&F Mode and provide to the SCS/AS related timing information to guide the SCS/AS decision when to try to contact the UE. This is further described in clause 5.6.3.10 of TS 23.682.