Novel Architecture for Cellular IoT in Future Non-Terrestrial Networks: Store and Forward Adaptations for enabling Discontinuous Feeder Link Operation

The Internet of Things (IoT) paradigm has already progressed from an emerging technology to an incredibly fast-growing field. Defined as one of the three key services in 5th Generation (5G), massive Machine Type Communications (mMTC) are intended to enable the wide-spread adoption of IoT services across the globe. Satellite-based Non-Terrestrial Networks (NTN) are crucial in providing connectivity with global coverage including rural and offshore areas, that are fundamental to support important use cases in future networks. A rapidly growing market for IoT devices with mMTC applications using NarrowBand-IoT (NB-IoT) will represent a large share of user equipment (UE) in such areas. While standardization efforts for NTN are underway for forthcoming 3GPP releases, they focus on transparent payload architectures where the satellite platform is necessarily connected to a ground station gateway to be able to provide satellite access services to the IoT devices, thus requiring complex ground segment infrastructure in low Earth orbit (LEO) constellation deployments for achieving global coverage. In contrast, satellite network deployments targeting the delivery of delay-tolerant IoT applications using NB-IoT, which are a major mMTC use case, can benefit from architectures based on the use of regenerative payloads in the satellite and support for Store and Forward (S&F) operation where satellite access can remain operational even at times when the satellite is not connected to a ground station. In particular, such an approach would allow for extending satellite service coverage in areas where satellites cannot be connected to ground stations (e.g. maritime or very remote areas with lack of ground-stations infrastructures), improving ground segment affordability by enabling operation with fewer ground-stations and allowing more robust operation of the satellite under intermittent feeder link operation. In this paper, we provide a high-level design of an extended 3GPP architecture featuring store and forward mechanisms for IoT NTN delay-tolerant applications that addresses the previous challenges, as well as a laboratory validation of said architecture for a specific use case.

or offshore coverage.
Inhibiting factors for greater adoption of these technologies are the absence of global coverage and limited roaming between networks offering IoT services. A large number of use cases may benefit especially from global coverage. Non-Terrestrial Networks (NTN) using satellites with cellular NB-IoT technology are well positioned to fill the gap, providing both global coverage and standardized roaming interfaces. In pursuit of these opportunities, NB-IoT satellite operators are starting to appear who attempt to provide global IoT service using standardized 3GPP protocols [4].
Standardization of 3GPP networks using satellite communication as NTN is currently underway and will be part of Rel-17, which is due in June 2022. Major use cases for NTN in future 3GPP releases include coverage extension, service reliability improvement and using NTN's multicast and broadcast capabilities to enable scalability [5].
The justification for the extension of the standard is based on a number of industries that have been identified for needing IoT operation anywhere on Earth: Transportation (maritime, road, rail, air) and logistics, Solar, oil and gas harvesting, Utilities, Farming, Environment monitoring, Mining, etc. [6]. Acknowledging the market potential and need for standardization in cellular IoT, 3GPP is working on adaptations to the current standard for the deployment of massive Machine Type Communications (mMTC) services using Long-Term Evolution-Machine Type Communication (LTE-M) and NB-IoT protocols via NTN.
The rise of small satellites over recent years removes cost barriers and thus enables both small low-cost constellations and large mega constellations spanning the globe [7]. Particularly, CubeSat 1 technology in spacecraft that can use commercial off-the-shelf (COTS) components drastically cuts the cost of deployment of satellites, especially in low Earth orbit (LEO) deployments.
3GPP work for NTN encompasses both 5th Generation (5G) New Radio (NR) adaptations, targeting broadband access services via satellite, and NB-IoT/LTE-M adaptations, directed at mMTC via satellite. Current extensions to the standard address basic challenges of NTN networks, but further study items in the area of NTN have been identified for Rel-18 and Rel-19, thus being an essential part of future 5G-Advanced/6th Generation (6G) networks to support global connectivity [9]. Possible access architectures for satellite based NTN include relay-like architectures where the satellite payload is transparent, and regenerative architectures. In transparent payloads, the Evolved Node B (eNB)/Next Generation Node B (gNB) is located on the ground segment. In contrast, regenerative payloads maintain a eNB/gNB components in the satellite payload [5]. NTN architectures can be deployed using geostationary or geosynchronous equatorial orbit (GEO), medium Earth orbit (MEO) or LEO satellite constellations. However, providing access via LEO satellites is more affordable when focusing on the cost factor of space missions. Small, low-density satellite constellations in LEO orbits provide a cost advantage over large and complex LEO, GEO or mixed satellite deployments. Furthermore, complex mega constellations with thousands of satellites are not needed for delay-tolerant IoT applications.
Non-Geostationary-Satellite Orbits (NGSO) are an intrinsic characteristic of LEO satellite constellations. The key drawback of transparent payloads is their inherent requirement of the link between satellite and ground stations (feeder link) being available in order to work. In areas where it is not feasible to deploy a ground station, e.g., in remote or offshore locations, transparent payload systems cannot provide service. Consequently, a LEO constellation, with discontinuous availability of the feeder link, leads to the requirement of a regenerative payload that is able to operate under discontinuous backhauling in order to be able to provide global coverage. Additionally, reducing the need for ground stations directly impacts the cost of operations.
A key service that can benefit from enabling regenerative LEO architectures with discontinuous connectivity is mMTC for IoT, where non-real-time services tolerate the additional delay introduced by a discontinuous backhaul.
Standard 3GPP core network components assume continuous connectivity between its components, allowing only small delays of a few seconds in response to interactions. This cannot be ensured in case of discontinuous satellite connectivity, especially when satellite visibility with the User Equipment (UE) and ground station are non-concurrent.
The main contribution of this paper is twofold. First, we propose a novel 3GPP core network architecture that enables delivery of cellular IoT services over LEO constellations with discontinuous feeder link availability. Our architecture features a novel functional split between the satellite payload and the ground segment, with three novel proxy functions featuring store and forward technology, that are not considered in current 3GPP NTN specifications. Second, we provide a validation of the proposed architecture in a laboratory environment.
The paper is organized as follows. In Section II we give the motivation and an overview of current 3GPP standardization efforts, followed by Section III, which contains an analysis of common procedures that can be affected by discontinuity and points to the discontinuity challenges to be addressed. Section IV introduces a novel architecture that can accommodate the outlined discontinuity challenge. In Section V, the proposed architecture is validated in a lab environment. Finally, a summary of the most relevant achievements and the future work is found in Section VI.

