Satellite Communications Integration with Terrestrial Networks

Adam Kapovits＊, Marius-Iulian Corici, Ilie-Daniel Gheorghe-Pop, Anastasius Gavras Frank Burkhardt,Thomas Schlichter, Stefan Covaci4 Eurescom GmbH, Heidelberg 69, Germany

2 Fraunhofer Institute for Open Communication Systems FOKUS, Berlin 10589, Germany

3 Fraunhofer Institute for Integrated Circuits IIS, Erlangen 91058, Germany

4 Technische Universität Berlin, Berlin 10623, Germany

* The corresponding author, e-mail: kapovits@eurescom.eu

Abstract: In this paper we evaluate the feasibility of seamless and efficient integration of terrestrial communication systems with satellite networks. This aspect is considered by standardisation bodies such as ETSI [1],5G-PPP [2] and 3GPP [3]. A comprehensive system is designed and implemented in an emulation prototype, including standard 3GPP LTE core network functionality [4] with its different layers: networking, data forwarding,control, management and monitoring and is validated through performance measurements.This work is a technical feasibility study of extending terrestrial communication systems with satellite networks as backhaul, increasing the energy efficiency, network robustness during natural disasters as well as being an alternative for peak-time data forwarding of the terrestrial communication services. Due to its global coverage property, terrestrial-satellite integration provides an obvious extension of communication services towards isolated and remote areas and an alternative for rural or highly distributed/highly mobile enterprise networks.

Keywords: network convergence; application sector requirements; experimental validation

I. INTRODUCTION

In our paper we first review the integration issues concerning satellite and terrestrial communication networks as described in [5] by summarising the use cases and requirements for such an integrated solution, present available architecture options, list and detail the arising integration issues. We then propose a system architecture and describe the required convergence layer. We go on by describing the implementation of a testbed we used to verify the performance of such an integration including a satellite emulator, and summarise our mainfindings. We conclude by providing an outlook and recommendations for actual system deployment.

II. INTEGRATION ISSUES

Traditionally cellular networks are backhauled using terrestrial infrastructure. This introduces restrictions on the deployment of LTE or 5G systems, as existing infrastructure bottlenecks are not resolved and remote areas without terrestrial backhaul options are not properly considered. One way to address these issues is to add a satellite backhaul option to the terrestrial network as shown in figure 1.

The transmission delay when backhauling data over satellite has a major effect on any acknowledge-based transmission protocol. For example TCP would retransmit packets for as long as no acknowledge packet is received,thus generating redundant traffic. Other protocols may terminate due to internal timeout before an acknowledgement is received. There has been research conducted on the challenges of providing resilient satellite backhaul connectivity [6]. To overcome these issues a convergence layer is included in the LTE-backhaul system [7].

2.1 Use cases and requirements

Figure 2 illustrates representative use cases as the main targets for backhauling terrestrial communication services over satellite.

1. Moving Site (Train) – covers mobile networks which are mostly covered by terrestrial networks but frequently lose connection to the backhaul due to area characteristics. Pure terrestrial network communication has drawbacks due to multiple operator coverage (requiring multiple roaming agreements) or due to the speed of devices in which terrestrial only communication is inefficient.

2. Moving Site (Plane) – covers fast moving mobile networks which, most of the time,have the satellite network as the only backhaul alternative and have nearly always an unobstructed link to the satellite. Terrestrial backhaul is available only at specific loca-tions.

Fig. 1. Integration of satellite backhaul into 3GPP LTE networks.

Fig. 2. Possible use cases for backhauling LTE services with a GEO Satellite.

3. Moving Site (Cruise Ship) – covers slow moving mobile networks which, most of the time, have the satellite network as the only backhaul alternative and have nearly always an unobstructed link to the satellite.Terrestrial backhaul is available temporarily at specific locations.

4. Isolated location – covers fixed networks which are isolated due to terrain geography and where the satellite network is the only backhaul alternative as described in [8]

5. Rural location – covers fixed networks

which are isolated due to the high cost of terrestrial backhaul or very low capacity backhaul. The viable solutions for these sites require subsidies as explained in [9]

6. Urban location – covers fixed networks which can swap between terrestrial and satellite backhaul when needed. The satellite backhaul provides the advantage of being a single autonomous system for establishing the communication.

