Novel architecture for cellular IoT in future non-terrestrial networks: store and forward adaptations for enabling discontinuous feeder link operation

Received 4 May 2022, accepted 10 June 2022. Date of publication xxxx 00, 0000, date of current version xxxx 00, 0000. Digital Object Identifier 10.1109/ACCESS.2022.3184720 Novel Architecture for Cellular IoT in Future Non-Terrestrial Networks: Store and Forward Adaptations for Enabling Discontinuous Feeder Link Operation TIMO KELLERMANN 1, ROGER PUEYO CENTELLES 1, DANIEL CAMPS-MUR1, RAMON FERRÚS 2, (Member, IEEE), MARCO GUADALUPI3, AND ANNA CALVERAS AUGÉ 2 1i2CAT, 08034 Barcelona, Spain 2Departament d’Enginyeria Telemàtica, Universitat Politècnica de Catalunya (UPC), 08034 Barcelona, Spain 3SATELIOT, 08008 Barcelona, Spain Corresponding author: Timo Kellermann ([email protected]) This work was supported in part by the Spanish MCIN/AEI/10.13039/501100011033 under Project PID2019-106808RA-I00. ABSTRACT 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, which are fundamental for supporting important use cases in future networks. A rapidly growing market for IoT devices with mMTC applications using NarrowBandIoT (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 IoT devices, thus requiring complex ground segment infrastructure in low Earth orbit (LEO) constellation deployments to achieve 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 address the previous challenges, as well as a laboratory validation of said architecture for a specific use case. INDEX TERMS NB-IoT NTN, LEO constellation, store and forward. I. INTRODUCTION NarrowBand-IoT (NB-IoT) specification was first introduced in June 2016 as part of 3rd Generation Partnership Project (3GPP)’s Rel-13 [1]. Since then, an expected 1.9 billion connections via cellular Internet of Things (IoT) were operated The associate editor coordinating the review of this manuscript and approving it for publication was Qiang Yang . in 2021, and it is expected to grow to 5.5 billion cellular IoT connections by 2027 [2]. The growing demand for IoT services corresponds to a market potential consisting of billions of IoT devices [3]. While the expected growth figures were even greater pre-COVID-19 pandemic, a thriving adoption of cellular IoT is ongoing. Connecting IoT devices to existing cellular networks brings the advantage of being able to use existing infrastructure with powerful and extensible VOLUME 10, 2022 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ 1 T. Kellermann et al.: Novel Architecture for Cellular IoT in Future NTNs: Store and Forward Adaptations core network architectures, although lacking rural 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, CubeSat1technology 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 1U-Class Spacecraft miniaturized satellite made up of multiple cubic modules of 10 cm ×10 cm ×10 cm size [8]. 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 nonreal-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 NarrowBand-IoT (NB-IoT)’s standardized roaming interfaces, mobility and 2VOLUME 10, 2022 T. Kellermann et al.: Novel Architecture for Cellular IoT in Future NTNs: Store and Forward Adaptations scalability are crucial advantages over existing, proprietary solutions that offer satellite 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 TABLE 1. Current 3GPP work Item related to NB-IoT support for non-terrestrial networks. 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 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 10, 2022 3 T. Kellermann et al.: Novel Architecture for Cellular IoT in Future NTNs: Store and Forward Adaptations FIGURE 1. Satellite based non-terrestrial network with transparent payload, representing the scenario that is currently assumed by 3GPP. 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. TABLE 2. Relevant timers for the completion of Attach, Detach, Tracking Area Updating, Service Request and Paging procedure. 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 the 4G core, 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. 4VOLUME 10, 2022 T. Kellermann et al.: Novel Architecture for Cellular IoT in Future NTNs: Store and Forward Adaptations FIGURE 2. Attach procedure signaling in a regular NB-IoT deployment. 1) ATTACH PROCEDURE Fig. 2illustrates 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 Accept message (step 10 in Fig. 2) or an Attach Reject message. In NB-S1 mode, this timer has a value of 255 s (see Table 2). 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 (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. 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 VOLUME 10, 2022 5 T. Kellermann et al.: Novel Architecture for Cellular IoT in Future NTNs: Store and Forward Adaptations 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 ECMConnected 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 ECMConnected state is a crucial process, so that MO and MT traffic can be transmitted. A NB-IoT UE mainly residing in ECM-Idle state, must move into ECM-Connected state during each UE ↔satellite visibility window in which MO/MT traffic shall be transmitted. This signaling requires interaction with the MME. Furthermore, MO and MT traffic that is transmitted via the satellite requires buffering in both ground stations and satellite in this discontinuity scenario. Finally, it is necessary to ensure NAS signaling can be performed via multiple satellites of the constellation. This leads to the potential challenge to maintain UE context in a multi-satellite scenario. 6VOLUME 10, 2022 T. Kellermann et al.: Novel Architecture for Cellular IoT in Future NTNs: Store and Forward Adaptations TABLE 3. Summary of challenges that arise from discontinuity. 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. 3illustrates a high-level view of components of the solution framework. An IoT device uses a NB-IoT compliant frontend to connect to the LEO satellite constellation. A connection management entity orchestrates the devices connected, idle and (extended) sleep cycles based on satellite ephemeris. 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, FIGURE 3. High-level view of proposed architecture with store and forward mechanism. 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: •Authentication Proxy, facilitating the attach procedure across different visibility windows •User Data Proxy, enabling discontinuous transmission of MO and MT traffic •User Context Proxy, disseminating UE context across multiple satellites 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. A. AUTHENTICATION PROXY Due to the HSS being on the ground, which is mandatory to enable roaming with other MNOs, a novel way to acquire subscription information on the satellite is needed. The Authentication Proxy module consists of two components. The onboard satellite component, that is capable of interacting with the satellite’s MME. The ground station component, that communicates with a MNO’s HSS via a standard S6a interface. The Authentication Proxy is capable of fetching the required information on the ground, store it and forward it to the satellite where it is stored again until it is requested by the satellite’s MME. Thereby, it addresses Ch. 2 in Table 3. 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 VOLUME 10, 2022 7 T. Kellermann et al.: Novel Architecture for Cellular IoT in Future NTNs: Store and Forward Adaptations FIGURE 4. Required steps for UE attachment with service and feeder link discontinuity with one satellite. 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. 5shows 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. 5shows 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. 5depicts 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. 5presents 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 ECMConnected state (radio and network resources are assigned to the UE). While out of coverage, the UE is in ECM-Idle state. Once there is UE ↔satellite visibility, the UE can transition into ECM-Connected state and send MO traffic to the satellite. MO packets are buffered in the onboard User Data Proxy component until the satellite passes over a ground station. With feeder link availability, the MO packets can be sent to the User Data Proxy ground component, where they are directly forwarded to the corresponding Packet Data Network (PDN), or to the home network depending on the roaming model. In case of home routed traffic, a GPRS Tunnelling Protocol (GTP) tunnel between the User Data Proxy ground component and the MNO’s Packet Gateway (PGW) is established to transport the user data packet. Forwarding to the correct PGW is based on the UE’s IMSI ↔IP binding that allows to identify the traffic and its destination. The PDN or other MNO’s home networks are always connected to 8VOLUME 10, 2022 T. Kellermann et al.: Novel Architecture for Cellular IoT in Future NTNs: Store and Forward Adaptations FIGURE 5. Signaling between satellite components and UE (left) and satellite and ground segment components (right) over 4 steps in the discontinuous attach procedure. the ground station, thus no store and forward mechanism is required for MO traffic on the ground station. 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. 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 as encryption and integrity keys. A direct consequence of this, combined with our decision of placing the MME on the satellite, is that in a multi-satellite scenario, a UE registered with one satellite could only communicate with that specific satellite that contains this context. In order to communicate via a different satellite, the UE would have to complete a full attach procedure with that second satellite, however, that invalidates the context created with the first satellite. Thus, the UE would continue to be able to communicate via one satellite only. 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 VOLUME 10, 2022 9