II. CURRENT 3GPP ARCHITECTURAL APPROACH AND LIMITATIONS
NTN operation is adamant to be complementary to terrestrial deployments. In combination with NB-IoT's standardized roaming interfaces, mobility and scalability are crucial advantages over existing, proprietary solutions that offer satel-lite based global IoT connectivity [10]. Satellite operators providing coverage extension towards Mobile Network Operators (MNOs) implement these standardized interfaces for user authentication and user data pipeline in the case of home routed traffic.
In a typical scenario, the satellite operator has its own Public Land Mobile Network (PLMN) ID with its own licensed carrier. Visiting subscribers roaming from a terrestrial MNO have a different PLMN ID than the one of the satellite operator. During roaming, visiting subscribers still need to authenticate with their MNO's Home Subscriber Server (HSS). This implies that particularly the HSS, providing authentication vectors, is always ground based for roaming purposes. Thus, a ground based infrastructure is required that provides the standardized roaming interfaces to other MNOs in a continuous manner.
Taking advantage of the increase in allowed path-loss in the NB-IoT specification, an extension of its coverage using LEO satellites has been proposed. 3GPP working groups investigating NTN scenarios initially considered two payload architectures: (1) transparent payloads and (2) regenerative payloads. However, regenerative payloads, with the Radio Access Network (RAN) node on the satellite, were only addressed at study level as part of the 3GPP Service and System Aspects Working Group 2 (SA2) studies. For the normative phase, the regenerative architecture is no longer considered. The reasoning here is that existing fleets of deployed satellites in GEO can be taken advantage of, as well as simplicity.
In both architectures, the core network is placed in the ground segment. In LEO deployments, the main challenges in the service link compared to ground based applications lie in the largely increased Doppler effect due to the satellites' high relative velocity to the earth surface as well as to link budged constrains mainly introduced by the satellites' altitude (typically 400 − 800 km) [11], [12]. These challenging channel conditions in the service link lead to implications in the actual data rate that can be achieved, although low data rate requirements by IoT devices may not be restricted by this. Similar conditions apply to the feeder link. However, better channel conditions can be achieved largely due to no restrictions in the ground station's radio hardware, allowing large antennas and powerful signal processing and amplification. Satellite constellations with discontinuous service and feeder link operation introduce additional challenges in the core network.
In the following subsection, we give an overview of 3GPP's work regarding NTN extensions to the standard.

