Content for TS 23.401 Word version: 19.1.0

1… 4… 4.2.2… 4.3… 4.3.6… 4.3.8… 4.3.12… 4.3.16… 4.3.20… 4.3.25… 4.4… 4.6… 4.7… 4.13… 5… 5.1.2… 5.3… 5.3.2… 5.3.3… 5.3.3.2 5.3.3.3… 5.3.4… 5.3.4B… 5.3.5… 5.3.8… 5.3.9… 5.4… 5.4.4… 5.5… 5.5.1.2… 5.5.2… 5.5.2.2… 5.5.2.3… 5.5.2.4… 5.6… 5.7.3… 5.7A… 5.10 5.11… 5.19… D… D.3… D.3.4 D.3.5 D.3.6 D.3.7… D.3.8… E F… J… K… L… M… O…

O.1 Introduction O.2 Model A: Split MME architecture O.3 Model B: Full EPC in each satellite O.3.1 General O.3.2 Architecture and Principles of Operation O.3.3 Support of MO and MT Transactions

O Example Models of Store and Forward Satellite operation |R19| p. 457

O.1 Introduction p. 457

This Annex provides guidance on deployment options to support store and forward satellite operation.

O.2 Model A: Split MME architecture p. 457

In this architecture option (see Figure O.2-1):

eNB is onboard the satellite.
MME is split into two functions:
1. MME-onboard: the MME part which is onboard the satellite. MME-onboard is in charge of (1) handling the S1 interface with the onboard eNB and (2) handling the NAS protocol signalling from/to UEs via the onboard eNB.
2. MME-ground: the MME part which is on the ground network. MME-ground is in charge of handling the rest of interfaces towards other CN functions (e.g. S6a towards HSS, SGd towards SMS-GMSC/IWMSC /SMS Router, T6a towards SCEF, T6ai towards IWF-SCEF, S11 towards SGW).

Reproduction of 3GPP TS 23.401, Fig. O.2-1: "Split-MME" architecture for supporting S&F satellite operation for SMS and CP CIoT services

Figure O.2-1: "Split-MME" architecture for supporting S&F satellite operation for SMS and CP CIoT services

The split-MME architecture has below principles:

An MME-ground is associated with at least one MME-onboard. An MME-onboard is associated with a Satellite ID identifier. The MME-ground together with the associated MME-onboard(s) behave jointly as a single MME entity.
How MME-onboard(s) interacts with MME-ground and how synchronization of the UE context between them is done is outside the scope of 3GPP.

NOTE:
Based on implementation, the UE context can be uploaded on a subset of MME-onboard(s) or all MME-onboard(s) associated with MME-ground.
When a UE initiates a MO procedure that needs an interaction with a core network node on the ground, the MME-onboard stores the MO procedure transaction if the feeder link is not available and synchronizes with the MME-ground when the feeder link becomes available. The MME-ground executes the procedure with the ground network nodes and syncs back the UE context with the MME-onboard when the feeder link becomes available.
The MO data is stored in the MME-onboard when the service link is available and the feeder link is unavailable, and transferred to the MME-ground when the feeder link becomes available. The MT data is stored in the MME-ground when the feeder link is unavailable and transferred to the MME-onboard when the feeder link becomes available. The MME-ground determines the satellite through which to send MT data and the MT data is sent to the respective MME-onboard and stored in the MME-onboard when the feeder link is available, and transferred to the UE when service link becomes available.
For MO SMS, if the feeder link is not available upon reception of the MO SMS the MME-onboard can store the MO-SMS and can immediately send the delivery report (i.e. RP-ACK) to the UE i.e. as if the MO-SMS has already been successfully delivered to the Service Centre (SC). Once the feeder link is established the MO-SMS is forwarded to the SC. Subsequently the SC sends the RP-ACK to the UE. The MME-ground can also discard the RP-ACK received from the SC.
To support UE location verification on satellite, the E-SMLC, if needed, can be deployed on satellite to perform the verification of UE location functionality.
For the monitoring event which allows the SCS/AS to be notified of Store and Forward Satellite operation (see clauses 5.6.1.11 and 5.6.3.10 of TS 23.682) the SCS/AS communicates with HSS and MME-ground to configure and/or delete Monitoring Event.
For data transfer, only Control Plane CIoT EPS Optimization applies.

