It is widely recognized that, to be successful and meet user demands, the 5G infrastructure will be an ecosystem of networked networks, utilizing multiple different and complementary technologies [1
]. The advanced communication functions of 5G are expected to bring enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communications (URLLC), and massive Machine Type Communications (mMTC), as shown in Figure 1
In 4G mobile networks, the integration of Satellite Communication (SATCOM) was based on proprietary tailored solutions at both SATCOM and mobile network level [4
]. In the discussion of backhaul technologies, satellites were rarely considered as a cost effective solution in previous generations. The reasons for this attitude are manifold, ranging from commercial doubts to technological biases. In the latter context, various technical constraints such as throughput deficits, delay requests, or unsupported network functions are usually invoked.
With the explosion of data services, Mobile Network Operator (MNO) are looking for new technologies to expand their networks and provide more capabilities to their customers. One key challenge for rural and remote 5G deployments is how to backhaul network traffic in a way that makes it affordable for MNOs to extend their services. Coverage will always remain an issue for a standalone mobile network. Satellites can extend terrestrial networks to improve coverage (see Figure 2
). Moreover, satellites in the Geostationary Earth Orbit (GEO) provide efficient delivery of content across multiple sites with similar transmission delay, which is a main requirement for live broadcast to a certain area [7
]. The next generation of GEO satellites can benefit of more powerful and more flexible ubiquitous coverage through a dense spot beam architecture [8
In addition to the current fleet of geostationary and Medium Earth Orbit (MEO) satellites, the next-generation MEO satellite systems, such as the O3B mPOWER constellation, will be very flexible with 30,000 fully-shapeable and steerable beams. The next generation MEO satellites will utilize more than 5000 beams per satellite to provide capacity where it is required [10
The development of a convergent satellite-terrestrial architecture, tailored to the satellite capabilities and to the targeted use cases, is one of the key challenges [12
]. New technologies such as virtualization and cloud infrastructure at the edge of the cell are considered to meet the 5G requirements and use cases [13
]. In contrast to the previous mobile network developments, an increasing use of testbeds implementations for experimenting and evaluating new ideas has been extended in 2018 [14
]. Software-Defined Radios (SDRs) and the application of software based network functions make this kind of testbeds a reality for the academics, innovative research center and new partners to verify novel approaches without relying only on simulations [16
]. These testbeds are large projects that have started with 4G architectures and are moving towards 5G architectures based on the 3rd Generation Partnership Project (3GPP) Releases. In the past, SATCOM networks were based on proprietary hardware, that hinder the integration with future 5G networks [8
]. With the virtualization paradigm, a key technology could enable new innovations for the satellite ground equipment as well as the application of new 5G protocols and algorithms.
To evaluate 5G technologies over a convergent satellite-terrestrial architecture and to support the 3GPP and the European standardization efforts, practical demonstrations by means of testbeds, as shown in [17
] are required. They are pioneering for this kind of architecture and provide a platform to demonstrate the 5G satellite use cases. In addition to the EU H2020 project “Satellite and Terrestrial network for 5G” (SaT5G) [19
], the European Space Agency (ESA) funded “Demonstrator for Satellite-Terrestrial Integration in the 5G Context” (SATis5) [20
] project has been set up. It deals with the integration of satellites into a European large-scale 5G testbed with access to over-the-air demonstration test capabilities using GEO and MEO satellites.
ESA’s SATis5 testbed aims to practically demonstrate backhaul connectivity using 5G prototypes of satellite and terrestrial network elements working together to operate the satellite and terrestrial networks seamlessly. The testbed covers over-the-air satellite field demonstrations in addition to laboratory emulations and simulations in a federation of testbeds.
The development of the testbed is a multistage process that has started with the deployment of a virtualized edge node. The edge node includes functions of the packet core and is able to connect to the central core network through either satellite or terrestrial backhaul. First, the satellite path was implemented locally via a satellite emulator. After the first tests with the satellite emulator, a real edge network was deployed in Berlin, Germany, in November 2018.
This article describes two over-the-air demonstrations using geostationary satellite links as brought in by the project partners. This approach allows thorough testing and validation of all features required for the final phase. This is basically the deployment and simultaneous management of further static and nomadic edge nodes to prove the large-scale capabilities of the architecture. This article describes the first over-the-air demonstration tests using the SATis5 testbed based on a 3GPP Release 15 core network.
The rest of the paper is organized as follows. The SATis5 use cases are outlined in Section 2
. In Section 3
, the SATis5 testbed architecture is briefly presented. Section 4
describes the satellite emulator which allows a testbed utilization without satellite capacity. Section 5
presents the setup of two SATis5 over-the-air experiments utilizing a GEO satellite backhaul. Section 6
provides the conclusion.
2. SATis5 Use Cases
The SATis5 project focuses on the 5G use cases of eMBB, and mMTC [21
] and in particular on the backhauling use cases analyzed as a 3GPP SA1 Study Item and specified in [22
]. Satellite use cases for eMBB have been shown in [23
]. SATis5 has selected satellite use cases for eMBB and mMTC to be further investigated and tested through over-the-air demonstrations based on the SATis5 testbed [21
]. The SATis5 use cases for eMBB and mMTC correspond to the four satellite use case categories shown in Figure 3
. It should be mentioned that the eMBB and mMTC use cases are associated to several 5G market verticals, such as media and entertainment, transportation, logistics and automotive, manufacturing, health, utilities, agriculture industry, and public safety.
Satellites are very efficient in multicasting or broadcasting large eMBB data over a wide area directly to the users. 5G Satellite networks help to relieve the eMBB traffic of terrestrial 5G networks during rush hours by multicasting or broadcasting non time-sensitive eMBB data in idle times. An eMBB use case for Trunking and Head-End Feed would be the distribution of rich to very rich TV content due to new media encoding format such as 3D or Ultra High Definition video content.
Furthermore, disasters could lead to the unavailability of the eMBB terrestrial service in certain areas. The deployment of terrestrial 5G services may not be provided for Backhauling and Tower Feed due to economic profitability reasons in this areas. In addition, some users would like to use eMBB services such as broadband access or governmental public safety applications.
eMBB use cases for Comms on the Move
and Hybrid Multiplay
are related to grant users permanent access to 5G services while switching without service interruption between satellite and terrestrial networks. Moreover, this kind of use cases including moving land mobile or maritime and airborne platforms. In the eMBB satellite use case category, users may experience conditions where 5G services can only offered by satellite networks during the movement of the user [22
Typical mMTC use cases link small sensor devices to track containers including Comms on the Move
applications with drone swarms, as shown in [24
]. Backhauling and Tower Feed
use cases for mMTC include low bit-rate broadcast services such as emergency messages for sensor devices.
3. SATis5 Testbed Architecture
This paper proposes an network architecture to provide high bandwidth connectivity through base stations backhauled by geostationary satellites. The architecture for this testbed network aims to consider the latest 3GPP standardization and extend it with satellite inter-working functionality. The testbed system includes an edge node and a central core network node using a satellite backhaul connection among other backhaul opportunities, as shown in Figure 4
. The User Equipment (UE) connects to the edge node, which then connects to the central core network node through the satellite backhaul. The backhaul is seen as a transport layer for the messages between the edge node and the central core network site. Because of this, the backhaul is as transparent as possible, while at the same time assuring a guaranteed communication quality. The core network consists of the specific functions defined by 3GPP for the 5G core network. In the architecture for the SATis5 testbed, the Fraunhofer FOKUS Open5GCore toolkit [25
] has been deployed as the implementation of the 3GPP 5G core network. It provides a prototype of the 3GPP Release 15 for the core network functionality and its integration with 5G New Radio.
Note that that there are two major modes being developed by 3GPP to deploy radio base stations in 5G: the Non-Standalone (NSA) mode and the Standalone (SA) mode. In NSA mode, the 5G radio base station is co-located with an Evolved Node B (eNB) and connects to the Evolved Packet Core (EPC). In this model, the next generation Node B (gNB) acts as a secondary cell to provide capacity and throughput. This does not require a new core network, the Next Generation Core (NGC), and is an appealing option to network operators. To deploy 5G in SA mode requires the NGC instead. The SA architecture has been considered as a future Phase 2 item (Release 16 and Release 17 of the 3GPP 5G standardization process). In this testbed demonstration, we consider an NSA-like architecture, as illustrated in Figure 5
with the only difference that we use COTS eNBs for the RAN instead of gNB implementation because the latter are not yet commercially available. The background for this architecture was prepared with the LTE introduction of the concept of dual connectivity that allows the UE to connect simultaneously to two different base stations. These basestations do not need to be time-synchronized and therefore are not required to be collocated at one site.
Option 3: Traffic is split across 4G and 5G at eNodeB.
Option 3a: Traffic is split across 4G and 5G at EPC (S-GW).
Option 3x: Traffic is split across 4G and 5G at 5G cell.
In this testbed demonstration study, we considered an NSA Option-3-like architecture and the traffic is split across 4G and 5G at eNodeB. The main core network functions deployed in our testbed demonstration are listed below:
The Home Subscriber Server (HSS) is the master user database.
The Serving Gateway (SGW) is the interconnection point between the radio side of the network and the EPC. It forwards the uplink data traffic to the Packet Data Network Gateway (PGW).
The PGW provides connectivity to external packet networks.
The Mobility Management Entity (MME) is responsible for all the control plane functions related to session management and subscriber services.
Furthermore, an additional network function has been added to the edge node that is able to determine which backhauls are available, and forwards the specific traffic according to a set of routing policies over the satellite backhaul or an available local MNO network. In addition, we use 4G eNB for the Radio Access Network (RAN) part instead of 5G gNB implementations for all of our base stations because the latter were not yet commercially available at the time of the over-the-air experiments. The final deployment (Figure 6
) of the SATis5 testbed will include more edge node functionalities to deploy further core network elements at the edge of the network.
The final version of the SATis5 testbed will consist of two star-shaped backhaul networks, with one satellite hub in Munich and one in Betzdorf. The core network is located in Berlin and is connected to the hub locations via a best effort Internet connection. At each location of the local radio access networks, there is an edge node, satellite modems with outdoor equipment and at least one mobile base station to provide service to the UEs.
In this article, we present two testbed demonstrations with different satellite ground segment elements. The main difference between the two designs is that in Setup 2 (Section 5.2
) conventional point-to-point satellite modems were deployed because the Newtec Dialog 1IF satellite hub, which will be utilized in the final testbed, was not installed until this testbed demonstration. This basically means that no control signals are exchanged between the core network and these modems and therefore no management of this equipment is possible for a third party MNO. This setup is comparable to an existing user of satellite communication who wants to offer his communications service to an MNO (e.g., leased line).
With Setup 1, however, the iDirect satellite hub and modems offer integration into the overall 5G network architecture, as various concepts such as software defined networking in the Satellite Convergence (Sat Conv) layer are already taken into account in the design of these modems and the satellite hub, which are utilized in a star network topology. For an MNO, this has the advantage that it can manage these modems and the satellite hub in its network by itself. For cost reasons, various business models will be developed for the integration of satellite into a 5G network. The provision of a certain bandwidth via conventional legacy equipment with a guaranteed failure probability as in Setup 2 can also be of importance here, which is why this use case will also be investigated.
An overview of the architecture for the testbed demonstration Setup 1 in Section 5.1
is illustrated in Figure 7
and is described in detail thereafter.
The satellite ground segment corresponds to the iDirect Velocity Intelligent Gateway (IGW) system residing at the teleport site introduces a standard 3GPP core network (SatCore) to the satellite hub platform. Functions of the existing satellite network are offloaded, allowing SatCore to operate and manage network as a standard terrestrial 3GPP network. The existing satellite network is modified to comply standard RAN, referred to as Satellite RAN (SatRAN), node to the SatCore. In addition, the remote satellite terminal is modified to present itself as a standard UE to the network, which allows it to connect to a SatCore in order to access network services. Thus, the existing satellite network has been modified to comply with the standard 3GPP core network architecture. That is, SatRAN has been modified and Ni interfaces to SatCore have been aligned to the 3GPP core network. As such, SatRAN presents itself as a standard 3GPP Cellular RAN, whereas the remote satellite terminal presents itself as a standard 3GPP Cellular UE to the network. This enables support for 3GPP services, such as authentication, billing and policy and charging. This also enables the management of the satellite network by the Mobile Network Operator (MNO) in a seamless way, as if the MNO manages a standard 3GPP 5G cellular access network. As such, roaming between satellite and terrestrial mobile networks is enabled by such architecture. In fact, the SatCore may be operated by the MNO or the Satellite Network Operator (SNO), depending on the business model, and there may even be separate 3GPP core networks for the MNO and SNO networks. Initially, the existing non-3GPP based physical layer (e.g., DVB-S2x/RCS2 based) is used over the satellite, which allows faster satellite integration into 5G. However, work is currently ongoing in 3GPP to investigate support for 5G New Radio (NR) air-interface over satellite [26
]. This would allow the SatRAN function to be fully 3GPP compliant.
With reference to Figure 4
and Figure 7
, note that the core network residing in the central node is used to operate the cellular access network at the remote site and is different from the SatCore, which is integrated within the satellite hub platform site and is used to operate the satellite backhaul network. The satellite network functions are virtualized by transferring their execution environment from a dedicated server to a Virtual Machine using the OpenStack Pike Virtualized Infrastructure Manager (VIM). Satellite Virtual Network Functions (VNF) includes the SatRAN software element, the satellite 3GPP SatCore, the satellite Network Management System as well as additional auxiliary VNFs deployed on the same system using the OpenStack VIM. In terms of Management and Orchestration, the satellite hub platform system is integrated with the Open Source platform. With reference to ETSI TR 103 611 [28
] and Figure 8
below, the integration scenario of satellite networks in the 5G system architecture, which is of interest here is the so-called “Indirect Mixed 3GPP Non Terrestrial Network Access”. In this integration scenario, 5G UEs are served by an access point. This access point is served by a trusted mixed 3GPP Non-Terrestrial Networks (NTN) access network. UE management applies to the NTN enabled UE. The NTN enabled UE endorses a multiplexer node role. Another wording for this scenario could be “Indirect 3GPP NTN access with non-3GPP L2, non-3GPP L1”. In this case, there is indirect connection through a 5G satellite access network (bent-pipe satellite case) but with a mixed 3GPP NTN access network instead of a 5G satellite access network (i.e., instead of a 3GPP defined NTN 5G access).
4. SATis5 Satellite Emulator
Being able to create and use a satellite-testbed without always having a real satellite link available requires a satellite emulator. To this end, the SATis5 testbed is extended by a satellite link emulator that has partly been developed during the “Satcom integration with LTE-based core network emulator” (SATINET) project [6
]. In the SATINET project, the simulation of a DVB-S2 [29
] satellite modem with extensions to solve or lessen the systematic issues introduced by using a GEO satellite were implemented in addition to the pure satellite link simulation. Proprietary elements such as Performance Enhancement Proxy (PEP), header-/payload-compression and packet scheduling were developed and integrated into a convergence layer. In SATis5, the project partner Newtec provided the Dialog 1IF platform software containing convergence layer functions, which are identical to the ones used in their modems. Through the API provided by Newtec, the satellite resources (bandwidth, QoS) can be orchestrated through the core network. This has the advantage that network slices can be mapped directly to the satellite network. To provide a realistic simulation, these elements were selected to replace the satellite modem elements from SATINET. The software elements taken from the satellite hub platform are TelliNetServer and TelliShapeServer on the hub-side of the satellite link, as well as TelliNetClient and TelliShapeServer on the user-side of the satellite link. TelliNet implements a Distributed PEP for acceleration of TCP, HTTP, SMB and POP3 protocols via satellite. Besides this, it provides Authentication Authorization and Accounting (AAA) mechanisms, general payload and header compression and encryption. TelliShape implements real-time traffic shaping with QoS management, multilevel policies and VoIP prioritization as well as the creation of the DVB-S2 Baseband frames (BBFRAMEs). Figure 9
shows these different software elements.
From SATINET, only the SatLink element was reused. It was modified and integrated with the satellite hub platform. It emulates the satellite forward and return links to/from a (mobile) user terminal via a geostationary satellite. It is highly parameterizable, e.g., bandwidth and link budget (including antenna gain) can be set via configuration file. As the forward and return shadowing profile is identical for the user, only one profile is generated for modeling the movement of the user terminal (Line of Sight (LoS), moderate shadowing, blockage). Additionally, due to frequency separation of uplink and downlink, forward and return link have their own land mobile satellite (LMS) channel realization. Incoming BBFRAMEs are delayed depending on the hub–satellite–user geometry and BBFRAMEs are dropped if they are corrupted depending on the satellite link state. Figure 10
shows the structure of the forward and return link software modules. Incoming BBFRAMEs were created by TelliShape and contain IP packets split into suited chunks to fit into DVB-S2 frames for the given modulation and coding scheme.
The emulator is an key element for the further development of the testbed. Moreover, the emulator helps to evaluate important building blocks of the architecture at an early stage without the need of using satellite capacity. The TelliNet and TelliShape elements allow their QoS management to maintain virtual network slices even through the satellite link. In addition, various use cases of the testbed can be demonstrated with the emulator, thereby simplifying the use of the testbed by interested third parties such as small startup companies. The emulator thus represents an essential pillar in the development and operation of the SATis5 testbed.
5. Testbed Demonstration Setup
Emulation of the SATCOM part of the testbed are not enough to prove the whole functionality of the testbed development. It requires real over-the-air tests with commercial satellites to analyze the complete transmission chain. This section describes in detail the first over-the-air demonstration tests conducted with the SATis5 testbed in November 2018. The purpose of these tests was to demonstrate key benefits of satellite integration into 5G as well as to pave the way for the further development of the SATis5 testbed based on the lessons learned. In particular, two over-the-air demonstrations are elaborated here after:
5.1. Seamless Satellite Integration into Standard 3GPP Network Architecture
The first over-the-air demonstration showcased how SATCOM networks can be integrated into a standard 3GPP network architecture to provide seamless end-to-end connectivity via satellite. The 3GPP architecture integration results in the satellite network operating as a 3GPP network with the satellite terminal acting as a UE device. Moreover, the SATCOM network presenting itself as a RAN node to the standard 3GPP core network. The demonstration illustrates the use of Software-defined Networking (SDN) and Network Functions Virtualization (NFV) technologies and their integration with the SATCOM in the context of 5G. The objectives of this over-the-air demonstration were:
Satellite integration into standard 3GPP network architecture
SDN, NFV and edge node integration into SATCOM
Network Slicing of eMBB use cases over satellite
The end-to-end demonstration setup is illustrated in Figure 11
. In particular, it was built upon the following testbed elements by the respective SATis5 project partners. The Open5GCore [25
] corresponds to a 3GPP Release 15 compliant implementation of the 5G core network. The central entity of the testbed is a virtualized structure including the rest of the core network as well as the applications server. A commercial-off-the-shelf (COTS) available 4G RAN (including eNB and UE) was deployed, through which the UE was connected to edge node. iDirect provided the pre-5G enabled satellite hub platform and remote satellite terminals which incorporate SDN and NFV capabilities and enabled the satellite integration into a 3GPP core network architecture. The GEO SES owned satellite ASTRA 2F (28.2° E
] delivered seamless connectivity between the remote and the central parts of the testbed.
At the Fraunhofer FOKUS’s premises in Berlin, Germany, a COTS available Long Term Evolution (LTE) network was deployed. Specifically, during the testbed demonstration, the LTE band 7 (2.5 GHz–2.69 GHz) was used within the provided cell and an Airspan AirVelocity eNB was deployed. For the UE, a consumer LTE UE was selected supporting the LTE band 7. The stationary edge node was running on a Lenovo One ThinkCentre M900 with Ubuntu 16.04 and hosted the individual decentralized 5G core network functions. Through a VPN terrestrial link, the stationary edge node was connected to the remote satellite terminal located in Killarney, Ireland. In particular, the remote satellite terminal corresponds to the iDirect’s X7 EC satellite router with edge computing capabilities as Indoor Unit (IDU) and a
m Ku-Band Antenna System as Outdoor Unit (ODU) (see Figure 12
The remote satellite terminal was connected to the satellite hub station deployed in Betzdorf, Luxembourg through the geostationary satellite ASTRA 2F (28.2° E
]. In particular, the Ku-band channel bandwidths for downlink and uplink reserved for this experiment were 26 MHz and 6 MHz, respectively. This led to a maximum backhaul UDP throughput of around 60 Mbps and Round Trip Time (RTT) of around 550 ms. The satellite hub platform provided a SATCOM solution using 3GPP network architecture and by integrating SATCOM with a standard 3GPP telecommunications network (see Figure 12
Through a VPN terrestrial link, the satellite hub platform residing at the SES teleport in Betzdorf was connected to the 5G central node of the testbed, residing in Berlin. In this context, to assure the connectivity to the 5G network through the different backhauls, the 5G core network was deployed with a functional split between the edge node and the 5G core network. Further details on the edge-central network split are provided in [21
The testbed demonstration in Figure 13
showed data from five sensors on a screen, representing active devices such as a phone, a wearable, a car, and a fixed IoT sensor aggregator, all were connected and exchanged information as it was routed through the combined space-and-ground network to the core network in Berlin.
5.2. Mobile Edge Node Demo: Connectivity on the Move
The second over-the-air demonstration showed 5G connectivity “on the move” with a SATCOM-equipped van. This scenario could be envisioned as a use case for Comms on the Move
in a disaster relief situation or in areas where the terrestrial backhaul infrastructure has been damaged or is still too expensive to deploy. Possible applications are eHealth, rapid emergency response, and temporary deployments for public events. Comms on the Move
have to manage an unstable backhaul where communication may be blocked for variable duration’s of time due to shadowing. The van can be used to set up a standalone cell wherever a LoS connection to a satellite is available. In the case of a connection to a MNO network, the data traffic can be backhauled on top of this terrestrial network, as shown in Figure 14
To demonstrate the showcase, an Accelleran E1011 eNB was deployed in the van with a Satcom on the Move (SOTM) terminal from the Munich Center for Space Communications, a major research facility for satellite communications located at the Bundeswehr University Munich (UniBw) in Neubiberg, Germany [31
]. During the testbed demonstration, the LTE band 43 (3.6 GHz–3.8 GHz) was assigned from the German regulatory agency for test purposes. For the UE, the Essential PH-1 smartphone was selected because it phone is one of the few devices that supports LTE band 43. The edge node was running on a Lenovo ThinkPad X240 with Ubuntu 16.04. In addition, two Huawei E3372 Mobile Broadband LTE modems were connected with the edge node via USB to backhaul data traffic if the satellite backhaul was unavailable. In case a LoS connection to the satellite, the SOTM terminal on top of the van was utilized. This SOTM antenna features multiple on-board tracking sensors, enabling accurate tracking, short initial acquisition and instantaneous re-acquisition.
The transmitting and receiving Earth station was a m offset Gregorian antenna. Specifically, during the over-the-air tests, the satellite backhaul was implemented through geostationary satellite capacity provided through UniBw in the Ku-band. A small satellite bandwidth of 200 kHz was allocated to the forward link carrier and 200 kHz bandwidth was allocated to the return link carrier. For the uplink of the forward link, a center frequency of GHz was assigned by the operator. This frequency has been converted to GHz downlink frequency. The SATCOM modem in Munich was configured to provide access to the central node in Berlin with Public IP over the Internet. The edge node was connected through an OpenVPN connection to the central node in Berlin, which includes the main core network functions. In the case both backhauls are available, the edge node could split user plane and control plane separately to send the data to the central node over different physical paths.
A testbed demonstration architecture with edge node capabilities has been developed, to demonstrate the benefits of satellite technologies in a 5G environment, as shown in Figure 15
. During this scenario, the SOTM vehicle was parked in Berlin, Germany (52.53° N
). Line-of-sight to the satellite was given. Shadowing of the SATCOM link occurred occasionally through passing high-build vehicles such as trucks, delivery vans and buses. In the case of shadowing the reconnecting of to UE to the core network took a few seconds (hold mode of the antenna) or less than one minute (search mode of the antenna), depending on the length of the previous shadowing period. The specific processes for service deactivation, handover and tracking updates worked as expected.
Internet Control Message Protocol (ICMP) messages were used for validation and compatibility testing between the UE and the central node. The ICMP messages were encapsulated in IP packets within the GPRS Tunneling Protocol (GTP) and converted by the satellite modems into a physical signal (BPSK modulation with coderate 1/2). All tests include functionality evaluation for the considered architecture. As a result it can be stated that the performance and load management for this specific demonstration were limited by capacity.
This demonstration shows that a RAN can be directly deployed with a satellite backhaul to connect to a 3GPP Release 15 core network. The satellite backhaul can handle large RTT compared to terrestrial radio backhauls (The average RTT over half an hour was 584 ms). Moreover, the demonstration shows that an edge node can handle two different backhauls at the same time. In the case of a blocking of the SOTM link, a backup solution for the UE traffic is provided by offloading the traffic over local MNO networks via two LTE modems. This demonstration shows that even a small satellite bandwidth is sufficient to provide a satellite backhaul for mMTC sensor applications.
5.3. Summary and Outlook of the Testbed Demonstrations
The tests carried out have shown that the 5G integration of satellites currently depends very strong on the satellite ground and edge equipment that is used. New technologies such as network slicing can only be utilized in a satellite backhaul if satellite modems have already taken concepts such as SDN and NFV into account in their hard- and software architectures. On the one hand, the developed edge node concept allows independently of the modem technology the use of different backhaul technologies. For example, part of the data can be transmitted on top of an existing terrestrial MNO network and another part via satellite. On the other hand, legacy point-to-point modems (as used in Setup 2 in Section 5.2
) without a specific API to control satellite resources will be difficult to align with the 5G concepts.
The deployment of state-of-the-art satellite ground equipment and 5G elements such as RAN and core network alone will not be enough to successfully manage the satellite integration for 5G. A particular satellite network slice can differ from other slices within that network based on latency, bandwidth, reliability, security or functionality provided. The orchestration of the specific satellite ground equipment will be crucial for a smooth satellite 5G integration for example to adjust the satellite bandwidth. Concepts such as the SatCore shown in Setup 1 in Section 5.1
together with network slicing could enable a satellite network operator to segment its network dedicated to individual businesses such as 3rd party MNOs, other market segments or specific 5G services.
With the successful development of the satellite emulator, a solution for the high speed data plane processing within the satellite data processing pipe will be further optimized. The optimization of the TCP PEP functionality addressing specifically the 5G data path (primarily in respect to GTP optimization) will be carried out during the next phase of the testbed development. Moreover, the successful modem and satellite hub integration with the core network control plane elements via APIs for configuration and data path control will be very important to make network slicing on the satellite layer reality. The deployment of all the specific nodes (see Figure 6
) for the SATis5 testbed will be completed by 2019. Afterwards, a measurement campaign will provide results and data for the capabilities of the various concepts that have been developed.