A. 3GPP NTN IOT STANDARDIZATION EFFORT
Work at 3GPP is structured in Study Items (SIs), which cover feasibility analysis and identification of potential solutions, and Work Items (WIs), which determine the specific solutions and conduct the normative changes into the specifications. SIs and WIs addressing NTN extensions to the standard encompass 5G NR and NB-IoT/LTE-M. The architecture, developed in this paper, targets use cases that rely on NB-IoT for mMTC services. Thus, we focus specifically on studies and WIs related to NB-IoT in the following. A first SI related to this topic is the 'Study on Narrow-Band Internet of Things (NB-IoT) / enhanced Machine Type Communication (eMTC) support for Non-Terrestrial Networks (NTN)', approved in December 2019 with the aim to identify scenarios that apply for NB-IoT/eMTC over satellites, while reusing as many conclusions as possible from the related study on NR NTN (TR 38.821 [13]). The study was concluded in July 2021, and its outcomes are documented in the technical report TR 36.763 [6] as part of Rel-17. The main contributions of this study are related to the radio access side, that is most affected by NTN: • Mechanisms for Uplink pre-compensation at the UE side of time and Doppler frequency shifts and DL frequency synchronization enhancements. • Timing relationships adjustments and new time offsets in the different protocol procedures (random access, contention resolution, scheduling, hybrid automatic repeat request, etc.) to compensate for satellite propagation delays.
Based on the work in the above-mentioned study, 3GPP has concluded that it is necessary to support NB-IoT/eMTC in future NTN applications. Consequently, several WIs were created: '3GPP Work Item NB-IoT/eMTC support for Non-Terrestrial Networks' with sub-items targeting (1) Network core and (2) Architecture support (see Table 1). These WIs started in June 2021 and have been mostly concluded in March 2022, with some parts still in progress with a planned finalization in June 2022 as part of the feature freeze of Rel-17, that is also due in June 2022. VOLUME  In the working group's first meeting in RAN#92-e on 14 -18 Jun 2021, the following basic assumptions were established: (1) UE has Global Navigation Satellite System (GNSS) capabilities and (2) satellites' payloads are transparent. Therefore, in NTN standard extensions for Rel-17, network processing capabilities are assumed to be on the ground and the satellite is strictly used as a repeater. One should note, that the stipulation of GNSS capabilities in a UE mandates increased complexity of devices and potentially increased power consumption.
Moreover, system information enhancements, including the broadcasting of satellite ephemeris information, are proposed by 3GPP discussions. Mobility management improvements to cope with moving satellite cells and enhancements to tracking area management using the earth-fixed Tracking Area (TA) concept are also added. Support of discontinuous coverage (the concept of discontinuous coverage is further discussed in the next section) of the service link, without excessive UE power consumption and without excessive failures / recovery actions is studied by 3GPP.
While initially considering regenerative payloads, current WIs have been derived under the assumption of transparent payloads, where the service link can only be operational on par with a feeder link (see Fig. 1. Thereby, falling short in enabling constellations with discontinuous feeder link connectivity that necessitate regenerative payloads. Delaytolerant IoT applications that do not require continuous connectivity, can still greatly benefit from global coverage and roaming capabilities that can be offered by a constellation, which can be deployed without prohibitive cost.

III. DISCONTINUITY CHALLENGE
LEO satellite constellations with limited number of ground stations lead to discontinuity. In small, low density LEO constellations with tens or few hundreds of satellites, one can assume revisit times in the magnitude of hours and visibility windows in the magnitude of minutes [12]. An architecture that can accommodate discontinuity and non-concurrent operation of both service and feeder link relies on store and forward mechanisms. Specifically, maintaining a functioning service link independent of ground station connectivity is a crucial feature not being accounted for in the 3GPP work that is based on the assumption of transparent payload. In a mobile network, that historically assumes continuous connectivity between the core network components, the following EPS Mobility Management (EMM) procedures need to be investigated for discontinuity operation: Attach/Detach, (periodic) Tracking Area Update (TAU), data transmission/reception, Service Request and Paging.
In the signaling between the UE and the network, which is required for mobility and session management, a number of timers are present on both the UE and network side. The majority of these timers are in the order of multiple seconds. With the introduction of NB-IoT, the RAN interface to the core network (S1) can operate in either WB-S1 mode or NB-S1 mode. The latter can be used by a UE to access network services via NB-IoT. Therefore, the NB-S1 mode would be the preferred one. In NB-S1 mode, the signaling timers for mobility and session management are extended by 240 s for mobility management timers and 180 s for session management timers, respectively [14]. Thus, both network and UE side timers are significantly increased from being in the range of few seconds to the range of minutes. This timer extension for NB-IoT does help mitigate delays in signaling introduced by the NTN channel. However, with timers being in the order of minutes, signaling between UE and network for a Non-access stratum (NAS) procedure needs to be completed within a single UE satellite visibility period when assuming non-concurrent and discontinuous service and feeder link.
On the core network side, we focus on 4G core (EPC) as this is what is defined in the standard for NB-IoT NTN. However, the architecture extensions developed in this research are equally valid for a 5G core. After establishing a radio connection on the radio access side, NAS signaling between UE and Mobility Management Entity (MME) is used to perform EMM and EPS Session Management (ESM) procedures. In the core network, In the following subsections, we analyze the most relevant and potentially affected procedures with focus on the involved timers. A summary of the timers for each discussed procedure is presented in Table 2.

A. EMM SPECIFIC PROCEDURES
NAS signaling in EMM specific procedures includes the attach, detach and tracking area updating procedure. Fig. 2 illustrates the NAS signaling between UE and MME, as well as S6a signaling between MME and HSS for a regular attach procedure for a NB-IoT UE. The attach procedure is initiated by the UE with its 'ATTACH REQUEST' message (step 1 in Fig. 2) to the MME. Amid sending this message, the UE starts a timer (T3410) within which it expects the attach procedure to conclude by either receiving an 'ATTACH AC-CEPT' message (step 10 in Fig. 2) or a 'ATTACH REJECT' message. In NB-S1 mode, this timer has a value of 255 s (see Table 2).

1) Attach Procedure
Following the UE's 'ATTACH REQUEST' message, authentication, and security mode messages are exchanged between UE and MME. In order to perform authentication and security mode messaging, the MME needs authentication vectors generated by the HSS. For this purpose, it sends an Authentication Information Request (AIR) to the HSS. In response, the HSS returns an Authentication Information Answer (AIA) that contains the authentication vectors. These vectors are used to validate the UE's identity and to establish temporary NAS keys for encrypted signaling. Authentication vectors do not include timestamps, thus, their validity is not restricted by temporal length. However, they are only valid once, so for each attach procedure, new vectors need to be obtained. Authentication and security mode messaging are initiated by the network (steps 4 and 6 in Fig. 2), which starts the network side timer T3460 and stops it when receiving the corresponding response (steps 5 and 7 in Fig. 2). Now that the UE is authenticated, and a security context is established, the MME needs to obtain information about the UE's subscription. For that, it sends an Update Location Request (ULR) to the HSS, that is responded with an Update Location Answer (ULA) (steps 8 and 9 in Fig. 2). The subscription information is needed to provide session related information for the following message to the UE.
The attach procedure is concluded with the 'ATTACH ACCEPT' message (step 10 in Fig. 2) sent to the UE that contains session related information such as the IP address that is assigned to the UE, quality of service parameters, Access Point Name (APN), the UE's Globally Unique Temporary ID (GUTI) and timers that are defined by the network for following procedures. The UE acknowledges this with an 'ATTACH COMPLETE' message (step 11 in Fig. 2) to the network.
Typically, after completing the attach procedure, the network sends an 'EMM INFORMATION' message to the UE (step 12 in Fig. 2). In this message, the network informs the UE about the network name and local time, among others. This message is optional.
A UE context containing temporary identifiers and security keys, among others, that is required for further signaling between UE and core network is created in both UE and MME.

2) Tracking Area Updating
If a UE moves from one TA into another, it is required to perform a TAU procedure. Additionally, there is periodic TAU, that is controlled by timer T3412 on the UE side. On expiry of this timer, the UE is required to send a periodic TAU message to the network. This timer is specified by the network, and is mandatorily sent to the UE in the 'ATTACH ACCEPT' message to the UE during the initial attach procedure, and optionally it can be sent to the UE in 'TRACKING AREA UPDATE ACCEPT' messages. Its default value is 54 min, but with Extended Discontinuous Reception (eDRX) it can be as high as 413 days. During regular TAU message exchange, the UE send a 'TRACKING AREA UPDATE REQUEST' message to the MME, starts T3430 (see Table 2) and stops it upon reception of 'TRACKING AREA UPDATE ACCEPT' from the MME. With T3430 having a value of 255 s, this procedure needs to be completed within a single UE ↔ satellite visibility window.
While TAU timers do not necessary require adaptation for discontinuous NTN applications, the general concept of TAs need to be addressed for NTN. In traditional ground based networks, TAs are tied to geographical areas. A TA is composed of multiple eNBs/gNBs and the RAN equipment remains stationary for the time of its deployment. Typically, the TA is a value configured in the eNB/gNB.

