Youssouf Drif
email: youssouf.drif@irt-saintexupery.com

Emmanuel Chaput

Emmanuel Lavinal

| Pascal Berthou

| Boris

Tiomela Jou

| Olivier Gremillet

Fabrice Arnal

An Extensible Network Slicing Framework for Satellite Integration into 5G

Keywords: Network Slicing, Satellite Networks, Software Defined Networking, Network Function Virtualization Satellite Infrastructure SCC

With the imminent deployment of the 5th generation mobile network (5G) in the nonstandalone version, some researches focus on network slicing to fully exploit the 5G infrastructure and achieve a highest level of flexibility in the network. This level of flexibility offered by the network slicing paradigm also fits the need of satellite networks in which Satellite Network Operators (SNOs) want to offer 5G connectivity services additionally to the traditional satellite connectivity. However, the work that has been done so far for network slicing in 5G does not directly apply to satellite networks due to satellite architecture specificities and thus needs to be extended.

We extend the work on network slicing and this paper proposes a novel Satellite Slicing Framework in order to fully exploit the satellite infrastructure and to facilitate the integration of satellite services into 5G. Our framework includes defining, modeling, orchestrating and deploying multiple satellite network slices and their associated network services on top of mutualized satellite infrastructures.

INTRODUCTION

For the past decades, networks have evolved to increase their performances, increase their capacities, reduce latencies and optimize their resources management in order to remain competitive and to t the market. Today, the way consumers use networks has changed and more heterogeneous services have emerged such as Massive Internet of Things (MIoT), streaming services (e.g. Net ix, HULU, etc.) or Tele-medicine. Each service has its own requirements in terms of bandwidth, capacity, latency and needs its own speci c applications additionally to the connectivity provided by the network. Building a dedicated infrastructure for each service could be envisioned, nevertheless it would be very expensive and nearly impossible to manage. This has led network operators to de ne the network slicing paradigm. Network slicing creates multiple partitions in the network, each partition being dedicated to a particular service allowing vertical markets and multiple services with di erent requirements to run on top of a single infrastructure. Standardization Organizations (SDOs) such as NGNM [START_REF] Ngnm | Description of Network Slicing Concept[END_REF], IETF [START_REF] Netslices | IETF-NetSlices[END_REF], ITU-T [START_REF]2020 Network Management and Orchestration Requirements[END_REF][START_REF]IMT-2020 Network Management and Orchestration Framework[END_REF][START_REF]Framework for the Support of Network Slicing in the IMT-2020 Network[END_REF][START_REF]High-level Technical Characteristics of Network Softwarization for IMT-2020[END_REF], 3GPP [START_REF]3GPP . System architecture for the 5G System (5GS)[END_REF], ETSI [START_REF] Nfv Ei | Network Functions Virtualisation (NFV) Release 3; Evolution and Ecosystem[END_REF][START_REF] Ngp Ei | Next Generation Protocols(NGP); E2E Network Slicing Reference Framework and Information Model[END_REF] or ONF [START_REF] Onf) Onf | Applying SDN Architecture to 5G Slicing[END_REF] are actively working on the network slicing concept but none of their work fully encompass the slicing for satellite networks because of the satellite speci cities.

Network slicing opens up new opportunities, aims to provide end-to-end services across multiple administrative network domains and is expected to facilitate the integration of the satellite into terrestrial networks. Pooling broadband satellites, TV broadcast satellites and earth observation satellites together using network slicing would enable a SNO to o er customizable services such as quadruple-play services (broadband internet, television and telephony) coupled with a satellite monitoring service (e.g. a cargo operator could watch over its eet using real-time satellite observation while broadband and TV satellites would provide services to the crew). The pooling of satellite infrastructures reduces Capital Expenditures (CAPEX), Operating Expenses (OPEX), takes full advantage of various satellite types ying at several orbits (Low Earth Orbit (LEO), Middle Earth Orbit (MEO) and Geostationary Orbit (GEO)) and permits to provide new services with a minimum investment. Network slicing aims also at abstracting the complexity of the infrastructure and unify management systems to only focus on delivering services. Satellite actors initiatives such as VITAL [START_REF]H2020 VITAL project[END_REF] which aimed at virtualizing satellite components in order to improve exibility and easily provide services were the preliminary and necessary steps for network slicing. Integrating slicing within the satellite domain is the next logical step of those initiatives and lling the gap would bring the satellite networks to the next level.

Pooling the infrastructure for multiple services is a complex task. Satellite system architecture is composed of ground, space and user segments.

