Fast Recovery Routing Algorithm for Software Defined Network based Operationally Responsive Space Satellite Networks

Abstract

An emerging satellite technology, Operationally Responsive Space (ORS) is expected to provide a fast and flexible solution for emergency response, such as target tracking, dense earth observation, communicate relaying and so on. To realize large distance transmission, we propose the use of available relay satellites as relay nodes. Accordingly, we apply software defined network (SDN) technology to ORS networks. We additionally propose a satellite network architecture refered to as the SDN-based ORS-Satellite (Sat) networking scheme (SDOS). To overcome the issures of node failures and dynamic topology changes of satellite networks, we combine centralized and distributed routing mechanisms and propose a fast recovery routing algorithm (FRA) for SDOS. In this routing method, we use centralized routing as the base mode.The distributed opportunistic routing starts when node failures or congestion occur. The performance of the proposed routing method was validated through extensive computer simulations.The results demonstrate that the method is effective in terms of resoving low end-to-end delay, jitter and packet drops.

1. Introduction

The operationally responsive space satellite (ORS-Sat) program [1] is derived from military objectives, which focus on establishing multiple global targets in a continuous reconnaissance network. ORS-Sat employs small and intelligent satellites inlow orbits that are equipped with synthetic aperture radar (SAR) and other equipment to form a constellation. In addition to the military applications, ORS-Sat addresses the requirements of contemporary economic development, disaster surveillance and other applications on account of its flexibility and coordination [2]. As a result, ORS-Sat can improve the data transmission ability of remote satellites by reducing the waiting time between ground station and grosynchronous orbit (GEO) satellites or polar orbit (PO) satellites.

However, many open problems about ORS-Sat exists, such as formation flights, networking schemes, run-time configuration of multiplefunctions, high level automatic and autonomous management on satellites, routing between satellites, adaptive data storageabilities, standardization and reconfiguration. These technologies do not meet the plug-and-play requirements in fast deployment of ORS-Sat, especially in cases in which a satellite changes its status from a waiting orbit (silence status) to an objective orbit (active status). In this paper, we therefore focus on the networking and routing problem of ORS-Sat networks.

The conventional ORS-Sat networking scheme can be classified into three types: (1) a single ORS satellite, which employs a single ORS-Sat monitoring, tracking and transmitting of information in the battle field or disaster area; (2) an ORS-Sat constellation, which consists of a set of ORS satellites to accomplish communicating or monitoring tasks; and (3) an ORS-Sat formation network, which employs several ORS satellites in accordance with a certain flight trajectory and constitutes a virtual satellite that completes data acquisition and transmission tasks. However, all of these schemes have problems in long-distance transmission. If the single ORS-Sat scheme is used, the data can be received only when the satellite crosses receiving terminals, and the waiting delay is inevitable. Otherwise, if the ORS-Sat constellation or ORS satellites formation network, we have to use more satellites to realize larger distance transmission, this is contrary to the principles of timeliness and low cost which are the main advantages of ORS satellites.

To solve this problem, we first propose use available relay satellites to realize large distance transmission. However,owing to different orbit altitudes, payload systems, mission targets and agencies, it is difficult to build a heterogeneous satellite network. Therefore, a ‘software satellite’ [3] and ‘cognitive satellite’ [4][5] are proposed to handle this problem. These new types of satellites make the equipment platform more versatile and flexible. The software defined network (SDN) is a recently developed network art that separates the data plane and control plane. Moreover, it is programmable [6] as a centralized control network. We additionally propose a networking scheme for ORS-Sat using SDN technology and based on common communication network architecture.

To handling recovery, we first apply anypath opportunistic routing to the SDN based ORS-Sat network, and propose a fast recovery routing algorithm (FRA) for the ORS-Sat network. The remainder of this paper is organized as follows. We give a review of None-Geo (NGEO) satellite routing and SDN technology in Section 2. The SDN-Based ORS-Sat networking scheme is introduced in Section 3. FRA is presented in Section 4. Section 5 outlines the results of our evaluation which show the benefits of our proposed routing method. Finally, our conclusions are presented in Section6.

 

2. Related Work

2.1 NGEO Satellite Routing

A significant amount of publised studies exist on routing for NGEO satellite constellations. A thorough review of the literature is beyond the scope of this paper. In terms of route design, the majority research concerns three aspects: load balancing, quality of service (QoS) and differentiated services (diffserv).