3) Detach Procedure
In order to deregister a UE from a network and thereby removing UE context, the detach procedure is initiated. NAS signaling in detach procedures also involves timers. However, due to the nature of radio communication and its intrinsic possibility of lacking connectivity, the implicit detach is a standard procedure that doesn't require signaling between UE and network. In case a regular detach is initiated by the UE, it sends a 'DETACH REQUEST' message to the MME, starts timer T3421 and stops this timer when it receives the corresponding 'DETACH ACCEPT' message. If the detach procedure is network initiated, the MME sends a 'DETACH REQUEST' message to the UE, starts timer T3422 and stops this timer upon reception of the 'DETACH ACCEPT' message. VOLUME 1, 2022 While both network initiated and UE initiated detach signaling needs to be completed within the same UE satellite visibility period, failure to do so can be compensated by implicit detach of the UE. The implicit detach is triggered after a series of timers expires. First, when the periodic TAU timer expires and no TAU procedure could be performed, the mobile reachable timer is started. Once this timer is also expired, it is assumed that the UE is out of coverage. This is followed by commencing the implicit detach timer. On its expiry, the UE is finally detached from the network without any NAS signaling. The value of each timer is network dependent. The mobile reachable timer is set to a value that is equal to T3412 plus 4 minutes in a typical case, that is, when a UE is not attached for emergency bearer. Finally, the implicit detach timer is normally set to the same value that is defined for T3412.
In case the HSS initiates a detach procedure for operator determined purposes, two steps are required. A satellite needs to first have ground station visibility to be notified about the detach procedure, and then it can either detach the UE during a following UE visibility period or perform an implicit detach.

B. USER DATA TRANSMISSION -EMM CONNECTION MANAGEMENT PROCEDURES
A UE registered with the network can send Mobile Originated (MO) and receive Mobile Terminated (MT) traffic. In addition to being registered with the network, the UE needs to have established a NAS signaling connection with the MME, thus, being in EMM Connection Management (ECM)-Connected mode, as opposed to being in ECM-Idle mode when there is no signaling connection with the MME. In order to avoid taking up radio resources and preserve battery, which is particularly important for NB-IoT UEs, the majority of the time, a UE will reside in ECM-Idle mode. In order to transition between states, so that user data traffic can be transmitted, ECM procedures need to be performed. Following, we detail these procedures.

1) Service Request
In order for the UE to transfer from ECM-Idle into ECM-Connected mode, a service request procedure needs to be performed. When the UE sends a 'SERVICE REQUEST' message to the MME, it starts T3417 (see Table 2), with a value of 245 s or 250s for an extended service request in NB-S1. The timer is stopped upon reception of either a 'SERVICE ACCEPT' or a 'SERVICE REJECT' message from the MME. The service request procedure is crucial for moving into ECM-Connected state and is a requirement to transmit data. Therefore, this procedure need to be completed within a single UE ↔ satellite visibility window.

2) Paging
Paging is required when a UE is registered with the network and in ECM-Idle mode, and the network needs to establish a NAS signaling connection. This is typically the case when MT traffic is pending to be transmitted to the UE, but the UE is in ECM-Idle mode, thus NAS signaling needs to be established to trigger a transfer into ECM-Connected mode. When the MME requests paging, it starts T3413 or T3415 in case of eDRX and stops the respective timer upon reception of a SERVICE REQUEST message from the UE. Both parameters are network dependent and therefore, they can be chosen in a manner that suits the deployment. Please note that 3GPP does not specify explicit values for this reason. In general, a requirement for a successful paging procedure is that UE ↔ satellite visibility is given when paging is initiated and the UE should respond within the same visibility window.
The paging procedure is indirectly affected by the necessity to initiate paging at the correct moment in time when UE ↔ satellite visibility is given. In relation to this fact, tracking of a UEs location is a relevant issue to be solved.
Furthermore, mechanisms to preserve power including eDRX and PSM can affect paging, due to UE reachability being reduced by these procedures.

3) Generally affected timers
Apart from the previously mentioned timers that are present in the specific and most relevant procedures, it is imperative to mention other timers that are significantly impacted by the discontinuity.
One of these timers is T3402 on the UE side. This timer is initiated on 5 consecutive attach or tracking area update failures. The value of this timer can be defined by the network during EMM signaling. However, it is an optional Information Element (IE). If the network does not specify a specific value, the UE assumes a default value of 12 minutes. In a scenario with discontinuous UE ↔ satellite visibility, this default value is inappropriate due to possible extended out of coverage periods. Since the network has the possibility to define a larger value or even disable this timer, it is possible to choose an appropriate setting according to estimated satellite coverage patterns over the UE, thus requiring no further changes to this timer in the standard adaptations for NTN.

C. CHALLENGES SUMMARY
The main challenge, that affects the above-mentioned procedures, is that the NAS signaling needs to be concluded within a few minutes. Discontinuous and non-concurrent operation of both service and feeder link in a low density LEO satellite constellation require that the procedure is resolved within a single UE ↔ satellite visibility window. A summary of these challenges is listed in Table 3.
In order to complete the NAS signaling for the attach procedure, security and subscription information shall be necessarily available on the satellite. The required information that is obtained from the HSS is not restricted by timers, it is possible to retrieve this information prior or at the same time of performing the NAS signaling for the attach procedure.
Related to MO and MT traffic, moving into ECM-Connected state is a crucial process, so that MO and MT 6 VOLUME 1, 2022 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication.  After analyzing the impact of discontinuity, in the next section, we propose an extension to the network architecture that (1) is compliant with the 3GPP architecture and interfaces and (2) has a specific configuration of the core network functions allowing for the support of store and forward operation.