In general satellite backhaul provides advantages for all use cases, such as specific end-to-end security, uniform delay and high availability backhaul. This makes satellite backhaul ideal for enterprise communication and M2M use cases.

The analysis of the communication requirements are summarized in table 1. In case of dedicated devices this refers to satellite communication capable UEs. For example, in a rural location the locally deployed LTE system with satellite backhaul is considered sufficient in order to provide local connectivity through regular LTE/3G capable devices such as mobile phones. On the other hand, in an isolated location the presence of a satellite capable device becomes mandatory, as the satellite connection is the only feasible communication technology. For the same reasons convergence with a terrestrial network is impossible in an isolated location. For the other cases a device may hand over from satellite-connected ground segment to a terrestrial network. In the case of planes or trains, these handovers would occur during stops. For either of the cases the devices need to access an Home Subscribe Server (HSS) for authentication.

From the perspective when the satellite backhaul is used, there are three major alternatives: when the satellite network backhaul is cheaper compared to a terrestrial one, when the mobile segment is outside of the terrestrial coverage or a boost of the network perfor-mance is necessary. This provides a set of implications on the communication requirements. For the outside of coverage case the handovers to the terrestrial backhaul will happen at specific moments in time depending on the location of the network while for the other cases they depend on the situational opportunity. For all scenarios in order for the handover to happen there must be a mechanism for adapting dynamically to different backhauls.The implications were investigated during the design phase of the project. Additionally, both UE and M2M connectivity patterns were covered in the study.

Table I. Communication requirements.

2.2 Architecture options

We considered three architecture options as illustrated in figure 3.

A) S1 interface backhaul: The ground system maintains the Evolved Node B (eNB) – the User Equipment (UE) can be highly mobile between multiple ground segments and to the terrestrial network. The cost of the ground segment is minimal, as it contains only the Radio Access Network (RAN)component. The mobility and resource related signalling has to pass over the satellite network to the Mobility Management Entity (MME), which induces a large delay in all procedures (attachment, detachment,idle mode, paging handover and location updates) and generates additional backhaul signalling. The delay may result in packet loss during handover as the core network is not executing the expected procedures within the expected timeframe, resulting in poor network quality towards the subscriber. Similarly, for tracking area updates, the location of the device may be lost. For paging and handover the delay will result in a high buffering of the downlink data traffic,while for the attachment and detachment,the procedures will take longer.

In this architectural option, the convergence layer has to be able to compress and to supress data traffic on the S1-MME and S1-U interfaces. Specifically for the S1-MME there is a substantial signalling overhead,thus a large number of messages has to be considered. Deploying a highly sophisticated algorithm to decide which signalling may be supressed is an option. However, it is estimated that the cost for deploying such a decision mechanism is similar to the cost of deploying the MME as the data packets have to be completely de-capsulated and the identity of the UEs has to be assessed(this presumes the decoding of both the S1-AP and NAS headers as well as the maintenance of UE state, which is equivalent to 70-90% of the MME functionality).Additionally, the control plane messages are transmitted using NAS over S1-AP over SCTP, which are already compressed using ASN1 encoding. This makes the further minimization of the signalling traffic less efficient (i.e. this is a case of compressing an already compressed protocol).

Fig. 3. Architecture options.

B) S5/S6a interface backhaul: The ground system maintains local mobility and resource management – the ground segment includes its own MME and Serving Gateway (SGW) functionality. Any local mobility operation is maintained locally, while only S1 handovers, which requires re-location to the macro-network, is signalled to the Packet Gateway (PGW). This is a good option when the UE does not handover often to the terrestrial backhauled network,as in this case there is only a minimal signalling required at the establishment of the communication session with the PGW,maintaining all benefits of the GPRS Tunnelling Protocol (GTP) based routing (i.e.stable data paths with allocated Quality of Service (QoS) characteristics).In this option the convergence layer has to transport the messages of the S6a interface and the S5/S8 interface. This is considered suitable, as specifically the GTP-U (and all communication headers underneath) is rather easy to compress further (not being very large from the beginning). However, one of the main issues is to optimize the transfer of the data packets payload through additional performance enhancement components,especially the TCP Performance Enhancing Proxy (PEP), as a PEP has to process the data packets without any additional header.The function of the TPC PEP is described in [7].

