The Impact of Delay in Software-Defined Integrated Terrestrial-Satellite Networks

Luca Boero, Mario Marchese, Fabio Patrone＊

Department of Electrical, Electronics and Telecommunication Engineering, and Naval Architecture (DITEN)University of Genoa, Via All’Opera Pia 13, 16145, Genoa, Italy

* The corresponding author, e-mail: f.patrone@edu.unige.it

Abstract: Satellite communication networks have been evolving from standalone networks with ad-hoc infrastructures to possibly interconnected portions of a wider Future Internet architecture. Experts belonging to thefifth-generation (5G) standardization committees are considering satellites as a technology to integrate in the 5G environment. Software Defined Networking (SDN) is one of the paradigms of the next generation of mobile andfixed communications. It can be employed to perform different control functionalities, such as routing, because it allows trafficflow identification based on different parameters and trafficflow management in a centralized way.A centralized set of controllers makes the decisions and sends the corresponding forwarding rules for each trafficflow to the involved intermediate nodes that practically forward data up to the destination. The time to perform this process in integrated terrestrial-satellite networks could be not negligible due to satellite link delays. The aim of this paper is to introduce an SDN-based terrestrial satellite network architecture and to estimate the mean time to deliver the data of a new traffic flow from the source to the destination including the time required to transfer SDN control actions. The practical effect is to identify the maximum performance than can be expected.

Keywords: Integrated terrestrial-satellite networks; software defined networking; software defined satellite networks; delay estimation

I. INTRODUCTION

In traditional satellite communication networks the infrastructure is composed of satellites, ground stations, and ground terminals developed ad-hoc by each satellite operator.Proprietary hardware and software components have always limited the integration with terrestrial networks and also among satellite networks managed by different operators.

The main principles of the next generation of wireless communication (5G) are involving deep changes in the network infrastructure and management. An expansion of the classical Internet is foreseen in order to incorporate heterogeneous portions based on different technologies, including satellite communications, in a multi-layer network where the physical implementation is transparent to the users. There are several key areas where satellites can contribute [1]. Their wide coverage allows extending network access in rural and remote areas where there is no kind of communication infrastructure. Satellites can be exploited in case of emergency and disaster situations where the terrestrial infrastructure is damaged. A satellite temporary network could be quickly deployed to help collect information and spread news. Satellite integration in 5G may imply higher network availability and reliability, two of the 5G Key Performance Indicators (KPIs) defined in the framework of the 5G-PPP activity [2]. Another task where satellites can help, due to their broadcasting capability, is to bring application content closer to users located far from the content sources, which eases the achievement of the 5G KPI target of “zero perceived delay” and “1000 higher wireless area capacity in access”. Content caching to the edge can be employed in conjunction with Edge Computing (EC) paradigm in order to improve the end-user Quality of Experience (QoE). Lower energy consumption is another major concern related to the 5G evolution, which can be achieved by satellites again owing to their broadcasting capability.Summarizing, satellite networks can be integrated with terrestrial networks and exploited as a backhaul technology to help achieve some of the prefixed 5G KPIs, especially in terms of higher service availability, higher reliability,lower latency caching the content closer to the users, and lower energy consumption [3].

Network programmability and virtualization are other keywords of the today’s network evolution. Software Defined Radio (SDR),Software Defined Networking (SDN), and Network Functions Virtualization (NFV) are the paradigms which should be exploited also in satellite networks in order to:

? employ the intelligent delivery of services and smart routing strategies;

? allow the deployment of new services in a flexible and programmable way;

? give the satellite operators the ability to charge customers according to the real usage of the satellite resources;

? reduce the energy consumption by virtualizing the functions performed by the ground components of the satellite infrastructure(satellite gateways/hubs/terminals) and consolidating/activating/deactivating their action on remote datacenters;

? reduce Capital Expenditure (CAPEX) by exploiting general-purpose, instead of adhoc, hardware components over which standard virtualized functions are deployed.