IV. PROPOSED ARCHITECTURE
Our proposed architecture addressing the challenges of lowdensity LEO constellations with discontinuous feeder link availability is developed under a number of design principles: 1) We assume a regenerative satellite payload.
2) We assume a system where the satellite operator has an independent core that has a roaming relation with MNOs. 3) Services provided by the NTN architecture are non-real time, but based on delay tolerant traffic. Both MO and MT traffic is supported. 4) The satellite operator deploys a small satellite constellation that offers revisit times in the order of hours or days and visibility windows in the order of minutes. Simultaneous availability of service and feeder link cannot be assumed. 5) NAS signaling procedures need to be concluded within a visibility window. Thus, implying NAS processing capabilities on the satellite. 6) Satellite and ground station elements contain store and forward capabilities to mitigate the challenges outlined in the previous section. Addressing low density LEO constellations with discontinuous feeder link availability is achieved by the proposed architecture that relies on regenerative satellite payloads containing store and forward mechanisms. Fig. 3 illustrates   The device's IoT application handles use case specific user data messages. Regenerative payload satellites provide radio access by a eNB/gNB as well as components that are required to complete interactions within the same visibility window. Specifically, by placing the MME on the satellite, we can address the challenge of completing NAS signaling procedures within minutes (Ch. 1 in Table 3) as well as within a single UE ↔ satellite visibility window (Ch. 3 in Table 3). Furthermore, proxy elements containing store and forward entities for control plane as well as user data plane messaging are part of each satellite too. The ground segment contains similar store and forward entities as the satellites, with added orchestration to optimize the forwarding to the appropriate satellite. Other Network core components are running in the ground station, possibly in a public cloud provider, offering standard roaming interfaces to other MNOs and to enable connectivity to IoT service platforms. Subsequently, we present the relevant aspects in this architecture that are enabled by three novel proxy elements with store and forward mechanisms: Finally, we discuss other relevant architecture aspects related to NTN. The time necessary for authentication is at least the time it takes for a satellite to pass over the UE, a ground station, and the UE again. In case of mobile originated and mobile terminated traffic, the delay is the time it takes between a satellite passing a ground station and then the UE or vice versa.
Attaching a UE to a NTN with discontinuous feeder link availability requires a minimum of four steps, as shown in Fig. 4. Crucial messaging with the HSS during the attach are authentication information and update location procedures, as shown in Fig. 2. In a regular, non-discontinuous scenario, the update location procedure is only conducted after successfully completing the authentication. However, in a discontinuous scenario, it appears more efficient to complete both procedures with the HSS at the same time via proxy modules. Fig. 5 shows the exchanged messages in each step of Fig. 4 so that, signalling messages can be related to each required step in the UE attachment process. In the first UE ↔ satellite flyover (step 1 in Fig. 4), the UE gets into cell coverage, establishes a radio link with the satellite's eNB/gNB and sends the Initial Attach message to the onboard MME. The MME now needs to perform an AIR towards the MNO's HSS. This entity is not present on the satellite; hence, the MME queries the onboard store and forward entity ('S6a Auth Proxy SAT' in Fig. 5) that buffers messages for authentication purposes. As this is the very first attach request from this UE, no AIA is available on the satellite. The store and forward entity buffers the UE's International Mobile Subscriber Identity (IMSI) information for AIR as well as ULR until flying over an available ground station for its resolution. Subsequently, the MME sends an Attach Reject message to the UE. This Attach Reject contains an error code, indicating the reject cause. We propose to introduce a novel reject error code that indicates that the UE's Attach Request is being processed, with indication of the next UE ↔ satellite visibility window, where the attach procedure can be completed. The signaling for this first step is illustrated in Step 1 in Fig. 5.
The second step in the attach procedure is the AIR and ULR resolution on the ground station. During feeder link availability with the ground station, the satellite's store and forward entity forwards the cached IMSIs that are pending AIR resolution to the ground station's Authentication Proxy component. This list is now processed on the ground station, where the Authentication Proxy element sends AIR(s) as well as ULR(s) to the corresponding MNO HSS. The generated AIA, containing required vectors for UE authentication, and ULA, containing subscription information, are buffered in the ground station's store and forward entity ('S6a Auth Proxy GS' in Fig. 5). Fig. 5 shows the signaling for this second step (Step 2).
Vectors present in the ground station are sent to the satellites' store and forward entity in the third step. This can be the same satellite, that performed step one and two, but also any other satellite that passes over the ground station. Now, the satellite has all the required information to authenticate UEs that are waiting to complete the network attach. Please note that step two and three can be performed during a single satellite ↔ ground station flyover. Fig. 5 depicts the signaling for the third step (Step 3).
The fourth and final step in the discontinuous attach procedure is the second UE ↔ satellite flyover. The UE comes into coverage again and sends an Attach Request message again. The MME sends the AIR to the onboard Authentication Proxy component, which can now provide the AIA back to the MME. UE and MME can proceed with the mutual authentication and the UE registers with the network. Furthermore, the MME resolves the ULR with the store and forward entity. The network uses subscription information provided in the ULA to assign an IP address to the UE, and establish an Evolved Packet System (EPS) bearer. Fig. 5 presents the signaling of this last step (Step 4).

B. USER DATA PROXY
Store and forward requirements for user data traffic (Ch. 4 in Table 3) are addressed by the User Data Proxy, which is composed of an onboard satellite component and a ground based component. Once the UE is attached to the network, both MO and MT traffic is permitted and needs to be transmitted. The User Data Proxy addresses Ch. 4 in Table 3. For the transmission of MO and MT traffic, between UE and satellite, the UE must be in MME-Registered state (the UE attach procedure has been completed) as well as in ECM-Connected state (radio and network resources are assigned to the UE). Step 2

SAT -GS visibility
Step 4 For MT traffic, coming to the ground station, a store and forward entity is needed on the ground station as well as on the satellite. MT packets have to be buffered on the ground until feeder link availability with a satellite allows packet forwarding to the satellite. Based on UE location and satellite ephemerides, a specific satellite can be chosen by the ground station module in order to minimize delay in the delivery of MT traffic. Once user data packets are received by the satellite, the satellite's onboard User Data Proxy component buffers the packets until the service link to the destination UE is available. In case the UE is in ECM-Idle state, paging has to be initiated. The satellite's User Data Proxy module notifies the MME that pending MT traffic for a specific UE is present. The data packets are classified by destination IP address. The UE's IP address is bound to it's IMSI at the time the UE registers with the network. The IP ↔ IMSI binding can be extracted from the UE's context so that the User Data traffic module can notify the MME about a specific IMSI that needs to be paged. Once the UE transitions into ECM-Connected state, the MT packets are forwarded to the UE, completing the MT data transmission.

UE -SAT visibility
Capacity limitations in the feeder link as well as potential capacity limitations in the satellite's onboard User Data Proxy component offer the possibility to add per-UE quality of service policies. These can be enforced at the User Data proxy module. High priority subscribers can be transmitted ahead of lower priority subscribers, as well as memory in the store and forward entity can be reserved.