O.3 Model B: Full EPC in each satellite p. 458

O.3.1 General p. 458

This clause describes an example of Model B for support of Store and Forward Satellite operation as defined in clause 4.13.9.

O.3.2 Architecture and Principles of Operation p. 458

An example architecture of Model B is shown in Figure O.3.2-1. Each satellite contains the functionally of an eNB plus a full EPC that can include an MME, SGW, PGW, HSS, E-SMLC, SMSC etc. Each satellite further includes an endpoint proxy function that emulates the behaviour of a real endpoint (e.g. an AF) from the perspective of a UE. There is also store and forward functionality on the ground that can be part of, or connected to, an NTN Gateway and that contains the proxy functionality.

Reproduction of 3GPP TS 23.401, Fig. O.3.2-1: Example Architecture of Model B

Figure O.3.2-1: Example Architecture of Model B

For Model B, the signalling and procedures used between a UE and satellite to support UE access and UE services in S&F operation are the same as used between a UE and serving PLMN for normal satellite access except for the differences described in clause 4.13.9. A UE thus sees the onboard eNB and EPC as being equivalent to a serving PLMN for normal operation. Some PLMN services cannot be available for S&F operation due to subscription restriction for a UE or lack of support by the onboard eNB and/or EPC.

A UE accesses and attaches to a satellite for Model B as described in clause 4.13.9. The onboard EPC can obtain the UE location and verify that the UE is allowed to access the PLMN that was selected by the UE. The UE can then establish PDN connections to the onboard EPC and utilise them for the services that are supported in S&F operation.

Depending on what is supported by the onboard eNB and EPC, the UE can perform mobile originated (MO) transactions such as sending SMS, and sending data (e.g. using IP or non-IP protocols) using User Plane or Control Plane CIoT EPS optimisation. Each MO transaction is transferred by the onboard EPC to the onboard endpoint proxy which stores transaction data and signalling (e.g. SMS, data,) and associated protocol and remote endpoint data. The onboard endpoint proxy also returns responses to the UE at a transport and application level that are necessary to allow correct transport and application protocol operation, avoid timeouts and enable a user (if participating) to be aware of the one way communication status.

Shortly before satellite coverage will be lost, the onboard EPC can detach the UE.

After the UE loses coverage and when the satellite obtains a feeder link to a ground based portion of the serving PLMN selected by the UE for the Attach, the satellite (or the onboard endpoint proxy) transfers data for the UE (e.g. the IMSI and last known UE location), and all of the stored data and signalling for the UE MO transactions, to an S&F function for the serving PLMN. The S&F function might contain a proxy that stores the data and signalling for the UE MO transactions and then forwards the data and signalling for each MO transaction to the associated remote endpoint. The proxy can also receive and store data and signalling for mobile terminated (MT) transactions that can be returned by the remote endpoints to the UE.

The S&F function and proxy can simulate continuous reachability of the UE. The MT transaction data and signalling for the UE (e.g. the IMSI) received and stored by the proxy are transferred to one or more satellites that are expected to later provide coverage to the UE.

When MT data is transferred to the satellite(s), the onboard endpoint proxy subscribes to the reachability of the UE and optional PDN connectivity status related information for data transmission, e.g. T8 destination address for non-IP data, UE IP address for IP data. When the UE accesses and attaches to the satellite, the endpoint proxy sends MT data to the UE based on the notification from onboard EPC, e.g. sends non-IP data to the T8 destination address or replaces the target IP address for IP data to UE's IP address and sends to PGW.

O.3.3 Support of MO and MT Transactions p. 460

An MO or MT transaction for Model B can correspond to:

Transfer of an SMS message.
Transfer of data to or from a remote endpoint using Control Plane CIoT EPS optimisation or User Plane.