Additionally, the Diameter messages are rather rare with the notable exception of the keep-alive messages. However, the frequency of those can be con figured.

C) SGI interface backhaul: The ground system maintains a full Evolved Packet Core(EPC) network – all network components are located at the mobile segment. This supports local communication without transfer over the backhaul. Plain IP data traffic is exchanged over the network using IP mechanisms for routing and QoS.

In this option, the convergence layer has to handle plain IP data traffic as well as Diameter communication (for the S6a interface). The same considerations as in the previous option apply, with the exception of the GTP interface.

Fig. 4. End-to-end functional overlays.

In all three architecture options, we assume that the Home Subscribe Server (HSS) is deployed at the hub segment from the perspective of the satellite network. The only requirement is that the HSS can receive requests from the MMEs within the same system i.e. the IP addresses are allocated from the control plane address space of the operator. A single HSS may be deployed for multiple hubs or can be integrated with a terrestrial operator. This enables the usage of the same subscription on the remote system and on the terrestrial operator network. As the HSS is connected via an application level protocol (Diameter) to the MME, the only requirement is that a reliable IP connection can be established between them and that the timeouts of the message exchanges are suitably increased.

This is because the HSS maintains the subscription profile of the UE bound to its specific identity. The UE is authenticated and authorized to use the network, based on this subscription profile. Thus, the HSS information coverage is the one that defines the network operator deploying the system. A remote system HSS would simply create a new edge operator and not an integrated system. In this case, the network operator would be completely isolated.

2.3 Identification of integration issues

The integration issues are classified based on end-to-end functional overlays as illustrated in figure 4.

Regarding the carrier technologies that carry the EPC messages such as the radio, satellite and IP domain data paths the following aspects were considered. Issues in the area of radio resource control and management, and the required signalling and data plane resources were analysed considering the possible delay between the transport control and the transport data path entities.

Regarding LTE subscriber connectivity issues we considered authentication and authorization, security, redundancy, mobility and subscriber management, flexible data path realization, resource utilization considering the capacity limitations and delay of wireless connectivity.

Concerning end-to-end application delivery we considered data path establishment and its transmission delay, the quality of service provisioning, resource utilization and management.

2.3.1 Underlying carrier technology

The radio network connectivity is rather independent of the satellite backhaul. Two functional aspects may be affected by the satellite backhaul. The first one concerns device handovers within the same remote site, where the LTE system caches the downlink data traffic.If the handover procedure duration is large,then an appropriate caching is needed supporting the storage of a very large number of data packets either in the eNB or in the SGW. Additionally, the data traffic has to be forwarded to the UE after the handover is completed,resulting in a data traffic burst. To mitigate this effect the handover process duration has to be minimized. This is only possible by local processing of control plane requests on the ground segment.

The second one is related to the MME maintaining radio resource setup information which is transmitted to the eNB when itfirst attaches to the core network. The MME needs knowledge of radio properties to be able to make appropriate decisions. If the MME is located at a larger delay distance the duration of this procedure will increase the time until an eNB is integrated into the network. The procedure may have an alarm which could be triggered, implying that for radio management reasons part of the MME functionality should be placed at the mobile site.

In the IP domain, two main characteristics are considered. Firstly, in order to maintain end-to-end QoS characteristics, the main issue is the appropriate translation between the QoS Class Identifier (QCI) within the EPC and the QoS classes on top of the IP backhaul. These characteristics should be modified to include the delay and the packet loss budget inherent to a satellite backhaul. An appropriate traffic control mechanism must be developed for ensuring the efficient usage of the limited resources of the satellite network environment.

Secondly, in the case of routing IP over satellite, we assume that the mechanisms are already available, i.e. layer-2 of the satellite network can route data packets between the ground and the hub segments. From the network side the satellite link behaves like a layer-2 bridge but technically the modems on both sides intercept some messages and respond on behalf of components from the other side of the link. Namely the modems will ARP-proxy as the ARP protocol relies on short response times.

Specific to the IP domain communication optimization a TCP PEP is used to increase the network efficiency in terms of network overhead and capability.

2.3.2 LTE subscriber connectivity