The following studies address load balancing.In [7], based on the utilization ratio of inter-satellite links (ISLs), priority-based adaptive routing (PAR) determines the next hop in shortest path set. In terms of fair traffic distribution among low earth orbit (LEO) constellations, a routing scheme based on explicit load balancing (ELB) [8][9] was proposed by Tarik et al. In ELB routing, when the primary shortest path experiences traffic congestion, the traffic is rerouted to the secondary path. In [10], a load balancing mechanism based on a new congestion-prediction method is presented. The main concept of that method is that the satellite in a congested area should preliminarily inform the subsequent neighboring satellite. In [11], the authors focus on the congestion between interlayers of traffic. They propose an adequate method to avoid congestion.

In terms of QoS, the QoS guarantee is one target of the routing design in satellite networks, delays, bandwidths, capacities etc., which are all evaluation factors. In the hierarchical and distributed QoS routing protocol (HDRP) [12], the optimal route is determined to guarantee the requested bandwidth and minimized transmission delay. In Pradas and Vazquez-Castro[13], a NUM-based framework is developed to balance rate-delay performance for multicasting over an adaptive satellite network. The framework incorporates video delay requirements by solving a weighted sum utility maximization problem. In [14], a cross entropy ant routing system improves the convergence time.

With regard to diffserv, Karapantazis proposes a multiservice on-demand routing (MOR) [16] based on the LAOR [15] protocol. It provides service differentiation by using a modified route computation mechanism and different cost metrics for each traffic class, However, it only uses local traffic information, which may not reflect the entire traffic load distribution.

Overall, these protocols are based on conventional routing schemes, which are limited because their applications are characterized by intermittent connectivity and weak infrastructure. Opportunistic routing (OR) fundamentally differs from traditional routing because it enables a dynamic, on-the-fly any-path routing via opportunistic relay selection [17]. Anypath routing is an optimization based OR. The concept of anypath routing was first introduced by Dubios-Ferriere [18], and was subsequently studied in [19-22]. In anypath routing, the anycast link cost is considered. This is the cost of reaching the next-hop relay. The remaining path cost is likewise considered. This is the cost of traveling from the next-hop relay to the destination. This methodcan provide a more effectvie approch to choosing the relay nodes of OR. Thus, in our proposed routing method, we introduce the opportunistic routing idea to increase the probability of transmission success.

2.2 SDN Technology

Emerging mega trends in the information and communication technology domain require the computer network to adapt to changes without being signifivantly labor intensive in terms of hardware or software adjustments. Traditional network operations cannot be easily reprogrammed or re-tasked [23]. To solve this problem, SDN architecture includes decoupling the control and data planes of the network. It relies on a set of switches with the simplest functions, which forward packets according to rules. The rules are managed by a software-based controller [24]. SDN can provide the potential benefits of enhanced configuration and improved performance It encourages innovation in network architecture and operations.

The reference model of SDN consists of three layers, the infrastructure layer, control layer and application layer [25]. The infrastructure layer consists of switching devices. The majority of the tasks of these devices are used to collect network statuses, store and forward them to the controller, and process packets based on rules provided by the controller. The control layer bridges the application and infrastructure layers by a south-bound interface and north-bound interface. The control layer is used to maintain the network status and define the rules of the network. The application layer is designed to fulfill user requirements through the programmable platform provided by the control layer.

OpenFlow is proposed to standardize the communication between the infrastructure layer and control layer [26]. It consists of a flow table, secure channel and the OpenFlow protocol. In OpenFlow networks, all the logic is performed on a centralized system and switches handle the message using the flow table. A flow entry in the flow table consists of “a packet header”, which defines the flow, “an action”, which defines the process action of the packet,and statistics which track the number of packets.

 

3. SDN-based ORS Satellite Networking Scheme

In this section, we propose the SDN-based networking scheme for ORS-Sat. We illustrate the difference between our model and the traditional SDN model. We then outline the ORS-Sat network structure.

3.1 Network Scheme Model

In ORS satellite missions, to realize the wide-span data transmission, we utilize available satellites as relay nodes. In other words, by leveraging ground stations, the ORS-Sat can locate available satellites either on LEO、MEO or GEO to establish a new virtual satellite topology. When the user wants to activate ORS-Sat, the system determines the method of establishing the optimal network and quickly completes the access authentication. It can the choose the optimal transmission path.

Fig. 1 shows the proposed SDN-based ORS-Sat networking scheme (SDOS). Lines of different colors signify different missions and solid lines signify data links. Supposing the satellite payload supports multiple network interfaces, and the communication devices of other satellites in this system are universal. The satellite can communicate with various existing networks. The ground transmission backbone network consists of L2 switches and L3 routers. All of these facilities support flow operation of OpenFlow. The mission control center (MOC) is mainly responsible for satellite observation tasks; ground stations are responsible for launching ORS-Sat and controlling the data transmission. To accept the task instructions and transmit task data, the ground stations are connected with a terrestrial backbone network.

