Content for  TR 22.865  Word version:  19.2.0

This use case illustrates the realization of a S&F service between a UE with satellite access and an Application Server for a delay-tolerant/non-real-time IoT NTN service in the case of a Mobile Terminated message. A description of store and forward operation is provided in Annex A. Company TrackingInc offers a service of remote monitoring of fields and deploys and tracks many battery-powered IoT type UEs across the globe. All the IoT remote monitoring UEs deployed include a 5G communication with satellite access. Some of the UEs are deployed in a remote area where there is no mobile coverage by MNO and only satellite is possible. For the satellite access, TrackingInc uses the service of IoTSAT for the 5G IoT connectivity by satellite and IoTSAT uses a LEO constellation which supports S&F operation mode. All IoT remote monitoring UEs regularly send information related to the area they are monitoring to the application server of TrackingInc and sometimes receive new parameters from the application server. In most of the cases, the messages exchanged are delay-tolerant/non-real-time IoT.

In the present use case, the IoT remote monitoring UE is in a remote area with no ground stations available for feeder link connectivity and the IoT remote monitoring UE is aware that IoTSAT constellation operates in S&F mode.

The TrackingInc application server needs to send new parameters to the IoT remote monitoring UE. Based on the information provided by the network, the application server is aware that the communication with UE is in S&F mode. The TrackingInc application server message will send new parameters through dedicated messages by conventional means (e.g. IP routing, tunnels) to the network entry-point (e.g. a SCEF, PDN-GW, SMSC), and may provide additional information about the delivery priority, the acknowledgement, etc. to the network. At this point:

• Limitations on the amount of data to be transferred to the IoT remote monitoring UE could be enforced.
• Forwarding priority to the UE could be established.
• Acknowledgement of the received data by the network could be issued to the application server, possibly with the additional information about the store and forward, e.g. estimated time to deliver the messages.
• End-to-end acknowledgement policy can be established.

The network stores the message until it can be delivered/relayed to a satellite expected to fly over and provide coverage to the destination IoT remote monitoring UE. When the satellite is connected via the feeder link to the ground network, the message is uploaded into the satellite. All accumulated and stored MT messages are uploaded into the satellite via the feeder link. At the same time, all accumulated and stored MO messages are also delivered to 5GC via the same feeder link, which will cause a performance impact on the feeder link, satellite, and 5GC. It needs a performance optimization method here.When flying over the area that the IoT remote monitoring UE is located, the satellite with the stored message triggers paging over the service link for the UE to connect to the network. The stored message is delivered/downloaded from the satellite to the IoT remote monitoring UE. Acknowledgment may be requested/issued. Mechanisms to ensure integrity of the delivered information may be in place.

The message generated by the TrackingInc application server has been delivered successfully to the IoT remote monitoring UE without relying on a continuous end-to-end network connectivity path between them.

Clause 6.3.2.3 of TS 22.261 on satellite access includes the following requirements: However, it is not sufficient in regards of S&F operation especially for the delivery of delay-tolerant/non-real-time IoT NTN services with NGSO satellites.

[PR 5.2.6-001] [PR 5.2.6-002] [PR 5.2.6-003] [PR 5.2.6-004] [PR 5.2.6-005] [PR 5.2.6-006] [PR 5.2.6-007]