We have identified the following issues concerning the data plane. Firstly, it is very important that the GTP forwarding is not affected by the satellite backhaul. Secondly, an appropriate classification of the bearers is needed to the corresponding QoS classes considering the satellite backhaul characteristics. Bearers that are used for voice should get a real-time QoS class on the satellite link to minimize the delay that is added by the DVB-S2 framing[10]. Thirdly, traffic control needs to match the bearer classification to the outer IP header in order to be processed by the IP domain traffic control functionality. The QoS classes used by the satellite network need to be matched with the QoS classes used by the LTE network. Finally, in terms of UE communication patterns,the system needs to ensure that a minimal service is available for the subscribers according to their requirements.

For the control plane the following issues were addressed. When considering the UE population an appropriate dimensioning of the network was applied in terms of duration of the procedures vs. network function placement and backhaul characteristics.

In terms of common control plane procedures the following ones were addressed.To accommodate the delay of the attachment procedure that may trigger a timeout in either some network components or on the UE the timeout values had to be adapted in the UE and the core network components. Also concerning the attachment procedure the amount of signalling messages can be reduced by adapting the timeout values, as this decreases the number of retransmissions. Regarding the bearer resources allocated those are usually limited by the available RAN resources. In the current architecture the specific bearers that pass over the satellite backhaul also the satellite backhaul resources availability had to be considered.

Additionally, subscriber information is acquired by the system from the HSS at regular intervals to ensure consistency. The interval period should be re-configurable, as the UEs are connected to the same network area for long periods, and when another network area comes into reach the local HSS state has to be synced with the master HSS to allow handover. For tracking area information, the devices are staying within the same tracking area while being connected to a ground segment.Therefore, tracking area information exchange can be suppressed to a large extent. Regarding handovers, a larger delay in the handover procedure is increasing the necessary caching in the eNB/SGW and may interrupt the communication of the device, or disconnect it from the network. The Time-to-Trigger (TTT) parameter of the LTE should be adapted to start the procedures at the appropriate moment in time not to lose connectivity. For paging, this procedure shall be executed fast to reduce the data caching until the device becomes active.Andfinally, when a handover to terrestrial networks occurs, a procedure is required and the communication parameters have to be changed in all components, including UE, from the satellite backhaul to another type of backhaul.

Last but not least, for the management plane the following issues were identified.Regarding local breakout, the system has to include the appropriate policies to support local breakout in order to have local data paths which do not require satellite network backhaul. For subscription information maintaining a local cache of the subscription profile information enables a faster processing. Such caching may not be synchronized often and may contain a huge amount of information. In terms of bearer allocation policies, these must be designed in a way to allow adaption to the backhaul capacity and delay as well as the packet loss budget. Finally, handover policies have to be brought to the LTE/EPC in order to be able to make appropriate handover decisions. This is important in case of handovers to terrestrial networks, when the location of the network with satellite backhaul changes and permits that.

2.3.3 End-to-end delivery

As the control and management plane of the end-to-end application delivery are solely under the control of the application, the issues here relate to the data plane.

For TCP, the data packets are encapsulated into GTP packets while being transported within the EPC, thus on top of the satellite backhaul. This means that the PEP [7] that is running on the satellite modems doesn’t “see”the TCP connections and cannot optimize them. As a result, the PEP must be made either GTP aware or the PEP functions have to be integrated into the EPC data path.

Regarding the datalink enhancement, application data may also be compressed to increase the system data capacity. On the other hand, adding extra functionality and thus increasing the computation efforts and complexity of the deployed components needs to be precisely calculated beforehand.

In terms of the system end-to-end delay,reducing data processing delay at any of the components will directly reduce the end-toend delay.

III. SYSTEM ARCHITECTURE

Considering the detailed requirements we propose an integrated architecture, which is illustrated in figure 5 and which is a composition of options B and C as originally outlined in figure 3. The main reason for this choice is to avoid large transmission delay over the interface between eNB and MME, which result in large delays for the handover and activation procedures, leading to extensive buffering.

The architecture includes the convergence layer and the different network functions. Two different PGWs are deployed, one local PGW on the UE-side and one remote on the hub side for covering the communication mechanisms of options B and C.

The MME will select the data path for a specific bearer of a subscriber based on the Access Point Name (APN), the identity of the subscriber as reflected within the International Mobile Subscriber Identity (IMSI) and the bearer type request.