Each segment uses speci c technologies, standards and protocols making the pooling of the infrastructure di cult and thus jeopardize to have a global management system. Proprietary technologies are also still widely used in satellite systems and do not always fully implement standards (for instance Newtec's patented Mx-DMA technology [START_REF] Newtec | A Tale of 3 Satellite Return Technologies[END_REF] implemented to improve return channel bandwidth e ciency in broadband services). Many challenges have to be solved in order to rst partition the satellite network in di erent slices and then integrate those slices into the 5G networks.

FIGURE 1 Satellite Network Slicing

To allow the exibility level required by network slicing (Figure 1), space segments and ground segments have to evolve. Satellite actors have therefore been working on improving ground and space equipments. VITAL, SaT5G [START_REF] Liolis | Use cases and scenarios of 5G integrated satellite-terrestrial networks for enhanced mobile broadband: The SaT5G approach[END_REF] and ESA SATis5 [START_REF]SATis5 -Demonstrator for Satellite-Terrestrial Integration in the 5G Context[END_REF] projects studied the integration of satellite into 4G/5G terrestrial networks enabling Software De ned Network (SDN) and Network Function Virtualization (NFV) on satellite ground segment. Improvements have been made on the space segment, resulting in technologies such as beam-hopping techniques [START_REF] Anzalchi | Beam hopping in multi-beam broadband satellite systems: System simulation and performance comparison with non-hopped systems[END_REF] for GEO broadband satellites which allow to dynamically adapt the capacity allocated for a spot-beam. However GEO satellites have a lifetime of 10 to 20 years, making hardware upgrade impossible and challenges the shift of new services. Mega-constellations such as Amazon Kuiper [START_REF] Kuiper | [END_REF] and

StarLink [START_REF]SpaceX . Starlink[END_REF] ambition to o er high bandwidth and low latencies broadband services using respectively around 3 200 and 12 000 LEO satellites.

LEO satellites are smaller than GEO ones and have an expected lifetime of 2 years having the e ect of lowering the cost of a satellite unit and thus the price of the internet service. Renewing every 2 years a batch of satellites permits to adopt an agile development methodology, to upgrade the constellations and progressively add new features to it. Although there are still satellite speci cities and challenges to resolve to add exibility in satellites, with all the improvement and research results that have been produced so far, we can consider applying network slicing to satellite networks which would bene t both the satellite customers (companies) and to satellite providers (system integrators; satellite operators and satellite network providers).

In this paper, we confront the challenges related to the network slicing paradigm to the satellite network and de ne precisely what is a satellite slice. We take a top-down approach with a focus on Network Slicing which is a major di erence with other on-going projects. SDN and NFV are the key technologies to enable network slicing and reach an unprecedented exibility in the satellite network. We analyse the current satellite architecture and propose a new approach to the satellite network architecture to make it evolve in order to be more exible. This architecture is an enabler to pool all the satellite resources and to fully implement the network slicing paradigm. Using this architecture and the network slicing paradigm, we are able to integrate the satellite network into 5G networks in a seamless way. This allows to establish 5G end-to-end slices across the 5G terrestrial network and the satellite network.

The remaining sections of this paper are organised as follows. We start by referring our satellite architecture in Section 2 and describe the 5G networks and the network slicing paradigm in Section 3. Then, we propose a de nition of satellite slice, the evolved satellite architecture and how to pool resources in Section 4. Following the de nition of the satellite slice, we present a method to integrate this slice into a 5G end-to-end slice based on the 3GPP speci cations and to ensure the end-to-end service delivery in Section 5. Finally, we conclude in Section 6 and address areas for future works.

SATELLITE NETWORKS

This section describes the satellite networks architecture and the satellite role model. These are the base on top of which we build our proposition, so a clear description of their main components is needed before settling our work. It is also compatible with a multi satellite system con guration (LEO, MEO, GEO) that could be instantiated in a single system. Figure 2 describes a high-level architecture of our broadband reference architecture.

The architecture is composed of a user, a space and a ground segment. It holds the Satellite Terminal (ST) which communicates with the satellite gateways using one or multiple satellites. The ST is composed of two radio modules, one to modulate the signal and send it to the space segment on the return link and another radio module to receive the signal coming from the space segment on the forward link. Open standards or proprietary ones can be used on the forward and return links as long as the satellite gateway uses the same standard (e.g. DVB-S2/RCS2).

Ground Satellite Segment

The ground segment is composed of all the necessary elements for the control of the satellite and the communication between the satellite gateways and the satellite terminals. We can decompose those elements in two di erent categories: the control elements and the data elements. The data elements are composed of the Broadband Network Gateway (BNG) and the Satellite Gateways. The BNG is the device which interconnects the satellite backbone network to the other "external" networks such as service provider networks or mobile terrestrial networks. The satellite gateway is the device which handles tra c from and to the STs through the space segment. It handles the communication functionalities such as the radio resource management, modulation and demodulation of the radio signal, and network functions such as rewall or PEP functions. It could be compatible with a satellite standard or be proprietary. A single gateway can serve multiple STs located in di erent satellite beams. A satellite system can be composed of multiple gateways, for instance the multiplicity of the gateways in Very High Throughput Satellite (VHTS) systems are used to increase the capacity of the satellite network and to provide backup gateways. The control elements of the ground segment are: the Satellite Control Center (SCC) which is responsible of the positioning and the health monitoring of the satellite; the Satellite Network Control (SNC) which con gures the payload; the Network Control Center (NCC) which de nes the policy of the satellite network and handles non-realtime connection parameters; and nally the Network Management System (NMS) which is responsible for the realtime connection management.

Space Segment

The space segment is composed of one or multiple satellites orbiting at several altitudes: LEO, MEO and GEO. A satellite is a combination of a platform which takes care of the satellite positioning, power and a payload which handles the radio communication. A satellite payload can be of transparent or regenerative type: the transparent one only repeats and ampli es the signal received while the regenerative can demodulate the signal and process network packets directly on-board. The regenerative payloads enable more exibility and are capable of processing the packets on-board at the L3 level.

NETWORK SLICING IN MOBILE TERRESTRIAL NETWORKS

Network Slicing is a paradigm where the network is partitioned in di erent logical or physical networks. Each partition is de ned as a "slice", is dedicated and optimized for a speci c type of services, is end-to-end from the service to the end-user and is created on top of a mutualized network infrastructure. Partitioning the network into optimized "slices" is not an easy task and various challenges need to be addressed. The general concept of network slicing is the same for the entire network community, however there are no common frameworks yet for the network slicing ecosystem. We focus on the 3GPP speci cations and their de nition of network slicing. Indeed, the 3GPP is actively working on the network slicing standardization and it has de ned a set of speci cations to address the network slicing paradigm. 3GPP de nes three models [START_REF]3GPP . Management and orchestration; Concepts, use cases and requirements[END_REF] to use and and expose NSIs:

• Communication Services are instantiated on top of the NSI. The NSI in this case is only a way to provide services to end-users, for instance a broadband service instantiated on top of an optimized broadband NSI. The end users of the broadband service would be the customer of a mobile network operator.

• Network Slice as a Service (NSaaS) where the CSC is considered as the end user. The CSP becomes a Network Slice Provider (NSP) and based on a set of requirements, it provides a NSI to the CSC which acts as the Network Slice Customer (NSC). In this case the NSP o ers management capabilities to the NSC which can interact with the NSI and for example instantiate new functions in the slice or alter it. The management exibility which possess the NSC depends on the Service Level Agreement (SLA) de ned with the NSP. This model is the one we rely on to de ne our satellite framework.

• Network Slice as Network Operator (NOP) internals model where the NSIs are used internally by the NOP. A NOP uses the slice for its own network management purpose and are not part of any commercial service.

Each NSI must be compliant with a Service Level Speci cation (SLS). A SLS is a set of service level requirements associated with a SLA to be satis ed by the NSI. The slice requirements in 5G are de ned by the Service Pro le parameter [START_REF]3GPP . Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3[END_REF]. It holds crucial information such as the coverage Area, the latency, the upload/download throughput per slice, the jitter or the slice service type (e.g. eMBB, MIoT). The 3GPP decomposed the end-to-end slice and introduces the Network Slice Subnet Instance (NSSI) concept [START_REF]3GPP . Management and orchestration; Concepts, use cases and requirements[END_REF] to ease the management of the NSI. The NSSI represents a group of network function instances that form part or complete the NSI components. The management of each group of network functions are conducted independently of the management of the NSI. The NSI can be composed of one or various NSSI chained together to form the end-to-end NSI.

A NSSI can be part of one NSI or be shared among multiple NSIs. For instance, a single 5G Core Network (CN) could serve multiple 5G Radio Access Network (RAN), thus a NSI for broadband services could be composed of one CN NSSI and various RAN NSSIs. Those same RAN NSSIs could also serve another CN NSSI belonging for instance to a MIoT NSI. As for the NSI, each NSSI has a set of requirements described in the Slice Pro le parameter [START_REF]3GPP . Management and orchestration; Concepts, use cases and requirements[END_REF][START_REF]3GPP . Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3[END_REF]. Those requirements are derived from the Communication Service requirements. 3GPP explicitly refers to the GSMA Generic Network Slice Template (GST) [START_REF]Generic Network Slice Template[END_REF] to be used as the SLA information for the communication with the vertical industries [START_REF]3GPP . Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3[END_REF]. The GST is translated to 3GPP Service Pro le which acts as the SLS for the slice. The Service Pro le is then translated into each Slice Pro le for the Network Slice Subnets (NSSs) and the con guration of external components such as the Transport Network (TN) (the translation operations whether for the Service Pro le or the Slice Pro les are out of scope of 3GPP speci cations).

Network Slice Lifecycle and Management Framework

The 3GPP also de nes the Lifecycle operations [START_REF]3GPP . Management and orchestration; Concepts, use cases and requirements[END_REF] for the NSI and a generic architectural management framework [START_REF]3GPP . Management and orchestration; Architecture framework[END_REF]. The management aspect of the NSI is decomposed into four phases: the preparation, commissioning, operation and decommissioning phases. The preparation phase includes all the preliminary operations before the creation of the NSI such as the design, capacity planning and on-boarding of the network slice. The commissioning phase includes the creation of the NSI, during this phase all corresponding resources are allocated and con gured in the network.

The operation phase includes the activation, supervision, performance reporting, resource capacity planning, modi cation and de-activation of the NSI. Performance measurements [START_REF] Gpp | Management and orchestration; 5G performance measurements[END_REF] for each 5G Network Function (NF) and end-to-end Key Performance Indicators (KPIs) are also de ned [START_REF]3GPP . Management and orchestration; 5G end to end Key Performance Indicators (KPI)[END_REF].

By monitoring these KPIs, it is possible to react to any behaviour of the NSI. Finally, the decommissioning phase includes the release of all nonshared resources in the network and the de-activation of the NSI. For each one of the phase, the speci cations [START_REF]3GPP . Management and orchestration[END_REF] describe the procedures and the functional elements involved.

The management framework de nes generic Management Service (MnS) components type (which can be specialized for each management purpose) and models their interactions is not yet speci cation of these MnFs.

However, speci c interfaces are de ned to instantiate and terminate NSIs as well as for the NSSIs. The 3GPP management framework also relies on ETSI NFV Framework to instantiate the components required by the slice. The NFs are packaged as ETSI VNF/PNF/NS and could be instantiated using the ETSI NFV MANO ecosystem.

Network Slice Handling in the 5G Control and User Plane

A NSI shall include the Core Network Control Plane and User Plane Network Functions plus one Access Type (e.g. NG-RAN, N3IWF). Each slice in 5G networks is identi ed with the Single -Network Slice Selection Assistance Information (S-NSSAI) [START_REF]3GPP . System architecture for the 5G System (5GS)[END_REF]. The S-NSSAI is composed of the Slice/Service Type (SST) and the Slice Di erentiator (SD). The SST identi es the service for which the slice was instantiated which could be standard (eMBB, MIoT, URLLC, V2X) or non-standard. The SD is used to di erentiate the slices having the same SST. A User Equipment (UE) can belong to maximum 8 slices simultaneously. A UE when registering on the network sends the S-NSSAIs he wants to connect to [START_REF]Procedures for the 5G System (5GS)[END_REF]. The network allocates the adequate resources to the UE based on the slice it belongs to. The registration process is not detailed here as it is a complex process and is does not help understanding slicing in 5G networks.

Subsequently, for more clarity, in the rest of the article we will refer to the network slice and network slice instance as the end-to-end network slice or in its short form end-to-end slice.

SLICING THE SATELLITE NETWORK

Section 3 described the 3GPP Network Slicing and the components which are used to create and manage network slices. The 5G Transport

Network could be of any type. In this context, the satellite network is a suitable candidate as a transport network. Integrating the satellite network as a Transport Network is also the simplest option to integrate the satellite into 5G networks as it was studied in the SaT5G project. De ning an Application Programming Interface (API) between the 3GPP management system and the Transport Networks would be su cient to con gure the satellite network to handle the slice ows and back-haul data between the 5G RAN and the 5G CN (see Figure 3). As a Transport Network for 5G back-hauling, the satellite network covers multiple 5G gNB (through the ST) and interconnects with various 5G UPF (using the satellite gateway).

This implies to reserve adequate resources on ground and space equipments (e.g. satellite gateways and satellite payloads). The resource allocation is one of the major challenges for the satellite network due to the heterogeneity of the resources (e.g computing, storage, radio in ground segment and space segment). More than the reservation and allocation of resources, the equipments need to be con gured and orchestrated in a simple, automated and comprehensive manner. The 5G network should be able to dynamically request the establishment of a back-haul connectivity and to alter it later depending on its needs.

FIGURE 3 Satellite Network Slices Integrated into 5G

Satellite networks, as built today, have the ability to back-haul 5G data with for example, encapsulation in IP or through other tunneling methods.

Nevertheless, they are not capable to fully support the dynamics inferred by the network slicing paradigm such as dynamic resource allocation and scaling. The satellite network architecture needs to evolve in order to outcome its current limitations in terms of performance and management.

Network slicing cornerstone's technologies SDN and NFV can help to upgrade the satellite network. These two technologies are also the base components to allow the unprecedented exibility of 5G networks and on which relies the network slicing paradigm. In order to integrate the satellite into 5G network slicing, satellite networks should be able to support the network slicing paradigm. Applying the network slicing concepts and partitioning the satellite network is not straightforward. Fundamental questions must be addressed and key challenges must be resolved. In order to give a comprehensive de nition to the network slice, we extract and summarize a set of challenges associated to the slicing concept in terrestrial networks [START_REF] Afolabi | Network Slicing and Softwarization: A Survey on Principles, Enabling Technologies, and Solutions[END_REF][START_REF] Zhang | Network Slicing Based 5G and Future Mobile Networks: Mobility, Resource Management, and Challenges[END_REF][START_REF] Rost | Network Slicing to Enable Scalability and Flexibility in 5G Mobile Networks[END_REF], confront them to the satellite network and identify challenges individually and propose guidelines or lines to address them. Additionally to those challenges, we take into account the constraints related to the satellite integration into 5G. We categorize all the challenges, and the category of each challenge encountered in the article is identi ed by a pre x as described in Table 1.

Integration into 5G 5G

The nal purpose is to be able to "slice" the satellite network into partitions dynamically instantiated and fully optimized for a connectivity between the 5G CN and 5G RAN. Figure 3 shows such a partitioning and gives the example of two satellite slices instantiated on top of the satellite infrastructure. The upper one is dedicated to 5G eMBB using a GEO satellite and the lower one is used for MIoT with LEO satellites.

In this section, we dive deep into the satellite network and highlight the challenges related to the slicing of the satellite network and propose solutions to address those challenges.

Satellite Resource Allocation

A key requirement for network slicing is the slice isolation. A network slice should o er multiple levels of isolation to address the various market needs. This isolation process is the result of the isolation taking place at the di erent levels of the OSI model. This isolation process can be decomposed into two subdomains: the network isolation and the resource isolation. In this section, we focus on resource allocation and isolation.

One of the major challenges for the satellite network is the resource allocation. Satellite networks, as mobile terrestrial networks, have their own complex architecture which involves three segments: ground, space and user segments. Not only the resources need to be reserved on each segment, but also satellite systems can di er greatly between each other. Ground segments could implement standards such as DVB-S2/DVB-RCS2 or use proprietary ones. Space segment capabilities are mainly de ned by the satellite orbit and payload capacity (e.g GEO satellites or mega-constellation), thus consequently in uencing the exibility of the satellite system. Figure 4 shows the need of resources reservation on each satellite segment for a 5G end-to-end slice. The 5G User Plane Function (UPF) serves multiple 5G RAN located in one or multiple satellite spot beams. This implies to allocate and share resources on the satellite forward and return link. At the satellite level, the spot beams are not necessarily served by the same satellite gateway. Thus, for a single 5G end-to-end slice, resources could be reserved and orchestrated on multiple satellite gateways. In 5G networks, the clear separation between the CN and the RAN allows the identi cation and separation of resources allocated end-to-end.

Works have been conducted on the network slice isolation in 5G networks and models have been proposed [START_REF] Kotulski | Towards constructive approach to end-to-end slice isolation in 5G networks[END_REF]. The new 5G Service Based Architecture (SBA) is clearly cloud oriented and the resources that would be allocated to the CN are exclusively Network Functions Virtualization Infrastructure (NFVI) resources such as compute, storage, and network resources. In the 5G RAN, NFVI plus radio resource are allocated [START_REF] Checko | Cloud RAN for Mobile Networks-A Technology Overview[END_REF].

Research are also considering resource allocation and isolation in the terrestrial TN [START_REF] Liu | Enabling Technologies for 5G-Oriented Optical Networks[END_REF].

The satellite slice should o er multiple types of resource allocation and isolation at the infrastructure layer (RES-I). Multiple types of resources are involved on each segment when a satellite communication is established such as network functions or radio resources. To have a proper resource isolation, we must precisely model and de ne the granularity of the resources available on each segment (e.g. a carrier and a bandwidth for the satellite gateway in the forward link or a carrier in the return link for ST). For each satellite segment, we need to identify the resource type that could be reserved and isolated. The ground segment, as described in Section 2, is composed of the control elements of the satellite network and the data elements. VITAL project proposes a Cloud RAN-like approach [START_REF] Ahmed | Software-de ned satellite cloud RAN[END_REF] in which an accurate functional split of a DVB-S2/RCS2 gateway is performed. During this process, three type of resources can be identi ed: the NFVI resources to run NFs, radio resources on the forward and return link allocated to STs and the WAN physical resources. Depending on its capabilities, the space segment only translate the RF signal from the gateway to the beams thus imply radio resources or can also onboard advanced processors and Common-O -The-Shelf (COTS) hardware.

The satellite slice could also be scaled up or down (RES-II) according to the need of the slice customer. Resources allocated to a network slice could be locked-down exclusively for this slice and not be shared with other slices. The three types of resource allocation to a satellite slice are as follows:

• Dedicated resources: The term "dedicated" is not absolute here. For instance, considering NFVI resources, using Virtual Machine (VM) technologies, we can fairly consider the isolation at the hypervisor level strong enough to describe a VM based slice as dedicated resources.

This would not be true for a container based system where linux namespaces are used instead of full virtualization. Even for VM systems, one can argue on the hypervisor type (1 or 2) and their related isolation level. Dedicated resources could be a type of allocation where a subset of hardware resources at the Infrastructure Layer is dedicated to the slice only with no sharing support. Scaling up or down the slice means in this case adding direct physical resources to the slice and those resources will remain locked-down until the slice releases them or is terminated. For instance, resources could be physical servers, physical appliances, physical links such as dark ber, Satellite Gateways or Satellite Terminals. This type of resource allocation doesn't fully exploit the infrastructure and may lock-down unused resources, hence the slice would have a higher cost and would mainly be used for critical communication services which require a high level of isolation and enhanced performances.

We de ne resources as dedicated when resources allocated to a slice are guaranteed during the complete slice lifecycle and are not scaled up or down based on the need of other slices.

• Shared resources: where there is no speci c resources at the Infrastructure Layer that are allocated only to the slice. The resources allocated to the slice could vary in function of the time and based on the need of the slice. The granularity of the resources allocated is more negrained and could be for example multiplexing slices into a carrier instead of having a complete carrier. Such an approach allows a better utilization rate of the infrastructure and therefore could lower the cost of a network slice.

• Hybrid resources: a slice could request various resource allocation types based on its need. The most expensive part of a satellite communication is the occupation rate of the radio spectrum. Sharing the spectrum can signi cantly reduce the cost of a satellite communication for a slice customer. Thus hybrid allocations can be envisioned with dedicated resources on the NFVI infrastructure and shared resources on the radio infrastructure.

Pooling the Satellite Infrastructures

Another major di erence between 5G networks and satellite networks, apart from the architecture, is the fact that each satellite system is completely or partially isolated from the others. For each new satellite system, manufacturers re-use some key technologies and adapt them such as satellite gateways or payloads, still each new satellite system behaves as a standalone satellite network. Each segment composing the satellite architecture involves di erent actors, technologies and evolves at di erent speed which also makes the orchestration of the overall network difcult. Satellite networks were mainly designed to be e cient, thus their architecture and protocols are optimized and are very speci c for each satellite system. As each satellite system is isolated and can only o er the capacity it has, satellite networks do not take full advantage of their aggregated capacities and coverage areas. Pooling all satellite systems together (Figure 5) would greatly advantage the satellite network and doing so, in this new context, the network slicing paradigm would fully make sense. Especially for the major Top-10 SNOs which own more than dozens of satellites.

Given the current satellite network architecture, it is very challenging to pool all the resources together and to fully bene t from the network slicing paradigm and SDN/NFV technologies. The architecture is not exible enough and does not take full advantage of all the satellite infrastructure to partition the satellite network into optimized slices. Pooling infrastructures also require considerable e orts to increase the interoperability between satellite components. This could be achieved through standardization and will bene t the satellite networks in all aspects. To pool the satellite resources and fully exploit the network slicing paradigm, we propose to considerably enhance the satellite architecture. enable the "slicing" of the satellite network. This architecture takes full advantage of the NFV paradigm to allocate resources e ciently and the SDN paradigm to orchestrate the ows in a comprehensive manner. We describe a functional architecture comprised of a disaggregated satellite gateway and a satellite core network that would take the satellite network to the next level and fully exploit its disbanded capabilities.

Satellite Gateway

We start by rede ning the role of the satellite gateway which executes various functions. In the traditional satellite architecture, the gateway is usually a monolithic equipment and is physically located in a satellite teleport. It handles the functionalities related to three network layers: the L3-network layer which handles the upper functions of the gateway such as VPN, Performance-enhancing Proxies (PEP), or Load Balancing; the L2-MAC and L1-Physical layer which handles the radio functions such as allocating resources to satellite terminals on the forward and return links. In our approach, the satellite gateway is not a single component anymore. With improvements on processing capabilities many components can now be run on COTS type hardware, we now consider that we are in a virtualized environment and disaggregate the satellite gateway into independent parts as shown in Figure 6. The purpose of our satellite gateway architecture is to allocate the correct resource and to remove redundancy in satellite networks:

• Service Gateway: this part of the gateway is handling all the L3 upper layer functionalities. The service gateway is composed of one or multiple service network function (e.g. VPN, Firewall, PEP) and of a service controller. Service network functions are chained together and process the satellite network data-plane ow before forwarding it to the correct radio gateway. The service controller con gures all the service network functions and chains them together. The service gateway is totally independent from the other parts of the gateway and could serve one or more radio gateway. The service gateway should be instantiated on top of a NFVI. The location of this infrastructure is most likely to be in a public or private cloud. Some functions such as the PEP should be as close as possible to the radio gateway, therefore the service gateway could be split accross a rst NFVI outside the teleport and a second inside the teleport's NFVI.

• Radio Gateway: this is the radio part of the gateway which could be speci c to the satellite system. process the ows at the L2 and L1 levels on the forward and return links. They are programmed using the southbound interface of the radio controller (e.g. frequency plan con guration, DAMA con guration for a DVB-RCS2 system). Both open and proprietary standards are compatible with our approach. The radio gateway is also fully independent from the service gateway.

• Outdoor Unit (ODU): sends and receive the signal to the space segment.

The service gateway, radio gateway and ODU can be described as network services or network functions extracted from the ETSI NFV standard.

This allows to fully bene t from the existing state of the art NFV standard and exploit the ongoing work on virtualization in terrestrial networks.

Using this type of disaggregated gateway, we are able to instantiate only the necessary resources and start to address the RES-II challenge on the scalability of the slice. Altering the slice resource will only a ect the corresponding part of the gateway (e.g. increasing the bandwidth on the radio gateway will not necessarily increase the processing power of the service gateway). This gateway, nonetheless, does only process the data ow and does not handle any policy control or network management message. Those functions are processed by the satellite core network.

Satellite Core Network

Another fundamental aspect that we need to deal with in the slice is QoS. The QoS should be supported within the slice (QoS-I) with a QoS Policy independent from the other slice (QoS-II). The satellite core network is similar to the 5G Core Network at the functionality level, it handles core network functionalities such as accounting, authentication, and network policy functions. It also handles satellite speci c functions such as the space segment con guration and the handover plus mobility functions for the MEO/LEO mega constellations. The purpose of this satellite core network is to be able to mutualize main and redundant functionalities that are present in various satellite systems, instantiate them once and be available to one or multiple satellite slices. The satellite core network is modular and depending on the need of the slice, the network functions composing the satellite core network may vary. For instance a SNO could instantiate a common slice for authentication purposes. Figure 7 shows the similarity with the 5G SBA. The Radio Gateway and the satellite space segment united are similar to the RAN in a mobile terrestrial network.

They are the radio interface used by the satellite terminal to connect to the satellite core network. The Service Gateway could be similar to the 5G UPF with the di erence that it could be also split across the cloud and the teleport.

Using this architecture, we are able to de ne the satellite slice as the composition of a satellite core network, a service gateway and one or multiple radio gateway connected to ODUs. We can then tackle the QoS-I challenge: each slice as described above natively supports QoS as we did not fundamentally change the components of the satellite network. We also address partially the QoS-II challenge but the management and orchestration of the slice need to be detailed in order to fully address this challenge. Another key requirement for the network slicing is the support The security aspect is not only related to the architecture but also to the type of resources allocated to the slice as well as the underlying technology and network functions involved in the slice deployment.

Management and Orchestration of the Satellite Slice

In the previous section, we have modeled a satellite slice. We focus here on the management and orchestration of such as slice. A satellite slice or a group of slices should be managed by a tenant. A tenant could lease / possess one or multiple slices and have for each one a speci c management policy (MO-I). A policy is a subset of rules for the slice life-cycle management based on QoS parameters, services capabilities, economic considerations and dedicated resources. The slice operations namely creation, activation, supervision, reporting, modi cation, de-activation and termination should not require manual interventions and must be automated (MO-II). Operators can trigger the previous operations but must not execute the procedures linked to each operation manually. Automation in satellite networks is a real challenge because of the current monolithic components of the satellite network architecture. SDN and NFV technologies combined together can ease the automation process and have prompt slice deployments (MO-III). Moreover, the slice management system could have su cient intelligence to trigger the life-cycle operations in an autonomous way (MO-IV) (e.g. request more resources if needed).

Satellite Slice Role Model

To anwser those challenges, we start by de ning a role model. Based on the 3GPP slicing role model, we propose a role model (Figure 8) and identify the current satellite actors manipulating the slicing concept:

• Satellite Slice Customer is the user and tenant of the satellite slice. It could be a 5G terrestrial operator who wants to back-haul 5G data or a broker leasing multiple slices to multiple Satellite Slice Provider in order to provide multiple connectivity to its customer. The slice customer could also be a service provider who wants to run Over the Top (OTT) services.

• Satellite Slice as a Service Provider owns a slice management system to design, run and manage slices on the top of the the satellite infrastructure. The slice provider has the ability to provide slices with di erent levels of exibility to a slice customer. The type of slices and services he could o er also highly depend on the infrastructure capabilities. The SNO, Satellite Virtual Network Operator (SVNO) or a dedicated slice operator could act as slice providers.

FIGURE 8 Role model for satellite network slicing

• Satellite Network Operator owns the satellite space segment and the satellite VNF/PNF provided by suppliers (e.g. Eutelsat, SES, ViaSat).

VNFs/PNFs can be monolithic components such as satellite gateways and satellite terminals or be disaggregated components such as DVB modulator/de-modulator or encapsulator (e.g. iDirect, Newtec, Teamcast).

• Infrastructure Service Provider builds, manages and maintains a virtualized infrastructure (e.g. OVH, Scaleway). The NFVI supplier provides the management system for the infrastructure, it is usually a software company (e.g. VMWare, RedHat).

• Satellite Teleport Provider is the proprietary of the overall infrastructure. It builds the satellite teleport and con gures it with its desired ODUs according to its clients demand. The teleport could be used by multiple SNO or SVNO, it is not dedicated to a speci c tenant. The teleport provider also builds and maintains a backbone between all its teleports and ensures that each one is constantly connected to its customer network.

This role model does not fundamentally change the current role of satellite actors. It introduces new actors related to the NFV technology. Each actor could of course assume one or multiple roles and it would be most likely the case (e.g. the SNO and the slice provider being the same actor).

Satellite Management System

We now de ne how the satellite slice would be instantiated and orchestrated. The system we de ne is mostly inspired by the ETSI NFV framework to maximize the compatibility with existing MANO systems (e.g. ETSI OSM [START_REF]Open Source Mano[END_REF]). Figure 9 shows the management system we have de ned.

The satellite manager exposes the satellite network APIs to the external OSS/BSS which could be considered as the customer interface. These

APIs are used to request the creation of a satellite slice. It either exposes prede ned slices present in the satellite slice repository or a list of KPIs such as the upload/download throughputs, latency or coverage area. The GSMA GST could be used here as it is de ned to be generic and network agnostic. When based on KPIs to request a slice instantiation, the satellite manager acts as a proxy and forwards the list of parameters to the satellite slice designer. The satellite slice designer's main role is to design the optimal satellite slice in an automated manner according to the parameters received from the satellite manager. The designer holds the intelligence to translate the generic requirements into satellite understandable parameters. Such algorithms do not exist today and need to be de ned. For instance, upload/download throughputs and latency can be translated to a speci c space segment associated to a set of radio functions on the forward link (e.g. DVB-S2 with a dedicated bandwidth) and on the return link (e.g. SCPC). To determine the optimal satellite slice, the designer relies on two repositories: the space segment repository and the ground network function repository. The space segment repository contains all space segments available of the satellite networks and their associated SNC.

This repository results from the pooling of the satellite systems together. The ground network function repository holds the satellite core network functions, the disaggregated satellite network functions and the ODU functions. Based on the requirements and this latter repository, the slice designer composes the adequate satellite core network, service gateway, radio gateway and ODU.

Each function and the resulting slice are modeled using the ETSI NFV VNF/PNF and network services representations. The designer outputs a satellite slice de nition and appends it to the satellite slice repository. The satellite manager, when instantiating the slice, determines the optimal network functions placement in the infrastructure using the resources repository. This repository contains all the available infrastructure resources in each cloud/teleports. Some work have already been proposed to address the VNF placement in a satellite slice [START_REF] Ahmed | On-Demand Network Slicing using SDN/NFV-enabled Satellite Ground Segment Systems[END_REF]. Based on the resource usage, the satellite manager selects the appropriate clouds and teleport. Then it requests the satellite MANO system to instantiate all the corresponding network services in the selected infrastructures. As the instantiation process could imply to con gure the space segment, the satellite MANO system is upgraded to be able to communicate with the SNC when instantiating the resources at various location.

OSS

Slice Management System

For each slice, the satellite manager also includes a unique slice orchestrator. This ensures the independence between each slice and answers the MO-I challenge related to the management policy of the slice. The slice orchestrator is the component responsible for the slice initial con guration, modi cation, supervision and termination of the slice. In case the slice radio resources are shared with other slices, the orchestrator coordinates with the teleport NMS. It also needs to coordinate with the satellite manager in order to request more resources if needed. The slice orchestrator exposes the slice management interface to the slice customer. Through this interface, the customer can interact with the slice and orchestrate all its components. The interface exposed by the slice orchestrator can be complex allowing a satellite actor with su cient knowledge to ne-tune the slice parameters (e.g. radio gateway parameters) or a basic interface for external users.

Coupled with the architecture de ned in Section 4.3, we are able to fully address the MO-II and MO-III challenges related to the automated slice life-cycle and the prompt deployment. The autonomous aspect of the slice is in our opinion a prematurate challenge to address in the satellite context. The rst step and the main e orts need to be put into the wide deployment of NFV and SDN technologies in satellite networks.

NETWORK SLICING FOR SATELLITE INTEGRATION INTO 5G

In this section we list the challenges related to the satellite slice integration into a 5G end-to-end slice and propose a solution to interface them based on 3GPP speci cations.

Integrating the Satellite and 5G Management Systems

The work on 3GPP slicing framework is still on-going and the integration of the satellite slice into the 5G network must be compliant with the current 3GPP speci cations with some major constraints: the satellite and 5G networks must remain independent from each other in terms of underlying management and infrastructure (5G-I). Moreover, to have a seamless integration, the complexity of the satellite network must be hidden to the 5G network operator (5G-II).

Role Model

In the following, we consider the role model de ned previously in Section 4. [START_REF]IMT-2020 Network Management and Orchestration Framework[END_REF]. In order to ensure the independence between the satellite and the 5G networks, we rst identify the role of each satellite and terrestrial actor. The simplest and straightforward way is to consider the 5G end-to-end slice provider as a satellite slice customer. This permits to isolate the way the 5G mobile operator and the satellite actors manage their underlying networks, it answers the challenge 5G-I as there is a clear separation between the 5G networks and the satellite networks. The satellite slice orchestrator could abstract the satellite complexity and expose simple APIs such as bandwidth management. Nonetheless, we want to integrate the satellite slice in a transparent way in the 5G networks and providing satellite speci c APIs, as simple as they could be, would not be su cient enough.

Interfacing the Satellite and 5G Networks

Independently from the scenario, three major phases are to be considered when establishing the 5G end-to-end slice as described in Figure 10:

the high-level negotiation between the 5G and satellite management systems, the instantiation of all the elements which compose the end-to-end slice and the stitching of all these elements.

The goal of the rst phase is to de ne the interface between the satellite and the 5G network. Through this interface the 5G management system requests the satellite management system to instantiate a satellite slice based on 5G requirements. This satellite slice will be used to back-haul data between the 5G RAN and CN. In the second phase the satellite management system derives the 5G requirements into satellite requirements, instantiates the satellite slice and con gures it. Section 4 described how the satellite slice is modeled in the underlying architecture and how it could be instantiated. The 5G management system also instantiates the 5G slice subnets in this phase, the process is out of scope of this paper.

The third and last phase is the stitching between the satellite slice, the 5G CN slice subnet and the 5G RAN slice subnet. This phase is described in Section 5. [START_REF]IMT-2020 Network Management and Orchestration Framework[END_REF].

We focus here on the negotiation phase.

FIGURE 10

Major phases for end-to-end slice instanciation

Considering the satellite slice as a 3GPP network slice subnet would be a logical step. In this case, the satellite network would inherit the 3GPP speci cations on network slicing. The satellite network would therefore adopt the management framework of the 5G networks and implement its slice subnet life-cycle procedures (e.g. feasability check, instantiation, modi cation, termination). The satellite management system would behave as a NSSMF regarding the 5G NSMF and implement the slice subnet management interfaces (allocateNssi and deallocateNssi). These two interfaces are used to instantiate and terminate a network slice subnet by sending a list of parameters (the Slice Pro le data [START_REF]3GPP . Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3[END_REF]). As a network slice subnet is currently not designed to support multi-tenancy, the parameters sent through those interfaces are su cient for a single network operator orchestration but not to instantiate and stitch any external network slice subnet. Using only the SlicePro le is therefore not enough for the satellite management system, it would have to implement more mechanisms and interface to complete the 3GPP interface (e.g. slice/service type exchange, endpoint exchange).

The satellite management system could expose the 5G end-to-end slice management interfaces to the 5G network management system as shown in Figure 11. This does not change fundamentally the procedures described in section 3 for the 5G end-to-end slice's life-cycle. As the satellite network is considered like a slice subnet, it will only change the methods invoked by the 5G management system to interact with the satellite network management system. Instead of using the slice subnet management interfaces, we propose that the satellite network implements the end-to-end management interfaces (allocateNsi and deallocateNsi interfaces). They are dedicated to the 5G end-to-end network slice management, thus are more complete than the network slice subnet ones. Crucial parameters (Service Pro le [START_REF]3GPP . Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3[END_REF]) for the satellite network such as the download throughput, the latency, the upload throughput, the kPIMonitoring, coverageArea, resourceSharingLevel and the jitter could be passed using the interfaces dedicated to end-to-end slice. The satellite management system could then derive and re ne those parameters to determine the optimal equipments and con gurations to deploy. Besides, the satellite network would still be compatible with the 3GPP speci cations. Implementing these interfaces into the satellite management system will be su cient to communicate with the 5G management system in an automated manner. Using these interfaces, we are able to address the challenge 5G-II on the seamless integration of the satellite slice into the 5G end-to-end slice. Another major bene t of applying the end-to-end slice interfaces and speci cations to the satellite network is also to be able to use all the speci cations related to the end-to-end KPI performance measurement.

FIGURE 11 Satellite Slice Interfaces

The 3GPP work on network slicing is not over yet. Speci cations do not provide a normative way to interconnect the various network slice subnets composing the network slice and to ensure an end-to-end service. The speci cations seem only to provide mechanisms to nd the optimal allocation of resources for each slice subnet and to lock-down these resources for the 5G end-to-end slice. It does not specify procedures and methods to con gure endpoints and handle the 5G tra c between the slice subnets. Other SDO are currently working on a standardized way to interconnect network slices. Therefore, additionally to the interfaces already speci ed in 5G, procedures and mechanisms have to be de ned in order to stitch the various network slice subnets and to ensure an end-to-end service.

Defining the Slice Interconnection Level

In this section, we list the challenges related to the stitching of the slice subnets. The operation of stitching is the process to create the end-toend slice based on existing network slice subnets. The objective of this interconnection is to ensure that the performance requirements of the 5G end-to-end slice are ful lled. The QoS should be supported within the end-to-end slice, the continuity of QoS across the 5G and satellite domain is therefore fundamental. The "end-to-end" requirement implies to also have a QoS continuity across all the network slice subnets (5G-III). Each network slice subnet has its own management, control and data planes, thus we need to determine at which level and how they can be interconnected. Stitching the network slice subnets is a challenging task when the 5G end-to-end slice must respect the end-to-end KPIs requirements.

Each slice subnet is isolated from the others and processes the packets using its own internal QoS system. The 5G network uses 5QI Class of Services (CoSs) which can be standard or non-standard classes. It manages internally the mapping between the 5QI classes, the radio resources and the DSCP classes. The satellite network uses custom QoS classes which could be applied at the L3 and L2 levels. Uni ed CoS for the 5G and satellite network is most likely impossible as the two networks are too heterogeneous. The immediate and more common option is to do a QoS mapping between the 5G CoS and the satellite ones. The network functions from the CN communicates with the 5G RAN using the N2 and N3 reference points. The N2 reference point is dedicated to the communication between the AMF and the gNB (control plane through SCTP) and the N3 reference point is between the UPF and the gNB (data plane through GTP-Uv1). Both reference points are processed indiscriminately in the satellite data plane (Figure 12). Therefore a single mapping between the 5G 5QI and the satellite QoS classes is not enough, the 5G control plane needs to be taken into account. The unprecedented exibility of 5G networks could also change dramatically the architecture of the 5G deployments (e.g. backported CN network functions closer to the RAN). This could introduce new protocols, thus new QoS rules to take into account and the satellite slice would have to adapt quickly. Moreover, the 5G network operator could consider the satellite network not secure enough and use encryption protocols such as IPsec to cipher the ow between the 5G UPF and the 5G RAN. This encrypted ow obfuscate the N2 and N3 interfaces to the satellite network which would not be able to correctly handle the packets. A static QoS mapping and traditional QoS forwarding mechanisms is in our opinion not a long-term solution. We propose a more generic solution supporting the automation process and the high dynamics of the 5G networks.

Supporting the dynamics of 5G networks

The 5G network needs to coordinate with the satellite network to establish the link between the 5G CN and the 5G RAN. Static QoS forwarding is not enough to support the dynamics of network slicing. We want to propose a solution which supports the dynamics of 5G networks and which could be usable beyond 5G. Figure 13 shows the dynamic QoS negociation process. The satellite management system exposes an interface dedicated to this coordination. Through this interface, the 5G management system sends a set of QoS rules associated to the slice's ows (step 3).

The rules sent by the 5G management system must be understandable by the satellite management system, thus the interface exposed must be built conjointly with the 5G operator. Then, the satellite management system derives the QoS rules associated to the slice: the satellite management system analyzes the set of QoS rules sent by the 5G network (e.g. latency, priority) and maps those rules to its internal QoS system. The satellite management system creates a table to associate them with the 5G QoS rules. For each slice that would be requested by the 5G network, a unique table will be created and this procedure repeated. The uniqueness of the QoS table for each slice guarantees the independence of QoS between each slice. If the satellite management system cannot derive and respect one or multiple QoS rules sent by the 5G network, it proposes alternatives or rejects these QoS rules. This process ensures an optimal mapping is found between the QoS of each slice subnet and contributes to the QoS continuity between the slice subnets. It could be reiterated to update the tables during the slice's life-cycle. After nding the correct mapping of QoS at the control plane (step 4), the 5G network sends another batch of rules (step 5) but to identify the ows in the data plane associated with the slice and the QoS rules sent before. The rules are basically standard matches on packets elds (e.g. VLAN, IP, MPLS). The satellite management system then creates a QoS data plane the satellite network and the 5G RAN. Figure 14 shows the internal process of the Slice Classi er. In this gure, the classi er interconnects the 5G CN (west interface) with the satellite slice (east interface). Each interface has inbound ows which need to be translated to the correct outbound ows. Each inbound ow is marked as belonging to a speci c slice and QoS class. The classi er constantly maintains in memory a slice table and a unique QoS table associated to each slice. The ow is processed through the classi er which inspects each packet of the ow and matches a set of elds to identify and replace rst the slice identi er and then its associated QoS in the packet. For instance, as the classi er needs to handle the N2 and N3 interfaces (as explained in section 5.2) the inbound ows of the west interface could match on the SCTP ports or GTP-U TEID elds to identify the slice and the DSCP eld to identify the QoS. The classi er then takes actions based on the match (e.g. push MPLS label) to translate the ows for the satellite network. More matches and actions are possible as the purpose of this process is to translate the inbound ows into understandable ows on the opposite interface for the next slice subnet. However the translation process must not be time consuming and alter the performances (e.g. add overhead in the packets which minimizes the spectral e ciency of the radio link in the satellite network). Simple matches such as VLAN tags or MPLS label are the best option to identify both slice and QoS.

The tables in the classi er are regularly updated by the classi er control plane which is managed by the satellite management system. The slice classi er could also play the role of end-to-end encryption device in the satellite slice. This ensures an extra security layer (addresses the challenge

SEC-I).

In this section, we have proposed a method based on 3GPP speci cations to integrate the satellite slice into 5G end-to-end slices. Using the dynamic QoS negotiation and the slice classi ers, we are able to fully address the challenge 5G-III on the QoS continuity across the integrated satellite slice.

CONCLUSION

The satellite networks, by essence, have capabilities the terrestrial networks do not have. Empowered by NFV and SDN, satellite networks have a serious card to play in the deployment and the integration into future mobile networks. In this paper, we have de ned a satellite slice framework by confronting the satellite network to the network slicing challenges. We have summarized all those challenges in Table 2 We have shown the bene t of a network slicing approach for the satellite network and how it could take the satellite to the next level. However this is only possible due to adoption of the NFV and SDN technologies which are insu ciently deployed in the satellite architecture. We also de ned an evolved satellite architecture to pool all the satellite infrastructures together. This pooling process allows to fully exploit the satellite architecture, aggregate all the satellite systems together, thus reducing costs, open the way to new markets for the satellite actors. To pool the satellite infrastructure together, e orts need to be put in the standardization of the satellite network architecture and protocols. We also show, using this evolved satellite architecture as an enabler and the current 3GPP speci cations, how the satellite could be integrated into a 5G end-toend network slice. The integration needs to add some mechanisms notably to handle ows between the 5G slice subnets and the satellite slice and to ensure the end-to-end QoS leading to the introduction of slice classi ers.

We are currently implementing this architecture in a test-bed using a DVB-S2/RCS2 satellite emulator (a modi ed and containerized version of OpenSAND [START_REF]Viveris Technologie[END_REF]) and an open source 5G network (free5GC [36]).

4 FIGURE 4

 44 FIGURE 4 Resource Reservation on Satellite Segments for a 5G Slice Backhauling

FIGURE 5

 5 FIGURE 5 Pooling Satellite Systems to Slice the Satellite Network

FIGURE 7

 7 FIGURE 7 Satellite Core and Radio Networks

5 . 4

 54 Slice Classifier to Stitch the network slice subnetsTo stitch the satellite slice with the 5G slice subnets, we introduce Slice Classi ers. Slice classi ers are the equipments placed at the border of the satellite slice and are the interconnection points between the satellite slice and the 5G slice subnets. They replace the traditionnal BNG. Slice Classi ers, handle the tra c between the interconnected slices and ensure the QoS continuity in the data-plane between each slice subnet. The Slice Classi ers are responsible for the translation of the ows for each network domain. They ensure that each packet belongs to the correct slice and has the adequate QoS class at the frontier of each network domain. Slice subnets are interconnected through the classi er's west and east interfaces. In our context, Slice Classi ers translate the ows between the 5G CN and the satellite network then translate back the ows between

  . Each component type can interact with another type using a speci c set of interactions. The interaction model used by the components is the consumer/producer model. Based on these MnS, Management Function (MnF) can be built. A MnF is composed of various MnS. As of this writing, although MnF examples are given such as the Network Slice Management Function (NSMF) for slice instantiation and management or the Network Slice Subnet Management Function (NSSMF) for slice subnet instantiation and management, there

5G Core Network Slice Subnet MIoT Core Network Functions Data Network Satellite Infrastructure SCC SNC SMC NCC Satellite Gateway Satellite Gateway GEO Satellite Satellite Terminal Satellite MIoT Transport Network Satellite Broadband Transport Network 5G RAN Infrastructure 5G CN Infrastructure COTS COTS COTS COTS COTS 5G Core Network Slice Subnet Broadband 5G RAN Slice Subnet MIoT 5G RAN Slice Subnet Broadband

	5G Core Network	Satellite Transport Network	5G Radio Access Network
							UE
	Data	Core Network
	Network	Functions
							UE
							UE
							UE
				BNG
			LEO Satellites	BNG	Central Unit	Central Unit	Distributed Unit	Distributed Unit

TABLE 1

 1 Category of challenges related to satellite network slicing

	Network Slicing Challenges	Pre x
	Slice Resource Allocation	RES
	Slice Isolation	ISO
	Slice Management and Orchestration	MO
	Slice Quality of Service (QoS)	QoS
	Slice Programmability	SP
	Slice Security	SS

  Similar to a RAN in Terrestrial Mobile Networks Similar to the Core Network in Mobile Terrestrial Networks

					Space Segment
	Satellite Core Network
	Mobility	Space Segment
	Management	Management
	Function	Function
	Authentication	Network	Satellite Teleport 1
	Function	Policy
		Management
	User Database Function	Function ...	Service Gateway	Radio Gateway	ODU
			Satellite Teleport 2		Beam 1
	External Network	Service Gateway	Service Gateway	Radio Gateway	ODU
	Broadband			Beam 2
	Network
	Gateway

  Table based on the QoS Tableandthe ow rules sent by the 5G management system. This table will be pushed to the slice classi er along with the Slice Table.If new ows in 5G slice appears (e.g new PDU session), the 5G management system will regularly send new rules to the satellite network.

					Satellite
					Management System
			1.1		1.2	1.3
	System 5G Management	1	Satellite requirements Translation of the	allocation optimal resources Determine the	Slice the Satellite Instantiate
		2 successfully instantiated
			3.1		3.2	3.3
	5G Management System	QoS rules associated to the slice 4 the QoS mapping 3	Derives the QoS rules associated to the slice	Find the correct mapping between the 5G QoS and the Satellite QoS	Create a Map QoS Table for the slice
						Slice 1 QoS Table
			5.1		5.2	Satellite	5G
	5G Management	5 to the QoS and the slice	Create the slice Map Table to associate	Create the QoS Data-Plane Table	sat_qos_1 5g_qos_1 sat_qos_2 5g_qos_2
	System	6 successfully mapped	the 5G slice with the Satellite slice	based on QoS Table	sat_qos_n 5g_qos_n
			Slice Table	Slice 1 QoS dataplane Table
			Satellite	5G	Satellite	5G
			sat_slice_1 5g_slice_1
			7
		FIGURE 13 Dynamic QoS negotiation process

  and explicit each Step for implementing Network Slicing in Figure 15.

			Service Architecture
	Satellite Networks	1	Satellite Gateway Satellite RAN and CN Architecture	2	Flexible Satellite Systems
		Softwarization and Virtualization			Pooling Satellite Infrastructure	3	Slicing the Satellite Network according to
						Slice 1
						Slice 2
						...
						Slice N
						4	Satellite Slice Integration into 5G
			5G Core Network	Slice	Satellite Slice (e.g Broadband)	Slice	5G RAN
				5		5
				Stitching		Stitching

FIGURE

[START_REF] Anzalchi | Beam hopping in multi-beam broadband satellite systems: System simulation and performance comparison with non-hopped systems[END_REF]

High-Level Steps for Satellite Slicing Implementation and Integration into 5G

TABLE 2

 2 Challenges related to satellite network slicing and proposals

	Resources Allocation	Challenge number	Proposition
	Resources Isolation	RES-I	Hypervisor, Network Functions, Encryption
	Resources Scalability	RES-II	Virtualized Infrastructure, Hypervisor
	Quality of Service	Challenge number	Proposition
	Support the QoS within the slice	QoS-I	Re-use the satellite components
	Independent QoS Policy between each slice	QoS-II	Independent Orchestration, Slice Isolation
	Isolation	Challenge number	Proposition
	Network Isolation	ISO-I	Protocols, Encryption
	Management and Orchestration	Challenge number	Proposition
	Independent Management Policy Per Slice	MO-I	Single Slice Orchestrator Per Slice
	Automated Life-cycle Operations	MO-II	Virtualized Infrastructure, Management System
	Prompt Deployment	MO-III	Virtualized Infrastructure, Management System
	Autonomous Life-cycle Management	MO-IV	Not Addressed
	Programmability	Challenge number	Proposition
	Slice should be programmable	SP-I	Not Addressed
	Security	Challenge number	Proposition
	Customize Security Mechanisms Per Slice	SEC-I	Hypervisor, Encryption, Slice Classi ers, Security Network Functions
	Satellite Speci c	Challenge number	Proposition
	Flexibility in Slice Orchestration	SAT-I	APIs exposed by the Orchestrator, Disggregated Architecture
	Fully exploit the satellite architecture	SAT-II	Pooling the infrastructures
	5G Integration	Challenge number	Proposition
	Independence between the 5G and satellite networks	5G-I	Role Model, APIs
	Transparent satellite integration into 5G	5G-II	Implement the 3GPP interfaces
	QoS Continuity across the 5G end-to-end Slice	5G-III	Slice Classi ers

ACKNOWLEDGMENT

The authors would like to thank the Newcast and Phoebus Team of IRT Saint Exupéry for their involvement and their support in the research and understanding of satellite payloads and physical layer.