The VAL server decides to use SEALDD service for delay-tolerant traffic transfer and allocates address/port as SEALDD-S Data transmission connection information for receiving the data packets from SEALDD server. The VAL server sends Sdd_DTwithS&FTransmission request to the SEALDD server discovered by CAPIF. The service request includes UE ID/address, VAL server ID, VAL service ID, SEALDD-S Data transmission connection information of the VAL server side.

Upon receiving the request, the SEALDD server performs an authorization check. If authorization is successful, SEALDD server allocates the SEALDD-S data transmission connection information (e.g., address/port) of SEALDD server side to receive the application data packets from the VAL server to be delivered to the VAL UE. The SEALDD server responds with a Sdd_DTwithS&FTransmission response.

Same as step 3-9 of clause 9.2.2.2.

The SEALDD server subscribes the UE S&F status events from the 3GPP CN and is notified about the UE S&F status events information e.g., whether UE is registered in S&F Mode, the estimated delivery time indicating the DL estimated time to send data from the UE to gateway or from gateway to UE. The SEALDD server stores or the received UE S&F status events information for further control the downlink application data transmission.

The VAL server sends downlink application data to the SEALDD server which further delivers it to the VAL UE.

The SEALDD server controls the downlink application data delivery to the SEALDD client based on the UE S&F status events information, when the UE is in S&F mode:

• pending the DL data transmission when the Feeder Link is not available;
• (re-)transmitting the pending DL data when the Feeder Link is available.
• DL data volume to be transmitted is smaller than maximum S&F data storage quota per application per UE.
• If DL estimated delivery time is received from 3GPP CN, it may be used by the SEALDD server to estimate whether the transmitted DL application data is successfully delivered to the UE and its corresponding storage is available for new DL data. For each Feeder Link available period, the SEALDD server starts an estimated delivery timer based on the DL estimated delivery time which is corresponding to the current feeder link. The estimated delivery timer may be greater than or equal to the DL estimated delivery time. When in next Feeder Link available period, the SEALDD server checks the previous estimated delivery timer is expired or not before transmitting the DL data. Also, the maximum S&F data storage quota per application per UE is also considered.

1. If timer expires, the SEAL server calculates the new DL data volume (e.g., increasing the volume by certain data size (e.g., size of data previously delivered to the SEALDD client)).
2. If timer not expire, the SEALDD server also checks the available data volume within the maximum S&F data storage quota. The SEALDD server may send DL data limited within the available data volume. If no available data volume, the SEALDD server pends the DL data transmission until the timer expires.

The SEALDD server sends the DL data to the VAL UE via the 3GPP network as indicated in step 11.

Optionally, the SEALDD server may send Sdd_DTwithS&FTransmission notification to the VAL server to influence the DL application data transmission from VAL server if the VAL UE connection status changes or the DL data transmission from the VAL server needs to be adjusted.