The paper is organized as follows. Section II highlights the role of SDN within the integration of 5G and satellite communication and focuses on the aim of the paper. The introduced SDN-based terrestrial satellite network is reported in Section III, followed by the description of the time estimation model in Section IV. The results obtained with different network topologies are reported in Section V.Conclusions are summarized in SectionVI.

II. 5G AND SATELLITE COMMUNICATIONS:THE ROLE OF SDN

Different studies have investigated in details the benefits, opportunities, application scenarios, and challenges that the 5G paradigm brings to satellite communications [4-7].

In this paper, we focus on the SDN [8] in order to better understand which are the consequences of its employment in satellite networks. The main principle of SDN is to centralize the intelligence of the network decoupling control and Data Planes. The network infrastructure is abstracted in three different planes:

? Data/Forwarding Plane: it contains the nodes called SDN switches whose aim is to forward the received packets following the instructions contained in the flow table. If SDN switches do not have a rule for the new incoming traffic flow, they send a request to an SDN controller for indication about the next hop that the packet must follow by using standard Application Programming Interfaces (APIs) identified as southbound APIs. SDN switches also periodically send network statistics to SDN controllers.

? Control Plane: the nodes belonging to this Plane are called SDN controllers. Their aim is to compute forwarding rules for SDN switches in order to guarantee the required performance for each trafficflow. They use information about network statistics, such as traffic flows, link status, queue status,and information regarding trafficflow identification and user/application performance policies stored in the Management Plane nodes.

? Management Plane: information about network statistics, traffic flow identification parameters, and user/application performance policies are stored in the nodes of this Plane. The Management Plane is a sort of database containing all the information needed by SDN controllers and exchanged by using standard APIs identified as northbound APIs.

SDN can be employed for different purposes. The most common is routing, but also congestion control, flow control, and even security, allowing novel control and management strategies based on fine-grained trafficflow identification.

The most commonly used communication protocol between SDN switches and controllers is OpenFlow [9]. It is used to manage the flow tables inside the SDN switches to forward packets. These tables consist of lists of flow entries which include matching rules and corresponding actions. Each matching rule contains a set of matchingfields, i.e. a set of parameters to identify a traffic flow, such as source and destination Ethernet addresses,source and destination IP addresses, source and destination TCP/UDP ports, among others.An action is defined for each matching rule. If there is a match between received packets and matching rules, the packets are forwarded by using the corresponding actions. If there is no match, SDN switches ask for a new forwarding rule which is computed and sent back by the SDN controllers.

Several studies have already investigated the employment of SDN in integrated terrestrial-satellite networks. The main difference among them is how the different authors have decided to locate the different SDN Planes and their functionalities within the satellite network components. [10] investigates the use of the SDN paradigm in High-Throughput Satellite (HTS) networks, identifying the most interesting use cases and perspectives:the used network infrastructure is composed of a Geostationary (GEO) satellite including the SDN controller, Satellite Gateways acting as SDN switches, and a terrestrial Network Management Centre (NMC) implementing the Management Plane. Almost the same network architecture is considered in [11], where an SDN-based Information-Centric Networking(ICN) architecture for an integrated satellite-terrestrial network is proposed. [10] also suggests that a network composed of a Low Earth Orbit (LEO) satellite constellation in addition to a GEO satellite system could bring benefits. A novel software-defined satellite network architecture, called OpenSAN, is proposed in [12]: the satellite ground segment infrastructure acts as the Data Plane, a GEO satellite includes the Control Plane, while the Management functionalities are performed by a terrestrial Network Operation and Control Centre (NOCC). An architecture which exploits LEO inter-satellite links (ISLs) for data forwarding and GEO broadcasting capabilities for rapid network deployment is described in[13]. Other studies have considered a hierarchical multi-layer satellite network where the Data Plane is included both in LEO and Medium Earth Orbit (MEO) satellites [14-16].

Only [13] considers the computation of the time required to establish a new forwarding rule and to route and deliver the first packet of the new data. The rest of the packets will follow the same forwarding rule. The required time is in the order of few milliseconds in terrestrial networks and it does not significantly affect the application data delivery time. In integrated terrestrial-satellite networks, it could be not negligible, especially considering satellite link delays together with the strict performance requirements of some applications.The aim of this paper is to estimate the mean value of this time in a software-defined integrated terrestrial-satellite network, in order to identify which are the maximum performance requirements a certain application can get if its data are forwarded through satellites.