C. UE CONTEXT PROXY
The design decision to place the MME on the satellite, is mainly driven by the need to terminate signaling procedures with a UE during discontinuous feeder link periods. UE and core network, specifically the MME, generate a context that is maintained for the time a UE is registered with the network. This context includes timers, temporary identifiers as well VOLUME 1, 2022 9 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Enabling access via multi-satellite constellations is crucial for the purpose of increasing capacity of the NTN network as well as reducing delays for end-to-end data transmission. This can be achieved by creating a distributed MME. The onboard MME instance on each satellite is part of one logical MME that spans multiple satellites. The context created in the onboard MME related to a UE is stored in a database. A novel Context Proxy module, that is able to both extract from the database and also insert context information into the database, is in charge of synchronizing UE context state across the MMEs instantiated in different satellites. The Context Proxy module synchronizes the context with a master database located in the ground station. Context created or modified on other satellites synchronize their context via the ground station so that a UE's context is kept up to date on all satellites in the constellation. Maintaining UE context is one of the challenges identified in section III (see Ch. 5 in Table 3), that is addressed by the Context Proxy. Consequently, a UE, once registered with the network, can access the network via any satellite in the constellation. Fig. 6 illustrates the relevant modules for context distribution.
The importance of context synchronization between satellites mandates to prioritize traffic generated on the feeder link for this over other traffic that is related to user data transmission or authentication. Furthermore, it is possible to serve a UE only by a subset of satellites in the constellation and thus only upload the UE context to those satellites.

D. ARCHITECTURE DESIGN IMPLICATIONS
The proposed architecture has a number of implications. Discontinuity with satellite revisit times in the range of hours implies a delay for messages or actions initiated on either the UE or the ground station that affect the other. This aspect is accepted by delay tolerant IoT services and the operation is enabled by the proxies outlined above. However, signaling procedures can be affected, particularly the HSS initiated detach as well as periodic TAU and paging.

1) Detach
The design, requiring the HSS being on the ground, leads to a potential corner case in the detach procedure that is initiated by the HSS. In the time between the HSS initiated detach and feeder link availability between ground station and satellite, a UE might still be able to utilize the network and thereby taking up resources. The satellite network operator could respond to the MNO's detach request with an estimated time when the detach will take based on satellite ephemerides.

2) Tracking Area Updating
Periodic TAU messages ensure that the network is aware that the UE is reachable in a specific area. The network is in charge of specifying the timer (T3412) within which the UE needs to send the periodic TAU message. Predictable satellite ephemerides allow the network to provide an appropriate value for this timer in each accept message the network sends back to the UE following the TAU, so that the next periodic TAU message falls into a UE ↔ satellite visibility period. However, the granularity of the timers value is determined by 5 bits according to General Packet Radio Service (GPRS) Timer 3 specification and therefore, it may not be suitable for this. In order to avoid potential unintended UE detach due to failed periodic TAU messaging followed by an expiring Implicit Detach timer, one possibility is to deactivate periodic TAU. A UE could be made aware of UE ↔ satellite visibility periods based on its GNSS location and satellite ephemerides. Please note that sending satellite ephemerides to the UE is planned in Rel-17 as part of a new System Information Block (SIB), that is to be concluded by June. Utilizing this information, the UE can perform TAU signaling prior to expiry of relevant timers.

3) Tracking Areas
In NGSO satellite-based NTN, a statically configured TA would move with respect to the earth. One could consider novel TAs for NTN that are not tied to geographical locations, but follow a satellite's footprint. The major shortcoming of this approach lies in the amount of signaling generated for TAUs by stationary UEs, thus, leading to the preference of maintaining TAs tied to geographical areas. This is also reflected by current discussions in the standardization process of 3GPP NTN extensions [6].
In order to simplify the TA problem, one could consider a single TA for the whole coverage area of the NTN LEO constellation, e.g., the whole globe. The key advantage in this approach lies in the fact that periodic TAU is not necessary for the time a UE is registered with the network and T3412 can remain deactivated, simplifying NTN deployments. However, the implication of a single TA is the loss of 10 VOLUME 1, 2022 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2022.3184720 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ location information of a subscriber based on TA. This is crucial for paging procedures. Paging is initiated in the TA where the UE was last active. For a single TA spanning the whole globe, that would mean that paging is initiated everywhere, potentially leading to capacity limitations due to excessive signaling as well as the assumption that a UE is not available due to paging at the wrong location. Thus, keeping track of a UE's location would need to be addressed differently, e.g. by the IoT application server updating the location of the device that is tracked through GNSS. Eventually, this issue should be solved at network level.
Enabling multiple TAs tied to geographical areas can be achieved by continuously updating the configured TA in the eNB/gNB as well as mechanisms in the radio that ensure that the signal is only transmitted in the specific geographical areas while the satellite move relatively to the areas.

4) Paging
By default, the network triggers the paging procedure in a specific TA where the UE was last present. Paging in the correct geographical area is crucial for reaching the UE and to avoid unnecessary signaling taking up radio resources. This can be either addressed with classic TAs as discussed above, or potentially by deriving a UEs location based on last UE visibility and the satellite's footprint at that time.
Furthermore, the UE needs to be reachable when paging is initiated. Therefore, allowed time periods for power saving mechanisms on the UE such as eDRX and Power Saving Mode (PSM) need to be chosen by the network to reflect satellite ephemerides, so that reachability matches coverage periods.

V. ARCHITECTURE VALIDATION
Functional validation of the proposed architecture in Section V is done on an experimental basis on a testbed in a laboratory environment. The validated procedures include UE attach, MO/MT traffic and context synchronization in multi-satellite scenario.

A. TESTBED
The satellite is represented by a commercial Amarisoft eNB (AMARI Callbox Classic [15]) combined with core network components provided by a standalone Evolved Packet Core (EPC), implemented using the open source Magma Access Gateway [16] on a regular amd64 based machine. The open source Magma Access Gateway is enhanced with support for NB-IoT Rel-13, and with our proxy modules that provide the necessary store and forward capabilities for discontinuous operation.
The ground station contains corresponding store and forward entities, PDN connectivity via standard SGi interface, as well as a module for interacting with an MNO HSS via standard S6a interface inside the S6a Auth Proxy GS (Fig. 5). For simplicity we validate local breakout roaming. Ground station components are implemented in a separate physical machine.
The UE, used in this research, is a standard COTS NB-IoT modem (Quectel BG95-G) connected to a Raspberry Pi. Fig. 7 illustrates the testbed components with the indication of its representation.
Discontinuity emulation is achieved in two different ways. On the service link, we can reduce transmit and receive gain of the eNB amplifier, emulating out of coverage operation. Channel emulation during service link availability is not necessary as it has been tested in other research and the focus in this research lies in signaling with discontinuity between core network components [17], [18]. Satellite and ground station machines are connected via Ethernet. Feeder link discontinuity and link impairment during visibility periods are emulated by constraining traffic using Linux Traffic Control queuing discipline (tc qdisc).

