3D Multi Layered 6G-NTN Architecture

3D Multi Layered 6G-NTN Architecture Sandro Scalise, Juraj Poliak, Samuele Raffa DLR (German Aerospace Center) Inst of Communications and Navigation Weßling, Germany {sandro.scalise, juraj.poliak, samuele.raffa}@dlr.de Ji Lianghai Qualcomm Technologies Inc. San Diego, CA, USA [email protected]alcomm.com Madivanane Nadarassin Thales Alenia Space Toulouse, France madivanane.nadarassin @thalesaleniaspace.com Russell Hills Thales Alenia Space Bristol, United Kingdom [email protected] Eduardo Medeiros, Per-Erik Eriksson, Sebastian Euler Ericsson Research Kista, Sweden {eduardo.medeiros, per-erik.s.eriksson, sebastian.euler}@ericsson.com Abstract— This paper provides an initial version of a satellite multi-orbit network optimised for the non-terrestrial component of 6G, defines the proposed functional and physical architecture and performs a preliminary analysis of the required Radio Access Network (RAN) and Core network (CN) functions, and the corresponding split options to be implemented in space to address the Use Cases (UC) defined in the 6G-NTN project. Keywords—6G, Functional Split, Optical ISL, NTN, RAN. I. INTRODUCTION Prior to the advent of the 3GPP Release-17, satellite and mobile networks were designed independently from one another and had mainly addressed separate user markets. From Release-17, the Non-Terrestrial Network (NTN) component has been included in the 3GPP standard enabling 5G service coverage extension to unserved and underserved areas through seamless integration with terrestrial cellular network, thus removing the traditional market separation. However, the integration of the NTN component in 5G started by building upon an already well-defined 5G TN (Terrestrial Network) component since Release-15 and was constrained to minimize the number of network and user equipment modifications when accommodating novel NTN features, therefore limiting the achievable potential of the NTN part. In the context of the IMT-2030 system, also referred to as 6G, it is therefore of paramount importance to intrinsically support the native unification of terrestrial and non-terrestrial networks to enable the full potential of the NTN component while not impacting the experience on TN deployments, and achieve an improved ubiquitous and resilient connectivity experience. To this aim, the performance and capabilities of NTN shall be further extended compared to 5G NTN by developing, assessing, and validating new technical, standardization, and regulatory enablers. This will allow to improve the user experience, especially with handheld terminals and drone/vehicle mounted terminals, to support enhanced network operations leading to greater efficiency and flexibility for human interventions, and to address spectrum scarcity, sustainability aspects, security issues, and the growing traffic demand across space and time. II. 6G-NTN 3D ARCHITECTURE A. Overview As shown in Fig. 6, the underpinning concept of 6G-NTN is a 3D multi-layered architecture. The “3D” characteristic stems from the full integration of the non-terrestrial component with the terrestrial one, while the “multi-layered” feature is related to the integration of different layers consisting of communication nodes, i.e., satellites or HighAltitude Platforms(HAPs) flying at different and multiple altitudes. The flying nodes are interconnected by inter-node links (INL), sometime also referred to as inter-satellite links (ISL) when the two nodes are satellites. The 6G-NTN topology considers two types of nonterrestrial nodes, namely deterministic nodes with a fixed and predictable orbit (both geostationary and non) and flexible nodes, namely HAPs or special heavy drones, which might or might not be present at different points in time and at different locations to extend coverage or enhance the network capacity. The latter are supposed to be deployed “opportunistically” depending on specific needs but are not meant to be a permanent infrastructure with global coverage. B. Role of different Layers 1) GSO Layer The geostationary (GSO) role is expected to have mostly a complementary role with respect to non GSO (NGSO), focusing on: • broadband access that is less performant in terms of data rate and delay compared to the one of NGSO and shall therefore be considered either as backup or as complementary capacity in case of hotspots (assuming dual steer/connectivity between GSO and NGSO links) • selected control plane functionalities such as initial network login or signalling exchange with UE in idle mode (exploiting the large coverage area) • non-delay-sensitive traffic offloading from the NGSO network thanks for to the presence of ISLs between NGSO and GSO layers as well as ensuring resilience and link recovery in case e.g. of failure of the lower constellations • providing essential control and management plane functionalities to the NGSO fleet in case of unavailability of the feeder links / ground segment. This should allow resilient and autonomous operation (eventually with reduced capabilities) of the network even in presence of major disruption of the ground infrastructure. 2) NGSO Layer The main role of NGSO satellites is to provide broadband access to handhelds and to VSAT-like UEs. This layer has therefore a central role and its specific functional and physical design will be addressed in detail in this paper. 3) HAP Layer Flexible nodes are basically HAPs and/or special heavy drones which might be temporarily deployed to provide additional capacity to specific areas. Relevant examples include, for instance, disaster areas where no terrestrial infrastructure is available or areas where a sudden capacity increase is envisaged for a limited period, such as e.g., large concerts or sport events both within cities but also in remote locations. In other words, it is not foreseen to have a permanent network of such nodes, rather they will be opportunistically deployed when and where needed. This also means, that the ground segment design will be optimized for the NGSO layer and HAPs might or might not be in direct visibility of a ground station. In the latter case, they rely on INL to connect to the CN via the NGSO and eventually GSO layers. As last remark, during the movement of HAPs from one scenario of operation to another one, HAPs shall be considered as UEs since they need to be connected to the network, e.g. for movement control, but they are not offering any service to end users. The outline of the final version of the manuscript is as follows: Sections III and IV enter into the detailed functional and physical design of two different options for the LEO constellation, namely a conventional approach in which all LEO satellites have the same payload, communication links and RAN functionalities, and a distributed approach in which satellites have different roles and RAN/CN functionalities are distributed in space. Section V analysis the corresponding bandwidth requirements for the ISL and the feeder links and Section VI contains an initial sizing of optical ISL in order to fulfill such requirements. Lastly, Section VII contains our conclusion. III. 6G-NTN LEO CONVENTIONAL ARCHITECTURE A. Constellation Design The reference constellation has been defined based on the following coverage parameters: • Reference altitude 600 km. • Minimum of 1 satellite visible at any time • Minimum of 10s overlap between satellites for a user on ground to allow handover from one satellite to another • Minimum user elevation of 45° • Near-polar orbit (~87°) to achieve global coverage. Please note that the slight deviation from a nominal polar constellation with exactly 90° inclination avoids having all orbital planes intersecting at one point over each of the poles. This simplifies the management of the constellation with regards to potential collisions. With the above parameters, the constellation will have 1.269 satellites and 27 orbital planes, each with 47 satellites. In this architecture, all LEO satellites of the constellation are identical and shall include: • service links with multibeam coverage and related beamforming network and antenna elements • 4 bidirectional laser terminals for the ISL, connecting the two adjacent satellites in the same orbital plane and the 1 We refer here to the typical PDCP/RLC/MAC/PHY 3GPP protocol stack 2 nearest satellites in the two adjacent orbital planes. Please note that an additional laser terminal might be needed to connect to HAPs and for redundancy purposes. • 2 feeder links as a minimum (for redundancy and/or seamless ground station handover) • a Ka-band payload for the ISL to the GEO satellites, which may be present only in some LEO satellites • suitable on-board processing units to implement all required RAN and possibly some Core Network functionalities. With this approach, potential bottlenecks are to be expected as far as the availability of resources in space (complexity, power, and mass) is concerned, so a careful selection regarding RAN and CN functionalities to be implemented respectively in the satellite and on ground shall be performed. A thorough analysis of the advantages of the different functional split options currently considered in 5G [1] has been carried out in [2]. Its main outcomes can be summarized as follows: • Payload complexity increases when onboarding more protocol layers and the corresponding functions. • Onboard edge computing requires typically CN functionalities, so it’s feasible only if the payload contains at least the whole access stratum layers together with the PDU layer, e.g. a gNB + UPF. • If MAC 1 entity is implemented on the ground, latency critical services might be problematic, considering the incurred latency from feeder link on HARQ and randomaccess procedures. • Dynamic resource sharing between TN and NTN might be more difficult to support, if the MAC entity for NTN operation is contained in the payload, since that would cause the need of a tight interaction between the MAC entity of TN and the onboard MAC entity. • A centralized RRC entity for different satellites and even TN operations on the ground has the capability to optimize the system, e.g. to improve mobility support by collecting and considering more global information. It shall be noted once more that the split options are those currently defined in 5G, but we assumed that only incremental changes will be applied in 6G. The main conclusion is in any case that a “one size fits all” approach is not ideal. Therefore, the next section presents a novel concept named Adaptive Functional Split (AFS). B. Adaptive Functional Split In order to better support the different use cases in future 6G NTN, AFS is based on the idea that the functional split between satellite and ground can be dynamically adjusted in space and time. Different and non-mutually exclusive criteria to adapt the functional split are possible such as e.g.: • Cell/area-specific AFS: Different functional split options for different cells/areas • UE-specific AFS: Different functional split options for different UEs • Service-specific AFS: Different functional split options for different services. • MNO-specific AFS: Different functional split options for different MNOs sharing the same satellite infrastructure (multi-tenancy) For the sake of compactness only the first one will be presented in this paper (further info is available in [2]). Fig. 1 shows an example for the cell/area-specific AFS scheme. In this scheme, a satellite may serve different cells or different areas by using different functional split options at the same time. For example, TN and NTN may coexist in the area covered by cell #m, e.g. along a seashore, where it might be preferable to deploy a lower layer function split so that more Access Stratum (AS) protocol layers can be centrally located on the ground, which enables to apply a central scheduling for handling TN-NTN coexistence, dynamic TN-NTN resource sharing and lower layer mobility solutions for TNNTN handover. In contrast, cell #n may cover an area without TN coverage, e.g. over the ocean. In this case, cell #n may benefit from using a higher layer function split, which can help to achieve a lower latency in the AS layer and also support onboard edge computing. te Fig. 1. Illustration for the Cell/Area-Specific AFS. Please note, cell #n and cell #m may use the same physical lower PHY entity onboard the satellite, and they are logically separated in Fig. 1 for illustration purpose only. Further criteria are possible to adjust the functional split in addition to the four mentioned above. For instance, adaptation could take place depending on the actual load / level of congestion of ISLs, on depending on the un/availability of a direct feeder link to a ground station. IV. 6G-NTN LEO DISTRIBUTED ARCHITECTURE Another way to address the problem of resource shortage in space highlighted in the previous section departs from the conventional design approach of all existing satellite constellations, where all satellites are (almost) identical from a hardware and also from a logical point of view. We introduce two different types of satellites, namely service satellites and feeder satellites. A. Constellation Design Service satellites are mainly devoted to providing connectivity to the UEs. Most of the available payload mass and power is thus used to maximize the service upand downlink capacity, so these satellites will connect via ISLs to the feeder satellites but will have neither feeder links nor ISLs among them. On the other hand, feeder satellites do not have a direct link to the UEs, but they implement the full transport network in space using ISLs and feeder links. Moreover, they provide additional processing capabilities in space to implement RAN and if needed CN and edge computing functionalities. The current ongoing constellation design foresees the same altitude of 600 km for both service and feeder satellites. The service satellites shall fulfill the same design parameters as in Section III.A, thus resulting in the same number of satellites and orbital planes. Each feeder satellite nominally serves 4 service satellites. The number of feeder satellites is larger than 318 (~1269/4) as might be expected. This is because each feeder satellite serves two service satellites in each adjacent plane – as there are an odd number of service satellites per plane, there will be one feeder satellite in each plane that only serves two service satellites. Also, there is an odd number of service satellite planes, meaning there will be a plane of feeder satellites that only serve one service plane, and therefore only serve two service satellites (assuming the relative geometry of service and feeder satellites is kept constant). As not all feeder satellites are fully utilized, slightly more satellites are required, namely 336 feeder satellites with 14 orbital planes. The overall resulting constellation is sketched in Fig. 2, where red stars are service satellites, green stars are feeder satellites, magenta links are the ISL between service and feeder satellites and cyan links are the ISL between feeder satellites. Fig. 2. LEO Constellation with Service and Feeder Satellites. The advantages of this architectural solution are manifold, namely: • it allows higher service link throughput, since no resources have to be provisioned for feeder link and ISL and all available power can be devoted to the service link. • it offers better scalability and flexibility, since the feeder satellites are totally agnostic regarding which spectrum and bandwidth is used for the service links. As long as the ISL and feeder links capacity does not become the bottleneck, new service satellites (more powerful and/or operating in a different frequency bands) could be progressively and seamlessly added. Basically, through the distributed architecture the service links are completely decoupled from the transport network in space made of the ISL and feeder links. Although this concept is not new, so far it has been considered mostly at academic level. As a matter of fact, all existing constellations including e.g. Starlink (if we exclude the fact that different generations Cell #m Cell #n Lower PHY Higher PHY MAC PDCP RLC NAS/PDU RRC/SDAP PHY MAC PDCP RLC NAS/PDU RRC/SDAP Cell #m Cell #n NAS/PDU Cell #m Cell #n Payload Ground infra are coexisting in space) adopt a conventional design where all satellites are (functionally) identical. In addition, this distributed architecture is also novel to the architecture solutions considered for 5G development [3]. For the first time in the 6G-NTN project, a detailed constellation, payload and functional architecture design for this distributed solution is being proposed. It shall be mentioned that this solution requires ca 15% more satellites and additional payload design and accommodation exercise. A detailed cost/performance assessment is currently being carried out. B. Functional Split between Service and Feeder Satellites Although an initial power and mass budget for the service and feeder satellites is still under consolidation, the idea behind the split between service and feeder satellites is that the latter should have sufficient mass, power and processing capabilities to implement all baseband unit (BBU) functionalities, together with selected CN and edge computing functionalities if required, thus overcoming the limitations highlighted in section III.A. The service satellites shall carry a radio unit (RU) and provide the service link to the user terminals on the ground. It should be understood that baseband includes all upper layers of the radio protocol stack while the physical layer processing functionalities are split between the feeder satellite and the service satellites. The connection from the feeder satellite to the service satellites in the cluster is done via optical ISLs supporting a fronthaul interface such as the one defined by ORAN WG4 standards [4]. Fig. 7 shows how the switch/router in the feeder satellite can be used to route the backhaul from the feeder link to another feeder satellite in a neighbor cluster. As already mentioned, the intuition that motivates this concept is that power budget and payloads can be optimized for the different roles of the satellites. The feeder satellites carrying the BBU do not have to be equipped with multiple power amplifiers for the service link, therefore more power and payload volume can be allocated for computation parts. On the contrary, the service satellite carrying the RU will have less of its payload devoted to computation / signal processing tasks, which means more volume and power for the power amplifier, antennas, and beamforming network for the service link. One potential issue that this solution may have is that centralized scheduling over multiple feeder satellites will be harder to achieve as each feeder satellite will have its own scheduler. The system could however support slower radio resource management coordination, such as is done in terrestrial networks across independent base stations. V. BANDWIDTH REQUIREMENT ANALYSIS FOR LLS This section provides a quantitative analysis of the LLS option, focusing on the bandwidth requirements for ISLs and feeder links. Please note that the analysis presented here is also relevant to the scenario in which the lower layer split is implemented for the conventional LEO constellation (i.e., having a baseband unit on the ground and a radio unit onboard the satellite). A. Uplink In general, for an LLS architecture, the uplink is the direction driving the bandwidth requirements for the interface. In this section we provide a quantitative analysis of the bandwidth cost for transporting frequency domain samples between a radio node and a baseband node. The analysis is valid for systems where baseband is deployed on the ground or in a satellite, given that the logical functional split is the same. Differently from downlink, the bandwidth requirements for an uplink interface do not vary with modulation and coding scheme (MCS) choice, in case the method for representing the frequency domain IQ samples is kept constant (e.g., block floating point encoding). Similar to the downlink, on the other hand, the bandwidth utilization depends on utilization of the air interface and grows with the number of allocated UEs. To evaluate the required bandwidth, we propose to calculate the cost of transmitting the frequency domain IQ samples of a cell at maximum load (all physical resources allocated to UEs). Next, the cost of servicing one cell (approximately 815 Mbps) is used to estimate how many cells could be supported for a given fronthaul link capacity. For the calculations, we account for the overhead in user plane fronthaul packets. All underlying assumptions are detailed in [2]. The results are collected in TABLE I. Note that this calculation assumes a quite harsh requirement that all cells are fully loaded simultaneously. In practice, the utilization of different cells fluctuates over time, so the actual numbers of cells that can be supported are higher than those shown here. Additionally, the traffic is under control of the baseband scheduler, which can assure that no overload occurs and that there is fairness between different cells sharing the same link. It is also noted, due to satellite constraints (e.g. power limit), a satellite may not be able to support the communication to a large number of cells at the same time, which would reduce the required per-cell fronthaul capacity since a cell is only scheduled for a fraction of time. It is possible to observe that for fronthaul links of around 100 Gbps, the interface could possibly support more simultaneous cells (active beams) than the satellite would serve. The current working assumption is to have 100 simultaneous beams per satellite. TABLE I. NUMBER OF SUPPORTED CELLS AT PEAK LOAD Fronthaul Link Capacity Supported cells at peak load 5 Gbps 6 10 Gbps 12 25 Gbps 30 50 Gbps 61 100 Gbps 122 B. Downlink This section provides a comparison of the bandwidth requirements for two hypothetical systems, namely: • Option 1 - where a full base station is placed in a satellite. • Option 2 - where the physical layer is functionally split between a baseband node on the feeder satellite and a radio node on the service satellite. Due to the high number of variables in a real implementation, the results should be taken as an example, rather than an exact evaluation. We propose to compare both systems by a ratio of how much data needs to be sent over a link of interest for a full NR slot. For Option 1, the link of interest is a feeder link / ISL carrying the NG interface, while for Option 2 it is an ISL carrying the fronthaul LLS interface. For a full base station onboard the satellite, the traffic sent over the link corresponds (except for packet headers) to what is to be sent over to the UE. For option 2 (LLS), the data entering the base station is augmented by headers in PDCP, RLC, MAC (e.g., control elements), channel coding (LDPC for PDSCH). Besides that, there is overhead added for the fronthaul link itself. The results are presented in Fig. 3, where the capacity requirements are normalized by the requirements of the full base station onboard system (Option 1). Option 2 requires around 2.8 times the bandwidth used for Option 1. The main contribution comes from the bandwidth expansion added by the channel coding (LDPC for 5G NR). We assumed an average code rate of 0.42. This has been obtained by averaging the code rates from MCS 0 to MCS 10. In practice the average coding rate will depend on the channel conditions for each user/deployment. Fig. 3. Illustrative comparison of downlink capacity requirements (normalized). VI. SIZING OF OPTICAL INTER-SATELLITE LINKS The next step is to size the optical ISL based on the results of Section V.A so to avoid that they become a bottleneck for the entire system. Parametric link budgets have been performed in [2] assuming different optical output power levels and different telescope apertures. With respect to Fig. 2, the bottleneck is represented by the cyan links, i.e. the links between feeder satellites with a distance of 2040 km. According to the results in Fig. 4, a terminal aperture of 60mm would be required to reach 100 Gbps assuming 1W output power. Fig. 4. Link Budget for Optical ISL between Feeder Satellites. The link budget for the optical link between service and feeder satellites is shown in Fig. 5 as a function of the telescope apertures in both satellites. Since it is reasonable and advantageous to assume that all laser terminals in the feeder satellites will be identical, the aforementioned value of 60mm would allow to close the link at 100 Gbps with 1W output power (red line) using a much smaller aperture in the service satellite, i.e. only 20mm. These results confirm that a reasonable sizing of the optical ISL considering state-of-art technology is possible. Moreover, service satellites can use a smaller terminal, thus saving additional mass / power, with respect to feeder satellites. Fig. 5. Link Budget for Optical ISL between Feeder Satellites. VII. CONCLUSION In this paper, an initial LEO constellation design specifically optimized for a future 6G NTN multi orbit system has been carried out. Two solutions have been analyzed, namely one based on a conventional approach in which all satellites are identical and where the required flexibility to optimally serve use cases with conflicting requirements is achieved by means of an adaptive split of the RAN functions between space and ground; another one in which the full gNodeB is implemented in space according to a distributed approach in which not all satellites have the same role and functionalities. This permits to overcome the resource bottleneck associated to the implementation of a full gNodeB in space at the expenses of a higher required number of satellites. A detailed performance (throughput and also delay) as well as cost/benefits assessment is currently ongoing and will allow to refine this initial work and consolidated the reference LEO constellation design for 6G NTN. ACKNOWLEDGMENT This work has been funded by the 6G-NTN project, which received funding from the Smart Networks and Services Joint Undertaking (SNS JU) under the European Union’s Horizon Europe research and innovation program under Grant Agreement No 101096479. The views and opinions expressed are those of the authors and do not necessarily represent the project. Neither the European Union nor the granting authority is liable for any use that may be made of any of the information contained therein. The authors would like to thanks all other contributors to Tasks 3.1 of the 6G-NTN project, in particular Carla Amatetti, Marie-Laure Charles, Alessandro Guidotti, Joel Grotz, Fanny Parzysz and Laurent Reynaud. REFERENCES [1] L. M. P. Larsen, A. Checko and H. L. Christiansen, "A Survey of the Functional Splits Proposed for 5G Mobile Crosshaul Networks," in IEEE Communications Surveys & Tutorials, vol. 21, no. 1, pp. 146172, First quarter 2019, doi: 10.1109/COMST.2018.2868805. [2] “Report on 3D Multi Layered NTN Architecture”, Deliverable D3.5, 6G-NTN project, available at https://6g-ntn.eu/public-deliverables/. [3] “Solutions for NR to support Non-Terrestrial Networks (NTN)”, 3GPP TR 38.821. [4] “O-RAN Working Group 4 – Control, User and Synchronization Plane Specification”, O-RAN Alliance, v 16.01, October 2024, available at https://specifications.o-ran.org/download?id=738. Fig. 6. 6G-NTN 3D Network Concept. Fig. 7. LLS between Service and Feeder Satellites Enabling also Routing between BBU Satellites.