III. SDN-BASED TERRESTRIAL SATELLITE NETWORK

The introduced integrated terrestrial-satellite network shown in figure 1, is composed of three portions. The network is very challenging, in particular for the delay, because it involves GEO satellites, which have a main role also concerning the SDN control architecture,as explained below.

Fig. 1. Considered terrestrial-satellite network with focus on one of the three equal portions.

Fig. 2. Polar LEO satellite constellation.

Each portion is composed of a set of heterogeneous terrestrial networks which could be based on different technologies, such as 5G cells, Local Area Networks, LTE cells, linked together by a terrestrial infrastructure but also by a LEO satellite constellation, which is common among the 3 portions. In this way, traffic flows with given performance requirements,especially the delay-tolerant ones, can be forwarded through the satellite constellation,partially offloading the terrestrial infrastructure. Alternatively, the satellite route could be selected in case of fault of the terrestrial infrastructure.

In details, the overall terrestrial portion is composed of:

? Ground stations: terrestrial stations linked,on the one hand, with terrestrial terminals through terrestrial communication means(wired or wireless) and, on the other hand,equipped with a satellite antenna to send/receive data to/from satellites.

? Terrestrial hosts: they are all kind of nodes which can generate data traffic, such as user mobile andfixed terminals and servers.

? Network Management and Control Centres(NMCCs): three terrestrial centres which manage network resources and user requirements.

The satellite portion includes three GEO satellites. Each GEO satellite covers a third of the shared LEO constellation. LEO satellites are linked with the ground stations and,through ISLs, among them. The considered LEO satellite constellation is a multi-orbit polar constellation where orbital planes are circular and equally spaced among them. Satellites are equally spaced within each orbit. Its representation is reported in figure 2.

There are two types of ISLs: intra-orbit ISLs (ia-ISLs), which are the links between adjacent LEO satellites belonging to the same orbit; and inter-orbit ISLs (ie-ISLs), which are the links between adjacent LEO satellites belonging to different and adjacent orbits. In this way, each satellite has four bidirectional ISLs. However, in this kind of constellation,satellites which are travelling at high latitude are not able to keep ISLs active due to their speed and consequent Doppler effect. Another issue which could affect ISL status is the presence of the so-called “Seam”. Orbital planes are equally spaced around a 180°angle, hence there are two adjacent orbits whose satellites travel in opposite direction (as shown in figure 22.1 of [17]): thefirst ones from south to north and the other ones from north to south.Communications through the ie-ISL of these satellites could not be possible for the same reason of the high latitude ISLs. In our network all ISLs are always active except for the ones operating at high latitudes. Besides, we assume a “W” ISL pattern (Figure 22.3(a) of[17]). Figure 3 illustrates our considered ISL model: the horizontal size is two times the number of orbits and the vertical size is half the number of satellites per orbit.LEO satellites constitute the Data Plane and act as SDN switches. Their only purpose is to forward the data received from ground stations through the constellation following the routing instructions stored in their memory and previously received by the GEO satellites. GEO satellites act as SDN controllers. Their aim is twofold:each of them periodically collects and sends information about the statistics of the underlying LEO satellite constellation to the related NMCC; every time a GEO receives a newflow entry request, it computes the forwarding rules exploiting the data management strategies received from the NMCC and then sends aflow entry reply to the proper LEO satellite.NMCCs collect and keep updated the information about the network statistics received from the GEO satellites and the trafficflow performance requirements (policies) received from the terrestrial hosts. When NMCCs receive a strategy request from the GEO satellites, they establish a data management strategy exploiting these information and send it back to the GEO satellites. We opt for a distributed Management Plane in order to reduce the access time between NMCCs and GEO satellites,even though, in this case, a protocol to keep the consistency of this information is required,as also mentioned in [12]. In some cases,Control and Management Planes can be implemented in the same node. We have decided to apply the Management Plane on terrestrial nodes in order to reduce the time to install and update trafficflow policies and to avoid storing a huge amount of information and tackling a high computational effort on-board GEO satellites that have storage, energy, and computational power constraints.