Fig. 1.SDOS: SDN based ORS-Sat Networking Scheme

3.2 SDOS Reference model

Fig. 2 shows the proposed reference model and dataflow between the SDN facilities and existing satellites.Fig.2(a) shows the reference model of SDOS. Fig.2(b) [27] and Fig.2(c) [28] depict the existing satellites reference model.In SDOS, we assume that all satellites support the OpenFlow protocol and transmit through the flow table. The line in Fig.2 shows the dataflow of SDOS.

Fig. 2.Reference Model of SDOS

Unlike the conventional SDN network architecture,we introduce the inherent characteristics of the satellite network into SDOS, The control software in the control layer interacts with the SDN devices of the physical layer via OpenFlow.

The application layer provides network services for users, such as the satellite networking management protocol and data transmission protocol. The satellite networking management protocol is programmable. It can therefore monitor network traffic by using the network status provided by the control layer.

The control layer is used for maintaining the network status. It can interact with the physical layer via OpenFlow. The key function of OpenFlow is to manage data forwarding, which includes the flow table, secure channel and OpenFlow protocol. The flow table is used to store the forwarding rules. After the OpenFlow entity receives the data, it searches the flow table to find the matching forwarding information. Then, the controller decides how to forward the data based on this information. The secure channel is the interface connected to the OpenFlow switch and controller. The controller updates the flow table according to the OpenFlow protocol. Accordingly, the OpenFlow architecture enables centralized controlling of the network behaviors. The control layer extracts samples of the physical devices, while the application layer controls the network according to user’ needs. These processes make network virtualization more convenient. Furthemore, FlowVisor realizes the virtualized network to enable the hardware to be shared by several logical components.

 

4. Fast Recovery Routing Algorithm

In this section, we introduce FRA. FRA can be divided into two stages: a centralized routing stage, and a fast recovery stage. Opportunistic routing is used in the latter stage to handle incidents, including node failures, which means that next-hop satellite shuts down, in congestion or during emergency task.

4.1 Centralized Routing Stage

As in the conventional SDN network, the proposed network model is centrally operated. As discussed in [29], the minimal end-to-end delay of LEO-GEO system is 297ms, while that of the LEO-MEO system is 104ms. According to the real-time requirements of ORS tasks, we herein use only LEOs as the relay satellites. After receving the tasks set by MOC, the SDN controller determines the available LEO satellites as supplements of the ORS satellite constellation, It hence generates a new virtual satellite topologycollects the network status and initializes the flow table of each satellite. To decrease the load of the relay satellite and improve the performance, we transmit the data only through ORS satellites while the destination is covered in the ORS constellation.

Therefore, the most important task in the pre-computation procedure is to decide whether to use the relay constellation. Thus, when the task (time, data, source node (src), destination node (dst)) occurs, the SDN controller determines weather dst is in coverage with ORS satellites in slot t. The SDN controller computes the distance between src and dst. The distance between src and dst can be calculated as (1), where Li(t) = (xi(t),yi(t)) describes the location information of satellite i in time slot t.

If dis is smaller than the ORS-Sat coverage, we then compute the centric routing in the ORS-Sat layer. If dst is out of coverage of the ORS-Sat system, we use the relay constellation to transmit the data.

Assuming the distance of link i in time slot t is denoted by disli(t), transmission delay dli(t) can be calculated as:

Where C denotes the speed of light. Then, path r between src and dst is composed of links{l1,l2,l3⋯ln}, and the delay of path r is defined as d(r) =∑li∈rdli(t). We define R as the set of path r between src and dst.Then the shortest path in the ORS layer can be formulated as:

4.2 Fast Recovery Stage

OpenFlow follows an on-demand approach; that is, flow entries are not proactively added in switches. When a data packet arrives at an OpenFlow switch and it does notmatch a flow entry, it requests a flow entry from the controller by sending a “packet in” message [30]. In ground network, this mechanism maybe possible; however, problems occur when it is used in satellite network. Considering the long-round trip delay between satellite with ground station, we can not ensure that the controller can update the network status in real time. Thus, in the proposed SDOS scheme, the controller periodically updates the information. However, in this way, the satellite can not get the real-time information. If we ask the controller to reroute the data every time the node fails or experiences congestion, a large processing delay will. We therefore reroute on-board, using distributed routing to determine the new path and update the flow table.