B. UE ATTACH PROCEDURE VALIDATION
This test is intended to validate that the proposed design of the EPC for the discontinuity on the service and feeder link allows a UE to perform a valid attach procedure over two UE ↔ satellite flyovers, corresponding to two connectivity windows between the UE and the satellite. The complete procedure is composed of four steps, depicted in Fig. 4. The subscriber is registered in the (MNO) HSS and the satellite is set to advertise the satellite operator's PLMN. The NAS signaling message exchange over the course of the discontinuous initial attach procedure is shown in Fig. 8. An excerpt of the MME log over the course of the attach procedure is presented in Fig. 9.

1) Step 1 -active service link
In the first step, UE ↔ satellite visibility is given, so that the service link is active while the feeder link is inactive. After establishing a radio link with the eNB, the UE sends the first NAS Attach Request message (message (1) in Fig. 8) to the satellite's onboard MME. The MME then sends the AIR to the onboard authentication proxy module, which stores the UE identifier (IMSI) and returns an AIA with error code 5001 (DIAMETER_ERROR_USER_UNKNOWN) to the MME, which in turn sends an Attach Reject message (message (2) in Fig. 8) to the UE. The cause for this reject is 'subscriber unknown', however as mentioned before, the standard should be extended to be able to send a novel reject cause in this case, indicating to the UE that the initial attach procedure is halted until the next UE ↔ satellite visibility window with active service link.

2) Step 2 -active feeder link
Following the UE ↔ satellite exchange, the UE goes out of coverage due to the NGSO characteristic of the satellite. Thus, the service link becomes inactive. On the other hand, satellite ↔ ground station visibility is given now so that the feeder link becomes active. The satellite transmits a list of pending UE authentications to the ground station's authentication module. On the ground station, the received information is used to create Diameter protocol messages via VOLUME Step 1 Step 4 FIGURE 8: NAS signaling in discontinuous attach process in the Amrisoft eNB web-based log.
standard S6a interface to the external HSS in order to obtain the required authentication vectors (to create AIA messages) and subscriber information (to create ULA messages). This data is cached in the ground stations's local proxy with store and forward capabilities.

3) Step 3 -active feeder link
The third step occurs either during continued feeder link availability, or in a new pass over the ground segment with feeder link availability. Authentication vectors and subscriber information are now transmitted to the satellite. The satellite's authentication proxy module saves this data in its store and forward database. It now has the required information present to complete initial attach procedures for pending UEs.

4) Step 4 -active service link
The satellite moves out of satellite ↔ ground station visibility and eventually advances into UE ↔ satellite visibility. In our testbed this happens after about 7 minutes (426.76 s) since the last UE ↔ satellite visibility window (see Fig. 8).
Consequently, in the final step of the discontinuous attach procedure, the feeder link is inactive, and the service link is active. The UE is in coverage again and initiates the Initial Attach procedure again. It sends the NAS Attach Request message (message (3) in Fig. 8) to the MME satellite onboard MME, which in turn sends an AIR with the UE's IMSI to the onboard Authentication Proxy module. This time, the required authentication vectors are present to produce a successful AIA. The MME and UE can now proceed to mutually authenticate, followed by security mode control procedure (messages (4) in Fig. 8). Once this is completed, the MME sends a ULR message to the authentication proxy module in order to obtain subscriber information contained in the ULA that is needed for bearer establishment. The authentication proxy module creates the S6a ULA from the subscriber information it has saved in its store and forward entity. Now the MME can send the Attach Accept message (message (5) in Fig. 8) to the UE that includes the APN, UE's IP address, uplink/downlink bandwidth and a number of timer values specified by the network. The UE finalizes the initial attach procedure by responding with an Attach Complete message (message (6) in Fig. 8). Lastly, an optional message is the MME Information message sent from the MME to the UE (message (7) in Fig. 8).

C. USER DATA AND CONTEXT TRAFFIC VALIDATION
In this subsection, we validate the functionality of the User Data Proxy module that is in charge of buffering data packets in both MO and MT directions. User data packets are transported via the MME using NB-IoT's control plane CIoT EPS optimization [14]. Packets are encapsulated in NAS signaling messages, reducing the signaling overhead when otherwise needing to establish a data radio bearer. In the following, we assume that the UE is registered with the network, e.g., it has already completed the initial attach procedure. Furthermore, this validation is performed in a multi-satellite scenario.

1) Mobile Originated traffic
MO traffic send from the UE to the PDN (e.g. IoT platform) is achieved in two steps, illustrated in Fig. 10. In the first step, during service link availability, the UE send data packets to the satellite. The packets are saved in the User Data SAT Proxy. In the second step, during feeder link availability, the satellite is connected to the ground station's User Data Proxy module. The data packets are now forwarded from the satellite to the ground station, where they are directly forwarded to the PDN. For MO traffic, there is no store and forward mechanism in the ground station, since the PDN is always connected. We generate MO traffic using the command-line utility netcat in our testbed. We assume that the UE is in coverage, FIGURE 9: MME log excerpt showing the attach procedure Step 1 Step 2  FIGURE 10: MO traffic via satellite transmitted in two steps with store and forward mechanism in User Data Proxy module so a radio link between UE and RAN can be established. A UDP message with the destination address of a server in the PDN is sent to the satellite. If the UE is in ECM-Idle mode, the UE initiates service request procedure in order to transition to ECM-Connected. The user data packet is then sent to the MME encapsulated in a NAS control plane message (ESM data transport -see Fig. 12). MME extracts the data packet from the control plane message and passes it into the satellite core's data pipeline. In this step, the feeder link is not available, so the User Data Proxy element stores the data packet. Once the feeder link is up, the User Data Proxy injects the MO data packet into the data pipeline where it is forwarded to the ground station. In the ground station, regular IP routing rules then forward the packet further to PDN.

2) Mobile Terminated traffic
MT traffic, sent from the PDN to the UE, is transmitted in three steps as illustrated in Fig. 11. In the first step, the ground station is not connected to a satellite. User data traffic is generated in a client connected to the ground station's SGi interface. The traffic arriving at the ground station is recorded in the User Data Proxy's store and forward entity. Once Step can then decapsulate the data packet, completing the MT data transmission.