Fig. 5. Integrated architecture.

The IP address is allocated based on the destination PDN e.g. local network or remote PDN. In order to retain network routability and scalability, single IP addresses cannot be handed over between different network areas.Due to this IP address allocation limitation,the bearer is established for the duration of the session and is not handed over. Thus the allocation process is executed at the MME level.

As illustrated by figure 6, the architecture results in 3 data paths:

• DP1 – the device is connected through the PGW located at core network side. The UE can execute handovers with zero packet loss to and from the terrestrial network. The data packets are encapsulated into bearers which enable an easier QoS classification.

• DP2 – terminates the EPC data path at the remote site PGW and then forwards the data traffic to the internet over the satellite network. There is no support for mobility between the satellite backhauled and the terrestrial network, neither between different satellite backhauled PDNs.

• DP3 – the data path terminates locally on the remote site for applications which are handled locally. DP3 is not useful without combining it with DP1 or DP2 for remote access.

A combination of DP1 and DP2 is easier to implement and does not require specific functionality on the remote side for the data path.An additional macro-mobility solution must be added using external mechanisms to the EPC. One solution is to use SDN based mesh networks. The result is that a similar tunneling alternative to the GTP proposed for DP3 is added to the architecture, missing the functional advantages brought by the centralized EPC functionality.

A combination of DP1 and DP3 offers full mobility support, and ways to encapsulate the remote access data traffic into a common bearer – i.e. multiple flows having the same QoS are grouped and treated together, thereby reducing the number offlows seen by the QoS traffic control to a minimum. Compared to DP2, DP3 has the advantage of a single central point where different data traffic coming from multiple remote sites is processed in a common manner for QoS, charging and lawful interception.

3.1 Convergence layer functions

The convergence layer consists of multiple functions that form a stack. All data traffic must pass through that stack. Each transmit function of the stack forms a logical connection to the receive function at the same level.The data connection is transparent.

The convergence layer includes functionality related to the specific application (i.e. the EPC with control and data path) and functionality related to the forwarding of the IP data traffic.

Fig. 6. Integrated system data paths.

Fig. 7. Convergence layer functions overview.

For reducing the adaptation costs, it is important to maintain the convergence layer transparent to the application (i.e. EPC) as much as possible and to keep the functionality at forwarding level. However, this may not be possible due to specific protocol encapsulation of different data packets. In this case, a proxy solution is selected which is able to provide a back-to-back functionality. A new network function entity is introduced into the data path which is making the operations as transparent as possible to both sides.

To further improve the efficiency of the proxy functionality, we assume that such functionality is located on both sides of a satellite network and handles the presentation of the data packets to the satellite network (e.g. the data packets do not have to have the original encapsulation as long as the other side can re-create it).

The convergence layer handles the following aspects as part of adapted EPC functionality:

• Data traffic classification.

• Localized signaling.

• Signaling suppression/reconstruction.

The purpose of a PEP [7] is to:

• Handle the large round trip times (＞ 500ms)resulting from geostationary satellite links.

• Fast adaptation of the transfer rate to the link capacity, so that small packets are transferred efficiently.

• Optimize the retransmission of TCP/IP packets in case of packet loss. Therefore the longer, satellite-induced round trip times have to be estimated correctly.

The purpose of the Header/Payload Compression is to reduce the required data rate by compressing data which has a known relationship to other data and are transmitted regularly. Headers of a data stream fulfill the requirements for such a compression.

The purpose of the traffic control function is to:

• Schedule the transmission of data according to their Priority as provided by

○ LTE “Quality of Service Class Identifier” (QCI)

○ Requirements of LTE signalling between the entities of the ground segment and the core network

• Maximize the data throughput over the satellite link

IV. SYSTEM EMULATION IMPLEMENTATION

We implemented and evaluated the outlined architecture using an LTE system emulation for satellite backhaul as illustrated in figure 8.

The Local GW (which is a merge of a small SGW and a small PGW) is responsible for routing all local network access but terminates any voice calls. By that the local data traffic is kept from using the satellite link. All other traffic is routed via the SGW through the convergence layer. The extended convergence layer shown in figure 8 contains the full SGW functionality. This option is considered viable for the validation although for compliance reasons the baseline architecture should maintain a separate SGW.