In stage 1 of FRA, the routing path is stored in flow table. The SDN controller periodically calculates the path and uploads it to the satellites. This routing strategy is not sensitive to the node failure in each cycle. We thus use stage 2 as a recovery routing strategy to address this problem. When the node transmits the data, it first checks the flow table. If there is no record of this task, it asks the controller for the routing path. Otherwise, it sends a probe message to its neighbor. The reply message includes the neighbor node state information. The satellite transmits the data only if the reply message shows that the neighbor is in good status; otherwise, it begins the stage 2 to recover the path.

Compared to legacy routing, opportunistic routing selects the forwarder from a set of multiple receivers, which are typically known as a candidate relay set (CRS). This can significantly reduce the number of packet retransmissions caused by link failures. Thus, the concept of opportunistic routing can be prefectly applied to satellite networks. Anypath is always defined as the union of paths between two nodes [31]. Anypath routing is a generalization of single-path routing to solve the problem of finding optimal candidate relay sets and prioritize the candidate relays. Existing anypath routings always use packet loss to calculate the ETX, EAX, or EATT, which do not account for the cross-layer context of the link. On the other hand, side loading of the satellite network causes the hot spot problems. Thus, use of proper load balancing is a key factor in guaranteeing QoS. Accordingly, we propose penalty-based anypath routing in the LEO satellites layer.

In our proposed routing algorithm, we use two procedures to assist the nodes in determining which of its neighbors should be candidate relay nodes.

(1) Candidate relays filtering

The neighbor of the LEO satellite must satisfy:

Assuming that i and j are neighbors, disij is the distance between i and j in time slot t, dmax is the maximum transmission distance of satellite i, and dmax is related to the maximum transmit power and free space signal propagation. dhorizon is the maximum vision distance of link ij, it can be formulated as (5), where r is the earth radius and h is the height of the satellite.

To improve the efficiency of our routing scheme, we do not choose allneighbors as the relay satellites. Thus, after finding the neighbors, we filter the relay satellites.In a long-rang communication network, transmitting the data orientation to the destination will make the routing scheme more efficient.

As shown in Fig.3, if the node i is the source satellite, and node j is the destination satellite, the relay satellites of i should on the right hand of the solid line, we use the longitude as the constraint, the longitude of relay satellites should satisfied: lonsrc < lonrelay < londst.

Fig. 3.Relay Satellite Filtering

(2) The calculation of the anypath link cost

In time slot t, the transmission delay of link ij can be formulated as (6), where LS denotes the light speed and the node queuing delay has a significant influence on the transmission. We assume that the input and output traffic rates constant over a short period of time. Let Qi(t) denote the total length of the occupancy of the queue of satellite vi at time t. In addition, Pavg is the average packet size The routing table is updated every θ time intervals. Thus, when time t + Δt, C denotes the ISL capacity, and the node predicted value of the queuing delay in time t + Δt can be formulated as(7).

Where I is the total input traffic rates and O is the total output traffic rates at a given satellite. The total delay of time t can be formulated as:

On the other hand, the average bit error rate (BER) is a very strong indicator of how often the data units must be retransmitted on account of transmission error [32]. The BER for the QPSK signal is given as (9) [33]:

As in (9), the bit energy per noise density is related to the signal to noise ratio SNR as

where B is the bandwidth and Rb is the bit rate. SNR is calculated as:

where EIRP is the equivalent isotropic radiated power, G denotes the receiver gain, T is the temperature, FSL is the free space loss, Noise denotes the power of noise and Fading is a fading characteristic in the fading model.

To balance the load of the satellite network, we define a penalty function to increase the cost value of the nodes located in a hot spot region. Assume that the hot-spot region is range from X°E–Y°–E, where the centric latitude is Z°N.

We define the penalty function as:

Node v is closer to the hot spot region; therefore, the value of pf(t) is higher. Thus, the link cost matric can be formulated as:

We define the expected number of tranmissions (ETX) metric cij(t) to represent the expected number of tranmission necessary for a packet sent by i to be successfully recevied by j in J. It can be formulated as:

In (13), pij(t) is the delivery ratio of link ij. The anypath cost can be calculated as: Ci = minJ⊂N(i)(ciJ+CJ), which is composed of the hyperlink cost ciJ from i to J and the remaining anypath cost CJ from J to the destination, The remaining anypath cost CJ is defined as a weighted average of the costs of the nodes in the forwarding set where ωij is the probability of node j being the relaying node of node i in J. The FAR algorithm can operate in a distributed setting, in which nodes asynchronously recompute their costs and advertise them to their neighbors.

(3) Shortest Anypath Extraction