Fig. 3. LEO satellite constellation ISL model.

Fig. 4. SDN Planes and functionalities scheme.

Taking into account all these steps, the time required to route a new traffic flow could be quite large, especially considering the delay of GEO satellite links. In the next section, we will estimate the mean value of this time, in order to quantify its impact on the expected performances and identify the maximum performance requirements that allow the use of the satellites.

IV. TIME ESTIMATION MODEL

We consider a terrestrial host THSgenerating data packets destined to another terrestrial host THDlocated in areas covered by two different ground stations GSSand GSD, respectively. THSsends its packets to GSSwhich uploads them to the LEO satellite LES(which is an SDN switch) in contact in that moment.THS’s packets are a new trafficflow for LESthat requires a specific forwarding rule to the GEO satellite GES(an SDN controller)which is covering the LEO constellation portion where LESis located. GEScontacts the related NMCC NMSasking for information about the current status of the network and the performance policy related to the identified traffic flow. A routing path from LESto the LEO satellite LED(also an SDN switch) in contact with GSDis computed by GES. Proper forwarding rules are sent to each involved LEO satelliteslash SDN switch. If LEDis located in an area covered by another GEO satelliteslash SDN controller GED, a portion of the routing path includes the LEO satellites inside GED’s coverage area. In this case, the required information will be sent also to GEDthrough its related NMCC NMD. When LESreceives its forwarding rule, the packets are sent through the SDN-based LEO network until they reach LED. Finally, LEDdownloads them to GSDand then to their final destination THD.

To ease the model always keeping the considered scenario as close as possible to a real one, we consider only propagation delays. We ignore transmission, queuing, and forwarding delays in this paper, because they may be considered negligible compared to the satellite link propagation delays for traffic flows characterized by short durations. We assume that there is no handoff during the overall described process, i.e. the topology does not change. Consequently, the mean timerequired to compute and establish a new set of forwarding rules and deliver thefirst packet of the related new trafficflow data to the destination may be structured into 9 components:

1) propagation time between THSand

GSSfor data packets;

2) propagation time between GSSand

LESfor data packets;

3) propagation time between LESand

GESforflow entry request;

4) propagation time between GESand NMSfor policy and network statistics request;

5) propagation time between NMSand GESfor policy and network statistics reply;

6) propagation time between GESand

LESforflow entry reply;

7) propagation times of all ISLs from

LESto LEDfor data packets;

8) propagation time between LEDand

GSDfor data packets;

9) propagation time between GSDand

THDfor data packets;

The values of all these components depend on the distances between the involved node pairs. The distances among adjacent LEO satellites belonging to the same orbit is almost constant, therefore the propagation delay of ia-ISLs may be considered as a constant (part of component 7). The distances among GEO satellites and related NMCCs is constant,and, opportunely setting NMCCs positions,is the same for each of the three pairs (GEO,NMCC). Therefore the propagation delay of the (GEO, NMCC) link is constant (components 4 and 6). The distances related to the other elements range between a minimum and a maximum value. In this way, we can estimate the possible range offrom a lower to an upper bound considering, respectively, the minimum and maximum values of these distances, and, consequently, the minimum and maximum values of the related propagation delays. Hence,T can be obtained as in Equation (1). All variables are defined in table 1.

where:

Equations (4) and (7) are obtained from Equation (2.2) in [18], Equation (8) is defi ned in [19], Equation (9) is reported in [20],and Equations (10), (11), (12), and (14) areobtained from simple trigonometric computations.

Table I. List of defined variables.

V. RESULTS AND FINAL CONSIDERATIONS

To perform computations we use the python library math. To model the considered LEO satellite constellation we exploit the python library networkx that allows the creation of a connected graph and the association of weights to its edges. In our case, the weights represent the communication delays of the ISLs.

Fig. 5. Minimum and maximum T.

Table II. Set of initial parameters used for the experiments.