4.1 Testbed implementation

The implementation architecture of the testbed includes a set of virtual machines each having its own functionality. The evaluation of the system is an implementation of what is proposed in [11]

The testbed is composed of a set of virtual machines deployed on top of the same server,each implementing a set of network functions.The virtual machines and the expected interconnection are illustrated in figure 9.

4.1.1 Testbed networks

The interconnection between the virtual machines is established using 5 virtual networks to be able to separate concerns in terms of visualization and in terms of debugging of the testbed system:

• net_a – IP service network, implementing the SGi interface within an EPC system.The data traffic over the net_a is plain IP data traffic.

• net_b – operator backhaul, implementing the S5/S8 interfaces between SGW and PGW.

• net_c – IP addresses allocated to the UEs by the EPC system during attachment. The IP addresses of net_c are routable over the SGi interface implemented in the testbed in the form of net_a.

• net_d – backhaul of the LTE network, including the S1-MME and the S1-U interfaces.

Fig. 8. Chosen architecture of LTE-network with satellite backhaul.

Fig. 9. Testbed architecture.

• mgmt – remaining control and testbed management interfaces. Over mgmt, several interfaces of the EPC are deployed such as the S6a and the DNS.

Although the virtual network interfaces are depicted as star-topologies, due to the underlying bridging technology they are meshed, thus they share only the virtual interfaces at the virtual machines and not a centralized communication point.

4.1.2 Testbed Network Functions

Five types of network functions are connected to the different networks:

• satellite emulation (SatEm [12]) – software emulating the satellite air-interface physical and link layers;

• the satellite convergence layer (CL) – software implementing the convergence layer as described above;

• the EPC system – based on the Fraunhofer FOKUS Open5GCore [13];

• the benchmarking tool [14] – based on the Fraunhofer FOKUS Open5GCore benchmarking tool;

• The Testbed Controller – a web-GUI enabling the UEs configuration, EPC configuration, convergence configuration and satellite emulator configuration as well as the selection of the benchmarking tool input.

4.1.3 Testbed Virtual Machines

The testbed includes the following virtual machines that implement the following network functions:

• The Benchmarking Tool (BT) includes the Open5GCore implementation of the control and data plane benchmarking. The benchmarking tool includes a set of eNBs, and emulates a large number of subscribers and their uplink data traffic. The Internet BT is able to transmit IP data traffic towards the IP addresses allocated to the UEs to emulate downlink data traffic.

• MME – the MME VM includes the Open5GCore implementation of an MME.The MME is located as part of the mobile ground system (MGS).

• SGW – the SGW VM includes the Open5GCore implementation of an SGW.The current implementation splits the control and the data plane processing into two complementary software components communicating using OpenFlow.

• PGW-MGS – for local data traffic and for the support of SGi interface over the satellite backhaul a PGW is deployed as part of the mobile ground system (MGS). Similar to the SGW, the PGW is split into control and data plane software implementations allowing the dynamic allocation of data plane resources.

• PGW-HS – for the remote anchoring of the data traffic a PGW is located as part of the hub system (HS). This gateway is supporting the S5 interface on top of the satellite backhaul.

• Enablers – the enablers VM includes the rest of the functionality which is used for completing the system, such as DNS, IMS and HSS components, which from the benchmarking perspective are known to consume a low level of resources.

• CL-MGS, CL-HS – the two convergence layer functions which are added as part of the data path within the end-to-end system.The convergence layer functions are added to the EPC system as SGW components and to the satellite network as input producing and output consuming components adapting the transmission.

• Satellite emulator – emulating over-the-air link of the satellite network [7], [12].

• Testbed control – a separate control entity of the complete testbed. It may run as a separate virtual machine or it may be attached to the enablers due to its low resource consumption for the specific operations.

Using the proposed testbed system, all three data path models proposed within the system architecture (local offload, SGi satellite backhaul and S5 satellite backhaul) as well as the terrestrial system situation are covered,depending on whether the satellite emulator is added or not in the data path between the PGW-MGS and the benchmarking tool and in the case the satellite emulator is added or not between the SGW and the PGW-HS.

4.2 Comments on testbed limitations