3) User Equipment Context
Enabling connectivity between a UE and multiple satellites with onboard MMEs, is achieved by the User Context Proxy, that allows to disseminate the UE context across multiple satellites. In our testbed, we validated this distribution with two satellites, each consisting of a satellite machine and a separate Amarisoft eNB. The UE context is copied to the other satellite and then MO and MT traffic is transmitted as described in the previous section. The UE continues NAS signaling with the other MME using the same temporary keys and no authentication is needed.

VI. CONCLUSION
LEO satellite constellations for global NB-IoT coverage come with several implications, mainly due to discontinuity on service and feeder link. Those with limited number of ground stations lead to discontinuity on feeder link. Meanwhile, in small, low density LEO constellations with tens or few hundreds of satellites there is discontinuity in the service link. An architecture that can accommodate discontinuity and non-concurrent operation of both service and feeder link relies on store and forward mechanisms. Specifically, maintaining a functioning service link independent of ground station connectivity is a crucial feature not being accounted for in the 3GPP work that is based on the assumption of transparent payload. In this paper, after identifying the discontinuity challenges, we proposed a novel architecture that overcomes them. Our design includes regenerative satellite payloads using novel proxy functions that solve the gap in existing proposals by taking discontinuity into account. Furthermore, 3GPP standard compliance is maintained. Therefore, general benefits of cellular 3GPP networks, like roaming, are possible with this architecture. IoT NTN delay-tolerant applications will greatly benefit from not only cheaper but also faster deployable constellations due to needing fewer satellites compared to mega constellations. Moreover, we have demonstrated that our novel architecture is feasible in a validated testbed.
Future work on low density NTN constellations should be conducted in cooperation of the new inactive mode in 5G, that can be used to avoid the need to re-authenticate after long out of coverage periods. This can reduce the required time to access the network for devices that need to communicate in varying long intervals.
Moreover, further efforts need to be conducted by validating the proposed architecture on an actual satellite deploy-ment. Preliminary results on porting the satellite functions to an ARM based onboard computer for a CubeSat platform show promising performance results. In combination with a Software-defined radio (SDR) based eNB development of a flyable CubeSat architecture underway. Additional research related to multi-satellite constellations can be conducted on routing and prioritization mechanisms for control and user data traffic, that take satellite ephemerides into account. Additionally, larger constellations, where visibility between satellites is given, can potentially benefit from inter-satellite links. However, additional complexity in both satellite payload and routing mechanism require a cost benefit analysis.
Furthermore, as pointed out in the paper, a novel reject cause identifier should be standardized to be able to reflect the need for retrieving authentication information from the discontinuously available ground station. Additionally, investigating possible new IEs in NAS signaling in order to transmit custom timer values to reflect satellite ephemerides is particularly beneficial to discontinuous NTN use cases.
TIMO KELLERMANN received a B.S. degree in electrical engineering from Bonn Rhein-Sieg University of Applied Sciences in 2015 and an M.S degree in telecommunication engineering from Universitat Politècnica de Catalunya in 2020, where he is currently a PhD candidate.
Previously he has completed research stays at Griffith University in Brisbane, Australia and gained working experience in IT and fire protection engineering in Poland and Canada. His research interests cover software defined networks, wireless network protocols and architecture, with focus on cellular networks and core design. From 2014 to 2017, he worked at the Guifi.net Foundation, in research projects related to community networks, wireless mesh, and citizen science. From 2017 to 2021 he conducted research on distributed monitoring systems, and mesh routing protocols for IoT devices, with the Distributed Systems Group at UPC. His current research at the i2CAT Foundation involves 5G and beyond, and satellite-based cellular communication systems for the IoT.
DANIEL CAMPS-MUR is currently leading the Mobile and Wireless Internet (MWI) group at I2CAT in Barcelona, Spain. In addition, he is the technical coordinator of the 5G-PPP project 5G-Clarity, which investigates convergence of 5GNR, WiFi and LiFi.
Previously, he was a senior researcher at NEC Network Laboratories in Heidelberg, Germany. In 2004 he received a Masters degree and in 2012 a Ph.D. degree from the Polytechnic University of Catalonia (UPC). His research interests include mobile networks, software defined networking and communications protocols for the Internet of Things.
RAMON FERRÚS received the degrees of Telecommunications Engineering (B.S. plus M.S.) and Ph.D. from the Universitat Politècnica de Catalunya (UPC), Barcelona, Spain, in 1996 and 2000, respectively. He is currently a tenured Associate Professor with the Department of Signal Theory and Communications at UPC. His research interests include system design, functional architectures, protocols, resource optimization, and network and service management in wireless communications, with a focus on satellite-based cellular communications for massive IoT applications over the past two years. He has participated in 12+ research projects within the 6th, 7th, and H2020 Framework Programs of the European Commission and in 15+ national research projects and technology transfer projects for public and private companies. He has contributed to 3GPP and ETSI standardization bodies, co-authored 3 books on mobile communications and published 140+ papers, mostly in IEEE journals and international renowned conferences.
MARCO GUADALUPI Telecommunications Engineer by the University of Bologna, Master in IOT Technology, Postgraduate in Computer Security, entrepreneur and co-founder of SATELIOT the first wholesale satellite telecom operator that will enable IoT connectivity by merging satellite constellation and Mobile Network Operators under 5G ecosystem. More than 20 years of experience in the sector. Account to the credit of the deployment of the first fixed broadband access network in Spain in 3.5 GHz Band (5G band, WiMAX and then LTE). Implementation, management and control of the largest network of residential satellite terminals in Europe, first network deployment in Spain based on Hispasat Ku/Ka band and Avanti Ka band. Deployment and operation of a High Throughput Satellite Hub in Arganda del Rey, Spain and Goonhilly Downs, UK offering rural internet access to Iberian Peninsula, north of Africa, Balearia Island, Canaria Island and maritime services on routes between the peninsula and the islands. Her research interests and expertise areas comprise the design, evaluation and optimization of communications protocols and architectures for mobile cellular networks, wireless multihop networks, ad-hoc networks, wireless sensor networks, the Internet of Things, and application domains such as smart cities, building automation, satellite and emergency environments. She has been involved in several National and International research or technology transfer projects, and she has published in International and National conferences and journals.