To the purpose of computing the mean overall time to establish the routing path between THSand THD, we need to set the position of the control centre defined in terms of latitude and longitude coordinates, the altitude of geostationary satellites and their positions in terms of longitude. The longitude of the NMCCs and GEO satellites are always considered equal (?GE=?NM), so that the elevation angle between them, reported in Equation 9,depends only on the latitude of the NMCCs.Other parameters to be set for the experiments aremin andmin, which, respectively, are the minimum elevation angle between a ground station and a LEO satellite and the minimum elevation angle between a LEO and GEO satellite, respectively. These parameters are set to a value of 10°in order to avoid the presence of obstacles inside the communication path between the involved entities.

To take into account the effects of different paths in the simulations, the parameters

The set of parameters used in the simulations is reported in table 2.

Figure 5 shows the minimum and maximum values ofwith respect to the LEO satellite altitude hLEwhich influences the number of satellites and orbital planes considered in the model, as reported in [18]. Since the aim is that LEO satellites completely cover the Earth surface independently of their altitude, a specific number of orbital planes and satellites is needed: table 3 shows the number of orbital planes and LEO satellites necessary in order to cover the entire Earth with respect to the altitude of LEO satellites. From table 3 we can notice that increasing the altitude, the number of orbital planes and satellites per orbital plane decreases.

In figure 5, as expected,globally exhibits an ascending trend, since the end-toend-delay grows with the satellite altitude.We can also notice that, every time there is a decrease in the number of orbital planes, and,consequently, a reduction of the number of satellites involved in the complete Earth coverage,T slightly decreases. This reduction is due to the fact that a lower number satellites is needed in order to obtain a complete coverage of the Earth and, as a consequence, the number of hops to be performed by theflows in order to reach the destination decreases. In any case, this small decrease is balanced when the distance between two satellites increases due to the growing altitude. Consequently, the behaviour ofkeeps an ascending trend. It is worth noting that, considering a maximum altitude equal to 1500km, the maximum end to end delay is about 0.709s. This type of computation is essential to decide if a future 5G service can be forwarded to satellite portions or not. The time required to route and forward traffic over the considered SDN-based satellite network is not excessive but, of course, is in contrast with demanding delay sensitive applications.

VI. CONCLUSIONS

Traditional and currently operating satellite communication networks often rely on ad-hoc hardware components and proprietary software solutions. This hinders the integration of satellite and terrestrial networks and also of different satellite networks. New solutions are arising to ease the integration and allow satellites to be part of an overall Internet composed of heterogeneous networks, according to the network evolution envisioned in the 5G environment. New paradigms and keywords are proposed. Virtualization is one ofthem. It includes SDN, SDR, and NFV which have been developed for terrestrial networks.Their employment in satellite networks is not straightforward. This paper investigates the employment of the SDN paradigm in an integrated terrestrial-satellite network where three GEO satellites act as SDN controllers and the Data Plane is embedded in a LEO satellite constellation. A model to estimate the mean time required to complete the SDN control actions and to deliver thefirst packet of a new trafficflow is also proposed. The obtained results allow understanding which is the lower bound of the required mean delivery time.This value should be used by a userslash application tofix the performance requirements in case the satellite component is used or by the network management to decide if traffic may be forwarded through the satellite in a software-defined integrated terrestrial-satellite network.

Table III. Number of PL and SL needed for the complete coverage of the Earth.

In the proposed time estimation model,we have only considered propagation delays and assumed there is no handoff, i.e. the topology is unchanged during the traffic flow data delivery. Even if the assumptions seem reasonable for shortflows, the impact of transmission, queuing and forwarding delays must be considered for wider and possibly congested scenarios. The aspects neglected here will be investigated in future research. Other open issues to be tackled are: alternative integrated terrestrial-satellite network architectures,including, for example, Medium Earth Orbit(MEO) satellites; the study of a different distribution of the SDN Planes inside the network nodes; the impact of the overhead introduced by using the OpenFlow protocol for communication between SDN controller and switches;the synchronization problems due to the rapid movement of satellites; and the issues related to the migration of LEO satellites from one controller to another.