The testbed system is emulating a realistic system by deploying the different components as separate virtual machines. However, the following differences from an actual system deployment must be considered:

• Delay of the radio link is missing – the benchmarking tool does not emulate the terrestrial radio link. It includes directly the eNBs. Thus, the testbed does not account for the combined effects of LTE radio and satellite backhauled-EPC.

• Emulation of the satellite link – in order to cover a large number of use cases within a single system the satellite link is emulated.• Virtualization system limitations – due to the use of virtual interfaces the system networks are very fast. This may hold in a real deployment only for software components that are deployed in the same data center.However, a penalty of passing data traffic to the virtualized environment should be considered.

4.3 Summary of experimental results and their assessment, and conclusions

Control procedure delays were expected (1-20 ms local and 550 ms over GEO) and accommodated without modifying standards. We found that increasing timeouts and reducing redundant control messages is sufficient to support backhaul over satellite, even over GEO. The impact on the standard LTE procedures conform to the expected delays: 550 ms for detachment – 1 RTT over GEO –, 2.6-2.8 s for attachment ( figure 10) – 5 RTT over GEO–, 10-20 ms for TAU and S1 handover.

Fig. 10. Attachment delay.

The placement and location of functional components has a direct impact on control plane delay and can make an implementation significantly more suitable for and supportive of certain scenarios. For example M2M/IoT on narrow band end-to-end data transmission is more efficient with a local EPC deployment. Placement of functional components is flexible, and should be further explored. The results were obtained using a single implementation and are not cross-checked using a different implementation.

Regarding the data link a maximum of 360 Mb throughput capacity was considered on the satellite link. Because of the high number of processing operations on the packets an average delay of 1.5 s was observed when the link was saturated ( figure 11). Data compression is not relevant for video/audio [10] and encrypted data that are not further compressible, at least not via the zlib/TCP PEP libraries used.The use of this method over encrypted/encoded traffic increases the data-packet length by at least 2 bytes as well as a 15-20% increase in delay (figure 12). Header compression for narrow-band IoT is feasible though. Tests performed with unencrypted http traffic showed a 30% reduction in bandwidth usage. Selective compression of traffic flows would be the optimal solution therefore, but there is a clear need for further research in this direction.

Further research is needed concerning the convergence layer, in particular on data compression efficiency, PEP integration/synchronisation with the GTPflows on retransmission,and QoS synchronisation with satellite transmission.

Overall, our work demonstrated that existing standards and technology are a viable basis for building satellite-terrestrial integrated networks. Several research directions can be further explored and opportunities exist to standardise solutions to achieve such integra-

Fig. 11. Datapath capacity 360Mbps.

Fig. 12. Datapath with compression.

tion as part of 5G infrastructures.

V. CONCLUSIONS AND RECOMMENDATIONS FOR SYSTEM DEPLOYMENT

The results obtained show that the M2M and multimedia use-cases are fully supported by the deployed testbed. However, with the evolution of the market there is a need to consider other workload models with different proportions and weights of the signalling and data traffic, and other computing platforms.

The set-up and the architecture can be further optimised by performing an in-depth analysis of the test results and resources consumed during tests, and appropriately dimensioning and scaling components. Through such successive performance optimizations we expect a rapid progression from a prototype to a product.

As a condition for a standard solution, it is important that the next releases of the LTE and 5G core network architectures foresee a mechanism to dynamically add pieces of the mobile network to a system based on the backhaul authentication (i.e. satellite connectivity security). Through such means adding a new UE ground segment side becomes natural to the architecture.

We estimate considerable room for improvement in the cross-optimization with the virtualization layer. Embedding the data path forwarding and the convergence layer within the virtualization forwarding mechanisms could be considered. This presumes the design of new functions within the virtual infrastructure especially towards the network acceleration and towards the data path processing acceleration.

The next step is to install the functionality in a satellite modem relying on the available computing capacity, and prove that existing equipment can support the required core network functionality. This could bring the mobile connectivity business closer to the stakeholder chain of the satellite communication ecosystem.

ACKNOWLEDGEMENT

The work presented in this paper was part of the ESA ARTES 1 study “SatCom integration with LTE-based core network emulator” contract no. ESA 4000111941/15/NL/EM. The views expressed herein can in no way be taken to reflect the official opinion of the European Space Agency.