We use the shortest anypath extraction (SAE) algorithm to find the shortest anypath. Given graph G(V,E), the SAE algorithm calculates the shortest anypath from all nodes to a destination, d. For each node i ∈ V, we retain Ci as the anypath cost and Fi as the forwarding set. Fi stores the set of relays used as the next hop. Data structure S is used to store the set of nodes for which we already have the shortest anypath, while Q is a priority queue, which is used to store each node i ∈ V – S for which we still do not have a shortest anypath. Furthermore, Q is keyed by Ci.

As shown in Fig.4, the SAE algorithm first initializes the network status and sets the cost of destination d as 0. For the initial step of this algorithm, we have no shortest anypath for any node. Therefore, S is empty, while Q equals V. While Q is not empty, we use a Filtering-Min(Q) procedure to filter the candidate relay set and find the minimum cost node, j. SA is composed of N iterations, where N is the number of V. Assuming that the cost of each node in each iteration is a Fibonacci heap, the Filtering-Min(Q) procedure takes O(logV), with the total aggregated time of O(VlogV). In the SAE algorithm, we use the ‘for’ loop of lines 11 to 17 to update the anypath cost, which takes O(E) aggregated time. Thus, the total complexity of SAE is O(VlogV+E), which is the same as Dijkstra’s algorithm. In the centralized routing stage of FRA, Dijkstra’s algorithm is used to calculate the lowest cost path. Accordingly, FRA fully employs O(VlogV+E).

Fig. 4.Shortest Anypath Extraction Algorithm

 

5. Simulation Results

For the performance evaluation of FRA, the existing satellite component of the network simulator (ns-2) was expanded. Two centralized routings based on Dijkstra’s shortest path algorithm and two on-demand routings were tested, all of which are suitable for realistic satellite systems. The first centralized routing (DSP-PD) only considered the propagation delay, while the second one (DSP-PQ) was based on the sum of propagation delay and queuing delay. We used a hot spot scenario described in [34], which is based on web servers. The simulation parameters are given in Table 1.

Table 1.Applications in Each Class

Fig. 5 shows the results of the comparison in mean end-to-end delay of the proposed routing FRA with DSP-PD and DSP-PQ. To simulate our proposed method, we tested three methods for ten times, and obtained the mean test value. In this comparison, the average flow rate varied from 200 to 1,200 kb/s, and the routing table update time was 10 s. AlthoughDSP-PQ, which takes accounted for both the queuing delay and propagation delay, outperformed the DSP-PD, the simulation results show a minimal difference between them.

Fig. 5.Mean End-to-End Delay

For central routing, all communication between a pair of satellites was transmitted through the same path until the routing table was update, thereby making the path congested. However, as evident from the results shown in the figure, while the performances of DSP-PD and DSP-PQ worsened as the average flow rates increased, the performance of the proposed routing method maintained its effectiveness. These striking results are ascribed to the ability of the proposed method to capture the network state. Owing to the distributed aproach of FRA, each node could locally calculate the real-time routing cost and return to the resource node.

The mean delay jitter is defined as the variability of packet latency over time, Fig. 6 illustrates the mean delay jitter results with regard to successfully transmitted packets under increasing bitrates. From Fig. 6, it is clear that FRA performs better than centralized routing. The centralized routing must reflect the link cost until the routing table update. On the contrary, FRA iteratively computes the anypath cost after routing the request, and the remaining path cost is based on the neighbor anypath cost. Nevertheless, the penalty function decreases the probability of congestion. Therefore, FRAis more effective at responding to the change in network status.

Fig. 6.Jitter

By using the simulation results shows in Fig. 7, we verify the packet drop rate in FRA by comparing it to DSP-PD and DSP-PQ. It is evident that the packet drop ratio in our proposed routing method is drastically lower than that of the general model when the average bitrate increases. This is because account for the traffic distribution to avoid traffic congestion when the task occurs the hot spot area. Compared to the link costs of DSP-PD and DSP-PQ, we not only consider the propagation delay and queuing delay, but we also use BER to calculate the link cost. In the path selection process, the remaining path cost is one of the key factors of the better FRA performance.

Fig. 7.Packet Drop Ratio

 

6. Conclusion

ORS is an important part of research and development in the aerospace technology. To implement long range transmission, we proposed in this paper an SDN-based ORS network scheme. Based on this scheme, we introduced opportunistic routing in a satellite system, and proposed FRA. Our method uses distributed routing as a supplement to SDN-based centralized routing. In the rerouting process, FRA considers the link state of the network, and uses traffic distribution technology to avoid congestion in the hot spot region of the satellite system. To increase the transmission success rate, FRA calculates both ETX between the source node to neighbors and between the neighbors to the destination node. We evaluated our routing scheme with computer simulations and confirmed the effective reduction in end-to-end delay, jitter and packet drop ratio.